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

Apsara Conference 2026（杭州）の展示会場で、AIエージェントにクラウドを操作させる話は一つのブースにまとまっていませんでした。エージェントに道具をつなぐ展示、インフラの構成をコードで変える展示、呼び出しを入口で見張る展示が、それぞれ別のパネルやブースに並んでいました。そのなかで一枚だけ、エージェントに仕事を「任せる」話と、危ない操作を「止める」話を同じ画面に載せていた展示があります。本記事はそこから始めて、撮影した展示を順にたどります。展示が何を訴えていたかを日本語で整理し、公開文書で裏が取れる部分を補い、日本企業がこの仕組みを使うときに何が変わりそうかを考えます。

先に筆者の見立てを書いておきます。会場の展示は、エージェントによるクラウド操作を三つの仕事に分けていました。「ツールをつなぐ」「構成をコードで変える」「呼び出しを一か所で見張る」の三つです。どれか一つを入れれば済むわけではありません。どこで人が確認し、どこに記録を残すかは、使う側が決める必要があります。

「任せる」と「止める」が同じ画面にあった

Skills Hub と大きく書かれた展示台の上には、大型モニターが一台置かれていました。画面の見出しは「Human in the Loop 人机协同：为 Agent 操作加上人工兜底」です。人と機械が協働し、エージェントの操作に人の手で最後の歯止めを付ける、という趣旨です。そのすぐ下に小さく「高危操作必有退路」とあります。危険度の高い操作には必ず戻り道を用意する、という宣言です。

画面の左側には三つの枠が縦に並んでいました。一つ目は「风控引擎」（リスク制御エンジン）で、端末側とクラウド側が連携して、エージェントの計画に含まれる危険な操作を事前に見つけると説明しています。二つ目は「意图偏离检测」（意図の逸脱検知）で、エージェントが実行中に、利用者の意図に沿った当初の計画から外れていないかを調べるとあります。三つ目は「可信带外确认」（信頼できる経路外での確認）です。コンソールやスマートフォンのアプリに確認を非同期で送る、と書かれていました。

右側の図は流れを示していました。利用者の対話入力がまずエージェントに入ります。エージェントは Skills、A2A、MCP を通じて Alibaba Cloud につながります。その先に「阿里云 HITL」という箱があり、リスク制御、意図の逸脱検知、決定的なポリシー、実行の委任といった項目が並びます。さらに右では、エージェント自身の確認画面、コンソール、スマートフォンのアプリという三つの確認手段が描かれ、そこで承認されれば処理が続き、拒否されれば止まる、という分岐になっていました。

面白いのは、この画面の真下の台座です。そこには「阿里云官方云Skills门户，260+官方用云Skills一站供给Agent」と書かれていました。Alibaba Cloud 公式のクラウド用スキルを260以上そろえ、エージェントに一か所で供給するという説明で、英語でも「The official Alibaba Cloud agentic skills hub: 260+ production-ready skills」と併記されています。260以上という数字は出展者の説明で、筆者が数えたものではありません。

つまりこの一台の展示では、「エージェントにできることを260以上用意した」という話と、「危ない操作は人が止められるようにした」という話が、上下に並んでいました。エージェントに仕事を渡す仕組みを売り込む展示は多くありますが、止める仕組みを同じ画面の主題に据えた例はそれほど多くありません。できることを増やすほど止める仕組みが必要になる、という関係を、展示の配置がそのまま表していたと筆者は受け取りました。

ただし、写真から分かるのはパネルに何が書かれていたかまでです。リスク制御エンジンが何を基準に「危険」と判断するのか、どの製品のどの画面で確認が求められるのかは、今回取得した公開文書では確かめられませんでした。以下では、この「任せる」と「止める」の組み合わせを軸に、ほかの展示を読んでいきます。

MCP Core：一つの接続口で API 全体を扱う

次に見たのは「MCP Core：让 Agent 安全地操作阿里云」というパネルです。エージェントに Alibaba Cloud を安全に操作させる、という題で、副題には「MCP 開放標準・エージェント向けの Alibaba Cloud 統一 OpenAPI コネクタ」とあります。

