「賢さ」の次は「統制」が標準化される
homulaは、エンタープライズ企業のAIエージェント導入を、セキュリティ・コンプライアンス・監査の要件まで含めて設計するAIインテグレーターです。
ここ1年、PoCを越えて本番に乗せる現場で繰り返し聞く問いは同じです。「このエージェントに何を許し、どこで人が承認し、後から誰が何をしたかを監査できるのか」。モデルの賢さではなく、この統制（ガバナンス）の設計が、情報システム部門の最後の関門になっています。これまで各社は、その統制を自社プラットフォームの管理画面の中に閉じて提供してきました。だからこそ、統制はベンダーごとにバラバラで、フレームワークを乗り換えると作り直しになる——これが現場の悩みでした。
2026年6月2日、サンフランシスコで開かれたMicrosoft Build 2026で、この構図を変えうる発表がありました。Agent Control Specification（ACS）——エージェントの振る舞いを統制するための、オープンでロイヤリティフリーの標準仕様です（TechCrunch、Microsoft Foundry Blog）。ポイントは、統制を「単一製品の機能」ではなく「持ち運べる標準」にしようとしている点にあります。
ACSとは何か——統制を「宣言」して持ち運ぶ
ACSは、開発・コンプライアンス・セキュリティの各チームが、エージェントが何をしてよいか／何を避けるべきか／どんなときに人間の承認へエスカレーションするか／どんな証跡を記録すべきかを、宣言的に定義するためのポリシー言語です。ポリシーは**YAML（またはJSON）**で書かれた単一ファイルとして、エージェントのデプロイパッケージに同梱されます。これにより、統制がエージェントと一緒に移動する——フレームワークや実行環境を変えても、ポリシーがそのまま付いて回る、という発想です（Microsoft Foundry Blog）。
ACSは、MicrosoftのAgent Governance Toolkit（AGT）の一部として位置づけられ、リファレンス実装はMITライセンスで公開されています（GitHub: microsoft/agent-governance-toolkit）。AGTはポリシー強制・ゼロトラストのID・実行サンドボックス・信頼性エンジニアリングを束ねる枠組みで、リポジトリの説明ではOWASP Agentic Top 10を10/10カバーするとされています。
宣言的（declarative） とは、「どう実装するか」ではなく「何を満たすべきか」を記述する方式です。ACSはポリシーをコードに埋め込むのではなく、バージョン管理でき・差分が追え・監査できる外部ファイルとして切り出します。統制をアプリのロジックから分離することが、ポータビリティと監査性の前提になります。
8つの「インターセプトポイント」——ライフサイクル全体に網をかける
ACSの実装上の核心は、エージェントの実行ライフサイクルに沿って**8つの介入点（interception points）**を定義し、その各点で実行時コンテキストに対してポリシーを評価できることです（Microsoft Foundry Blog）。
| 介入点 | 何を評価するか（実務での意味） |
|---|---|
agent_startup | 起動時の前提・権限スコープの確認 |
input | ユーザー/外部入力の検査（プロンプトインジェクション対策の起点） |
pre_model_call | モデル呼び出し直前のチェック |
post_model_call | モデル出力の検査 |
pre_tool_call | ツール実行直前——危険な操作の承認・遮断の最重要ポイント |
post_tool_call | ツール実行結果の検査・記録 |
output | 最終出力のフィルタ（DLP・機密情報の流出防止） |
agent_shutdown | 終了処理・証跡の確定 |
ここで重要なのは、pre_tool_callのような「外界へ働きかける直前」に承認・遮断・記録のフックを差し込めることです。「DBに書き込む」「メールを送る」「外部APICを叩く」といった不可逆な操作の手前で、人間の承認を求めたり、ポリシー違反を止めたりできる——これは、私たちが日々のエージェント設計で承認境界と呼んできた考え方を、標準化された介入点として表現したものに他なりません。
「エージェント安全のMCP」——なぜ標準化が効くのか
Microsoftはこの位置づけを端的に表現しています。曰く、「ACSはエージェント安全におけるMCPやA2Aのようなもの」——MCP（Model Context Protocol）がエージェントとツールの接続を、A2A（Agent2Agent）がエージェント間通信を標準化したように、ACSは安全性・統制を1つのオープン標準にする、という狙いです（Microsoft Foundry Blog）。
それを裏打ちするのが、フレームワーク非依存の作りです。ACSはSDKとして提供され、LangChain・OpenAI Agents SDK・Anthropic Agents SDK・AutoGen・CrewAI・Semantic Kernel・Microsoft.Extensions.AI・MCPツールなどのプラグインが用意されます（TechCrunch）。つまり、エージェントを「どのフレームワークで作るか」と「どんな統制をかけるか」を切り離せる。実装の自由度を保ちながら、統制だけは共通の言語で書ける——これが標準化の実利です。
標準が効くのは「相互運用」が成立するからです。MCPが普及したことで、ツール接続は「各社独自コネクタ」から「共通プロトコル」へ移りました。同じことが統制でも起きれば、ポリシーを一度書けば複数のエージェント基盤で再利用できる。乗り換えコストとベンダーロックインの両方が下がります。MCP自体の進化はMCPのステートレス化とエンタープライズ対応も合わせてご覧ください。
同時に進む「統制の標準化」の波
ACSは単発の出来事ではありません。2026年は、エージェント統制が「製品機能」から「業界の共通基盤」へ移る局面に入っています。
- オープンな信頼スタック: MicrosoftはACSと同時に、ポリシー駆動の評価フレームワークASSERT（Adaptive Spec-driven Scoring for Evaluation and Regression Testing）をオープンソースで公開しました。統制（ACS）と評価（ASSERT）をセットで「open trust stack」として打ち出しています（Microsoft Foundry Blog）。
- 使用量の統制: GitHubは2026年6月1日、全Copilotプランを使用量ベース課金（AI Credits）へ移行し、ユーザー単位の予算上限を設定できるようにしました。Businessは$19/ユーザー・月（うち$19分のクレジット）、Enterpriseは$39/ユーザー・月（うち$39分）という構成です（GitHub Changelog）。「誰がどれだけ使えるか」もまた統制の一部になりました。
- 実行の隔離: NVIDIAとServiceNowは5月、自律エージェントをサンドボックス化されたポリシー統制下の環境で動かす仕組み（NVIDIA OpenShell／ServiceNow AI Control Tower）を打ち出しました。「エージェントが何を見られるか・どのツールを使えるか・各アクションをどう封じ込めるか」を定義する発想は、ACSの介入点と同じ方向を向いています（NVIDIA Blog）。
宣言的ポリシー（ACS）・評価（ASSERT）・使用量予算（Copilot）・実行隔離（OpenShell）——切り口は違えど、すべて**「自律エージェントに、検証可能な制約をかける」**という一点に収斂しています。
homulaの観点——標準があっても「運用」は自動で立ち上がらない
標準仕様は強力ですが、それ自体は「箱」です。日本企業の現場で本当に効かせるには、自社の業務・規程に合わせて中身（ポリシー）を設計し、運用に乗せる作業が残ります。具体的には、(1) どの操作を不可逆・高リスクと見なしpre_tool_callで止めるか、(2) 誰の承認をどの閾値で挟むか、(3) どの証跡を何年保持し、誰が監査するか——この3点は、標準を入れても自動では決まりません。
homulaはここを、ベンダー中立のインテグレーターとして設計します。現実の業務はClaudeもOpenAIも、社内のn8n / Dify / LangGraphによる自動化も、複数のSaaSもまたいで動きます。だからこそ統制は、特定プロバイダの管理画面に閉じず、横断で効く必要があります。AgensはMCPを活用し、200以上のツールと構築ゼロで接続する共通基盤を提供します。その上でAgens Controlは、承認フロー・DLP・RBAC・5年分の監査ログを、プロバイダをまたいで一元的に効かせます。ACSのような標準が示す「介入点と証跡」の考え方は、こうした横断統制の土台と組み合わせてこそ、本番運用に耐えるものになります。
どこから手を付けるかは、業務棚卸し・プロトタイプ構築・ROI試算を3〜5日（最短5日でPoC）で完結するAIエージェント・ブートキャンプで素早く見極められます。
まとめ
2026年6月2日のMicrosoft Build 2026で発表されたACSは、エージェント統制を「単一製品の機能」から「持ち運べるオープン標準」へ引き上げる試みです。YAMLで書いた宣言的ポリシーをエージェントに同梱し、ライフサイクル上の8つの介入点で「できること・止めること・承認・証跡」を制御する。フレームワークを横断する点で、MicrosoftはこれをMCPやA2Aに並ぶ「エージェント安全の標準」と位置づけています。GitHubの予算統制やNVIDIA／ServiceNowの実行隔離と合わせ、2026年は統制が標準化・ポータブル化する年になりつつあります。
日本企業が問うべきは「どの統制製品を買うか」ではなく、**「自社のリスクに合った介入点・承認・監査をどう設計し、プロバイダをまたいで一貫させるか」**です。標準が整いつつある今こそ、運用設計を先に固めることが、本番化の成否を分けます。
新しい標準を取り入れる前に、「どの操作を止め、誰が承認し、何を監査するか」を自社の規程に合わせて先に決めておくのが近道です。フレームワーク横断で一貫した統制の設計を、早めに整理することをおすすめします。