本文へスキップ

エージェントにクラウドを操作させる経路：MCP・Terraform・ホスト型 Skills・AI Gateway の役割分担

公開日 最終更新日 解説
share
エージェントからクラウド資源を操作する経路を抽象的に表現したイメージ（生成画像・技術図ではありません）

この記事が扱う問題

エージェントにクラウド資源を操作させるとき、二つの要求がぶつかります。一つは網羅性で、数万に及ぶ API をエージェントが使えるようにしたいという要求です。もう一つは安全性で、誤った API を呼んだり、過大な権限で資源を削除したりする事故を防ぎたいという要求です。さらに、モデルそのものへの呼び出しについても、鍵の管理、費用の帰属、内容の検査をどこで行うかを決める必要があります。

展示と公開文書を合わせると、クラウド資源を操作する経路は、(1) OpenAPI を呼ぶ MCP サーバ、(2) Terraform による宣言的な構成管理、(3) クラウド側にホストされた Skills を A2A で呼ぶ方式、(4) それらの資産を探すカタログ、の四つに整理できます。モデル呼び出しの経路は AI Gateway が担います。

用語の整理

  • MCP（Model Context Protocol）：LLM アプリケーションが外部のツールやデータに接続するためのオープンなプロトコル。
  • メタツール方式：API ごとにツールを定義するのではなく、「API を探す」「定義を取得する」「呼び出す」といった少数のツールで大量の API を動的に扱う方式。
  • HITL（Human-in-the-Loop）：自動処理の途中で人の確認・承認を挟む方式。
  • A2A（Agent-to-Agent）：エージェント同士がタスクを依頼・受託するための通信プロトコル。
  • AI Gateway：モデル、MCP サーバ、エージェントへの呼び出しを一つの入口に集め、認証・計量・流量制御・キャッシュ・内容検査を行うゲートウェイ。

全体構成と処理の流れ

四つの経路を、エージェントが目的を遂げるまでの流れとして並べ直すと次のようになります。以下は、前段で挙げた公開文書と展示の記載を編集部が並べた整理であり、製品の実装順序や推奨構成を示すものではありません。

  • ① 判断：エージェントが、何をしたいのかを決める。
  • ② 経路の選択：単発の API 呼び出しなら経路1（MCP）、構成そのものを変えるなら経路2（Terraform）、別のエージェントに任せるなら経路3（ホスト型 Skills／A2A）、使える道具を探すなら経路4（カタログ）。
  • ③ 検証：実環境に作用させる前に、API の定義と引数、Terraform のスキーマと plan、HITL の承認を挟む。
  • ④ 作用：API の呼び出し、apply の実行、A2A の依頼として実環境に反映する。
  • ⑤ 記録：呼び出しの主体・成否・使用量を監査ログに残す。
  • モデルへの呼び出し自体は、この流れの外側で AI Gateway が受け持つ。身元の割り当て、計量、流量制御、内容検査を一か所に集める。

経路1：OpenAPI を操作する MCP サーバ

展示の「MCP Core」は、エージェントが 2万を超える API を統一的に接続・呼び出し・管理できると説明し、「API 発見 → 引数の検証 → 制御下の実行 → 結果監査」の4段階を示していました（現地で確認した展示の提示内容。公開資料は閲覧時点で取得できていません）。「2万を超える」は展示上の記載です。

公開リポジトリで確認できるのは、Alibaba Cloud が公式にホストするリモート MCP サービスです。推奨される Core モードは一桁のコアツールで数万の OpenAPI を扱い、プロトコルは SSE と Streamable HTTP、認証は OAuth 2.0 とされています。権限不足で拒否された要求は EncodedDiagnosticMessage で診断できます。展示の「2万超」と公開文書の「数万」が同じ数え方かどうかは確認できていません。

メタツール方式の利点は、ツール一覧がモデルの文脈を圧迫しないことと網羅性です。代償は、呼び出しまでの往復回数が増えることと、モデルが誤った API を選んだ場合に気づきにくいことです。

資格情報の置き場所にも違いがあります。ホスト型は OAuth で権限を委任しますが、利用者が自分で起動する alibaba-cloud-ops-mcp-server の設定例は、AccessKey ID と Secret を環境変数で渡す方式です。同じ「MCP でクラウドを操作する」構成でも、長期の鍵がエージェント側に置かれるかどうかで、漏えい時の影響範囲が変わります。

経路2：Terraform による「生成と実行の分離」

LLM に Terraform の構成を書かせると、存在しない引数や古いリソース型を生成してしまう問題が知られています。展示の「Terraform × Agent」は、スキーマ照会と Provider の validate で生成物を検証し、「生成 ≠ 資源の作成」と明記していました。既存資源を取り込む経路では、実際の設定値から HCL を生成して state に import し、plan が差分なし（No changes）を返すことを完了条件にしています。

公式ツールキットの spec-ops プラグインも、「計画 → Terraform コード生成 → 検証 → IaC Service による実行」という段階を踏みます。エージェントの出力を「提案（コード）」と「実行（apply）」に分け、その間に検証を挟む設計です。ただし、差分ゼロは「現在の状態を正確にコード化できた」ことを示すだけで、その構成が安全であることは保証しません。過剰に開いたセキュリティグループも、そのまま正確にコード化されます。import に対応しない資源型があれば、取り込みは不完全になります。

経路3：ホスト型 Skills と A2A

展示の「Skills Hub」は、Skill をローカルに配置せず、クラウド側で実行されるサービスとして公開し、A2A で呼び出す方式を示していました（これも現地で確認した展示の提示内容です）。公式のクラウド利用 Skills を 260 以上提供するという記載は展示上の数値です。

