🧩

AI問い合わせ対応の分類ルールを、設定ファイルとして管理する

2026/06/01に公開

 AI問い合わせ対応の分類ルールを、設定ファイルとして管理する
問い合わせ対応にAI下書きを入れる時、プロンプトだけで運用を始めると、すぐに判断がぶれます。
同じような問い合わせなのに、ある日はAI下書きへ進み、別の日は担当者判断で止まる。

「急ぎ」「クレーム」「返金」「契約」「個人情報」などの扱いが、人によって変わる。

あとから見返しても、なぜAIに渡したのか、なぜ人間確認にしたのか分からない。
この問題は、プロンプトを長くするだけでは解決しにくいです。
この記事では、問い合わせ分類ルールをコード内に直書きせず、設定ファイルとして管理する方法を整理します。実装例はGoogleスプレッドシートとGASを想定しますが、Notion、CRM、Zapier、Make、独自DBでも同じ考え方で使えます。
Miraigentでは、AI導入前の業務整理で「AIに渡す前の分類」と「人間に戻す条件」を先に決めることを重視しています。

 この記事で作るものこの記事の完成形は、次の4つです。
問い合わせ分類ルールを管理するYAML
AI下書き可否を決める判定フロー
判定結果を受付ログへ残す項目
GASで分類ルールを読み、レビュー要否を返す最小コード

 想定する読者問い合わせ対応にAI返信下書きを入れたい人
Googleフォーム、スプレッドシート、GASで小さく運用を始めたい人
FAQ、CRM、AI下書き、人間レビューの境界を決めたい人
AIの回答品質だけでなく、運用品質も管理したい人
この記事では、AI APIの呼び出しそのものは扱いません。
まずは、AIに渡してよい問い合わせかどうかを安定して判断できる状態を作ります。

 なぜ分類ルールを設定ファイルにするのか問い合わせ分類は、最初は簡単に見えます。
たとえば、GASの中に次のような条件を書けば動きます。
if (message.includes("返金")) {
  return "human_review";
}
ただ、運用が始まると条件は増えます。
返金、解約、契約変更は人間確認にする
営業時間、所在地、一般的な料金説明はAI下書き可にする
個人情報、健康状態、法務、税務、採用、苦情は人間確認にする
VIP顧客、既存契約中、未払い、過去クレームありは担当者へ戻す
未分類の問い合わせはAIへ渡さず、分類ルールの改善候補にする
これをコード内に直書きし続けると、変更理由が分かりにくくなります。
分類ルールは、プログラムではなく業務ルールです。
そのため、エンジニアだけでなく、現場担当者や責任者が読める形で管理した方が安全です。

 分類ルールの基本形まず、問い合わせを4段階に分けます。


class
意味
AI下書き
人間確認


A
一般FAQで回答できる
可
任意

B
個別条件の確認が必要
条件付き
必須

C
リスクや苦情を含む
不可
必須

D
分類不能、情報不足
不可
必須

この分類は、AIの賢さを測るためではありません。
問い合わせを受けたあと、誰が何を確認すべきかを決めるための運用分類です。

 YAMLで管理する例小さく始めるなら、次のようなYAMLで十分です。
version: 2026-06-01
default:
  class: D
  ai_draft_allowed: false
  review_required: true
  reason: "分類不能または情報不足"

rules:
  - id: faq_basic_info
    class: A
    ai_draft_allowed: true
    review_required: false
    keywords:
      - 営業時間
      - 所在地
      - アクセス
      - 料金プラン
    reason: "一般FAQで回答できる可能性が高い"

  - id: booking_or_availability
    class: B
    ai_draft_allowed: true
    review_required: true
    keywords:
      - 予約
      - 空き
      - 日程変更
      - キャンセル
    reason: "個別状況の確認が必要"

  - id: refund_contract_complaint
    class: C
    ai_draft_allowed: false
    review_required: true
    keywords:
      - 返金
      - 解約
      - 契約
      - クレーム
      - 苦情
    reason: "金銭、契約、苦情を含むため人間確認"

  - id: sensitive_personal_context
    class: C
    ai_draft_allowed: false
    review_required: true
    keywords:
      - 病気
      - 診断
      - 住所
      - 電話番号
      - 本人確認
    reason: "個人情報または専門判断に近い可能性"
実運用では、YAMLをGitで管理するか、スプレッドシートの「分類ルール」シートで管理します。
非エンジニアが編集するなら、スプレッドシートの方が始めやすいです。

 スプレッドシートで管理する列スプレッドシートで運用する場合は、分類ルール用のシートを1枚作ります。


列名
例
目的


rule_id
refund_contract_complaint
ルールを一意に追う

