n8n Queue modeでCredentials could not be decryptedが出たとき、暗号鍵を安全に照合する

n8n Queue modeで「Credentials could not be decrypted」が出る場合、外部APIのtokenを作り直す前に、credentialを暗号化した鍵と、実行するprocessが使う鍵の対応を調べます。外部サービスに拒否されたエラーと、保存済みcredentialを読み出せないエラーは別です。

この記事は、mainでは動くがworkerで失敗する、再配置後に復号できなくなった、といった状況で、既存データを保全しながら確認する手順です。鍵の変更・credential再作成・本番再実行は、診断結果と復旧方針を確認してから扱います。

エラーの発生地点と失敗するprocessを特定する

対象execution ID、時刻、node、main／workerのどちらで出たか、変更前に正常だった時点を記録します。別のworkerへ割り当てられたrunだけが失敗するなら、全体共通のAPI権限より、process間の構成差を先に確認する材料になります。

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

観察	最初に確認すること
mainでは動きworkerだけ復号失敗	鍵の適用対象と接続database
特定workerだけ失敗	そのworkerのsecret参照・起動構成
再配置・再起動後から失敗	永続化領域、secret注入、変更履歴
外部APIから401等が返る	復号後のcredential有効性・認証先

最後のケースまで、すべてを暗号鍵不一致と断定しないでください。error本文と失敗地点を見て、credentialの読出し前なのか、外部リクエスト後なのかを分けます。診断のために秘密値そのものを表示する必要はありません。

mainの既存鍵とworkerの適用を照合する

n8n公式のQueue mode資料は、databaseに保存されたcredentialをworkerが利用するため、mainの暗号鍵をすべてのworkerとwebhook processorへ共有する構成を説明しています。mainとworkerが同じdatabaseを見ていても、異なる鍵を使えば同じcredentialを復号できるとは限りません。n8n：Enable queue mode（新しいタブで開く）

独自鍵を指定する項目はN8N_ENCRYPTION_KEYです。公式資料は初回起動時の鍵生成と独自鍵の指定を案内していますが、既存credentialを使っている環境で新しい文字列を作れば直る、という意味ではありません。まず正常時に使っていた鍵と暗号化済みデータの組を保全します。n8n：Set a custom encryption key（新しいタブで開く）

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

対象	鍵の値を出さずに記録する情報
main	secret管理元・参照バージョン・設定方法
各worker	参照先・バージョン・設定の適用対象
webhook processor	同じ鍵を必要とする構成と適用
database	正常時の暗号化済みcredentialを含む対象
backup	databaseと鍵の保管・復旧責任者

同じsecret名が書かれていても、namespace、バージョン、注入対象、起動時の設定が違えば、稼働processの値が同じだという証明にはなりません。実値の一致確認が必要な場合は、権限のある担当者が管理された環境内で行い、値をチャットや公開ログへ転記しないでください。

配置を変えた前後の組合せを見る

containerを作り直した、永続volumeを変更した、secret管理へ移した、databaseをrestoreした、workerを追加した、という変更を時系列に並べます。鍵だけが古い／新しい状態なのか、databaseも別世代なのかを区別します。

例えば、以前のdatabaseと新規生成された鍵の組合せになっていれば、既存credentialの読出しを妨げる候補です。逆に別のdatabaseへ接続しているなら、鍵の一致だけでは目的のcredentialを使っていると確認できません。構成ファイルの予定値だけでなく、稼働中の対象と正常時の記録を照合します。

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

変更	確認する境界
worker追加	mainと同じ鍵・databaseへ接続する設定か
volume変更	以前の鍵を含む設定を保持したか
secret管理方式変更	参照名だけでなく対象processへ適用されたか
database restore	そのデータを復号する鍵を確保できるか

これは原因候補を整理する表です。実際の構成や復旧履歴を確認していない状態で、「鍵が消えた」「volumeが原因」とは報告しません。

先にしない方がよい操作を決める

エラーを消すため、鍵をランダムに更新したり、credentialレコードを削除したり、database内の暗号文を書き換えたりしないでください。正常時の組合せを特定するための情報が失われる場合があります。

外部サービスのAPI keyを更新することも、n8n側の復号不一致をそのまま直す操作ではありません。復号できる経路を確認してから、外部credential自体の期限・scope・接続先を別に調べます。secretのrotationやcredential再登録が必要なら、その対象、影響するworkflow、復旧手順を権限者が判断します。

古い鍵の所在が不明な場合は、保管責任者とバックアップを確認し、確認できたデータ・確認できないcredentialを分けます。新しい鍵を設定しただけで、既存データまで復旧したことにはしません。

検証は復号と業務処理を段階に分ける

許可された検証環境で、復号対象のcredential、実行するprocess、必要最小限の接続確認を決めます。mainだけで成功しても、worker群へ設定が行き渡ったかは別です。副作用のある送信や更新を、復号確認のために何度も繰り返さないでください。

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

段階	確認したい結果
構成照合	既存鍵・database・processの対応が分かる
credential読出し	対象processで復号エラーが出ない
認証先の確認	必要最小限の接続が目的の相手へ届く
workflowの検証	対象itemの欠落・重複・誤接続がない
復旧記録	変更前後と残る未確認を追える

完了時は、どのprocessでどのcredentialの確認ができたかを残し、「すべて復旧」と範囲を広げません。本文は公式資料に基づく診断手順で、実際の鍵照合、認証情報更新、database復元、workflow実行を行った報告ではありません。