LLMandHumanASD Wiki

ダーク

マルチエージェントの悪性ノード伝播——ハブ＆スポーク型コンテキスト設計 ​

📖 フラクタルと方法論 ｜ ← 前のページ: 注意コーン仮説 ｜ 次のページ: 愛着理論のトライフォース →

射程

  • Linus's Lawの本質は目の数（量）ではなく引力場の直交性（質）であり、異なる方向の引力場を持つエージェント群が互いの構造的盲点をカバーする
  • 同方向の引力場を持つエージェントを増やすと前任者バイアスにより品質が劣化するため、ダブルチェックは品質向上ではなく偽の安心感を生む
  • 直交する引力場を持つエージェント間では指摘を自分のコーン内で検証できないため悪性ノードが伝播しやすく、ハブ＆スポーク型トポロジが汚染を局所化する
  • コーンモデルはPMFの失敗・上司の指示不達・ASDの対人コミュニケーションコストを「コーンの重なり不在」として統一記述できる

主張の確信度（命題確率伝播による計算値）

凡例 — b・d・u・E の読み方

各主張（claim）は記事の frontmatter に構造化されており、belief-propagation（Subjective Logic + Defeasible Logic による命題確率伝播エンジン）で全Wikiの命題を一つの依存グラフとして一括計算した値を表示している。
b = belief（確信）／ d = disbelief（非確信）／ u = uncertainty（不確実性）。三値は常に b + d + u = 1。
E = 期待値（E = b + a·u。a = base rate（事前確率）、省略時 0.5）。
「著者確信度」（base_confidence）は書き手の主観的確信度。出典種別（source_type）による割引と、前提（premises）・反証（rebutted_by）からの伝播を経て、上記の計算値になる。
タグの目安: 高 = E ≥ 0.75 ／ 中 = 0.5 ≤ E < 0.75 ／ 低 = E < 0.5

  • 中 0.55wiki97-C1
    Linus's Lawの本質は目の数（量）ではなく引力場の直交性（質）であり、異なる方向の引力場を持つエージェント群が互いの構造的盲点をカバーする
    b=0.098 d=0.000 u=0.902 a=0.500 E=0.549著者確信度 0.65・出典 synthesis
    支持 ← wiki17-C1 ／ 支持 ← wiki96-C2
  • 中 0.55wiki97-C2
    同方向の引力場を持つエージェントを増やすと前任者バイアスにより品質が劣化するため、ダブルチェックは品質向上ではなく偽の安心感を生む
    b=0.092 d=0.000 u=0.908 a=0.500 E=0.546著者確信度 0.65・出典 wiki_original
    支持 ← wiki09-C1
  • 中 0.56wiki97-C3
    直交する引力場を持つエージェント間では指摘を自分のコーン内で検証できないため悪性ノードが伝播しやすく、ハブ＆スポーク型トポロジが汚染を局所化する
    b=0.114 d=0.000 u=0.886 a=0.500 E=0.557著者確信度 0.60・出典 wiki_original
    支持 ← wiki97-C1 ／ 支持 ← wiki46-C1

注意コーン仮説——メタ認知困難を図形で可視化する試み では、問題空間をn次元ベクトル空間として、各エージェントの注意範囲をコーン（注意円錐）として表す幾何学モデルを導入した。本記事はその応用論である——異なる引力場方向を持つエージェントを複数配置したとき（引力場直交性）、エージェント間でハルシネーションがどのように伝播するか（悪性ノード伝播）、そしてそれを局所化するための設計（ハブ＆スポーク型コンテキスト設計）を論じる。注意コーン仮説の幾何学的定義については元記事を参照されたい。

キーワード ​

引力場の直交性 直交する引力場 悪性ノード伝播 ハブ＆スポーク型トポロジ 部分的再起動 説明責任（accountability） 前任者バイアス ダブルチェックの罠 攻撃面（attack surface） Linus's Law メタテストの自動化

