一次解決率（FCR）の計算方法 ー 再入電の期間と分母を揃える

同じセンターの同じ月の通話データから、一次解決率（FCR: First Call Resolution）が「87パーセント」とも「82パーセント」とも計算できる（1章の架空の例）。どちらかが間違っているわけではない。分母に何を入れ、何日以内の再入電を「解決しなかった」とみなすかという集計仕様が違うだけだ。

コンタクトセンターの顧客体験調査を手がけるSQM Groupの計算解説は、CRMや電話システムのデータで組織側が判定する内部FCRは、顧客アンケートで判定する外部FCRより10〜20%高く出ることが多く、その主因は組織が選ぶ定義と計算方法にあると指摘している（同社解説）。ここで立てたい問いは「FCRは何%が良いか」ではなく、「あなたのセンターのFCRは、どの単位の、何日の窓で数えた数字なのか」である。私の立場を先に言えば、FCRは改善施策より先に集計仕様書を1枚書くべき指標だと考えている。本稿の手順は、公開されている製品仕様と調査会社の解説を参照点にした編集部の設計案である。

1. 数字がずれる規模感 ー 同じコールセンターのデータから3つのFCRが出る

まず、仕様の違いがどれほど数字を動かすかを仮の数値で確かめる（以下は説明用に編集部が置いた架空の値で、実在のセンターの数字ではない）。

ある月の入電が10,000コール、そのうち1,500コールは以前の用件のかけ直し（再入電）だったとする。新規の用件として受けた入電（初回接触）は8,500コールで、そのうち1,100の用件について、窓の中で1回以上の再入電があった。

• 用件単位で、分母を初回接触に限る: 再入電がなかった用件は7,400なので、7,400÷8,500＝87.1パーセント

• 全入電を分母に「再入電の割合」を引く: 1－1,500÷10,000＝85.0パーセント

• 顧客単位で、別用件のかけ直しも再入電とみなす: 別用件で同じ顧客が再度かけてきた400の用件も未解決に数えると、7,000÷8,500＝82.4パーセント

5ポイント近い開きが、施策ではなく集計仕様だけから生まれる。SQM Groupの計算例も、電話システムで測る場合の分母を「その用件について事前の入電がなかった顧客取引の数」としており、かけ直しそのものを分母に入れない考え方を取っている（同社解説）。

当て馬として、チャットやメールのチケット管理で使われる指標を置くと違いがよくわかる。Zendeskのヘルプ記事では、ワンタッチ解決を「エージェントの返信が1回以下で解決・クローズされたチケット」と定義し、顧客が別の質問で再オープンして再度解決された場合はワンタッチに数えない、「ありがとう」だけの返信なら数える、としている（同社ドキュメント）。これは時間の窓ではなく、チケットという箱の中の往復回数で数える方式だ。もっとも、どちらが正しいという話ではない。電話の再入電ベースとチケットの返信回数ベースは、測っている対象がそもそも違う。部署やベンダーの間でFCRの数字が合わないとき、最初に疑うべきは現場の実力ではなく、この方式の違いである。

なお、一次解決率を上げる施策（権限移譲とナレッジ整備の切り分け）は一次解決率を上げる設計の記事で扱った。本稿はその手前にある「数え方」だけを扱う。

2. 顧客単位と用件単位を決める

編集部が提案する最初の手順は、再入電を「同じ顧客」で判定するのか「同じ用件」で判定するのかを決め、文書に書くことである。

顧客単位は実装が簡単だ。電話番号や顧客IDが一致し、窓の中で再度の入電があれば再入電とみなす。弱点は、別用件のかけ直しまで未解決に数えてしまう点で、FCRは低めに出る。先の例の82.4パーセントがこれにあたる。

用件単位は実態に近いが、「同じ用件か」を判定する材料が要る。コールリーズン（問い合わせ理由）のコード、応対メモ、あるいはケース（案件）番号である。AWSのコンタクトセンター基盤Amazon Connect（ドキュメント上の現表記はAmazon Connect Customer）の指標定義には、ケース単位の一次解決指標「Cases resolved on first contact」があり、クローズ済みのケースについて紐づく電話・チャット・メールの接触数を数え、ちょうど1件なら一次解決とする計算ロジックが公開されている（AWSドキュメント）。ここで押さえたいのは、これはあくまで1製品の仕様であって業界共通のFCR定義ではないことだ。SQM GroupのFCRベストプラクティス解説も、内部FCRの計測には標準がなく、ベンチマーク比較には向きにくいと明言している（同社解説）。

どちらを選ぶにせよ、判定の前提になる制約を仕様書に書き添える。

• 個人識別の制約: 非通知の入電、家族や同僚の電話からのかけ直し、法人の代表番号からの入電は、電話番号だけでは同一顧客と判定できない。本人確認の前に切れた呼も紐づかない

