IS（SDR）業務を生成AIで約70％・80時間削減！CRM情報可視化アプリ開発の舞台裏

はじめに

こんにちは、テックタッチ株式会社プロダクトマネージャー（PdM）の田中です（社内ニックネームはkokiです）。

昨今、業務の中で生成AIを活用して業務の効率化や生産性を向上させる取り組みをされている組織が多いのではないかと思っております。
その一方で、生成AIを業務に導入したいけど、どこから手をつければいいかわからない—そんな悩みを抱えている方もいらっしゃるのではないかと思います。

私たちテックタッチも、まさにそんな状態からスタートしました。AI のプロダクトを提供している会社なのに、社内メンバーがAIを全然活用できていない。これはまずいのではないかという危機感から、2025年2月にプロジェクトが急遽立ち上がったんです。
※プロジェクトの組成については、弊社勝俣（kacchan）のこちらの記事に記載されています。

そこからなんとか形にできたのが、インサイドセールス（IS）の一部門であるSDR（マーケティングが獲得したリードをフォローし、商談機会を創出するチーム）業務向けに、生成AIを活用したCRMにある情報を可視化するアプリです。

このアプリを導入した結果、SDRチームで月80時間の時間削減を実現しました。さらに嬉しいことに、SDRの大友（moko）がこの取り組みを発表した日本最大規模のインサイドセールスカンファレンス「Inside Sales Award 2025」では優秀賞を受賞できました。

この記事では、社内向けAIアプリの開発プロセスを包み隠さず公開します。MVP（Minimum Viable Product = 最小限の機能を備えた製品）の開発から本番リリースまでの具体的な手順、複数のAIプロンプトを連携させる実装方法、現場ヒアリングのコツ、そして実際の成果測定まで。失敗談も含めて、できるだけ詳細にお伝えしていきます。
同じような課題で悩んでいる方、生成AIの業務活用を進めたい方の参考になれば幸いです。

プロジェクトの背景

2025年2月、社内のAI活用推進プロジェクトが急遽立ち上がりました。PdMの私と情シスのkacchanの2名で、いくつかの部署でヒアリングを進めている中で、セールス領域、特にSDR業務に大きな課題を発見しました。

SDR業務の切実な課題を発見

SDRチームのmokoに詳しく話を聞いてみると、こんな実態が明らかになったんです。
リード情報の確認に、1件あたり平均20分もかかっている。
月間で計算すると、80時間。これは相当な時間です。
具体的な確認フローはこんな感じでした。

1. 新しいリードが入ってくる

2. その企業が既存顧客かどうか、Salesforceで確認

3. 取引先画面で、進行中の商談がないかチェック

4. 各商談の活動履歴を開いて、議事録をざっとななめ読み流し読み

5. 契約中の案件がないかもチェック

6. 同様に活動履歴を確認

7. 取引先画面に戻って、他のインサイドセールスの活動履歴も見る

8. ようやく「この人に連絡してもいいかな」と判断

つまり、複数の画面を行き来しながら、大量のテキストデータを流し読みする作業が毎回発生していたんです。
しかも確認する内容は結構複雑で、

• 同一取引先で進行中の商談があるか

• 同一取引先で契約中の案件があるか

• 問い合わせ者と同じ部署の人が、商談や契約で登場するか

• この取引先のキーパーソンは誰か

といった観点を、自由入力のテキストから読み取る必要がありました。
「これは大変だ…」と思いました（笑）

生成AIとの相性の良さ

ただ、この課題を聞いて、すぐにピンときたことがあったんです。
これ、生成AIの得意分野じゃないか？

• 非構造化データ（自由入力のテキスト）の解釈

• 大量のテキストからの情報抽出

• 文脈を読み取った判断

