Agent Control Specification（ACS）とは？仕組み・関連標準・活用方法を解説

Agent Control Specification（ACS）は、AIエージェントが「何をしてよいか」をランタイムで宣言的に制御するためのオープン仕様です。2026年5月27日にサンフランシスコのAI Agent Security Summitで発表され、6月のMicrosoft Build 2026で「オープントラストスタック」の中核として再アピールされました。
業界横断のミドルウェア型ガバナンス層として位置づけられ、Linux Foundation配下のMCPやA2Aがそれぞれ「ツール接続」「エージェント間通信」を標準化したのに対し、ACSは「実行時の許可・拒否・人手承認・証跡記録」を統一の宣言形式で扱います。

本記事では、ACSの定義と3層アーキテクチャ、8つのインターセプションポイント、ポリシーYAMLの記述方法、対応フレームワークとクイックスタート、関連標準との位置づけ、EU AI Act・NIST AI RMFなどへの規制対応、料金・コスト構造、そして導入判断で詰まる論点までを、2026年6月時点の最新情報で体系的に解説します。
すでにLangChainやFoundryでエージェントを動かしている組織から、これから本番運用を設計する企業まで、自社の段階に合わせて読み解ける構成です。

Agent Control Specification（ACS）とは？AIエージェントのランタイム制御を標準化する新仕様

Agent Control Specification（ACS／エージェント・コントロール・スペシフィケーション）は、AIエージェントが「何をしてよいか・何をしてはいけないか・いつ人間の承認を取るか・どんな証跡を残すか」をランタイムで宣言的に定義するためのオープン標準です。

正式な発表は2026年5月27日、サンフランシスコで開かれたAI Agent Security Summitの場で公開されました。Microsoftは自社AGTに乗せる形で「Agent Control Specification」を発表し、ベンダー中立を掲げる業界連合はAgent Control Standard（agentcontrolstandard.ai）としてオープン公開標準を公開しています。両者は同じ「ACS」と略されますが、バージョン体系が別建てで並走している2系統と理解するのが正確です（詳細は本記事「ACSの料金・コスト構造とライセンス」で整理）。

ACSが他のエージェント関連標準と根本的に違うのは、モデルやフレームワークの内側ではなく、エージェントの実行時パイプラインの「外側」にポリシーを置く点です。

Anthropic発で現在はLinux Foundation AAIF配下となったMCP（Model Context Protocol）はツール接続のプロトコル、Google発のA2A（Agent2Agent）はLinux Foundationがホストするエージェント間通信のプロトコルですが、ACSは「実行中のエージェントの行為を、フレームワークから切り離して制御するレイヤー」を標準化しました。

つまり「ポリシーは書面で持っているが、ランタイムで効かせる仕組みが標準化されていない」という、エージェント運用の現場で長く残っていた空白を埋めるための仕様です。

Microsoft公式が発表したAgent Control Specification（出典：Microsoft commandline blog）

ACSの3層アーキテクチャ

ACSは「すべてを1か所で抱える」設計ではなく、責務を3階層に分けたアーキテクチャを提案しています。それぞれが別の担い手を想定している点が、従来のガードレールツールと違うところです。

以下の表で、ACSが想定する3層を整理しました。

注目したいのは、Tier 1とTier 3が分離されている点です。フレームワーク側は「どこで止めるか」を提供すれば良く、企業側は「何を止めるか」を独自に書ける構造になっています。

この分離設計のおかげで、企業がフレームワークを乗り換えてもポリシーがそのまま動き、フレームワークが進化してもポリシー側を書き換えずに済みます。

ACSという名前と立ち位置

「ACS」という略称は、Microsoftの公式ブログでは「Agent Control Specification」、業界連合の公式サイトでは「Agent Control Standard」と表記されます。同じ「ACS」と呼ばれているものの、厳密にはMicrosoft AGT内蔵のAgent Control Specification実装と、業界連合（agentcontrolstandard.ai）が公開するAgent Control Standardという公開標準の2系統が並走しており、バージョン体系も別建てです。

業界連合側は「No single company owns this standard」をトップページで明言しており、特定企業の製品に縛られないベンダー中立設計です。実装の中心であるMicrosoftのAgent Governance Toolkitとは別に、業界連合の仕様本体はAgent-Control-Standard/ACSで公開されており、貢献者として複数組織のエンジニアが名を連ねています。

つまりACSは「Microsoft専用のガバナンス機構」ではなく、業界連合のオープン標準とMicrosoft実装の2系統が並走しながら相互に影響しあって育っている、と捉えるのが現実的です。

Microsoft Build 2026のステージでACSのパートナー・カスタマーを発表する責任あるAI担当CPO Sarah Bird氏（出典：Arize AI Blog）

既存のエージェント制御手段とその限界

