この記事は、複数部署からAIエージェントの開発要求が上がってきたとき、それをどう受け付け、レビューし、公開し、廃止するかの体制設計を担う情シス責任者・DX推進担当・CIOを対象にしています。個々のエージェントが安全かどうかのテスト設計は、姉妹記事の AIエージェントのポリシー評価と回帰テスト で扱っています。

Microsoft Build 2026：「Agent Factory」とは何か

2026年6月2日のMicrosoft Build 2026では、企業が多数のAIエージェントを継続的に開発・管理する流れが示されました。エージェントを工場のラインのように量産・運用する考え方を支える基盤の一つが、2026年4月2日にオープンソースで公開されたAgent Governance Toolkitです。同ツールキットはMITライセンスで提供され、複数のパッケージで構成されます。主要な構成要素には次のものがあります（Microsoft Open Source Blog、2026年4月2日）。

要素機能
Agent OSエージェントの動作を実行前に検証するポリシーエンジン（YAML／OPA Rego／Cedarに対応）
Agent Meshエージェント間の暗号化された通信と動的な信頼スコアリング
Agent SRESLO・エラーバジェットによる稼働品質管理
Agent Compliance規制フレームワークへの準拠状況を自動検証

なお、エージェントのポリシーをYAMLで定義しフレームワークをまたいで持ち運ぶ仕様としては、別途Agent Control Specification（ACS）が公開されています。

ポイントは、エージェントを一個ずつ個別管理するのではなく、工場のラインのように受付・レビュー・公開・廃止の流れを仕組みとして持つことです。工場の「生産管理」がなければ、どれが本番稼働中で、どれが誰の承認で動いているかが見えなくなります。

量産前に決める6つの基本設計

エージェントが1部署に1つ増えるたびに後付けで設計するのではなく、最初に組織全体の受付ルールを決めます。

設計項目決めること未設計のままだと起きること
受付窓口開発要求を誰が受け取り、誰が優先順位をつけるか類似エージェントが複数部署で並走・費用が膨らむ
安全レビューACSポリシーと入力禁止データを誰が審査するか機密情報を扱うエージェントが無審査で公開される
公開承認本番リリースに誰のサインオフが必要か業務責任者が知らないまま本番稼働が始まる
ログ・監査何を記録し、誰が確認し、何か月保存するか取引先審査・事故調査でログを出せない
廃止基準どの条件でエージェントを停止・削除するか使われていないエージェントが課金を続ける
費用帰属どの部署のどのエージェントがいくら使っているかを追えるか月末に「誰が承認した費用か」が分からなくなる

開発受付から廃止までの5段階フロー

ステップ1：開発要求の受付と業務要件の確認

業務部門から「このエージェントを作りたい」という要求が来たとき、最初に確認するのは機能の詳細ではありません。①対象業務と対象外業務の境界線、②扱うデータの機密分類、③成功条件の定義を一枚のシートで確認します。ここが曖昧なままPoC に進むと、試作物を捨てるか、要件変更コストが膨らみます。

ステップ2：安全レビューとACSポリシー作成

情シスと法務が合同で、エージェントが扱うデータ・権限・外部連携・ログ設計をレビューします。ACSポリシーファイルを作成し、禁止行動・承認条件・ログ要件を明文化します。ここは開発会社任せにせず、自社が所有する文書として管理します。

ステップ3：PoCと品質テスト

ASSERTフレームワークを使い、禁止ケース・権限逸脱・例外処理の3カテゴリを最低でも各30ケース実行します。合格条件は禁止ケースの全件停止と例外処理の確認返答率90%以上です。PoCでは「動いた」だけでなく「動いてはいけないことをしなかった」を確認します。

ステップ4：公開承認と本番移行

業務責任者・情シス・法務の3者がサインオフします。承認記録はAgent Governance Toolkitまたは社内ドキュメント管理ツールに残します。移行後2週間は日次でログを確認します。

ステップ5：定期レビューと廃止判断

