初心者向け
n8n HTTP Requestノードの使い方：最初の1回から実務で使う設定まで
n8nで一番使うHTTP Requestノードを、実際のAPIを1回叩くところから解説します。前半は初めての人向け、後半は認証・ページネーション・エラー対策まで。
公開 最終更新
動作確認: — n8n 2.36.8 / HTTP Request ノード v4.5
n8n で外部のサービスからデータを取ってきたり、データを送ったりするときに使うのが HTTP Request ノードです。n8n のノードの中で最もよく使います。
この記事は前半がn8n を触ったことがない人向けで、実際に動くAPIを1回叩いて、 結果を確認するところまでを通します。後半は基本操作ができる人向けに、認証や 大量データの取得、止まらないようにする設定を扱います。
設定項目の名前と既定値は、HTTP Request ノード v4.5 の定義を直接確認して書いています。 ボタン名などの画面上の表記と動作は、n8n 2.36.8 の画面で確認したものです。 バージョンが違うと表記が変わることがあります。
HTTP Requestノードは何をするものか
インターネット上のサービスの多くは、APIという窓口を用意しています。決められた形式で 「これをください」「これを保存してください」と送ると、結果を返してくれる仕組みです。
HTTP Request ノードは、その窓口にリクエスト（要求）を送り、返ってきたレスポンス（返事）を 次のノードに渡す役割を持ちます。
n8n には Slack や Google スプレッドシート専用のノードもありますが、専用ノードが用意されて いないサービスや、専用ノードでは足りない操作は、すべてこの HTTP Request で扱います。 公式でも、専用ノードにない操作を行う方法として Custom API actions の形で案内されています。
実際に叩いてみる
説明を読むより、1回動かした方が早いので、先にやってみます。
ここでは気象庁が公開している天気予報のJSONを使います。認証（ログイン）が不要なので、 準備なしですぐ試せます。
https://www.jma.go.jp/bosai/forecast/data/forecast/130000.json末尾の 130000 は東京都を表す番号です。
このJSONは気象庁のサイトが内部で使っているもので、利用者向けのAPIとして仕様が公開されて いるわけではありません。練習用として使い、業務のワークフローに組み込むのは避けてください。 形式が予告なく変わる可能性があります。
手順
- n8n で新しいワークフローを作る
- Add first step から Manual Trigger（手動実行）を選ぶ
- その後ろに HTTP Request ノードを追加する
- Method は
GETのまま - URL に上のアドレスを貼り付ける
- Execute step（オレンジ色のボタン）を押す
Execute step は2か所にあります。Parameters タブの右横と、右側の OUTPUT パネルの中央です。
どちらを押しても同じです。
Method の GET は「データをください」という意味です。逆にデータを送るときは POST を
使います。今回は取ってくるだけなので GET です。
うまくいくと、右側のパネルに結果が表示されます。
返ってきたデータの見方
結果パネルには Table / JSON / Schema の切り替えがあります。最初は JSON を見るのが 分かりやすいです。こういう構造が返ってきます。
[
{
"publishingOffice": "気象庁",
"reportDatetime": "2026-09-24T11:00:00+09:00",
"timeSeries": [
{
"areas": [
{
"area": { "name": "東京地方", "code": "130010" },
"weathers": ["晴れ 夜 くもり 所により 雨", "..."]
}
]
}
]
}
]レスポンスが配列だと、複数のアイテムに分割される
先頭が [ で始まっていることに注目してください。 このJSONは配列です。
HTTP Request ノードは、配列で返ってきたレスポンスを1要素ずつのアイテムに分けます。 この気象庁のJSONは2要素の配列なので、出力は 2件になります （結果パネルの右上に件数が表示されます）。
1件目が今日明日の予報、2件目が週間予報で、それぞれ中身の構造が違います。 後続のノードで「1件だけ来る」と思って組むと、想定外の件数で処理が回ります。
レスポンスを見たら、まず件数を確認してください。 配列で返ってくるAPIは珍しくありません。
ここでもう1つ大事なのは、入れ子になっているということです。「東京地方の天気」を取り出すには、
timeSeries の中の areas の中の weathers …と階層をたどる必要があります。
n8n ではこの階層を、次のように書いて指定します。
{{ $json.timeSeries[0].areas[0].weathers[0] }}{{ }} で囲んだ部分は**式（Expression）**と呼ばれ、「固定の文字ではなく、前のノードの
データを使う」という意味になります。$json は「前のノードから渡ってきたデータ」を指します。
式を書くときは、入力欄を Expression モードに切り替える必要があります。
切り替えのタブは常に見えているわけではなく、値の入力欄にマウスを乗せたときだけ
上に Fixed / Expression として現れます。
いま Expression モードになっているかどうかは、入力欄の左にある緑の = アイコンで
判断できます。これが付いていれば式として評価され、付いていなければただの文字列です。
この画面の便利なところは、式のすぐ下に評価結果が表示されることです。
{{ $json.timeSeries[0].areas[0].weathers[0] }} の下に 晴れ 夜 くもり 所により 雨
と出ていれば、階層のたどり方が合っているということです。
左側のツリーから項目をドラッグしても式を作れます。階層が深いときは、手で書くより確実です。
うまく動かないときは、まず緑の
=が付いているか確認してください。Fixedのまま式を書くと、{{ ... }}という文字列がそのまま入ります。
ここまでで「APIを叩いて、結果を取り出す」という基本の流れは終わりです。
認証が必要なAPIを叩く
実務で使うAPIのほとんどは、認証（誰からのリクエストかの確認）を求めます。 Authentication の設定には2種類あり、どちらを選ぶかは次のように決まります。
Predefined Credential Type
n8n が既に対応しているサービスの認証情報を、HTTP Request ノードから流用する方式です。 たとえば Slack ノード用に作った認証情報を、そのまま HTTP Request でも使えます。
公式ドキュメントでも、選べる場合はこちらが推奨されています。トークンの更新のような 面倒な部分を n8n 側が持ってくれるためです。
- Authentication で
Predefined Credential Typeを選ぶ - Credential Type で対象のサービスを選ぶ
- 既存の認証情報を選ぶか、
Create Newで作る
Generic Credential Type
n8n が対応していないサービスはこちらです。次から選びます。
| 方式 | 使う場面 |
|---|---|
| Templated Custom Auth | ヘッダー・クエリ・ボディに値を入れる形式全般。新規に作るならまずこれ |
| Header Auth | 既存の認証情報を使い回すとき。X-API-Key のような独自ヘッダー |
| Bearer Auth | 既存の認証情報を使い回すとき |
| Query Auth | URLのクエリにAPIキーを載せる形式 |
| Basic Auth | ユーザー名とパスワードを送る |
| Digest Auth | ダイジェスト認証。古いシステムで使われる |
| OAuth2 API | OAuth2 で認可する |
| OAuth1 API | OAuth1 で認可する |
| Custom Auth | 上記で表現できない独自形式 |
Authorization: Bearer <token>だからといって Bearer Auth を選ばないでください。 n8n のノード定義には、新規に作る認証情報は Templated Custom Auth を優先するよう明記されています。 Bearer 形式もテンプレートで{"headers":{"Authorization":"Bearer {{api_key}}"}}と書けば表現でき、 こちらの方が後から形式を変えやすくなります。Bearer Auth や Header Auth は、 既にその型で作った認証情報を使い回す場合に選びます。
APIキーをURLやヘッダー欄に直接書かないでください。 ワークフローをJSONで書き出したとき、 キーごと外に出ます。必ず認証情報として登録してください。Credential に入れた値は 書き出し対象から外れます。
データを送る
送る内容は3か所に分かれていて、それぞれトグルで有効にします。
- Send Query Parameters — URLの
?key=valueの部分 - Send Headers — リクエストヘッダー
- Send Body — 本文（データを登録・更新するときに使う）
どれも「名前と値を1組ずつ入力する」か「JSONでまとめて指定する」かを選べます。 値が動的に変わるなら、JSON指定にして式を埋め込む方が管理しやすくなります。
ボディの形式
| 形式 | 用途 |
|---|---|
| JSON | 大半のREST API |
| Form URLencoded | application/x-www-form-urlencoded を要求するAPI |
| Form-Data | ファイルを含むフォーム送信 |
| n8n Binary File | 前のノードから渡ってきたファイルをそのまま送る |
| Raw | 上記に当てはまらない任意の文字列 |
ファイルをアップロードする場合は、前のノードが出力したバイナリ（画像やPDFなどの ファイル本体のデータ）を n8n Binary File で受け渡します。
配列をクエリに載せるとき
Options → Array Format in Query Parameters で、配列の表現方法を選べます。
- No Brackets —
?id=1&id=2 - Brackets Only —
?id[]=1&id[]=2 - Brackets with Indices —
?id[0]=1&id[1]=2
既定は Brackets Only です。APIによって受け付ける形式が違うので、 配列を渡したのに1件しか反映されないときは、まずここを疑ってください。
APIドキュメントのcurlをそのまま取り込む
HTTP Request ノードには Import cURL があります。APIドキュメントに載っている
curl コマンドを貼り付けると、メソッド・URL・ヘッダー・ボディが自動で入ります。
手で項目を埋めるより速く、転記ミスも起きません。初めて触るAPIは、まずこれを試すのが 効率的です。
大量のデータはページネーションで取る
件数の多いAPIは、1回のリクエストで全件返ってきません。Options → Pagination を使うと、 n8n が複数回リクエストを投げて結果をまとめてくれます。
方式は2つあります。
- Update a Parameter in Each Request — ページ番号やオフセットを、リクエストごとに増やしていく形式
- Response Contains Next URL — レスポンスの中に次ページのURLが入っている形式
どちらを使うかはAPIの仕様で決まるので、対象APIのドキュメントを確認してから選びます。
終了条件も指定できます（レスポンスが空になったら / 特定のステータスコードが返ったら / 任意の条件式）。加えて Limit Pages Fetched（最大リクエスト数、既定100）と Interval Between Requests（リクエスト間隔）があります。
終了条件を誤ると、止まらなくなります。 検証中は Limit Pages Fetched を 小さい値（5など）にしておくと安全です。
止まらないようにする設定
本番で動かすワークフローでは、ここが効きます。すべて Options にあります。
Timeout
レスポンスヘッダーが返るまで待つ上限を、ミリ秒で指定します。
ここは2段構えになっていて、一度間違えて書いたので測り直しました。 実行データに残る実際のリクエスト設定を見ると、こうなっています。
| Options の状態 | 実際に使われた値 |
|---|---|
| Timeout を追加していない（初期状態） | 300000（5分） |
| Timeout を追加した（欄の表示は 10000 のまま） | 10000（10秒） |
つまり 10000 は「項目を追加したときに欄へ入る値」であって、追加しなかったときの 動作値ではありません。 何も設定していない状態では 5分 待ちます。
ノードの定義には @default 10000 と書かれています。定義だけを読むと「既定は10秒」と
書いてしまいますが、実際の動作は違いました。 定義に出てくるのは項目そのものの既定値で、
項目が無いときのフォールバックはまた別、ということです。
実務上の意味はこうです。
- 初期状態のままなら、応答の遅いAPIでも5分は待ちます。先に諦めることは、まずありません
- Timeout を追加すると、そのとたんに上限が10秒に縮みます。 「設定を触ったら たまに失敗するようになった」場合は、ここを疑ってください
- 処理に時間のかかるAPIを叩くなら、追加した上で明示的に長い値を入れること
Batching
Items per Batch と Batch Interval で、リクエストを分割して間隔を空けられます。 既定は 50件ごと・間隔1000ms（1秒）です。 レート制限（短時間に大量のリクエストを送ると拒否される仕組み）のあるAPIで必要になります。
Redirects
リダイレクトを追うかどうかと、最大回数（既定21回）を指定します。
関連して Send Credentials on Cross-Origin Redirect という項目があります。
別ドメインへリダイレクトされたときに Authorization ヘッダーを送り続けるかどうかの設定で、
既定はオフです。認証情報が意図しない相手に渡るのを防ぐためのものなので、
安易にオンにしないでください。
Response
- ヘッダーとステータスコードを出力に含めるか
- Never Error — エラーが返ってもワークフローを止めない
- レスポンスの解釈形式（JSON / テキスト / ファイルなど）
Never Error は扱いに注意が必要です。 止まらなくなる代わりに、失敗に気づけなく なります。使うなら、後段で必ずステータスコードを見て分岐させてください。
Ignore SSL Issues
SSL証明書の検証に失敗しても続行します。社内システムで自己署名の証明書を使っている場合などに 必要になりますが、外部のAPIに対して安易に有効化しないでください。通信内容を第三者に 読まれるリスクがあります。
うまくいかないときの切り分け
順番に確認すると原因が絞れます。
- Execute step でノード単体を実行する — 後段のノードの問題と切り分ける
- ステータスコードを見る — Options の Response でステータスを出力に含める
- 式の左に緑の
=が付いているか確認する — Fixed のままだと文字列として送られる - 同じリクエストを curl で投げてみる — n8n 側の問題かAPI側の問題かを分ける
- 認証情報を確認する — 有効期限切れ、権限不足、貼り付け時の余分な空白
特に5つ目は、エラーメッセージが「401」としか出ないことが多く、原因が分かりにくい 部分です。
次に読む
- n8n IFノードの使い方 — 取ってきたデータで処理を分岐させる
- n8n Schedule Triggerの使い方 — 決まった時刻に自動で動かす
- n8n Codeノードの使い方 — 取ってきたデータをコードで加工する
- n8n Edit Fields（Set）ノードの使い方 — 取ってきたデータの項目を整える
- コアノードの一覧 — ほかのよく使うノード
- エラーと対処 — 実際に出たエラーと切り分け方
- 権限と資格情報 — APIキーと認証情報の扱い方