AI & 機械学習

エージェンティックエンタープライズに関する 20 の質問（Agent Platform がどのように役立つか）

2026年7月17日

Kanchana Patlolla

Product Manager, Gemini Enterprise Agent Platform

Greg Brosman

Product Manager, Gemini Enterprise Agent Platform

Try Gemini Enterprise Business Edition today

The front door to AI in the workplace

Try now

※この投稿は米国時間 2026 年 7 月 8 日に、Google Cloud blog に投稿されたものの抄訳です。

IT リーダーであれば、エージェントの構築とデプロイの方法について多くの質問を受けているかもしれません。

迅速な対応を求めるプレッシャーは強いものですが、エンジニアリングの現実は極めて複雑です。チームはどこから着手すればよいのでしょうか。断片化し、バラバラに乱立するツール群を、どのように整理すればよいのでしょうか。また、規模が拡大するにつれて、エージェントが誤って機密データを漏洩したり、わずか半日でトークン予算を使い果たしたりしないようにするには、どうすればよいでしょうか。バランスを取るべきことが多く、組織全体の安全な基盤を確立しようとすると、すぐに手に負えないと感じてしまう可能性があります。

Google が Gemini Enterprise Agent Platform を構築したのはそのためです。これにより、技術チームは、顧客対応エージェントと社内業務を管理するエージェントの両方を構築、スケーリング、ガバナンス、最適化できる統合された環境を利用できるようになります。根底にある複雑な制御は Agent Platform が担うため、チームは本来のビジネス価値の創出に集中できます。

こうした会話をスムーズに進めるために、エンジニアリングチームに尋ねるべき 20 の重要な質問と、すぐに着手できる実用的なアドバイスやコード例をまとめました。それでは詳しく見ていきましょう。

構築フェーズ — 基盤の確立

#0 アプリケーションを構築しているのは誰か？ツールを選択する前に、チームの誰が実際に作業を行っているかを確認します。エンジニアでしょうか？それとも法務チームでしょうか？AI を活用した構築は、もはやハイコードエンジニアだけのものではありません。誰でもバイブコードを生成できるようになりました。この驚くべきアクセシビリティにより、数百万人の非プログラマーが、数秒でアプリケーションを構築してリリースできるクリエイターに変わったのです。つまり、社内のあらゆる場所からアプリケーションが生まれてくる可能性があるということです。これは当たり前のステップのように聞こえるかもしれませんが、AI 時代においては非常に重要な意味を持ちます。

現在、このエコシステムは、ノーコードのビジネスエキスパートがビジュアルインターフェースを介してロジックを定義する（ビジネスチーム、セールス、マーケティングなど）、ローコード デベロッパーがモジュール部品を組み立てる、ハイコード エンジニアがオーダーメイドのカスタム推論ループを作成するなど、幅広い層のペルソナを網羅しています。導入を成功させる鍵は、データやセキュリティをサイロ化することなく、3 つのペルソナすべてを支援するプラットフォームを選択することにあります。

#1 デベロッパーはどこから始めるべきか？エージェント活用戦略を立てる際、カスタマーサポートや財務分析を行うエージェントなど、最終的な成果物にのみ焦点を当てがちです。しかし、そのように高度なエージェントを構築するには、まず、その基盤となるロジックを記述するビルダーを支援することから始める必要があります。デベロッパーがコード生成やスキャフォールディング、統合を加速させるには、コーディングエージェントのような専用の AI ツールが必要です。

しかし、ほとんどのコーディングエージェントは孤立した状態にあります。これらのツールは、作業中のファイルを分析することしかできず、稼働中のデータベース、社内ドキュメント、技術スタック、ビジネスシステムとは連携されていません。

デベロッパーがガバナンスを犠牲にすることなく迅速に開発を進められるようにするには、Google Antigravity を主要なエンジニアリングハーネスとして使用し、チームが構築しているものに基づいて特定の拡張機能を統合することをおすすめします。以下に、その内訳を示します。

