2026-10-09確認。問い合わせ対応のAI化を検討するエンジニア・テックリードが、どの処理を検証対象にし、どこを人に残すかを決めるための測定設計です。
結論：AIを選ぶ前に、件数と作業時間と例外を分ける
最初に必要なのはモデル比較ではなく、現状の基準値です。問い合わせが多い処理と、人の時間を使っている処理は一致するとは限りません。
| 観測した条件 | 次に選ぶこと |
|---|---|
| 最新の公開FAQで答えられる質問が多い | FAQの導線・検索・定型文の改善を先に比較する |
| 根拠はあるが、複数条件の整理に時間がかかる | 人が確認する回答下書きの小さなPoCを検討する |
| 個別情報、状態変更、根拠不足・矛盾が中心 | 自動回答を見送り、業務・情報・権限を整理する |
| 作業時間や未解決件数が測れていない | 導入判断を保留し、測定から始める |
これは条件付きの設計案です。以下の検証は架空データの集計だけで、AIの精度・導入効果・本番運用を検証したものではありません。
課題・前提：速い返信と、少ない作業は別の指標
Zendeskの公式資料では、初回返信時間はチケット作成から最初の公開エージェント返信まで、完全解決時間は作成から最新の解決までを表します。必要なイベントが未発生なら値はnullです。
これらはイベント間の経過時間です。本稿では別に、人が調査・回答・確認・修正へ実際に使った時間を測る設計にします。待機時間をそのまま人件費削減へ換算しません。
| 記録するもの | 定義・判断への使い方 |
|---|---|
| 分類別の件数 | 対象期間、受付チャネル、重複の扱いを固定する |
| 人の実作業時間 | 調査・回答・確認・修正を含める。未計測は0にしない |
| 初回返信・解決の経過時間 | 暦時間か営業時間かをそろえ、未返信・未解決を別に数える |
| 根拠と例外 | 最新の根拠があるか、個別情報・書込み・矛盾があるか |
| やり直し | 再問い合わせ、回答修正、引継ぎの件数と時間 |
NIST AI RMF CoreのMEASURE 2.1は評価データ・指標・ツールの記録、2.3は導入環境に近い条件での評価を扱います。PlaybookのMEASURE 3.1は、単純な方式や人の基準性能との比較を提案しています。
ここから「手動対応とFAQ改善を比較対象に残す」と判断しました。問い合わせ向けの特定指標や合格値をNISTが指定している、という意味ではありません。
選択肢：現状維持・FAQ・既製品も同じ土俵に置く
| 選択肢 | 向く条件 | 採用前に残る確認 |
|---|---|---|
| 手動を維持し定型文を整理 | 少量、例外が多い | 忙しい時間帯と引継ぎの負担 |
| FAQ・検索・フォーム改善 | 公開根拠と定型質問がある | 利用者が答えを見つけられるか |
| 既製品の対応支援 | 既存の問い合わせ管理に組み込める | 権限、データ利用、計測定義、費用 |
| 自作のAI下書き | 独自の品質判定が必要 | 根拠確認・修正・保守を含む負担 |
同じ質問集合と品質条件で比較します。新規ツールが必要とは限らず、この段階では製品やモデルの推奨はしません。
小さな検証：件数の50%は、作業時間の50%ではない
架空の問い合わせ12件を用意しました。質問、区分、作業分数はすべて例示用に設定したもので、実業務の観測値ではありません。
| ID | 模擬問い合わせ | 仮定した作業分数 | 手で付けた区分 |
|---|---|---|---|
| F01 | サポートの受付時間は？ | 2 | 最新の公開根拠・単一条件 |
| F02 | マニュアルはどこ？ | 3 | 同上 |
| F03 | 対応ブラウザーは？ | 4 | 同上 |
| F04 | 一般的な利用開始手順は？ | 2 | 同上 |
| F05 | 更新情報はどこ？ | 3 | 同上 |
| F06 | ヘルプの探し方は？ | 4 | 同上 |
| D01 | 複数の公開設定を組み合わせられる？ | 10 | 最新の公開根拠・複数条件 |
| D02 | 公開された連携条件を整理したい | 12 | 同上 |
| H01 | 自分の契約状態を確認したい | 15 | 個別情報が必要 |
| H02 | 登録内容を変更してほしい | 18 | 書込みが必要 |
| H03 | 文書にない例外条件を知りたい | 20 | 根拠なし |
| H04 | 二つの説明が食い違っている | 25 | 根拠が矛盾 |
faqはFAQ改善の候補、draftは人が確認する下書きの候補、humanは人が判断を続ける対象です。自動送信の許可を示す区分ではありません。 根拠状態も架空のラベルで、本文からLLMが分類する処理は含めていません。
再現手順：次のコードをbaseline.pyへ保存し、python3 baseline.pyを実行します。2026-10-09にPython 3.11.8で実行しました。標準ライブラリだけを使い、外部通信・LLM呼出しはありません。
import json
import math
from collections import Counter
# 全て架空。時間は計算例の仮定で、実測値ではない。
# ID, 人の実作業分, 根拠状態, 個別情報, 書込み, 複数条件
ROWS = [
("F01", 2, "current", False, False, False),
("F02", 3, "current", False, False, False),
("F03", 4, "current", False, False, False),
("F04", 2, "current", False, False, False),
("F05", 3, "current", False, False, False),
("F06", 4, "current", False, False, False),
("D01", 10, "current", False, False, True),
("D02", 12, "current", False, False, True),
("H01", 15, "current", True, False, False),
("H02", 18, "current", False, True, False),
("H03", 20, "missing", False, False, False),
("H04", 25, "conflict", False, False, False),
]
def summarize(rows):
counts, minutes = Counter(), Counter()
seen, unmeasured = set(), 0
for key, work, evidence, individual, write, complex_case in rows:
if not isinstance(key, str) or not key or key in seen:
raise ValueError("IDは空でない一意の文字列にする")
seen.add(key)
if evidence not in {"current", "missing", "conflict", "unknown"}:
raise ValueError("根拠状態を確認する")
if any(type(v) is not bool for v in (individual, write, complex_case)):
raise ValueError("区分はboolにする。未確認をFalseで埋めない")
if work is not None and (
type(work) not in (int, float) or not math.isfinite(work) or work < 0
):
raise ValueError("作業時間は非負の有限数かNoneにする")
if individual or write or evidence != "current":
route = "human"
else:
route = "draft" if complex_case else "faq"
counts[route] += 1
if work is None:
unmeasured += 1
else:
minutes[route] += work
total_work = sum(minutes.values())
return {
"count": dict(counts), "known_minutes": dict(minutes),
"unmeasured": unmeasured,
"faq_count_pct": round(100 * counts["faq"] / len(seen), 1) if seen else None,
"faq_work_pct": round(100 * minutes["faq"] / total_work, 1)
if total_work > 0 and unmeasured == 0 else None,
}
if __name__ == "__main__":
print(json.dumps(summarize(ROWS), ensure_ascii=False, indent=2))
出力の主要部分は次のとおりです。
{
"count": {"faq": 6, "draft": 2, "human": 4},
"known_minutes": {"faq": 18, "draft": 22, "human": 78},
"unmeasured": 0,
"faq_count_pct": 50.0,
"faq_work_pct": 15.3
}
FAQ候補は6/12件で50%、仮定した作業時間では18/118分で15.3%です。この例は、対象件数だけで省力化を見積もると、時間の重みを見落とすことを示します。15.3%は削減率でも、その上限の実測値でもありません。
正常集計に加え、空入力、時間欠測、時間合計0、重複ID、負の時間、NaN、無限大、boolの時間、文字列の区分、不正な根拠状態、個別情報・書込み・矛盾を優先する分岐の計14項目を確認しました。時間未計測の1件を追加すると、件数には含まれ、unmeasured: 1とfaq_work_pct: nullになります。
確認できたのは計算と入力検証・分岐です。実際の分類精度、FAQの発見率、回答品質、作業時間の短縮は未検証です。
品質・費用・運用：何を人に残すか
本番へ近づける際は、同じ評価集合について手動、FAQ、AI下書きを比べ、次を分けて記録します。
人の時間差 = 手動の実作業時間
- 導入後の確認・修正・例外対応を含む実作業時間
運用・保守の固定工数、利用料、API費用は別に加えます。今回は導入後の時間も価格も測っていないため、ROIは算出できません。
| 失敗パターン | 設計上の対応と責任 |
|---|---|
| 欠測を0分にし、効果があるように見える | 計測担当が欠測率と対象期間を記録する |
| 件数が多い軽い質問だけでPoCを評価する | 業務担当が例外と重い質問を評価集合に残す |
| 古い文書や矛盾した根拠で回答する | ナレッジ担当が鮮度と根拠を確認し、人へ戻す |
| 個別情報・書込みをFAQ候補に混ぜる | 実装担当が閲覧・変更・送信の権限を分ける |
| 引継ぎや修正の時間を除外する | 運用担当が解決までの総作業を記録する |
この責任分担と停止条件は設計案です。後続のPoCでは、根拠・品質を確認できないものは自動送信せず、人が扱う状態を保つことを前提にします。
条件付きの推奨と次の確認
FAQ候補が多いだけなら、まずFAQの導線を改善する比較を推奨します。複数条件の整理に時間がかかり、根拠と確認担当を用意できるなら、人の確認を前提にAI下書きを追加検証します。個別情報・書込み・根拠不足が多い、または現状を測れないなら自動回答を見送ります。
開発・DX責任者が決めるのは、今すぐ全面導入するかではなく、どの範囲へ次の検証時間を使うかです。
- 業務担当：比較期間・受付チャネル・重複・未解決の扱いを定義する
- 計測担当：時間の記録方法と欠測を確認し、繁忙期との差を残す
- エンジニア・TL：同じ集合で手動・FAQ・下書きの品質と総作業時間を比較する
- 責任者：許容できない誤り、停止条件、継続費用、対応担当を先に決める
今回の架空12件から実際の問い合わせ分布へ一般化はできません。実データで検証する場合も、権限のある業務環境で最小限の情報を扱い、公開記事へ転用しないことが前提です。
参考資料
すべて2026-10-09確認。資料の記述と、本稿の分類・採否判断の設計案は区別しています。
- NIST AI RMF Core：MEASURE 2.1・2.3
- NIST AI RMF Playbook：MEASURE 3.1の比較対象
- Zendesk：About native Support time duration metrics
この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表。AI × Web × 業務自動化の開発・検証に取り組んでいます。
技術選定・品質・運用の判断材料を、検証範囲と制約を示して発信しています。
AI導入や業務自動化の技術選定・設計整理については、対応できる範囲を確認のうえご相談を承ります。