見出し画像

お問い合わせ後のディープリサーチからアクションプランを自動化｜Gemini Deep Research MAX Agent

岩崎修

BtoBの会社ではウェブサイトの問い合わせフォームから連絡が届くと、営業担当はこの会社について調べるところから始めます。会社概要、事業内容、想定される課題。これを1件ずつ調べてから返信を書き、ヒアリングをするという工程があります。

今回はその調べる工程を自動化してみました。
問い合わせがSlackに届いた瞬間、自動的にディープリサーチを開始して、Googleドキュメントに保存し、提案の方向性を自動で整理して、Slackに結果とURLを自動で投稿します。営業担当は、届いたリサーチ結果を読んで、アポイントを取ります。

今回のテーマはAI界隈でもあまり語られていない「Gemini Deep Research Max Agent」という自律型リサーチエージェントを使った実例です。

Gemini Deep Research Max Agentとは

Gemini Deep Research Max Agentは2026年4月にプレビュー版が公開された、Gemini APIで使える自律型のリサーチエージェントです。Geminiのサブスクで使えるディープリサーチは、チャット画面からリサーチを開始しますが、APIを使うことで自動化が可能になります。

通常のディープリサーチとの違い

インターネットからのディープリサーチだけでなく、社内のプライベートデータや、Factset や S&P Global などの金融データとのパートナー連携が可能で、グラフやインフォグラフィックも合わせて結果として返してくれます。
ベンチマーク上も、通常版のディープリサーチと比べて精度やファクトチェック能力も大幅に向上しています。

  • ウェブリサーチ精度（DeepSearchQA）
    Deep Research通常版は81.8%に対し、Deep Research Maxは93.3%と大幅に向上。

  • ファクトチェック能力（BrowseComp）
    Deep Research通常版は61.9%に対し、Deep Research Maxは85.9%と大幅に向上しています。

APIコスト

処理時間は最大60分ですがほとんどのタスクは20分以内に完了します。1回の実行コストはプレビュー価格のため変更される可能性がありますが、通常版が1〜3ドルで80件の検索クエリ・入力25万トークン・出力6万トークン、Max版が3〜7ドルで160件の検索クエリ・入力90万トークン・出力8万トークンです。

Gemini Deep Research Max Agentの実例

お問い合わせの内容を元に裏側で自動ディープリサーチし、Googleドキュメント出力とSlack通知を自動化する仕組みを実装してみました。ワークフローの流れは以下の通りです。

  1. Webサイトの問い合わせフォームから送信

  2. HubSpotがCRMに登録し、Slackに通知を投稿

  3. Slackの投稿を自動検知 （または担当者が絵文字リアクションで手動実行）

  4. Gemini Deep Research Max Agent が企業リサーチ（数分〜数十分）

  5. Gemini 3.6 Flash が提案の方向性と初動アクションを整理

  6. 調査結果をGoogleドキュメントに保存

  7. Slackの同じスレッドに、提案メモとGoogleドキュメントのURLを投稿

すべて自動です。営業担当が触るのは、届いたリサーチ結果とアクションプラン読み、アポイントを取るだけになります。

自動検知に加えて、絵文字リアクションでの手動実行も用意しました。担当者が改めて確認したい問い合わせに絵文字リアクションを付けるだけで、同じ処理をその場で再実行できます。

Cloud Tasksのキュー設計

Slack Appからの実行は3秒以内に応答することを求めます。一方でGemini Deep Research APIは、複数のWebページを横断しながら調査する都合上、完了まで数分から数十分かかります。

Slackからの通知を受け取ったら、即座に応答だけを返し、実際の調査処理は Cloud Tasks 側に別のキューを渡して切り離します。キュー側は時間の制約を受けずに処理を進め、完了したタイミングでSlackのスレッドに返信します。

ディープリサーチと提案内容の整理を2段階で分ける設計

Gemini APIの呼び出しは、1回にまとめず2段階に分けました。
1段階目はGemini Deep Research Max Previewによるディープリサーチです。問い合わせ企業の会社概要・事業内容・想定される課題を、複数の情報源を調べたうえで整理します。ここでのルールは、事実と仮説を厳密に分けることです。裏付けの取れた情報だけを事実として書かせ、それ以外は不明と明記させます。

