Gemini Advanced の Deep Research を頼んで、画面に「調査中…」と出たまま30分、1時間と動かない経験はないでしょうか。私自身、2014年からアプリ事業を運営している個人開発者として、月に何十回もマーケットリサーチを Deep Research に投げていますが、ある時期から「投げて朝確認したら止まっている」というパターンが急に増えた時期がありました。
このフリーズは一見「サーバが重いだけ」のように見えるのですが、半年ほど観測した結果、原因は実は5種類に分かれていて、リトライで直るのは1種類だけです。残りの4種類は 依頼の出し方を変えないと永遠に同じ場所で止まります。
ここでは、私自身の運用で踏み抜いた5パターンと、それぞれに対する切り抜け方を整理します。
止まる5つの典型パターン
私の手元の集計では、止まるパターンは次のように分かれていました（過去6ヶ月で約140件のフリーズ事例）。
- 検索ステップの並列度が過剰（発生率 約 35%）: リサーチ計画段階で生成された並列検索ステップ数が30件を超えると、後半が完了せずに「調査中」のまま固まりやすくなります
- 特定ドメインへの繰り返しアクセス制限（約 25%）: 同じドメイン（例: 一部の SaaS ドキュメントサイト、一部のニュースサイト）に対する繰り返しアクセスがブロックされ、その時点で進行が止まります
- リサーチ計画が広すぎる（約 20%）: 「○○業界の市場動向と主要プレイヤーと収益モデルと将来予測を網羅的に」のような広すぎる依頼は、計画段階で破綻して途中停止します
- PDF・スプレッドシート添付がきっかけの内部解析タイムアウト（約 12%）: 添付ファイルが大きい（数十MB級）と、参照解析の段階で停止します
- Recitation block が発火している（約 8%）: 著作権保護のある原文の長文引用に判定され、調査結果の生成段階で停止して何も返ってこなくなります
リトライで直るのは1番目だけです。残りは依頼の出し方そのものを変える必要があります。
並列検索ステップの過剰を抑える
最も多いのがこれです。Deep Research は最初に「これからどんな検索をどの順序で実行するか」という計画を立てますが、依頼が広すぎると計画段階で 40〜60 個の並列検索が立つことがあります。経験上、25 ステップを越えると停止確率が急上昇します。
対処は依頼を 複数のリサーチに分割する ことです。具体的には次のような形に書き換えます。
- ❌ 大ざっぱな依頼: 「日本の壁紙アプリ市場の競合状況と収益モデルとユーザー動向と今後の展望を調べて」
- ✅ 分割した依頼: 「日本の壁紙アプリ市場の上位10アプリのダウンロード規模と運営会社を調べて」+ 別途「日本の壁紙アプリ市場の主流の収益モデル3種類とそれぞれの ARPU 水準を調べて」
私のリサーチ業務では、1依頼あたりの計画ステップ数が 20〜25 に収まるように粒度を意識しています。これだけで、止まる事例の3分の1以上が消えました。
繰り返しアクセス制限を回避する
特定ドメインの参照が繰り返されるリサーチでは、進行が突然止まります。観測したパターンとしては、技術ドキュメントサイト（特定 SaaS の公式ドキュメント）や、API リファレンス系のサイトで頻発しました。
対処は2段階です。
- 同じドメインへの参照が必要な場合、リサーチ依頼の中で「このドメインだけを集中的に」と指定するのではなく、「複数の情報源を比較しながら」のように 比較構造の指示 に書き換える
- 止まったリサーチを再依頼するときは、「前回参照したドメインは避け、代替の情報源を探して」と明示する
私の運用では、後者の指示を入れるだけで、再依頼の成功率が体感で 80% を越えるようになりました。
計画が広すぎる時のチェックリスト
3番目の原因は、Deep Research の計画段階の出力を見れば一発でわかります。リサーチ開始時に表示される「計画」を必ず確認し、次のいずれかに該当したら依頼を狭めて出し直すのが安全です。
- 計画の項目数が 8つ以上: 多すぎる。3〜5項目に絞る
- 「網羅的に」「すべての」「全体像」といった言葉が含まれている: 範囲が定義されていない依頼なので破綻しやすい
- 比較対象が4つ以上の比較: 2〜3対象に絞る
私が運営している Lacrima と Mystery のブログ運営で、月次の競合分析を Deep Research に依頼していますが、最初は「主要競合サイト10社の収益・トラフィック・コンテンツ戦略を調べて」のような広い依頼でしたが、停止頻度が高すぎたため「Tier1 競合3社のコンテンツ戦略だけを比較」「Tier2 競合5社のトラフィック規模だけを比較」のように、依頼軸を1つに絞った分割発注に切り替えました。停止頻度はほぼゼロになりました。
添付ファイルが原因のタイムアウト
リサーチに参考資料として PDF やスプレッドシートを添付すると、ファイルサイズによっては内部解析の段階で停止します。経験的には、1ファイル 10MB 以上、または 合計添付サイズ 30MB 以上 で停止確率が上がります。
対処はファイルの前処理です。
- PDF は事前に必要な章だけを抽出して、5〜10MB 以下のスリム版を作る
- スプレッドシートは「分析対象の列だけを残した CSV」に変換して添付する
- 画像 PDF は OCR してテキスト PDF にする（画像のままだと内部解析が極端に遅くなる）
これは Gemini API 経由で Deep Research を使う場合により顕著です。ブラウザ経由の Deep Research は内部解析を多少粘ってくれますが、API 経由は早めにタイムアウトします。
Recitation block が起きている場合の見分け方
5番目は最も判別が難しいパターンです。Recitation block は、Gemini が「特定の長文を逐語引用しそうになる」と検知したときに、応答全体を黙って停止させる安全機構です。Deep Research では、ニュース記事や論文の本文を大量に引用するリサーチ依頼で発火しやすくなります。
見分け方は次の通り。
- 「調査中…」のまま長時間動かないが、エラーメッセージが出ない
- 同じ依頼を 2〜3 回投げても、同じ場所で止まる
- 依頼の中に「○○の発表文を引用しながら」「○○の論文の本文を踏まえて」のような 逐語引用を求める表現 が含まれている
対処は、引用を求める部分を「要約を踏まえて」「主張のポイントを抽出して」のように言い換えることです。私のニュース監視リサーチでは、「該当記事の発表文を引用」を「該当記事の発表文の要点を3行で抽出」に変えただけで、停止する事例がなくなりました。
止まった時の現実的な復旧手順
それでも止まった時のために、5分以内に動かせる復旧手順を共有します。私の運用で実証済みの順序です。
- ブラウザを開き直す（タブを閉じてもう一度開く）— サーバ側のセッションは生きていることが多く、結果が表示されるケースがあります
- それでも進まなければ「中断」して、依頼を分割した形で投げ直す
- 結果が部分的に表示された場合は、その結果をスクリーンショットなどで控え、続きを別依頼として投げる
- 5番目の Recitation 疑いがある場合は、依頼文から逐語引用の表現を外して再依頼
夜中に Deep Research を投げて、朝起きたら止まっていた経験を何度も繰り返した結果、私自身は「広い1依頼を一晩寝かせる」運用をやめて、「狭い3〜5依頼を順番に投げる」運用に切り替えました。完走率が安定して 95% を越えるようになり、結果の質も上がりました。
Deep Research は強力ですが、止まる症状は無音で起きるため気づきにくいのが厄介です。同じ症状に困っている方の参考になれば幸いです。