MKC — Dify Japan コンテンツ体系

全体構成

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#0033FF', 'primaryTextColor': '#FFFFFF', 'primaryBorderColor': '#0026CC', 'lineColor': '#0033FF', 'secondaryColor': '#F8F9FB', 'tertiaryColor': '#E5EAFF', 'fontFamily': '-apple-system, BlinkMacSystemFont, sans-serif'}}}%%
flowchart TD
    YOU(["あなたが書く"])

    YOU --> L1
    YOU --> L2
    YOU --> L3
    YOU --> L4

    subgraph L1["第1層 · 公開チャネル Public"]
        A1["技術記事 / ブログ"] --> A2["X · LinkedIn"]
        A2 --> A3["ブランド露出 · 技術影響力"]
    end

    subgraph L2["第2層 · Dify協会 Members Only"]
        B1["深掘り Use Case / トラブル記録"] --> B2["協会限定公開"]
        B2 --> B3["コミュニティ定着 · エコシステム育成"]
    end

    subgraph L3["第3層 · パートナー研修 Partners"]
        C1["デプロイドキュメント Docker / Helm"] --> C3["パートナー独自デリバリー"]
        C2["アプリ構築講座 · 業務シナリオ"] --> C3
    end

    subgraph L4["第4層 · メーカー技術サポート Premium"]
        D1["アーキテクチャ提案 · コンサルドキュメント"] --> D2["深掘り技術コンサル 1on1"]
        D2 --> D3["高単価 · ブランド競争優位"]
    end

    style L1 fill:#E5EAFF,stroke:#0033FF,color:#000000
    style L2 fill:#E5EAFF,stroke:#0033FF,color:#000000
    style L3 fill:#E5EAFF,stroke:#0033FF,color:#000000
    style L4 fill:#E5EAFF,stroke:#0033FF,color:#000000

4層 × 具体的な執筆内容

第1層 · 公開チャネル Public

1-1 Dify プロダクト認知系

• Dify とは何か：企業が特定の AI ベンダーに依存せず、AI アプリケーションを自ら管理できるプラットフォーム
• Dify Cloud vs Dify Enterprise の違い：SaaS トライアル vs オンプレミスのプライベートデプロイ
• Dify が対応する LLM：OpenAI、Claude、Gemini、ローカルモデル（Ollama）などの接続方式
• Dify のコアコンセプト解説：Chatbot / Agent / Workflow / Knowledge Base それぞれの概要と適用シナリオ
• Dify Workflow と n8n / Zapier の本質的な違い

1-2 シナリオ事例系

• Dify で社内 FAQ ボットを構築する：ナレッジベースのアップロードから対話テストまでの完全フロー
• Dify + ナレッジベースで契約レビューアシスタントを作る：PDF ドキュメントの処理方法と検索パラメータの設定
• Dify Workflow で日報生成を自動化する：マルチノード連携、変数の受け渡し、出力フォーマット制御
• Dify Agent で外部ツールを呼び出す：天気予報クエリを例に、ツール定義から呼び出しまでの全フロー
• 日本企業でよくある AI ニーズの全体像：カスタマーサポート、ドキュメント処理、社内ナレッジ検索、レポート生成

1-3 技術動向系

• MCP（Model Context Protocol）とは何か：AI のツール呼び出しを標準化する理由
• RAG のコア課題：ナレッジベース検索結果が不正確な理由 — チャンク戦略から Embedding モデル選定まで
• プロンプトエンジニアリングの落とし穴：日本企業でよくある 3 つの書き方ミス
• AI Agent の限界：Agent に任せるべきでないタスクとは
• オンプレミスでの AI アプリケーションデプロイの必要性：データ主権、コンプライアンス、ネットワーク分離の実務的考慮

第2層 · Dify協会 Members Only

2-1 深掘り Use Case（設定詳細付き）

• 製造業設備故障トラブルシューティングボット：ナレッジベースの階層構造設計 + 検索パラメータチューニング記録
• 法務契約比較 Workflow：イテレーションノードによる複数ファイル処理、Human-in-the-Loop レビューノードのトリガー条件設定
• 社内稟議自動ドラフト生成：構造化出力フォーマット設計 + プロンプトバージョン比較
• 多言語カスタマーサポート Agent：ツール呼び出しチェーン設計、フォールバック戦略、会話メモリ管理
• HR 入社書類処理パイプライン：PDF 解析 → 情報抽出 → フォーム記入の完全ノード構成

2-2 トラブル記録と解決策

• ナレッジベース検索結果が不適切：Top-K、Score 閾値、Rerank モデルの三者連動調整方法
• Workflow ノードの頻繁なタイムアウト：LLM ノードのタイムアウトパラメータ、リトライ機構、非同期処理の設定方法
• 同じ質問に対する回答が毎回異なる：Temperature パラメータとプロンプト構造が出力安定性に与える影響
• 大容量ファイル（100MB+ PDF）のアップロード失敗：分割アップロード、前処理スクリプト、ストレージ設定の実務的解決策
• Agent ツール呼び出しの無限ループ：最大イテレーション回数の設定 + 終了条件プロンプトの設計ロジック

2-3 Dify Enterprise デプロイベストプラクティス（詳細版）

• 本番環境 vs テスト環境の設定差異：リソーススペック、ログレベル、バックアップ戦略の比較
• Helm Chart デプロイの values.yaml 重要パラメータ逐項解説：変更必須項目と既定値のまま推奨の項目
• マルチテナント権限設計：社内の各部門間でのデータ分離とモデル設定の共有方法
• License 管理実務：License 有効期限の監視、更新フロー、マルチインスタンス環境での割り当て戦略
• バージョンアップグレード時の注意事項：データ移行、API 互換性、ロールバック計画

第3層 · パートナー研修 Partners

3-1 デプロイ技術研修コンテンツ

• Docker Compose デプロイ全フロー：docker-compose.yaml 各サービスの役割と依存関係
• Helm Chart デプロイ全フロー：Kubernetes 環境要件、namespace 設計、永続化ストレージ設定
• License アクティベーションと検証：Key フォーマット説明、アクティベーション API、アクティベーション失敗時のトラブルシューティング手順
• 基本運用操作マニュアル：サービス再起動順序、ログの保存場所、よくあるエラーコード対照表
• SSO 連携設定：SAML / OIDC プロトコルの選択、IdP 設定パラメータ、ユーザー権限マッピングルール

3-2 アプリ構築研修コンテンツ

• ナレッジベース 3 種類の構築方式の適用シナリオ：設定方式 / パイプライン / Web プラットフォームインポートそれぞれの適用範囲
• プロンプト設計規範：ロール設定、出力フォーマット制約、Few-shot 例の標準的な書き方
• Workflow ノードタイプと組み合わせパターン：逐次実行、条件分岐、イテレーション、Human-in-the-Loop の典型的な組み合わせ
• Agent ツール定義規範：ツール説明フィールドの書き方で LLM が正確に呼び出せるようにする方法
• API 連携ガイド：公開後の API Endpoint 構成、認証方式、リクエスト/レスポンスフォーマットの説明

3-3 パートナーデリバリーチェックリストコンテンツ

• デプロイ受入基準：正常稼働が必須のサービス、疎通が必須のインターフェース、License ステータス確認項目
• 基本機能検証項目：ナレッジベースアップロード → 検索 → 対話のエンドツーエンドテストケース
• 顧客引き渡しドキュメントテンプレート：環境情報記録表、管理者アカウント引き継ぎ書、運用連絡先
• よくある顧客質問 Q&A 集：パートナーがデリバリー現場で最もよく遭遇する 20 の質問と標準回答
• アップグレードおよび契約更新リマインド機構：バージョン更新通知チャネル、License 期限前の顧客コミュニケーション方法

第4層 · メーカー技術サポート Premium

4-1 プロダクト設計思想コンテンツ

• Dify がオンプレミスを選択した理由（純粋な SaaS ではなく）：データ主権、企業コンプライアンス、日本市場の特殊性
• Dify の Provider 抽象レイヤー設計：数十種類の LLM を同時接続しながら疎結合を維持できる理由
• Knowledge Base の検索アーキテクチャ：ベクトル検索 + 全文検索 + Rerank の三層がすべて不可欠な理由
• Workflow のノード設計哲学：「Human-in-the-Loop」ノードが必要な理由とその境界線
• Dify のマルチテナントモデル：Workspace 分離の粒度、権限の継承関係、設計上のトレードオフ

4-2 アーキテクチャ提案コンテンツ

• 企業 AI アプリケーションの階層アーキテクチャ：インフラ層 / プラットフォーム層 / アプリケーション層 / ユーザー層の各責務
• モデル選定提案フレームワーク：タスクタイプ別（生成/検索/分類/マルチモーダル）に異なるモデル組み合わせを推奨
• ナレッジベースのスケーラブル設計：ドキュメント数が 10 万件を超えた場合の分割戦略、インデックスメンテナンス、検索パフォーマンス保証
• 高可用デプロイアーキテクチャ：マルチレプリカ、ロードバランシング、データベースのプライマリ・セカンダリ構成、災害対策のリファレンス構成
• AI アプリケーションのセキュリティ境界設計：入力フィルタリング、出力チェック、ツール呼び出し権限制御の完全な方式

4-3 AI ガバナンスコンサルティングコンテンツ

• 企業 AI 導入ロードマップテンプレート：パイロット段階 → スケール段階 → 自律運用段階のマイルストーン定義
• AI 投資対効果評価フレームワーク：AI アプリケーションによる効率向上・コスト削減の実際の価値を定量化する方法
• 企業 AI 委員会設置提案：AI 戦略、技術、コンプライアンスの各担当者の責務分担
• データガバナンスと AI コンプライアンス：日本の個人情報保護法（改正個人情報保護法）が AI アプリケーションに及ぼす制約ポイント
• 組織能力構築パス：社内 AI 人材育成計画 vs パートナー依存の境界線と移行戦略

Dify とは何か：企業が AI アプリケーションを構築・管理・継続的に進化させるためのプラットフォーム

LangGenius では、Dify を企業・チーム向けの AI アプリケーション開発プラットフォームと定義しています。

Dify は単一モデルのチャットインターフェースでも、特定のモデルベンダーに付随するツールでもありません。Dify の核心的な価値は、企業が自社のビジネスロジック、データ資産、ガバナンス要件を中心に、AI アプリケーションを構築・デプロイ・改善していくことを支援することにあります。

なぜ企業に Dify が必要なのか

多くのチームが生成 AI に初めて触れる際、まず単発の対話から始めることが一般的です。

• 一つのモデルで Q&A を行う
• 一つの Web ページでコンテンツを生成する
• 一つの prompt で局所的な課題を解決する

このような方法は探索には適していますが、真に再利用可能かつ管理可能なビジネス能力として定着させることは困難です。企業が実際の適用段階に入ると、すぐにいくつかの課題に直面します。

1. 単一モデルベンダーへのロックインを避けたい
   モデルの性能、価格、コンテキスト長、コンプライアンス要件は常に変化しており、企業はモデルの切り替えや組み合わせの自由度を確保する必要があります。

2. AI を自社のビジネスシステムやナレッジ資産に接続する必要がある
   実際のビジネスは一往復の対話だけではなく、知識検索、プロセス制御、外部ツール呼び出し、結果監査の組み合わせです。

3. 運用可能・ガバナンス可能・反復改善可能であること
   AI アプリケーションはワンショットの納品ではなく、prompt、データ、ワークフロー、ユーザー体験を継続的に最適化していく必要があります。

Dify はまさにこれらのニーズに対応するために設計されています。

Dify は「AI に聞く」ではなく「AI アプリを作る」

汎用チャット製品が解決するのが「モデルとのやり取り」だとすれば、Dify が解決するのは「モデルをどのように納品可能なアプリケーションに変えるか」です。

Dify を活用することで、チームは実際のビジネスに沿って以下を迅速に構築できます。

• 従業員や顧客向けの Chatbot
• 企業ナレッジベースに基づく Q&A システム
• 複数ステップの Workflow 自動化
• ツール呼び出しが可能な Agent
• API や Web アプリとして提供する AI サービス

これにより、企業はモデル API、検索パイプライン、プロセスオーケストレーション、公開インターフェース、ログ監視といった基盤レイヤーをゼロから構築する必要がなく、統一プラットフォーム上で設計から提供までを完結できます。

Dify のプラットフォームとしての価値

プラットフォームの観点から見ると、Dify が提供するのは AI を「能力」から「システム」へ変換するための方法論です。

1. モデルの疎結合

Dify は複数モデルの接続をサポートしており、企業はタスクの種類に応じてモデルを自由に選択できます。すべてのシナリオを単一ベンダーに依存する必要はありません。

2. データとの統合

企業はドキュメント、FAQ、ナレッジ記事、Web コンテンツなどをナレッジベースとして整理し、実際のビジネスコンテキストに即した AI アプリケーションを構築できます。

3. プロセスのオーケストレーション

多くのビジネスシナリオは「一つの質問に一つの回答」ではなく、複数ステップの判断・検索・生成・呼び出し・返却を含みます。Dify はこのようなプロセスをビジュアルに実装することを可能にします。

4. プロダクトとしての提供

アプリケーション完成後、Web、API、埋め込みなどの方法で外部に能力を提供し、チームやビジネスプロセスに実際に組み込むことができます。

5. 持続的な運用

AI アプリケーションは継続的な改善が必要です。Dify はチームが prompt、ナレッジベース、プロセス、ログを中心に継続的に効果を向上させることを可能にし、毎回ゼロから再開発する必要がありません。

Dify が適する企業シナリオ

Dify は、AI が単なるチャットウィンドウではなく、組織能力の一部となるべきだと認識しているチームに適しています。

代表的なシナリオは以下の通りです。

• 企業内部のナレッジ Q&A
• カスタマーサポートおよびプリセールス支援
• コンテンツ分析と要約生成
• フォーム、チケット、ドキュメント系のプロセス自動化
• マルチモデル連携のビジネスワークフロー
• データガバナンスやデプロイ方式に明確な要件を持つ組織

Dify の役割に対する私たちの考え

Dify はどのモデルを使うべきかを企業に代わって決定するものでも、自社のビジネスロジックを何らかの AI ツールに合わせて変更することを求めるものでもありません。

むしろ、Dify が企業自身の AI アプリケーション基盤となることを目指しています。

• モデルは入れ替え可能
• データは自社で管理可能
• ワークフローは自由に定義可能
• 提供方式は選択可能
• アプリケーションは継続的に進化可能

Dify の意義は、チームがより早く AI を導入できるようにすることだけではなく、AI 時代において企業が自律性を保てるようにすることです。

まとめ

LangGenius の視点から見ると、Dify の本質は「もう一つの AI プロダクト」ではなく、企業が AI アプリケーション体系を構築するためのプラットフォームです。

もしあなたの目標が、AI を本当にビジネスに役立てることであり、散発的な試用段階にとどまらないのであれば、Dify が提供するのはより長期的かつコントロール可能なアプローチです。

単一ベンダーに依存せず、企業自身のデータ・プロセス・シナリオを中心に、自社の AI アプリケーションを構築する。

Dify Cloud vs Dify Enterprise：迅速な試用からプライベート環境への本格導入まで

企業が AI アプリケーションプラットフォームを採用する際、通常は二つの段階を経ます。

• まず迅速に価値を検証する
• 次に安定的でガバナンス可能かつスケーラブルなデプロイへ移行する

この観点から見ると、Dify Cloud と Dify Enterprise は異なる段階・異なる要件を持つ組織のニーズに対応しています。

一言で理解する

• Dify Cloud：迅速な開始、低い導入障壁、最初の AI アプリをいち早くリリースしたいケースに最適
• Dify Enterprise：データ管理、デプロイ環境、ガバナンス能力、組織連携により高い要件を持つエンタープライズ導入に最適

Dify Cloud：より早くスタート

Dify Cloud はマネージド型の体験パスであり、チームができるだけ早くアプリを作り、動かし、検証することに重点を置いています。

通常、以下のような状況により適しています。

• チームがまず PoC やパイロットを行いたい場合
• 製品の機能を素早く体験したい場合
• 自社インフラの構築準備がまだ整っていない場合
• 現段階ではシナリオ検証が主目的で、複雑なガバナンスは後回しにできる場合

多くのチームにとって、AI プロジェクトの障壁はアイデアではなく、立ち上げコストにあります。Dify Cloud の意義は、この最初の一歩を十分に軽くすることです。

• 登録すればすぐに始められる
• モデルやアプリを直接設定できる
• 単一シナリオからの着手に適している
• ビジネスチームがまず成果を確認し、その後投資拡大を判断できる

Dify Enterprise：より強い制御力

企業が「AI を試す」段階から「AI を正式なビジネスシステムに組み込む」段階へ移行する際、ニーズは変化します。

この時、組織が通常より重視するのは以下の点です。

• データの保管場所
• プライベートデプロイやイントラネットデプロイの必要性
• より厳格なセキュリティ・コンプライアンス要件への対応
• アクセス、ログ、監査、組織連携のきめ細かな管理
• AI 能力を長期的なインフラとして定着させること

この段階では、Dify Enterprise がエンタープライズ級のデプロイ形態としてより適しています。

重視されるのは「より簡単に始められること」ではなく、「より本格的な運用に適していること」です。

どちらを選ぶべきか

Dify Cloud を選ぶ場合（重視するポイント）：

• スピード
• 低い導入障壁
• 最初のデモ可能なアプリを素早く作ること
• ビジネスチームにまず価値を検証させること

Dify Enterprise を選ぶ場合（重視するポイント）：

• プライベートデプロイ
• データと環境の制御
• エンタープライズセキュリティとガバナンス
• 中長期的なプラットフォーム化構築
• 組織内での AI アプリの大規模展開

二者択一ではなく、二つの段階

Dify Cloud と Dify Enterprise を互いに対立する製品とは考えていません。むしろ、企業の AI 導入における二つの自然な段階と捉えています。

多くのチームはまず Cloud から始めます。

1. 素早く試用する
2. 適切なシナリオを見つける
3. ビジネス効果を検証する
4. 社内コンセンサスを形成する
5. その後 Enterprise デプロイへ移行する

このアプローチの利点は、企業が最初からすべての課題に対して大きな投資をする必要がなく、価値が明確になった後にデプロイ、ガバナンス、組織化の能力を段階的に整備できることです。

LangGenius の視点から見たデプロイの選択

私たちは常に、企業が AI プラットフォームを採用する際、「作れるかどうか」だけでなく「長期的にコントロールできるかどうか」も重視すべきだと考えています。

したがって、デプロイ方式そのものがプロダクト能力の一部です。

• ビジネスチャンスをいち早く検証したいチームには Cloud がより適している
• AI をコアビジネスシステムに組み込む必要がある企業には Enterprise がより適している

どちらのパスを選んでも、目標は一致しています。

企業が自社の境界内で、真に利用可能かつ制御可能で、持続的に進化する AI アプリケーション能力を確立すること。

よくある判断基準

両者を評価中であれば、以下の質問を優先的に検討してください。

1. 現在はパイロット段階か、それとも本格導入の準備段階か？
2. データをパブリッククラウド環境にホスティングすることは許容されるか？
3. イントラネット、プライベートクラウド、またはオンプレミスデプロイの要件があるか？
4. より厳格な権限管理、ログ、監査、組織管理が必要か？
5. 今後、複数チーム・複数シナリオでの展開を計画しているか？

最初の二つの質問がより重要であれば、Cloud が効率的な出発点となることが多く、後半の質問が必須条件となっている場合は、Enterprise がよりマッチします。

まとめ

Dify Cloud と Dify Enterprise の違いは、単に「一方がオンライン、他方がプライベート」というだけではありません。

本質的には、それぞれ企業の AI 採用における二つの重点に対応しています。

• Cloud が解決するのは「いかに素早く始めるか」
• Enterprise が解決するのは「いかに着実に定着させるか」

LangGenius の視点から、企業が低い障壁で AI アプリケーション時代に参入できると同時に、必要な際には十分に強力なデプロイ・ガバナンス能力を持てることを目指しています。Dify のプロダクト設計は、まさにこの二つのことを中心に展開されています。

Dify が対応する LLM：OpenAI、Claude、Gemini からローカルモデルまで同一プラットフォームで接続

Dify の基本設計原則の一つは、企業の AI アプリケーションを単一のモデルベンダーに縛り付けないことです。

そのため、Dify は最初から「どのモデルが最も優れているか」を中心に構築されたのではなく、「企業がタスクの種類、コスト目標、デプロイ要件に応じてモデルを自由に選択できるようにする」ことを中心に設計されています。

Dify が対応するモデルの種類

Dify では、チームは通常以下のカテゴリのモデルを接続できます。

• OpenAI：汎用的な生成、要約、分類、対話などのシナリオに適している
• Anthropic Claude：長文理解、複雑な推論、ビジネス文書作成などのタスクに適している
• Google Gemini：マルチモーダルや Google エコシステム関連の能力拡張に適している
• ローカルモデル / オープンソースモデル：Ollama などを通じて接続可能で、より強力なデータ管理や特定のコスト戦略に対応
• その他の互換インターフェースを持つモデルサービスや推論バックエンド

これにより、企業は統一プラットフォーム上で異なるモデルを使用でき、モデルごとにアプリケーション層を個別に再構築する必要がありません。

なぜマルチモデル対応が重要なのか

企業が AI を実際に使用する際、単一のニーズだけということはほぼありません。

例えば：

• FAQ 分類タスクではコストとスピードが重視される
• ナレッジ Q&A では検索品質と安定した出力が重視される
• 長文要約ではコンテキスト処理能力が重視される
• 複雑な推論ではモデルの知的レベルが重視される
• 特定のデータシナリオではモデルをローカル環境で実行する必要がある

プラットフォームが単一モデルにしか対応していなければ、企業はすぐに制約に直面します。Dify が提供するのは「最適なモデルを代わりに選ぶ」ことではなく、「モデルを選択する権利を企業に残す」ことです。

Dify におけるモデル接続の位置づけ

アプリケーション層から見ると、モデル接続は独立した技術的アクションではなく、以下の機能と連動して行われます。

• Prompt オーケストレーション
• Workflow プロセス制御
• Knowledge 検索拡張
• Agent ツール呼び出し
• API / Web アプリ公開

つまり、Dify の価値は単に「Claude や Gemini に接続できる」ことにとどまらず、これらのモデルが統一されたアプリケーションフレームワーク内で実際にビジネスプロセスに参加できるようにすることにあります。

OpenAI、Claude、Gemini はそれぞれどのシナリオに適しているか

各モデルは継続的に進化していますが、プラットフォーム実践の観点から、企業は通常以下のように理解しています。

OpenAI

汎用的な基盤能力として最も適している：

• テキスト生成
• 基本的な対話
• 分類と抽出
• 一般的なワークフローノード

Claude

長文テキスト、複雑な理解、表現品質に対する要求がより高いシナリオに適している：

• 長文要約
• 政策、規程、契約などのテキスト分析
• 安定した書面表現が求められる企業コンテンツ生成

Gemini

Google 関連の能力を活用したい、またはマルチモーダル拡張シナリオを探索したいチームに適している。

ローカルモデル / Ollama

デプロイ環境やデータ境界に明確な要件を持つ組織に適している。例えば：

• ローカルまたはプライベート環境での実行が必要
• 外部依存に厳格な制限がある
• 特定タスクでコスト構造を最適化したい

なぜローカルモデル対応が重要なのか

企業にとって、「ローカルモデルに対応しているか」はオプションではなく、アーキテクチャ上の意思決定の一部であることが多いです。

Ollama などを通じてローカルモデルを接続することで、企業は以下が可能になります。

• よりコントロール可能な環境で推論を実行する
• 自社リソースに応じてオープンソースモデルを選択する
• 特定タスクにおける外部 API 依存を軽減する
• プライベートデプロイに向けたより完全なクローズドループを提供する

Dify がこのパスをサポートするのは、企業の AI 採用において SaaS モデルだけが唯一の答えであるべきではないと考えているからです。

マルチモデルは代替手段ではなく戦略である

企業が AI プラットフォームを成熟した形で活用する際、一般的なアプローチは「最強のモデルを一つ選ぶ」ことではなく、モデル戦略を確立することです。

• 低コストモデルが高頻度・標準化タスクを担当
• 高品質モデルが重要ノードを処理
• プライベートモデルが機密データシナリオをカバー
• 異なるワークフローが目的に応じて異なる推論バックエンドを切り替え

Dify はこの戦略のための統一基盤レイヤーを提供します。

言い換えれば、Dify は「どちらが賢いか」を比較するのではなく、企業が異なるモデルの能力を真に実行可能なアプリケーション体系として組織化することを支援しています。

モデルエコシステムに対する私たちの見方

LangGenius の視点から見ると、モデルエコシステムは必ず継続的に変化します。

• 新しいモデルが登場する
• 価格が変動する
• 能力の境界が移動する
• 企業のニーズも絶えず調整される

したがって、エンタープライズ AI プラットフォームにとって最も重要な能力の一つは、モデルの変化に対してオープンであり続けることです。

これが、Dify がモデル接続能力をプラットフォームの基盤として設計し、付属機能としてではなく位置づけている理由です。

まとめ

Dify が OpenAI、Claude、Gemini、ローカルモデルなど複数の接続方式をサポートする意義は「対応数が多い」ことではなく、以下の点にあります。

企業が統一プラットフォーム上で、シナリオに応じてモデルを選択し、要件に応じてアーキテクチャを制御し、ビジネスに応じてアプリケーションを継続的に最適化できること。

LangGenius にとって真に重要なのは、企業が最終的にどのモデルを使うかではなく、AI アプリケーションの進化方向を長期的にコントロールする力を持てるかどうかです。

Dify のコアコンセプト：Chatbot・Agent・Workflow・Knowledge Base はそれぞれどのシナリオに適しているか

Dify は統一的な AI アプリケーションプラットフォームですが、異なるビジネスニーズが同一の構築方法に対応するわけではありません。

LangGenius では通常、四つのコアコンセプトを用いてチームが Dify を理解できるよう支援しています。

• Chatbot
• Agent
• Workflow
• Knowledge Base

これらは互いに代替する関係ではなく、異なる課題に対応する機能の組み合わせです。

1. Chatbot：ユーザー向けの対話入口に適している

Chatbot は最も理解しやすく、最も一般的な AI アプリケーションの形態です。対話形式でユーザーとやり取りするシナリオに適しています。

例えば：

• 従業員のセルフサービス Q&A
• カスタマーサポートアシスタント
• 製品利用に関する問い合わせ
• 基本的な情報収集と回答

「ユーザーが直接質問でき、自然言語で回答を得られるようにしたい」という目標であれば、Chatbot が最も適した入口となることが多いです。

Chatbot の特徴

• インタラクションが直感的
• リリースまでの障壁が低い
• ユーザーニーズの迅速な検証に適している
• ナレッジベースと組み合わせて FAQ アプリを容易に構築できる

Chatbot がより適するシナリオ

• Q&A が中心
• プロセスが比較的シンプル
• ユーザーがチャットを通じて操作を完了したい
• 重要なのは体験と応答であり、複雑なプロセス制御ではない

2. Agent：AI がツールを能動的に呼び出してタスクを完了するケースに適している

アプリケーションが単に「質問に答える」だけでなく、AI が目標に応じて自律的にツールを選択し、ステップを実行し、結果を統合する必要がある場合、それは Agent の領域です。

例えば：

• 資料を検索してから結論を生成する
• 外部インターフェースを呼び出してタスクを完了する
• 複数のツール間で連携して複雑な問題に対処する
• 目標に応じて次のアクションを動的に決定する

Agent の特徴

• 単一回答ではなくタスク完了を重視
• ツール呼び出しとの連携が可能
• オープンエンドで複数ステップの問題に適している
• より自律性の高い AI アプリの構築に適している

Agent がより適するシナリオ

• タスクパスが完全には固定されていない
• ツール呼び出しが必要
• AI がコンテキストに基づいて戦略を判断する必要がある
• ユーザーが提供するのは目標であり、明確なステップではない

3. Workflow：明確な制御が求められるビジネスプロセスに適している

多くの企業シナリオでは、Agent に完全に自律的な判断を委ねるのは適切ではなく、予測可能・再利用可能・ガバナンス可能な実行パスがより求められます。こうしたシナリオには Workflow が適しています。

例えば：

• 入力内容をまず分類し、次に検索、生成、レビューを行う
• フォームを読み取り、複数ステップの判断と分岐処理を行う
• テキストを受け取り、要約・翻訳・フォーマット・返送を行う
• ナレッジ検索、モデル生成、条件分岐を固定パイプラインとして連結する

Workflow の特徴

• プロセスが明示的
• ノードが制御可能
• トラブルシューティングと最適化が容易
• 企業の正式なビジネスプロセスにより適している

Workflow がより適するシナリオ

• ステップが明確
• 条件分岐が必要
• 安定した出力が必要
• 観測可能・デバッグ可能・再利用可能であること

Agent が「AI に目標達成の方法を自分で考えさせる」イメージであるのに対し、Workflow は「チームがプロセスを定義し、AI がそのプロセス内で実行する」イメージです。

4. Knowledge Base：企業のナレッジに基づいた質問への回答に適している

Knowledge Base は Dify においてナレッジ型アプリケーションを構築するための基盤です。モデルを置き換えるものではなく、モデルが質問に回答する際に企業自身の資料を参照できるようにするためのものです。

一般的なナレッジソースには以下が含まれます。

• PDF
• ドキュメントやマニュアル
• FAQ
• Web コンテンツ
• 製品資料
• 社内規程や説明文書

Knowledge Base の特徴

• 回答にビジネスコンテキストを提供する
• モデルが事実から離れて自由に生成するリスクを低減する
• ナレッジ Q&A、検索拡張、社内アシスタントなどのシナリオをサポート
• 多くの Chatbot や Workflow の重要なインフラとなる

Knowledge Base がより適するシナリオ

• 既存の資料に基づいて質問に回答する必要がある
• 企業が大量のドキュメント資産を持っている
• 回答の根拠性と安定性を向上させたい
• 「自社のビジネスを理解する」AI を構築したい

四つの関係性

Dify を理解する鍵は、これら四つのコンセプトを個別に記憶することではなく、それらがどのように組み合わさるかを理解することにあります。

一般的なアプリケーション構造は以下のようになり得ます。

• Chatbot をフロントエンドの入口として使用
• Knowledge Base で検索サポートを提供
• Workflow で回答ロジックを組織
• 必要に応じて Agent によるツール呼び出しを追加

つまり、Dify は単に「一つのチャットボット」を提供するのではなく、異なるレイヤーの AI アプリケーションを構築するための汎用フレームワークを提供しています。

どう選ぶべきか

以下のように判断できます。

コアの課題が以下の場合：

「ユーザーが直接質問できるようにしたい。」
Chatbot を優先的に検討してください。

コアの課題が以下の場合：

「AI に目標に基づいてタスクを実行させたい。」
Agent を優先的に検討してください。

コアの課題が以下の場合：

「明確で安定した制御可能な処理フローが必要。」
Workflow を優先的に検討してください。

コアの課題が以下の場合：

「AI に自社の資料に基づいて回答させたい。」
Knowledge Base の構築を優先してください。

LangGenius の視点

私たちは企業に理解していただきたいのは、AI アプリケーションには一つの形態しかないわけではないということです。

ある課題には使いやすい対話入口が必要であり、ある課題には制御可能なプロセスエンジンが必要であり、ある課題にはビジネスコンテキストを真に理解するナレッジ層が必要であり、ある課題にはツールを自律的に呼び出す実行能力が必要です。

Dify のプロダクト設計は、これらの能力が複数のシステムに分散するのではなく、同一プラットフォーム上で連携して機能するようにすることを目指しています。

まとめ

Chatbot、Agent、Workflow、Knowledge Base は抽象的な用語ではなく、企業が AI アプリケーションを構築する際に最も頻繁に遭遇する四つの能力ニーズです。

• Chatbot は対話入口を解決する
• Agent はタスク実行を解決する
• Workflow はプロセスオーケストレーションを解決する
• Knowledge Base はビジネスナレッジの接続を解決する

チームがこれら四つのコンセプトを明確に理解すれば、自分たちのシナリオに何が必要か、どこから始めるべきか、そして単発の AI 能力をどのように完全な企業アプリケーションへと段階的に拡張していくかをより適切に判断できるようになります。

Dify Workflow vs n8n / Zapier：AI アプリオーケストレーションとシステム自動化は異なる二つの課題

チームが自動化に取り組み始めると、しばしば複数のカテゴリのツールを同時に目にします：Dify、n8n、Zapier。

これらは表面上はいずれも「フローをつなぎ、自動化を行う」ことができますが、同じカテゴリの製品として見てしまうと、最も重要な判断基準を見落とすことになります。

LangGenius の視点から見ると、三者の最も本質的な違いはインターフェースの形式ではなく、それぞれが何を中心に自動化システムを設計しているかにあります。

一言で概括する

• n8n / Zapier の中心は：システムの接続、データの移動、アクションのトリガー
• Dify Workflow の中心は：LLM を中核とした制御可能な AI アプリケーションフローの構築

これが二つのカテゴリの製品を分ける境界線です。

n8n / Zapier は「システム間の自動化パイプライン」に近い

n8n と Zapier は、異なる SaaS、データベース、フォーム、通知システムを接続することに非常に優れています。

典型的なフローは以下の通りです。

• あるイベントが発生する
• 自動化がトリガーされる
• データを別のシステムに送る
• 条件に応じて分岐処理を続ける

例えば：

• フォーム送信後にスプレッドシートに書き込み、Slack に通知する
• メール着信後に CRM へ同期する
• 定期的にデータを取得しレポートを生成する

このようなシナリオでは、自動化の中核は以下の通りです。

• イベントトリガー
• アプリケーション統合
• データフロー
• 条件分岐

この種のツールは非常に強力であり、非常に重要です。

Dify Workflow は「AI 処理フローのオーケストレーション層」に近い

Dify Workflow もちろん外部システムとの接続は可能ですが、設計の出発点が異なります。

Dify Workflow が重点的に解決するのは以下です。

• LLM をビジネスプロセスに組み込む方法
• ナレッジ検索、モデル推論、条件判断、ツール呼び出しを一つの AI アプリとして組織する方法
• 出力に生成能力を持たせつつ、ビジネス上の制御性も備える方法

典型的なフローはより以下に近いものです。

• ユーザー入力を受け取る
• ナレッジベースを検索する
• モデルまたはツールを選択する
• 推論と生成を行う
• 結果に基づいて分岐処理する
• 成果物を返すか、後続タスクを継続実行する

つまり、Dify Workflow は単に A システムを B システムに接続するのではなく、AI の理解、AI の判断、AI の生成を設計可能・再利用可能なアプリケーションフローに組み込むものです。

本質的な違い①：自動化の対象が異なる

n8n / Zapier が自動化するもの：

システムイベントとシステムアクション

Dify Workflow が自動化するもの：

AI アプリにおける推論、検索、生成、制御ロジック

もし課題が： 「複数の SaaS ツールをつなぎたい。」
であれば、n8n / Zapier がより直接的です。

もし課題が： 「ナレッジ、モデル、判断ロジック、出力プロセスを一つの AI アプリとして組織したい。」
であれば、Dify Workflow がよりマッチします。

本質的な違い②：コア機能が異なる

n8n / Zapier の強み

• 豊富なシステム接続
• イベント駆動
• Webhook とスケジュールタスク
• データ移動とシステムオーケストレーション

Dify Workflow の強み

• LLM ノードオーケストレーション
• Knowledge / RAG との連携
• Prompt と推論パイプラインの設計
• AI 出力制御とアプリケーション提供

両方の機能とも重要ですが、対象とする課題が異なります。

本質的な違い③：成果物が異なる

n8n / Zapier の成果は通常以下です。

• あるフローが自動実行された
• システム間の手動同期が不要になった
• 通知、更新、書き込みアクションが自動的に完了した

Dify Workflow の成果は通常以下です。

• 直接使用できる AI アプリケーション
• ナレッジ能力を備えた Q&A システム
• API や Web として公開できるビジネスインテリジェンスフロー
• モデル能力を真にプロダクト化したアプリケーション層

したがって、Dify Workflow は「AI アプリ開発」により近く、従来の意味での「システムグルー」ではありません。

Dify は n8n / Zapier を置き換えるのか？

いいえ。

多くの企業アーキテクチャにおいて、両者の関係は代替ではなく補完であることがより一般的です。

非常に自然な組み合わせ方は以下の通りです。

• n8n / Zapier がトリガー、システム接続、外部フローの移動を担当
• Dify Workflow が AI 推論、ナレッジ検索、生成、判断を担当

例えば：

• フォーム送信後に n8n がトリガーし、Dify を呼び出してテキスト分析と返信生成を完了する
• 外部システムがデータ収集後、Dify に渡して要約、分類、Q&A 処理を行う
• Dify の出力結果を n8n が CRM、メッセージシステム、データベースに書き戻す

この観点からすると、n8n / Zapier は「手足」に近く、Dify は「ビジネスコンテキストを持つ AI の頭脳」に近い存在です。

企業はどう選ぶべきか

n8n / Zapier を優先的に検討すべき場合

• 自動化の重点が SaaS 統合にある
• ビジネスルールが明確で、AI がコアではない
• 主な要求がトリガー、データ移動、同期、通知

Dify Workflow を優先的に検討すべき場合

• ビジネスのコアが LLM 能力にある
• ナレッジベース検索と生成の組み合わせが必要
• AI 出力を中心にフローを設計する必要がある
• 目標が正式な AI アプリの構築であり、単なる接続自動化ではない

LangGenius の視点

Dify Workflow を従来の自動化ツールの代替品とは位置づけていません。

Dify Workflow の価値は、本来分散していた AI の能力——モデル、ナレッジ、Prompt、ツール、プロセス——をアプリケーション指向のフレームワークに統合することにあります。これにより、チームは単に「AI を使った」だけでなく、AI を真にシステムの一部に変えることができます。

これが Dify と n8n / Zapier の根本的な違いでもあります。

Dify Workflow の目標はシステム同士を接続することではなく、AI を真にビジネスプロセスに組み込むことです。

まとめ

自動化を「フローを自動的に動かすこと」と捉えるなら、n8n / Zapier は非常に優れています。しかし、解決すべき課題が「AI をビジネスの中で安定的かつ制御可能に機能させること」であれば、Dify Workflow こそが課題そのものにより近い答えです。

したがって、Dify Workflow と n8n / Zapier の本質的な違いは、どちらが強いかではなく、それぞれが異なるレイヤーの課題を解決しているという点にあります。

• 前者は AI アプリオーケストレーション寄り
• 後者は システム自動化統合寄り

