導入判断 · 運用設計

情シスがDifyを導入するときに整理しておくべき運用要件

2026.07.02 読了時間 約10分 Dify情シス導入判断運用

「Difyを使えば社内FAQボットが作れる」という話を聞いてPoC（概念実証）を試してみたものの、本番導入の話になった途端に「待った」がかかった——そんな経験はないだろうか。

情シス担当者から見ると、ツールの使いやすさとは別に整理すべき問いがある。誰がアクセスを管理するのか。ログはどこに残るのか。APIコストは誰が負担するのか。これらを先に決めておかないと、現場が使い始めてから問題が噴出する。

本記事では、Difyを社内で本格運用する前に情シスが確認・設計しておくべき運用要件を8つのカテゴリに整理した。末尾に実践的なチェックリストも用意したので、導入判断の材料として使ってほしい。

①まず決める：セルフホスト vs Dify Cloud

運用要件のほぼすべてはこの選択に依存する。最初に方針を固めておこう。

観点Dify Cloud（SaaS）セルフホスト（Docker）
データ所在Difyのサーバー（米国）自社インフラ（オンプレ / VPS）
個人情報・機密情報利用規約の確認が必須自社管理で完結できる
初期構築コスト低い（すぐ使える）高い（Docker設定が必要）
アップデート管理自動（バージョン選択不可）自分でタイミングを管理できる
SSO対応有料プランのみ自前で設定可能
コスト予測ユーザー数・API使用量に応じた従量課金サーバー費 + LLM API費

🐝 IroHive メモ 社内の機密情報（個人情報・契約書・財務データ）をナレッジベースに登録する場合はセルフホスト一択。Dify Cloudは利用規約上、入力データをモデル改善に使用しない旨が記載されているが、データが社外に出ること自体を許容できない場合は除外する。

②認証・アクセス管理

「誰でもDifyにログインして、誰でもワークフローを編集できる状態」は情シスの管理対象として危険だ。最低限、以下の3点を決めておく。

ユーザー管理ポリシー

  • 招待制にする：Dify管理者が承認したメールアドレスのみ登録可能にする
  • 退職者対応：退職・異動時にアカウントを即削除するフローを人事と連携して整備する
  • 権限分離：「管理者」「開発者」「一般利用者」の3ロールを使い分ける

SSOとIdP連携

セルフホスト版のDifyはSAML・OAuth2によるSSO設定が可能だ。すでにGoogle WorkspaceやMicrosoft Entra ID（旧Azure AD）を使っている企業なら、そのIdPと連携することで「Dify専用パスワード」を排除できる。

⚠️ よくある落とし穴 テスト段階で作った「admin / admin」のような共有アカウントを本番でも使い続けているケースがある。導入前に管理者アカウントのパスワードポリシーを整備し、個人アカウントに移行しておこう。

③ログ・監査証跡

「誰がいつ何を聞いたか」「どんな回答が返ったか」を記録・保管できる仕組みが必要だ。特にコンプライアンス要件が厳しい業種（医療・金融・法律）では監査証跡の保存義務が発生することがある。

Difyが標準で記録するもの

  • 会話ログ（入力・出力・タイムスタンプ）
  • ナレッジベースの変更履歴
  • APIリクエスト数・トークン使用量

情シスが追加で設計すべきもの

  • ログ保存期間の定義：1年・3年・永続など、社内規程に合わせて設定
  • 外部ログ転送：セルフホスト版ならSplunkやCloudflare Logpushへの転送が可能
  • 個人情報のマスキング：会話ログに氏名や社員番号が含まれる場合の対処方針

💡 実務ポイント Dify Cloudの会話ログはダッシュボードから手動エクスポートが可能（CSV形式）。セルフホスト版はPostgreSQLに直接クエリを打てるため、より柔軟なログ管理ができる。

④データ管理方針

ナレッジベースに登録するドキュメントの管理方針を決めておかないと、古い情報が蓄積してボットの回答精度が下がる。

分類例更新頻度
社内規程・ポリシー就業規則・情報セキュリティポリシー年1〜2回
業務マニュアル申請手順・システム操作手順随時
FAQ蓄積問い合わせ対応記録月次

