n8nでAIワークフローを作るときの基本構成

n8nでAI workflowを作るとき、最初からAI Agentへ全部任せる必要はありません。

基本は、

Trigger

→ 入力data整理

→ AI model / Agent

→ toolや外部data

→ validation

→ action / response

という流れです。

通常のautomationの中にAIを一つの判断・生成stepとして入れると、debugしやすくなります。

1. Triggerを決める

最初に「何をきっかけにAIを動かすか」を決めます。

chatbotならChat Trigger。

問い合わせ処理ならWebhookやGmail Trigger。

定期reportならSchedule Trigger。

AIより先にtriggerを決めると、input dataの形が決まりやすくなります。

2. 入力dataを整える

AI Agentへraw dataをそのまま大量に渡すより、必要な情報だけに絞ります。

Set / Edit Fields、Code、IF、Filterなど通常nodeを使い、

不要fieldを削る

文字列を整形する

対象dataだけ残す

metadataを付ける

といったpreprocessingを行います。

AIに考えさせる必要のない処理はdeterministic nodeへ任せる方がcostと再現性を管理しやすくなります。

3. AI Agentか単純なmodel callかを決める

文章要約、classification、文章生成だけなら、複雑なAgentを使わなくても対応できます。

一方、

複数toolから必要なものを選ぶ

途中結果を見て次のactionを判断する

複数stepでgoalを達成する

場合はAI Agentが向いています。

n8n公式Docsでも、LLMはtext生成、Agentはgoal-orientedなtask completionと役割を分けています。

4. Chat Modelを接続する

AI Agentにはchat modelを接続します。

OpenAI、Anthropic、Google Gemini、Azure、Groq、Ollamaなど複数のproviderを選べます。

providerごとにAPI credentialを登録し、modelを選択します。

n8n subscriptionとmodel API料金は別なので、productionではtoken / request costも確認する必要があります。

5. 必要なtoolだけ渡す

Agentの強みはtoolを使えることです。

たとえば、

Google Calendar

Gmail

HTTP API

database

calculator

別n8n workflow

MCP tool

などをAgentから呼ばせられます。

ただしtoolを増やすほど、Agentが選択を誤る可能性やpermission範囲も増えます。

最初は一つか二つのtoolだけ接続し、動作を確認してから増やす方が安全です。

6. memoryは必要な場合だけ使う

chatbotでは会話contextを保持するためmemoryが役立ちます。

一方、単発のclassificationやbatch処理ではmemoryが不要な場合もあります。

毎回同じinputだけで判断してほしいworkflowに不要なmemoryを付けると、過去contextが結果へ影響する可能性があります。

「会話を覚える必要があるか」で判断します。

7. RAGが必要ならretrievalを追加する

社内documentやproduct manualを元に回答させたい場合は、vector databaseやretrieverを使ったRAGを組み込めます。

AIにすべてを覚えさせるのではなく、質問に関連するdocumentだけ取得し、model contextへ渡します。

ただしRAGでは、

document更新

chunk設計

metadata

permission

citation

の管理が必要です。

単純な少量dataならGoogle Sheetsやdatabaseをtoolとして直接参照する方が簡単な場合もあります。

8. AIの出力をそのまま実行しない

特にwrite actionでは、Agentのoutputをそのまま外部serviceへ流さない方が安全です。

たとえば、

email送信

database update

payment

delete

production deploy

の前に、IFやvalidation、human approvalを入れます。

AIが判断する部分と、必ず守るbusiness ruleを分離することが重要です。

9. human-in-the-loopを入れる

n8nではtool callへhuman approvalを入れる考え方も公式Docsで扱われています。

高risk actionでは、

AIが案を作る

→ 人間がapprove

→ action実行

という構成にします。

完全自動化より一step増えますが、誤送信や誤更新のriskを下げられます。

10. fallbackを作る

AIが回答できない、tool callに失敗する、API rate limitに当たる場合があります。

そのため、

retry

error workflow

human fallback

timeout

default response

を用意します。

AI workflowほど「正常時」だけではなく「判断できなかったとき」の設計が重要です。

まずは使ってみる

記事の文脈に合うToolへ進めます。報酬の有無で見た目は変えていません。

• 

  n8n

  公式サイトを見るTool詳細を見る

11. loggingとevaluationを残す

productionでは、

input

model

