コールセンターの品質保証(QA):スコアカードの実際の仕組み
Riellvriany Indriawan
Katelin Teen
最終更新 July 7, 2026

コールセンターの品質保証が実際に意味すること
サポートチームは遅かれ早かれ、「自分たちは本当に良い仕事をしているのか、それともそう感じているだけなのか」という問いに行き着く。品質保証(QA)とは、この問いに対する答えをプロセスに落とし込んだものだ。通話・チャット・メール・チケットといったサポート対応を定められた基準と照らして体系的にレビューすることで、「良いサービス」が単なる感覚ではなく、マネージャーが指し示せるスコアになる。
ほとんどのQAプログラムの土台にある仕組みがスコアカードだ。これは、会話を読んだり聞いたりした後にレビュアー(人間、そして近年はAIが増えている)が記入する、重み付けされた評価カテゴリーを持つ構造化された評価フォームである。Zendeskが述べているように、スコアカードは「エージェントのパフォーマンスを評価し、改善すべき点を特定し、チームが組織の目標を達成できるようにする」ために存在する。QAはワークフォーススケジューリングや需要予測と並んで、**ワークフォース・エンゲージメント・マネジメント(WEM)**という総称の傘の下に位置づけられており、Zendeskを含むほとんどのベンダーが、このスイートの2〜3のモジュールの1つとしてQAを販売している。
これはチームが成長するにつれて重要性が増す理由がある。3人のエージェントからなるチームであれば、マネージャーがすべてに目を通せばQAは成立する。30人のチームではそうはいかない。スコアカードとサンプリングがあって初めて、マネージャーが一件一件チケットを読まなくても、何百人ものエージェントに対して比較可能なスコアをQA機能が生み出せるようになる。これらはコーチングの材料でもある。「もっと丁寧に」という漠然とした1on1のコメントではなく、「このエージェントは決まって締めの一文を省略している」という具体的な指摘ができるようになる。そして金融サービス、ヘルスケア、債権回収といった規制業界では、QAスコアカードが法的な重みを持つことも多い。開示事項の見落としはスタイルの問題ではなく、コンプライアンス違反そのものだ。
ビジネス上のメリットも抽象的な話ではない。Zendesk自身のQA製品ページによると、ラジオ局ネットワークのAudacyは構造化されたQAを導入後、エージェントの生産性が19%向上し、一発解決率が15%上昇したと報告している。Kahoot!はCSATが5ポイント上昇し、実際にレビューされたチケットの割合が150%増加した。LibertyはCSATが+2.3%、社内品質スコアが+4%向上したと報告している。これらはどれもQAのためのQAという数字ではなく、チームが自分たちの死角にようやく気づけるようになったときに起きることだ。
QAスコアカードが実際にどう機能するか
ベンダーのダッシュボードを取り払ってしまえば、スコアカードは単なる加重平均にすぎない。正確性、トーン、共感、文法、解決度、コンプライアンスといった各カテゴリーに、0から100の評価尺度と重みが設定される。Zendeskのドキュメントはその計算方法についてはっきりと述べている。「対応のレビュースコアを算出するには、各カテゴリーのスコアにその重みを掛け合わせ、合計を重みの合計で割ります。」ドキュメント作成のスタイルよりも根本原因の理解を重視するチームは、根本原因の重みを高く設定すればいい。あとは計算式が処理してくれる。
どの尺度を選ぶかは、スピードと精緻さのトレードオフになる。Zendesk QAは4種類の尺度を用意している。
| 尺度 | 内容 | 向いている場面 |
|---|---|---|
| バイナリ | 良い / 悪い | 大量のチケットを素早くレビューする場合 |
| 3段階 | 良い / まずまず / 悪い | もう少し細かく、かつ迅速に |
| 4段階 | 良い / やや良い / やや悪い / 悪い | 中間の逃げ道をなくし、決断を迫る |
| 5段階 | A〜E形式の採点 | 最も詳細なフィードバックだが採点に最も時間がかかる |
成熟したQAプログラムでは、2つの仕組みが大きな役割を果たす。1つ目はクリティカルカテゴリーだ。「解約手数料を開示したか」をクリティカルに設定すれば、そこで不合格スコアが出た瞬間、返信の残りの部分がどれだけ丁寧で誤字がなくても、レビュー全体が0%になる。これは、コンプライアンス上の見落としが良いトーンによって平均でごまかされないようにするために、規制業界のチームが引くレバーだ。2つ目は根本原因タグ付けだ。単に「共感:悪い」と採点するのではなく、レビュアーがあらかじめ用意されたリストから理由を選ぶ。これによって初めて、QAデータはエージェントが反発するだけの数字ではなく、コーチングに実際に役立つものになる。
Zendesk QAの自社製AutoQAシステムには、チケットがクローズされた瞬間に自動で採点される8つのデフォルトカテゴリーが搭載されている。
| カテゴリー | チェックする内容 |
|---|---|
| 挨拶 | エージェントは顧客に挨拶したか |
| 共感 | エージェントは相手の悩みに共感していたか |
| スペルと文法 | 誤字、スペルミス、文体上のミス |
| クロージング | 適切に締めくくり、さらなるサポートを申し出たか |
| 解決策の提示 | チャット中に解決策を提案したか |
| トーン | 7つの基本トーン(明るい、支援的、落ち着いているなど)に分類 |
| 読みやすさ | 単語の難易度と文の長さ |
| 理解度 | エージェントは問題を実際に理解していたか |

