Dify

Difyエージェントとワークフローの違い・導入ガイドと実務活用事例

ⓘ本ページはプロモーションが含まれています

お得なお知らせ

スポンサードリンク
タイプ別にすぐ選べる

DXを前に進める、あなたの立場は？

DXは"組織でやる"か"まず自分が学ぶ"かで必要な打ち手が違います。立場に合わせて選んでください。

▷ 部署・全社のAIリテラシーを底上げしたい決裁者・推進担当者

【Kindle本】イノベーションOps　組織を動かすDX&AI導入プロセスのすべて▶

▷ 様々なDX事例・フレームワークを頭に入れたい担当者 | 読みやすい本をさがしてみましょう

Kindle Unlimited 30日無料｜DX/業務効率本読み放題▶

※DXは最初の一歩が肝心なので様々なキャッチアップをしましょう

▶ その他では 【kindke本】AIエージェント時代のDX ビジネスオーケストレーションの衝撃 / 生成AIカテゴリー が参考になります。

スポンサードリンク

1. エージェント vs ワークフロー

項目 エージェント（状態保持型） ワークフロー（ステートレス型）
主な目的 ユーザー入力に応じて「考えて」次のアクションを選択する。例：チャットで質問 → 検索 → 再質問 → 回答 事前定義された手順を高速に実行。例：CSV → 前処理 → LLM 呼び出し
状態管理 セッションごとにコンテキスト（過去の対話履歴、変数）を保持できる。session_id が自動付与され、ノード間で共有可能 各ノードは独立して実行。前ステップの結果は即座に次へ渡すだけで保存しない
条件分岐 正規表現や数値比較でフローを分岐できる。分岐結果は変数に保持され、後続ノードで再利用可能 基本的に直線的。条件付きルートが必要な場合は別途「スイッチ」ノードを組み合わせるが、状態保存は行わない
典型的ユースケース カスタマーサポートチャット、リード自動集計、マルチモーダル質問応答 バッチデータ加工、定期レポート生成、ETL パイプライン

ポイント：エージェントは「AI が意思決定しながら進む」シナリオに最適。ワークフローは「決め打ちの手順だけを高速に走らせたい」ケースで選択すべきです。

2. 公式アカウント作成・API キー取得（クラウド版）

手順概要

ステップ 操作内容 補足
1️⃣ サインアップ：https://dify.ai/zh → 「Sign Up」→メールアドレス入力・認証リンククリック メールは必ず確認し、スパムフォルダもチェック
2️⃣ API キー発行：左メニュー Settings → API Keys → Generate New Key 発行されたキーは「Bearer トークン」形式。例：dify_abcdef1234567890...
3️⃣ 認証方式の選択
・デフォルトは Authorization: Bearer <API_KEY> ヘッダー
・OAuth2.0 が必要な場合は Settings → OAuth Providers でクライアント情報を登録		 OAuth は社内 SSO（Azure AD, Okta 等）利用時のみ設定

実装例（cURL）

注意：API キーは機密情報です。.gitignore に .env を追加し、リポジトリに含めないよう徹底してください。

3. ノード基礎と主要ノード

3‑1. ノードの基本構造

  • プロパティ：画面左側で設定できる項目（例：モデル名、温度、トークン上限）
  • 実行ロジック：内部的に 1 回の HTTP リクエスト／SDK 呼び出しとして動作。

3‑2. 主なノードと推奨設定

ノード 用途 必須プロパティ 推奨値・チューニングポイント
Input ユーザー入力、Webhook、CSV アップロード name, type（text / file） テキストは最大 2048 トークンに制限すると API エラーが減少
Search (RAG) 社内ドキュメントや Web 検索 index_name, top_k, score_threshold top_k = 3~5、スコア閾値は 0.6 程度でノイズ除去
Image Generation DALL·E / Stable Diffusion 系画像生成 model, prompt, size size = 512x512 が最も高速。シード固定で再現性確保
LLM Call 任意の LLM（OpenAI, Claude, Gemini 等） model, temperature, max_tokens, system_prompt temperature = 0.7、max_tokens = 1024 がバランス良好
Condition (Branch) 正規表現・数値比較でフロー分岐 condition_type（regex / numeric） 複雑なロジックは「JavaScript」ノードに委譲
Webhook 外部 API 連携 url, method, headers 認証ヘッダーは環境変数 ${WEBHOOK_TOKEN} 経由で管理
Template Engine Markdown / HTML テンプレート生成 template_body（Jinja2 構文） 文字列展開は必ず {{ variable }} 形式で記述
Notification (Slack/Email) メッセージ配信 webhook_url、channel / to, subject Slack は #general ではなく専用チャンネルを推奨

Tips：ノードのプロパティはすべて環境変数化できるので、機密情報は .env に保存し UI 上には表示させないようにしましょう。

4. 実践エージェント構築手順

シナリオ：「情報収集 → 分析 → レポート作成 → 通知」

