n8nからvLLMなどのOpenAI互換エンドポイントを呼び出す

非公開モデルは、自動化から到達できて初めて役に立ちます。n8nで確認済みの汎用経路はHTTP Requestノードです。vLLMのOpenAI互換サーバーのほか、実際にPOST /v1/chat/completionsを公開して受け付ける別の環境も呼び出せます。

この記事は運用者向けのガイドです。HTTP呼び出しの接続方法、認証方法、実測したローカル推論時間を反映したタイムアウト予算の設定方法、信頼できないネットワークからモデルサービスを隔離する方法を説明します。

n8nが適切な自動化レイヤーかをまだ検討している場合は、n8n、Zapier、Makeの比較から始めてください。その配管の上にエージェント型ワークフローを構築する場合は、n8nで初めてのAIエージェントを構築するを参照してください。

認証なしで公開インターネットから到達できるOpenAI互換エンドポイントは、誰でも使える推論プロキシです。発見した人はGPU時間を消費できます。vLLMでは、--api-keyが保護しない推論ルートや運用ルートに攻撃者が到達する可能性もあります。プロンプト漏えいは、ログ記録とアクセス制御に関する別のリスクであり、チャットルートから自動的に生じる性質ではありません。非公開ネットワークにだけバインドし、ゲートウェイで認証を必須にしてください。「デモだけ」を理由にポート転送してはいけません。

ここでいう「OpenAI互換」の意味

n8nで必要な契約は限定的です。

• ベースURLは、ノードが期待する形式に応じてサーバーのルートまたは/v1を指します。
• チャット呼び出しは/v1/chat/completions、またはノードが追加する同等のパスへ送ります。
• 要求本文はチャット補完の形式とし、model、messages、必要に応じてtemperature、max_tokensなどを含めます。
• 応答は、ノードが解析できるメッセージ内容をchoicesとして返します。

OpenAIのすべての製品インターフェースと同じ機能は必要ありません。要求、認証、モデル識別子、応答形式をn8nからテスト済みのチャット補完ルートが必要です。

vLLMはこのOpenAI互換サーバーモードを文書化しており、ほかのランタイムも似た形式を掲げています。本番ワークフローへ接続する前に、_自分の_環境でルートとcurlのサンプルを確認してください。インターフェースの形式が共通でも、ルート、モデル識別子、認証、応答互換性は製品やバージョンによって変わり得ます。

確認済みのn8n経路：HTTP Request

現行のn8n一次ドキュメントからは、OpenAI認証情報またはOpenAI Chat ModelノードがカスタムベースURLをサポートするとは確認できません。特定のn8nバージョンやコミュニティーノードにそのような欄があっても、確認するまではバージョン固有の機能として扱ってください。文書化された汎用経路はHTTP Requestノードで、メソッド、URL、ヘッダー、本文、認証、ノードの再試行設定を明示的に制御できます。

シークレットをワークフローに直接書くのではなく、汎用のBearer認証情報またはヘッダー認証情報を使ってください。認証情報には、推論サービスかそのゲートウェイが実際に検証する値を入れる必要があります。LAN限定のエンドポイントに仮のキーを設定しても、認証にはなりません。

POST http://10.0.0.20:8000/v1/chat/completions
Content-Type: application/json
Authorization: Bearer <secret>

{
  "model": "installer-recommended-local-model",
  "messages": [
    { "role": "system", "content": "Classify the ticket. Reply with JSON only." },
    { "role": "user", "content": "{{ $json.body }}" }
  ],
  "temperature": 0
}

モデル文字列は、/v1/modelsが返す正確な識別子に置き換えてください。NVIDIA NemoClawのローカルvLLM経路を使う場合は、稼働中のサーバーから記録された識別子、または選択した管理対象プロファイルの識別子を使います。管理対象vLLMは対応ホストでの選択肢であり、すべてのNemoClaw環境に共通する機能ではありません。一般的なLinuxでは、試験的な選択肢またはプロバイダーを明示的に選ぶ必要があります。記憶を頼りにチェックポイント名を作らないでください。

