DifyのHTTPリクエストノードとは？外部APIと連携するワークフローの作り方
室谷今回はDify（ディファイ）のHTTPリクエストノードを深掘りしましょう。これ、.AI（ドットエーアイ）コミュニティの中でも使いこなせている人とそうでない人の差がはっきり出るノードなんですよね。
テキトー教師ほんとそうですよね。講座でDifyのワークフローを教えるとき、LLMノードやナレッジ取得はすぐ理解してもらえるんですが、HTTPリクエストだけ「設定が難しくて・・・」って止まってしまうコミュニティのメンバーさんが多いんです。
室谷でも本当に面白いのは、HTTPリクエストを使えるようになった瞬間、Difyのワークフローで何でもできるようになるんですよ。外部APIに繋がるということは、天気予報でも、楽天の商品検索でも、自社の内部APIでも、全部ワークフローの一部にできるということで・・・
テキトー教師まさにそこが本質ですよね。「DifyはAIツールだから、AIに関係することしかできない」と思い込んでいる人が結構いるんですが、HTTPリクエストを知った瞬間に認識が変わります。
「あ、これって何でもできるじゃないか」って。
「あ、これって何でもできるじゃないか」って。
室谷MYUUUでも、クライアント企業のシステムにDifyのワークフローをAPI経由で繋ぐ案件が増えてきています。バックエンドで動いているREST APIに対してHTTPリクエストで叩く構成が、開発コストを大幅に削減してくれるんですよ。
テキトー教師この記事では、HTTPリクエストノードの基本的な設定方法から、よくあるエラーの対処法、応用的なユースケースまで順番に解説していきます。初めて触る方も、エラーで詰まっている方も、一緒に確認していきましょう。
DifyのHTTPリクエストノードとは何か
室谷まず基本から整理しましょう。DifyのHTTPリクエストノードは、ワークフロー内から外部のWebサービスやAPIにHTTP通信を送れる機能です。
テキトー教師シンプルに言うと「DifyのワークフローからURLにリクエストを送る」ためのノードです。メソッドはGET、POST、PUT、PATCH、DELETE、HEADに対応しています。
室谷Dify公式ドキュメントには「外部データの取得、Webhook送信、ファイルアップロード、HTTP通信を受け付けるあらゆるサービスとの連携」と書かれています。要は「HTTPが使えれば何でも繋がる」ということで・・・
テキトー教師整理すると、このノードで何ができるかというと：
- 外部APIからデータを取得する（天気、ニュース、株価など）
- 他のサービスに情報を送信する（Slackへの通知、CRMへの登録など）
- ファイルをアップロードまたはダウンロードする
- Webhookをトリガーする
- 自社の内部APIと連携する
室谷このリストを見ると「DifyってAIだけじゃないんだ」とわかりますよね。HTTPリクエストが使えると、Difyは実質的に汎用の自動化プラットフォームになるんですよ。
テキトー教師そうなんですよ。.AIの受講生さんでも「DifyでNotionにデータを自動登録するワークフロー」とか「スプレッドシートAPIと連携して結果を自動記録する」みたいな使い方をしている方が増えています。
HTTPリクエストノードで使えるHTTPメソッド
室谷HTTPメソッドについても確認しておきましょう。「dify httpリクエスト get」「dify httpリクエスト post」どっちを使えばいいかという質問がよく来るんですよね。
テキトー教師ここは基本的なHTTPの知識になりますが、Difyで使うメソッドとしては以下のように整理できます：
| メソッド | 用途 | 典型的なユースケース |
|---|---|---|
| GET | データの取得 | 天気API、検索API、ステータス確認 |
| POST | データの送信・作成 | フォーム送信、ファイルアップロード、JSONデータ送信 |
| PUT | リソースの更新（全体） | 既存データの全項目更新 |
| PATCH | リソースの部分更新 | 特定フィールドだけ更新 |
| DELETE | リソースの削除 | ファイル削除、レコード削除 |
| HEAD | ヘッダーのみ取得 | リソースの存在確認 |
室谷実務で一番使うのはGETとPOSTですね。GETはAPIから何かデータを引っ張ってくるとき、POSTはデータを送信したいときです。
テキトー教師講座でよく聞かれるのが「GETとPOSTどちらを使えばいいか迷う」というパターンです。迷ったら使いたいAPIのドキュメントを確認してください。
どのエンドポイントにどのメソッドを使うかは、そのAPI側が決めていることなので。
どのエンドポイントにどのメソッドを使うかは、そのAPI側が決めていることなので。
DifyのHTTPリクエストノードの基本的な設定方法
室谷では実際の設定方法を見ていきましょう。HTTPリクエストノードを開くと、URL入力欄、ヘッダー設定、ボディ設定が並んでいます。
テキトー教師まず設定の全体像を整理すると、以下の項目があります：
- API（メソッド + URL）: リクエスト先のメソッドとURLを設定
- 認証（APIキー）: API認証が必要な場合の設定
- ヘッダー: リクエストヘッダー（Content-TypeやAuthorizationなど）
- パラメータ: クエリパラメータ（URLの?以降に付くパラメータ）
- ボディ: リクエストボディ（POSTやPUTで使う）
- タイムアウト: 接続・読み込み・書き込みのタイムアウト設定
室谷この中で一番大事なのがURLとヘッダーの設定ですね。Difyでは
{{変数名}}という記法で、前のノードの変数を動的に挿入できます。テキトー教師たとえば「ユーザーが入力した都市名を使って天気APIを叩く」なら、URLを
https://api.example.com/weather?city={{start.city}}のように書けます。前のノードで取得した値を次のリクエストに使えるのがDifyのワークフローの強みですよね。室谷深いオブジェクトのアクセスもできるので、
{{api_response.data.items[0].id}}みたいな書き方で前のHTTPリクエストのレスポンスから特定の値だけを取り出すことも可能です。cURLからインポートして設定する方法
テキトー教師設定で詰まったときに超便利なのが「cURLからのインポート」機能です。画面右上に「cURLからのインポート」というボタンがあります。
室谷API開発者が「このAPIの使い方はこのcURLコマンドを実行してください」とドキュメントに書いていることが多いんですよ。それをそのままコピーしてDifyにペーストすると、URL・ヘッダー・ボディの設定が全部自動で入力されます。
テキトー教師手動でヘッダーを設定するのが難しいという受講生さんには必ずこの方法を教えています。ゼロから設定するより、cURLコマンドを起点にする方が圧倒的に設定ミスが減りますから。
# 天気APIのcURLコマンド例
curl -X GET "https://api.openweathermap.org/data/2.5/weather?q=Tokyo&appid=YOUR_API_KEY" \
-H "Accept: application/json"
このcURLをDifyのインポート欄に貼り付けると、GETメソッド・URLのセット・Accept: application/jsonのヘッダーが全部自動入力されます。あとはAPIキー部分を変数に差し替えるだけです。
ヘッダーとパラメータの設定
テキトー教師ヘッダーとパラメータの違いも確認しておきましょう。混乱しやすいポイントです。
室谷ヘッダーはリクエストの「メタ情報」を伝えるもの。一番よく使うのはContent-TypeとAuthorizationです。
パラメータはURLの後ろに
パラメータはURLの後ろに
?key=valueの形で付く情報ですね。テキトー教師APIキーの設定場所についてはよく聞かれます。整理すると：
- ヘッダーにAPIキーを入れる場合:
Authorization: Bearer {APIキー}またはX-API-Key: {APIキー} - パラメータにAPIキーを入れる場合: URLの後ろに
?api_key={APIキー} - Dify組み込みの認証機能を使う場合: APIキー認証でBasic/Bearer/Customを選択
室谷どの方法を使うかはAPIのドキュメントに依存するので、使いたいAPIのドキュメントを必ず確認してください。ここをミスると403エラーや認証エラーで詰まります・・・
ボディ（dify httpリクエスト body）の設定
テキトー教師dify httpリクエストのbodyについては、POSTリクエストでデータを送信するときに使います。ボディタイプは以下の4種類があります：
- JSON: 構造化データの送信（最も一般的）
- Form Data: 従来のWebフォーム形式
- Binary: ファイルのアップロード
- Raw Text: カスタムコンテンツタイプ
室谷実務でよく使うのはJSONですね。多くのAPIがJSON形式でのリクエストを受け付けています。
たとえばSlack Webhookに通知を送る場合なら：
たとえばSlack Webhookに通知を送る場合なら：
{
"text": "{{llm.output}}"
}
{{llm.output}}の部分に前のLLMノードの出力が入ります。こうやってLLMが生成したテキストをそのままSlackに送信するワークフローが簡単に作れます。室谷DifyのHTTPリクエストノードのJSONボディ設定で詰まりやすいのが変数の埋め込みです。
文字列型のフィールドには
{{変数名}}を文字列として"{{変数名}}"と書くか、そのまま{{変数名}}と書くかは、APIが期待する型によって変わります。文字列型のフィールドには
"{{変数名}}"、数値型のフィールドには{{変数名}}（ダブルクォートなし）と書く必要があります。DifyのHTTPリクエストの出力変数とレスポンスの扱い方
室谷HTTPリクエストを送信した後、レスポンスをどう扱うかが次のポイントです。「dify httpリクエスト 出力変数」や「dify httpリクエスト 出力」の設定で詰まる人が多いんですよね。
テキトー教師レスポンスは後続のノードで以下の変数として参照できます：
- body: レスポンスボディ（主なコンテンツ）
- status_code: HTTPステータスコード（200、404、500など）
- headers: レスポンスヘッダー（キーと値のペア）
- files: レスポンスにファイルが含まれる場合のファイル変数
室谷ステータスコードを使ってIf-Elseノードで「200なら次に進む、エラーなら別ルートに」という分岐処理が作れます。これで堅牢なワークフローが構築できます。
テキトー教師レスポンスのbodyがJSON形式の場合、次のノードでドット記法でアクセスできます。たとえばレスポンスが：
{
"weather": [{"description": "晴れ", "main": "Clear"}],
"main": {"temp": 20.5}
}
この場合、LLMノードのプロンプトに
{{http_request.body.main.temp}}と書くと、気温の20.5が取得できます。{{http_request.body.weather[0].description}}なら「晴れ」が取れます。テキトー教師ここがわかると、APIから取得した動的なデータをLLMに渡して「今日の東京の気温は{{temp}}度です。おすすめの服装を教えてください」みたいな使い方ができるようになります。
受講生さんも「この変数の書き方がわかった!」となる瞬間がこのあたりです。
受講生さんも「この変数の書き方がわかった!」となる瞬間がこのあたりです。
ナレッジとHTTPリクエストを組み合わせる（dify httpリクエスト ナレッジ）
室谷「dify httpリクエスト ナレッジ」の組み合わせも実用的なパターンです。ナレッジ（RAG）で社内文書から情報を取得して、HTTPリクエストで外部APIを叩いて最新情報を補完するという構成です。
テキトー教師具体的な例を挙げると、社内の製品情報をナレッジに登録しておいて、在庫状況はリアルタイムでAPIから取得するという構成が考えられます。ナレッジから「製品Aの仕様」を取得して、在庫管理APIに「製品AのIDで在庫照会」をかけるイメージですね。
室谷この組み合わせは特に法人向けのAI導入案件で実際に使うことが多いです。RAGだけでは「いつの情報か」問題があるので、動的なデータはAPIで補完するという設計が合理的なんですよね。
DifyのHTTPリクエストでのファイル送受信
室谷「dify httpリクエスト ファイル」の使い方も需要が高いですよね。画像やPDFをAPIに送りたいというケースが増えています。
テキトー教師ファイルのアップロードとダウンロード、両方ありますよね。まずアップロードから説明すると、ボディタイプで「Binary」を選んで、前のノードからのファイル変数を指定します。
室谷たとえばユーザーが画像をアップロードして、それをOCR APIや画像分析APIに送るというワークフローが作れます。「PUTリクエストのボディにバイナリのファイル変数を指定」という設定で送れます。
テキトー教師ファイルのダウンロードについては、Difyが自動でレスポンスの種類を判定してくれます。Content-Dispositionヘッダーを確認したり、MIMEタイプを解析したりして、テキストかバイナリかを自動判断するんです。
室谷バイナリと判断されたレスポンスは自動的にファイル変数として保存されます。後続のノードでそのファイルをさらに処理したり、別のAPIに送ったりできます。
これがシームレスに動くのはDifyの地味に便利なポイントです。
これがシームレスに動くのはDifyの地味に便利なポイントです。
テキトー教師Form Dataでのファイルアップロードも可能です。ボディタイプで「Form Data」を選んで、キーにファイル変数を指定するだけです。
複数ファイルの送信も対応しています。
複数ファイルの送信も対応しています。
DifyのHTTPリクエストの認証設定（dify httpリクエスト 認証）
室谷「dify httpリクエスト 認証」の設定、これが一番詰まるポイントですよね。外部サービスとのAPI連携を試みると必ずぶつかる壁です。
テキトー教師Difyが提供する認証タイプは以下の4種類です：
- No Auth: 認証なし（公開APIなど）
- API Key Basic: Basic認証（ベースエンコードされた認証情報）
- API Key Bearer: BearerトークンをAuthorizationヘッダーに追加
- API Key Custom: カスタムヘッダー名と値を自由に指定
室谷実務で一番よく使うのはBearerですね。
Authorization: Bearer {APIキー}というヘッダーを追加するパターンは多くのAPIで採用されています。テキトー教師認証情報を変数に入れるのがポイントです。APIキーをノードの設定に直書きするのではなく、「開始」ノードの変数として渡すか、Difyの環境変数機能を使うと管理しやすくなります。
室谷セキュリティ的にも、APIキーをワークフロー内にハードコードしない方がいいですよね。コードが流出したときのリスクがまったく違いますし・・・
テキトー教師企業向けのDify構築案件を手がけているコミュニティのメンバーさんも、APIキー管理は特に気をつけていると言っていました。DifyのDSLファイルをエクスポートしてシェアする際に、APIキーが含まれてしまわないよう注意が必要です。
DifyのHTTPリクエストのプロキシ設定（dify httpリクエスト プロキシ）
室谷「dify httpリクエスト proxy」「dify httpリクエスト プロキシ」という検索も多いんですよね。企業のイントラネット環境で使う場合や、特定のIPからのアクセスが必要な場合に出てくる話です。
テキトー教師プロキシの設定は、Dify本体のシステム設定（環境変数）で行います。HTTPリクエストノードの個別設定でプロキシを指定するUIはなく、Difyサーバー全体のHTTP_PROXYやHTTPS_PROXY環境変数で制御します。
室谷企業のファイアウォール内でDifyをセルフホスティングしていて、外部APIへのアクセスにプロキシが必要な場合は、DockerのCompose設定にプロキシの環境変数を追加します。
テキトー教師また、SSL検証の設定もあります。内部APIや自己署名証明書を使っているサービスにアクセスする場合、SSLの検証をスキップする
本番環境での無闇なSSL検証スキップは避けた方がいいですが、テスト環境や内部システムでは便利です。
ssl_verifyパラメータが使えます。本番環境での無闇なSSL検証スキップは避けた方がいいですが、テスト環境や内部システムでは便利です。
室谷開発段階でよくあるのが、ローカルのAPIサーバーにアクセスしたいケース。DockerコンテナからホストマシンのAPIにアクセスするには、URLを
http://host.docker.internal:3000/api/のように書きます。localhostでは繋がらないので注意が必要です。DifyのHTTPリクエストのタイムアウト設定
テキトー教師「dify httpリクエスト タイムアウト」の設定も重要です。外部APIとの通信では、レスポンスが遅かったり接続が失敗したりすることがあります。
室谷タイムアウトの設定は3種類あります：
- Connect timeout: 接続確立の最大待機時間
- Read timeout: レスポンスデータの読み込み最大待機時間
- Write timeout: リクエストデータの送信最大待機時間
テキトー教師画像生成APIや大量データを処理するAPIでは、Read timeoutを長めに設定する必要があります。タイムアウト値を大きくしすぎるとワークフロー全体のパフォーマンスに影響するので、APIの処理時間を見ながら調整しましょう。
室谷MYUUUで構築したシステムで「画像生成APIのタイムアウトで失敗が多発する」という問題が起きたことがあって・・・。Read timeoutを長めに設定したら解決しました。
APIの処理時間に合わせてタイムアウトを調整するのが大事ですね。
APIの処理時間に合わせてタイムアウトを調整するのが大事ですね。
テキトー教師タイムアウトエラーとリトライ機能を組み合わせるのが堅牢なワークフローのポイントです。タイムアウトが発生しても、リトライ設定で自動的に再試行できます。
DifyのHTTPリクエストのエラー処理とリトライ（dify httpリクエスト エラー）
室谷「dify httpリクエスト エラー」は、HTTPリクエストを使い始めた人が必ず一度はぶつかります。エラー別に対処法を整理しましょう。
テキトー教師よくあるエラーとその原因はこんな感じです：
| エラー | 原因 | 対処法 |
|---|---|---|
| 400 Bad Request | リクエスト形式が不正 | パラメータの型・必須項目を確認 |
| 401 Unauthorized | 認証情報が間違い | APIキーの設定を再確認 |
| 403 Forbidden | アクセス権限がない | プランや権限の確認 |
| 404 Not Found | URLが間違い | エンドポイントURLを再確認 |
| 405 Method Not Allowed | 使用したメソッドが許可されていない | 正しいHTTPメソッドを使う |
| 429 Too Many Requests | レート制限に達した | リクエスト頻度を下げる |
| 500 Internal Server Error | サーバー側のエラー | 時間をおいて再試行 |
室谷「dify httpリクエスト 403」はよく出るエラーですね。ヘッダーのAuthorization設定が間違っていたり、APIキーの権限が不足していたりするケースが多いです。
テキトー教師cURLコマンドでターミナルから同じリクエストを送ってみるのが一番の診断方法です。DifyのUI上では何が送られているか分かりにくいですが、cURLで確認すると問題が特定しやすくなります。
室谷あとよくあるのが文字コードの問題です。「dify httpリクエスト 文字化け」という悩みも多くて・・・。
日本語のテキストをボディに含める場合、Content-Typeに
日本語のテキストをボディに含める場合、Content-Typeに
charset=UTF-8を明示するか、APIのドキュメントで文字コードの指定方法を確認しましょう。リトライ機能で失敗を自動回復する
テキトー教師Difyのリトライ機能は、ネットワークエラーや一時的なサービス障害に対して自動で再試行してくれます。公式ドキュメントによると、設定できる最大リトライ回数は10回、最大リトライ間隔は5000msです。
室谷生産環境のワークフローでは、リトライを必ず設定することをおすすめしています。一時的なネットワーク不安定や外部サービスのレート制限で失敗したときに、自動回復できるかどうかで運用の安定性が大きく変わりますから。
テキトー教師さらに「エラーハンドリング」機能を使うと、HTTPリクエストが失敗したときに別のワークフローパスを実行できます。たとえば「APIが失敗したらデフォルトの返答をする」という分岐が簡単に作れます。
室谷これはビジネスロジックとして重要ですよね。外部APIに依存するワークフローを作るとき、「APIが落ちたらアプリ全体が止まる」という設計は避けたい。
エラーハンドリングで代替処理に切り替えられるようにしておくのが鉄則です。
エラーハンドリングで代替処理に切り替えられるようにしておくのが鉄則です。
DifyのHTTPリクエストの実践的なユースケース
室谷ここまで設定方法とエラー対処を見てきましたが、実際にどんなユースケースで使えるか、具体的な例も見ておきましょう。室谷のツイートにも書いたんですが、DifyのHTTPリクエスト、結局これが一番実用的なんですよね。
テキトー教師ですよね。コミュニティのメンバーさんが試している主なユースケースをまとめると：
ユースケース1：外部サービスへの通知・連携
室谷SlackやLINEへの通知はHTTPリクエストの定番ユースケースです。Webhook URLにPOSTリクエストを送るだけで、AIの処理結果を瞬時に通知できます。
テキトー教師具体的な設定は：
- URL: SlackのWebhook URL
- メソッド: POST
- ヘッダー: Content-Type: application/json
- ボディ（JSON）:
{"text": "{{llm.output}}"}
室谷これだけで「LLMが分析した結果をSlackに自動投稿」が実現します。MYUUUではDifyのワークフローをAPI化して、社内システムからトリガーする仕組みを複数のクライアント企業に導入しています。
ユースケース2：楽天APIとの連携
テキトー教師楽天Web Serviceとの連携も人気があります。商品検索APIを使って「ユーザーが入力したキーワードで楽天の商品を検索してAIが紹介する」というワークフローが作れます。
室谷楽天APIはキーパラメータをクエリパラメータで渡す方式なので、パラメータ設定に
applicationIdとkeywordを設定するだけで動きます。テキトー教師楽天以外にも、Amazon Product Advertising API、Yahoo! JAPANのAPIなど、多くの日本のサービスがAPIを公開しているので、組み合わせ次第でかなり実用的なアプリが作れます。
ユースケース3：Dify APIをバックエンドとして使う
室谷少し高度な話になりますが、DifyのワークフローをAPI化して、HTTPリクエストで別のDifyワークフローから呼び出すパターンもあります。ワークフローのモジュール化です。
テキトー教師「テキスト分析ワークフロー」を作っておいて、複数の別のワークフローからそれを呼び出すという設計ができます。同じロジックを複数のワークフローにコピーするより、メンテナンスがずっと楽になりますよね。
室谷これ、正直DifyのHTTPリクエストの中で最も価値が高い使い方だと思っています。Dify APIをラップして、バックエンドの一部として使うという発想は、開発スピードを爆上げしてくれますよ。
DifyのワークフローとHTTPリクエストの組み合わせ（dify ワークフロー httpリクエスト）
テキトー教師「dify ワークフロー httpリクエスト」という視点で、ワークフロー全体の設計も考えてみましょう。HTTPリクエストノードをどの位置に置くかで、ワークフローの性質が変わります。
室谷大きく分けると3つのパターンがあります。まず「事前取得型」。
ワークフローの最初にHTTPリクエストで外部データを取得して、その後のLLMに渡すパターンです。
ワークフローの最初にHTTPリクエストで外部データを取得して、その後のLLMに渡すパターンです。
テキトー教師次に「事後送信型」。LLMが生成した内容を最後にHTTPリクエストで外部サービスに送信するパターンです。
SlackやCRMへの記録などはこれが多いですね。
SlackやCRMへの記録などはこれが多いですね。
室谷もう一つが「中間処理型」。LLMで意図を解析して、その結果に基づいてAPIを叩いて、さらにLLMで整形するという複合的なパターンです。
AIエージェント的な処理ができます。
AIエージェント的な処理ができます。
テキトー教師この3パターンを意識すると、ワークフローの設計がスッキリします。「何を取得したいのか、何を送信したいのか、それはいつのタイミングか」を先に決めると、設定ミスが減りますね。
室谷ワークフロー設計で大事なのは「HTTPリクエストが失敗した場合の代替ルート」を最初から考えておくこと。If-Elseノードでステータスコードを確認して、200以外なら別ルートに流す設計を最初から入れておくのが実務レベルの設計です。
Dify HTTPリクエストのパラメータ設計のコツ
テキトー教師「dify httpリクエスト パラメータ」の設計について、実際にハマりやすいポイントをまとめておきましょう。
室谷パラメータ設計で一番詰まるのが「変数の型変換」です。Difyのノード間で渡される変数には型があって、文字列型の変数を数値型として渡そうとするとエラーになることがあります。
テキトー教師あとは「URLエンコード」の問題もあります。クエリパラメータに日本語を含める場合、自動でURLエンコードされないケースがあって、文字化けの原因になります。
室谷Difyのパラメータ欄を使うと、自動でURLエンコードしてくれます。URLに直接
?keyword={{キーワード}}と書くより、パラメータ欄にkeyword: {{キーワード}}と設定する方が安全です。テキトー教師もう一つ覚えておきたいのが「複数のAPIリクエストを並列実行する」というパターンです。Difyの並列処理機能と組み合わせると、複数のAPIを同時に叩いて結果を統合できます。
室谷並列HTTPリクエストは実行速度の改善に大きく効きます。3つのAPIを順次実行すると合計3秒かかるところを、並列実行なら1秒で済む。
MYUUUの案件でも並列化でレスポンス速度を大幅に改善したケースがあります。
MYUUUの案件でも並列化でレスポンス速度を大幅に改善したケースがあります。
DifyのHTTPリクエストノード設定チェックリスト
室谷最後に、HTTPリクエストの設定で詰まったときに確認すべきチェックリストをまとめておきます。これ、自分でもよく使います。
テキトー教師設定前の確認から動作確認まで、順番にやっていけば大体の問題は解決できるはずです：
設定前チェック
- 使いたいAPIの公式ドキュメントを確認したか
- 必要なAPIキーや認証情報を取得したか
- APIのレート制限（1分あたり何リクエストまで）を確認したか
- リクエストのサンプルcURLコマンドをメモしたか
設定時チェック
- HTTPメソッドはドキュメントの指定通りか
- URLにスペルミスがないか
- ヘッダーのキー名と値が正確か（大文字小文字に注意）
- ボディのJSONフォーマットが正しいか（波括弧・引用符の対応）
- 変数の参照が
{{変数名}}の形で正しいか
動作確認チェック
- まず変数なしの固定値でテスト実行したか
- レスポンスのステータスコードが200か
- レスポンスのbodyに期待したデータが入っているか
- 後続ノードでレスポンスの変数を正しく参照できているか
室谷「変数なしの固定値でテスト」というのは特に大事です。変数が絡むと問題の切り分けが難しくなるので、まずAPIが正常に動くことを固定値で確認してから変数に切り替えるというステップを踏むと、トラブルシューティングが格段に楽になります。
テキトー教師教える立場からすると、エラーで詰まる人の多くは「全部同時に設定して動かない」というパターンに陥っています。HTTPリクエストは「URLだけ → ヘッダー追加 → ボディ追加 → 変数に置き換え」という順番で段階的に確認すると、どこで問題が起きているかがわかりやすくなります。
よくある質問（FAQ）
室谷ここまでの解説を踏まえて、よくある質問をまとめておきましょう。
テキトー教師「dify httpリクエスト レスポンス」に関してよく聞かれるのが「レスポンスが大きすぎてエラーになる」という問題です。DifyではデフォルトでHTTPレスポンスの最大サイズに制限があります。
Docker環境で「Text size is too large, max size is 1.00 MB」というエラーが出た場合は、リクエストを分割するか、APIのレスポンスをフィルタリングして必要なデータだけを取得するようにします。
Docker環境で「Text size is too large, max size is 1.00 MB」というエラーが出た場合は、リクエストを分割するか、APIのレスポンスをフィルタリングして必要なデータだけを取得するようにします。
室谷「APIキーをヘッダーとパラメータのどちらに入れればいいか」という質問もよくあります。これはAPIのドキュメント次第ですが、セキュリティ的にはヘッダー（Authorization: Bearer）の方が推奨されます。
URLにAPIキーを含めると、ログやブラウザ履歴にキーが残ってしまうリスクがあります。
URLにAPIキーを含めると、ログやブラウザ履歴にキーが残ってしまうリスクがあります。
テキトー教師「HTTPリクエストでDify自身のAPIを叩けるか」という質問もあります。これは可能です。
DifyのAPIキーをHTTPリクエストのヘッダーに設定して、Difyのエンドポイントに対してリクエストを送ることでできます。ただし、再帰的なループが起きないよう注意が必要です。
DifyのAPIキーをHTTPリクエストのヘッダーに設定して、Difyのエンドポイントに対してリクエストを送ることでできます。ただし、再帰的なループが起きないよう注意が必要です。
室谷「無料版のDifyでHTTPリクエストは使えるか」という質問も多いですね。セルフホスト版のDifyは無料でフル機能が使えます。
クラウド版は利用可能ですが、プランによって実行回数に制限があります。最新のプラン情報はでご確認ください。
クラウド版は利用可能ですが、プランによって実行回数に制限があります。最新のプラン情報はでご確認ください。
まとめ
室谷今回はDifyのHTTPリクエストノードについて、基本設定から応用ユースケース、エラー対処まで一通り解説しました。改めて整理すると・・・
テキトー教師まとめると以下の通りです：
- HTTPリクエストノードを使えばDifyから外部APIに自由にアクセスできる
- GETはデータ取得、POSTはデータ送信が基本。APIドキュメントでメソッドを確認する
- cURLからのインポートで設定を自動化できる
- 変数は
{{変数名}}で参照、JSONレスポンスはドット記法でアクセスする - 認証はBearer認証が最もよく使われる
- 403エラーは認証設定を確認、タイムアウトはRead timeoutを調整
- リトライとエラーハンドリングを設定して堅牢なワークフローを構築する
室谷HTTPリクエストを使いこなせるようになると、Difyで作れるものの幅が劇的に広がります。「AIと外部サービスを繋ぐ接着剤」として、DifyのHTTPリクエストはその位置づけにふさわしい機能だと思っています。
テキトー教師.AI（ドットエーアイ）の講座でも「HTTPリクエストを理解した瞬間が一番盛り上がる」と感じています。ぜひ実際のAPIを使って試してみてください。
最初は天気APIや公開されている無料APIで動かしてみると、設定の感覚がつかみやすいです。
最初は天気APIや公開されている無料APIで動かしてみると、設定の感覚がつかみやすいです。
室谷次回はDifyのCode実行ノードとHTTPリクエストを組み合わせた高度なデータ処理についても扱っていきます。引き続きよろしくお願いします。