Skip to main content

アーランC計算ツール:エージェントは何人必要か?

アーランC計算ツールは、サービスレベル目標を必要人数に変換します。何をモデル化しているのか、そして答えを実用に耐えるものにする2つの補正を解説します。

Digvijay Singh Shekhawat
Digvijay Singh Shekhawat
July 28, 2026
1 min read
真鍮の天秤が、クリーム色の台の上でピンクの受話器と緑色のブロックを釣り合わせている

アーランC計算ツールは、目標時間内に目標割合の呼へ応答するために、キューに何人のエージェントが必要かを教えてくれます。業界標準は「20秒以内に80%の呼に応答する」というもので(Call Centre Helper)、アーランCはその約束を必要人数に変換する数式です。

ただ実行するだけでなく、仕組みまで理解しておく価値があります。というのも、この式が返す数値は決まった2つのかたちで間違っており、そこで足をすくわれる人が多いからです。ただし、どちらも出どころさえ分かれば取り返しがつきます。

アーランCが実際にモデル化しているもの

アーランCが答えるのは1つの問いだけです。呼量、平均処理時間、エージェント数が与えられたとき、t 秒より長く待たされる発信者の割合はどれくらいか、という問いです。

必要な入力は3つあります。

**オファードロード(呼量負荷)**はアーランという単位で測り、1時間あたりの呼数に平均処理時間(時間換算)を掛けたものです。1時間に500件の呼を受け、平均処理時間が363秒(Call Centre Helper)のキューは、50アーランを少し超える負荷を抱えていることになります。これはそのキューが表す「途切れなく話し続けている量」であり、ほかの要素を一切考慮する前の段階で、およそエージェント50人分の会話に相当します。

**目標サービスレベル**は約束そのものです。Y秒以内にX%へ応答する、という宣言です。

エージェント数が、解いて求める対象です。

この数式は、発信者は切らずに待ち続けること、呼はランダムに到着すること、どのエージェントもどの呼にも対応できることを前提にしています。この前提があるからこそ、素の計算結果がそのまま要員計画になることは決してありません。

押さえておくべき2つの補正

シュリンケージ

アーランCが示すのは、実際に電話に出ているエージェントの数です。休憩、研修、病欠、コーチング、事務作業のことは何も知りません。業界のシュリンケージは支払い労働時間のおよそ30%に達します(Call Centre Helper)。

これは丸め誤差ではありません。アーランCが「通話対応に50人必要」と示すなら、50 ÷ 0.7、つまり約72人をシフトに組み込んで、ようやく50人を確保できます。この工程を飛ばしたチームは慢性的にサービスレベルを割り込み、しかもその理由を突き止められません。モデルは正しく、間違っていたのはシフト表のほうだからです。要員計画が最初の1週間で破綻する原因として、これが最も多いパターンです。

稼働率(オキュパンシー)

稼働率とは、ログイン時間のうちエージェントが通話に費やす割合です。アーランCは稼働率95%を意味する答えも平然と返してきますが、それは算術的には正しくても運用上は使い物になりません。おおむね83%を超える稼働率が続くと、人は疲弊し、離職につながります(Call Centre Helper)。

モデルが返した計画がこの上限を超えるなら、超えなくなるまでエージェントを足してください。人が辞めるかどうかについて、数式は何の意見も持っていません。

大きなキューほど1呼あたりが安くなる理由

アーランCの直感に反する性質は、線形にスケールしないことです。呼量を2倍にしても、必要なエージェントは2倍よりはっきり少なくて済みます。

これがプーリング効果です。小さなキューでは、通話を終えたエージェントの前に待っている人がいないことが多く、その空き時間は無駄になります。大きなキューではほぼ常に誰かが待っているため、各エージェントの余剰能力が吸収されます。小さなキューを2つ統合すると同じ人数のままサービスレベルが改善するのはこのためであり、組織図の上ではどれほど筋が通って見えても、スキル別にキューを分割すると気づかないうちにエージェントを余計に食うのも同じ理由です。

モデルが成り立たなくなるところ

アーランCは発信者が待つことを前提にしています。しかし現実の発信者は放棄します。放棄した発信者は、モデルが埋まっていると考えていた枠を空けるため、放棄率が高い環境ではアーランCは必要なエージェント数を過大に見積もる傾向があります。これを織り込めるよう拡張したモデルがアーランAです。

また、モデル化する時間帯の内側では定常状態であることも前提にしています。15分または30分の間隔でモデル化してください。1日単位は禁物です。日次の平均値は、実際にサービスレベルを壊している朝のピークを覆い隠してしまいます。

さらに、エージェントは均質だと仮定しています。スキルベースルーティングを導入した瞬間、運用しているのは1つの大きなキューではなく複数の小さなキューになり、先ほどのプーリングの恩恵は逆に働きます。

実際に使ってみる

アーランC計算ツールは、時間帯あたりの呼数、平均処理時間、サービスレベル目標を入力として受け取り、シュリンケージと稼働率の補正を利用者任せにせず自動で適用します。

補正そのものを直接扱う計算ツールも2つあります。30%と決め打ちせず自社の実数を出したいならシュリンケージ、計画を確定する前に持続可能かどうかを確かめるなら稼働率です。

よくある質問

アーランC計算ツールは何に使うのですか? 呼量と平均処理時間をもとに、サービスレベル目標(一般的には20秒以内に80%応答)を達成するためにキューへ何人のエージェントが必要かを算出するために使います。

呼量から想像するより多くのエージェントが必要だと出るのはなぜですか? 呼が均等にではなくランダムに到着するからです。平均に合わせて要員を組むと、到着が集中したときに必ず足りなくなります。そして集中は絶えず起こります。

シュリンケージはアーランCの結果の前と後、どちらで適用しますか? 後です。アーランCが返すのは通話対応に必要なエージェント数なので、それを1からシュリンケージ率を引いた値で割ると、シフトに組み込むべき人数が求まります。

アーランCはチャットやメールにも使えますか? 直接には使えません。1人のエージェントが同時に扱う会話は1件という前提なので、チャットの同時対応はモデルを壊します。メールはそもそもアーランの意味でのキューではありません。

Digvijay Singh Shekhawat
Digvijay Singh Shekhawat

創業者、Finn AI

Digvijayは Finn を開発しています。通話の内容を推論し、データを抽出し、システムをリアルタイムで更新する、エンタープライズ向けの音声オーケストレーション層です。音声AI、市場開拓(Go-to-Market)、そして自律型エージェントを大規模に提供するために必要なことについて執筆しています。