n8nとLangChainでAIワークフローを構築する方法
n8nとLangChainを組み合わせることで、多くのチームが最終的に直面する問題を解決できます。それは、「実データに接続し、実際のアクションをトリガーするAIエージェントが必要だが、PythonでLangChainを実装するとアプリケーションスタック全体を維持しなければならない」というジレンマです。n8nのネイティブLangChainノードを使えば、エージェント、チェーン、メモリ、ベクトルストアを視覚的なワークフローにドラッグ＆ドロップで配置し、SDKコードを書かずに400以上のインテグレーションと接続できます。
手に入るもの：n8nのLangChainノードライブラリ
n8nには、LangChainの概念を視覚的なビルディングブロックとして実装した70以上のAIノードが標準搭載されています。Pythonでlangchainをインポートしてモジュールを繋ぎ合わせる代わりに、キャンバス上でノードを接続します。内訳は以下の通りです。
| ノードカテゴリ | 機能 | 主要なノード |
|---|---|---|
| ルートノード | コアAIロジック（「頭脳」） | AIエージェント、基本LLMチェーン、Q&Aチェーン、要約チェーン |
| チャットモデル | LLM接続 | OpenAI、Anthropic Claude、Google Gemini、Ollama、Groq、Mistral、DeepSeek |
| メモリ | 会話の永続化 | シンプルメモリ、Redis、Postgres、MongoDB、Zep |
| ベクトルストア | ドキュメント保存＋検索 | Pinecone、Qdrant、Supabase、Chroma、Weaviate、PGVector、インメモリ |
| 埋め込み | テキストからベクトルへの変換 | OpenAI、Cohere、HuggingFace、Ollama、AWS Bedrock |
| ツール | エージェントのための外部機能 | 計算機、SerpAPI、Wikipedia、カスタムコード、MCPクライアント、ワークフローツール |
| 出力パーサー | 構造化されたレスポンスフォーマット | 自動修正、構造化、アイテムリスト |
| テキストスプリッター | ドキュメントのチャンク分割 | 文字ベース、再帰的文字ベース、トークンベース |
アーキテクチャは、n8nがクラスターノードと呼ぶ構造を採用しています。ルートノード（AIエージェントなど）が、その機能を拡張するサブノード（チャットモデル、メモリ、ツール）に接続されます。これはLangChainのモジュールシステムを視覚化したものと考えると分かりやすいでしょう。
n8nがLangChainの概念にどう対応するか
コードでLangChainを使ったことがあれば、n8nでの対応関係は単純明快です。
| LangChainの概念 | n8nでの同等物 | 使用場面 |
|---|---|---|
ChatOpenAI() | OpenAIチャットモデル（サブノード） | LLMが必要なあらゆるワークフロー |
ConversationBufferMemory() | シンプルメモリ / Redisメモリ | マルチターン会話 |
RetrievalQA.from_chain_type() | Q&Aチェーン + ベクトルストア検索器 | ドキュメントへの質問応答 |
ツール付きAgentExecutor | AIエージェントノード（Tools Agentタイプ） | 動的なツール選択 |
RecursiveCharacterTextSplitter() | 再帰的文字テキストスプリッター（サブノード） | RAG用ドキュメントのチャンク分割 |
FAISS.from_documents() | シンプルベクトルストア（ドキュメント挿入） | 埋め込みのローカル保存 |
決定的な違いは何でしょうか？ コードではこれらを繋ぐために50〜100行書く必要がありますが、n8nではキャンバス上で4〜6個のノードを接続し、ドロップダウンメニューで設定するだけで済みます。
ドキュメントQ&Aパイプライン（RAG）の構築
実際に何かを作ってみましょう。このワークフローはPDFドキュメントを取り込み、ベクトルデータベースに保存し、その内容に関する質問に答えます。これは古典的なRAG（検索拡張生成）パターンであり、ビジネスチームにとって最も有用なLangChainワークフローです。
ステップ1：データ取り込みワークフローの設定
ドキュメントを読み込むための新しいワークフローを作成します。新しいドキュメントを追加するたびにこれを実行します。
追加するノード:
- Manual Trigger: 取り込みを実行するためにクリック
- Google Driveノード（またはHTTP Request、Read Binary File）: ソースドキュメントを取得
- Simple Vector Store: 操作をInsert Documentsに設定
- OpenAI Embeddingsサブノード: ベクトルストアに接続し、テキストをベクトルに変換
- Default Data Loaderサブノード: ドキュメント内容をチャンクに解析
- Recursive Character Text Splitterサブノード: 内容を約500トークンのチャンクに分割（オーバーラップ50トークン）
ベクトルストアの設定詳細:
- 操作:
Insert Documents - メモリキー:
company-docsのような説明的な名前を付けます（後で参照する方法になります） - データローダーはサブノードとして接続され、PDF/テキストの解析を自動的に行います
テキストスプリッターの設定:
- チャンクサイズ: 500（トークン）
- チャンクオーバーラップ: 50（境界線でコンテキストが失われないようにするため）
- 分割方法: Recursive Character（Markdown、HTML、プレーンテキストを賢く処理）
ステップ2：Q&Aエージェントワークフローの構築
次に2つ目のワークフローを作成します。これがユーザーが操作する部分です。
追加するノード:
- Chat Trigger: 質問用のチャットインターフェースを提供
- AIエージェント（Tools Agentタイプ）: 何をするか決定する頭脳
- OpenAI Chat Modelサブノード: GPT-4oまたはGPT-4o-miniに接続
- Simple Memoryサブノード: 会話のコンテキストを記憶
- Vector Store Toolサブノード: エージェントにドキュメントへのアクセス権を与える
AIエージェントノードの設定:
- エージェントタイプ: Tools Agent（最も柔軟なオプション。いつ、どのようにツールを使うかを決定します）
- システムプロンプト:
あなたは当社のドキュメントに基づいて質問に答える役立つアシスタントです。答えを見つけたドキュメントを必ず引用してください。情報がドキュメントにない場合は、はっきりとその旨を伝えてください。
Vector Store Toolの設定:
- 名前:
search_documents - 説明:
関連情報を検索するために会社のナレッジベースを検索します。ユーザーが会社の方針、手順、またはドキュメントについて尋ねたときにこのツールを使用してください。 - ベクトルストア: 作成したSimple Vector Storeを選択
- 埋め込みモデル: 取り込み時に使用した同じOpenAI Embeddingsモデル
- Top K: 4（取得する関連チャンクの数）
この説明は思った以上に重要です。エージェントはこの説明を使って、ツールを呼び出すべきか、自身の知識から答えるべきかを判断します。具体的になりましょう。
ステップ3：テストと改善
下部パネルのChatをクリックして、n8n組み込みのチャットインターフェースを開きます。ドキュメントに関する質問をしてみてください。実行トレースを確認すると、n8nはどのノードが発火したか、エージェントの推論プロセス、およびどのドキュメントチャンクが取得されたかを正確に表示します。
この段階での一般的な問題:
- エージェントがツールを使わない: ツールの説明が曖昧すぎます。ツールに含まれる知識について具体的に記述してください。
- 無関係なチャンクを取得する: チャンクオーバーラップを増やすか、チャンクサイズを減らしてください。300トークン、オーバーラップ100を試してみてください。
- レスポンスが遅い: チャットモデルをGPT-4o-miniに変更してください。コストは1/10で、ほとんどのQ&Aタスクには十分な速度です。
ツール呼び出しエージェントの構築
上記のQ&Aパイプラインはドキュメント向けに優れています。しかし、ウェブ検索、計算実行、データベース查询、そしてドキュメントからの回答をすべてこなすエージェントはどうでしょうか？ そこで真価を発揮するのがTools Agentです。
ワークフロー設定
- Chat Trigger: ユーザー入力
- AIエージェント（Tools Agent）: 適切なツールへルーティング
- OpenAI Chat Model: 複雑な推論用のGPT-4o
- Simple Memory: 会話履歴
- 複数のツール接続:
- SerpAPIツール: ウェブ検索機能
- Calculatorツール: 数学演算
- Vector Storeツール: ドキュメントナレッジベース
- Custom Codeツール: 作成したJavaScript関数
- Workflowツール: 他のn8nワークフローをツールとしてトリガー
Workflowツールはn8nの秘密兵器です。任意のn8nワークフローをエージェントが呼び出せるツールとしてカプセル化できます。在庫をチェックするワークフローがありますか？ それをツールにします。Slackメッセージを送信するものは？ ツールにします。CRMを查询するものは？ ツールにします。ここでn8nの400以上のインテグレーションノードがAIエージェントから利用可能になります。
マルチツールエージェント用のシステムプロンプト
システムプロンプトには、エージェントの能力について指示する必要があります。
You are a research assistant with access to the following tools:
- search_documents: Search our internal knowledge base
- web_search: Search the internet for current information
- calculator: Perform mathematical calculations
- send_notification: Send a Slack message to the team
For factual questions about our company, always check search_documents first.
For current events or external data, use web_search.
Show your reasoning before giving a final answer.このプロンプトパターンは、エージェントがツール間でどのようにルーティングするかを直接制御します。曖昧なプロンプトは、まずドキュメントを確認すべき場面でウェブ検索を使ってしまうエージェントを生み出します。
適切なエージェントタイプの選択
n8nは6つのエージェントタイプを提供しています。それぞれを選ぶべき場面は以下の通りです。
| エージェントタイプ | 適している用途 | ツール対応？ | 備考 |
|---|---|---|---|
| Tools Agent | ほとんどのユースケース | はい | デフォルトの選択肢。柔軟で信頼性が高い |
| Conversational Agent | 単純なチャットボット | はい | 機能は少ないが軽量 |
| ReAct Agent | 複雑な推論チェーン | はい | 明示的な推論ステップを表示 |
| OpenAI Functions Agent | OpenAI固有の機能 | はい | OpenAIのfunction calling APIを使用 |
| Plan and Execute Agent | 複数ステップのタスク | はい | まず計画し、その後実行。複雑なワークフローに適す |
| SQL Agent | データベース查询 | 限定 | データベースに対してSQLを生成・実行 |
ほとんどのチームにとって、Tools Agentが正しい出発点です。マルチツールのルーティングをうまく処理し、任意のLLMプロバイダーで動作し、後から変更も可能です。これをLangGraphやCrewAIなどのフレームワークでコードからエージェントを構築することと比較すると、ここでの利点はデプロイのオーバーヘッドがゼロであること、つまりエージェントがn8nのインフラ内で動作することです。
永続化するメモリの追加
デフォルトでは、Simple Memoryサブノードは会話履歴をメモリ上に保持するため、ワークフローが再起動すると消えてしまいます。本番運用では、永続的なメモリが必要です。
選択肢:
| メモリタイプ | 永続性 | 設定の手間 | 適している用途 |
|---|---|---|---|
| Simple Memory | セッションのみ | なし | テスト、プロトタイピング |
| Redis Chat Memory | 永続的、高速 | 中程度（Redis必要） | 本番環境のチャットボット |
| Postgres Chat Memory | 永続的、查询可能 | 中程度（Postgres必要） | 会話を分析したい場合 |
| MongoDB Chat Memory | 永続的、柔軟 | 中程度（MongoDB必要） | ドキュメント指向のストレージ |
| Zep Memory | 永続的＋要約 | 中程度（Zep必要） | コンテキストウィンドウを超える長い会話 |
長い会話履歴を持つAnythingを構築している場合、Zepは特筆すべき価値があります。古いメッセージを自動的に要約するため、会話の50ターン目になってもエージェントがコンテキストウィンドウを使い果たすことを防ぎます。
永続的なメモリを追加するには、Simple MemoryサブノードをRedis/Postgres/Zepに置き換えるだけです。ワークフローの残りの部分は同一のままです。
異なるLLMプロバイダーへの接続
LLMを必要とするすべてのルートノードは、チャットモデルサブノードを受け入れます。プロバイダーの切り替えはノード1つ分の変更です。
| プロバイダー | ノード名 | 利用可能なモデル | 備考 |
|---|---|---|---|
| OpenAI | OpenAI Chat Model | GPT-4o, GPT-4o-mini, o1, o3-mini | n8nで最も広くテスト済み |
| Anthropic | Anthropic Chat Model | Claude 3.5 Sonnet, Claude 3 Opus | 分析と長いコンテキストに強力 |
| Google Gemini Chat Model | Gemini 1.5 Pro, Gemini Flash | 良い無料枠あり | |
| Ollama | Ollama Chat Model | Llama 3, Mistral, Phi-3 | 完全ローカル、APIコストなし |
| Groq | Groq Chat Model | Llama 3, Mixtral | 極めて高速な推論 |
| AWS Bedrock | AWS Bedrock Chat Model | Claude, Titan, Llama | エンタープライズ向けAWS統合 |
ローカル開発とテストには、Ollamaがゼロコストの選択肢です。マシン上でモデルを実行し、n8nをlocalhost:11434に接続します。本番環境では、タスクに応じてOpenAIまたはAnthropicを使用するチームが大多数です。
実世界のワークフローレシピ
30分以内に構築できる、本番環境-readyなパターンを3つ紹介します。
レシピ1: 自動サポートチケット分類
トリガー: 新しいメール到着（Gmail/Outlookノード） チェーン: 分類プロンプト付きの基本LLMチェーン 出力: カテゴリに基づいて異なるSlackチャンネルへルーティング
プロンプトが重労働を行います。このサポートメールを次のいずれか1つのカテゴリに分類してください: billing, technical, feature_request, other。カテゴリ名のみで返信してください。
レシピ2: 週間コンテンツダイジェスト
トリガー: スケジュール（毎週月曜日午前9時） エージェント: SerpAPI + Custom Codeツール付きのTools Agent メモリ: 不要（ワンショットタスク） 出力: Slack/Emailに送信される要約レポート
エージェントは業界ニュースを検索し、上位5記事の要約を作成し、ダイジェストをフォーマットします。Custom Codeツールは、プロンプトよりもJavaScriptで処理した方が簡単なフォーマットロジックを扱います。
レシピ3: ドキュメント根拠型Slackボット
トリガー: 特定チャンネル内のSlackメッセージ エージェント: Vector Storeツール付きのTools Agent メモリ: Redis Chat Memory（SlackスレッドIDでキー付け） 出力: Slackスレッドへの返信
これは前述のQ&Aパイプラインですが、チャットUIではなくSlackによってトリガーされます。スレッドベースのメモリキーにより、各Slack会話が独自のコンテキストを持ちます。
n8n alongside どのRAGツールを使用するかを検討しているチームにとって、ベクトルストアの選択はチャンキング戦略ほど重要ではありません。プロトタイピングにはSimple（インメモリ）ベクトルストアから始め、本番環境ではPineconeまたはQdrantに移行しましょう。
よくある間違いとその回避方法
数十のn8n AIワークフローを構築してきた経験から、人々が陥りがちな落とし穴を挙げます。
1. システムプロンプトを省略する。 AIエージェントノードはシステムプロンプトなしでも動作しますが、性能は劣ります。エージェントの役割、利用可能なツール、望ましい動作を常に定義してください。プロンプトに10分費やすことで、奇妙なレスポンスのデバッグに費やす時間を数時間節約できます。
2. 巨大な単一ワークフローを使用する。 取り込みと查询を別々のワークフローに分けましょう。取り込みワークフローは偶尔実行され（新しいドキュメント到着時）、查询ワークフローは常に実行されます。これらを混ぜると実行競合が発生します。
3. 間違ったチャンクサイズを選ぶ。 デフォルトのチャンキング（1000文字）は一般的なコンテンツに適しています。技術ドキュメントの場合は300〜500トークンに下げます。法的文書の場合は、オーバーラップを大きくして800〜1000トークンに増やします。普遍的に「正しい」チャンクサイズはないため、実際のドキュメントでテストしてください。
4. 実行ログを無視する。 n8nはすべてのワークフロー実行に対して完全な実行トレースを表示します。エージェントが間違った答えを出した場合、どのツールを呼び出したか（または呼び出さなかったか）、どのチャンクが取得されたか、どのような推論を示したかを確認してください。ログは問題がどこで発生したかを正確に教えてくれます。
5. 必要のない場面でGPT-4oにお金を払う。 分類、要約、単純なQ&Aの場合、GPT-4o-miniはコスト10%で性能90%を発揮します。複雑な多段階推論にはGPT-4oまたはClaudeを予約しましょう。
Techsyがn8n AI自動化に取り組む方法
私たちは、3人のスタートアップからエンタープライズチームまで、さまざまなクライアントのためにn8n AIワークフローを構築してきました。私たちのプロセスは以下の通りです。
- 意思決定フローのマッピング: n8nを開く前に、すべての意思決定ポイントとデータソースを図式化します
- Simple Vector Storeでのプロトタイピング: インメモリストレージでコアロジックを動作させます
- 早期の実データでのテスト: 合成テストデータはチャンキングや検索の問題を隠蔽します
- メモリと永続性の追加: コアのQ&Aまたはエージェントロジックが検証された後にのみ実施します
- 監視と反復: どのツール呼び出しが成功したか、どのチャンクが取得されたか、ユーザーがどこで不満を感じているかを追跡します
ビジネスワークフロー向けのAIエージェントを構築しており、アーキテクチャ設計の支援が必要な場合は、無料相談のお問い合わせください。
よくある質問
n8nのAIノードを使用するためにLangChainを知る必要がありますか？
いいえ。n8nはLangChainをドロップダウン設定付きの視覚的なノードに抽象化しています。LangChainの概念（エージェント、チェーン、メモリ、検索器）を理解することはより良い設計決定に役立ちますが、LangChain Codeノードの使用を選択しない限り、LangChainコードを書く必要はありません。
OpenAIの代わりにn8nでローカルLLMを使用できますか？
はい。Ollamaチャットモデルサブノードを、マシン上で実行されている任意のモデル（Llama 3、Mistral、Phi-3など）に接続できます。http://localhost:11434を指定すれば、完全にプライベートでゼロコストのAIワークフローが完成します。Groqも、独自のハードウェアを管理せずに高速推論を行うための別の選択肢です。
n8nにおけるチェーンとエージェントの違いは何ですか？
チェーンは固定された順序に従います。入力はステップA、次にB、次にCを通ります。エージェントは入力に基づいて、どのツールを呼び出すかを動的に決定します。予測可能なタスク（要約、分類）にはチェーンを使用してください。次に何をすべきかについて意思決定が必要なワークフローにはエージェントを使用してください。
Simple Vector Storeはどのくらいのドキュ数を扱えますか？
Simple（インメモリ）ベクトルストアは、数百のドキュメントでのプロトタイピングには問題なく機能します。数千のドキュメントを対象とした本番環境では、Pinecone、Qdrant、Supabase、またはChromaに切り替えてください。ワークフローは同じままで、ベクトルストアノードを入れ替えるだけです。
外部アプリからn8n AIワークフローをトリガーできますか？
はい。Webhook Triggerノードを使用して、AIワークフローをAPIエンドポイントとして公開します。HTTPリクエストを行えるあらゆるアプリが、エージェントにデータを送信し、レスポンスを受け取ることができます。これが、既存の製品にn8n AIワークフローを統合する方法です。
AIワークフローにn8nは無料ですか？
n8n Community Editionは完全にオープンソースで、セルフホストなら無料です。すべてのLangChainノードが含まれています。インフラを管理したくない場合、Cloudプランは月額24ドルから始まります。LLM APIコスト（OpenAI、Anthropicなど）は別であり、プロバイダーによって請求されます。
n8nはAIエージェントワークフローのエラーをどのように処理しますか？
n8nにはノードレベルの組み込みエラー処理があります。リトライロジック、フォールバックパス、エラーワークフローを設定できます。LLMタイムアウトやレート制限などのAI固有の問題については、チャットモデルサブノードに指数バックオフ付きのリトライを追加してください。実行ログは、失敗がどこで発生したかを正確に示します。
独自のAPIキーでn8nのAIワークフローを使用できますか？
はい。すべてのLLMノードでは、独自のAPIキーを使用した認証情報の作成が必要です。n8nは認証情報を暗号化して保存します。セルフホスティングの場合、キーがインフラ外に出ることはありません。
LangChain Codeノードは何のためですか？
LangChain Codeノードを使用すると、LangChainモジュールを直接使用するカスタムJavaScriptを記述できます。これは、n8nの視覚的なノードが_exact_なユースケースをカバーしていない場合の脱出ハッチです。たとえば、カスタム検索器、特定のプロンプトテンプレート、またはn8nがまだラップしていないLangChainモジュールが必要な場合などに使用します。
n8n AIワークフローをチームと共有するにはどうすればよいですか？
ワークフローをJSONとしてエクスポート（Ctrl+Shift+E）し、ファイルを共有します。誰でもそれを自分のn8nインスタンスにインポートできます。チームコラボレーションの場合、n8n Cloudにはバージョン履歴付きの共有ワークスペースが含まれています。バージョン管理のために、ワークフローJSONファイルをGitにコミットすることもできます。