AIにJSONで返してもらうことと、その値を業務に使ってよいことは別です。n8nではStructured Output Parserなどで形式を揃えた後に、許す値・数値の範囲・根拠を別の処理で確認します。
出力を、後続が必要とする項目だけへ絞る
問い合わせの分類なら、種別と確認が必要な理由を返す設計にします。AIに担当者の連絡先や送信先URLまで自由に作らせず、分類に対応する担当はworkflow側の設定から選びます。
{
"type": "object",
"properties": {
"category": { "type": "string", "enum": ["billing", "support", "review"] },
"reason": { "type": "string" }
},
"required": ["category", "reason"],
"additionalProperties": false
}これは説明用のSchemaです。「その他」は自動処理の担当へ流さず、reviewへ寄せる例になっています。
Schemaは、形の確認として使う
Structured Output Parserでは、出力に必要な形を指定できます。例のJSONから作る方法と、Schemaを設定する方法の違いは公式Structured Output Parserで確認してください。
形が合っていても、請求の問い合わせをsupportへ誤分類することはあります。番号の桁数が正しくても実在する注文とは限りません。型の検査と、元データや台帳への照合を別に設けます。
不正な形式を、更新処理へ渡さない
| AIの出力 | 扱い |
|---|---|
| JSONとして読めない | 外部操作をせず、元出力とエラーを確認 |
| 許していないcategory | 確認待ちへ。勝手に既定の担当へ変えない |
| 形式は合うが根拠がない | 原文と照合し、人が判断 |
| 確認済みの分類 | workflow側の固定された担当設定へ渡す |
AI Agentから直接最終結果を受ける構成が安定しない場合は、出力の整理を別の段階へ分けます。自動修復を加える場合も、同じ入力への再試行回数と上限費用を決めておきます。
正解が分かる少数の入力で、意味も確認する
請求、操作、不明の三種を用意し、入力と出力の対応を読みます。分類が曖昧な一件、空の本文、指示のような文章を含む一件も加えます。成功率を測っていない段階で、精度の数字を比較へ使わないようにします。
完成した出力をそのまま送信せず、問い合わせの振り分けへ渡す項目だけを決めてください。JSONを整える役割と、実行を許可する役割を分けると修正箇所を追えます。