ガバナンス負荷テスト: 1000 エージェント時代のガバナンスはどこで破綻するのか?

1. はじめに: ガバナンスは直線的に拡大しない

AI エージェントを導入するすべての組織は、ガバナンスのオーバーヘッドがエージェントの数よりも速く増加するという、同じ不快な発見に直面します。 10 人のエージェント チームに 11 人目のエージェントを追加すると、ガバナンスの負荷が約 10% 増加します。 100 人のエージェント フリートに 101 人目のエージェントを追加すると、ガバナンスの負荷が約 30% 増加します。 1000 エージェントの展開に 1001 番目のエージェントを追加すると、ガバナンスの負荷が 300% 以上増加する可能性があります。

根本的な原因は組み合わせによるものです。ガバナンスはエージェントごとのプロパティではなく、関係 プロパティです。すべての決定は、他のエージェントの決定を参照する制約に照らしてチェックされる必要があります。すべての承認には同時操作に関するコンテキストが必要です。すべての競合検出スキャンでは、ペアごとの相互作用を考慮する必要があります。ガバナンスの表面積は単純なケースでは O(n^2) のように増大し、ハードウェアをいくらスケーリングしてもアーキテクチャの複雑さのクラスの不一致を克服することはできません。

MARIA OS は、責任ゲート、証拠バンドル、監査証跡を備えた 6 段階の意思決定パイプラインを実装しています。このアーキテクチャはスケーラビリティを念頭に置いて設計されていますが、適切に設計されたシステムであっても限界点は存在します。問題は、負荷がかかっているときにガバナンスが「壊れるかどうか」ではなく、「どこで」、「いつ」、そして「実際的な制約でなくなるまで限界点を遅らせる方法」です。

For n concurrent agents with d average decisions per cycle and c constraint checks per decision, naive governance overhead scales as O(n * d * c + n^2 * k) where k is the conflict detection cost per pair. The n^2 term dominates beyond ~200 agents.

2. 意思決定パイプラインのスループット分析

MARIA OS 意思決定パイプラインは、提案、検証、承認要求、承認、実行、完了 (または失敗) の 6 つの段階を通じて意思決定を処理します。各遷移により、不変の監査レコードが作成されます。同時実行性が低い場合、このパイプラインはエンドツーエンドで約 12 ミリ秒で決定を処理します。しかし、大規模な場合はどうなるでしょうか?

意思決定パイプラインを、各ステージがサービス ステーションであるタンデム キューイング ネットワークとしてモデル化します。決定は、エージェント数に比例するレート ラムダを使用するポアソン プロセスに従って到着します。

\lambda(n) = n \cdot \bar{d} \cdot \frac{1}{T_{cycle}}

where:
\bar{d} = average decisions per agent per cycle (measured: 3.7)
T_{cycle} = governance cycle duration (1 second)
n = concurrent agent count

At n = 1000: \lambda = 3,700 decisions/second

各パイプライン ステージには、そのステージの計算の複雑さに依存するサービス レート mu があります。検証ステージでは制約チェック (mu_v) が実行され、承認ステージではキュー管理とルーティング (mu_a) が行われ、実行ステージではダウンストリーム アクション (mu_e) がトリガーされます。

// Decision pipeline throughput model
interface PipelineStage {
  name: string;
  serviceRate: number;       // mu: decisions/second capacity
  servers: number;            // c: parallel processing capacity
  utilizationAt: (n: number) => number;
}

const stages: PipelineStage[] = [
  {
    name: "validation",
    serviceRate: 8500,        // mu_v: constraint checks/sec
    servers: 4,
    utilizationAt: (n) => (n * 3.7) / (4 * 8500),
  },
  {
    name: "approval_routing",
    serviceRate: 2200,        // mu_a: approval route/sec
    servers: 2,
    utilizationAt: (n) => (n * 3.7 * 0.4) / (2 * 2200),
  },
  {
    name: "gate_evaluation",
    serviceRate: 1800,        // mu_g: gate evals/sec
    servers: 2,
    utilizationAt: (n) => (n * 3.7 * 0.4) / (2 * 1800),
  },
  {
    name: "execution",
    serviceRate: 12000,       // mu_e: executions/sec
    servers: 8,
    utilizationAt: (n) => (n * 3.7) / (8 * 12000),
  },
];

