n8nでAIエージェントを本番に出したあと、一番怖いのは「エラーで止まること」ではない。エラーにならずに、間違った答えを自信満々に返してくることだ。ツール呼び出しも成功し、レスポンスも整った日本語で返ってくる。ログを見ても異常はない。だが答えの中身は、存在しない数値や、聞かれてもいない固有名詞を含んでいる。
2026年10月22日、n8n公式ブログが「Hallucination Detection Methods for AI Agent Workflows」という記事を公開した。4つの幻覚タイプと5つの検出手法を整理した内容だが、ノード構成やしきい値の具体例までは書かれていない。本記事では、その内容をn8nの実際のノード仕様に照らして、設定値レベルまで翻訳・整理する。
なぜ幻覚は「普通の回答」に見えるのか
n8nのAI AgentノードはツールやメモリとLLMをつなぐ配線の役割しか持たない。ツール呼び出しが失敗すればエラーになるが、LLMが事実と異なる文章を生成すること自体はエラーとして扱われない。配線は正しく動いているのに、流れる中身だけが間違っている状態だ。
n8n公式ブログの指摘はここにある。幻覚は例外処理では捕まらない。回答の中身を評価する別レイヤーを、ワークフローの中に自分で組み込む必要がある。
4つのハルシネーションタイプ
対策を立てる前に、何を検出したいのかを分解する。n8n公式ブログは幻覚を4タイプに分類している。
検証可能な事実と矛盾する主張をする。存在しない統計・人物・出来事を創作するケース。最も実害が大きいタイプ。
与えられたコンテキストに裏付けがない回答をする。RAG構成で特に起きやすく、ナレッジベースを使うエージェントほど注意が必要。
与えられていない詳細で、もっともらしくギャップを埋める。質問の情報量が少ないほど出やすい。
自分が以前に述べた内容や、同じ回答の別の部分と矛盾する主張をする。マルチターンのエージェントで発生しやすい。
🐝 IroHive メモ 4タイプのうち、検出のコストが最も低いのは自己矛盾（同じ回答内を見るだけで検出できる）。最も高いのは事実的ハルシネーション（外部ソースとの照合が必要）。最初に手をつけるべきはコストと実害のバランスで決める。
5つの検出手法 — 仕組みと使い分け
n8n公式ブログは5つの検出手法を挙げている。それぞれをn8nのノードでどう組むかまで含めて整理する。
回答を主張（クレーム）単位に分解し、各主張が取得済みドキュメントに裏付けられているか照合する。RAG構成で最も効果が出る。DeepEvalなどのLLM評価ライブラリが自動化している。
同じ質問を複数回投げ、回答が収束するかを見る。収束しない設問は、モデルが知識の空白を埋めている可能性が高い。外部ソースが不要で導入コストが低い。
複数の応答を生成し、意味的に同じ答えをグループ化する。グループが割れるほどモデルの確信度が低いと判定する。②の発展形で、実装コストは高い。
クレームを信頼できる外部ソース（データベース・API・ドキュメント）に照らして検証する。数値や固有名詞など、照合対象が明確な主張に向く。
スコアに応じて「自動通過」「追加チェック」「人間レビュー」の3段階に振り分ける。①〜④で出したスコアを最終的にどう扱うかの受け皿になる手法。
n8nでの実装パターン：2層のワークフロー
n8n公式ブログの図では「AI Agentノード→検証ステップ→Error Triggerノード」という流れが示されている。ここで誤解しやすいのが、Evaluationノードの役割だ。実務で組む前に、この点を整理しておく必要がある。
🐝 Evaluationノードは本番の即時判定装置ではない n8nのEvaluation機能（Evaluation Trigger＋Evaluationノード）は、「デプロイ前のライト評価」と「デプロイ後のメトリクスベース評価」のために用意されたテスト用の仕組みだ。本番実行のログをデータセットに取り込んで育てることはできるが、実行自体はEvaluation Trigger起点のバッチ処理であり、本番を流れる1件ずつのリクエストをリアルタイムに判定する仕組みではない。毎リクエストの幻覚をその場で止めたいなら、IFノードとStop And Errorノードを組み合わせたゲートを別に用意する必要がある。
この前提に立つと、実装は役割が異なる2つのレイヤーに分かれる。
レイヤーA — 本番のリアルタイムゲート
毎リクエストに対して走る、通常のワークフローだ。
レイヤーB — エラーワークフロー（人間確認・通知）
レイヤーAでStop And Errorが発火したときだけ起動する、別のワークフローだ。
Evaluationノードが出番を持つのは、このどちらでもない第3の場面だ。レイヤーAで記録したスコアや、人間が修正した回答をデータセットに蓄積し、Evaluation Triggerで定期的に回帰テストを回す。「しきい値や評価プロンプトが劣化していないか」を事後に検証する役割になる。
🐝 IroHive メモ この2層構造が必要になるのは、n8n Agentsのような完成品のエージェント機能ほど、内部の判断経路が見えにくいからだ。障害時に「なぜその回答を返したか」を追う難しさは、「n8n Agentsで何が変わるか — 導入前に判断すべき3つの制約」で整理した監査可能性の制約と根が同じ問題になる。
設定手順
Step 1 — 検証ステップを置く（忠実性チェックの例）
AI Agentノードの直後に、Basic LLM Chainノード（または2つ目のAI Agentノード）を追加する。プロンプトは次のように、スコアと理由を必ずJSONで返すよう固定する。
以下の回答を、提供されたコンテキストと照合して評価してください。
コンテキスト：
{{ $json.context }}
回答：
{{ $json.output }}
回答を主張（claim）単位に分解し、各主張がコンテキストに
裏付けられているかを確認した上で、次のJSON形式のみで返してください。
{"score": 1-5の整数, "reason": "判定理由を1文で"}出力を安定させるため、Structured Output ParserサブノードをLLM Chainに接続し、{ "score": number, "reason": string } のスキーマを指定する。自由文で返ってくると、次段のIFノードで数値比較ができない。
Step 2 — Evaluationノード（Set Metrics）でスコアを記録する
検証ステップの直後にEvaluationノードを置き、OperationはSet Metricsを選ぶ。
| 項目 | 設定値 |
|---|---|
| Operation | Set Metrics |
| Name | faithfulness_score |
| Value | ={{ $json.output.score }}（数値であること。文字列だと記録に失敗する） |
ここで記録した値はEvaluationsタブに蓄積され、Evaluation Trigger経由のテスト実行を重ねるたびに傾向を追える。本番の個別リクエストの通過・拒否判定そのものは、次のIFノードが担う。
Step 3 — IFノードで閾値分岐する
5点満点のスコアを、3段階に振り分ける。
| スコア | 判定 | 次の処理 |
|---|---|---|
score >= 4 | ✅ 自動通過 | そのまま応答を返す |
score == 3 | ⚠️ 要注意フラグ | 「要確認」の注記を付けて返す（ブロックしない） |
score <= 2 | ❌ ブロック | Stop And Errorノードへ渡す |
しきい値を4/3/2のどこに引くかは、最初から正解が決まっているわけではない。後述の「精度を上げるTips」で、決め方の手順に触れる。
Step 4 — Stop And Errorノードでエラーワークフローに渡す
IFノードの「ブロック」ルートの先にStop And Errorノードを置く。Error TypeはError Messageを選び、どの判定で落ちたかを本文に含める。
Error Type: Error Message
Message: Hallucination check failed (score={{ $json.output.score }}, reason={{ $json.output.reason }})このノードはワークフローを意図的に失敗させる。失敗した瞬間、設定済みのエラーワークフローが起動する。
Step 5 — エラーワークフローを登録する
- Error Triggerノードを最初のノードとする新規ワークフローを作成する（例：「Hallucination Alert」）
- メインワークフロー側で Options → Settings → Error Workflow を開き、作成したワークフローを指定して保存する
- Error Triggerの出力には
lastNodeExecuted（どのノードで落ちたか）と、Stop And Errorで設定したメッセージが含まれる
Error Triggerの次にSlackノードを置き、OperationをSend and Wait for Responseに設定する。承認・却下の応答が届くまでワークフローはそこで一時停止し、応答後に処理が再開する。利用にはSlackアプリ側でInteractivityを有効化し、Signing Secretを設定しておく必要がある。Advanced InteractivityのUnauthorized Reply（承認者以外が操作したときの返信文）とAfter Decision（判定後にメッセージをどう書き換えるか）も、この時点で決めておく。
精度を上げるTips
よくある失敗と対処法
まとめ・チェックリスト
n8n公式ブログの図を実機に落とすと、「AI Agent→Eval→Error Trigger」という一直線の矢印ではなく、本番ゲートと回帰テストの2層構造になる。導入前に次の項目を確認してほしい。
- 4タイプのうち、どのハルシネーションが業務上最も実害が大きいかを先に決める
- 検証ステップ（忠実性/自己一貫性チェック）の追加コールが、1リクエストあたり何回増えるか見積もる
- IFノードのしきい値（score>=4など）を仮決めし、運用開始後に全件ログで検証する運用を組む
- Stop And ErrorとError Workflowの設定を、手動実行ではなく自動実行で動作確認する
- Slack「Send and Wait for Response」を使う場合、Interactivity・Signing Secretを事前に設定する
- 本番ログから蓄積したデータセットを、Evaluation Triggerで定期的に回帰テストする仕組みを別途用意する
✅ まとめ Evaluationノードは「本番の瞬時ブロッカー」ではなく「回帰テストの記録係」だ。即時の幻覚ブロックはIF＋Stop And Errorで組み、Evaluationノードはそのゲートが劣化していないかを後から検証する役割に回す。この2層を混同すると、本番で何も止まっていないのにEvaluationsタブだけ賑わう、という状態に陥る。
参考資料
- Hallucination Detection Methods for AI Agent Workflows（n8n公式ブログ） — 4タイプ・5手法の原典
- Evaluations overview（n8n公式ドキュメント） — ライト評価／メトリクスベース評価の違い
- Evaluationノード（n8n公式ドキュメント） — Set Outputs / Set Metrics / Check If Evaluating の仕様
- Error Triggerノード（n8n公式ドキュメント）
- Stop And Errorノード（n8n公式ドキュメント）
📌 バージョン注記 本記事はn8n公式ブログ（2026年10月22日公開）と、同時期のn8n公式ドキュメントのノード仕様を基にしている。Evaluation機能・Human-in-the-loop機能はn8nの中でも更新が比較的早い領域であり、実装前に公式ドキュメントの最新版でノード名・設定項目を確認してほしい。