ここで計算をミニチュアで示してみよう。正確性の重みが40、トーンの重みが20、コンプライアンスの重みが40だとする。あるエージェントが正確性で90%、トーンで100%、コンプライアンスで80%のスコアを取ったとする。重み付けすると、(90×40 + 100×20 + 80×40) ÷ 100 = 88%になる。重みを変えれば、同じ実際のパフォーマンスからでも異なる見出しの数字が生まれる。だからこそキャリブレーション(後述)がこれほど重要になる。

サンプリング:静かに機能しなくなった計算式
QAの歴史のほとんどにおいて、人間のレビュアーはすべての対応を聞いたり読んだりすることはできなかった。そこでチーム全体がこの領域をランダムサンプリングを中心に構築してきた。エージェント1人あたり週に何件かのチケットを抜き出し、採点し、そこから全体を推測するというやり方だ。
問題は、この計算がチームレベルでは問題なく見えても、エージェントレベルでは破綻することだ。Leo Gasperinは、自身の元チームについてLinkedInの投稿で率直にこの点を説明している。彼らは月に200時間をかけて厳格な基準でチケットをレビューしていたにもかかわらず、それでもチケット総量の約5%しかカバーできていなかった。1人のエージェントが月に約500件のチケットを扱っているとして、週に5〜10件をレビューするだけでは、QAダッシュボード上のサンプリング率が問題なく見えたとしても、そのエージェントについて統計的に信頼できる評価は得られない。彼が示した解決策は、そのままの言葉で言えばこうだ。「AIエージェントを評価者として設定し、100%を監査したうえで、問題があったものだけをレビューする。」同じ投稿にコメントしたShubhashree S.氏は、この失敗のパターンを一言でこう言い表した。「サンプリングは自信を生むが、明確さは生まない。」
これは少数派の不満ではない。G2では、MaestroQAのレビュアーであるExecutive Directorが、それ以前の状態を率直に「チケットのランダムサンプリングでQAを行っていた」と述べたうえで、「ターゲットを絞ったQA」を可能にするツールに切り替えたと説明している。航空業界のサポートを担当するSenior Advisorがevaluagentについて語った内容も、視点は違えど同じ話だ。彼は、AI AutoQAが解決しようとしている問題そのものをこう名指ししている。「QAサンプリングによる可視性の限界を解消し、手動レビューにかかる時間と労力を削減する。」

