n8nでOpenAI APIをつないで処理する方法

n8nでOpenAI APIを組み込むと、受信したtextを要約・分類・生成して次のSaaSへ渡す処理をワークフローの途中へ入れられます。

現在のn8n OpenAI ノード V2ではOpenAI Responses APIに対応するGenerate a Model Responseと、Chat Completions APIを使うGenerate a Chat Completionが分かれています。新しく組む場合は、目的とノードのoperationを確認して選びます。

先に結論：最小構成は5段階で十分

Trigger

→ 必要な入力だけ整形

→ OpenAI

→ 出力を検証

→ Slack / Gmail / DBなどへ渡す

最初から複数のAI処理を入れず、「何を入力し、何を返し、どの条件なら次へ進めるか」を1処理だけ固定します。

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

Contract	決める内容
Input	AIへ渡す項目
Task	要約・分類・生成など1つ
Output	後続ノードで使う形式
Guard	空・想定外・要確認の扱い
Action	検証後に実行する処理

最小構成を作る

まずAIへ渡す処理を1つに絞る

「AIを入れる」ではなく、問い合わせ分類、会議要約、返信下書き、商品情報の整形など、入力と期待出力を決めます。

OpenAI Credentialを作る

n8nのOpenAI credentialはAPI key認証に対応しています。OpenAIでsecret keyを作り、n8nのcredentialへ保存します。API keyをワークフローのplain text 項目へ直接書かないようにします。

Input dataを整える

前ノードから届くJSONのうち、AIに必要な項目だけを選びます。メール本文、フォーム回答、database recordなどをそのまま全部渡すのではなく、必要情報へ絞ります。

OpenAI nodeでText operationを選ぶ

OpenAI ノードのText resourceでは、Responses APIを使うGenerate a Model Responseや、Chat Completions APIを使うGenerate a Chat Completionなどを選べます。

既存ワークフローとの互換性がある場合を除き、operation名と使用APIを確認してから設計します。

本番につなぐ

Promptへ役割と出力条件を書く

何を判定するか、何を出力するか、禁止事項、必要なformatを明確にします。後続ノードで使う場合は、自由文だけでなく項目として扱いやすい出力を意識します。

AI outputをそのままActionへ渡さない

外部送信、database更新、契約判断など影響が大きい処理では、If / validation / human approvalなどを挟みます。AI レスポンスが空、想定外、曖昧だった場合のルートも決めます。

CostとErrorを運用対象にする

API処理では入力量、実行回数、モデル選択によってcostが変わります。retryを無制限にせず、rate limitやAPI エラー時の処理を分けます。

End-to-endでWorkflowを確認する

AI ノード単体で期待レスポンスが返るだけでなく、トリガー→入力整形→OpenAI→validation→Slack / Gmail / DBなど最終アクションまでテストします。

AIものさしの判断

n8nでOpenAI APIを使う価値は、ChatGPTのように会話することではなく、AI処理を既存業務の途中へ「1 step」として埋め込める点にあります。

トリガー→normalize→AI processing→validation→アクション→monitoringという流れにすると、AIを業務自動化へ組み込みやすくなります。

AIものさしでは、API レスポンスが返ったことではなく、AI 出力が後続処理で使える形になり、失敗・cost・誤出力を含めて運用できる状態をこのワークフローの完了条件にします。

入力から後続Actionまでを一つの契約にする

n8nへ届くJSONを、そのままOpenAIへ渡すのではなく、AIに必要な値だけを先に取り出します。問い合わせ分類なら、受付番号と本文だけを入力にし、氏名・住所・決済情報のような分類に不要な値は除外します。これは精度を保証する手法ではありませんが、余計なデータ送信と後続処理の誤参照を減らす設計になります。利用できるデータ範囲は、社内規程とOpenAI側で使用する契約・設定も確認してください。

たとえば入力が次の形なら、分類タスクに使うのはticket_idとmessageに限定できます。

{

  "ticket_id": "T-1042",

  "message": "請求書の宛名を変更したい",

  "customer_name": "例示 太郎",

  "billing_address": "（分類には不要）"

}

