deep-research

ディープリサーチ

新しいものを構築する前に、包括的な調査と発見を行います。トレーニングデータをもとにいきなりコードを書き始めるのではなく、このスキルでは幅広く深く調査します。ローカル環境の調査、ウェブリサーチ、競合分析、エコシステムの動向、将来予測などを行い、実際の開発を10倍生産的にするリサーチ概要を作成します。

深度レベル

違いは単に所要時間ではなく、目的の範囲です。

深度	目的	範囲
focused	特定の質問に答える	1つの判断：「CodeMirror と ProseMirror のどちらを選ぶ？」— 対象を絞った検索、ローカル環境のスキャン、1〜2件の比較を行います。1ページの推奨事項を作成します。
wide	分野の全体像を把握する	新しい製品や機能の全体像を調査します。競合、エコシステム、ユーザーニーズ、アーキテクチャの選択肢を含みます。仕様書を作成できるだけの情報を集めます。
deep	大規模な開発を計画する	あらゆる点を徹底的に調べます。wide の内容すべてに加え、ライブラリ／コンポーネントの調査、プラグインエコシステム、GitHub のイシューの調査、コミュニティの評価、将来予測、各判断に関する技術的な詳細調査を行います。数週間にわたるコーディングを進めるのに十分な情報を集めます。

デフォルト：wide

ワークフロー

1. 意図を理解する

ユーザーに次のことを尋ねます。

• 何を構築しますか？（1文で）
• なぜですか？ どのような問題を解決しますか？誰を対象にしていますか？
• 制約はありますか？ 希望する技術スタック、予算、スケジュール、必須要件など。
• 既存の成果物はありますか？ ベースにできるプロジェクトや、調査対象のリポジトリはありますか？

ユーザーのプロンプトが簡潔な場合（「cloudflare 上の obsidian 代替」など）でも、それで十分です。調査を通じて不足部分を補います。

2. ローカル環境の調査

ユーザーのマシンをスキャンし、関連する過去の成果物を探します。

# Find related projects by name/keyword
ls ~/Documents/ | grep -i "KEYWORD"

# Read CLAUDE.md of related projects for architecture context
find ~/Documents -maxdepth 2 -name "CLAUDE.md" -exec grep -l "KEYWORD" {} \;

# Check for reusable patterns, schemas, components
find ~/Documents -maxdepth 3 -name "schema.ts" -o -name "ARCHITECTURE.md" | head -20

関連するプロジェクトが見つかった場合は、それぞれについて次のことを行います。

• CLAUDE.md を読みます（技術スタック、アーキテクチャ、注意点）。
• 再利用可能なコード（スキーマ、コンポーネント、ユーティリティ、設定）を確認します。
• うまくいった点と、うまくいかなかった点を記録します（git 履歴や TODO コメントから）。

また、次の項目も確認します。

• Basalt Cortex（~/Documents/basalt-cortex/）に、関連するクライアント、連絡先、ナレッジに関する情報がないか確認します。
• grep -rl "KEYWORD" ~/Documents/basalt-cortex/ --include="*.md"

3. ウェブリサーチ

分野の全体像を把握するため、幅広く検索します。

• 製品カテゴリー：「markdown note app」、「knowledge management tool for teams」
• 競合製品：「best X」、「X alternatives」、「X vs Y」などを検索して、上位5〜10件を見つけます。
• オープンソース：GitHub でオープンソースの代替製品を検索し、スター数を確認します。
• アーキテクチャ：「how to build X」、「X tech stack」、「building X with [framework]」
• 技術ドキュメント：llms.txt や主要技術の公式ドキュメントを確認します。
• プラットフォームの事例：「built with Cloudflare Workers」、「D1 full-text search example」
• チュートリアルと事例研究：「building a Y from scratch」、「lessons learned building Z」

4. エコシステムとコミュニティの調査（幅広く＋深く）

中核となる製品だけでなく、エコシステムまで調べましょう。ユーザーが実際に必要としていることが見えてきます。

プラグインとアドオン:

• 主要な競合製品には、どのようなプラグインがありますか？人気の高いプラグインから、コア製品に欠けているものが分かります。
• 例：Obsidian には 1800 以上のプラグインがあり、上位 20 個から Obsidian が標準機能として苦手としていることが分かります。
• 検索：「top [product] plugins」、「[product] plugin directory」

GitHub の Issue と機能リクエスト:

• 競合製品の主要な GitHub リポジトリで、最も多く賛同されている Issue を確認します。
• サムズアップのリアクション数で並べ替えます。これはユーザーからの需要を直接示すシグナルです。
• クローズ済みの Issue を確認し、機能がどのように実装されたかを調べます。