// Find saturation point per stage
function findSaturationPoint(stage: PipelineStage): number {
  // Saturation at utilization rho >= 0.95
  // rho = lambda / (c * mu) = n * d_bar / (c * mu)
  return Math.floor(0.95 * stage.servers * stage.serviceRate / 3.7);
}

// Results:
// validation:      saturation at n = 8,729
// approval_routing: saturation at n = 1,135
// gate_evaluation:  saturation at n = 929   <-- BOTTLENECK
// execution:        saturation at n = 24,648

ゲート評価段階が最初のボトルネックであり、デフォルト構成では約 929 エージェントで飽和状態になります。ただし、実際の劣化ははるかに早い段階で始まります。どの段階でもキューの深さが許容範囲を超えると、エンドツーエンドの遅延が非線形に急増します。

3. 承認キューの飽和と際限のない増加

すべての決定に承認が必要なわけではありません。一般的な MARIA OS の導入では、意思決定の約 40% が Approved_required 状態をトリガーし、人間または上級エージェントのレビュー担当者にルーティングされます。承認キューにはスループットが本質的に制限されているヒューマンインザループ (HITL) 処理が含まれるため、承認キューは最も危険なスケーリングのボトルネックです。

承認キューを M/M/c キューとしてモデル化します。ここで、c は同時承認者 (人間または代理エージェントのレビュー担当者) の数です。

Approval arrival rate: \lambda_a = 0.4 \cdot n \cdot \bar{d} / T_{cycle}

For stability: \rho = \lambda_a / (c \cdot \mu_{approver}) < 1

Human approver: \mu_{human} \approx 0.033 approvals/sec (2 per minute)
Agent reviewer: \mu_{agent} \approx 5.0 approvals/sec

With 5 human approvers + 10 agent reviewers:
c_{eff} \cdot \mu_{eff} = 5(0.033) + 10(5.0) = 50.165 approvals/sec

Stability limit: n < 50.165 \cdot T_{cycle} / (0.4 \cdot \bar{d}) = 33.9 agents

With pure agent review (50 reviewers):
n < 50(5.0) / (0.4 \cdot 3.7) \approx 168.9 agents

この結果は驚くべきものです。人間参加型の承認者が加わると、承認キューはエージェントがわずか 34 人になると不安定になります (際限なく増加します)。純粋なエージェントレビュー担当者が 50 人いたとしても、システムは 169 人のエージェントで飽和します。承認待ちのキューは単なるボトルネックではなく、ガバナンスの崖です。

Under default HITL configuration, the approval queue grows unbounded beyond 34 concurrent agents. Pending approvals accumulate at rate (lambda_a - c*mu) per second, creating a governance debt that can never be repaid during operation. Decisions pile up, SLAs breach, and agents either stall (waiting for approval) or bypass governance (if timeout fallbacks exist).

4. 同時負荷時のゲート評価レイテンシ

MARIA OS の責任ゲートは、エージェントが意思決定を進めるための権限、証拠、状況に応じたクリアランスを持っているかどうかを評価します。各ゲートの評価には、(1) MARIA 階層内の権限検索の調整、(2) 証拠バンドルの検証、(3) アクティブなポリシーに対する制約満足度のチェック、および (4) 同時決定に対する競合の事前スクリーニングが含まれます。

同時実行性が低い場合、ゲート評価は 3 ～ 8 ミリ秒で完了します。同時実行性が高い場合は、ステップ (4) (競合の事前スクリーニング) が優先されます。これは、関連するゾーン全体で一連の実行中の決定を検査する必要があるためです。

// Gate evaluation latency model
interface GateLatencyProfile {
  agentCount: number;
  coordinateLookup_ms: number;    // O(log n) - tree traversal
  evidenceVerify_ms: number;       // O(1) - hash check
  constraintCheck_ms: number;      // O(p) - p active policies
  conflictPrescreen_ms: number;    // O(k) - k in-flight decisions in zone
  total_p50_ms: number;
  total_p99_ms: number;
}

