エージェント統治のFail-Closedゲート設計: 責任分解と最適エスカレーション

要旨

エンタープライズ AI エージェントは、本番リポジトリのソース コードの変更、金融取引をトリガーする外部 API 呼び出しの実行、自動調達パイプラインでの契約条件の変更など、取り返しのつかない結果をもたらすアクションを実行することが増えています。これらのアクションはそれぞれ 意思決定ノード、つまり実行責任と結果責任が分岐するポイントを構成します。何か問題が発生した場合、エージェントが間違いを犯したかどうかが問題になることはありません。それは人間にそれを防ぐ機会があったのにそれをしなかったのか、それともシステムがその機会を完全に拒否したのかということである。

この論文では、フェイルクローズド・ゲートを、マルチエージェント・ガバナンス・システムにおける責任分解のための最小限のアーキテクチャー・プリミティブとして形式化します。ゲート障害がデフォルトでアクションを許可するフェールオープン設計とは異なり、フェールクローズド ゲートは、不確実性が設定されたしきい値を超えると実行を停止し、不可逆的なアクションを続行する前に人間によるレビューを強制します。私たちは、責任を意思決定ノードごとに 6 つの連続変数 (影響、リスク、自動化レベル、人間の介入確率、ゲート強度、証拠の十分性) に分解する数学的フレームワークを導入します。

私たちは、結果責任が実行責任を超えるとき、つまり組織が監査可能性を失う正確な条件を定量化する 責任シフト 指標 RS を導き出します。次に、ゲートの最適化を制約付き最小化問題として定式化します。つまり、総遅延バジェットに従うすべての決定ノードにわたる予想損失を最小化し、KKT 条件を使用したラグランジュ双対によって解決します。シグモイド人間介入モデルは、実際にゲートの強さが人間のエスカレーションをどのように誘発するかを捉えています。

3 つのリスク層 (コード変更、API 実行、コントラクト変更) にわたる内部シミュレーションでは、フェールクローズ ゲートが適度なレイテンシ オーバーヘッドで高い誤実行防止を達成できることが示唆されています。この記事の後半で使用する例示的なキャリブレーションでは、H = 30% 人間 / 70% エージェントの組み合わせにより、責任範囲が維持され、人間による完全なレビューと比較してエンドツーエンドの意思決定の待ち時間が短縮されました。責任シフト スコア RS は、テストされた構成全体で設計目標の 0.05 を下回ったままでした。

この研究の核となる洞察は、フェールクローズド ゲートは主に AGI レベルの存続リスクを軽減するためのものではないということです。これらは、責任分解点の管理に関するものであり、すべての自動化された意思決定に明確に定義された所有者、追跡可能なエスカレーション パス、および測定可能な安全マージンが確保されていることを保証します。これは企業が今日直面しているエンジニアリングの問題であり、ここで紹介する数学で解決できます。

1. はじめに

エンタープライズ環境に自律型 AI エージェントを導入すると、ガバナンスの空白が生じます。従来のソフトウェア システムは決定論的ロジックを実行します。同じ入力が与えられると、同じ出力が生成され、コードを作成した開発者はその動作に対して明確な責任を負います。 AI エージェントはこの契約を破ります。彼らは状況に応じた決定を下し、新しい出力を生成し、開発者が設計時に完全には予想できなかったアクションを実行します。責任の問題は深刻になります。

企業組織が日常的に直面する 3 つの具体的なシナリオを考えてみましょう。

• コードの変更: AI コーディング エージェントは、運用マイクロサービスへの変更を提案します。この変更は自動テストには合格しましたが、高負荷時に微妙な競合状態が発生します。トラフィックのピーク時にサービスが低下し、230 万ドルのトランザクション損失が発生します。責任者は誰ですか? エージェント、PR を承認したエンジニア、エージェントの権限を設定したチーム リーダー、または PR を導入した組織?
• 外部 API の実行: AI 調達エージェントはサプライヤーの API を呼び出し、需要予測に基づいて原材料 45 万ドルの発注書を出します。予測は古いデータに基づいているため、注文をキャンセルすることはできません。エージェントは設定されたパラメータ内で動作しました。経済的損失は誰が負担するのでしょうか?
• 契約変更: AI 法務代理人は、キャッシュ フローの最適化に基づいて、ベンダー契約の支払い条件を純額 30 ドルから純額 60 ドルに変更します。ベンダーはエスカレートし、戦略的パートナーシップを終了すると脅迫しました。エージェントの行動は技術的には最適でしたが、戦略的には壊滅的でした。人間関係の損害は誰の責任ですか?

いずれの場合も、エージェントは目的関数に従って正しく実行されました。失敗はエージェントのロジックにあるのではなく、人間による適切なチェックポイントなしで影響が大きく、取り消し不能なアクションを許可していた ガバナンス アーキテクチャにあります。これは、AGI レベルのリスク軽減を必要とする将来の問題ではありません。これは、正確な責任分解を必要とする現在のエンジニアリング問題です。

フェールオープン パラダイム (ゲートが不確実性に遭遇したときのデフォルトの動作はアクションを許可する) が、現在のエージェント フレームワークを支配しています。この設計の選択により、監査可能性を犠牲にしてスループットが最適化されます。フェールオープン ゲートが境界線のリスク スコアに達すると、アクションが許可されます。組織が問題を発見するのは被害が発生した後であり、人間が介入する機会がなかったことが死後の解剖によって明らかになります。

私たちは、フェイルクローズ という代替案を提案します。ゲートが不確実性に遭遇すると、実行を停止し、人間にエスカレーションします。これは保守的な設計哲学ではなく、責任範囲を維持するための数学的必然性です。フェールクローズが厳密に必要となる条件は責任シフトメトリクスによって正確に定式化され、最適なゲート構成が分析的に計算できることを示します。

この論文の貢献は次のとおりです。

• A formal responsibility decomposition framework with six continuous variables per decision node
• The Responsibility Shift metric RS that detects when automation exceeds auditability
• A constrained optimization formulation for gate strength allocation
• ゲートの活性化によって引き起こされる人間の介入のシグモイド モデル
• 精度、責任、スループットのバランスをとった最適な人間/エージェント比率分析
• エンタープライズ スタイルのワークロードを使用した 3 つのリスク層にわたる内部シミュレーション

この文書の残りの部分は次のように構成されています。セクション 2 では、責任分解フレームワークを紹介します。セクション 3 では、実行責任と結果責任を区別します。セクション 4 では、責任の転換の問題を形式的に説明します。セクション 5 では、フェールクローズド ゲート アーキテクチャについて説明します。セクション 6 では、ゲート最適化の定式化を導き出します。セクション 7 では、人間の介入をゲート強度の関数としてモデル化します。セクション 8 では、人間とエージェントの最適な比率を分析します。セクション 9 では、実際的なゲート構成について説明します。セクション 10 では、安全性スコアの複合指標を設計します。セクション 11 では実験計画について説明します。セクション 12 では、予想される結果を示します。セクション 13 では MARIA OS の実装について詳しく説明します。セクション 14 ではその影響について説明し、セクション 15 で結論を述べます。

2. 責任分解フレームワーク

まず、マルチエージェント システムにおける責任の帰属を管理する数学的オブジェクトを定義します。私たちのフレームワークは、責任をバイナリのラベル (人間か機械か) としてではなく、意思決定ノード全体に分散される連続量として扱います。

2.1 意思決定ノードと変数の定義

システムに、i = 1、2、...、N でインデックス付けされた N 個の意思決定ノードが含まれているとします。各ノードは、エージェントが観察可能な結果を​​生み出すアクションを実行するポイントを表します。各決定ノード i で、6 つの連続変数を定義します。

• I_i ∈ [0,1] — 影響: ノード i でのアクションが意図しない結果を生み出した場合の影響の大きさ。 I_i = 0 はアクションが重要ではないことを意味します。 I_i = 1 は、そのアクションが組織に最大の損害を与える可能性があることを意味します。
• R_i ∈ [0,1] — リスク: システムの現在の状態を条件として、ノード i でのアクションが意図しない結果を生み出す確率。 R_i = 0 は、アクションが決定論的に安全であることを意味します。 R_i = 1 は失敗が確実であることを意味します。
• a_i ∈ [0,1] — 自動化レベル: ノード i でのアクションが人間の介入なしに自律エージェントによって実行される程度。 a_i = 0 は完全に手動であることを意味します。 a_i = 1 は完全に自動化されていることを意味します。
• h_i ∈ [0,1] — 人間の介入確率: 実行前に人間がノード i でのアクションをレビューして承認する可能性。 h_i = 0 は人間によるレビューがないことを意味します。 h_i = 1 は人間による強制的な承認を意味します。
• g_i ∈ [0,1] — ゲート強度: ノード i におけるガバナンス ゲートの強度。 g_i = 0 はゲートなし (パススルー) を意味します。 g_i = 1 は、完全な証拠要件を備えた最大限のゲート精査を意味します。
• e_i ∈ [0,1] — 証拠の十分性: ノード i で利用可能な証拠が意図したアクションをサポートする度合い。 e_i = 0 は裏付けとなる証拠がないことを意味します。 e_i = 1 は完全な証拠の裏付けを意味します。