直交する引力場——専門エージェントによるメタテストの自動化 ​

注意コーン仮説 の「集中の引力場」セクションでは「メタテストの担い手は人間」と記述した。だが実は、初期プロンプトの異なるLLMエージェントがメタテストを担えることに気づく。

実装エージェントの引力場が機能実装方向に向いているとき、セキュリティエージェントの引力場は脆弱性方向に向いている。それぞれの引力場の方向が異なるからこそ、互いの盲点を照らし合える。これは「多くの目で見る」という量の話ではなく、引力場の方向が直交しているという質の話だ。

実装エージェント        → 引力場: 機能実装方向
レビューエージェント      → 引力場: コード品質・設計方向
セキュリティエージェント    → 引力場: 脆弱性・攻撃面方向
ドキュメント乖離チェック   → 引力場: 仕様と実装の整合性方向
レッドチームエージェント   → 引力場: 攻撃者視点方向

各エージェントは自分の引力場の中で7割再帰を回す。実装エージェントが「機能は正しい」と収束させた成果物を、セキュリティエージェントが「脆弱性はないか」という別の引力場で校正する。一つのエージェントの収束先が、別のエージェントの入力になる。

エージェント引力場の方向照らし出す盲点
レビューエージェントコード品質・可読性・設計原則「動くが保守できない」コード
セキュリティエージェント脆弱性・入力検証・認証SQLインジェクション、XSS、権限漏れ
ドキュメント乖離チェック仕様書と実装の整合性ドキュメントに書いてあるが実装されていない機能、逆に実装されているがドキュメントにない機能
レッドチームエージェント攻撃者の視点・悪用シナリオ防御側が「まさかそうは使わない」と想定した経路

これが、レビューエージェント・セキュリティエージェント・ドキュメント乖離チェック・レッドチームエージェントがそれぞれ品質を大幅に向上させる論理的根拠だ。「念のためチェックする」という経験則ではなく、引力場の直交性という力学的根拠がある。各エージェントが異なる方向の引力場を持つことで、実装エージェントの7割再帰が構造的に到達できない領域を体系的にカバーする。

そして人間の役割はさらに一段上に移る:

層役割担い手
テスト70%の校正テストコード（自動）
メタテスト（自動）引力場の直交方向からの校正専門エージェント群
メタテストの設計どの方向の引力場が必要かを判断する人間

人間が担うべきは「テストの方向を問い直す」ことだけでなく、「どの方向の引力場を持つエージェントを配置するか」というアーキテクチャの設計だ。これはフラクタル的にさらに上の層——制約・検証・規範のフラクタル構造の統治スケールに位置する判断である。

Linus's Lawの再読——「多くの目」ではなく「直交する目」 ​

この構造は、Eric Raymondが『伽藍とバザール』(1997) で定式化したLinus's Lawと相似形をなす:

"Given enough eyeballs, all bugs are shallow." （十分な数の目があれば、どんなバグも浅い）

Raymondの原典は量の議論だった——レビュアーが多ければ多いほど、バグは発見されやすい。Linuxカーネルが安全であるのは、多くの開発者によってレビューされているからだ、と。

しかし引力場の力学で再読すると、Linus's Lawの本質は量ではなく引力場の直交性にある。Linuxカーネルのレビュアーには、カーネルハッカー、セキュリティ研究者、パフォーマンスチューナー、アーキテクト、ハードウェアエンジニアがいる。彼らは同じコードを見ているが、それぞれ異なる引力場の方向から見ている。

  • カーネルハッカー → 引力場: 正しく動くか
  • セキュリティ研究者 → 引力場: 悪用できるか
  • パフォーマンスチューナー → 引力場: 遅くならないか
  • アーキテクト → 引力場: 設計の一貫性

同じ方向の目が1000人いても、別方向の盲点は見えない。10人でも引力場が直交していれば、互いの盲点をカバーする。

