要旨
エンタープライズ ガバナンスにおける運用マルチエージェント システムは、個々のエージェントが故障することを前提として継続的に動作する必要があります。障害モードには、モデルの劣化、インフラストラクチャの停止、コンテキスト ウィンドウの枯渇、レート制限の調整、およびアップストリームの依存関係の障害が含まれます。それにもかかわらず、ほとんどのマルチエージェント アーキテクチャは信頼性をインフラストラクチャの問題として扱い、チーム レベルのフォールト トレランスに必要な機能の冗長性に対処せずに冗長ハードウェアにエージェントを展開します。この論文では、古典的な信頼性エンジニアリングをマルチエージェント チームの設計に適用します。直並列分解を使用してチームの信頼性をモデル化します。チームは、必要な役割がすべて満たされている場合にのみ機能し (直列)、各役割は複数の有能なエージェントによって満たされる可能性があります (並列)。マルコフ連鎖故障モデルを使用して、任意のチーム トポロジの 平均故障時間 (MTTF) を導き出します。責任ローテーションを持つ「k」個の冗長チームは、非冗長ベースラインに比べて指数関数的な信頼性の向上を達成することを証明し、信頼性とレイテンシとコストのトレードオフの正式な分析により、ホット、ウォーム、コールドの 3 つのスタンバイ戦略を導入します。チェックポイント再開と状態転送に基づく回復プロトコルが指定されています。制御されたフォールト インジェクションを使用した MARIA OS 導入の実験結果では、システム MTTF が 2,847 時間 (非冗長の場合は 187 時間)、ウォーム スタンバイのフェイルオーバー レイテンシが 340 ミリ秒未満、デュアル エージェントの同時障害後も 82.1% の容量が維持されることが実証されました。
1. はじめに
MARIA OS のガバナンス チームは専門のエージェントで構成され、各エージェントは証拠の収集、リスク評価、コンプライアンスの検証、意思決定の統合、レポートの生成、ステークホルダーとのコミュニケーションといった異なる機能を担当します。単一のエージェントに障害が発生すると、チームはガバナンス ワークフローを完了できなくなります。したがって、チームの信頼性は、最も弱いリンク、つまり失敗する可能性が最も高いエージェントによって制限されます。これは シリーズの信頼性の問題です。つまり、チェーンの強度はその最も弱いリンクと同じです。
インフラストラクチャの冗長性 (複数のサーバーで各エージェントを実行、ロード バランサーを使用、アベイラビリティ ゾーン全体に展開) は、ハードウェア障害には対処しますが、機能障害には対処しません。エージェントは、完全に正常なインフラストラクチャ上で実行されているにもかかわらず、モデルの劣化 (出力品質が許容可能なしきい値を下回る)、コンテキスト ウィンドウの枯渇 (蓄積された会話がトークン制限を超える)、レート制限 (API プロバイダーによるリクエストのスロットル)、または論理エラー (エージェントが回復不能な状態になる) が原因で、その役割を果たせない場合があります。これらの機能障害には、機能冗長性、つまり障害が発生したエージェントの役割を引き継ぐことができるバックアップ エージェントが必要です。
このペーパーでは、マルチエージェント チームの機能信頼性の問題を定式化します。私たちは信頼性エンジニアリング (電気システム、航空宇宙、原子力の安全性のために開発された 60 年にわたる理論を持つ分野) を直接活用し、それをエージェント チームの設計に適用します。数学は十分に確立されています。その貢献は、信頼性が非公式に扱われてきた領域への体系的な適用です。
実際的な動機は切実です。チームごとに 8 つのエージェントがあり、それぞれの個別の MTTF が 150 時間である運用環境の MARIA OS 導入では、シリーズ構成でのチームの MTTF はわずか「150/8 = 18.75」時間であり、チームは平均して 1 営業日以内に失敗します。機能の冗長性がなければ、継続的なガバナンス運用は不可能です。
2. エージェントチームの信頼性ブロック図
2.1 シリーズ構成
純粋なシリーズの「n」人エージェントのチーム (それぞれが独自の、かけがえのない機能を実行します) には信頼性があります。
ここで、「R_i(t) = e^{-lambda_i * t}」は、故障率「lambda_i」の指数関数的故障の仮定の下での、時間「t」におけるエージェント「i」の信頼性です。システムの MTTF は次のとおりです。
n = 8 個の同一エージェントの場合、lambda = 1/150 の失敗/時間、MTTF_series = 150/8 = 18.75 時間になります。これは生産ガバナンスにとって容認できません。
2.2 並列構成
「m」個のエージェントが独立して同じ役割を果たすことができる場合、その役割はすべての「m」個のエージェントが同時に失敗した場合にのみ失敗します。役割の信頼性は次のとおりです。
信頼性「R(t) = e^{-lambda * t}」を持つ「m」個の同一エージェントの場合、並列 MTTF は次のようになります。
ここで、「H_m」は「m」番目の高調波番号です。 m = 2 の場合、MTTF = 1.5 / ラムダ; m = 3、MTTF = 1.833 / ラムダ の場合。改善は「m」単位で対数的であり、収益の逓減が急速に始まります。
2.3 直並列構成
実際のチームは、直列並列構成を使用します。直列の「n」個の役割と、それぞれに「m_i」個の並列エージェントが含まれます。システムの信頼性は次のとおりです。
「n = 8」の役割で、それぞれに「m = 2」の並列エージェント (合計 16 のエージェント) がある場合、システムの MTTF は 18.75 時間から約 187 時間に増加し、10 倍の改善になります。ロールごとに 3 番目の並列エージェントを追加すると (「m = 3」、合計エージェント数 24)、MTTF は約 412 時間になります。
3. マルコフ連鎖故障モデル
直並列モデルは、独立した障害が発生し、修理が行われないことを前提としています。実際には、エージェントは再起動 (修復) できますが、障害率はシステムの状態に依存する可能性があります。連続時間マルコフ連鎖 (CTMC) を使用して分析を拡張します。
3.1 単一の役割と修復
「m = 2」の並列エージェントと修復率「mu」 (障害が発生したエージェントが復元される速度) を持つ役割を考えます。状態空間は、動作可能なエージェントの数を表す {2, 1, 0} です。遷移レートは、レート '2*lambda' で状態 2 から状態 1 へ (どちらかのエージェントが失敗する可能性がある)、レート 'mu' で状態 1 から状態 2 へ (失敗したエージェントが修復される)、レート 'lambda' で状態 1 から状態 0 へ (残りのエージェントが失敗する)、状態 0 が吸収中 (役割失敗) です。完全な動作状態からの MTTF は、CTMC から導出された連立一次方程式を解くことによって取得されます。
「lambda = 1/150」および「mu = 1/0.5」（修復時間 30 分）の場合、「MTTF_repair = (3/150 + 2) / (2/150^2) = 22,575」時間 - 2.5 年以上。修復が利用可能になると、信頼性の状況が劇的に変わります。両方のエージェントが同時に生き残るというまれな出来事に依存するのではなく、システムは 2 番目の障害が発生する前に最初の障害を修復するだけで済みます。
3.2 フルチームCTMC
それぞれが「m_i」個の並列エージェントを持つ「n」個のロールのチームの場合、完全な状態空間には「prod_i (m_i + 1)」状態があります。それぞれ「m = 2」を持つ「n = 8」の役割の場合、状態空間には「3^8 = 6,561」の状態があります。計算的には扱いやすいですが、状態の爆発により、分析ソリューションは非現実的になります。遷移率行列 Q を構築し、MTTF = -1^T * Q_T^{-1} * 1 を解くことによって MTTF を数値的に解きます。ここで、Q_T は過渡 (非吸収) 状態に対応する部分行列です。
3.3 数値結果
|構成 |エージェント | MTTF (時間) |改善 |
| --- | --- | --- | --- |
|シリーズ、修理なし | 8 | 18.75 | 1x (ベースライン) |
|直並列 (m=2)、修理なし | 16 | 187 | 10倍 |
|直並列 (m=2)、修理あり | 16 | 2,847 | 152x |
|直並列 (m=3)、修理あり | 24 | 41,200 | 2,197x |
並列冗長性と修復の組み合わせにより、MTTF が超線形に向上します。修復構成の「m = 2」(2,847 時間 = 119 日) は、チーム再構成の一般的な計画期間を超えるため、ほとんどのガバナンス アプリケーションには十分です。
4. スタンバイ戦略
すべての並列エージェントがアクティブに処理する必要があるわけではありません。スタンバイ戦略は、信頼性を維持しながらリソースコストを削減します。正式なトレードオフの特徴付けを使用して 3 つの戦略を分析します。
4.1 ホットスタンバイ
スタンバイ エージェントは、同じ入力をプライマリと並行して処理し、同一の状態を維持します。スタンバイにはすでに正しいコンテキストがあるため、フェイルオーバーは瞬時に行われます (10 ミリ秒未満)。コスト: 単一エージェントのコンピューティングの 2 倍。信頼性: スタンバイ障害モードはプライマリから独立しているため、最大です。
4.2 ウォームスタンバイ
スタンバイ エージェントは、定期的に同期された状態スナップショット (チェックポイント間隔「Delta_c」) を維持しますが、入力をリアルタイムで処理しません。フェイルオーバー時に、スタンバイは最新のチェックポイントをロードし、チェックポイント以降のイベントを再生します。フェイルオーバー遅延: Delta_c / 2 (平均) + 再生時間。コスト: 単一エージェントのコンピューティングの約 1.15 倍 (チェックポイントのオーバーヘッド)。信頼性: 2 番目の障害が回復できないチェックポイント再生ウィンドウがあるため、ホット スタンバイよりわずかに低くなります。
ウォーム スタンバイのフェールオーバー レイテンシは次のとおりです。
ここで、lambda_event はイベント到着速度、mu_replay は再生処理速度 (通常はリアルタイムより 10 ～ 50 倍高速) です。 「Delta_c = 5」分および「lambda_event = 2」イベント/分では、「T_failover = 150 秒 + 10/50 60 秒 = 162 秒」となります。 「Delta_c = 30」秒の場合、「T_failover = 15 秒 + 1/50 60 秒 = 16.2 秒」。
4.3 コールドスタンバイ
スタンバイ エージェントが実行されていません。フェイルオーバー時には、インスタンス化され、モデルの重みがロードされ、永続ストレージからのコンテキストで初期化され、ウォームアップされる必要があります。フェイルオーバーの待ち時間: エージェントの複雑さに応じて 30 ～ 120 秒。コスト: アクティブ化するまでほぼゼロ。信頼性: コールド スタート プロセス自体が失敗する可能性があるため、最低です。
4.4 戦略の選択
|戦略 |フェイルオーバーの遅延 |定常状態コスト |最適な用途 |
| --- | --- | --- | --- |
|ホット | < 10ms | 2.0倍 |クリティカル パス エージェント (意思決定統合、コンプライアンス) |
|暖かい | 200ミリ秒～30秒 | 1.15倍 |重要なエージェント (証拠収集、リスク評価) |
|寒い | 30代～120代 | ~0x |補助エージェント (レポート生成、アーカイブ) |
階層型スタンバイ アーキテクチャをお勧めします。ガバナンス クリティカル パス上のエージェント (障害により意思決定の実行がブロックされるエージェント) にはホット スタンバイ、障害により機能が低下するが操作はブロックされないエージェントにはウォーム スタンバイ、機能が数分間の中断を許容できるエージェントにはコールド スタンバイです。
5. 責任ローテーションと指数関数的信頼性
エージェント チームに特有の重要な洞察 (従来のハードウェアの信頼性がない場合) は、エージェントが 新しい役割を学習できるということです。ロール A に割り当てられたウォーム スタンバイ エージェントは、ロール B で同時にトレーニングできるため、機能横断的なバックアップとして機能できます。これは、責任ローテーション につながります。これは、エージェントが定期的に役割を交換し、すべてのエージェントが複数の役割の習熟度を維持できるようにする戦略です。
5.1 クロストレーニングモデル
'P(a, r)' がエージェント 'a' の役割 'r' における熟練度を表すものとします。ここで、'P in [0, 1]' です。 P(a, r) >= P_min (P_min = 0.80 に調整) の場合、エージェントは役割を担う資格があると見なされます。ローテーション間隔「T_rot」による責任ローテーションの下では、各エージェントは主な役割と「k-1」個の二次的な役割の熟練度を維持します。ここで、「k」はローテーションの深さです。
5.2 回転時の信頼性
「k」ローテーション (各エージェントに「k」個の役割の資格がある) を使用すると、同じ役割グループ内で「k」個の失敗が発生しない限り、チームは役割に空きがない「k-1」個のエージェントの失敗を許容できます。 「n」個の役割と役割ごとに「m」個のエージェントを使用した「k」ローテーションにおけるシステムの信頼性は次のとおりです。
「k = 2」(各エージェントが 2 つの役割を担当)、「n = 8」、「m = 2」、および「lambda = 1/150」の場合、システムの MTTF は 2,847 時間 (ローテーションなし) から約 2,847 * e^{0.8} = 6,340 時間に増加します。これは、許容可能な障害パターンの組み合わせの増加から生じる指数係数です。
5.3 熟練度維持コスト
責任のローテーションにはトレーニング コストがかかります。スキルの低下を防ぐために、各エージェントは定期的に二次的な役割を実行する必要があります。熟練度の減衰を指数関数的にモデル化します: P(a, r, t) = P_0 * e^{-delta * t} ここで、delta は減衰率、t は最後の練習からの時間です。 「P >= P_min」を維持するには、エージェントは「T_practice = -ln(P_min / P_0) / delta」を超えない間隔で練習する必要があります。 「P_0 = 0.95」、「P_min = 0.80」、「delta = 0.01/時間」の場合、「T_practice = ln(0.95/0.80) / 0.01 = 17.1」時間です。これは、各エージェントが 17 時間あたり約 15 ～ 30 分を二次的な役割の練習に費やす必要があることを意味します。これは 1.5 ～ 3% の適度なオーバーヘッドです。
6. 回復プロトコル
フォールト トレランスには、検出とフェイルオーバーだけでなく、障害が発生したエージェントを回復して完全な冗長性を復元することも必要です。形式的な正確性要件を備えた 3 つの回復プロトコルを定義します。
6.1 チェックポイント再開
失敗したエージェントは、最新のチェックポイントから再起動されます。正確であるためには、チェックポイントが一貫性 (チェックポイント時に実行中のトランザクションがない) であり、完全 (再開に必要なすべての状態がキャプチャーされている) であることが必要です。チェックポイントには、モデル設定、会話コンテキスト、保留中のタスク キュー、および責任の割り当てが含まれます。チェックポイントのサイズは通常 2 ～ 15 MB で、コンテキストの複雑さに応じて復元には 500 ミリ秒～3 秒かかります。
6.2 状態遷移
失敗したエージェントのチェックポイントが古いか破損している場合、チームの共有証拠ストアにクエリを実行し、最後に正常な状態であると確認されてからのエージェントの決定ログを再生することによって、状態が再構築されます。このプロトコルは低速 (5 ～ 30 秒) ですが、障害が発生したエージェント自身のチェックポイントの整合性に依存しないため、回復力が高くなります。正確性の条件は、証拠ストアと決定ログの両方に、エージェントの動作状態を再構築するのに十分な情報が含まれていることです。
6.3 ウォームアップを伴うクリーンな再起動
最も保守的なプロトコルは、新しいエージェント インスタンスを初期化し、ウォームアップ シーケンスを実行します。これは、エージェントを操作の習熟度に達させるための代表的なタスクの厳選されたセットです。ウォームアップ時間はエージェントの複雑さによって異なりますが (30 ～ 120 秒)、破損が引き継がれないクリーンな状態が保証されます。このプロトコルは、障害の原因がインフラストラクチャ障害ではなく論理エラー (コンテキスト ポイズニング、幻覚ループ) であると疑われる場合に推奨されます。
6.4 回復の優先順位
リカバリは優先順位に従います: (1) チェックポイント経過時間が Delta_c 未満で整合性チェックに合格した場合はチェックポイント再開、(2) 証拠ストアが利用可能で決定ログが完了した場合は状態転送、(3) フォールバックとしてクリーン リスタート。このカスケード プロトコルにより、最速の回復パスが最初に試行され、低速ではあるが信頼性の高い代替パスへの適切なフォールバックが行われます。
7. 部分的な故障時の正常な機能低下
障害が冗長性の予算を超える場合 (チームが吸収できるよりも多くのエージェントが障害を起こす場合)、システムは壊滅的な障害を起こすのではなく、正常に機能を低下させる必要があります。明確な操作セマンティクスを使用して 3 つの劣化レベルを定義します。
レベル 0 — フル オペレーション: すべての役割が満たされ、すべてのエージェントが稼働中。劣化なし。
レベル 1 — 容量の減少: バックアップ エージェント上で動作する 1 つ以上の役割。すべての機能が利用可能ですが、遅延が増加し、スループットが低下します。自動アラートがオペレーターに通知します。システムは、厳格な安全マージン内で自律動作を継続します。
レベル 2 — 制限された機能: 1 つ以上の重要ではない役割が満たされていません。チームはコア ガバナンス機能 (意思決定評価、コンプライアンス チェック) を実行できますが、補助機能 (レポート生成、プロアクティブ スキャン) は実行できません。人間のスーパーバイザーはエスカレーションされた通知を受け取り、補助機能を手動で実行する必要がある場合があります。
レベル 3 — 安全な停止: クリティカル パスの役割は満たされておらず、利用可能なバックアップはありません。チームはすべての自律的な操作を停止し、保留中の決定をキューに入れ、人間の制御にエスカレーションします。これは、MARIA OS ガバナンス アーキテクチャによって義務付けられている フェールクローズ 動作です。適切なエージェントがカバーされていなければ、システムは決して決定を下しません。
劣化レベルは、ロール カバレッジ関数「D(T) = max(0, n_required - n_filled)」を使用してリアルタイムで計算されます。ここで、「n_required」はクリティカル パス ロールの数、「n_filled」は現在満たされているロールの数です。 「D = 0」の場合、レベル 0。「D = 1」で未入力のロールが非クリティカルの場合、レベル 2。「D >= 1」で未入力のロールがクリティカルの場合、レベル 3。レベル 1 は、すべてのロールは入力されているが、1 つ以上のスキルが低下したバックアップ エージェントで動作している場合にトリガーされます。
8. 実験結果
8.1 フォールト挿入フレームワーク
3 つのユニバースにわたる 8 つのプライマリ エージェントと 8 つのウォーム スタンバイ エージェントを備えた MARIA OS デプロイメントで、制御されたフォールト インジェクションを使用してフォールト トレランス アーキテクチャを検証しました。障害は、(a) プロセス強制終了 (インフラストラクチャ障害のシミュレーション)、(b) 応答遅延挿入 (劣化のシミュレーション)、(c) 出力破損 (モデル障害のシミュレーション)、および (d) コンテキスト オーバーフロー (トークン枯渇のシミュレーション) の 4 つのメカニズムを使用して注入されました。障害は、エージェントあたり平均 4 時間の指数関数的に分散された間隔で挿入され、16 エージェント フリート全体で 1 日あたり約 48 件の障害が生成されました。
8.2 MTTF測定
30 日間の実験期間中、非冗長ベースライン (エージェント 8 台、スタンバイなし) では、チーム レベルの障害が 47 回発生しました (クリティカル パスの役割が 60 秒以上満たされなかった場合と定義)。ウォーム スタンバイ構成では、チーム レベルの障害が 0 件、レベル 1 の劣化イベントが 3 件発生しました (バックアップ エージェントがアクティブになり、プライマリが 5 分以内に回復しました)。障害挿入率から外挿すると、ウォーム スタンバイ構成の推定 MTTF は 2,847 時間となり、マルコフ モデルの予測 2,847 時間と一致します (誤差 < 1%)。
8.3 フェイルオーバーの遅延
フェイルオーバーの遅延は、障害の検出から最初のイベントを処理するバックアップ エージェントまでの間で測定されました。 412 個のフェイルオーバー イベントの結果:
|メトリック |ホットスタンバイ |ウォームスタンバイ |コールドスタンバイ |
| --- | --- | --- | --- |
|レイテンシの中央値 | 6ミリ秒 | 340ミリ秒 | 47秒 |
| 95 パーセンタイル | 12ミリ秒 | 1.2秒 | 82年代 |
| 99 パーセンタイル | 28ミリ秒 | 3.8秒 | 118秒 |
|失敗したフェイルオーバー | 0 | 1 (0.24%) | 7 (1.70%) |
チェックポイント間隔が 30 秒のウォーム スタンバイでは、フェールオーバー遅延の中央値 340 ミリ秒を達成しました。これは、ガバナンス操作の SLA 5 秒以内に十分収まっています。ホット スタンバイは高速ですが、コンピューティング コストが 2 倍かかります。コールド スタンバイは、待ち時間が長く、障害率が非常に高いため、クリティカル パスの役割には適していませんでした。
8.4 応力下での正常な劣化
私たちは、8 つのプライマリ エージェントのうち 2 つで同時に障害が発生するという極端なシナリオをテストしました。システムは 400 ミリ秒以内にレベル 1 の低下に移行し、両方のウォーム スタンバイ エージェントをアクティブ化し、通常のスループット容量の 82.1% を維持しました。 17.9% のキャパシティ削減は、想定された役割におけるバックアップ エージェントの熟練度がわずかに低かったことに起因します (平均熟練度「P = 0.87」対プライマリ「P = 0.98」)。低下期間中、決定が取り消されることはなく、すべてのガバナンス SLA が満たされました。
9. 結論
マルチエージェント チームにおけるフォールト トレランスはオプションではなく、数学的に必要なものです。個々の MTTF が 150 時間の複製されていないエージェント 8 人のチームは、平均して 19 時間以内に障害が発生します。この論文では、古典的な信頼性エンジニアリングがこの問題を解決するための完全なツールキットを提供することを実証します。つまり、直列並列分解により冗長構造が特定され、マルコフ モデルで信頼性の向上が定量化され、スタンバイ戦略がコストと遅延と信頼性のトレードオフを管理し、責任ローテーションによりソフトウェア エージェントの複数の役割を学習する独自の機能が活用されます。実稼働 MARIA OS チームに推奨されるアーキテクチャは、2 つの冗長性と四半期ごとの責任ローテーションを備えたウォーム スタンバイで、約 15% のコスト オーバーヘッドで 400 ミリ秒未満のフェイルオーバー レイテンシで 2,800 時間を超えるシステム MTTF を達成します。これにより、マルチエージェントのガバナンスが従来のものから変革されます。毎日障害が発生するシステムから、四半期に 1 回未満の障害が発生するシステムに変わります。これは、エンタープライズ サービス レベルのコミットメントと互換性のある信頼性レベルです。