これら 6 つの変数は、各ノードの 責任状態ベクトル を形成します。

完全なシステム状態は、すべてのノード責任ベクトルの集合です: R = {r_1, r_2, ..., r_N}。

2.2 変数の意味論と測定

各変数には、展開されたシステム内の測定可能な量にマッピングされる具体的な操作定義があります。

衝撃 (I_i) はアクションの爆発半径から計算されます。コード変更の場合、I_i は、依存するサービスの数、変更されたパスを通過するトランザクション量、および変更の可逆性と相関します。テスト環境での 1 行のログ変更では I_i = 0.02 になる可能性がありますが、1,000 万ユーザーにサービスを提供する運用データベースでのスキーマ移行では I_i = 0.95 になる可能性があります。

リスク (R_i) は、過去の故障率、モデルの信頼スコア、環境の変動性から推定されます。安定したシステム状態で十分にテストされた API 呼び出しを実行するエージェントの R_i = 0.03 は、上流の依存関係が低下した部分的な停止中の同じ呼び出しの R_i = 0.62 になる可能性があります。

自動化レベル (a_i) は、ノードにおけるエージェントの自律性の程度を反映する構成パラメータです。完全に手動のワークフローでは、a_i = 0 になります。エージェントが行動し、人間が拒否できる人間オンザループ構成では、a_i は 0.8 になる可能性があります。完全自律型パイプラインでは、a_i = 1.0。

人間の介入 (h_i) は、ゲートの強度、リスク スコアリング、および組織のポリシーに依存する導出量です。セクション 7 では、h_i がゲート強度 g_i のシグモイド関数として適切にモデル化されていることを示します。

ゲート強度 (g_i) は主な制御変数です。決定ノードでどの程度の精査が適用されるかを決定します。ゲート強度が低いということは、エージェントのアクションが最小限のチェックで通過することを意味します。ゲート強度が高いということは、広範な検証、証拠収集、および人的エスカレーションの可能性を意味します。

証拠十分性 (e_i) は、ノードにおける認識論的状態を捉えます。エージェントがそのアクションに高い信頼性を持っている場合 (強力な裏付けデータ、成功したドライラン、一貫した履歴結果)、e_i は 1 に近づきます。エージェントが新しい条件または矛盾する信号で動作する場合、e_i は 0 に近づきます。

2.3 責任の多様性

6 次元の単位超立方体 [0,1]^6 には、考えられるすべての責任構成が含まれています。ただし、すべての構成が物理的に実現できるわけではありません。たとえば、g_i が 0 の場合、h_i を高くすることはできません (ゲートがない場合は人間によるエスカレーション メカニズムがないことを意味します)。同様に、a_i と h_i は実際には逆相関しています。一般に、高度な自動化は人間の介入が低いことを意味します。

これらの制約は、ハイパーキューブ内の 責任多様体 M を定義します。実行可能領域は次のような特徴があります。

• 単調増加関数 f の場合、h_i <= f(g_i) (人間の介入にはゲート メカニズムが必要)
• a_i + h_i <= 1 + epsilon (自動化と人間の介入はほぼ補完的です)
• e_i は a_i から独立しています (証拠の質はアクションの実行者に依存しません)

エンジニアリング上の問題は、予想される損失を最小限に抑え、遅延を最小限に抑え、責任範囲を最大化するという多目的基準を最適化するこの多様体上の操作点を選択することです。

3. 2 種類の責任

既存のエージェント ガバナンス フレームワークが認識できていない重要な違いは、実行責任と結果責任の間です。これら 2 つの量は発散する可能性があり、その発散はまさにガバナンスの失敗を引き起こす条件です。

3.1 執行責任

実行責任は、(エージェントではなく) 人間がアクションを実行する程度を測定します。 a_i = 0 (完全手動)、ExecResp_i = 1 の場合、人間がアクションの実行に全責任を負います。 a_i = 1 (完全自動)、ExecResp_i = 0 の場合、エージェントがアクションを実行し、人間はその実行に直接責任を負いません。

この定義は、単純だが重要な直観を捉えています。つまり、アクションを実行しなかった場合、そのアクションに対する実行責任を負うことはできません。 AI エージェントがコミットしたコードを一度も見たことがないエンジニアは、組織のポリシーが何であろうとも、そのコードを書く責任を負うことはできません。

3.2 結果に対する責任

結果責任はさらに複雑です。たとえ人間がその行動を実行しなかったとしても、人間にそれを阻止する機会があったのにそれを選択しなかった場合、またはその行動を許可するシステムを設計した場合には、依然としてその結果に対して責任を負う可能性があります。

責任ロック L_i ∈ [0,1] は、結果責任のどの程度が責任のある当事者に「ロック」されているかを測定します。 h_i = 1 (人間の承認が必須) の場合、ゲートの強度に関係なく、L_i = 1 になります。承認した人間が全結果責任を負います。 h_i = 0 であるが g_i > 0 の場合、ゲート自体が部分責任ロックを提供します。システムのガバナンス メカニズムが責任帰属の一部を引き受けます。

L_i の背後にある直観は、責任は誰かまたは何かに割り当てられる必要があるということです。人間の介入は、人間がアクションを明示的に承認するため、責任ロックの最も強力な形式です。ゲートの強度は、弱いながらも意味のある形式を提供します。ゲートを設計および構成した組織は、ゲートを通過するアクションに対して責任を負います。

結果責任は、アクションの影響力 (I_i)、リスクの度合い (R_i)、および責任が当事者にどの程度限定されているか (L_i) の 3 つの要素の積です。強力な責任ロックを伴う影響が大きくリスクの高いアクションは、結果に対する高い責任を生み出します。つまり、誰かが明確に責任を負います。責任ロックが弱い、影響が大きくリスクの高いアクションは、結果に対する責任が低くなります。これはまさに危険な状態です。

3.3 責任のギャップ

結果責任と実行責任の間のギャップにより、意思決定ノードのガバナンスの健全性が明らかになります。

• OutcomeResp_i <= ExecResp_i の場合、ノードは 適切に管理されています。行動を実行する人は、その結果に対して少なくとも同等の責任を負います。
• OutcomeResp_i > ExecResp_i の場合、ノードには 責任ギャップ があります。行為の結果は実行者の責任を超えます。これは、高度に自動化された (a_i が高く) 影響力の高い (I_i が高い) アクションの責任ロックが弱い (L_i が低い) 場合に発生します。

責任のギャップは、単なる会計上の抽象概念ではありません。これは運用上の直接的な影響を及ぼします。責任のギャップがあるノードで何か問題が発生した場合、事後分析では責任のある当事者を特定できません。エージェントは、設定されたとおりのことを実行しました。人間はそれをレビューしませんでした。ゲートが弱すぎて捕まえられませんでした。責任は蒸発し、組織には失敗から学ぶ仕組みがありません。

4. 責任転嫁問題

実行と結果の責任が正式に定義されたことで、責任シフト指標を介してシステムレベルのガバナンスの健全性を定量化できるようになりました。

4.1 正式な定義

RS は、すべての意思決定ノードにわたる責任のギャップを集約します。各ノードのギャップは max(0, OutcomeResp_i - ExecResp_i) です。実行責任が結果責任を超えるノードは、RS への寄与がゼロになります (管理が不十分ではなく、過剰に管理されます)。真の責任ギャップ（結果の賭け金が執行者の責任を超えている場合）を持つノードのみが合計に寄与します。

4.2 解釈

RS = 0 は、システムが 完全な責任範囲 を持っていることを意味します。つまり、すべての意思決定ノードには、結果責任が実行責任を超えないことを保証するための十分な人間の関与、ゲート強度、または証拠があります。これは、すべての行動が人間によって承認されるという意味ではありません。これは、すべての自動化されたアクションが、低影響、低リスク、または強力なガバナンス メカニズムによって自動化が正当化される体制で動作することを意味します。

RS > 0 は、システムに 責任漏洩 があることを意味します。エージェントが適切なガバナンスなしで影響が大きくリスクの高いアクションを実行する意思決定ノードが存在します。 RS の大きさは、漏洩された責任の総量を定量化します。

4.3 自動化が進む中での RS ダイナミクス

組織が自動化を増やすと (ノード全体で a_i を増やすと)、ExecResp_i = (1 - a_i) が減少するため、RS は増加する傾向があります。自動化を強化しながら RS をしきい値未満に維持する唯一の方法は、責任のギャップが拡大するノードでのゲート強度 g_i と人間の介入 h_i を同時に増やすことです。

これにより、基本的なトレードオフが生じます。自動化を進めると、ガバナンスが低下するのではなく、より多くのガバナンスが必要になります。ゲート インフラストラクチャを比例的に強化せずに自律エージェントを導入した組織では、RS がしきい値を超え、監査可能性が失われ、規制や運用上の危険にさらされることになります。

4.4 しきい値の選択

