エージェントの制御範囲拡大に伴い、MicrosoftのAI安全性ガバナンスが強化

Microsoftは、自社製品全体でエージェントのアクセス権、自律性、業務上の影響範囲が拡大するなか、責任あるAIに関するルールを再設計した。このMicrosoftのAI安全性ガバナンスの転換は、根本的な矛盾に対応するものだ。チャットボット向けに策定された制御は、行動を実行できるソフトウェアを自動的に統制できるわけではない。

同社の2026年版Responsible AI Transparency Reportでは、エージェントに焦点を当てた脅威モデリング、プロンプトインジェクション対策、安全性分類器、リリース前の監督強化について説明している。また、ガバナンスの対象をモデルだけでなく、それを取り巻くプラットフォーム、ツール、データ、アプリケーションへと広げている。

この対象拡大は重要だ。エージェントはメッセージ送信、記録の取得、文書の変更、ソフトウェアツールの呼び出し、作業の委任を行える。Anthropic、OpenAI、Googleなどのモデル提供企業も、回答を生成する段階からタスクを実行する段階への同じ移行に直面している。

Microsoftの対応は、単なる方針更新にとどまらない。AI安全性はリリース前にレビューされる文書ではなく、運用上の制御システムになるべきだという考えに基づくものだ。

MicrosoftのAI安全性ガバナンスはエージェントスタック全体を対象に

Microsoftは、安全性の焦点をモデル出力から、AIシステムが実行できる行動の連鎖全体へ移している。

同社によれば、Responsible AI Standardを包括的に再設計した。この基準は、Microsoftが事業全体でAIシステムを開発、リリース、運用する際の指針となる。

透明性レポートによると、改訂版のアプローチはモデル、プラットフォームサービス、アプリケーションを対象とする。エージェント型の機能は独立した製品カテゴリーとして存在するのではなく、あらゆる層を横断する。

AIエージェントとは、モデルを利用してツール、データ、またはデジタル環境を通じてタスクを計画し、完了させるソフトウェアだ。そのリスクプロファイルは、モデルの応答だけで決まるものではない。

チャットボットは不正確な回答を生成するかもしれない。一方、エージェントは人が確認する前に、その回答に基づいて行動できる。

この違いにより、ガバナンスが対象とすべき範囲は変わる。企業は、エージェントのID、権限、メモリ、ツール、承認要件、実行履歴を検討する必要がある。

Microsoftによれば、同社の基準には現在、AIライフサイクル全体にわたるエージェント型機能の要件が含まれている。同社はまた、エージェントの挙動を中心に設計した新たな脅威モデリング手法も導入した。

脅威モデリングでは、システムがどのように障害を起こし、悪用され、攻撃を受け得るかを特定する。エージェントの場合、このプロセスでは多段階の活動や実行中に変化する条件を考慮する必要がある。

Microsoftは、関連する複数の変更を報告している。プロンプトインジェクション対策の拡充、安全性分類器の適用範囲拡大、新たな透明性テンプレートの作成、エージェントのガバナンス機能強化などだ。

プロンプトインジェクションは、信頼できないコンテンツがエージェントの指示を上書きしようとする際に発生する。攻撃は、エージェントが処理する文書、メール、Webページ、ソフトウェアインターフェース内に現れる可能性がある。

インジェクションが成功すれば、基盤となるモデルを侵害せずにエージェントを別の方向へ誘導できる。そのため、周辺アプリケーションのアーキテクチャが安全性の中心的な要素となる。

Microsoftは、リリース前の中央監督プロセスについても説明している。このプロセスは、システムが提供開始される前に、関連するリスクが対処済みであることを検証する目的で設計されている。

同社はこの取り組みを、NIST AI Risk Management Frameworkの4つの機能、すなわちgovern、map、measure、manageに整合させている。これらの機能は、リスク管理を最終的なリリース審査ではなく、継続的なプロセスとして扱う。