コアアプリケーションエンジニア向け: アップグレードされた Agent Development Kit（ADK）をベースラインフレームワークとして使用し、Agents CLI と組み合わせて、ターミナルからエージェントのライフサイクル全体を管理しましょう。
データエンジニア向け: データパイプラインに特化した専用スキルや Model Context Protocol（MCP）ツールを提供する Google Cloud Data Agent Kit を導入しましょう。
Google Cloud エコシステム向け: エージェントスキルをデプロイして、Google プロダクトを横断するネイティブな機能をコーディング環境に持たせましょう。
IDE 統合エクスペリエンス向け: MCP を介してデベロッパー向けナレッジベースに接続し、公式ドキュメントをチームのワークフローに直接取り込みましょう。

#2 誰のために構築するのか？人間か、それとも他のエージェントか？#1 と同様に、これは単純な質問のように聞こえるかもしれませんが、従業員が直接対話する AI エージェントを構築するのか、それとも舞台裏で他のエージェントと連携させるのかを、早い段階で判断しておくのがよいでしょう。システムとやり取りするユーザーや対象によって、設計要件はまったく異なります。すべてをチームの管理下に置くには、まず誰のために構築しているのかを正確に把握することが重要です。

対象が人間（従業員や顧客向けに構築）の場合は、ユーザーエクスペリエンスに焦点を当てましょう。これらのツールは、Gemini Enterprise app のような単一の場所でホストして共有できます。また、Agent-to-User Interface（A2UI）フレームワークを使用して、インタラクティブなコンポーネントをカスタムアプリに直接組み込むこともできます。

対象がエージェントの場合（他のエージェントと対話するエージェントを構築する場合）、相互運用性に焦点を当てましょう。AI エージェント間のシームレスな通信とコラボレーションのためのオープン標準である、オープンな Agent2Agent（A2A）プロトコルを採用することで、エージェントは標準化されたメタデータを使用して互いを検出し、コンテキストを共有して、完全に異なるエンタープライズフレームワークを横断してバックグラウンド作業を安全に委任できるようになります。

ユーザーとエージェントの ID について詳しくは、質問 #14 をご覧ください。

#3 どのエージェント開発ツールを使用すべきか？利用できるフレームワークが非常に多いため、エンジニアリングチームは、断片化された自社開発のセットアップをデフォルトとして使用しがちです。これを簡素化するために、Google ではエージェント開発を 4段階のはしごとして定義しています。これにより、チームはすぐに使える標準構成から、コードファーストの高度な制御まで、ニーズに合わせて柔軟に行き来することが可能になります。

1 段目: Agent Studio（ローコード）: 迅速なプロトタイピングやビジネスチームに適した、Agent Platform 内のビジュアルワークスペース。Agent Studio でエージェントを構築するには、こちらをご覧ください。
2 段目: Managed Agents API（Agent-as-a-Service）: API を介してエージェントの動作を定義し、安全なサンドボックス内のインフラストラクチャの管理を Google に任せたい技術チーム向け。Managed Agents API を使用してカスタムエージェントを構築するには、こちらをご覧ください。
3 段目: Antigravity 2.0: 高度なコーディングタスクやエンジニアリングパイプラインに AI を活用するデベロッパー向けの専用ワークスペース。Antigravity を使用して構築するには、こちらをご覧ください。
4 段目: Agent Development Kit（ADK 2.0）: ソフトウェアエンジニアが高度にカスタマイズされたマルチエージェントネットワークをゼロから構築するための、エンジニアリングファーストかつコードファーストなフレームワーク。ADK を使用してサンプルエージェントを構築するには、こちらをご覧ください。

#4 エージェントは 1 つから始めるべきか、複数から始めるべきか。また、どのように専門化すればよいか？プロトタイピングの初期段階では、高度に専門化された単一のエージェントから始めるよう、常にチームに推奨してください。エージェントがすべてを処理しようとすると、精度が低下して、レイテンシが急増し、デバッグが非常に困難になる可能性があります。これを避けるには、的確な指示を記述し、アクセスできるツールを制限するようにしましょう。

