Claude Codeで並列サブエージェントを使ったリサーチ、めちゃくちゃ便利なんですよね。「この3つの領域を調べて」と投げれば、3つのエージェントが同時に走って、数分で各領域のレポートが返ってくる。
でも先日、エンタープライズAI活用の調査で3つのLayer別レポートを並列リサーチさせた結果を読んでいて、ある違和感に気づきました。
日立製作所のGitHub Copilot導入事例。同じMicrosoft事例ページを出典にしているのに、あるレポートでは「約3万人対象」、別のレポートでは「5,000名規模展開中」、さらに別のレポートでは「200人パイロット→全社展開」と書いてある。
同じURL、3つのエージェント、3つの異なる数字。
これ、ハーネス側で何か整合性チェックしてくれてるんだろうか？ — と思って調べたのが今回の話です。
結論から言うと、整合性チェックは存在しない
公式ドキュメントを確認したところ、Claude Codeのハーネスには並列エージェント間の整合性チェック機構は一切ありません。
各サブエージェントの結果は独立して親エージェントに返り、矛盾検出もマージロジックもない。公式が推奨しているのは「タスクのスコープが重ならないように設計する」こと。つまり、矛盾が起きないように祈る設計です。
「いや、でも実際どのくらい矛盾するの？」
気になったので、自分のリサーチ結果を使って体系的に検証してみました。
実験: 実データで突合してみた
手元にあったのは、エンタープライズAI活用の並列リサーチ結果。2セットあります。
– Layer別リサーチ: 3ファイル（直接的レバレッジ / 間接的レバレッジ / 言語非依存レバレッジ）→ 3ペア突合
– 市場価値リサーチ: 5ファイル（上流ポジション / バックエンド / インフラ・SRE / 専門職 / レガシー）→ 10ペア突合
2ファイルずつのペアを作り、サブエージェントに「同一エンティティに対する事実の記述を突合して、矛盾を探してくれ」と並列で投げました。
見つかった3つのパターン
13ペアの突合で検出された矛盾は、きれいに3パターンに分類できました。
パターンA: 排他的情報による誤判断
Layer 1のレポートが「COBOL→Java変換にはIBM watsonxがほぼ唯一の本格ソリューション」と3回断言していました。
ところがLayer 3のレポートでは、富士通PROGRESSION（北米20年以上・50社超の実績）、NTTデータ t4C（COBOL専用にファインチューニングしたLLM）、TISのモダナイゼーションサービスと、3社の競合ソリューションが紹介されている。
原因は単純で、Layer 1のエージェントは「コード生成ツール」にスコープが限定されていたため、レガシーマイグレーション専業のプレイヤーを知らなかった。自分のスコープ内の情報だけで「唯一」と結論づけてしまった。
これ、人間のチームでも起きますよね。自分の担当領域だけ見て「うちしかやってない」と思い込むやつ。
パターンB: 同一ソースからの異なる抽出
冒頭の日立の話がこれです。同じMicrosoft事例ページから、3つのエージェントが「3万人」「5,000名」「200人」という異なる数字を拾ってきた。
おそらく元ページには「200人のパイロットから始まり、5,000名規模に展開、最終的に3万人を対象」という時系列の記述があって、各エージェントがそれぞれ別のフェーズの数字を切り取ったのだと思います。
もう一つ深刻だったのが、経産省のIT人材不足予測。「AI人材不足340万人」という同じ数字が、あるファイルでは「2026年時点」、別のファイルでは「2040年」と書かれていた。14年のズレ。同一の出典URLを参照しているのに。
パターンC: 定義の不統一
Amazon Q Developerの閉域網対応について、Layer 1のレポートは「非対応」、Layer 2のレポートは「AWS PrivateLink経由で閉域網からアクセス可能」と書いていました。
これは「閉域網」の定義が揃っていないことが原因です。完全なエアギャップ環境を指すのか、VPN/専用線経由のプライベートネットワークを含むのか。エージェント間で用語の定義が暗黙的に異なっていた。
規模感: 矛盾はどのくらい起きるのか
Layer別（3ペア）と市場価値（10ペア）の合計13ペアでの検出結果です。
| 検出カテゴリ | Layer別（3ペア） | 市場価値（10ペア） |
|---|---|---|
| 矛盾 | 5件 | 14件 |
| 不整合リスク | 14件 | 60件 |
| 整合確認済み | 19件 | 59件 |
ファイル数が増えると、矛盾は線形ではなく組み合わせ的に増える。 3ファイルなら3ペアで済むけど、5ファイルだと10ペア。ペア数はn(n-1)/2で増えるので、チェックコストが急激に上がります。
また意外だったのが、ファイル内の自己矛盾も複数見つかったこと。SAPコンサル上位単価が同一ファイル内で「上限250万円」と「上限400万円」で食い違っていたり、経産省の79万人と340万人が論理的に共存できない形で並んでいたり。これは並列リサーチ特有の問題ではなく、単一エージェントのリサーチでも起きる品質問題です。
対策: 整合性チェックスキルを作った
見つかった問題に対して、Claude Codeのスキル（~/.claude/skills/に置く .md ファイル）として整合性検証フローを設計しました。
やっていることはシンプルです。
1. 並列リサーチが完了したら、全ペアの突合をサブエージェントに投げる
2. チェック項目は6つ: 同一URL異数値、同一エンティティ矛盾、排他的表現の反証、定義の不統一、フレーミングの不一致、ファイル内自己矛盾
3. 矛盾ごとに判断材料を付与するが、正誤の判定はしない
3番目が設計上のポイントです。「どちらが正しいか」の自動判定は入れていません。
理由は、出典の信頼度を機械的に判定するのが本質的に難しいから。公式プレスリリースでも古い情報が残っていることがあるし、個人の検証レポートでも再現条件が明示されていれば公式より信頼できることがある。「公式か個人か」ではなく「検証可能か否か」が信頼度の軸であり、それは文脈依存で人間が判断すべきもの。
スキルの責務は「矛盾を検出し、両方の出典情報を並べて、判断材料を揃える」ところまで。最終判断はユーザーに委ねます。
作って、回して、直した
ただし、このスキルは「作って完成」ではありませんでした。
Layer別3ファイルで回したあと、market-value 5ファイルで実際に使ってみたら、評価軸自体に問題があることに気づきました。
– 「公式ソースは信頼度が高い」と書いていたが、公式でもマーケティング資料は条件不明だし、個人の検証レポートでも再現条件が明示されていれば信頼できる。「公式 vs 個人」ではなく「検証可能 vs 検証不能」に軸を修正した
– 「複数ソースで一致すれば信頼度が上がる」と書いていたが、同じ誤った二次ソースの孫引きが複数ファイルに散在するケースがあった。「独立した調査主体で一致しているか」に修正した
– ファイル内の自己矛盾を見落としていた。SAPコンサル単価が同一ファイル内で400万円と250万円になっていたり。チェック項目に「ファイル内自己矛盾」を追加した
AIツールに限らずだけど、品質チェックの仕組みは使ってフィードバックを受けて育てるもので、最初の設計で完成することはない。今回のスキルも、次に別のリサーチで使ったときにまた新しいパターンが見つかるはずで、そのたびに改訂していく前提です。
「もっと精度を上げられないか？」の止めどき
検証を進めていくと、「3ファイルの場合、01 vs 02で01が正しかったけど、02と03が一致していたら多数決で02側が正しいのでは？」という問いが出てきます。
結論から言うと、これは追う価値がない。
02と03が同じ誤った二次ソースを孫引きしていたら、2対1でも01が正しい。逆に01が公式の一次ソースを直接引いていたら、数の問題ではない。複合ペアの多数決ロジックを入れても判断精度は上がらないのに、組み合わせ爆発でコストだけが跳ね上がる。
「並列リサーチ後に突合フェーズを1回挟む」で十分。 それ以上の自動化は費用対効果が急落する領域です。
実際に修正してみた
検出して終わりでは検証にならないので、突合レポートの指摘に基づいてリサーチファイルを実際に修正しました。
主な修正:
– COBOL変換「ほぼ唯一」→「Layer 1スコープ内では唯一」 に変更し、Layer 3に競合3社が存在する旨の注記を追加
– 日立Copilot導入規模 → 「200人パイロット→5,000名展開→約3万人対象」と時系列を明示
– Amazon Q閉域網対応 → 「PrivateLink経由でVPC内からアクセス可能（完全エアギャップは非対応）」と定義を明確化
– 経産省「340万人」 → 年次とスコープに諸説ありの注記を追加、ファイル内の論理矛盾を解消
– SAPコンサル上位単価 → ファイル内自己矛盾（400万円 vs 250万円）を統一
修正前・修正後の全文と、変更箇所のハイライトを含む検証データを公開しています。
検証データ一覧（生データ・突合レポート・修正後diff）はこちら
まとめ
冒頭の違和感 — 同じURLから3つのエージェントが3つの異なる数字を拾ってきた — に対する答えが出ました。
人間のチームでも起きる「担当領域だけ見て全体像を見誤る」問題が、AIエージェントでもそのまま再現される。 これが今回の検証で一番大きな発見でした。
これは並列処理の構造的な限界であり、ツールが進化しても消えない本質的な課題だと思います。
だからこそ、対策も人間のチームと同じ発想になる。レビュープロセスを作って、使って、育てる。今回作った整合性チェックのスキルも、最初に設計した評価軸が2ラウンド目で崩れて修正が入りました。「公式か個人か」で信頼度を測ろうとしたら、公式マーケティング資料の方が条件不明だったり。「複数ソースで一致」を信頼の根拠にしたら、全部同じ二次ソースの孫引きだったり。
「一回作って完成」にはならない。問題を見つけて、仕組みを作って、使ってみて、仕組み自体を直す。人間のチームでレビュープロセスを育てるように、AIツールも育てていく。次に使えばまた変わるはずです。
FAQ
並列サブエージェントのリサーチで、矛盾はどのくらいの頻度で起きる？
今回の検証では、3ファイル（3ペア）で矛盾5件、5ファイル（10ペア）で矛盾14件を検出しました。ファイル数が増えるとペア数が組み合わせ的に増えるため、矛盾の検出件数も急増します。ただし「スコープの違いによる見かけ上の乖離」も多く含まれるため、全てが深刻な矛盾というわけではありません。
Claude Codeのハーネスに整合性チェック機能はある？
2026年4月時点ではありません。公式ドキュメントでも「タスクのスコープが重ならないように設計する」ことが推奨されており、矛盾検出やマージロジックは提供されていません。タスク依存関係の自動解決はありますが、これは情報の整合性ではなく実行順序の管理です。
整合性チェックスキルは公開されている？
現時点では個人のClaude Code環境（~/.claude/skills/）に配置するローカルスキルとして運用しています。スキルの設計思想と検証データは本記事で公開しているので、同様の仕組みを構築する際の参考にしてください。
検証の生データは見られる？
検証データ一覧ページで公開しています。リサーチ生データ8ファイル（修正前の原本）、突合レポート2ファイル、修正後5ファイル（変更箇所ハイライト付き）+ インデックスの計16ファイルです。「この入力から、この矛盾が検出され、こう修正された」の流れを一貫して追えます。
この記事が参考になったら
Share