初回解決率（FCR）とは：計算式と改善のコツ

Q: FCRの計算式は何ですか？

FCR ＝ 初回の接触で解決した依頼数 ÷ 期間内に対応した依頼の総数 × 100 です。結果は数え方のルール、つまり何を依頼とするか、再発とみなす期間、引き継ぎを数えるかどうかで変わります。先に決めて文書にしてください。

要点： 初回解決率（FCR、First Call Resolution）とは、最初の問い合わせだけで完全に解決できた依頼の割合です。再度の連絡、チケットの再オープン、他の担当者への引き継ぎが要りません。ITサポートでの計算式は、初回の問い合わせで解決した依頼数 ÷ 同じ期間に対応した依頼の総数です。数字を示す前に、数え方のルールを決めてください。ルールが結果に与える影響は、チームの実力より大きいことがあります。

ITヘルプデスクの責任者に「ヘルプデスクがうまく回っているかを一番よく示す指標は何か」と尋ねると、初回解決率を挙げる人が少なくありません。説明が簡単で、ユーザーの望み（一度で直してほしい）と一致し、教育、ツール、ナレッジが良くなるにつれて動きます。一方で、間違った測り方もしやすい指標です。この記事では、FCRの意味、計算方法、数字を左右する要因、数字を作り込まずに改善する方法を説明します。

外部の定義は2026年10月28日に確認しました。WikipediaのFirst call resolutionの項目です（2026-10-28確認）。Brocentが約束をどう公開しているかについては、SLAのページに基づいています。

初回解決率（FCR）とは何か

Wikipediaの該当項目（2026-10-28確認）は、初回解決率、すなわち初回問い合わせ解決率（FCR）を、コールセンターが最初の電話や問い合わせで顧客の用件を解決し、追加の連絡を不要にする能力を測る指標としています。理想的なFCRとは、顧客の立場から見て、繰り返しの電話や連絡が要らないことだとも述べています。

同じ項目は、同じ考え方に二つの呼び名があることを区別しています。

First call resolution（初回コール解決率）： コールセンター、つまり音声通話について測ります。
First contact resolution（初回コンタクト解決率）： チャット、メール、ポータル、電話など、あらゆる窓口について測ります。

ITヘルプデスクにとっては、後者のほうが実用的です。ユーザーは電話、チャット、メール、チケットポータル、場合によっては窓口への直接訪問で連絡してきます。そこで、この記事では「FCR」をどの窓口でも初回の接触で解決することとして使い、窓口が音声のときだけ「コール」と言います。

混同されやすい近い用語が三つあります。

一次対応での解決（ファーストレベル解決）： チケットが最初のサポートレベル（L1）で解決し、L2やL3に回らないことです。L1で解決するまでに三回やり取りが必要なこともあるので、FCRと同じではありません。各レベルについてはL1・L2・L3サポートレベルで説明しています。
平均解決時間（MTTR）： 登録から解決までの平均経過時間で、MTTR・MTBF・MTTAの解説で扱っています。速さを測る指標で、FCRは一回の接触で足りたかを測ります。
再オープン率： 解決済みとなったチケットが戻ってくる割合です。FCRの裏返しなので、両方を併せて読みます。

FCRの計算方法

計算式は単純です。

FCR ＝（初回の接触で解決した依頼数 ÷ 期間内に対応した依頼の総数）× 100

計算の流れを示す例です（数字は説明のための仮のものです）。ある月にヘルプデスクが200件の依頼に対応しました。そのうち130件は、ユーザーが同じ問題で再び連絡する必要がなく、チケットも再オープンされませんでした。FCRは130 ÷ 200 ＝ 65%です。

難しいのは、「初回の接触で解決」をどう判定するかです。次の点を一度に決め、文書にして、変えないようにします。

何を「依頼」として数えるか。 インシデントとサービスリクエストの両方か、インシデントだけか。パスワードリセットとサーバー障害はどちらもチケットですが、性質がまったく違います。両者のFCRを分けて報告するヘルプデスクも多くあります。
再発とみなす期間はどれだけか。 同じユーザーが、たとえば2営業日以内に同じ問題で再び連絡してきたら、再発とみなすか。Wikipediaの項目には、「一定期間内に繰り返しの電話がないこと」が最もよく使われる方法の一つだと書かれています。期間は自分で決めますが、事前に固定しなければなりません。
同じ問題かどうかを誰が判断するか。 システムが自動で突き合わせない限り、後続の問い合わせを元のチケットに紐付けるのは人の判断です。誰が、どうやるかを決めておきます。
引き継ぎは未達として数えるか。 L1がL2に回し、ユーザーが二度と連絡してこなかった場合、初回の接触で解決したことになるか。多くの定義では、最初の接触では解決していないので「ならない」とされています。立場を明確にしてください。
除外するチケットは何か。 計画作業、能動的な監視アラート、他の人に代わって登録したチケットは、通常は数えません。除外項目を一覧にします。

FCRの測定：システムのデータか、顧客の実感か