まさに生成AIが力を発揮できそうな領域でした。
さらに、mokoからこんな話も聞けました。
「別に100点満点の情報じゃなくていいんです。80%くらいの精度で、当たりをつけられれば十分です。最終的には自分で Salesforce を確認してファクトチェックするので」
この「80%で十分」という要件が、とても重要でした。生成AIは完璧ではありませんが、人間が最終判断する前提であれば、十分に実用的なツールになり得ます。
「これはいけそう！」と思い、SDR業務の効率化ツール開発に取り組むことにしました。

開発プロセス①: MVP段階

業務の「なぜ」まで深掘りするヒアリング

開発を始める前に、まずは業務を徹底的に理解する必要がありました。
mokoに協力してもらって、かなり深いヒアリングを実施しました。ここでのポイントは、単なる業務フローの把握にとどまらず、「なぜそのアクションを取るのか」という思考プロセスまで聞き出すことです。
例えば、

• 「活動履歴を確認する」という業務フローがある

  • なぜ確認するのか？
    → キーパーソンを特定したいから

  • どうやって判断するのか？
    → 複数の商談に登場する人、役職が高い人、議事録の記載が詳しい人などを見る

  • どんな情報があれば判断できるか？
    → 登場回数、役職、活動内容の要約があればいい

こういう深掘りをしていくと、業務の「コンテキスト」が見えてきます。そしてこのコンテキストこそが、後で生成AIへの指示（プロンプト）を作る際に、すごく効いてくるんです。
ヒアリング内容は、業務フローチャートとして書き起こして、各ステップでの思考過程を付箋で整理しました。これを mokoと一緒に壁に貼って、「この順番で情報が見えたら判断できそう？」「この情報は本当に必要？」といった壁打ちを繰り返しました。

スプレッドシートでのMVP開発

業務理解が深まったところで、さっそくMVPの開発に取り掛かりました。
ここで選んだ技術スタックは、Google Apps Script（GAS）+ スプレッドシートです。
なぜこの組み合わせを選んだかというと、

• 開発速度が速い: GAS は JavaScript ベースで書きやすく、スプレッドシートがそのままUIになる

• 視覚的に確認しやすい: データの取得・加工・表示が一目で分かる

• Gemini にコードを書かせやすい: シンプルな構造なので、生成AIでコード生成がしやすい

実は、このMVP開発の段階では、Gemini にかなりコードを書いてもらいました（笑）「Salesforce API でこういうデータを取得したい」「スプレッドシートのこのセルに表示したい」というプロンプトを投げると、ある程度動くコードを生成してくれるので、それをベースに調整していきました。
MVP の主な機能は、

1. Salesforce API で取引先、商談、活動履歴のデータを取得

2. スプレッドシートに整形して表示

3. Gemini API を使って、活動履歴からキーパーソンを抽出

というシンプルなものです。

「こういう情報が見えたら判断できそう？」という壁打ち

MVP ができたら、moko に実際に使ってもらいました。
「こういう情報がこう見えたら判断できそう？」
「この順番で表示されてたら、思考の流れに合ってる？」
「この情報、実は要らない？」
こういう壁打ちを繰り返して、必要な情報の過不足を確認していきました。
その中で、いくつか重要な発見がありました。

発見1: 活動履歴のフリーテキストこそが重要
最初は、商談の「件名」「金額」や、取引先責任者名・部署名といった構造化されたデータを中心に表示していました。Salesforceにはこれらのカラムが用意されているので、当然それを活用すべきだと考えていたんです。

ところが、キーパーソンを見極めるヒントは、活動履歴に記載された議事録の中にこそ詰まっていました。「〇〇部長が決裁権を持っている」とか「△△さんが積極的に質問していた」とか、そういう文脈が重要だったんですね。
この発見は大きかったです。「構造化データを使えばいい」という思い込みを捨てて、実際に現場が使っているデータソース（フリーテキスト）に向き合うことの重要性を学びました。

発見2: 失注案件は優先度が低い
当初は、すべての商談情報を表示していたんですが、「失注した案件は、あまり気にしなくていい」ということが分かりました。優先度が高いのは、進行中の商談と契約中の案件です。
こういうスコープの絞り込みができたのも、MVP で早期に検証できたおかげです。

