「動くもの」から「求められているもの」へ
Gemini Enterprise と ADK で、営業デモ用のAIエージェントを構築しています。 最初は動くものを実装することに意識が向いていましたが、上司のフィードバックを受けて、作り始める前にやることが変わりました。
- 提案前〜提案後営業活動の前後どちらもエージェント化
- 100件+準備したデモ用の資料データ
作っているもの
営業担当者が商談の場で見せるためのデモとして、Gemini Enterprise 上に複数のAIエージェントを構築しています。直近の中心は提案活動そのものを支援するエージェントです。
営業担当者が「◯◯企業への提案資料を作りたい」と入力すると、エージェントが次のことをまとめて行います。
- 01企業情報のリサーチ提案先の企業について調べる
- 02過去の提案資料の参照Driveに蓄積された社内資料から近いものを探す
- 03資料構成案の作成どういう流れで提案するかの案を出す
提案の前だけでなく、提案した後を担当するエージェントも作りました。議事録からタスクを起こし、カレンダーとSlackにつないで次の行動まで落とすところまでを扱います。
構築したエージェント
営業・マーケティング・情報システムの各領域にわたって構築しました。主なものは次のとおりです。
- 商談ロープレシミュレーター ─ AIが顧客役になり、営業担当者が商談の練習をする
- 商談録音からのCRM自動入力 ─ 会議の録音からCRMへの入力とネクストタスク化まで
- ターゲットリストの自動生成
- セグメント作成の効率化 ─ SQLを書く手間を減らす
- メルマガの自動生成 ─ Gmail連携でメール送信まで
- 超多層ナーチャリング ─ 100パターン以上のシナリオとコンテンツを一括生成
- 成果データに基づく広告コピーの自動生成
- バナーの自動生成と分析
- 配信後データの分析と改善方針の自動化
- AIによるスコアリングモデルの自動チューニング
- 広告インシデント防止 ─ Slack連携でリアルタイムに検知
- 社内ヘルプデスク・FAQの自動化 ─ グラウンディングを活用
- 社内コンテンツの統合とメール文案の自動生成
- システムドキュメントの自動生成とソースコード・エラー解析 ─ GitHub連携
- シャドーIT・セキュリティのログ横断検知
- A2A（エージェント間連携）エージェント ─ BigQueryのSQL結果との連携
作るだけでなく、作りやすくする
エージェントの数が増えてくると、毎回同じところでつまずいていることに気づきました。そこでエージェント構築を効率化するスキルとフォーマット変換のスキルを作り、構築の手順そのものを短くしています。
リポジトリも作り直しました。エージェントを置き場所なく増やしていくと誰も探せなくなるので、業務領域ごとにフォルダを分ける構成にしています（マーケティング / 広告 / 営業 / IT・情報システム / 研究開発 / 広報・IR / 調達・SCM / 店舗運営、そして領域を問わず試作を置ける「アイデア箱」）。READMEには新しいエージェントを追加する手順を書き、ADKの標準レイアウトに沿えば誰でも足せる形にしました。社内の他のメンバーが同じ手順で作れるように、ホワイトペーパーも書いて更新し続けています。
認証まわりでは、Drive連携のたびにOAuthクライアントを作っていたところを、サービスアカウントにファイル閲覧権限を渡しておけばクライアントを作らずに認証が通ることを見つけ、権限設計を単純にできました。デモを量産する前提では、こうした「一回の手間」を削るところが効いてきます。
デモに使うデータの扱い
デモとして成立させるには、それらしいデータが必要です。社内から100件以上の資料データを抽出して整えました。
このとき同時にやったのが、抽出したデータに顧客情報が紛れていないかのレビューです。商談の場で見せるものなので、実在の顧客名がそのまま出れば事故になります。あわせて、出力に個人情報が含まれた場合の対策として Model Armor も調査しました（出力を止めることはできても、マスクして出し直すことはできない、というのが調査の結論です）。
考え方が変わったところ
最初のうちは、「とにかく動くものを実装する」ことに意識が向いていました。エージェントが指示どおりに動けば、それで仕事をしたつもりになっていたのだと思います。
社内向けの説明の場で準備不足を痛感したことがあり、そこから考え方が変わりました。
クライアントが何を求めているかを明確にしてから開発する。
上司からのフィードバックを経て意識するようになったこと以前
指示された機能を実装する。動けば完成。
いま
デモが実際に使われる場面を先に決める。誰が、どんな状況で、何のために触るのかを固めてから作り始める。
いまはデモのシナリオを先に書き、上司にフィードバックをもらってから実装に入るようにしています。営業デモの場合、触るのは開発者ではなく営業担当者で、その先には商談相手がいます。操作に迷った時点でデモとしては失敗なので、誰でも一発で使えるかどうかを基準に作っています。
あわせて ─ 技術調査と提案資料
エージェントを作るだけでなく、導入を検討している相手の疑問に答える調査も担当しました。IPアドレス制限の可否、外部ストレージを使わない場合の懸念の整理、監査の観点でのチャット履歴の管理方法、そしてアーキテクチャ図の作成まで行い、スライドに反映しています。
この仕事は、自分が目指している「顧客の課題を理解して、要件を定義して、提案する」という流れそのものでした。手を動かして作れることと、なぜそれを作るのかを説明できることは別の能力だと実感しています。現在は、社内向けに Gemini Enterprise の初学者向け資料も作成中です。