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

こんにちは。6月に入って雨の日が増えてきましたね。家の中で調べものをする時間が、少し長くなりそうな季節です。

先に結論を書きます。Claude の「Research」（ディープリサーチ。AI が自分で何度も検索を重ねて、引用付きの報告書にまとめてくれる機能）は、通常の Web 検索の上位互換ではありません。そして、コーディングや、手元の文脈と強く結びついた作業には、基本的に使わないほうがいいです。ここを曖昧にしたまま検索のつもりで回すと、トークン（AI が文章を数える単位で、使用量や料金の目安になります）を大きく溶かしたうえに、欲しかった答えではなく「それっぽい長文」が返ってきます。実務では、これがいちばん厄介です。

私はこの手の機能を見ると、まず疑ってかかります。賢そうに見えるものほど、使いどころを間違えると高くつくからです。今回も、そこは変わりませんでした。実際に1回回したら約437万トークンが消えた話も含めて、以下で順に整理します。

• Claudeの『Research』は何をしているのか
• 公式の使い分け基準はかなり明確
• OpenAI Deep Researchと比べると何が違うか
• コストは思ったより軽くない
• 実際に回したら、1回で437万トークン溶けた
• コーディングに使うべきでない理由
• 引用はある、でも鵜呑みにはできない
• 今日からの使い分けフロー
  • 1. まず自分に聞く
  • 2. 1〜2回で済むなら通常検索
  • 3. 5回以上かかりそうならResearch
  • 4. コーディング中ならResearchを挟まない
  • 5. 出てきた引用は最後に人間が確認する
• この記事を書いた人

まず押さえておきたいのは、Claude の Research が「検索を1回強くした機能」ではない、という点です。Anthropic の説明では、Research は頼まれた内容を小さく分解し、たくさんの情報源を深掘りし、前の結果に積み上げながら検索を繰り返し、最後にインライン引用付きのレポートへまとめる仕組みです。1回きりの検索とも、決まった資料から答えを引くだけの仕組み（静的 RAG）とも違います。 出典: Claude blog / Integrations（2026年時点） / Claude Support / Research（2026年時点）

中の作りも、かなりエージェント（自分で次の手を決めて動く AI）寄りです。Anthropic の技術記事によると、まとめ役の lead agent が計画と分解を受け持ち、3〜5の専門 subagent（手分けして調べる子役の AI）を並列に起動します。それぞれの subagent が見つけた内容を持ち帰り、まとめ役が足りないと判断すれば追加で調べてから統合する、という流れです。 出典: Anthropic Engineering: Multi-agent research system（2026年時点）

この構造は、調べものにはよく効きます。ただ、後で書くとおり、コードを書く・バグを直すといった「文脈が密に結びついた作業」では、むしろ重荷になります。

この記事でいちばん大事なのはここです。Anthropic 公式の判断基準は、かなりはっきりしています。

1〜2回の tool call（AI が検索などの道具を呼び出す回数）で答えられる事実は、通常の Web 検索。5回以上の tool call や、1〜3分かけて包括的に集める調べものは Research。 出典: Claude Support / when to use Research（2026年時点）

この線引きは、実務でもそのまま使えます。たとえば次のような用事なら、通常の検索で足ります。

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

一方で、Research に寄せたいのはこういう場面です。

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

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

比較相手として外せないのが OpenAI Deep Research です。こちらも1回きりの検索ではなく、何段階も考えては検索することを前提にしたエージェント型です。OpenAI は、Deep Research を o3 ベースで、end-to-end の RL（強化学習）によって多段の調べ方を学習させた仕組み と説明しています。 出典: OpenAI: Introducing Deep Research（2026年時点）

公開情報では、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 は、もっともらしい誤りを作ること（hallucination）、権威ある情報と噂を混同すること、自信の度合いの見積もり（confidence calibration）が弱いこと、引用の誤りがあることも明示しています。引用が付いているからといって、答えまで正しいとは限らない。ここは覚えておきたいところです。

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

なお、Gemini Deep Research と Perplexity については、今回の論点に必要な仕組み・引用の質・使える条件についての一次情報を十分に確認できませんでした。なので、ここでは無理に比較へ加えません。未確認は未確認のまま、今後の検証候補として置いておきます。

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

Anthropic の研究記事では、複数の AI が手分けする multi-agent は、単独の Opus 4（single-agent）より精度で上回る一方、agent はふつうのチャットの約4倍、multi-agent は約15倍のトークンを使うとされています。ウェブで答えを探し出す試験 BrowseComp では、使ったトークンの量だけで、性能のばらつきの80%を説明できた、という報告もあります。 出典: Anthropic Engineering: Multi-agent research system（2026年時点）

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

さらに、開発者向けの Claude API にある web-search ツールは、消費者向けの Research とは別物で、$10 / 1,000検索に加えて通常のトークン料金がかかります。検索で取ってきた結果も、入力トークンとして課金されます。 出典: 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 は「毎回回す検索」ではなく、勝負どころだけで使う道具です。

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

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

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

先ほどの「multi-agent はチャットの約15倍」は Anthropic の公表値です。今回は同じ問いを通常のチャットで解いた量と比べていないので、15倍という倍率そのものを手元で確かめたわけではありません。それでも、1回で約437万トークンは、気軽に回せる量ではありませんでした。深掘りの質は確かに高く、一次ソース付きで論点が整理されて返ってきます。ですが、これを「いつもの検索」の感覚で回したら、お財布も時間もふつうに溶けます。

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

ここが本題です。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で解決できない心の課題も解決いたします！