OpenAIへ渡す指示には、分類の定義と「判断できないとき」の逃げ道を含めます。返答を次のSaaSへ直結せず、受け取った値が許可した候補かをn8n内で検査してください。たとえば出力カテゴリを「請求」「契約」「技術」「要確認」に限定し、想定外文字列、空文字、JSONとして読めない応答は要確認ルートへ送ります。モデルにJSONを求めることと、下流が安全に処理できることは別です。

ノードをつなぐ前に決める入出力

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

項目	例	n8nで確認すること
Trigger	WebhookまたはSchedule Trigger	一回の実行で何件のitemが流れるか
Input	ticket_id、message	null・空文字・長文をどう扱うか
Task	4分類のいずれか	判定基準の重なりを減らす
Output	category、needs_review	ノードoperationごとの実際の出力パス
Guard	許可カテゴリだけ通す	不正・空・未確定を自動Actionから外す
Action	ラベル付与または担当者通知	送信・更新前に再確認が必要か

OpenAIノードは、n8nのバージョンにより利用できるoperationが異なります。公式Docsによると、OpenAI node V2はn8n 1.117.0以降で利用でき、Responses APIをサポートする一方、Assistants API operationは含みません。既存workflowを移行する場合は、表示されるノードversionとoperationを確認し、画面上の名前だけでAPI互換性を決めないでください。現行ノードにはGenerate a Model ResponseやGenerate a Chat Completionなどがあり、どれを使えるかはn8n versionとノード設定に依存します。

Credential・実行費用・失敗を分けて管理する

OpenAI credentialはn8nのCredentialとして保存し、prompt、固定値、HTTP bodyへAPI keyを直書きしません。n8n CloudではOpenAI nodeのcredential欄からGateway creditsを選べる環境も公式Docsに記載されています。自分のOpenAI API keyを使う方式とGateway creditsの利用条件・請求経路は同じとは限らないため、実際のアカウント画面で選択したcredentialと課金先を確かめてください。ここでは単価や無料枠を固定値で示しません。

試作では1件のテスト入力を使い、各ノード出力を確認します。本番前は、最小の利用量で回数と入力内容を記録し、件数が増えた場合にコストがどう増えるかを見積もります。APIのrate limit、認証失敗、タイムアウトは、単に同じ処理を無制限にretryすると費用増や重複Actionにつながります。再試行は一時障害だけに限定し、上限回数、待機、最終通知を決めてください。

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

状況	自動で続けるか	安全な分岐
必須入力なし	続けない	入力元へ不足を返すか、要確認queueへ
API認証・権限エラー	続けない	credentialと利用可能operationを確認
rate limit・一時timeout	条件付き	上限付きretry。下流Actionを重複させない
出力カテゴリが未知	続けない	人が確認してから分類表を更新
下流SaaSへの書き込み失敗	AIを再実行しない	保存済み結果を使って安全に再処理できるか確認

本番導入前に、OpenAIノード単体だけでなくTriggerから最終Actionまで一連で実行します。AI処理が同じ入力に対して常に同一の出力になるとは限らないため、AIの成功を業務処理の成功と同一視しません。出力を監査できる記録、担当者が介入する条件、最終的なSaaS更新の重複防止まで整って初めて、自動化の範囲を広げられます。

最初の実装で止める基準

次の項目が決められない状態では、API連携を本番の自動更新へつなげません。

• OpenAIへ送る項目と送らない項目

• タスクの定義と、要確認に回す条件

• 期待する出力の形と、許可する値

• n8n version、node version、選択operation

• credentialの保存先と実際の課金経路

• rate limit・timeout時のretry上限

• 出力不正時の人手確認先

• 同一eventの再処理による二重Actionを防ぐ方法

最初は分類結果を別SaaSへ自動反映せず、結果を記録して人が確認する構成でも構いません。誤判定がどの入力・カテゴリで起きるかを見て、許容できる範囲だけ自動化します。業務上の影響が小さく、修正や取り消しが容易な処理から自動化し、送信・契約・削除など戻しにくいActionは承認を残します。

更新確認日：2026-10-10

追加確認：n8n公式「OpenAI node」https://docs.n8n.io/integrations/builtin/app-nodes/n8n-nodes-langchain.openai（新しいタブで開く）

追加確認：n8n公式「OpenAI credentials」https://docs.n8n.io/integrations/builtin/credentials/openai（新しいタブで開く）