1. はじめに

本記事は、営業提案書の作成や案件立ち上げで発生する「時間がかかる」「過去事例が探しにくい」「品質がばらつく」「ヒアリング漏れが起きる」といった課題に対して、Databricks Agent Bricks をどう活用できるかを整理した構想記事です。営業企画や提案担当の方、また業務改善を進める方を想定しています。実装手順の詳細よりも、どのデータを用意し、どの役割をエージェントに持たせると営業支援として機能しやすいかに焦点を当てます。

2.Agent Bricksとは

Databricks の Agent Bricks は、企業のスキーマや業務定義などのコンテキストを使って、どのツールやテーブルを使うか、どう結合するか、どのように一貫した回答を出すかを支援するプラットフォームです。Knowledge Assistant は文書ベースの質問応答と引用付き回答に向いており、Supervisor Agent は複数のエージェントやツールをまとめて調停する用途に向いています。databricks.com

3. 背景と課題

営業提案では、業種や顧客課題ごとに提案内容を毎回考える必要があります。その結果、提案書作成に時間がかかり、過去事例の探索も属人的になりやすく、ヒアリング漏れや提案品質のばらつきにつながります。
特に、提案初稿をゼロから作る場面では、次のような負荷が重なります。
• 顧客業種に合う提案の型を探す
• 類似案件を思い出す、または探し直す
• 次回商談で確認すべき項目を整理する
• 商談後のフォローアップメールを書く
本記事では、これらを個別の作業ではなく、ひとつの支援フローとして扱います。

4. 提案するエージェントの全体像

この構想では、営業担当の判断を置き換えるのではなく、初稿作成と確認作業を速くする伴走者としてエージェントを設計します。入力された顧客情報から提案骨子を作り、類似案件を示し、次回商談の確認ポイントを整理し、最後にメール文面まで下書きする流れです。

Knowledge Assistant は文書に基づいた回答と引用を返せるため、提案プレイブックや案件カードの根拠を示しやすくなります。Supervisor Agent は複数のエージェントやツールを束ねて複雑なタスクを調停できるため、提案支援のように情報源が分かれる業務と相性がよいと考えています。docs.databricks.comまた、Supervisor Agent にはアクセス制御が組み込まれており、エンドユーザーは権限のある subagent（役割を分担した下位エージェント）とデータのみを参照できます。営業案件のように権限管理が重要な題材では、この点を前提に設計しておくと安心です。さらに、Knowledge Assistant も Supervisor Agent も、専門家からの自然言語フィードバックで改善していけるため、営業部門のレビューを回しやすい構成です。docs.databricks.com

5. 使用データとナレッジ

構造化データと文書ナレッジを分けて持たせることで、検索と提案の両方を支援しやすくなります。

この構成にすると、データに基づく類似案件検索と、営業提案の「型」の両方を支援しやすくなります。最初は、内容が比較的安定している提案プレイブックや案件カードから使い始めると、扱いやすいです。

6. Agent Bricksでの活用イメージ

6-1. 顧客業種や課題に合わせて提案骨子を作成する

顧客の業種、課題、利用データを入力すると、提案骨子をひとまとめに整理します。営業担当者が最初に考えるべきポイントを見渡しやすくなるため、提案書の初稿作成を早める起点として使えます。

出力項目の例

提案テーマ
想定顧客課題
提案メッセージ
提案書アウトライン
類似事例
ヒアリング項目
必要データ
次アクション

6-2. 類似案件を検索する

「似た案件を探したい」と思っても、過去資料がどこにあるか分からなかったり、探し出すまでに時間がかかったりします。そこで、顧客業種・課題・利用データに近い類似事例を返し、提案時に再利用しやすくすることを狙います。Knowledge Assistant の引用付き回答を活用できれば、営業担当は「なぜこの事例を出したのか」をすぐ確認できます。docs.databricks.com

出力項目の例

• 対象業種
• 近い課題
• 採用した打ち手
• 参考にしたデータ
• 再利用時の注意点

6-3. 次回商談で確認すべき項目を整理する

提案を進めるうえで重要なのは、ヒアリングの抜け漏れを防ぐことです。情報が足りないまま提案書を作ると、あとから追加確認が必要になり、商談の進行が遅れます。そこで、顧客業種や相談内容に応じて、次回商談で確認すべき項目を自動で整理する流れを想定しています。

確認項目の例

• 現在の業務フロー
• 利用中のデータ
• 制約条件
• 決裁フロー
• 関係者
• 次回までの宿題
これにより、案件立ち上げ時の確認漏れを減らしやすくなります。

6-4. フォローアップメールを生成する

商談後のフォローアップメール文面も、ヒアリング内容や業種別ユースケースをもとに下書きできると便利です。営業担当者はゼロから文章を考える負担を減らしつつ、提案の一貫性を保ちやすくなります。ここでは自動送信ではなく、営業担当が最終確認してから送る運用を前提にするのが安全です。

メールに含める要素の例

• 商談のお礼
• 認識合わせ
• 宿題
• 次回アクション

7. 期待効果と評価指標

Agent Bricks を使うことで、営業担当の「考える時間」を減らすのではなく、提案の質を上げるための時間に変えることを目指します。

営業活動全体で見ると、提案内容の標準化、対応スピードの向上、初回提案の精度向上につながる可能性があります。ここで重要なのは、完全自動化ではなく、人が確認すべきポイントを残したうえで効率化することです。

8. 実際に試す場合の前提条件

この構想を PoC として試すなら、Databricks の公式ドキュメント上、Knowledge Assistant と Supervisor Agent には次の前提があります。
• Workspace には、Serverless compute、Unity Catalog、Mosaic AI Model Serving、非ゼロ予算の serverless usage policy、対応リージョンが必要です。docs.databricks.com
• Knowledge Assistant では、入力データとして Unity Catalog の volume 内のファイル、または file column を持つ Unity Catalog テーブルを使えます。対応形式は txt、pdf、md、ppt/pptx、doc/docx です。文書検索用に vector search index も必要で、embedding endpoint 側では AI Guardrails と rate limits を無効にしておく必要があります。docs.databricks.com
• Supervisor Agent では、少なくとも 1 つの subagent が必要で、エンドユーザーは各 subagent に対する明示的なアクセス権が必要です。トレーシングを使いたい場合は、MLflow production monitoring（Beta）を有効にします。docs.databricks.com

9. まとめ

今回の構想を通じて、Agent Bricks は営業提案のような知識集約型業務と相性がよいと考えました。構造化データで候補を絞り、文書ナレッジで提案の型と根拠を補うことで、提案初稿のスピードと品質の両立を狙えます。今後は、実データを使って類似案件検索の精度、提案骨子の採用率、フォローアップメール作成時間を検証し、どの工程に最も効果が出るかを見ていきたいです。

参考文献

Agent Bricks | Databricksdatabricks.com
Use Knowledge Assistant to create a high-quality chatbot over your documentsdocs.databricks.com
Use Supervisor Agent to create a coordinated multi-agent systemdocs.databricks.com