「応対評価は、もうAIに任せられるのではないか」。コンタクトセンターの品質管理（QA）に関わる人なら、一度は考えたはずです。

従来の応対評価は、SVやQA担当者が全体の数%をサンプリングして聞き、モニタリングシートに沿って採点する仕事でした。LLMを使えば、この採点を全件・毎日実行できます。全件・毎日やることに意味があるのか？という論点はいったんおいておいて、解説を進めます。

実際、文字起こしAPIとLLMを組み合わせれば、動く評価AIは数日で作れます。作れるかどうかは、もう論点ではありません。

しかし、点数が出ることと、その点数で応対品質が上がり続けることは、別の問題です。私たちが見てきた内製プロジェクトの多くは、構築でつまずくのではなく、「AIの採点を現場が信頼し、改善につながる」状態を維持する段階で止まります。

この記事では、内製の7ステップを実務の順番で解説したうえで、本当に難しいのはどこか、そして内製とSaaSをどう使い分けるべきかまで踏み込みます。

全体像：7ステップと「育てるループ」

先に全体像を示します。ステップ1〜2が設計、3〜5が構築、6〜7が検証と運用の入り口です。

注目してほしいのは、ステップ7からステップ1へ戻る点線の矢印です。評価AIは一度作って完成するものではなく、AIと人間の採点の不一致を評価基準に還流させるループを回し続けることで、初めて現場に信頼される採点になります。

ステップ1：評価基準を棚卸しし、「測れる基準」に翻訳する

最初にやるべきことは、ツール選定でもプロンプト作成でもなく、いま使っているモニタリングシートの棚卸しです。

多くの組織の評価シートには、「お客様に寄り添った対応ができている」「丁寧な言葉遣いである」といった項目が並んでいます。人間の評価者は経験でこれを解釈できますが、書いてあるままではAIは採点できません。人間同士でも、実は解釈がずれています。

やることは、各項目を判定可能な文に分解する翻訳作業です。

「寄り添った対応」なら、「顧客の発話を遮っていない」「不満の表明に対して謝辞または共感の言葉を返している」「顧客の名前や状況を復唱して確認している」のように、応対ログの中に根拠を指させるレベルまで具体化します。

このとき、翻訳できない項目が必ず残ります。声のトーンの温かみのような、テキストから判定しようがないものです。それらは初期リリースの対象外と明記します。ここで「何を測らないか」を決めておくことが、後続のすべてのステップの分母を小さくします。

• 例（架空の通販コールセンター・B社）：
  既存のモニタリングシートは18項目あった。棚卸しの結果、「オープニングで名乗っている」など判定文に翻訳できたのは12項目。「声の明るさ」など3項目は対象外とし、残り3項目は2つに分割・統合して、最終的に14の判定項目に再編した。

ステップ2：スケールと、納得されない時の運用を設計する

構築に入る前に、もう1つ決めるべきことがあります。採点の形式と、その採点が受け入れられなかった時に何が起きるか、です。

採点形式は、項目ごとの2値判定（できている／できていない）を推奨します。5段階評価は一見きめ細かいですが、「3と4の違い」は人間の評価者間でも一致しません。人間がぶれる基準は、AIも同じようにぶれます。総合点が必要なら、2値判定の積み上げで算出する方が、後から根拠をたどれます。

そして評価AI特有の論点が、納得性の設計です。AIの採点はオペレーターの育成や処遇に触れる情報です。

低い判定が出た時に、本人やSVが根拠を確認できるのか。納得できない場合に人による再評価を申し立てられるのか。AIの点数がそのまま人事評価に直結するのか、あくまでコーチングの参考情報なのか。

これらはプロンプトの問題ではなく、業務と組織の意思決定です。あわせて、この取り組み自体のKPIもここで定義します。推奨は評価カバレッジ（全応対のうち評価された割合）と人間評価との一致率の2つです。

• 例：
  B社は14項目すべてを2値判定とし、「AIの判定は当面コーチングの参考情報とし、人事評価には使わない」「オペレーター本人が根拠ログを確認でき、SV経由で再評価を申請できる」と文書で決めた。KPIはカバレッジ100%（従来3%）と、一致率85%以上と置いた。

ステップ3：応対データを整備し、基準の「正」を1つにする

評価AIの品質は、モデルの賢さよりも入力データと基準の質で決まります。内製プロジェクトで最も時間がかかるのは、実はこのステップです。

データ整備の中心は、電話応対なら文字起こしです。評価の材料となるテキストの精度が低ければ、その上でどれだけプロンプトを磨いても採点は歪みます。確認すべきは3点です。

第一に、話者分離（オペレーターと顧客の発言が区別できているか）。誰が謝ったのかが分からない文字起こしでは、応対は評価できません。

第二に、自社の商品名や業界用語が正しく起こせているか。必要ならカスタム語彙を登録します。

