Dify本番リリース前チェックリスト＆運用設計ガイド

PoC から本番への移行で起きること

PoC（試作）環境では「動いた」のに本番でトラブルになるパターンが多い。主な原因：

PoC では見落としがちな問題:
  ① 少量のテストデータでは見えなかった精度のばらつき
  ② 複数ユーザーが同時利用したときの API レート制限
  ③ 個人情報・機密情報の取り扱いが未整備
  ④ コストが想定より大幅に膨らむ
  ⑤ 障害時の対応手順が決まっていない

このチェックリストを使って、本番リリース前に穴を塞ぐ。

---

フェーズ1: セキュリティ・プライバシー確認

□ API キーの管理
  □ 環境変数または Dify の Secrets Manager に格納している
  □ ソースコード・Git リポジトリに API キーをハードコードしていない
  □ 本番用と開発用で API キーを分けている
  □ 使用しているモデルプロバイダーのキー権限を最小限に絞っている

□ 個人情報・機密情報の取り扱い
  □ ナレッジベースに個人情報・顧客情報が含まれていない
  □ ワークフローのログに個人情報が記録されない設計になっている
  □ セルフホスト or クラウド の選択を個人情報保護要件に照らして決定した
  □ 国内法規制（個人情報保護法・業界規制）への対応を確認した

□ アクセス制御
  □ 内部ツールは社内ネットワーク or VPN から限定アクセスにしている
  □ 公開 API に認証トークンを設定している
  □ 管理者・一般ユーザーのロール分離が完了している

---

フェーズ2: 品質・精度確認

□ プロンプト品質
  □ システムプロンプトを10件以上の多様な入力でテストした
  □ 「意図的に困難な質問」「悪意のある入力」でテストした（プロンプトインジェクション）
  □ 出力フォーマット（JSON・箇条書き等）が安定している
  □ ハルシネーションが発生しやすいケースを特定してガード設計をした

□ RAG 品質（ナレッジベースを使う場合）
  □ 代表的な質問20件以上でリトリーバルの精度を確認した
  □ 関係ない質問をしたとき「わかりません」と答えられる
  □ チャンキング設定をドキュメントの種類に合わせて調整した
  □ ナレッジベースの更新スケジュールと担当者が決まっている

□ エッジケース対処
  □ 入力が空のとき正しく処理される
  □ 極端に長い入力（コンテキスト上限を超える）への対処がある
  □ LLM が空文字・エラーを返したときのフォールバックがある
  □ 多言語入力（日本語以外）への対処方針が決まっている

---

フェーズ3: コスト・パフォーマンス確認

□ コスト上限設定
  □ 月額の API コスト予算を試算した（[コスト設計ガイド](concepts_dify_intro_cost.md) 参照）
  □ モデルプロバイダー側でコスト上限 (Hard Limit) を設定した
  □ 想定外の大量呼び出しを防ぐレート制限を設定した

□ コスト最適化
  □ タスクの難易度に応じてモデルを使い分けている
  □ 不要なトークン（長すぎるシステムプロンプト・不要なコンテキスト）を削除した
  □ 繰り返す処理にキャッシュ機能を検討した

□ パフォーマンス
  □ エンドユーザーへのレスポンス時間を計測した
  □ Streaming 出力（逐次表示）を有効にして体感速度を改善した
  □ 並列実行が必要なノードを並列化してレイテンシを短縮した
  □ タイムアウト設定がワークフローの処理時間に対して適切か確認した

---

フェーズ4: 可観測性・監視設定

□ ログ設定
  □ Dify 内蔵ログで入出力・エラーを確認できる
  □ Langfuse または LangSmith でトレースを有効化した（推奨）
  □ トークン消費量・コストのダッシュボードを設定した

□ アラート設定
  □ エラー率が閾値を超えたときの通知フロー（Slack・メール）がある
  □ API コストが閾値を超えたときの通知フローがある
  □ Dify サーバー自体（セルフホストの場合）の死活監視がある

□ 評価・改善サイクル
  □ ユーザーフィードバック（👍/👎）収集機能を有効にした
  □ 週次 or 月次でログを確認して精度改善するプロセスを決めた
  □ A/B テスト（複数プロンプトの比較）の手順を理解している

---

フェーズ5: 運用・障害対応設計

□ ロールバック手順
  □ 本番デプロイ前にワークフローの DSL をエクスポート・バックアップした
  □ 問題が起きたときに旧バージョンへ戻す手順が決まっている
  □ ナレッジベースの旧バージョンも保存されている

□ インシデント対応フロー
  □ 障害発生時の一次対応担当者が決まっている
  □ 「AI の回答が明らかにおかしい」ときに素早く修正・停止できる体制がある
  □ ユーザーへの障害告知文テンプレートがある

□ ドキュメント整備
  □ このワークフローの目的・設計意図を README またはコメントに残した
  □ プロンプトの変更履歴を管理する方法を決めた
  □ 担当者が変わっても引き継げるドキュメントがある

---

本番移行の判断基準

リリース可否の目安（すべて YES であれば本番 GO）:

品質:
  ✅ 代表的な質問20件で正答率80%以上
  ✅ プロンプトインジェクションで意図しない出力が起きない
  ✅ エラー時のフォールバックが動作確認済み

コスト:
  ✅ 月額コスト試算が予算内に収まる
  ✅ プロバイダー側のコスト上限を設定した

セキュリティ:
  ✅ API キーを環境変数で管理している
  ✅ 個人情報の取り扱いが法令に準拠している

運用:
  ✅ 担当者・更新スケジュールが決まっている
  ✅ 障害時の対応フローが決まっている

---

PoC → 本番のよくある失敗パターンと対策

失敗パターン1: 「テストでは良かったのに精度が悪い」
  原因: テストデータが少なすぎた / 実際のユーザー入力が想定外だった
  対策: 初月は「ベータ公開」として少数ユーザーに限定し、ログを集めて改善

失敗パターン2: 「月末にコストが爆発した」
  原因: 利用者数・トークン量の見積もりが甘かった
  対策: プロバイダーのダッシュボードでコスト上限を設定する。
        Dify Cloud の場合はレート制限（1分あたり呼び出し回数）を設定する

失敗パターン3: 「担当者が変わったら誰も触れなくなった」
  原因: プロンプト・設計意図が属人化していた
  対策: DSL エクスポート + 設計ドキュメントを Git 管理する

失敗パターン4: 「法令改正があったのにナレッジが古いまま」
  原因: 更新プロセスを決めていなかった
  対策: カレンダーに四半期レビューを登録。担当課との更新合意を取り付ける

---

継続運用のサイクル

週次:
  □ エラーログの確認（Dify ログ / Langfuse）
  □ ユーザーフィードバック（低評価回答）の確認
  □ コスト消費の確認

月次:
  □ 精度改善（問題のあった回答のプロンプト修正）
  □ ナレッジベースの更新確認
  □ モデルプロバイダーの新モデル・価格変更の確認

四半期:
  □ ワークフロー全体の見直し（アーキテクチャの陳腐化）
  □ セキュリティ設定の棚卸し
  □ コスト最適化の再検討（安くなったモデルへの切り替え）

---

参考：関連ドキュメント

• Difyアンチパターン集 — 本チェックリストで防ぐべき問題の詳細
• Difyのコスト設計と節約テクニック — フェーズ3 のコスト試算
• 可観測性・デバッグ・評価 — フェーズ4 のログ・監視設定
• Difyでできること・できないこと — Human-in-the-loop の設計判断