enabled
TRUE
一時停止できるようにする

class
C
A/B/C/D分類

keywords
返金,解約,契約,クレーム
検出語

ai_draft_allowed
FALSE
AI下書きへ進めてよいか

review_required
TRUE
人間確認が必須か

owner
CS責任者
判断責任者

reason
金銭/契約/苦情を含む
ログに残す理由

ポイントは、reason を必ず持たせることです。
分類結果だけでは、あとから判断を見直せません。
「なぜ止めたのか」「なぜAIに渡したのか」を残すことで、FAQ改善やルール改善につなげられます。

 受付ログへ残す項目問い合わせ受付ログには、少なくとも次の列を追加します。


列名
例
用途


inquiry_id
INQ-20260601-001
問い合わせID

source
form
流入元

message
料金プランを知りたい
問い合わせ本文

detected_rule_id
faq_basic_info
一致したルール

inquiry_class
A
A/B/C/D分類

ai_draft_allowed
TRUE
AI下書きへ進めるか

review_required
FALSE
人間確認が必要か

review_owner
CS責任者
確認担当

decision_reason
一般FAQで回答できる可能性が高い
判断理由

final_status
draft_created
最終状態

final_status は、次のように固定値にしておくと集計しやすくなります。
received
classified
draft_created
human_review
replied
blocked
need_rule_update
未分類が増えているなら、問い合わせが悪いのではなく、分類ルールが現場に追いついていない可能性があります。

 GASで分類する最小コード次は、分類ルールを配列として持った最小コードです。
実務ではスプレッドシートから読み込む方がよいですが、まず挙動を確認するために、コード内の配列から始めても構いません。
const RULES = [
  {
    id: "faq_basic_info",
    className: "A",
    aiDraftAllowed: true,
    reviewRequired: false,
    keywords: ["営業時間", "所在地", "アクセス", "料金プラン"],
    reason: "一般FAQで回答できる可能性が高い",
  },
  {
    id: "booking_or_availability",
    className: "B",
    aiDraftAllowed: true,
    reviewRequired: true,
    keywords: ["予約", "空き", "日程変更", "キャンセル"],
    reason: "個別状況の確認が必要",
  },
  {
    id: "refund_contract_complaint",
    className: "C",
    aiDraftAllowed: false,
    reviewRequired: true,
    keywords: ["返金", "解約", "契約", "クレーム", "苦情"],
    reason: "金銭、契約、苦情を含むため人間確認",
  },
];

const DEFAULT_DECISION = {
  ruleId: "default_unclassified",
  className: "D",
  aiDraftAllowed: false,
  reviewRequired: true,
  reason: "分類不能または情報不足",
};

function classifyInquiry(message) {
  const normalized = String(message || "").trim();

  if (!normalized) {
    return DEFAULT_DECISION;
  }

  for (const rule of RULES) {
    const matched = rule.keywords.some((keyword) => normalized.includes(keyword));
    if (matched) {
      return {
        ruleId: rule.id,
        className: rule.className,
        aiDraftAllowed: rule.aiDraftAllowed,
        reviewRequired: rule.reviewRequired,
        reason: rule.reason,
      };
    }
  }

  return DEFAULT_DECISION;
}
問い合わせ本文を受け取ったら、結果を受付ログへ書き込みます。
function appendClassificationResult(rowNumber, message) {
  const sheet = SpreadsheetApp.getActive().getSheetByName("受付ログ");
  const decision = classifyInquiry(message);

  sheet.getRange(rowNumber, 6, 1, 5).setValues([[
    decision.ruleId,
    decision.className,
    decision.aiDraftAllowed,
    decision.reviewRequired,
    decision.reason,
  ]]);
}
この例では、6列目から次の5項目を書き込む想定です。
detected_rule_id
inquiry_class
ai_draft_allowed
review_required
decision_reason
列位置を固定で書くのが不安な場合は、ヘッダー名から列番号を取得する関数を作ってください。

 AI下書きに進める条件AI下書きに進める条件は、分類結果だけで決めない方が安全です。
最低限、次の条件をすべて満たす時だけ進めます。

ai_draft_allowed が TRUE
問い合わせ本文に、不要な個人情報や機密情報が含まれていない
参照するFAQや商品説明が最新である
送信前の人間確認が必要な分類では、未確認のまま送信しない
AIが作るのは「送信用の確定文」ではなく「下書き」である
特に、B分類はAI下書きを作れても、人間確認は必須にします。
予約、日程変更、キャンセル、見積もり、既存契約の確認などは、文章だけ自然でも、事実確認を誤ると問題になります。

 人間が必ず見る条件次の条件に当てはまる場合は、AI下書きへ進める前に人間確認へ戻します。