Microsoftによると、約2万人のエンジニア、政策立案者、顧客に責任あるAIの研修を提供した。また、基準の改訂にあたり、100件を超える法案または制定済みの法律をレビューした。

この法務・ガバナンス業務には、30を超えるチームから80人以上の従業員が参加した。これらの数値は取り組みの組織的な規模を示しているが、すべての制御が意図どおりに機能することを裏付けるものではない。

それでも、中心的な変化は明確だ。Microsoftは、モデル評価だけでは自律性を高めるシステムに対する十分な保護にならないと考えている。

エージェントの挙動は、モデル、指示、権限、ツール、データ、運用環境の相互作用から生まれる。ガバナンスはその連鎖全体を追随しなければならない。

エージェントの行動が異なる安全性の問題を生む理由

より難しい問題は、モデルが回答を生成した後、エージェントがその回答を外部での行動に変換する段階で始まる。

従来の生成AIにおける制御は、コンテンツに焦点を当てることが多い。チームは、モデルが危険な指示、偏った応答、個人情報、不正確な主張を生成しないかをテストする。

エージェントシステムは、さらに別の層を加える。モデルの判断を、実際の結果を伴うツール呼び出しへ変換するからだ。

カスタマーサービスエージェントは、アカウント記録の閲覧、回答の作成、返金の承認を行うかもしれない。コーディングエージェントは、リポジトリの変更、コマンドの実行、プルリクエストの作成を行う可能性がある。

オフィス向けエージェントは、メールの検索、会議の要約、文書の更新、同僚へのメッセージ送信を行える。それぞれの手順が、異なる権限を持つ別々のシステムに影響する可能性がある。

リスクは組み合わせによって増幅する。一見無害に見えるモデル出力でも、広範なアクセス権や不十分な検証と組み合わされると、危険な行動を引き起こしかねない。

MicrosoftがAgent Hooksで示した例は、この問題を説明している。架空のサポートエージェントが、承認制御で例外が発生した後に誤って返金処理を行う。

周辺フレームワークはエラーを記録するが、実行を継続する。別のバッチ処理経路では、想定されていたコールバックが実行されないため、別の制御が回避される。

教訓は構造的なものだ。安全性制御は、認識できない実行経路を保護できない。

このため、Microsoftの最近の取り組みは監視と執行を区別している。エージェントの活動を記録することは調査に役立つが、必ずしも危険な行動を止めるわけではない。

Microsoftは、エージェント実行内に制御を配置するためのオープンかつフレームワーク中立の契約としてAgent Hooksを導入した。この仕様は、フレームワークとガバナンスコンポーネントがどのように連携すべきかを定義する。

初回リリースには、Python、TypeScript、.NET、Rust、Go向けのソフトウェア開発キットが含まれる。47シナリオの適合性テストスイートも含まれている。

適合性テストでは、定義された条件下でフレームワークが契約を守るかを確認する。Microsoftが掲げる目標は、互換性の主張にとどめず、対応状況を検証可能にすることだ。

この契約は、複数の障害モードを対象としている。制御はすべての関連実行経路を認識し、証跡を記録し、ポリシーが拒否した場合には行動をブロックすべきだ。

最後の要件は当然に聞こえるが、エージェントフレームワークはオーケストレーションや可観測性ツールから発展してきたケースが多い。エラー処理は、厳格な執行よりもタスク完了を優先する可能性がある。

エージェントは委任のリスクも生む。親エージェントがサブエージェントにタスクの一部を依頼すると、新たなIDと実行経路が加わる。

再試行はさらに複雑さを増す。ブロックされた行動が、異なるミドルウェアや承認ロジックを適用する復旧経路を通じて再び実行される可能性がある。

バックグラウンドジョブやバッチプロセスは、対話型セッションとは異なる動作をする場合がある。ユーザー向けワークフローだけに接続された制御は、こうした経路を完全に見落とすかもしれない。