ACSが登場する前から、AIエージェントの動作を制御する手段は存在していました。ただ、これらは断片化されていて本番運用での再利用・監査が難しく、規制対応の根拠としても使いにくいという現実があります。

このセクションでは、エージェントの本番運用で実際に起きている「ガードレール散在問題」を整理し、なぜランタイム側に標準が必要だったのかを掘り下げます。

既存ガードレール手段の3つの限界

現場で使われているガードレール手段は、大きく3つに分類できます。それぞれに以下のような限界が指摘されています。

Microsoftが整理した既存ガードレールの3手段とそれぞれの限界。ガードレールはAgent runtimeに対して断片的にしか効かず、「No standard contract / no shared input / no portable verdicts」状態になっている（出典：Microsoft commandline blog）

共通する問題は、「ポリシーの記述場所がフレームワークごとに違い、責任分界も曖昧」という点です。セキュリティチームが書きたい統一ポリシーを、開発チームが各エージェントのコードに散らして実装する形になり、結果として誰も全体像を把握できなくなります。

Microsoftの公式ブログでも「prompts are not controls（プロンプトはコントロールではない）」と明確に表現されており、システムプロンプト依存のガードレールはランタイム制御の代替にはならない、という業界共通の認識が広がりつつあります。

ランタイム制御がエンタープライズで求められる理由

エンタープライズの観点では、ガバナンスの根拠を「コードの中に書かれた if 文」に置くわけにはいきません。次の4つは、企業がACSのような標準を必要としている直接的な背景です。

• 規制対応
  EU AI Actは高リスクAIシステムに対して人間監督（Art.14）・ログ保持（Art.12）を要求し、NIST AI RMFも継続監視と緊急停止を求めている。
  これらに対応する仕組みを各社が独自実装すると、監査時の説明コストが非現実的なほど大きくなる。
  
  

• 責任分界
  セキュリティチームがポリシーを書き、開発チームが運用する、という分業のためには「ポリシー」と「アプリケーション」を分離できる仕組みが必要。
  コードに埋め込む方式では、セキュリティ側が変更するたびに開発側のリリースが必要になる。
  
  

• 移植性
  LangChainで実装したエージェントをCrewAIに乗せ換える、ということが現実に起きる。
  そのたびに同じポリシーを書き直すのは非効率で、漏れも生じる。
  
  

• 可観測性
  監査・インシデント対応のためには「どのエージェントが・いつ・何を・なぜ拒否したか」を統一フォーマットで残す必要がある。
  プロンプト依存のガードレールでは、この記録すら標準化されない。

これらは「あれば便利」ではなく、本番運用するなら避けて通れない要件です。ACSはまさに、ここを標準化することに価値の中心を置いた仕様です。

AI総合研究所の支援現場でも、PoC段階ではプロンプト依存のガードレールで足りていた組織が、本番化・部門横展開のフェーズで「責任分界とログ標準」が課題として浮上するケースが繰り返し見られます。

ACSの仕組み——8つのインターセプションポイントと4段階判定

ACSの中核は、エージェントの実行フローのどこで・どんな判定を行うかを規定した「インターセプションポイント」と「判定」の組み合わせです。仕様としては8つのインターセプションポイントと、4段階＋追加効果の判定が定義されています。

このセクションでは、フックの全体像と判定ロジック、そして媒体ごとに数が違って見える理由を整理します。

8つのインターセプションポイント

ACSは、エージェントの起動からシャットダウンまでの実行サイクルを8つの介入点に分割しています。具体的な定義は以下のとおりです。

各ポイントには標準化された入力（intervention_point名、policy_target、ホストの状態スナップショット、分類器・LLMジャッジの注釈、tool情報）が渡され、ポリシー側がそれを見て判定を返す、という構造です。

そして、これら8つの介入点から呼び出されたあとACSランタイムの内部で実行される処理も、別軸で8ステップに分けて定義されています。

8つのインターセプションポイントから呼ばれたあと、ACSランタイムが内部で実行する8ステップ。Host calls ACS → policy入力構築 → 対象解決 → 分類器・LLMジャッジ実行 → policy本体呼び出し → 判定の正規化 → 判定返却 → ホスト側でのEnforcement、を「One call, eight steps, fail-closed on any error」で回す（出典：Microsoft commandline blog）

つまり「仕様としての8つの介入点（どこで止めるか）」と「ランタイム内部の8ステップ処理（どう判定するか）」は別の軸で、両方が"8つ"という偶然の重なり方をしているだけです。記事や解説を読むときに混同しやすいポイントなので、軸を分けて押さえておくと整理がしやすくなります。

TechCrunchの記事（2026年6月2日）では「入力前・ツール呼び出し前・ツール結果受領後・最終応答前」の4チェックポイントとして紹介されており、Microsoft Foundry blogでは「入力／LLM／状態／ツール実行／出力」の5段階として説明されています。