フォーラムでの議論:

• Reddit：r/[product]、r/selfhosted、r/webdev、関連するニッチなサブレディット
• Hacker News：製品カテゴリーを検索
• Discord/Discourse：製品固有のコミュニティ
• ユーザーが気に入っている点は何ですか？不満に思っている点は何ですか？どんな機能を望んでいますか？

アプリストアとレビューサイト:

• 星 1 つのレビュー＝満たされていないニーズ（製品が対応できていない点）
• 星 5 つのレビュー＝維持すべき点（ユーザーが気に入っているので、損なわないこと）
• 星 3 つのレビュー＝興味深い中間層（悪くはないが……）
• 検索：ProductHunt、G2、Capterra、App Store のレビュー

連携リクエスト:

• ユーザーはどのシステムとの接続を望んでいますか？（Zapier の連携、API のリクエスト）
• こうしたリクエストから、実際のワークフローが分かります。ユーザーはツール同士を寄せ集めて、なんとか連携しています。

5. 競合製品の詳細調査（幅広く＋深く）

主要な競合製品ごとに調査します（幅広く調べる場合は 3～5 件、深く調べる場合は 5～10 件）。

質問	調査方法
機能	ランディングページ、ドキュメント、変更履歴
価格	価格ページ、比較サイト
ユーザーからの不満	Reddit、HN、アプリストアのレビュー
技術スタック	Wappalyzer、view-source、求人情報、ブログ記事
得意なこと	星 5 つのレビュー、製品デモ
苦手なこと	星 1 つのレビュー、フォーラムでの不満、その製品からの移行ガイド
ドキュメントの品質	ドキュメントサイトを読んで確認します。内容は充実していますか？最も詳しい説明が必要なトピックは何ですか？（複雑なトピックは、ユーザーが苦労していることを示します）
ヘルプ／サポートコンテンツ	ヘルプセンター、FAQ、ナレッジベース、サポートフォーラムを確認します。ユーザーから最も多く寄せられる質問は何ですか？
オンボーディング／チュートリアル	スタートガイド、動画チュートリアル、インタラクティブなウォークスルーを確認します。製品の使い方をどのように教えていますか？ユーザーがすでに知っていると想定していることは何ですか？
API ドキュメント	API がある場合、ドキュメントはどれほど充実していますか？どのようなパターンを採用していますか？どの SDK を提供していますか？
移行ガイド	「X からの乗り換え」ガイドはありますか？こうしたガイドから、競合製品が自社の強みと考えている点や、ユーザーが乗り換えにくいと感じている点が分かります。

6. ライブラリとコンポーネントの調査（深掘り）

構成要素を調査します。利用したり、参考にしたりできるものがすでにあるかを確認します。

React／UI ライブラリ：

• npm でカテゴリに特化したパッケージ（「react markdown editor」「react kanban」「react data table」など）を検索します
• 週間ダウンロード数、最終公開日、GitHub スター数、未解決の issue 数を確認します
• README とサンプルを読み、どのようなパターンが使われているかを確認します
• バンドルサイズ（bundlephobia.com）を確認し、プロジェクトの制約に合うかを判断します
• 有力なライブラリのソースコードを見てみます。実際の利用によって、そのアーキテクチャの有効性が証明されています

ヘッドレス／スタイルなしのライブラリ：

• Headless UI、Radix、React Aria、Downshift には、必要な機能に使えるプリミティブがあるでしょうか？
• スタイリングを自分で制御できるため、これらはフルコンポーネントライブラリより優れていることがよくあります
• shadcn/ui に必要なものをラップしたコンポーネントがすでにあるか確認します

フックとユーティリティ：

• TanStack（Query、Table、Virtual、Router）には、関連するものがあるでしょうか？
• React Hook Form、Zod、date-fns、Zustand は、よくある問題への実績ある解決策です
• 「awesome-react」のリストや、厳選されたコレクションを検索します

プラットフォーム固有のライブラリ：

• Cloudflare の場合：Workers で動作するものは何でしょうか？（Node.js API とネイティブモジュールは使えません）
• Cloudflare 独自のサンプルやスターターテンプレートを確認します
• 必要な機能と「cloudflare workers」を組み合わせて検索します

各ライブラリについて記録する項目：

質問	重要な理由
課題を解決できるか？	機能との適合性
バンドルサイズ	パフォーマンス予算
最終公開日	メンテナンスされているか
未解決の issue／PR	コミュニティの健全性
プラットフォームで動作するか？	Cloudflare Workers には制約があります
どのようなパターンを使っているか？	ライブラリを使わない場合でも、そのパターンは参考になります