チームがこの点を明確に理解すれば、ツール選択は格段にシンプルになります。

Dify で構築する社内 FAQ チャットボット：ナレッジベースのアップロードから対話テストまでの完全フロー

企業が AI アプリケーションを導入する過程において、社内 FAQ チャットボットは最も価値を検証しやすく、最も先行導入に適したシナリオの一つです。

その理由は明確です。組織内部には、高頻度で繰り返し発生し、ルールが比較的明確な質問が大量に存在します。例えば、経費精算の基準、休暇申請フロー、出張規程、情報セキュリティ要件、契約フロー、IT サポートの窓口などです。これらの質問自体は複雑ではありませんが、人事・総務・経理・法務・IT チームの対応時間を継続的に消費します。

Dify を活用することで、企業は規程文書、フロー説明、よくある質問をナレッジベースとして整理し、ビジュアルな方法でテスト可能・改善可能・リリース可能な FAQ チャットボットを構築できます。

本記事では、完全な導入フローに沿って説明します。資料準備、ナレッジベースのアップロードから、Q&A フロー設計、対話テスト、その後の最適化まで、チームが初版の社内 FAQ チャットボットを迅速に構築できるよう支援します。

一、なぜ企業は通常 FAQ チャットボットから始めるのか

より複雑な Agent やクロスシステム自動化と比較して、FAQ チャットボットには三つの明確な利点があります。

1. 業務範囲が明確
   回答範囲は通常、規程・フロー・社内文書に沿って展開されるため、標準化に適しています。

2. リリースまでの障壁が低い
   第一段階では、複雑なツール呼び出しを導入しなくても、ナレッジベース検索と回答生成で基本的な能力を実現できます。

3. 効果を検証しやすい
   実際の質問を一定数準備すれば、ヒット率、回答品質、ユーザー受容度を迅速に評価できます。

したがって、多くの企業にとって FAQ チャットボットは AI アプリケーション構築への最も堅実な出発点の一つです。

二、第一ステップ：ナレッジ資料を準備する

FAQ チャットボットの効果は、ナレッジ資料の整理方法に大きく左右されます。

以下の内容を優先的に準備することを推奨します。

• 社員ハンドブック
• 就業規則または社内規程
• 経費精算・出張規程
• 情報セキュリティ・コンプライアンスハンドブック
• IT サポート文書
• よくあるフローの説明
• 既存の FAQ 一覧やカスタマーサポート対応マニュアル

資料整理のポイント

ナレッジベースにアップロードする前に、基本的なクリーニングを一通り行うことを推奨します。

• 明らかな重複コンテンツを削除する
• 一つのファイルが多すぎるテーマをカバーすることを避ける
• 各資料を明確な一つの問題領域に集中させる
• 明確なタイトルを使用する。例：「出張経費精算基準」「休暇承認フロー」「VPN 申請手順」

このステップの目的は、後続の検索をより安定させ、無関係なコンテキストが回答結果に与える干渉を軽減することです。

三、第二ステップ：Dify でナレッジベースを構築する

Dify では、FAQ チャットボットのナレッジ層は通常 Knowledge によって提供されます。

一般的なアプローチは以下の通りです。

• テーマ別にナレッジベースまたはドキュメントグループを作成する
• PDF、Word、Markdown、Web コンテンツなどの資料をアップロードする
• システムがチャンク分割とベクトル化を実行する
• 後続の Q&A フローで検索結果を呼び出す

推奨するナレッジの整理方法

実際のプロジェクトでは、すべての資料を一つの統一ナレッジベースにそのまま投入することは推奨せず、テーマ別に分割することをより推奨します。例えば：

• 人事制度
• 経費精算
• 情報セキュリティ
• 総務・オフィス管理
• IT サービスサポート

企業の資料規模がより大きい場合は、ドキュメント単位でさらに細分化することも可能です。例えば：

• 出張管理規程
• 旅費基準
• 休暇・勤怠制度
• 契約承認規程

この整理方法の利点は、後続のフローで問題タイプに応じて検索範囲を限定しやすくなり、関連性を向上させられることです。

四、第三ステップ：FAQ チャットボットの Q&A フローを設計する

基本的ながら実用的な FAQ チャットボットは、通常以下のロジックで構築できます。

ユーザーの質問
→ 質問の分類
→ ナレッジベース検索
→ 検索結果に基づいて回答を生成
→ 回答を出力

Dify Workflow では、このフローは通常以下のノードに対応します。

1. Start / Input：従業員の質問を受け取る
2. LLM ノード：質問のテーマ分類を行う
3. Condition ノード：どのナレッジ範囲を使用すべきか判断する
4. Knowledge Retrieval：対応するナレッジベースを検索する
5. LLM Answer：コンテキストを組み合わせて回答を生成する
6. Answer：最終結果を出力する

なぜ「質問分類」ステップの追加を推奨するのか

小規模なナレッジベースでは、質問を直接検索に入れることができます。しかし、資料規模が拡大すると、全体検索では安定性が明らかに低下します。

分類層を追加することで、システムはまずユーザーの質問がどのカテゴリに属するかを判断し、関連するナレッジのみを検索できます。例えば：

• 「出張手当の基準はいくらですか？」 → 経理 / 出張管理
• 「副業は許可されていますか？」 → 人事制度
• 「VPN のパスワードを忘れたらどうすればいいですか？」 → IT サポート

全量ブラインド検索と比較して、このアプローチは正式な企業シナリオにより適しています。

五、第四ステップ：主要なプロンプトを設定する

FAQ チャットボットにおいて最も重要なプロンプトは通常、分類プロンプトと回答プロンプトの二種類です。

1. 分類プロンプト

質問の所属範囲を判断するために使用します。例えば：

あなたは社内問い合わせの分類アシスタントです。
以下の質問がどのカテゴリに属するか判断してください：
- 人事制度
- 経費精算
- 出張管理
- 情報セキュリティ
- IT サポート
- その他

質問：{{user_query}}

2. 回答プロンプト

出力の範囲を制約し、モデルが範囲外の推測を行うことを防ぐために使用します。例えば：

あなたは社内 FAQ アシスタントです。
提供された参考資料に厳密に基づいて質問に回答してください。
要件：
- 制度に記載のない情報を勝手に補足しないこと
- 資料が不足している場合は、「現在の資料では明確な根拠が見つかりません」と明示すること
- 簡潔で実行可能な表現を優先すること
- 必要に応じて、文書名や規程の出典を記載すること

従業員の質問：{{user_query}}
参考資料：{{context}}

社内 FAQ シナリオでは、重要なのは回答を「チャットらしく」することではなく、明確な根拠に基づき、表現が安定し、直接実行可能な回答にすることです。

六、第五ステップ：第一ラウンドの対話テストを実施する

ナレッジベースの準備とフロー構築が完了したら、直接リリースするのではなく、まず構造化されたテストを一ラウンド実施することを推奨します。

少なくとも三種類の質問を準備してください。

1. 標準的な質問

• 出張経費精算の基準はいくらですか？
• 年次休暇の申請は遅くともいつまでに提出する必要がありますか？
• 会社メールのパスワードを忘れた場合はどうすればいいですか？

2. 曖昧な質問

• この状況は経費精算できますか？
• 出張の宿泊にはどのような要件がありますか？
• PC が故障した場合、誰に連絡すればいいですか？

3. 境界的な質問

• 会社が明記していない場合はどうすればいいですか？
• この制度と実際の運用が一致しない場合はどうすればいいですか？
• 代わりに承認してもらえますか？

これら三種類のテストにより、以下を迅速に特定できます。

• 検索が正しい資料にヒットしているか
• 回答に範囲外の推測が含まれていないか
• ユーザーの表現方法が変化しても、システムが安定しているか

七、第六ステップ：テスト結果に基づいて最適化する

FAQ チャットボット構築において、最も一般的な問題は「モデルが十分に強力でない」ことだけではなく、多くの場合以下の点に起因します。

1. ナレッジベースが雑多すぎる

一つのナレッジベースがあまりにも多くのテーマをカバーしていると、検索結果が明らかに不安定になります。

最適化方法：テーマ別に資料を再編成し、一回の検索範囲を縮小する。

2. 分類が粗すぎる

すべての質問が同じパスを通ると、システムは複雑なビジネス質問に対して安定した振り分けが困難になります。

最適化方法：分類の次元を追加し、その後にどのナレッジを呼び出すかを決定する。

3. 回答スタイルが汎用的すぎる

プロンプトの制約が十分に明確でないと、モデルは流暢だが根拠が不十分な回答を出力しがちです。

最適化方法：回答プロンプトにおいて「資料に基づいてのみ回答し、推測を禁止し、出典の引用を優先する」ことを強調する。

4. ユーザーが質問の仕方を知らない

完全にオープンな入力では、一部のユーザーがどのように質問すべきかわからなくなります。

最適化方法：質問例やプリセットボタンを追加する。例えば「経費精算」「休暇」「出張」「機器サポート」。

八、FAQ チャットボットリリース後の強化方向

初版の FAQ チャットボットが検証を通過した後、以下の能力を段階的に追加できます。

1. 回答の出典を表示する

回答に規程名、文書タイトル、条項の引用を付記して信頼性を向上させる。

2. リンクジャンプを追加する

例えば以下を付記する：

• 申請フォームへの入口
• 経費精算システムへのリンク
• IT チケットのアドレス
• 規程原文のアドレス

3. 回答できない場合は有人対応へ転送する

規程が網羅していない、個別判断が必要、または権限承認が必要な質問については、該当部門への問い合わせをユーザーに案内し、モデルに推測を続けさせないようにする。

4. ログの継続的な分析

高頻度の質問、誤回答の質問、未ヒットの質問を観察し、ナレッジベースとプロンプト設計を継続的に最適化する。

九、推奨する企業導入方式

実際のプロジェクトでは、第一段階から「全社・全規程・全問題領域」をカバーすることは通常推奨しません。

より効果的なアプローチは以下の通りです。

1. まず一つの部門でパイロットを実施する。例えば人事部門や総務部門
2. まず 20 から 50 の高頻度質問をカバーする
3. 実際の利用を通じてフィードバックを収集する
4. 効果が検証された後、より多くの規程や部門へ拡張する

この方法は範囲を制御しやすく、組織内部でポジティブなフィードバックを形成しやすいです。

まとめ

Dify を活用した社内 FAQ チャットボットの構築は、複雑な Agent から始める必要はありません。多くの組織にとって、より重要なのはまず三つのことをしっかり行うことです。

• ナレッジ資料をきちんと整理する
• Q&A フローを明確に設計する
• テストと最適化のパスを明確にする

真に実用的な FAQ チャットボットは、少なくとも以下の要件を満たすべきです。

• 正しい資料を見つけられる
• 資料に基づいて安定して回答できる
• 資料が不足している場合に根拠のない推測を行わない

チームがまずこのような基本的な能力をしっかりと構築すれば、FAQ チャットボットは企業の大量の重複コミュニケーションコストの削減に役立つだけでなく、後続のナレッジ検索、プロセス自動化、Agent アプリケーション構築の重要な入口にもなり得ます。

Dify + ナレッジベースで構築する契約レビューアシスタント：PDF 文書の処理と検索パラメータの設定方法

企業シナリオにおいて、契約レビューとは AI が法務を代替することではなく、契約の事前審査、条項識別、リスク提示の第一層の能力として活用することがより適切です。

このようなシナリオは、Dify の Knowledge と Workflow を活用した実装に非常に適しています。なぜなら、契約レビューの基本作業は通常、以下のステップに分解できるからです。

1. 契約テキストを読み取る
2. テンプレート、規程、ルールから根拠を検索する
3. 構造化されたリスク提示と修正提案を出力する

ここで最も重要な二つの課題は通常「モデルが十分に強力かどうか」ではなく、以下です。

• PDF 文書をどのように処理すべきか
• 検索パラメータをどのように設定すれば結果がより安定するか

本記事ではこの二つの課題を中心に、Dify + ナレッジベースを使って実用的な契約レビューアシスタントを構築する方法を説明します。

一、まず明確にすべきこと：契約レビューアシスタントが担うべき役割

企業の実務において、契約レビューアシスタントは「事前審査ツール」として位置づけるのがより適切であり、最終的な意思決定主体ではありません。

担うのに適したタスクは以下の通りです。

• 契約の基本情報の抽出。例：当事者、金額、期間、支払条件
• 重要条項の特定。例：違約責任、秘密保持、知的財産権、自動更新
• 企業標準テンプレートや法務ルールとの初期比較
• リスク提示リストの出力
• 事業部門や法務が利用する修正提案ドラフトの生成

一方、以下は引き続き人的判断に委ねるべきです。

• 重大な取引ストラクチャーの判断
• 越境コンプライアンス問題
• 業界規制の細則解釈
• 企業の既存ルール体系を超える複雑な紛争

したがって、成熟した契約レビューアシスタントの目標は「法務を代替する」ことではなく、標準化され、繰り返し性が高く、ルール化可能な第一ラウンドの審査作業を優先的に完了することです。

二、第一ステップ：二種類の資料を準備する

契約レビューアシスタントには通常、少なくとも二種類の入力資料が必要です。

1. レビュー対象の契約

事業部門がアップロードする PDF、Word、またはその他の契約テキストです。

2. レビュー根拠資料

例えば：

• 企業標準契約テンプレート
• 法務レビューチェックリスト
• リスク条項ルール表
• 契約承認制度
• よくある質問の説明
• 過去の修正規範

実際のプロジェクトでは、多くのチームが契約そのもののアップロードを優先する一方、「レビュー根拠」の整理を見落とし、結果としてシステムが汎用的な要約しか出力できず、真に価値のあるレビュー結論を生成できないケースがあります。

三、第二ステップ：PDF 文書を処理する

契約シナリオにおいて、PDF は最も一般的であり、検索品質に最も影響を与えやすいファイル形式の一つです。

よくある問題

1. スキャン版 PDF はテキストを直接抽出できない
   後続処理に進むには OCR が必要です。

2. レイアウトが複雑
   ヘッダー・フッター、表、印章、ページ番号がチャンク分割の効果を妨害しやすいです。

3. 複数テンプレートが同一ファイルに混在
   後続の検索結果の安定性に直接影響します。

4. 重複条項が多すぎる
   ランキング段階で有効なコンテンツが押し出されます。

推奨する処理方法

アップロード前に、PDF の基本的な前処理を行うことを推奨します。

• テキスト抽出可能な PDF を優先的に使用する
• スキャン版には先に OCR を実施する
• 実質的な意味のない表紙、空白ページ、署名のみのページを削除する
• 一つの契約につき一つのファイルを維持する
• レイアウトが複雑な場合は、よりクリーンなテキストまたは Markdown 構造に変換する

企業の契約ソースが多い場合は、本格的な構築前に独立した「契約クリーニングフロー」を構築し、原本ファイルを標準化してから Dify のナレッジ体系にインポートすることを推奨します。

四、第三ステップ：ナレッジ層を明確に分割する

契約レビューシナリオでは、すべての資料を一つの統一ナレッジベースにそのまま投入することは推奨せず、役割別に分割することをより推奨します。

ナレッジベース A：企業契約テンプレート

• 標準調達契約
• 標準販売契約
• サービス契約テンプレート
• NDA テンプレート

ナレッジベース B：レビュールールとレッドライン

• リスク条項リスト
• 法務レビュー規程
• 承認権限ルール
• 例外事項の説明

ナレッジベース C：補足制度・コンプライアンス資料

• 印章管理制度
• 支払承認制度
• データコンプライアンス要件
• 業界固有の制約

このように分割する価値は、システムが後続で契約タイプに応じてより適切なナレッジ範囲を選択でき、全資料に対する無差別検索を行わなくて済むことです。

五、第四ステップ：契約レビュー Workflow を設計する

実装可能な契約レビューの基本フローは、通常以下のように設計できます。

契約アップロード
→ 契約テキスト抽出
→ 契約タイプ判定
→ 対応するテンプレートとレビュールールを検索
→ 重要条項の抽出
→ リスクリストと提案の生成
→ 構造化されたレビュー結果の出力

Dify では、通常以下のノードに分割できます。

1. Input：契約テキストの入力または処理済みテキストのアップロード
2. LLM ノード：契約タイプの識別
3. Knowledge Retrieval：テンプレートとルールの検索
4. LLM ノード：重要条項の抽出
5. LLM ノード：ルールに基づくリスク分析の出力
6. Answer / JSON 出力：構造化されたレビュー結果の出力

推奨する出力フィールド

自然言語の要約を一段出力するよりも、構造化された結果の採用をより推奨します。例えば：

• 契約タイプ
• 契約期間
• 支払条項の要約
• 自動更新条項
• 違約責任条項
• 潜在的リスクポイント
• 修正提案項目
• 人的レビューの推奨有無

この構造は、後続の承認システム、法務台帳、社内レポートフローへの接続により有利です。

六、第五ステップ：検索パラメータを正しく理解する

契約レビューアシスタントでは、検索品質が出力品質を決定します。

システムが正しい条項、テンプレート、ルールを検索できなければ、後続の生成ステップがどれだけ完全であっても、偏差はむしろ大きくなる可能性があります。

そのため、構築段階では以下のパラメータに関する考え方に重点を置くことを推奨します。

1. Top K は小さすぎても、むやみに大きくしてもいけない

Top K はシステムが一回の検索で返す関連チャンクの数を示します。

• 小さすぎ：重要な根拠を見落としやすい
• 大きすぎ：ノイズが多くなり、モデルの集中力に影響する

契約シナリオでは、条項特定型の質問はやや小さめに、総合レビュー型の質問はより多くのコンテキストサポートが通常必要です。したがって、Top K は単一の値に固定すべきではなく、質問タイプに応じて調整すべきです。

2. 「無効化」を長期的な戦略にしない

一部の RAG 実践では、重複した、または使用を続けたくないチャンクを無効に設定し、これで結果に影響しないと考えるチームがあります。

しかし多くの場合、重複チャンクはランキングプロセスに引き続き影響を与え、真に有効なコンテンツが上位から押し出される可能性があります。無効化に頼るよりも、より堅実なアプローチは以下です。

• アップロード前に重複条項をクリーニングする
• 古いバージョンを削除する
• クリーニング作業を検索後に残さない

3. チャンクは文字数ではなく契約構造に合わせるべき

契約は一般的な文章ではありません。細かすぎる分割では条項の前後関係が断裂し、長すぎる分割では検索の焦点が低下します。

より合理的なアプローチは通常以下の通りです。

• 条項または小節単位で分割する
• 条項タイトルを保持する
• 一つのチャンクが一つの完全なルールを表現するようにする

例えば「支払方法」と「違約責任」を同一の大きなチャンクに入れるべきではなく、一つの完全な条項を人為的に複数の断片に分割すべきでもありません。

4. 曖昧な質問は先にリライトする

契約レビューでは、よくある質問は往々にして曖昧です。例えば：

• 「この条項にリスクはありますか？」
• 「ここは修正が必要ですか？」
• 「この契約はコンプライアンスに準拠していますか？」

このような質問を直接検索に入れても、通常効果は良くありません。より推奨されるのは、前段の LLM ノードで質問をより明確な検索リクエストにリライトすることです。例えば：

• 「支払条項が会社テンプレートと一致しているか確認してください」
• 「契約中の自動更新と違約責任に関する内容を特定してください」

この方法により、関連性を大幅に向上させることができます。

七、第六ステップ：プロンプトでは「根拠」と「境界」を必ず強調する

契約レビューシナリオにおける最大のリスクの一つは、資料が不足している場合にもモデルが一見合理的に聞こえるが根拠の欠けた判断を出力することです。

そのため、回答プロンプトでは以下の原則を明確に制約することを推奨します。

あなたは契約レビューアシスタントです。
提供された契約内容とレビュールールに厳密に基づいて分析を行ってください。
要件：
- 存在しない条項を捏造しないこと
- 推測を結論として扱わないこと
- 各リスクポイントについて根拠を説明すること
- 資料が不足している場合は、人的レビューが必要であることを明示すること
- 出力はできるだけ構造化すること

企業がさらに可読性を高めたい場合は、リスクの等級分けを追加することもできます。例えば：

• 高リスク
• 中リスク
• 低リスク
• 情報不足

八、第七ステップ：小規模テストセットを構築する

正式リリース前に、まず単一の契約カテゴリからテストを開始することを推奨します。例えば：

• NDA
• 標準調達契約
• 業務委託契約

そして 10 から 20 件のテストサンプルを準備し、以下のケースをカバーします。

1. 標準テンプレートバージョン
2. 人的修正が加えられたバージョン
3. 明らかにリスク条項が存在するバージョン
4. 情報が不完全、または OCR 品質が低いバージョン

評価時に重点的に確認すべき点：

• 契約タイプの識別は正確か
• 重要条項が安定して抽出できるか
• リスク提示に根拠があるか
• 結果が事業部門や法務が直接閲読するのに適しているか

九、推奨する導入方式

社内でこのようなプロジェクトを推進する際、第一段階から「AI 契約レビューシステム」と命名することは通常推奨しません。

事業部門や法務により受け入れられやすい表現は通常以下の通りです。

• 契約事前審査アシスタント
• 契約情報抽出アシスタント
• 条項リスク提示アシスタント
• 契約テンプレート比較アシスタント

このような表現は現在の AI の実際の能力の境界により適合しており、組織内部で合理的な期待を形成するのにも役立ちます。

まとめ

Dify + ナレッジベースを活用した契約レビューアシスタントの構築において、効果を真に決定するのはモデルだけではなく、三つの基本的な工程がしっかりしているかどうかです。

• PDF 文書が高品質なテキストにクリーニングされているか
• レビュー根拠が明確なナレッジ層として整理されているか
• 検索パラメータとチャンク分割戦略が契約構造に沿って調整されているか

これら三つが適切に処理されれば、Dify は実用的な契約事前審査フローを十分に担うことができます。まず情報を抽出し、次に条項を特定し、ルールに基づいてリスク提示を出力し、最後に複雑な判断を人的レビューに委ねる形です。

これが現在、企業が最も実際に活用しやすいアプローチでもあります。AI に法務を直接代替させるのではなく、まず AI を法務の手前にある効率的なスクリーニング能力として位置づけること。

Dify Workflow で日報生成を自動化：マルチノード連携、変数受け渡し、出力フォーマット制御

日報、週報、ニュースダイジェスト、プロジェクト進捗サマリーは、企業内部で最も典型的な高頻度テキスト生成タスクの一つです。

この種のタスクにはいくつかの共通特徴があります。

• 入力ソースが多い
• フォーマットが比較的安定している
• 内容を継続的に更新する必要がある
• 繰り返し作業のコストが高い

そのため、Dify Workflow による自動化構築に非常に適しています。このようなシナリオはマルチステップ処理が必要であり、結果のフォーマットに明確な制御も必要なため、単一のプロンプトによる一回限りの生成には向いていません。

本記事では「自動日報生成」を例に、三つの重要な課題を中心に説明します。

• マルチノードの設計と連携方法
• ノード間で変数を安定的に受け渡す方法
• 出力フォーマットを制御可能・再利用可能にする方法

一、なぜ日報生成に Workflow が適しているのか

多くのチームが初めて日報生成を試みる際、通常はモデルに直接以下のようなリクエストを送ります。

「今日のデータをもとに日報を作成してください。」

この方法でもちろん結果は生成できますが、正式なビジネス環境では通常、以下の問題がすぐに表面化します。

1. 入力情報が混在しすぎる
   モデルがソースや構造の異なるコンテキストを安定的に理解することが困難です。

2. 出力フォーマットが不安定
   日報のような時もあれば、ニュースダイジェストのような時もあり、説明文のようになることもあります。

3. デバッグと最適化が困難
   結果が理想的でない場合、問題が情報収集、重点抽出、最終レイアウトのどこにあるのか判断しにくいです。

Workflow の利点は、「日報を書く」ことを設計可能・テスト可能・進化可能なフローに分解できることにあります。

二、日報生成が通常受け取る入力とは

日報は必ずしも単一のデータソースから来るわけではありません。一般的な入力は以下の通りです。

• Web 検索結果
• 収集されたニュース本文
• 社内ビジネスシステムデータ
• 営業またはカスタマーサポートの日報表
• プロジェクト進捗記録
• グループチャットや会議議事録のサマリー

ニュース系日報の場合、入力は通常以下に近くなります。

• キーワード
• 時間範囲
• 検索結果のリンク
• ページ本文

社内ビジネス系日報の場合、以下が含まれることが多いです。

• 当日の新規顧客数
• チケット処理件数
• プロジェクトステータスの変化
• 異常イベントリスト
• 経営層の重点関心事項

入力ソースに関わらず、核心的な目標は一貫しています。まず散在する情報を処理可能なコンテンツに整理し、その後サマリーと生成フローに入ることです。

三、実装可能な Workflow の構造

「業界ニュースを自動収集して日報を生成する」を例に、典型的なフローは通常以下の通りです。

開始
→ テーマまたは日付を入力
→ ニュースを検索
→ Web ページ本文を抽出
→ 原始コンテンツを集約
→ 重要情報を抽出
→ 日報本文を生成
→ テンプレートに従いフォーマット出力

Dify では、通常以下のノードに分割できます。

1. Start / Input：日報テーマ、日付、キーワードを入力
2. ツールノードまたはプラグインノード：検索を実行
3. コンテンツ抽出ノード：本文を取得
4. LLM ノード A：重要情報をフィルタリング
5. LLM ノード B：日報のアウトラインに整理
6. LLM ノード C：テンプレートに沿って正式な日報を生成
7. Answer：Markdown または固定フォーマットテキストを出力

四、マルチノード連携の原則：一つのノードは一つのことだけを行う

Workflow 設計において最も一般的な問題は、一つのノードが過度に多くの責務を担うことです。

例えば以下を同時に担当する場合：

• 検索
• フィルタリング
• サマリー
• レイアウト

このような設計は初期には手間が省けるように見えますが、デバッグの難易度が明らかに増し、後続の再利用にも不利です。

より推奨されるのは、各ノードの責務を単一かつ明確にすることです。

ノード 1：検索

候補リンクまたは原始データの取得のみを担当。

ノード 2：本文抽出

Web ページや原始コンテンツを分析可能なテキストに変換することのみを担当。

ノード 3：重点抽出

「今日最も注目すべき重点は何か」への回答のみを担当。

ノード 4：日報生成

整理された重点を日報本文に書くことのみを担当。

ノード 5：フォーマット出力

固定テンプレートに従った出力のみを担当し、ビジネス内容の再解釈は行わない。

ノードの責務が十分に明確であれば、モデルの入れ替え、プロンプトの最適化、承認・配信ステップの追加のいずれにおいても、管理がより容易になります。

五、変数受け渡しの設計方法

日報系アプリケーションでは、変数受け渡しがフローの制御性を直接決定します。前のノードの出力が、通常次のノードの入力となるためです。

典型的な変数チェーンは以下を含むことがあります。

• topic：日報テーマ
• date_range：時間範囲
• search_results：検索結果
• raw_content：本文抽出結果
• key_points：重点サマリー
• report_outline：日報アウトライン
• final_report：最終日報本文

変数設計のポイント

1. 変数名には意味を持たせる

text1、result2 のような命名は避けてください。変数が明確であるほど、後続のメンテナンスが容易になります。

2. 重要な中間変数を保持する

ステップごとに前の値を上書きしないでください。中間結果を保持することで、問題の迅速な特定に役立ちます。

3. 後続ノードは必要な変数のみを読み取る

日報生成ノードが key_points と date_range のみを必要とする場合、原始本文全体を併せて渡すべきではありません。

4. アウトラインと本文は分離する

report_outline と final_report は別々に保持するのが望ましいです。これにより、問題がアウトライン設計にあるのか本文表現にあるのかを迅速に判断できます。

六、出力フォーマット制御の重要な方法

日報シナリオの重点は「コンテンツを生成する」ことだけでなく、「企業が必要とするフォーマットを安定的に出力する」ことです。

多くのチームは以下のように書くだけの傾向があります。

「日報形式で出力してください。」

実際のプロジェクトでは、通常これだけでは全く不十分です。

より効果的な方法

プロンプト内に明確なテンプレートを直接提示する。例えば：

以下の形式で出力してください：

# {{date}} 日報

## 一、本日の重点
- 重点 1
- 重点 2
- 重点 3

## 二、詳細サマリー
### 1. テーマ一
内容

### 2. テーマ二
内容

## 三、リスクと注意事項
- 項目 1
- 項目 2

## 四、推奨アクション
- アクション 1
- アクション 2

日報を下流システムに送信する必要がある場合、出力フォーマットはさらに構造化できます。

• Markdown
• JSON
• HTML フラグメント
• 固定フィールド形式

これにより、生成結果は可読性が高いだけでなく、ナレッジベース、メールシステム、企業メッセンジャー、コンテンツ管理システムで直接利用可能になります。

七、より実用的なノード設計例

以下に、企業の実務により近い Workflow 構造を示します。

ノード A：入力パラメータ

入力内容：

• 日付
• キーワード
• レポート対象（例：経営層 / マーケティング部 / プロダクト部）

ノード B：原始情報の取得

出力内容：

• ニュースタイトルリスト
• 本文の抜粋
• ソースリンク

ノード C：重複排除とフィルタリング

役割：

• 重複情報を除去
• 低価値コンテンツを除外
• コアイベントを保持

ノード D：重点抽出

出力：

• 本日の 3 から 5 つの重点
• 各重点の一文サマリー

ノード E：日報アウトライン生成

出力：

• 本日の重点
• 背景説明
• リスクと提案

ノード F：フォーマット整形し正式日報を生成

出力：

• 最終 Markdown 日報

ノード G：任意の配信

日報をメール、ナレッジベース、社内メッセンジャー、その他の社内チャネルに配信。

八、「文章は流暢だが情報が空虚」を避ける方法

日報生成シナリオにおける典型的な問題は、内容が読みやすいが情報量が不足していることです。

この問題を解決するには、通常三つの観点からアプローチできます。

1. まず抽出し、それから執筆する

モデルに大量の原始テキストから直接一気に日報を生成させないでください。

2. 抽出段階で事実情報の保持を要求する

例えば、以下の保持を明確に要求する：

• 数字
• 時間
• 企業名
• 製品名
• リスクポイント

3. 執筆ノードに明確なスタイル境界を設定する

例えば：

• 空虚な書き出しを書かない
• 誇張した修飾を使わない
• 結論を先に書き、その後に背景を書く
• 各重点の文字数範囲を制御する

このようなレイヤー分けにより、日報を汎用的なサマリーではなく、正式なビジネス文書により近づけることができます。

九、日報 Workflow が継続的な拡張に適している理由

日報フローが稼働すれば、通常すぐにより多くのアプリケーションタイプに拡張できます。例えば：

• 週報
• 月報
• 競合監視レポート
• 評判サマリー
• 営業モーニングレポート
• カスタマーサポート異常日報
• プロジェクト進捗ブリーフィング

本質的に見ると、これらのシナリオは同一の基本パイプラインを共有しています。

収集 → クリーニング → 抽出 → 生成 → フォーマット出力

したがって、日報生成は単独のアプリケーションであるだけでなく、企業の後続の自動化レポート体系の起点となることも多いです。

まとめ

Dify Workflow による日報生成の自動化の真の価値は、単に「AI に一段落書かせる」ことではなく、従来人手による集約・整理・レイアウトに依存していたフローを、再利用可能・デバッグ可能・継続的に最適化可能なワークフローに再構築することにあります。

このプロセスにおいて、最も重要な三つのポイントは常に以下の通りです。

• マルチノード連携：フローの明確性を保証する
• 変数受け渡し：コンテキストの安定性を保証する
• 出力フォーマット制御：結果の公開可能性・再利用可能性を保証する

これら三つのポイントが明確に設計されれば、日報アプリは単なるデモケースではなく、企業内部で非常に実用的な自動化能力の一つとなります。

Dify Agent で外部ツールを呼び出す：天気クエリを例にツール定義から呼び出しまでの完全なパイプラインを解説

多くの企業シナリオにおいて、ユーザーが本当に必要としているのは単に「AI と対話する」ことではなく、「AI が外部の能力を使ってアクションを完了する」ことです。

これこそが Agent の価値が発揮される場面です。

通常の Q&A アプリケーションとは異なり、Agent の重点は一つの回答を生成することだけでなく、タスク完了に向けた完全なパイプラインを展開することです。

• ユーザーの意図を理解する
• ツール呼び出しが必要かどうか判断する
• 正しいツールを選択する
• 呼び出しパラメータを組み立てる
• ツールからの返却結果を受け取る
• 結果に基づいて最終的な返答を生成する

このパイプラインを説明しやすくするために、天気クエリは非常に典型的な例です。十分にシンプルでありながら、Agent が外部ツールを呼び出す際の最も核心的な能力構造を完全にカバーしています。

一、「ツール呼び出し」とは何か

ツール呼び出しとは、モデルが自身では信頼性のある回答ができないと判断した場合に、外部の能力を通じて情報を取得し、その結果を最終出力として組織することと理解できます。

天気クエリを例にすると、典型的なフローは以下の通りです。

ユーザー：今日の東京の天気はどうですか？
→ Agent の判断：リアルタイム情報が必要な質問である
→ 天気 API を呼び出す
→ 気温、天気状態、風力、降水確率を取得する
→ 最終回答を生成する

つまり、重要なのはモデルが「天気を知っているかどうか」ではなく、モデルが「いつ天気を確認しなければならないかを知っているかどうか」です。

二、Dify Agent でよく使われる二つの戦略

Dify の Agent シナリオにおいて、ツール呼び出しは通常二つの方式を中心に展開されます。

• ReAct：モデルが「思考 → 行動 → 観察」のサイクルで段階的に次のステップを決定する
• Function Calling：モデルがツール名とパラメータを直接出力し、構造化された形で呼び出しを発行する

ReAct がより適する状況

• タスク目標が比較的オープン
• マルチステップの推論が必要
• 思考プロセスと呼び出しパスを観察したい
• 複雑な行動チェーンのデバッグが必要

Function Calling がより適する状況

• タスク構造が明確
• ツール呼び出しパスが安定している
• 応答速度とパラメータ精度への要求がより高い
• 出力フォーマットに構造化が求められる

天気クエリのようなタスクでは、Function Calling がより直接的であることが多いです。一方、「天気、交通、スケジュールを組み合わせて外出の提案を行う」ようなよりオープンなタスクでは、ReAct の柔軟性がより高くなります。

三、なぜ天気クエリは典型的な Agent シナリオなのか

天気クエリは標準的な Agent シナリオのすべての特徴を備えています。

1. 問題がリアルタイムデータに依存する
2. 外部 API の呼び出しが必要
3. パラメータ構造が明確。例：都市と日付
4. 返却結果が構造化されている。例：気温、天気状態、降水確率
5. 最終結果に自然言語での表現が必要であり、生の JSON ではない

したがって、天気クエリは単なるシンプルな例ではなく、Agent のツール呼び出しの全パイプラインを理解するための最も適した入門ケースの一つです。

四、第一ステップ：ツール能力を定義する

Dify Agent において、ツールは本質的にモデルが呼び出せる外部能力です。

天気クエリを例にすると、ツールを定義する際には少なくとも以下の三項目を明確にする必要があります。

1. ツール名

例えば：

• get_weather
• query_weather

名称はできるだけ明確にし、モデルが用途を理解しやすいようにすべきです。

2. ツールの説明

例えば：

• 指定された都市の指定日の天気情報を照会するために使用する
• 天気状態、気温、湿度、風力、降水確率を返す

説明の品質はモデルが使用シナリオを正しく判断できるかどうかに直接影響するため、あまりに汎用的な記述は避けるべきです。

3. 入力パラメータ

天気クエリで最も一般的なパラメータは以下の通りです。

• city：都市名
• date：日付
• unit：温度単位（任意）

企業シナリオでは、パラメータ定義が明確であるほど、呼び出しの安定性は通常より高くなります。

五、第二ステップ：外部天気 API に接続する

ツール定義が完了したら、次のステップは実際にデータを提供する外部サービスに接続することです。

一般的な接続方法は以下の通りです。

• 公開天気 API を使用する
• 企業内部の中間サービスを呼び出す
• HTTP リクエストでサードパーティの天気インターフェースにアクセスする

このステップの重点は API 自体の複雑さではなく、入出力構造が十分に安定していることを保証することです。

理想的な返却構造は通常以下のようになります。

{
  "city": "東京",
  "date": "2026-04-12",
  "condition": "曇り",
  "temperature_min": 14,
  "temperature_max": 22,
  "rain_probability": "30%",
  "wind": "北東の風 3級"
}

Agent にとって、返却構造が明確であるほど、後続の生成結果はより安定します。

六、第三ステップ：Agent に「いつツールを呼び出すべきか」を学ばせる

実践では、このステップが過小評価されることがよくあります。

多くのチームは「ツールが接続できたかどうか」に重点を置きますが、体験を真に決定するのは、通常モデルが以下を理解しているかどうかです。

• どの種類の質問で天気ツールを呼び出す必要があるか
• どの種類の質問は既存のコンテキストで直接回答できるか
• パラメータが不完全な場合、先に確認すべきか

基本的な制約の例

システムプロンプトに以下のようなルールを追加できます。

ユーザーが天気、気温、降雨、風力、服装の適切さ、外出の適否など天気に関連する質問をした場合、直接回答するのではなく、天気ツールを優先的に呼び出してください。
都市や日付が不足している場合は、先にユーザーに確認してください。

この目的は、リアルタイム情報シナリオにおけるモデルの主観的な推測を減らすことです。

七、第四ステップ：不完全な入力を処理する

実際のユーザーの入力は常に完全であるとは限りません。例えば：

• 「今日は外出に適していますか？」
• 「東京の天気は？」
• 「明日大阪は雨が降りますか？」

このような場合、Agent には二つの基本的な能力が必要です。

1. 推測可能な情報の自動補完

例えば「今日」は現在の日付として解析できます。

2. 欠落パラメータの能動的な確認

ユーザーが「天気はどうですか」とだけ言い、都市を指定しなかった場合、優先的に確認すべきです。

• 「どの都市の天気を照会しますか？」

この能力は非常に重要です。なぜなら、Agent が利用可能なシステムとして振る舞うか、たまにツール呼び出しが成功するデモプロトタイプに過ぎないかを直接決定するからです。

八、第五ステップ：構造化された結果を実用的な回答に変換する

ツールが返すのは構造化データですが、ユーザーが本当に必要としているのは実行可能で理解しやすい結論です。

例えば、ユーザーが以下のように質問した場合：

「明日東京で傘は必要ですか？」

Agent は生の JSON を機械的に復唱するのではなく、以下のような結果を出力するのがより適切です。