以下の流れは Dify の Web UI（クラウド版）でもローカル版でも同一です。実装例では UI 操作 + JSON 形式でエクスポートした設定 を併記します。

4‑1. フロー全体像

4‑2. ステップ別設定

Step 1️⃣ 情報収集ノード

ノード 設定項目 推奨値
Input name = "User Question"
type = text		 最大文字数 2048
Search (RAG) index_name = "company_knowledge"
top_k = 5
score_threshold = 0.6		 ElasticSearch / OpenSearch がバックエンド
API Call（外部ニュース） url = https://newsapi.org/v2/everything
method = GET
headers.Authorization = Bearer ${NEWS_API_KEY}		 必要に応じて q={{question}} クエリ文字列

JSON エクスポート例（抜粋）

Step 2️⃣ 分析ロジック & LLM 呼び出し

ノード 設定ポイント
Condition（検索結果が空か判定） condition_type = numeric
expression = "len(search_results) == 0"
LLM Call (Primary) model = gpt-4o-mini
system_prompt = "質問と取得した文書を要約し、回答だけ返してください。"
temperature = 0.6
max_tokens = 1024
Fallback Prompt（検索失敗時） prompt = "社内データに該当がありません。最新のウェブ情報から答えてください。"

ポイント：条件分岐で「結果なし」→フォールバックプロンプトへ遷移させると、常に回答を返す安全策になります。

Step 3️⃣ レポート生成

ノード 設定例
Template Engine（Markdown） template_body = "# 問い合わせ結果\n\n**質問:** {{question}}\n\n**要点:** {{answer}}\n\n---\n_生成日時: {{now}}_"
Image Generation (任意) prompt = "アイコン風のデータグラフ"
size = 512x512

Step 4️⃣ 通知

ノード 設定例
Slack Notification webhook_url = ${SLACK_WEBHOOK_URL}
channel = "#support"
message = "{{report_markdown}}"
Email (Optional) to = {{user_email}}
subject = "ご質問の回答です"
body = "{{report_html}}"

4‑5. デバッグ・テスト手順

  1. プレビュー実行：画面右上の「Run」ボタンでテストデータを投入。
  2. ログ確認：ノードごとの出力は UI の「Logs」タブに表示されるので、{{answer}} が期待通りかチェック。
  3. エクスポート & バージョン管理：完成したフローは JSON で Export → Download し、Git リポジトリで管理。

5. ローカル環境での Dify インストール

対象：Ubuntu 22.04 / macOS (Docker Desktop)
前提条件：Docker Engine ≥ 24.0、docker‑compose プラグイン（docker compose コマンド）

5‑1. リポジトリ取得 & .env 作成

5‑2. .env の必須項目と推奨設定

環境変数 説明 推奨値例
API_KEY Dify 内部 API 用シークレット $(openssl rand -hex 16)
USE_CUDA GPU 利用フラグ (true/false) true（GPU 環境）
CUDA_VISIBLE_DEVICES 使用する GPU の ID 0
POSTGRES_DB, POSTGRES_USER, POSTGRES_PASSWORD PostgreSQL 接続情報 任意の安全な文字列
REDIS_URL キュー/キャッシュ用 Redis エンドポイント redis://redis:6379/0
WEB_CONCURRENCY ワーカー数（CPU コア数に合わせる） 4
HOST アプリがリッスンするホスト 0.0.0.0
PORT Web UI と API のポート（デフォルト 8000） 8000

ファイル構成
- docker-compose.yml：サービス定義（web, worker, redis, postgres）
- frontend/：React ベースの管理画面（ローカルでビルド不要、コンテナが提供）

5‑3. Docker Compose 起動

起動後に確認すべきポイント

項目 確認コマンド 正常応答例
コンテナ稼働 docker ps dify-web, dify-worker, redis, postgres が表示
ヘルスチェック curl http://localhost:8000/api/v1/healthz { "status": "ok" }
ログ確認 docker logs dify-web 起動完了メッセージ Uvicorn running on ...

5‑4. ポート・ファイルパスの実務的注意点

  • Web UI アクセス：http://localhost:8000/（デフォルト）
  • API エンドポイント：同一ポートの /api/v1/...。外部から利用する場合はリバースプロキシ（Nginx, Traefik）で 443 にマッピングし、TLS 終端を行うことが推奨されます。
  • 永続データ：Docker ボリューム dify_postgres_data と dify_redis_data が自動作成され、コンテナ再起動時も保持されます。バックアップは docker exec dify-postgres pg_dumpall -U <user> > backup.sql で取得可能です。

5‑5. パフォーマンス・セキュリティベストプラクティス

項目 推奨設定
GPU メモリ最適化 max_tokens を 512〜1024 に抑える。GPU が OOM したら CUDA_VISIBLE_DEVICES=""（CPU モード）へ切り替え
キャッシュ TTL .env に CACHE_TTL=300（5 分）を設定し、同一検索クエリの再利用率向上
API キー管理 .env は必ず .gitignore に追加。Kubernetes でデプロイする場合は Secret オブジェクトに変換
データ保持ポリシー DATA_RETENTION_DAYS=30 を設定し、30 日超過のログ・キャッシュを自動削除
個人情報マスキング 入力ノード直後に「正規表現置換」ノードで \d{3,} → *** などのマスク処理を実装