Wikipediaの項目（2026-10-28確認）は、二系統の方法を紹介しています。内部の方法は、運用上の成果を測るもので、オペレーターの記録、音声解析、品質モニタリング、再オープンされた案件、繰り返しの着信件数の集計などです。外部の方法は顧客に尋ねるもので、通話後のアンケートなどがあります。また、FCRは顧客の立場から判断するのが理想だとも述べています。問題が本当に解決したかどうかは、顧客にしか分からないからです。

ITヘルプデスクでは、両方を組み合わせるのが現実的です。

システム上の信号： 再発とみなす期間内に、同じユーザーから同じ話題での再オープンや新規チケットがないこと。低コストで、すべてのチケットを網羅できます。
顧客の信号： クローズ後に一問だけ尋ねます。たとえば「今回のお問い合わせで、問題は完全に解決しましたか」です。毎回すべてのユーザーに尋ねるとアンケート疲れを招くので、抽出して行います。
突き合わせ： 四半期ごとに両者を比べます。システム上は70%なのにユーザーの回答は55%という場合、実際には直っていないチケットを閉じているということです。

ITサポートでFCRはどのくらいなら良いのか

誰にでも当てはまる数字はなく、当社も一つの数字を示すことはしません。公開されているベンチマークには、種類の異なるコールセンターが混ざっていることが多く、パスワードリセットが中心のITヘルプデスクは、複雑な業務システムを支えるヘルプデスクより点が高く出ます。数字を判断するには、次のほうが適切です。

自社の過去実績と比べる。 同じ数え方のルールで比較します。
カテゴリ別に比べる。 パスワードリセット、アクセス権の申請、ソフトウェアのインストールは、多くが初回の接触で解決できるはずです。ネットワーク障害やアプリケーションエラーは、できないことが多くあります。
再オープン率やユーザー満足度とあわせて見る。 同じチケット群で比べます。FCRが高くて再オープン率も高いなら、チケットを早く閉じすぎています。

FCRは、ヘルプデスクとその改善活動のための指標であって、通常は契約上の約束ではありません。WikipediaのSLAの項目は、初回解決率をSLAでよく使われる指標の一つとして挙げていますが、ITサポートのSLAの多くは、初回応答時間と復旧時間を約束します。詳しくはITサポートにおけるSLAとはをご覧ください。FCRは、これらの目標の隣に、品質指標として月次レポートに載るのが一般的です。

初回解決率を左右する要因

FCRを大きく動かす要因は七つあります。多くは、依頼を最初に受ける人に何を持たせるかの問題です。

1. 一次対応の担当者が使えるナレッジ

よくある問題の直し方が、特定の誰かの頭の中にしかなければ、初回の接触で解決できるのはその人だけです。更新されているナレッジベースと、一次対応向けの短い手順書があれば、誰でも定番の問題を解決できます。古くなった記事は、記事がないのと同じくらいFCRを下げます。

2. 権限とアクセス

問題を切り分けられても、パスワードをリセットできない、アカウントのロックを解除できない、権限を変更できない担当者は、チケットを引き継ぐしかありません。一次対応に許されている日常操作を見直し、安全に委任できるものには、ログを残したうえで権限を与えます。

3. リモートツール

（ユーザーの同意のもとで）画面を見る、端末を操作できると、「見えている内容を説明してください」というやり取りが、数分で直る作業に変わります。分散して働くチームでは、これが単独で最も大きな要因になることがよくあります。

4. 教育とスキルの網羅

一次対応の担当者は、上位20件程度の問題を頭に入れておくべきです。L2の技術者とのペア作業、大きな変更のたびの短い復習、誰が何に詳しいかを示す明確な一覧があると、最初の接触が実りあるものになります。

5. 最初のやり取りの質

適切な順序で適切な質問をすれば、二度目の連絡を省けます。何が変わったか、いつ始まったか、ほかに誰が影響を受けているか、ユーザーが何を試したか。よくあるカテゴリごとの短いスクリプトがあれば、あとから同じことをもう一度聞く手間を避けられます。

6. 分類とルーティング

チケットの分類を誤ると、直せない人のところに届いてしまいます。明確な分類とルーティングのルール、できれば優先度の定義（重大度と優先度の違いを参照）と結びつけたルールがあれば、初回の接触で適切な人が着手できます。

7. 依頼の構成

標準化された端末と管理されたアプリケーションを支えるヘルプデスクは、古いシステムが継ぎはぎになった環境を支えるヘルプデスクより、初回で解決できる件数が多くなります。これはFCRを無視する理由ではなく、同じ条件のものを比べ、この数字を「複雑さがどこにあるか」を示す地図として扱う理由です。

初回の接触で解決しやすい依頼としにくい依頼

FCRのばらつきの大半は依頼の構成で説明できるので、改善目標を決める前に、チケットを種類別に分けて眺めてください。

初回で解決しやすい： パスワードのリセットやアカウントのロック解除、標準の承認手順に沿ったアクセス権の申請、承認済みカタログからのソフトウェアのインストール、解決策が決まっているプリンターやネットワークドライブの問題、操作方法の質問。
初回で解決できることもある： メールやMicrosoft 365の問題、端末の動作が遅い、VPNの問題、アプリケーションのエラー。ナレッジベースとリモートツールの質に左右されます。
初回ではまず解決しない： 部品が必要なハードウェア故障、回線事業者のネットワーク内の障害、ベンダーのソフトウェアの不具合、変更の作業時間枠が必要なもの。