第三に、個人情報のマスキングです。氏名・住所・カード番号などを外部APIに送る前に処理するのか、契約上送ってよいのかを、法務・セキュリティ部門と先に握っておきます。チャットやメールの応対はこの負荷が軽く、内製の最初の対象として向いています。

もう1つが、基準の「正」を1つにすることです。多くの現場には、公式のモニタリングシートのほかに、SVごとの採点メモ、研修資料、暗黙の運用が併存しています。シートでは「クッション言葉を使う」とあるのに、ベテランSVは「多用しすぎも減点」と教えている、という矛盾を放置したままAIに学ばせると、どちらかをランダムに引いた採点になります。

ステップ1で翻訳した判定文を唯一の基準ドキュメントと定め、項目ごとに更新責任者を決めます。責任者のいない基準は、公開の日から劣化が始まります。

• 例：
  B社の文字起こしは、話者分離までは既存の通話録音システムで対応できたが、自社商品名の誤変換が多く、カスタム語彙200語を登録した。個人情報は文字起こし直後にマスキングする前処理を挟むことで法務の承認を得た。評価基準はSV3名の採点メモをすべて回収し、矛盾していた5項目を議論のうえ一本化した。

ステップ4：評価パイプラインの最小構成を組む

ここから技術の話に入ります。ただし、最初から凝る必要はありません。応対評価AIの最小構成は次の4層です。

1. 文字起こし層：
   通話録音をテキスト化します。商用の音声認識APIを使うのが標準です。チャット・メールの評価から始めるなら、この層は不要です
   

2. 前処理層：
   話者分離の整形、個人情報のマスキング、評価対象の切り出し（保留時間の除去など）を行います。地味ですが採点品質への影響が大きい層です
   

3. LLM判定層：
   判定項目ごとにLLMを呼び出し、判定と根拠を出力させます。14項目を1回のプロンプトでまとめて判定させる構成は、実装は楽ですが精度が落ちます。項目ごと、または関連する数項目ごとに分けて判定させるのが基本です
   

4. 集計・表示層：
   判定結果をデータベースに格納し、オペレーター別・項目別・期間別に見られるダッシュボードにします。既存のBIツールで十分です

精度が足りない場合の改善手段として、判定の難しい項目だけ複数回判定させて多数決を取る方法や、より高性能なモデルへの切り替えがあります。ただしこれらは、まず最小構成で動かして一致率を測ってから足すべきものです。最初から全部盛りにすると、どこが効いているのか分からなくなります。

• 例：
  B社はチャット応対から着手し、文字起こし層を後回しにした。14項目を「オープニング」「本人確認」「問題解決」「クロージング」の4グループに分け、グループごとにLLMを呼び出す構成を2週間で動かした。ダッシュボードは使い慣れた既存BIツールに接続しただけだった。

ステップ5：採点手順書を書く

評価プロンプトというと、短い命令文を想像するかもしれません。しかし実務で機能するのは、新任のQA担当者に渡す採点マニュアルに近い文書です。私たちはこれを採点手順書と呼んでいます。

項目の定義から、判定の手順、根拠の示し方、判定に迷う境界例の扱いまでを1つの手順書として書き上げ、それをそのまま判定プロンプトにする、という考え方です。

手順書で定義すべきことは、大きく4つです。

項目の定義と判定文（ステップ1の翻訳結果）、判定の手順（「まず該当箇所をログから探し、なければ『該当なし』とする」のように、結論より先に根拠を探させる）、出力の形式（判定・根拠となる発言の引用・引用位置を必ずセットで出力させる）、そして境界例です。「顧客が雑談を始めた場合の共感はどう扱うか」のような迷いやすいケースは、実例と正解の判定をセットで手順書に載せます。

人間の研修で使う「ケーススタディ」と同じものが、そのままfew-shot例になります。

禁止事項も明文化します。根拠を引用できない判定を出さない。ログに書かれていない意図を推測して減点しない。判定に迷う場合は無理に判定せず「要人間確認」と出力する。この「わからないと言える設計」が、現場からの信頼を大きく左右します。

• 例：
  B社の採点手順書は、判定文・手順・出力形式に加えて、SV間で判定が割れた過去の実例12件を境界例として収録した。出来上がりは、新任QA担当の研修資料とほぼ同じ構成になった。

ステップ6：人間の採点と突き合わせ、一致率を測る

「なんとなく良さそう」で運用を始めてはいけません。実際の応対ログから100件程度を抜き出し、経験のあるSV・QA担当者が採点した結果とセットにしたキャリブレーションセットを作ります。これに対してAIの判定を突き合わせ、項目ごとの一致率を測ります。

このとき先に測っておくべき数字があります。人間同士の一致率です。同じ100件を2人のSVが独立に採点すると、多くの組織で一致率は8〜9割にとどまります。人間同士が85%しか一致しない項目で、AIに95%を求めるのは筋違いです。人間同士の一致率が、実質的な天井になります。