重要なポイント：独自に実装すると決めた場合でも、既存のライブラリを調査すれば、実際のユーザーに使われる中で生き残ったパターンがわかります。スター数が 10K のライブラリなら、何千人もの開発者によって API が洗練されてきたということです。その設計上の判断を取り入れましょう。

7. プラットフォーム機能の徹底調査（広く、深く）

これは非常に重要です。 Claude の学習データは、プラットフォームの機能について常に最新ではありません。Cloudflare、Vercel、Firebase、Supabase は、いずれも新機能を次々とリリースしています。存在しないと思っていた機能が、先月リリースされているかもしれません。Basalt Cortex プロジェクトは、積極的に調査しなければ気づきにくい機能（Workers AI の toMarkdown、Vectorize のメタデータフィルタリング、D1 の FTS5）を活用するために生まれました。

プラットフォームの機能について、学習データに頼ってはいけません。 現在の公式ドキュメントを実際に読みましょう。

プラットフォームを調査する方法

1. プラットフォームの変更履歴／ブログを取得します：

   • Cloudflare：https://blog.cloudflare.com/ と https://developers.cloudflare.com/changelog/
   • Vercel：https://vercel.com/changelog
   • Firebase：https://firebase.google.com/support/releases
   • Supabase：https://supabase.com/changelog

2. すでに使っているサービスだけでなく、製品カタログ全体に目を通します：

   • Cloudflare：Workers、D1、R2、KV、Vectorize、Queues、Durable Objects、Workers AI、AI Gateway、Workflows、Containers、Browser Rendering、Tunnel、Email Routing、Images、Stream、Hyperdrive、Pipelines、Sandbox
   • Vercel：Functions、Edge Middleware、KV、Postgres、Blob、AI SDK、Cron、Firewall
   • Firebase：Firestore、Auth、Storage、Functions、Hosting、Extensions、Genkit、App Check

3. 各サービスについて、次の点を確認します：これから構築するプロダクトの課題を解決できるでしょうか？

4. 実現可能なことを広げる、最近リリースされた機能を探します：

   • エッジで利用できる新しい AI モデルはありますか？
   • 新しいストレージプリミティブはありますか？
   • 新しいネットワーク機能はありますか？
   • 新しい認証／ID 機能はありますか？
   • 新しいビルド／デプロイの選択肢はありますか？

Cloudflare の機能チェックリスト (他のプラットフォーム向けに展開)

それぞれについて確認し、「これは私たちが作っているものに役立つだろうか?」と問いかけてください:

カテゴリ	調査すべきサービス
コンピューティング	Workers、Cron Triggers、Queues コンシューマー、Workflows (マルチステップ)、Containers、Durable Objects (ステートフル)、Tail Workers
ストレージ	D1 (SQL + FTS5)、R2 (オブジェクト)、KV (キーバリュー)、Durable Object ストレージ (強整合性)
AI	Workers AI モデル (テキスト、画像、埋め込み、音声、翻訳、toMarkdown)、Vectorize (セマンティック検索)、AI Gateway (キャッシュ/ルーティング)
ネットワーキング	カスタムドメイン、Tunnel、Spectrum (TCP/UDP)、WebSockets、Hyperdrive (データベースプロキシ)
セキュリティ	WAF、Turnstile (CAPTCHA)、Bot Management、API Shield、DDoS
メディア	Images (オンザフライでのリサイズ/最適化)、Stream (動画)、Browser Rendering (スクリーンショット、PDF 生成)
メール	Email Routing (ルール)、Email Workers (プログラマブルな受信メール処理)
可観測性	Workers Logs、Analytics Engine、GraphQL analytics

記録すべき内容

関連する各機能について、以下を記録してください:

• 何をするものか (一文で)
• この製品でどのように活用できるか
• 制限や料金に関する考慮事項
• 例: 「Workers AI の toMarkdown() は、アップロードされたあらゆる PDF/DOCX をエッジで markdown に変換します — これを使えば、外部サービスなしでドキュメントのインポートができます」

これが重要な理由

「ノートアプリを作る」と「あらゆるファイルを markdown に変換し、すべてのノートをセマンティック検索し、AI で要約を生成し、バックグラウンドの Workflows で同期し、Browser Rendering で PDF をレンダリングするノートアプリを作る」の違いは、プラットフォームが何を提供しているかを知っているかどうかです。ほとんどの開発者は、残りの 80% を見たことがないために、プラットフォームの 20% しか使っていません。

