AIで問い合わせの緊急度を判定するルールを作る方法

問い合わせの緊急度をAIに判定させるときは、怒りの強さではなく「放置した場合の業務・顧客への影響」と「対応可能な時間」を基準にします。AIには本文から影響範囲、期限、障害、金銭・安全上の兆候などを抜き出させ、優先度への割り当ては会社が決めたルールで行います。影響が不明、情報が食い違う、または安全・不正に関わる可能性がある問い合わせは、自動で低優先度にせず人へ回してください。

この記事の目的はAIに「重要そうか」を自由に決めさせることではありません。自社のサポートSLAと業務リスクに合わせた分類表を作り、受信文からAIが拾うSignal、次に取るAction、誤判定を検出する方法を決めることです。以下の区分や例は設計の出発点であり、共通の時間基準や法律上の優先度を示すものではありません。実際の閾値は、担当チームと責任者が承認してください。

感情ではなく、影響と時間で分類する

まず「緊急」を運用可能な言葉にします。次の2軸を分けると、怒りの表現だけに引きずられにくくなります。

• 影響（Impact）：何人・何業務に影響するか、代替手段があるか、金銭・安全・情報管理への影響があるか。

• 時間制約（Time sensitivity）：いつまでに対応しないと影響が広がるか、期限を過ぎたときに取り戻せるか。

表は横にスクロールできます

優先度の例	条件の考え方	AIが抽出する情報	初期Action
Critical候補	複数顧客への広範な停止、アカウント侵害の疑い、安全上の危険など、放置による損失が大きく、影響が進行中	対象機能・顧客範囲・開始時刻・被害の進行・回避策の有無	定めた緊急窓口へ即時エスカレーション。AIだけで完了・却下しない
High候補	重要業務が止まる、締切が迫る、代替策がないなど、通常順より先に人が確認すべき	期限、業務影響、代替手段、顧客の次の予定	優先Queueへ送り、担当者がSLAを適用
Standard候補	個別の質問や回避可能な不具合など、定めた通常処理で扱える	問題の種類、利用環境、再現条件	通常Queueへ分類。必要な追加情報を案内
Unknown / Review	影響範囲が分からない、日時・事象が矛盾する、分類への確信が低い、ルールにない内容	不明項目、矛盾する記述、追加確認事項	人の確認へ回す。情報不足を理由に自動で低優先度へ落とさない

「Critical候補」の例に当てはまる単語があるだけで自動確定するのではありません。たとえば「ログインできない」は、一人だけの端末問題か全社的な認証障害かで影響が違います。分類前に「対象の人数・機能」「発生開始時刻」「代替手段」「既知の障害情報」を確認する設計にします。サービス停止や不正アクセスの疑いなど、社内の既存Incident手順がある場合は、その手順を分類モデルより優先します。

自社用の閾値を決める

「何分以内ならHighか」の数値を他社記事から借りるのではなく、自社の契約SLA、有人対応時間、重大障害手順、業務上の締切から定めます。担当部署と一次対応者が「この案件ならどのQueueへ置くか」を合意した具体例を使ってください。営業時間外の扱い、休日、担当不在、同一障害に関する複数チケットのまとめ方も先に決めます。

AIに任せる範囲を切り分ける

AIは、文章の中から複数の情報を抽出し、担当者が読み始める位置を整える役に向いています。一方、事業上の優先度・SLA・安全判断の所有者にはなりません。

表は横にスクロールできます

工程	AIの役割	人・システム側で決めること
Signal抽出	事象、時刻、影響対象、期限、代替策、顧客の困りごとを候補として示す	どの項目が実運用の証拠になるか、必須情報は何か
Rule適用	根拠となる明示Ruleを参照して候補Queueを返す	PriorityとSLA、上書き権限、エスカレーション先
不確実性の扱い	欠落・矛盾・未定義の兆候を示す	Unknownを誰がどの時間内に確認するか
対応	下書き要約や必要質問を作る	返金、アカウント停止、セキュリティ対応などの決定
改善	誤判定例を集計する材料を作る	指標の評価、Ruleの変更、変更承認

怒りの強さや文面の丁寧さを、影響度の代わりにしないでください。短文で淡々と報告する顧客の大規模障害が、感情的な個人の軽微な不満より緊急の場合があります。Sentimentは対話の配慮を考える補助Signalにはなりますが、Priorityを決める単独条件にはしません。ZendeskのIntelligent Triageはtopic、sentiment、language、custom entities等でチケットを分類する製品例です。この製品例は一般的なAIの正確性や、どのサポート製品でも同じ分類が使えることを保証しません。

分類Ruleを作る手順

1. 実際の問い合わせと運用結果を集める

直近のチケットから、通常案件、過小評価が起きた案件、過大評価された案件、Unknownにすべき案件を選びます。個人情報や機密情報はテスト用に削除・置換します。ラベルだけでなく、その時にどの業務が止まり、誰がどのActionを取ったかを記録します。過去に担当者が付けたPriorityを正解と決めつけず、SLAや対応結果との整合性を担当者と確認します。

2. 先に例外Ruleを書く