四半期ごとに稼働中エージェントの一覧を見直します。月次APIコストが導入時の見積もりを20%超えた、利用部署から問い合わせが止まった、参照文書が大幅に更新されたのいずれかに該当した場合は廃止または更新の検討を開始します。

Agent Factory運用で失敗しやすい3パターン

所有者を決めないまま横展開する

AI・SaaS・データ基盤は部署横断になりやすく、所有者が決まらないと問い合わせ・障害・費用管理が宙に浮きます。業務部門・情シス・法務・外部委託先の責任をRACI表で分け、最終判断者を文書化します。

ログを後回しにする

ログは事故後に急に必要になります。後から追加すると実装も運用も重くなります。何を記録し、誰が参照でき、何か月保存するかを受付時点で決めます。レビュー頻度・例外承認・削除手順まで一体で設計しないと、監査では「ログがある」だけでは不十分です。

教育を使い方説明で終わらせる

必要なのは、禁止事項・例外時の相談先・誤回答時の停止手順・費用超過時の対応です。入力してよい情報・確認が必要な出力・顧客に転記してはいけない内容を、具体的なシナリオ例で示します。

RACIモデル：役割別の責任分担

工程業務部門情シス法務外部ベンダー
開発要求・要件定義R（実行）C（助言）C（助言）I（情報共有）
安全レビュー・ACS作成C（確認）R（実行）R（実行）I（情報共有）
PoC・品質テストA（承認）R（実行）C（確認）R（実行）
公開承認A（承認）A（承認）A（承認）—
運用・モニタリングC（確認）R（実行）—C（実行）
廃止判断R（提案）A（承認）C（確認）—

AIエージェント導入readiness診断で、このRACIモデルをどこまで整備できているかを確認できます。

GXOはどう支援するか

GXOでは、エージェントを1つ動かすPoC支援だけでなく、複数エージェントが並走する組織での受付・レビュー・承認・廃止フローの設計と、Agent Governance Toolkitの導入支援を行います。初回相談では、現在の開発要求件数・稼働中エージェントの数・情シスの体制・法務の関与レベルを確認し、過不足のない運用モデルを提案します。AIガバナンスの実務ガイドの内容と合わせて、稟議資料に落とせる形でお手伝いします。

よくある質問

Q1. エージェントが3つ以下の段階でも体制設計は必要ですか

今は少なくても、承認の仕組みがないまま増やすと後から標準化が困難になります。受付窓口と公開承認の2工程だけでも先に決めておくと、組織に合わせて段階的に拡張できます。

Q2. Agent Governance ToolkitはAzure以外でも使えますか

MIT ライセンスのオープンソースです。AWS・GCP・オンプレミス環境でも導入でき、LangChain・CrewAI・Semantic Kernelなど主要フレームワークと組み合わせて使えます。

Q3. 既存ベンダーに運用を丸投げしても大丈夫ですか

実装はベンダーに任せられますが、業務責任・顧客説明・社内教育・廃止判断は自社側に残ります。ベンダーが変わったときに業務が止まらないよう、ACSポリシーとテストスクリプトを自社資産として管理することを推奨します。

参考情報

  • Microsoft Open Source Blog「Introducing the Agent Governance Toolkit: Open-source runtime security for AI agents」：https://opensource.microsoft.com/blog/2026/04/02/introducing-the-agent-governance-toolkit-open-source-runtime-security-for-ai-agents/
  • Microsoft Foundry Blog「Build agents you can trust across any framework with open evals and a control standard」：https://devblogs.microsoft.com/foundry/build-2026-open-trust-stack-ai-agents/
  • 総務省・経済産業省「AI事業者ガイドライン（第1.2版）」（2026年3月31日）：https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/pdf/20260331_1.pdf

AIエージェント工場の運用体制設計を相談しませんか

GXOでは、開発受付から廃止までのオペレーティングモデル設計、Agent Governance Toolkitの導入支援、RACI作成と稟議資料への展開を支援します。

エージェント運用体制の設計を相談する