Dify APIとは?ワークフローをバックエンドAPIとして使える仕組み
室谷今回はDify APIの使い方を深掘りしていきましょう。これ、.AI(ドットエーアイ)コミュニティでも毎週のように質問が来るテーマなんですよね。
「DifyってUIから使うだけじゃないの?」って思ってる人が多くて・・・
「DifyってUIから使うだけじゃないの?」って思ってる人が多くて・・・
テキトー教師そうなんですよ。講座でも初日に必ず聞かれます。
「Difyって結局GUIツールなんですよね?」って。コミュニティのメンバーさんでもAPI連携に踏み込んでいる人はまだ少ない印象があります。
「Difyって結局GUIツールなんですよね?」って。コミュニティのメンバーさんでもAPI連携に踏み込んでいる人はまだ少ない印象があります。
室谷実はDifyのAPIをバックエンドで使う手法、マジでおすすめなんですよ。MYUUUでもLang GraphにDify APIをぶら下げて使ってます。
例えば求人メディアをやってる会社にバックエンドでDifyを使うことを推奨したら、3日くらいでAI履歴書機能を実装できた事例がありますw
例えば求人メディアをやってる会社にバックエンドでDifyを使うことを推奨したら、3日くらいでAI履歴書機能を実装できた事例がありますw
テキトー教師その事例、講座でも紹介させてもらってるんですが、毎回反応がいいんですよ。「え、3日で?」って(笑)。
要するにDifyのワークフローをAPI化することで、フロントエンドの開発者がAIのロジックを書かなくていいんですよね。
要するにDifyのワークフローをAPI化することで、フロントエンドの開発者がAIのロジックを書かなくていいんですよね。
室谷そこが本質で、「AIのロジックをDifyで管理して、システム側からはAPIで叩く」という分業が成立するんです。非エンジニアがワークフローを修正しても、エンドポイントは変わらないのでシステム側は一切触らなくていい。
テキトー教師その構造をまず理解してもらうのが大事ですね。Difyが提供するAPIは大きく2種類あります。
| APIの種類 | 用途 | 主なエンドポイント |
|---|---|---|
| アプリケーションAPI | ワークフロー・チャットボット等を外部から呼び出す | /v1/workflows/run、/v1/chat-messages |
| ナレッジAPI | ナレッジベースをプログラムから操作する | /v1/datasets、/v1/documents |
室谷ほとんどのケースで使うのは「アプリケーションAPI」の方ですね。ワークフローをAPI化して、自社サービスに組み込む、というパターン。

DifyをBaaS(Backend as a Service)として使うという発想
テキトー教師公式ドキュメントにも「Backend-as-a-Service API」という表現が使われてるんですよね。これは面白い発想で。
室谷バックエンドをそのままサービスとして使う、という意味ですよね。一般的なBaaSといえばFirebaseが有名ですが、DifyはAI部分のBaaSとして機能する。
AI処理のインフラを自前で構築せずに、DifyをAIバックエンドとして使えるんです。
AI処理のインフラを自前で構築せずに、DifyをAIバックエンドとして使えるんです。
テキトー教師公式ドキュメントによると、DifyのAPIを使う主なメリットはこういう構造です。
- バックエンドの複雑さをスキップ:AIインフラストラクチャを管理することなく、大規模言語モデル機能にアクセスできる
- ビジュアルアプリ管理:AIの動作を視覚的に設計・更新でき、変更は全てのAPIコンシューマーに即座に反映される
- プロバイダーの柔軟性:コード変更なしでAIプロバイダーを切り替え、APIキーを一元管理できる
- 組み込み監視機能:ログ、分析、ユーザーアクティビティ追跡が標準で利用できる
室谷特に「プロバイダーの柔軟性」は経営的に重要ですよね。今日はあるモデルを使っていても、明日別のモデルに切り替えたいとなったとき、Dify側でモデルを変更するだけで済む。
コードを一切変えなくていい。
コードを一切変えなくていい。
APIキーの取得と基本設定