RS のしきい値は、組織のリスク許容度と規制環境によって異なります。実験的評価では、目標しきい値として RS < 0.05 を使用します。これは、総責任漏れが理論上の最大値の 5% 未満でなければならないことを意味します。規制された業界 (金融サービス、ヘルスケア、防衛) では、RS < 0.01 が適切な場合があります。外部からの影響が少ない内部工具の場合は、RS < 0.10 で十分な場合があります。

重要な洞察は、RS は測定可能、監視可能、そして実用的であるということです。 RS がしきい値を超えると、システムは寄与するノードのゲート強度を自動的に増加させることができます。これは自己修正ガバナンス メカニズムです。

5. フェールクローズドゲートアーキテクチャ

5.1 設計原則

フェールクローズ ゲートは、単一の動作不変条件によって定義されます。ゲートがアクションが安全かどうかを判断できない場合、アクションを拒否します。これは、不確実性が高い場合にデフォルトでアクションを許可するフェールオープン ゲートとはまったく対照的です。

フェールクローズの不変条件には、次の 3 つの具体的な意味があります。

• デフォルトの拒否: リスク スコアリング システムが利用できない場合、ゲートは最小影響しきい値を超えるすべてのアクションをブロックします。システムは、安全ではなく安全に劣化します。
• 証拠要件: ゲートには、危険の証拠がないことよりも、安全性の明確な証拠 (e_i が閾値を超える) が必要です。これにより、立証責任は代理人に移されます。
• エスカレーション保証: ゲートがアクションをブロックする場合、意思決定のコンテキスト、リスク評価、推奨されるアクションを含む人間が判読できるエスカレーション リクエストを生成する必要があります。ゲートは単にブロックするだけではなく、人間に責任を移します。

5.2 ゲート評価パイプライン

各決定ノード i でのゲート評価パイプラインは次のように処理されます。

• ステップ 1 — リスク スコアリング: 影響評価とリスク評価から複合リスク スコア S_i = I_i x R_i を計算します。
• ステップ 2 — 証拠チェック: 利用可能な監査証跡、テスト結果、モデルの信頼性から証拠の十分性 e_i を評価します。
• ステップ 3 — しきい値の比較: S_i > theta_i (ノードのエスカレーションしきい値) の場合は、ステップ 4 に進みます。そうでない場合は、アクションを許可します。
• ステップ 4 — ゲート適用: ゲート強度 g_i を適用します。 g_i x (1 - e_i) > デルタ (ゲート アクティベーションしきい値) の場合、人間にエスカレーションします。それ以外の場合は、ゲートログを使用して許可します。
• ステップ 5 — 人間によるエスカレーション: 責任ある人間に決定のコンテキストを提示します。承認、変更、または拒否を待ちます。決定を完全な証拠とともに記録します。

5.3 エスカレーションしきい値の設計

各ノードのエスカレーションしきい値 theta_i は固定定数ではありません。これは、ノードの責任状態ベクトルから動的に計算されます。

ここで、theta_base はデフォルトのしきい値 (例: 0.7)、theta_min は最小しきい値 (例: 0.2) です。ゲート強度が高いほどしきい値が低くなり、エスカレーションが発生しやすくなります。これにより、強力にゲートされたノードがリスク信号に対してより敏感になることが保証されます。

5.4 フェールクローズとフェールオープン: 正式な比較

|プロパティ |フェールオープン |フェールクローズ |

|---|---|---|

|不確実性に対するデフォルトの動作 |アクションを許可する |ブロックアクション |

|リスクスコアリング失敗モード |アクションはスコアなしで続行されます。スコアが回復するまでアクションは停止します |

|証拠負担 |エージェントは証拠がなくても行動できる |エージェントは明確な証拠を提供する必要があります |

|責任の帰属 |責任のギャップが生じる可能性 |責任は常に割り当てられます |

|スループットへの影響 |遅延を最小限に抑える | +340ms 平均オーバーヘッド |

|監査の完全性 |障害時に発生する可能性のあるギャップ |完全な監査証跡を保証 |

|障害時の RS の動作 | RSが増加（責任漏れ） | RS は制限されたままになります (責任は維持されます)。

+340ms のレイテンシ オーバーヘッドは、フェールクローズ設計のコストです。影響が少なく、頻度の高いアクション (ログのフォーマット、変数の名前変更など) の場合、このオーバーヘッドは許容できない場合があります。影響が大きく、元に戻せないアクション (本番環境への展開、金融取引、契約の変更など) の場合、340 ミリ秒は、誤実行のコストに比べれば無視できます。

5.5 3 段階のリスク分類

当社では、エージェントのアクションをその影響と可逆性に基づいて 3 つのリスク層に分類しています。

|階層 |衝撃範囲 |可逆性 |ゲート要件 |アクションの例 |

|---|---|---|---|---|

|ティア 1 (低) | I_i < 0.3 |簡単にリバーシブル |最小ゲート (g_i ~ 0.1) |コードのフォーマット、コメントの更新、テストの追加 |

|レベル 2 (中) | 0.3 <= I_i < 0.7 |部分的にリバーシブル |標準ゲート (g_i ~ 0.5) | API パラメーターの変更、構成の更新、重要ではないデプロイメント |

|レベル 3 (高) | I_i >= 0.7 |取り消し不能または費用がかかる |最大ゲート (g_i ~ 0.9) |運用スキーマの移行、金融取引、契約の変更 |

各層は責任多様体の異なる領域にマッピングされ、最適なゲート構成はそれに応じて異なります。

6. ゲートの最適化 — ラグランジュの定式化

ゲート アーキテクチャを定義したら、次は中心的な最適化問題に取り組みます。総遅延バジェットに応じて予想される損失を最小限に抑えるために、デシジョン ノード全体にゲート強度をどのように割り当てるべきかということです。

6.1 損失関数

ここで、P0_i は基本失敗確率 (ゲートが適用されず証拠が考慮されない場合の誤実行の確率)、alpha > 0 はゲート有効性パラメータ (ゲート強度の各単位が失敗確率をどの程度低下させるか)、beta > 0 は証拠有効性パラメータ (証拠の十分性の各単位が失敗確率をどの程度低下させるか) です。

指数形式は収益逓減を捉えます。ゲート強度の最初の増加で損失が最大に減少し、その後の増加で減少が徐々に小さくなります。これは経験的に検証されており、最初の自動チェックで最も多くのエラーが検出され、追加のチェックでは限界値が減少します。

6.2 遅延機能

ここで、D0_i は基本処理時間 (ガバナンスとは独立したアクション自体の時間)、D1_i はゲート遅延係数 (ゲート強度の単位あたりの時間、自動チェックを反映)、D2_i は人間による遅延係数 (人間による介入確率の単位あたりの時間、人間によるレビュー時間を反映) です。

遅延関数は g_i と h_i で線形ですが、これは簡略化したものです。実際には、人間による遅延は非常に変動しやすいです (単純な承認には数秒かかる場合もありますが、複雑なレビューには数時間かかる場合もあります)。扱いやすさのために線形近似を使用しており、実際の遅延分布が非線形である場合でも、最適化の結果は有用な境界を提供することに注意してください。

6.3 制約付き最適化問題

ゲート最適化問題は次のとおりです。

ここで、T_budget は合計遅延バジェット、つまり単位時間あたりのすべての意思決定ノードにわたる最大許容合計遅延です。この定式化は、遅延と損失の削減をトレードオフします。つまり、ゲートが強化されると損失は削減されますが、遅延が増加します。また、制約により、遅延の合計が動作範囲内に収まることが保証されます。

6.4 ラグランジュ双対

ラグランジュ双対を介して制約付き問題を解決します。ラグランジアンは次のとおりです。

ここで、lambda >= 0 は遅延制約のラグランジュ乗数です。乗数ラムダには直接的な経済的解釈があります。つまり、遅延の影の価格、つまり、追加の遅延予算の単位当たりの予想損失の限界減少です。

6.5 一次最適性条件

g_i に関して L の導関数を取得し、それをゼロに設定します。

これにより、次の最適条件が得られます。

これは制約付き最適化の標準的な KKT 条件ですが、ゲート設計コンテキストでの解釈は強力です。これは、遅延バジェットのすべてがノードで費やされ、予想される損失が最大に削減されるときに、最適なゲート割り当てが達成されることを示しています。

6.6 固定 h_i の解析解

人間の介入 h_i が外生的 (ゲート強度から導出されるのではなくポリシーによって固定される) として扱われる場合、遅延関数は g_i のみで線形になり、dDelay_i/dg_i = D1_i になります。最適性条件は次のように単純化されます。

g_i* を解くと、次のようになります。

各ノードの最適なゲート強度は、ノードの基本故障確率 (証拠として調整) とシャドウプライスのゲート遅延の比の対数になります。基本故障確率が高く、証拠十分性が低いノードは、より強力なゲートを取得します。失敗の可能性が低い、または証拠が高いノードは、より弱いゲートを取得します。シャドウ価格 lambda は、補完的なスラックネス条件 lambda (Sigma_i Delay_i(g_i*) - T_budget) = 0 によって決定されます。

6.7 数値解法戦略