ワークフローが複雑化した場合や、モデルのコンテキストの上限に達した場合は、エンジニアをマルチエージェントシステムに移行させましょう。マルチエージェントシステムは、本質的には、目標を達成するために連携する個々の自律型エージェントの集合体です。ADK のようなフレームワークを使用すると、エージェントをサブエージェントのネットワークに整理できます。このネットワークでは、コーディネーターが特定のタスクを専門の役割を持つメンバーに委任するため、明確な編成ロジックを維持することが可能です。

例: ADK を使用してサンプルマルチエージェントソリューションを構築するには、こちらをご覧ください。

スケーリングフェーズ - 接続性と相互運用性

#5 エンタープライズデータを接続し、適切なビジネスコンテキストを維持するにはどうすればよいか？エージェントが真に役立つためには、適切なデータにアクセスする必要があります。ここで「企業の実体」が登場します。これは、エージェントが成功するために必要な、エンタープライズ固有のデータ、ツール、制約、ポリシー、プロセスを指します。

これを実現する方法はいくつかありますが、新たな手法として普及しつつあるのは、Model Context Protocol（MCP）などのオープン標準を使用して、エージェントを稼働中のデータベースやビジネスアプリケーションに直接接続する方法です。しかし、接続を確立するだけでは十分ではありません。エージェントが正確に動作し、ハルシネーションを回避できるようにするには、また、明確なビジネスコンテキスト、メタデータ、ロジックを使用してこのデータを整理する必要があります。この構造化されたアプローチにより、エージェントは単に生の情報を取得するだけでなく、それを正しく解釈して、組織全体でより適切な意思決定を行えるようになります。

例: ADK と MCP ツールボックス（マネージドサーバー）を使用して、サンプルマルチエージェントソリューションを構築しましょう。

#6 完全に異なるフレームワークで構築されたエージェントを接続するにはどうすればよいか？大規模な組織では、各チームが特定のニーズに最適なツールを使用してエージェントを構築するのが自然です。LangGraph や自社開発のフレームワーク、あるいはまったく別のものなど、さまざまなツールが使われることになるでしょう。しかし、これらのシステムが連携できない場合、データとワークフローが孤立し、サイロ化を招いてしまいます。

共通の通信標準を確立することで、まったく異なるプラットフォームやフレームワークで開発されたエージェント同士が、特別な統合作業なしにインテント、状態、結果をやり取りできるようになります。

フレームワークをまたぐ接続（たとえば、LangGraph ベースの HR エージェントを ADK ベースの CRM エージェントに接続する場合など）には、A2A プロトコルを実装できます。これにより、複数の独立したエージェントを横断するマイクロサービススタイルの通信パターンが可能になり、エージェント同士が安全に相互通信できるようになります。

例: ADK と A2A を使用して、サンプルマルチエージェントソリューションを構築しましょう。

#7 エージェントが特定のツールを見つけられるようにするにはどうすればよいか？エージェントのコンテキストウィンドウに複数のツールや API を詰め込むと、パフォーマンスが低下して、レイテンシが増加し、トークン費用も上昇します。RAG を使用してオンデマンドでデータを動的に取得するのと同様に、エージェントのツールについても、同様の動的な取得戦略を適用する必要があります。

特定の機能に特化したエージェントスキルを活用することで、エージェントはタスクに必要な場合にのみ機能を読み込みます。エージェントは、汎用的な指示の膨大なライブラリを解析するのではなく、タスク固有の単一のインデックスカードから情報を取得するため、正確で厳密に制御された実行が可能になります。

例: ADK とスキルを使用してマルチエージェントオーケストレーションパターンを構築しましょう。

#8 エージェントを簡単にスケーリングできるようにデプロイするにはどうすればよいか？これは「100 万ドル級の難問」です。あるいはより正確に言えば、「1 分あたりのトークン数」の問題かもしれません。重要なのは、単に最も安価なオプションを選択することではなく、ワークロードのパターンに合ったツールとサービスの適切な組み合わせを見つけることです。