MCP（Model Context Protocol）は、AIのアプリケーションが外部の道具やデータにつながるための公開仕様です。ここで言う道具（ツール）とは、エージェントが呼び出せる個々の機能のことです。パネルの大見出しは「从「会调用 API」到「能承担云上任务」」でした。「APIを呼べる」段階から「クラウド上の仕事を引き受けられる」段階へ、という主張です。その下には、あらかじめツールの一覧を用意しておく必要はなく、一つの MCP サーバで Alibaba Cloud の OpenAPI 全体をまかなう、と書かれていました。

四つの枠には、それぞれ具体的な操作名が並んでいました。一つ目は API の発見と検証で、SearchApis、ListProducts、GetApiDefinition、ListProductRegions、GenerateCLICommand といった名前が見えます。自然言語から目的の API を探し、引数やエラーコード、リージョンで使えるかを確かめてから呼ぶ、という説明です。二つ目はコマンドとスクリプトの実行で、CallCLI、RunScript、GetTask に加えて「AssumeRole 跨账号」（別アカウントのロールを引き受ける操作）が書かれていました。三つ目は複数の資源の編成で、「RunIaC（plan → apply → destroy）」とあります。四つ目は公式文書の検索です。

この考え方は、公開されているリポジトリの説明とよく似ています。Alibaba Cloud が GitHub で公開している alibabacloud-api-mcp-server の英語版 README は、「a single-digit number of core tools」、一桁の数の中核ツールで数万の OpenAPI をまかなう、と説明しています。接続方式は SSE と Streamable HTTP、認証は OAuth 2.0 で、「up to 1 year of login-free operation」とも書かれています。再ログインなしで最長1年使える、ということです。権限が足りないときに診断する機能や、Terraform の構成をツールとして取り込む機能も目次に並んでいます。ただし、展示の MCP Core とこのリポジトリが同じものかどうかは、パネルにも README にも明記がありません。本記事では「考え方が近い」にとどめます。

ツールの数を絞る設計には理由があります。ツールを一つずつ用意すると、クラウドの API の数だけツールが増え、エージェントが最初に読み込む一覧が膨らみます。検索用のツールと汎用の実行用ツールだけを持たせれば、一覧は短くて済みます。そのかわり、エージェントが何を呼べるかは、事前の一覧からではなく実行時の検索結果で決まります。便利さと引き換えに、あらかじめ「この操作しかさせない」と一覧で縛る方法は使いにくくなる、と筆者は見ています。

同じ会社は、もう一つ性格の違う MCP サーバも公開しています。alibaba-cloud-ops-mcp-server の README には、ECS の RunCommand、StartInstances、StopInstances、RebootInstances、RunInstances、DeleteInstances、ResetPassword、ReplaceSystemDisk といった操作が、一つずつツールとして表に並んでいます。起動設定の例では、環境変数に ALIBABA_CLOUD_ACCESS_KEY_ID と ALIBABA_CLOUD_ACCESS_KEY_SECRET を入れる形です。こちらは操作が名前付きで見えるので、どのツールを許すかを決めやすい一方、インスタンスの削除やシステムディスクの置き換えといった取り返しのつかない操作も、同じ表に並んでいます。

パネルの最下段には「安全底座」、つまり安全の土台として、「受控 sandbox 执行」（管理されたサンドボックスでの実行）、「凭证不落脚本」（資格情報をスクリプトに書き込まない）、「HITL 人工审批」（人による承認）、「任务全程审计」（作業全体の監査）といった項目が並んでいました。一方、MCP の仕様書そのものは、ツールの節で「there SHOULD always be a human in the loop with the ability to deny tool invocations」と書いています。ツールの呼び出しを拒否できる人を常に介在させるべきだ、という推奨です。仕様は推奨を書くだけで、実際に人を介在させるのは実装の仕事です。展示が人の承認を土台の一つに挙げていたのは、この仕様の考え方と同じ方向を向いています。

MCP の仕様には、もう一点、見落とされやすい記述があります。ツールには「読み取り専用か」「破壊的か」といった性質を示す注釈を付けられますが、仕様は「clients MUST consider tool annotations to be untrusted unless they come from trusted servers」としています。信頼できるサーバから来たものでない限り、注釈は信用してはならない、という意味です。ツール自身が「これは安全です」と名乗っていても、それだけで確認を省いてはいけない、ということになります。

Terraform × Agent：構成をコードで変え、差分を見てから反映する

