第11章 ツール・プラグイン・API連携

この章では、Difyのアプリを外部のサービス・システムとつなぐ方法を説明します。つなぎ方は、方向で見ると次の2つに分かれます。

• Difyから外部を呼ぶ：ツール・プラグインで機能を追加して呼び出す（11-1・11-2）。ワークフローから外部の窓口（API）を直接呼び出す（11-3）。
• 外部からDifyが呼ばれる：作ったアプリをAPIとして公開し、外部のシステムから実行してもらう（11-4）。

この章で扱わない内容は、次の章で説明します。

• ノードをキャンバスに置く・線でつなぐ操作の詳細は第7章で説明します。
• ツール以外の各ノードの仕様は第10章で説明します。
• エラーが出たときの切り分けと対処は第14章で説明します。

なお、この章の機能の多くは、Difyから外部のサービスへ、または外部のシステムからDifyへ、ネットワーク接続できることが前提です。庁内ネットワークから外部に接続できるかは環境によります。 インターネットに直接つながらない環境（閉域網など）では使えない機能があるため、着手する前に情報担当部署へ確認してください。

図11-1　外部との連携は「呼ぶ」と「呼ばれる」の2方向（左＝ツール・HTTPリクエストで外部を呼ぶ、右＝APIとして外部から呼ばれる）

11-1. ツールとは

ツール（アプリから呼び出す外部機能）は、AIモデルだけではできないことをアプリに任せるための部品です。たとえばWeb検索で最新の情報を調べる、外部サービスのデータを取ってくる、といった処理は、AIモデル単体ではできず、ツールを呼び出して行います。

序章0-4のとおり、ノードがキャンバスに直接置く「処理の流れを作る部品」であるのに対し、ツールは「ノードやエージェントの中から呼び出す機能」です。この節では、ツールの種類と、ワークフローの中でツールを使う流れを説明します。

ツールの種類

公式ドキュメントでは、ツールを次の4種類に分けています。種類の名前は公式ドキュメント（英語版）の表記で、日本語画面での表記は環境・バージョンにより異なることがあります。

本書で主に使うのは、1つ目のツールプラグインです。導入のしかたは11-2で説明します。

ワークフローの中でツールを使う流れ

前提：ワークフローまたはチャットフローの編集画面を開いていること。使いたいツール（プラグイン）が導入済みであること（未導入の場合は11-2へ）。

1. キャンバスのノード追加の操作で、一覧から「ツール」の区分を開きます。
2. 使いたいツールと、その中の機能（アクション）を選びます。選ぶと、ツールのノードとしてキャンバスに置かれます。
3. 認証が必要なツールでは、認証情報を設定します（設定済みの認証情報を選ぶか、新しく作ります）。
4. ツールごとの設定項目（検索する言葉など）に、値を直接入れるか、前のノードの変数（ノード間で受け渡すデータ）を指定します。
5. テスト実行で動きを確かめます（第2章2-6）。

完了状態：ツールのノードがキャンバスに置かれ、前後のノードと線でつながり、テスト実行で結果が返ってくる。

ノードの追加・接続・変数の指定の細かい操作は第7章を参照してください。また、エージェント（AIがツールの使い方を自分で判断して実行するアプリ・序章0-2）では、使ってよいツールをアプリに登録しておくと、AIが必要に応じて呼び出します。

11-2. プラグインとは

プラグイン（Difyに機能を追加する部品）を導入すると、使えるツールやAIモデルが増えます。Dify本体には基本の機能だけが入っており、外部サービスとの連携機能は、必要なものをプラグインとして後から追加する仕組みです。

なお、公式ドキュメント（クラウド版）では、プラグインを含む外部接続の仕組み全体を「統合（Integrations）」というまとまりで説明しています。画面上の表記（「プラグイン」「ツール」「統合」など）は環境・バージョンにより異なります。

プラグインの種類

マーケットプレイスでは、プラグインが次の区分で掲載されています。

このほか、マーケットプレイスの画面には「バンドル（Bundles）」という区分の表示があります。