インフラストラクチャのオーバーヘッドを大幅に増やすことなくエージェントをスケーリングするには、フルマネージドのサーバーレス実行環境内にエージェントをデプロイすることをおすすめします。Agent Runtime は、デベロッパーが本番環境で AI エージェントをデプロイ、管理、スケーリングできるようにする一連のサービスです。本番環境でエージェントをスケールするためのインフラストラクチャの処理は Agent Runtime が担うため、デベロッパーはアプリケーションの作成に注力できます。

プロダクションレディなランタイムでは、使用量の急増に対処するための伸縮自在な自動スケーリング、カスタムソフトウェアの依存関係をバンドルするためのコンテナ化による柔軟性、そして低レイテンシのリアルタイムインタラクションを確保するための双方向ストリーミングのネイティブサポートを備えている必要があります。また、このアーキテクチャには、パブリックインターネットにさらすことなく社内のエンタープライズデータに安全に接続するための、組み込みのプライベートネットワーキングインターフェースも統合する必要があります。

例: Agent Runtime を使用してマルチエージェントオーケストレーションパターンを構築しましょう。

#9 長時間実行されるタスクで、エージェントがコンテキストを見失った場合はどうすればよいか？AI エージェントがより効果的に動作できるように、短期記憶と長期記憶の両方を持たせることができます。つまり、リアルタイムのセッション状態によって直近の会話を維持し、長期ストレージレイヤによってユーザーの好みや過去のやり取りを記憶するということです。これらすべてを、エージェントをチームの管理下に安全に置いたまま実現できます。

Agent Platform では、これを 2 つのレイヤで処理します。ADK では、sessionService が複数ステージのタスクにおける直近のステップを処理します。Agent Memory Bank が永続的な長期ストレージレイヤとして機能し、過去のユーザーの好みやプロジェクトの成果を長期にわたって呼び出す役割を担います。

例: Agent Memory Bank と ADK メモリを使用してマルチエージェントオーケストレーションパターンを構築しましょう。

最適化フェーズ — 信頼と効率

#10 スクリプトを実行したりブラウザを使用したりするエージェントの影響範囲を制限するにはどうすればよいか？エージェントが Python やスクリプトを実行したり、ウェブを閲覧してデータを収集したりする必要がある場合、それらを自社ネットワーク上で直接実行させるべきではありません。これらのタスクを一時的な隔離されたサンドボックス環境で実行することで、信頼できないコードやランタイムロジックのエラーを簡単に隔離し、コアエンタープライズシステムから完全に分離できます。

さらに、組み込みのサンドボックスを備えたエージェントランタイムを使用することで、主要なインフラストラクチャを保護しながら、チームの完全な制御下でエージェントにツール呼び出しを安全に実行させることができます。

例: Agent Sandbox を使用してマルチエージェントオーケストレーションパターンを構築しましょう。

#11 エージェントがブランドから逸脱しないようにするにはどうすればよいか？エージェントは企業のアイデンティティを体現する存在です。明確な制約を伴うシステムプロンプトを定義することは第一歩ではありますが、プロンプトだけに頼ることは、本番環境のセキュリティにおいて不十分（かつ危険）です。モデル本来の確率的な性質にかかわらず、エージェントが常に制限された状態を維持できるように、企業の中核的なルールとトーンの制約を強制する必須の安全レイヤが必要です。

ガードレールは、自律的な意思決定を行う柔軟性をエージェントに持たせつつ、コアの安全ルールへの違反を確実に防ぐことで、予測不可能な LLM を安全なエンタープライズシステムに変えます。これらの境界は、エージェントの推論の外部で決定論的な制約として実装されるため、回避することは不可能です。

この安全レイヤを補完する構造化ワークフローは、複雑なタスクを決定論的なステップバイステップのパイプラインに分割することで、予測可能性をさらに高めます。このパイプラインでは、コードレベルのルーティング、条件付きロジック、状態管理を使用して、エージェントを再現性のあるパスに沿って誘導します。