MCP Core がツールをつなぐ展示だとすれば、「Terraform × Agent：把云上基建交给可校验的 IaC」は構成をコードで変える展示です。クラウドのインフラを、検証できるコードとしての構成管理（IaC、Infrastructure as Code）に任せる、という題です。

見出しは「生成得出来，还要 validate 得过、纳得住管」でした。生成できるだけでなく、検証を通り、管理下に置けなければならない、という意味です。その下に、モデルの記憶に頼って Terraform の構成言語（HCL）を書くのではない、と添えられていました。右上には、実際のクラウドの情報源として「IaC Service Schema」「Provider 文档」「Resource Center」の三つが矢印でつながっています。資源の定義、Terraform の Provider の文書、実在する資源の一覧を参照して構成を書く、という主張です。

左の流れは新規構築です。例として「在杭州搭 VPC + ECS + RDS + SLB，安全组只开 80/443」と書かれていました。杭州リージョンにネットワーク、仮想サーバ、データベース、ロードバランサを作り、セキュリティグループでは80番と443番のポートだけを開ける、という依頼です。要求の解析と依存関係の補完、スキーマの照会と検証、Provider での検証という段階を経て、terraform.tf、main.tf、variables.tf、outputs.tf の四つのファイルができる、という図でした。末尾には「validate-module: ok・校验来自真实工具」、つまり検証結果は本物の道具から来ている、とあります。

右の流れは、すでに動いている資源の取り込みです。「把 cn-hangzhou 下 VPC / ECS / RDS / OSS 纳入 Terraform」、杭州リージョンにある既存の資源を Terraform の管理下に入れる、という例です。Resource Center でまとめて発見し、実際の設定から HCL を生成し、構成の関係に沿って state（Terraform が管理対象を記録するファイル）に取り込みます。新しく見つかった資源には取り込みを提案し、消えた資源は state から整理し、実物と記録のずれ（ドリフト）には修正案を出す、とも書かれていました。そして完了の条件として「plan -refresh=true → No changes 才算完成」とあります。最新の状態を読み直したうえで plan を実行し、変更なしと出て初めて完了とみなします。

この完了条件は理にかなっています。既存の資源を取り込むとき、生成した構成が実物と一致しているかどうかは、見た目では分かりません。一致していなければ、次に apply したとき Terraform は構成に合わせて実物を変えようとします。「差分なし」を完了の定義にすれば、取り込みが本当に正しかったかを道具で確かめられます。

Terraform の公式文書は、plan について「The plan command alone does not actually carry out the proposed changes」と書いています。plan だけでは変更は実行されず、予定された変更が期待どおりかを apply の前に確かめるための命令だ、という位置づけです。エージェントに構成を書かせても、plan の結果を人が読み、納得してから apply する流れを守れば、「何が変わるか」を実行の前に見られます。MCP 経由で API を一つずつ呼ぶ方法との一番大きな違いは、この点にあります。

パネル最下段の安全の項目は、この違いを意識した並びでした。「生成≠创建资源」（生成は資源の作成ではない）、「关键步骤人工确认」（重要な段階で人が確認する）、「校验来自真实工具」、「AK/SK 不落 HCL」（アクセスキーを構成ファイルに書かない）、「safety-policy 白名单」（安全ポリシーの許可リスト）、「Trace 可追溯」（追跡できる記録）です。

パネル中央の「上手」（使い始め）の欄には「npx openplugin aliyun/alibabacloud-agent-toolkit」というコマンドがありました。MCP Core のパネルにも同じツールキットを追加するコマンドが書かれており、二つの展示が一つの配布物を入口にしていることが分かります。GitHub の alibabacloud-agent-toolkit の README を読むと、spec-ops というプラグインが「planning → Terraform codegen → validation → execution via IaC Service」、つまり計画、Terraform のコード生成、検証、IaC Service での実行という四段階の流れを持つと説明されています。段階は自動で連結され、利用者の確認は「one user gate」、デプロイの直前に一か所だけ置かれると書かれています。計画の段階ではセキュリティ、費用、効率、安定性の観点で対話するとされ、実行は IaC Service 上で plan と apply を行い、state はリモートに保存されるとあります。