最初のグループでFCRが低いなら、プロセスや権限の問題で、直せます。最後のグループでFCRが低いのは当然で、問うべきは、チケットがどれだけ早く、適切な情報を携えて適切な人に届くかです。これにはL1・L2・L3サポートレベルとエスカレーションマトリクスのテンプレートが答えています。

初回解決率を高める方法

順番に進めてください。どの手順も、人を増やすよりずっと安く済みます。

基準値を測る。 前の節で数え方のルールを決め、何も変える前に1か月測ります。
繰り返しの連絡が多い上位10カテゴリを見つける。 複数回の接触が必要だったチケットをカテゴリ別に並べます。上位のいくつかが、差の大部分を占めるのが普通です。
それぞれのナレッジ記事を書くか直す。 症状、簡単な確認、直し方、エスカレーションのタイミングを、短くまとめます。担当者と見直し日を決めます。
安全な操作を開放する。 各カテゴリで、いまL1にできない操作とその理由を挙げます。習慣だけで残っている障壁は取り除き、残りはスクリプト化した引き継ぎに置き換えます。
一次対応にリモートツールと端末情報を持たせる。 資産とユーザーの情報がチケット上に見えるようにして、担当者が尋ねなくて済むようにします。
初回接触用の短いチェックリストを加える。 聞くべきこと、集める証拠、エスカレーション前に試すこと。エスカレーションするチケットには、次の技術者が必要とする情報がすべて付いている、というルールも入れます。
ユーザーに確認して終える。 クローズ前に直ったことを確認し、再発とみなす期間をユーザーと合わせておくと、再度の連絡が元のチケットに記録されます。
毎月見直す。 カテゴリ別のFCR、再オープン率、初回で解決できたはずのエスカレーションを見ます。そこで学んだことをナレッジベースに戻します。

エスカレーションが必要なときは、すっきりと行います。エスカレーションマトリクスのテンプレートでは、誰にいつ連絡するかを説明しています。初回で解決できないチケットも、同じ質問を繰り返さずに前へ進められます。

FCRを追いかけるときの落とし穴

間違った手段で簡単に達成できる目標は、間違った手段で達成されます。次に注意してください。

早すぎるクローズ。 FCRだけを評価すると、担当者はユーザーが確認する前にチケットを解決済みにします。FCRは、再オープン率と顧客への確認とセットで使います。
簡単なものだけ選ぶ。 複雑な問い合わせを避ける担当者は、自分のFCRを上げ、難しい仕事を同僚に押し付けます。数字一つではなく、カテゴリ別にFCRを報告します。
対応時間との綱引き。 通話を短くする圧力と、初回で解決する要求は、反対方向に引っ張り合います。10分長くかかっても二度目の連絡を避けられる対応のほうが、全体では安く済みます。
引き継ぎを成功に数える。 ちらっと見て回したチケットは、初回の接触での解決ではありません。定義を明確にし、一部を抜き取って監査します。
ユーザーを見落とす。 チケットシステム上では直っていてもユーザーの環境では直っていなければ、ユーザーはまた連絡することになります。システムは解決済みを示し、ユーザーは失敗と感じます。
FCRを品質の代用品にする。 ヘルプデスクはFCRが高くても、毎週同じ問題を直して原因を取り除かないなど、間違ったことを処理し続けていることがあります。それは問題管理の領域で、重大インシデント管理のプロセスの記事で扱っています。

FCRはSLAや外部委託とどう関係するのか

FCRとSLAの目標は、測っているものが違います。初回応答と復旧の目標は優先度ごとに速さを約束し、FCRは初回の接触で足りる頻度を表します。どちらも重要で、互いに影響します。初回で解決できる件数が多いヘルプデスクは、エスカレーションが少なくて済み、エスカレーションが必要なチケットの復旧目標を守りやすくなります。各優先度が何を約束するのかは、ITサポートSLAのP1からP4の優先度で解説しています。

ITサポートを外部委託する場合は、提供会社がFCRをどう測っているか、どんな数え方のルールを使っているか、その数字が月次レポートに載るかを尋ねてください。答えを聞けば、提供会社がヘルプデスクをサービスとして扱っているのか、チケットの待ち行列として扱っているのかが分かります。どの日常的な依頼を提供会社が最初から最後まで処理するのかも尋ねる価値があります。当社のSLAのページでは、パスワードのリセットとユーザー管理を日常的（P5）な依頼として挙げており、それを処理するヘルプデスクは24時間365日のヘルプデスクで紹介しています。より大きな契約のなかでサービスがどう位置づけられるかは、マネージドITサポートのプランをご覧ください。マネージドITサポートのプランとユーザー単価では、公開している初回応答の約束とプラン料金を並べています。これらのページにFCRの数字は載せておらず、この記事のどの部分も、そのような数字として読まないでください。