n8nがGoogleスプレッドシートやSlackにつながるのは、Credential（認証情報）に鍵を預けているからです。ワークフローが止まる原因で多いのはノードの設定ではなく、この鍵が切れた、持ち主が辞めた、どのアカウントでつながっているか誰も知らない、のどれかです。ここでは「問い合わせ受付」ワークフローを例に、Credentialの種類の選び方、OAuth2のつなぎ方、共有と権限、暗号鍵の管理、担当者が替わるときの付け替えまでを通します。前提は、最初のワークフローを一度作ったことがあることです。版は2026年10月時点の安定版2.44.7で確かめています。
先に決めること
外のサービスに、誰のアカウントでつなぐか
Credentialは「n8nの中の誰か」ではなく「外のサービスの誰か」として動きます。担当者個人のGoogleアカウントでつなぐと、問い合わせの記録はその人の権限で書かれ、その人のアカウントが止まった日に記録も止まります。会社で使うなら、共用の業務アカウント（例: automation@example.co.jp）でつなぎます。SlackはBot User OAuth Token（アプリに付くトークン）を使えば、人に紐づきません。Slackの方式の違いは「n8nとSlack連携：通知・投稿・ボタンで承認・スラッシュコマンド」に書いています。
n8nの中で、誰の持ち物にするか
n8nのCredentialには持ち主がいます。個人の置き場「Personal」に作ると持ち主はその人で、ほかの人は原則使えません。Cloudの有料プランやセルフホストのBusiness以上なら、部署やチームの単位でプロジェクトを作り、ワークフローとCredentialをそこに置けます。こうしておくと担当替えは「プロジェクトのメンバーを入れ替える」だけで済みます。無料のCommunity editionでは共有ができません。プロジェクトが使えるかは公式の中でも書き方が割れているので、料金ページで確かめます。共有が無いときの回し方は後で書きます。
暗号鍵をどこに控えるか
セルフホストでは、Credentialは暗号鍵 N8N_ENCRYPTION_KEY で暗号化してデータベースに入っています。鍵をなくすとバックアップから戻してもCredentialは開けません。立てた日に、社内のパスワード管理ツールに控える場所を決めます。
名前の付け方
n8nは新しいCredentialに「Google Sheets account」のような名前を付けるので、3つ作ると同じ名前が並びます。最初に命名の型を決めます。実際に本番で動かしていると、名前にアカウントを入れておくだけで、止まったときの調べる時間が大きく減ります。
| 入れるもの | 例 |
|---|---|
| サービス | Google Sheets |
| つないだアカウント | automation@example.co.jp |
| 用途 | 問い合わせ受付 |
| 完成形 | Google Sheets / automation@example.co.jp / 問い合わせ受付 |
Credentialの種類と選び方
n8nは、専用のCredentialがあるサービスにはそれを使うよう勧めています。専用のものが無いときに、HTTP Requestノードの「Generic Credential Type」（汎用の認証）から選びます。
| 種類 | 預けるもの | 例 | 向く場面 |
|---|---|---|---|
| 専用・OAuth2（「Google Sheets OAuth2 API」など） | ログイン画面で許可した結果のトークン | スプレッドシート、Gmail | 専用ノードがあり、アカウントの権限で動かす |
| 専用・APIキーやトークン（「Slack API」など） | 相手の管理画面で発行したキー | SlackのBot User OAuth Token、LLMのAPIキー | 発行したキーを貼れば済む |
| Google Service Account API | サービスアカウントの鍵（JSON） | 共有ドライブのシート | 人のアカウントに紐づけたくない |
| Header Auth | ヘッダーの名前と値 | kintoneのAPIトークン | 専用が無いAPIをHTTP Requestで呼ぶ |
| Bearer Auth | トークン | LINEのチャネルアクセストークン | Authorization: Bearer で送るAPI |
| Basic Auth / Digest Auth | ユーザー名とパスワード | 社内の古いシステム | ほかの方式が無い |
| Query Auth | パラメーター名と値 | URLに ?key= を付けるAPI | APIがそれしか受けない |
| Custom Auth | ヘッダー・クエリ・本文をJSONで組む | ヘッダーを2つ送るAPI | 上のどれにも当てはまらない |
| OAuth2 API（汎用） | Client ID・Client Secret・各URL | kintoneのOAuthクライアント | 専用が無いOAuth2のサービス |
迷ったら次の順で決めます。
- 専用ノードと専用のCredentialがあるか見る。あればそれを使う
- 相手のサービスが、ログインして許可する方式（OAuth2）か、発行したキーを送る方式かを確かめる
- 専用が無ければ、HTTP Requestの「Generic Credential Type」で、APIドキュメントの指定どおりの型を選ぶ
OAuth2は許可した人が辞めれば切れ、APIキーは発行した画面で止めるまで使えます。Webhookで受ける側の鍵（Header Auth）とHTTP Requestの型ごとの使い方は「n8nで外部サービスとつなぐ：Webhook・HTTP Request・API」に書いています。
手順
Credentialを作る
入口は3つあります。どれで作っても同じものができます。
- 左のメニュー上部の追加ボタンから「New credential」を選ぶ
- 「Overview」かプロジェクトの画面で、右上の「Create credential」を押す
- ワークフローのノードを開き、Credentialの欄で「Create new credential」を選ぶ
プロジェクトが使える版では、作る場所を自分の「Personal」にするかプロジェクトにするかを選びます。Overviewから作ると「Personal」に、プロジェクトの中から作るとそのプロジェクトに入ります。保存するとn8nが接続を試し、「Connection tested successfully」か「Couldn’t connect with these settings」が出ます。作ったら、名前の部分を押して命名の型どおりに付け直します。
OAuth2でつなぐ：戻り先URLを合わせる
OAuth2は、相手のサービスのログイン画面で許可を押すと、相手がn8nへ戻ってきてトークンを渡す仕組みです。この戻り先が「OAuth Redirect URL」で、Credentialの画面に表示されます。相手のサービスには、この値を一字一句同じに登録します。
セルフホストの戻り先は https://n8n.example.co.jp/rest/oauth2-credential/callback の形です。n8nはこのURLの頭を次の順で決めています（2.44.7のソースで確かめました）。
| 順番 | 使う値 | この値が無いとき |
|---|---|---|
| 1 | N8N_EDITOR_BASE_URL | 2へ |
| 2 | N8N_WEBHOOK_URL（旧名 WEBHOOK_URL） | 3へ |
| 3 | N8N_PROTOCOL・N8N_HOST・N8N_PORT を組み合わせた値 | http:80 と https:443 のときだけポートを省く |
3まで落ちると、N8N_PROTOCOL=https でポートが5678のままなら https://n8n.example.co.jp:5678/rest/... になり、外からは届きません。「n8nをセルフホストで導入する：Docker ComposeでVPSに立て、独自ドメインとHTTPSで使う」の構成のように N8N_EDITOR_BASE_URL を書いておけば、本番のURLがそのまま入ります。URLを変えると戻り先も変わるので、相手のサービスへの登録もやり直しです。
n8n Cloudでは、GoogleやSlackのような対応済みのサービスは、相手側の設定なしに「Sign in with Google」や「Connect my account」でつなげます。セルフホストではこれが使えないので、相手側でOAuthのアプリ（クライアント）を作ります。Googleの作り方は「n8nの使い方入門：最初のワークフローを作って動かす」に手順を書いています。
例：kintoneにOAuth2でつなぐ
kintoneには専用のCredentialが無いので、汎用の「OAuth2 API」を使います。APIトークンより手間はかかりますが、レコードの更新者が許可した人の名前で残ります。APIトークンでのつなぎ方は「n8nとkintone・Salesforce・HubSpot連携：問い合わせを顧客管理に入れる」に書いています。
- n8nで「Create credential」を押し、「OAuth2 API」を選ぶ
- 表示された「OAuth Redirect URL」をコピーする
- cybozu.com共通管理を開き、「OAuth」を押す
- 「高度な連携を設定する」の「OAuthクライアントの追加」を押す
- 「クライアント名」に「n8n 問い合わせ受付」、「リダイレクトエンドポイント」にコピーしたURLを入れて保存する
- 追加したクライアントの編集アイコンを押し、クライアントIDとクライアントシークレットを控える
- 「利用者の設定」で、つなぐアカウント（automation@example.co.jp に当たるユーザー）にチェックを入れて保存する
- n8nに戻り、下の表のとおり入れる
- 「Connect」を押し、kintoneの許可の画面で許可する
- 「Account connected」と出たら保存する
| 項目 | 入れる値 |
|---|---|
| Grant Type | Authorization Code |
| Authorization URL | https://example.cybozu.com/oauth2/authorization |
| Access Token URL | https://example.cybozu.com/oauth2/token |
| Client ID / Client Secret | 手順6で控えた値 |
| Scope | k:app_record:read k:app_record:write |
| Authentication | Header |
OAuthクライアントを追加できるのはcybozu.com共通管理者だけです。kintoneのアクセストークンの有効期間は1時間で、切れたらn8nがリフレッシュトークンで取り直します。使うときは、HTTP Requestノードの「Authentication」を「Generic Credential Type」、「Generic Auth Type」を「OAuth2 API」にして、このCredentialを選びます。
APIキーやトークンを入れる
- 相手のサービスの管理画面でキーを発行する。発行するアカウントも共用のものにする
- n8nでそのサービスのCredential（無ければHeader AuthやBearer Auth）を作る
- キーを貼って保存し、接続の確認が通るのを見る
- キーの控えは社内のパスワード管理ツールに入れ、チャットやメモに残さない
ノードはCredentialをIDで参照しています。キーを作り直したら、Credentialを1つ書き換えるだけで、それを使う全部のノードに効きます。
どのアカウントで動いているか確かめる
OAuth2のCredentialを開くと「Account connected」とは出ますが、どのアカウントかまでは出ません。確かめるには、「問い合わせ一覧」の変更履歴やSlackの送り主のように、結果の側を見ます。
共有と権限
版ごとにできること（2026年10月時点）
| できること | Community（登録なし） | Cloud Starter | Cloud Pro | セルフホスト Business | Enterprise |
|---|---|---|---|---|---|
| Credentialの共有 | できない | できる | できる | できる | できる |
| 共有プロジェクトの数 | なし | 1 | 3 | 6 | 無制限 |
| インスタンスのAdmin | なし | なし | あり | 料金ページで確認 | あり |
| プロジェクトのEditor | なし | なし | あり | 料金ページで確認 | あり |
| プロジェクトのViewer | なし | なし | なし | なし | あり |
| 外部のシークレット保管庫 | なし | なし | なし | 料金ページで確認 | あり |
Communityでは、ワークフローとCredentialを開けるのはオーナーと作った本人だけです。Businessの役割と外部シークレット、無料登録したRegistered Communityのプロジェクトは、公式の中で記載が食い違っています。契約や登録の前に料金ページで確かめます。
役割は2段です。インスタンス全体の役割は「Owner」「Admin」「Member」の3つで、OwnerとAdminはすべてのCredentialを見て、編集し、共有できます。Memberは自分の物だけです。プロジェクトの中の役割は「Admin」「Editor」「Viewer」で、AdminとEditorはプロジェクトのCredentialを作り、直せます。Viewerは見るだけで、ワークフローを手で実行することもできません。
オーナーは全部を編集できるので、公式は普段の作業用にMemberのアカウントをもう1つ作るよう勧めています。
Credentialを共有する
共有された人は、そのCredentialを自分のワークフローで使えますが、中身は見られず、直せません。
- 左のメニューで「Overview」かプロジェクトを開く
- 「Credentials」タブを開く
- 共有したいCredentialを開く
- 「Sharing」タブを押す
- 「Share with users or projects…」の欄で相手のユーザーかプロジェクトを選ぶ
- 「Save」を押す
外すときは同じ画面でゴミ箱を押して「Save」です。外すと、その人が組んだワークフローは止まります。
ワークフローを共有すると、相手はそのワークフローの中で使っているCredentialを、個別に共有されていなくても使えます。逆に、Credentialを共有されていない人は、そのCredentialを使っているノードを直せません。開いて実行はできます。
プロジェクトにまとめる
チームで回すなら、個別の共有を重ねるより、プロジェクトに置くほうが崩れません。「問い合わせ受付」なら「営業窓口」プロジェクトを作り、ワークフロー、スプレッドシートとSlackのCredentialをそこへ入れます。プロジェクトの中で作ったCredentialは、メンバー全員が使えます。
既に個人の置き場にあるものは移せます。
- Credentialの一覧で、移すもののメニューから「Move」を選ぶ
- 「Select project or user…」の欄で、移す先のプロジェクトかユーザーを選ぶ
- 既存の共有が外れるという注記を読み、「Move credential」を押す
ワークフローを移すときは、使っているCredentialも一緒に共有する選択肢が出ます。外すと移した先で動かなくなります。移すと既存の共有はすべて外れるので、ほかのワークフローがそのCredentialを共有で使っていないか先に見ます。
Community editionでの回し方
共有が無いので、1本のワークフローを触る人を1人に決めます。2人目が直す必要が出たら、オーナーが入って直すか、次の節の引き継ぎで持ち主を替えます。それで足りなくなったら、共有のあるCloudかBusinessを考えます。費用の比べ方は「n8nの料金：Cloudとセルフホストの費用、商用利用の線引き」に書いています。
鍵の管理
N8N_ENCRYPTION_KEYは失くせない
n8nは初回の起動時に暗号鍵を作り、~/.n8n の config ファイルに保存します。Credentialはこの鍵で暗号化してからデータベースに入ります。データベースのバックアップがあっても、鍵が違えば中身は読めません。
- 鍵は
N8N_ENCRYPTION_KEYで自分で決められる。決めたら変えない - キューモードで複数台に分けているなら、全部に同じ値を入れる
- 控えは社内のパスワード管理ツールに入れ、バックアップと別の場所に置く
鍵を控える手順とバックアップの取り方は「n8nを止めずに運用する：アップデート・バックアップ・エラー通知・脆弱性」に書いています。
書き出しと –decrypted
CLIでCredentialを書き出すと、普段は暗号化されたまま出ます。--decrypted を付けると、パスワードやトークンが平文で出ます。
docker compose exec -u node n8n n8n export:credentials --backup --output=/home/node/.n8n/backups/credentials/
docker compose exec -u node n8n n8n export:credentials --all --decrypted --output=/home/node/.n8n/backups/decrypted.json1行目が普段のバックアップ、2行目が平文の書き出しです。平文が要るのは、鍵の違うn8nへ移すときだけです。移す先で読み込んだら、平文のファイルはその場で消します。
読み込みは n8n import:credentials --input=decrypted.json です。--userId か --projectId を付けると、持ち主を指定して入れられます。同じIDのCredentialが先にあると上書きされます。
暗号鍵のローテーション
2.xでは、データを暗号化する鍵だけを定期的に入れ替える仕組みを、環境変数で有効にできます。N8N_ENV_FEAT_ENCRYPTION_KEY_ROTATION=true を全部のn8nに入れて再起動すると、「Settings」の「Data encryption keys」に鍵が出て、「Rotate key」で入れ替えられます。N8N_ENCRYPTION_KEY 自体は変わりません。セルフホストだけの機能で、操作はオーナーだけです。
有効にすると、Credentialは古いn8nが読めない形式で書かれます。有効にした後は版を下げられず、戻すにはバックアップから戻すしかありません。公式は3.0で既定で有効にする予定としています。入れるなら、データベースを丸ごとバックアップし、検証用の環境で試してからにします。
退職・担当替えのときの付け替え
「問い合わせ受付」を作った担当者が異動する場面で書きます。順番が大事です。外のアカウントを先に止めると、その日から記録が止まります。
- オーナーでログインし、「Overview」の「Credentials」タブで、担当者が持ち主のものを洗い出す
- 「Settings」の「Users」で担当者のメニューを開き、「Delete User」を選ぶ
- 「Transfer their workflows, credentials and data tables to another user or project」を選び、後任かプロジェクトを指定して削除する
- 後任が、共用アカウント（automation@example.co.jp）で新しいCredentialを作る
- 「問い合わせ受付」の各ノードで、Credentialを新しいものに選び直す
- 「Execute step」で、シートに1行入りSlackに届くのを確かめる
- 「Publish」を押して本番に出す
- 古いCredentialを削除する
- 情報システムの担当に、外のアカウントを止めてよいと伝える
手順3で「Delete their workflows, credentials and data tables」を選ぶと、全部消えます。確認で「delete all data」と打たせる画面なので、そこまで来たら選び間違いです。
手順3で移るのはn8nの中の持ち主だけで、Credentialの中身は前の担当者のアカウントのままです。手順4〜7を飛ばすと、アカウントを止めた日に止まります。ノードでCredentialを選び直すと、同じワークフローの中で古いものを使っていたノードもまとめて切り替わります。2.xでは選び直しも下書きの変更なので、手順7のPublishを忘れると本番は古いCredentialのまま動きます。手順8の前に、ほかのワークフローが古いCredentialを使っていないか確かめます。使っていないCredentialは、セキュリティ監査 n8n audit でも洗い出せます。
プロジェクトに置き、共用アカウントでつないでいれば、「Project settings」でメンバーを外すだけで済みます。
セルフホストのオーナー自身が替わるときは注意が要ります。オーナーのメールアドレスは「Settings」の「Personal」で書き換えられますが、それはオーナーのアカウントの中身が変わるだけで、別のユーザーにオーナーを移す機能ではありません。オーナーは最初から n8n-admin@example.co.jp のような役割のアドレスで作ります。n8n Cloudでは、オーナーのメールアドレスを書き換えるとインスタンスの持ち主と請求の宛先も替わります。
GoogleのOAuthクライアントを作ったGoogle Cloudのプロジェクトにも、オーナーを2人以上入れておきます。
応用
HTTP Requestで使える先を絞る
多くのCredentialには「Allowed HTTP Request Domains」という欄があります。「All」（どこにでも送れる）、「Specific Domains」（指定したドメインだけ）、「None」（HTTP Requestでは使わせない）から選びます。初期値は「All」です。kintoneのHeader Authなら「Specific Domains」で example.cybozu.com だけにしておくと、別のURLへ鍵を送る組み方を止められます。専用ノードで使うときには効きません。
Client IDとClient Secretを利用者に見せない
セルフホストでOAuthのアプリを社内に1つだけ用意し、各自は「Connect」を押すだけにするなら、Credential overwritesを使います。CREDENTIALS_OVERWRITE_ENDPOINT の受け口にClient IDとClient SecretをJSONで送ると、画面ではその欄が隠れます。CREDENTIALS_OVERWRITE_DATA に書く方法は、漏れうるとして公式が勧めていません。
外部のシークレット保管庫を使う
Enterpriseでは、1Password（Connect Server）・AWS Secrets Manager・Azure Key Vault・GCP Secrets Manager・HashiCorp Vault・Infisicalの値を、Credentialの欄に {{ $secrets.保管庫名.キー }} の形で入れられます。使えるのはCredentialの欄だけです。
使う人ごとのアカウントで動かす
Enterpriseでは、OAuth2のCredentialを「Fixed credential」（誰が動かしても同じ）か「End-user credential」（動かした人のアカウント）から選べます。2026年10月時点ではプレビューで、誰も手で動かさない「問い合わせ受付」には向きません。
できないことと、その代わり
| できないこと | 代わりの手 |
|---|---|
| Community editionでCredentialを他の人と共有する | 1本を触る人を1人に決め、引き継ぎはユーザー削除時の移管で行う。共有が要るならCloudかBusiness以上 |
| 共有された人がCredentialの中身を見る、直す | 持ち主かプロジェクトのAdmin（Editor）が直す |
| Credentialの画面で、つながっているアカウント名を見る | 名前にアカウントを入れる。結果側（シートの変更履歴、Slackの送り主）で確かめる |
| セルフホストで「Sign in with Google」を使う | Google CloudでOAuthクライアントを作る |
| 暗号鍵を失くしたあとでCredentialを開く | 戻せない。鍵を控え、無いなら全部つなぎ直す |
| ローテーションを有効にした後で版を下げる | 有効にする前にデータベースを丸ごとバックアップする |
| Communityで外部のシークレット保管庫を使う | n8nの暗号化された保管に入れ、暗号鍵を厳重に管理する |
よく詰まるところ
| 症状 | 原因 | 直し方 |
|---|---|---|
redirect_uri_mismatch などで許可の画面から戻れない | 相手に登録した戻り先とOAuth Redirect URLが違う | Credential画面のURLをコピーし直して登録する。http/https、ポート、末尾まで揃える |
OAuth Redirect URLが localhost やポート付きになる | N8N_EDITOR_BASE_URL も N8N_WEBHOOK_URL も無い | N8N_EDITOR_BASE_URL を本番のURLにして作り直し、相手側の登録も直す |
| 「Sign-in window was blocked」と出る | ブラウザがポップアップを止めた | n8nのドメインでポップアップを許可して押し直す |
| 7日ほどでGoogleにつながらなくなる | Google側のアプリが External かつ Testing | Internalにするか、公開の状態を見直す。手順は「n8nの使い方入門：最初のワークフローを作って動かす」 |
| ある日からGoogleが失敗する | 許可の取り消し、6か月使っていない、Gmailを含む許可でパスワードを変えた、など | Credentialを開いて「Reconnect」で許可し直す |
| テストで何度もつなぎ直したら古いCredentialが切れた | Googleは1つのアカウントと1つのクライアントにつきリフレッシュトークン100個までで、超えると古いものから黙って失効する | 不要なCredentialを消し、本番用は作り直しを繰り返さない |
| 期限切れのはずなのにトークンが更新されない | 相手のAPIが期限切れを401ではなく403で返す | OAuth2 APIの「Token Expired Status Code」を403にする |
| ノードに「not shared with」と出て直せない | そのCredentialが自分に共有されていない | 持ち主に共有してもらうか、プロジェクトに移す |
| 移したワークフローが動かなくなった | Moveで既存の共有が外れ、Credentialが付いてこなかった | 移す先にCredentialを共有するか、移す先で作り直す |
| 誰のアカウントで動いているか分からない | 既定の名前「〜 account」のまま並んでいる | 結果側でアカウントを確かめ、命名の型で付け直す |
| 担当者のアカウント停止と同時に止まった | n8nの持ち主を移しても、中身は前の担当者のアカウントのまま | 共用アカウントでCredentialを作り直し、選び直してPublishする |
| 選び直したのに本番が古いCredentialで動く | 選び直しは下書きのまま | 「Publish」を押す |
| 戻したらCredentialが全部開けない | 暗号鍵が違う | 元の N8N_ENCRYPTION_KEY で起動し直す |
次にやること
- n8nをセルフホストで導入する：Docker ComposeでVPSに立て、独自ドメインとHTTPSで使う
- n8nを止めずに運用する：アップデート・バックアップ・エラー通知・脆弱性
- n8nとGoogleスプレッドシート連携：読み書き・更新・重複を防ぐ
- n8nで外部サービスとつなぐ：Webhook・HTTP Request・API