導入の3つの経路

プラグインは、次の3つの経路で導入できます。

本書ではマーケットプレイスからの導入だけを扱います。GitHub・ローカルファイルからの導入は、提供元の確認など安全面の判断が必要になるため、情報担当部署と相談のうえで行ってください。

マーケットプレイスからの導入手順

前提：Difyにログインしていること。プラグインを導入できる権限があること（誰が導入できるかは、ワークスペースの権限設定で「全員」「管理者のみ」「導入不可」から制限されている場合があります。導入の操作が表示されないときは管理者に確認してください）。

1. Difyの画面から、プラグイン（統合）の管理画面を開きます。開き方・画面の名称はバージョンにより異なります（序章0-3のメニュー構成も参照）。
2. マーケットプレイスを開き、区分や検索で目的のプラグインを探します。マーケットプレイスのサイト（marketplace.dify.ai）から直接探すこともできます。
3. 目的のプラグインの画面で、インストール（導入）の操作を行います。
4. 外部サービスの認証が必要なプラグインでは、認証情報（そのサービスのAPIキーなど）を設定します。認証情報は、連携先のサービス側で別途取得しておきます。

完了状態：導入したプラグインの機能が使える状態になっている（ツールのプラグインなら、11-1のノード追加の「ツール」一覧に表示される）。

導入時の注意

• 外部サービスに接続するプラグインは、Difyへの導入とは別に、そのサービス側の契約・アカウント・APIキーが必要な場合があります。費用が発生するサービスもあるため、導入前に確認してください。
• どのプラグインを導入してよいか（外部サービスへ庁内のデータを送ってよいか）は、お使いの環境のルールに従ってください。
• セルフホスト版では、管理者の設定により導入できるプラグインが制限されている場合があります。

11-3. HTTPリクエストで外部APIを呼ぶ

HTTPリクエスト（外部の窓口＝APIに接続してデータを送り受けするノード）を使うと、できあいのツールが用意されていない外部サービスや庁内システムでも、APIさえ公開されていればワークフローから直接呼び出せます。

この節の機能は、Difyから呼び出し先へネットワーク接続できることが前提です。庁内ネットワークから外部に接続できるかは環境によるため、事前に情報担当部署へ確認してください。

主な設定項目

• URL・ヘッダー・ボディには、{{変数名}} の形で前のノードの変数を差し込めます（例：利用者の入力をそのまま検索条件にする）。
• 実行結果として、応答の本文・ステータスコード（処理結果を表す3桁の番号。200番台は成功）・ヘッダー・ファイルが出力され、後続のノードで使えます。

再試行は必ず上限を決める

呼び出しに失敗したときは、自動で再試行させることができます。再試行は、回数の上限（最大10回）と間隔（最大5000ミリ秒＝5秒）を決めて設定する仕組みです。上限は小さめの値から始めてください。呼び出し回数に応じて課金される外部サービスでは、再試行した分も呼び出し回数に数えられます。

再試行してもなお失敗したときの動きは、エラー処理の設定で決められます（失敗したら別の流れに進める、など）。エラーの切り分けと対処は第14章で説明します。

APIキーの扱い

呼び出し先のAPIキーは、ノードの認証の設定欄に入力します。次の点を守ってください。

• APIキーを、手順書・共有ファイル・DSLファイルを共有する文書などに書き残さない。キーそのものは、所属で決めた安全な保管場所（パスワード管理の仕組みなど）で別に管理する。
• キーが漏れた可能性があるときは、発行元のサービスで速やかに無効化・再発行する。

設定の手順

前提：ワークフローまたはチャットフローの編集画面を開いていること。呼び出し先APIの仕様（URL・メソッド・必要なヘッダー・認証方法）とAPIキーが手元にあること。Difyから呼び出し先へ接続できることを確認済みであること。

