Contents
Dify の管理画面から API キーを取得する手順と注意点
Dify の API を n8n で利用する第一歩は 有効な API キー を取得し、安全に保管することです。キーが漏洩すると不正アクセスや課金リスクが発生しますので、取得から管理までの流れを公式ドキュメントに沿って解説します。本節では UI の実際の表示位置（2024 年版）と、権限設定・環境変数化のベストプラクティスを示します。
管理画面での取得フロー
管理画面左側メニューの 「Settings」 → 「API Access」 を開くと、現在登録されているキー一覧と新規作成ボタンが表示されます。
- 「Create new API key」 ボタンをクリック
- キー名（例：
n8n‑production）と有効期限（最低 90 日推奨）を入力 - 「Create」を押すと、キー文字列が一度だけ表示されます
重要：生成後は画面上で再表示できません。必ずコピーして安全な場所に保存してください。
権限（スコープ）設定と安全な保存方法
Dify の API キーには 「read」 と 「write」 の2つのスコープがあり、公式ドキュメントの API Scopes ページで詳細が確認できます[^1]。n8n からワークフロー実行やデータ更新を行う場合は write スコープも付与してください。
取得したキーは環境変数として管理するのが最も安全です。プロジェクトルートに .env ファイルを作成し、以下のように記述します。
|
1 2 3 |
# .env（Git 管理から除外すること） DIFY_API_KEY=sk-xxxxxxxxxxxxxxxxxxxx |
.env の管理ポイント
| 項目 | 推奨設定 |
|---|---|
| ファイル名 | .env （プロジェクト直下） |
| Git 除外 | リポジトリの .gitignore に /.env を追加 |
| アクセス権限 | サーバー上は 600（所有者のみ読み取り）に設定 |
| 秘密情報の共有 | CI/CD のシークレットストアや HashiCorp Vault 等を利用 |
.env ファイルがリポジトリに含まれないよう 必ず .gitignore に記載し、チームメンバーと共有する際は安全な手段（例：1Password Teams）で渡すようにしましょう。
キーローテーションのベストプラクティス
- 有効期限が近づいたら 新規キーを発行 → 旧キーを無効化 のサイクルを自動化する
- n8n 側は環境変数
DIFY_API_KEYを参照しているため、.envを更新すれば即座に全フローが新鍵へ切り替わります
n8n の HTTP Request ノードで Dify API を呼び出す設定方法
n8n には Dify 用の専用ノードはありませんが、汎用 HTTP Request ノードを使って REST API にアクセスできます。本節ではエンドポイント・認証ヘッダー・リクエストボディの作り方を公式情報に基づき解説します。
エンドポイントとメソッド
Dify のベース URL と各エンドポイントは公式 API Reference に記載されています[^2]。ワークフロー実行は次のパスへ POST でリクエストします。
|
1 2 |
https://api.dify.ai/v1/workflows/{workflow_id}/run |
| 項目 | 設定例 |
|---|---|
| URL | https://api.dify.ai/v1/workflows/{{ $env.DIFY_WORKFLOW_ID }}/run |
| Method | POST |
| Authentication | None（ヘッダーで Bearer トークン） |
| Content-Type | application/json |
認証ヘッダーの構成（Bearer トークン）
認証は Authorization: Bearer <APIキー> ヘッダーで行います。キーを直接ノードに書くとコードベースに残ってしまうため、環境変数 から参照させます。
| Header | Value |
|---|---|
| Authorization | Bearer {{ $env.DIFY_API_KEY }} |
| Content-Type | application/json |
n8n の Credentials タブで「Environment Variable」タイプを作成し、上記ヘッダーに変数名だけを書き込む方法でも同等の安全性が保てます。
リクエストボディ例とテンプレート変数
ワークフロー実行時は入力パラメータを JSON で渡します。以下はテキスト要約用ワークフローに対するサンプルです（{{ $json.email_body }} は前段のメール取得ノードから受け取った本文）。
|
1 2 3 4 5 6 7 8 9 10 |
{ "inputs": { "text": "{{ $json.email_body }}", "language": "ja" }, "options": { "stream": false } } |
HTTP Request ノードの Body 設定は JSON (application/json) を選択し、上記 JSON をテンプレート文字列として貼り付けます。変数展開は n8n の Expression 機構（{{ }}）で行われるため、動的に値が置換されます。
ポイント：ヘッダー・ボディともに環境変数やフロー内変数を利用すれば、コードベースに機密情報が残らない安全な設計になります。
Dify 側で Webhook エンドポイントを作成し、n8n と双方向連携する手順
Dify の処理結果やイベント通知をリアルタイムで n8n に送るには Webhook 機能を有効化します。本節では設定画面の操作手順と、n8n 側の受信ノード構成を具体的に示します。
Dify の Webhook 設定画面
左サイドバーの 「Integrations」 → 「Webhooks」 を開くと、既存Webhook一覧と 「Create new webhook」 ボタンが表示されます。以下の項目を入力してください（公式手順は Webhook Guide に掲載[^3]）。
- Name：例
n8n_incoming - URL：後述する n8n の Webhook URL を貼り付ける
- Authentication：
Bearer Tokenを選択し、先ほど作成した API キーと同一のトークンを入力 - Events：必要なイベント（例
workflow_completed）にチェック
保存後、Dify が生成する Endpoint URL が画面に表示されます。これが n8n 側へ通知される先です。
n8n の Webhook ノード設定と URL 取得
n8n エディタで新規フローを作成し、左パネルから Webhook ノードをドラッグします。
| 項目 | 設定例 |
|---|---|
| HTTP Method | POST |
| Path | dify/webhook（任意） |
| Response Mode | On Received（即時 200 応答） |
| Authentication | None（Dify 側で Bearer 認証済み） |
ノードを保存すると Webhook URL が自動生成されます。例：
|
1 2 |
https://your-n8n-instance.com/webhook/dify/webhook |
この URL を Dify の Webhook 設定画面（手順 2）の URL フィールドに貼り付けます。
受信ペイロードの検証と分岐例
テスト送信ボタンを Dify 側で実行すると、n8n の Execution Log に以下のような JSON が表示されます（公式サンプルは Webhook Payload に記載[^4]）。
|
1 2 3 4 5 6 7 8 9 |
{ "event": "workflow_completed", "workflow_id": "123e4567-e89b-12d3-a456-426614174000", "result": { "summary": "本日の売上は..." }, "timestamp": "2026-06-24T08:15:30Z" } |
n8n の IF ノードで event === 'workflow_completed' を判定し、成功時は Slack 通知やデータベース保存へ分岐させます。失敗イベント（例 workflow_failed）は別途エラーハンドリングフローに回すと運用が楽になります。
ポイント：Webhook の認証方式を Dify と同一の Bearer Token に統一すると、シークレット管理が一本化できてミスが減ります。
API 呼び出し結果の確認・エラーハンドリング・リトライ設定
自動化フローの信頼性は レスポンスの正確な判定 と 適切な再試行 に依存します。本節では成功・エラー時にチェックすべきフィールドと、n8n の Try / Catch 構造によるハンドリング方法を解説します。
成功レスポンスとチェックポイント
Dify が 200 系ステータスで返す典型的な JSON は次の通りです（公式リファレンス参照[^5]）。
|
1 2 3 4 5 6 7 8 |
{ "status": "success", "data": { "output_text": "...要約結果..." }, "request_id": "req_abcdef123456" } |
| チェック項目 | 内容 |
|---|---|
status |
"success" かどうか |
data.output_text |
空文字でないことを確認 |
request_id |
ログに残してトラブル時に追跡可能 |
エラー構造と対処方法
エラー時は 4xx/5xx と共に以下のようなペイロードが返ります。エラーコード一覧は Error Codes ページに掲載されています[^6]。
|
1 2 3 4 5 6 |
{ "status": "error", "error_code": "INVALID_INPUT", "message": "入力テキストが空です。" } |
対処の基本は error_code に応じた分岐です。たとえば RATE_LIMIT_EXCEEDED はリトライ待機時間を伸ばすべきシグナルになります。
n8n での Try / Catch とリトライ設定
- HTTP Request ノードを Try ブロックに配置
- 同ブロック内で
{{ $json.status }}が"error"の場合は Catch フローへ遷移させる（IF ノードで判定） - Catch 内で Slack や Email にエラーメッセージを送信
リトライは HTTP Request ノードの Options から設定できます。
| パラメータ | 推奨値 |
|---|---|
| Retry On Failure | 有効 |
| Max Attempts | 3 |
| Backoff Strategy | Exponential (2, 4, 8 秒) |
Additional Delay on RATE_LIMIT_EXCEEDED |
30 秒以上 |
この設定により、一時的なネットワーク障害やレートリミット超過でも自動的に再試行され、フロー全体の耐障害性が向上します。
ポイント：HTTP ステータスだけで成功判定せず、レスポンスボディの
statusフィールドも必ず確認してください。
実務向けサンプルワークフローとテスト手順
以下に業務ですぐに使える 3 つの典型的なフロー と、それぞれのテスト方法を示します。全ては n8n のテンプレートとしてエクスポート可能です。
サンプル①：定期実行で要約取得
毎日決まった時刻に Dify の要約ワークフローを呼び出し、結果を Slack に投稿するシナリオです。
| ノード | 主な設定 |
|---|---|
| Cron | 09:00 (UTC+9) 毎日実行 |
| HTTP Request (Dify) | 前述のエンドポイントに POST、{{ $env.SUMMARY_WORKFLOW_ID }} を使用 |
| Set | summary フィールドに {{$json.data.output_text}} を格納 |
| Slack (Send Message) | チャンネル #ai-summary に {{ $node["Set"].json.summary }} を送信 |
HTTP Request のコードスニペット
|
1 2 3 4 5 6 7 8 9 10 11 12 |
{ "url": "https://api.dify.ai/v1/workflows/{{ $env.SUMMARY_WORKFLOW_ID }}/run", "method": "POST", "headers": { "Authorization": "Bearer {{ $env.DIFY_API_KEY }}", "Content-Type": "application/json" }, "body": { "inputs": { "text": "本日の売上データを要約してください。" } } } |
サンプル②：メール受信 → 要約 → Slack 通知
- IMAP Email ノードで新着メール取得
- Set ノードで本文 (
email_body) を抽出 - HTTP Request (Dify) で要約ワークフロー実行
- Slack に要約結果を投稿
この構成は顧客からの問い合わせメールを自動的に要約し、担当者へ即時共有したいシーンに有効です。
サンプル③：スプレッドシート更新 → 正規化 → CRM 送信
| ノード | 役割 |
|---|---|
| Google Sheets (Watch) | 行追加を検知 |
| HTTP Request (Dify) | データ正規化ワークフローへ POST |
| HTTP Request (CRM API) | 正規化結果を外部 CRM に送信 |
| IF / Error Handling | 失敗時はメールで担当者に通知 |
Dify 呼び出し例（正規化）
|
1 2 3 4 5 6 7 8 9 10 11 12 |
{ "url": "https://api.dify.ai/v1/workflows/{{ $env.NORMALIZE_WORKFLOW_ID }}/run", "method": "POST", "headers": { "Authorization": "Bearer {{ $env.DIFY_API_KEY }}", "Content-Type": "application/json" }, "body": { "inputs": { "record": "{{ $json.newRow }}" } } } |
Postman コレクションで事前検証する方法
公式サイトから Postman Collection をダウンロードできるので、実装前に API の挙動を確認すると安心です（手順は Developer Resources に記載[^7]）。
- Dify 管理画面 → 「Developers」→「API Collection Download」
- Postman にインポートし、環境変数
DIFY_API_KEYとWORKFLOW_IDを設定 - 各リクエストを実行して 200 応答と期待通りの JSON 構造を確認
n8n 側でも Run Once ボタンでデバッグでき、Execution Log にリクエスト/レスポンスが詳細に出力されます。Postman と n8n の両方でテストし、エラーハンドリングとリトライ設定が期待通り機能することを必ず検証してください。
まとめ：API キーは環境変数化・
.env管理で安全に保管し、Dify と n8n の双方向連携は公式エンドポイントと Webhook を組み合わせるだけで実装可能です。上記サンプルをベースに自社の業務フローへカスタマイズすれば、AI 活用の自動化がスムーズに進むでしょう。
参考リンク
[^1]: Dify API Scopes – https://docs.dify.ai/reference/scopes
[^2]: Dify API Reference – https://docs.dify.ai/api-reference
[^3]: Webhook Guide – https://docs.dify.ai/webhooks/guide
[^4]: Webhook Payload Specification – https://docs.dify.ai/webhooks/payload
[^5]: Success Response Format – https://docs.dify.ai/api-response#success
[^6]: Error Codes List – https://docs.dify.ai/api-response#error-codes
[^7]: Developer Resources – https://docs.dify.ai/developers/resources