AIエージェントを安全に運用するOSS「agent-governance-toolkit」の仕組み

「AIエージェントを本番に出す前に、ガードレールは用意できているのか」「誰がどの操作を実行したのか、後から追跡できるのか」。社内向けのAIエージェントをPoCから本番投入へ進めようとした段階で、こうした問いを経営部門やセキュリティ部門から突きつけられた経験はないでしょうか。

エージェントがツール呼び出しやデータベースへのクエリ、外部APIの連携を自律的に実行するようになると、従来の「プロンプトに危険な操作はしないでくださいと書いておく」という対策だけでは説明責任を果たせなくなります。とはいえ、ガバナンスを担保する仕組みを自前で設計するのは負担が大きく、どこから手をつければよいのか判断がつきにくいのも実情です。

こうした課題に対し、Microsoftが2026年4月にオープンソースとして公開したのが「agent-governance-toolkit」（略称AGT）です。自律型AIエージェントのポリシー実行・ID管理・実行サンドボックス・監査ログを一つのスタックとして統合し、エージェントの「何をするか」を制御することを目的としています。

本記事では、このagent-governance-toolkitが何を解決するOSSなのか、どのような仕組みで動くのか、最小構成ではどう書くのか、そしてOPAやNeMo Guardrailsといった既存のガバナンス/ガードレール系OSSと何が違うのかを、公式ドキュメントとREADMEの記載をもとに解説します。「自分のスタックに導入すべきか」を判断するための材料として整理していきます。

なお本記事は公開されている公式情報をもとにした解説であり、実際のインストールや動作検証を行ったうえでの記述ではない点をあらかじめお断りしておきます。

agent-governance-toolkitとは何か

agent-governance-toolkitは、Microsoftが公開している自律型AIエージェント向けのガバナンス基盤OSSです。公式リポジトリの説明によると、ポリシー実行（policy enforcement）、ゼロトラストID（zero-trust identity）、実行サンドボックス（execution sandboxing）、そして信頼性エンジニアリング（reliability engineering）を提供し、OWASP Agentic Top 10の10項目すべてをカバーすると記載されています（GitHubリポジトリ）。

ライセンスはMITで、商用利用を含めて扱いやすい条件になっています。主要言語はPythonですが、TypeScript・.NET・Rust・GoのSDKも提供されており、いずれもコアとなるガバナンス機能（ポリシー・ID・信頼・監査）を実装しています。LangChain／LangGraphやCrewAI、OpenAI Agents SDK、AutoGen、Semantic Kernelなど12以上のフレームワークとの統合が用意されている点も特徴です。各フレームワークのネイティブな拡張点にフックする設計のため、既存コードを大きく書き換えなくても組み込める方針が示されています。

公開からの日はまだ浅いものの注目度は高く、本記事執筆時点（2026年5月31日時点）でGitHubのスター数は3,511、fork数は501に達しています。リポジトリは活発に更新されており、直近のプッシュも同日付で記録されています。一方で現在のステータスは「Public Preview」であり、Microsoftの署名付きで提供されてはいるものの、GA（正式提供）前のため破壊的変更が入る可能性がある段階です。この点は採用判断の前提として押さえておく必要があります（Public Previewであることの含意は後述します）。

つまりagent-governance-toolkitは、「自律的に動くAIエージェントが、許可された操作だけを、追跡可能かつ証明可能な形で実行する」ことを担保するための統合スタックである、と整理できます。

なぜAIエージェントにガバナンスが必要なのか

そもそも、なぜプロンプトに注意書きを足すだけでは不十分なのでしょうか。ここを納得しておかないと、AGTのような別レイヤーを導入する動機が言語化できません。

ガバナンスが答えるべき3つの問い

公式の発表ブログでは、AIエージェントが自律的にツールを呼び出し、Webを閲覧し、データベースへクエリを投げ、ほかのエージェントへ作業を委任するようになると、次の3つの問いに答えられる必要があると整理されています（Microsoft Open Source Blog）。

