「ポリシーは文書、エージェントは野放し」というギャップ
多くの企業で、AIエージェントの利用ガイドラインは立派なPDFになっています。「機密データは外に出さない」「重要な操作は人間が承認する」「操作履歴は監査用に残す」——。ところが、その文書に書かれたルールが、実際に動いているエージェントの中で機械的に効いているかとなると、話は別です。ポリシーは文書の世界にあり、エージェントはコードの世界で動く。この2つの世界が地続きになっていないことが、エンタープライズAIの最大の弱点でした。
homulaは、エンタープライズ企業向けにAIエージェントの戦略策定・PoC・実装・運用・内製化までを一気通貫で支援するAIインテグレーターです。本稿では、2026年6月にMicrosoftが公開した**Agent Control Specification（ACS）**を取り上げます。ACSは「文書のポリシー」と「動くエージェント」のあいだの溝を、オープンな標準で埋めようとする試みです。なぜこれが単なる一社の新機能発表にとどまらず、業界全体の論点なのか。日本企業が取るべき打ち手とあわせて整理します。
ACSとは何か——ポリシーがエージェントと一緒に「旅をする」
ACSは、AIエージェントの実行時（ランタイム）統制を定義するオープンソースの標準仕様です。Microsoftが自社の「Agent Governance Toolkit（AGT）」の一部として公開し、ライセンスはMIT、特定ベンダーに縛られないベンダーニュートラルな仕様として位置づけられています（TechCrunch, 2026年6月2日 / Microsoft Foundry Blog）。
ACSが定めるのは、開発・セキュリティ・コンプライアンスの各チームが共通の書式で記述できるポリシーファイルです。そこには次の4点を書きます。
- エージェントが何をしてよいか（許可される行動）
- 何を避けるべきか（禁止される行動）
- どの操作で人間の承認を必須とするか
- 後から監査できるよう、どの証跡を残すか
肝は、このポリシーがエージェント本体にバンドルされ、フレームワークや実行環境を越えて持ち運べる点です（Microsoft Open Source Blog, 2026年4月2日）。LangChainで作ったエージェントをCrewAIに載せ替えても、AWSからオンプレに移しても、統制ルールが置き去りにならない。「ポリシーがエージェントと一緒に旅をする」——これがACSの設計思想です。
従来、エージェントの統制ロジックは「作ったフレームワークの中」に閉じていました。フレームワークを乗り換えると統制も書き直し。ACSはこの統制をフレームワークから切り離した共通レイヤーに引き上げます。アプリのコードを書き換えなくても、各フレームワークのネイティブな拡張点にフックして統制を差し込めるのが特徴です。
5つのチェックポイント——「どこで」効かせるのか
ポリシーを書くだけでは絵に描いた餅です。ACSが実務的なのは、エージェントの処理フローのどの瞬間にルールを照合するかを明確に定義している点にあります。仕様は、エージェントのライフサイクルに5つの検証チェックポイントを置きます（CSO Online / Microsoft Foundry Blog）。
| チェックポイント | 効かせる場面 | 典型的な統制例 |
|---|---|---|
| Input（入力） | ユーザー入力を受け取る前 | プロンプトインジェクション検査・機密語句の遮断 |
| LLM | モデルに推論を投げる前後 | 送信前のマスキング・出力の方針逸脱検知 |
| State（状態） | エージェントの内部状態が更新される時 | メモリ汚染（記憶の改ざん）の検出 |
| Tool execution（ツール実行） | 外部ツール／APIを呼ぶ前後 | 権限外の操作の停止・人間承認の差し込み |
| Output（出力） | 最終応答をユーザーへ返す前 | DLP（情報漏えい防止）・証跡の確定 |
決定的なのは、これらの検査が**確定的（deterministic）**に——つまり「AIの気分」ではなくルールに従って機械的に——実行される点です。AGTはアプリケーション層でエージェントの各アクションをポリシーに照合し、その判定をサブミリ秒級の遅延で挟むとされています（Microsoft Community Hub）。「承認が必要な操作（ツール実行のチェックポイント）」で人間に判断を仰ぐ、という設計は、まさに多くの日本企業が求めてきた Human-in-the-loop の標準化です。
なぜ「標準」であることが効くのか——MCP・A2Aに続く第3の標準
ACSの本質的な価値は、機能そのものよりも「標準であること」にあります。CSO Onlineは、ACSを「エージェント安全性におけるMCPやA2Aのような存在」と表現しています。**MCP（Model Context Protocol）**がエージェントとツールの接続を、A2A（Agent2Agent）がエージェント同士の通信を標準化したように、ACSは安全性・統制の制御を、どのフレームワークでも採用できる1つの開かれた標準にしようとしている、という整理です。
その「採用可能性」を裏付けるのが、対応フレームワークの広さです。ACS／AGTは、LangChain、OpenAI Agents SDK、Anthropic Agents SDK、AutoGen、CrewAI、Semantic Kernel、Microsoft.Extensions.AI、そしてMCPツールに対応するとされ、Python・TypeScript・.NETの3言語で提供されています。TypeScript SDKは @microsoft/agent-governance-sdk@4.0.0 としてパブリックプレビューで配布されています。さらにツールキットは、エージェント固有のリスクを体系化したOWASP Agentic Top 10の10項目すべて（ゴール乗っ取り、ツール悪用、ID濫用、メモリ汚染、暴走エージェント等）をカバーすると謳われています（GitHub: microsoft/agent-governance-toolkit）。
エコシステムの広がりも始まっています。たとえばネットワーク企業のAviatrixは、ACSをネットワーク層まで拡張する取り組みを2026年6月に発表しました。特定ベンダーの製品ではなく共通の語彙が生まれると、周辺のセキュリティ製品やインフラが同じ仕様に乗ってくる——標準が標準たるゆえんです。
標準化の流れは「接続（MCP）→協調（A2A）→統制（ACS）」と読むと整理しやすいです。homulaが繰り返し論じてきたコントロールプレーン（統制基盤）の本命化は“製品カテゴリ”の話、ACSは“その下で動く共通仕様”の話。製品とプロトコルは補完関係にあります。
標準ができても、運用は別物——日本企業の落とし穴
ここで冷静になりたいのは、ACSは「ポリシーの書式」を標準化するものであって、ポリシーの中身や運用体制まで用意してくれるわけではないという点です。仕様が共通になっても、次の問いは各社に残ります。
- 誰がポリシーを定義し、承認するのか（業務部門か、情シスか、リスク管理か）
- 「人間の承認が必要」と書いたとして、現実に誰がいつ承認するのか。承認の滞留で業務が止まらないか
- 残した証跡を、どこに・何年・改ざん不能な形で保全するのか。監査・内部統制の要件を満たすか
- 部門ごとに乱立した「野良エージェント」に、そもそもポリシーを後付けで適用できるのか
つまりACSは、統制の**配管（インターフェース）**を標準化してくれますが、水を流す体制——承認フローの設計、監査ログの保全、RBAC（役割ベースのアクセス制御）の運用、そして部門横断のガバナンス体制——は、依然として各社が自ら作り込む領域です。標準対応のSDKを入れただけで統制が完成する、という誤解は禁物です。
homulaの観点——ポリシーを「絵に描いた餅」にしないために
homulaは、まさにこの「標準と運用のあいだ」を埋めることを生業にしています。提供プラットフォーム Agens は、MCPを活用して200以上のツールと構築ゼロで接続し、エージェントを早期に実戦投入できる基盤です。そして統制面を担う Agens Control は、承認フロー・DLP・5年分の監査ログ・RBACを備えます。これはACSが標準化しようとしている統制要素——人間の承認、情報漏えい防止、証跡の保全、権限制御——と、思想がそのまま重なります。
実務での勝ち筋は、順序にあります。いきなり全社の野良エージェントに統制をかぶせるのではなく、業務の棚卸し → 小さく統制込みでPoC → 効果検証 → 横展開 → 内製化という段階を踏むこと。homulaのAIエージェント・ブートキャンプは、業務棚卸し・プロトタイプ構築・ROI試算を3〜5日で完結させ、最初から「承認と監査が組み込まれた」エージェントの型を作ります。標準が固まりつつある今だからこそ、自社のポリシーを機械が読める形に落とし込み、運用に乗せる設計力が差になります。
過去の導入支援では、定型業務で処理時間を93%削減した例もあります。重要なのは、その自動化が「誰が承認し、何を記録するか」まで含めて設計されていたこと。スピードと統制は二者択一ではありません。
まとめ——統制が「後付け」から「前提」へ
ACSの登場が示すのは、AIエージェントの統制が後付けのオプションから、設計の前提へ移りつつあるという潮流です。MCPがツール接続を、A2Aがエージェント連携を当たり前にしたように、「実行時にポリシーを機械的に効かせる」ことが、近い将来の標準装備になります。
日本企業が今やるべきは、流行の標準名を追うことではありません。自社の業務に即したポリシーを言語化し、それを機械可読な形で運用に組み込み、承認と監査を回せる体制を持つこと。標準はその器を整えてくれますが、中身を満たすのは各社の実務です。homulaは、その器と中身の両方を、戦略から内製化まで伴走して形にします。
AIエージェントの統制を「文書」から「動く仕組み」へ。承認・監査・権限設計を実装に落とし込みたい方は、お気軽にご相談ください。