問い合わせから見積まで：ADKで営業の準備作業をつなぐ

この記事でわかること

抽出・照会・計算・確認を順序でつなぐ。

未回答の納期や値引きを確定にしない。

承認を準備票の版と対象へ結び付ける。

問い合わせのメールを読んで、過去の案件を探し、商品表を開き、担当者に納期を聞く。見積を作る前に、営業担当者は何度も画面を切り替えています。忙しい日に後回しになるのは、お客様への関心が薄いからではなく、必要な情報が一か所に揃っていないからかもしれません。

この準備を小さくつなぐのが、GoogleのAgent Development Kit、ADKを使う一つの方法です。今回は、問い合わせの内容を整理し、社内情報を照会して、担当者が確認できる見積準備票を作る設計を考えます。完成した見積の発行やメール送信まで任せる前に、営業が判断しやすい材料を揃えるところから始めます。

本稿の技術情報と公開事例は2026年10月14日時点で確認したものです。以下の中小企業、金額、件数は説明用の仮想例であり、KONDAXや顧客企業の導入実績・成果ではありません。

最初の到達点は「AIが見積を送った」ではなく、「担当者が根拠を追える見積準備票を受け取った」です。

営業の仕事を、情報整理と約束する判断に分ける

問い合わせには、要望と事実と曖昧な表現が混ざっています。「前と同じものを急ぎで」「予算は去年くらい」「来月までにお願いしたい」といった言葉を、商品番号、数量、希望日、確認事項にほどく作業はAIに手伝わせやすい部分です。一方で、どの単価を使うか、値引きを認めるか、納期を約束できるかは、文章が自然だからといって確定できません。

そこで、AIは読み取りと説明を担当し、価格や値引きの判定は通常のコードと既存の業務ルールで固定します。担当者が決める条件は承認待ちにします。既存の見積システムが価格の正本なら、AIに別の価格表を覚えさせず、そのシステムから案件ごとに取得します。

• 作業: メールから要望を整理

  主な担当: AI

  確認できる出力: 原文と対応する項目、未確認事項

• 作業: 商品・顧客・価格を照会

  主な担当: 権限を絞ったツール

  確認できる出力: ID、値、取得時刻、資料の版

• 作業: 単価・値引き・承認条件を判定

  主な担当: 通常のコード

  確認できる出力: 適用した規則と判定理由

• 作業: 提案範囲・納期・対外文書を決定

  主な担当: 営業担当者

  確認できる出力: 承認済みの内容と対象の版

この分け方なら、AIの抽出を改善しても値引き権限は変わりません。また、文章の解釈が誤っていた場合も、どの項目から直せばよいかがわかります。見積の前後にある仕事を一度に自動化するより、責任の境界を明確にするほうが、現場の人が試しやすくなります。

公開事例から学べるのは、判断に使う材料のつなぎ方

Googleの2025年4月9日の発表では、Renault GroupがADKで地理・用途地域・交通データをつなぎ、EV充電器の投資分析を支援したと説明しています。営業見積の導入例ではなく、展開範囲や時間削減率も同資料では示されていません。Google Cloud公式発表

中小企業の見積準備に応用するなら、「複数の情報源をつなぎ、判断する人に根拠を渡す」という構造が参考になります。ここから先の受付票や承認フローは本稿の設計提案です。公開事例に登場する企業が同じ見積フローを使っているという意味ではありません。

最初の対象は、一種類の問い合わせに絞る

連載の仮想企業「ケース企業A」を考えます。社員35人の法人向け設備・部品販売会社で、今回は営業担当者を3人と仮定します。既存顧客から届く交換部品の問い合わせを最初の対象にします。新規取引、特注品、施工条件の調査が必要な案件は対象外とし、受付票を作って担当者に渡します。会社が小さいほど、一人の担当者に知識が集中しやすいため、対象を絞ることは無理な置き換えを避ける助けにもなります。

対象を決める際は、件数だけでなく、使う資料が揃っているかを確認します。商品番号のない古い価格表しかない場合、AIを導入しても照会結果は安定しません。よく使う商品の台帳、価格の有効期間、取引先ID、納期の問い合わせ先を整理する作業を、導入準備に含めます。

さらに、完了の定義を先に決めます。今回は「既存顧客の部品交換依頼について、必要項目と根拠を揃え、担当者が見積作成に進める状態にする」を完了とします。問い合わせを受けてから返信案ができるまでの速さだけでは、数量が違う、古い単価を使う、納期を過剰に約束するといった問題を見逃します。

