n8nの認証テストは成功するのに404：送信先APIを確認する

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への認証テストがあります。このテストは完全なチャット生成を実行しません。

三つの操作を分けて考える

モデル一覧を認証なしで公開する提供者なら、一覧取得の成功はキーの有効性についても弱い根拠です。すべての提供者がそうだとは考えず、生成失敗だけでキーが無効とも判断しないでください。提供者の認証要件と実際の応答を確認します。

失敗したノードを特定する

OpenAIアクションノードの公式文書には複数の生成操作があります。OpenAI Chat Modelは別のサブノードで、AI Agentに接続することが多く、独自のオプションを持ちます。一方の設定説明を他方へそのまま適用しないでください。

n8n 2.36.9のChat Model実装では、ノードのtypeVersion 1.3以降にResponsesオプションがあり、UI上の既定値をtrueと定義しています。ただし保存済みワークフローの明示的な設定と実行時の挙動も重要です。この説明は固定したソース版についてで、すべての現行環境を保証するものではありません。

一般的な文書や古いチュートリアルでは既定値が違う場合があります。対象ノードをエクスポートしてtypeとtypeVersionを記録し、ワークフローに実際に保存されたオプションを確認します。別の版のスクリーンショットで代用しないでください。

生成経路だけを試す最小ワークフロー

対象フローを複製し、コピーは無効のままにします。メール送信、データ書き込み、課金、公開を行うノードは切り離します。最初は Manual Trigger と OpenAI の生成アクション一つで十分です。エージェントのツールループ、メモリー、後段の解析から API 呼び出しを分離できます。ただし生成自体はクォータや料金を消費し得ます。

対象プロバイダーの OpenAI 資格情報を作成または選択し、公式の API ルートとキーを保存します。公式ルートが https://provider.example/v1 なら、その形が Base URL です。このドメインは説明用で、接続先ではありません。ルート欄に /chat/completions や /responses を貼り付けず、別のチュートリアルにあるからと /v1 を二重に加えないでください。

アクションノードでは、プロバイダーが対応するエンドポイントの操作を選び、その経路用の正確なモデル ID を指定します。表示用の名称は使いません。Chat Completions のみ対応するなら、インストール済みノードが提供する chat 生成操作を使います。入力は一つの「Reply with ready.」だけにし、最初はツール、画像、構造化出力設定を外します。

この隔離したノード列だけを実行します。成功条件は資格情報の緑表示ではなく、ノードが完了し、生成内容を確認できることです。時刻、経路、ステータス、応答構造を保存し、本番側の依存要素を一つずつ戻します。最初の呼び出しは成功し、ツール追加で失敗するなら、確認済み Base URL ではなく追加機能を調べます。

AI Agent に OpenAI Chat Model サブノードをつなぐフローでは、サブノードの保存済み typeVersion と Responses 設定を確認します。アクションノードの成功は比較材料ですが、エージェントの設定を変更したことにはなりません。変更後は実際の送信パスを確認してください。二つのノードは同一の要求を作るとは限りません。

二つの要求形式のフィールドを混ぜない

以下はエンドポイントの違いを説明する簡略 JSON です。MODEL_ID は公式 ID に置き換えます。n8n のフローのエクスポートでも、特定プロバイダーが対応する証明でもありません。

Chat Completions は messages 配列を使います。

{"model":"MODEL_ID","messages":[{"role":"user","content":"Reply with ready."}]}

Responses は input を使います。

{"model":"MODEL_ID","input":"Reply with ready."}

カスタムプロバイダーは片方、両方、または機能の一部だけに対応する場合があります。Responses の本文を chat URL に送っても chat 要求にはなりません。choices[0].message.content 用のパーサーも Responses の output-item 構造を自動では読めません。n8n 実行を調べる際は、プロバイダーの生応答とノードが正規化した結果を区別します。

ノード固有の処理を避けて診断するなら、独立した HTTP Request ノードに公式のメソッド、完全なエンドポイント URL、認証、JSON 本文を設定します。秘密情報は n8n の資格情報機能で管理します。無害な一回の要求を失敗ノードと比較しますが、それだけで本番フローを置き換えないでください。元ノードにはストリーミング、ツール呼び出しなど別の要件があるかもしれません。

失敗したリクエストを追う

1. n8nの版、ノードのtype、typeVersion、操作を記録します。
2. キーを公開せず、Base URLのルートと正確なモデルIDを確認します。
3. 機密情報を除いたログや提供者側の記録で、/responsesと/chat/completionsのどちらに送信されたか確認します。
4. そのモデルに対する提供者の対応経路と照合します。
5. Chat Completions対応が文書化されているなら、その操作を選ぶかChat Model設定を変更し、実際の送信経路を再確認します。

一つの設定をオフにしても必ず解決するとは限りません。ライブラリや他の機能設定が経路選択に影響する場合があります。合否はスイッチの見た目ではなく、実際のパスと応答で判断します。

URLを見るためだけに、副作用のある本番ワークフローを再実行しないでください。モデル呼び出しを無害な入力で分離し、メッセージ送信やレコード更新のツールは切り離します。応答を直接確認できる最小の再現例にします。

資格情報を再編集する前に送信 URL を読む

すべての版がこの URL を作るという主張ではなく、診断上のパターンです。プロバイダーのトレース、リバースプロキシのログ、許可されたアプリの記録は、ラッパーの一般的なエラーから URL を推測するより有用です。保存・共有前に認証ヘッダーを削除してください。

プロバイダーに要求が届いていないなら、n8n の実行環境からの DNS、TLS、プロキシ、到達性を調べます。手元のブラウザーで接続できても、コンテナーやホスト上の worker が同じ場所へ接続できる証明にはなりません。証明書確認を無効にするのを標準の修正にせず、実際の通信エラーを残します。

経路が動いたらデータの流れも試す

入力を一件から始め、次に「Return ALPHA」「Return BETA」のように明確に違う二件を使い、実際にどのプロンプトが送られたか確認します。サブノードの式解決は通常ノードと異なる場合があります。各 item が独立して渡ると思い込まず、Chat Model 資料を参照してください。要求は成功しても別の入力を処理する、という経路互換性とは別の失敗を見つけられます。

次に必要な機能だけを戻します。構造化抽出はフィールド、ツールは呼び出しと結果、streaming は最終出力の収集方法を確認します。普通のテキスト要求を基準として残せば、後の失敗を追加した機能に結び付けられます。

最後に資格情報の値を含まない設定記録と正常なコピーを保存します。n8n の版、node typeVersion、操作、API ルート、モデル ID、関連オプションを記載してください。更新時には全自動処理を有効にする前に、この小さな例を再実行します。緑のバッジや古い画面ではなく、動作による合格確認になります。

サポートに渡す最小の記録

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移行ガイド（英語）は提供者切り替え全体を扱います。どちらも現在使う正確なエンドポイントの検証に代わるものではありません。