n8nの認証テストは成功するのに404：送信先APIを確認する
n8nの認証テストと生成処理は別の経路を使う場合があります。Base URL、ノードの種類、Responses設定をバージョン別に確認します。
Ofox 
n8nのOpenAI認証テストが成功しても、ワークフローが使う生成エンドポイントの対応は証明できません。 認証テストがモデル一覧を調べる一方、生成は別の経路を使う場合があります。提供者が/modelsを受け付けても、選択された/responsesに対応しなければ、認証テストは成功して実行時に失敗することがあります。
本記事ではOpenAI認証情報、OpenAIアクションノード、OpenAI Chat Modelサブノードを区別します。全バージョンで既定値が同じとは仮定せず、特定バージョンのソースを根拠にします。既存の中国語記事には過去のローカル試験が記録されていますが、本記事ではその結果を新たな本番テストとして扱いません。
Base URLは認証情報で設定する
OpenAI認証情報にはBase URL欄があります。対応するノードを別のAPIルートに接続するための設定です。特定のチャット操作や応答操作の完全URLではなく、提供者が指定するルートを使います。
例えばルートの末尾が/v1であれば、生成処理がその後に操作別のパスを追加します。ルートを期待する欄に/chat/completionsまで含めると、ノードがさらにパスを追加して不正なURLになる場合があります。実際のエラーは提供者次第であり、404だけでは原因を特定できません。
固定版のn8n 2.36.9の認証情報ソースにはBase URL欄と/modelsへの認証テストがあります。このテストは完全なチャット生成を実行しません。
三つの操作を分けて考える
| 操作 | 成功から分かること | 証明できないこと |
|---|---|---|
| /modelsによる認証テスト | モデル一覧のリクエストが受理された | 同じモデルと認証情報で生成もできること |
| Chat Completions | そのチャット要求が受理された | Responsesも実装されていること |
| Responses | その応答要求が受理された | チャット対応モデルがすべて同じ経路を使えること |
モデル一覧を認証なしで公開する提供者なら、一覧取得の成功はキーの有効性についても弱い根拠です。すべての提供者がそうだとは考えず、生成失敗だけでキーが無効とも判断しないでください。提供者の認証要件と実際の応答を確認します。
失敗したノードを特定する
OpenAIアクションノードの公式文書には複数の生成操作があります。OpenAI Chat Modelは別のサブノードで、AI Agentに接続することが多く、独自のオプションを持ちます。一方の設定説明を他方へそのまま適用しないでください。
n8n 2.36.9のChat Model実装では、ノードのtypeVersion 1.3以降にResponsesオプションがあり、UI上の既定値をtrueと定義しています。ただし保存済みワークフローの明示的な設定と実行時の挙動も重要です。この説明は固定したソース版についてで、すべての現行環境を保証するものではありません。
一般的な文書や古いチュートリアルでは既定値が違う場合があります。対象ノードをエクスポートしてtypeとtypeVersionを記録し、ワークフローに実際に保存されたオプションを確認します。別の版のスクリーンショットで代用しないでください。
失敗したリクエストを追う
- n8nの版、ノードのtype、typeVersion、操作を記録します。
- キーを公開せず、Base URLのルートと正確なモデルIDを確認します。
- 機密情報を除いたログや提供者側の記録で、/responsesと/chat/completionsのどちらに送信されたか確認します。
- そのモデルに対する提供者の対応経路と照合します。
- Chat Completions対応が文書化されているなら、その操作を選ぶかChat Model設定を変更し、実際の送信経路を再確認します。
一つの設定をオフにしても必ず解決するとは限りません。ライブラリや他の機能設定が経路選択に影響する場合があります。合否はスイッチの見た目ではなく、実際のパスと応答で判断します。
URLを見るためだけに、副作用のある本番ワークフローを再実行しないでください。モデル呼び出しを無害な入力で分離し、メッセージ送信やレコード更新のツールは切り離します。応答を直接確認できる最小の再現例にします。
サポートに渡す最小の記録
n8n version:
node type and typeVersion:
selected operation / Responses option:
provider API root:
exact model ID:
observed HTTP method and path:
HTTP status and redacted error body:
request ID, if supplied:APIキー、Authorizationヘッダー、非公開ワークフロー全体を公開Issueへ貼らないでください。経路とエラーフィールドは残し、認証情報と機密プロンプトを除去します。
過去のIssue #21651にはn8n 1.118.2で、独自プロバイダーの認証テスト成功後に実行時404が出たという報告があります。この症状が実際に報告された根拠にはなりますが、同じ古い不具合が現在の版にも残る証拠ではありません。
最初の説明だけで調査を終えない
404はモデルIDの誤り、提供者固有の経路、余分なパス、リバースプロキシでも起こり得ます。/chat/completions自体が失敗する場合は応答を保存し、Responses互換性だけが原因と判断する前にこれらも確認します。
model-not-foundの調査ガイド（英語）はモデルへのアクセスと識別子を、API移行ガイド（英語）は提供者切り替え全体を扱います。どちらも現在使う正確なエンドポイントの検証に代わるものではありません。
よくある質問
- n8nで独自のOpenAI互換Base URLは使えますか？
- はい。OpenAI認証情報に設定欄があります。ただし各ノード操作が動くかは、提供者、モデル、対応エンドポイントによります。
- 緑色の認証テスト成功表示はResponses対応の確認になりますか？
- いいえ。ここで確認した固定版ソースではテスト先は/modelsです。生成の対応は別途確認してください。
- MODEL_NOT_FOUNDは必ずモデル名の誤りを意味しますか？
- いいえ。送信パスと提供者の応答も確認します。ラッパーのエラー分類だけでは、すべての経路エラーと実際のモデルID拒否を区別できません。