• 明日の東京は曇りのち小雨、最高気温 21℃、降水確率 60%、雨具の携帯をお勧めします。

さらに、よりシナリオに即した表現も生成できます。

• 明日屋外の予定がある場合は、短時間の降雨に備えて折りたたみ傘をご用意ください。

これが Agent と通常の API 呼び出しの核心的な違いでもあります。ツールがデータ取得を担当し、モデルが解釈と表現を担当する。

九、なぜ天気クエリは Function Calling により適しているのか

天気クエリが特に Function Calling に適している理由は、以下の特徴を満たしているからです。

• 呼び出し対象が明確
• パラメータ構造が安定
• 返却値の構造が明確
• 長いチェーンの推論が不要

ReAct と比較して、通常三つの明確な利点があります。

1. 応答が速い
   不必要な思考テキストの生成を削減できる。

2. パラメータがより安定
   要件を満たす構造化された呼び出しパラメータを出力しやすい。

3. コストがより低い
   余分なトークン消費を削減できる。

したがって、Agent のタスクが主に「天気を調べる、在庫を調べる、注文を調べる、価格を調べる」といった標準的なアクションである場合、Function Calling が通常より適切な第一選択となります。

十、天気クエリから企業シナリオへの拡張

天気クエリは教育的なケースに過ぎませんが、その背後には実際には一連の企業シナリオが対応しています。

• 在庫照会
• チケットステータス照会
• 注文進捗照会
• 顧客情報照会
• 会議室予約状況照会
• 経費承認ステータス照会

これらの問題と天気クエリには一つの共通点があります。

モデルに回答を憶測で生成させるのではなく、モデルにまずデータ取得能力を呼び出させ、その後結果を組織させること。

天気クエリのパイプラインが明確に構築されれば、企業は通常同じパターンをより多くの社内ビジネスシステムに移植できます。

十一、推奨する設計原則

Agent のツール呼び出し設計において、非常に実用的な原則は以下の通りです。

ツールはできるだけ構造化し、モデルの推測はできるだけ少なくする。

具体的には、以下を可能な限り実現すべきです。

• ツールの説明が明確
• パラメータ定義が明確
• 返却フィールドが明確
• リアルタイム情報シナリオでは「ツール呼び出し必須」を明確に要求する
• パラメータ欠落シナリオでは「先に確認してから呼び出す」を明確に要求する

このような基本設計は、単にモデルを入れ替えるよりもシステムの信頼性を向上させることが多いです。

まとめ

天気クエリを例にすると、Dify Agent による外部ツール呼び出しの完全なパイプラインは以下のように明確に分解できます。

• ツールを定義する
• API に接続する
• 呼び出しタイミングを制約する
• パラメータ補完を処理する
• 結果をユーザーが理解できる回答に組織する

このパイプラインの本質は、モデルを何でも知っている万能な存在にすることではなく、適切なタイミングで外部の能力を呼び出せるようにすることです。

企業にとって、この能力は「より上手にチャットする」ことより重要であることが多いです。なぜなら、実際のビジネスにおいてより一般的なニーズは「より美しい文章を書くこと」ではなく、以下だからです。

調べて、取得して、判断して、そして結果を直接使える出力に整理してほしい。

これこそが Dify Agent とツール呼び出しの最も注目すべき価値です。

日本企業に多い AI ニーズシナリオの総括：カスタマーサポート、文書処理、社内ナレッジ検索、レポート生成

企業の実際の導入パスから見ると、多くの組織は AI 導入時に最初から「汎用 Agent プラットフォーム」を目標にするわけではありません。

より一般的な状況は、企業がまず目にするのは一連の具体的で繰り返し発生し、計測可能な課題です。

• カスタマーサポートや社内問い合わせの負荷が高すぎる
• 文書は多いが、検索効率が低い
• レポートやサマリー作成に時間がかかりすぎる
• プロセス内にまだ大量の手動入力と人的判断が残っている

だからこそ、企業が Dify のようなプラットフォームに求めるのは、抽象的な「AI を導入したい」ではなく、より具体的に以下の一点に集約されます。

高頻度で標準化されており、価値を検証しやすい業務プロセスを優先的に解決できるかどうか。

本記事では、最も一般的な五つの企業ニーズを中心に、日本企業の文脈においてどのようなシナリオが出現しやすく、Dify のようなプラットフォームで着手するのに最適かを説明します。

一、カスタマーサポートと Q&A 対応

カスタマーサポートと Q&A 対応は、企業にとって最も ROI を数値化しやすい AI シナリオの一つです。

よくある課題

• ユーザーが同じタイプの質問を繰り返し問い合わせる
• カスタマーサポートチームが大量の低複雑度の問い合わせに占有される
• 夜間や営業時間外に即時対応が困難
• 担当者によって回答の内容が一致しない

典型的なアプリケーション

• FAQ チャットボット
• 注文・サービスステータス照会アシスタント
• 社内ヘルプデスクボット
• プリセールス製品問い合わせアシスタント

なぜこのシナリオが優先的に構築されるのか

この種のシナリオは通常以下の特徴を備えているからです。

• 繰り返し度が高い
• 頻度が高い
• 価値を計測しやすい
• リリース後の効果が体感されやすい

一般的な問い合わせが自動処理されれば、人的チームはより複雑な問題や高付加価値のコミュニケーションに注力できるようになります。

二、文書処理とナレッジ抽出

企業が本格的に AI アプリケーションの構築を始めると、すぐに気づくのは、組織で最も一般的な問題はモデルの不足ではなく、ナレッジは明らかに文書内に存在しているのに効率的に活用できないということです。

よくある文書タイプ

• PDF の規程文書
• 契約書と添付資料
• 会議議事録
• 提案資料
• 操作マニュアル
• 過去のプロジェクト文書

典型的なアプリケーション

• 契約情報の抽出
• 請求書、支払依頼書、申請書の識別
• 長文サマリーの生成
• 文書の分類と整理
• 条項比較とリスクの初期スクリーニング

なぜこのシナリオのニーズが普遍的なのか

一方で、企業内部には通常大量の規範化された文書が蓄積されています。他方で、文書量が多いからこそ、人的な検索、閲読、整理のコストも顕著に増加します。

したがって、文書処理系の AI アプリケーションは、組織が AI 実践段階に入った後、非常に自然に生まれるニーズの一つです。

三、社内ナレッジ検索

多くの企業において、ナレッジ検索はパイロットから正式運用段階に移行した後、最も構築する価値のある能力の一つです。

前段階で組織はまずチャットボットを構築するかもしれませんが、すぐにより根本的な問題に直面します。

組織内部のナレッジは、自然言語で効率的に呼び出せるか。

よくある課題

• 情報が Drive、Wiki、フォルダ、チャット履歴、社内システムに分散している
• 新入社員が規程、テンプレート、過去の資料を素早く見つけられない
• ベテラン社員が経験で質問に答えており、ナレッジが個人に高度に依存している
• 同じ質問が複数部門で繰り返し問い合わせされている

典型的なアプリケーション

• 社内規程 Q&A
• IT サポートナレッジアシスタント
• プロジェクト資料検索
• 営業ナレッジベースアシスタント
• 人事・総務制度照会

なぜこの能力が極めて重要なのか

社内ナレッジ検索は必ずしも最もデモ映えする AI アプリケーションではありませんが、通常は最も実際にビジネスプロセスに組み込みやすい能力の一つです。

なぜなら、解決するのは組織連携における基本的な問題だからです。情報は明らかに存在しているのに、タイムリーかつ正確に呼び出せない。

文書の規範化程度が高く、部門間連携が密な企業にとって、この能力は特に重要です。

四、レポート生成とサマリー自動化

企業の実務において、レポート系テキストは依然として多くの時間を占めています。

• 日報
• 週報
• 月報
• 会議議事録
• 市場調査サマリー
• 競合モニタリングブリーフ

よくある課題

• 原始資料が多く、整理に時間がかかる
• フォーマットは固定だが、毎回繰り返し作成する必要がある
• 情報の漏れが起きやすく、スタイルが統一されない
• 経営層が求めるのは結論であり、原始資料ではない

典型的なアプリケーション

• 自動日報生成
• 会議議事録の整理
• 業界ニュースダイジェスト
• 営業・運用週報の生成
• 経営層向け報告ドラフトの生成

なぜこのシナリオが AI に適しているのか

レポート系タスクは本質的に以下の特徴を持つことが多いです。

• 高い構造性
• 低い差異性
• 高い繰り返し性
• 固定フローに分解可能

したがって、Workflow による自動化構築に天然に適しています。企業は必ずしも AI に最終稿を直接生成させることを求めませんが、通常はまず使える初稿を形成してくれることを非常に期待しています。

五、部門型効率化ツール

比較的汎用的なシナリオに加えて、企業は通常、より細分化された部門型 AI アプリケーション段階に段階的に移行していきます。

例えば

人事部門

• 休暇・制度 Q&A
• 採用 FAQ
• 候補者情報のサマリー

経理部門

• 経費ルール Q&A
• 経費精算書のチェック
• 請求書情報の抽出

法務部門

• 契約事前審査
• リスク条項の提示
• テンプレート比較

営業・マーケティング部門

• 顧客資料の整理
• 商談議事録の生成
• 競合情報の集約

IT・情報システム部門

• 社内サポートボット
• 操作マニュアル Q&A
• 権限申請フローアシスタント

この種のシナリオの構築パスは通常、まず全社が理解できるアプリケーションから着手し、その後段階的に各部門の具体的なビジネスプロセスに深化していく形です。

六、企業が AI プラットフォームを評価する際に通常気にすること

「何ができるか」に加えて、企業が AI プラットフォームを評価する際には通常、以下の点も特に注目します。

1. データの保管場所

特に社内文書、契約書、規程、顧客資料を扱う場合、データ境界は非常にコアな問題です。

2. 構築の担当者とメンテナンスの担当者

一つのプラットフォームが少数のエンジニアしか長期的にメンテナンスできなければ、ビジネスサイドが構築や拡張に真に参加することは困難です。

3. 小規模パイロットが先行可能か

多くの組織は、まず部門レベルの PoC で価値を検証してから拡大を判断することを好みます。

4. ガバナンスが容易か

例えば、権限、監査、ログ、バージョン管理、コンプライアンス要件など。

5. 単一シナリオからプラットフォーム能力へ拡張可能か

これが Dify のようなプラットフォームが広く注目される重要な理由の一つでもあります。シンプルな Q&A から着手し、段階的に Workflow、Agent、マルチモデル接続へ拡張できるからです。

七、なぜこれらのシナリオが Dify に適しているのか

以上のニーズから分かるように、企業が本当に必要としているのは通常、単独のモデルではなく、モデル、ナレッジ、プロセス、ツール呼び出しを組織できるアプリケーション層です。

これこそが Dify がこの種のニーズを担うのに適している理由です。統一プラットフォームの形で複数のシナリオをカバーできるからです。

• Chatbot：カスタマーサポートと FAQ に適している
• Knowledge：規程、文書、ナレッジ検索に適している
• Workflow：レポート生成、前処理、情報集約に適している
• Agent：データ照会、ツール呼び出し、アクション実行に適している

したがって、企業にとって Dify の意義は単なる「一つの AI ツール」ではなく、パイロットから段階的に正式な能力構築へと発展できるプラットフォーム層に近い存在です。

八、より現実的な導入順序

企業の実際の導入パスを観察すると、より一般的な順序は以下の通りです。

1. まず FAQ またはナレッジ検索に取り組む
2. 次に文書処理とサマリーに取り組む
3. さらに Workflow 自動化に取り組む
4. 最後に段階的に Agent とクロスシステム呼び出しへ拡張する

これは第一段階で企業が最も重視するのが通常以下であるためです。

• リスクが低い
• 価値が明確
• パイロットが迅速
• ビジネス部門が参加できる

この観点から、カスタマーサポート、文書処理、社内ナレッジ検索、レポート生成が高頻度ニーズとなっているのは偶然ではなく、企業の AI 導入が最も成功しやすい出発点に位置しているからです。

まとめ

企業の実践から見ると、高頻度ニーズは必ずしも最も想像力のある汎用 Agent のナラティブではなく、多くの場合日常業務に最も近い課題です。

• カスタマーサポートと Q&A 対応
• 文書処理と情報抽出
• 社内ナレッジ検索
• レポート生成とサマリー自動化
• 部門型効率化ツール

これらのシナリオが重要なのは、明確なビジネス価値を持ち、検証可能かつ拡張可能な導入パスを形成しやすいからです。

多くの企業にとって、より効果的な戦略は最初から「万能 AI」を目指すことではなく、まず高頻度で繰り返し発生し、標準化可能なタスクをしっかりこなし、その後に点から面へ段階的に拡張していくことです。

そしてこれこそが、Dify のようなプラットフォームが最も力を発揮できる場面でもあります。一つの具体的なビジネスシナリオから始め、AI を組織内部で真に活用できる能力として段階的に定着させていくこと。

MCP（Model Context Protocol）とは何か：なぜ AI のツール呼び出しが標準化されるのか

ここ最近、MCP は AI 分野で議論頻度の非常に高いキーワードの一つとなっています。その重要性は、モデルに初めてツール呼び出し能力を持たせたことにあるのではなく、モデルと外部ツール、データソース、ビジネスシステム間の接続関係を、より統一された方法で定義しようとし始めたことにあります。

一言でまとめると：

MCP は、モデルとツール間の連携方法を段階的に標準化するためのプロトコルです。

MCP が解決する中心的な課題は「AI がツールを呼び出せるかどうか」ではなく、「異なるモデル、異なるプラットフォーム、異なるツール間で、より一貫した方法で相互理解できるかどうか」です。

一、MCP 以前、AI のツール呼び出しにはどんな問題があったか

MCP が登場する以前も、AI がツールを呼び出すことはもちろん実現可能でしたが、実装方法は往々にして非常に断片的でした。

よくある状況は以下の通りです。

• あるモデルを Slack に接続するには、個別の方式が必要
• 同じモデルを Notion に接続するには、また別の方式が必要
• プラットフォームを変更すると、ツールの接続方法も変更が必要になることが多い
• モデルのアップグレードや切り替え時に、接続コードの再適応が必要になることが多い

これにより、いくつかの直接的な問題が生じます。

1. ほぼすべての接続がカスタム実装を必要とする
2. ツール数が増えるほど、接続の複雑度が増す
3. モデルやプラットフォームの変更時に、移行コストが明らかに増加する
4. モデル能力の進化は速いが、接続層は長期的に断片化状態にある

多くのチームが実際に遭遇するボトルネックは、モデル能力自体ではなく、モデルとビジネスツール間の接続層にあります。

二、MCP が実際に標準化しているものは何か

MCP が標準化しているのは、特定の具体的なツールではなく、モデルとツール間のインタラクション方式です。

より具体的に言えば、以下の問題への回答を試みています。

• モデルはツールが何をできるかをどう知るのか
• ツールは自身の能力、パラメータ、返却構造をどう記述するのか
• モデルはどのように呼び出しを開始するのか
• ツールが結果を返した後、モデルはどう処理を続けるのか

統一プロトコルがない場合、これらは各プラットフォーム、各プラグイン、各開発者が個別に取り決めに依存していました。MCP の価値は以下にあります。

異なるシステムに散在していたプライベートな取り決めを、より汎用的なプロトコル層に引き戻すこと。

三、なぜ MCP が「AI 世界の USB-C」に例えられるのか

MCP を USB-C に例える人は多く、この比喩は非常に直感的です。

USB-C の価値はディスプレイ、キーボード、ハードディスクを発明したことではなく、接続方式を統一し、異なるデバイス間の接続を標準化しやすくしたことにあります。

MCP が AI の世界で持つ意義も同様です。

• メールシステムを発明するわけではない
• データベースを発明するわけではない
• 検索、ドキュメント、カレンダーツールを発明するわけではない

そうではなく、これらの外部能力がモデルに対面する際に、より一貫した方法で自身を記述し、公開し、呼び出されることを可能にするのです。

この観点から見ると、MCP の真の意義は特定のツールにではなく、接続エコシステム全体の進化にあります。

四、なぜ MCP がツール呼び出しをより標準化するのか

ツール呼び出しが本当に「標準化」されているかどうかの鍵は、呼び出しが可能かどうかではなく、呼び出し行動が十分に予測可能・移行可能・再利用可能かどうかにあります。

MCP の価値は主に以下の四つの面で発揮されます。

1. ツールの能力がより明確に記述できる

ツールがモデルに呼び出されるためには、少なくとも以下を明確に説明する必要があります。

• それは何か
• 何ができるか
• どのような入力パラメータが必要か
• どのような結果を返すか

これらの情報が統一された方法で表現できるようになると、モデルやプラットフォームのツールに対する理解コストが大幅に低下します。

2. モデルとツール間の結合度が低下する

過去、多くのツール呼び出し方式は特定のプラットフォームに強く依存していました。

今日あるプラットフォームで使えても、別のプラットフォームに変えると再接続が必要になり、今日あるモデルで呼び出せても、モデルを変えると個別の適応が必要になることがありました。

プロトコルが統一に向かえば、モデルとツールの関係は「互いに深く結合する」のではなく、「標準インターフェースを通じて連携する」ことにより近くなります。

3. ツール接続がエンジニアリング課題から設定課題へ段階的に移行する

これはエンジニアリング作業がなくなるという意味ではなく、過去はグルーコードの手書きに依存せざるを得なかった部分が、今後はますます以下に変換される可能性があるということです。

• ツール能力の記述
• 認証方式の設定
• 呼び出し境界の設定
• 権限と動作の制御

接続コストが低下すれば、真に重要な問題は「どう接続するか」から「なぜ接続するか、何を接続するか、どうガバナンスするか」に移行します。

4. クロスプラットフォームの再利用能力が向上する

ツールが MCP を通じて能力を公開すれば、その価値は特定のプラットフォーム内での使用に限定されず、MCP をサポートする複数のシステムからの接続が可能になります。

これはエコシステム全体の構築方法を変えることになります。

プラットフォームはそれぞれ完全に独立したプラグイン体系を維持する必要がなくなり、プロトコル層を通じてますます多くの能力を共有できるようになる可能性があります。

五、MCP が Dify のようなプラットフォームにとって何を意味するか

Dify のような AI アプリケーションプラットフォームにとって、MCP の価値は特に顕著です。

Dify 自体が非常に重要な位置にあるからです。

• 一方ではモデルに接続
• 他方ではナレッジベース、ワークフロー、ツール、ビジネスシステムに接続

統一プロトコルがなければ、プラットフォームは大量のプラグインに依存するか、異なるツールごとに異なる接続方法を維持する必要がありました。MCP がもたらす変化は以下の通りです。

• Dify が構築したアプリケーション能力をさらに外部に公開できる
• 外部の MCP Server も Dify の Agent やフローに取り込める
• ツール呼び出しが「プラットフォーム固有の能力」から段階的に「プロトコル能力」に移行し始める

これにより、Dify はアプリケーション構築プラットフォームであるだけでなく、企業の AI 接続体系の一部となることがより容易になります。

六、MCP と API の違いは何か

MCP に初めて触れる多くの人が質問するのは以下です。

「これは API と何が違うのか？」

両者は関連していますが、同一ではありません。

API は能力そのものに近い

例えば天気 API、メール API、データベース API は、本質的にシステム能力のインターフェースです。

MCP はモデルがこれらの能力にアクセスする際の連携方式に近い

注目するのは以下です。

• モデルがツールをどう理解するか
• ツールがモデルに対してどう能力を公開するか
• パラメータと返却結果がどう統一的に記述されるか
• 呼び出しプロセス全体がどうより一貫して組織されるか

したがって、以下のように理解できます。

API はツール自体の能力公開であり、MCP はモデルとツール間のより標準化されたインタラクションプロトコルです。

七、MCP がもたらし得る変化

MCP が発展を続ければ、最も直接的な変化は通常三つのレベルに現れます。

1. モデル競争が部分的に接続能力の競争に移行する

将来の競争は「どのモデルが最も強いか」だけでなく、以下も含まれる可能性があります。

• 誰が企業システムに接続しやすいか
• 誰が外部能力を調整しやすいか
• 誰がワークフロー内の実行ノードとして最も適しているか

2. AI ツールエコシステムがよりモジュール化される

モデル、プラットフォーム、ツール、ビジネスシステム間の境界が徐々に明確になります。

これは企業が特定のクローズドエコシステム製品に完全に縛り付けられる必要がなくなり、より柔軟な方法で能力を組織できることを意味します。

3. 設計の問題が接続の問題より重要になる

接続方式がますます標準化されると、本当に差をつけるのは「接続できるかどうか」ではなくなり、以下になります。

• どのツールを接続するか
• どのシナリオで呼び出すか
• モデルにどの程度の権限を与えるか
• どのステップは引き続き人的制御を保持するか

つまり、AI アプリケーションの重点はますます「技術的な接続」から「ワークフロー設計とガバナンス設計」に移行していきます。

八、MCP は万能の答えではない

もちろん、MCP はプロトコルを採用すればすべての問題が自動的に解消されることを意味するわけではありません。

少なくとも以下の現実的な制約を受けます。

• ツール側が本当に標準に従って能力を公開しているか
• プラットフォーム側が十分な MCP サポート能力を持っているか
• 権限制御が明確に設計されているか
• 企業がキーシステムをこの種のオープンな呼び出し体系に接続する意思があるか

さらに、標準化は安全性とイコールではなく、ガバナンスが自動的に完了することもイコールではありません。

ツールが標準化された呼び出し方式を既に備えていたとしても、企業は引き続き以下を明確にする必要があります。

• 誰が呼び出せるか
• どのシナリオで呼び出すか
• 何を読み取り、何を書き込めるか
• 呼び出しが失敗した場合の対処方法

したがって、MCP が解決するのは「接続方式の標準化」の問題であり、「すべての接続リスクが自動的に消える」問題ではありません。

まとめ

MCP が注目に値する理由は、AI に初めてツール呼び出しを学ばせたからではなく、元来高度にプライベート化され、一回限りの適応に依存していた接続モデルを、より標準化された段階へと段階的に推し進めているからです。

長期的に見ると、その真の意義は「より速く接続できる」ことだけでなく、AI エコシステム全体をより組み合わせ可能なシステムに近づけることかもしれません。

• モデルは理解と生成を担当
• ツールは能力の実行を担当
• プラットフォームは組織とガバナンスを担当
• プロトコルはそれらをより安定的に接続することを担当

これが、MCP が今日特に重要である理由です。MCP は単なる技術用語ではなく、AI が「チャットができる」から「システムに接続できる」へと進む過程における、非常に重要な基盤レイヤーの変化です。

RAG の核心的な問題：なぜナレッジベースの検索結果が不正確になるのか ── チャンク戦略から embedding モデル選定まで

多くのチームが RAG を構築する際、最初に注目するのは通常、生成モデルです。

• どの大規模モデルで回答するか
• どのプラットフォームで構築するか
• プロンプトをどう書くべきか

しかし、本番運用後に最も一般的に発生する問題は「モデルが回答できない」ことではなく、「システムがそもそも正しい資料を検索できていない」ことです。

言い換えれば、RAG の核心的な問題は通常、生成側ではなく検索側にあります。

検索結果そのものが不正確であれば、後続のモデルが強力であるほど、むしろ誤ったコンテキストの上にもっともらしい、実際には的外れな回答を生成しやすくなります。

本記事ではこの問題を中心に展開します。なぜナレッジベースの検索結果がしばしば不正確になるのか、そしてチャンク戦略から embedding モデル選定まで、企業が実践においてどう理解し対処すべきかを説明します。

一、なぜ RAG はしばしば「不正確」に見えるのか

RAG の理想的なフローは通常以下の通りです。

ユーザーの質問
→ システムがナレッジベースから最も関連性の高いコンテンツを検索
→ モデルがそのコンテンツに基づいて回答を生成

問題は主に第二ステップに集中します。現実には、検索の不正確さには通常三つの典型的な表れがあります。

1. 資料は明らかに存在するのに、検索されない
2. 検索はヒットしたが、最も重要なその段落ではない
3. 多くのチャンクが検索されたが、ノイズが多すぎて、かえって回答品質が低下する

多くのチームはこれらの問題を「大規模モデルが十分に安定していない」と帰結しますが、実際にはより一般的な原因は通常以下です。

• 文書のチャンク分割方法が不合理
• データクリーニングが不十分
• ユーザーの質問と文書の表現方法に明確なセマンティックギャップがある
• embedding モデルと業務コーパスが不一致
• 検索パラメータがシナリオに応じて調整されていない

二、第一層の問題：チャンク戦略が検索の上限を決定する

RAG の基本動作の一つは、長い文書を複数のチャンクに分割し、これらのチャンクに対してベクトル化と検索を行うことです。

問題は、文書が分割されると、元々完全なコンテキストに属していたセマンティックな関係が破壊される可能性があることです。

典型的な例

元の文書の文は以下のようなものかもしれません。

• 「従業員は入社後六ヶ月経過後に10日間の年次有給休暇を取得できます。」

チャンク分割後に以下のみが保持された場合：

• 「六ヶ月経過後に10日間取得可能」

この文は一部の情報を保持していますが、コンテキストから切り離されると、その真の意味は曖昧になります。年次有給休暇、手当、試用期間、研修のいずれについて述べているのか、システムは自然に判断できません。

これが多くの RAG システムで最も一般的な第一カテゴリの問題です。情報はまだ存在するが、チャンク分割後にセマンティクスが不完全になっている。

三、チャンクは小さいほど良いわけでも、大きいほど良いわけでもない

多くの実践において、チームは「チャンクをより小さく分割すれば、検索がより精確になる」という直感を形成しがちです。

しかし、実際にはそれほど単純ではありません。

チャンクが小さすぎる場合の問題

• 文脈が失われる
• 一つの完全なルールが複数の断片に分割される
• 検索ヒット後、モデルが取得するのは不完全なコンテキスト

チャンクが大きすぎる場合の問題

• ノイズが増加する
• 複数のテーマが同一チャンクに混在する
• 検索はヒットしたが、真に重要な情報が長い段落に埋もれる

したがって、チャンク戦略の本質は二つの事項のバランスを取ることです。

• セマンティックの完全性
• 検索の集中度

より合理的な実践方法

異なる文書タイプには、通常異なる分割方法を採用すべきです。

• 制度系文書：条項または章・節単位で分割
• FAQ 系文書：質問と回答のペアで分割
• 契約系文書：条項単位で分割
• 製品文書：機能ポイントまたはテーマ単位で分割

つまり、より効果的なチャンク戦略は通常、固定文字数ではなく、文書のセマンティック構造に基づいて分割するものです。

四、第二層の問題：質問方法と文書の表現方法の間に明確なギャップがある

RAG が不正確になるもう一つの一般的な原因は、ユーザーの質問とナレッジベース文書の表現方法の差異です。

例えば、ユーザーは直接以下のように質問します。

• 「休暇は何日ありますか？」
• 「これは経費精算できますか？」
• 「台風の時は何に注意すべきですか？」

一方、文書中の表現は往々にしてより正式です。

• 「年次有給休暇の付与日数」
• 「旅費精算規程 第八条」
• 「災害時の行動基準」

ユーザーの質問は通常より口語的、より曖昧、より圧縮されます。文書の表現はより正式、より完全、より専門的です。セマンティクス上は関連していても、ベクトル空間上の距離が十分に近いとは限りません。

これが、ますます多くのチームが Query Rewrite や HyDE などの拡張戦略を導入する理由です。

• まずユーザーの質問を規程言語や文書言語に近い形にリライトする
• リライト後のクエリで検索に入る

本質的に見ると、この種の方法は「質問方法」と「文書の表現方法」間のギャップを埋めるものです。

五、第三層の問題：データ品質は通常モデル選択より重要

多くの RAG システムのパフォーマンスが不安定な理由は、戦略が高度でないからではなく、基盤データそのものが十分にクリーンでないからです。

よくある問題は以下の通りです。

• 同じコンテンツの複数バージョンがアップロードされている
• 旧版と新版の規程が混在している
• PDF テキスト抽出のエラー
• OCR スキャン品質が不安定
• 一つの文書に複数の無関係なテーマが混入している
• ヘッダー・フッター、ページ番号、印章などのノイズが本文に入っている

このような状況では、どんなに優れた embedding モデルでも、低品質データに対してベクトル化を行うことしかできません。

したがって、非常に重要な原則は以下の通りです。

RAG の検索品質は、まずデータの入口が十分にクリーンかどうかで決まります。

アップロード前のクリーニング、重複排除、バージョン管理、構造整理は、多くの場合、後工程の複雑な調整よりも優先的に投資する価値があります。

六、なぜ embedding モデルの選定が極めて重要なのか

多くのプラットフォームでは、embedding はデフォルトコンポーネントとして扱われ、あれば十分使えるかのように見えます。

しかし実際には、embedding モデルはシステムが「類似」をどう理解するかを直接決定します。

ベクトル検索の本質はキーワードマッチングではなく、embedding モデルがテキストをセマンティック空間にどうマッピングするかだからです。

これが意味すること

同じ文が、異なる embedding モデルでは異なるセマンティック近接関係を形成する可能性があります。例えば：

• 英語技術コーパスに長けたモデルもある
• 日本語やビジネステキストに適したモデルもある
• 短文クエリに適したモデルもある
• 長文コンテキストの圧縮においてより安定したモデルもある

企業のナレッジベースが主に規程、契約、社内規範などのビジネスコーパスであるにもかかわらず、このタイプのテキスト構造に適していない embedding モデルを選択してしまうと、検索の不正確さは非常に自然な結果です。

七、embedding モデルはどう評価すべきか

企業の実践において、embedding モデルの選定では通常少なくとも四つの次元を考慮すべきです。

1. 言語の適合性

ナレッジベースが主にどの言語で、ユーザーが主にどの言語で質問するか。

ナレッジベースとユーザークエリの言語が異なる場合、クロスリンガルなセマンティックアラインメントにおけるモデルのパフォーマンスに重点を置く必要があります。

2. テキストタイプの適合性

FAQ、規程、契約、製品文書、ニューステキストのいずれか。異なるコーパスタイプは通常、異なるパフォーマンス特性に対応します。

3. 長さと粒度のパフォーマンス

短文マッチングに適したモデルもあれば、長い段落のセマンティック圧縮においてより安定したモデルもあります。

4. コストと速度

企業が本番リリースする際には、以下も考慮する必要があります。

• インデックス構築コスト
• インデックス再構築コスト
• 検索レスポンス速度
• ローカルまたはプライベートデプロイのサポート有無

したがって、embedding モデルの選定は「どれが最も先進的か」だけを見るのではなく、「現在のビジネスコーパスと実際のデプロイ条件に最も適したもの」を重点的に見るべきです。

八、なぜ単に大規模モデルを入れ替えるだけでは RAG の問題は通常解決しないのか

チームが RAG のパフォーマンスが悪いと感じた場合、最初の反応としてよくあるのは、より強力な生成モデルへの入れ替えです。

しかし、検索で取得したコンテキスト自体が不正確であれば、どんなに強力な生成モデルでも根本的には問題を解決できません。できることは通常以下のいずれかに限られます。

1. 誤ったコンテキストに基づいて誤った回答を生成する
2. ノイズの多いコンテキストの中で要点から外れた回答を生成する
3. 資料不足の場合、常識で補完する

これが、実際の構築において以下の順序での最適化がより推奨される理由です。

1. データクリーニング
2. チャンク設計
3. クエリリライトまたは検索拡張
4. embedding モデルの評価
5. 最後に生成モデルとプロンプトの最適化

九、より現実的な最適化順序

企業が社内 RAG システムを構築中であれば、以下の順序で問題を優先的に調査することを推奨します。

第一ステップ：データ品質を確認する

• 重複文書がないか
• 旧版資料が混入していないか
• PDF のテキスト抽出は安定しているか
• コンテンツがテーマ別に合理的に分割されているか

第二ステップ：チャンク戦略を確認する

• 純粋な文字数ではなくセマンティック構造に基づいて分割しているか
• コンテキストが切断される問題がないか
• 一つのチャンクが複数のテーマをカバーしていないか

第三ステップ：クエリ方法を確認する

• ユーザーの質問が口語的・曖昧すぎないか
• Query Rewrite や HyDE が必要か
• マルチターン対話で指示代名詞の解消が必要か

第四ステップ：embedding モデルを確認する

• 現在の言語に適しているか
• 現在の文書タイプに適しているか
• 実際の比較テストを行ったか、デフォルトオプションをそのまま使用していないか

第五ステップ：検索パラメータを確認する

• Top K が合理的に設定されているか
• 重複チャンクが結果を占有していないか
• リランキングや付加的な検索戦略が必要か

十、RAG の本質は「資料を入れること」ではない

多くの人は RAG を以下のように理解しています。

「会社の資料をアップロードすれば、AI が理解してくれる。」

しかしシステムの観点から見ると、RAG は検索システムにより近いものであり、生成モデルはこのシステムの最終層の表現能力に過ぎません。

その鍵は「どれだけ記憶しているか」ではなく、以下です。

• 正しいタイミングで
• 正しい場所から
• 正しいコンテキストを見つけ
• それをモデルに組織化と出力を任せる

したがって、RAG の核心は「ナレッジベースがあるかどうか」ではなく、「検索システムがあなたの文書構造とユーザーの質問を真に理解しているか」です。

まとめ

ナレッジベースの検索結果が不正確になるのは、通常単一の問題ではなく、複数の層が重なった結果です。

• チャンク分割方法が不合理
• データ品質が不十分
• ユーザーの質問と文書表現のギャップが大きすぎる
• embedding モデルとコーパスが不一致
• 検索パラメータがビジネスシナリオに沿って調整されていない

したがって、RAG の核心的な問題は「モデルにどうすればもっとうまく回答させるか」ではなく、以下です。

回答されるべきコンテンツをシステムにどうすればまず見つけさせるか。

この順序を整理すれば、元々「モデルが十分に賢くない」ように見えた多くの問題が、より具体的で解決に適した検索エンジニアリングの問題として還元されることになります。

プロンプトエンジニアリングの誤り：日本企業に最も多い 3 つの書き方の間違い

多くの企業が AI アプリケーションの導入を始める際、プロンプトは通常最初に学ばれ、最も即座に結果を出せる部分です。

これは自然なことです。プロンプトは参入障壁が低く、フィードバックが速く、修正コストも比較的低いため、チームが AI に触れる最初の入口になることが多いです。

しかし、実際のビジネス環境では、問題もまたここから生じ始めることが多いです。

多くの企業がプロンプトを万能の解決策として扱っています。

結果として、本来はプロセス設計、ナレッジ整理、権限制御、システム設計に属する問題が、プロンプト層に解決を押し付けられ続けます。最終的に出力が不安定になるだけでなく、チームに「AI は信頼できない」という誤解を与えかねません。

企業導入の観点から見ると、最も一般的な誤りは「プロンプトの書き方を知らない」ことではなく、「プロンプトに本来属さない責任を負わせている」ことです。

以下に、企業の一般的な実践と結びつけて、最も典型的な三つの書き方の間違いを整理します。

誤り一：すべての要求を一つの超長プロンプトに詰め込む

これが最も一般的な間違いです。

よくある書き方には通常以下が含まれます。

• 役割定義
• 十数条のルール説明
• 大量の業務背景
• 出力フォーマット要件
• リスク提示
• 正確性の要求
• 最後に実際のタスク

一見非常に完全に見えますが、実際の使用では問題が多く発生します。

なぜこれが問題なのか

1. 複数の責務が混在している

プロンプト内で同時に以下を担っています：

• 業務ルールの説明
• プロセス制御ロジック
• データ背景の補足
• フォーマット制約
• リスクガバナンス要件

これらは本来すべてを一つのプロンプトに任せるべきではありません。

2. メンテナンス性が急速に低下する

業務が変化すると、チームはどの部分を修正すべきか判断が困難になります。最終的にプロンプトはどんどん長くなり、誰もメンテナンスを続けたがらなくなります。

3. 長いプロンプトは高品質な設計と同義ではない

プロンプトが長いのは、詰め込まれた情報が多いだけであり、構造がより明確であることを意味しません。多くの場合、長いプロンプトはルール同士が矛盾し、境界がより曖昧になるだけです。

より適切なアプローチ

正式なビジネスシナリオでは、異なる責務を異なる層に分割することがより推奨されます。

• 業務知識はナレッジベースに委ねる
• プロセス制御は Workflow に委ねる
• ツール呼び出しは Agent または Tool 層に委ねる
• 出力フォーマットは個別に制約する
• プロンプトは現在のノードが完了すべきタスクのみを担当する

つまり、プロンプトはシステム内の一つの部品であるべきであり、システム全体そのものではありません。

誤り二：「業務知識の欠如」を「プロンプトが十分に強力でない」と誤判断する

これは企業内で非常に高頻度に発生する誤判断です。

AI の回答が不正確な場合、多くのチームの最初の反応は通常以下です。

• 「プロンプトの書き方が不明確だったのでは？」
• 「もう一つルールを追加してみよう」
• 「もう一度、でたらめを言わないよう強調しよう」

しかし実際のプロジェクトでは、より一般的な真の原因は以下です。システム自体が十分に正確で十分に完全な業務知識を取得できていない。

典型的な表れ

例えば：

• 企業の規程がナレッジベースに整理されていない
• アップロードされた文書のバージョンが混乱している
• 検索が本当に関連するコンテンツにヒットしていない
• PDF のテキスト抽出品質が低い
• 質問自体がリアルタイムデータに依存しているが、システムが対応するツールに接続していない

このような状況では、プロンプトをどう修正しても、モデルはナレッジが不足した前提のまま「推測」を続けるしかありません。

なぜこれが構造的な問題なのか

プロンプトはモデルの表現方法を制約できますが、ナレッジそのものを代替することはできません。

コンテキスト自体が誤っていたり、欠けていたり、汚れていたりすれば、どんなに丁寧にプロンプトを設計しても、誤った基盤の上での局所的な修飾にしかなりません。

より適切なアプローチ

結果が理想的でない場合、まず問題がどの層で発生しているかを判断すべきです。

• ナレッジベースがヒットしていないのか？
• 検索戦略に問題があるのか？
• データ自体が不完全なのか？
• 出力表現層の最適化が必要なのか？

多くの企業がこの点で大量の無効な時間を投じています。本来はドキュメントのクリーニング、チャンクの再設計、検索の最適化を行うべきなのに、プロンプト層での調整を繰り返し続けています。

したがって、二つ目の核心的な誤りは以下です。

システム層の問題を、プロンプト層の問題と誤認すること。

誤り三：「正確に、専門的に、簡潔に」とだけ書いて、実行可能な境界を示さない