キャリブレーション:レビュアー同士に本当に意見を揃えさせる
スコアカードが機能するのは、2人のレビュアーが同じチケットを採点したときに同じ結論にたどり着く場合だけだ。この意見をすり合わせる作業はキャリブレーションと呼ばれ、Zendesk自身の定義はまさに言葉通りの内容だ。「すべてのレビュアーに同じ会話のバッチを評価してもらい、スコアとコメントを比較する……これにより、レビュアーの評価が揃い、レビュー担当者が誰であってもエージェントに一貫したフィードバックが提供されるようになる。」
仕組みとしては、通常「まず個別にレビューし、そのあとで議論する」という流れで進む。レビュアーが個別に採点し、マネージャーが1件をベースラインとして指定し、グループでギャップをすり合わせる。多くの場合、意見が割れた際の最終判断はQAリードが行う。実際にすり合わせが必要になるのは、大きな論点であることはめったになく、たいていはエッジケースだ。ある会話でまったく登場しなかったカテゴリーはどう採点すればいいのか。フィードバックの文章はどのくらいの長さが適切か。キャリブレーションのスコアは意図的にエージェントの実際のInternal Quality Scoreから切り離され、独自のダッシュボードで管理される。これは、この取り組みがレビュアーを訓練する場であり続け、隠れた2つ目の採点チャンネルにならないようにするためだ。ほとんどのチームはこれを月次で実施している。
AIが会話の100%をレビューする方向へのシフト
私が調べた主要なQAベンダーはすべて、同じ売り込み方に収斂しつつある。それをはっきりと名指ししておく価値がある。AIがすべての対応をレビューし、手動サンプリングを完全に置き換える一方で、スコアカードとキャリブレーションという構造そのものは土台として維持されている。
Zendesk QA(旧Klaus)はAutoQAを前面に押し出しており、音声・チャット・メール・AIエージェントのトランスクリプトにまたがる会話の100%を採点する。管理者はコードを書かずに、プレーンな言葉でカスタムのプロンプトベースのカテゴリーを作成できる。Spotlight機能は、人間が該当スレッドを1つずつ読まなくても、解約リスクやナレッジギャップを自動で検出する。Real-time QAは、事後ではなく会話がまだライブの間に問題を表面化させる。

私が最も興味深いと感じたのはAI Agent QAだ。人間のエージェントに使われているのと同じ採点基準を、ボットにも適用している。Zendeskは人間のエージェントとAIエージェントのスコアを明示的に並べて比較し、ボットのどこを改善すべきかを見ている。これは静かに、考える価値のあることを裏付けている。AIエージェントが実際のチケットを扱うようになった以上、それはソフトウェアだからという理由でQAを免除されるのではなく、QAプロセスを必要とするということだ。

