Microsoft Agent Control Specification：エージェント承認が企業AI基盤になる理由

Microsoft は Agent Control Specification を公開しました。AI エージェントのライフサイクル全体にランタイム治理を適用するための、オープンでベンダー中立な仕様です。TechCrunch もこの発表を報じ、開発、セキュリティ、コンプライアンスの各チームがエージェントの振る舞いをより一貫して制御する方法として紹介しています。

重要なのは、エージェントに設定ファイルが増えたことではありません。

企業AIは、エージェントがデータを取得し、ツールを呼び出し、ワークフローを実行し、複数システムをまたいで行動する段階に入っています。ソフトウェアが人の代わりに行動し始めると、問いは「モデルに何ができるか」から 「エージェントは何を許可され、誰が承認するのか」 に変わります。

ACS は治理をランタイムに組み込む

多くの組織は、まだ prompt、アプリケーションコード、フレームワークの callback、個別チェックでエージェントを制御しています。実験には十分でも、本番では脆い構造です。

Microsoft は ACS を agent framework ではなく controls layer と位置づけています。ポータブルな manifest によって、policy をエージェントのライフサイクルのどこで、いつ、どのように評価・適用するかを定義します。特定のフレームワーク、ランタイム、policy engine に依存しません。

ACS は共通の制御契約を提供します。

• ユーザー入力がモデルに入る前に検査する；
• モデル呼び出し前に文脈を検査する；
• runtime がモデル出力に基づいて動く前に検査する；
• ツール呼び出し前に検査する；
• ツール結果が文脈に戻る前に検査する；
• 最終出力がエージェントを離れる前に検査する；
• 起動時と終了時に設定、ログ、監査条件を評価する。

各ポイントで policy は allow、warn、deny、escalate を返せます。

Guardrails は prompt 内の助言ではなく、エージェント行動に結びついたランタイム判断になります。

新しい企業課題は承認である

有用なエージェントほど、メール、チケット、CRM、コードリポジトリ、顧客データ、財務ワークフロー、社内文書、デプロイツールに触れます。

従来のアクセス制御は、credential がリソースを呼べるかを答えます。しかしエージェントには、これまで見た情報、これから呼ぶツール、データラベル、承認状態を踏まえて「この行動は今も安全か」を判断する必要があります。

だから承認はインフラになります。

古い承認フローではなく、精密な制御面です。

• 自動実行できる行動；
• 人間の承認が必要な行動；
• マスクすべき機密データ；
• ブロックすべきツール呼び出し；
• 監査のために残すべき証拠；
• fail closed すべき失敗。

エージェント管理はプロダクト層になる

ACS は、エージェント管理がモデル選択だけではないことも示しています。

より強いモデルは推論を改善できます。しかし policy、監査、エスカレーション、証拠収集、人間への引き継ぎを自動的には作りません。それはシステムの責任です。

企業にとって長期的な価値は、エージェントの周辺層にあります。ID、権限、ワークスペース文脈、ツール境界、ログ、承認ゲート、改善ループです。エージェントはプラグインではなく、デジタルワーカーとして管理されるようになります。

Buda との関係

Buda も同じ前提で設計されています。エージェントは human-led system の中で働くべきです。

Buda の Space は組織の境界を定義します。エージェントはその中でファイル、セッション、ターミナル、ブラウザ、channels、artifacts、タスクを使って働きます。人間は作業をレビューし、指示を調整し、重要な行動を承認し、必要なら引き継げます。

ACS はエコシステム全体も同じ方向に向かっていることを示しています。エージェントが有能になるほど、企業には承認、policy、監査、エスカレーション、human oversight という明示的な制御面が必要になります。

企業AIの未来は、より多くの autonomous agents だけではありません。

よりよく管理された agents です。

buda.im で human-led agent workflows を始めることも、Buda Agent Workspace docs を読むこともできます。