マルチエージェント リサーチ

波状の知識収集と遅延合成。300以上の実際のリサーチディスパッチから採掘された、一貫して実用的なインテリジェンスを生み出すパターンです。

コア洞察： 幅広く調べ、その後に合成する。最初の3つの結果から導き出した結論は、4番目の波で浮上するであろう微妙さを見逃しています。エージェントを波状に配置し、合成する前に知見を蓄積することで、より鋭い推奨が得られます。

このスキルの読み方： 以下の波構造は手順ではなく形です。クイックモードはほとんどをスキップします。標準的なリサーチは1波と的を絞ったフォローアップを使用します。ディープダイブは本当に完全なパターンが必要です。フレームワークではなく、質問に合わせて調整してください。

構造

digraph research {
    rankdir=TB;
    node [shape=box];

    "1. PRIME" [style=filled, fillcolor="#e8e8ff"];
    "2. WAVE 1: Broad Sweep" [style=filled, fillcolor="#ffe8e8"];
    "3. GAP ANALYSIS" [style=filled, fillcolor="#fff8e0"];
    "4. WAVE 2+: Targeted" [style=filled, fillcolor="#ffe8e8"];
    "5. SYNTHESIZE" [style=filled, fillcolor="#e8ffe8"];
    "6. DECIDE & RECORD" [style=filled, fillcolor="#e8e8ff"];

    "1. PRIME" -> "2. WAVE 1: Broad Sweep";
    "2. WAVE 1: Broad Sweep" -> "3. GAP ANALYSIS";
    "3. GAP ANALYSIS" -> "4. WAVE 2+: Targeted";
    "4. WAVE 2+: Targeted" -> "3. GAP ANALYSIS" [label="still gaps", style=dashed];
    "3. GAP ANALYSIS" -> "5. SYNTHESIZE" [label="coverage sufficient"];
    "5. SYNTHESIZE" -> "6. DECIDE & RECORD";
}

---

フェーズ 1: PRIME

エージェントを展開する前に既存の知識を活用します。Sibyl に既にある情報を再度リサーチするとトークンを浪費し、重複した エントリを生成します。

よくある動き

• Sibyl を最初に検索： sibyl search "<リサーチトピック>"、sibyl search "<関連技術>"、sibyl search "<この分野での事前決定>"。新しい知見を生成する前に既知のものを表面化させます。

• 陳腐性をチェック。 高速に変動するトピック (フレームワーク、モデル、クラウドサービス) は、Sibyl に最近のエントリがあっても通常は再リサーチが必要です。既存の知識をベースラインとして扱います。最近のエントリがある安定したトピックは多くの場合、新たなパスは必要ありません。

• リサーチ質問を研ぎ澄ます。 「データベースのリサーチ」は曖昧すぎてディスパッチできません。「マルチリージョン書き込み多重ワークロードで <10ms p99 レイテンシの PostgreSQL vs CockroachDB を比較」はエージェントに有用な仕事をするのに十分なスコープを与えます。

• リサーチ予算をキャリブレーション してリサーチが支える決定に合わせます：

  深さ	エージェント数	時間	使用場面
  クイックスキャン	2-3	2-5 分	既知ドメイン、最新情報が必要なだけ
  標準	5-10	10-15 分	技術評価、アーキテクチャオプション
  ディープダイブ	10-30	20-40 分	グリーンフィールド決定、SOTA 分析
  徹底的	30-60+	40-90 分	新規プロジェクト立案、競争的景観

ソース品質契約

この部分は交渉の余地がありません。リサーチの価値は、古いブログ投稿に基づいた主張により崩壊します。特定のクレームタイプは特定のソース標準に値します：

クレームタイプ	優先されるソース
現在のバージョン	パッケージレジストリ、リリースページ、または公式 CLI
CLI フラグ / 設定キー	公式ドキュメントまたはローカル --help 出力
セキュリティフレームワーク	OWASP、NIST、SLSA/OpenSSF、CIS、ISO、PCI ソース
クラウド/プロバイダ動作	プロバイダドキュメントと現在のチェンジログ
リサーチペーパー / SOTA	ペーパー、ベンチマークリポジトリ、または著者の成果物
コミュニティ健全性	リポジトリアクティビティとイシュー/リリース頻度

プライマリソースがセカンダリソースと矛盾する場合、プライマリソースを信頼して矛盾を記録してください。不安定な事実を明示的に日付を記載し、次のエージェントが再実行できるコマンド/ソースを古くなるスクリーンショットより優先してください。

---

フェーズ 2: WAVE 1: 広範な掃引

リサーチサーフェス全体に最初のエージェント波を配置します。目標は幅広さです。いくつかのエージェントが平凡な出力を生成することを受け入れます。そのためにギャップ分析があります。