1. この操作は許可されているか（Is this action allowed?） — OAuthのスコープやIAMのロールは「どのサービスに到達できるか」を制御しますが、「接続したあとで何をするか」までは制御しません。たとえば send_email と query_database の権限を持つエージェントが、drop_table を実行できてしまってはいけません。到達可能性の制御と、実行内容の制御は別物だという指摘です。
2. その操作を実行したのはどのエージェントか（Which agent did this?） — マルチエージェント環境で5体のエージェントが1つのAPIキーを共有していると、障害が起きたときに「どれかがやった」としか言えず、原因の切り分けができません。
3. 何が起きたかを証明できるか（Can you prove what happened?） — 監査担当者や規制当局は、どのポリシーが有効で、エージェントが何を要求し、なぜ許可または拒否されたのかを示す改ざん防止された記録を求めます。

これらは、まさに本番投入レビューで「ガードレールは？」「誰がどの操作をしたか追跡できるのか？」と問われる内容そのものです。

プロンプトレベルの安全策では足りない理由

agent-governance-toolkitのREADMEは、プロンプトに「ルールを守ってください」と書くタイプの安全策を、制御の仕組みではなく「確率的なシステムへの丁寧なお願い」にすぎないと位置づけています。そして、その限界を示す外部研究を複数引用しています。

たとえば、適応的な攻撃手法を用いた研究では、GPT-4o・GPT-3.5・Claude 3・Llama-3といった主要モデルに対して100%の攻撃成功率が報告されています（Andriushchenko et al., ICLR 2025）。また、プロンプトインジェクションについては確実な防止策が確立されているとは言えない状況が指摘されています（OWASP LLM01:2025）。Microsoft自身が100種類の生成AI製品をレッドチーミングした知見でも、緩和策はリスクを完全には除去しないと結論づけられています（Microsoft Security Blog）。

ここからAGTが導く方針は明快です。モデルの意図がワイヤ（実際の通信）に到達する「前」に、決定論的なアプリケーションコードでツール呼び出し・メッセージ送信・委任をインターセプトする、というアプローチです。AGTのカーネルが拒否したアクションは「起こりにくい」のではなく、構造的に「実行できない」ものになります。確率に頼るのではなく、コードのレイヤーで遮断するという考え方が、プロンプトレベルの対策との根本的な違いです。

なお、こうした技術的なガードレールを組織のルールや運用体制とどう接続するかについては、社内AIガバナンス体制構築ガイドも併せて参考になります。

agent-governance-toolkitの仕組みとアーキテクチャ

では、agent-governance-toolkitは具体的にどのような流れでエージェントの操作を制御するのでしょうか。公式ドキュメントによると、処理は「Agent → Policy Engine → Identity → Audit Log」という順序で進みます（公式ドキュメント）。

エージェントが操作を要求すると、まずポリシーエンジンがそのアクションを評価します。許可されればツールが実行され、拒否されれば GovernanceDenied という例外が送出されます。そして、許可・拒否いずれの判断も改ざん防止された監査ログに記録され、意思決定の記録（Decision Record）として残ります。先ほど述べた「モデルの意図が通信に到達する前にインターセプトする」という思想が、この処理フローに反映されています。

4つのレイヤー

AGTのガバナンスは、大きく次の4つのレイヤーで構成されています。

• ポリシーエンジン — どの操作を許可・拒否・承認待ちにするかを評価する中核。宣言的なYAMLに加え、OPAのRegoやAWS Cedarで書いたポリシーも同じ評価パイプラインに載せられます。
• ゼロトラストID — どのエージェントが操作したかを識別する仕組み。SPIFFE・DID・mTLSといった方式に対応します。
• 実行サンドボックス — 特権リングによる実行の隔離。
• 改ざん防止監査ログ — 何が起きたかを後から証明するための記録。

重要なのは、これらのレイヤーがいずれもオプションだという点です。公式ドキュメントは、まず後述する govern() から始め、リスクプロファイルの拡大に応じてレイヤーを追加していく「段階的導入（incremental adoption）」を設計思想として掲げています。多くのチームはポリシー実行と監査ログだけで運用し、フルスタックは必要としないと説明されています。マルチエージェント化したらIDを追加し、規模が大きくなったら信頼性エンジニアリングのレイヤーを足す、といった足し方ができます。「いきなりフル機能を入れなければならない」という導入規模の不安には、このレイヤー選択の自由度が答えになります。