const profiles: GateLatencyProfile[] = [
  {
    agentCount: 10,
    coordinateLookup_ms: 0.3,
    evidenceVerify_ms: 1.2,
    constraintCheck_ms: 2.1,
    conflictPrescreen_ms: 0.8,
    total_p50_ms: 4.4,
    total_p99_ms: 8.1,
  },
  {
    agentCount: 100,
    coordinateLookup_ms: 0.5,
    evidenceVerify_ms: 1.3,
    constraintCheck_ms: 4.7,
    conflictPrescreen_ms: 12.3,
    total_p50_ms: 18.8,
    total_p99_ms: 67.2,
  },
  {
    agentCount: 1000,
    coordinateLookup_ms: 0.8,
    evidenceVerify_ms: 1.4,
    constraintCheck_ms: 14.2,
    conflictPrescreen_ms: 187.5,
    total_p50_ms: 203.9,
    total_p99_ms: 2340.0,
  },
  {
    agentCount: 10000,
    coordinateLookup_ms: 1.1,
    evidenceVerify_ms: 1.5,
    constraintCheck_ms: 48.3,
    conflictPrescreen_ms: 18720.0,  // O(n) scan of in-flight set
    total_p50_ms: 18771.0,
    total_p99_ms: 47200.0,
  },
];

エージェントが 1000 の場合、p99 ゲート評価のレイテンシは 2.34 秒で、すでに 1 秒のガバナンス サイクルを超えています。エージェントが 10,000 の場合、p50 遅延だけでも 18.7 秒です。これは、すべてのゲート評価の 半分 がガバナンス サイクルよりも長いことを意味します。システムは構造的に、アーキテクチャを変更しない限り、この規模でのガバナンスを実現できません。

5. 競合検出の急増: O(n^2) 問題

競合検出は、最も計算コストのかかるガバナンス操作です。エージェント A が決定を提案する場合、ガバナンス システムは、この決定が、関連するスコープ全体でエージェント B、C、D、... によって提案された決定または進行中の決定と矛盾しないことを検証する必要があります。最悪の場合、すべての決定を他のすべての実行中の決定と照合する必要があります。

Pairwise conflict checks per cycle:
C(n) = \binom{n \cdot \bar{d}}{2} = \frac{n\bar{d}(n\bar{d} - 1)}{2}

At n = 10:    C = \binom{37}{2} = 666 checks
At n = 100:   C = \binom{370}{2} = 68,265 checks
At n = 1000:  C = \binom{3700}{2} = 6,843,150 checks
At n = 10000: C = \binom{37000}{2} = 684,481,500 checks

With conflict check cost \tau = 0.05ms per pair:
At n = 1000:  total = 342.2 seconds per cycle (342x real-time)
At n = 10000: total = 34,224 seconds per cycle (9.5 hours)

これが基本的なスケーリングの壁です。ペアごとの競合検出は O(n^2) であり、定数因子最適化ではこれを克服できません。エージェントが 1,000 個の場合、システムは 1 秒のガバナンス サイクルごとに 342 秒のコンピューティングを必要とし、これは 342 倍の不足になります。アーキテクチャを O(n^2) から根本的により優れたものに変更する必要があります。

6. 証拠検証のバックログ

MARIA OS でのすべての決定には、決定を正当化するデータ ポイント、ログ、および証明書のコレクションである証拠バンドルが伴う必要があります。証拠の検証には、ハッシュの整合性チェック、来歴の検証、および関連性のスコアリングが含まれます。個別の検証は高速 (約 1.2 ミリ秒) ですが、同時実行性が高い場合、集約負荷によりバックログが作成されます。

証拠検証パイプラインは、バンドルを FIFO 順に処理します。 1,000 人のエージェントがそれぞれ 1 秒あたり 3.7 件の決定を行う場合、パイプラインは 1 秒あたり 3,700 の証拠バンドルを検証する必要があります。各バンドルには平均 4.2 個の証拠アイテムが含まれており、1 秒あたり 15,540 個の個別検証が行われます。

