こんにちは、株式会社 ACES でサーバーサイドエンジニアをしている福澤 (@fuku_tech) です。
ACES は、オンライン会議を録画し、独自 AI による話者ごとの自動文字起こしや重要なシーンの可視化を行うことで、オンライン商談における成約率の向上と現場の工数削減に寄与する商談解析 AI ツール「ACES Meet」を提供しています。
今回は、先日プレスリリースが公開された ACES Meet の新機能である ChatGPT API を活用した AI まとめ機能の裏側についてご紹介します。
はじめに
近年、 AI 技術の発展に伴い、大規模言語モデルが実用的なアプリケーションで広く利用されるようになりました。 特に、 GPT シリーズのような革新的なモデルは、自然言語処理のさまざまなタスクで優れた性能を発揮し、多くの企業や研究者がその活用方法を模索しています。 これらの技術の進歩は、ビジネスプロセスの効率化や新たなサービスの創出に寄与していくことが期待されています。
そのような中弊社では、このような大規模言語モデルの力を活かすため、自社の商談解析 AI ツールである「ACES Meet」に大規模言語モデルを活用した AI まとめ機能をリリースしました。
本記事では、具体的なプロンプトの内容については割愛し、 ChatGPT API の性能を最大限に活かすための工夫や、 AI まとめ機能がどのような検証プロセスを経てリリースされたのかという点に焦点を当てて解説していきます。
AI まとめ機能を実現するための課題
AI まとめ機能を実現するにあたって、以下のような課題をクリアしていく必要がありました。
- 入力データの精度改善
- 長時間の会議・商談への対応
- 商談と商談以外の会議の性質の違いの考慮
- 適切なプロンプトの模索
以下ではそれぞれの課題に対してどのように取り組んだかについて説明していきます。
2-1. 入力データの精度改善
そもそもの大前提として、 ChatGPT API に渡す元々の入力データの精度が良くなければ、 ChatGPT API の真価を発揮できません。
この点については、元々、 ACES の独自アルゴリズムによる話者分割および文字起こしの精度が高い (※1) ことが分かっていたため、この前提条件は最初からクリアできていました。そのため、この部分は実際にはボトルネックにはなりませんでした。
詳細は後述しますが、入力データの精度が高いという前提条件をクリアしていることで、商談では特に誰の発言を中心に要約すべきかという情報をプロンプトに組み込むことができ、それが ACES Meet の AI まとめの精度向上に繋がっています。
(※1) https://prtimes.jp/main/html/rd/p/000000042.000044470.html
2-2. 長時間の会議・商談への対応
ChatGPT API はトークン長の制限があるため、長文を渡して要約をしてもらう場合は何かしらの工夫を施す必要があります。なお、トークン長は API 利用コストにも関係してくるため、金銭的な問題も発生してきます。
例えば、1時間の商談はおおよそ2万文字程度の文字数があるため、何らかの方法で文字数を圧縮しなければ、エラーになってしまうか、出力文が途中で途切れてしまいます。
そこで、長時間の会議・商談の要約を可能にするために、以下の2つのパターンをベースに AI アルゴリズムパイプラインの検証・構築に取り組みました。
案1: 社内アルゴリズムと ChatGPT API を併用する
1つ目の案は、 ACES の独自アルゴリズムである重要シーン抽出アルゴリズムを使用してまとめるべき発話を原文で抽出した後、 ChatGPT API に要約だけを依頼するようなパイプライン設計でした。
これにより、 ChatGPT API へのリクエストを最小限に抑えることができ、コストが安くなるというメリットもあります。
ただし、重要箇所を除き文章を全てカットしてしまうというロジックの都合上、意味のある要約を生成するために十分な情報が残らないことがあるという課題がありました。
案2: ChatGPT API をフル活用する
案1の検討中にタイミングよくOpenAI の API 提供が開始され、コストが約 1/10 になったことで、コスト面でも ChatGPT API だけで全ての処理を行うという案が現実味を帯びてきました。
具体的に考えたこととしては、発話データを一定間隔 (約3,000字ごと) で区切りながら各ブロックで要約し続け、出てきた複数個の要約をマージしたものに対して最終要約を行うというシンプルなものでした。
その結果、精度も上記の案よりも安定的に高いことが確認でき、かつ、 API 利用コストも許容範囲内に収まることが確認できたため、最終的にこちらの案を採用することにしました。
2-3. 商談と商談以外の会議の性質の違いの考慮
ACES Meet は主に商談向けのサービスですが、社内の議事録や採用シーンで利用されるお客様も多いため、商談以外の会議への配慮も必要でした。 商談に特化させすぎると、他のお客様の体験が悪くなる懸念があります。例えば、採用面談なのに商談特有の BANTC (※2) 情報の内容を一律で出してしまうと違和感を強く抱くことがあります。
そこで、事前に ChatGPT API に会議が商談かどうかを判定してもらうようにする工夫を取り入れました。なお、 ACES の独自アルゴリズムでも判定は可能とのことだったのですが、工数の関係等もあり、取り急ぎ ChatGPT API に判定をしてもらうようにしています。
これにより、商談の場合と商談以外の場合でプロンプトを分けることや、商談だと判定された時だけ商談特有の要約ポイントを組み込んだりすることが可能になりました。
(※2) BANTC とは、商談において重要とされる要素の頭文字をとったもので、 Budget (予算), Authority (決裁権), Needs (必要性), Timing (導入時期), Competition (競合) を意味します。一般的に、これらの要素を把握することで、商談が成功する可能性が高まると言われています。
2-4. より良い商談議事録を出力するためのプロンプト改善
ここまでの流れで、商談議事録を自動生成するための大枠の方針が決まりました。 そのため、後はチーム一丸となって、ひたすらプロンプトの最適化を進めていきました。
まず最初に、プロンプトの改善を効率的に実施するために、アルゴリズムエンジニアに上記のアルゴリズムパイプラインを動かせるデモ環境を構築してもらいました。 その結果、ビジネスチームを含む誰でも、そのデモ環境を使って思い付いたプロンプトを簡単に試し打ちすることができるようになったのと、複数人で並列かつ高速にプロンプトの改善を進めることが可能となりました。
その後、以下の項目について検証を進めていきました。
検証1: プロンプトの Tips を愚直に検証
社内のアルゴリズムエンジニアから、プロンプトエンジニアリングをするにあたってこれだけは読んでおいて！と言われた以下の資料を読み漁り、 step by step や few shot prompting 等の有名所は一通り試してみました。
- https://github.com/dair-ai/Prompt-Engineering-Guide
- https://github.com/f/awesome-chatgpt-prompts
- https://learnprompting.org/ja/docs/intro
- https://speakerdeck.com/smiyawaki0820/2023-dot-03-dot-21-gpt-4-prompt-bao-gao-hui
- https://dev.classmethod.jp/articles/how-to-design-prompt-engineering/
- https://twitter.com/forestone05/status/1639598446662524928?s=46&t=W6G4aN8cUyVTVqFbEsGjvw
なお、 ACES Meet の AI まとめにおいては、それらのテクニックを駆使しても劇的な効果が見られなかった (後述しますが、そもそも良いまとめとは何か？を言語化してプロンプトに落とし込むという作業の方が効果が高かった) ため、現状は深津式プロンプト・システムをベースとしたシンプルなプロンプトに落ち着いています。
検証2: プロンプトの分割単位の検証
AI まとめの 1st リリース時点では、「まとめ」「ネクストアクション」および、商談の場合のみ「商談ヒアリング項目 (BANTC)」の大項目を出すことを目指しました。 この時、選択肢としては一つのプロンプトで全ての大項目を出力させるか、大項目毎にプロンプトを分割するかの二択を考えていました。
後述のプロンプト改善項目を進めていく中で、プロンプトについても単一責任の原則のような考え方で、一つのプロンプトに対して一つのことに集中させた方が ChatGPT API は制約条件を聞いてくれやすく、安定した出力が得られる傾向が見られたため、最終的には後者を選択しました。
検証3: ChatGPT API への文字起こしデータの渡し方の検証
商談の特徴として、必ずその場に買い手と売り手が存在していることが挙げられます。 そこで、ただ単に文字起こしの内容だけを ChatGPT API に渡すのではなく、話者名もセットで渡し、更に誰が売り手で誰が買い手かという情報を与えることで、 ChatGPT API に買い手側の発言が重要度が高く、買い手側の発言を中心に要約してもらうようなプロンプトを用意しました。
その結果、 ChatGPT API に商談における重要ポイントを適切に伝えることができるようになり、意味のある要約が出力されやすくなりました。 これは、上述した文字起こしと話者分割の精度の高さがないと実現が難しいことであり、 ACES Meet における1つの強みだと考えています。 (それらの精度が低いと、 ChatGPT に間違った前提情報を与えてしまい逆効果になることが予想されます。)
また、全ての会話文を渡すべきか、前半部分はノイズが多いものと仮定して一律カットすべきかも併せて検証しました。
結果として、「まとめ」と「商談ヒアリング項目（BANTC）」については全ての会話文を渡した方が意味のある要約が出力される傾向があることが分かり、「ネクストアクション」については、商談の前半を思い切ってカットすることで、ネクストアクションとして違和感のある項目が減少する傾向が掴めたため、 ChatGPT API に渡す前にあえてデータをカットして渡すようにする工夫を入れています。
検証4: 出力形式の検証
ソフトウェア上で ChatGPT API からの出力結果をハンドリングしやすくするために、どの出力形式がベストかについての検証も行いました。
まずは JSON フォーマットでの出力を検証しました。 JSON での出力におけるメリットは文字列をパースできれば、その後の処理が容易に操作可能であることです。 一方、デメリットとしては以下のようにフォーマットが指定通り出てくれなかった場合や、トークン長の問題で出力が途中で切れてしまった場合のエラーハンドリングが煩雑なことが挙げられます。
配列を期待しているが配列になっていない例
{ "summaries": "str" }
フォーマットは正しいが不要なまとめ文章が最後に付記されている例
{ "summaries": ["str"] } この商談では、xxxについて話し合われていました。
出力が途中で切れてしまった例
{ "summaries": ["too long str...
JSON の場合は、上記のようなイレギュラーな出力がどうしても一定確率 (体感で数%程度) で発生してしまうことで、 AI まとめが出力できないという問題がユーザー体験を悪化させてしまう懸念が強く残ったため、次に箇条書きでの出力も検討しました。
箇条書きで出力する場合は、出力結果を自前のロジックで後処理していく必要はあるものの、箇条書き形式になっていないイレギュラーなパターンの場合は一律で無視するなど、柔軟に調整がしやすいというメリットがあります。 例えば、出力結果が以下のような文字列だった時は、正しく箇条書きになっているもののみを残すようなことをルールベースで実装すれば、簡単にノイズを削除することができます。
- まとめ
\t- インデント付きの箇条書き
箇条書きになっていない項目
それぞれのメリット・デメリットを踏まえた上で、 今回は AI まとめが出力できないことによるユーザー体験の悪化を防ぐことが最重要だと考え、箇条書きを採用することにしました。
検証5: 良いまとめとは何か？を言語化してプロンプトに反映
ここまでで、様々な説明をしてきましたが、私の体感として、結局、「良いまとめとは何か？」についてヒアリングし、仮説を立て、言語化し、プロンプトに反映させるという地道な作業の繰り返しが、意味のある要約になるかを分けるポイントだったと感じています。
上述のプロンプト改善と並行して、ビジネスチームに「良いまとめとは何か？」についてのヒアリングを行った結果、特に重要な部分が明確になりました。
一例として、以下の点が挙げられます。
- 箇条書きの個数や文字数については、適切な範囲を越えないことが極めて重要
- ネクストアクションに関しては、担当者とセットで出力すべき
- 商談においては、売り手側の発言よりも買い手側の発言の方が重要度が高い (実際に、営業マンが商談議事録を作成する際は、お客様の発言を中心に記載している)。
これらの重要項目を可能な限り外さないような制約条件をプロンプトに組み込むことで、より満足度の高い「まとめ」「ネクストアクション」「商談ヒアリング項目 (BANTC)」を出力できるようになりました。
なお、これらの外すべきでないポイントをプロンプトだけで何とかしようとするのではなく、 ChatGPT API の苦手な部分 (※3) をアプリケーション側でもルールベースで補完していくような設計もユーザー体験をより良いものにしていく上で重要だと考えています。
(※3) 例えば、 体感として、ChatGPT API は個数や文字数に対する制約に対してはあまり言うことを聞いてくれない時が多いです。
AI まとめ機能リリース後の反響
開発当初からアルゴリズムチームおよびビジネスチームの方々と密に連携し、多くの意見や提案をもらいながら、約3週間という短い開発期間の中、何周も何周も上記の項目についてPDCAサイクルを回すことができました。
これは、今回の開発に携わった全員が、ただ単に ChatGPT API を利用するのではなく、意味のあるもの・実際に使いたいと思ってもらえるものをお客様に提供したいという情熱を持っていたからこそできたことだと感じています。
上記のような流れで作り上げられた AI まとめ機能ですが、リリース後に社内外問わず沢山の方々から以下のような反響をいただくことができたのでいくつかご紹介します。
■ 社外のお客様からの反響
■ 社内ユーザーからの反響
以上のように、リリース後に沢山の反響をいただくことができました。一方、まだまだブラッシュアップすべき部分は沢山残っているため、今後もさらなる改善と機能追加に努めてまいります。
まとめ
本記事では、商談解析 AI ツール「ACES Meet」における ChatGPT API 活用についてご紹介しました。
1st リリース後も、沢山の喜びの声をいただいている機能ですが、改善の余地が多く残っています。 そのため、今後も継続して改善を行い、営業マンのより効率的な議事録作成や、商談時の生産性・パフォーマンスの向上に役立てられるように努めてまいります。
これを実現するために、現在、ソフトウェアエンジニアをはじめ、NLPのアルゴリズムエンジニアなど幅広く募集しています。弊社の取り組みにご興味をお持ちいただける場合は、下記の募集ページから是非ご応募ください！
Serverside Engineer open.talentio.com
Front-end Engineer open.talentio.com
Algorithm Engineer（自然言語処理・音声認識） open.talentio.com