多くの企業のプロンプトには以下のような表現が頻出します。

• 正確に回答してください
• 専門的に説明してください
• 簡潔明瞭に
• 捏造しないでください
• 企業の視点で回答してください

これらの要求自体には問題はありませんが、真に実行可能な境界が欠けていることが多いです。

なぜこれでは不十分なのか

「正確」「専門的」「簡潔」はいずれも抽象的な要求だからです。

モデルにとって本当に重要なのは以下です。

• 回答の根拠はどこから来るのか
• どの場合に回答を拒否すべきか
• どの場合に追加質問すべきか
• 出力はどのような構造を満たすべきか
• どの程度まで要約して良いか
• どの境界を越えてはならないか

これらの境界が説明されていなければ、モデルは「専門的」の意味を自分で解釈するしかなく、その解釈が企業の要件と一致するとは限りません。

典型的な例

多くの企業は以下のように書きます。

• 「社内資料に基づいて回答してください。でたらめは言わないでください。」

しかし通常、以下について追加の説明はしません。

• 資料が不足している場合はどうすべきか
• 資料間で相互に矛盾する場合はどうすべきか
• 質問が権限範囲外の場合はどうすべきか
• 承認、法務、個別判断に関わる場合はどうすべきか

結果として、モデルは時に過度に保守的になり、時に推測を続け、回答のスタイルと境界が一貫しなくなります。

より適切なアプローチ

企業シナリオでは、抽象的な要求を明確なルールに書き換えるべきです。例えば：

• 提供された参考資料にのみ基づいて回答すること
• 資料に明確な根拠がない場合、必ず「現在の資料では十分な情報が提供されていません」と明示すること
• 常識で企業の規程を補完してはならないこと
• 出力は統一的に「結論 / 根拠 / 推奨アクション」の構造を採用すること
• 承認、法務、個別判断に遭遇した場合、必ず人的対応を推奨すること

境界が実行可能なルールとして記述された時、モデルの行動はより安定しやすくなります。

なぜこれらの間違いが企業環境で特に多いのか

これら三つの問題が高頻度で発生するのは、企業がプロンプトを重視していないからではなく、むしろ企業がプロンプトを最もコストの低い制御手段として見なしやすいからです。

企業にとって、プロンプトの修正は通常以下を意味します。

• システムアーキテクチャの調整が不要
• データの再クリーニングが不要
• ワークフローのやり直しが不要
• 外部システムの再接続が不要

そのため、多くの問題がプロンプト層での解決に優先的に押し付けられます。

しかし、ビジネスが実際に動き始めると、チームは徐々に気づきます。

• プロンプトは確かに重要である
• しかしプロンプトは、本来担うべきその部分の問題しか解決できない

プロンプトがナレッジ構造、プロセス設計、権限制御、ガバナンス境界の責務を強いられると、問題は通常ますます複雑化するだけです。

より成熟した理解方法：Prompt Engineering からシステム設計へ

企業は AI の使用過程で、通常一つの認知の転換を経験します。

第一段階の問題は通常：

「プロンプトをどうすればもっとうまく書けるか？」

より成熟した段階では：

「どの問題は本来プロンプトで解決すべきではないか？」

正式なプロジェクトでは、AI アプリケーションをシステム層の観点から理解し、少なくとも以下の層に分解することがより推奨されます。

• Prompt 層：現在のノードの動作を制約する
• Knowledge 層：業務根拠を提供する
• Workflow 層：プロセスと状態を組織する
• Tool 層：リアルタイム能力とアクション実行に接続する
• Governance 層：権限、境界、監査を制御する

このような理解方法に従えば、元々プロンプトに積み上げられていた混乱した問題は、自然に分解されていきます。

企業向けの簡易チェックリスト

チームが現在のプロンプト設計に問題が生じていると疑う場合、素早くセルフチェックを行えます。

以下の現象が見られる場合、注意が必要

• プロンプトが際限なく長くなり、ルールがどんどん増えている
• 業務知識、プロセスロジック、出力フォーマットを同時に記述している
• 回答が不正確な時、プロンプトへの追記を続けるだけ
• システムの問題とプロンプトの問題を区別できていない
• 抽象的な要求が多く、実行可能なルールが少ない

より効果的な判断方法は、まず自分に三つの質問をすること

1. この問題は本当にプロンプトで解決すべきか？
2. ナレッジベース、ワークフロー、ツール層が担うべきではないか？
3. 現在のプロンプトには、実行可能で検証可能な境界が明確に定義されているか？

まとめ

プロンプトエンジニアリングはもちろん重要ですが、企業で最も一般的な問題は「プロンプトの書き方を知らない」ことではなく、「プロンプトに本来属さない過剰な仕事を負わせている」ことです。

最も典型的な三つの間違いは、本質的にすべて同一の問題を指し示しています。

システム設計の問題を、プロンプト記述の問題に圧縮してしまうこと。

したがって、より成熟したプロンプト実践とは、プロンプトを際限なく長くすることではなく、システムの責務分担をどんどん明確にすることです。

• プロンプトが担うべきことは、明確に書く
• プロンプトが担うべきでないことは、ナレッジ、プロセス、ガバナンス層に委ねる

企業がこれを実現できた時、プロンプトは「試行錯誤を繰り返す書き方テクニック」から、「安定したシステム内の明確な指示」へと真に変わります。

AI Agent の限界：どのタスクを Agent に任せるべきでないか

AI Agent は直感的な印象を形成しやすいものです。目標を与えれば、自らタスクを理解し、自らツールを呼び出し、自らプロセスを実行し、最終的に仕事を完了してくれる、と。

この想像は完全に間違いではありません。Agent は特定のシナリオにおいて確かに非常に有用であり、特に外部ツールの呼び出し、マルチステップタスクの処理、一定の動的意思決定が許容される業務に適しています。

しかし、実際のビジネスに入る際には、まず一つの前提を認める必要があります。

Agent は万能の実行体ではなく、特定のタスク構造にのみ適用可能なシステム形態です。

タスク自体が Agent に適していない場合、その「自律性」を強調すればするほど、リスクは通常高くなります。

本記事ではこの点を中心に、どのタスクが Agent に適さないか、そして企業が Agent を設計する際にどの境界を優先的に考慮すべきかを説明します。

一、まず明確にすべきこと：Agent はどのタスクの処理に長けているか

限界を議論する前に、まず Agent の適用範囲を明確にする必要があります。

通常、Agent は以下のタイプのタスクにより適しています。

• 目標は明確だが、プロセスパスは動的に選択できる
• 外部ツールやシステムの呼び出しが必要
• 一定程度の試行錯誤と反復が許容される
• プロセスの完全固定への要求が高くない
• 最終結果に合理的な範囲があり、唯一の正解ではない

例えば：

• 資料を収集して整理する
• 複数のシステムに問い合わせてサマリーを生成する
• ツールを呼び出して標準的なアクションを完了する
• オープンな情報環境で探索的タスクを実行する

しかし企業の実践では、よくある問題はまさに、このカテゴリに属さない多くのタスクが誤って Agent に委ねられることです。

二、Agent に適さない第一のタスク：高確実性・低容錯タスク

以下を要求するタスクであれば：

• すべてのステップが厳密に正確でなければならない
• プロセスが完全に予測可能でなければならない
• 一旦間違えると、結果が明白でコストが大きい

通常、直接 Agent に任せるのには適しません。

典型的なシナリオ

• 財務決算
• 支払承認
• 契約の最終確定
• 生産制御指令
• 権限変更とアカウント開設
• 法務、コンプライアンス、監査における重要な意思決定アクション

なぜ適さないのか

Agent の本質は、一定の目標制約の下で自律的に意思決定を行うことです。これは以下を天然に伴うことを意味します。

• パスが完全には固定されない
• 呼び出し順序が変化し得る
• 曖昧な入力に対する解釈に差異がある
• 例外状況の処理に不確実性がある

高確実性タスクにおいて組織が本当に必要としているのは、通常「自律的に完了する」ことではなく「規定通り正確に実行する」ことです。

この種のタスクには通常以下がより適しています。

• 固定 Workflow
• 明確なルールエンジン
• 人的レビューノード
• 厳密なステートマシン制御

つまり、容錯余地が極めて小さいタスクであるほど、Agent に制御権を大幅に委ねるべきではありません。

三、Agent に適さない第二のタスク：責任範囲が不明確なタスク

企業にはもう一つ、一見 Agent に自律処理させるのに適しているように見えて、実際にはリスクがより高いタスクがあります。それは責任範囲が明確でないタスクです。

例えば

• ある契約に署名してよいかどうかの判断
• ある顧客に特別融資を認めてよいかの判断
• ある制度が特殊ケースに適用されるかの判断
• 権限外承認を許可するかの決定
• 社内紛争の処理方法の決定

なぜこの種のタスクのリスクが高いのか

これらは単純な情報検索やアクション実行の問題ではなく、以下に関わるからです。

• 権限と責任の分担
• 状況判断
• ルール解釈
• リスク負担の主体

Agent にこの種の決定を直接させると、問題はその判断が正確かどうかだけでなく、以下にあります。

最終結果の責任を誰が負うのか。

したがって、明確な責任帰属が求められ、人的署名が必要、組織の裏書きが必要なタスクは、すべて Agent に完全に委ねるのには適しません。

四、Agent に適さない第三のタスク：目標自体が高度に曖昧なタスク

Agent は曖昧なタスクの処理に長けていると思われがちですが、より正確に言えば、Agent が得意なのは「目標は明確だがパスがオープン」なタスクであり、「目標自体が不明確」なタスクではありません。

例えば

• 「この件をうまく処理して」
• 「ここに何か問題がないか見て」
• 「ちょっと最適化して」
• 「自分で何とかして完了して」

この種の入力の問題は、実行能力の不足ではなく、タスク定義自体が不完全であることです。

なぜ適さないのか

目標が曖昧な場合、Agent は明確な制約がないまま自らタスク理解を補完しやすくなります。これにより以下が生じます。

• 目標が誤読される
• 実行範囲が拡大する
• 結果は一見積極的に見えるが、方向がすでにずれている可能性がある

したがって、このようなシナリオでは、直接権限を委譲するよりも、まずシステムに以下をさせるのがより合理的です。

• 目標を確認する
• 範囲を明確にする
• 制約条件を確認する
• 成功基準を明確にする

言い換えれば、曖昧な目標は Agent の天然の優位性ではなく、むしろ最も制御を失いやすい出発点であることが多いです。

五、Agent に適さない第四のタスク：強い説明可能性が求められるタスク

ビジネスシナリオの中には、エラーを受容できないのではなく、「なぜこの結果になったか説明できない」ことを受容できないものがあります。

典型的なシナリオ

• リスク管理判断
• 監査提案
• 医療補助判断
• 教育評価
• 人材評価
• 法律意見のサポート

なぜ Agent への直接依存が適さないのか

Agent は部分的な実行ログを保持できますが、複数ラウンドの推論、複数ツール呼び出し、複数ステップの判断を経た後、ある結果に至った完全なチェーンは、常に十分に安定的で十分に明確であるとは限りません。

高い説明可能性が求められるシナリオでは、企業が通常より必要とするのは以下です。

• 各ステップの根拠が明確
• ルールの境界が明確
• データソースが明確
• 最終的な責任が明確

この種のタスクには通常以下がより適しています。

• 固定推論チェーン
• 根拠の強制引用
• 構造化された出力
• 厳密な人機協調プロセス

つまり、「説明可能性」が「実行の柔軟性」より重要であれば、Agent は往々にして第一候補の形態ではありません。

六、Agent に適さない第五のタスク：コアシステムの制御タスク

Agent は企業の「ツール呼び出し」を支援するのに非常に適していますが、コアシステムの高権限制御能力を直接付与すべきという意味ではありません。

例えば

• 本番データベースの変更
• 重要ファイルの削除
• 顧客マスターデータの一括変更
• 高権限運用コマンドの実行
• 財務マスターテーブルへの直接書き込み

なぜリスクがより高いのか

Agent の核心的特徴の一つは、コンテキストに基づいて次のアクションを自律的に判断することです。これは、権限が過大な場合、「間違ったツールを呼び出す」だけでなく、「正しいツールで誤ったアクションを実行する」可能性があることを意味します。

したがって、コアシステムシナリオでは、Agent が担うのに適しているのは以下です。

• 情報の読み取り
• 提案の提供
• ドラフトの生成
• 操作計画の準備

適していないのは以下です。

• 不可逆な操作の直接実行
• 過大な権限の保持
• 人的確認なしでのキーシステムへの書き戻し

七、なぜ企業は Agent を過大評価しやすいのか

企業が Agent に過大な期待を抱きやすい理由は、通常以下のいくつかに起因します。

1. 「自律的にタスクを完了する」というナラティブに惹かれる

「目標を伝えるだけで、自分で完了してくれる」という表現は非常に魅力的ですが、境界設計の重要性を軽視しがちです。

2. Workflow と Agent を混同する

本来固定プロセス制御により適したタスクの多くが、Agent に自由に実行させるべきものと誤認されます。

3. モデル能力をシステム能力と過大評価する

モデルが話せる・推論できることは、システム全体が複雑なビジネスを安定的に実行する能力を持つことと同義ではありません。

企業における実際のシステムは通常、以下が同時に関わります。

• データ
• 権限
• プロセス
• ツール
• 監査
• 例外処理

Agent はこのシステムにおける一つの実行方式に過ぎず、システム全体そのものではありません。

八、より実用的な判断基準

チームがあるタスクを Agent に任せるべきかどうかを判断している場合、まず以下の五つの質問に答えてみてください。

1. このタスクは一定の試行錯誤を許容するか？
2. このタスクの成功基準は十分に明確か？
3. 実行パスが変化しても、結果は依然として受容可能か？
4. エラーの結果は可逆的・制御可能か？
5. 実行権限を安全な範囲に制限できるか？

これらの質問のうち複数の答えが否定的であれば、そのタスクは通常 Agent が主導的に実行するのには適しません。

九、より成熟したアプローチ：Agent には得意な部分のみを担わせる

これは Agent に価値がないという意味ではありません。むしろ、Agent の価値は非常に明確であり、ただ真に得意な部分を担うのがより適切というだけです。例えば：

• 検索
• 調整
• ツール呼び出し
• ドラフト作成
• 集約
• 提案の提供

安易に以下に拡張すべきではありません。

• 最終決定
• 高リスク実行
• 権限・責任の判断
• 不可逆な操作

成熟した企業システムにおいて、より一般的で合理的な方式は以下です。

Agent に前半の情報取得、ツール呼び出し、提案生成を担当させ、高リスクの意思決定と最終実行は人的対応または固定プロセスで担保する。

まとめ

AI Agent の限界は、主にモデルが「十分に賢くない」ことにあるのではなく、多くのタスクが構造的に自律性を持つ実行体に委ねるのに適していないことにあります。

Agent に最も適さないタスクは、通常以下の種類です。

• 高確実性・低容錯タスク
• 責任範囲が不明確なタスク
• 目標が高度に曖昧なタスク
• 強い説明可能性が求められるタスク
• コアシステムの制御タスク

したがって、真に成熟した Agent の設計は「できるだけ何でもやらせる」ことではなく、以下です。

まずタスク構造が Agent に適しているかを判断し、その上で自律度と権限の境界を決定する。

そうすることで初めて、Agent は企業システムにおける効率増幅器となり得るのであり、新たな不確実性の源とはなりません。

オンプレミスで AI アプリケーションをデプロイする必要性：データ主権、コンプライアンス、ネットワーク隔離の実際的な考慮事項

AI アプリケーション構築の初期段階では、多くのチームが SaaS ソリューションを優先的に選択します。これは非常に自然な流れです。SaaS には通常以下の利点があるからです。

• 立ち上げが速い
• デプロイコストが低い
• 試用の障壁が低い
• PoC や初期検証に適している

しかし、AI アプリケーションが正式なビジネス段階に入ると、組織は通常すぐにより現実的な問題に直面します。

これらのデータ、これらのプロセス、これらのシステム接続は、長期的にパブリックなホスティング環境で運用するのに適しているか。

これこそが、オンプレミス（ローカルデプロイ / プライベートデプロイ）が企業の正式な議題となり始める理由です。

本記事は「ローカルデプロイがより先進的かどうか」を議論するのではなく、より現実的な判断基準に焦点を当てます。なぜ企業は特定のシナリオにおいて、AI アプリケーションのオンプレミスデプロイを真剣に検討しなければならないのかを説明します。

一、オンプレミスの本質は「より重い」ではなく「よりコントロール可能」

多くの人がオンプレミスに初めて接する際、直接的に以下のように理解しがちです。

• より複雑
• より高価
• よりメンテナンスが難しい
• 大企業向け

これらの印象は完全に間違いではありませんが、表面的なものです。

企業がオンプレミスを真剣に検討するのは、通常技術的な好みからではなく、管理境界の必要性からです。より正確に言えば、企業が通常コントロールしようとするのは以下の三つの境界です。

• データ境界
• コンプライアンス境界
• ネットワーク境界

これらの境界がビジネスにとって十分に重要であれば、デプロイ方式は単なる技術選択ではなくなり、ガバナンスの選択となります。

二、第一の核心的理由：データ主権

AI アプリケーションが企業シナリオに入ると、接触するのは通常公開テキストだけでなく、組織内部の最もリアルで最もセンシティブなデータ資産です。例えば：

• 社内規程とナレッジ文書
• 契約・法務資料
• 顧客情報
• 財務データ
• 営業記録
• 研究開発資料
• 監査・リスク管理ファイル

これらの内容が AI ワークフローに入った時、企業は自然と一つの問題を提起します。

これらのデータは究極的にどこに保管され、誰がコントロールし、誰がアクセスし、誰がその流れを決定できるのか。

なぜデータ主権の問題に発展するのか

多くの企業にとって、AI はもはや単なるチャットツールではなく、コアな経営情報を読み取り、処理し、統合する能力層に段階的になりつつあるからです。

このような状況で、組織は通常以下を非常に重視します。

• データが指定された環境内にとどまるか
• 外部にホスティングされるか
• リージョンをまたいだ処理が発生し得るか
• アクセスとストレージの制御権を完全に掌握できるか

これらの要件が十分に強い場合、ローカルデプロイまたはプライベートデプロイはもはや加点項目ではなく、前提条件となり得ます。

三、第二の核心的理由：コンプライアンス要件は後回しにできないことが多い

多くの AI プロジェクトはパイロット段階では順調に進みますが、正式デプロイの準備に入ると、コンプライアンスやセキュリティ審査で止まってしまいます。

よくある問題は以下の通りです。

• データが企業指定のリージョンを離れないか
• 業界規制要件を満たしているか
• 監査証跡の要件を満たしているか
• 顧客契約中のデータ処理制約を満たしているか
• 内部資料を外部サービス環境に入れることが許可されるか

特定の業界にとって、これらは最適化項目ではなく、参入の前提条件です。

特にコンプライアンス要件の影響を受けやすいシナリオ

• 金融
• 医療
• 製造業コア研究開発
• 公共部門
• 大企業グループ
• 顧客のセンシティブ情報を扱う B2B サービス

これらの環境では、SaaS の機能がいかに完全であっても、コンプライアンス要件を満たせなければ、正式なビジネスシステムに本当に組み込むことは困難です。

なぜオンプレミスがコンプライアンス要件の一部を満たしやすいのか

ローカルデプロイが本質的により安全だからではなく、通常企業により多くの証明可能・設定可能な制御能力を持たせるからです。例えば：

• データパスがより明確
• アクセス制御がより管理可能
• 監査チェーンの定義がより容易
• 既存のセキュリティアーキテクチャとの統合がより容易
• データの域外移転の問題を追加説明する必要がない

言い換えれば、オンプレミスの価値は以下にあります。企業がセキュリティとコンプライアンスの要件を運用環境に直接実装しやすくなること。

四、第三の核心的理由：ネットワーク隔離は少数のシナリオではない

多くの AI の議論は以下を前提としています。

• システムが安定的にインターネットに接続できる
• 外部 API に継続的にアクセスできる
• クラウドサービスへの依存は合理的かつデフォルトである

しかし現実は常にそうとは限りません。多くの企業の内部環境にはネットワークに関する非常に明確な制約があります。例えば：

• 内部ネットワークと外部ネットワークの隔離
• 本番ネットワークとオフィスネットワークの隔離
• 研究開発環境からの公衆網への直接アクセス禁止
• 高感度システムの外部直接接続禁止

このような環境では、ビジネスが AI の導入を強く望んでいても、パブリック SaaS ソリューションをキーシステムに直接接続することはできません。

この場合のオンプレミスの意義は非常に直接的

AI アプリケーションを企業の既存ネットワーク構造内で自然に動作させることができます。例えば：

• 企業イントラネットへのデプロイ
• ローカルドキュメントシステムへのアクセス
• 内部データベースへの接続
• 既存の認証システムへの接続
• ネットワーク隔離環境での安定動作

つまり、オンプレミスの価値は「データが企業外に出ない」だけでなく、以下も含みます。

AI アプリケーションが企業の現在のネットワーク現実に真に組み込めるようにすること。

五、なぜ多くの企業が SaaS パイロットからプライベートデプロイへ移行するのか

企業の実践において、非常に一般的なパスは以下の通りです。

1. まず SaaS で PoC を行う
2. ビジネス価値を検証する
3. 実際のビジネスデータの接続を開始する
4. セキュリティ、法務、情報システム部門が正式に関与する
5. 最終的にプライベートデプロイまたはハイブリッドデプロイへ移行する

これは矛盾ではなく、むしろ非常に合理的な進化パスです。

SaaS はニーズの検証により適しており、オンプレミスは正式なビジネスの受け皿により適しています。

したがって、企業が本当に考えるべきことは通常「一つのモードだけを選ぶ」ことではなく、以下です。

• どの段階が SaaS に適しているか
• どの段階でプライベートデプロイへ移行すべきか
• どのデータがパブリック環境に入れられるか
• どのデータがローカル境界内に留めるべきか

この観点から、デプロイ方式は一回限りの決定ではなく、進化パスとして理解すべきです。

六、オンプレミスのコストも直視すべき

もちろん、オンプレミスはコストゼロのソリューションではありません。

企業が最初から全面的にプライベートデプロイを採用しない理由は、確かにより重いからです。

一般的なコスト

• インフラの自社構築とメンテナンスが必要
• バージョンアップグレードの対応が必要
• 監視と障害対応が必要
• バックアップ、権限、ネットワーク、監査の設定が必要
• より多くのエンジニアリングと運用リソースが必要

したがって、本当の問題は以下ではありません。

「ローカルデプロイの方が良いか？」

そうではなく：

「現在のビジネスシナリオの境界管理要件は、これらの追加コストを支えるのに十分なほど高いか？」

答えが肯定的であれば、オンプレミスは必要な投資です。答えがまだ否定的であれば、先に SaaS で価値を検証する方が通常より効率的です。

七、どのシナリオでオンプレミスを優先的に検討すべきか

以下のシナリオは、通常ローカルデプロイまたはプライベートデプロイの評価をより優先的に行うべきです。

1. ナレッジベースに高感度の社内資料が含まれる

例えば法務、財務、研究開発、監査、顧客マスターデータ。

2. アプリケーションが複数のイントラネットシステムに接続する必要がある

キー能力が企業内部のデータベース、ファイルシステム、ビジネスシステムに依存しており、これらのシステムが元々外部に出られない場合、ローカルデプロイがより自然です。

3. 業界規制がデータ管理に明確な要件を持つ

例えば金融、医療、公共部門、大規模インフラ関連業界。

4. 企業自体がデータ主権に極めて高い要件を持つ

特に大企業グループ、多国籍組織、データリージョンの厳格な管理が必要な企業。

5. 組織が AI を長期的なインフラとして構築したい

目標が単一ツールではなく、エンタープライズ級の AI アプリケーション基盤であれば、デプロイの制御可能性の重要性は通常継続的に上昇します。

八、より現実的な判断フレームワーク

企業がオンプレミスの必要性を評価する際、以下の五つの質問に優先的に回答できます。

1. この AI アプリケーションはどのレベルのデータを処理するか？
2. これらのデータは外部ホスティング環境に入れることが許可されるか？
3. このアプリケーションはイントラネットシステムへの接続が必須か？
4. 現在の業界規制や顧客契約に明確な制約が存在するか？
5. このシステムの目標は短期パイロットか、長期運用か？

これらの質問の中で、複数の答えが高感度・高制約・高長期性を指している場合、オンプレミスは単なる強化オプションではなく、正式リリースの前提条件となる可能性がより高いです。

九、AI プラットフォームにとって、オンプレミスのサポートは何を意味するか

Dify のような企業向け AI プラットフォームにとって、ローカルデプロイのサポートは非常に重要です。

企業が本当に必要としているのは、単に「AI アプリケーションを作れるかどうか」だけでなく、以下だからです。

• 自社の境界内で運用できるか
• 既存のシステムと安定的に接続できるか
• ガバナンス要件を満たせるか
• パイロットからプラットフォーム化構築へスムーズに移行できるか

プラットフォームがパブリッククラウドでしか運用できなければ、カバーできる企業シナリオは天然に制限されます。逆に、プラットフォームが SaaS とプライベートデプロイの両方をサポートしていれば、企業は異なる段階・異なるデータレベルに応じて、より適切な構築パスを選択できます。

まとめ

AI アプリケーションのオンプレミスデプロイの必要性は、最終的にすべて一つの問題に帰結します。

企業は AI アプリケーションが存在する運行境界を真にコントロールする必要があるか。

その背後にある重要な考慮事項は、通常技術的な好みではなく、三つの非常に現実的な要件です。

• データ主権
• コンプライアンス要件
• ネットワーク隔離

パイロット段階では SaaS で通常十分です。しかし、AI がコアナレッジ、コアプロセス、コアシステムに接触し始めると、ローカルデプロイは単なる「より堅実な選択肢」ではなくなり、「正式に導入できるかどうか」の基盤条件となる可能性があります。

したがって、オンプレミスの必要性は技術チームだけで判断すべきではなく、ビジネス価値、データ感度、ガバナンス要件が共同で決定すべきものです。

phase-2

本フェーズは phase-1 と同じディレクトリ構成で整理し、Dify 協会 Members Only コンテンツに焦点を当てています。

目次

• 2-1 深掘り Use Case（設定詳細付き）
• 2-2 トラブル記録と解決策
• 2-3 Dify Enterprise デプロイベストプラクティス（詳細版）

説明：本フェーズのコンテンツは、公開資料・公開事例・汎用的な企業実践を優先的にベースとして整理しています。公開情報が明らかに不足している部分については、本文中に後日の内部資料補足が必要な旨を記載しています。

phase-2 公開資料候補インデックス

説明：以下は本フェーズの各テーマに関連する公開資料の候補です。note.com、zenn.dev、Dify 公式ドキュメント、Enterprise ドキュメントおよびその他の日本語ページを優先的に掲載しています。

phase-2/2-1/01-制造业设备故障排查机器人.md

• 検索ワード：Dify 製造業 設備 故障 RAG
• note ヒット数：4
• サイト検索ヒット数：2

note.com 候補

• リコー「H.D.E.E.N」が示す暗黙知AI化の本質：4,500エージェントの実績が教える段階的実装の成功法則 | https://note.com/shin48ya/n/n14d3ec2acaf5
• 英単語/熟語リスト＜TOEIC 600＞#1-1 | https://note.com/ginjib/n/nd373bdd52c80
• 英単語/熟語リスト＜TOEIC 600＞#2-1 | https://note.com/ginjib/n/ne592d080cccd
• 【ChatGPTによる和訳】Rocket Lab USA, Inc. (NASDAQ:RKLB) Q4 2024 Earnings Call Transcript | https://note.com/american_stock/n/n21a7d6d00ca2

zenn.dev / 公式ドキュメント / その他日本語ページ

• ローカルLLMの実用性が爆上げ：オフライン環境でも使える … | https://zenn.dev/taku_sid/articles/20250402_local_llm
• Developers Summit 2026 Day2, 3 公開資料・Xアカウント … | https://zenn.dev/h_yoshikawa0724/articles/2026-02-22-developers-summit-2026

phase-2/2-1/02-法务合同比对-Workflow.md

• 検索ワード：Dify 契約書 workflow human in the loop
• note ヒット数：6
• サイト検索ヒット数：8

note.com 候補

• Human-in-the-Loopの活用事例　Difyでの具体的な運用パターン9選 | https://note.com/nocode_solutions/n/n91655a876f4d
• 生成AIをツールから習慣へ。Berkeley Lawのエグゼクティブ講座で再起動します。From Tool to Habit: Rebooting with Berkeley Law’s GenAI Executive Program. | https://note.com/ishii_jumpei/n/n6683a7454a76
• 『エージェンティック AI』：DXデイリーワード | https://note.com/kitorhythm/n/n2a9d9bab6361
• イスラム教に搾取される日本人と苦悩の人生を歩む被害者 Japanese exploited by Islam and victims walking a life of suffering. Englsih after Japanese | https://note.com/aideepdown/n/n32e0b25bbd48

zenn.dev / 公式ドキュメント / その他日本語ページ

• Human-in-the-Loopの活用事例 Difyでの具体的な運用 … | https://zenn.dev/nocodesolutions/articles/62a03c6770b824
• Human-in-the-Loopの概念をDifyに落とし込み、AIの暴走を … | https://zenn.dev/nocodesolutions/articles/df0d883c7d1f79
• AI AgentとKG：L5エージェントを実現する知識基盤 | https://zenn.dev/knowledge_graph/books/knowledge-graph-llm-guide/viewer/kg-and-ai-agents
• Dify チャットフローを AI が生成する仕組みを AI で作った話 | https://zenn.dev/ryoyoshii/articles/05d2ffe846f518
• Build Appで作る業務効率化AI【実例5選】 | https://zenn.dev/unikoukokun/articles/621ab7ed081242

phase-2/2-1/03-社内稟議自动草稿生成.md

• 検索ワード：Dify 稟議 生成 構造化出力
• note ヒット数：0
• サイト検索ヒット数：4

note.com 候補

• 現時点では十分に関連性のある note.com の結果は検出されていません

zenn.dev / 公式ドキュメント / その他日本語ページ

• 2025/04/01付近に発売されたDify本4冊の比較 | https://zenn.dev/arrowkato/articles/dify_book_comparison
• 「AIエージェント」開発について | https://zenn.dev/headwaters/articles/fec5638eab414e
• 2025 AI Agentの現況と課題（勉強会資料） | https://zenn.dev/fl4tlin3/articles/abc18da303dddc
• Developers Summit 2026 Day2, 3 公開資料・Xアカウント … | https://zenn.dev/h_yoshikawa0724/articles/2026-02-22-developers-summit-2026

phase-2/2-1/04-多语言客服-Agent.md

• 検索ワード：Dify 多言語 カスタマーサポート Agent
• note ヒット数：6
• サイト検索ヒット数：8

note.com 候補

• n8nでできること完全ガイド｜業務自動化×AI連携を実践例でわかる | https://note.com/weel_media/n/n17758fb2a49c
• AIエージェント開発フリーランス需要109%増2026年Q1：Lancers×クラウドワークスで今月受注できる高単価AI案件5種と月収15万円への90日ロードマップ | https://note.com/shiodome_098/n/nb86da4189390
• AIエージェントで問い合わせ対応を自動化｜24時間対応を実現する方法 | https://note.com/tateru_ai/n/n919b556b609f
• AIエージェントの業務活用事例10選｜中小企業の導入パターン | https://note.com/tateru_ai/n/ndfc110d90da9

zenn.dev / 公式ドキュメント / その他日本語ページ

• 知識ベースを使用したカスタマーサービスボット | https://docs.dify.ai/ja/use-dify/tutorials/customer-service-bot
• エージェント | https://docs.dify.ai/ja/use-dify/nodes/agent
• AIエージェントのみでBPO 企業を作り上げる方法：Dify+Ollama … | https://zenn.dev/ippeisuzuki/articles/71971d747c101b
• Dify の基礎基本まとめ 〜ノーコードで LLM アプリを開発する〜 ✨ | https://zenn.dev/okikusan/articles/e0ac79e54d1ab0
• Difyを使ってLeSS用語回答Bot（RAG）を実現 | https://zenn.dev/bm_sms/articles/bce457fbc281ce

phase-2/2-1/05-HR-入职文件处理流水线.md

• 検索ワード：Dify 人事 書類 PDF 自動化
• note ヒット数：6
• サイト検索ヒット数：8

note.com 候補

• ノーコードでAIエージェントを作る全手順〜月10万円の副業につなげた実例付き〜 | https://note.com/ample_swan1803/n/n7e54530c77c0
• 「LLMでDXしたい」と言う前に知っておくべき全体像。JTC→コンサル→スタートアップといろんなDXを見てきたワイが整理する | https://note.com/haisupena/n/n9b6ca8024c5f
• 生成AIワークフローの実践：AIの真骨頂である 「業務の自動化」に踏み出す｜第5章 | https://note.com/dxcj/n/nd67a14989562
• 【初心者向け】 チャットボットと何が違う？　自律的に働く「AIエージェント」徹底解説 　導入から活用まで | https://note.com/tomohiko_naba/n/n22d374696739

zenn.dev / 公式ドキュメント / その他日本語ページ

• Azure AI Document IntelligenceのOCR機能を使ってPDFを … | https://zenn.dev/solvio/articles/9d9643ec24dd96
• Human-in-the-Loopの活用事例 Difyでの具体的な運用 … | https://zenn.dev/nocodesolutions/articles/62a03c6770b824
• 【Dify】ナレッジパイプライン調査レポート2/3 - 文脈を理解した「 … | https://zenn.dev/upgradetech/articles/fa118f1eba541c
• 専用教科書！ナレッジベースを作りましょう！ | https://zenn.dev/hamaup/books/6c09e513a52bdc/viewer/fef868
• （ノード）知識検索ノード：ナレッジの取得 → RAG｜Dify完全ガイド | https://zenn.dev/kentaichimura/books/e48a042e40c657/viewer/147487

phase-2/2-2/01-知识库检索结果不相关.md

• 検索ワード：Dify ナレッジ 検索 TopK Score Threshold Rerank
• note ヒット数：0
• サイト検索ヒット数：7

note.com 候補

• 現時点では十分に関連性のある note.com の結果は検出されていません

zenn.dev / 公式ドキュメント / その他日本語ページ

• 【Dify】RAG大全：仕組みと設定を徹底解説 | https://zenn.dev/upgradetech/articles/ac9099a6489abe
• ハイブリッド検索 | 日本語 | https://legacy-docs.dify.ai/ja-jp/learn-more/extended-reading/retrieval-augment/hybrid-search
• チャンク / インデックス / 検索方法 / ReRank / メタデータ | https://zenn.dev/kentaichimura/books/e48a042e40c657/viewer/2fbfb4
• インデックス方法と検索設定を指定 | https://docs.dify.ai/ja/use-dify/knowledge/create-knowledge/setting-indexing-methods
• Rerank | 日本語 | https://legacy-docs.dify.ai/ja-jp/learn-more/extended-reading/retrieval-augment/rerank

phase-2/2-2/02-Workflow-节点超时频繁.md

• 検索ワード：Dify Workflow タイムアウト リトライ 非同期
• note ヒット数：1
• サイト検索ヒット数：1

note.com 候補

• Dify API workflowディレクトリ | https://note.com/aoyama_sys/n/nbd50dac8bce9

zenn.dev / 公式ドキュメント / その他日本語ページ

• Flaky Test におけるパイプラインの再実行 max_auto_reruns … | https://zenn.dev/kameoncloud/articles/0182e15840a92d

phase-2/2-2/03-同一问题每次回答不一致.md

• 検索ワード：Dify Temperature プロンプト 出力 安定
• note ヒット数：6
• サイト検索ヒット数：8

note.com 候補

• 第2回：【Dify】ReActとFunction Callingの技術的差異と使い分け | https://note.com/niti_technology/n/n46032ff32cc1
• 【第7回 ローカルLLM】AIを「システム」から「ツール」へ：全社員が直感操作できるWeb UIの作り方 | https://note.com/eques_ai_/n/n9849da7e4bf4
• 【2026年最新】AITuber・AIキャラクター作成ツール完全まとめ ── 配信ツールからチャットAI、PNGtuberまで全部紹介 | https://note.com/95inari/n/n835d61feb479
• AIに「忖度」をさせない：合議制プロトコルによるAI意思決定の構造改革 | https://note.com/dear_quokka1974/n/n1fc07218f675

zenn.dev / 公式ドキュメント / その他日本語ページ

• LLM | 日本語 | https://legacy-docs.dify.ai/ja-jp/guides/workflow/node/llm
• Dify × Claudeでつくる、2分週報AI | https://zenn.dev/deepflowdesign/articles/dify-claude-weekly-report-ai
• AIエージェントフレームワーク実装比較 | https://zenn.dev/dalab/articles/770a39a24c1940
• 現場で使える！Dify x Pythonハイブリッド開発実践！ | https://zenn.dev/sapeet/articles/edfee5b30d79a8
• （基礎知識）AIエージェントの基本：Function Calling / ReAct | https://zenn.dev/kentaichimura/books/e48a042e40c657/viewer/395147

phase-2/2-2/04-大文件上传失败.md

• 検索ワード：Dify PDF アップロード 大容量 失敗
• note ヒット数：4
• サイト検索ヒット数：8

note.com 候補

• 教員のAIツール選び方完全ガイド──ChatGPT・Claude・Gemini、どれを選ぶ？ | https://note.com/lush_quail8536/n/n8fe031b778b3
• DifyのAIアプリケーション構築ツールと、n8nの外部サービス連携の自動化ワークフローツール組み合わせ工夫 | https://note.com/cognitive_01/n/na21f0db9b41b
• ノーコードで業務にAIを取り入れる時代へ：Dify完全ガイド（2025年最新版） | https://note.com/ranxxx/n/n0d1b2885e172
• ChatGPTとの違いは？Difyのメリット・デメリットを元エンジニアが徹底比較 | https://note.com/hide6631/n/n0a79e1e8a27d

zenn.dev / 公式ドキュメント / その他日本語ページ

• ファイルアップロード | 日本語 | https://legacy-docs.dify.ai/ja-jp/guides/workflow/file-upload
• Weaviate 移行ガイド：クライアント v4 とサーバー 1.27+ への … | https://docs.dify.ai/ja/self-host/troubleshooting/weaviate-v4-migration
• ステップ2：ナレッジパイプラインをオーケストレーションする | https://docs.dify.ai/ja/use-dify/knowledge/knowledge-pipeline/knowledge-pipeline-orchestration
• レッスン 3：ワークフローの頭脳（LLM ノード） | https://docs.dify.ai/ja/use-dify/tutorials/workflow-101/lesson-03
• Dify + Llama 3 で遊んでみる (1) | https://zenn.dev/derwind/articles/dwd-llm-dify01