メールを自動取得できない場合も始められる

最初は担当者が対象メールを選び、社内画面に貼り付ける方法でも構いません。誰のメールを読むか、どの添付を扱うかが曖昧なまま、共有受信箱の全件取得を始める必要はありません。入力する人、利用できる顧客、保存先を決めて、数件の練習案件で受付票の使いやすさを確かめます。

作る前に、情報の受け渡しを一枚にする

システム担当者へ「見積を自動化したい」と伝えるだけでは、価格表の管理者も、未回答の納期を誰が調べるかも決まりません。業務の受け渡しシートを使い、供給者、入力、工程、出力、受け手を揃えます。ここでは難しい図を作る必要はなく、一つの問い合わせを実際に辿って表を埋めます。

• 情報を出す人: お客様・受付担当

  入力: 元メール、添付、受付番号

  整理する仕事: 要望と不足を整理

  渡すもの: 原文付きの受付票

  受け取る人: 営業担当

• 情報を出す人: 商品・価格の管理者

  入力: 有効な台帳、適用条件

  整理する仕事: IDと版を照会

  渡すもの: 根拠付きの価格・仕様

  受け取る人: 計算処理、営業担当

• 情報を出す人: 在庫・作業の担当

  入力: 引当情報、作業枠の回答

  整理する仕事: 希望日との関係を確認

  渡すもの: 確認済みの条件、未回答項目

  受け取る人: 営業担当

• 情報を出す人: 営業担当・承認者

  入力: 準備票、値引き申請

  整理する仕事: 条件を確認して承認

  渡すもの: 発行可能な内容と版

  受け取る人: 見積発行担当

この表は、本稿の会社を想定した作業票です。表の各行に「更新を担当する人」「回答が得られないときの連絡先」「どこまで待てるか」を追記します。価格の管理者が変更を登録しても、見積担当に有効日が伝わらないなら、AI導入前から受け渡しに問題があります。先に通知や照会の方法を整えることで、自動化が引き継ぐ不具合を減らせます。

お客様の質問が一件のメールに収まるとも限りません。電話で条件が変わる場合は担当者が受付票を更新し、何を聞いて何が変わったかを残します。メールだけを読んだAIが、電話で合意した内容を知っていると期待しないことが大切です。案件に紐づく記録を正本に集めると、担当者が交代したときにも続きを理解できます。

受付から準備票までを六つの手順でつなぐ

ADKはグラフワークフローを提供しています。ADK公式グラフ説明

本稿の設計では、読み取り、照会、計算、確認を決めた順序で進めます。順序を固定しても、AIが読み違えた数量や商品は別に検証する必要があります。ここでは特定のSDK版の実装コードを示さず、業務の流れを説明します。

1. 受付番号を付ける。 元メールと添付を対象案件に結び、受信時刻と担当者を記録します。同じメールをもう一度取り込んだ場合も、別の見積を無意識に作らないよう、重複候補として示します。
2. 事実と希望を抽出する。 顧客名、商品候補、数量、希望日、設置条件を整理します。書かれていない項目は空欄にし、原文の場所を付けます。「急ぎ」を勝手に具体的な納品日に変換しません。
3. 正本を照会する。 顧客台帳、商品台帳、有効な価格表を読みます。似た会社名が複数ある場合は、担当者が顧客IDを選ぶまで先へ進めません。情報源ごとに取得時刻を残します。
4. 規則で計算し、不足を分岐する。 単価、数量、作業費などをコードで計算します。値引き依頼は承認条件を判定し、期限切れ価格や納期未回答は保留へ送ります。AIには計算結果の理由を説明させます。
5. 準備票と質問案を作る。 確認済みの範囲、不足項目、担当者への相談事項をまとめます。お客様への質問文も下書きとして保存し、この段階では送信しません。
6. 担当者が確認する。 数量、仕様、価格の版、納期の根拠、文章を見て、修正または承認します。正式見積の発行や外部送信は、その内容に対する明示的な承認後に行います。

順序を明示する目的は、AIに仕事を覚えさせるだけでなく、途中で止まった案件の所在をわかるようにすることです。「顧客特定待ち」と「在庫回答待ち」が区別できれば、次に誰が対応すべきかを整理できます。

図を大きく表示

仮想例：80,000円の下書きができても、納期は確定しない