// Evidence verification backlog model
interface EvidenceBacklog {
  agentCount: number;
  bundlesPerSecond: number;
  itemsPerBundle: number;
  verifyTime_ms: number;
  requiredThroughput: number;  // items/sec
  actualThroughput: number;    // items/sec (4 workers)
  backlogGrowth: number;       // items/sec accumulation
  timeToSLA_breach_sec: number; // when backlog > 1000
}

const backlogs: EvidenceBacklog[] = [
  { agentCount: 10,    bundlesPerSecond: 37,    itemsPerBundle: 4.2,
    verifyTime_ms: 1.2, requiredThroughput: 155,
    actualThroughput: 3333, backlogGrowth: 0, timeToSLA_breach_sec: Infinity },
  { agentCount: 100,   bundlesPerSecond: 370,   itemsPerBundle: 4.2,
    verifyTime_ms: 1.2, requiredThroughput: 1554,
    actualThroughput: 3333, backlogGrowth: 0, timeToSLA_breach_sec: Infinity },
  { agentCount: 1000,  bundlesPerSecond: 3700,  itemsPerBundle: 4.2,
    verifyTime_ms: 1.2, requiredThroughput: 15540,
    actualThroughput: 3333, backlogGrowth: 12207, timeToSLA_breach_sec: 0.08 },
  { agentCount: 10000, bundlesPerSecond: 37000, itemsPerBundle: 4.2,
    verifyTime_ms: 1.2, requiredThroughput: 155400,
    actualThroughput: 3333, backlogGrowth: 152067, timeToSLA_breach_sec: 0.007 },
];

4 つの検証ワーカー (デフォルト構成) を使用すると、スループット容量は 1 秒あたり 3,333 アイテムになります。これは、最大 794 人のエージェントに十分です。そのしきい値を超えると、証拠検証のバックログが継続的に増加し、1,000 人以上のエージェントでミリ秒以内に SLA に違反します。承認キュー (委任によって緩和できる) とは異なり、証拠の検証は厳密な整合性要件です。検証をスキップすると、監査の保証が無効になります。

7. MARIA 調整ルーティングのオーバーヘッド

MARIA 座標系 (G.U.P.Z.A) は、すべてのエージェントに階層的なアドレス指定を提供します。すべてのガバナンス操作には座標の解決が必要です。つまり、どの銀河、宇宙、惑星、ゾーン、エージェントが関与しているのか、各レベルでどのようなガバナンス ルールが適用されるのかを決定します。

調整ルーティングは、各レベルでポリシー ルックアップを行うツリー トラバーサルとして実装されます。深さは 5 レベル (G、U、P、Z、A) に固定されているため、エージェント数に関して個々の検索は O(1) になります。ただし、集約 ルーティング負荷は決定量に比例して増加し、個別の座標の数が増加するにつれてポリシー キャッシュ ヒット率は低下します。

Cache miss rate as a function of coordinate space utilization:

m(n) = 1 - \left(1 - \frac{1}{|\mathcal{C}|}\right)^{n}

where |\mathcal{C}| is the coordinate space size (product of G, U, P, Z, A cardinalities)

For a typical deployment:
|\mathcal{C}| = 2 \times 5 \times 10 \times 8 \times 50 = 40,000 coordinates

At n = 100:   utilized coordinates \approx 100,  cache hit \approx 99.7%
At n = 1000:  utilized coordinates \approx 980,   cache hit \approx 97.6%
At n = 10000: utilized coordinates \approx 8,800, cache hit \approx 80.2%

Routing latency: t_{route}(n) = t_{hit} + m(n) \cdot (t_{miss} - t_{hit})
At n = 100:   t_{route} = 0.2 + 0.003 \cdot 4.8 = 0.21ms
At n = 10000: t_{route} = 0.2 + 0.198 \cdot 4.8 = 1.15ms