ベンダー固有のAIノードがカスタムエンドポイントを文書化していない場合も、HTTP Requestが適切な迂回手段です。

実効性のある認証とネットワーク制御

ローカルであることは、認証が不要という意味ではありません。

vLLMの--api-keyは、HTTPサービス全体の境界防御ではありません。公式のセキュリティーページは、保護対象と保護対象外のエンドポイント群を記載し、公開が必要な場合にはネットワーク隔離とリバースプロキシを推奨しています（vLLMのセキュリティー指針）。推論ルートにAPIキーがあっても、すべてのルートが未認証トラフィックを拒否する証拠にはなりません。

**必須の基本構成：**vLLMはループバック、コンテナーまたはクラスターのネットワーク、あるいはプロキシかn8nワークロードだけを許可するファイアウォールポリシーで保護した非公開インターフェースにだけバインドします。複数のホストから接続する必要がある場合は、Caddy、nginx、Traefik、または同等の管理されたゲートウェイを前段に置きます。経路が信頼済みの暗号化オーバーレイでない場合はTLSを終端し、公開するすべてのルートを認証し、レートと要求サイズを制限して、必要なパスだけを許可します。n8nはプロキシと通信し、クライアントからvLLMへ直接到達させません。

vLLMの--api-keyは、対応する推論エンドポイント向けの追加制御として使い、プロキシやファイアウォールの代わりにはしないでください。すべての認証情報はn8nの認証情報ストアか承認済みのシークレットストアに保存し、Gitへエクスポートされる平文のワークフローフィールドには入れません。

避けるべきこと：

• 自宅やオフィスのWAN IPで「一時的に」0.0.0.0へバインドする。
• トンネルのURLをSlackで共有する。
• Authorizationを検証しないローカルサーバーの「パスワード」として個人用OpenAIキーを使い回す。サーバーが無視するなら、そのキーは見せかけにすぎません。

ローカルエンドポイントに送ったプロンプトもn8nホストの外へ出て、推論サーバー、プロキシ、n8nの実行履歴に記録される可能性があります。ローカルホスティングは第三者クラウドでの保持を減らしますが、ログ、画面キャプチャ、運用者のアクセスをなくすわけではありません。顧客テキストは、自社のポリシーと適用法に照らして、機密データまたは個人データを含む可能性があるものとして分類し、保持とアクセス制御を確認してください。

範囲を限定した認証情報、サービスアカウント、監査証跡を含む、より広い連携の衛生管理については、AIを安全に接続するのパターンを使ってください。

タイムアウトと遅い推論

ローカルモデルの遅延は、モデル、プロンプト長、ハードウェア、同時実行数、コールドスタート状態によって大きく変わります。n8nノードの実効タイムアウトも、ノードと導入済みバージョンによって異なります。HTTP Requestノードについて文書化されたタイムアウトは、応答ヘッダーまたは応答本文の先頭を待つ時間を対象とします。ストリーミングや長時間の生成がエンドツーエンドで制限される証拠ではありません。そのため、チュートリアルの既定値をそのまま使うと、正常なジョブが失敗したり、別のレイヤーに明確な上限がなくなったりします。

タイムアウトは意図的に設定します。

1. n8nホストからcurlを実行し、コールド呼び出しとウォーム呼び出しを測定する。
2. ノードの初期応答タイムアウトを実測p95より長くし、負荷の急増に対して根拠のある余裕を持たせる。
3. ワークフロー、プロキシ、クライアント、推論サーバーの上限を、生成全体の予算に合わせる。
4. 分類やルーティングには短いプロンプトと小さなmax_tokensを優先し、長い生成は非同期で継続できる下書きステップに限定する。

あるステップが日常的に数分を超えるなら、同期webhook応答ではなく、非同期継続を備えたキューに置く方が適している可能性があります。