2段階目はGemini 3.6 Flashによる推論です。1段階目の調査結果をコンテキストとして受け取り、提案できる自社のプライベートデータを元に、営業担当が今日中に取るべきアクションを整理します。

分けた理由は役割の違いです。1段階目は事実を集める役割、2段階目は自社の提案に変換する役割。1つのプロンプトに両方を詰め込むより、役割ごとに分けたほうが、それぞれの精度が上がります。

リサーチプロンプト・提案プロンプト

実際に使っているプロンプトを、自社名と提供サービスの部分だけ汎用化して掲載します。{}で囲んだ部分は、Slackに届いた問い合わせ内容から自動で埋め込まれる値です。コピペして自社名と提供領域を書き換えるだけで、そのまま営業支援リサーチとして使えます。

ディープリサーチのプロンプト

あなたは株式会社◯◯の営業支援リサーチアシスタントです。

目的：
問い合わせ企業について、営業担当が初回対応前に把握すべき情報を整理してください。

重要ルール：
- 事実と仮説を厳密に分けること
- 確認できない内容を断定しないこと
- 不明な情報は「不明」と書くこと
- 冗長にせず、営業担当がすぐ読める簡潔な日本語で書くこと
- 問い合わせ内容との関係が薄い一般論は書かないこと
- 出力は必ず指定フォーマットに従うこと
- 確認できない内容は推測で補完せず、「不明」または「仮説」と明記すること
- 出力フォーマットで指定した見出しと「-」の箇条書き以外の記号は付けないこと

入力情報：
- お問い合わせ概要：{カテゴリ}
- 想定予算：{予算感}
- 希望時期：{希望時期}
- 会社名：{会社名}
- 会社URL / ドメイン：{URL}
- 担当者名：{担当者名}
- メール：{メールアドレス}
- 電話番号：{電話番号}
- お問い合わせ詳細：{問い合わせ本文}

出力形式：
【企業調査サマリー】
- 会社概要：
- 提供サービス / 事業内容：
- 想定顧客：
- 問い合わせ内容との接点：
- 明確に確認できた事実：
- 不明点：

【課題仮説】
- 仮説1：
- 仮説2：
- 仮説3：

【補足】
- 初回対応時に注意すべき点：
- 追加で確認したい点：

アクション内容のプロンプト

あなたは株式会社◯◯の営業戦略アシスタントです。

目的：
問い合わせ内容と企業調査情報をもとに、自社として提案できる内容と、
営業担当が次に取るべきアクションを整理してください。

重要ルール：
- 提案は自社の提供領域に必ず結びつけること
- 事実と仮説を混同しないこと
- 推測が含まれる場合は「仮説」と明記すること
- 営業担当が今日中に動ける粒度で書くこと
- 一般的すぎる営業論ではなく、この問い合わせに即した内容にすること
- 出力は必ず指定フォーマットに従うこと
- 確認できない内容は推測で補完せず、「不明」または「仮説」と明記すること

自社の提供領域：
- （自社が提供する事業領域を箇条書きで列挙する）

入力情報：
- 企業調査サマリー：{1段階目の出力結果}

出力形式：
【自社が提案できること】
- 優先提案1：
- 優先提案2：
- 優先提案3：

【営業担当が取るべき次のアクション】
- 優先度：
- 最初にやること：
- 初回連絡で伝えるべきこと：
- 初回連絡で確認すべきこと：
- 次回商談につなげる論点：

【営業メモ】
- 刺さりそうな切り口：
- 懸念点：
- 仮説として扱うべき点：

その他技術的な工夫

Gemini Deep Research Agent以外にも、Slack App、Cloud Tasks、Cloud Runの組み合わせ方に実装上のポイントがあります。

Gemini Deep Research Agent

通常のGemini API 呼び出しとは別の Interactions API という仕組みを使います。公式ドキュメントに沿って書くと、Node.jsでは次の形になります。