調整ルーティングのオーバーヘッドは単独で管理可能です -- 10000 エージェントで 1.15 ミリ秒は許容可能です。ただし、ルーティングはゲート評価ごとに複数回呼び出されるため (エージェント調整に対して 1 回、ポリシー スコープごとに 1 回、競合ターゲットごとに 1 回)、影響が増幅されます。エージェントが 10,000 人で、ゲート評価ごとに平均 7 回のルーティング ルックアップを行う場合、ルーティングはゲート遅延に 8.05 ミリ秒の影響を及ぼします。これは重大ではありますが、主要なボトルネックではありません。

8. ストレステストの方法論

MARIA OS 意思決定パイプラインに対して現実的なエージェントのワークロードをシミュレートするガバナンス負荷テスト フレームワークを開発しました。フレームワークは、ランプ、サステイン、スパイク、ドレインの 4 つのフェーズで動作します。

// Governance load test configuration
interface LoadTestConfig {
  phases: LoadPhase[];
  agentProfile: AgentProfile;
  governanceConfig: GovernanceConfig;
  metrics: MetricCollector;
}

interface LoadPhase {
  name: "ramp" | "sustain" | "spike" | "drain";
  duration_sec: number;
  targetAgentCount: number;
  rampRate?: number;  // agents/second during ramp
}

interface AgentProfile {
  decisionsPerCycle: { mean: number; stddev: number };  // Normal dist
  decisionComplexity: "low" | "medium" | "high";
  approvalRate: number;           // fraction requiring approval
  conflictProbability: number;    // P(conflict with any other)
  evidenceItemsPerDecision: { mean: number; stddev: number };
  coordinateDistribution: "clustered" | "uniform" | "hotspot";
}

// Standard test profile
const standardProfile: AgentProfile = {
  decisionsPerCycle: { mean: 3.7, stddev: 1.2 },
  decisionComplexity: "medium",
  approvalRate: 0.4,
  conflictProbability: 0.02,
  evidenceItemsPerDecision: { mean: 4.2, stddev: 1.8 },
  coordinateDistribution: "clustered",
};

// Load test phases for 1000-agent test
const phases: LoadPhase[] = [
  { name: "ramp",    duration_sec: 60,  targetAgentCount: 1000, rampRate: 20 },
  { name: "sustain", duration_sec: 300, targetAgentCount: 1000 },
  { name: "spike",   duration_sec: 30,  targetAgentCount: 2000 },
  { name: "drain",   duration_sec: 120, targetAgentCount: 0,    rampRate: -10 },
];

方法論における主要な設計上の決定: (1) エージェントの決定は、現実的なワークロードの分散を反映し、サイクルあたりの測定平均 3.7 を中心とする正規分布に従います。 (2) 「coownedDistribution: 'clustered'」設定により、エージェントが座標空間全体に均一に分散するのではなく、現実的なゾーン グループに集中するようになります。 (3) スパイク フェーズでは、バースト回復力をテストするために、エージェントの数を 30 秒間 2 倍にします。 (4) すべてのメトリクスは、ナノ秒のタイムスタンプを使用して 100 ミリ秒の粒度で収集されます。

8.1 収集されるメトリクス

9. ブレークポイントの特定: ガバナンスが失敗する場所

10 ～ 10,000 のエージェント数でストレス テストを実行したところ、異なるスケールのしきい値でトリガーされる 5 つの異なるガバナンス障害モードが特定されました。

9.1 故障モードの分類

効果的なガバナンスの限界点は、これらのしきい値の最小値です。デフォルト設定では、F1 (HITL を使用する ~34 エージェントでの承認キュー オーバーフロー) が最初の失敗です。純粋なエージェントのレビューでは、F4 (約 200 のエージェントでの競合検出) が拘束制約となります。 F1 から F4 までを緩和した後でのみ、パイプラインのスループット制限 (約 929 エージェントでの F5) が上限になります。

