自動化にAIの要約・分類を組み込むときの確認点:結果を信じすぎない設計

1. 基本の形:「AI → ルール検査 → 振り分け」

おすすめの流れは次の4段です。

1. 入力チェック:AIに渡してよいデータか、空や長すぎでないかを確認する
2. AIステップ:要約・分類を、決まった形式(JSONなど)で出させる
3. 出力チェック:形式、選択肢の範囲、根拠、確信度をルールで確認する
4. 振り分け:通ったものだけ自動処理、それ以外は人の確認キューへ

ポイントは、人に回す道を「例外処理」ではなく最初から本流の一部として作っておくことです。AIは言い切った口調で間違えることがあるため、「間違えたら気づく仕組み」がないと、誤りが黙って業務データに溜まります。

2. AIステップの前に置く検証

AIに渡す前に確認すると、無駄な誤りをかなり減らせます。

• 本文が空・極端に短い、例：「了解」だけのメール、NGのときの扱い：AIを呼ばず人へ、または固定ラベル「情報不足」
• 長すぎる、例：引用が延々続く返信チェーン、NGのときの扱い：先頭や新しい部分だけに切る。切ったことを記録
• 渡してはいけない情報、例：氏名・電話番号・口座情報、NGのときの扱い：伏せ字に置換してから渡す。置換できなければ人へ
• 言語・形式の想定外、例：想定外の言語、添付のみ、NGのときの扱い：人へ回す

情報の取り扱いでは、「学習に使われない設定」と「秘密を守れること」は別の話だと考えてください。設定でオフにできる場合でも、渡す情報を最小にする方針は変わりません。

3. AIに渡す依頼文の例

分類は、選択肢を固定し、根拠の抜き出しと自己申告の確信度を一緒に出させます。以下は編集側の提案する依頼文の例です。

あなたは問い合わせの分類担当です。次の本文を読み、JSONだけを返してください。

選べるカテゴリ(これ以外は禁止):
- billing(料金・請求)
- bug(不具合の報告)
- howto(使い方の質問)
- other(上記のどれにも当てはまらない、または判断できない)

ルール:
- 本文に書かれていないことを推測で補わない。
- 迷う場合や複数に当てはまる場合は other にする。
- evidence には、判断の根拠にした本文の一文を、一字も変えずに引用する。
- confidence は high / medium / low のいずれか。
- summary は80字以内。本文にない事実を書かない。

出力形式:
{"category":"","evidence":"","confidence":"","summary":""}

本文:
{{ここに問い合わせ本文}}

「迷ったら other」と「根拠を一字も変えずに引用」の2点が肝です。引用が本文に実在するかは、後段でルールとして機械的に確かめられます。

入力と出力の説明用の例です。

• 入力:「先月分の請求書が2通届いています。どちらが正しいですか」
• 期待する出力:{"category":"billing","evidence":"先月分の請求書が2通届いています","confidence":"high","summary":"請求書が重複して届いており、正しい方の確認を求めている"}

4. AIステップの後に置く検証と判断表

自己申告の確信度は、数字として当てにしすぎないでください。AIが「high」と答えても誤ることはあります。確信度は「人に回す条件の一つ」にとどめ、ルール検査と組み合わせます。

• 形式、内容：JSONとして読めるか、4項目が揃うか、失敗時：人へ(または再実行を1回だけ)
• 選択肢、内容：categoryが許可リストにあるか、失敗時：人へ
• 根拠の実在、内容：evidenceが元の本文に含まれるか、失敗時：人へ
• 長さ、内容：summaryが80字以内か、空でないか、失敗時：人へ
• 確信度、内容：lowか、失敗時：人へ
• 重要カテゴリ、内容：返金・解約・クレームなど、誤りの影響が大きい語を含むか、失敗時：確信度に関係なく人へ

判断は次のようにまとめられます。

• 全検査OK、confidenceがhigh、重要語なし、扱い：自動処理
• 全検査OK、confidenceがmedium、扱い：自動処理しつつ記録。一定割合を後で人が抜き取り確認
• どれか1つでも失敗、またはlow、またはcategoryがother、扱い：人の確認キューへ
• 重要語を含む、扱い：常に人へ

「medium」の扱いは、誤りが起きたときの被害の大きさで決めてください。社内の仕分け程度なら自動処理でもよく、顧客への返信に直結するなら人へ回すほうが安全です。