テキトー教師では実際の使い方に入りましょう。まずAPIキーの取得から説明しますが、ここで混乱する人が多いんです。
室谷「APIキー」が2種類存在するんですよね。これが初心者の人にはわかりにくい。
テキトー教師そうなんです。整理すると、Difyには2つの異なる「APIキー」があります。
- モデルプロバイダーのAPIキー(例:OpenAI APIキー、Gemini APIキー):DifyがLLMを呼び出すために必要。Difyの設定画面で入力する。
- DifyアプリのAPIキー(Service API Key):外部システムからDifyアプリを呼び出すために必要。アプリごとに発行する。
室谷この2つを混同しているケースがめちゃくちゃ多いんですよね・・・
テキトー教師まず前提として、Difyでワークフローを動かすには①のモデルプロバイダーのAPIキーが設定済みである必要があります。その上で、外部からDifyを呼び出すには②のDifyアプリのAPIキーを使います。

モデルプロバイダーのAPIキー設定
室谷①の設定方法ですが、Difyの「設定」→「モデルプロバイダー」から各LLMのAPIキーを登録します。OpenAI、Anthropic、Google(Gemini)、Azure OpenAIなど多数のプロバイダーに対応しています。
テキトー教師クラウド版(dify.ai)を使う場合は、無料のSandboxプランでも試せます。ただしSandboxは月200メッセージクレジットという制限があるので、本番利用にはProfessionalプラン(月$59)以上を検討してください。
室谷セルフホスト版(Community Edition)の場合は、DockerでDifyを自前サーバーに立てる形になります。この場合はDify本体の利用制限がないので、LLMのAPI料金のみで運用できます。
DifyアプリのAPIキー(Service API Key)の発行

テキトー教師外部からDifyを呼び出す「DifyアプリのAPIキー」の取得方法を説明しますね。公式ドキュメントによると、こういう手順です。
- Dify上でアプリ(ワークフロー・チャットフロー等)を作成・公開する
- アプリの左サイドバーから「API Access」に移動する
- 「APIシークレットキー」を新規作成する
- 発行されたキーをコピーして安全な場所に保管する
室谷キーが流出した場合は即座に再発行して既存のキーを無効化できるので、万が一の時も対応できます。
テキトー教師セキュリティのベストプラクティスとして、本番・ステージング・開発環境で別々のAPIキーを作成することを公式でも推奨しています。同一アプリに複数のキーを作成できるので、環境ごとに管理できます。
室谷注意点として、APIキーはフロントエンドのコードに直接書かないこと。必ずバックエンド側に置いて、環境変数で管理するのが鉄則ですね。
チャットフローのAPI呼び出し方法
テキトー教師では実際のAPI呼び出し方法を見ていきましょう。まずチャットフロー(対話型アプリ)からです。
室谷チャットフローは会話の継続性が特徴なんですよね。APIでも
conversation_idを使って会話セッションを維持します。
テキトー教師公式ドキュメントのサンプルを見てみましょう。チャットメッセージの送信は
/v1/chat-messagesエンドポイントにPOSTリクエストを送ります。curl --location --request POST 'https://api.dify.ai/v1/chat-messages' \
--header 'Authorization: Bearer {YOUR_API_KEY}' \
--header 'Content-Type: application/json' \
--data-raw '{
"inputs": {},
"query": "こんにちは、今日のニュースを教えてください",
"response_mode": "blocking",
"conversation_id": "",
"user": "user-001"
}'
室谷response_modeが重要ですね。streamingとblockingの2つがあって、streamingにするとタイプライターのようにレスポンスが流れてきます。チャットUIを作るなら
streamingの方が体験がいいです。
テキトー教師最初の呼び出し時は
conversation_idを空にします。するとレスポンスに新しいconversation_idが返ってくるので、その後の会話継続にはそのIDを使います。conversation_idの管理ポイント
室谷conversation_idの扱いは少し注意が必要で・・・
テキトー教師そうですね。公式ドキュメントによると、重要な点が3つあります。
- 新しい会話を開始するときは
conversation_idを空にする(システムが自動生成して返す) - 既存の会話を継続するときは、前の呼び出しで返ってきた
conversation_idを含める - セッション中に変数を変更したい場合は「会話変数」を使って動的に調整できる
室谷一点注意があって、WebアプリとAPIの会話は共有されません。DifyのWebアプリUIで作った会話と、APIで作った会話は完全に別管理になっています。
テキトー教師そこを知らずに「WebアプリでテストしたらOKだったのに、APIで取れない」という問い合わせが来ることがあります(笑)。
ワークフローのAPI化と外部システムへの組み込み