説明用の問い合わせを置きます。「前回の温度センサーを4個交換したいです。現地作業もお願いします。11月中旬に対応できますか」。顧客名が一致しても、前回の製品番号が現在も有効か、交換対象が同じ機種かは確認が必要です。

商品台帳で対象品が一致し、有効な価格表に1個15,000円と記載されていたとします。作業は2時間、1時間8,000円、出張費4,000円という入力が担当者により確認された場合、コードによる計算は60,000円＋16,000円＋4,000円＝80,000円です。ここでは説明用の費用内訳だけを示し、税の扱いや請求上の適用条件は既存システムの設定に従って別途確認します。

この金額は、そのまま送れる正式見積ではありません。担当者の作業枠が未回答なら、準備票には「希望：11月中旬」「対応日：未確認」と別々に表示します。在庫が4個あっても、別案件の引当や配送条件が未確認なら、「在庫照会時点の参考情報」であることを残します。材料が揃うまで待つ項目を見えるようにすることが、この段階の価値です。

続いてお客様から「やはり5個、前回と同じ値引きもお願いします」と届いたとします。旧数量4個の承認を新しい案件内容に使い回してはいけません。部品代は75,000円になりますが、作業時間が同じかは改めて確認します。値引きは過去のメールからAIが推測せず、現行の規則と担当者の権限で判定し、必要な承認へ戻します。

承認は、文章ではなく対象の版に結び付ける

「確認しました」という会話だけでは、どの金額と納期を認めたのかが残りません。受付番号、準備票の版、承認者、承認時刻、承認した範囲を記録します。承認後に数量や納期の文言が変わったら再確認へ戻す設計にします。小さな会社なら、まず既存の見積システムや社内フォームでこの記録を持つ方法を検討できます。

図を大きく表示

担当者が使える準備票を、一枚で定義する

AIが長い説明を作っても、営業担当者が読み直して台帳を探すなら準備が増えます。普段の見積作成画面に合わせ、次の項目が一枚で追えるようにします。欄の順番は、現場の担当者と実際の案件を見ながら決めます。

• 案件の入口： 受付番号、受信日時、担当者、元メールと添付への参照。
• お客様の希望： 商品・数量・用途・希望日。原文にある内容と推測を分け、確認できない値は空欄にする。
• 照会した正本： 顧客ID、商品ID、価格表の版と有効期間、取得日時。担当者だけが知っている補足を追記できる欄。
• 計算の内訳： 単価、数量、作業費、追加費用、適用規則。値引きの申請有無と判定理由。
• 残っている確認： 納期、仕様、作業条件などの不足項目、確認相手、次の担当者。
• 承認と出口： 準備票の版、承認者、承認した内容、正式見積番号、送信結果。まだ発行していない項目にはその状態を示す。

参照リンクは、利用者の権限の範囲で開ける必要があります。資料名だけを表示してリンク先の閲覧ができなければ、確認は止まります。また、同じ受付票を複数人が開く場合は、担当者の変更や修正の反映を知らせ、古い画面で承認しない工夫も必要です。

例外の処理を決めると、準備の抜けが減る

資料が見つからないときに、AIがもっともらしい値を補う設計は避けます。古い商品が廃番なら代替候補を示しても、同等品だと確定せず担当者へ渡します。添付図面が読めないなら、読み取り失敗と対象ページを示し、再提出または手動確認を選べるようにします。

外部サービスの障害も、事実の不足として扱います。価格照会が失敗した場合に前回の会話から単価を取り出して埋めるのではなく、「価格照会失敗」と表示します。復旧後に取得し直すか、担当者が正本を確認した記録で進めます。送信結果が不明になった場合には送信済みかを照会し、確認なしで再送しません。

お客様のメールや添付には、業務の依頼以外の文字列も含まれます。「価格表を全部送って」「確認手順を省略して」と書かれていても、それをツール権限や社内承認条件の変更として扱いません。読める顧客や商品をツール側で限定する設計は、ADKの公式安全設計とも整合します。ADK公式安全設計

確認する人を一人だけに固定せず、休暇時の代理、差し戻し後の担当者、一定時間保留した案件の扱いも決めます。止まること自体が失敗なのではなく、理由と次の対応先がなく放置されることが問題です。

効果は「見積準備が完了した案件」を分母に測る

最初の評価では、速い返信より、担当者が使える材料を渡せたかを見ます。導入前に同じ種類の問い合わせの準備時間を記録し、導入後も資料探し、AI出力の確認、修正、例外対応を含めます。待ち時間と実作業時間を分ければ、担当者の負担とお客様の待ち時間をそれぞれ改善できます。