h_i が g_i に依存する場合 (セクション 7 のシグモイド モデルのように)、最適化問題は非線形になり、数値的に解決されます。標準的なアプローチは次のとおりです。

• すべての i に対して g_i = 0.5、lambda = 1.0 を初期化します。
• Iterate gradient descent on the Lagrangian with respect to g_i
• Update lambda via dual ascent: lambda <- max(0, lambda + eta (Sigma_i Delay_i - T_budget))
• Converge when primal feasibility (Sigma_i Delay_i <= T_budget) and dual feasibility (complementary slackness) are satisfied

実際には、N < 1000 の決定ノードを持つシステムでは 50 ～ 200 回の反復で収束が達成され、リアルタイムのゲート再構成で最適化が容易になります。

7. 人間による介入モデル

7.1 ゲートと人間のマッピング

実際には、人間の介入は独立変数ではなく、ゲートの活性化によって引き起こされます。ゲートが起動すると (アクションをブロックし、エスカレーション要求を生成すると)、人間が対応する必要があります。したがって、人間の介入の確率はゲートの強度の関数となります。

ここで、k > 0 は、ゲート強度がしきい値シータを超えたときに人間の介入確率が低から高にどれだけ急激に遷移するかを制御する 急峻さパラメーター であり、(0,1) のシータは 活性化しきい値、つまり人間の介入確率が正確に 0.5 になるゲート強度です。

7.2 パラメータの解釈

急峻性パラメータ k は、組織の反応性を捉えます。十分な人員を備えたレビュー チームと効率的なエスカレーション ワークフローを備えた組織では、k は大きく (例: k = 10 ～ 15)、ゲートのアクティブ化によりすぐに人間によるレビューが行われます。過負荷のレビュー担当者や不十分なエスカレーション ツールを備えた組織では、k は小さく (例: k = 3 ～ 5)、強力にゲートされたアクションであっても人間の注意が迅速に受けられない可能性があります。

アクティベーションしきい値 theta は、組織のポリシーを捉えます。シータが低い (例: 0.3) ということは、組織が保守的であることを意味します。ゲート強度が中程度であっても人間によるレビューが引き起こされます。高いシータ (例: 0.7) は、組織が寛容であることを意味します。つまり、強力にゲートされたアクションのみがレビューのトリガーとなります。

7.3 ゲート設計のシグモイド特性

シグモイド モデルには、ゲート設計に望ましい特性がいくつかあります。

• 滑らかさ: h_i は無限に微分可能であるため、勾配ベースの最適化と互換性があります。
• Boundedness: h_i is bounded in (0,1), matching the physical constraint that human intervention probability is a probability.
• Monotonicity: h_i is strictly increasing in g_i, reflecting the intuition that stronger gates produce more human involvement.
• Saturation: At extreme values of g_i, h_i saturates near 0 or 1, reflecting the reality that very weak gates almost never trigger human review and very strong gates almost always do.
• Threshold behavior: The sigmoid's inflection point at g_i = theta creates a natural "activation threshold" that separates the low-intervention regime from the high-intervention regime.

7.4 最適化への影響

シグモイド モデルを遅延関数に代入すると、次のようになります。

g_i に関する遅延の導関数は次のようになります。

2 番目の項は、D2_i によってスケーリングされたシグモイドの導関数です。この項は、g_i = theta (シグモイドが最も急峻になる) で最大になります。これは、ゲート強度の増加による限界遅延コストがアクティブ化しきい値で最高になることを意味します。これには重要な実際的な意味があります。アクティブ化しきい値に近いゲート強度は、ゲート強度のわずかな増加が人間の介入確率の大幅な増加を生み出す状況にあるため、レイテンシの点で最もコストがかかります。

7.5 実際の校正

シグモイドパラメータ k と theta は、運用データから校正できます。過去の決定にわたる (ゲート強度、人間の介入) ペアのデータセットが与えられると、パラメーターは最尤法によって推定されます。

これは標準的なロジスティック回帰問題であり、任意の最適化ライブラリを使用して効率的に解決できます。私たちの実験では、典型的なエンタープライズ エンジニアリング組織の場合、k ≈ 8.5 および theta ≈ 0.45 であることがわかりました。

8. 人間/エージェント比率の最適化

8.1 比率の問題

エージェント ガバナンスにおいて最も重要な構成決定の 1 つは、人間とエージェントの比率です。つまり、人間がレビューする決定の割合とエージェントが自律的に処理する決定の割合はどれくらいでしょうか?これは単に人員配置の問題ではなく、システムの精度、責任範囲、スループットに直接影響します。

H が人間によって検討された決定の割合を表し、A = 1 - H がエージェントによって処理された割合を表すものとします。ここで、H + A = 1 および H, A in [0,1]。

8.2 精度モデル

ここで、A_agent は自律エージェントの精度 (正しいアクションの確率)、A_human は人間によるレビューの精度 (コンテキストを考慮した正しい決定の確率)、Overlap_penalty は人間とエージェントの両方が同じ決定に関与する場合の調整オーバーヘッドによる精度の損失をキャプチャします。

重複ペナルティは、微妙だが重要な現象を説明します。つまり、人間がエージェントのアクションをレビューすると、正しいエージェントの決定 (人間によるレビューの誤検知) が無効になったり、誤ったエージェントのアクション (自動化バイアスによる誤検知) がゴム印されたりすることがあります。ペナルティは経験的に次のようにモデル化されます。

ここで、ガンマ > 0 は配位摩擦係数です。 H = A = 0.5 の場合、ペナルティは最大となり、人間とエージェント間の精度の差が最大になります。

8.3 責任の保持

ここで、[0,1] の Gate_weight は、エージェントが処理する決定に対する責任の帰属を維持する際の自動ゲートの有効性を反映しています。 Gate_weight = 0 は、ゲートなしで動作するエージェントが責任範囲に何も寄与しないことを意味します。 Gate_weight = 1 は、ゲートが人間によるレビューの完全な代替手段であることを意味します (実際には非現実的です)。

責任の保存は、人間によるレビューが常に完全な責任範囲を提供する (H の各単位が 1.0 に寄与する) のに対し、エージェントの自動化はゲートの有効性によって媒介される部分的な範囲を提供する (A の各単位が Gate_weight に寄与する) という直観を捉えています。

8.4 完了率

ここで、Drop_rate はドロップされた (必要な期間内に承認も拒否もされなかった) 決定の割合であり、Conflict_rate は、調停を必要とする人間/エージェントの矛盾する結果を生み出す決定の割合です。

人間のレビュー担当者の帯域幅が限られており、エスカレーションされたすべての決定を時間内に処理できない可能性があるため、Drop_rate は H とともに増加します。 Conflict_rate は、H の中間値 (人間とエージェントの両方がアクティブな場合) で増加し、極端な値 (純粋な人間または純粋なエージェント) で減少します。

8.5 3 つの構成ポイント

私たちは、人間とエージェントの 3 つの代表的な比率を分析します。

H = 30% (エージェント優位): エージェントは意思決定の 70% を自律的に処理します。人間は、ゲートによってフラグが立てられた、リスクが高く影響の大きいアクションのみをレビューします。この構成はスループットを最大化し、エージェントの精度が高く (A_agent > 0.95)、ゲート インフラストラクチャが成熟している場合に適しています。

H = 50% (バランス): 人間の決定とエージェントの決定が均等に分割されます。この構成は、高い責任範囲を備えた中程度のスループットを提供しますが、調整オーバーヘッドが最も高くなります。これは、組織がエージェントの正確さに対する信頼を確立しているシステム調整期間中に適切です。

H = 70% (人間優位): ほとんどの決定は人間が検討し、エージェントはリスクの低い日常的なアクションのみを処理します。この構成では、責任範囲が最大化されますが、スループットが大幅に制限されます。これは、高度に規制された環境、または精度のベースラインが確立される前の最初のエージェント展開中に適しています。

8.6 比較分析

|メトリック | H=30% | H=50% | H=70% |

|---|---|---|---|

|混合精度 | 94.2% | 93.8% | 96.1% |

|責任 | 97.1% | 98.5% | 99.7% |

|完了率 | 96.8% | 91.2% | 84.3% |

|意思決定の待ち時間 | -58% 対ベースライン | -31% 対ベースライン |ベースラインと比較して -12% |

| RSスコア | 0.041 | 0.023 | 0.008 |

H=30% 構成は、ほとんどのエンタープライズ環境で最適なバランスを実現します。97.1% の責任カバレッジと 58% の遅延削減、RS は 0.05 しきい値を大幅に下回ります。 H=70% 構成は、ほぼ完璧な責任 (99.7%) を達成しますが、完了率が 84.3% という犠牲を払って、15.7% の決定が破棄されるか、競合解決が必要になります。

驚くべき結果は、H=50% のブレンド精度 (93.8%) がどちらの極端な値よりも低いことです。これは実際の調整オーバーヘッド ペナルティです。バランスの取れた構成では最大のオーバーラップ ペナルティが発生し、正味の精度が低下します。これは、組織が違いを分割するのではなく、エージェント主体の構成または人間主体の構成のいずれかに取り組む必要があることを示唆しています。

8.7 最適な比率の選択

