こんにちは！Digitization部 & Corps兼務の荻野悠一です。
この半年間、社内の営業業務を効率化するためのAIツール開発をしていたので、その経験を共有します。
忙しい人向けの要点
- AIとデータを繋いだだけでは活用できません
- たとえ社内ツールでも、社外向けサービス同様に実用性やUXを改善しないと定着しません
- 「使える」ものを作る工数の大部分は、業務理解とデータモデリングでした
1. やったこと全体像
「営業の業務生産性をAIを活用して上げて欲しい」という話がVPoEからあり、対応することになりました。営業業務と言ってもいろいろありますが、表面化しているペインとして商談準備業務があげられたので、その改善をターゲットにしました。
- 商談のための事前準備
- 企業調査
- キーマンや主要人物の調査
- 過去の営業接点や動向の整理
- 提案資料の作成
営業現場では、Web検索・Salesforce・Box・Slack・Sansanなど多様なデータソースから情報を集めて、営業提案のための準備をする必要があります。しかも、大抵の営業社員は朝から定時まで商談や会議でカレンダーが埋まっており、その隙間で上記をこなして提案の質を高める必要がありました。
そこで、営業現場の生産性向上を目的に、半年間で次のようなAIツールを社内リリースしました。
- Slack bot
- Notionレポート自動作成ボット
- OpenAI GPT Actions
- MCPサーバ
これらはどれも大きな構造としては同じで、社内データをAIと繋いで、情報取得・対話が可能なRAGシステムです。 インタフェースによって得意なタスクが多少異なります（例えばNotionボットはまとまった長文のレポート生成に向いているなど）。
これらをリリースして、定着したツールもあれば、しないツールもありました。 現時点で定着しているのは、OpenAI GPT Actions、Slack botによる営業支援ツールです。 本記事では定着が進んだものについて、その要因を探っていきます。
要素技術
AI関連に絞ると次のようなものを使ってきました。 本題ではないのと、個別技術の話題は陳腐化が早いジャンルなので割愛します。
- MCP (FastMCP)
- OpenAI API
- OpenAI GPT Actions
- OpenAI Agent
- LangChain
- LangGraph
- Vertex AI Search (BigQueryでのembedding modelの利用)
- Claude Code Action (開発用)
- Cursor (開発用)
2. ツールが使われない・定着しない理由
1. 認知されていない
そもそも存在が知られていないツールは使われません。例えば全社のアナウンスチャンネルでリリースを告知したとしても、認知してもらえる人数は思ったより少ないです。
また、弊社の営業組織はプロダクトや領域ごとに細分化された大人数の組織であるため、すべての人がツールを認知するまでにはハードルがあります。
2. 利用ハードルが高い
新しいツールを試すというのは疲れることです。
現場以外のエンジニアから突然ツールをリリースされても、使い方が分からない・何ができるのか分からないなど、試すのにはハードルがあります。
3. 現場の実務に即していない
自分の業務と関係ない出力をするツールは使えません。 わざわざ時間を割いて試してみたツールが、自分の業務とズレたトンチンカンな出力や、聞いてない無関係な情報を出してきたら、使いたくなくなります。
4. 性能が悪い
遅くて不正確なツールは使われません。 わざわざ時間を割いて新ツールを試そうとしたのに、何分も待たされた挙げ句にハルシネーションだらけの結果を出されたりすれば、使いたくなくなります。
3. ツールを定着させるステップ
というわけで、前項で挙げた問題を順番に潰していきます。
1. 認知してもらう
PoCで感度の高い人に試してもらう
ツールリリース時には、PoCという形でAIに関心のあるユーザを募って試してもらいました。 リリース初期に大事なのは、「何でも良いからリリースすること」「何でも良いからフィードバックを得ること」です。このサイクルが始まらないと進展が中々ありません。 幸い社内にはAIや新ツールに感度の高いメンバーがいたのでその方々に協力いただきました。
ただ、この「PoC」という体裁には注意すべき点もあります。
PoCに参加してくれる方は大抵の場合、感度が高くかつツールに対して積極的に接してくれます。 例えば、利用前のインストール手順が少し煩雑だったり、精度やパフォーマンスに多少の問題があっても、自分で工夫したり乗り越えながら使ってくれます。
実運用に乗せる場合はそのようなハードルを残すべきではないので、フィードバックを受ける際は、少しでも気になる部分は徹底的に掘り下げたほうが良いでしょう。
宣伝する
社内ツールといえども宣伝することは必要です。特に弊社など社員数が一定規模以上の企業では社内広報は無視できません。
新ツールのリリースや機能追加のたびに、全体告知をして宣伝をしていますが、「この告知でツールの存在を初めて知った」という人がその都度現れます。 規模の多い集団で情報を通知するには、想像以上に繰り返しの伝達が必要なのだとわかります。
また、社内広報だけでなくダイレクトマーケティングも時には有効です。 Slackでの評判や利用ログなどから不満を抱えていそうなユーザーを分析・直接インタビューするなどすると、深いフィードバックを得られる可能性があります。
2. 利用ハードルを下げる
既存のツールやプラットフォームに乗っかる
UI・UXの洗練された便利な既製ツールがたくさんあります。
Slack AppやChatGPTのカスタムGPTを使えば、自力で作らずに洗練された対話UIをすぐ提供できますので、活用していきました。
特にカスタムGPT(※1)やMCP(※2)は、エージェンティックな要素を丸投げできるという点でとても効率が良いです。
営業現場では出先からスマホでアプリを使うケースが多い点でも、既存アプリに乗っかるのは理にかなっていました。
より高度でユースケースの定まった業務に対しては、LangGraphやGemを用いて個別化されたエージェントを作ることで精度を上げることもできます。
しかし、雑多にRAGを伴う対話をするだけであれば、ChatGPTやClaude DesktopのUIにまかせてしまうのが一番早く、かつ汎用的で精度が高いという体感です。
(※1) 弊社はChatGPTやClaudeのEnterprise契約を結んでおり、統制やセキュリティ面での良さも有りました。
(※2) 本記事でMCPの影が薄いのは、開発を始めた当初、HTTP経由でのMCPサーバの仕様策定やクライアントの実装が固まっていなかったためです。直近はMCPの導入も積極的に進めています。一方で、AIを用いた業務改善にあたってMCPはあくまで手段の一種でしかなく、必然性は無いということがこの記事からわかります。
具体的な体験を示す
文字だけでツールの説明をされても、何に使えるのかわかりにくいものです。
- ユーザの具体的な困りごとをツールで解決する事例を共有する
- 使い方を簡単な動画で共有する
といった工夫でユーザーの利用ハードルを下げます。
3. 実務に即したツールを作る
業務に合わせてデータをモデリングする
社内DB（Salesforce、BigQuery、Sansanなど）には多くのデータがありますが、すべてを業務で使うわけではありません。
また、使うデータがどこにあるのか、データ間の関係性がどうなっているのかなどについて、メンタルモデルと実際のデータ構造は一致しません。
また、Salesforceなど非エンジニアが扱うデータソースのデータは非正規化状態のテキストも豊富にあります。
SalesforceやBigQueryのデータをそのままAIには与えておらず、実際の業務体験に合うようアプリケーションレイヤで結構加工しています。
MCPのツールのdescriptionやOpenAPIの内容が、AIフレンドリーかつ業務内容を伝えるような内容になるよう調整を重ねています。
業務に沿ったデータ加工の把握のために、現場営業の方に細かくインタビューしたり、会議の録画を頂いたりして勘所を詰めました。
アプリケーションレイヤで加工しない別のアプローチとしては、そもそもSalesforceやBigQueryといった一次データの整理を進めるという考え方もあります。長期的にはこちらのほうが理想的かもしれません。
一方で、弊社の一次データはさまざまな管轄の組織に散在しており、それらを短期間で整理するのは非現実的でした。数日〜一週間のような突貫でリリースするために今回はAIによる実装も駆使してアプリケーションレイヤで対応しています。
一例として、会社の名寄せにAIを活用しています。
システムによってデータのキーが異なる（法人番号、Account ID、etc.）問題や、同名企業・表記ゆれの問題を、非正規テキストからAIに判断させて吸収しています。
4. 利用状況を見ながらチューニングしていく
PoCである程度うまくいっても、実運用では性能や使い勝手が悪ければ活用が進みません。
ユーザビリティに応じて自然と利用が広まったり縮小したりするのは、社内向けアプリであっても社外向けと同様でした。
印象的な事例があります。
これはカスタムGPTの利用数のグラフですが、利用数が途中で急減しているのがわかります。
原因は、OpenAIの仕様変更によりツールの挙動が不安定になっていたからでした。
数日後に修正対応をいれることで利用者が復活していますが、実は原因発見〜修正対応までを通して、ユーザからの報告はなかったのです。
この件を経て、社内ツールといえどもモニタリングを通じた利用状況やペインの把握が重要であることを実感しました。
また、直接の声はなくともSlackで問題報告が上がっていることもあるので、社内エゴサみたいにこちらから困っているユーザを発見して話を聞きに行ったりします。
アプリの性能向上にあたって使った主な工夫は次のようなものです。
- 一次データソースからの取得に時間がかかるデータを、検索用のBigQueryに同期蓄積する
- プロンプトチューニングによる改善
- ENUMなど固定値で検索可能なデータはSQLでフィルタしてしまうなど、ベクトル検索以前のフィルタリングを行う
- BigQueryのチューニング（パーティション・クラスタリング・中間テーブルなど）
- マルチエージェントや、多段のLLMによる中間データの圧縮や要約など
4. 結果
ここまでのような取り組みを通じて、最終的には掲題の通り利用数が伸び、毎日数百セッションの利用が行われるようになりました。
5. 注意点
本記事を参考にしていただく場合、このプロジェクトは意思決定周りが非常に通しやすい体制だった点にご注意ください。
というのも、このプロジェクトはVPoE直轄で行われました。
社内に散在するデータを横断でRAG接続するにあたって、各種データの接続設定や権限を申請する必要はありましたが、VPoEの直接的な後押しのもとでかなりスピーディに進められました。
一方、一定規模以上の企業でこのような取り組みを行う場合、ここが大きなボトルネックになることは容易に想像できます。
規模の大きな組織でスピーディに進めるには、上層部の支援を取り付けられるかが重要なポイントのひとつになるでしょう。
まとめ（再掲）
- AIとデータを繋いだだけでは活用できません
- たとえ社内ツールでも、社外向けサービス同様に実用性やUXを改善しないと定着しません
- 実際に「使える」ものを作る工数の大部分は、業務理解とデータモデリングでした
ここまで読んでくださりありがとうございました！
ぜひ皆さんの現場でも、業務に寄り添ったAI活用を検討してみてください。
Sansan技術本部ではカジュアル面談を実施しています
Sansan技術本部では中途の方向けにカジュアル面談を実施しています。Sansan技術本部での働き方、仕事の魅力について、現役エンジニアの視点からお話しします。「実際に働く人の話を直接聞きたい」「どんな人が働いているのかを事前に知っておきたい」とお考えの方は、ぜひエントリーをご検討ください。
※ Salesforce は salesforce.com, inc. の商標であり、許可のもとで使⽤しています。