Governance does not fail at a single point -- it degrades across multiple dimensions simultaneously. The 'breaking point' is the agent count at which the first governance invariant is violated. Under default MARIA OS configuration, this occurs at approximately 34 agents (HITL approval) or 200 agents (pure agent review). The commonly assumed limit of ~340 agents represents the point where gate evaluation alone fails, ignoring approval and conflict detection constraints.

10. 正式なキューイング理論モデル

古典的なキュー理論を使用して各ガバナンスのボトルネックをモデル化し、キューの深さ、待機時間、安定性条件の閉形式を導き出します。

10.1 M/M/c キューとしての意思決定パイプライン

各パイプライン ステージは、M/M/c キュー (ポアソン到着、指数関数的サービス、c サーバー) としてモデル化されます。

For stage j with arrival rate \lambda_j, service rate \mu_j, and c_j servers:

Utilization: \rho_j = \frac{\lambda_j}{c_j \mu_j}

Stability condition: \rho_j < 1

Erlang C probability (probability of queueing):
C(c_j, A_j) = \frac{\frac{A_j^{c_j}}{c_j!} \cdot \frac{1}{1 - \rho_j}}{\sum_{k=0}^{c_j - 1} \frac{A_j^k}{k!} + \frac{A_j^{c_j}}{c_j!} \cdot \frac{1}{1 - \rho_j}}

where A_j = \lambda_j / \mu_j (offered load)

Expected waiting time: W_j = \frac{C(c_j, A_j)}{c_j \mu_j (1 - \rho_j)}

Expected queue depth: L_{q,j} = \lambda_j \cdot W_j

10.2 M/G/1 キューとしての競合検出

競合検出のサービス時間は非指数関数的であるため (現在の飛行中の決定数に依存します)、Pollaczek-Khinchine 式を備えた M/G/1 モデルを使用します。

Conflict detection service time: S = \tau \cdot k(t)
where k(t) is the number of in-flight decisions at time t

E[S] = \tau \cdot E[k] = \tau \cdot \lambda \cdot \bar{T}_{pipeline}
Var[S] = \tau^2 \cdot Var[k]

Pollaczek-Khinchine mean queue depth:
L_q = \frac{\rho^2 + \lambda^2 \cdot Var[S]}{2(1 - \rho)}

where \rho = \lambda \cdot E[S]

As n increases, E[k] grows linearly with n, making E[S] grow linearly.
Since \rho = \lambda \cdot E[S] \propto n^2, the queue becomes unstable at:
n_{critical} = \sqrt{\frac{1}{\bar{d}^2 \cdot \tau \cdot \bar{T}_{pipeline}}}

11. 緩和戦略

4 つのアーキテクチャ変更により、ガバナンス スケーリングが O(n^2) から O(n log n) に変換され、実際の制限が約 340 エージェントから 12,000 エージェントに拡張されました。

11.1 階層的な委任

すべての承認を中央プールにルーティングする代わりに、承認権限を MARIA 座標階層の下位に委任します。ゾーンレベルのエージェント (Z レベル) は、惑星または宇宙レベルにエスカレーションすることなく、ゾーン内の決定を承認できます。クロスゾーンまたは影響の大きい決定のみが上方にエスカレートされます。

// Hierarchical delegation configuration
interface DelegationPolicy {
  level: "zone" | "planet" | "universe" | "galaxy";
  canApprove: (decision: Decision) => boolean;
  escalationCriteria: EscalationRule[];
}

const delegationPolicies: DelegationPolicy[] = [
  {
    level: "zone",
    canApprove: (d) =>
      d.impactScore < 0.3 &&
      d.scope === "intra-zone" &&
      d.reversibility > 0.7,
    escalationCriteria: [
      { condition: "cross-zone", escalateTo: "planet" },
      { condition: "highImpact", escalateTo: "universe" },
    ],
  },
  {
    level: "planet",
    canApprove: (d) =>
      d.impactScore < 0.6 &&
      d.scope !== "cross-planet",
    escalationCriteria: [
      { condition: "cross-planet", escalateTo: "universe" },
      { condition: "irreversible", escalateTo: "universe" },
    ],
  },
];

// Effect: ~85% of approvals handled at zone level
// Reduces approval queue load by 6x at 1000 agents