メモリも別の攻撃対象領域を生む。保存されたコンテキストは、最初に現れたセッションを越えて、誤った指示や機密データを保持する可能性がある。

こうしたリスクが、Microsoftがガバナンスを動的なものとして説明する理由だ。1回限りのモデルテストでは、導入後に遭遇するあらゆる権限、ツール、ユーザー、データソースを捉えられない。

同社の立場は、その製品の広がりも反映している。Microsoftは、モデル、クラウドインフラ、業務アプリケーション、IDシステム、開発者ツール、セキュリティ製品を提供している。

この広がりにより、Microsoftはスタック全体でポリシーを執行できる場所を持つ。同時に、制御が失敗し得る接続点が増えることへの責任も負う。

企業の購入担当者にとって、実務上の問いはもはや、エージェントが受け入れ可能なデモを実現するかどうかではない。導入されたシステムが、行動に至るあらゆる経路で予測可能に振る舞うかどうかだ。

核心となるトレードオフは能力と執行可能な制御の間にある

Microsoftはエージェントにより広範なタスクの完了を求めているが、権限が追加されるたびに信頼できる執行は難しくなる。

エージェント製品は、関連するコンテキストにアクセスし、意味のある行動を取れるようになるほど有用性が高まる。限定的な権限はリスクを低減するが、エージェントが完了できる作業を制限する場合もある。

広範な権限は反対の問題を生む。エージェントはより多くのタスクを完了できる一方で、ミスや攻撃による潜在的な影響も大きくなる。

この緊張関係は、MicrosoftのCopilot Coworkの例に表れている。同社によると、このシステムはユーザー承認、権限ベースのアクセス、安全性制御、段階的な展開を通じて、Microsoft 365全体の職場タスクを完了する。

段階的なリリースは、チームが挙動に関する証拠を収集する間の影響範囲を限定する。ユーザー承認は、エージェントの計画と選択された行動の間に人を介在させる。

どちらの仕組みもリスクを完全になくすものではない。ユーザーは結果を理解しないまま行動を承認する可能性があり、段階的なリリースでは特殊な条件を必要とする障害が明らかにならない場合がある。

最小権限アクセスも別の制御手段となる。これは、エージェントに割り当てられたタスクに必要な権限だけを与える考え方だ。

ただし、タスクがオープンエンドである場合、この原則の適用は難しい。プロジェクト更新の作成を依頼されたエージェントには、メール、カレンダー、文書、チャット、顧客記録へのアクセスが必要になるかもしれない。

共有システムへの書き込み権限も必要になる可能性がある。新しい接続が増えるたびに、有用性と潜在的な障害経路の数の両方が増加する。

Microsoftのより広範なフロンティアモデルフレームワークは、最も深刻な能力リスクに対応している。同社のガバナンスフレームワークは、化学、生物、放射線、核、サイバー、自律性、制御、操作に関する懸念を追跡している。

このフレームワークは、一般的な推論、長文コンテキストでの推論、計画、ツール利用、科学的推論、ソフトウェアエンジニアリングなどの先行指標を評価する。

関連する指標を示すモデルには、より詳細な評価が実施される。Microsoftは、結果として生じるリスクを低、中、高、重大に分類する。

同社によれば、高または重大なリスクには、導入前に追加レビューと緩和策が必要となる。また、特定されたリスクを十分に低減できない場合は、開発と導入を一時停止することも約束している。

この約束は重要だが、Microsoft内部の評価とガバナンス判断に依存している。外部の人々が、すべてのモデル結果や導入判断を独自に確認することはできない。

フロンティアフレームワークは、国家安全保障と公共安全に対する脅威にも重点を置く。企業向けエージェントは、顧客にとってなお重要な、より小規模なリスクを数多く生む。

エージェントは、機密ファイルを公開し、未承認のメッセージを送信し、誤った取引を実行するために、フロンティアレベルの自律性を必要としない。