返金、解約、契約変更、請求、未払い
苦情、強い不満、炎上の可能性
個人情報、本人確認、健康、法務、税務、採用
既存顧客ごとの契約条件確認
価格交渉、特別対応、例外対応
分類不能、本文不足、意図不明
ここを曖昧にすると、AIが悪いというより、運用設計の責任範囲が曖昧になります。
AIに任せる範囲と、人間が責任を持つ範囲を先に分けてください。

 ルール改善の見方分類ルールは一度作って終わりではありません。
週1回でもよいので、次の観点で見直します。
D分類が多すぎないか
C分類に本来A/Bでよい問い合わせが混ざっていないか
AI下書き後に人間修正が多い分類はどれか
FAQ化できる問い合わせが個別対応のまま残っていないか

reason が現場担当者に伝わる言葉になっているか
集計するときは、最初はこの程度で十分です。
週次レビュー項目
- 問い合わせ総数
- A/B/C/Dの件数
- AI下書き作成数
- 人間確認数
- blocked件数
- need_rule_update件数
- FAQ追加候補数
「AIが何件返信したか」だけを見ると、危ない問い合わせを止められた価値が見えなくなります。
止めた件数、止めた理由、ルール改善候補も一緒に見ます。

 小さく始める時のチェックリスト最初の導入では、次の順番で進めると事故が起きにくくなります。
問い合わせ受付ログを1つに集約する
A/B/C/Dの分類定義を決める
AI下書き可否と人間確認条件を分ける
分類ルールをYAMLまたはスプレッドシートに置く
判定理由を受付ログへ残す
C/D分類はAIへ渡さない
B分類はAI下書き後に人間確認を必須にする
週1回、D分類と人間修正が多い分類を見直す
この状態まで作ると、AI返信下書きのプロンプト改善も進めやすくなります。
どの問い合わせで失敗したのか、どの分類で修正が多いのかが見えるからです。

 まとめAI問い合わせ対応で最初に必要なのは、強いプロンプトだけではありません。
問い合わせをどう分類し、AIに渡してよいものと、人間が見るべきものをどう分けるかです。
分類ルールを設定ファイルとして管理すると、判断基準をチームで見直せます。
まずは、直近20件の問い合わせをA/B/C/Dに分けてください。
そのうえで、AIに渡す前に止めたい条件が何かを1行ずつ書き出すと、最初の分類ルールが作れます。
無料診断や問い合わせ対応にAIを入れる前に確認したいのは、次の一点です。
その問い合わせをAIに渡さない条件は、チーム内で同じ言葉になっていますか。

 Miraigentの公開リソースMiraigentでは、AI導入前に整えるべき問い合わせ対応、FAQ、CRM、人間確認ルールを整理しています。
公開リソース: https://miraigent.com/resources
無料診断: https://miraigent.com/diagnosis
GitHub: https://github.com/Miraigent/miraigent-ai-ops-templates
npm: https://www.npmjs.com/package/@miraigent/ai-ops-templates

class	意味	AI下書き	人間確認
A	一般FAQで回答できる	可	任意
B	個別条件の確認が必要	条件付き	必須
C	リスクや苦情を含む	不可	必須
D	分類不能、情報不足	不可	必須

列名	例	目的
rule_id	refund_contract_complaint	ルールを一意に追う
enabled	TRUE	一時停止できるようにする
class	C	A/B/C/D分類
keywords	返金,解約,契約,クレーム	検出語
ai_draft_allowed	FALSE	AI下書きへ進めてよいか
review_required	TRUE	人間確認が必須か
owner	CS責任者	判断責任者
reason	金銭/契約/苦情を含む	ログに残す理由

列名	例	用途
inquiry_id	INQ-20260601-001	問い合わせID
source	form	流入元
message	料金プランを知りたい	問い合わせ本文
detected_rule_id	faq_basic_info	一致したルール
inquiry_class	A	A/B/C/D分類
ai_draft_allowed	TRUE	AI下書きへ進めるか
review_required	FALSE	人間確認が必要か
review_owner	CS責任者	確認担当
decision_reason	一般FAQで回答できる可能性が高い	判断理由
final_status	draft_created	最終状態

AI問い合わせ対応の分類ルールを、設定ファイルとして管理する

この記事で作るもの

想定する読者

なぜ分類ルールを設定ファイルにするのか

分類ルールの基本形

YAMLで管理する例

スプレッドシートで管理する列

受付ログへ残す項目

GASで分類する最小コード

AI下書きに進める条件

人間が必ず見る条件

ルール改善の見方

小さく始める時のチェックリスト

まとめ

Miraigentの公開リソース

Discussion