AI エージェントは、質問に答えることから行動を起こすことへと移行しています。
この変化一つで、リスクモデル全体が変わります。
チャットボットはテキストを生成します。エージェントはシステムを操作します。
メールを読み取り、API を呼び出し、顧客レコードを更新し、コードをデプロイし、チケットを作成し、ワークフローのステップを承認し、他のエージェントと連携し、新しい知識を長期記憶に保存することができます。
つまり、中核となる問いはもはや次のものではありません。
この回答は正しいか？
そうではなく、次の問いです。
このエージェントが今すぐ行動することを許可すべきか？
ガバナンスレイヤーが存在するのは、この問いに答えるためです。
1. メモリは有用ですが、ガバナンスではありません。
メモリは、エージェントがセッションをまたいでコンテキストを維持するのに役立ちます。
ユーザーの好み、過去の作業、ツールの出力、以前の判断を記憶するのに役立ちます。それは重要です。しかし、メモリは次のことを決定しません。
- どの事実をメモリに入力することを許可するか
- どのメモリが古いか、または汚染されているか
- どのアクションに承認が必要か
- どのワークフローステップを次に実行すべきか
- 実行前にどのような証明が必要か
- どのエージェントがどの情報を使用することを許可されているか
本番環境のエージェントシステムでは、より困難な問題は検索ではなく、権限であることがよくあります。
メモリはエージェントが記憶するのを助けます。
ガバナンスは、エージェントが何を行うことが許可されているかを選択するのを助けます。
この違いこそが、Marrow が位置する場所です。
Marrow は単なるメモリレイヤーではありません。これは、AI エージェント群のための判断レイヤーです。
2. 可観測性は過去を説明します。エージェントは未来の前に制御を必要とします。
可観測性は必要不可欠です。チームには、トレース、ログ、評価、アノテーション、アラート、ダッシュボードが必要です。
しかし、事後的な可視性では、悪質なアクションが発生する前に止めることはできません。
エージェントが安全でないコードをデプロイしたり、機密性の高いメールを送信したり、間違った支払いを承認したり、必須のワークフローステップをスキップした場合、ダッシュボードは後でインシデントを説明するかもしれません。しかし、それを必ずしも防ぐわけではありません。
影響の大きいワークフローでは、シグナルはアクションの前にエージェントに届かなければなりません。
- リスクレベル
- 必要な証明
- ポリシー制約
- オーナーの承認
- ロールバック計画
- 正確な次のステップ
- 許可、警告、レビュー、またはブロック
これが、可観測性とガバナンスの間のギャップです。
ダッシュボードは人間に情報を提供します。
ガバナンスは、エージェントが行動する前にエージェントに情報を提供します。
3. 評価はスナップショットです。本番環境はストリームです。
デプロイ前の評価は多くの障害をキャッチします。しかし、本番環境のエージェントは変化する環境に存在します。
プロンプトが変わります。ツールが変わります。API が変わります。データが変わります。ポリシーが変わります。群れの中の他のエージェントも変わります。
ある条件下ではエージェントがうまく機能することをベンチマークが示すかもしれません。本番環境は別の問いを投げかけます。
環境が変化しても、このエージェントは正しい判断をし続けるだろうか？
ツールを使用するエージェントに関する研究も、同じ方向性を示しています。
ToolEmu は、ハイステークスなツールを使用する言語モデルエージェントを研究し、エージェントの障害が深刻な現実世界の結果を生み出す可能性があることを示しています。AgentHarm と CUAHarm は、エージェントがツールを使用したりコンピュータを操作したりできるようになった場合の有害な行動に焦点を当てています。他の研究では、エージェントは抽象的にリスクを理解していても、具体的な軌道においてリスクのある行動を回避できない可能性があることが示されています。
教訓は実践的です。
安全性は、モデルだけ、あるいはベンチマークだけに存在することはできません。
本番環境のエージェントには、ランタイム制御が必要です。
4. ガバナンスは AI インフラストラクチャになりつつあります。
主要な AI ガバナンスフレームワークは、同じ考えに収束しつつあります。責任ある AI は運用可能にならなければなりません。
原則だけではありません。
ポリシー PDF だけではありません。
ダッシュボードだけではありません。
運用ガバナンスには以下が必要です。
- 文書化されたリスク管理
- 自動ログ記録
- 影響の大きい判断に対する人間の監視
- ライフサイクル全体にわたる品質管理
- システム動作のトレーサビリティ
- 上市後の監視
- 悪影響に対する説明責任
これは、NIST AI RMF、NIST の Generative AI Profile、ISO/IEC 42001、OECD AI 原則、EU AI 法、OWASP のエージェンティック AI リスク分類、および 2026 年の Five Eyes によるエージェンティック AI サービスに関するガイダンスにわたって見られます。
方向性は明確です。
エンタープライズ AI システムは、その運用寿命全体にわたって、証拠、制御、トレーサビリティ、および説明責任を必要とします。
AI エージェントにとって、これはガバナンスがランタイムに移行しなければならないことを意味します。
5. エージェントガバナンスレイヤーがすべきこと
ガバナンスレイヤーは、エージェントランタイムとエージェントが影響を与える可能性のあるシステムとの間の制御プレーンです。
エージェントの意図されたアクションを受け取り、ポリシー、権限、リスク、証明、および以前の結果に対して評価し、実行可能な決定を返します。
許可
警告
レビュー必要
ブロック
真剣なガバナンスレイヤーには、9 つの機能が必要です。
- アイデンティティとスコープ付き権限
すべてのエージェントには、明確なアイデンティティ、制限された権限、およびスコープ付きの認証情報が必要です。
すべてのエージェントが同じ API キーを共有している場合、群れを統制することはできません。
- ランタイムポリシー
ポリシーは実行可能なランタイム条件にならなければなりません。
どのステップが最初に来るか？
どの証明が必要か？
どのアクションが常にレビューを必要とするか？
どのアクションが自動的に実行されるべきでないか？
- リスクゲート
システムは、影響、回復可能性、機密性、およびビジネスコンテキストによってアクションを分類する必要があります。
低リスクの作業は自動的に実行される可能性があります。高リスクの作業は、証明、承認、またはブロックを必要とする場合があります。
- 証明パック
アクションの前に、エージェントは証拠を添付する必要があります。
例：
- テストカバレッジ
- ロールバック計画
- ポリシー条項
- 本人確認
- 臨床承認
- 請求書レビュー
- 上司の承認
- 承認ルーティング
人間によるレビューは、すべてに対する手動キューであるべきではありません。
エラーのコストが高いアクションに対する条件付きチェックポイントであるべきです。
- 監査と来歴
すべての決定はトレーサブルでなければなりません。
誰が開始したか？
なぜ許可またはブロックされたか？
どのポリシーが適用されたか？
どの証明が添付されていたか？
誰が承認したか？
次に何が起こったか？
- 結果のクロージャ
ガバナンスは許可またはブロックで終わりません。
システムはループを閉じなければなりません。
- アクションは成功したか？
- 失敗したか？
- ロールバックが必要だったか？
- 誰が承認したか？
- どの教訓を保存すべきか？
- メモリ書き込みガバナンス
すべてのログが知識であるとは限りません。
すべての知識がすべてのエージェントに影響を与えるべきではありません。
実際の結果は、制御された書き込みを通じてのみメモリになるべきです。
- 群れレベルの学習
ガバナンスレイヤーは、群れ全体の行動を追跡する必要があります。
- ベースラインワークフローからの逸脱
- リトライループ
- 繰り返される失敗
- 将来のエージェントに警告すべきパターン
これにより、ガバナンスは制限以上のものになります。それは学習になります。
6. ガバナンスのケーススタディとしての Marrow
Marrow は、シンプルな運用ループを中心に設計されています。
オリエント -> 思考 -> 行動 -> チェック -> コミット
各ステップにはガバナンス機能があります。
オリエントは、関連する履歴、警告、制約を表面化します。
思考は、意図されたアクションが実行される前に評価します。
行動は、コンテキストとガードレールを添付して実行します。
チェックは、証明またはクロージャが欠けているかどうかを検査します。
コミットは、結果を記録し、次の判断が改善されるようにします。
これがメモリと判断の核となる違いです。
メモリは問います。
エージェントは何を知っているか？
Marrow は問います。
エージェントは行動すべきか、そしてどのような条件下で行動すべきか？
そのプロダクトサーフェスは、ランタイムガバナンスに直接マッピングされます。
- decisionBrief() は、アクション前のコンテキストをエージェントに提供します。
- workflowGate() は、許可、警告、レビュー必要、またはブロックを返します。
- runGuarded() は、アクション前のガイダンスと結果クロージャでリスクの高い作業をラップします。
- agentRuntime() は、教訓と証明要件をエージェントコンテキストに注入します。
- agentStatus() は、Marrow がアクティブで有用なシグナルを収集しているかどうかを示します。
- valueReport() は、ガバナンスをオーナーが見える証明に変えます。
言い換えれば。
Marrow は、過去の結果をアクション前の判断に変えます。
7. 具体的な例: 不良デプロイ
支払い用 Webhook の変更をデプロイしようとしている CI/CD エージェントを想像してください。
ビルドはパスします。
ブランチの準備はできています。
エージェントは本番環境にプッシュしようとしています。
しかし、プルリクエストには 3 つのものが欠けています。
- テストカバレッジ
- ロールバック計画
- スモークテスト
ガバナンスがなければ、デプロイは実行されてしまうかもしれません。
数時間後に支払い障害が現れます。顧客が影響を受けます。オンコールエンジニアが手動でロールバックします。インシデントは別の事後分析になります。
ガバナンスがあれば、デプロイ前にワークフローゲートが実行されます。
それは以下を返します。
リスクレベル: 高
証明パック不足
デプロイブロック
エージェントは単により多くのログを記録しているわけではありません。正しい時点で停止することを強いられているのです。
これがアクション前ガバナンスの価値です。
8. エージェントガバナンスのための適切な指標
ガバナンスレイヤーは、ログをカウントするだけではありません。
群れがより安全に、より一貫性を持ち、監査しやすくなっているかどうかを測定する必要があります。
有用な指標は次のとおりです。
- アクションカバレッジ: いくつの高インパクトアクションがゲートを通過するか
- 証明完了率: 実行前に必要な証明を含むアクションの数
- 結果クロージャ率: 実際の結果でクローズされた決定の数
- 防止された再発障害: 既知の障害パターンが回避された頻度
- 逸脱の深刻度: エージェントが承認されたワークフローからどの程度離れるか
- 偽陽性率: ゲートがブロックしすぎる頻度
- 偽陰性率: 危険なアクションがすり抜ける頻度
- 監査再構築時間: 決定を説明するのにかかる時間
- 人間によるレビューの精度: 人間の承認が適切なアクションに使用されているかどうか
ガバナンスは、ロールバックを減らし、繰り返されるインシデントを防ぎ、不要なレビューを狭め、エージェントの動作を証明しやすくする場合に有用です。
そうでなければ、コンプライアンスの見せかけになります。
9. ガバナンスレイヤーにもリスクがあります
ガバナンスレイヤーもまた失敗する可能性があります。
誤って設定される可能性があります。ポリシーが古くなる可能性があります。証明が不完全になる可能性があります。ゲートがブロックしすぎる可能性があります。攻撃者が制御プレーンを標的にする可能性があります。機密データを保存しすぎると、リスク集中ポイントになります。
したがって、ガバナンスレイヤー自体にも規律が必要です。
- デフォルトで最小権限 エージェントは、必要な期間に、必要な権限のみを受け取るべきです。
- 高インパクトアクションではフェイルクローズ アクションが深刻な害を引き起こす可能性がある場合、証明が不足していれば実行を停止する必要があります。
- 低リスク自動化ではフェイルソフト すべてのアクションが同じレベルの摩擦に値するわけではありません。
- 人間が読める証拠、機械が読めるポリシー オペレーターは決定を理解できる必要があります。システムはそれを強制できる必要があります。
- 実際の結果から学習する 結果クロージャがなければ、システムは判断ではなくログを蓄積します。
10. 結論
AI エージェントは、ソフトウェアを新しい運用モデルに押し上げます。
ツールを選択し、他のエージェントと連携し、システムを変更し、結果を生み出すことができます。
そのモデルでは、ガバナンスはデプロイ後に追加されるレイヤーではありません。ランタイムの内部に属します。
メモリ、可観測性、評価、人間によるレビューはすべて重要です。しかし、それぞれが問題の一部しか解決しません。
ガバナンスレイヤーはそれらを説明可能なアクションループに接続します。
アクション前のポリシー、実行前の証明、アクション中の権限、アクション後の結果、群れ全体の学習
これが Marrow の背後にあるテーゼです。
AI エージェント群は、単により多くを記憶する必要があるだけではありません。
行動する前に、より良い判断を必要としています。
参考文献
- NIST. AI リスクマネジメントフレームワーク
- NIST. 生成 AI プロファイル、NIST AI 600-1
- OECD. OECD AI 原則
- 欧州委員会 AI 法サービスデスク. 第 9 条: リスク管理体制
- 欧州委員会 AI 法サービスデスク. 第 12 条: 記録保持
- 欧州委員会 AI 法サービスデスク. 第 14 条: 人間による監視
- 欧州委員会 AI 法サービスデスク. 第 17 条: 品質管理体制
