n8n の LLM エージェントで本番環境に陥りやすい5つの問題と対策

n8n のワークフローで LLM ノードを利用する際、開発時には問題にならないケースでも本番環境では様々な失敗が顕在化します。本稿では代表的な5つの症状と、その再現手順、ノードレベルで取れる具体的な修正方法をまとめました。

1. LLM が JSON ではなく散文を返す

症状：テスト用プロンプトでは正常に動作するが、本番環境では予期しないトークンがスローされる。

理由：モデルが「はい、ここに JSON があります:」といった接頭辞を付けて出力する。

テスト：タイプミス、絵文字、極端に短い文字列など、乱雑な入力を20件投入する。

修正：ノードが対応していれば JSON 出力を要求し、プロンプトに明示的なスキーマを記載する。また、厳格なプロンプトで1回再試行するフォールバックブランチを追加する。

症状：実行は緑色で完了するが、下流データが空になる。

理由：多くの API がエラー本文（レート制限やクォータ）を含む HTTP 200 を返す。

テスト：429 や 500 をモックし、ワークフローの挙動を確認する。

修正：「エラーなし」の設定をオフにし、IF ノードでレスポンス本文をチェック、エラーブランチを通知へ接続する。

症状：同一リードに対して3通のメールが送信される。

理由：Webhook トリガーの再試行と最低1回の配信が原因。

テスト：同一ペイロードを3回 POST する。

修正：冪等キーとしてペイロードをハッシュし、既視の場合はスキップするロジックを導入する。

症状：1つの空白フィールドだけで実行全体がクラッシュする。

理由：従来は正常系のみテストされていた。

テスト：名前やメールアドレスなど最小限の入力で実行する。

修正：AI ノードの直前に IF ノードで入力を検証し、不良行は「レビューが必要」バケットへ振り分け、失敗させずに処理する。

症状：夜間にワークフローが突然停止し、午前2時にアラートが上がる。

テスト：特別な操作は不要。実際に起こるケースを想定する。

修正：失敗時に ping を送信し、API ノードでバックオフ付き再試行を行う n8n エラーワークフローを組む。

以上の5項目はいずれも「幸せな道」だけがデモされ、エッジケースでのみ顕在化する失敗です。実践的な出発点として、無料の AI フックジェネレーター（公式 n8n テンプレート）をインポートし、プロンプトとエラー処理の構成例をご参照ください。

公式 n8n テンプレート（ワンクリックインポート）：リンク

無料のワークフロー＋ソース（MIT）：リンク

有料ワークフローと組み合わせた無料ダウンロード：リンク

テストを省きたい場合は、n8n AI エージェントの固定価格プレデモストレステストを利用し、エクスポート結果から優先順位付けされた障害リストとパッチを取得できます。