これは段階の数の違いではなく、媒体ごとに簡略化の粒度が違うだけで、仕様そのものは8つのインターセプションポイントを採用しています。

判定の4段階と効果

ポリシー評価の結果として返される判定は、以下の4段階に標準化されています。これに加えてredaction（編集）という効果が組み合わさります。

• allow（許可）
  ポリシーに違反しないと判断され、そのままアクションを通す
  
  

• warn（警告）
  アクションは通すが、警告ログを残す。後続のレビュー対象に。
  
  

• deny（拒否）
  アクション自体を実行させない。エージェントには拒否理由が返される。
  
  

• escalate（エスカレーション）
  人間の承認を求めるフローに進む。CISO・管理者・部門責任者など、組織ごとの承認経路を呼び出す。
  
  

• redaction（編集効果）
  判定とは別に、入力・出力テキストから機密情報を自動マスキングして渡す副作用。allow と組み合わせることが多い。

4段階に集約されていることで、各組織のセキュリティチームは「自社のポリシーをどう設計するか」を考えるときに、共通の語彙で議論できます。「これはdenyすべきか、warnで様子を見るか」というレベルから、組織横断で合意を取りやすくなる点が、標準化の実務的な価値です。

Rust製のfail-closedランタイム

ACSの判定ロジックを動かすコアは、Rustで実装されたランタイムです。MicrosoftのAgent Governance Toolkitでは、ACSを「stateless, deterministic, fail-closed policy decision runtime」と説明しています。

それぞれの設計選択には意図があります。

• stateless（ステートレス）
  判定ごとに状態を持たない設計。並列実行・スケーラビリティ・テスト容易性のために選ばれている
  
  

• deterministic（決定論的）
  同じ入力には同じ判定を返す。確率的に揺らぐシステムプロンプトとは対照的に、監査可能性を担保するための条件
  
  

• fail-closed（フェイルクローズド）
  判定エンジン自体に問題が起きた場合、デフォルトで拒否側に倒す。「障害時に何が起きるか分からないが通す」設計ではなく、「迷ったら止める」設計

これらは「セキュリティ機構として最低限の自衛」を盛り込んだ設計で、規制対応の説明ロジックとしても扱いやすい構造になっています。

ACSポリシーの記述方法（YAML・Rego・分類器）

ACSの実用面で最も注目されているのは、ポリシーを宣言的にYAMLで書ける点です。Regoでより高度な条件を記述したり、独自の分類器・LLMジャッジを差し込んだりすることもできますが、入り口はYAMLで十分に成立します。

このセクションでは、最小のYAML例から少し複雑な構成までを段階的に紹介します。

最小のポリシーYAML

最も単純な形では、許可・拒否のルールを並べるだけでポリシーが成立します。Agent Governance Toolkit公式のフォーマットに沿った例が以下です。

apiVersion: governance.toolkit/v1
name: production-policy
default_action: allow
rules:
  - name: block-destructive
    condition: "action.type in ['drop','delete','truncate']"
    action: deny

このポリシーが何をしているかというと、デフォルトは許可だが「drop」「delete」「truncate」を含むアクションだけは無条件で拒否する、という宣言です。

たった数行で「データ破壊系の操作はエージェントに渡さない」というルールが、フレームワーク非依存・監査可能な形で書ける、というのがACSのコアバリューです。

deny-by-defaultの社内CRMポリシー例

エンタープライズでは「明示的に許可したものだけ通す」設計（deny-by-default）が安全側の選択になります。dev.toの実装PoC記事で示された社内CRMエージェント向けの例が、その典型です。

allow: repo.read
allow: test.run
allow: file.write under workspace path
deny: shell.rm
deny: git.push
deny: secrets.read
deny: deploy.production

このポリシーで明示的に許可しているのは、リポジトリの読み取り、テスト実行、ワークスペース内へのファイル書き込みのみです。

それ以外（シェルからの削除、git push、シークレット読み取り、本番デプロイ）はすべて拒否しています。「危険操作を網羅的に列挙する」のではなく、「やっていい操作だけを並べる」発想で書ける点が、運用設計を大きく簡略化します。

Node.js SDKを使った実装例

ACSはYAML設定だけでなく、SDKからプログラム的にポリシーを構築することもできます。Node.js（@microsoft/agent-governance-sdk）での実装例は以下のようになります。

const {
  AgentMeshClient,
  GenericFrameworkAdapter,
} = require("@microsoft/agent-governance-sdk");

async function main() {
  const client = AgentMeshClient.create("effloow-sandbox-agent", {
    policyRules: [
      { action: "framework.tool_call.search_docs", effect: "allow" },
      { action: "framework.tool_call.summarize", effect: "allow" },
      { action: "framework.tool_call.shell.rm", effect: "deny" },
      { action: "*", effect: "deny" },
    ],
  });

  const adapter = new GenericFrameworkAdapter(client);

  const allowed = await adapter.run(
    {
      name: "search_docs",
      kind: "tool_call",
      input: { query: "ACS policy checkpoints" },
    },
    async () => ({ items: ["input", "tool", "output"] }),
  );
}