phase-2/2-2/05-Agent-工具调用陷入死循环.md

• 検索ワード：Dify Agent 無限ループ 最大反復
• note ヒット数：3
• サイト検索ヒット数：7

note.com 候補

• 第1回：【Dify】ReActエージェントの基本構造と「思考・行動・観察」ループ | https://note.com/niti_technology/n/nb8640f15a899
• 効果的な AIエージェント 設計方法：Anthropic公開の資料要約 | https://note.com/kakeyang/n/nf919725fdce0
• OpenAI o1 previewにreflectionプロンプトっぽい動作のエージェントを実装案を考えてもらう | https://note.com/hamachi_jp/n/n87482831981f

zenn.dev / 公式ドキュメント / その他日本語ページ

• エージェント | https://docs.dify.ai/ja/use-dify/nodes/agent
• 繰り返し処理（ループ） | 日本語 | https://legacy-docs.dify.ai/ja-jp/guides/workflow/node/loop
• ループ - Dify Docs | https://docs.dify.ai/ja/use-dify/nodes/loop
• Self-Correction in Coding：Difyでワンショット生成の限界を … | https://zenn.dev/nocodesolutions/articles/1fd0c75476d302
• AIが自ら「検索し直す」。DeepSeek-R1とDifyが作る高度な … | https://zenn.dev/nocodesolutions/articles/0c24477dac9882

phase-2/2-3/01-生产环境-vs-测试环境.md

• 検索ワード：Dify 本番環境 テスト環境 構成
• note ヒット数：6
• サイト検索ヒット数：8

note.com 候補

• 【悲報】9割がハマるDifyの罠7選｜導入で失敗しないためのチェックリスト | https://note.com/sone_ai/n/nfee16bbba037
• ConoHa VPSとは？AIツールを試したい人のための“最初の1台“ガイド | https://note.com/ryo_ai_dev/n/ne69c4d14217c
• 【構築フェーズ③】ツールを設定・構築する | https://note.com/kaizen_workout/n/nee0b96508720
• React 経由の重大脆弱性と、2024〜2025年の Dify 脆弱性をまとめてみた話 | https://note.com/jumao/n/n979d9409ad5c

zenn.dev / 公式ドキュメント / その他日本語ページ

• （ノード）HTTPリクエストノード｜Dify完全ガイド | https://zenn.dev/kentaichimura/books/e48a042e40c657/viewer/a11f91
• Difyの.env.exampleを毎回目視で見てる人へ：安全に同期する … | https://zenn.dev/zozotech/articles/9add3a5c2de5cc
• TerraformでDify AIプラットフォームをAWSに構築する完全ガイド | https://zenn.dev/zuzuzu/articles/dify_building
• モデルプロバイダー - Dify Docs | https://docs.dify.ai/ja/use-dify/workspace/model-providers
• モデルの認証情報を管理 | https://docs.dify.ai/versions/3-5-x/ja/user-guide/model-configuration/manage-model-credential

phase-2/2-3/02-Helm-Chart-values关键参数.md

• 検索ワード：Dify Helm values.yaml 設定
• note ヒット数：2
• サイト検索ヒット数：8

note.com 候補

• DifyをAzure Kubernetes Service (AKS)で動かせるようにしました。 | https://note.com/k_7tsumi/n/n347b0db42499
• 普通のおじさんでも使えるDify | https://note.com/aiojisan2024/n/ne46593daf97c

zenn.dev / 公式ドキュメント / その他日本語ページ

• helmを使って、minikubeでDifyをデプロイしてみた | https://zenn.dev/data_and_ai/articles/703ac71eea4b01
• Difyで作ったLLM ApplicationをAzure Kubernetes Serviceに … | https://zenn.dev/microsoft/articles/dify_on_azure
• Kubernetes on Jetson Linux + Ollama + Dify でローカルLLM … | https://zenn.dev/ussvgr/scraps/81168b96a16bc9
• Dify on Azure | https://zenn.dev/yusu29/scraps/8bc6a603989789
• ACKにデプロイしたDifyのDBをマネージドにする | https://zenn.dev/maipippi/articles/c4b4e7e99c1c65

phase-2/2-3/03-多租户权限设计.md

• 検索ワード：Dify マルチテナント Workspace 権限
• note ヒット数：1
• サイト検索ヒット数：3

note.com 候補

• Dify 弱点 | https://note.com/aoyama_sys/n/n1884f48bc2a3

zenn.dev / 公式ドキュメント / その他日本語ページ

• Dify 触ってみたメモ | https://zenn.dev/yamato0811/scraps/7ba74410173165

• フロントエンドから読み解くDifyアーキテクチャ | https://zenn.dev/takapom/articles/27ed1389beccb7

• 【保存版：Dify導入済の企業向け】n8n導入するべき？Difyとの … | https://zenn.dev/upgradetech/articles/eea37f22313816

phase-2/2-3/04-License-管理实务.md

• 検索ワード：Dify Enterprise License 有効期限 更新
• note ヒット数：2
• サイト検索ヒット数：8

note.com 候補

• CISSPメモまとめ | https://note.com/swign/n/n8edb2b98aa1b
• Linuxのトリセツ | https://note.com/hachilock/n/n68d2dd018011

zenn.dev / 公式ドキュメント / その他日本語ページ

• 環境変数の説明 | 日本語 | https://legacy-docs.dify.ai/ja-jp/getting-started/install-self-hosted/environments
• Dify チャットフローを AI が生成する仕組みを AI で作った話 | https://zenn.dev/ryoyoshii/articles/05d2ffe846f518
• コードが書けなくても使える！「Dify用コード生成プロンプト」を … | https://zenn.dev/upgradetech/articles/79d5bff364cbc7
• AI AgentとKG：L5エージェントを実現する知識基盤 | https://zenn.dev/knowledge_graph/books/knowledge-graph-llm-guide/viewer/kg-and-ai-agents
• Developers Summit 2026 Day2, 3 公開資料・Xアカウント … | https://zenn.dev/h_yoshikawa0724/articles/2026-02-22-developers-summit-2026

phase-2/2-3/05-升级版本注意事项.md

• 検索ワード：Dify Enterprise アップグレード 移行 ロールバック
• note ヒット数：1
• サイト検索ヒット数：5

note.com 候補

• 【ChatGPTによる和訳】Best Buy (BBY) Q4 2025 Earnings Call Transcript | https://note.com/american_stock/n/n3dd632ffef8a

zenn.dev / 公式ドキュメント / その他日本語ページ

• DifyをAWSでセルフホストする際のデータフローとセキュリティ対策 | https://zenn.dev/upgradetech/articles/8b7773dc2de4b3
• 週刊AI駆動開発 - 2025年12月28日 | https://zenn.dev/pppp303/articles/weekly_ai_20251228
• 【生成 AI 時代の LLMOps】プロンプト管理編 | https://zenn.dev/google_cloud_jp/articles/db61e6617020a4
• 開発者生産性Conference 2024に参加してきました！ | https://zenn.dev/communitio/articles/199322793252ba
• 週刊AI駆動開発 - 2026年03月08日 | https://zenn.dev/pppp303/articles/weekly_ai_20260308

phase-2 資料ソースインデックス

本ファイルは phase-2 で現在収集済みの、本文に最も有用な公開資料を記録するものです。優先ソースは note.com、zenn.dev、および Dify 公式 / Enterprise 公式の公開ドキュメントです。

一、2-1 深掘り Use Case

1. 製造業設備故障トラブルシューティングボット

• note.com
  • リコー「H.D.E.E.N」が示す暗黙知AI化の本質：4,500エージェントの実績が教える段階的実装の成功法則
    https://note.com/shin48ya/n/n14d3ec2acaf5
• zenn.dev
  • ローカルLLMの実用性が爆上げ：オフライン環境でも使える …
    https://zenn.dev/taku_sid/articles/20250402_local_llm
• 説明
  • 「Dify + 製造業設備故障トラブルシューティング」を直接取り上げた公開記事はまだ少なく、現時点では「製造業ナレッジの構造化 + 図表型資料 + ローカルデプロイ」の組み合わせによるエビデンスが中心です。

2. 法務契約比較 Workflow

• note.com
  • Human-in-the-Loopの活用事例　Difyでの具体的な運用パターン9選
    https://note.com/nocode_solutions/n/n91655a876f4d
• zenn.dev
  • Human-in-the-Loopの活用事例 Difyでの具体的な運用 …
    https://zenn.dev/nocodesolutions/articles/62a03c6770b824
  • Human-in-the-Loopの概念をDifyに落とし込み、AIの暴走を …
    https://zenn.dev/nocodesolutions/articles/df0d883c7d1f79
  • DifyとGradioで作るPDF処理ワークフローアプリケーション
    https://zenn.dev/tregu0458/articles/fbd86a6f3b4869

3. 社内稟議自動ドラフト生成

• note.com
  • 稟議なんか通せない。だから余ったPCで勝手にAI環境を作ることにした
    https://note.com/kusanone_dx/n/nd2952fe10842
  • 【コスト削減】Difyで実現する企業の業務効率化｜明日から使える事例10選
    https://note.com/sone_ai/n/n65c4c48417ac
• zenn.dev
  • Human-in-the-Loopの活用事例 Difyでの具体的な運用 …
    https://zenn.dev/nocodesolutions/articles/62a03c6770b824
• 説明
  • このテーマは「企業内文書自動化 + 承認シナリオ」寄りであり、直接のヒットは弱いものの、HITL + 構造化出力 + 日本企業の稟議コンテキストを組み合わせることで構成可能です。

4. 多言語カスタマーサポート Agent

• note.com
  • AIエージェントで問い合わせ対応を自動化｜24時間対応を実現する方法
    https://note.com/tateru_ai/n/n919b556b609f
• 公式ドキュメント
  • 知識ベースを使用したカスタマーサービスボット
    https://docs.dify.ai/ja/use-dify/tutorials/customer-service-bot
  • エージェント
    https://docs.dify.ai/ja/use-dify/nodes/agent
  • Agent | Dify
    https://legacy-docs.dify.ai/guides/workflow/node/agent

5. HR 入社書類処理パイプライン

• note.com
  • Human-in-the-Loopの活用事例　Difyでの具体的な運用パターン9選
    https://note.com/nocode_solutions/n/n91655a876f4d
• zenn.dev
  • 【脱・OCR】Dify×VLMで、あらゆる画像・PDFを思い通りのJSONに変換する
    https://zenn.dev/nocodesolutions/articles/c7fc07a13a701a
  • DifyとGradioで作るPDF処理ワークフローアプリケーション
    https://zenn.dev/tregu0458/articles/fbd86a6f3b4869
  • Human-in-the-Loopの活用事例 Difyでの具体的な運用 …
    https://zenn.dev/nocodesolutions/articles/62a03c6770b824

二、2-2 トラブル記録と解決策

検索パラメータ / Rerank

• Dify Docs
  • Specify the Index Method and Retrieval Settings
    https://docs.dify.ai/en/guides/knowledge-base/create-knowledge-and-upload-documents/setting-indexing-methods
• Legacy Docs
  • Re-ranking
    https://legacy-docs.dify.ai/learn-more/extended-reading/retrieval-augment/rerank
  • Integrate Knowledge Base within Application
    https://legacy-docs.dify.ai/guides/knowledge-base/integrate-knowledge-within-application
• GitHub Discussion
  • Doubt about the topk and threshold usage in rerank stage settings
    https://github.com/langgenius/dify/discussions/3171

Agent 無限ループ / 最大イテレーション回数 / Memory

• Dify Docs
  • Agent
    https://docs.dify.ai/en/use-dify/nodes/agent
• Legacy Docs
  • Agent
    https://legacy-docs.dify.ai/guides/workflow/node/agent
• Environment Variables
  • https://docs.dify.ai/getting-started/install-self-hosted/environments

大容量ファイルアップロード / 環境変数 / アップロード制限

• Dify Docs
  • Environment Variables
    https://docs.dify.ai/getting-started/install-self-hosted/environments
  • Deploy Dify with Docker Compose
    https://docs.dify.ai/en/self-host/quick-start/docker-compose

三、2-3 Enterprise デプロイベストプラクティス

Helm / Kubernetes / values.yaml

• Dify Enterprise Docs
  • Dify Helm Chart
    https://enterprise-docs.dify.ai/en-us/deployment/advanced-configuration/dify-helm-chart
  • Deployment FAQ
    https://enterprise-docs.dify.ai/en-us/deployment/faq/deploying
  • Kubernetes
    https://enterprise-docs.dify.ai/en-us/deployment/prerequisites/kubernetes
  • Resources Checklist
    https://enterprise-docs.dify.ai/versions/3-7-x/en-us/deployment/resources-checklist

License

• Dify Enterprise Docs
  • License Activation
    https://enterprise-docs.dify.ai/versions/3-0-x/en-us/deployment/license-activation

高可用 / 本番デプロイ

• Alibaba Cloud Community
  • High Availability and Performance: Best Practices for Deploying Dify based on ACK
    https://www.alibabacloud.com/blog/high-availability-and-performance-best-practices-for-deploying-dify-based-on-ack_601874

四、オリジナル取得ファイル

本ラウンドで取得・保存済み：

• research-public/
• phase-2/2-1/sources/

今後 phase-2 をさらに深掘りする場合は、以下の追加取得を優先的に推奨します：

• 2-2 および 2-3 で最もヒット率の高い公式ドキュメントの全文
• 日本語の企業ブログにおける Dify / RAG / Workflow / HITL の導入事例の追加

製造業の設備故障診断ボット：Dify Knowledge Base + Workflow による実践設計ガイド

はじめに

製造業の現場では、設備トラブルが発生するたびにベテラン技術者が呼び出され、経験と勘に頼った対応が繰り返されている。しかし、熟練者の高齢化・退職が進む中、この属人的な故障対応モデルは持続可能ではない。設備マニュアル、SOP、過去の修理記録、アラームコード一覧――これらの情報は社内に存在するものの、分散・非構造化された状態では、現場の即応性に結びつかない。

本稿では、Dify の Knowledge Base（ナレッジベース）と Workflow を組み合わせ、製造業設備の故障診断アシスタントを構築する方法を、アーキテクチャ設計からチューニングまで実践的に解説する。

背景と課題

製造業における故障対応の現実

なぜ Dify が適しているのか

Dify は以下の点で製造業の故障診断シナリオに適合する。

• Knowledge Base による複数ナレッジソースの統合管理
• Workflow によるルーティング・条件分岐の視覚的設計
• セルフホスト（Docker Compose） によるオンプレミス・閉域網デプロイ
• Rerank や Score Threshold など、検索パラメータの細かいチューニング
• HTTP Request ノード を通じた MES / SCADA 等の外部システム連携

全体アーキテクチャ

flowchart TD
    A[現場担当者の問い合わせ] --> B[Dify Chatbot / API]
    B --> C{質問分類ノード}
    C -->|設備仕様| D[KB: 静的知識]
    C -->|標準手順| E[KB: SOP・アラームコード]
    C -->|過去事例| F[KB: 修理記録・ナレッジ]
    C -->|現在状態| G[HTTP Request: MES/SCADA]
    D --> H[回答生成ノード]
    E --> H
    F --> H
    G --> H
    H --> I[構造化回答出力]
    I --> J{信頼度チェック}
    J -->|高| K[現場担当者へ回答]
    J -->|低| L[エスカレーション: 保全チームへ通知]

ナレッジベースの階層構造設計

設計思想：4 層モデル

すべてのドキュメントを 1 つの Knowledge Base に投入するのは、製造業では致命的なアンチパターンである。情報の性質に応じて Knowledge Base を分割し、質問タイプごとに検索先を切り替える「階層型ナレッジ設計」を推奨する。

第 1 層：設備静的知識ベース

役割: 「この設備は本来どう動くべきか」に答える。

Chunk 戦略: 章・サブシステム・部品モジュール単位で分割。固定文字数分割は避ける。

第 2 層：標準操作・故障対応知識ベース

役割: 「この異常が出たら、標準ではどう対処するか」に答える。

Chunk 戦略: アラームコード単位、手順段落単位で分割。1 チャンクが 1 つの対処パスに対応するのが理想。

第 3 層：歴史的事例知識ベース

役割: 「過去に似た症状が出たとき、実際にはどう解決したか」に答える。

Chunk 戦略: 1 件の故障 = 1 チャンク。メタデータとして設備ID・日付・アラームコードを付与。

第 4 層：リアルタイム補助情報（外部連携）

役割: 「今この設備はどういう状態か」に答える。Knowledge Base に入れるのではなく、Workflow の HTTP Request ノードでリアルタイム取得するのが望ましい。

Workflow 設計の詳細

質問分類ノード（LLM ノード）

ユーザーの入力を受け取り、以下の 4 カテゴリに分類する。

System Prompt:
あなたは製造業設備の問い合わせ分類エンジンです。
ユーザーの質問を以下のカテゴリに分類してください。

1. SPEC - 設備の仕様・原理・構造に関する質問
2. SOP - 標準手順・アラームコード・点検に関する質問
3. CASE - 過去の故障事例・修理履歴に関する質問
4. STATUS - 現在の設備状態・稼働状況に関する質問

カテゴリ名のみを出力してください。複数該当する場合はカンマ区切りで出力。

条件分岐ノード

分類結果に応じて、検索先の Knowledge Base を切り替える。Dify Workflow の IF/ELSE ノード または Question Classifier ノード を利用する。

IF category contains "SPEC" → Knowledge Retrieval(静的知識KB)
IF category contains "SOP"  → Knowledge Retrieval(SOP・アラームKB)
IF category contains "CASE" → Knowledge Retrieval(事例KB)
IF category contains "STATUS" → HTTP Request(MES/SCADA API)

複数カテゴリの場合は並列検索し、結果をマージして回答生成ノードに渡す。

回答生成ノード（LLM ノード）

System Prompt:
あなたは製造業の設備保全エキスパートアシスタントです。
以下のフォーマットで回答してください。

## 初期判断
[症状に対する第一印象]

## 考えられる原因（優先度順）
1. ...
2. ...
3. ...

## 推奨する確認手順
1. ...
2. ...

## 確認すべきログ・センサー・部品
- ...

## エスカレーション判断
[人手による対応が必要かどうかの判断]

注意事項:
- 推測の域を出ない場合は明示すること
- 安全に関わる作業は必ず「有資格者による実施」を注記すること
- 検索結果に該当情報がない場合は「該当情報なし」と明示すること

検索パラメータのチューニング

チューニングの考え方

製造業の故障診断では、「一つのパラメータ設定ですべての質問タイプに対応する」ことは現実的でない。質問カテゴリごとに最適なパラメータが異なるためである。

推奨パラメータ設定

チューニング記録テンプレート

実際のチューニングでは、以下のような記録を残すことを推奨する。

Chunk 設計の実践ポイント

アラームコードドキュメントの Chunk 例

---
alarm_code: E-401
equipment: 油圧ユニット HU-200
severity: WARNING
---

## E-401: 油圧圧力低下

### 症状
油圧系統の圧力が設定値を下回った場合に発報。設備は低速運転を継続するが、加工精度が低下する可能性がある。

### 考えられる原因
1. 油圧ポンプの摩耗
2. リリーフバルブの設定ずれ
3. 油圧ホースからのリーク
4. 作動油の劣化（粘度低下）

### 対処手順
1. 油圧計で実測圧力を確認
2. ポンプ周辺の油漏れを目視確認
3. 作動油のサンプリング検査を実施
4. 異常が認められた場合、ラインを停止し保全チームに連絡

メタデータの付与

Dify の Knowledge Base にドキュメントをアップロードする際、以下のメタデータをファイル名やドキュメント説明に含めると検索精度が向上する。

• 設備 ID / 設備名
• アラームコード（該当する場合）
• 文書カテゴリ（マニュアル / SOP / 事例 / 点検表）
• 最終更新日

オンプレミスデプロイの考慮事項

Docker Compose によるセルフホスト

製造業の工場環境では、インターネット接続が制限されるケースが多い。Dify はセルフホスト版（Docker Compose）を提供しており、閉域網での運用が可能である。

# docker-compose.yml 抜粋（LLM プロバイダ設定例）
services:
  api:
    environment:
      # ローカル LLM を使用する場合（Ollama 等）
      - OLLAMA_API_BASE=http://ollama-server:11434
      # または vLLM を使用する場合
      - OPENAI_API_BASE=http://vllm-server:8000/v1
      - OPENAI_API_KEY=dummy

ローカル LLM の選択肢

閉域網で運用する場合は、Embedding モデルもローカルでホストする必要がある点に注意。

運用フローと継続改善

フィードバックループの設計

flowchart LR
    A[故障発生] --> B[ボットに問い合わせ]
    B --> C[回答を確認]
    C --> D{解決?}
    D -->|Yes| E[解決記録を KB に追加]
    D -->|No| F[保全チームが対応]
    F --> G[対応結果を工単に記録]
    G --> E
    E --> H[ナレッジベース更新]
    H --> I[検索精度が向上]

定期的なメンテナンス項目

導入ステップ

1. Phase 1（2-3 週間）: アラームコード一覧と主要 SOP を Knowledge Base に投入。基本的な Q&A ボットとして稼働開始。
2. Phase 2（1-2 ヶ月）: 過去の修理工単・故障記録を構造化して追加。質問分類ノードを導入し、検索先の自動振り分けを実装。
3. Phase 3（2-3 ヶ月）: MES / SCADA 連携の HTTP Request ノードを追加。リアルタイム状態を踏まえた回答が可能に。
4. Phase 4（継続）: 現場フィードバックを基にナレッジとパラメータを継続改善。

まとめ

製造業の設備故障診断ボットは、単にマニュアルをアップロードして終わりではない。知識の階層化、質問タイプに応じた検索ルーティング、Chunk 設計の最適化、そして運用フェーズでの継続的なナレッジ蓄積――これらを一体として設計することで、初めて現場で使われるツールになる。

Dify の Knowledge Base + Workflow の組み合わせは、この要件に対して十分な柔軟性を提供する。特にセルフホスト版を活用すれば、製造業特有のセキュリティ要件（閉域網・データ外部送信禁止）にも対応可能であり、エンタープライズ導入のハードルを大きく下げることができる。

最も重要なのは、このプロジェクトを「AI 導入プロジェクト」としてではなく、「現場知識の構造化プロジェクト」として位置づけることである。暗黙知をいかに検索可能な資産に変換するか――その設計品質が、ボットの実用性を決定づける。

法務契約書比較 Workflow：Dify の迭代ノードと Human-in-the-Loop による実践設計

はじめに

企業法務において、契約書のレビューは最も工数がかかる業務の一つである。新規契約のドラフトと自社テンプレートの差異確認、取引先から送付された修正版（レッドライン版）の変更点把握、複数の関連契約書間での条項整合性チェック――これらの作業は、高い専門性を要するにもかかわらず、その大部分は「定型的な差異の抽出」に費やされている。

本稿では、Dify の Workflow 機能を活用し、複数ファイルの契約書比較を自動化しつつ、高リスク条項については人間による確認を必須とする法務契約書レビューシステムの設計と実装を解説する。

背景と課題

契約書レビューの現状

本 Workflow が解決すること

• 定型的な差異抽出の自動化: 条項単位での比較を LLM に委任
• リスク分級の標準化: 条項ごとのリスクレベルを一貫した基準で判定
• Human-in-the-Loop: 高リスク・低確信度の判断は必ず人間に回す
• 複数ファイル対応: 迭代（イテレーション）ノードによる逐次処理

全体アーキテクチャ

flowchart TD
    A[契約書ファイルアップロード<br>主契約 + テンプレート + 附属書] --> B[ファイル解析ノード]
    B --> C[契約タイプ分類]
    C --> D[迭代ノード:<br>ファイルごとに条項抽出]
    D --> E[条項マッピング・差異検出]
    E --> F[リスク分級ノード]
    F --> G{高リスク条項あり?}
    G -->|Yes| H[Human-in-the-Loop:<br>法務担当に確認依頼]
    G -->|No| I[レビュー結果出力]
    H --> J{承認 / 差戻し}
    J -->|承認| I
    J -->|差戻し| K[修正指示付きで再レビュー]
    K --> E
    I --> L[構造化レポート出力]

Workflow ノード設計の詳細

ノード 1: ファイル受信・前処理

Dify Workflow の 開始ノード でファイルをアップロードする。複数ファイルを受け付ける場合、各ファイルにメタデータを付与する。

{
  "files": [
    {
      "name": "master_agreement_v2.pdf",
      "role": "review_target",
      "type": "主契約",
      "version": "v2.0"
    },
    {
      "name": "standard_template_2024.pdf",
      "role": "template",
      "type": "業務委託契約テンプレート",
      "version": "2024年版"
    },
    {
      "name": "appendix_a.pdf",
      "role": "attachment",
      "type": "別紙A（SLA条件）",
      "version": "v1.0"
    }
  ]
}

ノード 2: テキスト抽出

PDF からテキストを抽出する。Dify では以下の方法が利用可能である。

契約書は通常テキスト PDF であることが多いため、まずは直接解析を試みるのが効率的である。

ノード 3: 契約タイプ分類（LLM ノード）

System Prompt:
あなたは日本の企業法務の専門家です。
アップロードされた契約書のテキストを分析し、以下の契約タイプに分類してください。

- 業務委託契約
- 秘密保持契約（NDA）
- ソフトウェアライセンス契約
- SaaS 利用規約
- 売買基本契約
- 共同開発契約
- その他（具体的に記述）

出力フォーマット:
{"contract_type": "...", "confidence": 0.0-1.0}

契約タイプに応じて、後続のリスク判定基準やテンプレートを切り替える。

ノード 4: 迭代ノードによる条項抽出

Dify Workflow の 迭代（Iteration）ノード を使用し、アップロードされた各ファイルに対して同一の条項抽出処理を適用する。

迭代ノードの設定:
- 入力配列: files[]
- 各イテレーションの処理:
  1. テキスト抽出
  2. LLM ノードで条項単位に分割
  3. 各条項をJSON配列として出力

条項抽出の LLM プロンプト例:

以下の契約書テキストから、主要条項を抽出してください。
各条項について以下のフィールドを出力してください。

- clause_id: 条番号（例: "第3条第2項"）
- clause_title: 条項名（例: "秘密保持義務"）
- clause_text: 条文全文
- clause_category: カテゴリ（以下から選択）
  [契約主体, 契約期間, 業務範囲, 報酬・支払条件, 
   知的財産権, 秘密保持, 損害賠償, 解除条件, 
   自動更新, 準拠法・管轄, 反社会的勢力排除, その他]

JSON配列で出力してください。

迭代ノードを使う理由: 全ファイルのテキストを一括で LLM に投入すると、コンテキストウィンドウの制約により条項の見落としが発生しやすい。ファイル単位で逐次処理し、中間結果を保持することで、後から「この差異はどのファイルから検出されたか」を正確にトレースできる。

ノード 5: 条項マッピング・差異検出（LLM ノード）

迭代ノードから出力された各ファイルの条項リストを受け取り、テンプレートとレビュー対象の条項を突き合わせる。

System Prompt:
あなたは契約書の比較分析エキスパートです。
テンプレート条項とレビュー対象の条項を比較し、
以下のフォーマットで差異を報告してください。

各条項について:
{
  "clause_category": "...",
  "template_clause": "テンプレート側の条文",
  "review_clause": "レビュー対象側の条文",
  "status": "identical | modified | added | deleted | missing",
  "diff_summary": "差異の要約（日本語）",
  "risk_level": "high | medium | low | info",
  "risk_reason": "リスク判定の根拠"
}

リスク判定基準:
- high: 損害賠償上限の撤廃、自動更新の無制限化、排他的拘束、
        準拠法の変更、データ越境義務、競業避止の過度な拡大
- medium: 支払条件の変更、解除条件の非対称性、保証範囲の縮小
- low: 通知期間の軽微な変更、形式的な文言修正
- info: 差異はあるが実質的影響なし

ノード 6: リスク分級と集計

差異検出結果を集計し、レビューサマリーを生成する。

{
  "total_clauses_compared": 24,
  "identical": 15,
  "modified": 6,
  "added": 2,
  "deleted": 1,
  "high_risk_count": 2,
  "medium_risk_count": 3,
  "requires_human_review": true,
  "high_risk_clauses": ["..."]
}

Human-in-the-Loop 審査ノードの設計

なぜ完全自動化してはいけないのか

契約書レビューにおける AI の役割は「差異の検出と分類」であり、「法的判断」ではない。法的責任は最終的に人間が負うため、高リスクな判断を AI に委ねることは、コンプライアンス上も実務上も許容されない。

トリガー条件の設計

人間の入力ノードの分岐

Dify の「人間の入力」ノードは、以下の 3 つの分岐をネイティブでサポートする。

• ACCEPT: 法務担当が確認し承認 → レポート出力へ進む
• DENY: 法務担当が差戻し → 修正指示を付与して条件分岐へ戻す
• TIMEOUT: 一定時間内に応答なし → 自動承認せず保留状態を維持

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
契約書レビュー: 人間による確認が必要です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

■ 高リスク条項:

1. 第12条（損害賠償）
   テンプレート: 賠償上限は委託料の12ヶ月分
   レビュー対象: 賠償上限の記載なし（無制限）
   → リスク: 損害賠償上限の撤廃

2. 第15条（自動更新）
   テンプレート: 1年ごとの自動更新、解約通知3ヶ月前
   レビュー対象: 3年ごとの自動更新、解約通知6ヶ月前
   → リスク: ロックイン期間の大幅延長

■ 判断をお願いします: [承認] [差戻し]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

条項比較のチェックリスト

比較すべき主要条項

出力レポートの設計

構造化出力（JSON）

下流の契約管理システムやワークフロー承認システムとの連携を想定し、構造化された JSON 形式で出力する。

{
  "review_id": "REV-2026-0412-001",
  "review_date": "2026-04-12",
  "reviewer_ai": "Dify Workflow v1.2",
  "reviewer_human": "法務部 田中",
  "contract_type": "業務委託契約",
  "review_target": "master_agreement_v2.pdf",
  "template": "standard_template_2024.pdf",
  "summary": {
    "total_clauses": 24,
    "differences": 9,
    "high_risk": 2,
    "medium_risk": 3,
    "human_review_status": "approved_with_comments"
  },
  "high_risk_details": [
    {
      "clause_id": "第12条",
      "category": "損害賠償",
      "diff_summary": "賠償上限の記載が削除されている",
      "recommendation": "上限条項の追記を交渉"
    }
  ],
  "recommendations": [
    "第12条の損害賠償上限を明記するよう交渉を推奨",
    "第15条の自動更新期間を1年に短縮するよう修正依頼"
  ]
}

実装上の注意点とアンチパターン

やってはいけないこと

1. 契約書全文を一括で LLM に投入して「違いを教えて」と聞く — 条項単位に分解しないと、重要な差異が埋もれる
2. 主契約・附属書・変更覚書を区別せずに処理する — バージョンと適用優先順位が混乱する
3. AI の判定結果をそのまま最終判断として扱う — 法的責任は人間が負う前提で設計する
4. リスクレベルの判定基準を組織のルールと切り離す — 決裁権限・コンプライアンスポリシーと連動させる
5. Human-in-the-Loop のトリガー条件を定義しない — 「どの条件で人間に回すか」が不明確だと、全件人間に回るか、全件スルーされるかの両極端になる

導入ステップ

API 連携例

Dify Workflow は REST API として公開できるため、既存の契約管理システムから呼び出すことが可能である。

curl -X POST 'https://dify.example.com/v1/workflows/run' \
  -H 'Authorization: Bearer {api_key}' \
  -H 'Content-Type: multipart/form-data' \
  -F 'inputs={"contract_type":"業務委託契約"}' \
  -F 'files=@master_agreement_v2.pdf' \
  -F 'files=@standard_template_2024.pdf' \
  -F 'response_mode=blocking' \
  -F 'user=legal_team_tanaka'

まとめ

法務契約書比較 Workflow の本質は、「AI に契約書を読ませる」ことではなく、標準化可能な差異抽出を自動化し、高リスクな判断を確実に人間に委ねる仕組みを構築することにある。

Dify の迭代ノードにより複数ファイルの逐次処理が実現でき、Human-in-the-Loop ノードの ACCEPT / DENY / TIMEOUT 分岐により、法務レビューに求められる「人間が最終判断する」原則を Workflow レベルで担保できる。

重要なのは、この Workflow を「法務部門の省力化ツール」としてではなく、**「契約リスクの可視化と標準化の基盤」**として位置づけることである。AI が差異を見つけ、リスクを分類し、人間が判断する――このサイクルを継続的に回すことで、組織全体の契約リスク管理能力を底上げすることが可能になる。

社内稟議書の自動ドラフト生成：Dify による構造化出力とプロンプト設計の実践

はじめに

日本企業において、稟議書は意思決定プロセスの中核をなす文書である。新規ツールの導入、予算の申請、外部ベンダーとの契約締結――あらゆる重要な意思決定は稟議書を通じて承認を得る必要がある。しかし、稟議書の作成には相当な時間がかかる。背景の整理、費用対効果の算出、リスクの洗い出し、関連部署との調整事項の記載など、1 件の稟議書に数時間から丸一日を費やすことも珍しくない。

本稿では、Dify を活用して稟議書のドラフトを構造化された形式で自動生成し、人間による確認・修正を経て承認フローに乗せるシステムの設計を解説する。ポイントは「うまい文章を書くこと」ではなく、組織の承認フォーマットに沿った、欠落のない構造化出力を安定して生成することにある。

背景と課題

稟議書作成の現実的な課題

なぜ「自動生成」ではなく「自動ドラフト」なのか

稟議書は組織内の公式な意思決定文書であり、最終的な責任は申請者と承認者にある。AI が生成した内容をそのまま提出することは、以下の理由で適切でない。

• 数値の正確性: 予算額・ROI・投資回収期間は AI が推測してはならない
• 組織固有の文脈: 過去の経緯や社内政治的な配慮は AI には判断できない
• 責任の所在: 稟議書の内容に対する責任は申請者が負う

したがって、AI の役割は「構造を整え、草稿を生成し、不足項目を明示する」ことに限定し、最終化は人間が行う設計とする。

全体アーキテクチャ

flowchart TD
    A[申請者: 要件を入力] --> B[入力情報の構造化ノード]
    B --> C[稟議タイプ判定]
    C --> D[テンプレート選択]
    D --> E[LLM ドラフト生成]
    E --> F[不足項目チェック]
    F --> G{不足項目あり?}
    G -->|Yes| H[不足項目リスト提示<br>+ 暫定ドラフト出力]
    G -->|No| I[完全ドラフト出力]
    H --> J[Human-in-the-Loop:<br>申請者が確認・補完]
    I --> J
    J --> K[最終稟議書出力]
    K --> L[承認ワークフロー連携<br>API / メール / Slack]

稟議書の構造化フォーマット設計

標準フィールド定義

稟議書のドラフト生成において最も重要なのは、出力フォーマットの安定性である。自然文の長文ではなく、固定フィールドの構造化出力を基本とする。

{
  "ringi_title": "Dify Enterprise 版 導入に関する稟議",
  "applicant": {
    "name": "",
    "department": "",
    "position": "",
    "date": "2026-04-12"
  },
  "background": {
    "current_situation": "現状の課題を記述",
    "trigger": "稟議提出のきっかけ"
  },
  "purpose": "本稟議の目的を1-2文で記述",
  "proposal": {
    "overview": "提案の概要",
    "scope": "適用範囲・対象部門",
    "timeline": "想定スケジュール"
  },
  "cost": {
    "initial_cost": "初期費用（税込）",
    "running_cost": "月額/年額ランニングコスト",
    "total_budget": "稟議申請金額",
    "budget_source": "予算科目",
    "payment_terms": "支払条件"
  },
  "expected_benefits": {
    "quantitative": "定量的な効果（工数削減○時間/月 等）",
    "qualitative": "定性的な効果"
  },
  "roi": {
    "payback_period": "投資回収期間",
    "calculation_basis": "算出根拠"
  },
  "risks": [
    {
      "risk": "リスク項目",
      "probability": "高/中/低",
      "impact": "高/中/低",
      "mitigation": "対策"
    }
  ],
  "alternatives": [
    {
      "option": "代替案",
      "pros": "メリット",
      "cons": "デメリット",
      "reason_not_selected": "不採用理由"
    }
  ],
  "approval_items": "承認を求める事項を明確に記述",
  "attachments": ["見積書", "製品資料", "PoC報告書"],
  "compliance_check": {
    "personal_data": "個人情報の取扱い有無",
    "security_review": "セキュリティ審査の要否",
    "legal_review": "法務確認の要否"
  },
  "missing_fields": ["未入力または情報不足のフィールド一覧"]
}

稟議タイプ別のフィールド調整

プロンプト設計：バージョン別の比較

Version 1: 自由生成型

System Prompt:
あなたは社内稟議書の作成をサポートするアシスタントです。
ユーザーの入力に基づいて稟議書のドラフトを作成してください。

結果の傾向:

• 文章としては読みやすいが、フィールドが不安定
• 必須項目（予算・リスク等）が抜け落ちやすい
• 承認システムやフォームに直接取り込めない形式になりがち

Version 2: テンプレート拘束型

System Prompt:
あなたは社内稟議書の作成支援アシスタントです。
以下のフィールドに従って、構造化された稟議書ドラフトを JSON 形式で出力してください。

必須フィールド:
- ringi_title: 稟議件名
- background: 背景・現状の課題
- purpose: 目的
- proposal: 提案概要
- cost: コスト（初期費用、ランニングコスト、合計）
- expected_benefits: 期待効果（定量・定性）
- risks: リスクと対策
- approval_items: 承認を求める事項

すべてのフィールドを必ず出力してください。
情報が不足している場合は、そのフィールドに "【要入力】" と記載してください。

結果の傾向:

• フィールドの網羅性が大幅に向上
• ただし「【要入力】」が多すぎると、ドラフトの実用性が低下
• 入力情報が少ないと、推測で埋めてしまうケースがある

Version 3: 構造化 + 不足検出 + 安全制約型（推奨）

System Prompt:
あなたは社内稟議書の整理・構造化アシスタントです。
以下のルールに厳密に従ってください。

【役割の定義】
- あなたは稟議書の「整理者」であり、「意思決定者」ではありません
- 入力情報に基づいてドラフトを構造化する役割のみを担います