主要パッケージの役割

AGTは複数のパッケージで構成されています。主要なものの役割は次のとおりです。

このほか、ツール汚染やタイポスクワッティングを検出するMCP Security Gateway、未登録エージェントを発見するShadow AI Discovery、ガバナンスの可視化を行うGovernance Dashboardといった追加機能も含まれます。なお、かつて多数に分かれていたパッケージは、v4.0.0でcore／runtime／sre／cli／metaの5つのトップレベル配布物に統合されています。

最小構成で動かすイメージ

ここまでで仕組みの全体像を見てきましたが、実際の導入コストはどの程度なのかが気になるところです。公式のQuick Startドキュメントによると、最小構成はごく短いコードで始められます（Quick Start）。

2行で既存ツールをガバナンス下に置く

前提はPython 3.10以降で、パッケージは pip install agent-governance-toolkit[full] でインストールします。READMEに記載されている最小の利用例は次のとおりです。

from agentmesh.governance import govern

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

出典: agent-governance-toolkit README

既存のツール（my_tool）を govern() でラップするだけで、その呼び出しがすべてポリシーに基づいてチェック・ログ・実行制御の対象になります。先に述べた「既存コードを大きく書き換えなくても組み込める」という方針が、この書き味に表れています。ここから始め、必要に応じてIDや監査などのレイヤーを足していく、という段階的な進め方が想定されています。

ポリシーの書き方とCLIツール

policy.yaml は apiVersion: governance.toolkit/v1 を持つ宣言的なYAMLファイルです。condition（条件）と action（処理）の組み合わせでルールを定義し、action には allow（許可）・deny（拒否）・require_approval（承認待ち）を指定します。拒否に該当した場合は、先述の GovernanceDenied 例外が送出されます。条件と処理を宣言的に並べるだけなので、OAuthスコープやIAMロールの知識があるエンジニアであれば読み解きやすい構造です。

運用面では agt というCLIも用意されています。公式ドキュメントによると、主なサブコマンドは次の役割を持ちます。

• agt doctor — インストール状態の確認
• agt verify — OWASPコンプライアンスのチェック
• agt red-team scan — プロンプトインジェクションの監査
• agt lint-policy — ポリシーファイルの検証

ポリシーをコードと同じようにリントし、レッドチーミングまでCLIから回せる設計になっている点は、CI/CDへの組み込みを意識した構成だと読み取れます。

既存のガバナンス/ガードレール系OSSとの違い

技術選定の場面で必ず比較対象に挙がるのが、NeMo GuardrailsやOPA、Guardrails AIといった既存OSSです。agent-governance-toolkitがこれらの「乗り換え」なのか「併用」なのかを整理しておきます。

比較表

軸を整理すると、これらは「会話の内容を制御する系」と「アクションの実行を制御する系」に分かれます。NeMo GuardrailsやGuardrails AIは主に「エージェントが何を言うか・どんな出力を返すか」を制御する側で、署名や改ざん防止監査、ゼロトラストIDといった仕組みは持ちません。一方AGTは「エージェントが何をするか」、つまりツール呼び出しや委任といったアクションを実行前にインターセプトすることに重心があり、そこにID管理と監査ログを組み合わせています。

併用できるものと置き換えになるもの

OPAとの関係は特に整理しておく価値があります。OPAは特定領域に限定されない汎用のポリシーエンジンで、AIエージェント専用ではありません。AGTはこのOPAのRegoを自身の評価パイプラインに取り込めるため、両者は競合というより補完の関係にあります。単一の PolicyEvaluator.evaluate() のなかで、Rego・Cedar・YAMLを併用できる設計です。すでにOPAを運用しているチームであれば、ポリシー資産を活かしながらAGTのエージェント固有レイヤー（ID・サンドボックス・監査）を上乗せする、という導入の仕方が考えられます。