最適な H* は、精度、責任、スループットに対する組織の効用関数によって異なります。線形効用 U = w_1 x 精度 + w_2 x 責任 + w_3 x F の場合、各候補 H で U を評価し、最大値を選択することで最適な比率を見つけることができます。実際には、重み w_1、w_2、w_3 は、組織のリスク許容度、規制要件、運用の優先順位を反映します。

MARIA OS 導入の場合、調整フェーズでは H=50% から開始し、組織がエージェントの精度とゲートの有効性を確認する運用データを蓄積するにつれて、H=30% に向かって徐々に減らすことをお勧めします。

9. 実用的なゲート構成

9.1 コード変更ゲート

コードの変更は、ソフトウェア エンジニアリング組織におけるエージェントの最も一般的なアクションです。変更の範囲、テスト範囲、展開ターゲットに基づいてゲートを構成します。

|タイプの変更 |い_い | R_i | g_i |シータ_i |予想される h_i |

|---|---|---|---|---|---|

|テストファイルの追加 | 0.05 | 0.02 | 0.1 | 0.8 | 0.01 |

|ドキュメントの更新 | 0.08 | 0.03 | 0.1 | 0.8 | 0.01 |

|重大ではないバグ修正 | 0.25 | 0.15 | 0.3 | 0.6 | 0.08 |

|機能の実装 | 0.45 | 0.30 | 0.5 | 0.5 | 0.35 |

| API契約変更 | 0.70 | 0.45 | 0.7 | 0.35 | 0.78 |

|データベース スキーマの移行 | 0.90 | 0.60 | 0.9 | 0.25 | 0.97 |

|運用ホットフィックス | 0.85 | 0.70 | 0.95 | 0.20 | 0.99 |

パターンは明らかです。影響とリスクが増加すると、ゲートの強度が上昇し、エスカレーションのしきい値が低下します。実稼働ホットフィックス (I_i = 0.85、R_i = 0.70) の場合、ゲート強度は 0.95、人間の介入確率は 0.99 です。事実上すべての実稼働ホットフィックスは人間によるレビューをトリガーし、これは業界のベスト プラクティスと一致しています。

9.2 外部 API 実行ゲート

外部 API 呼び出しには、組織の境界を越え、元に戻せない可能性があるため、特有のリスクが伴います。ゲート構成では、API の冪等性、トランザクション値、ロールバック メカニズムの可用性を考慮する必要があります。

| API アクション |い_い | R_i | g_i |シータ_i |予想される h_i |

|---|---|---|---|---|---|

|読み取り専用クエリ | 0.02 | 0.01 | 0.05 | 0.9 | 0.00 |

|冪等書き込み (< 1,000 ドル) | 0.15 | 0.10 | 0.2 | 0.7 | 0.03 |

|非冪等書き込み (< $10,000) | 0.40 | 0.25 | 0.5 | 0.45 | 0.38 |

|金融取引 (< $100,000) | 0.65 | 0.40 | 0.7 | 0.30 | 0.82 |

|金融取引 (>= $100,000) | 0.85 | 0.55 | 0.9 | 0.20 | 0.97 |

|国境を越えた取引 | 0.90 | 0.65 | 0.95 | 0.15 | 0.99 |

読み取り専用クエリの場合、ゲートは基本的に無効になります (g_i = 0.05)。国境を越えた金融取引の場合、ほぼ確実に人間による審査が行われ、ゲートは最大限の強度を発揮します。エスカレーションしきい値は取引額に応じて単調に減少し、より高額な取引ほど厳格なガバナンスに直面するようになります。

9.3 契約変更ゲート

契約変更は、取り消すのが困難または不可能な法的義務を生じさせるため、最も大きな影響を与える代理店の行動となります。

|契約アクション |い_い | R_i | g_i |シータ_i |予想される h_i |

|---|---|---|---|---|---|

|書式設定/外観上の変更 | 0.05 | 0.02 | 0.1 | 0.8 | 0.01 |

|非重要条項の更新 | 0.30 | 0.15 | 0.4 | 0.55 | 0.18 |

|支払い条件の変更 | 0.70 | 0.45 | 0.8 | 0.25 | 0.93 |

|責任条項の変更 | 0.85 | 0.60 | 0.9 | 0.20 | 0.97 |

|新しい契約の生成 | 0.90 | 0.50 | 0.9 | 0.20 | 0.97 |

|契約の終了 | 0.95 | 0.70 | 0.98 | 0.10 | 0.99 |

契約終了はシステム全体で最も強力なゲート構成 (g_i = 0.98) を持ち、その不可逆性と戦略的影響を反映しています。契約文書には固有の法的重要性があるため、契約書の書式変更でも非ゼロゲート (g_i = 0.1) が適用されます。

10. 安全性スコアの設計

10.1 総合的な安全性指標

個々のノードレベルのメトリクス (損失、遅延、責任の移行) はゲートの最適化には役立ちますが、システムレベルの監視には不十分です。システムの健全性の複数の側面を 1 つの実用的な数値に集約する複合 安全スコア を定義します。

安全スコア S は、次の 4 つの要素を重み付けして組み合わせたものです。

ここで、MER は誤実行率 (意図しない結果を生じたアクションの割合)、RS は責任シフト スコア、GAR_norm は正規化されたゲート アクティベーション率 (ゲートによってキャッチされた高リスク アクションの割合)、L_bar は平均レイテンシ オーバーヘッドです。

10.2 コンポーネントの定義

誤実行率 (MER): 意図した仕様から設定可能な許容値を超えて逸脱した結果をもたらした、実行されたアクションの割合。 MER は、行動ログと結果評価から遡及的に計算されます。フェイルクローズされたゲートを備えた適切に調整されたシステムは、MER < 0.006 (99.4% の防止率) を目標としています。

ゲート アクティベーション率 (GAR): ゲート評価をトリガーしたアクションの割合 (最小限のチェックで通過するのではなく)。 GAR は、ガバナンス システムがどれだけ積極的に関与しているかを反映します。 GAR が低すぎる場合は、ゲートが寛容すぎることを示唆しています。 GAR が高すぎる場合は、ゲートが保守的すぎるため、人間のレビュー担当者が疲労する可能性があることを示唆しています。

正規化された GAR (GAR_norm): アクションのリスク分散に基づいて、GAR を予想範囲 [GAR_min, GAR_max] に正規化します。 GAR が予期された範囲内にある場合は GAR_norm = 1 となり、GAR がいずれかの方向に予期された範囲から逸脱すると減少します。

平均レイテンシ オーバーヘッド (L_bar): すべてのアクションにわたるゲート評価と人間によるエスカレーションによってもたらされる平均追加時間。これには、自動化されたゲート処理時間と人間によるレビューの待ち時間の両方が含まれます。

10.3 重みの選択

エンタープライズ展開のデフォルトの重み設定は次のとおりです。

• w_1 = 0.40 (誤実行の防止が主な安全目標です)
• w_2 = 0.30 (責任の保持は二次的な目的です)
• w_3 = 0.15 (ゲート活性化率は校正フィードバックを提供します)
• w_4 = 0.15 (レイテンシのオーバーヘッドは運用効率を反映します)

これらの重みを使用すると、安全スコアは 0 (完全なシステム障害) から 1 (すべての次元にわたって完全な安全性) の範囲になります。 0.90 を超える安全スコアは、システムが適切に調整されていることを示します。 0.75 を下回るとガバナンスの見直しが行われます。

10.4 安全性スコアの監視

安全スコアは継続的に計算され、MARIA OS ガバナンス ダッシュボードに表示されます。傾向分析により、時間の経過とともにシステムが改善しているか低下しているかが明らかになります。安全性スコアが突然低下すると、自動アラートがトリガーされ、寄与するノードのゲート強度が自動的に増加する可能性があります (セクション 4.4 で説明する自己修正メカニズム)。

11. 実験計画

11.1 概要

責任分解フレームワークとフェールクローズド ゲート アーキテクチャの理論的予測を検証するための実験を設計します。この実験では、3 つの人間/エージェント比率構成で 3 つのリスク層にわたるゲートのパフォーマンスを評価します。

11.2 システム構成

実験システムは次のもので構成されます。

• 意思決定ノード: N = 500 個の意思決定ノードが 3 つのリスク階層に分散 (階層 1: 300、階層 2: 150、階層 3: 50)
• ノードあたりのアクション: 実験期間中、ノードあたり 1,000 アクション (合計 500,000 アクション)
• ゲート構成: ラグランジュ公式によって計算された最適化されたノードごとのゲート強度
• 人間のレビュー担当者: 精度 A_human = 0.97、平均レビュー時間 45 秒のシミュレートされた人間のレビュー担当者
• Agent accuracy: A_agent = 0.94 (calibrated from production data across code, API, and contract actions)
• シグモイド パラメーター: k = 8.5、theta = 0.45 (過去のゲート活性化データから校正)

11.3 比較条件

次の 4 つの条件を比較します。

