自己紹介とインターン参加の理由 自己紹介 公立はこだて未来大学 情報システム科学部 情報アーキテクチャ学科3年の阿部大晟と申します。 大学では主に情報デザインについて学んでおり、現在は数年後の未来で使われるアプリを制作するプロジェクトに携わっています。開発においては、フロントエンド側のUI/UX設計や、チームの進捗管理を担当することが多いです。 趣味はゲームや小説、アニメ鑑賞など日本のサブカルチャー全般です。 サイオスのインターンを選んだ理由 大学での説明会をきっかけに参加を決めました。目的は以下の3点です。 実際の現場で必要な能力の把握と習得 AI駆動開発の正しい手法の習得 （特に「Claude Code」を使用できる点） 就職活動に向けた実践的な学習 加えて、社員の方々の人柄が良く、「一度お話してみたい」と感じたことも大きな決め手でした。 開発したプロダクト：学習支援アプリ「メタゼロ」 制作物の紹介 私たちAチームが10日間で開発したのは、大学生の「メタ学習時間」をゼロに近づける学習支援アプリ 「メタゼロ（MetaZero）」 です。 「メタ学習時間」とは、学習を始める前に資料を探したり、勉強のスコープを定めたりする「探す・計画する・管理する」時間を指す私たちの造語です。 メタゼロは複数の大学サイトに分散した課題・試験情報を自動巡回して1枚の日程表に統合し、そこからAIとの対話で「いつ・何を・どれくらい」やるかの学習スケジュールを決定します。メタ学習時間削減により浮いた時間は、アップロードした資料から自動生成される模擬試験や一問一答に充て、学習そのものに集中してもらう狙いがあります。 私たちは 13画面と、AR実験機能まで実装 しました。 自分の役割 私は フロントエンド側を中心に担当し、UIデザインの方向性も決定 しました。 具体的にはタイトル画面や各種ロードマップの作成・UI調整、模擬試験などの画面実装です。 特にこだわったのは科目別ロードマップで、 「試験本番までの道のりをハニカム（六角形）で見せ、蜂がその日のセルを移動する」という演出 を作り込みました。 成果発表までの道のり ハッカソン形式で行われ、初日はアイスブレイクやセキュリティ研修がメインでした。その後、ワイヤーフレームを作成してイメージを共有しながら開発を進めました。 開発の軸となったのは、 「仕様書を唯一の正とする」こと 。仕様書をもとに「実装→レビュー→テスト」のループを回し続ける手法により、非常にスムーズに開発を進めることができました。 チーム開発を通じて気づいたこと、学んだこと コミュニケーションの大切さとコンフリクトからの学び 開発当初、「ワイヤーフレーム通りに実装すれば大丈夫だろう」と高を括り、大した相談もせず開発を進めていたため、コンフリクト（コードの衝突）が頻発してしまいました。また、途中でフロントエンドとバックエンドで担当を分けた際にも、連携の難しさを実感しました。 そこでチームでの進め方を見直し、 「バックエンド1人・フロントエンド2人」の層（レイヤー）で分担し、両方が触るデータの形（API）だけ事前合意した上で、それ以外は「〇〇を直す。影響ある人がいたら教えて」の一報だけで進めるルールに変更 しました。これにより承認待ちで手が止まることがなくなり、リモートでも開発スピードを維持できるようになりました。 この経験を通して、「短くても的確に伝わるコミュニケーション」の重要性を痛感しました。チームが連動して動くことで、結果的により良いものが生まれます。 コミュニケーションは他人のためだけでなく、「自分のため」でもあるの だと強く感じました。 「1コミット1関心事」とAIを活用した仕組みづくり 開発面では、 コミットを「1コミット1関心事」に徹底 し、メッセージの型（feat:, fix:など）と理由をGitフックで機械的に検査しました。また、AIエージェントを活用し、コードをレビューする役目と、テストの期待値を決める役目を実装者から切り離しました。 「指摘する人と直す人を分ける」「コードを1行も読まずに期待値を先に決める」仕組み により、期待値が実装に引きずられて甘くなるのを防ぐことができました。  SIOS Values（チームワークとパッション）の実践 サイオスが掲げる5つの指標のうち、私は特に 「チームワーク」と「パッション」を意識 しました。常に「チームワークが大事だ」と念頭に置き、環境づくりにも注力したことで、開発そのものも円滑に進むと感じました。 チームメンバーは優秀な方ばかりで、助けられてばかりでした。実装で手が止まった時や意見を求めたい時には必ず丁寧にサポートしてくれました。特に感心したのは、皆さんの物腰が柔らかく、自然と話しやすい環境になっていったことです。笑いながら作業できる和やかさがありつつ、決してたるんでいない、素晴らしい環境でした。 彼らがいなければこのアプリは完成しなかったと思います。  認識共有の難しさと「ほうれんそう」 開発で一番苦労したのは「認識の共有」です。 人が持つイメージは本人にしか100%理解できません。しかしチーム開発では複数人のイメージをすり合わせる必要があります。 これが想像以上に難しく、きちんと共有できていないと、いつの間にか見当違いの方向へ進んでしまうことが多々ありました。 人は間違えるからこそ、見当違いを防ぐ仕組みづくりが必要だ と学びました。 また、Claude Codeのような便利で作りやすいAIツールがあるからこそ、一歩立ち止まって考える時間が必要だと痛感しています。私は「これがあったら喜ばれるだろう」と良かれと思って独断で機能を追加実装してしまい、結果として重めのバグを残してしまうという失敗をしました。 便利だからと勢いで進めるのではなく、 仲間がいる以上、最低限の共有（ほうれんそう）は絶対に欠かしてはいけない と猛省しました。 最大の学びと、これからの目標 サイオスのインターンシップを通じて「エンジニア」のイメージが大きく変わりました。 最大の収穫は、 「エンジニアに一番大切なのはコミュニケーション能力である」と知れたこと です。 もともとエンジニアの仕事は、「頭をフル回転させて一人でコードを実装する」という イメージでした。 しかし実際は、時間の大半は「要件定義」に費やされます。またコードの実装自体も、Claude Codeなどのツールで代行できるケースが今後さらに増えていくからこそ、 最終的に差がつくのは人との対話力だと感じました。 私の中で、エンジニアとは 「プロジェクトのゴールを達成するために、仲間と話し合い、コミュニケーションを通じて物事を解決していく職業」 へと大きく変わりました。 私にとってこのエンジニア像のアップデートは、非常に大きなものでした。 今後の展望 今回のインターンを通じて、今後の自分に向けた明確な目標が2つできました。 1つ目は、 英語の学習 です。 コミュニケーションツールとして英語ができれば、国境の壁を越えてさまざまな人と円滑に連携が取れると感じたためです。 2つ目は、 セキュリティの学習 です。 開発速度が劇的に上がるこれからの時代だからこそ、セキュリティを深く理解していれば、より安心して技術を活用できるのではないかと考えています。 これからインターンを受ける後輩へ向けたアドバイスや応援の一言！ サイオスのインターンシップは、オンライン開催でありながら、社員の方々とのコミュニケーションの機会が豊富にあり、非常に有意義な10日間でした。 これからのIT業界で必要なスキルを、確実に学べるインターンだと思います。 今後参加される方は、ぜひ 「大いなる熱意」 をもって臨んでみてください。必ず素晴らしい経験になるはずです。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post コンフリクトの頻発を乗り越え「報告・連絡・相談」でチームが団結！ first appeared on SIOS Tech Lab .

