はじめに
この記事を読むことで、Difyのあらかたはまるっと理解することができます。
まだ触ったことがない人は「ちょっと試してみようかな」、すでに触れている人には「次の一歩のヒント」になれば嬉しいです。
この記事で分かること
- Difyが注目されている理由と、企業・自治体などで活用事例
- AIエージェントの考え方と、Difyが果たす役割・位置づけ
- Difyの基本機能・構成・使い始めるためのポイント
- PowerPoint検索アプリ「資料見つかるくん」の実装方法と仕組み
- 実際に触って分かった、Difyの強み・限界・運用のコツ
目次
内容が多めなので、気になる項目からどうぞ！
Difyが熱い！
ここ1-2年ほどで、Difyは世界的にも日本でも急速に注目を集めています。
まだ触ったことはなくても、名前はどこかで聞いたことがあるという方も多いのではないでしょうか。
-
GitHubスター急増：公開1年で★10万超え、LangChainを一時追い抜く勢い
-
企業導入が拡大：国内外の大手企業・自治体で採用、メディア露出も増加
-
解説本も登場：2025年から入門書・実践書が次々出版され始めた
最近の事例
Difyは、公共・行政・企業の現場でも実際に活用されるケースが増えてきています。
最近では以下のような事例が話題になりました。
-
教えて!? AIサナエさん
2025年の自民党総裁選に向けて、政策情報をRAGで検索しながら回答するAIアシスタントにDifyを活用。Facebook：高市早苗が「AIサナエさん」を体験しました！
（選挙活動終了をもってサービスを終了しています。）
同選挙活動期間中、チームみらいの「AIあんの」にもDifyが活用されています。
-
東京都AI戦略
「東京都AI戦略」が公表され、自治体職員が自らAIアプリを作れるAI基盤としてDifyを採用。
AIエージェントを理解する
Difyについて説明する前に、まず押さえておきたいのが「AIエージェント」という考え方です。
Difyといえば、関連するワードとして「AIエージェント」が頭に浮かぶのではないかと思います。
実際Difyは単なるRAGチャットボット構築ツールではなく、AIエージェントを実際に作り、動かし、運用できるプラットフォームとして設計されています。
そのため、Difyの価値を理解する前に、まず「AIエージェントとは何か」「今のAIができることと、この先の姿」を簡単に整理していきたいと思います。
Difyとは→「最先端のAgentic AI開発プラットフォーム」
1. チャットボットからエージェントへ
2022年末にChatGPTが登場して以来、「質問するとAIが答えてくれる」という体験が一気に広まりました。
最初のAI活用は、FAQ対応・社内チャットボット・文章生成といった “人が指示し、AIが応答する” スタイルが中心でした。
しかし、AIの技術が進化するにつれて、
「AIに質問する」のではなく、「AIに目的を伝えて、やり方は任せる」
という流れが生まれてきました。
つまり、AIは単なるツールではなく、「主体的に考えて動くエージェント」 として捉えられるようになり、それらはエンタープライズでの利用も求められるようになりました。
これまでの自動化の歴史を見ていくと、これまでのAIは人の指示に従う存在でしたが、AIエージェントでは 「AIが主体になってタスクを遂行する」 ことで、
人が細かく手順を指示しなくても、状況に応じて判断し、必要な情報を取りに行き、ツールを自ら呼び出して実行する ― そんな役割が求められるようになりました。
2. AIエージェントとは何か？定義と役割
「AIエージェント」の定義を調べてみると、色々の解釈があるものの、次のように定義できると思います。
ユーザーやシステムの代わりに、目的を達成するためのタスクを計画し、判断し、実行するAIプログラム
つまり、プロンプトに答えるだけではなく、
- 目的を理解し、
- どう進めるかを考え、
- 必要に応じてAPIや外部ツールを操作し、
- 実行結果を見ながら次のアクションを決める
という「Think → Act → Reflect」を繰り返す存在です。
3. 一体どんな種類があるのか？
AIエージェントと言っても、その構造やどこまで自律して考え・動けるかによっていくつかのタイプに分かれます。
ワークフロー型は、AIは利用しているものの、人が決めた手順どおりに処理を直線的に進める方式で「決まった動作を正確に実行する」形式です。
シングルエージェント型になると、AIが目的を理解し、API呼び出しや情報取得などを自ら判断しながらタスクを進めます。
さらに高度なのがマルチエージェント型で、複数のAIが役割を分担し、協調しながら問題を解く仕組みです。
| 種類 | 特徴 |
|---|---|
| ワークフロー型 | あらかじめ決められた処理フローを順に実行 |
| シングルエージェント型 | 1つのAIが目的を達成するまで考えながら実行 |
| マルチエージェント型 | 複数のエージェントが役割分担・協調してタスクを解決 |
4. Agentic AIという言葉の登場
最近では「AIエージェント」だけでなく、Agentic AI（エージェント型AI） という言葉も聞かれるようになりました。
「Agentic AI」は「AIエージェント」とどう違うのでしょうか？
どちらも似た概念に見えますが、研究論文 AI Agents vs. Agentic AI: A Conceptual Taxonomy, Applications and Challenges では、次のように整理されています。
つまり、
AI Agent：単体でタスクを実行するAI
Agentic AI：複数のエージェントが協調しながら目的達成するAIの体系
先ほど、AIエージェントには「ワークフロー型」「シングルエージェント型」「マルチエージェント型」という段階があることを説明しました。
Agentic AIは、AIが自律的に動くだけでなく、目的を分解し、判断しながら、必要に応じて他のエージェントやツール・データと連携して進めていく枠組みです。つまりAIのチームでタスクを遂行する「マルチエージェント型」に近い位置付けとなる概念と言えます。
5. 2025年の現在地は？
2025年前半の時点では、多くの企業がAIを業務フローに組み込む「ワークフロー型」の活用にとどまっており、目的達成まで自律して動く仕組みを本格導入している例はまだ少数です。
その背景には、実運用するには解決すべき課題が依然として多いことがあります。1つのAIが動くシングルエージェントでは、それっぽく見えて実は間違った情報を答えてしまったり（ハルシネーション）、話の筋道や理由づけが浅くなるといった問題があります。
複数のAIが協力するマルチエージェントでは、意図が噛み合わずに作業が止まったり、結果が毎回ばらつく、何が起きているのか内部の動きが見えにくいなど、安定運用が難しいという指摘もあります。
6. これからどこに向かうのか？
一方で、以下のような調査結果からも分かるように、多くの企業が次のステップとして「Agentic AI（自律型エージェント）」や「マルチエージェント」の活用を次の重要なステージであると捉えています。実際に、PoCや検証を進める企業も増えています。
本格的にAIが自律して動く「完全自律エージェント」は、いつ頃実現されるのでしょうか。
各企業や研究機関の見解を整理したレポートによれば、完全自律型AI（汎用AIエージェント）の実現時期は「2030年代前半〜2040年代以降」と幅広く予測されており、技術面でもまだ不確実性が残ります。
とはいえ、特定業務に特化した“限定自律エージェント”は、2030年ごろには実用化が進むという見方も多くあります。つまり、何でもこなせるAIが突然登場するわけではなく、まずは「業務の一部を任せられるAIエージェント」から数年内に現実味を帯びてくるという流れです。
✓ ここまでの流れ
ここまでの内容を整理すると：
-
AIの役割は転換期にある
「質問に答えるAI」から「目的を理解して動くAIエージェント」へ。 -
エージェントにも種類・段階がある
ワークフロー型 → シングルエージェント → マルチエージェントへと進化。 -
ただし現実はまだ移行の途中
多くの企業はワークフロー型にとどまり、エージェント導入はPoC段階。精度・安定性・協調など課題も残る。
・ハルシネーション・不安定な挙動・協調の難しさなど課題も多い
このように、AIは“自律的に動く存在”へ向かっていますが、まだ過渡期にあります。
今求められているのは、現実的に運用できる形でエージェントを業務に落とし込むことです。
こうした「試しながら、実際に使える実装へ落とし込む」段階を支えているのが、まさに Dify のようなプラットフォームです。
次の章では、Difyとは何か、またその強みについて見ていきます。
Difyとは
AIアプリ開発プラットフォーム
Difyとは、「AI（LLM）を使ったアプリケーションの開発と運用を手軽に出来るオープンソースプラットフォーム」です。
Difyのドキュメントを見てみると、DifyはBaaS（Backend as a Service）とLLMOpsの考え方を組み合わせ、認証・DB・ストレージ・開発UIなど、AIアプリ開発に必要なバックエンド一式をまとめて提供するプラットフォームであることが書かれています。
Difyは誰が提供している？
- 提供元：LangGenius Inc.
- 公開時期：2023年5月にオープンソースとして公開（約2年前）
- 創業者：Luyu Zhang（1991年生まれ / 元Tencent Cloud DevOpsチーム）
- 目的：GPTやOpenAI APIをもっと簡単に活用し、誰でも自然言語でAIアプリを作れるようにするために開発
- 名称の由来：
Dify（旧読み：ディファイ／ディフィ）＝「Define（定義する）＋Modify（改良する）」
“Do it for you” の意味も込められている
2025年5月にリブランディング、読み方を「ディファイ」から「ディフィ」へ変更（「if＝もし」への思考を意識）
なぜDifyか？
ユースケース
Difyの強みを理解するために、まずは実際にどのような場面で活用されているのかを見ていきます。
過去1-2年で国内の企業や自治体でも、Difyの導入事例がいくつか公開されています。
以下は公開情報をもとにまとめた事例の一部ですが、これ以外にも先日LangGenius主催で開催されたカンファレンス「IF Con Tokyo 2025」では、さまざまな企業や組織が登壇し導入・運用の取り組みを紹介されたようです。
こうした動きから、公開事例以外にもDifyの活用は着実に広がってきていることがうかがえます。
| 企業・自治体 | 事例 |
|---|---|
| サイバーエージェント | 社員の20％が利用、月3,000時間超の削減。全社展開の進め方や非エンジニアの急拡大も公式で公開。 |
| IIJ | 公式エンジニアブログで多数のDify活用。九州支社発で 「RFC 9,573文書を取り込みRAG化」 など実践例を公開。 |
| カカクコム／食べログ | 全社導入・高頻度利用のレポートや、社内向けBot等の活用事例を技術ブログで発信。食べログの店舗紹介記事の作成支援。 |
| 東京都 | クラウド上でDifyを動かし、各局のAIアプリ開発の足場に。都がAI活用に向け有識者会議を設置。 |
| 町田市 | 「AIナビゲーター」刷新。Dify導入で複数LLM連携や回答強化、バーチャル市役所の案内性能を向上。 |
| リコー、NTTデータ、CTC | Difyエンタープライズプラン提供・構築運用パートナー契約。 |
Difyの特徴
では、なぜDifyが存在感を持ち始め、実際に選ばれているのでしょうか。
その背景には、現在のAI活用に求められている要件と、Difyが備えている仕組みがマッチしていることがあると考えられます。
多くの企業や自治体では、単にChatGPTのような対話型AIを利用するだけでなく、業務プロセスに組み込めること、セキュリティやコストに配慮できること、さらに専門知識がなくても現場で改善・運用できることが求められています。
Difyは、これらの要件に対し、OSSによる柔軟性、複数LLMへの対応、ノーコードでのアプリ構築、そして展開・再利用しやすい基盤という形で応えています。
1. OSSであることによる柔軟性と信頼性
Difyはオープンソースとして公開されており、ソースコードを含めた内部仕様を確認できる点が特長です。これにより、企業独自の要件に合わせたカスタマイズや機能拡張が可能です。また、社内ネットワークや閉域環境へデプロイして運用できるため、外部サービスへ機密情報を送らずにAIを活用できます。Community Editionは無償で利用でき、商用利用にも対応しているため、初期導入のハードルも低く抑えられます。
OSSとして継続的に改善が行われている点も、長期的な採用を検討する上で重要な要素となっています。
2. 複数LLMモデルへの対応とコスト最適化
DifyはOpenAIやAzure OpenAIなど主要なモデルはもちろん、40をこえる多様なLLMプロバイダーに対応しています。OCI Generative AIにも対応しています。
用途・精度・コストに応じてモデルを切り替えられるほか、同じアプリケーション内で異なるモデルを使い分けることも可能です。
さらに、実行ごとのトークン使用量やAPIコストをログやAnalytics画面で確認でき、Langfuseなどの外部ツールとの連携による高度な分析にも対応しています。自動実行やループ処理には回数制限も設定でき、コストや誤動作の制御が行える点も実運用で有効です。
3. ノーコード／ローコードでのAIアプリ構築
これまでのAIアプリ開発では、LangChainなどのフレームワークを用いてPythonなどのコーディングが必須でした。Difyでは、プロンプト、ツール呼び出し、分岐処理などをビジュアルエディタ上で組み立てることができ、非エンジニアでもプロトタイプやPoCを自ら作成できます。
テンプレートも用意されており、RAG検索、チャットボット、エージェント型の構成などをすぐに試せます。また、実行ログ、履歴、再実行、権限管理など運用面の機能も備わっているため、開発から運用までを1つの画面で完結できます。
4. 展開性・標準化による組織運用のしやすさ
Difyは、作成したフローやエージェントをDSL形式でエクスポートし、他プロジェクトや他部署へ展開できる構造になっています。チームや組織全体で同じプラットフォームを利用できるため、開発・レビュー・運用の基盤を統一しやすく、属人的な実装になりにくいことも利点です。
また、運用担当者・現場部門・IT部門が同じ基盤上で役割を分担できるため、AI活用を個別の試行から組織的な活動へと移行しやすいという特徴があります。
以上が、Difyが現在のAI活用ニーズに適合し、選ばれている主な理由です。
次章では、実際にDifyをどのように使い始めるのか、基本構成や主要コンポーネントについて触れていきます。
Difyの提供形態
Difyは、大きく 「クラウド版（SaaS）」 と 「セルフホスト版（OSS）」 の2種類で提供されています。
- クラウド版
アカウント登録すぐに利用可能／環境構築不要
利用規模に応じて以下の3プラン：
| プラン | 料金 | 想定利用者 |
|---|---|---|
| Sandbox | 無料 | 個人・試用向け |
| Professional | $59/月 | 小規模チーム向け |
| Team | $159/月 | 中規模チーム／共同開発向け |
- セルフホスト版
自前の環境で運用可能
商用利用や大規模運用を想定した派生プランも存在：
| エディション | 特徴 |
|---|---|
| Community | 完全無料・OSS版 |
| Premium | AWS Marketplace などで提供／ブランドカスタム可 |
| Enterprise | セキュリティ・監査・SAMLなど企業仕様 |
Dify基本編！
ここまでで「Difyとは何か」「なぜ注目されているのか」そして「どう活用していくべきか」の全体像を整理してきました。
ここからはいよいよ実践編です。
Difyを理解するうえで、実際に手を動かしてみることが一番の近道です。とはいえ、いきなり作り始めるのではなく、次の流れを意識するととてもスムーズに進められます。
▶ じゃあ使ってみよう！Dify習得のステップ
👉 Step0. 環境を用意する
まずはDifyを動かせる環境（クラウド版 or 自分で立てる）を準備します。
👉 Step1. 基本画面・アプリケーションの型を押さえる
どの画面で何ができるのか、チャット／ワークフロー／エージェントなどの“型”を理解します。
👉 Step2. サンプルを触りながら、RAGチャットボットや簡単なワークフローを作ってみる
テンプレートやチュートリアルを使って、まずは動くものを体験します。
👉 Step3. 身近な課題でシンプルにチャレンジ
例えば「社内資料検索」「FAQ回答ボット」など、自分の業務に寄せてみる段階です。
👉 Step4. 自分の課題を解決するアプリへ発展！（応用編へ）
実際の業務で使えるレベルに落とし込み、課題を解決するアプリを作ってみます。
では次の章から、「環境を作る」に進んでいきます。
環境を作る
では早速、Difyを使える環境を用意するところからはじめましょう。
■ クラウドサービスの場合
アカウントを作成してすぐに利用開始
■ コミュニティ版（セルフホスト）の場合
ソースコードはGithub上で公開：https://github.com/langgenius/dify
Docker Composeもしくはローカルソースコードからデプロイ
最低限、Docker と docker compose が利用できる環境であれば構築可
OCI上でのDify環境
今回は、OCI上にDify環境を構築して検証しています。
Compute上でDifyを動かし、ナレッジベースやベクトル検索のため、マネージドのDBサービス Autonomous Database、LLMモデルはOCI Generative AI、データ保管はObject Storageを利用しています。
今後のワークフローやRAG構築もこの構成を基盤として進めていきます。
OCIを利用したDify環境構築についての参考記事を次に紹介します。
- GUIだけでOCI環境を構築する手順
こちらのTerraformテンプレートを利用することで、コマンドなしでOCIリソースを利用したDify環境が作成可能です！
- Docker Composeを用いてOCI Compute上にDifyを立ち上げる手順
- OCI Generative AIのセットアップ手順
初期設定
Dify に初めてログインすると、管理者アカウントの作成とあわせて 1つのワークスペースが用意されます。
このワークスペースに他のユーザーを招待して共同利用することもできます。
マルチワークスペースの利用はエンタープライズ版で利用可能です。
あわせて、利用するLLMモデルのAPIキー登録を最初に設定しておくと、この後すぐにアプリを作り始められます。
OCI Generative AIのセットアップについてはこちらをご覧ください！
プラグインとは
プラグインについて、ここで少し触れておきます。
Difyでは、LLMモデルの追加や機能拡張は「プラグイン」という形式で行います。
上記LLMモデルをインストールしたのも、「モデルプラグイン」を入れたという扱いです。
さらにプラグインはモデルだけではありません。
このあと使うワークフローの新しいノード（外部API連携／データ処理／エージェント戦略など）も、すべてプラグインとして追加できます。
- プラグインの入手や追加はマーケットプレースからワンクリックで可能
- 必要に応じて機能を“あとから足していける”のがDifyの大きな強み
つまり、Difyは最初から全部を作り込むのではなく、必要な機能をプラグインとして後から拡張していく構造になっています。
基本画面を押さえる
Dify を使いこなすうえで、まず押さえておきたいのがこの「3つの画面」です。
| 画面 | 役割 |
|---|---|
| スタジオ | アプリケーションの作成・編集・管理を行うメイン画面 |
| ナレッジ | PDFやドキュメントなど、RAG向けのナレッジベースを登録・管理する場所 |
| ツール / プラグイン | 外部APIや機能を追加する場所。新しいツール・エージェント機能もここで管理 |
● スタジオ
アプリケーションを作成、編集、管理する場所。
アプリは「最初から作成」「テンプレート利用」「DSLファイルのインポート」から開始できます。
● ナレッジ
ドキュメントなど独自の情報を組み込む（RAG）のためのナレッジベースを作成・管理する場所。
Difyのインターフェースだけでドキュメントのベクトル化ができます。
● ツール
作成するアプリに外部の機能を追加するためのプラグインやカスタムツールを追加・管理する場所。
実際には、アプリの作成画面などから遷移して新しいツールをダウンロードしたりできるので便利ですが、ここでは一覧で確認することができます。
アプリケーションの型を押さえる
DifyではAIアプリを作成するとき、まず「どの型（アプリケーションタイプ）で作るか」を選択します。
型によって構築の考え方や使える機能が変わるため、最初にこれを理解しておきましょう！
| 型 | 役割・特徴 |
|---|---|
| チャットボット | LLMへのプロンプト入力と応答を中心とした、最もシンプルな対話型アプリ。RAGやツール連携の起点にも使われる。 |
| チャットフロー | メモリ機能を持ち対話形式でインタラクションを行うワークフロー。対話の流れに応じて処理や分岐を行える。 |
| ワークフロー | 複数の処理ステップ（ノード）を組み合わせて、条件分岐・API連携などを含むタスク自動化を行う。 |
| エージェント | LLMが思考・ツール選択・実行を自律的に行う形式。複数ステップのタスクをAIが判断しながら進める。 |
| テキストジェネレーター | 指定したテンプレートやプロンプトに基づいて文章を生成する。ブログ・メール・説明文などの大量生成に向く。 |
ここからは、実際の活用シーンでも特によく使われるアプリケーションタイプについて、ひとつずつ簡単に整理していきます。
■ チャットボット
最もシンプルな型で、プロンプトに対するLLMの応答を返すアプリ。RAG（知識検索）や外部ツールの呼び出しにも対応。
■ チャットフロー
チャットボットに対し、より高度な会話型アプリケーション。ワークフロー型と同じブロックを繋げる形で作成する。対話しながら内部で処理を分岐させたり、変数保持を活用してより発展した会話アプリを構築できる。
チャットフローの活用例として、以下の記事もご参照ください。
■ ワークフロー
複数の処理（ノード）を並べて、AI応答・条件分岐・API連携などを組み合わせられる型。チャットフローがチャットボット形式で応答が繰り返されるのに対し、ワークフローは基本的にフローが最後まで行ったら処理終了。
■ エージェント
エージェントはLLMが使うツールを定義することで、LLMが自分で判断しながら各種のツールを使うような、より高度なチャットボット形式のアプリ。
RAGチャットボットをつくってみる
準備は整いました！
ここからは、まずはDifyの基本となるアプリケーションとして、RAGのチャットボットを作ってみます。
手元の資料を読み込ませて回答できるAIアプリを、どれだけ簡単に構築できるのかを体感してみましょう。
手順はこちらの記事を参照ください。
同じようなRAGのアプリをワークフローでも作成できます。
以下の手順をご参照ください。こちらを手順を実施することで、「チャットボット」や「ワークフロー」の違いや、知識検索をワークフローの中に組み込む方法もあわせて理解できるようになります。
ワークフローのアプリをつくってみる：メール作成お助けアプリ
続いて、「ワークフロー」の形でちょっと役立ちそうなアプリを作ってみましょう。
ここで作成するのは「会議メモを入力すると、顧客名・予算・要望内容などを整理し、メール案を生成する」アプリです。
手順は以下を参照してください。
ここで主に利用するノードは「パラメータ抽出」と「LLM」です。
- パラメータ抽出ノード
- LLMノード
Dify応用編！
実際に困りごとを解消するアプリを作ってみた：資料見つかるくん！
ここまででDifyの基本操作やアプリの種類を理解してきました。
次はその知識を使って、実際に自分が解決したいなと思っていた課題を実際にDifyで作ってみたので紹介します。
テーマ：「資料が見つからない問題」
- 過去の提案資料を探すのに毎回時間がかかる
- PowerPoint資料がどこに保存されているかわからない
- 図やスライドの画像内の文字は検索でヒットしない
※ある調査では、社員が「社内情報の検索に使う時間＝1日1時間以上」 という結果もあるほど、よくある課題です。
これを解消するために、パワーポイントファイルを格納し、内容を横断検索できるアプリをDifyのワークフローで作ってみました。
■ 今回作ったアプリの概要
- PowerPoint資料をアップロードすると、自動でデータベース化して検索可能にする
- その名も「資料見つかるくん」！！
最初に完成したアプリをお見せします。
チャットボットで「こんな資料が欲しい」と質問を投げると、
該当するPowerPointのファイルからスライドを特定して、関連度の高いものを回答として返してくれます。
実際欲しい資料が見つかったら、ダウンロードリンクから手元にファイルをダウンロードして資料作成に活用できます。
■ 解決したかった課題
- PowerPointファイルを変換せず、そのまま格納・処理したい
-
開かずに内容検索（図内テキストも含めて）できるようにしたい
→ この2点を実装するところが、工夫が必要だったポイントになります。
次の章では、このアプリをどのように作ったのか、Difyのワークフロー構成・工夫したポイントを順番に紹介します。
■ 実装したアプリ構成
最初はPowerPointをそのままDifyのナレッジに入れて検索できないかと考えていましたが、
- ナレッジベースはPDFやテキストのみ対応（.pptxは不可）
- スライド内の画像・図表の文字を上手く検索できない
（作り始めた時は、ナレッジパイプラインの機能がなかった）
という制約がありました。
そのため、以下のようにファイル投入アプリをワークフローで別アプリ上で行うことにしました。
- ファイル投入アプリ：PowerPointをアップロード → 画像化＋データベースに登録
- 検索アプリ：格納された資料を横断検索、候補のスライドを表示
①ファイル投入アプリ：PowerPoint資料をデータベース化
PowerPoint 資料を検索できるようにするため、まずは ファイルを自動で分解・変換し、画像＋ベクトル情報として保存するアプリを Dify で作成しました。
● 処理の流れ（全体イメージ）
- ユーザーが PowerPoint（PPTX）をアップロード
- Dify のワークフローがファイルを受け取り、以下の表内の処理を自動で実行
- 保存されたデータは、後から検索アプリで横断検索できるようになります。
| 処理ステップ | 内容 |
|---|---|
| PPT → PDF 変換 | APIを使ってPowerPointをPDFへ変換 |
| PDF → PNG 変換 | PDF内の各スライドを画像（PNG）に変換（PDF Processプラグイン） |
| 画像保存 | 生成されたPNGファイルをObject Storageへ保存 |
| ベクトル埋め込み | 画像をEmbeddingモデル（Cohere Embed v4）でベクトル化し、Oracle Autonomous DBに保存 |
● なぜこの方法にしたのか？
- ベクトルストアにはOracle Autonomous Database： ナレッジベースにPPTファイルを直接格納できなかったため、別途ベクトルストアを用意しました。
- テキスト抽出ではなく画像検索： PPTの文字だけを抽出して検索する方法も検討しましたが、図・表・スクリーンショットが多い提案資料では精度が上手く出なかったため、画像をEmbeddingして検索する方式にしました。
- 検索結果はスライド単位で表示できるように画像を保存： PPTファイルを毎回開かなくても内容を確認できるよう、スライド画像も保存してプレビュー表示できるようにしました。(画像にする過程で一度PDFに変換）
- PPTファイル自体もダウンロード可能に： 気になったスライドはすぐ資料作成に転用できるよう、PPTファイル本体もダウンロード可能な形で保存しています。
ワークフローの構成
PowerPointファイルをアップロードすると
① Object Storageへの保存
② PDF変換 → スライド画像化
③ スライドごとの画像をデータベースに登録（ベクトル化）
を実行します。
この処理を実現するために、次のようなノードを使っています：
・外部APIと連携するための「HTTPリクエストノード」
・スライドを1枚ずつ処理する「反復処理（イテレーション）」
・PDFから画像を生成する「DF Processプラグイン」
HTTPリクエスト
スライドのベクトル化やObject Storageへのアップロードについては、Databaseプラグインやコード実行ノードの活用も検討しました。しかし機能の制約があったため、FlaskでAPIサーバーを作成し、外部で処理した結果をHTTPリクエストノードを通じてやり取りする方法で行うことにしました。
反復処理（イテレーション）
スライドを1枚ずつに対して、Object Storageへの格納やベクトル化を反復して処理を行います。
プラグイン
今回はPDF化したファイルをページごとの画像（PNG）に変換するために、「PDF Process」というプラグインを利用しました。
このような標準機能では行わない処理をツールとして追加して行うことができます。
②検索アプリ：保存された資料を横断検索する
続いてファイル投入アプリによって保存された画像・ベクトル・PPTファイルを活用し、
「知りたい内容に最も近いスライドを探して回答する」アプリを作成しました。
● 処理の流れ（全体イメージ）
ユーザーが質問すると、以下のように処理されます：
| ステップ | 内容 |
|---|---|
| ① クエリ入力 | ユーザーが「この製品アーキテクチャ図ある？」など質問 |
| ② ベクトル検索 | Flask API経由でOracle Autonomous Databaseに問い合わせ、類似スライドを取得 |
| ③ 条件分岐 | スライドが見つかった場合／見つからない場合で処理を分岐 |
| ④ 回答生成 | スライド画像・PPTファイルのリンクを返す／無い場合はナレッジ or Web検索で回答 |
スライド画像を返すため、ユーザーはファイルを開かなくても内容を確認できます。
- Flask API経由で、Oracle Autonomous DBでベクトル検索を実施
- ユーザーが「資料の何ページにあるのか」一目で分かるこように、スライド画像を直接返す＋ダウンロードリンクを提供
- もし該当スライドが無い場合はAIエージェントがナレッジ検索 → Web検索という形で補完
● ワークフロー構成のポイント
使用しているノード：
- HTTPリクエストノード：Flask APIを呼び出し、ベクトル検索結果を取得
- 条件分岐ノード (IF/ELSE)：該当スライドの有無で処理を切り替え
- 反復処理 (イテレーション)：取得したスライド情報を1件ずつ画像URL＋ファイル名に整形
- エージェントノード：回答がなかった場合、ナレッジ検索・Web検索などを自律的に実行
新しく使ったノードを次に簡単に紹介します。
条件分岐ノード（If / Else）
スライド検索結果が0件の場合に、次のように処理を切り替えます：
- スライドがある場合 → 画像＋ファイル名＋ページ数を整形して回答
- ない場合 → エージェントに処理を渡し、代わりにナレッジ検索やWeb検索を実行
エージェントノード
ユーザーの意図を判断して、以下のように自律的に処理します：
Difyナレッジベースで検索 or Web検索（Perplexityなど）を実行
やってみて分かった、Dify活用の流れ！
今回、「資料見つかるくん」を一から作ってみて、課題をどのように形にしていくのかが最初は掴めず、つまづく場面も多くありました。
ただ、試行錯誤する中で、Difyを使いこなすための進め方が少しずつ見えてきました。
ここでは、実際に手を動かす中で分かったプロセスを3つのステップに分けて整理します。
① Difyのアプリタイプ・ワークフローノードの役割を理解する
まずは「どのタイプのアプリを作るのか」「どのノードで何ができるのか」を理解します。
どのアプリタイプを選ぶか（チャット／エージェント／ワークフロー）、
ワークフローの各ノードは何をするものか──ここを押さえておくと迷いが激減し近道です。
② Pluginを活用する
デフォルトで備わっているノードの機能を利用するだけでもアプリは作れますが、現実的な業務に近づけようと思うと、足りない部分が出てくると思います。そんな時に役立つのがプラグインです。
色々な処理やツール連携のプラグインが用意されているので、マーケットプレースで探しているものがないか確認してみます。
③ コード実行 / 外部連携を検討する
さらに複雑な処理や独自ロジックが必要になったら、コード実行ノードや外部サービス連携を組み合わせます。
Difyの魅力はGUIだけで完結できる点だけではなく、必要に応じてコードも取り入れられる柔軟さにあります。最後の一手としてコーディングを加えることで、実現できることの幅が大きく広がります。
まだまだ奥が深い、豊富な機能
■ ナレッジパイプライン
Dify v1.9.0 で新たに追加された「ナレッジパイプライン（Knowledge Pipeline）」機能の特徴は次のとおりです。
- RAG における ETL（Extract＝抽出、Transform＝変換、Load＝格納）プロセス を可視化
- データソース接続、ドキュメント解析、チャンキング戦略の適用などを ノード単位で管理
- テキストだけでなく「画像」「HTML」「PDF」などのマルチモーダルな入力、Google DriveやSharePointなどのデータソースとの連携
Google Driveのフォルダから直接ナレッジ登録をしてみた記録です。↓
■ 双方向MCP連携
Dify v1.6.0のアップデートで、簡単に外部MCPをツール化したり、Difyで作成したDifyアプリを簡単にMCP化することができる機能です。
■ トリガー機能
バージョン1.10.0-rc1で追加された新機能（RC版）で、ワークフローの「開始ノード」の1種類として機能し、スケジュール設定もしくは外部システム（GmailやSlack）などのイベントをきっかけに、ワークフローを開始させる仕組みです。
現状では3種類のトリガーが用意されています。
- スケジュールトリガー: 設定した時間をきっかけに
- プラグイントリガー: 対応アプリのイベントをきっかけに
- Webhookトリガー: その他の外部システムからの通知をきっかけに
まとめ
今回色々Difyを使ってみて分かったこと、気づいたポイントを最後に振り返ります。
■ Difyの魅力
- 直感的なUI・視覚的な設計でとにかく触りやすい
- コーディングが苦手でも、すぐにAIアプリの形にできる
- 使い方に慣れてくるほど、工夫次第でできることが広がる
- ノーコード基盤でありながら、コード実行・外部連携も可能な柔軟さ
■ 使ってみて感じた課題・限界
- ノーコード／ローコードだけでは複雑な処理は限界がある
- RAGや簡単なワークフローまでは直感的に作れるが、凝った処理には学習コストが必要
- コーディングに抵抗がない場合は、直接書いた方が早いケースもある
- とはいえ、プラグインやAPI連携を使えば拡張性は高く保てる
■ 運用面で気づいたこと
- アプリ数が増えると管理が煩雑になりやすい（タグなどで整理が必要）
- 同じWorkspace内では他人のアプリも編集・削除可能、競合が発生
- エンタープライズ版ではアクセス権限や管理機能が強化されている
■ コミュニティとアップデート事情
- IssueやGitHubで活発に議論され、頻繁に機能追加・改善が行われている
- 入力変数・画面仕様などがアップデートで変わることもあり、仕様追従が必要
- 良い意味で「進化し続けているプロダクト」
おわりに
最後まで読んでいただきありがとうございました！
Difyをちょっと触ってみたくなりましたか？この記事が何かのヒントやきっかけになれば嬉しいです。
「資料見つかるくん」を作る過程で、色々な機能アップデートがあり、まさに進化が進んでいる勢いのあるツールであることを感じることができました。
試す人・工夫する人が増えるほど、Difyの可能性や活用の幅もさらに広がっていくはずです。
この記事が、その最初のきっかけや次の一歩につながれば幸いです！
参考
2025年11月5日「Oracle Cloud Hangout Cafe（OCHaCafe）」実践！Dify
当日の資料👇