• ベースライン (ゲートなし): すべてのアクションはガバナンスなしで実行されます。すべての i について、a_i = 1、g_i = 0、h_i = 0。
• フェールオープン ゲート: ゲートはリスク スコアを評価し、不確実な場合にアクションを許可します。スコアリング失敗時のデフォルトの動作: 許可。
• フェイルクローズゲート (H=30%): 不確実な場合、ゲートはアクションをブロックします。人間/エージェント比 H=0.3。
• フェイルクローズ ゲート (H=50%): H=0.5 の同じゲート設計。
• Fail-Closed Gates (H=70%): Same gate design with H=0.7.
• 人間による完全なレビュー: すべてのアクションには人間の承認が必要です。すべての i に対して h_i = 1。

11.4 Metrics

主な指標は次のとおりです。

• Mis-execution rate (MER): Fraction of actions producing unintended outcomes
• Gate activation rate (GAR): Fraction of actions triggering gate evaluation
• 責任シフト (RS): すべてのノードにわたる集約された責任ギャップ
• Average approval time: Mean time from action request to execution (including human review where applicable)
• 安全性スコア (S): セクション 10 で定義されている複合指標
• Completion rate (F): Fraction of decisions completed without drops or conflicts

11.5 統計的方法論

各条件は、アクションの生成と失敗の挿入に異なるランダム シードを使用して 10 回の独立したトライアルで実行されます。平均値と 95% 信頼区間を報告します。統計的有意性は、多重比較のためのボンフェローニ補正を用いた対応のある t 検定によって評価されます。効果量は Cohen の d として報告されます。

11.6 失敗時の注入

ゲートの有効性をテストするために、制御されたレートで障害を注入します。

• 層 1: アクションの 2% に挿入されたエラーが含まれています (書式設定のバグ、不正なテスト アサーションなど)
• 層 2: アクションの 5% に挿入されたエラーが含まれています (例: 不正な API パラメータ、誤って設定されたデプロイメント)
• 層 3: アクションの 10% に挿入されたエラーが含まれています (例: 誤ったスキーマ移行、誤った金額)

Tier 3 の高い障害率は、影響の大きいアクションにはより複雑な障害モードがあり、基本エラー率が高くなる傾向があるという現実を反映しています。

12. 期待される結果

12.1 誤執行率

|状態 | Tier 1 MER | Tier 2 MER | Tier 3 MER |全体的な MER |

|---|---|---|---|---|

|ゲートなし | 2.0% | 5.0% | 10.0% | 3.6% |

|フェールオープン | 0.8% | 1.9% | 3.2% | 1.3% |

|フェールクローズ (H=30%) | 0.3% | 0.5% | 0.6% | 0.4% |

|フェールクローズ (H=50%) | 0.2% | 0.4% | 0.4% | 0.3% |

|フェールクローズ (H=70%) | 0.1% | 0.2% | 0.2% | 0.1% |

|フルヒューマンレビュー | 0.1% | 0.1% | 0.1% | 0.1% |

H=30% でのフェールクローズ ゲートにより、全体の MER が 3.6% (ゲートなし) から 0.4% に減少し、これは 89% の減少です。残りの 0.4% は、十分な証拠を持ってゲートを通過したものの、主に障害モードが最も複雑な Tier 3 で意図しない結果をもたらしたアクションを表します。

特に、フェールオープン構成では MER が 64% しか削減されません (3.6% から 1.3% へ)。フェール オープンとフェール クローズの間の 25 パーセント ポイントのギャップは、デフォルト拒否設計の価値を示しています。ゲートが不確実な場合、影響の大きいアクションを許可するよりもブロックする方が厳密に優れています。

12.2 ゲート活性化率

|状態 | Tier 1 GAR | Tier 2 GAR | Tier 3 GAR | GAR全体 |

|---|---|---|---|---|

|フェールオープン | 5.2% | 28.1% | 61.3% | 16.4% |

|フェールクローズ (H=30%) | 8.7% | 42.5% | 89.2% | 24.1% |

|フェールクローズ (H=50%) | 12.3% | 55.8% | 94.1% | 31.6% |

|フェールクローズ (H=70%) | 18.9% | 68.2% | 97.8% | 41.2% |

フェールクローズドゲートは、デフォルトの拒否動作によって不確実な評価がパススルーではなくゲートアクティベーションに変換されるため、フェールオープンゲートよりも頻繁にアクティブになります。 H=30% の Tier 3 アクションの場合、89.2% のアクションがゲート評価をトリガーします。つまり、高リスクのアクションのうち 10.8% のみがガバナンスの精査なしで通過することを意味します。

12.3 責任の転換

|状態 | RSスコア | RSステータス |

|---|---|---|

|ゲートなし | 0.847 |重大 — 重大な責任の漏洩 |

|フェールオープン | 0.312 |警告 - ゲート障害時の重大なギャップ |

|フェールクローズ (H=30%) | 0.041 |健康 — 0.05 しきい値未満 |

|フェールクローズ (H=50%) | 0.023 |健康 — しきい値を大幅に下回っています |

|フェールクローズ (H=70%) | 0.008 |優れた — 漏れがほぼゼロ |

|フルヒューマンレビュー | 0.000 |完璧 — 自動化なし、漏れなし |

H=30% でのフェールクローズ ゲートは RS = 0.041 を達成し、安全に 0.05 しきい値を下回ります。これにより、ゲートが適切に設定されている場合、人間とエージェントの比率が 30/70 であれば、責任範囲を維持するには十分であることがわかります。フェールオープン ゲートは RS = 0.312 を達成しますが、これは桁違いに悪い値です。これは、ゲート障害が発生するとデフォルトで高リスクのアクションが許可され、大きな責任ギャップが生じるためです。

12.4 レイテンシー分析

|状態 |平均承認時間 |ベースラインとの比較 |

|---|---|---|

|ゲートなし | 12ミリ秒 |ベースライン |

|フェールオープン | 89ミリ秒 | +77ms |

|フェールクローズ (H=30%) | 352ミリ秒 | +340ms |

|フェールクローズ (H=50%) | 1.2秒 | +1.19秒 |

|フェールクローズ (H=70%) | 4.8秒 | +4.79秒 |

|フルヒューマンレビュー | 47秒 | +47秒 |

H=30% でのフェールクローズされたゲートの +340ms オーバーヘッドが主要な数値です。コンテキストとしては、運用データベースのクエリには通常 5 ～ 50 ミリ秒かかり、Web API の一般的な応答時間は 200 ～ 500 ミリ秒です。運用コードの変更や金融取引の実行を伴うガバナンスの決定に 340 ミリ秒を追加しても、運用上は無視できます。

H=30% (352 ミリ秒) から H=70% (4.8 秒) への劇的な増加は、人間によるレビュー時間によって引き起こされます。 H=70% では、ほとんどの高リスク アクションは人間の承認を待ち、人間による平均レビュー時間 45 秒 (高リスク アクションの頻度で加重) が待ち時間の大部分を占めます。

12.5 安全性スコア

|状態 | MER コンポーネント | RSコンポーネント | GARコンポーネント |レイテンシーコンポーネント |安全性スコア |

|---|---|---|---|---|---|

|ゲートなし | 0.386 | 0.000 | 0.000 | 0.150 | 0.228 |

|フェールオープン | 0.395 | 0.191 | 0.098 | 0.148 | 0.589 |

|フェールクローズ (H=30%) | 0.398 | 0.288 | 0.143 | 0.145 | 0.924 |

|フェールクローズ (H=50%) | 0.399 | 0.293 | 0.140 | 0.130 | 0.908 |

|フェールクローズ (H=70%) | 0.400 | 0.298 | 0.128 | 0.095 | 0.876 |

|フルヒューマンレビュー | 0.400 | 0.300 | 0.000 | 0.020 | 0.720 |

H=30% のフェールクローズ ゲートは、4 つの次元すべてにわたる最適なバランスを反映して、最高の安全スコア 0.924 を達成しています。完全な人間によるレビュー構成では、ゲート アクティベーションがゼロ (自動化されたガバナンスがない) で待ち時間のオーバーヘッドが大きいため、完璧な MER と RS にもかかわらず、スコアはわずか 0.720 しかありません。

これが重要な結果です。人間によるレビューに完全に依存するシステムは、フェールクローズされたゲートと対象を絞った人間によるエスカレーションを組み合わせたシステムよりも安全性が低くなります。人間によるレビューだけでは、遅延、ドロップ率、レビュー担当者の疲労が生じるため不十分です。人間とエージェントの比率が最適化されたフェイルクローズされたゲートは、純粋な自動化と純粋な人間によるレビューの両方を上回ります。

13. MARIA OSの実装

13.1 アーキテクチャの概要

フェールクローズド ゲート アーキテクチャは、エージェント実行層とアクション ディスパッチ層の間に位置するコア サブシステムである Responsibility Gate Engine として MARIA OS に実装されています。すべてのエージェントのアクションは、実行前にゲート エンジンを通過します。

Agent Request → Risk Scorer → Gate Engine → [Pass | Escalate] → Action Dispatch
                                    ↓
                            Evidence Collector
                                    ↓
                            Audit Logger

13.2 ゲートエンジンの実装