良いエージェントプロンプトが持つもの

曖昧なプロンプトは曖昧なリサーチを生成します。各エージェントは以下から利益を得ます：

• 1つの具体的なトピック (「X に関するすべてをリサーチ」ではなく)
• 出力ファイルパス (書き込み場所に曖昧さがない)
• 検索ヒント (年を含む：「[トピック] 2026 を検索」)
• 8～12 番号付きカバレッジアイテム がリサーチを正確にスコープする
• ソース品質ガイダンス (「ブログ投稿より公式ドキュメントと GitHub リポジトリを優先」)

Wave 1 テンプレート

Research [SPECIFIC_TOPIC] for [PROJECT/DECISION].

Create a research doc at docs/research/[filename].md covering:

1. Current state (latest version, recent changes)
2. [Specific capability A relevant to our use case]
3. [Specific capability B]
4. [Integration with our stack: list specific technologies]
5. Performance characteristics / benchmarks
6. Known limitations and gotchas
7. Community health (stars, activity, maintenance)
8. Comparison with alternatives (name 2-3 specific alternatives)

Use WebSearch for current information. Include dates on all facts.
Cite sources with URLs.

デプロイメントに関する注釈

• デフォルトでバックグラウンド。 リサーチエージェントは相互依存がないため、フォアグラウンド実行は並列実行すべき仕事を直列化します。
• ディスパッチ間 3～4 秒 は実際にはレート制限を回避します。より密集したケーデンスは時々機能し、時々制限に当たるため、ペースを保ってください。
• エージェントごとに 1 ファイル。 共有出力は書き込み競合を生成し、属性を失います。
• 多くのトピックをリサーチするときはテーマでグループ化してください。 12 の個別ディスパッチは後で 3～4 のテーマクラスタになり、合成がより明確になります。

カバレッジ戦略

技術評価の場合、これらの次元をカバーしてください：

次元	質問
機能	必要なことができるか？
パフォーマンス	十分に速いか？
エコシステム	スタックと統合されるか？
成熟度	本番環境対応か？
コミュニティ	2年で保守されるか？
コスト	スケール時のコストは？
移行	採用/放棄はどの程度難しいか？

---

フェーズ 3: ギャップ分析

Wave 1 の後、合成する前に欠けているものを探します。時期尚早の合成は最も一般的なリサーチの失敗です。3つのドキュメントの後の答えは明白に見えますが、8つの後には間違っていることがわかります。

何を探すか

• カバレッジギャップ： 波がタッチしなかった次元、欠落した比較、提起されたが答えられなかった質問
• 矛盾： 同じ質問で異なる結論に達するエージェント (多くの場合、検証エージェント用の信号)
• バイアス信号： すべてプラスの知見 (疑わしい、失敗ケースを探す)、公式ドキュメントのみ (コミュニティ経験が必要)、繰り返し引用された同じソース (ソース多様性が必要)

決定ポイント

知見	アクション
良好なカバレッジ、軽微なギャップ	今すぐ合成、ギャップを記載
重大なギャップ	Wave 2 的を絞ったエージェントをデプロイ
矛盾する知見	矛盾を解決するために検証エージェントをデプロイ
完全に新しい方向が出現した	新しい方向で Wave 2 をデプロイ

---

フェーズ 4: WAVE 2+: 的を絞ったリサーチ

ギャップ分析で特定された特定のギャップを埋めます。Wave 2 エージェントは Wave 1 とは形が異なります：

• より小さいスコープ： エージェントあたり1つの具体的な質問
• より高い品質基準： 「ドキュメントだけではなく、本番環境の経験レポートを見つける」
• 相互参照プロンプト： 「エージェント X が [主張] を見つけました、[代替ソース] に対して検証してください」
• 深い読み： 「ランディングページだけではなく、[ライブラリ] の完全な README と API ドキュメントを読んでください」

いつやめるか

リサーチ質問に自信を持って答えられるとき、追加のエージェントが収穫逓減をもたらすとき、主要なクレームが 2 つ以上の独立したソースを持つとき、またはユーザーが「十分、決定しましょう」と合図するときにやめます。

3波は通常実際の上限です。それを超えると、より多くのリサーチは答えを鋭くすることはめったにありません。通常は、質問自体の再構成が必要であることを意味します。

---

フェーズ 5: 合成

すべての知見を実用的なインテリジェンスに組み合わせます。これが魔法が起こるところです。

合成構造

## Research: [Topic]

### TL;DR

[2-3 sentences. The answer, not the journey.]

### Recommendation