ここで展示と README の書き方の差が気になります。展示は「重要な段階で人が確認する」と複数形に読める書き方をしていましたが、README は確認の関門を一つと明記しています。どちらが誤りというより、見せ方の違いだと筆者は考えます。ただ、導入を検討する側から見ると、この差は大きいはずです。確認がデプロイ直前の一回だけなら、計画や設計の段階でエージェントが下した判断は、最後の plan の差分を読む人が一度に見抜く必要があります。差分が数十行なら読めますが、ネットワークや権限の設定が大量に入った差分を一度で見極めるのは簡単ではありません。

なお、同じ会社の iac-code というリポジトリは、自然言語で ROS と Terraform を扱うAIアシスタントとして紹介されています。変更を自動で反映するか、確認を求めるかについては、今回取得した README に記述が見当たりませんでした。

ホスト型 Skills を A2A で呼ぶ：手元に置かないスキル

Skills Hub の話に戻ります。別のパネルは「阿里云 Skills 全面拥抱 A2A：直接使用云上托管 Skills」と題されていました。Alibaba Cloud の Skills を A2A に全面対応させ、クラウドでホストされた Skills をそのまま使えるようにした、という題です。副題は「跨 Agent 安全通信与任务分发」、エージェント間の安全な通信と作業の振り分けです。

まず言葉を整理します。Skills は、エージェントに作業の手順書や補助のスクリプトを渡す仕組みです。公開仕様の Agent Skills Specification では、SKILL.md というファイルを含むフォルダが一つのスキルになり、名前と説明を必須の項目として持ちます。A2A（Agent2Agent）は、エージェント同士がやりとりするための公開仕様です。

図の左側には、A2A でつながるエージェントとして Qwen Paw（「已支持」、対応済み）、Qoder、千问办公、OpenClaw が並び、その下に「A2A 客户端均可接入」、A2A のクライアントならどれでも接続できる、とありました。右側の「托管 Skills」（ホストされた Skills）には、ECS、RAM、Elasticsearch、PTS、EMR Spark、Tablestore、ODPS、DataWorks など、製品名の付いた枠が並んでいます。中央の A2A の箱には三つの特徴が書かれていました。「免安装」（手元に何も入れずに A2A で接続すればすぐ使える）、「免维护」（クラウド側でまとめて更新するので利用者は更新の手間がない）、「强管控」（人の確認が組み込まれていて、危険な操作は人の確認を要する）です。

ここで「任せる」と「止める」の関係が、もう一段具体的になります。手元に Skills を置く方式では、スキルの中身は手元のファイルなので、読もうと思えば読めます。ホスト型では、スキルの中身はクラウド側にあり、利用者のエージェントは A2A で依頼を送って結果を受け取ります。A2A の仕様は、エージェントが「without needing to share their internal thoughts, plans, or tool implementations」、内部の思考や計画、ツールの実装を共有することなく協力できることを設計の原則に挙げています。中身を隠せることはA2Aの利点です。ただ、クラウドを操作される側から見ると、依頼先のエージェントがどの API をどういう順で呼んだのかは、呼び出した側からは直接見えにくい、ということでもあります。

だからこそ、展示が「强管控」を三つの特徴の一つに入れていたのは筋が通っています。中身が見えないなら、危険な操作の直前に人に確認が届く仕組みと、あとから追える記録が要ります。A2A の仕様自体も、認証されたクライアントに必要な権限がないときは「Servers MUST return an authorization error」、サーバは認可エラーを返さなければならないと定めています。権限を確かめる責任は、呼ばれる側のサーバにあります。

もう一点、Agent Skills の仕様では、スキルが使ってよいツールを事前に指定する allowed-tools という項目が「Experimental」、実験的な扱いで、対応はエージェントの実装によって異なると書かれています。スキルという仕組みそのものは、手順の質を上げるものであって、権限の境界ではない、と筆者は整理しています。権限を絞るのは、あくまでクラウド側の権限管理と、その手前に置く確認や記録の仕組みです。

Agent Catalog：探して、入れて、組み込む

Agent Catalog のパネルは英語で書かれていました。題は「Agent Catalog: Install Alibaba Cloud」で、エージェント、Skills、プラグイン、ツールを一か所で探し、入れ、組み込むための目録だと説明しています。