8. 未来予測 (ディープモード)

今日存在するものの先を考えてください:

プラットフォームのロードマップ: 上記の変更履歴とブログの調査に基づくと、プラットフォームはどの方向へ向かっているでしょうか? 何がベータ版ですか? 発表されたがまだ GA になっていないものは何ですか?

AI 統合: 「チャットボットを追加する」ことではありません — もっと深く考えてください。ツールがユーザーのデータを読み取り、推論し、それに基づいて行動できるようになったとき、何が可能になるでしょうか? すべてのノートをセマンティック検索できたらどうでしょうか? アプリが自分自身のドキュメントを書けたらどうでしょうか? アップロードが自動的に markdown に変換されたらどうでしょうか?

デバイスと入力の進化: モバイルファースト、音声入力、ウェアラブル、空間コンピューティング。2〜5 年後、ユーザーはこれとどのようにやり取りするでしょうか?

データソース: どのような新しい入力が取り込めるでしょうか? センサー、API、リアルタイムデータ、アプリをまたいだコンテキスト?

隣接する機会: この問題の隣にはどのような問題があるでしょうか? 例えば、ノートアプリを作る場合 — 隣接するもの: タスク管理、プロジェクト追跡、チームコミュニケーション。ユーザーは今日、何をテープで貼り合わせて使っているでしょうか?

収束のトレンド: どのような別々のツールが統合されつつあるでしょうか? (メール + チャット + タスク = Slack。ノート + データベース + Wiki = Notion。次は何でしょうか?)

9. 技術調査 (ディープモード)

主要なアーキテクチャ上の決定ごとに:

決定領域	答えるべき問い
エディタ / UI フレームワーク	選択肢、トレードオフ、コミュニティの規模、私たちの経験
データベース	SQL 対 NoSQL 対 ファイル、マネージド 対 セルフホスト、私たちのスタックのサポート
認証	Better-auth、Clerk、Auth.js、カスタム — どれが合うか?
ホスティング / デプロイ	Cloudflare、Vercel、Railway — 制約と機能
検索	FTS5、Elasticsearch、Meilisearch、Vectorize — どの規模か?
リアルタイム	WebSockets、SSE、Durable Objects — 必要か?
ファイルストレージ	R2、S3、ローカル — アクセスパターンは?
API 設計	REST、tRPC、GraphQL — ユースケースが求めるものは何か?

10. 統合

.jez/artifacts/research-brief-{topic}.md に保存されるリサーチブリーフを作成します:

# Research Brief: [Topic]
**Depth**: [focused|wide|deep]
**Date**: YYYY-MM-DD
**Research time**: [duration]

## Executive Summary
[2-3 sentences: what to build, why, key insight from research]

## Competitive Landscape
| Product | Strengths | Weaknesses | Pricing | Users |

### Key Insights
[What winners do well, what gaps exist in the market]

## Ecosystem Signals
### Most Popular Plugins/Add-ons
[Top plugins for competitors — reveals unmet needs]
### Most Requested Features
[From GitHub issues, forums, reviews — sorted by demand]
### Integration Patterns
[What systems users connect to — reveals real workflows]

## User Needs
[What real users want, from reviews/forums/complaints]

## Technical Landscape
| Decision | Options | Recommendation | Why |

## Libraries and Components
| Need | Library | Stars | Size | Fits platform? | Notes |
[Key libraries evaluated for each major feature]

## Platform Capabilities
| Service | Could use for | Impact |
[Every platform service evaluated against the product's needs]
[Flag recently shipped features the team may not know about]

## Reusable From Existing Projects
| Project | What to reuse | Location |

## Future Possibilities
### Platform roadmap
### AI opportunities
### Adjacent problems
### 2-5 year horizon

## Proposed Architecture
[Stack, data model sketch, key flows]

## Risks and Open Questions
[Things research couldn't answer]

## Suggested Phases
[Build order based on research findings]

## Sources
[Links to everything read]

ヒント

• 概要は早めに作成し、調査を進めながら内容を追加してください。成果物そのものが納品物です
• ディープモードでは、サブエージェントを使ってウェブ調査とローカルでの調査を並行して進めてください
• 「既存プロジェクトから再利用できるもの」のセクションは、何週間もの作業を省けることがよくあります
• エコシステムの兆候（プラグイン、課題、レビュー）は、競合の機能一覧よりも価値があることがよくあります
• 概要は .jez/artifacts/ に保存してください。今後のセッションや実際の構築フェーズで役立ちます
• 概要は継続的に更新するドキュメントです。構築中に新たにわかったことを反映してください