Google Deep Research Max は MCP とネイティブ ビジュアルを追加: リサーチ エージェントは再利用可能なビルダー パイプラインになりつつあります
Google の 4 月 21 日の Deep Research アップデートは、チャットボット機能としてよりも、エージェント システムの動きとして重要です。 Gemini Deep Research と Deep Research Max は、オープン Web とプライベート データを組み合わせ、インラインでチャートを生成し、チェーン内の次のモデルにフィードするバックグラウンド リサーチ ジョブとして実行できるようになりました。
Googleが実際に出荷したもの
Googleによると、新しいエージェントはGemini 3.1 Pro上に構築されており、Web検索、リモートMCPサーバー、アップロードされたファイル、接続されたファイルストア、URLコンテキスト、コード実行、ファイル検索を組み合わせた調査ワークフローをサポートするようになったという。同社は製品を 2 つのモードに分割しました。1 つは低遅延、低コストのインタラクティブ エクスペリエンスを実現する標準の Deep Research で、もう 1 つはより多くのテスト時間のコンピューティングを使用する、より包括的なバックグラウンド実行を実現する Deep Research Max です。
公式発表は、対象となるワークフローについて異例に明示的です。 Google の例は消費者向けのチャット クエリではありません。これは、アナリスト チームが起床する前にデュー デリジェンス レポートを生成する毎晩の cron ジョブです。これは、リサーチ エージェントが単なる回答エンジンではなく、下流の作業のインフラストラクチャとして位置付けられていることを示す強い兆候です。
建築業者にとってこれが重要な理由
ここには 3 つの重要な変化があります。まず、Google は研究を再利用可能なパイプライン段階に変えています。チームはディープ リサーチを実行して証拠を収集および合成し、インタラクション API を使用してその状態を別の Gemini モデルに渡すことができます。 previous_interaction_id 要約、再フォーマット、または次のステップの実行に使用します。 2 番目に、Google はエージェントがウェブとカスタム データ ソース全体で動作できるようにすることで、パブリック コンテキストとプライベート コンテキストの間のギャップを減らしています。第三に、チャートとインフォグラフィックスは、別個の視覚化ステップではなく、同じ実行の一部になりました。
ビルダーにとって、これは「詳細な調査」がプレミアム UI 機能ではなくなり、バックエンド ジョブ クラスのように見えるようになるということを意味します。製品チームは、調査概要、販売準備、コンプライアンス ワークフロー、市場調査、技術調査にこれを添付できます。うまく機能すれば、検索、メモ、スプレッドシート出力、エグゼクティブサマリーを手動でつなぎ合わせるのに費やす時間が短縮されます。
重要な注意点: ドキュメントはまだ開発中です
Google 独自のサーフェスには有用な警告が隠されています。ブログ投稿では、Deep Research が任意のリモート MCP と複合ツールをサポートするようになったと述べていますが、公開されている Interactions API ドキュメント ページには依然として 4 月 15 日のプレビュー時代の注意事項と古いモデル ID が表示されています。この不一致は、その打ち上げが偽物であることを意味するものではありません。これは、製品の表面が安定したドキュメントよりも速く動いていることを意味します。
まさにそこからトークンの無駄とチームの混乱が始まります。発表コピーから直接構築すると、現在安定しているものを過大評価する危険があります。立ち上げを無視すると、実際のワークフローの変化を見逃してしまいます。実際的なルールは、リサーチ エージェントを他のプレビュー ランタイムと同じように扱うことです。つまり、テストした正確なエージェントまたはモデル ID を固定し、どのツールの組み合わせが実際に機能したかを記録し、ベータ サーフェスが変更されたときのフォールバック パスを保持します。
これは、TRH が推進しているのと同じ運用規律です。 Google AI Studio の割り当ての現実 そして OpenAI Agent SDK ランタイム設計。ワークフローの圧縮は、ランタイムが読みやすい状態を維持する場合にのみ価値があります。
TRH の角度: 研究パイプラインにも予算が必要
Token Robin Hood 読者は、ベンチマーク チャートだけでなく、請求形態にも注意を払う必要があります。 Deep Research Max は深度に合わせて最適化されており、通常、実行時間が長くなり、ツールの使用量が増え、コンテキストが蓄積され、出力アーティファクトが大きくなります。レポートが再利用可能である場合、または収益に結びついている場合には、それだけの価値があります。スタックの残りの部分が使用できる形式で結果を保存する人がいないため、レポートがタブ内で表示されなくなったり、最初から再生成されたりすると、無駄になります。
正しいパターンはシンプルです。仕事を縛りました。許可されるデータ ソースを定義します。出力を再利用可能な形式で保存します。実際に発生する必要がある次のモデル ステップのみをチェーンします。レポートを一度だけ流し読みするだけの場合、Deep Research Max はおそらく間違ったデフォルトです。それがコーディング エージェント、営業ワークフロー、または運用メモのブリーフィング層になれば、その支出は正当化される可能性があります。
建築業者が次にすべきこと
瞬時の遅延よりもリサーチの品質が重要となる 1 つのバックグラウンド ワークフローから始めます。競合モニタリング、デュー デリジェンス、ポリシー追跡、バグ フォレンジック、パートナーの準備などです。 1 つの反復可能なタスクについて、通常の Deep Research と Max を比較します。問題全体を再説明することなく、合計実行時間、出力の有用性、および結果を 2 番目のモデルに渡すことができる頻度を測定します。次に、高価なバージョンが本番環境に属するか、それとも人間の門の向こう側にのみ属するかを決定します。
スタックがすでにエージェントを使用している場合は、もう 1 つのルールを追加します。調査結果は行き止まりではなく入力になる必要があります。それらを永続化し、バージョン化し、ダウンストリームのハンドオフを明示的に保ちます。