「問い合わせ対応を改善したい。KPIを決めてください」
AIにそう聞くと、きれいな一覧が返ってきます。初回応答時間、解決時間、一次解決率、顧客満足度、再問い合わせ率。目標値まで付いてきます。「平均1時間以内」「60〜80%」「CSAT 85%以上」。
そのまま社内に持っていきたくなります。
ですが、この一覧には共通する問題があります。数字が悪化したとき、何を直せばいいかが1つも書かれていません。
先に結論
指標には、結果を見るものと、その結果を生む原因を見るものの2種類があります。
素の質問では、出力が結果側に偏りやすい。 件数、時間、達成率。原因側は、こちらから条件を渡さないと出てきにくくなります。
誤解のないように書いておくと、結果側の指標が悪いわけではありません。 目標に近づいているかを見るには必要です。問題は、原因側が1つも無いことです。原因側が無いと、悪化したときに手の打ちようがありません。
なお厳密には、返ってきたのは結果そのものと、結果にかなり近いものが中心でした。この記事では、まとめて「結果側」と呼びます。
その原因側を選ぶには、満たすべき条件が4つあります。とくに効くのが「自分たちで動かせるか」です。
実際に試した条件
以下は、私が実際にAIへ投げた結果です。読んだ方が同じことを試せるよう、条件を書いておきます。
| 内容 | |
|---|---|
| 時期 | 2026年8月（両方とも同じ日） |
| 質問文 | 「問い合わせ対応の業務を改善したいです。KPIを決めてください」（完全に同じ文） |
| セッション | どちらも新規。前の会話を引き継いでいない |
| モデル | 同一 |
| 追加情報 | なし。業種も件数も体制も伝えていない |
| 違い | 判定の条件を持たせたかどうかだけ（下記） |
条件を渡した側では、質問文の手前に次を持たせています。これが唯一の違いです。
- 指標は、結果側と原因側に分けること
- 原因側の指標は、次の4条件で判定すること
（原因系である／結果への影響が大きい／自分たちで動かせる／期の途中で見られる）
- 改善前の実測値がない場合、目標値を置かないこと
- 最初は結果1つ・原因1つに絞ること
- 何を改善したいのかが分からないうちは、指標を提案しないこと
結果はこうなりました。
| 素のまま聞いた場合 | 条件を渡した場合 | |
|---|---|---|
| 出てきた指標 | 10個（うち推奨5個） | まず質問を返す。そのうえで結果1つ・原因1つに絞る |
| 目標値 | 十数個を自動で設定（各指標に平均値・達成率・点数などが複数付いたため） | 置かない。「実測か一般論か」を確認してくる |
| 原因側の指標 | なし | 1つ（4条件の判定つき） |
| 改善前の確認 | なし | あり |
| 測定期間の確認 | なし | あり |
素のまま聞くと、何が起きるか
目標値が、根拠なく置かれる
返ってきた目標値は、「平均1時間以内」「一次解決率60〜80%」「CSAT 85%以上」「再問い合わせ率10%以下」。
もっともらしく見えます。ですが私の会社のデータは1件も見ていません。業種も、件数も、体制も聞かれていない。一般論のように見えますが、実態は根拠不明の仮置きです。
これを社内に出すと、どうなるか。「なぜ1時間なのか」と聞かれて、答えられません。
原因側が1つも無い
10個は、件数・時間・率で構成されていました。どれも起きたあとの数字です。
悪くなったときに、手順を直すのか、担当の割り振りを変えるのか、案内を増やすのか。どこを触ればいいのかが分かりません。
「改善前」を聞かれない
比べる相手がないまま、指標だけが決まりました。
条件を渡すと、まず質問が返ってきた
同じ質問を、判定の条件を持たせた状態で投げ直しました。
すると、指標を出してきませんでした。 代わりにこう返ってきます。
問い合わせ対応で、最優先で変えたいことはどれですか？
1. 返信を早くしたい
2. 一度で解決できるようにしたい
3. 同じ問い合わせを減らしたい
4. クレーム化・再問い合わせを減らしたい
これは正しい反応です。「問い合わせ対応」という業務名だけでは、指標は決まりません。 返信を早くしたいのか、やり取りの回数を減らしたいのかで、置くものが変わります。
ここを飛ばして指標を出すから、当たり障りのない一覧になります。
原因側の指標を選ぶ、4つの条件
品質管理の世界では、結果を見るものを管理項目、原因を見るものを点検項目と呼びます。
点検項目
プロセスの結果に与える影響が大きく，直接制御が可能な原因系の中から，定常的に監視する特性・状態として選定した項目
——JSQC-Std 00-001:2023『品質管理用語』13.5
この定義を分解すると、条件は4つになります。
| # | 条件 | 落ちる例 |
|---|---|---|
| 1 | 原因系である | 「クレーム件数」は結果 |
| 2 | 結果への影響が大きい | 動かしても結果が変わらないもの |
| 3 | 自分たちで動かせる | 景気、天候、他社の動き |
| 4 | 定常的に監視できる | 年1回しか分からないもの |
実務で一番効くのが条件3です。
「売上が落ちたのは景気のせいだ」。原因としては正しいかもしれません。ですが動かせないものを監視しても、打ち手は出ません。
人そのものを、原因側に置かない
条件3で実際によく落ちるのが、人の属性です。
「担当者の習熟度」「対応品質のスコア」「やる気」。指標として置きたくなりますが、直接は動かせません。そして測られる側からすると、評価そのものに見えます。
ここは分けて考えてください。対応品質を測ること自体は問題ありません。 判定基準がはっきりしていて、改善につながるなら結果側の指標として成立します。まずいのは、それを「人の能力の評価」として置くことと、自分たちで動かせる原因側だと勘違いすることです。
原因側に置くのは、変えられる仕組み・行動・環境です。
| 置きたくなるもの | 原因側に置くもの |
|---|---|
| 担当者の習熟度 | 手順書のカバー率、研修の実施率 |
| 対応品質 | チェックリストの実施率、レビュー前の自己確認 |
| その人しか対応できない | その業務を実施できる人数 |
言い換えると、人ではなく、その人が置かれている状態を測るということです。
実際の判定結果
条件を渡したAIに、先ほどの5つのKPIを点検させました。返ってきた表がこれです（4条件すべてで判定させています）。
| 指標 | 位置づけ | 影響が大きいか | 動かせるか | 期中に見られるか | 原因側として | 指摘 |
|---|---|---|---|---|---|---|
| 初回応答時間（平均1時間以内） | 結果側 | ○ | △ | ○ | 不可 | 結果側としては使える。平均だけだと遅延案件が隠れるので超過率も見る |
| 解決時間（平均24時間以内） | 結果側 | ○ | △ | ○ | 不可 | 「顧客の返信待ち」を含めるか定義が要る |
| 一次解決率（60〜80%） | 結果寄り | ○ | △ | ○ | 不可 | 「一次解決」の定義が未確定 |
| 顧客満足度（CSAT 85%以上） | 結果側 | ○ | ✗ | △ | 不可 | 満足度そのものは直接動かせない |
| 再問い合わせ率（10%以下） | 結果側 | ○ | △ | ○ | 不可 | 「何日以内・同一案件」の範囲を決める |
5つとも、結果側としては使えます。使えないのは原因側としてです。 4条件はもともと原因側を選ぶための条件なので、この表は「原因側の候補が1つも無い」ことを示しています。
注目してほしいのはCSATの行です。
これは「CSATを置くな」という意味ではありません。満足度は結果側の指標として置いてよい。ただし、上げようとしても直接は触れません。触れるのは、回答の品質や、返信の漏れや、必要な情報が最初に揃っているかどうか。そちらを原因側に置いて初めて、打ち手が出ます。
この判定は、私が教え込んだ指標ではありません。少なくともこの5件については、条件を渡しただけで、知らない指標にも同じ判定ができていました。
📄 この4条件を紙で使えるようにしたワークブック（A4・無料）も置いています。
👉 業務改善の効果測定 スターターキット（PDF）
条件を、そのまま道具にしました
この4条件と、業務タイプ別の指標の候補、落とし穴の一覧をまとめて、AIエージェント用のスキルとして公開しました。
🔗 mamagotolab/kaizen-hyouka-skill（変更履歴）
Claude Code と Codex CLI の両方で動きます（2026年8月時点で動作確認。両ツールとも仕様が変わる可能性はあります）。中身は全部テキストです。プログラムを書ける必要はありません。自分の業種に合わせて書き換えて使えます。
できることは4つです。
- 決める … 何を測るかを決める
- 点検する … すでにあるKPIを4条件で査読する
- 報告する … 成果を報告の形にする
- 記録シートを作る … Excel・CSV・Markdownで、明日から記録できるファイルを出す
一番使えるのは2の点検だと思っています。ゼロから決めることより、すでにあるKPIを見直したい場面のほうが多いからです。
作ってみて分かったこと
「記録できるシート」と「記録が続くシート」は違う
最初に私が作った記録シートは、使い物になりませんでした。
「初回返信までの時間（分）」という列を用意していました。一見よさそうです。ですが現場の人は、受付時刻と返信時刻を見て、毎回引き算をして入力することになります。
続くわけがありません。
いま出すシートは、受付日時と返信日時をそのまま入れると、分数が自動で出る形にしています。人に計算させない。当たり前のようですが、自分で作っているときは気づきませんでした。
データ源と記録者を決めないと、シートは埋まらない
もう1つ抜けていました。
シートの形を整えることばかり考えていて、その数字をどこで見るのか、誰が書くのか、いつ書くのかを確認していませんでした。
現場で止まるのは、書式ではありません。誰がいつ書くかが決まっていないと、どんなにきれいなシートでも空のままです。
いまは、シートを作る前にこの4つを聞くようにしています。
- データ源：その値はどこを見れば分かるか
- 記録者：誰が書くか。その人はそれを知っているか
- 記録頻度：1件ごとか、1日1回か
- 除外条件：数えない場合はあるか（テスト、社内からの依頼）
出典の扱いを、自分が間違えていた
公開前に、別のAIに辛口レビューをかけました。その1件目が私の事実誤りでした。
引用元の規格を2つ挙げて、まとめて「無料公開されている」と書いていたのですが、片方は公開されているのがサンプルだけで、本体は有料販売でした。測り方の話をしている資料で出典の扱いを間違えるのは、いちばんまずい種類の誤りです。
痛かったのは、以前の記事では正しく書けていたのに、道具に落とし込むときに雑にまとめたことです。元の資料が正しくても、別の形に移すときに壊れます。
指摘は14件ありました。何をどう直したかは、上のリポジトリの変更履歴に全部残しています。
よくある質問
Q. AIに指標を決めさせること自体、危なくないですか？
A. 決めさせるのではなく、候補を出させて、こちらが4条件で落とす使い方が安全です。とくに目標値は、AIに置かせないでください。自社の実測から決めます。
Q. 最初にいくつ指標を置けばいいですか？
A. 結果1つ、原因1つで十分です。一覧表を作ることが目的になった時点で、たいてい続きません。増やすのは、記録が続くと分かってからです。
Q. 数字にできない業務は、どうすればいいですか？
A. 品質管理には「代用特性」という考え方があります。直接測れないものを、測れる別のもので見る。「業務の分かりやすさ」なら「質問された回数」、「判断が言葉になっているか」なら「判断基準の文書があるか」。ただし代用だと必ず書いてください。
Q. 改善前を測り忘れました。もう手遅れですか？
A. 手遅れとは限りません。チケットの履歴、メールの日時、台帳、会計データから後追いで推定できることがあります。ただし、どこから取ったか・何が欠けているかを添えて、実測値とは分けて出してください。混ぜるのが一番まずいです。
Q. スキルを入れたのに出てきません。
A. Claude Codeは ~/.claude/skills/ を監視していて、スキルの追加・編集は再起動なしで反映されます。反映まで少し時間がかかることはあります。ただし、~/.claude/skills/ というフォルダ自体をそのとき初めて作った場合は、Claude Codeを開き直してください（監視の対象に入らないためです）。Codexは実行のたびに読み直します。
【訂正】2026年8月23日
公開当初、上のFAQで「Claude Codeは起動時にスキルを読み込む」と書いていましたが、これは誤りでした。
公式ドキュメントには Live change detection として、追加・編集は再起動なしで反映されると明記されています。
私が別のセッションで一度見えなかった事象だけを見て、仕様として一般化していました。訂正します。
おわりに
AIは、指標の候補を出すのが速いです。ですが「それは自分たちで動かせるのか」だけは、こちらが判定するしかありません。
業務のどこが動かせるかを知っているのは、AIではなく現場です。
「自社の業務に合わせたい」「どこから測ればいいか、一緒に整理してほしい」というご相談を承っています。
業務の流れを整理する"要件定義"から、運用後の保守まで対応します。
関連記事
- 「で、効果はどれくらい出たの？」に答えられないとき──改善の成果を、何で測るか
- 「あの人しか分からない」をなくす──業務の見える化、AIを使った5つの手順
ママゴトラボは、業務の自動化ツールを要件定義から設計してつくる開発ラボです。
属人化した業務の見える化から、自動化ツールの開発・保守まで承っています。
👉 ママゴトラボ｜業務自動化の開発ラボ