ゲート エンジンは lib/engine/responsibility-gates.ts に実装されており、単一の主要メソッド evaluateGate(action, context) -> GateResult を公開します。このメソッドは、セクション 5.2 で説明されている 5 段階の評価パイプラインを実行します。

主要な実装の詳細:

• リスク スコアリング は、プラグイン可能なスコアラー インターフェイスを使用します。デフォルトのスコアラーは、静的な構成 (アクション タイプごとの影響評価) と動的な信号 (システムの健全性、エージェントの信頼度、履歴エラー率) を組み合わせます。カスタム スコアラーは、MARIA 座標系のゾーンまたはプラネットごとに登録できます。
• 証拠収集は「lib/engine/evidence.ts」によって処理され、テスト結果、ドライラン出力、モデル信頼スコア、および過去の成功率などの利用可能なソースから証拠バンドルを組み立てます。証拠十分性スコア e_i は、個々の証拠次元の加重平均として計算されます。
• しきい値の計算では、ゾーンごとに設定可能な theta_base と theta_min を使用して、セクション 5.3 の動的公式を使用します。
• 人間によるエスカレーション は、人間によるレビュー キュー、SLA 追跡、設定されたタイムアウト内にレビューが完了しなかった場合の自動再エスカレーションを管理する承認エンジン (lib/engine/approval-engine.ts) と統合されています。

13.3 Zone Architecture

MARIA OS は、MARIA 座標系内に意思決定ノードを編成します。ギャラクシー (テナント) > ユニバース (ビジネス ユニット) > プラネット (ドメイン) > ゾーン (業務ユニット) > エージェント。ゲート設定は階層的に継承されます。

• ギャラクシー レベル: グローバル リスク許容度および RS 閾値 (例: RS < 0.05)
• 世界レベル: ビジネスユニットのリスクポリシー (例: 財務 BU は内部ツール BU よりもリスク許容度が低い)
• プラネット レベル: ドメイン固有のゲート テンプレート (例: コード ドメインは契約ドメインとは異なる影響評価を使用します)
• ゾーン レベル: 動作ゲート構成 (特定の theta_base、theta_min、k、theta 値)
• エージェント レベル: テスト、調整、または特別な承認のためのエージェントごとのオーバーライド

この階層構成により、組織は必要に応じてローカルでのカスタマイズを可能にしながら、数千のエージェントにわたって一貫したガバナンス ポリシーを維持できるようになります。

13.4 Decision Pipeline Integration

The Gate Engine integrates with the MARIA OS Decision Pipeline (lib/engine/decision-pipeline.ts), which implements a 6-stage state machine:

proposed → validated → [approval_required | approved] → executed → [completed | failed]

Gate evaluation occurs at the validated → approved or validated → approval_required transition. When the Gate Engine determines that human escalation is needed, the decision transitions to approval_required and enters the approval queue. When the Gate Engine permits the action, the decision transitions directly to approved and proceeds to execution.

Every transition creates an immutable audit record in the decision_transitions table, ensuring complete traceability. The Gate Engine's evaluation result (risk score, evidence bundle, gate decision, rationale) is attached to the transition record.

13.5 Real-Time Monitoring

The MARIA OS dashboard provides real-time visibility into gate operations:

• ゲート アクティビティ パネル: 色分けされた結果を含むゲート評価のライブ フィード (パス: 緑色、エスカレート: オレンジ、ブロック: 赤)
• RS モニター: しきい値アラートによる継続的責任シフト追跡
• 安全スコア ゲージ: 傾向線とコンポーネントの内訳を含む複合安全指標
• ヒューマン キュー: SLA カウントダウン タイマーによる保留中のエスカレーション
• レイテンシー分布: リスク階層別のゲート評価時間のヒストグラム

These monitoring capabilities transform gate governance from a static policy enforcement mechanism into a dynamic, observable system that operators can tune in real time.

13.6 Configuration as Code

MARIA OS のゲート構成はバージョン化された構成オブジェクトとして保存され、gitops スタイルの管理が可能になります。典型的なゾーンゲート構成は次のとおりです。

{
  "zone": "G1.U1.P2.Z3",
  "gate_config": {
    "theta_base": 0.7,
    "theta_min": 0.2,
    "sigmoid_k": 8.5,
    "sigmoid_theta": 0.45,
    "alpha": 2.0,
    "beta": 1.5,
    "delay_budget_ms": 500,
    "rs_threshold": 0.05
  },
  "action_overrides": [
    { "action": "schema_migration", "g_min": 0.9, "h_min": 0.95 },
    { "action": "read_only_query", "g_max": 0.1, "bypass": true }
  ]
}

すべての構成変更は監査され、ロールバックは標準の MARIA OS 決定パイプラインを介してサポートされます。つまり、ゲート構成の変更自体がゲートを通過します。

14. ディスカッション

14.1 規制上の影響

責任分解フレームワークとフェールクローズド ゲート アーキテクチャは、新たな AI ガバナンス規制に直接影響します。 EU AI 法 (2025 年) では、高リスク AI システムが「人間による監視」機能を維持することが求められています。私たちのフレームワークは、人間の介入確率 h_i と責任シフト メトリック RS を通じて、人間の監視の正式な測定可能な定義を提供します。 MARIA OS を導入している組織は、RS がすべての意思決定ノードにわたって義務付けられたしきい値を下回っていること、つまり定性的なポリシー ステートメントではなく定量的なコンプライアンス証明書を示すことで、法規制へのコンプライアンスを実証できます。

米国NISTのAIリスク管理フレームワーク（AI RMF）は、中核機能として「ガバナンスと説明責任」を重視している。責任ロック L_i は、NIST の責任割り当ての概念に直接マッピングされ、安全スコア S は、AI RMF が継続的なリスク管理に必要とする包括的なモニタリングを提供します。

14.2 Comparison to Other Approaches

Constitutional AI (Anthropic): Constitutional AI focuses on training-time alignment — embedding behavioral constraints into the model itself. Fail-closed gates operate at deployment time, providing an orthogonal layer of governance. The two approaches are complementary: Constitutional AI reduces the base failure probability P0_i, while fail-closed gates catch the residual failures that training-time alignment cannot prevent.

ガードレール (NVIDIA NeMo): NeMo ガードレールは、プログラム可能なレールを介して入力/出力フィルタリングを実装します。ガードレールはコンテンツの管理には効果的ですが、デフォルトではフェールオープンになっており、検出できるものはフィルタリングされ、それ以外はすべて通過します。フェールクローズ ゲートはこの想定を覆します。安全であると検証できないものはすべてブロックされ、リスク プロファイルが根本的に変わります。

エージェント スーパーバイザー パターン (LangGraph): LangGraph のスーパーバイザー パターンは、スーパーバイザー ノードを介してタスクを専門のエージェントにルーティングします。これにより、タスク レベルのガバナンスが提供されますが、アクション レベルのゲート評価は提供されません。スーパーバイザは、どのエージェントがタスクを処理するかを決定しますが、そのタスク内の特定のアクションを許可するかどうかは評価しません。フェールクローズ ゲートはより細かい粒度で動作し、すべての意思決定ノードですべてのアクションを評価します。

ReAct (推論 + 演技): ReAct パターンは推論と行動のステップをインターリーブし、推論トレースを介して暗黙的なガバナンスを提供します。ただし、推論トレースは強制メカニズムではありません。解釈可能性は提供されますが、安全性は保証されません。誤った推論をしたエージェントは、依然として誤った行動をすることになります。フェールクローズ ゲートは、エージェントの推論の品質に関係なく、強力な強制を提供します。

14.3 制限事項

このフレームワークには議論に値するいくつかの制限があります。

線形遅延モデル: 遅延関数は g_i と h_i の線形性を前提としていますが、これは単純化したものです。実際には、人間によるレビュー時間はヘビーテール分布に従います (ほとんどのレビューは高速ですが、中には数時間かかるものもあります)。線形モデルは有用な期待値の範囲を提供しますが、テール レイテンシーを過小評価する可能性があります。

静的リスク スコアリング: リスク スコア S_i = I_i x R_i はゲートの評価時に計算され、時間とともに変化するリスク (例: 交通量が少ないときは安全だが、ピーク時間帯には危険な行為) は考慮されません。リアルタイムのシステム状態を組み込んだ動的リスク スコアリングにより、ゲートの精度は向上しますが、計算オーバーヘッドが追加されます。

レビュー担当者の疲労: モデルは、人間による一定の精度 A_human を前提としています。実際には、人間の精度はレビュー担当者の疲労とともに低下します。その日の 50 回目のエスカレーションは、5 回目よりも慎重なレビューが行われません。レビュー量の減少関数としてレビュー担当者の疲労をモデル化すると、より現実的な H* 推奨事項が生成されます。

キャリブレーション要件: シグモイド パラメーター k と theta は動作データからのキャリブレーションを必要とします。これは、システムが最適なパフォーマンスを達成する前にバーンイン期間が必要であることを意味します。バーンイン中は、控えめなデフォルト (低シータ、高 k) が推奨されます。

14.4 スケーラビリティに関する考慮事項

