1つの LLM では足りない場面がある
ADR（Architecture Decision Record）という概念を初めて知ったとき、Claude Code に「ADR って何ですか？」と聞きました。返ってきたのは「Architecture Decision Record です。重要な意思決定を記録します」という一文。正確だけど、何も分からない。
Claude Code は開発に特化したエージェントです。コードを書き、ファイルを編集し、テストを実行します。しかし概念の丁寧な説明を求めると、開発タスクのコンテキストで動作しているため、回答が簡潔すぎると感じることがありました。
私は4つの LLM を使い分ける4段階アプローチを取っています。
4段階アプローチ
第1段階: Claude Code に質問
まず開発中に出てきた用語や概念を Claude Code に質問します。
me: 「ADR って何ですか？」
Claude Code: 「Architecture Decision Record です。重要な意思決定を記録します」
開発のコンテキスト内での回答が得られます。実装に直結する情報はここで十分です。
第2段階: Gemini / 通常の Claude に質問
Claude Code の回答が不十分だと感じたとき、Gemini や Claude（通常版）に同じ質問をします。
me: 「ADR とは何か、初心者にわかりやすく説明してください」
Gemini: 「ADR は、プロジェクトで重要な技術的決定をしたとき、
その理由と背景を記録する文書です。例えば...」
より詳しい説明、丁寧な例示、初心者向けの解説が得られます。
第3段階: 例え話で説明してもらう
それでもわからないとき、工夫します。
me: 「TDD をグラップラー刃牙に例えて説明してください」
Claude（通常版）: 「TDD は、まず『相手の技を想定』してから
『対策を練る』ようなものです...」
自分の知っている分野に置き換えることで、抽象的な概念が具体的になります。漫画、スポーツ、料理など題材は何でも構いません。
第4段階: ディープリサーチ
徹底的に調査したいとき、複数の LLM に同じ質問を並行で投げます。
以下は筆者の個人的な使い分けです（2026年2月時点）。
| LLM | 使う理由 | 使い方 |
|---|---|---|
| Claude Code | 実践的な使い方 | 「このプロジェクトでどう使う？」 |
| Gemini | 概念の詳細説明 | 「初心者向けに説明して」 |
| ChatGPT | ベストプラクティス | 「一般的にはどうするのが正解？」 |
| NotebookLM | 情報統合 | 複数ソースを投入して横断分析 |
NotebookLM の活用
NotebookLM は「複数の情報源を統合する」用途で使います。
- Claude Code の回答をコピー
- Gemini の回答をコピー
- 関連ドキュメントの URL を追加
- NotebookLM に全部投入
NotebookLM が複数ソースを横断的に分析し、矛盾点や共通点を整理してくれます。
たとえば ADR のテンプレートについて調べたとき、Claude Code は「5項目構成」と回答し、Gemini は「7項目構成」と回答しました。NotebookLM に両方を投入すると「基本は5項目、チーム運用では7項目が推奨」と整理してくれました。
使い分けの判断基準
開発中に疑問が出た
↓
Claude Code に質問
↓ 回答が十分 → 開発に戻る
↓ 回答が不十分
Gemini / Claude に質問
↓ 理解できた → 開発に戻る
↓ まだわからない
例え話で説明してもらう
↓ 理解できた → 開発に戻る
↓ 深掘りしたい
ディープリサーチ（複数 LLM 並行）
ほとんどの疑問は第1〜2段階で解決します。第3〜4段階まで進むのは、新しい概念を初めて学ぶときだけです。
まとめ
この使い分けを始めてから、新しい概念の理解に費やす時間が体感で半分になりました。以前は「なんとなく分かった気」で先に進んで後でハマることが多かったのですが、第2〜3段階で腹落ちさせてから実装に戻ることで手戻りが減りました。
- Claude Code は実装に直結する回答が得意。まずここに聞く
- 概念の理解には Gemini や Claude 通常版で補完する
- 例え話は理解の突破口になる。自分の知っている分野に置き換える
- NotebookLM で複数ソースを統合し、矛盾点を整理する
- 「どの LLM に何を聞くか」を事前に決めておくと迷わない