「このツールと連携したいけれど、専用のノードがない…」
そんな時に頼りになるのが、n8nの万能ナイフ「HTTP Request」ノードです。これさえ使いこなせれば、世界中のほぼすべてのWebサービス（API）と連携が可能になります。
しかし、多くの非エンジニアがここで挫折します。その原因の99%は「認証（Authentication）」です。
「Header？ Bearer？ API Key？ 何をどこに入力すればいいの？」
この記事では、ランサーズ・クラウドワークスで累計200件以上のAPI連携・自動化案件を受注してきた経験をもとに、HTTP Requestノードにおける認証設定を「3つの鉄板パターン」に絞って解説します。実際の失敗談やトラブル対処法も交えて紹介しますので、初めての方でも30分以内に設定が完了するはずです。
【結論】APIキーは「通行手形」。渡す場所は3箇所だけ
難しく考えるのはやめましょう。認証とは、相手のサービスに「私は怪しい者ではありません（APIキーを持っています）」と証明する通行手形を見せる行為です。
そして、その手形を見せる場所（設定箇所）は、大きく分けて以下の3パターンしかありません。
- Header（ヘッダー）: 封筒の宛名書き部分に書く（最も一般的）
- Query Parameters（クエリパラメータ）: URLの後ろにくっつける
- Body（ボディ）: 封筒の中身（手紙）に書く（稀なケース）
それぞれの設定方法を具体的に見ていきましょう。
【完全ガイド】3大認証パターンの設定手順
n8nの「HTTP Request」ノードを開き、Authentication の項目を設定していきます。
パターン1: Headerにキーを入れる（Header Auth）
最近のモダンなSaaS（Notion, DeepLなど）で最も多いパターンです。
#### 設定手順:
- HTTP Requestノードの Authentication を
Generic Credential Typeに設定します。 - Generic Auth Type で
Header Authを選択します。 - Credential for Header Auth で「Create New」を選択します。
出てきた画面で以下を入力します。
- Name:
AuthorizationやX-API-KEYなど（ドキュメントで指定された名前） - Value: 取得したAPIキー
★ここがポイント:
ドキュメントに「Authorization: Bearer sk-12345」と書かれている場合は、Value欄に Bearer sk-12345... と、「Bearer 」（半角スペース含む）をセットで入力する必要があります。
> 【実体験】Notionの連携で1時間ハマった落とし穴
>
> 初めてNotionのHTTP Request認証を設定した際、ドキュメントを見ながら Name欄に authorization（小文字のa） と手打ちしたところ、何度試しても 401 Unauthorized が返ってきました。APIキーを3回取り直し、ワークフローを作り直し…それでも解決しない。1時間格闘してようやく気づいた原因は、たった1文字の大小文字の差でした。
>
> 正しくは Authorization（頭文字が大文字A） です。HTTPの仕様上ヘッダー名は大小文字を区別しませんが、サービス側の実装によっては厳密に区別されるケースがあります。Name欄の値は必ず公式ドキュメントからコピペするのが鉄則。手打ちは絶対に避けましょう。
パターン2: URLにキーを入れる（Query Auth）
古いサービスや、簡易的なAPI（OpenWeatherMapなど）でよく使われます。URLの末尾に ?api_key=xxxx と付くタイプです。
#### 設定手順:
- Authentication を
Generic Credential Typeに設定。 - Generic Auth Type で
Query Authを選択。 - Credential for Query Auth で「Create New」を選択。
入力画面:
- Name:
api_keyやkeyなど（ドキュメントで指定された名前） - Value: APIキーそのもの
パターン3: IDとパスワードを使う（Basic Auth）
WordPressのAPIや、社内システムなどで使われる「ユーザー名」と「パスワード」の組み合わせです。
#### 設定手順:
- Generic Auth Type で
Basic Authを選択。 - User: ユーザー名
- Password: パスワード（またはアプリケーションパスワード）
【実践例】国産SaaSのHTTP Request認証設定
海外サービスの解説は多いですが、日本で普及している国産SaaSの設定例を紹介します。実際のクライアント案件で使用した設定です。
Chatwork（チャットワーク）
Chatworkは Header Auth を使います。日次レポートやアラートの自動通知案件でよく採用するパターンです。
| 項目 | 値 |
|——|—–|
| Name | X-ChatWorkToken |
| Value | 発行したAPIトークン（管理画面 → API Token） |
“
GET https://api.chatwork.com/v2/me
Header: X-ChatWorkToken: {your_token}
`
freee（フリー会計）
freeeは本来OAuth2が必要ですが、テスト用途なら Bearer Token（Header Auth） で簡易接続できます。
| 項目 | 値 |
|------|-----|
| Name | Authorization |
| Value | Bearer {アクセストークン} |
> 注意: freeeの本番連携はOAuth2フローの実装が推奨されています。Bearer Tokenは有効期限があるため、定期実行ワークフローには向きません。
Chatworkへの日次レポート通知やfreeeへの請求書自動作成など、こうした国産SaaS連携の案件では、1件あたり週4〜6時間の手作業を自動化できるケースが多く、費用対効果が高い自動化の代表例です。
n8nの「Credential」機能を使うべき理由
「なぜ直接ヘッダーにキーを書き込まずに、わざわざCredentialを作るの？」と思われたかもしれません。
それには重要な理由があります。
- セキュリティ: Credentialに保存されたキーは暗号化され、ワークフローをエクスポート（共有）しても他人には見えません（空欄になります）。
- 使い回し: 一度NotionのCredentialを作れば、別のHTTP Requestノードでもリストから選ぶだけで使い回せます。
APIキーをノード内の「Value」欄に直接ベタ書きするのは、セキュリティ事故の元なのでやめましょう。
【判断フロー】Generic Credential vs 専用Credential
n8nには「Generic Credential Type（汎用）」と「サービス専用Credential」の2種類があります。どちらを使うか迷ったら、このフローで判断してください。
`
専用のIntegrationノード（Notion, Slack, Gmail等）が存在する？
│
├─ YES → 専用ノード＋専用Credentialを使う
│ （OAuth2の自動リフレッシュ等が組み込まれていて安定）
│
└─ NO → HTTP Requestノードを使う
│
├─ サービスのCredentialテンプレートがn8nにある？
│ ├─ YES → Generic Credential Typeでそのテンプレートを選択
│ └─ NO → Header / Query / Basic Auth を手動設定
│
└─ → 本記事の3パターンの出番
`
原則：専用Credentialがある場合は必ずそちらを優先。
Generic Credential（Header Auth等）は柔軟ですが、OAuthのトークン自動更新などの便利機能はありません。
よくあるエラーとトラブルシューティング
エラー1: 「401 Unauthorized」
意味: 「誰だお前は！」（認証失敗）
対処法:
- APIキーのコピペミスはありませんか？（余計なスペースが入っている等）
- Headerの名前（Name）は正確ですか？（x-api-key
なのかAuthorizationなのか） - Bearer
という接頭辞が必要ではありませんか？
エラー2: 「403 Forbidden」
意味: 「お前であることはわかったが、通すわけにはいかん」（権限不足）
対処法:
- 無料プランの制限を超えていませんか？
- そのAPIキーに、実行しようとしている操作（書き込みなど）の権限が付与されていますか？（Read Onlyになっていないか）
初心者向けAPIドキュメントの読み方
英語のAPIドキュメントを見ると「うっ」となりますが、見るべき場所は1箇所だけです。
たいてい、左メニューの「Authentication」または「Getting Started」という項目に、以下のようなサンプルコードがあります。
`bash
curl https://api.example.com/v1/users \
-H "Authorization: Bearer YOUR_API_KEY"
`
この -H` というのが Header の意味です。これを見たら、「あ、n8nでHeader Authを選んで、名前をAuthorization、値をBearerにすればいいんだな」と判断できます。
まとめ
HTTP Requestノードの認証設定は、一度理解してしまえば「型」の使い回しです。
- Header Auth（最多・Notion/Chatworkなど）
- Query Auth（URLにパラメータ・OpenWeatherMapなど）
- Basic Auth（ID/Pass・WordPressなど）
この3パターンと「専用Credential vs Generic Credentialの判断フロー」を押さえておけば、未対応のツールでも自力で連携できます。
連携できたら、ぜひコメントで教えてください。 どのサービスと繋げたか、どこでハマったかなど、みなさんの実体験がこの記事を育てます。
次回はOAuth2認証（Google・Slack・freee本番連携など）の設定手順を解説予定です。更新を見逃したくない方はブログの読者登録をどうぞ。
参考文献・リンク
—
この記事の内容に関する開発・自動化のご依頼はお気軽にご相談ください。
累計200件以上の受注実績・残念評価ゼロ。
コメント