※本記事は、2025年ニューヨークで開催されたAI Engineer SummitのAgent Engineering Session Dayにおける、Aarush Selvan氏とMukund Sridhar氏による講演「How Deep Research Works」の内容を基に作成されています。講演の詳細情報は https://ai.engineer でご覧いただけます。本記事では、講演の内容を要約しております。なお、本記事の内容は原著作者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの講演動画をご視聴いただくことをお勧めいたします。
登壇者紹介
Aarush Selvan氏 は、GoogleのGemini Appチームでプロダクトマネージャーを務めています。Geminiをパーソナル研究アシスタントとして機能させるGemini Deep Researchを主導しており、Deep Research開始以前は、Gemini、Gmail、Google Maps、YouTubeなどのアプリやサービスをGeminiに接続してより有用な回答を提供するGemini Extensionsプラットフォームを率いていました。機械学習スタックのあらゆる部分の製品に携わった経験を持ち、次世代ASICからコンパイラ、フレームワーク、さらにはGoogle AssistantのSpeech・NLP技術まで幅広く手がけてきました。英国出身でニューヨーク在住（ベイエリアでもよく見かけられます）、スタンフォード大学でSymbolic Systemsの学士号と修士号を取得しています。
Mukund Sridhar氏 は、Google DeepMindでStaff ML SWE / TLM（Tech Lead Manager）として勤務しています。
1. Deep Researchの概要と開発背景
1.1 製品紹介と基本コンセプト
Aarush： Deep Researchについて、まだ試していない方もいらっしゃると思いますが、Gemini Advancedにアクセスしていただければ利用可能です。具体的には、2.0 Flash、2.0 Flash Thinking Experimental、2.0 Flash Thinking Experimental with Apps、2.0 Pro Experimentalを通り過ぎて、1.5 Pro with Deep Researchという項目を見つけていただけます。これが我々が開発した機能です。月額20ドルを支払っていただければ、これはあなたの代わりにウェブをブラウジングして、レポートを作成してくれるパーソナル研究エージェントであることがお分かりいただけるでしょう。
Mukund： 今日お話ししたいのは、なぜ我々がこれを構築したのか、そして製品開発で克服した課題、さらにウェブ研究エージェントを構築する際に直面する技術的な課題についてです。我々の動機は本当にシンプルで、人々が素早く賢くなれるよう支援したいということでした。研究や学習に関するクエリが、Geminiでの主要なユースケースの一つであることを発見したのです。
Aarush： しかし、チャットボット全般に本当に難しい質問を持ち込むと、実際の答えを提供するのではなく、答えの設計図のようなものを提供することが多いということが分かりました。例えば、我々がよく使っていた質問として「陸上投擲で体育奨学金を得るために何が必要で、どうやって取得できるか教えて」というものがありました。よくある回答は「コーチと話すべきです」「どれくらい遠くに投げられるかを調べるべきです」「良い成績を確保するべきです」といったものでした。しかし、私が本当に知りたいのは、具体的な成績の境界値や、実際にどれくらい遠くに投げる必要があるかといった、包括的な情報だったのです。そこに大きな機会があると考えました。
Mukund： そこで我々は考えました。推論時の計算量と応答時間の制約を取り除いて、Geminiが必要な時間をかけ、必要なだけウェブをブラウジングできるようにして、ユーザーにより包括的な回答を提供するトレードオフができないかと。ただし、5分以内で完了する必要があります。それ以上だと、我々にはチップが足りないからです。
1.2 開発動機と既存システムの限界
Aarush： 我々の根本的な動機は「人々が素早く賢くなる」ことを支援することでした。実際にGeminiの使用データを分析してみると、研究や学習に関するクエリが最も多いユースケースの一つであることが明確に分かったのです。しかし、ここで大きな問題が浮上しました。
Mukund： チャットボット全般に対して本当に複雑で難しい質問を投げかけると、実際の答えそのものではなく、答えにたどり着くための設計図や手順のようなものしか返ってこないという現象を我々は発見しました。これは非常に大きな制限でした。
Aarush： 具体的な例として、我々がよく検証に使っていた質問があります。「陸上の砲丸投げで体育奨学金を得るために何が必要で、実際にどうやってそれを取得できるか教えてください」という質問です。従来のチャットボットからの典型的な回答は「コーチと話をするべきです」「どれくらい遠くまで投げられるかを調べるべきです」「良い成績を維持するべきです」といった一般的なアドバイスでした。
Mukund： しかし、質問者が本当に知りたいのはそういった抽象的なアドバイスではありませんでした。具体的な成績の境界値、実際にどれくらいの距離を投げる必要があるのか、どの大学がどの程度の基準を設けているのか、といった詳細で実用的な情報だったのです。
Aarush： まさにそこです。我々が求めていたのは包括的で、実際に行動に移せる具体的な情報でした。「良い成績を取りなさい」ではなく「GPA3.5以上が必要で、SAT1200点以上が一般的な基準です」といった、実際に使える情報です。この大きなギャップを埋めることが、我々にとって重要な機会だと認識したのです。
Mukund： この問題を解決するために、我々は根本的にアプローチを変える必要があると考えました。従来の制約から解放されて、もし推論時の計算量と応答時間の制約を取り除くことができれば、Geminiが必要なだけ時間をかけ、必要なだけウェブをブラウジングして、ユーザーにより包括的で詳細な回答を提供できるのではないかと。ただし、現実的な制約として5分以内で完了させる必要がありました。それ以上の時間をかけると、我々の計算資源では対応できないからです。この時間制限内で、いかに質の高い研究結果を提供できるかが、我々の技術的挑戦となりました。
2. 製品設計における主要課題と解決アプローチ
2.1 非同期体験の実現とユーザー期待管理
Mukund： Deep Researchを開発する上で、我々は数多くの製品課題に直面しました。最も根本的な問題は、Geminiがこれまで本質的に同期的な機能、つまりチャットボットとして設計されていたことです。ユーザーが質問を投げかけると即座に回答が返ってくるという体験が基本でした。
Aarush： しかし、Deep Researchでは5分間という長い処理時間が必要になります。これは従来のGeminiの体験とは全く異なる非同期的な体験です。本質的に同期的な製品の中で、どうやって非同期体験を構築するかという課題に我々は取り組む必要がありました。
Mukund： さらに重要だったのは、ユーザーの期待値を適切に設定することでした。Deep Researchは非常に特定の用途に特化した優秀な機能ですが、Geminiに寄せられるユーザークエリの多くは「今日の天気は？」や「面白いジョークを書いて」といった、5分も待つ価値のない簡単な質問です。
Aarush： まさにその通りです。こうした簡単な質問に対して5分待たせても、良い答えが得られるわけではありません。我々はユーザーに対して、この機能がどういう場面で価値を発揮するのか、どういう場面では適さないのかを明確に伝える必要がありました。期待値の管理は製品設計の核心的な部分だったのです。
Mukund： 非同期体験を実現するために、我々は従来のチャットインターフェースを根本的に再設計する必要がありました。ユーザーが質問を投げかけてから結果が出るまでの5分間をどう過ごしてもらうか、その間にどんな情報を提供するか、そして最終的にどのような形で結果を提示するかという一連の体験設計が求められました。
Aarush： 期待値管理については、単に「この機能は時間がかかります」と警告するだけでは不十分でした。我々は積極的に、どういう種類の複雑な研究クエリがDeep Researchに適しているかをユーザーに理解してもらう必要がありました。投資分析、市場調査、技術動向の分析といった、本当に包括的な調査が必要な場面でこそ、この5分間の投資が価値を生むということを明確に伝える設計が重要でした。
2.2 長文出力への対応とUX設計
Aarush： もう一つの大きな課題は、我々の回答が数千語にも及ぶ非常に長いものになるということでした。これは従来のチャット体験では全く想定されていなかった問題です。ユーザーがこれほど長い出力とどうやって効果的にやり取りするかを考える必要がありました。
Mukund： 通常のチャットインターフェースでは、短い質問に対して比較的短い回答が返されることを前提として設計されています。しかし、Deep Researchでは包括的な研究レポートを生成するため、出力が数千語になることは避けられませんでした。この長文コンテンツをチャット体験の中でどう扱うかは、根本的な設計上の挑戦でした。
Aarush： 長文出力の問題は単に表示の問題だけではありませんでした。ユーザーがその長いレポートを読みながら、さらに追加の質問をしたり、特定のセクションについて詳しく聞いたり、レポートのスタイルを変更したりといった相互作用をどう実現するかという課題もありました。従来のチャット形式では、ユーザーは前の回答を見るためにスクロールして戻る必要があり、これは非常に使いにくい体験になってしまいます。
Mukund： この問題を解決するために、我々は従来のチャット形式から大きく逸脱する必要があることが明らかになりました。長文コンテンツを扱うための専用のインターフェース設計が求められ、これがその後のArtifacts形式の採用につながる重要な設計判断となったのです。ユーザビリティを確保しつつ、豊富な情報を効果的に提示する方法を見つけることが、製品の成功にとって決定的に重要でした。
3. ユーザーインターフェースと体験設計
3.1 研究計画提示から進捗表示まで
Aarush： UX設計について具体的に説明するために、実際の使用例を見てみましょう。あなたがベンチャーキャピタリストで、アメリカでの原子力投資について皆が話している状況を想像してください。そこで「小型原子炉の最新技術ブレークスルーについて学ばせてください。そして、サプライチェーンの興味深い企業も教えてください」というクエリをDeep Researchに投げかけたとします。
Mukund： この質問をDeep Researchに送信すると、最初のステップとして、Geminiが実際にあなたのための研究計画を組み立てて、それをカード形式で提示します。これは我々がユーザーとのコミュニケーションを図る最初の方法です。これは通常のチャットボット体験とは異なることを明確に示し、何かが起こる予定であることを伝えます。
Aarush： 研究計画の提示は単なる通知以上の意味を持っています。これは優秀なアナリストが行うアプローチと同じです。彼らは作業に取りかかる前に、「私はこのような方法でこの問題にアプローチします」ということを示してくれます。そして、これはユーザーが望めば研究の方向性を編集し、関与できる機会でもあります。
Mukund： ユーザーが「スタート」ボタンを押すと、我々は実際にGeminiがバックグラウンドで何をしているかをリアルタイムで表示するようにしました。具体的には、Geminiが現在ブラウジングしているウェブサイトを表示します。この機能は、思考モデル（thinking models）が登場する前に構築されたものですが、思考プロセスもモデルが何を考えているかの透明性を示す優れた方法です。
Aarush： 進捗表示の面白い点は、待機中にユーザーがそれらのウェブサイトをクリックして、実際のコンテンツを詳しく見ることができることです。しかし、我々が予期していなかった現象も観察しました。人々がその数字をゲーム化しようとして、Deep Researchがどれだけ多くのウェブサイトを読むことができるかを確かめようとしていたのです。
Mukund： 実際に、人々がその数字を数千まで押し上げようとする行動を確実に観察しました。これはユーザーがDeep Researchの能力の限界を探ろうとする興味深い行動パターンでした。このような予期しないユーザー行動も、我々の製品設計において重要な学習となったのです。
3.2 結果表示とソース管理システム
Aarush： 最終的に、我々は数千語にも及ぶレポートを得ることになります。この結果表示については、Anthropicが開発したArtifactsという機能に非常にインスパイアされました。これは長文コンテンツをピン留めできる優れた方法だと考えたのです。
Mukund： Artifacts形式を採用することで、ユーザーは研究資料を読みながら、同時にそのレポートについて質問することが可能になりました。前後にスクロールする必要がないため、非常に使いやすい体験となります。これによって、レポートのスタイルを変更したり、セクションを追加・削除したり、フォローアップの質問をしたりすることが簡単にできるようになったのです。
Aarush： 結果表示システムで最も重要な部分は、ユーザーの信頼構築とパブリッシャーに対する適切な配慮です。我々は常に、読み取ったすべてのソースと、実際にレポートで使用したソースの両方を表示するよう心がけています。読み取った情報すべてがレポートに使用されるわけではありませんが、フォローアップの質問のためにコンテキストに残しておきます。
Mukund： ソース管理システムの設計において、我々は透明性を最優先にしました。ユーザーは自分が受け取ったレポートがどのような情報源に基づいているかを完全に把握できます。また、これらの情報はすべて、ユーザーがGoogle Docsにエクスポートする際に引用として引き継がれるなど、学術的・専門的な用途にも対応できるよう設計されています。
Aarush： この包括的なソース表示システムは、単なる技術的要件以上の意味を持っています。これはパブリッシャーに対する敬意を示すものでもあり、ユーザーが情報の信頼性を自ら判断できるようにするものでもあります。我々のシステムがどのような情報源から情報を取得し、どのようにそれらを統合してレポートを作成したかを完全に透明化することで、ユーザーの信頼を獲得し、同時に情報の提供者である各ウェブサイトに対しても適切なクレジットを与えることができるのです。
4. 長時間実行タスクの技術的課題
4.1 システム堅牢性と状態管理
Mukund： 研究エージェントを構築する際に遭遇する課題について、私が今日選んだ4つの主要な課題の中で、まず長時間実行タスクの性質について話したいと思います。数分間にわたって動作し、多数の異なるLLM呼び出しや各種サービスへの呼び出しを行うジョブを考えてみてください。このような環境では、中間的な障害は避けられません。
Aarush： 現在我々は数分の処理時間について話していますが、将来的にはこのような研究エージェントが数時間かかることも容易に想像できます。そうした長期間の処理において、システムの堅牢性は決定的に重要になります。
Mukund： まさにその通りです。様々な信頼性レベルのサービスと連携し、複数の外部API呼び出しを行う中で、どこかで障害が発生することは統計的に確実です。重要なのは、一つの障害によって研究タスク全体を破棄してしまわないよう、中間的な障害に対して堅牢なシステムを構築することです。
Aarush： この問題を解決するために、我々は効果的な状態管理ソリューションの構築に取り組みました。システムがどの段階まで進行したか、どの情報を既に収集したか、次に何をすべきかを常に把握し、障害から効果的に復旧できるメカニズムが必要でした。
Mukund： 状態管理の複雑さは、単純なチェックポイントシステム以上のものです。研究プロセスは本質的に動的で適応的なものです。モデルが新しい情報を発見するたびに、次の行動計画が変更される可能性があります。したがって、静的な実行計画ではなく、動的に進化する研究状態を管理する必要があります。
Aarush： 障害復旧においては、単に以前の状態に戻るだけでは不十分でした。システムは収集済みの情報を評価し、研究の進行状況を理解し、最も効率的な継続方法を決定する必要があります。時には、障害が発生した特定のパスを放棄して、代替的なアプローチを選択することが最適な場合もありました。このような動的な復旧戦略が、長時間実行タスクにおける成功の鍵となったのです。
4.2 クロスプラットフォーム対応
Mukund： 長時間実行タスクが可能になったことで、我々は新しい機能の実現にも取り組むことができました。その一つがクロスプラットフォーム機能の実現です。我々は、ユーザーが研究タスクを登録して、その場を離れるという行動パターンがますます一般的になると確信しています。
Aarush： この使用パターンは非常に自然なものです。5分間の処理時間を考えると、ユーザーは研究タスクを開始してから、コーヒーを取りに行ったり、別の作業をしたり、あるいは全く違うデバイスに移動したりすることが想定されます。この現実的な利用シナリオに対応する必要がありました。
Mukund： そこで重要になるのが、デバイス間での通知システムです。ユーザーがスマートフォンで研究タスクを開始したとしても、完了時にはラップトップで作業している可能性があります。システムはユーザーがどこにいても、研究が完了したことを適切に通知する必要があります。
Aarush： さらに、単に通知するだけでは不十分です。ユーザーは異なるデバイスで研究結果を読み、継続して作業できる必要があります。つまり、研究結果のデータ同期、フォローアップ質問の継続、さらなる研究の依頼など、すべてがシームレスにクロスプラットフォームで動作する必要があります。
Mukund： この機能は、研究エージェントの本質的な価値提案を強化するものでした。ユーザーは自分の時間を最大限に活用できます。研究タスクを開始してから、その処理を待つためにデバイスの前に座っている必要はありません。代わりに、他の生産的な活動を行い、研究が完了したときに最も便利なデバイスで結果を確認できるのです。
Aarush： このクロスプラットフォーム対応により、Deep Researchは単なるリアルタイムツールから、ユーザーのワークフローに自然に組み込まれる非同期的な生産性ツールへと進化しました。これは長時間実行が可能になったことで初めて実現できた、重要な価値向上だったのです。
5. モデルの計画立案と情報処理
5.1 反復的計画とタスク分解戦略
Mukund： モデルがこれらの数分間にわたって実際に何を行っているかについて説明したいと思います。具体例として、陸上の砲丸投げで体育奨学金を獲得するという複雑なクエリを考えてみましょう。このような質問には多くの側面があり、我々が研究計画で示したように多面的なアプローチが必要です。
Aarush： この例では、モデルが最初に行わなければならないのは、これらのサブ問題のうちどれを並列で取り組むことができ、どれが本質的に順次処理が必要かを判断することです。この判断プロセス自体が、モデルの推論能力の重要な部分です。
Mukund： まさにその通りです。モデルはこの判断を行うために推論する必要があります。そして、ここで常に直面する状況は、部分的な情報しか得られない状態です。収集した情報に基づいて次に何をすべきかを決定する前に、これまでに発見したすべての情報を検討することが重要になります。
Aarush： 具体的な例を見てみましょう。この砲丸投げの事例では、モデルがD1部門の資格基準については既に把握していることが分かりました。しかし、ユーザーに完全なレポートを提供し、質問に答えるためには、D2部門とD3部門の同等の基準も調べる必要があることを認識する必要がありました。
Mukund： これが「発見した情報に基づいて次のステップを計画する」という概念の核心です。モデルは静的な実行計画に従うのではなく、収集した情報を評価し、まだ不足している情報を特定し、それらのギャップを埋めるための最適な戦略を動的に決定します。この能力が、効果的な研究エージェントにとって不可欠なのです。
Aarush： 反復的計画のもう一つの重要な側面は、情報の優先順位付けです。モデルは無限にリソースを持っているわけではなく、5分という制限時間内で最も価値の高い情報を取得する必要があります。したがって、どの調査パスが最も重要な洞察をもたらす可能性が高いかを継続的に評価し、リソースの配分を最適化する必要があります。
Mukund： この動的な計画立案プロセスは、従来の静的なワークフローとは根本的に異なります。モデルは新しい発見のたびに全体的な戦略を再評価し、必要に応じて方向転換を行います。これにより、予期しない情報や新しい研究の方向性が現れても、柔軟に対応できるのです。
5.2 部分情報統合と実体解決
Mukund： 部分的な情報の問題について、別の具体例で説明しましょう。子供に適したベストローラーコースターを見つけようとする場合を考えてみてください。検索を行うと、部分的な情報を提供する結果にたどり着くことがよくあります。この例では、トップ10ローラーコースターについて語るリンクにたどり着きますが、それらが子供に適しているかについては何も言及されていません。
Aarush： この状況で、プランナーはこの事実を認識し、次の計画ステップでこの曖昧さを解決しようとする必要があります。単に「トップ10ローラーコースター」のリストを受け入れるのではなく、それらが実際に子供向けなのかという元の質問の核心部分が未解決であることを理解する必要があるのです。
Mukund： 情報統合のもう一つの典型的な課題は、情報が一つの場所に見つからないことです。異なるソース間で情報の断片が散らばっていることがよくあります。例えば、近くのダイビングセンターでのスキューバダイビング認定取得に必要なことを調べる場合を見てみましょう。
Aarush： この例では、一つのソースで認定を受けるために必要なプロセスの構造や手順について情報を得ることができます。しかし、全く別のソースで、そのダイビングセンターの料金体系に関する情報を見つけることになります。モデルはこれらの分散した情報を組み合わせて、そのような認定の全体的なコスト構造がどのようなものかを理解する必要があります。
Mukund： そして、古典的な実体解決問題もあります。異なるソース間で同じエンティティへの言及を見つけることがありますが、それらが実際に同じエンティティについて話しているのか、より多くの探索を行ってそのような関連性を検証する必要があるのかを判断するために、いくつかの情報指標について推論する必要があります。
Aarush： ウェブ上での情報の断片化は、ほとんどの人がウェブ関連の問題に取り組んだことがある人なら知っているように、非常に深刻な問題です。同じトピックについて語る2つの異なるウェブサイトの例を見てみましょう。今年のポルトガルでの音楽フェスティバルについてです。
Mukund： 左側のウェブサイトにたどり着いた場合、レイアウトがより使いやすく、ほとんどの情報を一度に取得できます。しかし、右側では、レイアウトが異なっています。研究タスクでウェブをナビゲートしたい場合、堅牢なブラウジングメカニズムを持つことが重要な課題となります。
Aarush： この問題は単なる技術的な課題以上のものです。同じ情報が全く異なる形式で提示されている場合、モデルは構造の違いを乗り越えて、本質的な情報を抽出し、異なるソースからの断片的な情報を意味のある包括的な回答に統合する能力が必要なのです。これが効果的な情報統合と実体解決の核心的な挑戦となっています。
6. ウェブ環境での動作とコンテキスト管理
6.1 多様なウェブ構造への対応
Mukund： ウェブ環境で動作する際の根本的な課題について話しましょう。ほとんどの人がウェブに関する問題に取り組んだ経験があるなら、ウェブが非常に断片化されていることをご存知でしょう。同じトピックについて語る2つの異なるウェブサイトを見ても、その提示方法は大きく異なります。
Aarush： 具体的な例として、今年のポルトガルでの音楽フェスティバルについて情報を探している状況を考えてみてください。我々が観察したのは、同じ情報でも全く異なる方法で構造化されているということです。左側のウェブサイトでは、そのサイトにたどり着けば比較的簡単で、ほとんどの情報を一度に取得できます。
Mukund： しかし、右側のウェブサイトでは、レイアウトが完全に異なっています。同じ基本的な情報を提供しているにもかかわらず、その情報の組織化、ナビゲーション構造、コンテンツの配置が根本的に違うのです。これが研究タスクでウェブをナビゲートしたい場合の重要な課題となります。
Aarush： この多様性は単なる美的な違いではありません。情報がどこに配置されているか、どのようにカテゴリ化されているか、リンク構造がどうなっているかなど、すべてが異なります。一つのサイトでは主要な情報がトップページに明確に表示されているかもしれませんが、別のサイトでは同じ情報にアクセスするために複数のページをナビゲートする必要があるかもしれません。
Mukund： この問題を解決するためには、堅牢なブラウジングメカニズムが不可欠です。モデルは様々なウェブサイト構造に適応し、情報がどのような形式で提示されていても、本質的なコンテンツを識別して抽出できる必要があります。表形式のデータ、リスト形式の情報、段落形式のテキスト、さらには画像内のテキストなど、多様な形式に対応しなければなりません。
Aarush： さらに、ウェブサイトの品質と信頼性も大きく異なります。一部のサイトは包括的で正確な情報を提供しますが、他のサイトは不完全だったり、古い情報だったり、場合によっては誤解を招く情報を含んでいたりします。効果的な研究エージェントは、これらの質の違いを認識し、より信頼性の高いソースを優先する能力が必要です。
Mukund： ブラウジングメカニズムの堅牢性は、単に技術的な適応性だけでなく、戦略的な判断も含んでいます。どのリンクをたどるべきか、どの情報が最も関連性が高いか、そして限られた時間の中でどのような深さまで各サイトを探索するべきかを決定する必要があります。これらすべての要因が、ウェブの多様性に対応するための包括的なアプローチを必要とするのです。
6.2 長期コンテキスト管理戦略
Mukund： 先ほど見たように、多くの中間出力が存在し、計画中に情報のストリームを取得するにつれて、コンテキストサイズが非常に迅速に増大することが想像できます。これは研究プロセスにおける基本的な課題の一つです。
Aarush： コンテキストサイズに関するもう一つの課題は、研究タスクが通常最初のクエリで終わらないことです。ユーザーはフォローアップの質問をします。「同じことを別のトピックについても行ってください」といった追加の要求が来ることがあります。このようなフォローアップのDeep Research要求も、コンテキストに圧力をかける要因となります。
Mukund： 幸い、我々GeminiではCoexist 장기간のコンテキストモデルを利用できる恵まれた立場にあります。しかし、それでも効果的にコンテキストを管理する方法を設計する必要があります。ここには複数の選択肢があり、それぞれ様々なトレードオフを伴います。
Aarush： 我々が実装した手法の一つをここで紹介します。これは一種の近接性バイアスを持つシステムです。現在のタスクと直前のタスクについては、はるかに多くの情報を保持します。しかし、古いタスクについては、我々が「研究ノート」と呼ぶものを選択的に抽出し、それをRAG（Retrieval Augmented Generation）システムに配置します。
Mukund： この選択的保持システムでは、モデルは依然として古い研究の情報にアクセスできますが、より選択的な方法でアクセスします。すべての詳細な情報を永続的にコンテキストに保持するのではなく、最も重要な洞察、発見、結論を抽出して、必要に応じてアクセスできる形で保存します。
Aarush： この戦略により、長期間にわたる研究セッションでも効果的な性能を維持できます。ユーザーが複数の関連する研究タスクを連続して実行する場合、以前の研究からの重要な情報は利用可能な状態を保ちながら、新しいタスクのためのコンテキスト容量も確保できます。
Mukund： コンテキスト管理における重要な考慮事項は、どの情報を保持し、どの情報を圧縮または除外するかを決定することです。我々のシステムは、情報の関連性、重要度、および将来のクエリでの利用可能性を評価して、この決定を動的に行います。これにより、長時間の研究セッションでも一貫した品質を維持できるのです。
Aarush： 最終的に、このコンテキスト管理戦略は、ユーザーが自然な会話フローで複数の研究トピックを探索できるようにしながら、システムの応答性と正確性を保つことを可能にします。これは長期的なユーザーエンゲージメントにとって決定的に重要な機能となっています。
7. 市場反応と今後の発展方向
7.1 リリース後の反響と性能評価
Aarush： 12月にこの機能をリリースした時、我々は非常に興奮していました。同時に、実際に誰かがこれを使うのか、5分も待つことを気にかけてくれる人がいるのかについて、全く確信が持てませんでした。これは我々にとって大きな賭けだったのです。
Mukund： 正直なところ、ユーザーが長い待機時間を受け入れてくれるかどうかについて、我々は非常に不安でした。従来のチャットボット体験では即座の応答が期待されていましたから、5分間という待機時間が市場に受け入れられるかは未知数でした。
Aarush： しかし、実際の反響は我々の予想を大きく上回る好意的なものでした。ユーザーは単に5分待つことを受け入れただけでなく、その待機時間に見合う価値を実感してくれたのです。これは我々にとって非常に嬉しい驚きでした。
Mukund： 我々が構築したものの性能について評価してみると、マッキンゼーのアナリストレベルと同等のものを月額20ドルで提供していると考えています。これは非常に重要な価値提案だと思います。高品質な戦略コンサルティングや市場調査の能力を、従来とは比較にならないほど低コストでアクセス可能にしたのです。
Aarush： ただし、現在のシステムには制限もあります。現状では、オープンウェブから情報を取得するテキストイン・テキストアウトのシステムです。しかし、この基本的な機能でも、ユーザーが非常に価値を感じてくれることが証明されました。
Mukund： マッキンゼーアナリストレベルという評価は、情報の収集、統合、そして一定レベルの分析能力を指しています。我々のシステムは、複数のソースから情報を体系的に収集し、それらを意味のある形で統合して、包括的なレポートを生成する能力を実証しました。
Aarush： ユーザーからのフィードバックを見ると、多くの人々が実際に重要なビジネス上の決定や学術的な研究にこの機能を活用していることが分かりました。投資判断、市場参入戦略の検討、競合分析など、従来であれば専門コンサルタントに依頼していたような複雑な調査タスクに使用されているのです。
Mukund： この成功は、市場に本当にこのような包括的な研究能力への需要があったことを証明しています。人々は表面的な情報ではなく、深い洞察と包括的な分析を求めていたのです。そして、そのためには5分間の投資は十分に価値があると判断してくれたということです。これが我々の今後の開発方向性に大きな自信を与えてくれました。
7.2 専門性向上とパーソナライゼーション
Aarush： 我々が現在マッキンゼーアナリスト程度の能力を構築したということは素晴らしいことですが、研究エージェントが向かうべき方向性はいくつか見えています。最初の方向性は専門性の向上です。マッキンゼーアナリストからマッキンゼーパートナー、ゴールドマン・サックスのパートナー、あるいは法律事務所のパートナーレベルまで、どうやって向上させるかということです。
Mukund： この専門性の向上は、単に情報を集約して統合するだけではありません。「それで何なのか」という含意について考え抜く能力、つまり我々が何をしようとしているのかにとっての意味合いは何か、そしてそこから出てくる最も興味深い洞察やパターンは何かということです。
Aarush： もう一つの分野は、プロフェッショナルサービス以外の領域、例えば科学分野です。多くの論文を読み、仮説を形成し、どのような手法が使用されているかの興味深いパターンを見つけ、探求すべき新たな仮説を考え出すことができるシステムを想像してみてください。これは研究の質を根本的に変える可能性があります。
Mukund： しかし、本当に賢いものを構築できたとしても、それが誰かにとって有用でなければ意味がありません。例えば、企業のデューデリジェンスを実行するユースケースを考えてみると、その情報を私に提示する方法と、ゴールドマン・サックスの銀行家に提示する方法は大きく異なるべきです。
Aarush： まさにその通りです。私の場合、その会社が何で、どのように戦略的に位置づけられているかについて話してもらいたいのです。しかし、銀行家は財務情報のすべて、実際に検討できるDCF（割引キャッシュフロー分析）、より細かな財務モデリングと分析を求めるでしょう。
Mukund： そして、これがウェブをブラウジングする方法、答えをフレーミングする方法、追求する質問の種類を形作るべきです。これらすべては、ユーザーがいる場所でユーザーに会うということに非常にパーソナライズされるべきです。
Aarush： パーソナライゼーションは表面的なカスタマイゼーション以上のものです。ユーザーの専門分野、経験レベル、意思決定の文脈を理解し、それに応じて研究戦略全体を調整することです。投資家向けのレポートでは財務指標とリスク評価に重点を置き、技術者向けのレポートでは実装の詳細と技術的実現可能性に焦点を当てるということです。
Mukund： この高度なパーソナライゼーションにより、同じ基本的な研究質問でも、ユーザーの背景と ニーズに基づいて全く異なるアプローチと出力を生成できるようになります。これは単に情報を収集するだけでなく、その情報をユーザーの特定の状況と目標に最適化された形で提示することを意味します。これが次世代の研究エージェントが目指すべき方向性なのです。
7.3 マルチモーダル統合への展望
Mukund： 最後の部分は、モデルが実行できることの領域全体にわたるものです。テキストでのウェブ研究だけでなく、コーディング、データサイエンス、さらには動画生成といった能力と組み合わせることができるかということです。
Aarush： デューデリジェンスの例に戻ってみましょう。もしシステムが大量の統計分析を実行し、実際に財務モデルを構築して、それが提供する研究出力に情報を与えることができたらどうでしょうか。「なぜこの会社は良い会社なのか、そうでないのか」ということを教えてくれるようなシステムです。もちろん、Googleは財務アドバイスを提供するわけではありませんし、財務アドバイザーでもありません。
Mukund： しかし、この概念は非常に強力です。現在のシステムは主にテキストベースの情報収集と統合に限定されていますが、将来的には研究プロセス中に動的にデータ分析を実行し、カスタム可視化を作成し、さらには複雑な計算モデルを構築できるようになる可能性があります。
Aarush： 想像してみてください。市場調査を行っている際に、システムが関連するデータセットを特定し、そのデータに対して統計分析を実行し、トレンドを可視化し、さらに予測モデルを構築して将来の市場動向を予測することができるとしたら。これは単なる情報収集から、実際の知見生成への飛躍です。
Mukund： コーディング能力の統合も重要な側面です。研究中に特定のツールやスクリプトが必要になった場合、システムがリアルタイムでそれらを作成し、データ処理や分析に活用できるようになります。これにより、研究の深度と精度が大幅に向上する可能性があります。
Aarush： 動画生成機能も興味深い展望です。複雑な概念やプロセスを説明する際に、テキストレポートだけでなく、視覚的な説明動画やインフォグラフィックスを生成できれば、情報の理解と活用がはるかに容易になるでしょう。
Mukund： これらすべての機能が統合されることで、研究エージェントは単なる情報収集ツールから、包括的な分析・意思決定支援システムへと進化します。ユーザーは質問を投げかけるだけで、データ収集、分析、可視化、モデリング、そして実行可能な推奨事項まで含む完全なソリューションを受け取ることができるのです。
Aarush： これが我々が見ている将来の可能性です。そして、我々は研究エージェントをより良くするための大きな改善余地があると考えています。ちなみに、この機能を「Gemini Deep Dive」と呼ばなくて本当に良かったです。それが我々のローンチ前の最有力候補名でした。
Mukund： 確かに「Deep Research」の方がはるかに適切な名前でした。これは我々の将来への期待と、この技術分野での継続的な革新の可能性を表しています。