11.2 一括承認

同様の決定を承認バッチにグループ化します。同じゾーン内の複数のエージェントが同様の決定 (同じ決定タイプ、同様のパラメーター、同じ制約プロファイル) を提案する場合、1 回の承認でバッチ全体がカバーされます。

バッチ承認では、ゾーン内の意思決定のクラスタリング係数に比例して承認量が減少します。経験的に、類似性しきい値 0.85 のエージェント 1,000 名で承認数が 4.2 倍減少することが測定されました。

11.3 予測ゲート

ゲートを事後的に (決定が提案された後) 評価するのではなく、決定がパイプラインに入る「前」に、その決定がゲート評価を通過するかどうかを予測します。エージェントは、信頼スコアを返す予測ゲート モデルをクエリします。高い予測通過確率 (> 0.95) を持つ決定は、完全な競合事前スクリーニングをスキップするファストトラック パイプラインに入ります。ゲートの結果が不確実な決定のみが完全な評価を受けます。

Predictive gate model:
\hat{g}(d_i) = \sigma(w^T \phi(d_i, \mathcal{H}_t))

where:
\phi(d_i, \mathcal{H}_t) = feature vector from decision d_i and governance history \mathcal{H}_t
\sigma = sigmoid function

Fast-track fraction: f(n) = P(\hat{g}(d_i) > 0.95)

Measured f(n) across scales:
f(10) = 0.92   (92% of decisions fast-tracked)
f(100) = 0.84  (84% fast-tracked)
f(1000) = 0.71 (71% fast-tracked)
f(10000) = 0.63 (63% fast-tracked)

Effective gate evaluation load reduction:
\lambda'_{gate} = (1 - f(n)) \cdot \lambda_{gate}

11.4 ゾーンスコープの競合パーティショニング

O(n^2) の競合検出問題は、MARIA 座標階層によって分解できます。同じゾーン内のエージェントは、ゾーン内の競合がチェックされます (ゾーンあたり O(z^2)、z はゾーンあたりのエージェント)。ゾーン間の競合は、個々の決定ではなく、ゾーン レベルの 決定サマリー を比較することによって検出され、O(Z^2) が得られます。ここで、Z はゾーンの数 (Z << n) です。合計の複雑さは O(n * z + Z^2) になり、バランスのとれたゾーン分布の場合は O(n log n) になります。

// Zone-scoped conflict detection
interface ZoneConflictPartition {
  zoneId: string;
  agentsInZone: number;
  intraZoneChecks: number;       // O(z^2) within zone
  zoneSummary: DecisionSummary;  // Aggregated zone-level summary
}

function partitionedConflictDetection(
  decisions: Decision[],
  zones: Zone[]
): ConflictResult[] {
  const results: ConflictResult[] = [];

  // Phase 1: Intra-zone conflict detection (parallelizable)
  for (const zone of zones) {
    const zoneDecisions = decisions.filter(
      (d) => d.coordinate.zone === zone.id
    );
    // O(z^2) per zone, but z is small (~20-50 agents per zone)
    results.push(...detectPairwiseConflicts(zoneDecisions));
  }

  // Phase 2: Cross-zone conflict detection via summaries
  const summaries = zones.map((z) => buildZoneSummary(z, decisions));
  // O(Z^2) where Z = number of zones << n
  for (let i = 0; i < summaries.length; i++) {
    for (let j = i + 1; j < summaries.length; j++) {
      if (summariesMayConflict(summaries[i], summaries[j])) {
        // Only expand to pairwise when summary-level conflict detected
        results.push(
          ...detectCrossZoneConflicts(summaries[i], summaries[j])
        );
      }
    }
  }

  return results;
}

// Complexity analysis:
// n agents, Z zones, z = n/Z agents per zone
// Intra-zone:  Z * O(z^2) = Z * O((n/Z)^2) = O(n^2/Z)
// Cross-zone:  O(Z^2) + expansion cost
// With Z = O(sqrt(n)): total = O(n * sqrt(n)) = O(n^1.5)
// With Z = O(n/log(n)): total = O(n * log(n))