ドキュメントが更新されたときに誰がナレッジベースを更新するのかを役割として明確にしておく。「気づいた人が更新する」では必ず漏れが発生する。

⑤アップデート管理

Difyはオープンソースプロジェクトとして活発に開発が続いており、月に複数回のバージョンアップが行われる。セルフホスト版ではアップデートを自社で管理する必要がある。

セルフホスト版の更新フロー

  1. GitHubのリリースノートを確認（破壊的変更の有無をチェック）
  2. ステージング環境で先行アップデート・動作確認
  3. 本番環境をバックアップ（DB・ナレッジベースのデータ）
  4. docker compose pull && docker compose up -d で更新適用
  5. 動作確認（主要ワークフローのテスト）

✅ 推奨：ステージング環境を用意する 本番と同等のDockerコンテナをステージング環境に立てておくことで、アップデートによる予期せぬ不具合を本番に影響なく検証できる。

⑥コスト管理

Dify本体は無料（セルフホスト版）だが、LLM APIの費用は別途発生する。「使い始めたら請求が予想外に高かった」という事態を防ぐための設計が必要だ。

LLMプロバイダーコスト感用途
GPT-4o-mini低コストFAQ回答・一次対応向き
GPT-4o中コスト複雑な判断・要約が必要な場合
Claude Haiku低コスト高速・軽量タスク向き
Claude Sonnet中コスト品質重視の用途
Gemini Flash低コスト大量処理・コスト最適化
  • APIの利用上限：OpenAI等の管理画面で月間支出上限（Hard Limit）を設定する
  • 部門別API Key：部署ごとに異なるAPIキーを使い、使用量を可視化する
  • モデルの使い分け：回答品質と費用のバランスを見て、GPT-4oよりGPT-4o-miniを使うなど

⑦障害対応・SLA設計

「Difyが繋がらない」という問い合わせが情シスに来ることは想定しておく必要がある。

  • ヘルスチェック：Cloudflare WorkersのCron Trigger等で定期的にAPIをたたいて死活監視
  • アラート通知：n8nでSlack/LINE通知を飛ばす
  • 代替手段の準備：Difyが停止した場合の代替手段（従来のFAQページへの誘導など）をユーザーに周知しておく

⑧役割分担の明確化

業務情シス現場部門
ユーザーアカウント管理◎ 主担当申請窓口
ワークフロー設計・構築△ 支援◎ 主担当
ナレッジベース更新△ 仕組み構築◎ コンテンツ更新
LLM APIキー管理◎ 主担当利用申請のみ
コスト監視◎ 主担当月次レポート受領
障害対応◎ 主担当初動連絡
アップデート適用◎ 主担当動作確認協力

導入前チェックリスト

以下の項目を確認してから本番導入に進もう。

  • セルフホスト / Dify Cloud どちらを使うか決定した
  • 管理者アカウントの共有を廃止し、個人アカウントに移行した
  • 退職者・異動者のアカウント削除フローを人事と合意した
  • SSO連携（Google Workspace / Entra ID等）の要否を判断した
  • 会話ログの保存期間と保管場所を決定した
  • 個人情報がログに含まれる場合の対処方針を決めた
  • ナレッジベースに登録するドキュメントの更新担当者を決めた
  • ステージング環境を用意した（またはPreviewデプロイを設定した）
  • LLM APIの月間上限金額を設定した
  • 部門別APIキーの運用方針を決めた
  • 障害時の代替手段をユーザーに周知した
  • 情シスと現場部門の役割分担表を作成・共有した

✅ まとめ Difyは導入のしやすさが魅力だが、本番運用では認証・ログ・コスト・役割分担の設計が重要だ。PoC段階で「とりあえず動いた」状態のまま本番に移行すると、後から整備コストが跳ね上がる。この記事のチェックリストを導入会議の議題として使い、関係者と合意を取っておこう。

参考資料

📌 バージョン注記 本記事の運用要件・設定方法は Dify v1.x 系（最新 v1.15.0・2026年7月時点）を参考にしています。Difyは月に複数回アップデートされるため、UIのラベルや機能が変わっている場合があります。導入前に公式ドキュメントと照合してください。