AIエージェントの導入で最初に直面する課題は、モデルの性能だけではありません。

むしろ本番導入では、次のような問いに答えられるかが重要になります。

たとえば、営業支援エージェントを作るとします。

商談前に顧客情報を要約し、過去の提案資料を探し、類似案件を参照し、提案書のたたき台を作ってくれるAIがあれば、営業活動は大きく効率化できます。

しかし、そのAIが全顧客の機密情報に無制限にアクセスできてよいでしょうか。
提案書の内容を外部ツールに送ってよいでしょうか。
過去の誤った提案を正しい情報として再利用してしまった場合、どう検知するのでしょうか。
AIが生成した提案内容の根拠を、あとから追跡できるでしょうか。

このように考えると、AIエージェント導入の本質は
「便利なAIを作ること」ではなく、
「AIが業務に参加するためのルールと基盤を作ること」だと分かります。

特に重要なのは、次の4つです。

• 権限管理：AIごとに、見られるデータや実行できる操作を分ける
• 接続管理：社内外システムへの通信経路や操作内容を制御する
• 記憶と状態管理：会話や業務の流れを保持する
• 運用と改善：回答品質や失敗パターンを継続的に確認する

この4つを個別に手作りすると、AIエージェントはすぐに複雑化します。

だからこそ、Google Cloudのようなエージェント基盤を活用する意味があります。

Google CloudでAIエージェント基盤を考える場合、単にGeminiを呼び出すアプリケーションを作るだけでは不十分です。

必要になるのは、AIエージェントを中心に、実行環境、データ基盤、接続制御、権限管理、記憶、監視、評価を組み合わせた全体設計です。

上図は、AIエージェントを企業の業務で活用するために必要な構成を、役割ごとに層で整理したものです。

AIエージェント基盤では、どのAIモデルを使うかだけでなく、誰が使うのか、どのエージェントが動くのか、どのシステムへ接続できるのか、どのデータを参照できるのか、どのように運用・改善するのかを分けて考える必要があります。

このように層で分けて考えることで、AIエージェント基盤は単なるチャットアプリではなく、企業内の業務システムやデータと安全につながる共通基盤として設計しやすくなります。

特に営業支援AIでは、顧客情報、過去提案書、議事録、問い合わせ履歴など、複数の情報を横断して扱います。そのため、AIモデルの性能だけでなく、どの情報を参照できるのか、どの操作を許可するのか、回答品質をどのように確認するのかまで含めて設計することが重要です。

AIエージェントを本番業務で使う場合、単にGeminiに指示を出すだけでは不十分です。

AIは業務データを参照し、社内外のツールを呼び出し、会話や業務状態を保持しながら、複数ステップのタスクを進めます。そのためには、AIモデルだけでなく、実行・接続・記憶・運用を支える仕組みが必要になります。

Google Cloud が導入しようとしているエージェント関連技術は、まさにこの課題に対応するためのものです。

ここでは、シンプルな例として「営業支援エージェント」を考えます。

営業活動では、商談前後に多くの準備作業が発生します。顧客情報を確認する。過去の商談履歴を見る。類似案件を探す。提案資料を確認する。議事メモを整理する。次回アクションをまとめる。提案書のたたき台を作る。

これらは重要な業務ですが、担当者の経験や勘に依存しやすく、準備にも時間がかかります。

AIエージェントを導入すると、この流れを大きく変えられます。

たとえば、営業担当が「A社との次回商談に向けて、過去提案と最近の問い合わせ内容を踏まえて提案の方向性を整理して」と依頼したとします。

営業支援エージェントは、まずCRMから顧客情報を確認します。次に、過去の商談履歴や提案資料を検索します。さらに、問い合わせ履歴や関連する社内ナレッジを参照します。

そのうえで、今回の商談で押さえるべき論点、提案の方向性、想定される懸念、次回アクション案を整理します。

ここで重要なのは、AIが単に文章を生成しているわけではないという点です。

AIエージェントは、複数のデータソースを参照し、必要なツールを呼び出し、業務の目的に沿って情報を組み立てています。

そのため、営業支援エージェントを本番業務で使うには、単にAIに文章を書かせるだけでなく、どのデータを参照できるのか、どのシステムへ接続できるのか、どの操作まで許可するのかをあらかじめ設計しておく必要があります。

