Claude Code のディープリサーチはコーディングに不向き — 15倍トークンを溶かしてわかった使いどころ

冒頭で結論

Claudeの『Research』は、通常のWeb検索の上位互換ではありません。そして、コーディングや文脈が強く結びついた作業には、基本的に使わないほうがいいです。ここを曖昧にすると、検索のつもりで回しただけでトークンを大きく溶かし、しかも欲しかった答えより「それっぽい長文」が返ってきます。実務では、これがいちばん厄介です。

私はこの手の機能を見ると、まず疑います。賢そうに見えるものほど、使いどころを間違えると高くつくからです。今回もそこは同じでした。

Claudeの『Research』は何をしているのか
公式の使い分け基準はかなり明確
OpenAI Deep Researchと比べると何が違うか
コストは思ったより軽くない
実際に回したら、1回で437万トークン溶けた
コーディングに使うべきでない理由
引用はある、でも鵜呑みにはできない
今日からの使い分けフロー
この記事を書いた人
関連記事

Claudeの『Research』は何をしているのか

まず押さえるべきは、ClaudeのResearchは「検索を1回強くした機能」ではない、という点です。Anthropicの説明では、Researchはリクエストを分解し、多数の情報源を深掘りし、前の結果に積み上げながら反復検索し、最後にインライン引用付きのレポートへ統合する仕組みです。単発検索でも静的RAGでもありません。出典: Claude blog / Integrations（2026年時点） / Claude Support / Research（2026年時点）

内部アーキテクチャも、かなりエージェント寄りです。Anthropicの工程記事では、lead agent が計画と分解を行い、3〜5の専門 subagent を並列起動して、各 subagent が見つけた内容を返し、必要なら追加調査を回して統合します。出典: Anthropic Engineering: Multi-agent research system（2026年時点）

この手の構造は、調査には効きます。ですが、後述する通り、コード生成やバグ修正のような「文脈が密に結びついたタスク」では、むしろ重くなります。

公式の使い分け基準はかなり明確

ここが今回いちばん重要です。Anthropic公式の判断基準はかなりはっきりしています。 1〜2回の tool call で答えられる事実は通常のWeb検索。5回以上の tool call や、1〜3分かける包括的な情報収集はResearch。 出典: Claude Support / when to use Research（2026年時点）

この線引きは、実務ではかなり使えます。たとえば以下は通常検索で足ります。

あるライブラリの公式API仕様を1件確認したい
あるエラーコードの一次情報を見たい
変更点が1〜2ソースで収まる

一方で、Research側に寄るのはこういうケースです。

仕様変更の背景を複数ソースで突き合わせたい
競合製品の発表、ドキュメント、価格、制限をまとめたい
断片的な情報を、時間をかけて比較表にしたい

つまり、「探す」なら検索、「まとめる」ならResearchです。この整理だけで、かなり無駄打ちを減らせます。

OpenAI Deep Researchと比べると何が違うか

Claudeだけでなく、比較対象として見ておきたいのが OpenAI Deep Research です。こちらも単発検索ではなく、多段の推論と検索を前提にしたエージェント型です。OpenAIは、Deep Research を o3ベースで、end-to-endのRLで多段トラジェクトリを学習した仕組み と説明しています。出典: OpenAI: Introducing Deep Research（2026年時点）

OpenAI側の公開情報では、1タスクあたりの所要時間は5〜30分とされています。ここは正直、気軽さより「重さ」が先に立ちます。出典: OpenAI: Introducing Deep Research（2026年時点）

さらに重要なのは、OpenAI自身が限界も公開していることです。HLE（Humanity's Last Exam）での**26.6%**という数値は、OpenAIの自己申告です。しかも、text-only subset で browsing と Python を有効にした条件です。独立監査ではありません。 出典: OpenAI: Introducing Deep Research（2026年時点）

OpenAIは同時に、hallucinate すること、権威と噂を混同すること、confidence calibration が弱いこと、引用エラーがあることも明示しています。ここは大事です。引用が付いているからといって、答えまで正しいとは限りません。

ClaudeとOpenAIの違いを雑に言うと、どちらも「深掘り型」ですが、Researchは調査の補助輪、Deep Researchはかなり重い調査機械です。ただし、どちらも「検索した事実を最後に人間が検証する」前提は崩れていません。

ちなみに、Gemini Deep Research や Perplexity については、今回の論点で必要な仕組み・引用品質・可用性の一次情報を十分に確認できませんでした。なので、ここでは無理に比較対象へ押し上げません。未確認は未確認のまま、今後の検証候補として置きます。

コストは思ったより軽くない

ここで一度、足元を見ておきます。Research系は、体感以上にコストを食います。

Anthropicの研究記事では、multi-agent は single-agent Opus 4 より精度で上回る一方、agentはチャットの約4倍、multi-agentは約15倍のトークン消費とされています。BrowseComp では、トークン量だけで性能分散の**80%**を説明できた、という報告もあります。出典: Anthropic Engineering: Multi-agent research system（2026年時点）

ここはコスト感を見直す数字です。賢さがそのまま安さに変わるわけではない、といういつもの現実です。

さらに Claude API の web-search ツールは、消費者向け Research とは別物で、$10 / 1,000検索に加えて標準のトークン課金がかかります。検索結果は input token として課金対象です。出典: Claude API web-search tool（2026年時点）

OpenAI Deep Research も無料ではありません。2025-04-24時点の公開上限は、Free 5回/月、Plus/Team/Enterprise/Edu 25回/月、Pro 250回/月で、上限後は o4-mini の軽量版に自動切替です。出典: OpenAI: Introducing Deep Research / TechCrunch report（2026年時点, point-in-time）