このコードでは、search_docs と summarize のツール呼び出しは許可し、shell.rm と「それ以外すべて」を拒否しています。

このアプローチの利点は複数あります。第一に、ポリシーをコードの近くに置けるためテスト時に再利用しやすくなります。第二に、GenericFrameworkAdapter を使うことで、特定のエージェントフレームワークに依存せずポリシー判定を組み込めます。

Regoとカスタム分類器の差し込み

より複雑な条件分岐や、組織独自のリスクスコアリングを使いたい場合は、汎用ポリシーエンジンのRego（OPA：Open Policy Agent）で記述したロジックをACSのhookから呼び出す構成が取れます。

加えて、分類器（PII検出・プロンプト注入検知）やLLMジャッジ（特定の業務文脈で「これは怪しい」と判定するモデル）も、判定の補助入力として注入できます。

つまりACSは「ポリシーをYAMLだけに閉じ込める」のではなく、YAMLで書ける範囲はYAMLに、複雑な業務固有ロジックは外部エンジンに、不確実性の高い判断は分類器・LLMジャッジに、と層を分けて扱える設計になっています。

これは、これまで個別ツールで実装されていた様々なガードレール手段を「ACSのhookに統合する」という観点でも整理しやすく、移行設計のしやすさにつながります。

ACS対応フレームワークとクイックスタート

ACSが特徴的なのは、Microsoft主導でありながら特定のフレームワークに依存しないように設計されている点です。実装にあたるAgent Governance Toolkit（AGT）は、主要なエージェント開発フレームワークに対応するSDK・adapterを公開済みです。

対応SDK・フレームワーク（10種類超）

Microsoft commandlineの公式記事とTechCrunch記事で言及されている対応フレームワーク・SDKは以下のとおりです。

このカバレッジの広さが、ACSが「Microsoft専用ガバナンス」ではなく業界標準として広がっていく根拠になっています。

OpenAIとAnthropicのAgents SDKに対応している点は特に重要で、現時点で主要な3社（Microsoft・OpenAI・Anthropic）のエージェントフレームワークすべてで同じポリシーが効かせられる、という意味になります。

最小のPythonクイックスタート

Pythonでの導入は、pipインストールから2行で済みます。Agent Governance Toolkit公式のクイックスタートに沿った例が以下です。

pip install agent-governance-toolkit[full]

導入後、既存のツール関数にポリシーを当てるのは1〜2行の追加だけです。

from agentmesh.governance import govern

safe_tool = govern(my_tool, policy="policy.yaml")

これだけで、safe_tool を呼ぶたびに policy.yaml で定義したインターセプションポイント・判定が走るようになります。

エージェント本体のコードはほとんど変更せず、ガバナンス層だけを後付けで挟める設計です。既存のLangChain・AutoGen等で動かしているエージェントに、最小の侵襲でポリシー層を導入できます。

実装で詰まりやすい4つのポイント

導入を進めるなかで、よく相談を受ける詰まりポイントが4つあります。先回りで押さえておくと、PoC段階の手戻りが減ります。

• システムプロンプトを信用しすぎる
  「プロンプトに『○○しないで』と書いたから大丈夫」と思いがちだが、ACSのコア設計思想は「ランタイム制御はコードで実装する」。
  プロンプトはあくまで補助で、強制力のあるガードはACSのhookに寄せる。
  
  

• ログを過剰に取りすぎる
  判定の根拠を残そうとして入出力の全文をログに書くと、機密情報がそのまま保存されて漏洩リスクになる。
  ポリシー判定と監査メタデータに絞り、本文はredaction後に保存する設計が現実的。
  
  

• ツールを増やしてから整備しようとする
  ツール数が増えてから「全部の権限を整理」しようとすると、漏れが必ず出る。
  最初から deny: * を末尾に置き、明示的に許可したものだけ通す deny-by-default で組む。
  
  

• フレームワーク固有のライフサイクルを甘く見る
  LangChainとAutoGen、CrewAIで「ツール呼び出し前」が指すイベントの粒度が違うことがある。
  各adapterのドキュメントで、どのライフサイクルイベントがACSのどのインターセプションポイントに対応するかを必ず検証する。

これらは技術問題というより運用設計の問題で、PoC段階で押さえておくと本番化フェーズで詰まりません。

段階的な導入ロードマップ

エンタープライズでACSを採用する場合、フェーズを分けて進めるのが現実的です。AI総合研究所が支援している導入観察として、以下の3段階で進める組織が多くなっています。