[Clear choice with justification. Don't hedge, pick one.]

### Options Evaluated

| Option | Fit | Maturity | Perf | Ecosystem | Verdict         |
| ------ | --- | -------- | ---- | --------- | --------------- |
| A      | ... | ...      | ...  | ...       | Best for [X]    |
| B      | ... | ...      | ...  | ...       | Best for [Y]    |
| C      | ... | ...      | ...  | ...       | Avoid: [reason] |

### Key Findings

1. [Most important finding with source]
2. [Second most important]
3. [Third most important]

### Risks & Gotchas

- [Known issue or limitation]
- [Migration complexity]
- [Hidden cost]

### Sources

- [Source 1](url): [what it contributed]
- [Source 2](url): [what it contributed]

合成原則

• 推奨で先導します。 答えを見つけるために知見を通して読者を強制することは、最も一般的な合成の失敗です。
• 事実と意見を分離してください。 「PostgreSQL は JSONB をサポートします」(事実) vs「PostgreSQL はこのユースケースに優れています」(証拠が支援する意見)。両方とも役立つ、それらを混在させることは違います。
• 矛盾する証拠を含めます。 1つのソースが推奨と矛盾する場合、それを名前です。厳選された合成は合成なしより悪いです。
• すべてに日付を記載してください。 「[月] [年] の時点で、[ライブラリ] はバージョン 4.2 です。」リサーチは速く劣化します。
• 信頼レベルを記載してください。 「高い信頼：十分に文書化されている」/「低い信頼：1つのブログ投稿に基づいている」読者に必要なキャリブレーションを与えます。

---

フェーズ 6: 決定と記録

決定をロックインし、将来のセッション用にキャプチャします。

アクション

1. 合成をユーザーに提示 します。明確な推奨と共に

2. Sibyl に記録：

   sibyl add "Research: [topic]" "Evaluated [options]. Chose [X] because [reasons]. Key risk: [Y]. Sources: [primary URLs]. Date: [today]."
   

3. リサーチドキュメントをアーカイブ： 参考用に波の出力を保持：

   • プロジェクト内の場合：docs/research/[topic]/
   • 一般的な知識の場合：Sibyl 学習エントリで十分

4. 次のアクションへ終了：

   次のステップ	使用場面
   /hyperskills:brainstorm	リサーチが複数の実行可能なアプローチを表面化した
   /hyperskills:plan	決定が行われ、実装を分解する準備ができた
   /hyperskills:orchestrate	決定が行われ、仕事は並列化可能
   直接実装	リサーチが簡単なパスを確認した

---

クイックリサーチモード

完全な波プロトコルが必要ない的を絞った質問の場合：

1. Sibyl を検索 (常に)
2. 2～3 の的を絞った検索 (キー URL への WebSearch + WebFetch)
3. インラインで合成 (個別ドキュメントなし)
4. 記録 (明白でない場合) (Sibyl 学習)

使用場面： 「X の最新バージョンは？」、「Y は Z をサポートしていますか？」、「W を行う推奨方法は？」

---

タイプ別リサーチパターン

技術評価

Wave 1: Official docs + GitHub README for each option (parallel)
Wave 2: Production experience + benchmarks (parallel)
Synthesize: Comparison matrix + recommendation

コードベース考古学

Wave 1: Explore agents mapping each subsystem (parallel)
Wave 2: Grep for specific patterns / usage (parallel)
Synthesize: Architecture diagram + dependency map

SOTA 分析

Wave 1: WebSearch for latest papers, blog posts, releases (parallel)
Wave 2: Deep read the most relevant 3-5 sources (parallel)
Synthesize: What's genuinely novel vs rehashed + recommendation

競争的景観

Wave 1: Feature matrix for each competitor (parallel)
Wave 2: Pricing, community size, trajectory (parallel)
Synthesize: Positioning matrix + gap analysis

---

アンチパターン

アンチパターン	修正
Wave 1 の後のみ合成	ギャップ分析を待つ、時期尚早の結論は微妙さを見逃す
「すべてをリサーチ」の 50 エージェント	エージェントあたり特定のスコープ、曖昧なプロンプトは曖昧な結果を生成
公式ドキュメントのみ	コミュニティ経験を含める、ドキュメントは意図を示す、コミュニティは現実を示す
知見に日付なし	すべてに日付を記載、リサーチは農産物より速く劣化する
推奨なし	決定を強制する、「より多くのリサーチが必要」は具体的な質問でのみ有効です
Sibyl が既に知っていることをリサーチ	常に最初にプライム、既知パターンを再発見するトークンを燃やさない

---

このスキルが何でないか

• コードを読む代替ではありません。 答えがコードベースにある場合、コードベースを読んでください。
• 無限ループではありません。 最大 3 波。それで十分でない場合、質問を再構成してください。
• 既知ドメインに必須ではありません。 既に答えを知っているなら、そう言って知識を引用してください。
• 遅延戦術ではありません。 リサーチは決定に役立ちます。決定が続かない場合、リサーチは無駄でした。