【出力ルール】
1. 指定された JSON フォーマットで出力すること
2. 入力情報に含まれない数値（予算額、ROI、期間等）は絶対に推測・捏造しないこと
3. 情報が不足しているフィールドは "【要確認】" と明記すること
4. missing_fields に不足項目を一覧として出力すること
5. 金額には必ず税込/税抜を明記すること
6. 根拠のない効果の誇張は行わないこと

【フォーマット】
{上記の JSON フォーマットを挿入}

【重要な禁止事項】
- 予算額の推測禁止
- ROI の捏造禁止
- 投資回収期間の推測禁止
- 存在しない比較データの生成禁止

結果の傾向:

• フィールドの網羅性と正確性のバランスが最も良い
• 不足項目が明示されるため、申請者が何を補完すべきか明確
• 捏造リスクが大幅に低減

入力情報の設計

なぜ自由テキスト入力だけでは不十分か

「Dify を導入したい。稟議書を作って」という自由テキスト入力だけでは、ドラフトの品質は低くなる。最低限の構造化された入力を求めることで、出力品質は飛躍的に向上する。

推奨する入力フォーム

Dify Workflow の開始ノードで以下の入力変数を定義する。

添付ファイルからの情報抽出

見積書や提案書が添付された場合、Dify の VLM / パラメータ抽出ノードを使って、金額・ベンダー名・契約条件などを自動抽出し、稟議書ドラフトに反映する。

flowchart LR
    A[見積書PDF] --> B[VLM / テキスト抽出]
    B --> C[パラメータ抽出ノード]
    C --> D["金額: ¥3,600,000<br>ベンダー: ○○株式会社<br>期間: 12ヶ月"]
    D --> E[稟議書ドラフトに反映]

Human-in-the-Loop の設計

人間による確認が必要なケース

確認フローの設計

Dify Human-in-the-Loop ノードの表示例:

━━━━━━━━━━━━━━━━━━━━━━
稟議書ドラフト: 確認をお願いします
━━━━━━━━━━━━━━━━━━━━━━

■ 件名: Dify Enterprise 版 導入に関する稟議

■ 不足項目:
  ⚠ 初期費用が未入力です
  ⚠ 投資回収期間の算出根拠がありません
  ⚠ セキュリティ審査の要否が未回答です

■ ドラフト内容:
  [JSON / Markdown 形式のドラフトを表示]

■ アクション:
  [承認して次へ] [修正して再生成]
━━━━━━━━━━━━━━━━━━━━━━

下流システムとの連携

承認ワークフローへの接続

稟議書ドラフトが確定したら、Dify Workflow の HTTP Request ノード を使って社内の承認システムに連携する。

API 呼び出し例（kintone 連携）

curl -X POST 'https://{subdomain}.cybozu.com/k/v1/record.json' \
  -H 'X-Cybozu-API-Token: {api_token}' \
  -H 'Content-Type: application/json' \
  -d '{
    "app": 123,
    "record": {
      "稟議件名": {"value": "Dify Enterprise 版 導入"},
      "申請部門": {"value": "情報システム部"},
      "申請金額": {"value": "3600000"},
      "ステータス": {"value": "ドラフト確認済み"}
    }
  }'

実装上のベストプラクティス

やるべきこと

1. 出力フォーマットを先に確定する — プロンプトより先に、どの JSON フィールドが必要かを定義する
2. 不足項目を明示的に出力させる — missing_fields を必須フィールドとして定義する
3. 稟議タイプ別にプロンプトを切り替える — SaaS 導入と人員採用では必要項目が異なる
4. 金額フィールドには安全制約を設ける — 推測禁止を明示的にプロンプトに記載する
5. Human-in-the-Loop を必ず組み込む — 完全自動提出は許容しない

やってはいけないこと

1. 「稟議書を書いて」だけの自由テキスト入力で運用する — 入力の構造化が出力品質を決める
2. AI に予算額や ROI を推測させる — 承認者の信頼を損ない、制度全体の信用が崩壊する
3. すべての稟議タイプに同一テンプレートを適用する — タイプ別の最適化が必要
4. 自然文の長文で出力する — 下流システムに接続できない

導入ステップ

まとめ

社内稟議書の自動ドラフト生成において最も重要なのは、「うまい文章を書くこと」ではなく、組織の承認フォーマットに沿った構造化出力を安定して生成し、不足している情報を明示することである。

Dify の Workflow を活用すれば、入力の構造化 → タイプ判定 → テンプレート選択 → ドラフト生成 → 不足検出 → 人間確認 → システム連携という一連のフローを、ノーコードで構築できる。特に Version 3（構造化 + 不足検出 + 安全制約型）のプロンプト設計を採用することで、AI が数値を捏造するリスクを抑えつつ、申請者の作成工数を大幅に削減することが可能である。

稟議書は日本企業における意思決定の「インターフェース」であり、その品質は組織の意思決定速度に直結する。AI による構造化ドラフト生成は、このインターフェースの標準化と高速化を実現する有効なアプローチである。

多言語カスタマーサポート Agent：Dify Agent によるツール連携・フォールバック・メモリ管理の実践設計

はじめに

グローバルに事業を展開する企業にとって、多言語でのカスタマーサポートは避けて通れない課題である。従来は言語ごとにサポートチームを編成するか、翻訳ツールを介して対応していたが、LLM の多言語処理能力の向上により、単一の AI Agent で複数言語のサポートを実現するアプローチが現実的になっている。

しかし、多言語カスタマーサポート Agent の設計で最も重要なのは「多言語に対応できるか」ではない。GPT-4o や Claude といったモデルは、プロンプトなしでも多言語の入出力を処理できる。真の設計課題は、ツール呼び出しチェーンの安定性、フォールバック戦略の明確さ、会話メモリの適切な管理の三点にある。

本稿では、Dify の Agent ノードを中心に、エンタープライズ品質の多言語カスタマーサポート Agent を構築するための設計パターンを解説する。

背景と課題

多言語カスタマーサポートの現状

Dify Agent ノードの主要機能

Dify の Agent ノードは、以下の設定項目をネイティブでサポートしている。

全体アーキテクチャ

flowchart TD
    A[ユーザー入力<br>任意の言語] --> B[Dify Agent ノード]
    B --> C{意図判定}
    C -->|FAQ| D[Knowledge Base 検索]
    C -->|注文照会| E[Tool: 注文検索API]
    C -->|配送状況| F[Tool: 物流追跡API]
    C -->|工単作成| G[Tool: チケット作成API]
    C -->|クレーム/感情的| H[Tool: 人間エスカレーション]
    C -->|不明| I[フォールバック: 確認質問]
    D --> J[回答生成<br>入力と同じ言語で]
    E --> J
    F --> J
    G --> J
    H --> K[人間オペレーターに転送]
    I --> J
    J --> L[ユーザーへ返答]

ツール設計の詳細

ツール一覧と定義

Agent の精度は、ツールの「説明文（description）」の品質に大きく左右される。抽象的な説明では LLM が適切なツールを選択できない。

Tool 1: 注文検索

name: search_order
description: |
  顧客の注文情報を検索します。
  以下の場合に使用してください：
  - 顧客が注文番号を提示して状況を確認したい場合
  - 顧客が「注文」「購入」「買った」等のキーワードを含む質問をした場合
  以下の場合は使用しないでください：
  - 注文番号が不明で、顧客が一般的な質問をしている場合
  - 返品・返金に関する質問の場合（create_ticket を使用）
parameters:
  order_id:
    type: string
    required: true
    description: 注文番号（例: ORD-20260412-001）

Tool 2: 物流追跡

name: track_shipment
description: |
  配送状況を追跡します。
  以下の場合に使用してください：
  - 顧客が「届かない」「配送」「いつ届く」等の配送関連の質問をした場合
  - 注文検索の結果、ステータスが「発送済み」の場合
parameters:
  tracking_number:
    type: string
    required: true
    description: 追跡番号

Tool 3: チケット作成

name: create_ticket
description: |
  カスタマーサポートチケットを作成します。
  以下の場合に使用してください：
  - 顧客が返品・返金を希望する場合
  - 商品の不具合を報告する場合
  - Agent では解決できない問題の場合
parameters:
  customer_id:
    type: string
    required: true
  issue_type:
    type: string
    enum: [return, refund, defect, complaint, other]
    required: true
  description:
    type: string
    required: true
    description: 問題の概要（日本語で記載）

Tool 4: FAQ 検索（Knowledge Base）

name: search_faq
description: |
  FAQ ナレッジベースを検索します。
  以下の場合に使用してください：
  - 顧客が製品の使い方、仕様、ポリシーに関する一般的な質問をした場合
  - 注文や配送に直接関係しない質問の場合

Tool 5: 人間エスカレーション

name: escalate_to_human
description: |
  人間のオペレーターにエスカレーションします。
  以下の場合に必ず使用してください：
  - 顧客が明らかに怒っている、または強い不満を表明している場合
  - 法的な言及（訴訟、消費者庁等）がある場合
  - 3回以上ツール呼び出しを試みても解決できない場合
  - 返金額が50,000円を超える場合
parameters:
  reason:
    type: string
    required: true
  priority:
    type: string
    enum: [normal, high, urgent]
    required: true
  conversation_summary:
    type: string
    required: true
    description: これまでの会話の要約

Agent Instruction（System Prompt）の設計

あなたは多言語カスタマーサポートの AI アシスタントです。

【言語ルール】
- ユーザーが使用した言語と同じ言語で回答してください
- 言語の切替が検出された場合は、新しい言語に合わせてください
- 製品名・ブランド名は原語のまま使用してください

【回答構造】
1. まず結論を述べる
2. 次に根拠や状況を説明する
3. 最後に次のアクションを提示する

【ツール呼び出しルール】
- ツールを呼び出す前に、必要なパラメータが揃っているか確認すること
- パラメータが不足している場合は、推測せずユーザーに確認すること
- 1つの質問に対してツール呼び出しは最大3回までとする
- ツール呼び出しが失敗した場合は、エラー内容をユーザーに伝え、
  代替手段を提示すること

【禁止事項】
- 注文のキャンセル・返金の自動実行（チケット作成まで）
- 個人情報（クレジットカード番号等）の取得要求
- 他社製品との比較における他社の誹謗
- 未確認の情報に基づく断定的な回答

【エスカレーション条件】
以下の場合は必ず escalate_to_human を呼び出すこと：
- 顧客の感情が強くネガティブ（怒り、失望、脅し等）
- 法的措置への言及
- 3回のツール呼び出しで解決できない場合
- 自分の回答に自信がない場合

フォールバック戦略の設計

3 層フォールバックモデル

フォールバックとは、Agent が最適な回答を返せない場合の退避戦略である。カスタマーサポートにおいては、「答えられないこと」よりも「誤った対応をすること」の方がはるかに深刻なため、フォールバック設計は最重要事項の一つである。

flowchart TD
    A[ユーザーの質問] --> B{ツール呼び出し<br>条件を満たす?}
    B -->|Yes| C[ツール呼び出し実行]
    B -->|No| D[第1層: Knowledge Base 検索]
    C --> E{成功?}
    E -->|Yes| F[回答生成]
    E -->|No| G[第2層: 確認質問]
    D --> H{該当情報あり?}
    H -->|Yes| F
    H -->|No| G
    G --> I{情報取得成功?}
    I -->|Yes| C
    I -->|No| J[第3層: 人間エスカレーション]

第 1 層: Knowledge Base フォールバック

ツール呼び出しの条件を満たさない場合（注文番号がない、配送情報がない等）、まず Knowledge Base を検索する。FAQ、製品仕様、ポリシー文書などの静的情報で回答できる場合は、ここで完結する。

第 2 層: 確認質問フォールバック

Knowledge Base でも回答が得られない場合、不足情報をユーザーに確認する。

確認質問の例:
- 「注文番号をお教えいただけますか？注文確認メールに記載されています。」
- 「お問い合わせの製品名をお聞かせください。」
- 「いつ頃ご注文されましたか？おおよその日付で構いません。」

重要なのは、不足情報を推測してツールを呼び出さないことである。誤った注文番号で検索すると、他人の情報を返してしまうリスクがある。

第 3 層: 人間エスカレーション

以下の条件に該当する場合は、即座に人間オペレーターにエスカレーションする。

会話メモリ管理

Memory Window の設計

Dify Agent ノードの Memory 設定では、保持する会話ターン数（Window Size）を制御できる。適切な Window Size の設定は、回答品質とコスト・レイテンシのバランスに直結する。

Window Size のトレードオフ

• 大きすぎる場合: トークンコスト増大、レイテンシ増加、無関係な過去情報による回答精度低下
• 小さすぎる場合: 「さっき言った件」が解決できない、同じ情報を再度要求してしまう

長い会話セッションでは、Window Size を超えた会話を要約テキストに変換してコンテキストに含める「要約メカニズム」の併用が有効である。

多言語対応の実装ポイント

言語検出と切替

LLM は入力言語を自動で検出し、同じ言語で回答する能力を持っている。ただし、以下の点に注意が必要である。

Knowledge Base の多言語対応

推奨は 単一 KB（日本語 + 英語）を multilingual Embedding モデルで検索 するアプローチである。multilingual-e5-large や bge-m3 などのモデルは、言語を跨いだ意味検索に対応している。

Agent Strategy の選択

Function Calling vs ReAct

カスタマーサポートの本番運用では、Function Calling を推奨する。ツール呼び出しの精度が高く、予測可能な動作が期待できる。

Maximum Iterations の設定

Agent がツール呼び出しを繰り返す最大回数を制限する。カスタマーサポートでは 3-5 回 を推奨する。

• 3 回未満: 複合的な問い合わせに対応できない
• 5 回超過: 無限ループのリスク、レイテンシの増大、顧客の待ち時間増加

運用モニタリング

監視すべき指標

導入ステップ

まとめ

多言語カスタマーサポート Agent の設計において、言語対応は LLM の基本能力で実現できるため、差別化要因にはならない。真に設計品質が問われるのは、以下の三点である。

1. ツール呼び出しチェーンの安定性: ツールの description を具体的に記述し、呼び出し条件を明確にする
2. フォールバック戦略の明確さ: Knowledge Base → 確認質問 → 人間エスカレーションの 3 層で設計する
3. 会話メモリの適切な管理: シナリオに応じた Window Size の設定と、要約メカニズムの併用

Dify の Agent ノードは、Function Calling / ReAct の選択、ツール定義、Memory 設定、Maximum Iterations をすべて GUI で設定でき、エンタープライズ品質のカスタマーサポート Agent を構築するための十分な基盤を提供している。

HR 入社書類処理パイプライン：Dify Workflow による PDF 解析から人事システム連携までの実装ガイド

はじめに

新入社員の入社手続きにおいて、人事部門は大量の書類を処理する必要がある。履歴書、住民票、マイナンバー通知カード、銀行口座届出書、年金手帳のコピー、各種誓約書――これらの書類から必要な情報を正確に抽出し、人事システムに登録する作業は、1 名あたり数十分から 1 時間を要する。4 月の一括入社時期には、この作業が集中的に発生し、人事部門のボトルネックとなる。

本稿では、Dify の Workflow を活用して、PDF / 画像形式の入社書類から情報を自動抽出し、検証・人間確認を経て人事システムに登録するエンドツーエンドのパイプラインを設計・実装する方法を解説する。

背景と課題

入社書類処理の現実

パイプライン化のメリット

全体アーキテクチャ

flowchart TD
    A[書類アップロード<br>PDF / 画像] --> B[ファイル振分けノード]
    B --> C{ファイル形式判定}
    C -->|テキスト PDF| D[テキスト抽出]
    C -->|スキャン PDF / 画像| E[VLM / OCR 処理]
    D --> F[パラメータ抽出ノード<br>構造化 JSON 出力]
    E --> F
    F --> G[フィールド検証ノード]
    G --> H{検証結果}
    H -->|全項目 OK| I[Human-in-the-Loop<br>最終確認]
    H -->|不備あり| J[不備通知<br>再提出依頼]
    I --> K{承認?}
    K -->|Yes| L[人事システム連携<br>HTTP Request]
    K -->|修正| M[修正入力]
    M --> G
    L --> N[処理完了・ログ記録]

ノード設計の詳細

ノード 1: ファイル受信（開始ノード）

Dify Workflow の開始ノードで、以下の入力を受け付ける。

ノード 2: ファイル形式判定・振分け

アップロードされた各ファイルについて、処理方法を振り分ける。

判定ロジック:
- 拡張子が .pdf でテキスト抽出可能 → テキスト PDF ルート
- 拡張子が .pdf でテキスト抽出不可 → スキャン PDF ルート（VLM）
- 拡張子が .jpg / .png / .heic → 画像ルート（VLM）

ノード 3: テキスト抽出

テキスト PDF の場合

PDF パーサーを使用して直接テキストを抽出する。最もコストが低く、精度も高い。

スキャン PDF / 画像の場合

Dify の Vision 対応モデル（GPT-4o、Claude 等）を使用し、画像から直接構造化データを抽出する。従来の OCR パイプライン（画像 → 文字認識 → 後処理）よりも、VLM による直接抽出の方が以下の点で優れている。

ノード 4: パラメータ抽出（LLM ノード）

抽出したテキストまたは画像から、構造化された JSON を出力する。

System Prompt:
あなたは HR 書類処理の専門アシスタントです。
以下の入社書類から、指定されたフィールドを正確に抽出してください。

【抽出フィールド】
{
  "personal_info": {
    "full_name_kanji": "氏名（漢字）",
    "full_name_kana": "氏名（カタカナ）",
    "date_of_birth": "生年月日（YYYY-MM-DD）",
    "gender": "性別",
    "nationality": "国籍"
  },
  "address": {
    "postal_code": "郵便番号（XXX-XXXX）",
    "prefecture": "都道府県",
    "city": "市区町村",
    "street": "番地以降",
    "building": "建物名・部屋番号"
  },
  "contact": {
    "phone": "電話番号",
    "email": "メールアドレス",
    "emergency_contact_name": "緊急連絡先氏名",
    "emergency_contact_phone": "緊急連絡先電話番号",
    "emergency_contact_relationship": "続柄"
  },
  "bank_account": {
    "bank_name": "銀行名",
    "branch_name": "支店名",
    "account_type": "口座種別（普通/当座）",
    "account_number": "口座番号",
    "account_holder": "口座名義（カタカナ）"
  },
  "tax_social": {
    "my_number": "マイナンバー（12桁）",
    "pension_number": "基礎年金番号",
    "health_insurance_number": "健康保険証番号"
  }
}

【重要ルール】
1. 書類に記載がないフィールドは null を設定すること
2. 読み取りに自信がないフィールドは
   {"value": "読み取り値", "confidence": "low", "note": "理由"}
   の形式で出力すること
3. マイナンバーは12桁の数字であること。桁数が合わない場合は
   confidence を "low" に設定すること
4. 絶対に推測や補完を行わないこと

各フィールドには value、confidence（high / medium / low）、source_file を付与する。confidence が low のフィールドは後続の Human-in-the-Loop で必ず人間確認に回す設計とする。

ノード 5: フィールド検証

抽出されたデータに対して、ルールベースの検証を行う。

検証ルール:
1. 郵便番号: XXX-XXXX 形式であること
2. 電話番号: 0X-XXXX-XXXX または 0XX-XXX-XXXX 形式
3. メールアドレス: 有効な形式であること
4. マイナンバー: 12桁の数字であること
5. 口座番号: 7桁の数字であること
6. 生年月日: 入社日時点で18歳以上であること
7. 必須フィールド: 氏名、住所、銀行口座が全て入力済みであること

Dify Workflow では、コードノード（Python / JavaScript）を使用してこれらの検証を実装できる。

# コードノードでの検証例
import re
import json

def validate_fields(data):
    errors = []
    warnings = []
    
    # 郵便番号チェック
    postal = data.get("address", {}).get("postal_code", "")
    if postal and not re.match(r"^\d{3}-\d{4}$", postal):
        errors.append({
            "field": "address.postal_code",
            "value": postal,
            "message": "郵便番号の形式が不正です（XXX-XXXX）"
        })
    
    # マイナンバーチェック
    my_number = data.get("tax_social", {}).get("my_number", "")
    if isinstance(my_number, dict):
        # confidence が low の場合
        warnings.append({
            "field": "tax_social.my_number",
            "value": my_number.get("value"),
            "message": my_number.get("note"),
            "requires_human_review": True
        })
    elif my_number and not re.match(r"^\d{12}$", str(my_number)):
        errors.append({
            "field": "tax_social.my_number",
            "value": my_number,
            "message": "マイナンバーは12桁の数字である必要があります"
        })
    
    # 口座番号チェック
    account = data.get("bank_account", {}).get("account_number", "")
    if account and not re.match(r"^\d{7}$", str(account)):
        errors.append({
            "field": "bank_account.account_number",
            "value": account,
            "message": "口座番号は7桁の数字である必要があります"
        })
    
    return {
        "is_valid": len(errors) == 0,
        "errors": errors,
        "warnings": warnings,
        "requires_human_review": len(warnings) > 0
    }

ノード 6: Human-in-the-Loop（人間確認）

以下の条件で、人事担当者による確認を求める。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━
入社書類処理: 確認が必要です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━

■ 対象者: 山田 太郎（社員番号: EMP-2026-0501）
■ 入社予定日: 2026-05-01

■ 要確認項目:

  ⚠ マイナンバー: 123456789012
    → スキャン品質が低く、3桁目が不明確です。
       原本を確認してください。

  ⚠ 基礎年金番号: 未検出
    → 年金手帳のコピーが提出されていない可能性があります。

■ 抽出結果（全項目）:
  [構造化データを表示]

■ アクション:
  [承認] [修正して承認] [書類再提出依頼]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━

ノード 7: 人事システム連携（HTTP Request ノード）

確認済みのデータを、Dify Workflow の HTTP Request ノードから人事システムの API に送信する。構造化 JSON をそのまま POST するため、フィールドマッピングの設計が重要である。

連携先のシステム例:

セキュリティ設計

個人情報の取扱い

入社書類にはマイナンバー、銀行口座情報など、特に厳格な管理が求められる個人情報が含まれる。

個人情報保護の観点から、マイナンバーや口座情報を外部クラウドに送信できない場合は、Dify セルフホスト版（Docker Compose）を閉域網で運用し、ローカル VLM と組み合わせることでデータ外部送信を完全に回避できる。

エラーハンドリング

想定されるエラーと対処

導入ステップ

まとめ

HR 入社書類処理パイプラインの核心は、「AI が PDF を読めるか」ではなく、解析・抽出・検証・人間確認・システム登録という一連のプロセスを、追跡可能かつ再現可能な形で自動化することにある。

Dify Workflow は、ファイル入力の受付、VLM / OCR による情報抽出、コードノードによるバリデーション、Human-in-the-Loop による人間確認、HTTP Request ノードによる外部システム連携――これらすべてをビジュアルに設計・運用できる基盤を提供する。

特に重要な設計原則は以下の三点である。

1. 構造化出力: 自然文ではなく、フィールド単位の JSON で出力し、confidence と source を付与する
2. 人間確認の必須化: 機密性の高いフィールド（マイナンバー、口座番号）は必ず人間が最終確認する
3. セキュリティ設計: 個人情報の取扱いに応じて、セルフホスト版の採用やデータの一時保存制限を検討する

これらの原則を守ることで、人事部門の繁忙期における書類処理の負荷を大幅に軽減しつつ、正確性と安全性を担保するパイプラインを実現できる。

[LangGenius 社内事例] IDE からプロダクションを直接見に行く：LangGenius 社内で作った Ops Smart Assistant

はじめに

まず用語について。プロダクト名 Ops Smart Assistant の “Ops” は Operations の略で、日本語で言えば 運用――本番環境・サーバー・監視・ログといったインフラを担当する役割を指す。以下、本文ではこの役割を「運用（Ops）」と表記し、プロダクト名そのものは英語のままで扱う。

本番で何かが起きると、1 分ごとに損失が積み上がる。一方で、実際にコードを書いているエンジニアは Grafana / Sentry / Kubernetes の閲覧権限も PromQL の知識も持っていないことが多い。結果として毎回同じ脚本が再生される：チケットを切る → 運用チャンネルで誰かをメンションする → 待つ。同時に、運用側は 1 日の大半を同じ類いの質問に答えることに費やし、本来やるべきインフラ仕事が押し出されていく。

LangGenius 社内でも同じ穴にハマった。そこで Dify を使って、社内エンジニア向けの「Ops Smart Assistant」を組んだ。ユーザーは自然言語で 1 行問うだけ。アシスタントが問いを正しいバックエンドツールへ自動ルーティングし、ダッシュボードのスクリーンショットと AI による解釈をまとめて、ユーザーが普段使っている入口（Cursor / VS Code / Web）に返す。

本稿は LangGenius 自身が走らせ、今も使い続けている use case として、使い方と設計上のトレードオフをそのまま書き起こしたものである。

背景と課題

「待ち時間税」は実在する

従来の ChatOps では足りない理由

従来の ChatOps ボットは典型的に「命令型」だ：/metrics billing cpu 24h のような固定構文。本番をたまにしか触らない開発者にとっては、コマンドを覚えること自体がハードルになる。より本質的には、返ってくるのは大抵グラフか JSON の塊で、解釈が付いてこない。結局開発者はまた誰かに聞きに行く。

私たちが欲しかったのは「人間の言葉が通じる／正しい場所へルーティングできる／結果を説明できる」フロントエンドだった。開発者が Slack で口にするのと同じ粒度で、そのまま問えるもの。

なぜ Dify がこの用途に合うのか

この場面で Dify と噛み合うポイントは明確にある：

• 自然言語フロントエンド + ツール・オーケストレーション・バックエンド：開発者は単一の自然言語入口に向き合うだけ。ルーティング、データ取得、合成はバックエンドが引き受ける。
• 権限境界を一本化できる：ツール呼び出しが Dify 側に集まり、バックエンドの認証情報がクライアントに漏れない。監査しやすく、爆発半径を絞りやすい。
• 入口を使い回せる：同じ Dify アプリで Cursor プラグイン、VS Code 拡張、Web ページを同時に支えられる。入口ごとにロジックを書き直す必要がない。
• 結果を組み合わせられる：「ダッシュボードのスクリーンショット + AI による解釈」のような複合的な回答を、ユーザー側で二次加工させずに一発で返せる。

使い手から見た動き方

1. 自然言語で聞く。 IDE 内で 「ここ 24 時間の billing サービスの CPU 使用率どう？」 と書くだけ。コマンドも覚えなくていいし、ウィンドウも切り替えない。
2. システムが自動でルーティングする。 アシスタントは「これは指標系の問い」と判断し、ログではなくメトリクス系ツールを呼ぶ。
3. 図と文が一緒に返ってくる。 Grafana ダッシュボードのスクリーンショットと、AI が生成した解釈が数秒で戻る。
4. 普段の場所で答えを受け取る。 開発者にツールを切り替えさせない。Cursor / VS Code / Web の 3 面で同じバックエンドを共有する。

開発者側の体感の変化は 「本番を見に行く」ことが、スケジュールを要する作業から、息をするようにできる作業に変わった、に尽きる。

運用した結果

効果そのものは派手でもないし、Dify だけが実現できるものでもない。本当に削れているのは、「日常の小さな問い合わせ」にかかる組織全体の協調コストだ。普段は見えないコストだが、一度消えるとそこに戻りたくなくなる。

自分たちが溜めてきた教訓

今日まで走らせてみて、書き残す価値があると思っている教訓がいくつかある：

• まずリードオンリーから始める。 クエリを磨き切ってから、書き込み系操作（Pod の再起動、設定変更）を考える。権限境界は一度緩めると戻しにくい。
• 権限はオーケストレーション層で効かせる。Prompt 層ではなく。 モデルが「危ないツールを呼ばない」と信じるのではなく、そもそも危ないツールをユーザー入口から見えない形で外しておく。
• 「わからない」にも明確な逃げ道を。 幻覚でもっともらしい答えを作るよりは、「この問いは自信がない、oncall に相談してほしい」と言えるほうがずっといい。
• 最初からダッシュボード網羅を狙わない。 頻度上位 3〜5 種の問いをまず撃ち抜き、安定させる。ロングテールは後から足す。
• 入口を、開発者が既にいる場所に貼る。 Cursor プラグイン / VS Code 拡張 / Web――開発者のデフォルト環境に入口を置く。新しいツールを 1 つ覚えさせた時点で、たぶん使われなくなる。

まとめ

Ops Smart Assistant の本質は「新しいツール」ではない。自然言語入口・ツールオーケストレーション・結果合成という 3 つを Dify で束ね、「本番を見に行く」という小さな行為が社内で人をまたがずに済むようにしただけだ。それが削っているのは、開発者と運用のあいだに普段は見えずに溜まっている暗黙のコストである。まずクエリを磨く。閉ループは後回し。まず開発者に効かせる。組織レベルの話はその後――これが、私たちが走らせてきた中で一番残しておきたい 1 行だ。

ナレッジベース検索で関連性のない結果が返される：チャンク戦略・Embeddingモデル・Top-K/Score閾値の連携チューニング

はじめに

Dify のナレッジベースに「確かにドキュメントは入っている」のに、ユーザーの質問に対して的外れな回答が返ってくる――これはエンタープライズ導入現場で最も頻繁に報告される問題の一つである。多くのチームはまずプロンプトを修正しようとするが、実際にはプロンプト以前の 検索レイヤー に根本原因があることが大半だ。

本記事では、Dify のナレッジベース検索における Top-K、Score Threshold、Rerank モデルの三要素を中心に、チャンク分割戦略や Embedding モデル選定まで含めた総合的なチューニング手法を解説する。

症状

以下のような挙動が見られる場合、検索レイヤーの調整が必要である可能性が高い。

原因分析

検索パイプラインの全体構造を理解する

Dify のナレッジベース検索は、単一のパラメータで制御されるものではない。以下の多層構造を理解することが前提となる。

flowchart TD
    A[ユーザーの質問] --> B[クエリ前処理]
    B --> C{検索モード選択}
    C -->|ベクトル検索| D[Embedding → ANN検索]
    C -->|全文検索| E[キーワードマッチング]
    C -->|ハイブリッド検索| F[ベクトル + 全文 並列]
    D --> G[候補チャンク群 Top-N]
    E --> G
    F --> G
    G --> H{Rerank有効?}
    H -->|Yes| I[Rerank モデルで再スコアリング]
    H -->|No| J[スコア順でそのまま返却]
    I --> K[Top-K + Score Threshold でフィルタ]
    K --> L[LLM に渡すコンテキスト]
    J --> L

第1層：チャンク分割の問題

検索精度の根本はチャンクの品質にある。どれだけ検索パラメータを調整しても、チャンク自体が壊れていれば意味がない。

よくある失敗パターン：

• チャンクサイズが大きすぎる（2000トークン超）：一つのチャンクに複数のトピックが混在し、Embedding ベクトルが曖昧になる
• チャンクサイズが小さすぎる（100トークン未満）：文脈が失われ、単独では意味をなさない断片になる
• オーバーラップなし：段落の境界でちょうど重要な情報が切断される
• 自動分割に頼りきり：PDFの改行位置やHTMLタグの都合で意味的に不自然な位置で切れる

推奨チャンク設定：

第2層：Embedding モデルの選定

Embedding モデルはチャンクをベクトル空間に写像する役割を担う。日本語コンテンツにおいては、モデル選定が検索精度に直結する。

日本語対応 Embedding モデル比較：

注意：Embedding モデルを変更した場合、既存のナレッジベースは再インデックスが必要である。モデル変更は既存チャンクのベクトルを自動更新しない。

第3層：検索モードの選択

Dify は高品質インデックスモードで以下の検索方式をサポートしている：

• ベクトル検索：意味的な類似度に基づく検索。口語的・曖昧な質問に強い
• 全文検索：キーワードマッチング。型番・エラーコードなど正確な文字列検索に強い
• ハイブリッド検索：ベクトル検索と全文検索を併用し、Rerank で統合する

# ナレッジベース検索設定の例
retrieval_mode: hybrid        # hybrid / vector / fulltext
top_k: 5                      # 最終的にLLMに渡すチャンク数
score_threshold: 0.5          # この値未満のチャンクは除外
reranking_model:
  provider: cohere
  model: rerank-multilingual-v3.0

第4層：Top-K・Score Threshold・Rerank の連携

ここが最も誤解されやすいポイントである。Dify 公式ドキュメントおよび GitHub Discussion（#3171）で明確に説明されている通り：

Top-K と Score Threshold は、Rerank モデルが有効な場合、Rerank 後のフィルタリングに適用される。

つまり、Rerank を有効にしている場合と無効にしている場合で、これらのパラメータの挙動が異なる。

Rerank 無効時：

ベクトル検索 → Top-K 件取得 → Score Threshold で足切り → LLM へ

Rerank 有効時：

ベクトル検索 → 初期候補 N 件取得 → Rerank で再スコアリング →
Top-K 件に絞り込み → Score Threshold で足切り → LLM へ

この違いを理解していないと、パラメータ調整が意図通りに機能しない。

典型的な誤設定パターンと診断

パターン1：Top-K が小さすぎる（Top-K = 1〜2）

問題：ユーザーの表現とドキュメントの表現にギャップがある場合、
      正解チャンクが候補に入らずに漏れる
対策：Top-K を 5〜8 に拡大し、Rerank で絞り込む

パターン2：Score Threshold が高すぎる（0.8以上）

問題：「該当する情報が見つかりません」が頻発する
      実際にはスコア 0.6〜0.7 の有用なチャンクが存在している
対策：閾値を 0.3〜0.5 に下げてから徐々に調整

パターン3：Rerank なしで Top-K を大きくしている

問題：類似度スコアの低いノイズチャンクが大量に LLM に渡される
      コンテキストウィンドウが無関係な情報で埋まる
対策：Top-K を大きくするなら必ず Rerank を有効にする

パターン4：ハイブリッド検索で Rerank なし

問題：ベクトル検索と全文検索の結果がスコア体系の異なるまま混在
      統合的なランキングができず、結果の質が不安定
対策：ハイブリッド検索には Rerank を必ず併用する

解決策

ステップ1：チャンクの品質を確認する

まず Dify のナレッジベース管理画面で、実際のチャンク内容を目視確認する。

確認ポイント：

• 一つのチャンクが一つのトピックに対応しているか
• 重要な情報が途中で切断されていないか
• ヘッダーやフッターなどの不要なテキストが混入していないか

問題がある場合は、チャンク設定を変更して再インデックスを実行する。

ステップ2：検索モードと Rerank を設定する

推奨構成：

ステップ3：Rerank モデルを選定する

# Cohere Rerank（多言語対応、日本語精度高）
reranking_model:
  provider: cohere
  model: rerank-multilingual-v3.0

# Jina Rerank（軽量、コスト低）
reranking_model:
  provider: jina
  model: jina-reranker-v2-base-multilingual

ステップ4：段階的にパラメータを調整する

推奨チューニング手順：

1. Top-K を大きめに設定（8〜10）して、候補が十分に入ることを確認
2. Score Threshold を低め（0.3）に設定して、足切りが厳しすぎないことを確認
3. Rerank を有効化して、再スコアリング後の上位結果の品質を確認
4. Top-K を徐々に絞る（5〜6）
5. Score Threshold を徐々に上げる（0.4〜0.5）
6. 実際のユーザー質問でテストし、精度とノイズのバランスを確認

ステップ5：Workflow ノード内の検索設定を確認する

Workflow 内のナレッジ検索ノードでは、ナレッジベース本体の設定とは別にパラメータを上書きできる。この二重設定が矛盾していると、意図しない挙動になる。

# Workflow ナレッジ検索ノードの設定例
knowledge_retrieval:
  dataset_ids:
    - "dataset_abc123"
  retrieval_mode: "multiple"    # single / multiple
  top_k: 5
  score_threshold: 0.5
  reranking:
    enabled: true
    model: "rerank-multilingual-v3.0"

予防策

1. ナレッジベース設計のガイドライン

• 1ナレッジベース = 1ドメインの原則を守る。異なるドメインのドキュメントを1つのナレッジベースに混在させない
• ドキュメントアップロード前に、不要なヘッダー・フッター・目次ページを除去する前処理を実施する
• 定期的にチャンク品質を抜き取り検査し、分割の妥当性を確認する

2. Embedding モデル選定チェックリスト

• 対象コンテンツの主要言語に対応しているか
• 日本語の専門用語・固有名詞を適切にベクトル化できるか
• チャンクサイズに対して最大入力トークン数が十分か
• コストと精度のバランスが運用要件に合っているか

3. 検索品質モニタリング

検索結果の品質を継続的に監視する仕組みを構築する。

# 検索品質テストスクリプトの例
test_queries = [
    {"query": "有給休暇の申請方法は？", "expected_doc": "就業規則_休暇.pdf"},
    {"query": "VPN接続がタイムアウトする", "expected_doc": "IT_FAQ_ネットワーク.pdf"},
    {"query": "経費精算の締め日はいつ？", "expected_doc": "経理マニュアル.pdf"},
]

for test in test_queries:
    results = dify_api.knowledge_retrieval(
        query=test["query"],
        dataset_id="your_dataset_id",
        top_k=5
    )
    # 期待するドキュメントが上位に含まれているか確認
    hit = any(test["expected_doc"] in r["document_name"] for r in results)
    print(f"Query: {test['query']} -> {'PASS' if hit else 'FAIL'}")

4. 運用時のトラブルシューティングチェックリスト

• ナレッジベースのチャンク粒度は適切か（粗すぎ・細かすぎの両方を確認）
• チャンク分割で完全な文脈が切断されていないか
• Embedding モデルは対象言語に適しているか
• 複数ナレッジベース間で類似コンテンツが重複していないか
• Workflow ノードの検索設定がナレッジベース本体の設定と矛盾していないか
• Rerank モデルが有効になっているか（特にハイブリッド検索時）
• Score Threshold が厳しすぎて有効な結果を除外していないか

まとめ

検索結果が不適切な場合、「モデルがなぜ間違えたか」ではなく「システムが何を検索して何を見つけたか」を最初に確認すべきである。Dify のナレッジベース検索は、チャンク分割 → Embedding → 検索モード → Rerank → Top-K/Score Threshold の多層パイプラインであり、いずれか一つのレイヤーだけを調整しても十分な効果は得られない。

特に重要なのは、Top-K と Score Threshold が Rerank との連携で挙動が変わるという点である。この仕様を理解した上で、チャンク品質の確認から始めて段階的にチューニングすることが、安定した検索精度への最短経路となる。

参考資料

• インデックス方法と検索設定を指定 | Dify Docs
• Re-ranking | Dify Legacy Docs
• Integrate Knowledge Base within Application | Dify Legacy Docs
• GitHub Discussion #3171: Top-K and threshold usage in rerank stage

