Deep Research の品質を上げたいとき、検索回数やモデルを先に変えたくなる。だが LongCat-DeepResearch の公開レポートを読むと、効いているのは検索の豪華さだけではない。計画は共有し、セクションごとの調査履歴は共有しない。完成したセクションは機械的に組み、編集は全体指示→局所修正の順に進める。この分担が、長いレポートの根拠を残すための設計になっている。
本稿は、公開レポートとハーネスを読み、自分の調査パイプラインに持ち帰るなら何を設計項目にするかを整理する。再実装の記録ではなく、概念整理である。では、この分担を自分のパイプラインに持ち帰るなら、何を設計項目にすればよいのか。
この記事で分かること
- ResearchSpec が共有する情報と、各 Researcher が閉じる情報の違い
- 計画→セクション調査→組み立て→全体/局所編集の流れ
- 公開ベンチマークの数字を、実務でどう読むか
- 導入前に確認すべき制約
対象読者
- 社内の調査エージェントやレポート自動化を検討している開発者
- Deep Research 型のパイプラインを設計している人
- 公開ベンチマークの数字を導入判断に使いたい人
前提
- 参照するのは公開されている技術レポート、プロジェクトページ、ハーネスのコードのみ。
- モデル本体や学習データは公開されていない。再現実験は行っていない。
- 図は公式のものを出典付きで使う。
TL;DR
- 共有するのは ResearchSpec。セクションごとの検索・読解履歴は共有しない。
- 計画は Planning Writer / Judge / Critic / Reviser で作り、dispatch 後は固定される。
- セクションは書き直さず機械的に結合し、Global Editor の指示で Local Editor が局所修正する。
- 公開ベンチマークは 55.25 / 51.35 / 79.83。ただし比較単位はシステム全体で、ネイティブのツールと予算が異なる。
- 導入時は「計画の再開可否」「部品分析の範囲」「可読性評価の主体」「公開範囲」を確認する。
1. 設計の中心は「共有状態」の分割
LongCat-DeepResearch の中心は、ResearchSpec という実行可能な調査計画だ。スコープ、答えるべき問い、必要な事例、暫定的な情報源、セクションごとの担当が含まれる。これは全員の共有状態になる。一方で、各セクションの検索履歴、読んだページの要約、書きかけの段落は、その担当 Researcher の手元に閉じる。
共有する情報を増やすほど、全体の整合は取りやすい。だが、一つのセクションを深く掘るための文脈は押し出される。逆に全部を分けると、各担当は深く掘れるが、最後に集めたときに用語も問いも噛み合わない。この設計は、全部共有か全部分離かではなく、共有する層と閉じる層を分けている。
図1：ResearchSpec を作る計画段階、独立した Researcher によるセクション執筆、Global/Local Editor による調整。出典：プロジェクトページ／公式README。
2. 3段階の処理フロー
| 段階 | 入力 | 出力 | 実務での確認点 |
|---|---|---|---|
| 計画 | 依頼、複数の計画候補 | ResearchSpec | スコープ、問い、事例、情報源、担当が検査可能か |
| セクション調査 | 依頼＋ResearchSpec 全体＋担当範囲 | 引用付きセクション | 履歴が担当内に閉じているか、引用があるか |
| 組み立て・編集 | 完成したセクション | 最終レポート | 機械的結合か、編集が局所か |
第一段階では、複数の Planning Writer が短時間だけ検索・読解して計画候補を出し、Planning Judge が統合し、Critic が抜けを指摘し、Reviser が更新する。ここで作られた ResearchSpec が、以降の共通言語になる。
第二段階では、セクションごとに独立した Researcher が、元の依頼、ResearchSpec 全体、自分の担当範囲を受け取り、追加調査をして引用付きのセクションを書く。計画は共有されるが、調査の履歴は共有されない。
第三段階では、完成したセクションを書き直さずに機械的に結合する。その後、Global Editor がセクション間の矛盾、重複、担当の重なりを見つけ、Local Editor が指示に沿って該当箇所だけを直す。最後に一人の書き手が全文を再生成しないことが重要だ。再生成すれば、調査の文脈も引用も一度リセットされる。
公式のハーネス図は全体像をつかむのに便利だが、実務では各段階の入出力を表で確認したほうがよい。図は「何段階あるか」を示すが、どの情報が共有され、どこで閉じるかまでは示しきらない。
3. 実務に持ち帰るワークフロー例
ここでは、論文の記述を自分の現場に置き換えるための架空の依頼を使う。実験ではない。
依頼は「競合3社の製品を、公開情報と社内情報を分けて比較し、導入判断に使えるレポートにしたい」とする。
| 手順 | やること | 出力・確認 |
|---|---|---|
| 1. Spec を作る | スコープ、問い、事例、情報源、セクション、担当を決める | 検査可能な ResearchSpec |
| 2. 担当を分ける | 1セクション1担当。情報源の境界も決める | セクションごとの引用方針 |
| 3. 機械的に結合 | 文章を直さず、セクションIDと引用を保って並べる | 結合済みドラフト |
| 4. 全体指示 | 用語の統一、重複の除去、欠けた論点の補足を指示する | Global Editor の指示 |
| 5. 局所修正 | 指示で指された段落だけを直す | 差分の小さい修正 |
この例の狙いは、立派な文章を一気に生成することではない。計画を共有して問いを揃え、調査履歴を閉じて深さを確保し、最後に局所的な編集で整合を取る。品質を保証するものではないが、長いレポートで失われがちな「なぜそう言えるのか」を残すための分業にはなる。
4. 公開ベンチマークの読み方
図2：比較した4システムの公開ベンチマークスコア。出典：プロジェクトページ。
| システム | DeepResearchBench | DeepResearchBench II | ResearchRubrics |
|---|---|---|---|
| LongCat-DeepResearch | 55.25 | 51.35 | 79.83 |
| ChatGPT-DeepResearch | 54.95 | 47.16 | 74.21 |
| Claude-DeepResearch | 53.43 | 48.18 | 72.91 |
| Gemini-DeepResearch | 50.21 | 46.72 | 64.92 |
数字を導入判断に使うときの注意は4つある。
- 比較単位はシステム全体。各製品はネイティブのツールと予算で動かされている。モデル単体やハーネス単体の比較ではない。
- 差は一様ではない。DeepResearchBench では2位との差が +0.30 と小さい。社内ベンチマークでは 76.04 で、ChatGPT-DeepResearch の 76.59 に 0.55 及ばず2位だった。
- 部品の寄与は分けて見る。以前の LongCat モデルに ReAct/直接執筆を組み合わせると 47.65 / 33.13 / 60.33、同じモデルに現在のハーネスを組み合わせると 53.58 / 48.68 / 71.90、現在のモデルとハーネスで 55.25 / 51.35 / 79.83。モデルとハーネスは補完的だと整理されている。固定した ResearchRubrics サブセットでは、複数の Planning Writer の視点を Judge が統合すると、単一 Writer の計画より 81.67 から 85.13 に上がった。
- 評価主体を確認する。可読性はモデルによる判定であり、人間の評価ではない。反復実行や統計的有意性を主張したものでもない。
避けたい読み方は、「世界一」「すべての指標で圧勝」「モデルだけの比較」と要約することだ。どれも、公開されている条件からは言えない。
5. 導入前チェックリスト
- 公開範囲を確認した。公開されているのは調査ハーネスのコードのみで、モデル本体、学習データ、重み、隠れた rubric、軌跡、学習コードは含まれない。
- 計画が dispatch 後に固定されることを理解した。調査中に全体の問いへ戻って計画を開き直す用途には向かない。
- 部品分析が開発用サブセットに基づくと知っている。フルベンチマークでの独立した追試ではない。
- 可読性がモデル判定であることを確認した。人間の評価と読み替えない。
- 比較条件を保持している。システム全体、ネイティブのツールと予算という条件を外して「同一条件の比較」と言わない。
- 図は公式の2枚を使い、出典を付けた。新しいグラフや数値を作っていない。
- AI生成の開示を1回入れ、人間レビュー済みと読める表現を避けた。
6. まとめ
-
LongCat-DeepResearch の設計は、ResearchSpec を共有し、セクション調査の履歴を閉じ、完成物を機械的に結合し、全体指示→局所修正で仕上げる。
-
公開ベンチマークは 55.25 / 51.35 / 79.83 だが、比較単位はシステム全体。社内ベンチマークでは 76.04 で2位、公開指標の差も一様ではない。
-
導入時は、計画の再開可否、部品分析の範囲、可読性評価の主体、公開範囲を先に確認する。
-
コード（ハーネスのみ公開）：https://github.com/meituan-longcat/LongCat-DeepResearch
-
プロジェクトページ：https://meituan-longcat.github.io/LongCat-DeepResearch/