**MaestroQA**は「QAツール」というブランディングからさらに距離を置き、今では自らを会話データプラットフォームと呼んでいる。同社のホームページ自体がこの方向転換をこう率直に表現している。「私たちはコンタクトセンターQAの会社として始まった……2023年にChatGPTが登場して以来、会話データの分析はCレベルの優先事項になった。」同社のDraftKingsのケーススタディは、手動のQAレビューを完全に置き換えるものとして描かれており、BrexはQAプロセスを同プラットフォーム中心に再構築した後、リスクのある顧客の検出数が20倍に増えたと報告している。これは非常に大きな増加であり、ケーススタディによれば、BrexのCOOはある一度のプレビューを見ただけで「もう手動QAはいらない」とチームに伝えたと言われている。
現在はNICEの一部となったPlayvoxも、より広範なワークフォース・エンゲージメントスイートの中で同様の役割を果たしている。柔軟なスコアカード、キャリブレーション、Zendesk/Salesforceとのネイティブ連携などだ。ただしそのマーケティングページはスクレイピングを積極的にブロックしているため、Playvoxに関する詳細は検証済みというよりも参考情報として扱ってほしい。
| Zendesk QA | MaestroQA | Playvox | |
|---|---|---|---|
| ポジショニング | Support/Suiteに対するQAアドオン | 会話データプラットフォーム | WEMスイート内のQA(現在はNICEの一部) |
| カバレッジモデル | AutoQAが会話の100%を採点 | 手動サンプリングを置き換えるAIレビュー | カスタムスコアカード、AIカバレッジ率は未確認 |
| AIエージェントも採点するか | あり - AI Agent QA | あり - ボット/チャットボットのモニタリング | 未確認 |
| キャリブレーション | 組み込み、ベースライン比較 | 主眼ではない | 組み込み |
| コンプライアンス | SOC 2 Type 2、GDPR、HIPAA対応 | 非公開 | 非公開 |
| 価格 | アドオン、非公開 | 見積もり制 | 見積もり制 |
現場の実務者たちは、採点というよりコーチングという捉え方を裏付けている。独立契約者として働くあるMaestroQAレビュアーは、うまい言い方をしている。「品質レビューを単純な『合格/不合格』のテストのように扱うのをやめさせ、実際に人を育てる方法に変えてくれる。」そして、マネージャーではなく実際に日々採点作業をしている本物のQAアナリストは、MaestroQAを2年半使ってきた経験について、「最初はエージェントとして自分の品質スコアをモニタリングする立場で、今はQuality Analystとしてすべての採点業務を行っている」と述べ、そのプロセスを「非常にわかりやすい」と評している。
摩擦がまったくないわけではない。通信業界のあるFounderはG2で、実際のコストに関する落とし穴を指摘している。「AI機能は追加購入が必要で、コストを大きく押し上げる。」AIスコアリングは基本のQA製品に無料で追加されるアップグレードではなく、追加の費目として予算に組み込んでおくべきだ。そしてevaluagentのOperations担当役員は、エージェント側から見た小さいながらも実際にあるUX上の不満を挙げている。スコア通知のメールにはレビューが行われたことしか書かれておらず、実際の結果は書かれていないというもので、彼はそれを「落ち着かない」と表現し、「不安になり、すぐにEvaluagentを開いてしまう」ものだと述べている。技術的にどれだけ厳密なQAプログラムであっても、エージェント側からすると校長室に呼び出されるような感覚になってしまえば、印象は悪くなりうる。
レビュー対象がAIであり、人間ではないとき
ここからは、私自身が持っている具体的な数字の話になる。AIエージェントがキューに加わったとき、QAプログラムが答えなければならないのはまさにこの問いだからだ。「そのAIはそれらしく聞こえるか」ではなく、「人に対して行うのと同じスコアカードに照らしても通用するか」という問いだ。
あるeコマースチームの実際のZendeskトラフィックに対して行ったクロスバリデーション済みの試験で、eeselのAIはトリアージ精度93%、スパム検出100%(誤検知ゼロ)を達成した。対象の受信箱ではスパムが全体量の22%を占めていた。ドラフトの方向性の正確さ(directional accuracy)は88%で、返信の中身が10回中ほぼ9回は正しい方向に向いていたことを意味する。しかし、そのまま送信された下書きはわずか12%で、事実誤りの発生率は7%だった。カテゴリー別のパフォーマンスにはばらつきがあり、返品・返金の下書きは93.8%の頻度で有用と評価され、保証関連は96.4%、商品に関する問い合わせと返金ステータスの確認はどちらも100%に達した。

方向性の正確さ88%と、そのまま送信された割合12%との間にあるこのギャップこそ、じっくり考える価値がある。エージェントがAIの判断を信頼していなかったわけではない。実際に支配的だったパターンは「ざっと見て書き直す」というものだった。エージェントは8〜15文からなる下書きを、送信前に1〜3文にまで削っていた。この書き直しのパターンを分解してみると、およそ65%は純粋に長さとトーンの編集であり、これはチームが過去に実際に送信した返信でエージェントを学習させれば解決できるものだった。さらに20%は、生きたERPや物流のステータスなど、AIがまだ接続されていないデータを必要とするものだった。下書きが完全に事実として間違っていたために書き直された割合は、わずか5%程度だった。直近のエージェントの返信200件のサンプルで学習させたところ、そのまま送信される割合は12%から、その後のフォローアップテストでは30〜40%の範囲まで上昇した。
このことを取り上げるのは、これがまさに本物のQAスコアカードが表面化させるべきパターンであり、チケットの5%しかサンプリングしていなければ見えなくなってしまう類のパターンだからだ。もしあなたのQAプログラムが、AIエージェントの下書きが「間違っている」のか、それとも単に「チームの書き方とスタイルが違う」だけなのかを見分けられないのであれば、それは実際には品質を測定しているのではなく、余計な手間をかけて雰囲気を測定しているにすぎない。
その違いは、顧客が実際の返信を目にする前の段階でも表れる。eeselを評価していたあるプロスペクト、ベルギーのある企業のサポートリードは、実際のチケットでツールを信頼する前に、自ら67項目のテストを組み立てて評価し、ナレッジの回答を全体的に「しっかりしている」と評価した(最終的に彼が見送ったのは無関係な理由、つまりチャットウィジェットの速度であり、回答の質ではなかった)。これはベンダーではなく買い手自身が実行する、小規模なQAプロセスそのものであり、AIエージェントを評価するすべてのチームに持ってほしい感覚でもある。「デモの出来が良い」ことを、そのままスコアカード代わりにしてはいけない。
今週から作れる実践的なQAスコアカード
WEMプラットフォームがなくても始められる。最初のスコアカードとして機能させるには、次の4つが必要だ。
- 実際に自社のビジネスにとって重要なことに対応する4〜6個のカテゴリーを選ぶ — 正確性、トーン、解決度、そして規制業界であればコンプライアンス上のクリティカルカテゴリーを1つ。厳選された少数のカテゴリーのほうが、誰も一貫して記入しない15項目の肥大化したフォームより優れている。
- 最初はバイナリまたは3段階の尺度を選ぶ。 5段階の細かい尺度は厳密そうに聞こえるが、レビューを遅くし、レビュアー間の意見の食い違いを増やしてしまう。これはまさにキャリブレーションが解決しようとしていることだ。まずはシンプルに始め、プログラムが軌道に乗ってから細かさを加えていく。
- 採点しやすいことではなく、実際に成果を左右することに重みを置く。 根本原因の診断が、きれいに句読点の整った返信よりも継続率にとって重要であるなら、そのように重みをつければいい。計算式は採点のしやすさなど気にしない。
- コーチングの前にキャリブレーションを行う。 誰かの実際のスコアが公開される前に、同じ10件のチケットについてレビュアーとキャリブレーションセッションを1回実施しよう。ここでの意見の食い違いは正常であり、想定内のことだ。それこそが、最初にこれを行う意味そのものだ。