数字の欄には、Agents が「20+」で順次追加、Skills/Plugins が「262 Skills/3 Plugins」で「Live now・expanding」、Tools が「20,000+ APIs」で「MCP/CLI・Terraform/SDK」とありました。Skills Hub の台座の「260+」とこのパネルの「262」は、どちらも出展者の数字です。同じ集計かどうかは分かりませんが、桁は合っています。

下段には「Two paths: from "answering" to "doing"」とあり、答えるだけのAIから、実際に作業するAIへ、という流れを四段階で示していました。Use（クラウド製品のコンソールで公式のエージェントを使う）、Extend（Skills やプラグインを入れる）、Integrate（標準のツールを設定する）、Execute（自然言語でクラウドの資源を操作する）です。

この目録は、ここまで見てきた展示の索引のような位置にあります。ツールの欄に MCP と Terraform が並び、Skills の数が載っているからです。ただし、Catalog のサイトは JavaScript で描画されるため、今回の取得では中身を読めませんでした。パネルの内容以上のことは確かめていません。

目録には、便利さとは別の役割もあると筆者は考えます。社内でエージェントを使う部署が増えると、誰がどのスキルやツールを入れたのかが分からなくなりがちです。公式の目録から入れるという入口を決めておけば、少なくとも出どころは揃います。何を入れてよいかを決めるのは、目録ではなく使う企業の側です。

AI Gateway：呼び出しを一か所で見張る

三つ目の仕事、「呼び出しを一か所で見張る」を担っていたのが AI Gateway のブースです。ブース番号は 1-B3-1 で、上部に「AI网关 AI Gateway」と大きく掲げられていました。モニターの下には「连接大模型、MCP与Agent的统一入口，一次接入即可管理全部流量」と書かれています。大規模言語モデル、MCP、エージェントをつなぐ統一の入口で、一度接続すればすべての通信を管理できる、とうたっています。英語でも「A unified gateway connecting LLMs, MCP, and agents」と併記されていました。

撮影時にモニターに映っていたのは、安全対策のスライドでした。画面下部にページ送りの点が並んでいるので、スライドは複数枚が切り替わる形式だったとみられます。同じ体裁のスライドが別の写真に三枚写っているので、順に見ていきます。

一枚目は「Token 治理：把每一分 AI 成本算清楚」、AIの費用を一銭まで明らかにする、という題でした。四つの枠は、呼び出し元の認証と認可、FinOps とトークンの割り当て、多段の流量制限、キャッシュによるコスト削減です。認証の枠には API Key、JWT、HMAC といった方式名が見えます。下の帯には「每一笔 Token 花费，都能归因到消费者与模型」、トークンの支出を一件ずつ、呼び出し元とモデルに結び付けられる、とあります。

二枚目はブースのモニターに映っていたものと同じ「AI 安全护栏：请求与响应双向防护」、要求と応答の両方向で守るAIの安全柵です。見出しの下に、内容のコンプライアンス、プロンプトへの攻撃、機微なデータ、悪意のあるファイル、電子透かしの五つが検査の観点として並びます。右の枠には処置として「拦截」（遮断）と「脱敏」（機微な情報を伏せる処理）の二つのボタンがあり、防御の水準や処置を利用者が決められること、遮断の記録をすべて残して監査できることなどが箇条書きされていました。帯の一文は「让每一次模型调用都合规、可控、可追溯」で、モデルを呼び出すたびに規則を守らせ、制御し、あとから追えるようにする、という宣言です。

三枚目は「MCP 与 Agent 统一管控，六大场景开箱即用」、MCP とエージェントを一元管理し、六つの場面ですぐ使える、という題でした。上段は「MCP 网关」と「Agent API」の二枠で、Agent API の枠には阿里云百炼（Alibaba Cloud Model Studio）や独自のエージェントといった接続先が並んでいます。下段の利用場面には、統一のモデル入口、MCP の一元管理、コーディング用のツールの一元管理などが書かれているように読めました。写真の解像度では細部を読み切れないため、これ以上の引用は控えます。