形式の自動修正機能がある場合も注意が必要です。たとえばn8nのText Classifierノードには、モデル出力を期待する形式に合わせて直す「Auto-Fixing」の設定があります(n8n Docs: Text Classifier)。これは形式を整える機能で、分類が正しいかどうかを保証するものではありません。形式が整っても、中身の検査は別に必要です。

5. 確信が低いときの人への回し方

n8nの場合

n8nのText Classifierノードには、「When No Clear Match」という設定があり、明確に当てはまらない項目を捨てる(既定)か、「Other」ブランチへ出すかを選べます。人に回す設計では、捨てずにOtherブランチへ出す設定にします。この設定は2026年10月28日にドキュメントで確認しました。

その上で、次のように組みます。

1. Otherブランチを、通知(メールやチャット)や、確認用シートへの書き込みにつなぐ
2. 通常のカテゴリ側にはIfノードを置き、前節の検査(evidenceの包含、confidenceの値など)を条件にする。Ifノードは文字列・数値などの比較を、AND/ORで組み合わせられます(n8n Docs: If)
3. 検査に落ちた側を、Otherと同じ確認キューに合流させる

想定外の失敗(AIの呼び出しエラーなど)には、エラーワークフローが使えます。ワークフロー設定でエラー用のワークフローを指定すると、実行が失敗したときに動き、Error Triggerが実行IDやエラーメッセージなどを受け取ります。また、Stop And Errorノードで意図的に失敗させ、エラーワークフローを呼ぶこともできます(n8n Docs: Error handling)。

なお、私が確認したText Classifierのページには、モデルの確信度を数値で返す設定の記載は見当たりませんでした。確信度を使いたい場合は、前節のようにJSONの項目として出させるのが現実的です。

Makeの場合

Makeのルーターは、条件(フィルター)ごとに分岐し、ルートは並列ではなく設定した順に処理されます。どの条件にも合わないデータを受ける「フォールバックルート」も指定できます(Make Help Center: Router)。

• 上位のルートに「検査が全部OK」の条件を置き、自動処理へつなぐ
• フォールバックルートを確認キュー(シートへの追記や通知)にする

これにより、条件を書き漏らしたパターンも、自動処理ではなく人の側へ落ちます。「自動処理に入る条件を狭く、それ以外は全部人へ」という向きにするのがコツです。

Zapierの場合

Zapierには、Zapを一時停止して人の承認を求める「Human in the Loop」の「Request Approval」アクションがあります。確認できた範囲(2026年10月28日時点)では、次の点が公式ヘルプに書かれています(Zapier Help: Request approval with Human in the Loop)。

• 有料プランが対象(Professional、Team、Enterprise)。Professionalでは自分自身にしか承認を依頼できない
• 確認者へはメール、Slack、別のZapの起動で通知できる
• 確認者にはZapierアカウントが必要です。Zapを共有し、確認者がログインして承認する必要があります
• 返信がないときは「スキップして続行」か「実行を終了」を選べる
• Loopingステップ内やその後には置けません。最後のアクションにもできます

AIの結果を扱うなら、タイムアウト時は「実行を終了」を選ぶのが安全側です。「スキップして続行」にすると、未確認のAI出力がそのまま流れる可能性があります。承認画面には、元の本文、AIの分類、evidence、summaryを並べて見せると、確認者が短時間で判断できます。

6. 確認キューを回し続けるための記録

人に回す仕組みは、作っただけでは改善しません。最低限、次の項目を1行ずつ残します。

• 元データの識別子(本文そのものでなく、IDや参照先でも可)
• AIの分類・確信度、人が最終的に決めた分類
• 人に回った理由(形式NG、根拠なし、low、重要語など)

「AIと人の結論が違った」行を月に一度見直すと、依頼文の改善点やカテゴリの定義の曖昧さが分かります。たとえばotherが多すぎるならカテゴリの説明不足、evidence不一致が多いなら入力が長すぎる可能性がある、といった具合です。ただし、これらは見直しのための仮説であり、原因を断定する材料ではありません。

最初は「自動処理は high かつ全検査OKのみ」と厳しく始め、人の確認結果が安定して合うことを確かめてから、mediumを自動側へ広げる順番をおすすめします。この記事の依頼文・条件・閾値は説明用の例なので、実際のデータで試し、自分の業務に合わせて調整してください。