【学習記録 #3】専門特化型AIチャットボットを作りたい！ ― Dify × React ハイブリッド構成に決めるまで
はじめに
前回の記事 では、AIチャットボットの構築方法4パターンとRAGの仕組みを解説しました。
構想・設計フェーズの最終回となる第3回では、まず今回の構成の核となる Dify とは何かを解説し、さらに2026年3月にリリースされた Gemini Embedding 2（マルチモーダル埋め込みモデル）の可能性も検討した上で、最終的なアーキテクチャと構築ロードマップを記録します。
対象読者：エンジニア経験1年程度の方。プログラミングの基本は分かるけど、AI周りの用語にはまだ馴染みが薄い、という方を想定しています。
この記事で分かる4点を最初に示します。
- Difyとは何か ― RAG内蔵のAIアプリ開発プラットフォームの全体像
- Gemini Embedding 2 ― マルチモーダル埋め込みモデルの可能性と採用判断
- 5つのアプローチを比較検討して、Dify × React に決めた理由
- 具体的なアーキテクチャと構築ロードマップ（Phase 1〜4）
シリーズ構成
| # | タイトル | 内容 |
|---|---|---|
| #1 | AIチャットボットとは？なぜ作るのか | 種類・メリット・活用事例 |
| #2 | AIチャットボットの作り方4選とRAG入門 | 構築方法の比較 + RAGの仕組み |
| #3 | 本記事 | Dify解説 + Gemini Embedding 2検討 + アーキテクチャ設計 |
1. Difyとは何か
1-1. 概要
Dify（ディファイ）は、プログラミング知識がなくてもLLM1を活用したAIアプリケーションを構築できる オープンソースのプラットフォーム です。
単なるチャットボット作成ツールではなく、RAG2、エージェント、ワークフロー、LLMOps3まで統合した 「AIアプリ開発OS」 のような位置づけです。
1-2. Difyの主な特徴
| 特徴 | 詳細 |
|---|---|
| ノーコード/ローコード | ドラッグ＆ドロップのVisual Workflow Builderで複雑なロジックも構築可能 |
| RAG内蔵 | PDFやWordをアップロードするだけで自動的にベクトル化してナレッジベースを構築 |
| モデル中立 | Claude、GPT、Gemini、OSSモデル（Ollamaなど）を自由に切り替え可能 |
| Embeddingモデル選択可 | ナレッジベースのベクトル化に使うEmbeddingモデルも選べる（ここが今回重要） |
| API自動公開 | 作ったチャットボットをREST APIとして公開でき、外部フロントエンドと連携可能 |
| 料金 | SaaS版：無料〜$159/月（最新の料金体系を確認）、セルフホスト版：無料（サーバー管理は自前） |
| デプロイ方式 | SaaS版（クラウド）とセルフホスト版（Docker）の両方に対応 |
| オープンソース | GitHubで公開されており、コミュニティが活発 |
1-3. なぜDifyを選ぶのか -- 他のRAGツールとの違い
RAGを構築できるツールはDify以外にもあります。簡単に比較しておきます。
| ツール | 特徴 | Difyとの違い |
|---|---|---|
| LangChain | LLMアプリ開発のフレームワーク | コーディング必須。自由度は最高だが学習コスト高い |
| LlamaIndex | データ接続に特化したフレームワーク | RAG構築に強いが、UIやAPIは自前で用意する必要あり |
| Flowise | ノーコードLLMアプリ構築ツール | Difyと似ているが、ワークフロー機能やLLMOpsが弱い |
| Dify | RAG + ワークフロー + API + LLMOps統合 | 全部入り。GUIでRAGからAPI公開まで完結する |
私のケースでは「ノーコードでRAGを組みたい」「後からReactフロントと連携したい」「Embeddingモデルを選択したい」という要件があり、これを全て満たすのがDifyでした。
2. Gemini Embedding 2 -- マルチモーダル埋め込みモデルの可能性
2-1. Gemini Embedding 2とは
位置づけ：Gemini Embedding 2は現時点では採用を延期していますが、将来の切り替え候補として検討した内容を記録しておきます。
2026年3月にGoogleがリリースした、初のネイティブマルチモーダル4埋め込みモデル（Embedding Model5）です。
従来の埋め込みモデルはテキスト専用でしたが、Gemini Embedding 2は テキスト・画像・動画・音声・PDFの5つを1つのベクトル空間にマッピング できます。
私のケースでの応用可能性
健康・医学の資料には、テキストだけでなく 解剖図、リンパ、舌診の写真 など画像付きの資料が多く含まれます。
【従来のテキスト専用Embedding】
質問：「棘上筋の位置を教えて」
→ テキストだけ検索 → 「肩甲骨の…」
→ 解剖図は検索対象外 ❌
【Gemini Embedding 2（マルチモーダル）】
質問：「棘上筋の位置を教えて」
→ テキスト + 画像も検索 → テキスト説明 + 関連する図も取得 ✅
ただし、現時点での採用には注意点もあります。
| 判断ポイント | 現状 |
|---|---|
| ステータス | ⚠️ パブリックプレビュー（本番利用は自己責任） |
| 入力制限 | ⚠️ 画像6枚/リクエスト、PDF6ページまで |
| 既存モデルとの互換性 | ❌ ベクトル空間に互換性なし。切り替え時は全データ再埋め込みが必要 |
| Difyとの連携 | ✅ Gemini APIプロバイダ経由で設定可能（動作はプレビュー段階のため要検証） |
2-2. 主なスペック
スペック詳細を見る
| 項目 | 内容 |
|---|---|
| 対応モダリティ | テキスト、画像（PNG/JPEG、最大6枚）、動画（最大120秒、音声トラックありの場合は80秒）、音声（最大80秒）、PDF（最大6ページ） |
| 出力次元 | デフォルト3,072次元。MRL6により128〜3,072次元に調整可（768/1,536次元が推奨） |
| 対応言語 | 100言語以上（日本語対応◎、MTEB多言語ベンチマーク1位） |
| 入力上限 | 最大8,192トークン |
| 料金 | $0.20/100万トークン（無料枠あり） |
| ステータス | パブリックプレビュー（2026年3月〜） |
| エコシステム | LangChain、LlamaIndex、ChromaDB、Pinecone等と統合済み |
2-3. 採用方針 -- 段階的に導入する
検討の結果、以下の方針に決めました。
【Phase 1〜3】Dify標準のEmbeddingモデルで検証
│
│ テキスト検索の精度を確認
│ 画像付き資料の検索が不十分と感じたら…
▼
【Phase 3+】Gemini Embedding 2に切り替え
│
│ Dify上でEmbeddingモデルを変更するだけ
│ （ただし全データの再埋め込みが必要）
▼
【GA後】正式リリースを待って本格導入
理由： まずはテキスト検索の精度に集中すべき。画像検索はプレビュー段階のリスクもあるので、必要性を実感してからの導入が合理的です。Dify上でEmbeddingモデルを切り替えられるため、後からの変更が容易なのもこの判断を後押ししています。
3. 5つのアプローチを比較検討する
前回の記事では4つの構築方法を比較しましたが、今回はGemini Embedding 2を活用した第5のアプローチを加えて再検討します。
Gemini Embedding 2を加えた5つの構築方法を、私の要件に当てはめて検討しました。
私の要件
| 要件 | 詳細 |
|---|---|
| 資料量 | 数百ファイル（講義PDF、Word、過去問テキスト） |
| 資料の特徴 | テキスト + 画像（経穴図、経絡図、舌診写真など）が混在 |
| 検索方法 | 自然な日本語で横断検索したい |
| 回答の根拠 | どの資料のどこから答えたか表示してほしい |
| 将来性 | UIを学習に特化してカスタムしたい |
| 構築コスト | 構築に時間をかけすぎたくない |
要件に対する各アプローチの適合度
| アプローチ | 大量資料 | カスタムUI | 構築時間 | 画像検索 | 総合判定 |
|---|---|---|---|---|---|
| 既存サービス | ❌ | ❌ | ✅ | ❌ | お試し向き |
| Dify | ✅ | ✅ API経由 | ✅ | ✅ Emb切替 | 最適 ◎ |
| API + React | ❌ | ✅ | △ | ❌ | UI拡張向き |
| フルRAG自前 | ✅ | ✅ | ❌ | ✅ | オーバースペック |
| Gemini Emb 2 + 自前RAG | ✅ | ✅ | ❌ | ✅✅ | 将来有望だが時期尚早 |
結論：Difyをベースに、将来API + Reactで拡張。EmbeddingモデルはまずDify標準で開始し、必要に応じてGemini Embedding 2に切り替える。
なぜDify単体でもAPI + React単体でもなく「ハイブリッド」なのか
ここが検討の肝です。Dify単体でもチャットボットは作れるし、API + Reactでもゼロから構築できます。あえて組み合わせる理由を整理します。
Dify単体の限界
Difyは標準のチャットUIを提供していますが、シンプルで汎用的な画面です。「筋肉を解剖図上でタップして質問する」「科目別にタブ切り替え」「回答に星評価をつけて復習リストに追加」といった学習に特化した機能は作れません。
API + React単体の限界
Reactで自前UIを作ること自体は得意分野ですが、大量資料のRAGをゼロから構築すると、ベクトルDB選定、チャンク分割、Embedding処理、検索ロジックなど、バックエンド側の工数が膨大になります。
ハイブリッドの利点
┌──────────────────────────────────────────┐
│ Difyが担当（ノーコードで済む部分） │
│ ├── ナレッジベース管理 │
│ ├── チャンク分割 + ベクトル化 │
│ ├── Embeddingモデル選択（← 後で切替可能） │
│ ├── RAG検索エンジン │
│ ├── LLM呼び出し │
│ └── REST API 公開 │
├──────────────────────────────────────────┤
│ Reactが担当（自分で作りたい部分） │
│ ├── 学習に特化したチャットUI │
│ ├── 科目別タブ・出典表示 │
│ ├── 学習履歴・弱点分析 │
│ └── 復習リスト機能 │
└──────────────────────────────────────────┘
「RAGのバックエンドはDifyに任せ、フロント側だけ自由に進化させる」という分担。バックエンドは一切変更不要で、フロント部分だけ差し替えられるのが最大のメリットです。
4. アーキテクチャ -- 段階的に構築する
全体アーキテクチャ
Step 1：Dify標準UIで精度検証
まずDifyの標準チャットUIを使って、RAGの精度検証に集中 します。
ユーザー（私）
│
│ ブラウザでアクセス
▼
┌─────────────────────┐
│ Dify 標準チャットUI │ ← ここは既製品をそのまま使う
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Dify バックエンド │
│ ├── ナレッジベース │ ← 資料をアップロード
│ ├── Embedding │ ← まずはDify標準モデル
│ ├── RAG検索 │ ← チャンク設定を調整
│ ├── LLM呼び出し │ ← プロンプトを設計
│ └── 引用表示 │ ← 出典を確認
└─────────────────────┘
なぜPhase 1で標準UIを使うのか： バックエンドの精度が十分でなければ、どんなにUIを凝っても意味がありません。まず「質問に対して正確な回答が返ってくるか」を検証し、チャンク設定やプロンプトを改善するサイクルに集中します。
Step 2（任意）：Gemini Embedding 2への切り替え
Step 1で「テキスト検索は問題ないが、画像付き資料の情報が引っかからない」と感じたら、EmbeddingモデルをGemini Embedding 2に変更します。
【切り替え手順（Dify上の操作のみ）】
1. Dify設定画面でモデルプロバイダにGemini APIを追加
2. ナレッジベースのEmbeddingモデルを gemini-embedding-2-preview に変更
3. 全データの再埋め込みを実行（← ここだけ時間がかかる）
4. テスト・検証
注意： Embeddingモデルを変更すると、ベクトル空間に互換性がないため 全データの再埋め込みが必要 です。資料量が多い場合は数時間かかる可能性があります。
この切り替えをいつ検討するかのタイミングは、セクション5の**Phase 3+**で説明します。
Step 3：React フロントエンドに切り替え
精度に満足できたら、DifyのAPIキーを発行してReactフロントから接続します。
ユーザー（私）
│
│ ブラウザでアクセス
▼
┌─────────────────────────────────┐
│ React カスタムフロントエンド │ ← ここを自由に開発
│ ├── 専門チャットUI │
│ ├── 科目別タブ切り替え │
│ ├── 出典のリッチ表示 │
│ ├── 学習履歴保存 │
│ └── 復習リスト + 弱点分析 │
└──────────────┬──────────────────┘
│ REST API
│ POST /v1/chat-messages
▼
┌─────────────────────────────────┐
│ Dify バックエンド │
│ （Phase 1/2と全く同じ。変更不要） │
└─────────────────────────────────┘
5. 構築ロードマップ
具体的な構築ステップを時系列で整理します。
Phase 1：Difyセットアップ + ナレッジベース構築（1〜2日）
| ステップ | やること | ポイント |
|---|---|---|
| 1 | Difyクラウド版でアカウント作成 | dify.ai から登録 |
| 2 | LLMプロバイダ設定 | Claude API / GPT / Gemini のAPIキーを登録 |
| 3 | 資料アップロード | PDF、Word、テキストをそのまま投入 |
| 4 | チャンク設定 | 1000〜1500文字推奨 |
| 5 | 科目別にナレッジベースを分割 | 後の管理を楽にするため |
鍼灸・東洋医学の資料で特に注意すべきポイント： 経穴一覧表や漢方薬の比較表のような「表形式の情報」は、チャンクが途中で切れると意味が壊れます。チャンクサイズを大きめに設定するか、テーブル単位で分割するのが有効です。
Phase 2：チャットボット作成 + プロンプト設計（1〜2日）
| ステップ | やること | ポイント |
|---|---|---|
| 1 | チャットボットアプリを作成 | Dify管理画面から数クリック |
| 2 | システムプロンプトを設計 | 下記の例を参考に |
| 3 | ナレッジベースを接続 | Phase 1で作ったものを紐づけ |
| 4 | 「引用と帰属」をONに | 出典表示が有効になる |
| 5 | テスト・調整 | 実際に質問して回答品質を確認 |
システムプロンプト例：
あなたは鍼灸師国家試験対策の専門講師です。
以下のルールに従ってください：
- 回答はナレッジベースの情報を最優先で使用する
- 根拠となる出典（資料名、ページなど）を示す
- 不確かな場合は「この点は資料に記載がないため確認が必要です」と正直に伝える
- 経穴名は正式名称を使用する
- 漢方処方は構成生薬も併記する
Phase 3：精度検証 + ナレッジ拡充（1週間〜継続的）
実際の国試過去問や定期試験の問題を投げて、回答精度を検証します。
【精度改善のサイクル】
過去問を投げる
│
▼
回答が正確か確認 ──── 正確 → 次の問題へ
│
│ 不正確
▼
原因を特定
├── チャンクの切り方が悪い → チャンク設定を調整
├── 資料が不足している → 資料を追加アップロード
├── 表形式が壊れている → Markdown変換してから再アップ
├── プロンプトが不適切 → システムプロンプトを改善
└── 画像内の情報が必要 → Gemini Embedding 2を検討 ← NEW
│
▼
再度過去問を投げて検証（繰り返し）
Phase 4：React フロントエンド構築（Phase 3の後）
| 機能 | 概要 |
|---|---|
| Dify API連携 | APIキー発行 → fetch で /v1/chat-messages を呼ぶ |
| 専門チャットUI | 鍼灸学習に特化した画面デザイン |
| 科目別タブ | 東洋医学概論、経絡経穴、臨床医学など切り替え |
| 出典のリッチ表示 | どの資料の何ページから回答したかを視覚的に表示 |
| 学習履歴 | 過去の質問・回答を保存して振り返り |
| 復習リスト | 間違えた問題や重要な回答を保存 |
まとめ
本シリーズ全3回で整理した内容を振り返ります。
最終的な構成と選択の決め手
なお、「なぜ段階的に進めるのか」について最後にまとめておきます。バックエンドの精度を確認してからUIを作り、UIが安定してから画像検索を追加する。段階ごとに投資対効果を検証できるのが、この構成の最大の利点です。
| 判断ポイント | 結論 |
|---|---|
| 大量資料を扱いたい | → RAG必須 → Difyならノーコードで構築可能 |
| 学習に特化したUIがほしい | → Reactで自前フロントを構築 |
| バックエンドとフロントを独立させたい | → DifyのREST APIで疎結合に連携 |
| 画像付き資料も検索したい | → Gemini Embedding 2を段階的に導入 |
| 段階的に進めたい | → まずDify標準で検証 → 必要に応じて拡張 |
次のステップでは、実際にDifyでナレッジベースを構築し、チャットボットを作成していきます。その過程も学習記録として公開予定です。
参考リンク
- Dify公式サイト
- Dify公式ドキュメント
- Dify GitHub
- Gemini Embedding 2 完全ガイド - AQUA
- Gemini Embedding 2 - Google Cloud ドキュメント
- RAG (検索拡張生成) とは？ - KDDI
- 検索拡張生成（RAG）とは - AWS
次のステップ：実際にDifyでナレッジベースを構築して鍼灸・東洋医学チャットボットを作る（実践編）
-
LLM（Large Language Model / 大規模言語モデル）：膨大なテキストデータを学習し、人間のように自然な文章を生成できるAI。ChatGPT、Claude、Geminiなどが代表的。 ↩
-
RAG（Retrieval-Augmented Generation / 検索拡張生成）：LLMに外部データを検索・参照させてから回答を生成させる技術。前回の記事で詳しく解説しました。 ↩
-
LLMOps：LLMアプリケーションの運用・監視・改善を行うための仕組み。利用状況やコストの追跡、プロンプトのバージョン管理などが含まれる。DevOpsのLLM版。 ↩
-
マルチモーダル（multimodal）：テキスト・画像・音声・動画など、複数の種類（モダリティ）のデータを統一的に扱えること。対義語は単一種類のデータだけを扱う「ユニモーダル」。 ↩
-
Embedding Model（埋め込みモデル）：テキストや画像などのデータを、意味的な近さを数値で表現した「ベクトル」に変換するAIモデル。生成AIとは異なり、「理解・分類・検索」に特化している。RAGの検索精度を左右する重要なコンポーネント。 ↩
-
MRL（Matryoshka Representation Learning）：ベクトルの先頭次元に重要な情報を集中させる学習手法。これにより、3,072次元 → 768次元に縮小しても精度低下が小さい。ストレージコストとのトレードオフを柔軟に調整できる。マトリョーシカ（入れ子人形）のように、小さいベクトルが大きいベクトルの一部になっている。 ↩