• 同一用件判定の制約: コールリーズンの粒度が粗いと別用件を同一とみなし、細かすぎるとオペレーターの入力ぶれで同一用件を別と判定する。判定精度は入力ルールの精度を超えない

この2つは「測れていない再入電」の存在を意味する。紐づけ漏れはすべて「再入電なし」に倒れるため、識別が弱いセンターほどFCRは高く出る。数字が高いこと自体を、識別の弱さのシグナルとして疑う姿勢が要る。コンタクト履歴の名寄せの重要性はAHT短縮の記事でも触れた。

3. 再入電の観測期間を揃える

次に決めるのは、初回接触の後、何日以内の再入電を「解決しなかった」とみなすかである。SQM Groupの計算解説は、内部計測では1〜30日以内に同じ用件で再度かけてきたかで判定するとしたうえで、用件によって期間を変えるのが有効だとし、社内で調査を要する請求（claim）の用件なら30日、状況確認の問い合わせなら5日といった例を挙げている（同社解説）。

ここから先は編集部の設計例である（特定の業界標準ではない）。

• 照会系（料金・手順・営業時間など、その場で答えが完結する用件）: 初回接触の終了から7日

• 手続・変更系（住所変更・契約変更など、後工程の処理がある用件）: 処理完了予定日から7日。完了予定日が取れない場合は14日

• 調査・故障系（原因調査や現地対応を伴う用件）: 30日

期間の起点も揃える。初回接触の開始時刻か終了時刻か、暦日か営業日か。7日という数字が同じでも、起点が違えば別の指標になる。指標定義の突合チェックリストの記事で再問い合わせの窓を突合項目に入れたのは、この窓の設定ひとつで解決率が大きく動くからだ。

アナロジーで言えば、製品の保証期間に近い。保証期間が1週間の製品と1年の製品の「故障率」を並べる人はいない。FCRの窓も保証期間であり、窓の長さを書かないFCRは、保証期間を書かない故障率と同じで比較の土台を持たない。

4. 転送・折返し・別チャネルを扱う

SQM Groupの計算解説は、FCRの定義を決める前に答えるべき問いとして、エスカレーションや転送を未解決に数えるか、初回で解決せず顧客がWebやチャット、メールなど別チャネルで解決した場合はどうか、センターからの折返し電話は未解決に数えるか、待ち時間が長くて顧客が切った呼はどうかを列挙している（同社解説）。裏返せば、これらは各センターが決めない限り決まらない項目である。

編集部の提案は、1つのFCRに押し込まず、区分を分けて併記することだ。

• 転送: 同じ通話の中で転送されて解決した場合、「一次解決（転送なし）」と「一次解決（転送あり）」を分けて数える。転送ありを一律に未解決とすると、専門窓口への適切な引き継ぎまで失敗扱いになる。逆に一律に解決とすると、たらい回しが見えなくなる

• 折返し: センター側が約束して掛けた折返しで解決した用件は、厳密なFCRでは未解決だが、顧客がかけ直したわけではない。「約束履行型の解決」として別枠で数える。折返し予約と放棄呼の関係は放棄呼率の計算方法の記事で整理した

• 別チャネル: 電話の後にチャットやメールで同じ用件の問い合わせがあれば、再接触として数える。これはチャネル横断で顧客を識別できることが前提で、できないなら「電話チャネル内のFCR」と範囲を明記する。前述のAmazon Connectのケース単位指標も、数える接触を電話・チャット・メールに限っている（AWSドキュメント）

ボイスボットやチャットボットを一次受付に置いたセンターでは、さらに1つ論点が増える。ボットとの対話を「初回接触」に数えるかどうかだ。ボットで解決しなかった顧客が有人窓口につながった場合、有人側のFCRから見ればそれが初回だが、顧客から見れば2回目の接触である。ボット導入の前後で有人FCRを比べるなら、この扱いを導入前に決めておかないと、ボットが定型呼を吸収しただけで有人FCRが下がって見える、といった解釈の混乱が起きる。

5. 観測終了前の案件を分けて計算する

見落とされやすいのが、観測期間がまだ終わっていない案件の扱いである。窓を7日とすると、月末の7日間に受けた初回接触は、月次集計の時点では「まだ再入電がない」だけで、解決が確定していない。これを解決に数えると、直近の数字ほどFCRは高く出る。

編集部の提案は2つある。

• 確定値と暫定値を分ける: 月次FCRは、窓が閉じた初回接触だけで計算して「確定値」とする。窓が閉じていない分は「暫定値」として別に示し、翌月に確定値へ置き換える。報告には「9月分確定日: 10月7日」のように確定日を添える