A2A 仕様（閲覧時点の最新版 1.0.0）は、JSON-RPC 2.0、gRPC、HTTP+JSON の三つのバインディングと、ストリーミング送信、タスクの購読、Push 通知を定めています。長いタスクを同期呼び出しに閉じ込めない仕組みがプロトコル側に用意されています。ホスト型の利点は、配布と更新の手間がなく、高危険操作を提供者側で統制できることです。代償として、呼び出し側からは Skill の中身が見えにくくなり、何が実行されたかの説明責任はホスト側のログに依存します。閉域環境では到達性も前提になります。

モデル呼び出しの統制点：AI Gateway

公開文書によると、AI Gateway は Model Studio、OpenAI、Anthropic、Amazon Bedrock、Azure、自前で運用するモデルなどへの呼び出しを代理します。呼び出し元ごとに消費者の身元を割り当てて認証し、バックエンドのモデルの鍵は KMS に保管できます。既存の HTTP API を MCP サーバに変換する機能、複数のツールを組み合わせた仮想 MCP サーバ、要求内容に応じてツールを絞り込む知的ツールルーティング、REST から A2A へのプロトコル変換、流量制御とキャッシュの記載もあります。

  • 鍵の閉じ込め：上流のモデルの鍵をゲートウェイに置き、利用者にはゲートウェイ側の身元だけを配るため、漏えい範囲と失効手順が単純になります。
  • キャッシュ：公開文書では、キャッシュヒット数が観測項目として記載されています。類似した質問を意味的に判定して再利用する仕組みまでは、閲覧した文書では確認できていません。一般には、類似判定による再利用は費用と遅延を下げる一方で、「似ているが答えが異なるべき質問」に誤った回答を返す危険があります。
  • 応答側の検査：ストリーミング応答では、検査が遅延を生むか、部分的に送出した後で遮断することになります。
  • 集中化：すべての流量が一か所を通るため、ゲートウェイ自体の可用性と設定誤りが全エージェントに波及します。

評価前の検証チェックリスト

  • HITL の承認が求められる操作の範囲（削除系のみか、設定可能か）
  • 資格情報の置き場所（OAuth による委任か、AccessKey をエージェント側に置くか）
  • 別アカウント操作での権限の境界と、監査ログに残る主体
  • Terraform の import に対応しない資源型が含まれる場合の扱い
  • ホスト型 Skills の実行ログを呼び出し側が取得できる範囲
  • ストリーミング応答と、意味キャッシュ・トークン計量・応答側検査を同時に使ったときの挙動

まとめ

四つの経路は、エージェントに渡す「単位」と「作用の仕方」が異なります。MCP は個々の API 呼び出し、Terraform は差分確認を経た構成、ホスト型 Skills は別エージェントへの依頼です。共通するのは、エージェントの計画と実環境への作用の間に検証段を挟むことです。どの操作を自動承認し、どの操作に人の確認を求めるかという閾値の設計が、使い勝手と安全性を左右します。

本記事は Apsara Conference 2026 技術解説シリーズ の一部です。実行環境側の隔離と非同期通信は 第1回「AIエージェントの実行基盤と非同期通信」 で扱います。権限とデータ境界を扱う第5回「エージェントの身元・データ境界・実行時防御」は準備中です。

よくある質問

MCPのメタツール方式はどんなときに有利ですか？

数万規模のAPIをエージェントに使わせたいときです。APIごとにツールを定義せず少数のコアツールで扱うため、ツール一覧がモデルの文脈を圧迫しません。一方で、呼び出しまでの往復回数が増え、モデルが誤ったAPIを選んだ場合に気づきにくくなる代償があります。

Terraformをエージェントに書かせて安全ですか？

生成と実行を分離すれば事故は減らせますが、安全は保証されません。差分ゼロは現在の状態を正確にコード化できたことを示すだけで、過剰に開いたセキュリティグループもそのまま正確にコード化されます。

AI Gatewayを置くと何が変わりますか？

上流モデルの鍵をゲートウェイに閉じ込め、呼び出し元ごとに身元を割り当てられます。流量制御・キャッシュ・内容検査も集約できますが、全流量が一か所を通るため、ゲートウェイ自体の可用性と設定誤りが全エージェントに波及します。

参照した一次情報

参照した一次情報（公開リポジトリ・製品文書）

記事情報

取材・執筆・編集株式会社Metelix
公開日
最終更新日
分類解説（クラウド操作・MCP・IaC・AIゲートウェイ）
利害関係本記事は、Apsara Conference 2026の展示と公開文書をMetelixが取材・編集した技術解説です。数値は特に断りのない限りベンダー提示値であり、Metelixによる測定値ではありません。
検証方法公開文書の記述は、2026年9月26日（日本時間）に公式サイト・公式リポジトリから一次情報を取得し、本文に含まれる文字列と一致することを確認しました。展示の記述は2026年9月の現地取材で確認した提示内容で、測定条件は示されていません。
評価時点展示の取材は2026年9月（杭州・現地）。公開文書の初回閲覧日は2026年9月25日（日本時間）、再確認日は2026年9月26日（日本時間）。内容と提供段階は閲覧時点のもので、今後変わる可能性があります。

関連記事

改訂履歴

初版公開
share

RiN Gateway

このコラムの内容を自社に適用する方法をご相談ください

RiN Gatewayは、企業のAI活用における統制・ガバナンス・コスト最適化を支援するプラットフォームです。トライアルや導入相談はお気軽にどうぞ。

RiN Gatewayの詳細お問い合わせ
コラム一覧へ