こうした障害は、導入コンテキストに大きく左右される。同じモデルでも、下書きツールでは低リスクであっても、金融ソフトウェアに接続されると大幅にリスクが高まる可能性がある。

Microsoftは、階層化されたガバナンスを通じてこの違いに対応している。フロンティア評価は例外的な能力を対象とし、より広範な基準は製品、導入、継続的な運用を対象とする。

同社のオープンソースのAgent Governance Toolkitは、別のアプローチを採っています。ポリシー施行、エージェントのアイデンティティ、実行制御、信頼性、コンプライアンス証跡、プラグインセキュリティのためのコンポーネントを提供します。

governance toolkitには、Python、TypeScript、Rust、Go、.NETにまたがる7つのパッケージが含まれます。Microsoftによれば、このリポジトリには9,500件を超えるテストが含まれています。

あるコンポーネントは、エージェントのアクションの前にポリシー判定を置きます。別のコンポーネントはエージェントに暗号学的アイデンティティを割り当て、エージェント間の信頼判断をサポートします。

このツールキットには、実行リング、トランザクション処理、サーキットブレーカー、緊急停止メカニズムも含まれます。これらの機能は、オペレーティングシステムとサイト信頼性エンジニアリングで確立された考え方を取り入れています。

このエンジニアリングの方向性は重要です。エージェントの安全性を、モデルに自然言語のルールに従うよう求めることだけに全面的に依存することはできません。

プロンプトは意図を表現できますが、外部ポリシーエンジンは決定論的な判断を下せます。モデルが要求した場合でも、禁止されたツール呼び出しを拒否できます。

このトレードオフは依然として解決されていません。より高性能なエージェントには実システムへの経路がさらに必要になる一方、経路が増えるほど施行上の負担も増えます。

Microsoftの戦略は、それらの経路を可視化し、テスト可能かつ統制可能にすることです。この戦略の価値は、製品がどれほど一貫して採用するかに左右されます。

Microsoftのフレームワークには依然として施行上のギャップがある

公開された標準は意図するシステムを示しますが、安全性は製品上の圧力、統合の誤り、未知の攻撃に対して制御が機能し続けるかどうかに依存します。

Microsoftの透明性レポートは、ガバナンスのプロセスについて広範な詳細を提供しています。ただし、すべての製品、モデル、制御、インシデントについて完全な公開証拠を提供しているわけではありません。

この区別は重要です。内部ガバナンスは、部分的には自己評価だからです。Microsoftは技術を開発し、多くのリスクを評価し、緩和策を選択し、いつ展開を進められるかを決定します。

外部テストは、この利益相反を軽減できます。同社は評価パートナーシップを拡大し、Copilot Healthに外部テストフレームワークを使用したとしています。

同社は、そのヘルスケア体験をリリースする前に、24カ国以上から250人を超える有資格臨床医に相談しました。この取り組みでは、明確性、有用性、安全性を扱いました。

この事例は、展開に特化した評価プロセスを示しています。しかし、同等の独立した精査がすべてのエージェント製品に及んでいることを示すものではありません。

システムが複雑化するにつれ、透明性の確保も難しくなります。単一のアプリケーションが、Microsoftのモデル、サードパーティモデル、プラグイン、独自データ、顧客定義のポリシーを組み合わせることがあります。

そのサプライチェーン全体で責任が分断される可能性があります。モデルプロバイダーが制限事項を文書化する一方で、フレームワーク開発者がツール実行を制御し、顧客が権限を割り当てることがあります。

インシデントが発生すると、各参加者が別のレイヤーを指し示すことができます。したがって、効果的なMicrosoft AI安全性ガバナンスには、展開全体にわたる明確な所有責任が必要です。

NISTのrisk frameworkは、このライフサイクルの見方を支持しています。ガバナンスを横断的な機能として扱い、継続的な監視、レビュー、文書化、定義された責任を求めています。