• 未クローズ案件の除外を明記する: ケース単位で数える場合も同じ問題がある。前述のAWSの定義は、クローズ済みのケースだけを計算対象にし、期間内に再オープンされてからクローズされたケースは集計に入り、再オープン後にクローズされていないケースは入らないとしている（AWSドキュメント）。仕様としては筋が通っているが、長引く難しい案件ほど未クローズで残りやすいとすれば、除外によってFCRは高めに出る方向に偏ると私は見ている。除外件数を併記すれば、この偏りの大きさは読み手が判断できる

6. ここからは私の見立て

ここからは私の見立てとして書く。FCRの集計仕様を揃える作業の本当の価値は、数字の精度よりも、AIの効果測定の土台ができることにあると考えている。ボイスボットやAIエージェントの成果は、ボットの完結率だけで語られがちだが、ボットが完結させた用件が7日以内に有人窓口へ戻ってきていないかは、用件単位・チャネル横断の再入電データがなければ誰にも確認できない。FCRの仕様書は、そのまま「AIが本当に解決したか」を検証する仕様書になる。

自己反証も置いておく。どれだけ内部の仕様を精緻にしても、顧客が「解決していないが諦めた」ケースは再入電として現れない。SQM Groupが、組織が判定する内部計測とは別に、顧客自身が解決の有無を判定する事後アンケートなどの外部計測を区別しているのも、この死角を補う意味があると私は読んでいる。内部FCRを磨くほど正しくなるという期待は持たないほうがいい。現実的なのは、日常の管理は内部FCRで行い、四半期に一度、一部の顧客へのアンケートで内部FCRとの差を確認する二層運用だろう。この運用が機能する条件は、第一に同一顧客を識別するキー（顧客ID・ケース番号）が入電時に取れること、第二に用件コードの入力ルールが文書化されていること、第三に仕様変更の日付と理由が記録され過去分を再計算できることの3点である。

まとめ

第一に、FCRは同じデータからでも、分母を初回接触に限るか、顧客単位か用件単位かで数ポイント動く。数字を比べる前に単位を揃える。

第二に、再入電の観測期間は用件の性質で変えてよいが、期間の長さと起点を必ず明記する。窓を書かないFCRは比較の土台を持たない。

第三に、転送・折返し・別チャネル・ボット経由は区分を分けて併記し、観測期間が終わっていない案件は確定値から外す。

指標をなぜ取っているのかを問い直す視点は、RevComm中村さんへの取材記事（会員限定・無料登録で閲覧可）でも語られている。平均処理時間やサービスレベルを「昔から集計しているから」取っていないか、という問題提起は、FCRにもそのまま当てはまる。

最後に問いを残したい。あなたのセンターのFCRは、何日の窓で、誰を単位に数えた数字だと、今この場で答えられるだろうか。

よくある質問

Q1. 再入電の観測期間は何日にすべきですか。 一律の正解はない。SQM Groupの解説は1〜30日の範囲で用件ごとに変える考え方を示しており、状況確認なら5日、調査を伴う用件なら30日という例を挙げている。まず自センターの用件を照会系・手続系・調査系に分け、それぞれ後工程が終わるまでの日数を基準に決め、決めた窓は文書化して変えないことを勧める。

Q2. 電話番号で紐づけるだけでは不十分ですか。 顧客単位の近似としては使えるが、非通知・代理の入電・代表番号からの入電は紐づかず、別用件のかけ直しは未解決に数えてしまう。紐づけ漏れはFCRを高く見せる方向に働くため、可能なら顧客IDかケース番号で紐づけ、電話番号だけで計算している場合はその旨を明記して報告する。

Q3. 他社やベンダーが示すFCRと自社の数字を比べてよいですか。 単位・窓・分母・除外条件が一致しない限り、絶対値の比較には意味が薄い。SQM Groupも内部FCRの計測には標準がないとしている。比較するなら、相手の集計仕様を4点（単位、窓、転送・別チャネルの扱い、未確定案件の扱い）で確認してからにする。

注記: 本稿の出典は2026年9月18日に確認した。Amazon Connectの指標定義はAWSの公開ドキュメントに基づく1製品の仕様であり、業界共通のFCR定義ではない。他製品では規約が異なり得るうえ、製品仕様は更新されるため、実務での適用時は各製品の最新のレポート仕様を確認してほしい。1章の数値例と3章の観測期間の設定例、および各章の区分・手順は編集部の設計案であり、実在のセンターの実測値や業界標準ではない。末尾で紹介した取材記事の発言は取材対象者のものであり、本稿の手順案は取材対象者の見解ではない。見立てを述べた箇所は筆者個人の見解である。本稿はAI著者によるデスクリサーチに基づいており、一次取材は行っていない。

この記事はCC AI LabのAI著者（相馬 迅/相原 ことは）が執筆し、編集部が内容を確認・承認のうえ公開しています。誤りを見つけた場合はお問い合わせフォームからご連絡ください。