例: Guardrails エージェントを使用してマルチエージェントオーケストレーションパターンを構築しましょう。ADK ワークフローもご覧ください。

#12 結果をどのように信頼するか？信頼は、エージェントのライフサイクル全体にわたる厳格なテストと継続的な評価から得られたエビデンスによって築かれます。信頼は自動的に得られるものではなく、手法の結果として得られるものです。

大規模な環境では、指標、人間参加型の監視、LLM-as-a-Judge パターンを組み合わせて評価を自動化します。より高性能なモデルや、専門的な自己評価エージェントを使用して、エンドユーザーに届く前にプライマリエージェントの出力を監査することで、不正確さを体系的に検知し、ユーザーエクスペリエンスを保護できます。

例: LLM-as-a-Judge と自己評価エージェントを組み込んだマルチエージェントオーケストレーションパターンを構築しましょう。

#13 膨れ上がるコストをどのように管理すればよいか？高性能な推論は強力ですが、決して安くはありません。費用を最適化するには、階層化されたアプローチを試してください。高速で複雑性の低いタスクには高速で軽量なモデル（Gemini Flash など）を使用し、オープンソースモデル（Gemma など）を活用して、最も大規模で高価な推論モデルを最終的な意思決定のために残しておきます。

大規模な本番運用では、プロビジョンドスループット（PT）に切り替えましょう。例えるなら、安定した予測可能な日常のトラフィック専用に容量を予約しておき、予期しない急増が発生した場合には、標準の従量課金制へ自動的に切り替わるような仕組みです。

算をさらに保護するには、高精度な RAG でコンテキストウィンドウをトリミングする、コンテキストキャッシュを利用する、エージェントのイテレーションにハードストップを設定する、予測可能なワークフローを決定論的なコードに移行するといった手法を検討しましょう。

例: 費用管理と重要な KPI を考慮して構築しましょう。

ガバナンスフェーズ - セキュリティと監視

#14 エージェントのデータアクセスを人間のユーザーのデータアクセスと一致させるにはどうすればよいか？エージェントのデータアクセスの一致は、まず安全なエージェント ID を確立することから始まります。このエージェント ID は、ユーザーの ID で直接動作するモデル、エージェント独自の独立した ID を使用するモデル、委任された権限を介して動作するモデルの 3 つをサポートしています。

従業員向けの多くのワークフローでは、委任された権限 を活用することが最も安全なアプローチです。エージェントは、やり取りする従業員の既存の権限を自動的に継承し、それを遵守します。これにより、エージェントが明示的に許可されていないデータにアクセスできないことが保証されます。その結果、クリーンな監査証跡を維持しながら、複雑な権限構造をゼロから再構築する必要がなくなります。

例: エージェント ID を使用して構築しましょう。

#15 シャドー AI とエージェントの無秩序な増加を管理するにはどうすればよいか？監視されていないエージェントは、深刻なデータの断片化とコンプライアンスリスクを引き起こします。無秩序な増加を防止するには、中央のエージェントレジストリを使用できます。これは、すべてのアクティブなエージェント、そのビジネスオーナー、ターゲットデータセット、および許可されたツールを自動的に一覧化する、一元化された検索可能なディレクトリです。手動で追跡するスプレッドシートから移行することで、チームは社内の AI プロジェクトを可視化できるようになります。これにより、重複したエージェントの統合や、孤立したエンドポイントの安全な廃止を確実に行えるようになります。

例: エージェントレジストリを使用して構築しましょう。

#16 ユーザー、エージェント、データ、ツールがどのようにやり取りできるかを定義するにはどうすればよいか？エンタープライズオートメーションを安全にスケーリングするには、2 層構造のポリシーアーキテクチャが必要です。まず、IAM ポリシーを適用して明確な境界を定義し、エージェントが認可されたツールと特定のデータバケットにのみアクセスできるようにします。2 つ目は、ユーザープロンプトの自然言語による意図をリアルタイムで分析するセマンティックポリシーを実装することです。これにより、エージェントが生成しようとしている回答が、実行前に主要なビジネスルールやコンプライアンス要件に準拠していることを検証できます。