Deep Researchは「引用付きレポートを作る」ことを前提に動くエージェントです。プロンプトの出力フォーマットとは別に、`[cite: 12]`のような引用番号や参考文献リストを添えてくる場合があるため、自社の決まったフォーマットで出力したい場合は、プロンプトに指定した記号だけを使うよう明記したうえで、念のため後処理で取り除く仕組みも用意しておくと安定します。

import { GoogleGenAI } from "@google/genai";

const ai = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY });

// 1. リサーチを開始する（background: trueが必須）
const interaction = await ai.interactions.create({
  agent: "deep-research-max-preview-04-2026",
  input: prompt,
  background: true,
});

// 2. 完了するまでポーリングする
let result = interaction;
while (result.status === "in_progress" || result.status === "queued") {
  await new Promise((r) => setTimeout(r, 25000));
  result = await ai.interactions.get(result.id);
}

const reportText = result.output_text;

Slack App （Bolt）

自動検知と手動リアクションは、どちらも同じSlackアプリの中でBoltフレームワークのイベントとして受け取ります。messageイベントで自動検知、reaction_addedイベントで手動実行という2つのリスナーを用意し、どちらも同じ後続処理に合流させています。Boltは自分自身の投稿へのイベントを自動的に無視してくれるので、返信が返信を呼ぶような無限ループを避けられます。

出力の見た目にも工夫が要りました。Deep Researchの出力は標準的なMarkdownですが、Slackの書式には見出しがなく、太字・斜体・取り消し線・コード・ブロック引用・コードブロック・リンクは指定のマークアップに合わせて変換しています。

// Geminiの出力は標準Markdown（### 見出し、**太字**）だが、
// Slackのmrkdwnは#見出し非対応・太字は単一アスタリスクのため変換する。

function markdownToSlackMrkdwn(text: string): string {
  return text
    .replace(/^#{1,6}\s*(.+)$/gm, '*$1*')
    // 行頭の "* **ラベル**" は箇条書き記号を落として太字のみにする
    // （**→*にそのまま変換すると行頭で*が連続しSlackの太字パースが崩れるため）
    .replace(/^([ \t]*)[*-]\s+\*\*(.+?)\*\*/gm, '$1*$2*')
    .replace(/\*\*(.+?)\*\*/g, '*$1*')
    // Slackの太字は閉じアスタリスク直後に句読点が続くと認識されないことがある
    // （例: "*概要*：" は崩れるが "*概要：*" なら崩れない）ため、句読点を内側に入れる
    .replace(/\*([^*\n]+?)\*([：:、，,。])/g, '*$1$2*');
}

Cloud Tasks

Slackからの通知を受け取った直後に実際の処理をキューに積み、OIDCトークン付きのHTTPリクエストとして自分自身のCloud Runサービスに呼び戻す形にしています。タスク作成時には`dispatchDeadline`（Cloud Tasksが応答を待つ上限、最大30分）を、Deep Researchの処理時間に合わせて長めに設定しました。Cloud Tasks用のクライアントは初回呼び出し時の接続確立に時間がかかることがあったため、サーバー起動時に一度接続を温めておく処理も入れています。

Cloud Run

Cloud Tasksから呼び戻された後続処理は、レスポンスを返す前にDeep Researchの完了を待つ実装にしています。Cloud RunはHTTPレスポンスを返したあとCPUの割り当てを絞る仕様のため、その後も処理を続けるにはレスポンスを遅らせる必要があるためです。あわせて、Cloud Runのリクエストタイムアウトも、Deep Researchの最大処理時間に合わせて30分に設定しています。

問い合わせ対応に限らず、情報を集める、その情報をもとに考えるという2つの工程が分かれている業務は、同じ形で自動化できます。集める役割と考える役割を1つのプロンプトに詰め込まず、別々に任せる。この分け方が、精度を保ったまま自動化を広げるコツだと感じています。

本記事は所属する法人とは一切関係ない個人利用のブログです。文章や画像等のメディアは生成AIで作成していますが、掲載前に筆者が事前に事実関係を確認し、編集を行っています。筆者：岩崎修 https://note.com/_osamu_iwasaki_

いいなと思ったら応援しよう！