Workflow ノードのタイムアウトが頻発する：タイムアウト設定・ノード最適化・非同期パターンの実践ガイド

はじめに

Dify の Workflow を本番運用に乗せた途端、「ノードがタイムアウトしました」というエラーが頻発する――これは多くのエンタープライズチームが経験する壁である。単純に「モデルの応答が遅い」と片付けがちだが、実際にはフロー全体の設計、入力データのサイズ、外部依存の応答時間、リトライ戦略の欠如が複合的に作用している。

本記事では、Workflow ノードタイムアウトの原因を体系的に分析し、ノード分割・コンテキスト最適化・非同期処理パターンを含む具体的な解決策を解説する。

症状

原因分析

Workflow 実行の制約を理解する

Dify の Workflow は無制限にリソースを消費できるわけではない。公式の環境変数ドキュメントで以下の制約が明示されている：

タイムアウト発生の5つのレイヤー

flowchart TD
    A[タイムアウト発生] --> B{どのレイヤー?}
    B --> C[LLM応答遅延]
    B --> D[外部API遅延]
    B --> E[中間変数の肥大化]
    B --> F[同時実行数の飽和]
    B --> G[ファイル処理の長時間化]
    
    C --> C1[入力トークン過大]
    C --> C2[出力生成が長い]
    C --> C3[モデル選定が不適切]
    
    D --> D1[レート制限]
    D --> D2[外部サービス障害]
    D --> D3[タイムアウト設定不足]
    
    E --> E1[上流ノードの出力未圧縮]
    E --> E2[ループによる変数蓄積]
    
    F --> F1[Worker数不足]
    F --> F2[キュー詰まり]
    
    G --> G1[大容量PDF]
    G --> G2[VLM処理]
    G --> G3[OCR処理]

レイヤー1：LLM ノードの応答遅延

LLM ノードのタイムアウトで最も多い原因は、入力コンテキストが大きすぎる ことである。

典型例：
- ナレッジベースから Top-K=10 で取得したチャンクをすべて LLM に投入
- 上流ノードの出力（数千トークン）をそのまま下流に伝搬
- 1つの LLM ノードに「抽出 → 要約 → フォーマット → 結論生成」を全部させる

入力サイズとレスポンス時間の目安：

レイヤー2：外部 API・ツールノードの遅延

HTTP リクエストノードやカスタムツールノードが外部サービスに依存している場合、そのサービスの応答時間がボトルネックになる。

よくあるケース：

• サードパーティ API のレート制限（429 Too Many Requests）
• データベースクエリの遅延
• 外部 SaaS サービスのメンテナンス時間帯

レイヤー3：中間変数の肥大化

上流ノードの出力がそのまま下流に渡され、各ノードで蓄積されることで、MAX_VARIABLE_SIZE の制限に抵触する。

ノード A（LLM）→ 出力 5KB
  → ノード B（LLM）→ 入力 5KB + 出力 8KB = 13KB
    → ノード C（LLM）→ 入力 13KB + 出力 10KB = 23KB
      → ノード D（LLM）→ 入力 23KB + ...

レイヤー4：ファイル処理の特殊性

PDF、画像、VLM（Vision Language Model）を扱うフローは、テキストベースのフローとは桁違いの処理時間を要する。

解決策

解決策1：ノード分割（最も効果的）

一つの LLM ノードに複数の責務を持たせるのではなく、機能ごとにノードを分割する。

Before（アンチパターン）：

[単一LLMノード]
プロンプト: 以下のドキュメントを読み、
  1. 重要なポイントを抽出し
  2. 要約を作成し
  3. JSON形式でフォーマットし
  4. 推奨アクションを提案してください

After（推奨パターン）：

[ノード1: 抽出] → [ノード2: 要約] → [ノード3: フォーマット] → [ノード4: 推奨]

メリット：

• 各ノードの入出力が小さくなり、タイムアウトリスクが低減する
• 途中のノードが失敗しても、そこだけリトライできる
• 軽い処理には軽量モデル、重い判断には高性能モデルを使い分けられる

解決策2：コンテキストの圧縮

# 悪い例：上流の全出力をそのまま渡す
llm_node:
  context: "{{node_a.output}}"  # 5000トークンの生テキスト

# 良い例：要約ノードを挟んで圧縮する
summary_node:
  model: gpt-4o-mini           # 軽量モデルで要約
  prompt: "以下を300字以内で要約: {{node_a.output}}"

llm_node:
  context: "{{summary_node.output}}"  # 300字程度に圧縮済み

解決策3：モデルの使い分け

解決策4：HTTP リクエストノードのタイムアウト設定

# HTTP リクエストノードの設定
http_request:
  url: "https://api.example.com/process"
  method: POST
  timeout:
    connect: 10        # 接続タイムアウト（秒）
    read: 30           # 読み取りタイムアウト（秒）
    write: 30          # 書き込みタイムアウト（秒）
  retry:
    max_attempts: 3    # 最大リトライ回数
    backoff: exponential

解決策5：条件分岐による早期リターン

不要な処理をスキップするための条件分岐を入れる。

flowchart LR
    A[入力] --> B{入力長 > 5000トークン?}
    B -->|Yes| C[要約ノード]
    B -->|No| D[直接処理]
    C --> D
    D --> E[出力]

解決策6：環境変数の調整（セルフホスト環境）

docker-compose.yml または .env で以下を調整する：

# Workflow 実行制限の緩和
WORKFLOW_MAX_EXECUTION_TIME=1800        # 30分に延長
WORKFLOW_MAX_EXECUTION_STEPS=1000       # ステップ数上限を緩和

# 変数サイズ制限の緩和
MAX_VARIABLE_SIZE=524288                # 512KB に拡大

# HTTP リクエストタイムアウトの調整
HTTP_REQUEST_MAX_CONNECT_TIMEOUT=60
HTTP_REQUEST_MAX_READ_TIMEOUT=300
HTTP_REQUEST_MAX_WRITE_TIMEOUT=300

注意：これらの値を無制限に大きくすることは推奨しない。リソース消費が増大し、他のリクエストに影響を与える可能性がある。

解決策7：非同期処理パターン

処理時間が本質的に長いフローには、同期的な応答を期待せず、非同期処理パターンを採用する。

sequenceDiagram
    participant User as ユーザー
    participant API as Dify API
    participant WF as Workflow
    participant CB as コールバック

    User->>API: タスク投入（POST /workflows/run）
    API->>User: task_id を即時返却
    API->>WF: バックグラウンド実行開始
    WF->>WF: ノード1 → ノード2 → ... → ノードN
    WF->>CB: 完了通知（Webhook）
    User->>API: 結果取得（GET /workflows/{task_id}）
    API->>User: 処理結果を返却

Dify API の非同期呼び出し例：

# Workflow をブロッキングモードで実行（同期）
curl -X POST 'https://api.dify.ai/v1/workflows/run' \
  -H 'Authorization: Bearer {api_key}' \
  -H 'Content-Type: application/json' \
  -d '{
    "inputs": {"query": "処理対象テキスト"},
    "response_mode": "blocking"
  }'

# Workflow をストリーミングモードで実行（非同期）
curl -X POST 'https://api.dify.ai/v1/workflows/run' \
  -H 'Authorization: Bearer {api_key}' \
  -H 'Content-Type: application/json' \
  -d '{
    "inputs": {"query": "処理対象テキスト"},
    "response_mode": "streaming"
  }'

予防策

1. Workflow 設計レビューチェックリスト

• 1つの LLM ノードに3つ以上の責務が集中していないか
• 上流ノードの出力サイズを把握しているか
• 外部 API 呼び出しにタイムアウトとリトライが設定されているか
• ファイル処理ノードが直列チェーンに含まれていないか
• 条件分岐で不要な処理をスキップしているか

2. 負荷テストの実施

本番投入前に、以下の条件でテストする：

# 並行実行テスト（10件同時）
for i in $(seq 1 10); do
  curl -X POST 'https://api.dify.ai/v1/workflows/run' \
    -H 'Authorization: Bearer {api_key}' \
    -H 'Content-Type: application/json' \
    -d '{"inputs": {"query": "テスト入力'$i'"}, "response_mode": "blocking"}' &
done
wait

3. モニタリングとアラート

Workflow の実行ログを定期的に確認し、以下の指標を監視する：

4. トラブルシューティング手順

タイムアウトが発生した場合の推奨調査順序：

1. ログで特定：どのノードでタイムアウトが発生しているかを確認
2. 入力サイズを確認：該当ノードへの入力変数のサイズを確認
3. 外部依存を確認：外部 API のレスポンス時間やステータスを確認
4. 同時実行を確認：同時間帯の Workflow 実行数を確認
5. 分割可能性を検討：該当ノードを分割・簡素化できないかを検討
6. 非同期化を検討：処理が本質的に長時間を要する場合、非同期パターンに切り替え

まとめ

Workflow のタイムアウト問題は、「モデルの速度の問題」ではなく「フロー設計の問題」である。本当に安定したフローは、ノード分割による責務の分離、コンテキストの圧縮による入力サイズの制御、失敗時のリトライと降格パス、そして本質的に長い処理への非同期化設計から生まれる。

環境変数のタイムアウト値を単に延長するのは応急処置にすぎない。根本的な解決は、Workflow の設計そのものを見直すことにある。

参考資料

• Environment Variables - Dify Docs
• Dify と Gradio で作る PDF 処理ワークフローアプリケーション
• Dify x VLM であらゆる画像・PDF を JSON に変換する

同じ質問に対して毎回異なる回答が返される：Temperature・システムプロンプト・検索安定性のチューニング

はじめに

「同じ質問をしているのに、毎回違う回答が返ってくる」――これはエンタープライズ環境で Dify を運用するチームから最も多く寄せられる不満の一つである。ユーザーから見れば「システムが不安定」に映るこの問題だが、実際にはシステムが壊れているわけではなく、LLM の出力制御が適切に設計されていない状態を示している。

本記事では、回答の不一致を引き起こす3つのレイヤー（LLM パラメータ、プロンプト構造、検索の安定性）を分析し、エンタープライズ品質の安定した出力を実現するための具体的な手法を解説する。

症状

原因分析

回答の不一致は、単一の原因ではなく3つのレイヤーが複合的に作用して発生する。

flowchart TD
    A[回答の不一致] --> B[レイヤー1: LLMパラメータ]
    A --> C[レイヤー2: プロンプト構造]
    A --> D[レイヤー3: 検索の安定性]
    
    B --> B1[Temperature が高い]
    B --> B2[Top-P が高い]
    B --> B3[Presence/Frequency Penalty]
    
    C --> C1[役割定義が曖昧]
    C --> C2[出力形式が未指定]
    C --> C3[判断基準が不明確]
    
    D --> D1[検索結果が毎回異なる]
    D --> D2[Top-K が大きすぎる]
    D --> D3[Rerank スコアの揺れ]

レイヤー1：LLM パラメータの影響

Temperature（最も重要）

Temperature は LLM の出力における確率分布の「平坦度」を制御するパラメータである。

重要：Temperature = 0.0 に設定しても、完全に同一の出力が保証されるわけではない。LLM プロバイダのインフラ側での浮動小数点演算の差異や、バッチ処理の違いにより、わずかな揺れが生じる可能性がある。

Top-P（Nucleus Sampling）

Top-P は、累積確率が指定値に達するまでのトークン候補のみを考慮する。Temperature と併用する場合、両方のパラメータが出力の多様性に影響する。

# 安定性を最大化する設定例
llm_settings:
  temperature: 0.1
  top_p: 0.9          # 1.0に近いほど制約が少ない
  max_tokens: 2048
  presence_penalty: 0.0
  frequency_penalty: 0.0

Dify LLM ノードでの設定

Dify の LLM ノードでは、これらのパラメータをノードごとに個別設定できる。

# Workflow LLM ノードの設定
llm_node:
  model: gpt-4o
  temperature: 0.1        # 安定性重視
  top_p: 0.95
  max_tokens: 1024
  system_prompt: |
    あなたは社内規定に基づいて回答するアシスタントです。
    ...

レイヤー2：プロンプト構造の影響

Temperature を下げるだけでは安定性は確保できない。プロンプトの構造が曖昧だと、モデルは「どう答えるか」の自由度が高いため、毎回異なるアプローチで回答する。

不安定なプロンプトの例：

あなたは社内のヘルプデスクです。
ユーザーの質問に丁寧に答えてください。

このプロンプトでは以下が未定義：

• 回答のフォーマット（箇条書きか、段落か）
• 情報源の優先順位（ナレッジベースの情報を使うのか、一般知識か）
• 回答の長さの目安
• 情報が見つからない場合の挙動
• 推測や補完をしてよいかどうか

安定したプロンプトの例：

あなたは株式会社ABCの社内ITヘルプデスクアシスタントです。

## 回答ルール
1. 回答は必ず「結論」「詳細」「参考情報」の3セクションで構成すること
2. 回答の根拠は、提供されたコンテキスト情報のみに基づくこと
3. コンテキストに該当する情報がない場合は「この質問についての情報は
   現在のナレッジベースに含まれていません。IT部門（内線: 1234）に
   お問い合わせください」と回答すること
4. 推測や一般的な知識に基づく補完は行わないこと
5. 回答は200文字以内に収めること

## 出力フォーマット
### 結論
[1〜2文で端的に回答]

### 詳細
[必要に応じて箇条書きで補足]

### 参考情報
[参照したドキュメント名を記載]

レイヤー3：検索の安定性

ナレッジベースを使用している場合、同じ質問に対して毎回異なるチャンクが検索されると、LLM に渡されるコンテキストが変わり、結果として回答も変動する。

検索結果が不安定になる原因：

解決策

ステップ1：Temperature を適切に設定する

シナリオ別推奨設定：

ステップ2：プロンプトに構造的制約を組み込む

構造化出力の強制：

## System Prompt

以下のフォーマットに従って回答してください。
フォーマットから逸脱しないでください。

回答フォーマット:
---
【判定】: [該当 / 非該当 / 判定不能]
【根拠】: [コンテキストから引用した該当箇所]
【補足】: [必要な場合のみ、1〜2文で補足]
---

JSON 出力の強制（Workflow ノード間のデータ受け渡し）：

以下のJSON形式で出力してください。JSON以外のテキストは出力しないでください。

{
  "category": "技術質問 | 手続き質問 | クレーム | その他",
  "confidence": 0.0〜1.0,
  "answer": "回答テキスト",
  "source": "参照したドキュメント名"
}

ステップ3：検索の安定性を確保する

# 安定性重視のナレッジベース検索設定
knowledge_retrieval:
  retrieval_mode: hybrid
  top_k: 3                    # 小さめに設定して境界の揺れを抑制
  score_threshold: 0.6        # 高めに設定して低スコアの不安定チャンクを除外
  reranking:
    enabled: true
    model: rerank-multilingual-v3.0

検索安定性向上のためのポイント：

1. Top-K を小さくする：Top-K=3 なら、上位3件は比較的安定する。Top-K=10 にすると下位の入れ替わりが激しくなる
2. Score Threshold を高めに設定する：低スコアのチャンクほどスコアの揺れで順位が変動しやすい
3. Rerank を有効にする：Rerank モデルが一貫した基準で再スコアリングすることで、結果の安定性が向上する
4. 単一ナレッジベースで検索する：複数ナレッジベースのマージは結果の不安定性を増大させる

ステップ4：出力の後処理で安定性を補強する

LLM の出力に後処理を加えることで、表面的な揺れを吸収する。

flowchart LR
    A[ユーザー質問] --> B[ナレッジ検索]
    B --> C[LLM生成]
    C --> D[フォーマット検証ノード]
    D -->|OK| E[回答返却]
    D -->|NG| F[フォーマット修正ノード]
    F --> E

Code ノードによるフォーマット検証の例：

import json

def main(text: str) -> dict:
    """LLM出力が指定フォーマットに準拠しているか検証する"""
    try:
        result = json.loads(text)
        required_keys = ["category", "confidence", "answer", "source"]
        
        for key in required_keys:
            if key not in result:
                return {
                    "valid": False,
                    "error": f"必須キー '{key}' が欠落しています",
                    "original": text
                }
        
        if result["confidence"] < 0 or result["confidence"] > 1:
            return {
                "valid": False,
                "error": "confidence の値が範囲外です",
                "original": text
            }
        
        return {"valid": True, "data": result}
    
    except json.JSONDecodeError:
        return {
            "valid": False,
            "error": "JSON パース失敗",
            "original": text
        }

ステップ5：シード値の活用（対応モデルの場合）

一部の LLM プロバイダは seed パラメータをサポートしており、同一シードを指定することで出力の再現性を高められる。

# OpenAI API の seed パラメータ（対応モデルの場合）
llm_settings:
  model: gpt-4o
  temperature: 0.0
  seed: 42                # 固定シード値

注意：seed パラメータは出力の再現性を「高める」が、完全な同一性を「保証」するものではない。また、Dify のノード設定画面から直接 seed を設定できない場合は、API 経由でのカスタム設定が必要になる。

予防策

1. アプリケーション設計時のパラメータ設計書

新しい Dify アプリケーションを構築する際、以下の項目を事前に決定しておく。

2. 回帰テストの実施

定期的に同一の質問セットを投入し、回答の一貫性をチェックする。

import hashlib

def test_consistency(api_client, query: str, runs: int = 5):
    """同じ質問を複数回実行し、回答の一貫性を確認する"""
    answers = [api_client.chat(query=query)["answer"] for _ in range(runs)]
    hashes = [hashlib.md5(a.encode()).hexdigest() for a in answers]
    unique = len(set(hashes))
    rate = 1 - (unique - 1) / runs
    return {"query": query, "unique_answers": unique, "consistency_rate": rate}

for q in ["有給休暇の申請方法は", "経費精算の締め日はいつ", "VPN接続できない場合の対処法"]:
    r = test_consistency(client, q)
    print(f"[{'OK' if r['consistency_rate']>=0.8 else 'WARN'}] {q}: {r['consistency_rate']:.0%}")

3. 安定性に関するチェックリスト

• Temperature は用途に応じて適切に設定されているか
• システムプロンプトに出力フォーマットが明示されているか
• 「情報がない場合」の挙動が定義されているか
• 推測や補完の可否がプロンプトに明記されているか
• ナレッジベース検索の Top-K は必要最小限か
• Score Threshold は十分に高く設定されているか
• Rerank が有効になっているか
• 定期的な回帰テストの仕組みがあるか

まとめ

回答の不一致が発生した場合、Temperature だけに注目するのは不十分である。真にエンタープライズ品質の安定した出力を実現するためには、以下の3層を統合的に設計する必要がある：

1. LLM パラメータ層：Temperature を用途に応じて設定し、不必要な発散を抑制する
2. プロンプト構造層：出力フォーマット、判断基準、拒否条件を明示的に定義し、モデルの自由度を制限する
3. 検索安定性層：Top-K を絞り、Score Threshold を高めに設定し、Rerank で一貫した再スコアリングを行う

これら3層のうち、最も効果が大きいのはプロンプト構造の改善であることが多い。Temperature を下げるだけで解決しない場合は、まずプロンプトの構造化を見直すことを推奨する。

参考資料

• LLM ノード | Dify Docs（日本語）
• Dify x Claude でつくる2分週報 AI
• 現場で使える！Dify x Python ハイブリッド開発実践

大容量ファイルのアップロードが失敗する：サイズ制限・UPLOAD_FILE_SIZE_LIMIT・Nginx設定・分割アップロードの実践

はじめに

ナレッジベース構築プロジェクトにおいて、「100MB超のPDFをアップロードしようとしたら失敗する」という問題は非常に頻繁に発生する。ファイルが大きいほど、問題は単なる「アップロードの失敗」にとどまらず、リバースプロキシの制限、バックエンドの設定制限、ストレージ書き込み、後続の解析・チャンク分割・インデックス処理にまで連鎖する。

本記事では、大容量ファイルのアップロード失敗を引き起こす複数のレイヤーを特定し、各レイヤーの設定変更から前処理パイプラインの構築まで、実践的な解決策を解説する。

症状

原因分析

大容量ファイルのアップロード失敗は、以下の5つのレイヤーのいずれか（または複数）で発生する。

flowchart TD
    A[ファイルアップロード] --> B[レイヤー1: ブラウザ/クライアント]
    B --> C[レイヤー2: リバースプロキシ Nginx/Ingress]
    C --> D[レイヤー3: Dify バックエンド]
    D --> E[レイヤー4: オブジェクトストレージ]
    E --> F[レイヤー5: 後続処理パイプライン]
    
    B -.->|タイムアウト| B1[接続切れ]
    C -.->|413エラー| C1[body size制限]
    D -.->|サイズ制限| D1[UPLOAD_FILE_SIZE_LIMIT]
    E -.->|書込失敗| E1[権限/容量]
    F -.->|処理超過| F1[解析タイムアウト]

レイヤー1：ブラウザ / クライアント側

• ブラウザのメモリ制限（特に大量のタブを開いている場合）
• ネットワーク接続の不安定さ
• ブラウザのファイルアップロードタイムアウト

レイヤー2：リバースプロキシ（Nginx / Kubernetes Ingress）

これが最も頻度の高い失敗ポイントである。Dify のセルフホスト環境では、ほぼ必ず Nginx または Kubernetes Ingress がフロントに配置される。デフォルト設定では、リクエストボディのサイズ制限が 1MB〜10MB 程度であることが多い。

Nginx のデフォルト設定：

# デフォルト: client_max_body_size 1m;
# → 1MB を超えるファイルが 413 エラーで拒否される

レイヤー3：Dify バックエンドの設定

Dify 自体にもファイルサイズの上限が環境変数で設定されている。

レイヤー4：オブジェクトストレージ

Dify はファイルの保存先として以下をサポートしている：

• ローカルファイルシステム
• Amazon S3
• Azure Blob Storage
• Google Cloud Storage
• Tencent Cloud COS
• Huawei Cloud OBS
• MinIO（S3互換）

各ストレージにはマルチパートアップロードの対応状況や単一アップロード上限（S3: 5GB、Azure Blob: 256MB等）が異なるため、事前に確認が必要である。

レイヤー5：後続処理パイプライン

ファイルのアップロード自体が成功しても、ナレッジベースへの登録には以下の後続処理が必要であり、それぞれにタイムアウトのリスクがある。

アップロード → テキスト抽出 → チャンク分割 → Embedding生成 → ベクトルDB書込

100MB超のPDFの場合：

• テキスト抽出に数分〜数十分
• 数千チャンクの Embedding 生成に大量のAPIコール
• ベクトルDB への大量書き込み

解決策

解決策1：Nginx / リバースプロキシの設定変更

Nginx の場合：

# /etc/nginx/nginx.conf または /etc/nginx/conf.d/default.conf

http {
    # リクエストボディの最大サイズを 200MB に拡大
    client_max_body_size 200m;
    
    # アップロードタイムアウトの延長
    client_body_timeout 300s;
    
    # プロキシタイムアウトの延長
    proxy_connect_timeout 300s;
    proxy_send_timeout 300s;
    proxy_read_timeout 300s;
    
    # 大容量リクエストのバッファ設定
    client_body_buffer_size 10m;
    client_body_temp_path /tmp/nginx_upload;
}

Kubernetes Ingress（Nginx Ingress Controller）の場合：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: dify-ingress
  annotations:
    # リクエストボディの最大サイズ
    nginx.ingress.kubernetes.io/proxy-body-size: "200m"
    # タイムアウト設定
    nginx.ingress.kubernetes.io/proxy-connect-timeout: "300"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "300"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "300"
spec:
  rules:
    - host: dify.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: dify-web
                port:
                  number: 80

Docker Compose 同梱の Nginx の場合： docker/nginx/conf.d/default.conf を編集し、同様に client_max_body_size 200m; とプロキシタイムアウトを設定する。

解決策2：Dify 環境変数の調整

.env ファイルまたは docker-compose.yml で以下を設定する：

# ファイルアップロード制限の拡大
UPLOAD_FILE_SIZE_LIMIT=200          # 200MB に変更
UPLOAD_FILE_BATCH_LIMIT=10          # バッチ上限を10ファイルに

# ドキュメント解析エンジンの変更（大容量PDF対応）
ETL_TYPE=Unstructured               # Unstructured.io を使用
UNSTRUCTURED_API_URL=http://unstructured:8000/general/v0/general

# ワーカー設定の調整
CELERY_WORKER_AMOUNT=4              # バックグラウンドワーカー数

設定変更後の反映：

# Docker Compose 環境の場合
cd /path/to/dify/docker
docker compose down
docker compose up -d

# 設定が反映されたことを確認
docker compose exec api env | grep UPLOAD

解決策3：オブジェクトストレージの設定

Amazon S3 の場合：

# .env ファイル
STORAGE_TYPE=s3
S3_ENDPOINT=https://s3.ap-northeast-1.amazonaws.com
S3_BUCKET_NAME=dify-storage
S3_ACCESS_KEY=YOUR_ACCESS_KEY
S3_SECRET_KEY=YOUR_SECRET_KEY
S3_REGION=ap-northeast-1

MinIO（ローカルS3互換）の場合：

# .env ファイル
STORAGE_TYPE=s3
S3_ENDPOINT=http://minio:9000
S3_BUCKET_NAME=dify-storage
S3_ACCESS_KEY=minioadmin
S3_SECRET_KEY=minioadmin
S3_REGION=us-east-1
S3_USE_AWS_MANAGED_IAM=false

解決策4：ファイル前処理パイプライン

100MB超のPDFをそのままアップロードするのではなく、事前に前処理を行うことを強く推奨する。

Python による PDF 前処理スクリプト（PyPDF2使用）：

from PyPDF2 import PdfReader, PdfWriter
import os

def split_pdf(input_path: str, output_dir: str, max_pages: int = 50):
    """大容量PDFをページ数で分割する"""
    reader = PdfReader(input_path)
    os.makedirs(output_dir, exist_ok=True)
    for start in range(0, len(reader.pages), max_pages):
        writer = PdfWriter()
        for p in range(start, min(start + max_pages, len(reader.pages))):
            writer.add_page(reader.pages[p])
        out = os.path.join(output_dir, f"part{start//max_pages+1}.pdf")
        with open(out, "wb") as f:
            writer.write(f)

# 使用例: split_pdf("/path/to/large.pdf", "/path/to/output/", max_pages=30)

OCR 前処理（スキャンPDFの場合）：

# OCRmyPDF で日本語OCR処理
pip install ocrmypdf
ocrmypdf --language jpn --deskew --clean input_scan.pdf output_ocr.pdf

解決策5：Dify API によるプログラマティックアップロード

大容量ファイルのアップロードをブラウザUIではなく、APIから行うことで、タイムアウトの制御がしやすくなる。

import requests, os

def upload_document(api_base, api_key, dataset_id, file_path):
    url = f"{api_base}/datasets/{dataset_id}/document/create_by_file"
    with open(file_path, "rb") as f:
        resp = requests.post(url,
            headers={"Authorization": f"Bearer {api_key}"},
            files={"file": (os.path.basename(file_path), f, "application/pdf")},
            data={"data": '{"indexing_technique":"high_quality","process_rule":{"mode":"automatic"}}'},
            timeout=600)
    return resp.json() if resp.status_code == 200 else None

# 分割済みPDFを順次アップロード
for pdf in sorted(os.listdir("/path/to/split_pdfs/")):
    if pdf.endswith(".pdf"):
        upload_document("https://dify.example.com/v1", "YOUR_KEY", "DATASET_ID",
                       f"/path/to/split_pdfs/{pdf}")

解決策6：テーマ別ナレッジベース分割

大容量のドキュメントを1つのナレッジベースに詰め込むのではなく、テーマ別に分割する。

Before:
  ナレッジベース「全社マニュアル」 ← 500MB分のPDF

After:
  ナレッジベース「人事規程」      ← 就業規則、福利厚生、評価制度
  ナレッジベース「IT手順書」      ← VPN、メール、セキュリティ
  ナレッジベース「経理マニュアル」  ← 経費精算、請求、税務
  ナレッジベース「製品仕様書」    ← 製品A仕様、製品B仕様

メリット：

• 個別のドキュメント更新が容易
• 検索精度の向上（ドメインが絞られるため）
• アップロード失敗時の影響範囲が限定される

予防策

1. アップロード前チェックリスト

ファイルをアップロードする前に、以下を確認する：

• ファイルサイズが UPLOAD_FILE_SIZE_LIMIT 以下か
• Nginx / Ingress の client_max_body_size が十分か
• 不要なページ（空白、表紙、目次、索引）を除去したか
• スキャンPDFの場合、OCR処理済みか
• ファイルが破損していないか（PDFリーダーで開けるか確認）

2. 設定値の整合性チェック

各レイヤーの制限値が矛盾していないことを確認する。

Nginx client_max_body_size  >=  UPLOAD_FILE_SIZE_LIMIT  >=  実際のファイルサイズ

よくある矛盾の例：

3. 大容量ファイル運用フローの標準化

flowchart TD
    A[原本PDF] --> B{サイズ > 15MB?}
    B -->|No| C[そのままアップロード]
    B -->|Yes| D[前処理パイプライン]
    D --> E[空白ページ除去]
    E --> F[OCR処理 if スキャンPDF]
    F --> G{サイズ > 15MB?}
    G -->|No| C
    G -->|Yes| H[チャプター/ページ分割]
    H --> I[分割ファイルを順次アップロード]
    C --> J[インデックス処理完了を確認]
    I --> J
    J --> K[検索品質テスト]

4. モニタリング

API 経由で GET /datasets/{dataset_id}/documents を定期的に呼び出し、各ドキュメントの indexing_status が completed になっていることを確認する。processing のまま長時間停滞している場合は、後続パイプラインでのタイムアウトを疑う。

まとめ

100MB超のPDFアップロード失敗は、単一の設定変更では解決しないことが多い。Nginx のリクエストボディサイズ制限、Dify の UPLOAD_FILE_SIZE_LIMIT、オブジェクトストレージの設定、そして後続の解析パイプラインのタイムアウトが、すべて連鎖的に影響する。

最も効果的なアプローチは、アップロードの制限値を調整するだけでなく、ファイルの前処理パイプラインを構築し、大容量ファイルを適切なサイズに分割・最適化してからアップロードすることである。これはアップロードの成功率を上げるだけでなく、ナレッジベースの検索品質も向上させる。

参考資料

• Environment Variables - Dify Docs
• Deploy Dify with Docker Compose
• ファイルアップロード | Dify Docs（日本語）
• ナレッジパイプラインをオーケストレーションする | Dify Docs

Agent のツール呼び出しが無限ループに陥る：ツール定義の明確化・最大イテレーション数・フォールバック設計

はじめに

Dify の Agent が同じツールを何度も繰り返し呼び出す、あるいは「情報が見つからない → 再検索 → また見つからない」のループに入って止まらなくなる――この問題はトークンコストの浪費だけでなく、ユーザー体験を著しく損なう。

Agent の無限ループは一見「モデルが賢くない」ように見えるが、実際にはシステム設計の問題であることが大半だ。Dify の公式ドキュメントでは、Agent ノードに Maximum Iterations 設定が存在すること、環境変数 MAX_ITERATIONS_NUM でプラットフォームレベルの上限を設定できることが明示されている。つまり、この問題は「プラットフォームの上限設定 + ツール定義の品質 + プロンプトの退出条件」の三要素を適切に設計することで、大幅に軽減できる。

症状

原因分析

Agent の意思決定ループを理解する

Dify の Agent（ReAct方式）は、以下のループを繰り返すことで問題を解決する。

flowchart TD
    A[ユーザーの質問] --> B[思考 Thought]
    B --> C{ツール呼び出しが必要?}
    C -->|Yes| D[行動 Action: ツール呼び出し]
    D --> E[観察 Observation: ツールの結果]
    E --> F{回答できる?}
    F -->|No| B
    F -->|Yes| G[最終回答 Final Answer]
    C -->|No| G

無限ループは、「回答できる?」のステップで常に「No」と判断される 場合に発生する。

原因1：ツール定義（Description）が曖昧

ツールの description はモデルがツールを「いつ使うか」「何を期待できるか」を判断する最も重要な入力である。

悪い例：

tool:
  name: search_database
  description: "データベースを検索します"

この定義では以下が不明：

• どんなデータベースか
• どんなクエリに対応しているか
• 結果が見つからない場合はどうなるか
• どんな形式で結果が返るか

良い例：

tool:
  name: search_employee_database
  description: |
    社員情報データベースを検索します。
    入力: 社員名（姓名）または社員番号
    出力: 社員名、部署、内線番号、メールアドレスを含むJSON
    制約: 
    - 部分一致検索に対応
    - 結果が見つからない場合は空の配列 [] を返す
    - 一度に最大10件まで返す
    注意: 退職者の情報は含まれません

原因2：ツールのエラーハンドリングが不十分

ツールがエラーを返した場合や結果が空の場合に、Agent がそれを「もう一度試せば結果が変わるかもしれない」と解釈するケースが多い。

ループの例:
1. Agent: search_database("田中太郎") → 結果なし
2. Agent: "もう少し調べてみます"
3. Agent: search_database("田中 太郎") → 結果なし
4. Agent: "別の方法で検索します"
5. Agent: search_database("タナカタロウ") → 結果なし
6. Agent: "さらに調べます..."  → 以後繰り返し

原因3：Maximum Iterations が未設定

Dify の Agent ノードには Maximum Iterations パラメータがあるが、デフォルト値が十分に制限的でない場合、コストが膨張してから初めて停止する。

原因4：プロンプトに退出条件がない

多くのシステムプロンプトが「ユーザーの質問に答えてください」という前向きな指示だけで、「どういう場合に諦めるか」を明示していない。

典型的な問題のあるプロンプト：

あなたは社内ヘルプデスクアシスタントです。
ユーザーの質問に対して、利用可能なツールを活用して
正確な回答を提供してください。

この指示だけでは、Agent は「正確な回答を提供する」ことを最優先し、見つからない場合でも諦めずに試行を続ける。

原因5：ツール間の役割分担が不明確

複数のツールが似た機能を持つ場合、Agent がどちらを使うべきか判断できず、交互に呼び出すループに入ることがある。

1. Agent: search_knowledge_base("VPN設定方法") → 部分的な結果
2. Agent: search_faq("VPN設定方法") → 別の部分的な結果
3. Agent: "もう少し調べます"
4. Agent: search_knowledge_base("VPN 設定 手順") → 似た結果
5. Agent: search_faq("VPN接続できない") → 別の結果
6. → 繰り返し

解決策

解決策1：Maximum Iterations を適切に設定する

Agent ノードレベル：

Dify の Workflow エディタで Agent ノードを選択し、Maximum Iterations を設定する。

プラットフォームレベル（セルフホスト環境）：

# .env ファイル
MAX_ITERATIONS_NUM=15    # 全Agent共通の最大イテレーション数

解決策2：ツール定義を改善する

各ツールに以下の情報を含める：

tools:
  - name: search_employee
    description: |
      社員情報を検索します。
      
      【用途】社員の連絡先、所属部署を調べるとき
      【入力】社員名（姓または名）、または社員番号（E+数字5桁）
      【出力形式】
        - 見つかった場合: {"found": true, "employees": [...]}
        - 見つからなかった場合: {"found": false, "message": "該当なし"}
      【制限事項】
        - 退職者は検索対象外
        - 一度に10件まで
      【注意】結果が見つからなかった場合、パラメータを変えて
        再度呼び出しても結果は変わりません。
    parameters:
      query:
        type: string
        description: "社員名または社員番号"
        required: true

  - name: search_knowledge_base
    description: |
      社内ナレッジベースを検索します。
      
      【用途】社内規程、手順書、マニュアルの内容を調べるとき
      【入力】自然言語のクエリ（日本語）
      【出力形式】
        - 関連チャンクのリスト（最大5件、relevance_score付き）
        - 関連情報がない場合: 空リスト []
      【このツールで検索できないもの】
        - 社員の個人情報 → search_employee を使用
        - リアルタイムのシステム障害情報 → check_system_status を使用
      【注意】同じクエリで2回以上呼び出しても結果は同じです。
        結果が不十分な場合はクエリの表現を変えてください。

解決策3：システムプロンプトに退出条件を明記する

# System Prompt

あなたは株式会社ABCの社内ヘルプデスクAIアシスタントです。

## 基本ルール
- 利用可能なツールを活用して、ユーザーの質問に正確に回答してください
- 回答の根拠は必ずツールの検索結果に基づくこと

## 退出条件（重要）
以下の条件に該当する場合は、ツール呼び出しを停止し、
適切な回答を返してください：

1. **同じツールを2回呼び出しても有効な結果が得られない場合**
   → 「申し訳ございませんが、現在のナレッジベースにはこの質問に
      該当する情報が見つかりませんでした。IT部門（内線: 1234）に
      お問い合わせください。」

2. **ツールがエラーを返した場合**
   → エラー内容をユーザーに伝え、別の問い合わせ方法を案内してください

3. **ユーザーの質問が対応範囲外の場合**
   → 対応範囲外であることを伝え、適切な問い合わせ先を案内してください

4. **すでに十分な情報が得られている場合**
   → 追加のツール呼び出しは不要です。得られた情報で回答してください

## 禁止事項
- 同じツールを同じパラメータで2回以上呼び出さないこと
- 3回連続でツール呼び出しが空結果だった場合、それ以上の試行を行わないこと
- 「もう少し調べます」「別の方法で検索します」と言って呼び出しを続けないこと

解決策4：フォールバックパスを設計する

Agent が行き詰まった場合の段階的なフォールバックを設計する。

flowchart TD
    A[ユーザー質問] --> B[ツール呼び出し 1回目]
    B --> C{有効な結果?}
    C -->|Yes| D[回答生成]
    C -->|No| E[ツール呼び出し 2回目 クエリ変更]
    E --> F{有効な結果?}
    F -->|Yes| D
    F -->|No| G[フォールバック: ナレッジベース直接検索]
    G --> H{有効な結果?}
    H -->|Yes| I[ナレッジベースの情報で回答]
    H -->|No| J[人間への引き継ぎメッセージ]

Workflow での実装： Agent ノードの後に IF/ELSE ノードを配置し、Agent 出力に「見つかりませんでした」が含まれる場合はナレッジベース直接検索ノードへ、それでも結果がなければ人間引き継ぎ用の LLM ノードへ分岐させる。

解決策5：ツール間の役割境界を明確にする

## ツール使用ガイドライン（System Prompt に含める）

利用可能なツールと使い分け：

| 質問の種類 | 使用するツール | 使わないツール |
|-----------|--------------|--------------|
| 社員の連絡先・部署 | search_employee | search_knowledge_base |
| 社内規程・手順 | search_knowledge_base | search_employee |
| システム障害の状況 | check_system_status | search_knowledge_base |
| 会議室の予約状況 | check_room_availability | search_employee |