つまり、営業支援エージェントの価値は「提案書を自動生成すること」だけではありません。

営業活動に必要な情報収集、整理、判断材料の提示、次の行動への橋渡しを、一定の品質で支援できることにあります。

これにより、経験の浅い担当者でも過去の知見を活用しやすくなります。一方で、ベテラン担当者は資料探しや整理作業から解放され、より顧客理解や提案方針の検討に時間を使えるようになります。

Google CloudでAIエージェント基盤を作る特徴は、AIモデル、データ、セキュリティ、ツール連携、運用を一体で設計できる点にあります。

AIエージェントを業務に組み込む場合、単に高性能なAIモデルを使うだけでは十分ではありません。業務データにつなぎ、必要なツールを呼び出し、権限を管理し、実行結果を監視し、継続的に改善できることが重要になります。

まず、中心になるのがGeminiです。Geminiは、文章生成だけでなく、複雑な指示理解、マルチモーダルな情報処理、ツール呼び出しを組み合わせたエージェント型の処理に対応しやすいAIモデルです。AIエージェントがユーザーの依頼を理解し、必要な情報を探し、複数の処理を組み合わせて業務を進めるうえで中核となります。

次に重要なのが、BigQueryを中心とした統合データ基盤です。

企業内には、顧客データ、購買データ、問い合わせ履歴、業務ログ、各種マスタといった構造化データがあります。一方で、提案資料、契約書、マニュアル、議事録、社内ナレッジ、画像、動画、音声といった非構造化データも多く存在します。

AIエージェントが業務で使える回答を行うには、この両方を分断せず、同じ業務文脈の中で扱えることが重要です。BigQueryでは、構造化データを分析するだけでなく非構造化データも分析やAI処理の流れに組み込むことができます。

ここで重要なのは、AIに単にデータを渡すことではありません。顧客情報、商談履歴、提案資料、問い合わせ履歴、社内ナレッジを組み合わせ、AIが業務上の意味を理解しやすい形で文脈化することです。

このように、BigQueryを中心に構造化データと非構造化データを統合的に扱えることは、AIエージェント基盤を作るうえで大きな強みになります。AIエージェントは、単一の文書検索や単一テーブルの分析ではなく、企業内に散らばる複数種類のデータを横断して判断する必要があるためです。

さらに、Agent Gateway、Agent Identity、Model Armorを組み合わせることで、AIエージェントのアクセス先、実行可能な操作、監査の仕組みを管理しやすくなります。

また、AIエージェントは作って終わりではありません。業務に組み込まれるほど、回答品質、ツール呼び出し、処理時間、失敗パターンを確認し、改善していく必要があります。そのために重要になるのがAgent Opsです。

つまりGoogle Cloudの強みは、AI単体ではなく、企業の業務基盤としてAIエージェントを設計できることです。

Gemini、BigQuery、Cloud Storage、検索基盤、Agent Gateway、Agent Identity、Model Armor、Agent Opsを組み合わせることで、構造化データと非構造化データを統合的に活用しながら、AIエージェントを安全に業務へ組み込み、継続的に改善していく基盤を作れます。

役員から「AIエージェントを導入してほしい」と言われたとき、まず考えるべきことは、どのチャットボットを作るかではありません。

本当に考えるべきなのは、
AIエージェントが企業の業務に安全に参加できる環境をどう作るか
です。

このような基盤があって初めて、AIエージェントは一時的な実験ではなく、企業の業務を支える仕組みになります。

Google Cloud Next ’26で発表・紹介された
Agent Gateway、Agent Identity、Agent Platform Sessions、Agent Platform Memory Bank、Agent Registry、MCP、Agent Evaluation、Agent Observability
といった技術は、まさにこの課題に対応するための重要な構成要素です。
ただし、一部機能はプレビューまたは段階的提供のため、実際の導入時には最新の提供状況を確認する必要があります。

これからのAI活用で差がつくのは、AIを試す速さだけではありません。

AIエージェントを安全に、継続的に、業務へ組み込める基盤を作れるかどうか
です。

Google Cloudは、そのための実行環境、データ基盤、接続制御、権限管理、運用改善の仕組みを備えています。