そして不一致の分析こそが、このステップの最大の成果物です。AIと人間の判定が割れた箇所を見ていくと、AIの間違いと同じくらい、基準そのものの曖昧さや人間側の採点のぶれが見つかります。評価AIづくりは、自社の評価基準を初めて厳密に言語化するプロセスでもあるのです。

• 例：
  B社の初回の一致率は項目平均71%だった。不一致を分析すると、AIの誤判定は4割で、残り6割は基準の曖昧さとSV採点側のぶれだった。境界例を手順書に8件追加し、基準を2項目改訂して再評価したところ、一致率は88%まで改善した。モデルは一度も変えていない。

ステップ7：小さく運用を始め、不一致ログで育てる

運用は小さく始めます。最初から人間の評価を置き換えるのではなく、1チームに限定して、SVの採点とAIの判定を並走させる期間を設けます。SVが自分の採点とAIの判定を見比べ、納得できない判定に印をつける。この不一致と異議のログこそが、次に磨くべき基準と手順書のリストです。

週次で不一致ログをレビューし、手順書の境界例を追加し、キャリブレーションセットに新しいケースを足す。このループを回した分だけ一致率と現場の信頼は上がっていきます。並走期間で信頼ができてから、サンプリング評価を全件評価に切り替え、SVの時間を「採点する仕事」から「採点結果をもとにコーチングする仕事」に移していきます。逆に言えば、このループが止まった評価AIは、基準の変化に置いていかれ、静かに「誰も見ない点数」になります。

• 例：
  B社はまず1チーム・12名で4週間の並走期間を設けた。SVからの異議は初週の23件から4週目には4件まで減り、翌月から全チャット応対の全件評価に切り替えた。SVのモニタリング時間は週11時間から3時間に減り、浮いた時間は1on1コーチングに充てられた。

内製の壁は「8歩目」にある

動くものは数日で作れても、基準の翻訳や一致率検証まで含めたここまでの7ステップには、エンジニア1〜2名とQA実務者で数週間から数ヶ月かかります。内製の本当の壁はその先にあります。それは、採点が出続けることと、品質が上がり続けることの間の溝です。

具体的にはこうなります。全件評価のスコアは出ているが、フィードバックとコーチングの運用に接続されず、ダッシュボードが「見られない数字」になる。商品改定やトークスクリプトの変更のたびに基準の改訂が必要なのに、更新が「余裕がある時にやる仕事」に格下げされ、採点が実態とずれていく。LLMのモデルが更新されるたびに判定の傾向が変わり、キャリブレーションのやり直しに想定外の工数が発生する。

どれも技術的には解決可能ですが、解決し続けるには専任に近い体制が必要です。作るのは1回のプロジェクトですが、育てるのは終わりのない業務です。内製を検討するなら、構築の工数ではなく、この運用体制を確保できるかを先に問うべきです。

内製かSaaSかを分ける4つの判断軸

内製とSaaS、どちらが正しいという話ではありません。判断軸は次の4つです。

1. エンジニアリソースの常設：
   構築時だけでなく、モデル更新への追随や基準改訂の実装に継続的にエンジニアを割り当てられるか。割り当てられないなら、再校正の仕組みが製品側に組み込まれているSaaSに分があります
   

2. 評価基準の変化頻度：
   商品・キャンペーン・スクリプトの入れ替わりが激しいほど基準メンテナンスの負荷が上がり、更新運用の仕組みの差が効いてきます
   

3. 要件の特殊性：
   金融・医療のような業界固有のコンプライアンス項目や、独自の育成体系との連携が中核要件にあるなら、内製の価値が出ます
   

4. コスト構造：
   内製は初期が重く運用も人件費が続く、SaaSは月額が続く。3年の総所有コストで比べると、直感と逆の結果になることがよくあります

実務では二者択一でもありません。チャット応対の評価は内製で経験を積み、負荷の重い電話応対の評価はSaaSに任せる、といった併用は現実的な解です。

私たちは「採点」ではなく「育てるループ」が本体だと考える

私たちは、応対評価AIの本体はスコアを出す仕組みではなく、基準を磨き続け、採点結果をコーチングにつなぐ運用のループだと考えています。

だからこそ、内製という選択肢を否定しません。この記事の7ステップを実際にやり切った組織は、自社の「良い応対とは何か」を初めて厳密に言語化することになり、その言語化はどのツールを使っても資産になります。一方で、そのループを自社で回し続けることが難しいなら、ループそのものを製品として提供するSaaSに任せるのは、撤退ではなく合理的な設計判断です。

あなたの組織が確保すべきなのは、応対を採点する技術でしょうか。それとも、良い応対の基準を磨き続け、人の成長につなぐ体制でしょうか。内製を検討しているすべてのチームに、この問いを置きたいと思います。

評価から育成までを含めた応対品質マネジメントの設計に関心のある方は、お気軽にお問い合わせください。