NISTはまた、独立したレビューがテストを改善し、内部バイアスを減らせると指摘しています。この原則は、Microsoftが今後行う開示を評価するうえで有用な基準となります。

購入者は、障害条件下でも制御が機能する証拠を求めるべきです。依存先がクラッシュしたり、タイムアウトしたり、不正な形式のデータを返したりしても、ポリシーエンジンはアクションを拒否しなければなりません。

これは「フェイルクローズド」として知られています。制御が利用できなくなったことを理由に処理を継続するのではなく、不確実なアクティビティをブロックする仕組みです。

Agent Hooksはこの要件を直接対象としていますが、仕様だけで正しい実装を保証することはできません。フレームワークの保守者はこれを統合し、アプリケーションチームは適切に設定しなければなりません。

適合性テストは、互換性の問題を明らかにする助けになります。しかし、すべてのアプリケーション固有の経路、カスタムプラグイン、ポリシー設定ミスを予見することはできません。

パフォーマンスも別の圧力をもたらします。開発者は、目立つ遅延を加えたり、誤検知を生んだり、一般的なワークフローを中断したりする制御を回避する可能性があります。

プロダクトチームも導入上のインセンティブに直面します。常に承認を求めるエージェントは、素早く行動するエージェントより役に立たないように見える場合があります。

結果として生じる設計上の課題は、最大限の制限ではありません。通常の業務を使いものにならなくすることなく、影響の大きいアクションにより強い制御を適用することです。

規制は、別の圧力層を加えます。汎用AIモデルに対する欧州連合の義務は、すでに技術文書と下流プロバイダー向け情報を求めています。

欧州委員会のmodel obligationsは、著作権ポリシーとトレーニング内容の公開要約も対象としています。システミックリスクを伴うモデルには追加要件が適用されます。

これらのルールは、主にモデルプロバイダーに焦点を当てています。エージェントの展開では、リスクがモデル、アプリケーション、ツール、組織に分散します。

Microsoftの拡張された標準は、このギャップを埋めようとしています。新しいDeployer Chapterは、Microsoft内でサードパーティAIアプリケーションを利用するための要件を定めています。

同社は3つの運用段階を説明しています。プロバイダーの評価、展開リスクの管理、リリース後の継続的な検知と対応です。

このアプローチは、不都合な事実を認めています。十分にテストされたモデルであっても、設計の悪いアプリケーション内では安全でなくなる可能性があります。

最も重要な不確実性は、Microsoftが詳細なルールを書いたかどうかではありません。チームが、それらのルールが意味のあるすべてのアクション経路を統制していることを証明できるかどうかです。

顧客は、制御の証拠、評価範囲、インシデントプロセス、監査記録を求めるべきです。責任あるAIに関する包括的な保証だけでは十分ではありません。

また、自らのインベントリも維持すべきです。セキュリティチームとコンプライアンスチームが存在を把握していないエージェントを、組織が統制することはできません。

知識集約型の業務では、検索可能なAI knowledge baseを維持することで、トレーサビリティを改善できます。ただし、保存および検索の制御は、基礎となる情報の機密性に引き続き見合う必要があります。

ガバナンスが測定可能になって初めて、施行上のギャップは縮小します。Microsoftはより多くの仕組みを提供しましたが、決定的な試験は本番環境での証拠です。

Microsoftの競合各社もリスクベースのガバナンスに収束している

主要なAIプロバイダーは、能力の向上にはより強力な保護措置が伴うべきだという点で、しだいに一致しつつあります。ただし、そのしきい値と開示内容には違いがあります。

Microsoftだけが能力ベースの安全性ルールを採用しているわけではありません。Anthropicは2023年以降、Responsible Scaling Policyを維持しており、モデルの変化に合わせて繰り返し改訂しています。

Anthropicのポリシーは、定義された能力しきい値を必要な保護措置と結び付けています。同社の現在の資料は、生物学的リスク、サイバーリスク、自律的AI研究を扱っています。