「いきなりdeny運用に切り替える」のではなく、warnで挙動を観察してからdenyに昇格させる進め方は、業務影響を最小化する定石です。

ACSとMCP・A2A・Agent Skillsの位置づけ

ACSが「ガードレール標準化」を狙うのに対し、すでに業界には複数のエージェント関連標準が存在します。重要なのは、ACSがこれらを置き換えるのではなく役割の違うレイヤーとして補完関係にある点です。

このセクションでは、主要な4標準とACSの棲み分けを整理します。

4つの標準とACSの棲み分け

以下の表で、AIエージェント関連の主要4標準とACSの役割を整理しました。エージェントスタックを設計する際の地図として使えます。

注目すべきは、ACSが他の4つを否定する立場ではない点です。むしろ「他標準で接続したり拡張したりするエージェントが、実行時に何をやってよいかを宣言できる」のがACSの貢献領域です。

エージェントが将来的にMCP経由でDBに接続し、A2A経由で他エージェントを呼び出し、Skillsで能力を取り込み、Oracle Open Agent Specで自己記述する、というスタックを想定すると、ACSはそのすべての「上」で挙動を統制する位置に立ちます。

Linux Foundation AAIFとACSの距離感

2025年12月にLinux Foundation配下にAgentic AI Foundation（AAIF）が設立されました。共同設立はAnthropic・Block・OpenAIの3社で、AWS・Google・Microsoft・Bloomberg・CloudflareなどがPlatinum member／supportとして参加する構成です。MCPはAAIF配下の標準として整理された一方、A2AはLinux Foundationがホストする独立のA2A Protocol projectとして運営されており、配下組織は別建てになっています。

一方、ACSは2026年6月時点ではMicrosoftと業界連合（agentcontrolstandard.ai）の主導で、Linux Foundationには移管されていません。位置づけとしては「同じスタックを補完する別系統の標準」として並走している段階です。

業界連合のもとで仕様が公開され、複数組織のエンジニアが貢献者として参加している事実は、特定企業の独占的な仕様ではないことを示しています。標準化先（Linux Foundation／W3Cなど）については、現時点で公式に確認できる方針はなく、今後の業界調整次第と見るのが妥当です。

OPA Rego・Cedarとの関係

「汎用ポリシーエンジン」としてはすでにOpen Policy Agent（OPA）のRegoや、AWSのCedarが広く使われています。これらとACSは競合ではなく、ACSの内部で利用される選択肢の一つです。

具体的には、ACSのインターセプションポイントから呼ばれる判定ロジックとして、Regoで書いたポリシーをそのまま使えます。「Regoは知っているがエージェント特有のhookは知らない」という組織は、既存のRego資産を流用しながらACS導入を進められます。

つまりACSは「ポリシー言語そのもの」を作るのではなく、「エージェント特有のhookと判定インターフェース」を標準化することで、既存のポリシーエンジン資産を活かしながら統制を効かせる、という設計です。

ACSと規制対応——EU AI Act・NIST・Singaporeフレームワーク

ACSが今のタイミングで業界提案として出てきた背景には、AIエージェントに対する各国規制の高まりがあります。エンタープライズでACSを評価する際、規制対応の根拠としてどう機能するかは押さえておくべき論点です。

このセクションでは、主要な規制とACSの対応関係をマップ形式で整理します。

規制ごとの要求と対応するACSの仕組み

以下の表で、各規制が求める要件と、ACSのどの機能がその要件に対応するかを整理しました。

注目すべきは、これまで「個別企業のセキュリティ製品」レベルで扱われてきたエージェントガバナンスが、各国規制当局・標準化機関・セキュリティコミュニティのテーブルに上がり始めているという事実です。

欧州委員会のEU AI Act実装ページによれば、適用スケジュールは段階的に進んでおり、汎用AIモデル（GPAI）義務は2025年8月2日から適用済み、AI Act全体の一般適用は2026年8月2日、高リスクAIシステムの主要義務（Art.8〜22等）は2027年12月2日、製品組込み系の高リスクAIは2028年8月2日から適用となります。ACS自体は規制を充足する「直接の解」ではなく、人間監督・ログ・介入をランタイムで実装するための技術的手段として位置づけて評価する必要があります。

Open Trust Stack（ACS×ASSERT×OpenInference）

ACSは単独で規制対応の全てを担うわけではなく、Microsoftが提唱する「Open Trust Stack」の中で他の標準と組み合わさって機能します。

ASSERTで評価→ACSでインターセプションポイント設定→ASSERTで再評価、の3ステップで policy to measurement, measurement to targeted controls, controls to validated improvement のジャーニーを実現する（出典：Microsoft Foundry Blog）

Microsoftが提唱する「Policy-to-Production Trust Loop」は、ASSERTとACSの2標準だけで回る3ステップとして定義されています。