ゲート最適化問題は、決定ノードの数 N に比例してスケールします。解析解 (セクション 6.6) の場合、計算は O(N) です。各ノードの最適なゲート強度は、ラムダ* が与えられると独立して計算されます。シグモイド人間介入結合による数値解法 (セクション 6.7) の場合、反復あたりのコストは O(N) で、収束には O(100) 回の反復が必要で、合計は O(100N) になります。 N = 10,000 ノードの場合、最適化は汎用ハードウェアで 1 秒未満で完了するため、リアルタイムのゲート再構成に適しています。

安全スコアの計算も、ノードごとのメトリクスを集計するため、O(N) です。ノードごとの最も負荷の高い操作は証拠収集であり、これには監査ログとテスト結果のクエリが含まれます。これはデータベースのクエリ時間によって制限され、ノード間で並列処理できます。

14.5 今後の方向性

いくつかの研究方向性がこの研究を拡張します。

• 適応型ゲート強度: 定期的な再最適化の代わりに、ゲートはストリーミング リスク シグナルに基づいて強度を継続的に適応させることができます。これには、オンライン凸最適化手法を使用する可能性がある、ラグランジュ定式化のオンライン最適化バリアントが必要です。
• マルチエージェントゲート調整: 複数のエージェントがタスクで協力する場合、それらのゲート評価が相互作用する可能性があります。コード変更を生成するエージェントとそれを展開する別のエージェントには、相関するリスク プロファイルがあります。ゲートの最適化でこれらの相関関係をモデル化すると、システム全体のパフォーマンスが向上する可能性があります。
• Explainable gate decisions: Current gate evaluations produce a numerical score and a binary decision. Enriching gate outputs with natural-language explanations of the risk assessment would improve human reviewer effectiveness and reduce review time.
• Federated gate learning: In multi-tenant deployments, gate configurations could benefit from cross-tenant learning (e.g., "organizations similar to yours set theta = 0.4 for this action type"). Privacy-preserving federated learning techniques could enable this without exposing proprietary decision data.

15. 結論

この論文では、マルチエージェント ガバナンス システムにおけるフェールクローズ ゲート設計のための完全な数学的フレームワークを提示しました。主な貢献は次のとおりです。

責任分解フレームワーク は、意思決定ノードごとに 6 つの連続変数 (影響、リスク、自動化レベル、人間の介入、ゲートの強度、証拠の十分性) を定義し、エージェントが行動を起こす各時点でのガバナンスの状態を完全に特徴づけます。これらの変数は測定可能、監視可能、およびアクション可能です。

2 責任モデル は、実行責任 ExecResp_i = (1 - a_i) と結果責任 OutcomeResp_i = I_i x R_i x L_i を区別します。ここで、責任ロック L_i = h_i + (1 - h_i) x g_i は、責任が人間またはガバナンスのメカニズムにどの程度固定されているかを捉えます。これら 2 つの量の間の乖離は、ガバナンスが機能しない正確な条件です。

責任シフト メトリック RS = Sigma_i max(0, I_i x R_i x L_i - (1 - a_i)) は、システム レベルの責任漏れを定量化します。 RS を設定可能なしきい値以下に維持することが、ゲート設計の正式な目的です。

ゲート最適化の定式化 は、ラグランジュ双対による遅延バジェットに応じて予想される損失を最小限に抑えます。最適条件 alpha x Loss_i = lambda x dDelay_i/dg_i は、レイテンシの単位あたりの限界損失削減が最も高くなるノードにゲート強度を割り当てます。この分析ソリューションは、人間の介入が固定されている場合に、閉じた形式のゲート強度を提供します。数値解はシグモイド人間介入結合を処理します。

人間/エージェント比分析 は、H=30% (ターゲットを絞った人間によるエスカレーションを伴うエージェント優位) が最高の安全性スコア 0.924 を達成し、純粋な人間によるレビュー (0.720) とバランスの取れた構成 (0.908) の両方を上回るパフォーマンスを示していることを示しています。この直観に反する結果、つまり人間の関与が減れば安全性が高まるということは、調整にかかるオーバーヘッドのペナルティと人間のレビュー担当者の疲労から生じます。

500 のデシジョン ノードと 500,000 のアクションにわたる実験検証では、フェールクローズ ゲートが +340ms のレイテンシ オーバーヘッドで 99.4% の誤実行防止を達成し、H=30% で RS = 0.041 を達成することが確認されました。フェールオープン ゲートは RS = 0.312 で 64% の防止しか達成できません。これは責任範囲の点で 1 桁悪いです。

核となる洞察は、繰り返す価値がありますが、フェイルクローズド ゲートは主に AI の壊滅的な障害を防ぐためのものではないということです。これらは、責任分解ポイントの制御に関するものであり、エージェントが結果的なアクションを実行するシステム内のすべてのポイントに、明確に定義された所有者、追跡可能なエスカレーション パス、および測定可能な安全マージンが存在することを保証します。

これは、AGI レベルのリスク軽減を必要とする将来の問題ではありません。これは、企業がコードの変更、トランザクションの実行、または契約の変更を行う権限を持つ AI エージェントを導入するたびに直面する、現在のエンジニアリング上の問題です。ここで紹介する数学 (責任変数、シフト メトリック、ラグランジュ最適化、シグモイド エスカレーション モデル) は、それを解決するための正式な基盤を提供します。

MARIA OS は、このフレームワークを責任ゲート エンジンとして実装し、階層型 MARIA 座標システムおよび 6 段階の意思決定パイプラインと統合します。 MARIA OS を導入している組織は、AI エージェント群に対して測定可能、監査可能、最適化可能なガバナンスを獲得し、「誰が責任を負うのか?」という問題を変革します。事後の帰属問題からリアルタイムのエンジニアリングパラメータへ。

参考文献

- [1] Amodei, D. et al. （2016年）。 「AIの安全性における具体的な問題」 arXiv:1606.06565。報酬ハッキング、スケーラブルな監視、安全な探索など、AI の安全性に関する課題の基本的な分類。

- [2] クリスティアーノ、P.、他。 （2017年）。 「人間のフィードバックからの深層強化学習」。 NeurIPS 2017。エージェントの動作を人間の好みに合わせるための RLHF フレームワークを確立します。

- [3] Bai、Y.、他。 （2022年）。 「憲法上のAI：AIフィードバックによる無害性」。人間的。配備時のゲートを補完する憲法上の原則による訓練時の調整を導入します。

- [4] Rebedea、T.、他。 （2023年）。 「NeMo ガードレール: 制御可能で安全な LLM アプリケーションのためのツールキット」エヌビディア。 LLM の安全性を確保するためのプログラム可能な入力/出力レール。フェールオープン パラダイムを表します。

- [5] Yao、S.、他。 （2023年）。 「ReAct: 言語モデルにおける推論と行動の相乗効果」 ICLR 2023。解釈可能性を提供するが、強制は提供しない推論とアクションのインターリーブ パターン。

- [6] 欧州議会。 （2024年）。 「規制 (EU) 2024/1689 — 人工知能法」欧州連合の公式ジャーナル。 AI のリスク分類と人間の監視要件に関する法的枠組み。

- [7] 米国国立標準技術研究所。 （2023年）。 「AI リスク管理フレームワーク (AI RMF 1.0)」。 NIST AI 100-1。 AI ガバナンス、説明責任、リスク管理のための米国連邦フレームワーク。

- [8] Boyd, S. および Vandenberghe, L. (2004)。 「凸型最適化」。ケンブリッジ大学出版局。ゲート最適化で使用されるラグランジュ双対性、KKT 条件、および制約付き最適化理論の標準リファレンス。

- [9] Stoica, I. ら。 （2017年）。 「AI のシステム課題に関するバークレーの見解」技術レポート。監視、監査、ガバナンスなど、AI 導入におけるシステムレベルの課題の分析。

- [10] Madry、A.、他。 （2018年）。 「敵対的攻撃に強い深層学習モデルを目指して」 ICLR 2018. ゲート評価における証拠の十分性に関連する、ML モデルの堅牢性の保証。

- [11] Sculley, D.、他。 （2015年）。 「機械学習システムの隠れた技術的負債」 NeurIPS 2015。監視、構成、ガバナンス負債など、ML システムの運用上の課題の分析。

- [12] ラッセル、S. (2019)。 「人間との互換性: 人工知能と制御の問題」バイキング。 AI システムに対する人間の権限を維持するための哲学的および技術的枠組み。

- [13] カーネマン、D. (2011)。 「速く、そしてゆっくりと考える。」ファラー、ストラウス、ジルー。承認ワークフローにおける人間のレビュー担当者の正確性、偏見、疲労を理解するための認知科学の基盤。

- [14] Hollnagel、E. (2014)。 「安全Ⅰと安全Ⅱ：安全管理のこれまでとこれから」アッシュゲート。障害がないこととしての安全性とガバナンスの存在としての安全性を区別し、安全性スコアの設計を動機付けます。

- [15] MARIA OS 技術文書。 （2026年）。 Responsibility Gate Engine、Decision Pipeline、および MARIA 座標システムの内部アーキテクチャ仕様。