室谷ここが一番実用的な部分ですね。Difyのワークフローを実行するAPIエンドポイントは
/v1/workflows/runです。
テキトー教師ワークフローとチャットフローはエンドポイントが違うので整理しておきましょう。
| アプリタイプ | エンドポイント | 用途 |
|---|---|---|
| ワークフロー | POST /v1/workflows/run | 単発タスクの実行 |
| チャットフロー | POST /v1/chat-messages | 会話型AIとの対話 |
| テキスト生成 | POST /v1/completion-messages | テキスト生成タスク |
室谷ワークフローAPIの基本的な呼び出し方はこんな感じです。
curl --location --request POST 'https://api.dify.ai/v1/workflows/run' \
--header 'Authorization: Bearer {YOUR_API_KEY}' \
--header 'Content-Type: application/json' \
--data-raw '{
"inputs": {
"URL": "https://example.com/article",
"count": 120
},
"response_mode": "blocking",
"user": "user-001"
}'
テキトー教師inputsの中身は、ワークフローの開始ノードで設定した入力変数に合わせて変えます。変数を設定していない場合は空オブジェクト{}を渡します。
室谷レスポンスが返ってきたら、
data.outputsの中にワークフローの出力が入っています。どのキーで出力されるかはワークフローの設計によりますが、終了ノードで設定した出力変数名がそのままキーになります。streaming モードでのリアルタイム出力
テキトー教師response_mode: "streaming"にした場合は、Server-Sent Events(SSE)でレスポンスが流れてきます。
室谷サーバーから順次データが届く形式ですね。長い文章生成や複雑なワークフローで、処理の進行状況をリアルタイムに見せたいときに使います。
テキトー教師blockingの方が実装はシンプルなので、まずはblockingで試して、UX的に必要になったらstreamingに切り替える、という進め方がおすすめです。Pythonでの実装例
テキトー教師次はPythonでの実装例です。
requestsライブラリを使った基本パターンを見てみましょう。
室谷Pythonからワークフローを呼び出す場合はこんな感じになります。
import requests
import os
def run_dify_workflow(inputs: dict, user: str = "default-user"):
api_key = os.environ.get("DIFY_API_KEY")
base_url = os.environ.get("DIFY_BASE_URL", "https://api.dify.ai")
url = f"{base_url}/v1/workflows/run"
headers = {
"Authorization": f"Bearer {api_key}",
"Content-Type": "application/json"
}
payload = {
"inputs": inputs,
"response_mode": "blocking",
"user": user
}
response = requests.post(url, headers=headers, json=payload)
if response.status_code == 200:
result = response.json()
return result["data"]["outputs"]
else:
raise Exception(f"Error {response.status_code}: {response.text}")
# 使用例
outputs = run_dify_workflow(
inputs={"topic": "AI活用事例", "language": "ja"},
user="user-001"
)
print(outputs)
テキトー教師セキュリティの観点から、APIキーはコードに直書きせず環境変数から読み込む形が基本です。
os.environ.get("DIFY_API_KEY")がその書き方ですね。
室谷実運用だと
.envファイルか、クラウド環境のシークレットマネージャーで管理します。セルフホスト版の場合はエンドポイントが変わるので、DIFY_BASE_URLも環境変数で持っておくと環境切り替えが楽です。GASやn8nとの連携パターン
室谷実際のビジネス現場でよく使われる連携パターンも見ていきましょう。GAS(Google Apps Script)との組み合わせは特に人気ですよね。
テキトー教師コミュニティのメンバーさんでもGAS × Difyはかなり多い組み合わせです。スプレッドシートからDifyを呼び出して、大量データをAI処理するとか。
Google Apps Script(GAS)との連携
室谷GASからワークフローAPIを呼び出す基本パターンです。
function runDifyWorkflow() {
const API_KEY = PropertiesService.getScriptProperties()
.getProperty("DIFY_API_KEY");
const headers = {
"Authorization": "Bearer " + API_KEY,
"Content-Type": "application/json"
};
const payload = {
"inputs": {
"URL": "https://example.com/article",
"count": 120
},
"response_mode": "blocking",
"user": "gas-user"
};
const options = {
"method": "post",
"payload": JSON.stringify(payload),
"headers": headers,
"muteHttpExceptions": true
};
const response = UrlFetchApp.fetch(
"https://api.dify.ai/v1/workflows/run",
options
);
if (response.getResponseCode() === 200) {
const result = JSON.parse(response.getContentText());
Logger.log(result.data.outputs);
} else {
Logger.log("Error: " + response.getContentText());
}
}
テキトー教師GASのプロパティストア(ScriptProperties)にAPIキーを保存するのがポイントです。コードにそのまま書くと流出リスクがあるので、必ずプロパティストアに入れてください。
室谷muteHttpExceptions: trueを設定しておくと、APIエラーが発生しても例外が投げられずにレスポンスとして受け取れるので、デバッグがしやすくなります。n8nとの連携
テキトー教師n8nとの連携は「HTTP Requestノード」を使います。ノーコードで設定できるので、非エンジニアでも組めます。
室谷n8nの設定はシンプルで、HTTP RequestノードにDifyのエンドポイントURL、Bearerトークン認証、リクエストボディ(JSON)を設定するだけ。n8nのワークフローからDifyのワークフローを呼び出す構成になります。
テキトー教師n8n側でエラーハンドリングやリトライ処理も組めるので、本番運用に向いた形で構成できます。
ナレッジAPI(Knowledge API)の使い方
室谷もう一つの重要なAPIがナレッジAPIです。これを使うと、Difyのナレッジベースをプログラムから操作できます。
テキトー教師ナレッジAPIの主な用途は何でしょうか?
室谷大きく3つのパターンがあります。
- 自動更新:社内システムのデータが更新されたら、自動でナレッジベースも更新する
- バッチ登録:大量のドキュメントをまとめてナレッジベースに追加する
- 外部ナレッジベースとの連携:既存の社内DBをDifyから使う
テキトー教師講座でよく聞かれるのが「毎日更新される社内資料をDifyのナレッジベースに自動同期したい」というケースです。ナレッジAPIで解決できます。
ナレッジAPIのエンドポイント
室谷ナレッジAPIのAPIキーは、アプリのAPIキーとは別に発行します。Difyの「ナレッジ」タブから「APIアクセス」を開くと、Knowledge APIキーを取得できます。
テキトー教師主要なエンドポイントを整理するとこうなります。
| 操作 | エンドポイント | 説明 |
|---|---|---|
| データセット一覧取得 | GET /v1/datasets | ナレッジベースの一覧を取得 |
| ドキュメント追加 | POST /v1/datasets/{id}/documents | テキストドキュメントを追加 |
| ドキュメント一覧 | GET /v1/datasets/{id}/documents | ドキュメント一覧を取得 |
| セグメント追加 | POST /v1/datasets/{id}/documents/{doc_id}/segments | チャンク単位でデータを追加 |
| ドキュメント削除 | DELETE /v1/datasets/{id}/documents/{doc_id} | ドキュメントを削除 |
室谷ドキュメントをまるごと追加するより、セグメント(チャンク)単位で追加する方が細かい制御ができます。例えばQAペアを1問1答ずつ追加する場合はセグメントAPIが便利です。
エラーハンドリングとセキュリティのベストプラクティス
テキトー教師実運用で必ず直面するのがエラー処理です。Dify APIのエラーコードを把握しておくと対処が早くなります。
室谷バージョンアップ時にエラーが増えるのはDifyの課題で・・・。API経由でDifyを使っている場合、バージョンを上げるときは特に注意が必要なんですよね。
| ステータスコード | 意味 | 対処法 |
|---|---|---|
| 400 | リクエストパラメータが不正 | inputsの形式や必須項目を確認 |
| 401 | 認証エラー | APIキーを確認・再発行 |
| 404 | アプリが見つからない | アプリIDとエンドポイントを確認 |
| 500 | Dify内部エラー | エラーメッセージを確認、Difyのログを確認 |
| 503 | サービス一時停止 | しばらく待ってリトライ |
テキトー教師400エラーは
invalid_param(パラメータ不正)、provider_quota_exceeded(クォータ超過)、model_currently_not_support(モデル利用不可)など細分化されています。エラーレスポンスのメッセージを読むと原因が特定しやすいです。
室谷実際にDify APIをバックエンドで使っているときに一番困るのが、Difyのバージョンアップ後のエラーです。本番環境ではすぐに最新版に上げず、ステージング環境でテストしてから更新するのが安全な運用です。
セキュリティのベストプラクティス
テキトー教師セキュリティについても整理しておきましょう。公式ドキュメントが推奨しているプラクティスです。
- APIキーは必ずバックエンド側に置く(フロントエンドのコードに書かない)
- 環境変数でAPIキーを管理する
- 本番・ステージング・開発環境で別々のAPIキーを使用する
- 定期的にAPIキーをローテーションする
- API使用量を監視して異常なアクティビティを検出する
室谷フロントエンドに直書きするケースが初心者の方に多いんですよ。それをやるとブラウザの開発者ツールからAPIキーが丸見えになってしまう。
必ずバックエンド経由で呼び出す構成にしてほしいです。
必ずバックエンド経由で呼び出す構成にしてほしいです。
よくある質問(FAQ)
DifyのAPIは無料で使えますか?
室谷Dify自体のAPIは無料Sandboxプランでも使えます。ただし月200メッセージクレジットという上限があります。
テキトー教師クレジットはDifyが内部で用意しているモデルを使う場合に消費されます。自前のAPIキー(例:OpenAI APIキー)を設定してそちらのモデルを使う場合は、Difyのクレジットは消費されません。
その代わりモデルプロバイダー側の料金がかかります。
その代わりモデルプロバイダー側の料金がかかります。
セルフホスト版とクラウド版でAPIの使い方は変わりますか?
室谷エンドポイントのベースURLが変わるだけで、APIの仕様は同じです。クラウド版は
https://api.dify.ai、セルフホスト版は自分のサーバーのURLになります。
テキトー教師セルフホスト版のDockerイメージは
langgenius/dify-apiとして配布されています。にセルフホストのための手順が詳しく書かれています。Difyのワークフローを別のワークフローから呼び出せますか?
テキトー教師Dify内でワークフローをサブワークフローとして呼び出す方法と、外部からAPIで呼び出す方法の2つがあります。
室谷複雑なAIシステムを作るときは、機能ごとにワークフローを分けてAPIで組み合わせる設計が有効です。メンテナンス性が上がります。
streaming モードのレスポンスはどう処理しますか?
室谷streamingモードはSSE(Server-Sent Events)でイベントが流れてきます。各イベントに
eventフィールドがあり、message(テキスト生成中)、message_end(完了)、error(エラー)などのタイプを区別して処理します。
テキトー教師Pythonなら
requestsのstream=Trueオプションを使って順次読み取ります。Node.jsならeventsourceライブラリが便利です。まとめ
室谷Dify APIの使い方、一通り網羅できましたね。大事なポイントをまとめると・・・
テキトー教師まとめるとこういう構造です。
- Dify APIには「アプリケーションAPI」と「ナレッジAPI」の2種類がある
- アプリケーションAPIのエンドポイントはアプリタイプによって異なる(ワークフロー:
/v1/workflows/run、チャット:/v1/chat-messages) - APIキーはモデルプロバイダーのキーとDifyアプリのAPIキーの2種類がある
- セキュリティのため、APIキーは必ずバックエンド側で環境変数として管理する
- GASやPythonからも簡単に呼び出せる
室谷「DifyをBaaSとして使う」という発想が重要で、AIのロジックはDifyで管理してシステムからはAPIで叩く、という分業ができると開発スピードが大幅に上がります。これ、ビジネス的にめちゃくちゃ価値がある。
テキトー教師最初は
blockingモードでシンプルに実装して、動作確認ができてからstreamingやエラーハンドリングを追加していく、という進め方がスムーズです。ぜひ試してみてください。