G-genの本間です。当記事では、Gemini Enterprise Agent Platform（略称 Agent Platform）が提供する、フルマネージドの AI エージェント実行基盤である Agent Runtime へ、エージェントをデプロイする際のデプロイ手法について解説します。 はじめに Agent Platform とは Agent Runtime とは 当記事について 5つのデプロイ手法 概要 1. Developer Connect を使用してデプロイする 2. ソースファイルからデプロイする 3. Dockerfile を使用してデプロイする 4. コンテナイメージを使用してデプロイする 5. Agent Platform SDK オブジェクトからデプロイする 選び方と使い分け はじめに Agent Platform とは Gemini Enterprise Agent Platform（旧称 Vertex AI、略称 Agent Platform ）は、AI エージェントを構築、管理、実行するために必要な機能を提供する Google Cloud の統合プラットフォームです。 このうち、エージェントの統制を担う機能として、エージェント固有の ID を発行する Agent Identity 、エージェントやツールを登録して検出可能にする Agent Registry 、これらを参照して通信を制御する Agent Gateway があります。 Agent Platform の全体像については、以下の記事を参照してください。 blog.g-gen.co.jp Agent Runtime とは Agent Runtime は、Agent Platform に内包されたプロダクトの1つで、エージェントを実行するためのフルマネージドの実行基盤です。Agent Runtime では、組み込みの機能として、エージェントのマルチターン会話を実現するセッション機能や自動スケーリング機能、その他エージェントの機能拡張・運用管理に必要な様々な機能を使用できます。 Agent Runtime の全体像については、以下の記事を参照してください。 blog.g-gen.co.jp 当記事について Agent Runtime に対してエージェントをデプロイするにあたり、デプロイ手法を5つのうちから選択できます。当記事では、それら5つの手法について概要を説明します。 参考 : Deploy an agent 5つのデプロイ手法 概要 Agent Runtime で使用可能な5つのデプロイ手法の概要は、以下のとおりです。 No. 名称 概要 1. Developer Connect を使用してデプロイ Developer Connect を介してリンクされた Git リポジトリから直接ソースコードを取得してデプロイする手法。 2. ソースファイルからデプロイ ローカルファイルシステム上のソースコードから直接デプロイする手法。 3. Dockerfile を使用してデプロイ ローカルのソースコードと Dockerfile を送信し、Agent Runtime 側でコンテナイメージを自動でビルドしてデプロイする手法。 4. コンテナイメージを使用してデプロイ Artifact Registry にホストされているコンテナイメージを指定してデプロイする手法。 5. Agent Platform SDK オブジェクトからデプロイ Colab などのノートブック環境で定義されたインメモリのエージェントオブジェクトを直接 Agent Platform SDK の関数に渡してデプロイする手法。 なお 2026年10月現在、Agent Runtime は Google Cloud コンソールや標準の gcloud CLI からの直接デプロイには対応していないため、いずれの方式を選択した場合でも、基本的には Agent Platform SDK （または REST API / ADK CLI）を使用し、コードベースでデプロイを実行する必要があります。 また5つのうち、いくつかの手法では、Terraform を用いたエージェントのデプロイや、インフラ基盤の設定管理も可能です。 1. Developer Connect を使用してデプロイする Google Cloud と GitHub や GitLab などの外部のソースコード管理システムを連携・統合するためのサービスである Developer Connect を使用し、Git リポジトリから直接デプロイする方式です。事前にリポジトリの接続設定を実施したうえで、Agent Platform SDK の developer_connect_source パラメータにリポジトリやブランチを指定してデプロイします。 この方式の場合、エージェントの実装に使用できるプログラミング言語は Python のみです。Developer Connect で Git リポジトリを接続する工数は発生しますが、Git 連携が可能となるため、バージョン管理と連動した継続的デリバリーの自動化に適しています。 参考 : Developer Connect の概要 2. ソースファイルからデプロイする ローカル環境のソースファイルから、Agent Platform SDK を使用して Agent Runtime へ直接デプロイする方式です。デプロイ実行時に、対象の開発ディレクトリやエントリーポイント、公開するメソッド定義を指定します。 この方式の場合も、エージェントの実装に使用できるプログラミング言語は Python のみです。Infrastructure as Code（以下、IaC）や GitHub Actions / Cloud Build などの標準的な CI/CD パイプラインに組み込むワークフローと親和性があり、他の選択肢と比較して導入工数が低い点が特徴です。ただし、デプロイ実行時に指定する開発ディレクトリの合計ファイルサイズが 8MB を超えてはいけないという制限があるため、仮想環境ディレクトリや巨大なアセットが含まれないよう注意が必要です。 3. Dockerfile を使用してデプロイする ローカルのソースファイルとともに、 Dockerfile を指定し、Agent Runtime 側でコンテナイメージの自動ビルドとデプロイを実行させる方式です。 この方式では、エージェントの実装に Python 以外のプログラミング言語を使用できます。また、コンテナ環境を定義できるため、OS レベルでのシステムパッケージのインストールや、エージェントをホストする API サーバーの細かい制御が必要な場合にも適しています。なお、ビルドされるコンテナは Agent Runtime が定める所定のランタイム契約（Runtime contract）に準拠している必要があります。詳細は以下の公式ドキュメントを参照してください。 参考 : Agent Platform runtime contract 4. コンテナイメージを使用してデプロイする 事前に Artifact Registry にビルド済みのコンテナイメージを push し、Agent Platform SDK でイメージ URI を指定して Agent Runtime へデプロイする方式です。実行にあたっては、Agent Platform のサービスエージェントに対して、対象の Artifact Registry の読み取り権限を付与する必要があります。 「Dockerfile を使用してデプロイする」方式と同様に、Python 以外のプログラミング言語でもエージェントの実装が可能であり、ランタイム契約への準拠が必要です。 Dockerfile 方式との主な違いは、 デプロイ時に Agent Runtime 側でビルドするか、事前ビルドしたイメージをデプロイするか という点です。「コンテナイメージを使用してデプロイする」方式は事前ビルドが完了しているため、デプロイ時のパッケージインストール等による待ち時間を最小化できます。 こちらの方式は、CI パイプライン上でコンテナの脆弱性スキャン等のセキュリティツールを通過したイメージのみを本番環境にデプロイするといった、厳格なガバナンス要件や「基盤管理と開発管理の分離」が求められるエンタープライズ環境に適しています。 参考 : Set up the environment - Identity and permissions 5. Agent Platform SDK オブジェクトからデプロイする Colab Enterprise や Agent Platform Workbench などのノートブック環境で定義したメモリ上の Python オブジェクトを、直接 Agent Platform SDK の関数に渡してデプロイする方式です。Python の pickle を用いてメモリ上のエージェントオブジェクトをシリアライズし、Cloud Storage バケットへアップロードします。その後、アップロードされたファイルをもとにコンテナがビルドされます。 この方式では、ノートブック環境でコードを書いて、その場でインタラクティブに動作検証や初期プロトタイピングを手軽に行えます。一方、シリアライズできない複雑なデータ構造や依存関係を持つオブジェクトには適用できず、手動実行が前提となるため、CI/CD パイプラインへの組み込みには適していません。 また、エージェントの実装に使用できるプログラミング言語は Python のみです。 参考 : Introduction to Colab Enterprise 参考 : Introduction to Agent Platform Workbench 選び方と使い分け ここまで紹介した Agent Runtime への5つのデプロイ手法は、主にそれぞれ 「エージェントの対応言語」「Cloud Storage バケットの要否」「カスタマイズ性」「CI/CD や IaC との親和性」 に違いがあります。 開発フェーズ（初期のプロトタイピングか、本番の CI/CD 運用か）や、チームが採用するプログラミング言語・セキュリティ要件に合わせて、以下の比較表を参考に最適なデプロイ手法を選択してください。 名称 エージェントの対応言語 Cloud Storage バケット CI/CD・IaC 適性 主なユースケース 主な特徴・制約事項 Developer Connect を使用してデプロイ Python のみ 不要 ◎ Git リポジトリと直結した継続的デリバリー Developer Connect の事前設定が必要。リポジトリから直接コードを取得してデプロイするため、複雑な事前ビルド処理を伴う運用には不向き。 ソースファイルからデプロイ Python のみ 不要 ◎ Terraform や GitHub Actions 等を用いた標準的な本番運用 Pickle 化を行わないため依存関係の再現性が高く、導入工数も低い。送信するソースコード合計サイズに 8MB の制限 あり。 Dockerfile を使用してデプロイ 任意の言語 （Go や Java 等も可） 不要 ◯ OS パッケージの追加や、Python 以外の言語を使用する場合 クラウド側でコンテナを自動ビルド。ランタイム契約への準拠が必要。 コンテナイメージを使用してデプロイ 任意の言語 （Go や Java 等も可） 不要 ◎ 厳格な脆弱性スキャンや、デプロイ時間短縮が求められる本番環境 Artifact Registry のビルド済みイメージを指定するため、デプロイ時のレイテンシが小さい。サービスエージェントへの権限付与とランタイム契約への準拠が必要。 Agent Platform SDK オブジェクトからデプロイ Python のみ 必須 △ Colab Enterprise 等のノートブック環境での初期プロトタイピング・検証 メモリ上のオブジェクトを pickle で直感的にデプロイ可能。シリアライズできない複雑な構造や CI/CD への組み込みには不向き。 どの方式を採用すべきか迷った場合は、開発のフェーズやプロジェクトの要件を整理したうえで検討してください。 手軽に動作を試したい初期検証フェーズの場合は、ノートブック環境からすぐに実行できる 「Agent Platform SDK オブジェクトからデプロイ」 や、比較的導入コストが低い 「ソースファイルからデプロイ」 から始めることを推奨します。 Python で開発したエージェントを本番運用へ移行し、CI/CD パイプラインへ組み込むフェーズでは、導入コストが低く Terraform などの IaC ツールとも組み合わせやすい 「ソースファイルからデプロイ」 、あるいは Git 連携の機能を十分に発揮できる 「Developer Connect を使用してデプロイ」 が選択肢に入ります。 Go や Java といった Python 以外のプログラミング言語でエージェントを実装する場合や、OS レベルのライブラリ追加といった環境カスタマイズが求められる場合には、 「Dockerfile を使用してデプロイ」 または 「コンテナイメージを使用してデプロイ」 を選択します。特にエンタープライズの本番環境において、CI パイプラインでのコンテナ脆弱性スキャンを必須とする場合や、スケーリング・デプロイ速度、基盤管理と開発管理の分離を重視する場合には、 「コンテナイメージを使用してデプロイ」 の採用が最適です。 本間 優太郎 (記事一覧) クラウドソリューション部 クラウドエンジニアリング2課 北海道在住 2026年6月に G-gen にジョイン。前職では社内SE、Sler としてアプリ/インフラ開発業務に従事。アプリ/インフラ双方の経験をベースに現在はGoogle Cloudの学習を進めている。 好きなことは子供と遊ぶこと、ゲームをすること。

ロボットは「動く展示物」から「AIが働く身体」へ 2026年10月13日から16日にかけて幕張メッセで開催されたCEATEC 2026に参加した。生成AIが普及し始めたここ数年、AI業界では「次はPhysical AIだ」という言葉を耳にする機会が増えている。Physical AIとは、AIがロボットや機械の身体を通じて現実世界を認識し、自律的に行動する技術やその概念を指す。生成AIは文章を書いたり画像を生成したりすることはできるが、現実世界で物を運んだり、収穫したり、組み立てたりすることはできない。Physical AIとは、そのAIに「身体」を与え、現実世界で行動できるようにす