なぜ「Extensions」の理解がセキュリティの鍵なのか
「生成AIに社内のデータベースを繋いで、自律的に業務をこなすエージェントを作りたい」。
企業のデジタルトランスフォーメーション推進において、このような構想は今や珍しいものではありません。特に金融や製造といった、データの機密性がビジネスの生命線となる業界において、その関心は非常に高まっています。しかし同時に、現場のエンジニアやセキュリティ担当者の間では、ある種の懸念が共有されていることも事実です。
「AIが予期せずデータを書き換えてしまったらどうするのか」「権限のない機密データを一般ユーザーに開示してしまわないか」
これらの懸念は極めて正当なものです。LLM（大規模言語モデル）は、あくまで確率に基づいて言葉を操る「脳」に過ぎません。これまではブラウザのチャット画面の中で完結していましたが、社内システムと接続するということは、この脳に直接動ける「手足」を与えることを意味します。もし、その手足が制御不能な状態に陥れば、深刻なインシデントに繋がりかねません。
ここで重要になるのが、Google Cloudが提供するVertex AI Extensionsという概念です。
多くのプロジェクトでは、これを単なる「便利なAPI接続ツール」だと誤解する傾向があります。しかし、システムアーキテクチャの観点から言えば、これはAIという不確実性を伴う存在を、企業の厳格なセキュリティポリシーの枠内に安全に着地させるための「拘束具」であり、システム間の「通訳者」として機能するものです。
本記事では、具体的なコード実装の詳細に入る前に、システムアーキテクトやセキュリティ担当者が必ず押さえておくべき概念と用語を整理していきます。特によく混同されがちなFunction Calling（関数呼び出し）との決定的な違いを明確にし、なぜエンタープライズ領域においてExtensionsの利用が推奨されるのか、その理由を構造的に紐解いていきましょう。
AIモデル単体とエージェントの違い
まず、前提となる認識を合わせておきましょう。通常のチャットボットインターフェースは、基本的に事前学習された知識のみに基づいて回答を生成します。これは「静的」な存在だと言えます。学習時点までのデータしか持っていないAIに対して「今日の社内在庫数は？」と問いかけても、正確な答えを返すことは不可能です。
一方、AIエージェントは「動的」な性質を持ちます。外部のツール（APIやデータベース）を自律的に呼び出し、最新情報を取得したり、システム経由でメールを送信したりする実行能力を備えています。
特に昨今では、リアルタイム性の高いマルチモーダル機能や、長文脈理解と高度な推論能力を持つモデルが登場し、エージェントが実行できるタスクの幅は飛躍的に広がりました。しかし、ここでシステム設計者が警戒すべきは「モデルのライフサイクルの速さ」です。
AIモデルは極めて短い周期でアップデートされ、旧世代のモデルは順次廃止やレガシー化が進んでいきます。実際にOpenAIのモデル展開を振り返ると、かつて主流だったGPT-3.5やGPT-4o、GPT-4.1、o4-mini、さらにはGPT-5やGPT-5.1といったモデルは、2026年2月13日をもってChatGPTのUIから完全に引退しました。2026年現在、デフォルトモデルはGPT-5.2（要件に応じて切り替わるInstant、Thinking、Auto、Proの4モード体制）へと一本化されています。加えて、2026年1月にはコーディングに特化したGPT-5.3-Codexが追加されるなど、技術の進化は止まりません。
もし自社のシステムを特定のモデルの仕様に直結させてしまうと、こうしたモデルの廃止やインターフェース変更のたびに、大規模なシステム改修を余儀なくされます。Vertex AI Extensionsは、このような激しいモデルの変動を吸収し、外部システムとの安定した接続を担保する強力な「抽象化層」としても機能するのです。
社内データ連携における「3つの壁」
企業がAIエージェントを本番環境へ導入しようとする際、必ず直面する3つの壁が存在します。これらは単なる技術的な課題にとどまらず、コーポレートガバナンスの観点からも避けては通れない関門です。
- 幻覚（ハルシネーション）の壁: AIがもっともらしい嘘を生成し、誤った意思決定を誘発するリスク。
- 漏洩の壁: 社外秘データが外部モデルの学習に流用されたり、悪意あるプロンプトインジェクションによって機密情報が引き出されたりするリスク。
- 権限の壁: 「役員には開示できるが、一般社員には伏せるべきデータ」を、AIがユーザーの属性に応じて正確に区別できるかというリスク。
Vertex AI Extensionsは、これらの壁、とりわけ「漏洩」と「権限」の壁を安全に乗り越えるために設計されたマネージドサービスです。最新のVertex AI Agent Builderを活用することで、管理者がツールの利用権限を統合的に制御するガバナンス機能が大幅に強化されています。
単にシステム同士を繋ぐだけでなく、「誰が」「どのデータ範囲で」「どのような操作を」実行できるのかを厳密に制御する基盤として機能します。このように捉えることで、この技術がエンタープライズシステムにおいて果たす本質的な役割が浮き彫りになります。さらに、アクセスログの詳細な監査や利用状況のリアルタイムモニタリングを統合的に行える点は、企業がセキュリティリスクを最小限に抑えつつAIを活用する上で、極めて大きなアドバンテージとなります。
【基礎編】Vertex AI Extensionsの解剖図鑑
では、具体的にVertex AI Extensionsとは何なのか。ここが最も混乱しやすいポイントです。特にエンジニアの方は「それってFunction Callingと何が違うの？」と疑問に思うでしょう。
結論から言えば、「Function Callingは『機能』であり、Extensionsは『インフラ』である」 と言えます。
Vertex AI Extensions（拡張機能）
Extensionsは、LLMと外部API（Google独自のサービスやサードパーティのツール）を接続するための、Google Cloud上のマネージドな仲介役です。
想像してみてください。海外の要人（LLM）と商談をする際、通訳（Function Calling）だけを雇うのがこれまでのやり方でした。通訳は言葉を訳すだけなので、商談場所の手配やセキュリティチェック、相手の身元確認まではしてくれません。
一方、Extensionsは「大使館」のようなものです。通訳機能はもちろん、安全な会議室の用意、入館証のチェック、会話ログの記録まで、すべてをパッケージとして提供してくれます。
具体的には、Extensionsを利用することで、APIの定義ファイル（OpenAPI Spec）を登録するだけで、LLMがそのAPIをどう使えばいいかを理解し、実行までをGoogleの基盤上で行ってくれます。プロトタイプを素早く構築し、仮説検証を回す上でも、この手軽さは大きな武器となります。
Reasoning Engine（推論エンジン）
ここで新しい用語が登場します。Reasoning Engine です。これは、AIエージェントの「思考プロセス」を司るランタイム環境です。
一般的に、LangChain（特に最新のLangGraphを含むエコシステム）を使用してエージェントを構築する場合、Pythonコードを記述し、それを自前のサーバーで運用する必要があります。しかし、この運用は容易ではありません。LangChainのエコシステムは進化が極めて速く、例えばVertex AI SDKの移行（従来のChatVertexAIからChatGoogleGenerativeAIへの推奨変更など）や、頻繁なセキュリティパッチ（脆弱性修正）への即応が常に求められます。
Reasoning Engineは、この「エージェントのロジック」そのものをVertex AI上でホストし、実行してくれるサービスです。これにより、開発者はインフラ管理やライブラリの複雑な依存関係管理から解放され、ロジックの記述に集中できます。
Extensionsが「手足」だとすれば、Reasoning Engineは手足を動かすための「運動神経」や「小脳」にあたります。これらを組み合わせることで、スケーラブルで管理しやすいエージェントを構築できるのです。
Function Calling（関数呼び出し）との決定的な違い
ここが最大のポイントです。表で比較してみましょう。
| 特徴 | Function Calling (Raw) | Vertex AI Extensions |
|---|---|---|
| 実行主体 | クライアント（アプリケーション側） | Vertex AI (Google Cloud) |
| 役割 | 「どの関数を呼ぶべきか」を教えるだけ | 関数の実行まで代行する |
| 認証管理 | 自前で実装が必要 | プラットフォームが統合管理 |
| セキュリティ | 開発者が全責任を持つ | Googleのベストプラクティスが適用 |
| 導入ハードル | 高い（コード量が多い） | 低い（設定ベース） |
Function Callingの場合、LLMは「get_stock(item="A")を実行してください」というJSONデータを返してくるだけです。実際に在庫APIを叩くのは、そのJSONを受け取ったアプリケーション側のコードです。つまり、APIキーの管理やエラーハンドリングはすべて開発者の責任になります。
対してExtensionsは、LLMが「在庫を知りたい」と判断した瞬間、Vertex AIが裏側で安全にAPIを叩き、その結果だけをLLMに返します。開発者はAPIキーをSecret Managerに預けるだけでよく、生の認証情報がコード内に散らばることを防げます。
セキュリティ要件が厳しい企業にとって、この「実行責任の委譲」と「認証の一元管理」は計り知れないメリットとなります。
【接続・認証編】セキュアなパイプラインを構成する用語
「便利そうなのはわかった。でも、どうやって堅牢な社内システムに繋ぐんだ？」
ここからは、ネットワークや認証周りの用語を整理します。セキュリティ担当者との会話で必須となる語彙です。
OpenAPI Specification（OAS）
これはAIに対する「APIの取扱説明書」です。Swaggerとも呼ばれます。
人間がマニュアルを読んで道具の使い方を覚えるように、AIはOASファイルを読んで「このAPIにはどんな機能があり、どんなパラメータが必要か」を理解します。Extensionsを使う場合、このOASファイルの記述精度がAIの挙動を左右します。
セキュリティの観点では、OASに記述するAPIのエンドポイントを必要最小限に絞ることが重要です。「なんでもできるAPI」をAIに渡すのは、子供に万能ナイフを持たせるようなものです。
OAuth 2.0 / OIDC (OpenID Connect)
「誰が」AIを使っているかを識別するための標準プロトコルです。
企業利用で最も懸念されるのは、権限のないユーザーがAIを使って機密データを引き出せてしまうことです。これを防ぐために、ExtensionsはOAuthに対応しています。
ユーザーがチャットボットに話しかける際、GoogleやOktaなどのIDプロバイダを通じてログインします。ExtensionsがAPIを叩くとき、このユーザーのアクセストークンを代理で使用します。つまり、「AIがAPIを叩く」のではなく、「AIというインターフェースを通じて、ユーザー自身がAPIを叩く」 形になります。これにより、既存のシステム側の権限設定（ACL）がそのまま適用され、権限越えのリスクを回避できます。
Vertex AI Service Agent
これはGoogle Cloud内部で働く「専用の執事」のようなアカウントです。
Vertex AI Extensionsをセットアップする際、実際にはこのService Agentに対して「代わりにSecret Managerのパスワードを読んでいいよ」「ログを書き込んでいいよ」という権限を与えます。人間が直接アクセスするのではなく、この管理されたエージェントアカウントを介することで、最小権限の原則（PoLP）を徹底しやすくなります。
Private Service Connect (PSC)
厳格なセキュリティ要件により「インターネット経由の接続が制限される」ケースにおいて登場する切り札です。
通常、API接続はインターネットを通りますが、PSCを使うことで、Vertex AI（Googleの管理環境）と、自社のVPC（プライベートネットワーク）を、インターネットに出ることなく直接繋ぐことができます。
いわば、Googleのデータセンターと自社のシステムの間に「専用の地下トンネル」を掘るようなものです。これにより、社内システムのAPIをパブリックに公開することなく、Extensionsから安全に呼び出すことが可能になります。
【検索・参照編】RAGとGrounding関連用語
次に、社内ドキュメントを検索して回答させる RAG（Retrieval-Augmented Generation） の文脈で使われる用語を見ていきましょう。Extensionsは、単にアクションを実行するだけでなく、知識を検索する際にも活躍します。
Grounding（グラウンディング / 根拠付け）
AIの回答を「事実」に繋ぎ止めるための概念です。凧（AIの生成能力）がどこかへ飛んでいかないように、地面（信頼できるデータソース）に紐付けるイメージです。
Vertex AI Extensionsでは、回答生成時に必ず指定したデータソースを参照させ、その内容に基づいて回答を作成するように強制できます。さらに、回答には「この情報のソースは社内規定PDFの5ページ目です」といった引用元（Citation）が付与されます。これにより、ユーザーは情報の真偽を即座に確認できます。
Vertex AI Search
Google検索の企業版です。社内のPDF、Wiki、Webサイトなどをクロールし、インデックス化します。
Extensionsの一つとして「Vertex AI Search Extension」を利用することで、エージェントはユーザーの質問に関連する社内文書を瞬時に検索し、その内容を要約して回答できるようになります。自前で検索システムを構築するのに比べ、導入コストを抑えられ、Google品質の検索精度を利用できるのが強みです。
Vector Search（ベクトル検索）
より高度な検索ニーズに対応するための技術です。テキストを「意味の数値（ベクトル）」に変換して検索します。
例えば、「PCの調子が悪い」と検索したとき、キーワード一致だけでは「画面が割れた」というドキュメントはヒットしません。しかしベクトル検索なら、「調子が悪い」と「画面割れ」の意味的な近さを理解してヒットさせることができます。
Vertex AIにはこのベクトル検索エンジンも用意されており、Extensionsを通じてエージェントの「長期記憶」として活用することが可能です。
Retrieval Tool（検索ツール）
これはExtensionsの一種ですが、特に「情報の取得」に特化したものを指します。書き込み権限を持たず、読み取り専用で構成されることが多いため、セキュリティリスクが比較的低いのが特徴です。RAGの構築においては、まずこのRetrieval Toolの整備から始めるのがセオリーです。
【比較・整理編】類似技術との使い分けマップ
ここまで多くの用語が出てきましたが、開発現場では「で、結局どれを使えばいいの？」という疑問が尽きません。関連する技術との位置関係を整理しましょう。
LangChain / LangGraph vs Vertex AI Extensions
- LangChain / LangGraph: オープンソースのエコシステムです。最新のAgentic Workflowや実験的な機能をいち早く試せる自由度の高さ（DIY）が魅力です。しかし、その代償として「依存関係の管理責任」が伴います。
- 頻繁なアップデートへの追従: 例えば、2026年初頭時点の
langchain-core（v1.2系）では、スキーマ処理の防御強化やトレース機能の改善が頻繁に行われています。また、Google Cloud連携においても、従来のVertex AI SDK（ChatVertexAI）からChatGoogleGenerativeAIへの移行が推奨されるなど、エコシステムの変化は非常に速いです。 - セキュリティ対応: ライブラリに深刻な脆弱性（例：CVE-2025-68664のようなAPIキー流出リスク）が発見された場合、開発チーム自身で即座に情報をキャッチし、パッチを適用する体制が不可欠です。
- 頻繁なアップデートへの追従: 例えば、2026年初頭時点の
- Vertex AI Extensions: Google Cloudのフルマネージドサービスです。自由度はLangChainに劣る場合がありますが、インフラ管理、認証フロー、そして基礎的なセキュリティ対策がプラットフォーム側でパッケージ化されています。
プロトタイピングや研究開発ではLangChainが便利ですが、長期的なメンテナンスコストやセキュリティガバナンスが問われるエンタープライズの本番環境では、Extensions（およびReasoning Engine）への移行を検討すべきです。最新情報は常に公式ドキュメントで確認することをお勧めします。
Cloud Run Functions vs Extensions
- Cloud Run Functions: APIのバックエンドとして動く「プログラムそのもの」。ビジネスロジックの実体です。
- Extensions: LLMとCloud Run Functions（などのAPI）を「繋ぐパイプ」。OpenAPI仕様書に基づいて、LLMが関数を理解し実行するためのインターフェースです。
これらは競合するものではなく、協力するものです。例えば、複雑な在庫計算処理をCloud Run Functionsで書き、それをExtensions経由でLLMから呼び出す、という構成が一般的です。
BigQuery ML
データアナリスト向けのAI活用機能です。SQLを使ってBigQuery内のデータに対して直接LLMを適用できます。
アプリケーションに組み込むエージェントを作りたいなら Vertex AI Extensions、データ分析の一環としてAIを使いたいなら BigQuery ML、という使い分けになります。
まとめ：セキュリティは「制限」ではなく「翼」である
Vertex AI Extensionsや関連するセキュリティ用語について解説してきました。
多くの人はセキュリティを「開発の邪魔をする壁」と考えがちです。しかし、AI開発においては逆です。堅牢な認証基盤、明確な責任分界点、そして安全な接続トンネル（PSC）があるからこそ、私たちはAIという強力なエンジンをビジネスに投入できると考えられます。
本日の要点:
- Extensionsは「インフラ」: Function Callingの手動実装やOSSライブラリの脆弱性管理に伴うリスクを、Google Cloudのマネージドサービスにオフロードする仕組み。
- 認証のパススルー: OAuth/OIDCを活用し、ユーザーの権限で安全にAPIを実行させる。
- Groundingの徹底: RAG構成において、回答を社内データに繋ぎ止め、幻覚を防ぐ。
これらの概念を理解した上で設計図を描けば、AIプロジェクトは「PoC止まり」の壁を越え、本番運用へと進むことができるでしょう。まずは動くプロトタイプを作り、技術の本質を見極めながら、ビジネスへの最短距離を描いていきましょう。
コメント