ノートパソコンからだけでなく、_n8nプロセスのネットワーク名前空間_からスモークテストしてください。Dockerで動くn8nは、モデルのポートをそのネットワークへ公開しない限り、ホストのlocalhostには到達できません。Dockerサービス名、ホストゲートウェイIP、またはコンテナーからルーティング可能なLANアドレスを使います。

ベースURLの衛生チェックリスト

認証情報を本番利用可能と判断する前に、次を確認します。

エンドポイント停止時の障害処理は明示してください。バックオフ付きで再試行する、人のキューへ送る、または実行を明確に失敗させます。プライバシー方針が異なる公開APIへの切り替えが文書化され、承認された経路でない限り、黙ってフォールバックしてはいけません。

ゲートなしで公開しない

ルールは単純です。**vLLMを信頼できないネットワークへ直接公開してはいけません。**APIキーはHTTPサービス全体を保護しません。ネットワークを隔離し、認証とレート制限を備えたゲートウェイを通じて、必要なパスだけを公開してください。

許容できる構成：

• ループバックまたはDockerネットワークのみに限定し、n8nを同じホストかオーバーレイに置く。
• LANとファイアウォールの許可リストを使い、プロキシまたはn8nワークロードのIDやIPだけを許可する。拒否対象ホストからルールを検証する。
• VPNまたはTailscale／ZeroTierメッシュを使い、WANリスナーは設けない。
• 複数の信頼済みクライアントへ提供する必要がある場合は、強力な認証、TLS、レート制限を備えたリバースプロキシを使う。

許容できない構成：

• 認証のないWANバインド。
• 実データを使った「認証は後から追加する」デモ。
• ゲストWi-Fi上のすべてのノートパソコンで、同じ未認証エンドポイントを共有する。

ローカル推論、n8nオーケストレーション、エージェントステップを組み合わせた非公開スタックを構築する場合、モデルのベースURLを内部契約として扱ってください。Hermesなどのランタイムも同じ非公開サービスを参照できます。n8nからHermesを呼び出す場合、n8nが結果を必要とするなら認証済みAPIサーバーを選び、イベント受信と設定済みHermes配信先が必要ならHMAC webhookアダプターを選びます。この区別はn8n → Hermes：API呼び出しかイベントwebhookかで説明します。

最小構成の非公開サポート経路

性能値を作り上げずに実装できる流れの例です。

1. チケットのwebhookをn8nで受信する。
2. フィールドを検証し、機密情報を削除する。
3. HTTP Requestから非公開の/v1/chat/completionsエンドポイントを呼び出し、分類JSONを取得する。
4. Switchノードでラベルに応じてルーティングする。
5. 会社の境界外へ出る下書きは、人のゲートで待機させる（冪等性と人によるゲート）。

機能の多いエージェントを追加する前に、ローカルエンドポイントを採用する価値があるかを確かめるには、これで十分です。

編集日に確認すること

製品のUIや認証情報のフィールド名は変化します。このワークフローを出荷または更新する当日に、次を実施してください。

1. 推論サーバーのOpenAI互換ルートについて、最新のドキュメントを確認する。
2. HTTP Requestの認証情報とノード設定が、必要な認証、ヘッダー、生のJSON形式を引き続き送信することを確認する。
3. 非本番ペイロードでcurlとn8nのテスト実行を1回ずつ再実行する。
4. リスナーが引き続き非公開であることを確認する。ssまたはlsof、ファイアウォールルール、意図しないトンネルの有無を調べ、未認証の推論要求が失敗し、vLLMが文書化した保護対象外のエンドポイントへ外部境界越しに到達できないことを確認する。

ローカルのOpenAI互換エンドポイントを使えば、自動化グラフを書き換えずにn8nから非公開推論を利用できます。重要なのは巧妙なプロンプトではありません。推論をほかの内部APIと同じように扱うことです。公開する境界で認証し、性能を測定し、意図を持ってログを管理し、第三者から到達できないようにしてください。