1. ノード追加の一覧からHTTPリクエストのノードを選んでキャンバスに置き、前のノードと線でつなぎます（操作は第7章）。
2. メソッドと、呼び出し先のURLを入力します。
3. 呼び出し先の仕様に合わせて、ヘッダー・クエリパラメータ・ボディを設定します。前のノードの値を使う箇所は {{変数名}} で差し込みます。
4. 認証の形式を選び、APIキーを設定します。
5. タイムアウトと、再試行の回数の上限・間隔を設定します。
6. テスト実行し、ステータスコードが成功（200番台）で、応答の本文が想定どおりかを確認します。

完了状態：テスト実行で成功の応答が返り、応答の本文が後続のノードに渡っている。

11-4. 作ったアプリをAPIとして使う

ここまでは、Difyから外部を呼ぶ方法でした。この節は逆向きで、作ったアプリをAPI（外部のシステムから機能を呼び出す窓口）として公開し、外部から実行してもらう方法です。公開の4形式（第2章2-7）のうちの「API」にあたります。たとえば、庁内の既存システムや別の業務ツールから、Difyで作った要約ワークフローを呼び出す、といった使い方ができます。

APIキーを発行する

アプリをAPIとして呼び出すには、アプリごとのAPIキー（呼び出しを許可された相手であることを示す鍵の文字列）が必要です。

前提：呼び出したいアプリが作成済みであること。

1. スタジオで対象のアプリを開き、APIアクセスの画面に切り替えます（アプリ内の画面構成は第9章）。
2. APIキーを新しく作成します。
3. 表示されたキーの文字列を控え、所属で決めた安全な保管場所で管理します。

完了状態：APIキーの文字列を取得し、安全な場所に保管している。

APIキーの扱いは、11-3の注意に加えて次の点を守ってください。公式ドキュメントでも、キーは呼び出す側のシステムのサーバー内だけで使い、Webページの画面側のプログラムや配布するアプリに埋め込まないよう明記されています（埋め込むと第三者に取り出されて悪用されるおそれがあります）。

呼び出し先と呼び出し方

• 呼び出し先のURLの共通部分（ベースURL）は、クラウド版では https://api.dify.ai/v1 です。セルフホスト版では、お使いの環境のURLになります。
• 呼び出すときは、ヘッダー「Authorization」に、Bearer に続けてAPIキーを付けます。
• ベースURLから先の呼び出し先は、アプリの種類（チャット系・ワークフロー・テキストジェネレーターなど）ごとに異なります。自分のアプリで使える呼び出し先と項目の一覧は、そのアプリのAPIアクセスの画面と公式ドキュメントで確認できます。

最小の呼び出し例を1つ挙げます。アプリの基本情報を取得する呼び出しを、curl（コマンドラインからAPIを呼び出す道具）で行う例です。あなたのAPIキー の部分を、発行したキーに置き換えて実行します。

curl https://api.dify.ai/v1/info \
  -H "Authorization: Bearer あなたのAPIキー"

実際のプログラムに組み込むときは、キーをプログラムの中に直接書かず、環境変数（プログラムの外に別置きした設定値）から読み込ませてください。コマンドの実行履歴や共有するプログラムにキーが残ることを防げます。

完了状態：呼び出しに対して、アプリの情報が応答として返ってくる。認証エラーが返る場合は、キーの値とヘッダーの書き方を確認します（そのほかのエラーは第14章）。

応答の返り方（2つの方式）

ワークフローなどの実行APIでは、応答の返り方を2つの方式から選べます。

どちらを使うかは、呼び出す側のシステムの作りに合わせて決めます。

公開するときの注意

• APIキーを渡した相手は、そのアプリを外部から実行できます。誰にキーを渡すかを管理し、不要になったキーは整理してください。
• 呼び出す側のシステムからDify（クラウド版では api.dify.ai）へ接続できることが前提です。庁内システムから接続できるかは環境によるため、情報担当部署へ確認してください。

まとめ：3つのつなぎ方の使い分け

次の章では、アプリの設計内容を書き出したDSLファイルをAIに作らせて取り込む方法を説明します（第12章「AIにDSLを作らせてインポート」・本マニュアル）。

出典一覧

本章の記述の根拠です（いずれも確認日：2026-08-14）。