output

tool call

error

latency

を確認できるようにします。

n8nにはexecution historyがあり、AI系にはevaluation機能も用意されています。

promptを変えた結果が良くなったかを感覚だけで判断せず、代表caseで比較できる状態を作る方が改善しやすくなります。

最小構成はChat Trigger + AI Agent + Model

公式tutorialの基本形は、

Chat Trigger

→ AI Agent

→ Chat Model

です。

ここへ必要に応じてmemoryやtoolを追加します。

最初からvector database、複数Agent、MCPまで入れず、一つのconversationが最後まで通ることを確認してから拡張する方が理解しやすいです。

最初に動かすworkflowの完成形を定義する

「問い合わせをAIに処理させる」だけでは、入力と出力が曖昧なままnodeが増えます。最初の試作では、AIに渡す範囲と、回答を人が確認する境界を先に決めます。

表は横にスクロールできます

項目	最小の定義例
Trigger	問い合わせフォームから新規受付
Input	ticket_id、本文、受付日時、担当queue
AIの仕事	種別と緊急度の候補を返す
固定rule	ticket_id、必須欄、担当queueの許可値を確認
Output	category、urgency、summary、reason、needs_review
最終action	担当者が確認して分類を確定

たとえば「請求書が二重に届いた」という文なら、出力はbillingという分類だけでなく、その根拠となる本文の一節と、判定できない場合のreviewフラグを含めます。個人情報やカード番号は本文から除いてからmodelへ渡し、AIに返金や請求変更を実行させないのが初回の境界です。

ノードをつなぐ前にdata contractを決める

入力は外部フォームのJSONそのままではなく、workflow内のschemaへ整えます。ticket_idは文字列、messageは最大文字数を決めた文字列、received_atはISO 8601、sourceは許可リストの値にします。項目の欠落、型違い、空本文はAIへ送らず、validation error経路へ流します。

AI nodeには期待するJSON形式と禁止事項を渡しますが、形式指定だけで正しさは保証されません。後段のIFまたはCode nodeで、categoryが許可値か、urgencyが所定範囲か、reasonが空でないかを検査します。失敗時は再試行を無制限にせず、担当者のreview queueへ送ります。自由文を正規表現で分解する構成は、回答の言い回しが変わると壊れやすいため避けます。

問い合わせ分類の試験表

実データを使わず、個人情報を含まない架空入力を作ります。正常ケースだけでなく、迷うケースと壊れた入力を混ぜます。

表は横にスクロールできます

ケース	入力	期待する確認
1	ログインできない	access候補。理由を短く返す
2	今月の請求が二重	billing候補。金額変更は実行しない
3	解約したい、返金して	billing候補でも返金actionへ進まない
4	空本文	modelへ送らずvalidation error
5	顧客IDが欠落	担当者へ回し、外部更新しない
6	2分類に当てはまる	無理に確定せずreviewへ送る

期待値との一致だけでなく、別分類へ誤って進んだときに何が起きるかも記録します。特に、誤分類してもメール送信や顧客record更新が起きないことを、後続actionを無効にしたtest workflowで確かめます。

失敗時に止める場所

• Triggerが重複実行されたらticket_idで検知し、二重登録を防ぐ。

• model timeoutなら回数を限定して再試行し、失敗記録をerror workflowへ渡す。

• JSONが壊れていたら値を推定せずreview queueへ送る。

• credential権限errorならworkflowを停止し、権限を広げて通すのではなく担当者へ通知する。

• downstream APIが失敗したら、同じ書込みを再実行して二重処理にならないか確認する。

導入前の合格条件

試作の入力例、出力schema、正常・異常caseの結果、実行costと時間、失敗時の担当者、手動処理へ戻す手順を一枚に残します。n8n subscriptionのexecution枠とmodel providerのAPI料は別に見積もります。retryや分岐後の実行も数え、上限通知と停止方法を決めてから定期triggerを有効にします。

AIものさしの判断

n8nのAI workflowで重要なのは、「どのmodelが最強か」よりAIと通常automationの境界です。

format変換や固定ruleは通常node。

曖昧なclassification、文章理解、tool選択はAI。

高risk actionはhuman approval。

この役割分担を明確にすると、cost、debug、securityを管理しやすくなります。

AI Agentは便利ですが、workflow全体をblack boxにしないことが重要です。