Deep Research

何か新しいものを構築する前に、包括的なリサーチと発見を行います。トレーニングデータから直接コーディングに飛び込むのではなく、このスキルは広く深く探索します — ローカル探索、ウェブリサーチ、競合分析、エコシステムシグナル、未来予測 — そして、実際のビルドを 10 倍生産的にするリサーチブリーフを作成します。

深度レベル

違いは 時間だけではなく、野心のスコープ です。

深度	目的	スコープ
focused	特定の質問に答える	1つの決定: 「CodeMirror vs ProseMirror?」— ターゲット検索、ローカルスキャン、1-2 の比較。1ページの推奨事項を作成します。
wide	スペースを理解する	新製品またはフィーチャーのランドスケープ。競合、エコシステム、ユーザーニーズ、アーキテクチャオプション。スペック記述に十分です。
deep	大規模ビルドを計画する	あらゆる石を裏返します。wide のすべてプラスライブラリ/コンポーネントリサーチ、プラグインエコシステム、GitHub issues マイニング、コミュニティセンチメント、未来予測、あらゆる決定に対する技術的深掘り。数週間のコーディングを駆動するのに十分です。

デフォルト: wide

ワークフロー

1. インテントを理解する

ユーザーに質問します:

• 何 を構築していますか? (1文)
• なぜ? どのような問題を解決しますか? それは誰のためですか?
• 制約? スタック設定、予算、タイムライン、必須事項?
• 既存の作業? 構築できるプロジェクトはありますか? チェックするレポはありますか?

ユーザーが簡潔なプロンプト (「obsidian replacement on cloudflare」) を与えた場合、それで十分です — リサーチを通じて隙間を埋めます。

2. ローカル探索

ユーザーマシンで関連する過去の作業をスキャンします:

# 名前/キーワードで関連プロジェクトを検索
ls ~/Documents/ | grep -i "KEYWORD"

# 関連プロジェクトのアーキテクチャコンテキストについて CLAUDE.md を読む
find ~/Documents -maxdepth 2 -name "CLAUDE.md" -exec grep -l "KEYWORD" {} \;

# 再利用可能なパターン、スキーマ、コンポーネントをチェック
find ~/Documents -maxdepth 3 -name "schema.ts" -o -name "ARCHITECTURE.md" | head -20

見つかった関連プロジェクトごとに:

• CLAUDE.md を読む (スタック、アーキテクチャ、落とし穴)
• 再利用可能なコード (スキーマ、コンポーネント、ユーティリティ、設定) をチェック
• うまくいったこと、うまくいかなかったことをメモ (git history、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」を検索して top 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. エコシステムとコミュニティリサーチ (wide + deep)

コア製品を超える — エコシステムはユーザーが実際に何を必要としているかを明らかにします:

プラグインとアドオン:

• 主要な競合製品にどんなプラグインが存在しますか? 最も人気のあるプラグインは、コア製品に何が不足しているかを明らかにします。
• 例: Obsidian には 1800+ のプラグインがあります — トップ 20 はあなたに何を Obsidian がネイティブで上手くこなさないかを示します。
• 検索: 「top [product] plugins」、「[product] plugin directory」

GitHub issues とフィーチャーリクエスト:

• トップ競合の GitHub リポを最も票をもらった issues でチェック
• thumbs-up reactions でソート — これは直接的なユーザー需要シグナルです
• クローズされた issues でフィーチャーがどのように実装されたかをチェック

フォーラムの議論:

• Reddit: r/[product]、r/selfhosted、r/webdev、関連ニッチ subreddit
• Hacker News: 製品カテゴリーを検索
• Discord/Discourse: 製品固有のコミュニティ
• ユーザーが何を愛していますか? 何に不平を言っていますか? 何が存在することを望んでいますか?

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

• 1 つ星のレビュー = 満たされていないニーズ (製品がこれに失敗しています)
• 5 つ星のレビュー = 保持する価値があるもの (ユーザーはこれを愛しています、壊さないでください)
• 3 つ星のレビュー = 興味深いミドル (それは OK ですが...)
• 検索: ProductHunt、G2、Capterra、App Store レビュー

統合リクエスト:

• ユーザーはどのようなシステムを接続したいですか? (Zapier 統合、API リクエスト)
• これは実際のワークフローを明らかにします — ユーザーはツールを即興的に一緒にくっつけます

5. 競合深掘り (wide + deep)

主要な各競合 (wide は 3-5、deep は 5-10):

質問	リサーチ方法
フィーチャー	ランディングページ、ドキュメント、チェンジログ
価格	価格ページ、比較サイト
ユーザー不満	Reddit、HN、アプリストアレビュー
テックスタック	Wappalyzer、view-source、求人情報、ブログ記事
上手くやっていること	5 つ星レビュー、製品デモ
上手くいっていないこと	1 つ星レビュー、フォーラム不満、その製品 FROM の移行ガイド
ドキュメント品質	彼らのドキュメントサイトを読む — 包括的ですか? どのトピックが最も説明を必要としていますか? (複雑なトピック = ユーザーが苦労していることです)
ヘルプ/サポートコンテンツ	ヘルプセンター、FAQ、ナレッジベース、サポートフォーラム — ユーザーはほとんどどのような質問をしていますか?
オンボーディング/チュートリアル	始めるためのガイド、ビデオチュートリアル、インタラクティブなウォークスルー — 彼らはどのように製品を教えていますか? ユーザーが既に知っていると思われることは何ですか?
API ドキュメント	API がある場合 — どのようにドキュメント化されていますか? どのようなパターンを使用していますか? どのような SDK を提供していますか?
移行ガイド	「X から切り替え」ガイドをしていますか? これは彼らの利点を考慮したもの AND をユーザーが切り替えるのが難しいと思うことを明らかにします

6. ライブラリとコンポーネントリサーチ (deep mode)

ビルディングブロック — 使用または学習できる既存のものをリサーチします:

React / UI ライブラリ:

• npm で「react markdown editor」、「react kanban」、「react data table」など、カテゴリ固有のパッケージを検索
• 週単位のダウンロード、最後のパブリッシュ日、GitHub スター、open issues 数をチェック
• README とサンプルを読む — どのようなパターンを使用していますか?
• バンドルサイズをチェック (bundlephobia.com) — プロジェクト制約に適合していますか?
• 最良なもののソースコードを見る — これらのアーキテクチャは実際の使用によって証明されています

ヘッドレス / スタイルなしライブラリ:

• Headless UI、Radix、React Aria、Downshift — 必要なフィーチャーのどのようなプリミティブが存在しますか?
• これらは完全なコンポーネントライブラリよりも良いことが多いです。スタイリングを制御するため
• shadcn/ui が既に何が必要かをラップしているかをチェック

Hooks とユーティリティ:

• TanStack (Query、Table、Virtual、Router) — 何が関連していますか?
• React Hook Form、Zod、date-fns、Zustand — 一般的な問題の証明されたソリューション
• 「awesome-react」リストとキュレートされたコレクションを検索

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

• Cloudflare: Workers で何が機能しますか? (Node.js API なし、ネイティブモジュールなし)
• Cloudflare の独自の例とスターターテンプレートをチェック
• 「cloudflare workers」+ 必要なフィーチャーを検索

各ライブラリでキャプチャする内容:

質問	なぜ重要か
問題を解決しますか?	フィーチャーマッチ
バンドルサイズ	パフォーマンス予算
最後のパブリッシュ日	メンテナンスされていますか?
Open issues / PRs	コミュニティヘルス
プラットフォームで機能しますか?	Cloudflare Workers には制限があります
どのようなパターンを使用していますか?	ライブラリを使用しないことにしても、パターンは価値があります

洞察: ライブラリの使用しないことにしても、リサーチは実際のユーザーとの接触に耐えたパターンを示しています。10K スターを持つライブラリは、数千の開発者による API の洗練を受けています — 彼らの設計決定を盗んでください。

7. プラットフォーム機能深掘り (wide + deep)

これは重要です。 Claude のトレーニングデータは常にプラットフォームフィーチャーの後ろにあります。Cloudflare、Vercel、Firebase、Supabase — すべて継続的に新しい機能をリリースしています。存在しないと想定するフィーチャーは先月リリースされているかもしれません。Basalt Cortex プロジェクトは機能 (Workers AI toMarkdown、Vectorize メタデータフィルタリング、D1 FTS5) 存在するため積極的に探していなかったら明らかではなかったはずです。

プラットフォーム機能についてトレーニングデータに依存しないでください。 実際の現在のドキュメントを読んでください。

プラットフォームをリサーチする方法

1. プラットフォームの changelog/blog をフェッチ:

   • 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 モデル?
   • 新しいストレージプリミティブ?
   • 新しいネットワーク機能?
   • 新しい auth/identity フィーチャー?
   • 新しい build/deploy オプション?

Cloudflare 機能チェックリスト (他のプラットフォーム用に拡張)

各項目を通してアクセスして「構築しているものに役立つか」を聞く:

カテゴリー	調査するサービス
コンピュート	Workers、Cron Triggers、Queues consumers、Workflows (マルチステップ)、Containers、Durable Objects (ステートフル)、Tail Workers
ストレージ	D1 (SQL + FTS5)、R2 (オブジェクト)、KV (キー値)、Durable Object storage (強力に一貫した)
AI	Workers AI models (テキスト、画像、埋め込み、音声、翻訳、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

キャプチャするもの

関連する各機能については、以下をメモ:

• どのようなことをしますか (1 文)
• この製品でどのように使用できるか
• 制限またはコスト考慮
• 例: 「Workers AI toMarkdown() はアップロードされたすべての PDF/DOCX をマークダウンにエッジで変換します — 外部サービスなしでドキュメントインポートに使用できます」

なぜこれが重要か

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

8. 未来予測 (deep mode)

今日存在するものを超えて考える:

プラットフォームロードマップ: 上記の changelog とブログリサーチに基づいて、プラットフォームはどの方向に向かっていますか? ベータ版には何がありますか? 発表されたが GA ではない何がありますか?

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

デバイスと入力進化: モバイルファースト、音声入力、ウェアラブル、空間コンピューティング。ユーザーは 2-5 年でこれとどのように相互作用するかもしれません?

データソース: どのような新しい入力が供給される可能性がありますか? センサー、API、リアルタイムデータ、クロスアプリコンテキスト?

隣接する機会: この 1 の隣に何の問題が座っていますか? 例: ノートアプリを構築 — 隣接: タスク管理、プロジェクト追跡、チーム通信。ユーザーは今日何を即興でくっつけていますか?

収束トレンド: どのような別のツールが統一されていますか? (Email + chat + tasks = Slack。Notes + databases + wikis = Notion。次は何?)

9. 技術リサーチ (deep mode)

各主要なアーキテクチャ決定について:

決定領域	答えるべき質問
エディター / UI フレームワーク	オプション、トレードオフ、コミュニティサイズ、私たちの経験
データベース	SQL vs NoSQL vs file、managed vs self-hosted、スタックサポート
Auth	better-auth、Clerk、Auth.js、カスタム — 何が適合しますか?
ホスティング / デプロイメント	Cloudflare、Vercel、Railway — 制約と機能
検索	FTS5、Elasticsearch、Meilisearch、Vectorize — どのスケール?
リアルタイム	WebSockets、SSE、Durable Objects — 必要ですか?
ファイルストレージ	R2、S3、local — アクセスパターン?
API デザイン	REST、tRPC、GraphQL — ユースケースは何が必要?

10. 統合

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

# Research Brief: [Topic]
**深度**: [focused|wide|deep]
**日付**: YYYY-MM-DD
**リサーチ時間**: [duration]

## エグゼクティブサマリー
[2-3 文: 何を構築するか、なぜ、リサーチからの重要な洞察]

## 競合ランドスケープ
| 製品 | 強み | 弱点 | 価格 | ユーザー |

### 主な洞察
[勝者は何を上手くやるか、市場にどんなギャップが存在するか]

## エコシステムシグナル
### 最も人気のあるプラグイン/アドオン
[競合のトッププラグイン — 満たされていないニーズを明らかにします]
### 最も要求されたフィーチャー
[GitHub issues、フォーラム、レビューから — 需要でソート]
### 統合パターン
[ユーザーが接続するシステム — 実際のワークフローを明らかにします]

## ユーザーニーズ
[実際のユーザーが何を望むか、レビュー/フォーラム/不満から]

## 技術ランドスケープ
| 決定 | オプション | 推奨 | なぜ |

## ライブラリとコンポーネント
| ニーズ | ライブラリ | スター | サイズ | プラットフォームに適合? | 注記 |
[各主要フィーチャーについて評価されたキーライブラリ]

## プラットフォーム機能
| サービス | 使用できるもの | インパクト |
[製品のニーズに対して評価されたすべてのプラットフォームサービス]
[チームが知らないかもしれない最近リリースされたフィーチャーにフラグを立てる]

## 既存プロジェクトから再利用可能
| プロジェクト | 再利用する内容 | ロケーション |

## 未来の可能性
### プラットフォームロードマップ
### AI の機会
### 隣接する問題
### 2-5 年の地平線

## 提案されたアーキテクチャ
[スタック、データモデルスケッチ、キーフロー]

## リスクとオープンな質問
[リサーチが答えることができなかったこと]

## 推奨されるフェーズ
[リサーチ結果に基づくビルド順序]

## ソース
[読まれたすべてへのリンク]

ヒント

• ブリーフを早期に開始し、リサーチするにつれて追加 — artifact は成果物です
• deep mode については、サブエージェントを使用してウェブリサーチとローカル探索を並列化
• 「既存プロジェクトから再利用可能」セクションは多くの場合、数週間の作業を節約します
• エコシステムシグナル (プラグイン、issues、レビュー) はしばしば競合フィーチャーリストよりも価値があります
• ブリーフを .jez/artifacts/ に保存 — これは将来のセッションとビルドフェーズに役立ちます
• ブリーフは生きたドキュメント — ビルド中に学習するにつれて更新