Dify でできること・できないこと

はじめに：なぜ「できないこと」から学ぶのか

LLM アプリを作って「使えない」と判断する人の多くは、そもそも LLM が苦手なことをやらせようとしている。Dify は LLM の限界をそのまま引き継ぐ。

できることを正確に理解すれば、本当に価値のある用途に集中できる。

---

LLM の本質的な限界

1. 嘘をつく（ハルシネーション）

LLM は「もっともらしい文章を生成する機械」。
「正しい情報を検索する機械」ではない。

起きること:
  「2024年の売上高は〇〇億円です」← 実際に存在しない数字を自信満々に言う
  「〇〇法の第5条によると...」   ← 存在しない条文を流暢に引用する
  「A社のCEOはXXXです」         ← 古い情報や混同した情報を述べる

なぜ起きるか:
  LLM は次のトークン（単語）の確率分布から文章を生成する。
  「もっともらしい」≠「正しい」

対策（Dify での実装）:
  → RAG で根拠文書を提供する（ナレッジベース）
  → 「根拠がない場合は答えない」をプロンプトに書く
  → 出典表示を必須にする
  → 数値・固有名詞は人間が確認する

2. リアルタイム情報を知らない

LLM の知識には「カットオフ日」がある。

例:
  GPT-4o: 2024年4月までの情報
  Claude 3.5: 2024年4月までの情報

知らないこと:
  ✗ 今日の株価
  ✗ 最新のニュース
  ✗ 昨日リリースされた新製品
  ✗ 社内の最新情報（当然）

対策（Dify での実装）:
  → Web検索ツールを Agent に持たせる（Google Search等）
  → ナレッジベースを定期更新する
  → システム変数 {{sys.current_datetime}} で現在時刻を渡す

3. 長い文書の中間部分を忘れる

コンテキストウィンドウの限界:

GPT-4o:    128Kトークン ≒ 約10万文字
Claude 3.5: 200Kトークン ≒ 約15万文字

「十分長い」と思えるが、実際の問題:
  長文の最初と最後は覚えているが中間部分を見落とす（Lost in the Middle 問題）

具体的に困る場面:
  ✗ 200ページのPDFを全部読んで要約させる
  ✗ 1週間分のログを全部渡して異常を検出させる

対策（Dify での実装）:
  → RAG で関連する箇所だけを取り出して渡す
  → 長文はチャンク単位でイテレーション処理する

4. 算数が苦手

LLM はトークンで考えるため、正確な数値計算が苦手。

失敗例:
  「314 × 157 を計算して」→ 間違えることがある
  「100 件のデータの平均を出して」→ ミスが起きやすい
  「○○日から○○日は何日間？」→ 間違える場合がある

対策（Dify での実装）:
  → Code ノードに Python で計算を書く
  → Calculator ツールを Agent に持たせる
  → 「LLM には判断させる、計算はコードにやらせる」を徹底する

5. 指示を忘れる・無視する

プロンプトに何を書いても LLM は完璧には従わない。

よくある失敗:
  「必ず日本語で答えてください」→ たまに英語が混じる
  「JSON形式で返してください」→ 前後に余計なテキストが付く
  「200文字以内で答えてください」→ 超えることがある

対策（Dify での実装）:
  → 指示を短く・シンプルに書く
  → JSON 出力は Code ノードで try/except パースする
  → 長さ制限はプロンプト + Code ノードで切り詰める
  → Structured Output に対応したモデルを使う

---

Dify 固有の制限

実行時間・タイムアウト

Dify のワークフロー実行時間:
  推奨: 60秒以内
  上限: 数分（Cloud 版は制限あり）

問題が起きる場面:
  ✗ 何十回もループする深いリサーチ
  ✗ 非常に大きなファイルの処理
  ✗ 外部APIが遅いケース

対策:
  → タイムアウトする処理は外部サーバーへ切り出す
  → 大量データはバッチに分割して複数回呼び出す

Code ノードの制約

Code ノード（Python/Node.js）の制限:
  ✗ インターネットへのアクセス不可（セキュリティ）
  ✗ ファイルシステムへのアクセス不可
  ✗ ほとんどのサードパーティライブラリ不可
  ✓ 標準ライブラリ（json, re, math 等）は使える

対策:
  → ネットワーク必要な処理は HTTP Request ノードを使う
  → 複雑な処理は外部 API として別途実装する

RAG の精度に限界がある

「文書をアップロードすれば何でも答えられる」は誤解。

RAG が苦手なこと:
  ✗ 複数文書を横断した数値集計（「全商品の平均価格は？」等）
  ✗ 表・図の中の情報（テキスト化されていない部分）
  ✗ 文書の「行間を読む」推論
  ✗ 「書いていないこと」に気づく（=文書に記載のない情報の欠如検出）

対策:
  → 表はCSVやテキスト化してから登録する
  → 「文書に記載がある質問」にのみ使う設計にする
  → 集計が必要ならデータベースとAPIを組み合わせる

---

Dify に向いている用途・向いていない用途

向いている用途 ✅

✅ 文書に基づく Q&A
   → 「この規則では〇〇はどうなってますか？」

✅ 定型テキストの生成・変換
   → 「この商品情報を元に説明文を書いて」

✅ 分類・仕分け
   → 「このメールは苦情・問い合わせ・その他のどれ？」

✅ 要約・サマリー
   → 「この会議メモを3行にまとめて」

✅ 構造化データ抽出
   → 「このメールから名前・電話番号・課題を取り出して」

✅ 翻訳・言い換え
   → 「この文章を丁寧語に変換して」

✅ 複数情報の統合・レポート化
   → 「3つの調査結果を統合して報告書を書いて」

向いていない用途 ❌

❌ 100% 正確な情報提供が必要な業務
   → 医療診断・法的判断・会計処理（最終確認は必ず人間が行う）

❌ リアルタイムデータへの依存
   → 株価・在庫数・リアルタイム位置情報
   （ただしツールで外部APIを叩けば解決できる場合もある）

❌ 個人認証・セキュアなトランザクション
   → ログイン・決済・署名（LLMはこれらを担うべきでない）

❌ 大量数値データの集計・分析
   → Excelやデータベースの方が速く・正確
   （LLMはあくまで「解釈・説明」の補助に使う）

❌ 長大なコードベースの理解
   → 10万行のコードを丸ごと読ませる
   （RAGで関連ファイルを絞って渡す設計にする）

---

「AIに任せすぎない」設計原則

LLM アプリ設計の鉄則:

1. AIは「補助」、最終判断は人間
   → 重要な意思決定の前に Human Input ノードを入れる

2. AIの出力は「草案」として扱う
   → 「自動送信」でなく「確認後に送信」する設計

3. 失敗を前提に設計する
   → try/except・フォールバック・エラーメッセージを必ず用意

4. 出典を示す
   → RAGは必ず出典（文書名・ページ）を表示する

5. ログを取る
   → 何を聞いて何を答えたか記録し、定期的に確認する

---

参考

• 30分で最初のDifyアプリを作る — まずは動かしてみる
• RAGチャットボット構築 — ハルシネーション対策込みの実装例
• コスト設計入門 — 費用を把握してから本番へ