AGTが他と一線を画すのは、アクション実行前の決定論的なインターセプト、エージェントID、改ざん防止監査、そしてSRE（キルスイッチやSLO監視）を一つのスタックとして一気通貫で提供し、OWASP Agentic Top 10の全項目への準拠を掲げている点です。各リスクへのマッピングは公式ドキュメントに整理されています（OWASP Agentic Top 10 アーキテクチャ）。

したがって、「会話の内容制御だけが目的ならNeMo Guardrails」「出力のスキーマ検証ならGuardrails AI」「すでにOPAを使っているなら取り込みを検討」「アクション制御とID・監査を統合的にカバーしたいならAGT」といった具合に、目的に応じて使い分け・併用を考えるのが現実的です。

標準準拠と本番運用での注意点

導入を経営部門やセキュリティ部門に説明する際には、標準への準拠状況と、ツールの限界の両方を把握しておく必要があります。

公式ドキュメントによると、agent-governance-toolkitはOWASP Agentic AI Top 10の10リスクすべてに決定論的なコントロールをマッピングしているほか、NIST AI RMF 1.0（GOVERN／MAP／MEASURE／MANAGE）、EU AI Act、SOC 2への準拠も整理されています。これらは監査説明の材料として活用できます。信頼性の裏付けとしては、各主要コンポーネントにRFC 2119形式の仕様が用意され、992件の適合性テストでコードと仕様の整合を担保していると記載されています。なお、Microsoftの公式発表ブログでは全パッケージを通じて9,500件以上のテストがあると記載されており、適合性テスト992件はそのうち仕様準拠を確認する分という位置づけです。性能面では、ポリシー評価がサブミリ秒（p99で0.1ミリ秒未満）とされています。

一方で、公式が明示している設計上の限界も押さえておくべきです。AGTはアプリケーションのミドルウェア層でガバナンスを強制するもので、OSカーネル層での分離ではありません。ポリシーエンジンとエージェントは同一のプロセス境界を共有します。そのため公式は、本番環境では各エージェントを別コンテナで実行してOSレベルの分離を併用することを推奨しています。既知の限界はリポジトリの docs/LIMITATIONS.md に明記されているため、採用前に目を通しておくとよいでしょう（ポリシー言語の使い分けについてはOPA/Rego/Cedarチュートリアルも参考になります）。

加えて、すでに触れたとおり現在のステータスはPublic Previewです。Microsoftの署名付きで提供されてはいるものの、GA前のため今後の更新で破壊的変更が入る可能性があります。本番の基盤として全面的に依存する前に、まずは小さな範囲で評価する、という前提で検討するのが現実的です。

まとめ — どんなチームが検討すべきか

agent-governance-toolkitは、自律型AIエージェントの「何をするか」を実行前に決定論的に制御し、ID管理と改ざん防止監査までを統合して提供するMicrosoft製のOSSです。プロンプトレベルの安全策では確率的にしか防げない操作を、コードのレイヤーで構造的に遮断する点が中核の価値だと整理できます。

導入を第一に検討すべきなのは、複数のエージェントを協調させている、ツールを自律的に実行させている、あるいは監査要件を抱えている、といったチームです。逆に、目的が会話の内容制御に限られるならNeMo Guardrails、出力のスキーマ検証が中心ならGuardrails AIのほうが素直に合致します。すでにOPAを運用しているなら、Regoの資産を活かしてAGTに取り込む形での併用が選択肢になります。

始め方としては、govern() でツールをラップしてポリシー実行と監査ログだけを回す最小構成から入り、マルチエージェント化やスケールに応じてレイヤーを足していくのが、設計思想にも沿った現実的な進め方です。ただし現時点ではPublic Preview段階のため、いきなり本番基盤として全面採用するのではなく、PoCのガバナンス設計で小さく試しながら見極めることをおすすめします。技術的なガードレールと組織のガバナンス体制をどう接続するかも含めて検討する場合は、社内AIガバナンス体制構築ガイドも合わせてご覧ください。