1. Define & evaluate（ASSERT）——ポリシー仕様を評価に変換し、欠陥率を測定
2. Set intervention points（ACS）——測定で見つかった欠陥に対し、ACSのインターセプションポイントで制御を配置
3. Re-evaluate & validate（ASSERT）——制御適用後にASSERTで再評価し、改善幅を確認

このループを支える形でOpenInferenceが本番運用の観測を担います。Arize AIのブログによれば、ACSの全判定はOpenInferenceスパンとして出力されるため、Phoenix／Arize AXなどの既存observability基盤でそのまま消費できます。

Identify risk→Evaluate→Apply Control→Observe & Improveを回し続けるエージェントの信頼ライフサイクル。ACSは「Apply Control」のレイヤーを担当する（出典：Microsoft Foundry Blog）

これは、エージェント運用に必要な「評価→制御→監視」の3工程が、ベンダー間で共通のトレース・ポリシーコントラクトに乗ることを意味します。

業界横断のパートナー組織

ACSは標準としての地位を高めるため、Microsoft公式が「Customers（導入顧客）」と「Partners（パートナー）」の2区分で参加組織を公表しています。

Microsoftが公式に発表したACSの「Customers」2社と「Partners」9社のロゴ一覧（出典：Microsoft Foundry Blog）

この一覧はMicrosoftが2026年6月のBuild 2026で公式に提示したもので、セキュリティ・ガバナンス・Observability・エージェントフレームワークなど、エージェント本番運用に必要な周辺領域をカバーする企業群が並んでいます。

なお、Anthropic・Google・OpenAIといった同業のフロンティアLLM企業による明示的なACS支援表明は、現時点では公式に確認されていません。ただし対応SDKリストに各社のAgents SDKが含まれていることから、実装レベルでは相互運用が進んでいる、と整理するのが正確です。

【関連記事】
Project Solaraとは？Microsoftが「アプリからエージェントへ」のために作った新プラットフォーム

ACSの料金・コスト構造とライセンス

ACSは仕様・参照実装ともにオープンソースで公開されており、仕様自体の利用に直接的な料金は発生しません。ただし、本番運用ではAGT・Foundry・分類器・LLMジャッジなど周辺コンポーネントのコストが積み上がるため、構成要素ごとに整理しておく必要があります。

仕様本体と参照実装のライセンス

ACS仕様と主要実装のライセンスは以下のとおりです。

整理するうえで重要なのは、**Agent Control Standard（業界連合側のオープン公開標準）**と、Microsoft AGTに同梱されているAgent Control Specification実装が別物として並走している点です。前者はベンダー中立を掲げており「No single company owns」と公式に明言しています。後者はMicrosoftが自社AGTに乗せて使う実装で、現時点ではバージョンも別建てです。

AGT v4.0.0自体もPyPIではPublic Preview（Development Status: 4 - Beta）として公開されている段階です。GA前のため、本番運用では「API変更が入る可能性を前提に設計する」必要があります。

周辺コンポーネントのコスト

オープンソースでも、本番運用では以下のコストが発生する可能性があります。

• 分類器・LLMジャッジの呼び出しコスト
  PII検出・プロンプト注入検知などをLLMジャッジで実装する場合、各判定ごとにLLM API料金が発生する。
  高頻度なツール呼び出しを抱えるエージェントでは、ガバナンス側のLLMコストが本体LLMコストの数十%に達することもある。
  
  

• observability基盤の費用
  OpenInferenceスパンを消費するPhoenix/Arize AX等を商用利用する場合、別途料金が発生する。
  オープンソースのPhoenixだけで運用すれば直接料金は発生しないが、保守工数が乗る。
  
  

• Microsoft Foundry利用時のFoundry料金
  ACSをMicrosoft Foundry内で動かす構成にすると、Foundry側の利用料が発生する。
  ガイド付きガードレール設定・Rubric評価器・Runtime DLP（Purview統合）などのプレビュー以上の機能を併用する場合は、各機能の料金体系を確認する必要がある。
  
  

• 人手承認フローの運用コスト
  escalate判定で人間の承認を求める設計にした場合、承認担当者の工数が発生する。
  PoC段階では「とりあえずescalate」にしがちだが、本番運用ではエスカレーション基準を絞り込むことで運用コストを抑える設計が必要。

つまり「ACS自体は無料だが、運用全体ではゼロコストではない」という前提で予算化するのが現実的です。

コスト最適化の論点

導入コストを抑えながらガバナンス効果を出すために、以下の論点を押さえておく価値があります。

• 分類器とLLMジャッジを併用する判断基準
  高速・低コストな分類器でフィルタし、確信度が低いケースだけLLMジャッジに回す2段構成にすると、LLMジャッジ呼び出し回数を大幅に減らせる
  
  

• policy.yaml をどこに配置するか
  Managed設定（組織共通）／プロジェクト設定（チーム共通）／ローカル設定（個人）の3層に分けると、ポリシー変更の影響範囲をコントロールしやすい
  
  