重要: 上記の対応表に従ってツールを選択してください。
対応表にないタイプの質問には、ツール呼び出しを行わず
「この種類のお問い合わせには対応しておりません」と回答してください。

解決策6：Agent ログによるデバッグ

無限ループが発生した場合、まず Agent のログを確認する。

確認すべきポイント：

Dify コンソールの「ログと注釈」タブから、問題の会話を選択し、各イテレーションの Thought / Action / Observation を順に確認してループの開始点を特定する。

予防策

1. Agent 設計チェックリスト

新しい Agent を構築する際に以下を確認する：

• Maximum Iterations が設定されているか（推奨: 5〜10）
• 各ツールの description に「結果がない場合」の挙動が明記されているか
• システムプロンプトに退出条件が含まれているか
• 複数ツールの役割境界が明確か
• フォールバックパス（人間への引き継ぎ等）が設計されているか
• ツールのエラーレスポンスが Agent にとって理解可能な形式か

2. テストシナリオ

本番投入前に、以下の「失敗シナリオ」を必ずテストする：

3. コスト監視

Agent の無限ループは直接的にトークンコストに反映される。

# 環境変数でコスト関連の上限を設定
MAX_ITERATIONS_NUM=15              # イテレーション上限
WORKFLOW_MAX_EXECUTION_TIME=300    # 5分でタイムアウト

監視すべき指標：

4. 段階的な Agent 複雑化

最初からすべてのツールを持たせず、Phase 1（ナレッジベース検索のみ）→ Phase 2（+ 社員検索）→ Phase 3（+ システム状態確認）→ Phase 4（+ 予約・申請系）と段階的にツールを追加し、各段階で退出条件とルーティングを検証する。

まとめ

Agent の無限ループは「モデルの能力不足」ではなく、「いつ停止すべきかをシステムが教えていない」ことが根本原因である。効果的な対策は以下の三要素を同時に設計することで実現できる：

1. プラットフォーム上限：Maximum Iterations と MAX_ITERATIONS_NUM で物理的な停止条件を設定する
2. ツール定義の明確化：各ツールの description に、用途・入出力・制限事項・結果が空の場合の挙動を明記する
3. プロンプトの退出条件：「何回試しても結果がない場合は停止する」「同じツールを同じパラメータで再呼び出ししない」といった明示的なルールをシステムプロンプトに含める

これら三要素のうち一つでも欠けていると、無限ループのリスクは残り続ける。Agent の設計は「何ができるか」だけでなく、「いつ諦めるか」まで含めて完成となる。

参考資料

• エージェント | Dify Docs（日本語）
• Agent | Dify Legacy Docs
• Environment Variables - Dify Docs
• ReAct エージェントの基本構造と「思考・行動・観察」ループ | note.com

本番環境 vs 検証環境 – 構成差異・リソース設計・セキュリティ強化の実務ガイド

Dify Enterprise を検証環境で動かせたからといって、そのまま本番に持っていけるわけではない。検証環境と本番環境の違いは「ユーザー数が増える」程度の話ではなく、可用性・可観測性・復旧能力という根本的なリスクモデルが異なる。

Dify Enterprise の公式ドキュメント（Resources Checklist）では、testing deployment と production deployment の 2 種類の推奨スペックが明示されている。検証環境は worker node 1 台・4 CPU / 16 GB RAM 程度で済むが、本番環境は worker node 6 台・各 8 CPU / 32 GB RAM に加え、PostgreSQL・Redis・Qdrant もクラスタ構成での運用が前提となる。つまり公式が「検証」と「本番」を完全に別のリスクモデルとして定義している。

本記事では、日本企業のエンタープライズ IT チームが Dify Enterprise を本番展開する際に押さえるべき構成差異を、リソース・永続化・ログ・セキュリティ・バックアップの 5 軸で整理する。

1. リソースサイジングの違い

1.1 公式推奨スペック比較

1.2 Kubernetes リソース定義の考え方

検証環境では resources.requests / resources.limits を明示しなくても動作するが、本番では必ず定義する。以下は本番向けの参考値である。

# values.yaml -- 本番環境向け API サーバーのリソース例
api:
  replicas: 3
  resources:
    requests:
      cpu: "2"
      memory: "4Gi"
    limits:
      cpu: "4"
      memory: "8Gi"

worker:
  replicas: 3
  resources:
    requests:
      cpu: "2"
      memory: "4Gi"
    limits:
      cpu: "4"
      memory: "8Gi"

web:
  replicas: 2
  resources:
    requests:
      cpu: "500m"
      memory: "1Gi"
    limits:
      cpu: "1"
      memory: "2Gi"

sandbox:
  replicas: 2
  resources:
    requests:
      cpu: "500m"
      memory: "512Mi"
    limits:
      cpu: "1"
      memory: "1Gi"

1.3 レプリカ数の設計指針

ポイント: Alibaba Cloud ACK のベストプラクティス記事でも、本番環境では API / Worker / Web / Sandbox の多レプリカ配置が明示的に推奨されている。

2. 永続化（Persistence）の違い

2.1 検証環境

検証環境では emptyDir や Node ローカルストレージでも問題ない。目的は機能検証であり、データの耐久性は求めない。

# 検証環境 -- 永続化を最小限に
persistence:
  enabled: false

2.2 本番環境

本番では以下をすべて外部の永続化ストレージに接続する。

# 本番環境 -- 外部依存の明示
externalPostgres:
  enabled: true
  host: "dify-prod-pg.ap-northeast-1.rds.amazonaws.com"
  port: 5432
  username: "dify"
  database: "dify_production"
  existingSecret: "dify-pg-credentials"
  existingSecretPasswordKey: "password"

externalRedis:
  enabled: true
  host: "dify-prod-redis.xxxxx.apne1.cache.amazonaws.com"
  port: 6379
  existingSecret: "dify-redis-credentials"
  existingSecretPasswordKey: "password"

externalS3:
  enabled: true
  bucket: "dify-prod-storage"
  region: "ap-northeast-1"
  existingSecret: "dify-s3-credentials"

2.3 永続化チェックリスト

• PostgreSQL: RDS / Cloud SQL 等のマネージド DB を利用し、自動バックアップを有効化
• Redis: ElastiCache / Memorystore 等のマネージドサービスを利用
• Vector DB (Qdrant): 永続ボリューム (PVC) または外部クラスタを利用
• オブジェクトストレージ: S3 / GCS / Azure Blob のバージョニングを有効化
• values.yaml 自体を Git リポジトリで管理

3. ログレベルとオブザーバビリティ

3.1 検証環境のログ設定

検証環境では DEBUG レベルを有効にし、問題の早期発見と挙動確認を優先する。

# 検証環境
env:
  LOG_LEVEL: "DEBUG"

3.2 本番環境のログ設定

本番で DEBUG を常時有効にすると、ログ量が爆発してストレージコストとノイズが増大する。通常は WARNING 以上とし、必要に応じて一時的に INFO へ下げる運用とする。

# 本番環境
env:
  LOG_LEVEL: "WARNING"

3.3 本番で収集すべきログカテゴリ

3.4 オブザーバビリティスタックの推奨構成

graph LR
    A[Dify Pods] -->|stdout/stderr| B[Fluentd / Fluent Bit]
    B --> C[Elasticsearch / OpenSearch]
    C --> D[Kibana / Grafana]
    A -->|metrics| E[Prometheus]
    E --> D
    A -->|traces| F[Jaeger / Tempo]
    F --> D

本番環境では最低限 メトリクス (Prometheus) と ログ集約 (Fluentd + Elasticsearch) を導入する。Workflow の実行遅延やエラー率を可視化するダッシュボードを作成しておくと、障害の初動対応が大幅に改善される。

4. セキュリティ強化

4.1 シークレット管理

検証環境ではデフォルトの Secret 値をそのまま使いがちだが、本番では絶対に変更する。

# 本番環境 -- 必ず変更すべき Secret
api:
  secretKey: ""  # 外部 Secret Manager から注入
  innerApiKey: ""  # 同上

# Kubernetes Secret で管理する例
# kubectl create secret generic dify-secrets \
#   --from-literal=SECRET_KEY=$(openssl rand -hex 32) \
#   --from-literal=INNER_API_KEY=$(openssl rand -hex 32)

4.2 ネットワークポリシー

Sandbox コンテナはユーザーが投入するコードを実行するため、本番では NetworkPolicy で外部通信を厳密に制限する。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: sandbox-restrict
spec:
  podSelector:
    matchLabels:
      app: dify-sandbox
  policyTypes:
    - Egress
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: dify-api
      ports:
        - port: 5001
    # 外部インターネットへの通信はブロック

4.3 Ingress TLS

ingress:
  enabled: true
  className: "nginx"
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
  tls:
    - secretName: dify-tls
      hosts:
        - console.dify.example.co.jp
        - api.dify.example.co.jp
  hosts:
    - host: console.dify.example.co.jp
      paths:
        - path: /
          pathType: Prefix

4.4 セキュリティチェックリスト

5. バックアップ戦略

5.1 検証環境

検証環境ではバックアップ頻度は低くてよい。環境の再構築が容易であることを重視する。

5.2 本番環境のバックアップ設計

5.3 復旧テストの実施

バックアップは取得するだけでは不十分である。四半期に 1 回以上、以下の復旧テストを実施することを推奨する。

1. PostgreSQL のスナップショットから新規インスタンスを復元し、Dify が正常起動するか確認
2. オブジェクトストレージの特定バージョンへのロールバックを検証
3. Velero によるクラスタ全体の復元手順を確認
4. 復旧時間（RTO）と復旧ポイント（RPO）が SLA 要件を満たしているか検証

6. 環境分離のベストプラクティス

6.1 推奨構成

graph TB
    subgraph "本番クラスタ"
        A[namespace: dify-production]
    end
    subgraph "ステージングクラスタ"
        B[namespace: dify-staging]
    end
    subgraph "検証クラスタ"
        C[namespace: dify-testing]
    end
    D[GitOps リポジトリ] --> A
    D --> B
    D --> C

6.2 values.yaml の環境別管理

helm-values/
  base/
    values.yaml          # 共通パラメータ
  overlays/
    testing/
      values.yaml        # 検証固有の上書き
    staging/
      values.yaml        # ステージング固有の上書き
    production/
      values.yaml        # 本番固有の上書き

各環境の values.yaml は Kustomize 風にベースを継承し、環境固有の差分のみを上書きする。これにより、検証と本番の構成ドリフトを防止できる。

6.3 環境ごとの License 管理

Dify Enterprise の License は Kubernetes namespace に紐づくため、環境ごとに個別の License が必要となる。License の台帳管理については「04-License-管理実務」の記事を参照のこと。

7. まとめ – 本番移行チェックリスト

本番移行前に以下を確認する。

• リソース定義（CPU / Memory の requests / limits）が全コンポーネントに設定済み
• レプリカ数が可用性要件を満たしている（API / Worker は 3 以上）
• PostgreSQL / Redis / オブジェクトストレージが外部マネージドサービスに接続済み
• Secret がすべてランダム生成値に置き換え済み
• TLS 終端が設定済み
• Sandbox の NetworkPolicy が適用済み
• ログレベルが WARNING 以上に設定済み
• ログ集約基盤（Fluentd + Elasticsearch 等）が稼働中
• バックアップが自動化され、復旧テスト済み
• values.yaml が Git 管理下にある
• License が本番 namespace で有効化済み
• ステージング環境で本番相当の負荷テストを実施済み

検証環境は「動くか確認する場所」、本番環境は「サービスを約束する場所」である。両者は同じデプロイ方法論を共有すべきだが、リスクの前提条件は根本的に異なる。この違いを構成として明示的に反映することが、安定した Dify Enterprise 運用の第一歩となる。

Helm Chart values.yaml 重要パラメータ完全ガイド – 必須変更・環境別調整・デフォルト維持の判断基準

Dify Enterprise を Kubernetes に展開する際、values.yaml はデプロイの全体像を決定する最も重要なファイルである。公式のインストールコマンド helm upgrade -i dify -f values.yaml dify/dify が示すとおり、本番環境の構成差異はすべてこのファイルに集約される。

パラメータの数は多いが、すべてを理解する必要はない。重要なのは「必ず変更すべきパラメータ」「環境ごとに調整するパラメータ」「デフォルトのままでよいパラメータ」の 3 層に分類し、優先順位を付けて管理することである。

なお、公式は values の複雑さに対応するため dify-ee-helm-chart-values-generator を提供しており、初期構成の生成に活用できる。

1. values.yaml の全体構造

helm show values dify/dify で出力される主要セクションは以下のとおりである。

values.yaml
├── global              # グローバル設定（イメージレジストリ、プルシークレット等）
├── api                 # API サーバー設定
├── worker              # Worker サーバー設定
├── web                 # Web フロントエンド設定
├── sandbox             # コード実行 Sandbox 設定
├── enterprise          # Enterprise 固有設定（License 等）
├── ingress             # Ingress / ドメイン設定
├── persistence         # 永続化設定
├── externalPostgres    # 外部 PostgreSQL 接続
├── externalRedis       # 外部 Redis 接続
├── externalS3          # 外部オブジェクトストレージ接続
├── postgresql          # 内蔵 PostgreSQL（検証用）
├── redis               # 内蔵 Redis（検証用）
└── pluginDaemon        # プラグイン Daemon 設定

2. 必ず変更すべきパラメータ（Must Change）

以下のパラメータはデフォルト値のまま本番運用してはならない。

2.1 ドメインと Ingress

ingress:
  enabled: true
  className: "nginx"  # 環境に応じて alb, traefik 等
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
    nginx.ingress.kubernetes.io/proxy-body-size: "50m"
  tls:
    - secretName: dify-tls-cert
      hosts:
        - console.dify.example.co.jp
        - api.dify.example.co.jp
        - app.dify.example.co.jp
        - upload.dify.example.co.jp
        - enterprise.dify.example.co.jp
  hosts:
    console:
      host: console.dify.example.co.jp
    api:
      host: api.dify.example.co.jp
    app:
      host: app.dify.example.co.jp
    upload:
      host: upload.dify.example.co.jp
    enterprise:
      host: enterprise.dify.example.co.jp

注意: Dify Enterprise は console / api / app / upload / enterprise / trigger と複数のエンドポイントを持つ。DNS とワイルドカード証明書の設計を事前に行うこと。

2.2 Secret / 内部通信キー

api:
  secretKey: ""       # 必ず強ランダム値に変更
  innerApiKey: ""     # 必ず強ランダム値に変更

生成例:

# 32 バイトの hex 文字列を生成
openssl rand -hex 32

本番では existingSecret を使い、values.yaml に平文で書かない構成を推奨する。

api:
  existingSecret: "dify-api-secrets"
  existingSecretKeys:
    secretKey: "SECRET_KEY"
    innerApiKey: "INNER_API_KEY"

2.3 Enterprise License モード

enterprise:
  enabled: true
  licenseMode: "online"   # オフライン環境では "offline" に変更

オフラインモードの場合、License ファイルの配置方法は公式の License Activation ドキュメントを参照する。

2.4 外部データベース接続

本番では内蔵 PostgreSQL を無効化し、外部マネージド DB を使う。

# 内蔵 PostgreSQL を無効化
postgresql:
  enabled: false

# 外部 PostgreSQL を有効化
externalPostgres:
  enabled: true
  host: "dify-prod.cluster-xxxx.ap-northeast-1.rds.amazonaws.com"
  port: 5432
  username: "dify_app"
  database: "dify_production"
  existingSecret: "dify-postgres-secret"
  existingSecretPasswordKey: "password"
  sslMode: "require"    # 本番では SSL 必須

2.5 外部 Redis 接続

redis:
  enabled: false

externalRedis:
  enabled: true
  host: "dify-prod.xxxxx.apne1.cache.amazonaws.com"
  port: 6379
  existingSecret: "dify-redis-secret"
  existingSecretPasswordKey: "password"
  useSsl: true

2.6 外部オブジェクトストレージ

externalS3:
  enabled: true
  bucket: "dify-enterprise-prod"
  region: "ap-northeast-1"
  endpoint: ""  # AWS S3 の場合は空、MinIO の場合は URL を指定
  existingSecret: "dify-s3-secret"
  existingSecretKeys:
    accessKey: "AWS_ACCESS_KEY_ID"
    secretKey: "AWS_SECRET_ACCESS_KEY"

3. 環境ごとに調整するパラメータ（Per-Environment）

3.1 レプリカ数

3.2 リソース制限

# 本番向け -- 各コンポーネントに明示的に定義
api:
  resources:
    requests:
      cpu: "2"
      memory: "4Gi"
    limits:
      cpu: "4"
      memory: "8Gi"

worker:
  resources:
    requests:
      cpu: "2"
      memory: "4Gi"
    limits:
      cpu: "4"
      memory: "8Gi"

web:
  resources:
    requests:
      cpu: "500m"
      memory: "512Mi"
    limits:
      cpu: "1"
      memory: "1Gi"

sandbox:
  resources:
    requests:
      cpu: "500m"
      memory: "512Mi"
    limits:
      cpu: "1"
      memory: "1Gi"

3.3 ログレベル

# 検証環境
api:
  env:
    LOG_LEVEL: "DEBUG"

# 本番環境
api:
  env:
    LOG_LEVEL: "WARNING"

3.4 SMTP 設定（メール通知）

api:
  env:
    MAIL_TYPE: "smtp"
    SMTP_SERVER: "smtp.example.co.jp"
    SMTP_PORT: "587"
    SMTP_USE_TLS: "true"
    SMTP_USERNAME: "dify-noreply@example.co.jp"
    MAIL_DEFAULT_SEND_FROM: "Dify Enterprise <dify-noreply@example.co.jp>"
  existingSecret: "dify-smtp-secret"

3.5 SSO / SAML 連携

Enterprise 版では SAML / OIDC による SSO が利用可能である。Azure AD や Okta との連携を行う場合、以下を設定する。

enterprise:
  sso:
    enabled: true
    protocol: "saml"
    # 具体的な IdP 設定は管理コンソールから行う

3.6 Sandbox ネットワーク制限

sandbox:
  env:
    ALLOWED_SYSCALLS: ""  # 許可するシステムコールを限定
  networkPolicy:
    enabled: true
    # 許可する通信先を明示的に指定

4. デフォルトのまま維持してよいパラメータ（Keep Default）

以下は特段の要件がない限り変更不要である。

5. パラメータ分類サマリ表

6. values.yaml のバージョン管理

6.1 Git リポジトリでの管理

values.yaml はインフラのコードそのものであり、Git で管理する。

infra-repo/
├── helm/
│   └── dify/
│       ├── base-values.yaml        # 全環境共通
│       ├── testing-values.yaml     # 検証環境上書き
│       ├── staging-values.yaml     # ステージング上書き
│       └── production-values.yaml  # 本番環境上書き
├── secrets/
│   └── README.md                   # Secret の管理方針を記載
└── scripts/
    └── deploy.sh                   # デプロイスクリプト

6.2 デプロイコマンド例

# 本番デプロイ（base + 環境別の values を重ねて適用）
helm upgrade -i dify dify/dify \
  -n dify-production \
  -f helm/dify/base-values.yaml \
  -f helm/dify/production-values.yaml \
  --wait --timeout 10m

デプロイ前に helm diff プラグインで変更内容を確認する習慣を付けること。

7. トラブルシューティング

よくある values 起因の問題

9. まとめ

Helm Chart の values.yaml は Dify Enterprise デプロイの「設計書」である。すべてのパラメータを読み解く必要はないが、以下の優先順位で対応することを推奨する。

1. 初日に対応: ドメイン・Secret・外部 DB/Redis/S3・License モード
2. 環境構築時に対応: レプリカ数・リソース制限・ログレベル・SMTP・SSO
3. 運用開始後に対応: 必要に応じて実験的機能やプラグイン設定を追加

values.yaml を Git で管理し、環境ごとに分離し、デプロイ前に helm diff で差分を確認する。この 3 つの習慣を身につけることが、安定した Dify Enterprise 運用の基盤となる。

マルチテナント権限設計 – Workspace 分離・ロール階層・API キースコーピングの実践ガイド

エンタープライズにおけるマルチテナント設計とは、単に「部署ごとにアカウントを分ける」ことではない。データをどう隔離するか、モデルをどう共有するか、権限をどう継承するか – この 3 つの問いに答えることが本質である。

Dify では Workspace（ワークスペース）、Team Members（チームメンバー）、Model Providers（モデルプロバイダー）が異なる管理レイヤーとして設計されている。Enterprise 版ではこれらに加え、組織管理・SSO 連携・監査ログといったガバナンス機能が追加される。本記事では、日本企業が Dify Enterprise を社内展開する際の権限設計パターンを実務レベルで解説する。

1. Dify の権限モデル概要

1.1 基本概念の整理

graph TB
    subgraph "プラットフォームレベル"
        A[System Admin]
        B[Model Providers]
        C[License 管理]
    end
    subgraph "Workspace レベル"
        D[Workspace A<br/>営業部]
        E[Workspace B<br/>カスタマーサポート部]
        F[Workspace C<br/>法務部]
    end
    subgraph "Workspace 内"
        G[Apps]
        H[Knowledge Base]
        I[Tools]
        J[Members & Roles]
    end
    A --> D
    A --> E
    A --> F
    B -.->|共有可能| D
    B -.->|共有可能| E
    B -.->|共有可能| F
    D --> G
    D --> H
    D --> I
    D --> J

1.2 ロール階層

Dify には以下のロール階層が存在する。

1.3 隔離の境界

2. テナント設計パターン

2.1 パターン A: 強隔離モデル（部署完全分離）

graph LR
    subgraph "法務部 Workspace"
        A1[契約書レビューApp]
        A2[法務ナレッジベース]
        A3[専用 Model Provider]
    end
    subgraph "人事部 Workspace"
        B1[採用FAQ App]
        B2[人事ナレッジベース]
        B3[専用 Model Provider]
    end
    A1 -.- A2
    B1 -.- B2

適用場面: 法務、人事、財務、経営企画など、機密性の高いデータを扱う部署。

特徴:

• ナレッジベースは完全に分離
• Model Provider も部署ごとに個別設定（API キーを分離し、利用量を個別管理）
• メンバーの兼任は原則禁止または最小限
• 監査ログの定期レビューを実施

values.yaml との関連設定:

# Workspace 間のデータ分離は Dify のアプリケーション層で実現
# インフラレベルでは以下を確認
enterprise:
  enabled: true
  # 監査ログの有効化
  auditLog:
    enabled: true
    retention: "365d"

2.2 パターン B: 共有基盤 + データ分離モデル

graph TB
    subgraph "プラットフォーム共有層"
        M[共有 Model Provider<br/>GPT-4o / Claude]
        P[共有プラグイン]
    end
    subgraph "営業部 Workspace"
        C1[商談支援 App]
        C2[営業ナレッジベース]
    end
    subgraph "CS部 Workspace"
        D1[問合せ対応 App]
        D2[CS ナレッジベース]
    end
    M -->|利用| C1
    M -->|利用| D1
    C1 -.- C2
    D1 -.- D2

適用場面: 営業、マーケティング、カスタマーサポートなど、基盤モデルの共有が効率的な部署。

特徴:

• Model Provider はプラットフォームレベルで一元管理（コスト最適化）
• ナレッジベースとアプリケーションは Workspace で分離
• メンバーの複数 Workspace 所属を許可
• ツール（Web 検索、計算機等）は共有利用

2.3 パターン C: プロジェクト横断モデル

graph TB
    subgraph "DX推進PJ Workspace"
        E1[業務分析 App]
        E2[PJナレッジベース]
    end
    subgraph "営業部 Workspace"
        F1[営業 App]
        F2[営業ナレッジベース]
    end
    U1[ユーザーA<br/>DX推進 + 営業] --> E1
    U1 --> F1
    U2[ユーザーB<br/>DX推進のみ] --> E1

適用場面: 部署横断プロジェクトがある企業。同一ユーザーが複数の Workspace にそれぞれ異なるロールで所属する。

3. 権限設計のベストプラクティス

3.1 最小権限の原則

System Admin は最小人数（2-3 名）に限定する
  └── 通常業務では Workspace Admin 以下のロールを使用
      └── アプリ利用のみのユーザーは Member ロールで十分

具体的な推奨:

3.2 Model Provider の管理方針

Model Provider の設定はコスト管理とセキュリティの両面で重要である。

推奨アプローチ:
1. System Admin がプラットフォームレベルで利用可能なモデルを設定
2. Workspace ごとに利用可能なモデルを制限（必要に応じて）
3. 各モデルの API キーは Secret Manager で一元管理
4. 月次でモデル利用量をレビュー

Model Provider 設定例（プラットフォームレベル）:

3.3 ナレッジベースのアクセス制御

4. API キーのスコーピング

4.1 API キーの発行単位

Dify の API キーはアプリケーション単位で発行される。外部システムと連携する際は、以下の原則を守る。

1 つの API キー = 1 つのアプリケーション = 1 つのユースケース

アンチパターン: 1 つの API キーを複数のシステムで使い回す。

4.2 API キー管理のベストプラクティス

# 外部システムからの Dify API 呼び出し例
# 各システムごとに個別の API キーを発行する

# CRM システム → 商談要約 App
# API Key: app-xxxx1111 (CRM 専用)

# チャットボット → FAQ 回答 App
# API Key: app-xxxx2222 (チャットボット専用)

# 社内ポータル → ドキュメント検索 App
# API Key: app-xxxx3333 (ポータル専用)

4.3 API キーのライフサイクル管理

5. SSO 連携による認証統合

5.1 推奨構成

Enterprise 版では SAML 2.0 / OIDC による SSO が利用可能である。

sequenceDiagram
    participant User as ユーザー
    participant Dify as Dify Enterprise
    participant IdP as IdP (Azure AD / Okta)
    
    User->>Dify: ログイン要求
    Dify->>IdP: SAML AuthnRequest
    IdP->>User: 認証画面
    User->>IdP: 認証情報入力
    IdP->>Dify: SAML Response (属性付き)
    Dify->>Dify: Workspace / ロール自動割り当て
    Dify->>User: ダッシュボード表示

5.2 IdP 属性マッピング

5.3 SSO 導入時の注意点

• 初回ログイン時に Workspace への自動割り当てルールを事前に定義しておく
• IdP 側のグループ変更が Dify のロールに反映されるタイミングを確認する
• 緊急時用のローカル管理者アカウントを 1 つ維持する（IdP 障害時の対応）
• SSO セッションタイムアウトと Dify セッションタイムアウトを整合させる

6. 監査とコンプライアンス

6.1 監査ログで記録すべきイベント

6.2 定期レビューの実施

月次レビュー:
  - 各 Workspace のメンバー一覧と最終ログイン日を確認
  - 90 日以上ログインのないアカウントを無効化
  - API キーの棚卸し（不要なキーの失効）
  - Model 利用量のコスト確認

四半期レビュー:
  - ロール割り当ての妥当性確認
  - Workspace 構成の見直し
  - 監査ログの異常パターン確認
  - アクセス権限のレビュー（J-SOX 対応）

7. 典型的な組織構成例

7.1 中規模企業（500 名、5 部署）の設計例

System Admin は情報システム部の 2 名に限定し、各 Workspace の Owner は部署長またはAI推進担当が担う構成とする。

8. まとめ

マルチテナント権限設計の核心は「共有効率」と「データ境界」のバランスである。以下の 5 つの原則を指針とする。

1. Workspace = テナント境界: 部署またはプロジェクト単位で Workspace を作成し、ナレッジベースとアプリを隔離する
2. Model Provider は共有可能: コスト効率のため、基盤モデルはプラットフォームレベルで管理し、必要に応じて Workspace 単位で制限する
3. 最小権限の原則: System Admin は最小人数に限定し、一般ユーザーには必要最低限のロールを付与する
4. API キーはユースケース単位: 1 キー = 1 アプリ = 1 連携先の原則を徹底する
5. 監査と定期レビュー: 監査ログを有効化し、月次でメンバー・キー・コストの棚卸しを実施する

権限設計は一度決めたら終わりではなく、組織の変化に応じて継続的に見直す運用プロセスが不可欠である。

License 管理実務 – アクティベーション・更新・監視・コンプライアンスの運用ガイド

Dify Enterprise の License 管理は、導入時に一度アクティベーションすれば終わりではない。有効期限の監視、更新手続き、複数インスタンスへの配分、namespace 変更時の対応 – これらは継続的な運用タスクとして SOP（標準作業手順）に組み込む必要がある。

公式ドキュメントから確認できる重要な事実として、License は Kubernetes cluster の namespace に紐づく。つまり License 管理はインフラ運用の一部であり、単なる管理画面のクリック操作ではない。

1. License の基本構造

1.1 License とデプロイ環境の関係

graph TB
    subgraph "Dify Enterprise License"
        L[License ID: DIFY-ENT-xxxx]
    end
    subgraph "Kubernetes Cluster"
        subgraph "namespace: dify-production"
            A[dify-enterprise Pod]
            B[dify-api Pod]
            C[dify-worker Pod]
        end
    end
    L -->|bound to namespace| A
    A -->|License 検証| B
    A -->|License 検証| C

1.2 主要な制約事項

1.3 オンラインモード vs オフラインモード

2. アクティベーション手順

2.1 オンラインアクティベーション

# 1. values.yaml で License モードを確認
enterprise:
  enabled: true
  licenseMode: "online"

# 2. Helm デプロイ（または既存環境の場合は upgrade）
helm upgrade -i dify dify/dify \
  -n dify-production \
  -f values.yaml \
  --wait

# 3. Enterprise 管理コンソールにアクセス
#    https://enterprise.dify.example.co.jp
#    → License 画面で License キーを入力

# 4. アクティベーション成功を確認
kubectl get pods -n dify-production -l app=dify-enterprise
# STATUS が Running であること

2.2 オフラインアクティベーション

# 1. values.yaml で License モードをオフラインに変更
enterprise:
  enabled: true
  licenseMode: "offline"

# 2. Helm デプロイ
helm upgrade -i dify dify/dify \
  -n dify-production \
  -f values.yaml \
  --wait

# 3. License ファイルの配置
#    公式ドキュメントの手順に従い、License ファイルを
#    所定のパスに配置する

# 4. Enterprise Pod を再起動
kubectl rollout restart deployment/dify-enterprise -n dify-production

# 5. 起動確認
kubectl rollout status deployment/dify-enterprise -n dify-production

2.3 アクティベーション後の確認チェックリスト

• Enterprise 管理コンソールにログインできる
• License 情報（有効期限・プラン内容）が正しく表示される
• API / Worker / Web の各 Pod が正常に Running 状態
• アプリケーションの作成・実行が正常に動作する
• License 情報をスクリーンショットまたはテキストで台帳に記録する

3. License 台帳管理

3.1 管理すべき 3 つの台帳

エンタープライズ運用では、以下の 3 つの台帳を整備する。

台帳 1: License 基本情報

台帳 2: インスタンス情報

台帳 3: 更新・操作履歴

4. 有効期限の監視

4.1 多段階アラートの設計

License の期限切れは Dify Enterprise の全機能停止に直結するため、十分な猶予を持って対応する。

gantt
    title License 有効期限アラートスケジュール
    dateFormat  YYYY-MM-DD
    section アラート
    90日前通知 (更新交渉開始)   :milestone, m1, 2026-10-15, 0d
    60日前通知 (契約締結目標)   :milestone, m2, 2026-11-14, 0d
    30日前通知 (技術準備完了)   :milestone, m3, 2026-12-15, 0d
    14日前通知 (最終確認)       :milestone, m4, 2026-12-31, 0d
    7日前通知 (緊急対応)        :milestone, m5, 2027-01-07, 0d
    期限満了                    :milestone, m6, 2027-01-14, 0d

4.2 自動監視の実装方針

自動監視は以下の方法で実装できる。

• シェルスクリプト + cron: Enterprise Pod から License 有効期限を取得し、残日数に応じて Slack / メールで通知するスクリプトを日次実行
• Prometheus + AlertManager: License 残日数をメトリクスとして公開し、PrometheusRule でアラートを定義

4.3 Prometheus によるメトリクス監視

# PrometheusRule 例
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: dify-license-alerts
  namespace: monitoring
spec:
  groups:
    - name: dify-license
      rules:
        - alert: DifyLicenseExpiringSoon
          expr: dify_license_days_remaining < 30
          for: 1h
          labels:
            severity: warning
          annotations:
            summary: "Dify License の有効期限が 30 日以内です"
            description: "残り {{ $value }} 日です。更新手続きを確認してください。"
        - alert: DifyLicenseExpiryCritical
          expr: dify_license_days_remaining < 7
          for: 1h
          labels:
            severity: critical
          annotations:
            summary: "Dify License の有効期限が 7 日以内です"
            description: "残り {{ $value }} 日です。至急更新してください。"

5. License 更新手順

5.1 更新フロー

sequenceDiagram
    participant PM as 購買担当
    participant Dify as Dify Sales
    participant IT as 情報システム部
    participant K8s as Kubernetes Cluster
    
    PM->>Dify: 更新見積もり依頼 (90日前)
    Dify->>PM: 見積もり提出
    PM->>PM: 社内承認プロセス
    PM->>Dify: 発注 (60日前)
    Dify->>IT: 新 License キー送付
    IT->>IT: ステージング環境で検証 (30日前)
    IT->>K8s: 本番 License 更新 (14日前)
    K8s->>K8s: enterprise Pod 再起動
    IT->>IT: 動作確認・台帳更新

5.2 更新の実施手順（共通）

# 1. ステージング環境で事前検証（新 License キーまたはファイルを適用）

# 2. 本番環境で License 更新
#    オンライン: 管理コンソールから新しい License キーを入力
#    オフライン: 新しい License ファイルを配置

# 3. enterprise Pod を再起動（更新反映のため必須）
kubectl rollout restart deployment/dify-enterprise -n dify-production
kubectl rollout status deployment/dify-enterprise -n dify-production --timeout=300s

# 4. 動作確認
curl -s https://enterprise.dify.example.co.jp/api/health | jq .
# 管理コンソールで新しい有効期限が反映されていることを確認

6. 複数インスタンスの License 配分

6.1 環境別の配分戦略

企業が複数の Dify Enterprise インスタンスを運用する場合、License の配分方針を明確にする。

6.2 namespace 変更時の注意事項

License は namespace に紐づくため、以下の場合は再アクティベーションが必要となる。

• namespace 名を変更した場合
• 別のクラスタに移行した場合
• DR 用クラスタにフェイルオーバーした場合

# namespace 変更時の対応手順
# 1. 新 namespace にデプロイ
helm upgrade -i dify dify/dify \
  -n dify-production-v2 \
  -f values.yaml \
  --wait

# 2. 再アクティベーション
#    管理コンソールから License キーを再入力
#    オフラインの場合は License ファイルを再配置

# 3. 旧 namespace のクリーンアップ
kubectl delete namespace dify-production-old

6.3 DR（災害復旧）環境での License

DR 環境では、DR 用 License の要否確認、フェイルオーバー時の再アクティベーション手順の文書化、オフライン環境への License ファイル事前配置を行っておく。復旧訓練時に License アクティベーションも含めて検証すること。

7. コンプライアンスと内部統制

7.1 License 関連の統制ポイント

7.2 監査対応

内部監査や外部監査（J-SOX 等）に備え、License 台帳・更新承認フロー文書・作業記録・有効期限監視ログ・是正手順を整備しておく。

8. よくある問題と対処

9. まとめ

License 管理を確実に運用するための 5 つの原則を以下にまとめる。

1. 台帳を整備する: License 基本情報・インスタンス情報・操作履歴の 3 つの台帳を作成し、最新状態を維持する
2. 多段階アラートを設定する: 90 / 60 / 30 / 14 / 7 日前の 5 段階で通知し、余裕を持って更新手続きを進める
3. 更新手順を SOP 化する: ステージング検証 → 本番更新 → 動作確認 → 台帳更新のフローを標準化する
4. namespace との紐づきを意識する: 移行・DR・namespace 変更時には再アクティベーションが必要であることを常に念頭に置く
5. コンプライアンスを担保する: 棚卸し・利用状況レビュー・証跡保管を定期的に実施し、監査に備える

License は Dify Enterprise の「動作の前提条件」である。ここが途切れればすべてのサービスが停止する。だからこそ、License 管理をインフラ運用 SOP の一級項目として位置づけることが重要である。

バージョンアップグレード注意事項 – マイグレーション・互換性検証・ロールバック戦略の実践ガイド

Dify Enterprise のアップグレードは「イメージを差し替えて再起動する」だけの作業ではない。データベースマイグレーション、設定ファイルの変更、依存コンポーネントのバージョン整合性、API の互換性 – これらが同時に変化するため、事前準備なしのアップグレードは本番障害に直結する。

公式ドキュメントでも “upgrade steps may vary between releases” と明記されており、バージョンごとに異なる手順の確認が必須事項として位置づけられている。本記事では、日本企業の運用チームが安全にアップグレードを実施するための包括的なガイドラインを提供する。

1. アップグレードの全体像

1.1 アップグレードで変化する 3 つの要素

graph LR
    A[バージョンアップグレード] --> B[イメージ更新]
    A --> C[設定変更]
    A --> D[データマイグレーション]
    B --> B1[API / Worker / Web / Sandbox / Enterprise]
    C --> C1[values.yaml の新規・廃止パラメータ]
    C --> C2[.env の変更点]
    D --> D1[PostgreSQL スキーマ変更]
    D --> D2[Vector DB インデックス再構築]
    D --> D3[オブジェクトストレージの構造変更]

1.2 アップグレードの影響範囲

2. アップグレード前の準備（Pre-Upgrade）

2.1 Release Note の精読

アップグレードの最初のステップは、対象バージョンの Release Note を隅々まで読むことである。

確認すべきポイント:

• Breaking Changes: 既存機能の非互換変更
• Deprecations: 廃止予定の機能やパラメータ
• Migration Notes: データベースマイグレーションの特記事項
• New Configuration: 追加された設定項目
• Known Issues: 既知の不具合

# GitHub の Release ページを確認
# https://github.com/langgenius/dify/releases

# Enterprise 固有の変更は Enterprise Docs を確認
# https://enterprise-docs.dify.ai/en-us/deployment/

2.2 設定ファイルの差分確認

# Docker Compose の場合: .env.example の差分を確認
diff .env.example .env.example.new

# Helm の場合: values.yaml の差分を確認
helm show values dify/dify --version <新バージョン> > values-new.yaml
diff values.yaml values-new.yaml

特に注意すべき values.yaml の変更パターン: