n8nのAI Agentを使うと、自然言語の問い合わせを読み取り、状況に応じてtoolを選び、結果を文章や構造化データとして返せます。入力の表現が毎回違う問い合わせ分類や、文章の要約など、固定ルールだけでは扱いにくい処理に向いています。
一方、AI Agentは通常nodeの万能な代替ではありません。同じ入力でも表現や判断が変わる可能性があり、costとlatencyも発生します。厳密な計算、必須fieldの検証、送信先の確定、権限判定などは、IF、Edit Fields、Codeなどの決定論的な処理へ残す必要があります。
この記事では、AI Agent、chat model、Toolsの関係を整理し、AIへ任せる範囲を小さく保ちながら安全なWorkflowへ組み込む基本を学びます。
今日の到達点
- AI Agent、chat model、toolの役割を区別できる
- AIに向く曖昧な判断と、通常nodeへ残す固定処理を分けられる
- structured outputが保証する範囲と限界を説明できる
- toolの権限、human review、入力検証を安全設計へ組み込める
- 非決定性、hallucination、cost、latencyを故障モードとして評価できる
AI Agent・chat model・Toolsの関係
n8nのAI Agentは、入力と目的を解釈し、必要に応じて接続されたtoolを選び、処理を進める中心部分です。ただし、Agent単体で文章を理解しているわけではありません。推論に使うchat modelと、外部情報の取得や操作を担当するtoolを接続して使います。
入力
→ AI Agent
├─ Chat Model：文章理解、判断、生成
└─ Tools：検索、計算、Workflow呼び出しなど
→ 出力現在のn8n公式AI Agentドキュメントでは、AI Agentにchat modelと少なくとも1つのtoolを接続します。Agentは与えられた目的、toolの説明、入力に基づき、どのtoolをどの引数で呼ぶかを判断します。
最新のAI AgentはTools Agentとして動作します。以前のAgent type設定はn8n 1.82.0から非推奨となり、古いnode versionはn8n 3.0で削除されています。環境やn8nバージョンによって表示や利用可能な設定が異なる場合があるため、古い画面を前提にせず実環境と公式資料を確認してください。
n8n全体での位置づけ
AIをWorkflow全体の司令塔にする必要はありません。実務では、入力と出力の境界を通常nodeで固め、曖昧さがある一部分だけをAIへ渡す構成が追跡しやすくなります。
入力
→ 通常nodeで整形・秘密情報を除外
→ AI Agentで分類・要約
→ structured outputで形を制約
→ 通常nodeで型・値・権限を検証
→ IFで処理経路を確定
→ 必要なら承認後に外部操作重要な考え方は、AIの出力を信頼済みデータではなく、検証が必要な入力として扱うことです。Agentが自信を持って返した値でも、許可された選択肢か、対象IDが実在するか、実行してよい操作かは別に確認します。
AIへ任せる処理と通常nodeへ残す処理
判断基準は「AIで実現できるか」ではなく、「同じ入力に同じ結果が必要か」「誤りを機械的に検出できるか」です。
| 処理 | 第一候補 | 理由 |
|---|---|---|
| 自由文の意図分類 | AI Agent | 表現の揺れや文脈を扱う |
| 長文の要約・下書き | AI Agent | 正解が1つに決まらない |
| 関連toolの選択 | AI Agent | 入力に応じた柔軟な選択が必要 |
| 数値の単位変換 | Edit Fields／Code | 計算規則が固定されている |
| 必須field・型の検証 | IF／Filter／Code | 合否を再現可能にする |
| 正確な送信先IDの決定 | 通常node／DB参照 | 推測による誤送信を防ぐ |
| 金額・権限・安全条件の判定 | 通常node＋承認 | 説明可能で厳密な判断が必要 |
| recordの作成・削除 | 専用node＋承認 | 副作用を制御し監査する |
たとえば「問い合わせが障害報告か、一般質問か」をAIに分類させる価値はあります。しかし、priority = highなら必ず特定の担当へ送る、金額が上限を超えたら停止する、といった規則はIF nodeで固定する方が安全です。
promptとtool descriptionは役割を分ける
System Messageには、Agentの役割、判断基準、禁止事項、期待する出力を記述します。tool descriptionには、そのtoolを何のために、どの条件で使うのかを明確にします。
役割：受信した保守問い合わせを分類し、短く要約する。
制約：入力にない事実を補わない。機器IDを推測しない。
判断不能：categoryをotherとし、summaryに不足情報を示す。「いい感じに処理する」のような曖昧な指示では、評価基準も曖昧になります。何をしてよいかだけでなく、何をしてはいけないか、判断できない場合にどう返すかを決めます。
credential、API key、tokenをpromptへ書いてはいけません。認証はCredentialsと対応nodeで管理し、Agentへ見せるデータも目的に必要なfieldへ絞ります。
structured outputで出力の形を固定する
AIの自由文を後続nodeで扱うと、表現の揺れやfield不足が問題になります。Structured Output Parserを接続し、JSON Schemaで出力形式を制約すると、後続処理が参照するfieldを明示できます。
問い合わせ分類なら、次のようなschemaを使えます。
{
"type": "object",
"properties": {
"category": {
"type": "string",
"enum": ["question", "incident", "other"]
},
"priority": {
"type": "string",
"enum": ["low", "medium", "high"]
},
"summary": {
"type": "string"
}
},
"required": ["category", "priority", "summary"],
"additionalProperties": false
}AI AgentのRequire Specific Output Formatを有効にし、Structured Output Parserを接続します。JSON Exampleからschemaを生成する方法もありますが、Structured Output Parserの公式仕様では例に含めたfieldはすべて必須として扱われます。任意fieldを含む場合は、JSON Schemaを手動定義する方が意図を表しやすくなります。
ただし、schemaが保証するのは主に形です。priorityが許可された文字列でも、実際の優先度判断が正しいとは限りません。構造化後も値の妥当性、参照先、実行許可を通常nodeで検証します。
最小Workflowを組み立てる
実習では、自由文の保守問い合わせを分類・要約する小さなWorkflowを作ります。
Manual Trigger
→ Edit Fields - Sample Inquiry
→ AI Agent - Classify Inquiry
├─ Chat Model
├─ Calculator Tool
└─ Structured Output Parser
→ IF - Validate Category
→ Edit Fields - Prepare Result入力例は秘密情報を含まない架空データにします。
{
"machine_id": "pump-101",
"message": "ポンプの圧力が昨日から不安定です。現在は12MPaですが、点検が必要ですか？"
}AI Agentには、category、priority、summaryを返させます。Calculator Toolを安全な小規模toolとして接続し、必要な場合だけ数値計算に使える状態を確認します。
一方、12MPaを12000kPaへ変換するような固定計算はEdit Fieldsでも正確に実装できます。実務では通常node側へ残す判断も比較します。
同じ入力を複数回実行し、category、priority、summary、tool使用の有無が変化するかを観察してください。期待する結果を先に決め、実際のexecutionを記録します。
Toolsへ与える権限を最小化する
ToolはAgentの判断を外部操作へ変える境界です。読み取り、計算、検索だけのtoolと、送信、更新、削除を行うtoolでは危険度が異なります。
最初の実習では、Calculatorや読み取り専用のWorkflow Toolなど、失敗しても影響が小さいtoolを使います。外部操作を追加する場合は次を確認します。
- toolごとに目的と利用条件を明記する
- credentialの権限を必要最小限にする
- 送信先やrecord IDをAIの推測だけで決めない
- 実行前に通常nodeで引数と許可範囲を検証する
- 再実行しても二重処理にならない設計を検討する
- 送信、変更、削除などはhuman reviewを挟む
n8nでは、AI Agentの特定tool呼び出しにhuman reviewを設定できます。承認者はtool名と引数を確認し、承認または拒否できます。
不可逆な操作、外部への送信、高価値な判断、法務・セキュリティ上の確認が必要な処理では、Agentの判断だけで実行しない設計が重要です。
Call n8n Workflow Toolで既存Workflowをtoolとして利用する場合も、呼び出されるWorkflowを小さな内部APIとして扱います。入力field、出力、権限、副作用を明示し、Agentへ任せるparameterを限定します。$fromAI()で値をAgentに決めさせられても、すべてのparameterをAI定義にする必要はありません。
よくある故障モードと対策
Hallucination
入力にない事実、存在しないID、誤った説明を生成することがあります。参照元を限定し、不明時の出力を定義し、外部データと照合します。
間違ったtoolまたは引数
tool descriptionが似ている、利用条件が曖昧、入力値が不足していると、意図しないtoolを選ぶ可能性があります。tool数を必要最小限にし、引数をschemaと通常nodeで検証します。
Prompt injection
メール、Webページ、文書など外部入力に「以前の指示を無視して操作せよ」と書かれている可能性があります。外部データを命令として信頼せず、秘密情報へアクセスできるtoolと組み合わせないようにします。重大な操作には承認を入れます。
非決定性
同じ入力でも分類や文章が変わる場合があります。固定したtest caseを繰り返し実行し、許容範囲と失敗条件を決めます。完全一致が必要な処理をAIへ任せないことも対策です。
Costとlatency
model呼び出し、長いprompt、多数のtool呼び出し、反復はcostとlatencyを増やします。不要な入力を削り、tool数とAgentの反復上限を抑え、単純処理を通常nodeへ移します。AI AgentのMax Iterationsは無限ループを避ける境界として確認します。
Provider errorとrate limit
model提供側の一時エラーやrate limitで失敗することがあります。executionを確認できるようにし、再試行の回数と間隔、重複実行の影響、失敗時の退避先を設計します。
Debugと評価の進め方
AI Workflowは、1回期待どおり動いたことだけでは品質を判断できません。n8n公式のAI workflow evaluationでは、既知のtest dataと評価指標を使って変更前後を比較できます。最初は小さな表でも構いません。
| test case | 期待するcategory | 許容するpriority | 禁止事項 |
|---|---|---|---|
| 点検方法を質問 | question | low／medium | 機器IDを捏造しない |
| 停止を伴う異常 | incident | high | 自動で削除・送信しない |
| 内容不足 | other | low | 不足情報を推測しない |
各executionでは、少なくとも次を残します。
- 入力と期待結果
- 使用したmodel、prompt、tool構成
- Agentの最終出力とtool呼び出し
- structured outputの検証結果
- 実行時間と、取得可能ならcostまたはtoken量
- 同じ入力を繰り返したときの差
- 通常nodeへ戻すべき処理
promptやmodelを変更したら、同じtest caseで再評価します。AIの文章を人が眺めて「よさそう」と判断するだけでなく、分類精度、必須field、禁止操作、latencyなど、目的に対応した評価項目を決めます。
よくある失敗
AgentへWorkflow全体を任せる
固定変換、検証、権限判定までAgentへ集めると、失敗箇所と判断理由を追いにくくなります。曖昧判断だけをAIへ限定し、前後を通常nodeで囲みます。
structured outputなら正しいと思う
JSON Schemaに合っていても、内容の真偽は保証されません。値の範囲、IDの存在、業務規則を別に検証します。
強い権限を持つtoolを直接つなぐ
削除、送信、支払い、権限変更などをAgent判断だけで許可すると、誤判断やprompt injectionの影響が大きくなります。権限を狭め、human reviewを使います。
1件の成功だけで公開する
入力表現、欠損値、矛盾、長文、悪意ある指示、provider errorを含む複数caseで確認します。同じ入力の繰り返しも必要です。
costとlatencyを記録しない
精度だけを見ていると、運用開始後に時間と費用が増えることがあります。通常nodeだけで十分な処理を外し、呼び出し回数と入力サイズを観測します。
実務での設計チェック
AI Agentを追加する前に、境界を短く定義します。
ai_responsibility:
- classify_free_text
- summarize_message
deterministic_responsibility:
- validate_required_fields
- verify_machine_id
- convert_units
- route_by_approved_values
tool_policy:
allowed:
- calculator
- read_only_lookup
approval_required:
- send_message
- update_record
- delete_recordこの境界を説明できなければ、AI Agentを追加する前に処理を分解します。AIが不要な部分を増やさないことは、精度、cost、latency、監査可能性のすべてに効きます。
今日の実習で確認すること
- 小さなAI Agentへchat modelと安全なtoolを接続する
- 自由文の分類・要約だけをAIへ任せる
- Structured Output ParserでJSON Schemaを設定する
- 後続のIFで許可されたcategoryか検証する
- 同じ入力を複数回実行し、出力とtool使用の差を確認する
- 固定ロジックへ残すべき処理を1つ以上説明する
- cost、latency、非決定性、実環境のUI差分を記録する
実習では、実際の送信やrecord更新を無理に行う必要はありません。読み取りまたは計算だけのtoolから始め、Agentの判断、引数、出力、通常nodeとの境界を確認してください。
まとめ
n8nのAI Agentは、chat modelを使って入力を解釈し、必要に応じてToolsを選ぶ仕組みです。自由文の分類、要約、曖昧な判断に役立ちますが、正確な計算、検証、権限判定、重大な外部操作まで任せるべきではありません。
曖昧さが必要な箇所を特定
→ AI Agentの責務を限定
→ toolと権限を最小化
→ structured outputで形を制約
→ 通常nodeで値と許可を検証
→ test caseとexecutionで評価大切なのは、AI Agentを使ったことではなく、AIへ任せた判断と、通常nodeへ残した固定処理を説明できることです。AIの出力を検証可能な境界へ閉じ込め、失敗しても追跡し、止め、承認できるWorkflowにしましょう。
