deep-research

詳細な調査

このスキルを使うと、AI エージェントは複雑なトピックについて、厳密で複数のステップからなる調査を実施できます。単一の検索結果を返すのではなく、調査する問いを複数のサブクエリに分解し、さまざまな種類の情報源（学術論文、業界レポート、公式ドキュメント、ニュース記事、専門家の論評）から情報を収集し、調査結果を相互に照合して整合性を確認したうえで、引用元を明記した構成的なレポートにまとめます。その結果として、微妙な違いを明らかにし、相反する見解を特定し、知識の空白を指摘する、徹底的な分析が得られます。

ワークフロー

1. 調査する問いを分解する： ユーザーの大まかな問いを、トピックの異なる側面を網羅する3～6件の具体的なサブクエリに分解します。各サブクエリでは、歴史的背景、現状、主要な関係者、技術的な詳細、今後の展望など、特定の切り口を扱います。これにより、単一の検索から浅い情報を取得するのではなく、幅広く調査できます。

2. 情報源を特定して収集する： 各サブクエリについて、学術データベース、公式ドキュメント、信頼できるニュースメディア、業界アナリストのレポート、コミュニティフォーラムなど、複数の情報源カテゴリを横断して検索します。各サブクエリにつき、少なくとも2～3件の情報源を目指します。後で優先順位を付けられるよう、各情報源のURL、公開日、著者、関連性スコアを記録します。

3. 主な調査結果を抽出して整理する： 各情報源を読み、中心的な主張、データポイント、統計、専門家の意見を抽出します。調査結果は、テーマまたはサブクエリごとに分類した構成的なアウトラインに整理します。追跡可能性を確保するため、それぞれの調査結果に情報源を付記します。

4. 相互照合して検証する： 情報源間で調査結果を比較し、意見の一致点、矛盾点、情報の空白を特定します。単一の情報源にしか見られない主張や、大半の証拠と矛盾する主張にはフラグを付けます。意見の相違を解決する際は、各情報源の新しさと権威性に留意します。

5. レポートをまとめる： 検証済みの調査結果を、筋の通った内容にまとめます。レポートは、エグゼクティブサマリー、各テーマの詳細なセクション、制約と未解決の問いについての考察、完全な参考文献一覧で構成します。読みやすくするため、明確な見出しと箇条書きを使用します。

6. 見直して改善する： 論理の流れ、根拠のない主張、欠けている背景情報がないか、レポートを読み直します。すべての引用が正確であること、エグゼクティブサマリーが詳細な調査結果を忠実に反映していることを確認します。情報の空白が残る場合は、ユーザーに追加調査の提案をします。

使用方法

調査テーマをエージェントに提示します。必要に応じて、具体的なサブクエリ、希望する調査の深さ、優先する情報源の種類も指定できます。エージェントはワークフロー全体に沿って調査し、構成的なレポートを返します。

Research the current state of WebAssembly adoption in 2025.

Focus areas:
- Browser and server-side runtime support
- Major companies and projects using WebAssembly in production
- Performance benchmarks compared to native code
- Toolchain maturity (languages, compilers, debugging)
- Key limitations and open challenges

例

例 1：2025 年の WebAssembly の現状

ユーザーのリクエスト：

2025 年の WebAssembly の現状について、普及状況、ツールチェーン、パフォーマンス、今後の展望を詳しく調査してください。

クエリの分解：

サブクエリ	観点
"WebAssembly browser support 2025 Chrome Firefox Safari"	ランタイムのサポート
"WebAssembly server-side WASI Wasmtime Wasmer production"	サーバーサイドでの普及
"WebAssembly performance benchmarks vs native 2024 2025"	パフォーマンスデータ
"Rust Go C++ compile to WebAssembly toolchain maturity"	ツールチェーンの成熟度
"WebAssembly limitations garbage collection threads 2025"	未解決の課題

収集した情報源（一部）：

• W3C WebAssembly Working Group Status Report（w3.org、2025 年 1 月）
• 「Wasm in Production at Figma」 — Figma Engineering Blog（2024 年）
• Bytecode Alliance WASI 0.2 Announcement（bytecodealliance.org、2024 年）
• 「WebAssembly vs JavaScript: 2025 Benchmarks」 — InfoQ（2025 年）
• MDN Web Docs — WebAssembly GC Proposal Status（developer.mozilla.org）

統合レポート（一部）：