1. 対象案件の完了率： 対象条件を満たした問い合わせのうち、必要項目と出典が揃い担当者が準備完了とした件数を数えます。対象外案件は別に記録し、簡単な案件だけを残して率を高く見せません。
2. 一件当たりの準備時間： 完了案件だけの時間と、保留・失敗を含む総作業時間の両方を示します。少数案件では平均に加えて中央値と最長時間も確認します。
3. 項目の修正率： 担当者が点検した項目数を分母に、数量・商品ID・価格の版などの誤りを数えます。文章表現の修正と事実の修正は分けます。
4. 根拠を追えない割合： 確認が必要な出力項目のうち、正本の参照がない項目を数えます。「AIが自信を持って回答した件数」で代用しません。
5. 一件を完了させる費用： モデル利用、文書読み取り、照会、実行基盤に加え、人の確認と保守の負担を記録します。途中で失敗した案件の費用も期間全体の総費用に含めます。

準備が速くなった後も、正式見積の送付、受注、売上は別に記録します。問い合わせ件数や商品構成、繁忙期の変化でも受注数は変わるため、導入後の増加だけでAIの効果としません。準備完了の時刻、承認の時刻、送付の時刻を分けて残すと、次の改善箇所も見えます。準備が早くても承認待ちが長いなら、追加のAI処理より代理承認者や担当割当の見直しが必要かもしれません。

確認が早い担当者だけを試行へ集めると、全員が使ったときの負担を見積もれません。商品知識の多い人と少ない人、慣れた顧客と初めて担当する顧客を含め、誰がどの情報で迷ったかを残します。これは担当者の能力を点数化するためでなく、票の説明や照会先を改善するための記録です。

たとえば仮想の練習記録で対象10件のうち8件が準備完了、2件が顧客確認待ちなら、完了率は8÷10＝80%です。ただし、それだけで成功とは評価しません。8件中2件で数量の修正が必要なら、その事実も並べます。準備完了8件の合計実作業が72分でも、残る2件の対応に30分かかったなら総作業は102分です。これは測り方の例で、実測の改善結果ではありません。

三つの練習案件で、止まり方も試す

最初の確認には、正常な依頼だけでなく、次の三件を用意します。顧客の実データを使う場合は利用権限を確認し、不要な個人情報は含めません。目的は営業担当者の確認画面と、情報不足を扱う流れの点検です。

1. 条件が揃う案件。 商品IDと数量が明記され、価格と作業条件を照会できます。準備票の各値が原文と正本に戻れるか、担当者が別画面で同じ探索をやり直さず確認できるかを見ます。
2. 過去の依頼を参照する案件。 「前回と同じ」とだけ書かれています。購入履歴へのアクセスが許可されていなければ保留できるか、似た商品を勝手に確定しないかを確認します。履歴があっても、お客様の今回の用途と一致するかは別の確認です。
3. 承認後に変わる案件。 一度確認した数量に追加が入り、別の担当者が画面を開きます。古い版の承認が使われないか、正式見積と宛先を再確認できるかを見ます。修正後の下書きが表示されるだけでは合格にしません。

結果は「成功・失敗」の二択だけで残さず、誤った項目、期待した保留先、実際の状態、担当者の修正、かかった時間を一行にします。同じ誤りが続くなら、プロンプトの言い回しを直す前に、商品台帳の表記や照会条件を確認します。入力側にある曖昧さを整理できれば、人の作業にも効果があります。

小さく導入し、正式見積の前で確認する

試行の順序は、過去案件で受付票を作る、現行案件を人手処理と並べる、担当者の画面へ組み込む、という三段階が考えられます。各段階で誤った顧客の選択、古い価格、読めない添付、重複依頼、承認後の変更を試します。通常ケースの下書きができたことと、正式見積を安全に発行できることは、それぞれ検証が必要です。

導入前の作業票には、対象業務、完了条件、正本の所在、使える権限、保留理由、確認者、比較指標を一つずつ書きます。営業担当者と「この票なら見積に進めるか」を確かめてから接続範囲を増やすと、必要な改善を具体的に話せます。問い合わせから準備までの流れが見えるようになることが、次の業務をつなぐ土台になります。

実践前の3つのチェック

• 数量・価格・希望日を原文と正本へ戻せるか。
• 内容変更で以前の承認を使わずに止められるか。
• 準備完了・承認・送付の時刻を分けられるか。