通常の質問分類より前に、「Securityチームへ送る」「安全・不正の可能性を人が確認する」「既知の障害へ紐づける」など、組織内の既存手順を洗い出します。これらの例外は単なるキーワード一致にしません。「パスワード」という語があるだけでは侵害とは限らず、入力内容・申告された事象・既知のアラートを合わせて確認します。RuleにないケースはUnknownにできます。

3. SignalとPriorityを分けて保存する

AI出力は最終Priorityだけでなく、どの情報を根拠にしたかを残します。例えば次のような構造です。値は機械が確認できた事実と、本人の申告を区別し、分からないものはunknownにします。

{

  "impact_scope": "複数ユーザーとの申告",

  "business_function": "決済処理",

  "started_at": "記載なし",

  "deadline": "本日中との申告",

  "workaround": "unknown",

  "security_or_safety_signal": "要確認",

  "matched_rule_id": "PAYMENT_OUTAGE_01",

  "priority_candidate": "High",

  "reason": "決済処理が利用できないとの申告。影響人数・回避策は未確認",

  "human_review": true

}

ここで示したフィールド名や値は実装用の標準Schemaではなく、設計を具体化する例です。実際のデータ構造、保存期間、アクセス権は社内のチケットシステムと情報管理ルールに合わせます。AIの推定を、顧客が明示した事実のように記録しないことが重要です。

4. Human handoffを決める

次の場合は担当者へ確認します。

• 影響範囲や発生時刻がなく、Priorityを決める根拠が足りない

• メール本文、添付情報、既知の障害情報が矛盾する

• ルールに該当しない事象や新しい製品機能の問題

• 安全、決済、個人情報、アカウント不正など、既存手順との連携が必要

• AIの候補Queueと、手動Ruleの結果が異なる

• 顧客への不可逆なAction（契約終了、権限停止、返金等）を伴う

handoff先だけを決めても運用は成立しません。担当者不在時の代替、営業時間外の通知、情報不足の場合の顧客への追加質問、判断記録の保管場所まで定義してください。

導入前に誤判定を測る

初期運用では、自動で処理を閉じたり顧客へ確定案内を送ったりせず、既存担当者の判定と並べて候補の妥当性を確認する方法があります。ここでの目的は、AIの一致率だけを見て合格にすることではありません。重大案件の見逃しと、通常案件を過剰に緊急化する割合では、影響が違います。

検証用の問い合わせを、少なくとも次のグループに分けます。

• 一人の利用者だけに起きた操作エラー

• 複数利用者の同一機能停止

• 時刻・期限の明示がある案件とない案件

• 怒りの表現は強いが業務影響が限定的な案件

• 表現は穏やかだが決済・安全・情報管理の影響がある案件

• 情報が足りない、または記述が矛盾する案件

• 過去の分類と現在のSLAが一致しない案件

各例で、(1) 抽出されたSignal、(2) 適用Rule、(3) 候補Priority、(4) handoffの要否を人が確認します。誤りは「影響の見落とし」「期限の誤読」「Sentimentの過大評価」「Unknownを低優先にした」など原因別に記録し、Ruleや入力例を直します。精度の数字を出す場合も、重大案件を一つ見逃す重みを通常のラベル違いと同一に扱わず、どの誤りを許容しないかを事業責任者が決めます。

よくある失敗と戻し方

怒っている文面を全部Criticalにする

顧客の感情と業務影響を別フィールドにします。Sentimentは応答の配慮に利用し、PriorityはImpactとTime sensitivity、組織のRuleで決めます。

「障害」という単語だけで緊急Queueに送る

一人の端末、複数の顧客、回避策の有無、発生中か再現済みかを確認します。キーワードは候補抽出に使い、Actionの決定には文脈を必要とします。

文章が短いチケットを低優先にする

短さは影響の小ささを意味しません。本文に情報がないときは自動的にStandardへ落とさず、追加質問またはUnknown reviewへ送ります。

モデル更新後に分類の傾向が変わる

導入時と同じ代表ケースを再実行し、優先度別の見逃し・過剰判定が変わっていないか比較します。Rule、モデル、プロンプトのどれを変えたか記録し、一度に複数要因を変えないようにします。

結論：AIの候補と運用Ruleを分けて始める

先に作るのはAIへの「重要度を判断するプロンプト」ではなく、影響・時間・例外・人手確認を定めた組織のRuleです。その後でAIにSignal抽出と根拠を返させ、ルールに照らした候補を返させます。過去チケットで重大な見逃しを確認し、担当者が許容できると判断した範囲から運用へ移してください。

NISTのAI RMF Playbookは、リスク管理のための提案行動を示す任意の資料であり、全項目を守るチェックリストではありません。ここでは「用途・影響・責任・継続的な評価を明確にする」という設計の参考として扱います。自社のSLA、セキュリティ対応、法令上の義務を置き換えるものではありません。

AIものさしの判断

緊急度をAIの単独スコアで決める設計は避けます。Business ImpactとTime Sensitivityから組織のPriority Ruleを作り、AIは本文からSignalと根拠を抽出し、ルールに照らした候補を返すところまでにします。影響不明、矛盾、重大な例外はUnknownとして人に渡します。運用前に代表チケットで見逃しを検証し、例外処理を含むhuman handoffが成立した時点で段階的に適用してください。