そのスコアカードが人間のエージェント向けにできたら、AIエージェントに対しても同じものを適用しよう。エスカレーションやコールセンターの自動化を担っているスタックの部分も含めてだ。同じ重み付けされたカテゴリー、同じクリティカル・コンプライアンスのルール、同じキャリブレーションの規律を使う。実際のスコアカードに一度も照らされたことのないAIエージェントは、訓練を受けていない新人と同じように、ただの雰囲気だけで動いていることになる。
eeselと品質保証
私はeeselのサポートキューで実際に働いている。だから「確認せずにAIエージェントの返信を信頼していいか」という問いに対する正直な答えは、ノーだ。人間であれAIであれ、確認せずに誰かの返信を信頼していい理由などない。だからこそeeselは、QAを後から取ってつける別プログラムとしてではなく、ロールアウトそのものに組み込んでいる。エージェントが実際のライブチケットに回答する前に、シミュレーションモードが自社の過去のチケットに対してそれを実行し、テーマ別のカバレッジを確認したうえで、顧客の目に触れる前にギャップを見つけられるようにする。これは、事後ではなくローンチ前に実行するQAスコアカードに最も近いものだ。ライブになった後は、信頼度に基づくルーティングが、あらゆる返信に対する継続的なQAゲートとして機能する。信頼度の低い回答は、そのまま送信されるのではなく、人間が確認するための下書きとして保留される。これは、Zendesk の AI Agent QA が事後に適用しているのと同じロジックを、パイプラインのより早い段階に移しただけのものだ。

すでに人間のチームに対してQAプログラムを運用していて、AIエージェントが同じ基準に耐えられるかどうかを検討しているなら、それはまさに一度話してみる価値のあるテーマだ。eeselは無料で試すことができ、価格はシート単位の固定料金ではなくチケット単位の従量課金なので、自社のスコアカードに照らしてテストするのに、事前の調達プロセスを通す必要はない。
よくある質問
コールセンターの品質保証(QA)とは何ですか?
QAスコアカードは実際に何を測定しますか?
QAレビュアーはどのくらいの頻度でキャリブレーションを行うべきですか?
AIは実際にコールセンターの品質保証を担えますか?
チームが拡大するにつれて、手動QAサンプリングはなぜ破綻するのですか?
コールセンターのQAソフトウェアの費用はどのくらいですか?
QAとCSATの違いは何ですか?

Article by
Riellvriany Indriawan
Riell is a designer and writer at eesel AI with about two years of experience researching CX platforms, AI chatbots, and helpdesk software. She combines her design background with a sharp eye for how these tools actually look and feel in practice — making her comparisons unusually visual and user-focused.