同社は自らのポリシーを、比例的で反復的であり、Anthropic以外にも採用可能なものと説明しています。scaling policyには、不遵守の報告および報復防止プロセスも含まれています。

MicrosoftのFrontier Governance Frameworkは、関連する構造に従っています。両組織は高リスクな能力を特定し、モデルを評価し、結果をより強い保護と結び付けています。

これらのフレームワークは同一ではありません。定義、しきい値、報告慣行、組織プロセスが異なります。

OpenAIとGoogleも、フロンティア安全性へのアプローチを公開しています。これらのポリシーは総じて、段階的な評価とリスクベースの展開をめぐる合意が広がっていることを示しています。

現在の競争は、原則と同じくらい実装にも関わっています。プロバイダーは、保護措置が能力向上に追随することを政府や顧客に示しながら、より高性能な製品をリリースしようとしています。

Microsoftは、消費者向けソフトウェア、エンタープライズインフラ、アイデンティティ、セキュリティ、開発者プラットフォームにまたがって事業を展開しているため、独自の立場にあります。

この統合はガバナンス上の利点をもたらします。Microsoftは、モデル評価をアクセス制御、エンドポイントセキュリティ、アプリケーションポリシー、組織の監査システムと結び付けられます。

一方で、ロックインへの懸念も生じます。顧客は、エージェント、アイデンティティレイヤー、ポリシーエンジン、監視、コンプライアンス証拠を単一ベンダーに依存するようになる可能性があります。

MicrosoftがAgent Hooksをフレームワーク中立の仕様として公開した決定は、その懸念に抗うものです。同社のガバナンスツールキットは、複数の外部エージェントフレームワークもサポートしています。

オープンなインターフェースは、制御をポータブルにできます。また、チームが異なるプロバイダーのモデルとフレームワークを利用する際、顧客に一貫したポリシーレイヤーを提供できます。

エンタープライズAI環境が均一なまま維持されることはほとんどないため、ポータビリティは重要です。ある企業は、Microsoft 365、Azure、Anthropicモデル、OpenAIのコーディングエージェント、オープンソースのオーケストレーションソフトウェアを使用する場合があります。

フレームワーク中立の契約は、重複する統合作業を減らせます。また、各判断をどのコンポーネントが施行すべきかを明確にできます。

ただし、オープン仕様が意味を持つのは、競合するフレームワークがそれを忠実に実装した場合に限られます。したがって、Microsoft製品以外での採用は重要な評価指標となります。

規制当局もこの収束に影響を与えます。欧州連合のルールは、AIサプライチェーン全体にわたり、文書化、リスク管理、情報共有を求めています。

NISTの任意標準は、もう一つの共通語彙を提供します。Microsoftは、自社のガバナンスプロセスをNISTのgovern、map、measure、manageの機能に明示的に対応付けています。

共通の用語は、監査や調達を簡素化できます。ただし、プロバイダー間で同等の安全性パフォーマンスを保証するものではありません。

各組織は依然として、何をテストするか、結果をどのように採点するか、どの残余リスクを受け入れるか、どの情報を公開するかを選択します。

顧客が信頼できる証拠を要求すれば、競争圧力はガバナンスを強化できます。リリース速度が成功の主要な指標になれば、ガバナンスを弱める可能性もあります。

これが業界における中心的な競争です。勝者は、単に最も高性能なエージェントを提供する企業ではありません。

エンタープライズ顧客は、施行可能な制限の範囲内で有用な自律性を示せるシステムを選ぶでしょう。そのためには、アイデンティティ、権限、監視、承認、復旧、説明責任が連携して機能する必要があります。

Microsoftは、その統合モデルに向けて構築を進めています。競合各社は、この統合がポリシーの一貫性以上のものを生み出すことを証明するよう同社に圧力をかけるでしょう。

Microsoftがルールを本番運用に移す際の注目点