展示の訴えを公開文書と照らすと、かなりの部分が一致します。Alibaba Cloud の製品文書「What is AI Gateway」（2026年9月9日更新）は、既存の HTTP サービスを MCP サーバとして公開する機能や、場面ごとにツールの一覧を組み合わせた仮想 MCP サーバを作れることを説明しています。ツールが増えるとモデルに送る一覧が長くなり、トークン消費と推論の費用が増え、選択の精度も落ちるとしたうえで、要求の内容に応じて関係するツールだけを絞り込む機能を挙げています。セキュリティについては「authentication at the MCP server level and fine-grained permissions for individual tools」、MCP サーバ単位の認証と個々のツールに対する細かい権限を挙げ、権限は呼び出し元の身元とツールの危険度にもとづいて割り当てるとしています。モデルの呼び出しでは、禁止語やコンプライアンス違反、プロンプトインジェクションを防ぐ機能を API ごとに有効にできるとあります。エージェントの接続については、A2A と Nacos AI Registry による登録と発見に触れています。

MCP サービスの作り方を説明する別の文書では、裏側がもともと MCP サーバなら「MCP Service Direct Proxy」、裏側が普通の HTTP サーバなら「HTTP to MCP」を選ぶ、と二つの方式が示されています。社内にある既存の Web API を、改修せずにエージェントから呼べる形にできる、というのがこの方式の要点です。

一方で、文書の間で書き方が揃っていない部分もありました。概要の文書は個々のツール単位の権限をうたっていますが、呼び出し元の認可管理の文書（2026年8月26日更新）が説明している認可の種類は「Model API」と「MCP」の二つで、ツール単位の設定手順はそのページには出てきません。ツール単位の権限をどの画面でどう設定するのかは、本記事では未確認としておきます。

なお、Alibaba Cloud 発のオープンソースのゲートウェイに Higress があります。README では Istio と Envoy を土台にし、Go や Rust、JavaScript で書いた Wasm プラグインで拡張できるゲートウェイと説明されており、CNCF Sandbox のバッジも付いています。商用の AI Gateway と Higress の関係は、今回取得した文書には書かれていなかったため、両者を同じ製品として扱うことはしません。

ゲートウェイの強みは、呼び出しが必ずそこを通る限り、誰が、何に、どれだけ呼んだかを一か所で数え、止め、記録できることです。弱点はその裏返しで、ゲートウェイを通らない呼び出しは見えません。先に見た ops-mcp-server のように、手元の端末で MCP サーバを動かし、環境変数のアクセスキーで直接クラウドの API を呼ぶ構成では、その通信はゲートウェイを経由しません。一か所で見張るという約束は、経路をそこに集めて初めて成り立ちます。

三つの展示を並べると見えること

ここまでの展示を並べ直すと、会場では次のような分担になっていました。MCP Core とホスト型 Skills は、エージェントにクラウドの機能をつなぐ役です。Terraform × Agent は、変更をコードにして、実行する前に差分を見せる役です。AI Gateway は、モデル、MCP、エージェントへの呼び出しを入口に集めて、認証し、数え、検査し、記録する役です。Agent Catalog は、これらを探して入れるための目録です。

公開されている資料の範囲で言えば、MCP Core と Terraform × Agent は同じエージェント向けツールキットを入口にしている点でつながっています。一方、AI Gateway とツールキットが連携している、あるいは一つの製品として統合されているという記述は、今回読んだ文書には見当たりませんでした。展示が別々のブースやパネルに分かれていたこととも合っています。組み合わせ方は、使う側が設計することになります。

それぞれの経路には、得意なことと苦手なことがあります。MCP で API を直接呼ぶ経路は速くて柔軟です。サーバの再起動やログの確認のような、小さく戻しやすい作業に向いています。そのかわり、一回ごとの呼び出しが即座に実物を変えるので、何が起きるかを事前に一覧で見ることはできません。Terraform の経路は、構成全体の差分を事前に見られます。ネットワークやデータベースの追加のような、影響が広い変更に向いています。そのかわり手間がかかり、state の管理という別の仕事が生まれます。ホスト型 Skills の経路は、専門的な手順をクラウド側の知見ごと借りられますが、中身は見えにくくなります。ゲートウェイは、これらの経路のうち、自分を通るものだけを見張れます。