• warn→denyへの昇格基準
  PoC段階ではwarn中心で観察し、十分なデータが集まってからdenyに昇格させる進め方が、業務影響を最小化する

これらは仕様の話ではなく運用設計の話ですが、ACS導入の現実的なコストを左右する論点です。

ACS導入判断で詰まる論点とケース別の使い分け

ここまでで仕様・対応フレームワーク・規制対応・コスト構造の事実情報を整理しました。最後に、「自社の場合はどう導入すべきか」という判断軸を、AI総合研究所がエンタープライズAI導入を支援している立場から整理します。

詰まりやすい3つの論点

ACSの導入判断で、組織として詰まりやすい論点は以下の3つに集約されます。

• 誰がポリシーを書くのか
  セキュリティチーム・コンプライアンスチーム・開発チームのうち、ポリシーの一次オーナーをどこに置くかで運用が大きく変わる。
  ACS仕様はTier 3（独自分類器・ドメイン固有ロジック）でセキュリティ側の関与を想定しているが、実務ではTier 2（YAMLでの基本ポリシー）の段階から、開発と非開発の両者の合意が必要になる。
  
  

• PoCをどの規模で始めるか
  全社規模で導入しようとすると、最初の合意形成だけで数か月かかる。
  逆に1チーム1エージェントから始めても、組織全体のポリシー資産にならない。
  通常は「1部門・複数エージェント」をPoC単位として、warn運用→deny導入の順で進めるのが現実的。
  
  

• 既存のガードレール資産をどう扱うか
  すでにLangChainのコールバック、Semantic Kernelのフィルター、社内独自のラッパーで実装したガードレールを持っている場合、ACSへの移行は「全部書き直す」のではなく「インターセプションポイントにマッピングする」発想で進める。
  既存ロジックの大半は分類器・LLMジャッジとしてACSに差し込める。

これらは仕様を読んでも答えが出ない、組織固有の判断ポイントです。だからこそ、PoC段階で複数の関係者が議論できる場を設けることが、後の本番展開のスムーズさを左右します。

ケース別の第一候補ルート

組織の現状ごとに、ACSへの取り組み方を3パターンに整理しました。

共通する原則は、「全部の機能を最初から使おうとしない」ことです。warnでログを集める段階から始め、ポリシー候補を抽出してdenyに昇格させ、必要な箇所だけescalateを導入する、という段階展開が結果的に最短ルートになります。

【関連記事】
Microsoft Foundry Agent Serviceとは？使い方・料金を解説

Microsoft IQとは？Work IQ・Fabric IQ・Foundry IQ・Web IQの4層を徹底解説

「待つ」べきか「いま動く」べきか

ACSはAgent Control Standard側がv0.1 Public Preview相当、Microsoft AGT内蔵のSpecification実装もv0.3.1-betaという段階で、仕様の細部が今後変わる可能性があります。「正式版を待つべきか」という質問は当然出てきますが、実務では待つよりもPoCを始めるほうが合理的なケースが多いです。

理由は3つあります。

• EU AI Actの高リスク義務適用が控えている
  高リスクAIに分類されるエージェントを業務に組み込む企業は、適用開始（2027年12月2日／製品組込み系は2028年8月2日）に向けて人間監督・ログ・介入の実装根拠を整える必要がある。
  ACSが完成版を待つ余裕はなく、現行Preview段階の範囲でもwarn運用から始める価値が大きい。
  
  

• AGT v4.0.0はPublic Preview / Betaで提供中
  仕様がベータでもAGT実装は配布済み。「Microsoft実装に依存する」割り切りで進める組織なら、Preview段階のAPI変更を前提に設計しておけば、仕様変更リスクをある程度切り離せる。
  
  

• ポリシー資産は早く作るほど蓄積する
  ACSは「ポリシーを宣言的に書く」標準のため、組織のポリシー資産そのものは将来の標準にも転用できる。
  今のうちに「何を禁止し、何を許可するか」を組織的に議論しておくこと自体が、将来の負債を減らす。

逆に、「来年大幅な仕様変更が来た時に書き直したくない」という組織は、まずRego・Cedar等の汎用ポリシーエンジンで判定ロジックだけ書いておき、ACS側がfreezeしたタイミングでhookマッピングを後付けする、という二段構えも取れます。

AI総研の実務観察——CISO・SOC運用責任者のスキル要件が変わる

AI総合研究所がエンタープライズのAIエージェント導入を支援するなかで、ここ半年でCISO候補・SOC運用責任者のスキル要件が「AIエージェントを評価・統制する力」へシフトしている肌感が強くなっています。