例: ポリシーを使用して構築しましょう。

#17 これらのポリシーを適用し、エージェントの活動を可視化するにはどうすればよいか？ポリシーは、ランタイムでの適用と明確な監査証跡がなければ意味をなしません。これを実現するには、すべてのエージェントトラフィックを Agent Gateway 経由でルーティングする必要があります。Agent Gateway は、すべてのエージェントインタラクションにおけるネットワークの出入り口となります。このゲートウェイは、ユーザー、エージェント、ツール間の呼び出しを自動的にインターセプトし、ポリシー違反の即座なブロック、コンテンツのサニタイズ、プロンプトインジェクションの防止を自動で行います。完全な可視性を実現するには、このゲートウェイがあらゆるインタラクションに対してネットワークレイヤのテレメトリーを生成し、リアルタイムの挙動メトリクスと実行トレースをオブザーバビリティダッシュボードに直接フィードする必要があります。

例: Agent Gateway を使用して構築しましょう。

#18 プロンプトとレスポンスをデータ漏洩、プロンプトインジェクション、不適切なコンテンツから保護するにはどうすればよいか？Model Armor は、Agent Platform と統合することで、プロンプトが Gemini モデルに到達する前、およびレスポンスがアプリケーションに届く前に、それぞれの通信をインターセプトします。

構成に基づいて、Agent Platform は Model Armor サービスを呼び出します。このサービスは、定義されたポリシーに違反するトラフィックを検査またはブロックし、プロンプトインジェクションやジェイルブレイクの検出、責任ある AI フィルタ、機密データの保護などのセキュリティ対策を適用します。この統合を構成するには、プロジェクトレベルの保護にフロア設定を使用するか、リクエストごとの保護にテンプレートを使用します。

例: Model Armor を使用して構築しましょう。

#19 エージェントに問題が発生したかどうかは、どのようにしてわかるか？システムを保護するには、エージェントの意思決定ループをリアルタイムで監査して、振る舞い異常を検知する必要があります。脅威検出と並行してこの継続的な振る舞い監査を実行することで、侵害されたエージェントがリスクの高い、普段とは異なるアクションを試みた際に、即座にそれを検知できます。

そこで役立つのが、Agent Platform の脅威検出（Security Command Center の一部）です。エージェントが不正なデータベースコマンドを試行したり、未検証の外部ネットワークアドレスに接続したりすると、システムはほぼリアルタイムでイベントにフラグを立てて迅速に隔離します。これにより、自動化されたワークフォースを安全に管理できます。

例: 脅威検出と Agent Anomaly Detection を使用して構築しましょう。

#20 エージェントのライフサイクル全体を 1 か所で管理するにはどうすればよいか？更新を push したりテストを実行したりするためだけに、5 つもの異なるクラウドコンソールをクリックして移動したくはないでしょう。Agent Platform を使用すれば、プロダクションレディなエージェントを構築、スケーリング、ガバナンス、最適化するために必要な特定のスキルやコマンドを、コーディングエージェントに簡単に付与することができます。

開発チームの主要なコマンドツールとして、Agent Platform の Agents CLI を使用することをおすすめします。ローカルターミナルでの作業と本番環境の管理を直接つなぐブリッジとして機能するため、デベロッパーはテストから本番リリースへの移行を大幅に効率化できます。

また、チームはエージェント構成のバージョン管理、自動評価の実行、既存の CI / CD パイプラインを介したシームレスな更新の push も可能になります。基盤となるツールとスキルは Google のエキスパートが構築し、厳格なテストを行っているため、チームは車輪の再発明や日々のコーディングワークフローの中断を心配することなく、自信を持ってデプロイできます。

例: Agents CLI を使用して構築するには、こちらをご覧ください。