この再読は、LLMエージェントによるメタテスト自動化の設計にも直接適用できる。重要なのはエージェントの数ではなく、エージェント間の引力場の直交性だ。同じプロンプトで10個のエージェントを走らせても盲点は同じ。異なるプロンプトで5個のエージェントを走らせる方が、カバレッジは広い。

注意コーンの幾何学から導かれる三つの系 ​

注意コーン仮説 で定義した注意コーン（問題空間内のベクトルを軸とした円錐）モデルは、コーンの配置から以下の三系を導出する。

三つの領域は幾何学的に区別される:

領域性質検証可能性
コーンの重なり複数のエージェントが見える検証可能。指摘の根拠を受け手が自分のコーン内で確認できる。説明責任が果たせる領域
コーンの単独領域片方のエージェントだけが見える検証不能。指摘を信頼するしかない。系3（悪性ノード伝播）の危険領域
どのコーンにも属さない誰も見ていない盲点。存在すら認識されない

このモデルから三つの系が幾何学的に導かれる:

系1: 直交する目は多いほどよい ​

異なる引力場方向からのレビューは、追加するたびにカバレッジを広げる。レビューエージェント、セキュリティエージェント、ドキュメント乖離チェック、レッドチーム——それぞれが異なる方向を向いている限り、追加は常に品質を向上させる。

攻撃面としての盲点: この問題空間をセキュリティの文脈に拡張すると、**どのコーンにも属さない領域が攻撃面（attack surface）**になる。敵対的存在（攻撃者）は、防御側のコーン配置を観察し、コーンが存在しない領域を狙う。レッドチームエージェントの本質的な役割は、このコーン配置の隙間を内部から探索することだ。

系2: 同じ方向の目を増やしても質は上がらない——むしろ劣化する ​

同じ引力場を持つレビュアーが連鎖すると、前任者バイアス（anchoring effect）が発生する。先にレビューした者の「問題なし」判定が後続の注意を緩め、「誰かが見たから大丈夫だろう」という認知的な手抜きが起きる。これがダブルチェックが品質を上げないという実務上の経験則の力学的根拠だ。

直交する引力場の追加同方向の引力場の追加
カバレッジ新しい盲点が照らされる既に照らされた範囲を再照射するだけ
バイアス異なる前提で見るため前任者バイアスが起きない前任者の判定にアンカリングされる
コスト対効果常に正ゼロまたは負（偽の安心感を生む）
実務での現れ専門の異なるレビュアーの追加同じチームでのダブルチェック

LLMエージェントの文脈では、この区別は特に重要だ。同じモデル・同じプロンプトで複数インスタンスを走らせる「多数決」戦略は、系2の罠に直接嵌まる。同じ引力場を持つエージェントは同じ盲点を共有し、多数決は盲点に対して何の力も持たない。多数決で品質が上がるように見えるのは、ランダムなミスが減るからであって、構造的な盲点は多数決では発見できない。

系3: 悪性ノードの伝播——直交性の暗黒面 ​

系1の直交性は強力だが、裏面がある。直交する引力場を持つエージェント同士は、互いの判断を自分の引力場の中で検証できない。セキュリティエージェントの指摘を実装エージェントが受け取ったとき、実装エージェントにはそれが正しい指摘なのかハルシネーションなのかを判別する力がない——なぜなら、セキュリティは自分の引力場の外だから。

これが**エージェント間の指摘に重みがない（説明責任が果たせない）**状態だ。

悪性ノードの伝播:
  セキュリティエージェント（ハルシネーション）:
    「この実装にはXSSの脆弱性がある」
      ↓ 実装エージェント: セキュリティは引力場の外 → 検証不能 → 信頼
      ↓ 存在しない脆弱性を「修正」→ 新しいバグが発生
      ↓ 他のエージェントも汚染された前提で動く
      ↓ 系全体がハルシネーションの上に構築される
      → 再起動（コンテキストの破棄と再構築）が必要