エグゼクティブサマリー： WebAssembly はブラウザー専用のテクノロジーから、サーバーサイド、エッジ、組み込みワークロード向けのポータブルなコンパイルターゲットへと成熟しています。主要なブラウザーはすべて、GC と Threads の提案を含む Wasm 2.0 を完全にサポートしています。WASI 0.2 によってコンポーネントモデルが安定し、Fastly、Fermyon、Cloudflare Workers が採用する、言語に依存しないプラグインアーキテクチャが実現しました。パフォーマンスベンチマークでは、計算負荷の高いタスクで Wasm がネイティブの 85～95％の速度で実行されることが示されていますが、起動レイテンシーと GC の統合については、引き続き活発に取り組まれています。ツールチェーンエコシステムは Rust と C/C++ が最も充実しており、Go と Python のサポートも急速に向上しています。主な未解決の課題として、標準化されたデバッグプロトコルがないこと、UI が中心のブラウザーアプリケーションで DOM に直接アクセスする手段が限られていることが挙げられます。

---

例 2：製品ローンチに向けた競合分析

ユーザーのリクエスト：

製品ローンチに向けて、AI を活用したコードレビュー ツールの競合状況を調査してください。

クエリの分解：

サブクエリ	観点
"AI code review tools market 2025 overview"	市場の概況
"GitHub Copilot code review features pricing"	競合の詳細分析
"CodeRabbit AI automated code review capabilities"	競合の詳細分析
"developer survey AI code review adoption satisfaction"	ユーザーの評価
"AI code review tool limitations false positives"	弱点とギャップ

統合レポート（一部）：

市場概況： AI コードレビュー市場は、統合プラットフォームツール（GitHub Copilot、GitLab Duo）、独立系 AI レビューサービス（CodeRabbit、Codacy AI）、LLM を組み込んだオープンソースのリンター（MegaLinter + GPT ラッパー）の 3 つの層に集約されています。開発者の導入状況に関する調査によると、従業員エンジニアが 50 人以上の企業では、チームの 42％が何らかの AI 支援レビューを利用しています。

特定された競合上のギャップ： 現在、リポジトリ全体のアーキテクチャの一貫性をチェックできるツールはありません。どのツールも PR の差分レベルで動作しています。差分レベルの提案と、コードベース全体にわたるパターン適用を組み合わせる製品であれば、十分に開拓されていない「プラットフォームエンジニアリング」分野を取り込める可能性があります。

ベストプラクティス

• 情報源の種類を多様化します。 単一のカテゴリの情報源だけに依存しないでください。一次情報源（公式ドキュメント、データセット）と二次分析（ブログ記事、アナリストレポート）を組み合わせ、バランスの取れた見解を得ます。
• すべての主張について出典を記録します。 抽出した各知見に情報源の URL、著者、日付を添付し、最終レポートを監査でき、引用を検証できるようにします。
• 最近の情報源を優先しつつ、代表的な先行研究も含めます。 過去1～2年以内に公開された情報源を優先しますが、その分野を定義する基礎的な論文や文書も含めます。
• 可能な限り定量化します。 「広く採用されている」のような曖昧な主張を、「調査対象チームの38％が使用」のような具体的な数値に置き換え、レポートをより実用的なものにします。
• 意見の相違を明示します。 情報源間で見解が異なる場合は、一方を黙って選ぶのではなく、それぞれの根拠とともに両方の見解を示します。これにより信頼性が高まり、読者が判断できるようになります。
• 早い段階で調査範囲を定めます。 調査の対象範囲と対象外を明確に定義し、際限のない脇道に逸れるのを防いで、レポートの焦点を保ちます。

エッジケース

• 急速に変化するトピック： 調査対象が毎週変化する場合（活発な政策論争や、発生したばかりのセキュリティ脆弱性など）は、知識のカットオフ日を目立つように記載し、行動に移す前にユーザーが調査結果を確認するよう勧めます。
• 限られた情報源や有料壁のある情報源： 重要な情報源が有料壁の向こうにある場合や、アクセスが制限されている場合は、その欠落を記載し、入手可能であれば要旨や概要を引用して、検証のためにユーザーが全文にアクセスすることを勧めます。
• 権威ある情報源同士の矛盾： 同程度に信頼できる2つの情報源が直接矛盾する場合は、両方の主張を並べて示し、それぞれの方法論を説明したうえで、結論を無理に出さず、その知見に「議論の余地あり」というラベルを付けます。
• 文献が少ない新興トピック： 非常に新しい技術や概念については、エビデンスが限られていることを明示し、一次情報源（リリースノート、RFC、公式発表）を重視して、確立した事実と推測を明確に区別します。
• 多言語または地域固有の調査： トピックが複数の地域にまたがる場合は、情報源が対象とする地域を記載し、調査結果が世界全体に一般化できない可能性がある場合は注意を促します。