発見3: SDRの思考の順番に合わせた情報設計が重要
mokoは、情報を見る順番にある種のパターンを持っていました。
まず「進行中の商談があるか」を確認して、次に「キーパーソンは誰か」を見て、最後に「どういうコミュニケーションを取るべきか」を判断する——という流れです。
この思考の順番に合わせて情報を整理することで、アプリがより使いやすくなることが分かりました。

MVP段階での学び

MVP開発を通じて得られた最大の学びは、作り込む前に検証することの重要性です。
もし最初から完璧なWebアプリケーションを作ろうとしていたら、きっと要件がズレたまま大量の時間を費やしていたと思います（笑）
スプレッドシートというシンプルなUIで、「この情報は本当に必要か？」「この順番で見せるのが適切か？」を確認できたことで、本開発への確信が持てました。
「これで本開発に進めそう！」という手応えを得て、次のステップに進むことにしました。

開発プロセス②: プロダクション開発

スプレッドシートからWebアプリへ

MVP で要件が固まったので、次は本格的な開発に入りました。
ここで、スプレッドシートから GAS で Webアプリケーションとして実装することにしました。
理由は、

• より洗練されたUIを提供できる: HTML + CSS でデザインの自由度が高い

• タブ形式で情報を整理できる: SDRの思考の順番に合わせた画面設計が可能

• ローディングアニメーションなどでUXを向上できる: 待ち時間のストレスを軽減

• GASのメリットは維持できる: サーバーレスで運用が楽、Googleエコシステムとの親和性が高い

技術スタックは、

• フロントエンド: HTML + CSS（Pico CSS を使用）+ JavaScript

• バックエンド: Google Apps Script

• 外部連携: Salesforce API、Google Gemini API

という構成です。
GAS は、フロントエンドとバックエンドの両方を一つのプロジェクトで管理できるので、小規模なツール開発にはとても便利でした。

複数AIプロンプト連携という設計思想

ここからが、この開発で一番のポイントです。
このAIアプリでは、生成AIがリード情報を自動分析する仕組みとして、4段階のAIプロンプト連携を設計しました。
最初は「Gemini に全部任せればいいや」と思っていたんですが、試してみると、1つのAIに複数の指示（＝役割）を与えると、どうしても精度が下がってしまうことが分かりました。
そこで、役割を明確に分けて、段階的に処理することにしました。

AI設計の全体像
ここでは、アプリを構成する4つのAIの役割を簡単に紹介します。

AI①：登場人物情報を抽出する
Salesforce上のデータから、登場人物に関する情報を抽出する。

AI②：各商談のキーパーソンを推測する
商談・活動履歴から関係者を特定して、キーパーソンを推測する。

AI③：取引先のキーパーソンを推測する
部署名・商談登場回数・契約案件の関与度から取引先のキーパーソンと思われる人物を複数名推測する。

AI④：推奨アクションを提示する
各情報を整理して、SDRに推奨するアクションを出力する。

プロンプトの工夫

AI① 情報抽出（構造化の専門家）

役割: 活動履歴（フリーテキスト）から登場人物を抽出する。
使用モデル: Gemini 2.5 Flash Lite。
プロンプト（イメージ）:

あなたは情報抽出の専門家です。
以下の活動履歴から、取引先の担当者（お客様側の人物）を全てリストアップしてください。

【重要な指示】
1. まず活動履歴全体を読んでください
2. 登場する人物を全てリストアップしてください
3. その中から、自社の社員を除外してください
4. 結果をJSON形式で出力してください

【活動履歴】
{activity_history}

【出力形式】
{
  "persons": [
    {"name": "山田太郎", "title": "営業部長", "company": "株式会社サンプル"}
  ]
}

ここでのポイントは、思考プロセスを段階的に指示することです。「まず全体を読んで」→「リストアップして」→「除外して」という順番を明示することで、精度が上がりました。

AI② 個別分析（商談コンサルタント）
役割: 各商談ごとに、キーパーソンを推測する。
使用モデル: Gemini 2.5 Flash Lite。
プロンプト（イメージ）:

