「プロンプトで縛る」時代が終わりつつある
homulaは、エンタープライズ企業のAIエージェント導入を、承認・監査・権限といった統制要件まで含めて設計するAIインテグレーターです。
エージェントを本番に乗せるとき、多くの現場が最初に試すのは**「システムプロンプトで行動を縛る」やり方です。「機密情報は出力しない」「外部送信の前に確認する」「この操作は禁止」——指示を文章で書き込み、モデルの良識に委ねる。PoCではこれで十分に見えます。しかし本番では、この方法が確率的にしか守られない**という事実が必ず牙をむきます。プロンプトは破られ、忘れられ、無視され、そして「なぜその操作が起きたのか」を後から証明する手立ても残りません。
2026年6月2日に開幕した Microsoft Build 2026 で、Microsoftはこの問題に正面から答える発表を行いました。エージェントの統制をプロンプト（お願い）から、実行ループに組み込んだ決定論的な制御（インフラ）へ移すための、オープンな仕組み群です。本稿は、この「ランタイム・ガバナンス」の標準化の動きを、日本企業が自社の統制をどこに置くべきかという観点から読み解きます。
何が発表されたのか——Open Trust Stack
Microsoftが打ち出したのは、フレームワークを問わずAIエージェントの信頼性を担保するための 「Open Trust Stack（オープン・トラスト・スタック）」 という枠組みです。これは特定の製品ではなく、3つのオープンソース部品の組み合わせとして示されました（Microsoft Foundry Blog: Build agents you can trust）。
| 部品 | 役割 | 位置づけ |
|---|---|---|
| ASSERT | エージェントの振る舞い仕様を実行可能なテストへ変換する評価フレームワーク | デプロイ前の検証 |
| ACS（Agent Control Specification） | 実行ループの各所に決定論的な制御を置くポータブルな統制標準 | ランタイムの制御 |
| OpenInference | 評価・制御・観測を束ねる共通のOpenTelemetryテレメトリ層 | 横断する観測 |
3つに共通するのは、ベンダー中立・フレームワーク非依存・MITライセンスのオープンソースであることです（winbuzzer: Microsoft ACS Adds Runtime Governance、Arize: Microsoft's open trust stack runs on OpenInference）。Microsoftはこれを、コードからモデル・エージェントまでを開発ライフサイクル全体で守る取り組みの一部と位置づけています（Microsoft Security Blog: Build 2026）。
本稿が注目するのは、このうちランタイムの統制を担う ACS です。
ACSの中身——実行ループに「検問所」を置く
ACS（Agent Control Specification）は、エージェントの実行ループの決まった地点に、決定論的な安全・セキュリティ制御を置くためのオープンな業界仕様です。中核となるのは、「どこで・いつ・どのようにポリシーを評価し執行するか」を定義するポータブルなマニフェストで、これはエージェントのフレームワークも、ランタイムも、ルールを書くポリシーエンジンも問いません（commandline.microsoft.com: ACS）。
Microsoftの説明によれば、制御を差し込む「検問所」はエージェントループの5箇所——入力・LLM呼び出し・状態（state）・ツール実行・出力——に置かれます（Microsoft Foundry Blog）。TechCrunchも、ACSが入力を受け取る前・ツールを呼ぶ前・ツールの結果が返った後・最終応答を返す前といった複数地点でガードレールの遵守をチェックできると報じています（TechCrunch: Microsoft offers devs a better way to control AI agent behavior）。
各検問所でポリシーが取りうる判断は、おおむね次の4種です。
- 許可（allow）: そのまま実行を通す
- ブロック（block）: 禁止された操作を止める
- 秘匿（redact）: 機密情報を伏せて通す
- 人間の承認（human approval）: 実行前に担当者の判断を求める
ACSの実装上の肝は enforce（執行） にあります。これは操作が実行される前にそれを横取りし、有効なポリシーに照らして評価し、必要なら人間の承認を挟み、そして署名付き・タイムスタンプ付きの構造化レコード——操作・ポリシー評価・結果——を出力します。監査担当は、後から複数のアプリログを突き合わせて危険な操作を再構成するのではなく、ルール・判断・証拠・承認経路をひとまとめにした記録を実行そのものに紐づけて参照できます（agentcontrolstandard.ai）。
ACSは単体ではなく、Microsoftの Agent Governance Toolkit（AGT） の一部として提供されます。リファレンス実装は microsoft/agent-governance-toolkit として公開され、ポリシー執行・ゼロトラストID・実行サンドボックス・信頼性エンジニアリングを備え、OWASP Agentic Top 10 を10項目すべてカバーするとされています（GitHub: microsoft/agent-governance-toolkit）。任意のツールをガバナンス・ラッパーで包めば、その呼び出しはすべてポリシーに照らして評価され、ログに残り、執行されます。
なぜ「標準であること」が効くのか
ここで重要なのは、ACSが特定のエージェント・フレームワークに縛られない標準として設計されている点です。TechCrunchによれば、ACSはSDKとして提供され、LangChain、OpenAI Agents SDK、Anthropic Agents SDK、AutoGen、CrewAI、Semantic Kernel、Microsoft.Extensions.AI、そしてMCPツールなどのプラグインを備えます（TechCrunch）。
これは、MCP（Model Context Protocol）が「エージェントとツールの接続」を標準化したのと同じ構図を、**「エージェントの統制」**に持ち込もうとする動きです。接続の標準（MCP）と並んで、統制の標準（ACS）が立ち上がりつつある——と捉えると、潮流の意味が見えてきます。
| 観点 | プロンプトによる統制 | ランタイム・ガバナンス（ACS型） |
|---|---|---|
| 効き方 | 確率的（モデルの良識頼み） | 決定論的（実行前に機械的に執行） |
| 適用範囲 | そのプロンプトを使う1エージェント | フレームワーク横断で一貫適用 |
| 監査証跡 | 残りにくい・再構成が必要 | 署名付きレコードを実行に紐づけ |
| 人間の承認 | 文章でお願いするだけ | 実行前のフックとして組み込み |
| 変更管理 | プロンプト改修のたびに散在 | ポリシーをマニフェストで集中管理 |
なお、Open Trust Stackのもう一方の柱 ASSERT（Adaptive Spec-driven Scoring for Evaluation and Regression Testing）は、平易な言葉やYAMLで書いた「あるべき振る舞い」の仕様から自動でテスト群を生成し、実エージェントに対して走らせ、元のポリシーに照らして採点します。LiteLLM経由でOpenAI・Anthropic・Bedrock・VertexAI・自前のvLLMなど100超のエンドポイントに対応し、LLM判定は人手アノテーションと80〜90%の一致に達するとされています（effloow: Microsoft ASSERT）。デプロイ前は仕様をテストで検証し（ASSERT）、本番では実行ループで執行する（ACS）——この二段構えが今回の設計思想です。
日本企業がここから読むべきこと
この発表が日本企業に突きつけるのは、「Microsoftの製品を使うべきか」という問いではありません。**「エージェントの統制を、お願い（プロンプト）ではなく、実行基盤に組み込んだ仕組みとして持っているか」**という問いです。
情報システム部門と法務がエージェント本番化の場で必ず問うのは、決まって同じ3点です——「禁止された操作を機械的に止められるか」「重要な操作の前に人間が承認できるか」「後からすべてを監査できるか」。プロンプトに書いただけの統制は、この3点のいずれも保証しません。Microsoftが業界標準としてこの層を立ち上げてきたという事実は、**「ランタイムの統制は、もはやあって当然の前提」**になりつつあることの表れです。
一方で、ACSのような標準を「導入すれば終わり」と捉えるのは早計です。標準が定めるのは**「どこに・どう制御を差し込めるか」という枠組みであって、「自社の業務で何を許可し、何を止め、誰が承認するか」というポリシーそのもの**は、各社が自分で設計しなければなりません。さらに現実の業務は、Microsoft系だけでなく、社内のn8nやDify、LangGraphで組んだ自動化、複数ベンダーのモデルをまたいで動きます。統制は特定スタックの内側だけで完結させず、プロバイダ横断で一貫して効くように置く必要があります。
この論点は、OpenAIワークスペース・エージェントの権限設計や「野良AI」が企業を蝕む構造的リスク、そしてSnowflake×AnthropicのガバナンスドAIとも一直線につながります。各社が同じ方向——統制を実行基盤に埋め込む——へ動いている、というのが2026年の景色です。
homulaの観点——標準を「自社の運用」に落とす
ACSが示すのは、統制を差し込むべき地点と作法です。しかし企業に本当に必要なのは、その作法を自社の業務・権限・コンプライアンス要件に合わせて運用に落とすことにほかなりません。homulaはここを、特定ベンダーに寄り切らないインテグレーターとして設計します。
Agens はMCPを活用し、200以上のツールと構築ゼロで接続する共通基盤を提供します。これは、分散したSaaS・社内システムをエージェントの道具にするための、ベンダー中立な接続の「面」です。そのうえで Agens Control が、承認フロー・DLP・RBAC・5年分の監査ログを、プロバイダやフレームワークをまたいで一元的に効かせます。ACSが「実行ループに検問所を置く標準」を定めるなら、Agens Controlはその検問所で実際に止め・伏せ・承認を求め・証跡を残す運用を、複数の基盤にまたがって担う役割です。homulaが活用する n8n / Dify / LangGraph といった自動化基盤の上でも、統制を一貫して当てられる点が要になります。
どの業務に、どのエージェントを、どの承認点・監査要件で当てるか——その当てはめは、業務棚卸し・プロトタイプ構築・ROI試算を3〜5日（最短5日でPoC）で行うAIエージェント・ブートキャンプで素早く見極められます。統制の設計を先に固めた業務ほど、本番化が速く、処理時間の大幅な削減（過去には93%削減の例も）まで一気に到達します。
まとめ
Microsoft Build 2026で公開された Open Trust Stack（ASSERT・ACS・OpenInference） は、AIエージェントの統制をプロンプトという「お願い」から、実行ループに埋め込んだ決定論的な「インフラ」へ移す動きを、オープンな標準として前進させました。ACSは入力・LLM呼び出し・状態・ツール実行・出力の各検問所で、許可・ブロック・秘匿・人間の承認を機械的に執行し、署名付きの監査証跡を残します。
日本企業が問うべきは「どの製品を入れるか」ではなく、**「禁止操作を機械的に止め、重要操作の前に人が承認し、すべてを後から監査できる仕組みを、フレームワーク横断で持っているか」**です。接続の標準（MCP）に続いて、統制の標準（ACS型）が立ち上がる——この二つを実行基盤に組み込めた企業から、機密と権限が絡む本丸の業務でエージェントが安心して回り始めます。
エージェントを本番に乗せるなら、「何を許可し・何を止め・誰が承認し・どう監査するか」を、プロンプトではなく実行基盤の設計として先に固めるのが近道です。自社の業務とコンプライアンス要件に合った統制の置き方を、早めに整理することをおすすめします。