エージェントが業務で動く前提が固まるほど、セキュリティ職に求められるのは「ファイアウォール設計」よりも「ポリシー設計の言語化」になります。ACSの判定4段階や3層アーキテクチャの語彙は、まさにこの議論を社内で進めるための共通言語として有効です。

ACSを「採用するかしないか」の判断より先に、自社のセキュリティ・コンプライアンス担当が、ACSの語彙でポリシーを議論できる状態を作ることが、長期的にはより大きな価値を持ちます。

AIエージェントの本番運用基盤を企業環境に組み込む

ACSの登場で、AIエージェントのガバナンスは「個別企業が独自に作るもの」から「業界標準を組み合わせて構成するもの」へ変わりつつあります。

一方で多くの企業は、ACS仕様の評価そのものよりも先に、**「自社の業務で動かすエージェントの設計・統制・コスト・セキュリティをどう整えるか」**という、より広い論点に向き合っている段階にあります。

AI Agent Hubでは、エンタープライズのAIエージェント本番運用に必要な統制設計・セキュリティ要件・コスト構造を、業種・業務・現状フェーズに合わせて整理した導入支援を提供しています。ACSのような新標準が登場するなかで自社のエージェント運用基盤をどう設計するか、最初の整理として活用ください。

AIエージェント運用基盤の設計をAI Agent Hubで支援

ACS世代のエージェントを企業環境に組み込む

Agent Control Specification（ACS）は標準仕様として登場したばかりで、本番運用に組み込むには「どのフレームワークで・どの権限境界で・誰がポリシーを書くか」の設計が欠かせません。AI Agent Hubでは、AIエージェントの本番運用に必要な統制・セキュリティ・コスト設計を企業ごとに整理した導入支援を提供しています。

▶ 無料で資料をダウンロード

まとめ

本記事では、2026年5月27日に発表されたAgent Control Specification（ACS）について、定義・既存ガードレールの限界・8つのインターセプションポイント・ポリシー記述方法・対応フレームワーク・関連標準との位置づけ・規制対応マップ・料金・導入判断の論点まで、2026年6月時点の最新情報で解説しました。要点を改めて整理します。

• ACSはAIエージェントが「何をしてよいか」をランタイムで宣言的に制御するオープン標準で、Microsoft主導で発表され業界連合（agentcontrolstandard.ai）のもとで共同管理されている。3層アーキテクチャ（Platform／Enforcement／Enterprise）と8つのインターセプションポイント、allow/warn/deny/escalateの4段階判定が中核
  
  

• 既存のガードレール手段（システムプロンプト・カスタムコード・静的フィルター）には散在・属人化・監査困難という限界があり、エンタープライズの規制対応・責任分界・移植性・可観測性の要求を満たせない。ACSはこの空白を埋める標準として登場した
  
  

• 対応SDKはPython・TypeScript・.NET・Rust・Goの5言語で、LangChain・OpenAI Agents SDK・Anthropic Agents SDK・AutoGen・CrewAI・Semantic Kernelなど10種類超のフレームワークに対応。MCPやA2Aと役割が異なる「ランタイム制御」レイヤーとして補完関係にある
  
  

• EU AI Act（高リスクAI主要義務は2027年12月2日・製品組込み系は2028年8月2日適用）・NIST AI RMF・Singapore Model AI Governance Framework・OWASP Top 10 for Agentic Apps 2026への対応の技術的な実装手段としてACSを位置づけられる。Open Trust Stack（ACS×ASSERT×OpenInference）として評価・制御・監視の3工程をベンダー横断のトレース／ポリシーコントラクトに乗せられる
  
  

• Agent Control Standard本体（v0.1 Public Preview相当）と、Microsoft AGTに同梱されたSpecification実装（v0.3.1-beta）・AGT v4.0.0（Public Preview / Beta）が並走。仕様・参照実装ともにオープン公開だが、分類器・LLMジャッジ・observability・人手承認の運用コストは別途発生する
  
  

• **詰まりやすい論点は「誰がポリシーを書くか」「PoC規模」「既存ガードレール資産の扱い」**の3つ。ケース別には、LangChain既存利用ならadapter経由、Foundry利用者ならAGT統合経由、新規ならpip installからAgent Frameworkに統合するのが現実的なルート

エンタープライズのセキュリティ責任者にとってACSは、「使うかどうか」よりも「業界がこの語彙でポリシーを議論し始めた前提で、自社のエージェント運用基盤を再設計できるか」という問いを突きつける動きです。

EU AI Actの高リスク義務適用（2027年12月2日／製品組込み系は2028年8月2日）と、各国規制当局のエージェント標準化動向を踏まえると、現行のPreview仕様のままでもwarn運用から着手し、ポリシー資産を組織的に蓄積し始める段階に入りました。ACSをきっかけに、自社のセキュリティ・コンプライアンス担当が同じ語彙でエージェント統制を議論できる状態を作ることが、次世代のAI運用基盤の競争力を左右します。