要するに、Researchは「毎回回す検索」ではなく、勝負どころだけ使う道具です。

実際に回したら、1回で437万トークン溶けた

ここは私の実体験です。じつはこの記事の下調べそのものに、Claude Code のディープリサーチ（サブエージェントを並列に投げて深掘りさせるリサーチ機能）を一度だけ本気で回しました。テーマは「Claudeのリサーチと通常検索は何が違うのか」。結果はこうです。

起動したサブエージェント: 102個
消費トークン: 約437万
ツール呼び出し: 645回
所要時間: 約18分

たった1本のリサーチで、です。モデルはOpus 4.8、effortは最上位で回しました。体感としては、5時間枠の使用量メーターが一気に半分ほど、週の枠も8%前後持っていかれた印象です。ここは正確な前後比較ではなく体感値ですが、肌感として「軽い気持ちで回す重さではない」のははっきり分かりました。

おもしろいのは、さきほどの**「multi-agentはチャットの約15倍」というAnthropicの数字**を、はからずも自分の手元で裏取りした格好になったことです。15倍は煽りではありませんでした。深掘りの質は確かに高く、一次ソース付きで論点が整理されて返ってきます。ですが、これを「いつもの検索」の感覚で回したら、財布も時間も普通に溶けます。

逆に言えば、ここまでのコストを払う価値がある調べ物——複数ソースを突き合わせて、一次情報付きで腰を据えて整理したい、という場面でだけ抜く刀です。コードを書いている最中に軽い気持ちで呼ぶ道具ではない、と身をもって理解しました。次の節は、まさにそこの話です。

コーディングに使うべきでない理由

ここが本題です。ClaudeのResearchは、コーディング用途の常用には向きません。

理由は単純で、コード作業は情報収集よりも、いま手元にある文脈との接続が重要だからです。 Research は複数ソースを集めて統合するのは得意でも、あなたのリポジトリの状態、直前の修正差分、実行ログ、依存関係のつながりを、軽快に扱う道具ではありません。

Anthropic自身も、multi-agent は高価値な調査には効く一方で、文脈密結合タスクには明確に非推奨という立場です。Claude Code の subagent も独立コンテキスト窓を持ち、親に要約だけ返す構造です。これは裏を返せば、全体の細かな文脈を常時共有する設計ではない、ということです。出典: Claude Code docs / sub-agents（2026年時点） / Anthropic Engineering: Multi-agent research system（2026年時点）

実際に触ると、この差は地味に効きます。たとえば、

仕様を調べる
その仕様を踏まえて実装方針を考える
さらに今のコードベースに合わせて修正する

この3段階のうち、Research が強いのは最初の1段階目までです。2段階目以降は、むしろ通常の対話、リポジトリ内検索、差分確認、テスト実行のほうが速くて安いことが多いです。

「じゃあ、コード関連の調査なら全部Researchでよくないか」と思う気持ちは分かります。ですが、そこを一括りにすると外します。仕様調査と実装作業は別腹です。ここを混ぜると、長くて高いだけの回答を抱えたまま進むことになります。

引用はある、でも鵜呑みにはできない

Research系の出力で安心しやすいのは、引用が見えるからです。ですが、これは半分だけ正しい安心です。

Claude API の web-search でも引用は常時付きますが、公式ドキュメントは**「引用の存在 ≠ 引用の正確性」**という前提で読むべきだと示しています。出典: Claude API web-search tool（2026年時点）

OpenAI も同様で、Deep Research は hallucination や引用エラーを認めています。つまり、引用は検証の入口であって、検証の完了ではないです。出典: OpenAI: Introducing Deep Research（2026年時点）

私の判断はシンプルです。

引用がある → まず見る
一次情報か → すぐ確認する
文脈に合うか → 自分の手元で再確認する
そのまま採用していいか → まだ一段疑う

これで十分です。むしろ、ここを飛ばすほうが危ないです。

今日からの使い分けフロー

最後に、実務での最小フローだけ置いておきます。ここまで読んだ人は、たぶん「結局、どっちをいつ使うのか」を知りたいはずです。

1. まず自分に聞く

1〜2回の検索で足りるか
仕様や事実を1つ確認したいだけか
それとも、複数ソースを束ねた比較・整理が必要か

2. 1〜2回で済むなら通常検索

公式ドキュメントを開く
必要なページだけ当てる
その場で一次情報を読む

3. 5回以上かかりそうならResearch

複数ソースの横断
背景と比較の統合
長めのレポート化

4. コーディング中ならResearchを挟まない

まず手元のコード、テスト、ログを見る
仕様確認だけ通常検索で済ませる
Research は「調べ物」が本体のときだけ使う

5. 出てきた引用は最後に人間が確認する

公式か
そのページに本当に書いてあるか
いまの自分の文脈にそのまま当てはまるか

この順番にしておくと、無駄に高い調査を減らせます。 2026年時点の私は、ClaudeのResearchを「便利な調査員」としては認めます。ですが、検索の上位互換として常用する道具ではないと見ています。まして、コーディングの相棒として前に出すのは違う。そこははっきり切り分けたほうが、結局は速いです。

必要なのは、賢い機能を増やすことより、使い分けを雑にしないことでした。

この記事を書いた人

HW系エンジニアとして20年以上、10,000件を超える顧客訪問と2,000件を超える単独ソリューション実績。AIツールを使った個人開発やIoT農園など、Raspberry Piを使ったオートメーション化なども実践中です！エンジニア専門結婚相談所も運営中、ClaudeCodeで解決できない心の課題も解決いたします！