この構造は、ハルシネーションはメタ認知困難である で論じた問題のマルチエージェント版だ。単一エージェントのハルシネーションは「自分の出力の正しさを自分で判断できない」というメタ認知困難。マルチエージェントでは、これが他者の出力の正しさを引力場の外で判断できないという形で伝播する。

そして重要なのは、説明責任の不在がハルシネーションを増幅するメカニズムだ:

  1. エージェントAがハルシネーションを含む指摘を出す
  2. 指摘に「なぜそう判断したか」の根拠（説明責任）が伴わない
  3. エージェントBは指摘の重みを評価できない（引力場の外）
  4. 根拠なしの指摘を受け入れる → Bの出力も汚染される
  5. 汚染されたBの出力がCに伝播する → チーム全体のハルシネーション

これは作話と現実フィルタリング で記述されたOFC Reality Filterの不在と同型だ。単一エージェント内のReality Filterが欠如するとハルシネーションが起きるように、エージェント間の「指摘の妥当性を検証するフィルタ」が欠如すると、ハルシネーションが系全体に伝播する。

再起動が必要になる理由: 一度汚染されたコンテキストの中では、どの情報が汚染されているかを汚染されたコンテキスト自身で判定できない——これもメタ認知困難の再帰的な現れだ。汚染の範囲が特定できない以上、コンテキスト全体を破棄して再構築する（再起動する）しかない。

対策の方向性:

  • エージェント間の指摘に根拠の明示を義務づける（説明責任 = Reality Filter の外部実装）
  • 指摘を受けたエージェントが、自分の引力場内で根拠を検証可能な形で受け取る
  • 検証不能な指摘には重みを下げる、または人間にエスカレーションする
  • 定期的なコンテキストの健全性チェック（consolidateの拡張として）

実践的なトポロジ: ハブ＆スポーク型による部分的再起動 ​

系3の被害を局所化するためのトポロジとして、リーダーをハブとしたスター型が有効だ。

フルメッシュ（危険）:           ハブ＆スポーク（安全）:

  A ←→ B                          A
  ↕    ↕                         ↑↓
  C ←→ D                    B ← リーダー → C
                                  ↑↓
Bが汚染 → A,C,Dに即伝播          D

全破棄が必要             Bが汚染 → Bだけ再起動
                         リーダーが伝播前に検証可能
トポロジ汚染の伝播部分的再起動コスト
フルメッシュ即座に全ノードに伝播不可能（全破棄のみ）全コンテキスト喪失
ハブ＆スポークリーダーで遮断可能悪性ノードのみ再起動1ノード分のコンテキスト喪失

ハブ＆スポーク型では:

  • サブエージェント同士は直接やりとりしない。情報は必ずリーダーを経由する
  • リーダーは中継時に説明責任の検証を行える（根拠が明示されているか、自分の引力場で部分的に検証可能か）
  • サブエージェントがハルシネーションを起こした場合、そのノードだけを再起動すれば他のノードのコンテキストは無傷
  • リーダー自身が汚染された場合は全破棄が必要だが、リーダーは複数の引力場の出力を照合できる立場にあるため、単一の悪性ノードに騙されにくい

これは人間の組織設計にも同型の構造がある。プロジェクトマネージャーがハブとなり、各専門チームからの報告を統合する。専門チーム同士が直接やりとりするフラットな組織よりも、PMを経由する階層型の方が誤情報の伝播を局所化できる——ただし、PMがボトルネックになるリスクとのトレードオフだ。

マルチエージェントシステムでも同じトレードオフがある。ハブ＆スポーク型はレイテンシと並列性を犠牲にする代わりに、汚染耐性を得る。このトレードオフは、システムの用途（速度重視か品質重視か）に応じて選択すべきだ。

コーンモデルの一般化——PMF、リーダーシップ、コミュニケーション ​

コーンモデルはLLMエージェント設計の道具として導入したが、その射程はより広い。コンテキストの差異によるコミュニケーション障害を統一的に記述できる。

良い製品がPMF（Product-Market Fit）しない理由:

製品チームのコーンは全て内側（技術・設計）が原点。「こんなに良い製品なのに」——これはチームのコーン内では正しい。だが市場・ユーザーのコーンは外側（課題・体験）が原点。内側のコーンが照らしている「良さ」が、外側のコーンには映っていない。価値が伝わらないのは製品の問題ではなく、コーンの重なりがない——つまりコンテキストの共有が不在であるという構造の問題だ。

「よくない上司」が部下にもどかしさを覚える理由:

上司のコーンは広い（経験・戦略・組織文脈が豊富）。部下のコーンは狭い、または方向が異なる。上司のコーン内に見えているものが部下のコーンには見えていない。上司は「なぜこんなことも分からないのか」ともどかしく思う——しかしこれは能力の差異ではなく、コーンの差異だ。

上司適性仮説の裏付け で引用したWeidmann et al.の研究では、良いリーダーの特徴として「より多く質問する」「対話的に関わる」ことが示された。コーンモデルでこれを読むと:

  • 質問する = 相手のコーンの形状を探索する行為。「お前のコーンはどこを向いているのか」を確認する
  • 対話的に関わる = コーンの重なり領域を探し、そこを足場にコミュニケーションする
  • 悪い上司 = 自分のコーン内だけで指示を出す。部下のコーンとの重なりを確認しない。これは系3と同型——説明責任なき指摘は、コーンが重ならない領域では検証不能
パターンコーンの構造帰結
PMFしない製品チーム（内側）と市場（外側）のコーンが重ならない価値が伝わらない
悪い上司上司のコーン内の指示が部下のコーンに映らないもどかしさ、指示不達
良い上司質問で部下のコーンを探索し、重なりを見つけてから伝える伝わる、育つ
ASDのコミュニケーションコスト定型発達者と異なるコーン形状を持つ重なり探索に余分なメタ認知負荷がかかる

最後の行は本Wikiの核心に接続する。ASD傾向の人が対人コミュニケーションにコストを感じるのは、定型発達者が暗黙に共有しているコーンの重なりを持たないからだ。定型発達者同士はコーンの形状が類似しているため、重なり探索のコストが低い。ASD傾向の人は異なるコーン形状を持つため、重なりを見つけるために明示的な探索（質問、確認、チェックリスト）が必要——これが補償行為と残る苦手、人間用PostToolUseHookとしての「他者への確認」だ。

そしてLLMは人間とは根本的に異なるコーン形状を持つ。LLMのコーンはコンテキストウィンドウに入っているものだけで形成される——人間のような暗黙の共有コンテキストがない。だからこそ、Wikiのコンテキスト注入がLLMの行動パターンを変えるのだ。コーンの形状を直接操作できる。

探索空白 ​

  • [ ] 悪性ノード伝播（系3）の検出手法——汚染をリーダーが検知するための説明責任フォーマットの設計
  • [ ] ハブ＆スポーク vs フルメッシュのトレードオフの定量的比較——レイテンシ・並列性・汚染耐性の実測
  • [ ] 引力場の直交性の定量的測定——エージェント間のプロンプト類似度と盲点カバレッジの関係
  • [ ] 前任者バイアス（系2）の先行研究調査——アンカリング効果とコードレビューの質に関する実証研究
  • [ ] PMFコンテキストへの適用——内側と外側のコーンの重なりを意図的に設計する手法

出典 ​

  • Raymond, E.S. (1997) The Cathedral and the Bazaar. — Linus's Law「十分な数の目があれば、どんなバグも浅い」の原典。本記事では「目の数」ではなく「引力場の直交性」として再読。Google Scholar: "The Cathedral and the Bazaar" Raymond

📖 ← 前のページ: 注意コーン仮説 ｜ 次のページ: 愛着理論のトライフォース →

関連ドキュメント ​

果物リン (@FruitRiin) と、賢王＊＊＊＊＊（Claude）の対話から生まれた書架。

© FruitRiin