次の試験は、Microsoftがガバナンスアーキテクチャを、製品群と外部フレームワーク全体で可視的かつ再現可能な証拠へ変換できるかどうかです。

最初のシグナルは、製品レベルの文書化です。Microsoftは、改訂されたResponsible AI Standardが、個別のエージェントのリリース、権限、評価、インシデント対応をどのように変えるかを示すべきです。

詳細な展開ノートは、ガバナンスがAIライフサイクル全体に及ぶという同社の主張を強めるでしょう。開示が乏しければ、顧客は高レベルの保証に依存せざるを得ません。

最も有用な文書は、評価カテゴリ、既知の制限、承認の境界、監視慣行、残余リスクを特定するものです。また、制御が失敗した場合に何が起きるかも説明すべきです。

この証拠は、Copilot製品、Azureのエージェントサービス、コーディングエージェント、複数エージェントを連携させるシステムにとって重要です。それぞれの文脈が異なる結果を生みます。

2つ目のシグナルは、Microsoft自身のフレームワークを超えたAgent Hooksの採用です。主要なオーケストレーションプロジェクトによるサポートは、共通の施行契約に対する需要を裏付けるでしょう。

導入だけでは不十分です。フレームワークは適合性スイートを通過し、対話型、バッチ、再試行、委任された実行パス全体でポリシーの強制を維持しなければなりません。

統合の失敗に関する独立した報告は、共通契約が断片化の問題を解決するというMicrosoftの主張を弱めることになります。再現可能な適合性結果は、その主張を強化するでしょう。

3つ目のシグナルは、インシデントの透明性です。Microsoftは、デプロイ後も監視、ユーザーフィードバック、是正措置を継続するとしています。

読者は、エージェントの障害とそれに伴う修正について、同社が意味のある情報を公開するかを注視すべきです。実際のインシデントは、ラボでの評価では見落とされるギャップを明らかにします。

有用な報告では、モデルのエラーを、権限の失敗、ツールの誤用、プロンプトインジェクション、壊れた承認ロジックと区別する必要があります。この切り分けは、顧客が自社システムを改善する助けになります。

Microsoftのフロンティア・フレームワークについても、継続的な精査が必要です。より強い自律性、計画能力、サイバー、またはソフトウェアエンジニアリング能力を備えた新しいモデルは、より深い評価の契機となるべきです。

同社は、リスクを十分に低減できない場合には開発とデプロイを停止すると約束しています。将来このコミットメントが適用されれば、ガバナンスの独立性にとって大きな試金石となるでしょう。

顧客は、こうしたシグナルを待ってから行動する必要はありません。導入済みのエージェントを棚卸しし、権限を縮小し、影響の大きいツールを分離し、元に戻せない操作には承認を求めることができます。

また、障害条件もテストできます。チームは意図的にポリシーサービスを中断し、不正なツールリクエストを送信し、拒否された操作が確実に拒否されたままであるかを確認すべきです。

ログは、ポリシー判断と実際に実行された操作を結び付けるべきです。モデルのメッセージだけを記録するログには、重要なギャップが残ります。

組織は、リリース後にエージェントの責任を誰が担うのかを定めるべきです。挙動が変化した際には、プロダクト、セキュリティ、法務、データ、運用の各チームに明確な責任が必要です。

停止および復旧の手順も確立すべきです。緊急停止は、人々がいつ、どのように使うべきかを理解している場合にのみ有用です。

MicrosoftのAI安全ガバナンスは、エージェントをチャットインターフェースではなく、行動のためのオペレーティングシステムとして扱うことで、技術的には正しい方向へ進んでいます。その最も強力な考え方には、実行時の強制、アイデンティティ、権限、証跡が含まれます。

残る疑問は、こうした考え方が本番ソフトウェアの複雑な条件下でも通用するかどうかです。購入者は、エージェントにより広い権限を与える前に、あらゆる実行パスにわたる証拠を求めるべきです。