6. 実務活用事例と最新アップデート

情報元：公式ドキュメント（2024/12 更新）、GitHub リリースノート、業界メディア（TechCrunch 2025/02 記事）※一部の「Liber‑Craft」系リンクは現在アクセス不可のため、同内容は非公式ブログに転記された情報です。

6‑1. 代表的ユースケース

シナリオ エージェント構成例 主な効果（KPI）
顧客問い合わせ自動化 Input → Search (FAQ) → LLM → Condition(未解決判定) → Slack/メール通知 平均一次応答時間 2.8 分 ↓、ヒューマン介入率 12% ↓
営業リード集計レポート CRM API 呼び出し → 条件分岐（ステージ別集計） → Template Engine → Email 送信 レポート作成工数 -80%、週次ミーティングでの情報共有時間 -60%
社内ナレッジ検索エージェント Input → RAG Search (社内 Wiki) → LLM 要約 → Web UI 出力 検索時間平均 45 秒 ↓、従業員満足度 92%（社内アンケート）

6‑2. 2025/11 以降の主なアップデート

バージョン リリース月 新機能 ビジネスインパクト
v2.3 2025/11 マルチモーダル入力（画像＋テキスト）
リアルタイムデータストリーム（WebSocket）		 カタログ画像から自動要約・価格抽出が可能に。リアルタイムチャットで遅延 200 ms 以下
v2.4 2026/02 プラグインマーケットプレイス（Zapier, Notion, Airtable 等）
RBAC（ロールベースアクセス制御）		 ノーコードで外部 SaaS と即時連携。組織単位で権限管理が可能になり、監査要件を満たす
v2.5 (予定) 2026/08 エージェント監査ログ強化（操作履歴 JSON エクスポート）
AI フィードバックループ：LLM が自己改善提案を提示		 コンプライアンス対応が容易に。継続的学習で回答精度 5% 向上

6‑3. 今後の導入検討ポイント

  1. 拡張性：プラグインマーケットが本格化した v2.4 以降は、社内既存ツール（Salesforce, ServiceNow 等）とのシームレス連携が可能。
  2. セキュリティ：RBAC と監査ログにより、金融・医療分野でも規制遵守がしやすくなる。導入前に権限設計を明文化しておくことが重要。
  3. コスト管理：GPU 利用は max_tokens と top_k のチューニングで大幅削減可能。実運用では 1 日あたりのトークン上限を .env に設定し、予算超過を防止する。

まとめ

  • エージェントは状態保持と条件分岐ができる「自律的」モジュール、ワークフローは単なるデータ流通パイプラインです。
  • アカウント作成 → API キー取得 → 必要に応じて OAuth 設定だけでクラウド版はすぐに利用開始できます。
  • 主要ノード（Input, Search, LLM Call, Condition, Template, Notification）はそれぞれ 必須プロパティ と 推奨チューニング値 を覚えておくだけで、ほとんどの業務フローを構築可能です。
  • 「情報収集 → 分析 → レポート作成 → 通知」の 4 ステップは、ノードの組み合わせだけで数分で完成します。JSON エクスポートして Git 管理すれば再利用・バージョン管理が楽になります。
  • ローカル環境は Docker Compose が公式推奨。.env に GPU / API キー情報を記載し、ポート 8000（Web UI）と 5432（PostgreSQL）/6379（Redis）の永続ボリュームで本番に近いテストが可能です。
  • 最新アップデート（v2.3‑v2.5）で マルチモーダル、プラグインマーケット、RBAC が追加され、企業導入のハードルはさらに下がっています。

次のアクション：まずは公式サイトで無料アカウントを取得し、上記「情報収集 → 分析 → レポート作成 → 通知」フローを UI で作ってみましょう。その後、ローカル環境へ移行すれば本格的な社内導入がスムーズに進められます。

スポンサードリンク

お得なお知らせ

スポンサードリンク
タイプ別にすぐ選べる

DXを前に進める、あなたの立場は？

DXは"組織でやる"か"まず自分が学ぶ"かで必要な打ち手が違います。立場に合わせて選んでください。

▷ 部署・全社のAIリテラシーを底上げしたい決裁者・推進担当者

【Kindle本】イノベーションOps　組織を動かすDX&AI導入プロセスのすべて▶

▷ 様々なDX事例・フレームワークを頭に入れたい担当者 | 読みやすい本をさがしてみましょう

Kindle Unlimited 30日無料｜DX/業務効率本読み放題▶

※DXは最初の一歩が肝心なので様々なキャッチアップをしましょう

▶ その他では 【kindke本】AIエージェント時代のDX ビジネスオーケストレーションの衝撃 / 生成AIカテゴリー が参考になります。

-Dify