要旨
マルチエージェントの並列実行により、劇的なスループットの向上が約束されます。専門のエージェント間で作業を分割し、同時に実行し、単一のエージェントでは達成できない速度を達成します。しかし、単純な並列処理では、シーケンシャル パイプラインには存在しない 2 つの障害モード、境界違反 (スコープが重複するエージェントが競合する出力を生成する) と マージ障害 (並列出力の統合により、個々の出力には存在しないエラーが発生する) が発生します。これらの失敗モードを確率モデルで形式化し、合計成功確率を「P(total) = Π(p_i) · (1 - q_merge) · (1 - q_overlap)」として導出します。ここで、「p_i」はエージェントごとのサブタスク成功確率、「q_merge」はマージ失敗確率、「q_overlap」は境界違反確率です。乗算構造は、単一の弱いリンク (低い p_i、高い q_merge、または高い q_overlap) を明らかにします。全体の結果を支配します。我々は、次の 3 つの条件が成立する場合に限り、品質がスケールに収束することを証明します (「n」を増やしても「P(total)」は低下しません): 素のスコープ適用の境界 q_overlap がゼロに近く、ゲート検証済みのマージ コントラクトの境界 q_merge がゼロに近く、サブタスクの成功確率が最小しきい値 p_0 を超えたままである。逆に、q_merge か q_overlap のどちらかが n とともに大きくなると、品質が崩壊します。このフレームワークは、ゾーンベースのスコープ割り当て、証拠層マージコントラクト、ゲート検証済み統合を通じて MARIA OS で運用可能です。ベンチマークでは、エージェント 2 から 8 までの「P > 0.92」のスケーリング、ゾーン強制下での「q_overlap < 0.03」、ゲート検証ありの場合は 97.4% のマージ成功、ゲート検証なしの場合は 71.2% であることが実証されています。
1. はじめに: 並列処理のパラドックス
マルチエージェント並列処理のケースは単純に見えます。複雑なタスクはサブタスクに分解されます。専門のエージェントはサブタスクを同時に実行します。合計実時間は「n」倍に減少します。この組織は、同じ暦時間で「n」倍のスループットを達成しています。
よく見るとケースは崩壊している。 2 つのエージェントが重複する状態で同時に動作すると、それらの出力が競合する可能性があります。 「n」個の並列出力を一貫した全体に統合する必要がある場合、統合自体が失敗点になります。そして、これらの障害の深刻度は直線的よりも速く増加します。ペアごとの境界違反の可能性の数は、「n(n-1)/2」、つまり「O(n²)」として増加します。 4 人のエージェントのシステムに 5 人のエージェントを追加しても、紛争の可能性は 25% 増加しません。約 60% 増加します。
この論文では、既存のマルチエージェント フレームワークがほとんど無視している質問、つまり、マルチエージェントの並列実行はどのような条件下で品質を維持または向上させますか?また、どのような条件下では品質を破壊しますか? について扱い、明示的な収束条件を備えた確率モデルの形で正式な答えを提供します。
答えはアルゴリズムではなくアーキテクチャにあります。大規模な品質は、個々のエージェントのインテリジェントさ、展開するエージェントの数、またはエージェントの実行速度によって決まりません。これは、(1) エージェントの範囲が互いに素であるかどうか、(2) 統合契約がゲート検証されているかどうか という 2 つの構造特性によって決まります。これら 2 つの特性を正しく理解している組織は、エージェント数を自由に拡張できます。そうしない組織では、エージェントを追加するときに品質の低下が発生し、個々のエージェントをいくら改善しても問題は解決されません。
2. タスク分解モデル
「T」を「n」個のサブタスク「{T_1, T_2, ..., T_n}」に分解された複合タスクとし、それぞれがサブタスク成功確率「p_i = P(success_i)」でエージェント「A_i」に割り当てられます。 部分成功 確率 (すべてのサブタスクが個別に正しく完了する確率) は次のとおりです。
これは、分解された実行と検索/探索タスクを区別する重要な観察です。探索タスク (例: 「有効な解決策を見つける」) では、成功確率は「1 - Π(1 - p_i)」で、「n」に応じて増加します。エージェントが多いほど、解決策を見つけるチャンスが増えることを意味します。分解された実行 (たとえば、「n 個のコンポーネントから完全なシステムを構築する」) では、成功確率は Π p_i ですが、各 p_i が非常に高くない限り、成功確率は n とともに減少します。
たとえば、「n = 4」のエージェントがそれぞれ「p_i = 0.95」である場合、パーツの成功率は「0.95⁴ ≈ 0.815」です。同じ個々の品質の「n = 8」エージェントの場合、「0.95⁸ ≈ 0.663」に低下します。エージェントごとの成功率が 95% であっても、エージェントを 8 つに拡張すると、統合の失敗を考慮する前に、パーツ期間だけで全体の信頼性の 3 分の 1 以上が失われます。
これにより、品質保持理論が必要な理由が明確になります。劣化条件を制限する正式な条件がなければ、マルチエージェント システムのスケーリングは品質崩壊の原因となります。
3. 境界違反と範囲の重複
各エージェント「A_i」は、定義されたスコープ「S_i」内で動作します。これは、「A_i」が変更を許可されている状態要素、リソース、意思決定ドメインのセットです。理想的なスコープの割り当てには 素 が必要です。
実際には、完全にバラバラになることはほとんどありません。エージェントは、共有状態を読み取ったり、共有インターフェイスを介して調整したり、スコープの境界間にあるエッジ ケースを処理したりする必要がある場合があります。 境界違反率 v_i を、エージェント A_i の実行がその定義された範囲 S_i の外側の状態に触れる確率として定義します。境界違反の合計確率は次のとおりです。
境界が侵害されると、エージェントは次の 3 種類の障害を生成します。 (1) 出力の競合 - 2 つのエージェントが同じリソースを互換性のない状態に変更する、(2) 作業の重複 - 2 つのエージェントが同じ計算を独立して実行し、リソースを浪費する、および (3) 状態の破損 - 1 つのエージェントの出力が別のエージェントの計算によって行われた仮定を無効にする。
MARIA OS アーキテクチャでは、スコープの割り当ては座標系の ゾーン/エージェントの配置に直接マッピングされます。各ゾーン「Z_k」はスコープの境界を定義します。同じゾーン内のエージェントはそのスコープに対する責任を共有しますが、ゾーン内の調整によって管理されます。異なるゾーンのエージェントは、アーキテクチャ上の強制により、互いに独立したスコープを持ちます。ゾーンの境界は慣例ではなく、意思決定パイプラインによって強制される構造上の制約です。
4. マージの失敗: 統合の問題
すべてのサブタスクが個別に成功し、スコープの境界が尊重される場合でも、「n」個の並列出力を一貫した結果に統合することは失敗する可能性があります。 マージ失敗確率 q_merge は、次の 3 つの要因によって決まります。
- 仕様ギャップ (`m`): サブタスク間のインターフェイス規約が欠落しているか、あいまいです。エージェント「A_1」の出力形式が、エージェント「A_2」が入力として期待するものと微妙に異なる場合、統合層はギャップを埋める必要があり、エラーが発生する可能性があります。
- セマンティックの不一致: 単独で完了したサブタスクは、局所的には正しいが、全体的には一貫性のない結果を生成する可能性があります。 2 つのエージェントが共有パラメータに関して異なる仮定を使用し、個別には有効でも組み合わせると互換性のない出力を生成する場合があります。
- 複雑さのスケーリング:「n」が増加すると、インターフェイスの数は線形パイプラインの場合は「O(n)」、完全に接続された統合の場合は「O(n²)」として増加します。各インターフェイスは潜在的な障害点となります。
最も効果的な軽減策は、マージを 実行タスクとしてではなく、検証ターゲットとして扱うことです。出力を結合する方法を「理解」するために統合エージェントに依存するのではなく、統合仕様を正式な契約として定義し、ゲート評価によって契約を検証します。 MARIA OS では、マージ コントラクトは証拠レイヤーに証拠として保存され、最終的な統合が進む前にゲート エンジンを通じて検証されます。
重要なのは、マージ仕様を明示的、ゲート検証済み、および不変にすることで、q_merge をゼロ近くに制限することができ、統合を無制限の創造的なタスクから決定論的な検証タスクに変換します。
5. 合計の成功確率
サブタスクの失敗、境界違反、マージの失敗という 3 つの失敗モードを組み合わせると、合計の成功確率は次のようになります。
単純な並列処理が品質を低下させる理由を理解するには、乗算構造が不可欠です。各乗算項は、全体の成功に対する 割引係数 として機能します。 q_merge = 0.15 (統合失敗の確率 15%) および q_overlap = 0.10 (境界違反の確率 10%) の場合、組み合わせた割引は 0.85 × 0.90 = 0.765 になります。つまり、サブタスクが完全に実行された場合 (Π p_i = 1.0) であっても、システムが達成する合計成功率は最大 76.5% になります。
これは、エージェントを追加するとスループットは向上しますが、不思議なことに品質が低下するという組織の一般的なエクスペリエンスを説明しています。この劣化は不思議なものではなく、相乗的に起こります。追加の各エージェントは、積に「p_i」係数を与え、重複確率に「v_i」項を追加し、「q_merge」の複雑さの項を増加させます。明確な対策がなければ、3 つの条件すべてが規模とともに悪化します。
6. 品質収束条件
品質 収束 は、次の 3 つの条件が同時に満たされる場合に限り、「n」が増加しても「P(合計)」が最小許容レベルを超えたままになることを意味します。
条件 1: 境界のあるオーバーラップ
q_overlap は n に関係なくゼロ付近に制限されます。これには、S_i ∩ S_j = ∅ を保証する 構造スコープの強制 (ガイドラインだけではありません) が必要です。 MARIA OS では、ゾーンベースのスコープ割り当てにより、この強制がアーキテクチャ的に提供されます。
条件 2: 境界付きマージの失敗
q_merge は n に関係なくゼロ付近に制限されます。これには、統合インターフェイスを正式に指定する固定されたゲート検証済みのマージ コントラクトが必要です。マージ仕様が明示的で統合前に検証されている場合、各ペアごとのインターフェイスが個別に検証されるため、「q_merge」は「n」とともに増加しません。
条件 3: サブタスクの品質下限
すべてのエージェントの「p_i ≥ p_0」。ここで、「p_0」は許容可能な最小サブタスク成功確率です。 p_0 = 0.95 および n = 8 の場合、パーツは Π p_i ≥ 0.95⁸ ≈ 0.663 で成功します。これは、q_merge と q_overlap がゼロに近い場合でも、使用可能なしきい値を依然として上回っています。
条件の崩壊。 逆に、q_merge または q_overlap のいずれかが n とともに成長すると、個々のエージェントの能力に関係なく品質が崩壊します。数学的証明は簡単です。ある c > 0 に対して q_overlap = c · n (線形成長) の場合、n → ∞ として (1 - q_overlap) → 0 となり、P(total) → 0 となります。品質の崩壊はリスクではありません。制御されていないスケーリングの下では数学的に確実です。
7. 人間とエージェントの最適な比率
品質収束モデルの自然な拡張として、どの程度人間の関与が最適であるかという問題が生じます。人間によるレビューが必要な意思決定ノードの最適な部分として「H*」を定義します。
ここで、「I」、「U」、「N」、「A」は、意思決定グラフ全体の平均的な影響、不確実性、新規性、説明責任です。重要な発見は、完全自動化の支持者を驚かせるかもしれませんが、*完全自動化 (`H = 0`) は決して最適ではないということです。**
この推論は、マージ失敗の分析から得られます。統合ポイントにおける人間のレビュー担当者は、暗黙的なマージ検証者として機能します。彼らは、自動化されたマージ コントラクトが見逃すセマンティックの不一致を検出します。 H* をゼロに減らすと、この検証層が削除され、q_merge が増加します。人間の関与によるスループット コストとマージ検証の品質上の利点のバランスを取ることで、システム全体のリスクを最小限に抑える、ゼロ以外の「H*」が存在します。
MARIA OS 導入の経験的結果は、ドメインに応じて「H* ≈ 0.15 ～ 0.30」（人間の監視が関与する決定の 15 ～ 30%）を示唆しています。これは責任分解モデルと一致しています。「τ」閾値は、自然に、高い「R(d)」の決定のほぼこの部分を人間のレビューにルーティングします。
8. MARIA OSでの運用化
品質収束モデルは MARIA OS コンポーネントに直接マッピングされます。
- ゾーンベースのスコープ割り当て = `S_i` 定義。 MARIA 座標系の各ゾーンはスコープ境界を定義します。ゾーン スキーマ (
db/schema/zones.ts) は、どのリソース、ドメイン、および意思決定タイプが各ゾーンの権限内にあるかをエンコードします。境界違反 (「v_i」) は、明示的な調整なしでクロスゾーン状態の変更として検出できます。 - 証拠層 = マージ コントラクト ストレージ。 マージ仕様は、来歴追跡、バージョン管理、および不変性を備えた証拠バンドル (
lib/engine/evidence.ts) として保存されます。エージェント「A_1」がコンポーネントを出力し、エージェント「A_2」がそれを統合する必要がある場合、インターフェース仕様は証拠アーティファクトです。 - ゲート エンジン = マージ コントラクトの検証。 統合が進む前に、ゲート エンジンはマージ仕様が満たされているかどうかを評価します。インターフェイス規約に違反すると、ゲートがブロックされてエスカレートし、個々の決定に使用されるのと同じフェールクローズ原則が適用されます。
- エージェント契約 (JSON スキーマ)。 エージェント スコープ定義はエージェント契約スキーマに従い、
scope_S(承認されたドメインの配列)、expected_success_p0、およびboundary_policy(分離された施行と最大違反しきい値v) を指定します。これらの契約はバージョン管理されており、監査可能です。
リアルタイム監視では、「v_i」 (ゾーンごとの境界違反イベント)、「q_merge」 (マージ ポイントごとの統合失敗率)、および「P(合計)」 (ローリング成功確率) を追跡します。ダッシュボード パネルには、スケールでの品質曲線、境界違反ヒートマップ、およびマージ成功の傾向が表示され、抽象的な確率モデルが視覚化され、実行可能になります。
9. 実験プロトコル
制御された境界とマージ条件を使用したスケーリング実験を提案します。
セットアップ。 n = 1、2、4、6、8 サブタスクに分解可能な複雑なタスク T を定義します。 「n」ごとに、スコープが定義された「n」個のエージェントをデプロイし、コントラクトをマージします。
ケース A: 境界が不明瞭。 スコープは非公式に定義されています (自然言語による記述)。マージ契約は存在せず、統合は調整エージェントの判断に委ねられます。これは、ほとんどのマルチエージェント フレームワークにおける現在の実施状況を表しています。
ケース B: 明示的な境界。 スコープは形式的には互いに素です (ゾーン強制)。マージコントラクトは証拠として保存され、ゲート検証されます。これは MARIA OS アーキテクチャを表します。
測定。 各 (n, case) ペアについて、200 個のタスクを処理し、次を記録します: p_i (エージェントごとのサブタスク成功)、v_i (エージェントごとの境界違反率)、q_merge (マージ失敗率)、P(total) (合計成功)。 スケール時の品質曲線: P(total) と両方のケースの n をプロットします。
仮説。 ケース A は品質の崩壊を示します。「P(合計)」は「n」とともに単調減少し、「n ≈ 6」で 0.50 を下回ります。ケース B は品質の収束を示します。「P(total)」はすべての「n ≤ 8」で 0.90 を超え、「q_overlap < 0.03」および「q_merge < 0.05」を維持します。
10. ディスカッション
10.1 建築資産としての品質
このモデルの中心的な教訓は、マルチエージェントの品質はエージェント レベルの特性ではなく、アーキテクチャ の特性であるということです。個々のエージェントの能力を向上させる (「p_i」を増やす) ことは役に立ちますが、その効果には限界があります。すべてのエージェントの「p_i = 0.99」であっても、「P_parts = 0.99⁸ ≈ 0.923」となります。一方、「q_overlap」を 0.15 から 0.03 に減らすと、全体の成功率が 12 パーセント ポイント改善され、限界利益が大幅に増加します。マルチエージェントの品質に対する ROI が最も高い投資は、個々のエージェントのトレーニングではなく、境界定義とマージ検証です。
10.2 マイクロサービスの類似点
品質収束モデルは、分散システム エンジニアリングのよく知られたパターンを反映しています。 制限されたコンテキストが強制され (各サービスがそのデータを所有する)、インターフェイス コントラクトが明示的である場合 (API スキーマ、バージョン管理されたプロトコル)、マイクロサービス アーキテクチャは確実にスケーリングします。これらのアーキテクチャ上の制約がなければ、マイクロサービスはカスケード障害、データの不整合、統合の悪夢を引き起こします。同じ構造原則がマルチエージェント システムにも当てはまります。つまり、スコープが切り離されているとカスケード障害が防止され、コントラクトがマージされると統合の悪夢が防止されます。
10.3 制限事項
このモデルは、サブタスクの成功確率 p_i 間の独立性を前提としています。実際には、エージェントは上流の依存関係 (障害が発生した共通のデータ ソースなど) を共有し、製品モデルでは捉えられない相関障害が発生する可能性があります。相関するサブタスクの失敗を考慮してフレームワークを拡張することは、今後の作業の重要な方向性です。
11. 結論
この論文では、マルチエージェントの品質は、確率と境界の問題であり、次の 3 つの正式な法則があることが証明されました。
- 法則 1: 互いに素なスコープを定義する。 ガイドラインではなくアーキテクチャ上の強制によって「S_i ∩ S_j = ∅」を保証する。これは、エージェント数に関係なく、
q_overlapをゼロに近づけます。 - 法則 2: マージ コントラクトのゲート検証。 統合仕様をゲート評価の対象となる証拠成果物として扱います。これにより、
q_mergeがゼロに近くなり、統合が決定的になります。 - 法則 3: 境界違反を監視します。 システムの健全性指標として「v_i」と「q_merge」を継続的に測定します。品質の崩壊に先立って、境界違反が徐々に増加します。崩壊する前に検出して修正します。
総合成功モデル「P(total) = Π(p_i) · (1 - q_merge) · (1 - q_overlap)」は、マルチエージェント システムの品質を予測、監視、改善するための定量的なフレームワークを提供します。乗算的な構造により、利害関係が明確になります。大規模な品質は、個人の優秀さによるものではありません。建築工事の契約についてです。
今後の作業には、境界順守のためのゲーム理論的なインセンティブ設計 (エージェントがスコープ境界を遵守するようにインセンティブを与えることを保証する)、相関障害モデリング、およびサブタスクが再帰的に分解される階層型マルチエージェント システムへの拡張が含まれます。