筆者がこの分担で一番重要だと思うのは、どの展示も、エージェントが最終的に何をしてよいかを決める仕組みそのものではない、という点です。それを決めているのはクラウド側の権限管理で、Alibaba Cloud では RAM のロールと一時的な資格情報がその中心になります。Terraform の Provider の文書も、ECS 上では RAM ロールを使う方法を、資格情報をコードに直書きせずに済む「preferred approach」（推奨される方法）として挙げています。ロールを引き受ける設定では、一時的な資格情報に「A more restrictive policy」、より制限の強いポリシーを重ねられるとも書かれています。エージェント用に作業の範囲だけを許すロールを切り出し、そのうえで MCP、Terraform、Skills、ゲートウェイのどこで人が確認し、どこに記録を残すかを決める、という順番が現実的だと筆者は考えます。

条件付きの見通し

ここからは筆者の予測です。根拠は展示と公開文書ですが、将来の製品の動きを約束するものではありません。

まず、エージェントにクラウドを操作させる仕組みは、「どれだけのことができるか」より「どこで止められるか」で比べられるようになると考えます。Skills Hub の画面で、260以上のスキルと人の確認が同じ画面に並んでいたのは、その兆しに見えました。条件は、エージェントの操作による事故や、意図しない費用の発生が表に出てくることです。そうなれば、導入を判断する側はまず止め方を尋ねるはずです。

次に、Terraform のような「差分を見てから反映する」経路は、エージェントの時代にむしろ価値が上がると考えます。人が手で構成を書いていた頃、plan は書いた本人が自分の意図を確かめる道具でした。エージェントが構成を書くようになると、plan は書いていない人が他人の意図を確かめる道具になります。展示が「生成は作成ではない」「差分なしで完了」と繰り返していたのは、この変化を見越したものだと筆者は読みました。ただし、差分が長くなりすぎると人は読まなくなります。差分をどう要約し、どこを重点的に見るべきかを示す支援が、次の課題になるはずです。

三つ目に、呼び出しを入口で見張る仕組みは、費用の管理から広がると考えます。AI Gateway の展示で最初に来ていたのが、安全よりも「トークンの支出を呼び出し元とモデルに結び付ける」話だったのは象徴的です。費用の配賦は経理や情報システム部門にとって分かりやすい導入理由になり、入口がそこに集まれば、検査や記録もついてきます。ただしこれは、社内のエージェントやコーディング用のツールの通信を実際にゲートウェイへ集められる場合に限ります。手元の端末から直接クラウドを呼ぶ経路が残る限り、見張りには穴が空きます。

エージェント同士が互いの能力を呼び合う形も、A2A のような仕様によって少しずつ現実味を帯びています。ただし今回の展示と文書で確認できたのは、エージェントが別のエージェントやホストされたスキルに作業を依頼する仕組みまでです。エージェント同士が自動で料金を払い合って能力を売り買いするような姿は、まだ将来の話として見ておくべきだと考えます。

日本企業の仕事にとって何が変わるか

日本企業の情報システム部門やクラウドを運用する現場から見ると、この変化は三つの仕事の見直しにつながりそうです。

一つ目は、承認の仕事の見直しです。多くの企業では、本番環境の変更は申請書と承認の手続きを通ります。承認者が見るのは、多くの場合、担当者が書いた作業手順書です。エージェントが作業するようになると、承認者が見るべきものは手順書から、plan の差分や、エージェントが計画した操作の一覧に変わります。承認の粒度も問われます。Skills Hub の展示にあったような、スマートフォンに確認が届く仕組みは便利ですが、確認が頻繁に届けば人は中身を読まずに承認するようになります。どの操作は自動で通し、どの操作は人が見るのかを、業務ごとに線引きする必要があります。

二つ目は、権限設計の仕事の見直しです。これまでクラウドの権限は、人の担当者や、特定のバッチ処理に対して付けるものでした。エージェントは、同じ一つの仕組みがある日はログを調べ、ある日はサーバを止める、という使われ方をします。作業ごとに違う権限の範囲を持たせるには、ロールを細かく分け、一時的な資格情報を使い、長期のアクセスキーをエージェントに渡さない運用が要ります。展示が「資格情報をスクリプトに書き込まない」「アクセスキーを構成ファイルに書かない」を繰り返し掲げていたのは、この問題が現場で起きやすいことの裏返しだと思います。

