問い合わせフォームに届いた文面を、人が一件ずつ開いて「これは請求の話」「これは障害だから急ぎ」と仕分けする——この最初の振り分け作業を、n8n（ノーコードの自動化ツール）と Claude API でどこまで自動化できるかを試しました。ここでいう自動トリアージとは、受信した問い合わせを「カテゴリ分類・緊急度判定・担当者割り振り」の3点まで機械が仕分けることを指します。
先に結論を書きます。合成した問い合わせ20件で実測したところ、カテゴリ分類は95%・担当者の割り振りは90%と実用域に届きました。一方で緊急度の判定は50〜65%と大きく落ち込み、しかも「低いはずの案件を高く見積もる」系統的な癖が出ました。さらに、誤答を防ぐつもりで用意した「判定不能なら人手に回す」逃げ道は、5件の罠のうち1件も使われませんでした。この記事は、その実測値と作ったワークフローを、失敗も含めて全部見せる記録です。
何を作ったか：受信 → Claude 分類 → 緊急度で振り分け
作ったのは3ステップの流れです。①問い合わせフォームの送信を n8n の Webhook ノードで受け取る、②その文面を Claude API に渡してカテゴリ・緊急度・担当者を一度に判定させる、③緊急度に応じて担当チームへ通知を振り分ける。今回は架空の勤怠管理 SaaS「ミナトヤ クラウド勤怠」への問い合わせを題材にしました。
分類の枠組みは、カテゴリ5種（課金・請求／技術的な不具合／使い方の質問／解約・返金／営業・提案依頼）、緊急度3段階（高／中／低）、担当者はカテゴリから決まる5チームです。精度を正直に測るため、正解ラベルは Claude に見せずにブラインドで分類させ、あとで突き合わせました。
トリアージの中身：1回のAPIで3つを出す
肝は、1回のAPI呼び出しで「カテゴリ・緊急度・担当者・確信度・理由」を構造化した JSON で返させることです。Anthropic の公式ドキュメントでも、出力の形をスキーマで固定する方法が案内されています（ツール使用 — Anthropic 公式）。実際に使ったシステムプロンプトの要点はこうです。
あなたはSaaS問い合わせ振り分け担当です。次のJSONのみを出力してください。
前後に説明文やコードブロックは付けない。
{
"category": "<課金・請求|技術的な不具合|使い方の質問|解約・返金|営業・提案依頼|判定不能（要人手）>",
"urgency": "<高|中|低|不明>",
"assignee": "<経理チーム|技術サポート|カスタマーサポート|リテンション担当|営業チーム|判定不能（要人手）>",
"confidence": <0-1>,
"reason": "<日本語1文>"
}
自信が持てない場合は無理に決め打ちせず「判定不能（要人手）」「不明」を選んでください。この「判定不能を選んでよい」という一文が、後半で検証する逃げ道です。測定モデルには、高頻度・低コストのトリアージ用途を想定して Claude Haiku 4.5 を使い、温度は0に固定しました。
実測：合成20件（うち罠5件）で計測した
20件のうち5件は、わざと引っかけの「罠」にしました。たとえば次の3つです（すべて合成の架空データで、実在の個人情報は含みません）。
「初めて使うので操作を教えてください。打刻ボタンを押してもずっと『読み込み中』のまま反応がありません。他のメンバーに聞いたところ、みんな同じ状態だと言っていました。どう操作すればよいですか？」
使い方の質問に見えて、実態は全員が打刻できない障害（緊急度＝高）
「いつもサポートいただきありがとうございます。おかげさまで勤怠管理はスムーズになりました。（中略）もし継続しない場合の手続きについて教えていただけますか。」
感謝の言葉で始まるが、実質は解約の下調べ（担当＝リテンション）
「貴社の上位プランへの切り替えを検討しており（中略）実はその前に、現在使っている打刻APIが今朝から504エラーを返し続けており（中略）まずはこの点の確認を急ぎでお願いします。」
営業相談の体裁だが、本題は緊急の技術障害
この20件を、①強制選択（必ず1つ選ばせる・逃げ道なし）と、②逃げ道あり（判定不能・不明を許可）の2条件でそれぞれ分類させ、正解率を測りました。
| 条件 | カテゴリ | 緊急度 | 担当者 |
|---|---|---|---|
| ①強制選択 | 95.0%（19/20） | 50.0%（10/20） | 90.0%（18/20） |
| ②逃げ道あり | 95.0%（19/20） | 65.0%（13/20） | 90.0%（18/20） |
カテゴリと担当者は、罠を除いた15件では取りこぼしゼロ（カテゴリ15/15・担当14/15）。カテゴリの仕分けと、そこから決まる担当チームへの割り振りは、安いモデルでも十分に任せられる精度でした。
逃げ道は一度も使われなかった
いちばん意外だったのがここです。「判定不能を選んでいい」と明示したにもかかわらず、Haiku 4.5 は5件の罠で一度も逃げませんでした（0/5件）。強制選択で自信満々に誤答した罠2件は、逃げ道を用意した条件でも同じ2件が同じように誤答し、確信度はいずれも0.75〜0.92と高いままでした。
誤答した2件はこうです。ひとつは「シフト管理の使い方を教えてほしい。使えないなら他社への乗り換えも検討する」という、操作質問と解約シグナルが混ざった境界事例（そもそも人間でも正解が割れます）。もうひとつが、先ほどの「感謝から入る解約の下調べ」で、丁寧な文面に引きずられてカテゴリ・緊急度・担当をすべて外しました。
ここから言えるのは、プロンプトに「自信がなければ逃げていい」と書くだけでは逃げ道は機能しないということです。モデルは自信があると判断すれば、逃げ道があっても断定します。逃げ道を実際に効かせたいなら、確信度スコアなど別のシグナルで閾値を切り、システム側で強制的に人手キューへ回す設計が要ります。この壊れ方は、以前 LLMの構造化出力はどこで壊れるか で見た「検証は通るのに中身が捏造される」現象と同じ根っこです。
緊急度は「高く見積もる」癖がある
緊急度の正解率が両条件ともカテゴリ・担当者より大きく低いのも、はっきり出た傾向です。誤りの中身を見ると、本来低い案件を実際より高く見積もるものがほとんどでした。たとえば「有給の残日数はどの画面で見られますか」を『低』ではなく『中』、「参考までに解約時の違約金だけ聞きたい」を『低』ではなく『中』といった具合です。逆に「高いのに低く見た」誤りは罠2件に限られました。
誤分類は隠さず全件を log に残しました。強制選択の誤り8件のうち6件が、この「緊急度の過大評価」です。カテゴリと担当が9割超なのに緊急度だけ崩れるのは、3段階の主観的な線引きに引っ張られやすいからだと考えられます。
コストと速さ
20件×2条件（40回の呼び出し）の合計コストは約6円、1件あたりのレイテンシは中央値で約2秒でした。本番運用（1問い合わせにつき1回の呼び出し）を想定すると、1000件あたり約152円の概算です（Haiku 4.5 の単価・入力$1／出力$5 per 100万トークンで算出）。人が1件30〜60秒かけて仕分けると1000件で8〜17時間かかる計算なので、一次仕分けをここに寄せる価値は数字にも出ています。
n8n での実装：Webhook と、キーの安全な持たせ方
n8n 側は、Webhook ノードで受信し、HTTP Request ノードで Claude API を叩き、Code ノードで JSON を取り出して、Switch ノードで緊急度ごとに分岐、という最小構成です。実際にインポートできるワークフロー JSON も作りました（実キーは含めていません）。実装で押さえるべき点は2つあります。
1つめは、APIキーをワークフローに直書きしないこと。 n8n では認証情報を Credential として別管理し、ノードからは参照するのが公式の作法です（Anthropic credentials — n8n 公式）。書き出した JSON でも、キー本体ではなく Credential の参照プレースホルダだけを持たせています。
"credentials": {
"httpHeaderAuth": {
"id": "REPLACE_WITH_N8N_CREDENTIAL_ID",
"name": "Anthropic API Key (stored in n8n Credential Store — x-api-key header)"
}
}
// 認証情報はハードコードしない。n8n の Credentials 画面で Header Auth を作り、
// Name=x-api-key / Value=環境変数 ANTHROPIC_API_KEY を登録して参照する。2つめは、Webhook を無防備にしないこと。 n8n の Webhook はワークフローを Active にすると本番URLが有効になりますが、認証を付けなければURLを知る者は誰でも叩けます。公式には Basic／Header／JWT 認証と、IP ホワイトリスト（許可外は403）が用意されています（Webhook ノード — n8n 公式）。問い合わせ本文には個人情報が混じるので、送信前に 個人情報をマスキングする層 を挟むとより安全です。
もうひとつ、JSON パースが失敗したときの受け皿も入れておきます。Code ノードでパースに失敗したら、自動的に「判定不能（要人手）」へ倒して人手キューへ送る——プロンプト任せにしない、システム側の逃げ道です。
try {
parsed = JSON.parse(text);
} catch (e) {
parsed = { category: '判定不能（要人手）', urgency: '不明',
assignee: '判定不能（要人手）', confidence: 0,
reason: 'JSONパース失敗のため人手確認へ' };
}落とし穴と、設計で残すべき人手
- 逃げ道はプロンプトだけに頼らない。 「自信がなければ判定不能を選べ」は今回0/5で機能しなかった。確信度で閾値を切り、システム側で人手へ回す。
- 緊急度は最終確認を人が持つ。 正解率50〜65%で、しかも高く見積もる癖がある。カテゴリと担当の振り分けは任せ、緊急度は人のチェックを挟む。
- 丁寧な文面ほど疑う。 感謝から入る解約や、初心者質問を装った障害は、モデルもトーンに引きずられる。解約・障害のキーワードは別ルールで拾う二重化が有効。
- 1モデル・20件の測定である。 数字はこの条件でのもので、全ケースを保証しない。導入前に自社の実データで測り直すのが前提。
まとめ：任せる所と、残す所を分ける
問い合わせの自動トリアージは、「カテゴリと担当の一次仕分け」までなら、安いモデルでも9割超・1000件152円・1件2秒で実用域に入ります。ここは自動化して人の開封作業を減らせます。一方で、緊急度の最終判断と、解約・障害を見抜く目は人に残すのが今回の実測から出た線引きです。「AIに全部任せる」ではなく、「仕分けはAI、判断は人、逃げ道はシステムで強制」の三段構えが現実解でした。
問い合わせ対応が属人化していて、誰がどれを見るかの割り振りだけでも自動化したい——そんな現場なら、この一次トリアージは小さく始められる入口になります。自社の問い合わせで同じ検証をして業務に組み込みたい場合は、下のフォームから相談してください。