12. 大規模なベンチマーク結果

ネイティブ (デフォルト) 構成と最適化された構成の両方で、4 つのスケール ポイント (10、100、1000、10000 エージェント) で全負荷テスト スイートを実行しました。すべてのテストは同一のインフラストラクチャ (16 コア、64 GB RAM、NVMe ストレージ) 上で実行されました。

12.1 単純な構成の結果

単純な構成はエージェントが 10,000 になると完全に失敗します。単一の決定によって完全なガバナンス パイプラインが完了することはありません。エージェントが 1,000 人いる場合、決定の 27.7% が破棄され (ガバナンス タイムアウト)、残りの 72.3% の監査証跡は不完全になります。

12.2 最適化された構成の結果

最適化されたアーキテクチャは、1000 エージェントまでは 100%、10000 エージェントでは 99.94% のガバナンスの整合性を維持します。 1,000 エージェントでのゲート評価 p99 は 2,340 ミリ秒から 47 ミリ秒に低下し、49.8 倍の改善です。 O(n^2) ペアワイズ スキャンを排除することで、競合検出コストが 1 サイクルあたり 342 秒から 48.7 ミリ秒に減少します。これは 7,025 倍の改善 です。

The four mitigation strategies collectively extend the governance breaking point from ~340 agents to ~12,000 agents -- a 35x improvement. Beyond 12,000 agents, the evidence verification pipeline becomes the next binding constraint, requiring horizontal scaling of verification workers.

12.3 スケーリングの軌道と予測される限界

Governance capacity under optimized architecture:

n_{max} = \min\left(
  \frac{c_{gate} \cdot \mu_{gate}}{\bar{d} \cdot (1 - f(n))}, \quad
  \sqrt{\frac{T_{cycle}}{\tau \cdot \bar{d}^2 / Z}}, \quad
  \frac{c_{ev} \cdot \mu_{ev}}{\bar{d} \cdot \bar{e}}, \quad
  \frac{\sum_l c_l \cdot \mu_l}{\bar{d} \cdot (1 - h(n))}
\right)

Substituting measured values:
n_{max} = \min(14,200, \; 12,800, \; 12,400, \; 18,900) = 12,400

The evidence verification pipeline (third term) is the binding constraint
at the next scale frontier.

13. 結論: スケーリングアーキテクチャの問題としてのガバナンス

大規模なガバナンスはチューニングの問題ではなく、アーキテクチャの問題です。 10 個のエージェントで機能する同じ設計パターンは、1000 で壊滅的な障害モードを作成します。負荷テストでは、それぞれ異なるトリガーしきい値を持つ 5 つの異なる障害モードが明らかになり、対象を絞ったアーキテクチャ介入によりガバナンス能力を 35 倍に拡張できることが実証されました。

重要な洞察は、ガバナンスの複雑さは、エージェント組織自体と同じ階層境界に沿って分解する必要があるということです。 MARIA 座標系は単なるアドレス指定スキームではなく、ガバナンス分割戦略です。ゾーンスコープの競合検出。惑星スコープの承認委任。ユニバース スコープ ポリシーの評価。ガバナンス構造が組織構造を反映すると、O(n^2) 問題は O(n log n) になり、エージェント 1,000 人の時代はエージェント 12,000 人の時代になります。

次のフロンティアは 100,000 エージェント体制です。これには、より優れたアルゴリズムだけでなく、根本的に新しいガバナンス プリミティブ、つまり確率的ガバナンス (制御された不確実性を受け入れる)、緊急制約の発見 (エージェントが運用からガバナンス ルールを学習する)、および自己組織化ゲート トポロジ (ワークロード パターンに適応するガバナンス構造) が必要になります。これらは、次世代の MARIA OS にとって未解決の問題です。

All benchmark configurations, load test scripts, and analysis notebooks are available in the MARIA OS repository under /benchmarks/governance-load-test/. Results are reproducible using the standard test profile with deterministic PRNG seeding (seed: 0x4D415249).