三つ目は、記録と費用配賦の仕事の見直しです。エージェントがクラウドを操作すると、操作の記録は「誰が」の欄にエージェントの名前が残るだけでは足りません。どの利用者の、どの依頼から、どのエージェントが、どの資格情報で操作したのかを、あとからたどれる必要があります。監査や内部統制の担当者にとって、ゲートウェイの記録とクラウド側の操作記録をつなげられるかどうかは、エージェントを本番で使えるかどうかの分かれ目になりそうです。費用についても、部署ごとにトークンの支出を割り振れれば、予算の管理がしやすくなります。

加えて、日本企業ならではの事情もあります。Alibaba Cloud の中国リージョンと国際リージョンでは、エンドポイントや利用できる機能が分かれている場合があります。今回読んだ MCP サーバの README でも、中国サイトと国際サイトで入口の URL が別になっていました。展示で見た機能が、日本から使うリージョンやアカウントでも同じ形で提供されているかは、導入前に一つずつ確かめる必要があります。

クラウド操作をエージェントに任せるために当社が重視すること

当社は、海外で生まれた仕組みを日本企業の業務と手続きにつなぎ、AIに仕事を任せられる状態をつくることを目指しています。この分野では、次の三点を重視しています。

まず、評価と選定です。MCP で直接呼ぶ経路、Terraform を通す経路、ホスト型 Skills を呼ぶ経路、ゲートウェイを置く構成のうち、どれをどの作業に使うかは、企業ごとに答えが違います。本記事で見たように、展示の説明と公開文書の書き方には差があり、確認の関門が何か所あるのか、ツール単位の権限がどこで設定できるのかといった点は、実際に検証しないと分かりません。展示や公開文書を読み比べ、検証環境で確かめたうえで、作業の種類ごとに経路を選べるようにすることを目指します。

次に、業務への接続です。エージェントにクラウドを任せるときに一番時間がかかるのは、技術の設定よりも、既存の変更管理や承認の手続きとのすり合わせだと筆者は考えています。どの操作を自動で通し、どの操作で人が確認し、その確認を誰が担うのかを、現場の業務の流れに合わせて決める作業は、現場の方と一緒に進める必要があります。

最後に、現場で得た知見の再利用です。エージェントの作業で止めるべきだった場面や、確認の頻度が多すぎて形だけになった場面は、どの企業でも起きうる経験です。そうした知見を、確認の基準や作業の手順として整理し、次の導入に生かせる形にすることを目指します。海外で出てきた仕組みを日本の現場の手続きに合わせ、実際に仕事を任せられる状態まで持っていくことが、当社の担う役割だと考えています。

出典

• Alibaba Cloud「What is AI Gateway」 https://www.alibabacloud.com/help/en/api-gateway/ai-gateway/product-overview/what-is-an-ai-gateway
• Alibaba Cloud「Create and Manage MCP Services」 https://www.alibabacloud.com/help/en/api-gateway/ai-gateway/user-guide/gateway-managed-mcp-services
• aliyun/alibabacloud-api-mcp-server README-EN https://github.com/aliyun/alibabacloud-api-mcp-server
• aliyun/alibaba-cloud-ops-mcp-server README https://github.com/aliyun/alibaba-cloud-ops-mcp-server
• aliyun/alibabacloud-agent-toolkit README https://github.com/aliyun/alibabacloud-agent-toolkit
• aliyun/iac-code README https://github.com/aliyun/iac-code
• aliyun/terraform-provider-alicloud（Provider 文書 index） https://github.com/aliyun/terraform-provider-alicloud
• HashiCorp「terraform plan command」 https://developer.hashicorp.com/terraform/cli/commands/plan
• Model Context Protocol Specification「Tools」 https://modelcontextprotocol.io/specification/latest/server/tools
• A2A Protocol Specification https://a2a-protocol.org/latest/specification/
• Agent Skills Specification https://agentskills.io/specification
• Higress README https://github.com/alibaba/higress
• 展示写真：筆者撮影（Apsara Conference 2026 会場）

記事情報

関連記事

• 2026.09.26｜解説AIエージェント基盤を読み解く、6つの視点：Apsara Conference 2026 技術解説シリーズ
• 2026.09.26｜解説世界モデル・Physical AI編：生成と操作の違い、遅延という制約
• 2026.09.26｜解説AI端末・ワークスペース編：Qwen BookからクラウドPC、ウェアラブルまで

改訂履歴