あなたは営業コンサルタントです。
以下の商談情報から、この商談のキーパーソンを推測してください。

【判断基準】
- 役職が高い人
- 活動履歴に頻繁に登場する人
- 議事録の記載が詳しい人（重要な発言をしている可能性）
- 最初の方に登場する人（最初の打ち合わせから関与している可能性）
- 情報システム部門・DX推進部門・IT関連部署に所属する人（全社システム導入の決裁に関わる可能性が高い）

【商談情報】
{opportunity_data}

【登場人物】
{persons}

【出力形式】
{
  "key_person": "山田太郎",
  "reason": "営業部長という役職で、全ての打ち合わせに出席している"
}

ここでは、mokoのヒアリングで得た判断基準をそのままプロンプトに落とし込んでいます。これが、業務コンテキストを深掘りした成果ですね。
さらに、テックタッチ独自のビジネスロジックも組み込んでいます。私たちのプロダクトは全社システムとして導入されることが多いため、情シスやDX関連部署の担当者がキーパーソンになる確率が高いんです。こうしたドメイン知識をプロンプトに反映させることで、より実践的な判断が可能になりました。

AI③ 総合評価（営業アナリスト）
役割: 取引先全体で、最も重要なキーパーソンをランキング化する。
使用モデル: Gemini 2.5 Pro（より高度な推論が必要なため）。
プロンプト（イメージ）:

あなたは営業戦略アナリストです。
以下の情報から、この取引先で最も重要なキーパーソンをランキング化してください。

【評価軸】
- 複数の商談に関与しているか（量的データ）
- 役職の高さ（質的データ）
- 契約案件に関与しているか（重要度）
- 進行中の商談に関与しているか（現在の影響力）

【取引先情報】
{account_data}

【各商談のキーパーソン分析】
{opportunity_key_persons}

【出力形式】
{
  "ranking": [
    {
      "rank": 1,
      "name": "山田太郎",
      "score": 95,
      "reason": "3つの商談に関与、営業部長、契約案件の決裁者"
    }
  ]
}

ここでは、量的データ（登場回数など）と質的評価（役職など）を融合させる必要があるため、より推論能力の高い Gemini 2.5 Pro を使用しました。

AI④ アクション提案（インサイドセールスコーチ）
役割: 「次に何をすべきか」を提案する。
使用モデル: Gemini 2.5 Pro。
プロンプト（イメージ）:

あなたはインサイドセールスのコーチです。
以下の情報から、この新規リードに対してSDRが取るべきアクションを提案してください。

【分析情報】
- 進行中の商談: {ongoing_opportunities}
- 契約中の案件: {contracts}
- キーパーソン: {key_persons}

【新規リード情報】
- 問い合わせ者: {lead_name}
- 所属部署: {lead_department}
- 問い合わせ内容: {lead_inquiry}

【提案してほしいこと】
1. このリードにコンタクトしても問題ないか
2. コンタクトする場合、誰に連絡すべきか
3. どのようなアプローチが適切か

【出力形式】
{
  "contact_ok": true,
  "recommended_contact": "山田太郎",
  "approach": "既に営業部で導入検討中のため、情報共有と連携を提案する",
  "notes": "進行中の商談担当者に事前連絡を入れることを推奨"
}

このAIは、すべての分析結果を統合して、最終的な判断を支援します。

テックタッチ（DAP）の活用

AIアプリやAIワークフローを開発しても、ユーザーに利用されないという問題をしばしば聞きます。
その問題にはいくつかのアプローチが考えられると思いますが、今回はテックタッチ（DAP）を活用して、業務動線上にアプリの起動ボタンを置くことで、その問題をクリアしました。

テックタッチには変数ステップという機能があります。これは、画面上のテキスト要素を自動で取得したり、対象システムの入力ボックスに値を自動入力したりできる機能です。
この機能を使って、以下のような体験を設計しました。

