Agent Control Specification（ACS）とは？
Agent Control Specification（以下、ACS）とは、AIエージェントの実行時の振る舞いを統一的に統制するための、オープンソースかつベンダー中立の標準仕様です。Microsoftが主導して策定し、2026年6月のMicrosoft Build 2026にあわせて公開されました。本記事執筆時点（2026年9月）で参照される仕様文書は0.4.0-alpha.1のDraftであり、ACSを含むAgent Governance ToolkitはPublic Previewとして継続的にアップデートされています。
これまで企業がAIエージェントを業務に組み込むうえでは、「エージェントが何をしてよいか」「どこで人間の承認を挟むか」「どの操作をログとして残すか」といったルールを、フレームワークごと、プロジェクトごとに個別に実装する必要がありました。LangChainやAutoGen、CrewAIなど多様なフレームワークが併存する現在の開発現場では、同じ統制要件を満たすために重複した実装を抱え、監査時にも整合性を取りにくいという課題が指摘されてきました。
ACSは、こうしたガバナンスの実装をフレームワークの外側に取り出し、ポータブルなマニフェストとして表現できるようにするための仕様です。MITライセンスの下でGitHubに公開されており、Python・Node.js・.NET・Rustの各SDKを通じて、既存のエージェント実装に組み込むことができます。
ACSとは（出典：Microsoft Command Line）
Agent Governance Toolkit（AGT）とACSの関係
ACSを理解するうえで、先に整理しておくべきなのが「Agent Governance Toolkit（以下、AGT）」との関係です。両者は密接に関わっていますが、役割の粒度が異なります。
AGTは、Microsoftが2026年4月にオープンソースとして公開した、AIエージェント向けのランタイムセキュリティ／ガバナンスツールキットです。ポリシーエンジン、ゼロトラストID、実行制御、SRE、コンプライアンス検証、プラグインのライフサイクル管理など、AIエージェントのランタイムガバナンスに関わる複数の機能を提供しています。
一方、ACSはこのAGTの中核を担うポリシー判定の標準仕様にあたります。具体的には、エージェントがどのタイミングで、どのような入力をもとに、どの言語で書かれたポリシーを評価し、どの形式で判定結果を返すかを定義する仕様書とリファレンス実装です。
両者の関係を整理すると以下のようになります。
区分 | 内容 | 提供形態 |
|---|---|---|
AGT | エージェント全体のガバナンス実装群（ポリシー、ID、実行制御、SRE、コンプライアンス、プラグイン管理） | ツールキット |
ACS | ガバナンスの中核となるランタイム制御・ポリシー評価の標準仕様 | 仕様＋リファレンス実装 |
AGTがエージェントガバナンスを実装するための部品一式だとすれば、ACSはその中で「どの処理の前後に、どの制御を、どの入力にもとづいて適用するか」を定める設計図に近い位置づけです。
実務では、Azure AI FoundryやMicrosoft Agent Frameworkを利用するエージェントから、自社開発のLangChain／LangGraphベースのエージェントまで、共通のACSマニフェストを通じて統制ルールを適用できるように設計されています。
次のセクションからは、ACSそのものの特徴を詳しく見ていきます。
AGTとは（出典：Microsoft Agent Control Specification）
ACSの主な特徴
このセクションでは、ACSがエンタープライズAIエージェント開発にもたらす主な特徴を、設計思想と技術仕様の両面から解説します。
8つのインターベンションポイントによる統制
ACSの大きな特徴は、AIエージェントのライフサイクル全体を8つのインターベンションポイント（介入ポイント）に分解し、それぞれの地点でポリシー評価を行えるように標準化している点です。
具体的なインターベンションポイントは以下の通りです。
インターベンションポイント | 評価のタイミング |
|---|---|
agent_startup | エージェントセッションの開始前 |
input | ユーザーやシステムからの入力が組み立てられた直後 |
pre_model_call | LLMへプロンプトを送信する直前 |
post_model_call | LLMから応答が返ってきた直後 |
pre_tool_call | ツール呼び出しを実行する直前 |
post_tool_call | ツールの結果が利用可能になった直後 |
output | 最終出力をユーザーに返す直前 |
agent_shutdown | エージェントセッションの終了直前 |
出典：Microsoft Agent Control Specification
例えば「個人情報を含む入力はLLMに送らない」というルールはinputとpre_model_callで、「破壊的なデータベース操作には人間の承認を求める」というルールはpre_tool_callで、それぞれ評価する設計が可能です。これらをマニフェストで宣言的に記述することで、フレームワークやランタイムが異なる環境でも、同じ統制ルールを再利用しやすくなります。
Stateless・Deterministic・Fail-closedの設計原則
ACSのポリシー判定エンジンは、ステートレス（状態を持たない）、決定論的（同じ入力からは常に同じ出力）、フェイルクローズド（エラー時は拒否） という3つの原則に従って設計されています。
ステートレスであるため、ホスト側が各インターベンションポイントで完全なスナップショットを渡します。ACSランタイムは、後続の判定に影響する可変状態を保持しません。これにより、判定結果の再現性と監査性が高く保たれます。
決定論的な設計により、同じマニフェスト・同じスナップショット・同じenforcement mode・同じディスパッチャ結果を与えた場合、同じベルディクトを再現できるように設計されています。この4条件を揃えたテストであれば期待動作を安定して検証できるため、ガバナンス設計のテスト容易性が大きく向上します。
フェイルクローズドの設計は、ランタイム内部でエラーが発生した場合にも自動的に「deny（拒否）」を返すという原則です。判定不能な状況で誤って許可してしまうリスクを低減できる点が、エンタープライズ用途で重要となります。
3種類の決定へ正規化されるベルディクトモデル
ACSでは、ポリシーが表明できる意思はallow・warn・deny・escalate・transformの5種類ですが、ランタイムはこれを最終的にallow・deny・transformの3種類の決定（decision）に正規化します。
単純な可否判定にとどまらず、現実の業務要件に即した柔軟な制御が可能な設計です。
ポリシー側の意思 | 正規化後の決定 | 意味 |
|---|---|---|
allow | allow | ホストがポリシーターゲットの処理を続行できる |
warn | allow（ | 警告を記録・表示したうえで続行できる |
deny | deny | ホストが当該アクションをブロックする |
escalate | deny（ | 承認バックエンドへ回付する「解除可能なdeny」として扱う |
transform | transform | 変換後のポリシーターゲットを、元の対象の代わりに適用する |
出典：Agent Control Specification 0.4.0-alpha.1 仕様書
特にtransformは、評価対象のポリシーターゲットを変換したうえで処理を続行できる点が特徴です。例えば出力をポリシーターゲットに設定している場合、機密情報を含むモデル出力をマスキングして利用者に返す、といった統制が可能になります。
escalateは人間レビュアーへの承認回付に使い、承認経路が未設定・失敗・不明な結果を返した場合はフェイルクローズドとしてdenyで扱われます。承認先やタイムアウト時のフォールバック動作もマニフェストで明示的に定義できます。
Rego・Cedarなど4種類のポリシータイプに対応
ポリシータイプとして、ACSは以下の4種類をサポートしています。
- Rego：Open Policy Agentで広く使われるポリシー言語。既存のクラウドネイティブな統制資産を流用しやすい
- Cedar：AWSが公開したポリシー言語。エンティティとアクションの関係を明示的に記述できる
- test：固定のベルディクトを返すテスト用ポリシー
- custom：ホストアダプタを介した独自実装の拡張ポイント
出典：Microsoft Agent Control Specification
すでに社内でRegoによる統制基盤を運用している組織であれば、ACSのマニフェストからRegoポリシーやバンドルを参照する構成を取りやすくなります。
新規にCedarで設計したい場合も、エンティティ・アクション・リソース・コンテキストの形でAIエージェントの動作を表現できるため、既存の権限管理モデルと整合させやすくなっています。
マルチフレームワーク・マルチ言語SDKによるポータビリティ
ACSは、エージェント開発フレームワークの選定に縛られないポータブルな統制層として位置づけられています。
AGTのドキュメント上、各フレームワークへの統合は以下のような形態で提供されています。
フレームワーク | 統合形態 |
|---|---|
Microsoft Agent Framework | Native Middleware |
Semantic Kernel | Native（.NET / Python） |
AutoGen | Adapter |
LangGraph / LangChain | Adapter |
CrewAI | Adapter |
OpenAI Agents SDK | Middleware |
Claude Code | Governance plugin package |
Google ADK | Adapter |
LlamaIndex | Middleware |
Haystack | Pipeline |
Mastra | Adapter |
Dify | Plugin |
Azure AI Foundry | Deployment Guide |
GitHub Copilot CLI | Governance installer |
出典：GitHub
ACS自体のSDKもPython、Node.js、.NET、Rustの4言語で提供されており、いずれの言語からも同一のYAMLマニフェストを読み込んで同一のベルディクトを得られます。フロントエンドはNode.js、ビジネスロジックは.NET、機械学習基盤はPythonといった混成環境であっても、統制ルールは一本化できる設計です。
MITライセンスとベンダー中立性
ACSはMITライセンスのもとで公開されており、商用利用を含めて自由に利用・改変できます。仕様とリファレンス実装はGitHubのmicrosoft/agent-governance-toolkitで開発が進められており、公式ドキュメントはAgent Control Specification 公式ドキュメントで公開されています。発表時の解説はMicrosoft公式の発表記事を参照できます。
Microsoftが公開・主導する仕様でありながら、特定のフレームワーク、ランタイム、ポリシーエンジンに依存しない設計を掲げており、他社フレームワークやコミュニティとの連携を前提にしている点が特徴です。
ACSの料金
このセクションでは、ACSの利用にあたって発生する費用について整理します。
結論として、ACSの仕様とリファレンス実装は、ACSを含むAgent Governance Toolkitの一部としてMITライセンスで公開されており、ACS自体に個別のライセンス費用は設定されていません。MITライセンスの条件に従うことで、商用プロジェクトを含めて利用・改変できます。
ただし、実際にAIエージェントを本番運用する際には、ACSとは別に以下の費用が発生する点に注意が必要です。
- LLMの推論コスト（Azure OpenAI Service、OpenAI API、Anthropic APIなど）
- エージェント実行基盤のコスト（Microsoft Foundry、Azure Container Apps、Azure Functionsなど）
- ポリシー評価をクラウド上で行う場合の計算リソース料金
- 人間レビュアーへの
escalate時に利用する承認ワークフロー基盤の費用
Microsoft Foundry上でAIエージェントを稼働させる場合は、Foundry側の利用料金（モデル推論、エージェント実行、ストレージなど）が別途発生します。
具体的な単価はMicrosoft Foundry料金ページおよびFoundry Agent Service料金ページをご確認ください。Foundry Control Planeを通じた一元的なガバナンスやフリート管理の機能については、Foundry Control Plane公式ドキュメントを参照してください。
上記の内容は2026年9月時点の情報です。最新情報はmicrosoft/agent-governance-toolkitおよびMicrosoft Foundry公式サイトをご覧ください。
ACSの利用手順
それでは実際に、ACSをAIエージェントに導入する基本的な手順をご説明します。本セクションではPython SDKを例に解説しますが、ACSはNode.js・.NET・Rust向けSDKも提供されており、同じマニフェストを用いた評価が可能です。ただし、言語ごとにAPI表記は異なります。
1. SDKのインストール
まず、開発環境にACSのSDKを導入します。0.4系のマニフェストを読み込める公開パッケージは、上流のACSランタイムagent-control-spec（プレリリース）です。Pythonの場合は次のようにインストールします。
pip install --pre agent-control-spec
Python環境にACS SDKをインストールしている画面
このパッケージには、依存関係としてagent-hooks-sdk（インターセプトコントラクトを提供するSDK）が自動的にインストールされます。ACSはこれをホスト側のフックポイント表現として利用しており、マニフェストで宣言した8つのインターベンションポイントごとに評価コンテキストを組み立てる仕組みです。Node.js・.NET・Rust向けの実装もリポジトリで提供されており、同じマニフェストとRegoポリシーを共通の資産として扱えます。
なお、Microsoft Agent Governance Toolkit（AGT）側では、AgentControl.from_path()やguard_run()、guard_tool()といった高レベル統合API群を持つPythonパッケージagent-control-specification（ハイフン区切り）が用意されています。本記事執筆時点で公開されているPyPI版は0.3.1b1系のため、0.4系マニフェストを扱う本記事のデモでは、上流のagent-control-specを利用します。AGT SDKの0.4系リリースが公開されれば、ガードアダプタを介した組み込みへ移行できます。
2. ポリシーマニフェストの作成
次に、エージェントに適用したい統制ルールをYAML形式のマニフェストとして記述します。最も基本的なマニフェストは以下のような構造になります。
agent_control_specification_version: 0.4.0-alpha.1
metadata:
name: email_agent
policies:
email_policy:
type: rego
bundle: ./policy
query: data.email_agent.verdict
intervention_points:
pre_tool_call:
policy_target: $.tool_call.args
policy_target_kind: tool_args
tool_name_from: $.tool_call.name
policy:
id: email_policy
tools:
send_email:
type: Tool
id: send_email
clearance: internal
ポリシーマニフェストを作成している画面
このマニフェストでは、メール送信エージェントに対して、ツール呼び出し前のpre_tool_callインターベンションポイントでRegoポリシーを適用する設定を行っています。実際の運用では、input、pre_model_call、pre_tool_call、outputなど複数のインターベンションポイントに、業務要件に応じたポリシーを割り当てていきます。
3. Regoポリシーの作成
マニフェストのbundle: ./policyが参照するRegoポリシーを、同じディレクトリ配下に配置します。今回は、社内ドメイン@company.example以外の宛先へメール送信ツールを使う場合だけ拒否する簡単なポリシーを例に示します。
package email_agent
import rego.v1
default verdict := {"decision": "allow"}
verdict := {
"decision": "deny",
"reason": "external_recipient_blocked",
"message": "外部宛先へのメール送信はブロックされました"
} if {
input.intervention_point == "pre_tool_call"
input.tool.name == "send_email"
not endswith(input.policy_target.value.to, "@company.example")
}
このRegoファイルをpolicy/email_agent.regoとして保存し、opaコマンドで構文チェックを行っておくと、次のステップでSDKからの評価がスムーズに通ります。
ACSは判定結果として、必須のdecisionと、任意のreason・messageなどを含む所定の構造を受け取るため、Rego側もこの形式に合わせてverdictを返す点がポイントです。
4. エージェントへの組み込み
作成したマニフェストとRegoポリシーを、ActivatedPolicyを通じて評価器として起動します。0.4系のPython SDKでは、マニフェストを一度アクティベートしてから、各インターベンションポイントに対して評価コンテキストを渡す形になります。
from agent_control_spec import ActivatedPolicy
from agent_hooks import AgentContextBuilder
policy = ActivatedPolicy("manifest.yaml")
context = AgentContextBuilder(
agent_id="email-agent",
framework="demo",
session_id="s1",
).pre_tool_call(
call_id="t1",
name="send_email",
args={"to": "user@external.example"},
)
verdict = policy.evaluate("pre_tool_call", context)
print(f"decision={verdict.decision.value}")
print(f"reason={verdict.reason}")
if verdict.decision.value == "deny":
print("blocked: ACS policy denied this tool call")
Pythonからポリシー評価を実行している画面
ActivatedPolicyはマニフェストのRegoモジュールとデータを起動時に一括で読み込み・コンパイルします。各evaluate呼び出しはI/OとRegoコンパイルを伴わないため、判定処理をホットパスに置いても性能を確保しやすい設計です。
返されたverdictは、決定（allow・deny・transform）に加えて、reason、warnings、approvalなどの付随情報を持ちます。ホスト側はこれに応じて、続行・拒否・承認回付・変換などの処理を実装します。
5. 承認フローとアノテーターの設定
人間レビュアーへのescalateを利用する場合は、マニフェストにapprovalセクションを追加し、デフォルトの解決器、タイムアウト時の動作、承認疲労を防ぐためのスロットル設定を定義できます。
また、入力テキストの分類や悪意検出のために外部の分類器やLLMを呼び出したい場合は、annotatorsセクションで宣言したうえで、各インターベンションポイントから参照する形で利用できます。
6. テストと監視
ACSのポリシー判定は決定論的なため、ユニットテストでマニフェストの期待動作を検証することが可能です。本番環境ではテレメトリ機能を有効化し、判定結果を監査やインシデント分析に活用できます。
Microsoft Foundryと組み合わせる場合は、FoundryのObservability機能やAgent Monitoring Dashboard、Foundry Control Planeを通じて、エージェントの運用状況、評価結果、コンプライアンス姿勢などを可視化できます。
上記の流れで、ACSをAIエージェントの実行時統制レイヤーとして組み込む基本的な手順を理解できます。実運用では、ホスト側のenforcementや監査ログ設計もあわせて検討する必要があります。
ACSの使い方のコツ
ここでは、ACSの効果を最大化するための実務的なポイントをご説明します。
マニフェストを継承構造で管理する
ACSのマニフェストはextendsを用いて、親マニフェストを参照し、複数のマニフェストを加算的にマージできます。社内共通の基本ルール（個人情報の取り扱い、機密情報の送信禁止など）を親マニフェストとして整備し、各エージェント固有の設定を子マニフェストで追加する構成にすると、統制の一貫性とメンテナンス性を高めやすくなります。
ガバナンス担当部門が共通マニフェストを管理し、開発チームが業務要件に応じてエージェント固有のマニフェストを追加する役割分担にすると、全社共通ルールの再利用や変更管理を行いやすくなります。
ツールclearanceで情報フローを設計する
ACSのマニフェストでは、ツールごとにclearance（受け入れ可能な最大機密性レベル）とセキュリティラベルを宣言できます。社外APIを呼び出すツールには低めのclearanceを設定し、ホスト側でデータの来歴とラベルを追跡したうえで、機密ラベルが付与された情報を低い機密レベルのシンクに渡さないポリシーを評価する、といった「no write down（高機密の情報を低機密のシンクに書き出さない）」原則に沿った設計が可能です。
ユーザー権限、ツールの機密区分、データラベルを分けて設計しておくことで、ツール追加時やポリシー変更時にも、どのシンクにどの情報を渡せるかを確認しやすくなります。
ASSERTとRubricを併用して継続的に評価する
MicrosoftはBuild 2026で、ACSとあわせて、オープンソースの評価フレームワーク「ASSERT」、Microsoft Foundryの評価機能である「Rubric evaluator」、エージェント改善支援機能の「Agent Optimizer」を発表しています。ASSERTは自然言語で書かれた行動要件を実行可能な評価へ変換するための仕組みであり、Rubric evaluatorはエージェントの用途に応じた評価基準を生成し、品質を測定するためのFoundry上の評価機能です。
書かれたポリシー要件をASSERTで評価シナリオに落とし込み、ACSで実行時制御として適用し、FoundryのRubric evaluatorやAgent Optimizerで評価・改善につなげることで、ガバナンスを運用上のフィードバックサイクルへ発展させやすくなります。
ACSの活用シーン
このセクションでは、ACSがどのような業務課題の解決に役立つのか、具体的な活用シーンをご説明します。
金融業界における承認フロー組み込み
金融機関のように高い監査性と承認統制が求められる領域では、AIエージェントが顧客情報や取引関連情報に触れる場合、「人間の確認を経ずに重要操作を実行しない」「一定条件を超える操作は承認に回す」といった統制設計が重要になります。
ACSでは、Rego側で表明したescalate意思がランタイムによってapprovalブロック付きの解除可能なdenyとして正規化され、ホスト側の承認バックエンドと組み合わせることで、ツール呼び出し前に承認ワークフローへ回付する設計が可能です。承認経路が未設定、失敗、または不明な結果を返した場合はfail closedで最終的なdenyとして扱われます。また、承認はenforced_identityに紐づけられるため、ホスト側の監査ログと組み合わせることで、どのアクションに対する承認だったかを追跡しやすくなります。
製造業・医療業界における監査ログの確保
製造業の品質管理や医療業界の診療支援といった領域では、AIエージェントの判断過程や操作履歴を後から確認できるようにしておくことが、品質保証、説明責任、監査対応の観点で重要になります。
ACSはテレメトリ機能を通じて、判定結果・理由コード・適用したポリシーIDなどの構造化されたログを安定したスキーマで出力します。ACSのテレメトリは、ポリシーターゲット値、ツール引数・結果、アノテーション値、モデルメッセージ、シークレット、個人情報などの生データを出力しない設計です。そのため、監査用ログとプライバシー保護を両立しやすくなっています。
マルチフレームワーク混在環境でのガバナンス統一
エンタープライズの開発現場では、業務領域ごとに異なるエージェントフレームワークを採用しているケースが少なくありません。営業支援、社内ナレッジ検索、顧客対応チャットボットなどで異なるフレームワークを採用している場合、統制ルールを個別実装すると、開発・運用・監査の負担が増えやすくなります。
ACSはポータブルなマニフェストを通じて、複数フレームワーク間で統制ルールを再利用しやすくします。これにより、ガバナンス部門は共通のポリシー記述を軸に統制設計を進めやすくなります。
ACSの注意点
ここでは、本番環境への導入を成功させるために事前に把握しておくべき、ACSの注意点をご説明します。
アルファ版に伴う仕様変更のリスク
2026年9月時点でACSの仕様文書は0.4.0-alpha.1のDraftであり、リファレンス実装のRustクレートも0.4.0-alpha.3と、いずれもアルファ段階に位置づけられています。プレリリースタグが付いている間は、マニフェスト形式やSDKのインターフェース、ベルディクト正規化のルールに破壊的変更が入る可能性があります。
本番システムに組み込む際は、利用しているバージョンを明示的に固定し、GitHubリポジトリのリリースノートを継続的にウォッチする運用が必要です。仕様の更新が判定結果に影響する変更でないか、リリース時に必ず検証することが求められます。
制御層と実行層の役割分担を明確にする
ACSはあくまでポリシー判定の制御層であり、エージェントのオーケストレーション、ツール選択、メモリ管理を肩代わりするものではありません。エージェントループ自体はLangChainやAutoGenといった既存フレームワーク、もしくは自社実装のランタイムが担います。
そのため、ACSを導入したからといってエージェントの振る舞いが自動的に安全になるわけではなく、「どのインターベンションポイントに、どのような統制を、どの粒度で配置するか」という設計が不可欠です。設計の初期段階で、開発チームと統制部門が役割分担を明確にしておくことが導入成功の鍵となります。
ポリシー設計とテストへの投資
ACSの強みは、決定論的なポリシー判定によって統制ルールがテスト可能になる点にあります。一方で、その強みを引き出すためには、想定されるシナリオに対する期待動作を網羅したテストケースを整備する必要があります。
特に、承認回付を引き起こすescalate意思や、対象を書き換えるtransformベルディクトを多用する場合、誤った設定が承認フローの停滞や情報マスキングの過不足を招くリスクがあります。ASSERTなど評価フレームワークと組み合わせ、ポリシー変更時の回帰テストを継続的に回す体制を整えることが望まれます。
まとめ
本記事では、Agent Control Specification（ACS）の概要や、Agent Governance Toolkitとの関係、主な特徴、利用手順、活用シーン、注意点までを解説しました。ACSは、フレームワーク横断でAIエージェントの実行時統制を標準化するための、オープンな仕様およびリファレンス実装です。特定のフレームワーク、ランタイム、ベンダーに依存しにくい設計が特徴です。
8つのインターベンションポイントと3種類の決定（allow・deny・transform）へ正規化されるベルディクトモデル、RegoやCedarといった既存ポリシー言語への対応、Python・Node.js・.NET・Rustの多言語SDKによって、エンタープライズのマルチフレームワーク環境におけるガバナンス課題に対する有力な解として位置づけられます。一方で、現時点ではDraft／アルファ段階であり、運用設計や継続的なテストには十分な配慮が必要です。
東京エレクトロンデバイスでは、ACSを活用したAIエージェントのガバナンス基盤構築を総合的にサポートしています。Microsoft Foundryと組み合わせたエージェントフリートの統制設計、既存のLangChainやSemantic Kernel基盤へのACS導入支援、ASSERTやRubricを用いた評価ループの構築など、AIエージェントの本番運用に関するご相談をお受けしています。ご興味のある方はこちらからお問い合わせください。
