こんにちは！組織の創り手を増やしたい相澤(@tigers_loveng)です！
この記事はourly Advent Calendar 2025🎄 16日目の記事です。
前半はbizメンバーがnoteに書いてくれたので、後半はエンジニアがテックブログを書きます！
今回は、インサイドセールス(以降IS)チームと一緒に取り組んでいる、題して「IS架電構造化チャレンジ」の途中記録を共有します。このチャレンジは、生成AIを使ってISの架電内容を構造化し、商談化につながる重要ポイントを見つける取り組みです。
最初に結論を書いておくと、この取り組みを通じて「ステップバイステップで仮説を一つ一つ検証することの重要性」を改めて痛感しました！
AIの推論能力が高いからこそ、逆に一足飛びに進めてしまいがちですが、基本的な仮説検証のプロセスは変わらないということを学びました。
この記事では、成功したこと、失敗したこと、そこから学んだことを包み隠さず共有します。AIを活用した営業支援や、仮説検証のアプローチに興味がある方の参考になれば嬉しいです。
背景と課題
ourlyでは、ISチームが日々多くの架電を行っています。その中で、以下のような課題がありました。
- 架電の質のばらつき: どのようなポイントを押さえれば商談化しやすいのかが属人的
- フィードバックの難しさ: 架電内容を振り返る時間が取りづらく、改善サイクルが回しにくい
- 成功パターンの不明瞭さ: 商談化につながる架電の特徴が明確になっていない
また、ISチームでは架電時にお客様にとって価値ある情報を提供することを心がけているのですが、上記課題に伴って価値提供できていないケースもあるのではないかというところを問題視しました。
これらの課題を解決するために、AIを活用して架電内容を構造化し、重要ポイントを自動で抽出してISチームへのフィードバックとすることで、より価値のある架電にするための改善を行いたいというところから始まっています。
IS架電構造化チャレンジとは
チャレンジの概要
IS架電構造化チャレンジは、以下のような流れで進める取り組みです。
- ISの架電を録音する
- AIで文字起こしする
- 文字起こしされたテキストから重要ポイントを抽出する
- 商談化の結果と照らし合わせて、重要ポイントを見つける
- 最終的にはSlack連携などで自動フィードバックする仕組みを構築する
週次でMTGを開催し、仮説検証を繰り返しながら、少しずつ精度を上げていくアプローチを取りました。
技術スタック
今回は次の3つのツールを組み合わせて使いました。
| カテゴリ | ツール | 役割 |
|---|---|---|
| 文字起こし | Gemini 2.5 Pro | 音声からテキスト化（話者分離機能付き） |
| 情報抽出・分析 | Claude Sonnet 4.5 | 架電内容の評価・重要ポイント抽出 |
| ワークフロー | Dify | ノーコードAIワークフロー構築 |
それぞれのツールを選定した理由は、後ほど詳しく説明します。
チャレンジの詳細
ここからは、実際にどのように取り組みを進めていったのかを、目的別のフェーズごとに説明します。
長いので先に全体像共有しときます
フェーズ1: 文字起こしと情報抽出の精度検証（仮検証）
まず最初に取り組んだのが、「架電の音声を正確にテキスト化できるか」「テキストから情報を抽出できるか」の2つを同時に検証することです。
特に重要だったのが、話者分離（営業担当者と顧客の発言を区別）ができるかどうかです。これができないと、誰が何を言ったのかがわからず、後の分析が困難になります。
文字起こしツールの比較
以下のツールを比較しました。
- ChatGPT 5.1（音声ファイルアップロード機能）
- NotebookLM
- Whisper（Google Colab/ローカル環境）
- Gemini 2.5 Pro
実際の架電音声を各ツールで文字起こしし、「文字起こしの正確性」「話者分離の精度」「コストパフォーマンス」の3つの観点で評価を行いました。
結果: 最終的に3つの観点全てで優れいていたGemini 2.5 Proを選定しました。
- 文字起こし精度が最も高い
- 話者分離機能が標準搭載されている
- コストが比較的低い（10分程度の1架電あたり約7円、70架電で500円程度）
情報抽出の精度検証（BANT情報）
文字起こしができることが確認できたので、次は「文字起こしされたテキストから、営業に必要な情報を正確に抽出できるか」を検証しました。
この時点では、何を抽出すべきかが明確になっていなかったため、仮でBANT情報※を抽出対象としました。
BANT情報とは
BANT情報とは、営業において重要な以下の4つの情報です。
- Budget: 予算
- Authority: 決裁権
- Need: ニーズ
- Timing: 導入時期
以下のAIモデルを比較しました。
- ChatGPT 5.1
- Gemini 2.5 Pro
- Claude Sonnet 4.5
結果: 文字起こしの精度が高ければ、どのモデルも高精度で情報抽出が可能であることがわかりました。
最終的に、情報抽出・分析にはClaude Sonnet 4.5を使用することにしました。理由は、複雑な文脈理解や分析タスクにおいて優れたパフォーマンスを発揮するためです。
学び／気づき
このフェーズで学んだことは、まずはGUIでミニマムに検証することの重要性です。
いきなりDifyでワークフローを組んだり、APIを叩くコードを書いたりするのではなく、GeminiやClaudeのGUIで試してみる。この手軽さが、素早い検証を可能にしました。
また、「文字起こしの精度が全ての土台」であることも確認できました。
フェーズ2: 真に重要なポイントの特定（ISマネージャーへのヒアリング）
フェーズ1で文字起こしと情報抽出が可能であることが確認できました。しかし、BANT情報はあくまで仮の抽出対象です。本当に商談化につながる重要なポイントは何なのか？これを明確にする必要がありました。
ISマネージャーへのヒアリング
ISマネージャーに「架電時に商談化率を高めるために意識しているポイント」のヒアリングを行った結果、以下のような評価項目が抽出されました。
- 本質的な課題が聞けているか
- 課題に関する具体的なエピソードが聞けているか
- 担当者の業務範囲を理解しているか
- 担当者のミッションを把握しているか
- 商談当日への期待を醸成できているか
ただし、この時点ではこれらはあくまで仮説段階です。本当にこれらのポイントが商談化を分けるのかは、後のフェーズで検証する必要があります。
学び／気づき
この段階で、検証すべき課題が2つあることに気づきました。
- 評価項目を正確に抽出できるか（ステップ2の課題）
- その評価項目が本当に商談化を分けるポイントなのか（ステップ3の課題）
この2つは別々に検証する必要があります。しかし、この時点では、この区別を明確に意識できていませんでした...。
フェーズ3: 評価ポイント抽出の検証とDifyワークフローの構築
フェーズ2で特定した評価項目を、AIが正確に抽出できるかを検証します。
AI評価と自動フィードバック
実際の架電データをいくつかピックアップし、各評価項目の定義と判定基準を記載したプロンプトをClaude Sonnet 4.5に渡して各評価項目を◯×で判定させました。
が！ここで、予想外の展開がありました。
AIが単に評価項目を抽出するだけでなく、「商談の改善ポイント」まで自動的に出力するようになったのです。
例えば、以下のようなアドバイスです。
- 「もっとBANT情報を深掘りすべきです」
- 「この場面では導入事例を提示すべきです」
- 「相手のミッションをもっと深く聞くべきです」
これは、プロンプトで特に制限していなかったため、AIが推論能力を発揮して2-3歩先のアウトプットまで出してくれたのです。
ぱっと見、この出力は「いい感じ」に見えました。
評価もできて、改善ポイントも提示される。これは便利だ！と思い、そのまま自動化を進めることにしました。また、この段階でDifyのローカル環境を構築し、ワークフローを組み始めました。完成形が見えていたので、つい手を動かしてしまったのです。
フェーズ4: 失敗の気づき（精度未検証のまま自動化を進めようとしていた）
アウトプットに対するフィードバック
半自動化できた段階で、ISチームやプロジェクトメンバーに実際の評価結果とアドバイスを見てもらいました。すると、以下のようなフィードバックが返ってきました。
- 「この改善ポイント、ちょっと的外れですね」
- 「そもそも、この項目、本当に聞けていると評価されていますか？」
- 「評価基準が曖昧で、判定がぶれている気がします」
ここで重要な指摘を受けました。
「そもそも該当の情報がちゃんと抽出できたのかどうかの精度、まだ検証していませんよね？」
学び／気づき
ハッとしました。
僕は、以下の2つの検証項目を混同していました。
- 評価項目を正確に抽出できるか（精度検証）
- その評価項目が本当に商談化を分けるポイントなのか（因果関係の検証）
そして、どちらも検証できていないのに、「いい感じ」という感覚だけで自動化を進めようとしていたのです。AIが勝手に改善ポイントまで出力してくれたことで、「完成形」を見た気になってしまい、基本的な精度検証を飛ばしてしまっていました。
冷静に考えると、今やるべきことは明確でした。
- まずは評価項目の抽出精度を検証する（ステップ2）
- 精度が十分に高いことが確認できたら、その評価項目と商談化の相関を分析する（ステップ3）
- 改善ポイントの提示は、その後の話
改めて、ステップバイステップで進めることを決意しました。
フェーズ5: プロンプトチューニング（精度検証への回帰）
評価項目の抽出精度を高めるため、プロンプトをチューニングしていきます。
プロンプトチューニングのためのサイクル
以下のプロセスを繰り返しました。
- 実際の架電データに対してAIが評価（◯×判定）
- IS担当者が同じ架電を聞いて評価
- 両者を比較して、乖離がある箇所を分析
- プロンプトを修正
- 1に戻る
このサイクルを、約50件の架電データに対して繰り返しました。
プロンプト改善の具体例
例えば、課題に対する具体的なエピソードの深堀りでは、会話の中で5W1Hの全てが具体的に聞けてないと×の評価になるようなプロンプトになっていましたが、実際はそこまで具体的である必要はなかったため、因果関係（原因と結果）の話が出てくれば◯になるように調整しました。
特に抽象的な概念に加えて具体例をいくつか提示してあげるとグッと精度が上がりました。
評価基準の明確化
もう一つ重要な改善が、評価基準の明確化です。
- 「◯」と「×」のみを使用（「△」は使わない）
- 曖昧な場合でも明確に判定するためのガイドラインを設定
AIは優秀なので、曖昧な表現にも対応してくれますが、「△」のような中間評価を許すと基準がぶれやすくなります。明確な二値評価にすることで、基準の一貫性が保たれました。
結果: プロンプトチューニングを繰り返した結果、各項目で90%前後の精度（AI評価とIS評価の一致率）が出るようになりました。
ここでようやく、ステップ2（重要ポイント抽出の精度検証）をクリアできました。
学び／気づき
フェーズ3で先走って構築していたDifyのワークフローが、ここで思わぬ形で役立ちました。
50件のデータを分析する際、一つ一つ手動でAIに投げるのではなく、Difyのワークフローで効率的に処理できたのです。本来はもっと後でやるべき工程でしたが、結果的には検証を効率化することができました。
これは「失敗が偶然成功につながった」という幸運な例ですが、意図的に狙えることではありません。やはり、基本に忠実にステップバイステップで進めることが重要です。
フェーズ6: 商談化要因の分析（架電データ分析）
ステップ2をクリアし、評価項目を高精度で抽出できるようになりました。次は、ステップ3：その評価項目が本当に商談化を分けるポイントなのかを検証します。
架電データの地道な分析
一定量(100件以上)の架電データを対象に、以下の分析を行いました。
- 各架電に対してAIが評価項目を◯×で判定
- その架電が商談化したかのデータを紐付け
- 評価項目と商談化の相関を分析
スプレッドシートで1件1件評価を入れていく地道な作業も大事
結果
分析から、商談化する架電には明確な特徴がありました。
商談化した架電 vs 商談化しなかった架電の特徴
| 評価項目 | 商談化率(◯) | 商談化率(×) |
|---|---|---|
| 本質的な課題 | 45.8% | 46.2% |
| 具体エピソード | 52.6% | 41.9% |
| 相手の業務範囲 | 45.5% | 47.1% |
| 相手のミッション | 85.7% | 30.6% |
| 商談当日への期待 | 48.4% | 42.1% |
最も重要な発見：ミッションが商談化の鍵
表からも明らかなように、「相手のミッション」が聞けているかどうかが、最大の差分でした。
- 商談化する架電では、ほぼ例外なく（85.7%）相手のミッションを把握できている
- 逆に、ミッションが聞けていない架電は、他の項目が◯でも商談化しにくい（30.6%）
これは、営業の本質的な部分を突いています。相手が何を達成したいのかを理解せずに、いくら機能を説明しても響きません。ミッションを理解することで、相手にとって本当に価値のある提案ができるようになります。
学び／気づき
ミッションを引き出すためには、先に価値を提供する「Give」が重要であることもわかりました。つまり「Give-to-Get」です。業界の知見や他社事例など、相手にとって有益な情報を先に提供することで、相手も自分のミッションを話してくれるようになります。
これは、ISマネージャーが経験的に理解していたことですが、データ分析によって裏付けることができました。
ここでようやく、ステップ3（商談化要因の特定）をクリアできました。ISマネージャーが仮説として提示した評価項目が、実際に商談化を分けるポイントであることがデータで証明されたのです。
特に「ミッション」の重要性は、想像以上に大きなものでした。
フェーズ7以降
ここまででようやく当初の目的だった、架電のキーファクターを見つけることができました。
ですが、最終ゴールはそれを元に、架電時により多くの価値提供をできるようにして商談に繋げていくことです。
そのためには「ミッション」自体の深堀りも必要なため、そのポイントに絞って検証を行う予定です。自動化は最終フェーズに到達してからという風に考えています。
成功したこと
ここまでの取り組みを振り返って、成功したことをまとめます。
技術面での成功
高精度な文字起こしの実現
Gemini 2.5 Proを採用したことで、高精度な文字起こしと話者分離を比較的低コストで実現できました。1架電あたり約7円（70架電で500円程度）というコストパフォーマンスは、大量のデータを処理する上で許容範囲でした。
Claude Sonnet 4.5での高度な分析
Claude Sonnet 4.5の文脈理解能力と分析能力により、単なる情報抽出だけでなく、架電時の会話の内容を元に正確な評価ができるようになりました。
Difyでのワークフロー構築
ノーコードでAIワークフローを構築できるDifyを活用したことで、素早くプロトタイプを作成し、検証サイクルを回すことができました。
プロセス面での成功
失敗からの素早い軌道修正
一度失敗を経験したからこそ、ステップバイステップで検証することの重要性を実感できました。そして、失敗に気づいた時点で素早く軌道修正できたことが、最終的な成功につながりました。
週次MTGでの継続的な改善サイクル
週に1回のペースでMTGを開催し、検証結果を共有して次のアクションを決める。このサイクルが、着実な前進を可能にしました。
また、最初に50,60％くらいの完成度で良いので毎週何かしらの進捗を出し続けようという目標設定をしたことも心理的ハードルが下がり良かったように思います。
現場からのフィードバックを反映
ISマネージャーや現場メンバーからの率直なフィードバックが、プロンプト改善の鍵でした。机上の空論ではなく、実践的な評価基準を作ることができました。
データに基づく検証
ISマネージャーの経験と知見から仮説を立て、それをデータで検証する。この科学的なアプローチが、確かな成果につながりました。
最重要ポイントは「ミッション」だった
このチャレンジを通じて得られた最大の発見は、「ミッションが商談化の鍵である」ということです。
相手が何を達成したいのか、どんな状態を目指しているのかを理解すること。これができているかどうかが、商談の成否を大きく左右します。
また、ミッションを引き出すためには、先に価値を提供する「Give」が重要です。この発見は、IS活動だけでなく、営業全般に通じる本質的な学びだと感じています。
失敗したこと
成功だけでなく、失敗も包み隠さず共有します。
精度未検証のまま自動化を進めようとした
最大の失敗は、評価項目の抽出精度を検証する前に、自動化を進めようとしたことです。
AIが「いい感じ」のアウトプットを出してくれたことで、「完成形」を見た気になってしまいました。しかし、実際には以下の検証ができていませんでした。
- 評価項目を正確に抽出できるか（精度検証）
- その評価項目が本当に商談化を分けるポイントなのか（因果関係の検証）
2つの検証項目の混同
ステップ2（重要ポイント抽出の精度検証）とステップ3（商談化要因の特定）を混同し、どちらも検証できていないのに、次のステップに進もうとしていました。
本来は、一つ一つのステップをクリアしてから次に進むべきでした。
AIのアウトプットに惑わされた
AIの推論能力が高いため、やろうとしていることの2-3歩先を踏まえたアウトプットまで出してくれます。これは便利な反面、今解くべき問題を曖昧にしてしまうノイズにもなり得ます。
改善ポイントまで自動的に出力されたことで、「これで完成だ」と思い込んでしまいました。
軌道修正の重要性
失敗に気づいた時点で、素早く軌道修正できたことは良かったです。
評価基準の精度検証とプロンプト調整に立ち戻り、50件の架電データでチューニングし、その後100件で因果関係を分析する。この地道な作業が、結果的に大きな発見につながりました。
失敗したことは残念ですが、失敗から学べたことは大きな財産です。
学んだこと
ここまでの取り組みを振り返って、特に「これは重要だな」と感じたことを共有します。
便利なまとめ
仮説検証の基本は変わらない
AIを活用する際も、基本的な仮説検証のプロセスは変わりません。
- 複数の仮説が折り重なっている時は一気に解こうとしない
- 一つ一つ丁寧に検証する
- ステップバイステップで、取り組むべき課題を明確にしてその検証だけを行う
これは、プロダクト開発でもビジネス仮説検証でも同じです。AIプロジェクトだからといって、基本を忘れてはいけません。
ミニマムでの検証が鍵
いきなりワークフローを組んだり、APIを叩くコードを書いたりするのではなく、まずはGUIで試してみる。
GPTやGeminiのGUIでファイルをアップロードして試してみるだけで、十分な検証ができます。
完成形が想像できるとすぐに手を動かして作りたくなる気持ちはわかります。僕もエンジニアなので、そうなりがちです。しかし、まずは最小単位で検証することが、結果的に近道になります。
今回のケースでは、フェーズ3でDifyのワークフローを先走って構築してしまいましたが、結果的にはフェーズ5での大量データ検証を効率化できました。これは不幸中の幸いでしたが、意図的に狙えることではありません。やはり基本に忠実に、ステップバイステップで進めることが原則です。
AIの特性を理解する
AIの推論能力は非常に高く、やろうとしていることの2-3歩先を踏まえたアウトプットまで出してくれます。
これは便利な反面、今解くべき問題を曖昧にしてしまうノイズにもなり得ます。
AIが何を出力しているのか、それは今解こうとしている課題に対して適切なのかを、常に意識する必要があります。
チームでの取り組みが成功の鍵
ISマネージャーや現場メンバーからのフィードバックが、精度向上の鍵でした。
実際の営業活動の感覚を反映したプロンプト改善こそが、実用的なツールを作る上で不可欠です。
技術だけで完結するのではなく、現場と一緒に作り上げていく。このプロセスが、本当に価値のあるツールを生み出します。
仮説とデータの両輪
ISマネージャーの経験と知見から仮説を立て、それをデータで検証する。この両輪があることで、確かな成果を生み出すことができました。
経験だけでも、データだけでも不十分です。両方を組み合わせることで、実践的で根拠のある知見が得られます。
おまけ（技術的tips）
今回の取り組みで得られた技術的tipsもいくつか共有しておきます。
Gemini APIのオプトアウト設定に気をつけるべし
Gemini APIはGoogle AI StudioとVertex AI Studioの2種類のプラットフォームから利用することができます。
違いについては以下記事でよくまとめられているので気になる方はどうぞ！
Google AI Studioの方は無料版だとオプトアウトを設定できなかったり（超重要）、細かい権限設定ができなかったりするので、Vertex AI Studio経由でのAPI利用をオススメします。
同じAPIでも入り口が2つあり、最初どちらを採用すれば良いか迷ったのでtipsとして記載しておきます。
SlackをトリガーにしてDifyを起動するには一癖あり
Difyを使って、以下のようなワークフローを構築しました。
- 音声ファイルを受け取る
- Gemini 2.5 Proで文字起こし
- Claude Sonnet 4.5で評価・分析
- 結果をフォーマットして出力
ローカル環境でのワークフロー構築は完了しており、あとはインターネット環境に載せるだけなのですがSlack連携を行うにあたって少し壁がありそうなことが分かりました（未対応）。
最終的な理想形は、「Slackに音声ファイルをアップロードすると、自動で分析結果とフィードバックが返ってくる」という仕組みです。
ですが、SlackのWebhookとDifyのエンドポイントのインターフェース（パラメータの形式）が合わなかったため、中間層を挟む必要があります。
具体的には、以下の2つの選択肢を検討しています。
| 選択肢 | メリット | デメリット | 適用シーン |
|---|---|---|---|
| GAS（Google Apps Script） | インフラ不要で手軽に実装できる | 公開API作成時のセキュリティに注意が必要（URLを知っていれば誰でもアクセス可能） | プロトタイプ・検証段階 |
| Lambda | より堅牢なセキュリティを実現できる | AWSインフラの構築が必要 | 本格運用時 |
ourlyでは、まずはGASでプロトタイプを作り、本格運用時にはLambdaへの移行を検討する方針です。
分析用プロンプトの生成もAIに任せるべし
今回、各フェーズで使用するプロンプトそのものも生成AIにほとんど作成してもらいました（もちろんレビューは入りましたが）
プロンプトの改善も、フィードバックMTGを録音し文字起こししたものをそのまま渡してプロンプトの改善を依頼するというフローで行ったため、効率的に改善を反映させることができました。
MTG録音→文字起こし→プロンプトに含めて改善ぶん投げ、という改善フローが無駄な情報の漏れがなく、的確に修正を行うことができたため、他でも使えそうだなという気づきになりました。
まとめ
IS架電構造化チャレンジの途中記録をお届けしましたが、このチャレンジはまだ途中です。完成したら、改めて記事で共有したいと思います。
最後に、読者の皆さんへのメッセージです。
AIを活用する際も、基本的な仮説検証のプロセスは変わりません。 エンジニアだからこそ、すぐに実装したくなる気持ちを抑えて、まずは検証する。この姿勢が、結果的に成功への近道になります。
この記事が、皆さんのAI活用や営業支援の取り組みの参考になれば嬉しいです。
それでは今回はこのへんで。最後まで読んでいただき、ありがとうございました！
Discussion