• ボタン一つで実行: ユーザーは何も入力せず、ボタンをクリックするだけ

• 画面から変数ステップで情報を取得:Salesforce のDOM要素から必要な情報を抽出

• Webアプリへの自動入力: アプリへリダイレクトして、取得した情報をAIアプリに入力・検索

これにより、Salesforce → AIアプリへのデータフローが完全に自動化され、ユーザーの入力を最小化することができました。
Salesforce の画面を見ながら、「この取引先のリード情報を検索したい」と思ったら、ボタン一つでAIアプリが起動して、生成AIが分析した結果を表示してくれる—というシームレスな体験を実現できました。

成果と評価

定量的成果: 月80時間の削減

では、実際にどんな成果が出たのか、お伝えします。
最も分かりやすい成果は、時間削減です。

• 削減前: 1件のリード確認に20分

• 削減後: ボタンをクリックして15〜30秒（ほとんど待ち時間）

• 月間削減時間: 80時間

80時間というと、約10営業日分です。この時間が、SDR本来の業務（リードへのコンタクト、商談設定）に使えるようになりました。
開発期間も短かったです。

• MVP開発: 約2週間

• プロダクション開発: 約2週間

• 合計: 約1ヶ月

上記期間の隙間時間での要件定義や開発・実装となり、それなりに早いスピード感で進められたのかなと思います。

定性的成果: 活動量の増加とAward受賞

定量的な成果だけでなく、定性的な変化もありました。
活動量の増加:

• メール送信件数が増えた

• 電話時間が増えた

• SDRが「情報確認」ではなく「コミュニケーション」に時間を使えるようになった

Inside Sales Award 2025 優秀賞受賞:
これは本当に嬉しかったです。SDRのmokoがこの取り組みをプレゼンテーションして、優秀賞を受賞しました。Awardでは『単なる効率化に留まらない、ISの役割進化』を高く評価いただけたようです。
客観的な評価をいただけたことで、「この取り組みは意味があったんだ」と確信できました。

まとめ

今回のAIアプリ開発を通して学んだこと

1ヶ月の開発期間を振り返って、試行錯誤の連続でしたが、なんとか形にできました。月80時間の削減、Inside Sales Award 受賞という成果も出て、「やってよかったな」と心から思います。
この記事では、開発プロセスを包み隠さず公開しました。

• 現場ヒアリングの深掘り手法

• MVP開発での早期検証

• 複数AIプロンプト連携の設計

• 失敗談も含めた試行錯誤

この活動を通して得られた最も大きな学びは、当たり前ではあるのですが、実現したい業務要件のWhatだけでなく、Whyまで具体的に言語化しておくことの重要性です。
ここで言語化された業務のコンテキストが生成AIへの指示や業務改善の起点となるからです。

すべて実体験ベースの内容なので、同じような課題で悩んでいる方の参考になれば幸いです。
もし質問や「うちでも似たような取り組みをしている」といった情報交換があれば、ぜひお声がけください。大歓迎です！

免責事項

この記事は2025年10月時点の情報に基づいて作成されています。記載されている内容は、筆者の実体験に基づくものであり、すべての環境や状況で同様の結果が得られることを保証するものではありません。
また、以下の点についてご留意ください。

• 記事内で紹介しているツールやサービスの仕様は、記事執筆時点のものです。最新の情報は各公式サイトをご確認ください。

• 記事内で紹介している手法やワークフローは、筆者の環境や状況に最適化されたものです。ご自身の環境や状況に合わせて適宜調整してください。

• 記事内で紹介している AI ツールの利用については、各サービスの利用規約やプライバシーポリシーをご確認の上、自己責任でご利用ください。

• 記事内で紹介している情報は、あくまで参考情報としてご活用ください。本記事の内容を実践したことにより生じたいかなる損害についても、一切の責任を負いません。

• この記事に添付しているキャプチャやプロンプトに記載されている人物名は、すべて架空の人物名となり、本記事のためのダミーデータとなります。

• この記事は筆者が AI ツールを活用しながら書いています。