セキュリティ要件を満たす Dify セルフホスト基盤の構築と運用

参考になった

レビュー投稿日の情報になります

株式会社ナレッジワーク / minodisk

EM / バックエンドエンジニア / 従業員規模: 101名〜300名 / エンジニア組織: 51名〜100名

最終更新日2026/03/16投稿日2026/03/18

利用機能	ツールの利用規模	ツールの利用開始時期	事業形態
ワークフロー・チャットフロー・外部サービストリガー・スケジュールトリガー	101名〜300名	2025年9月	B to B

利用機能	ワークフロー・チャットフロー・外部サービストリガー・スケジュールトリガー
ツールの利用規模	101名〜300名
ツールの利用開始時期	2025年9月
事業形態	B to B

アーキテクチャ

アーキテクチャの意図・工夫

当初はサイドカー構成で複数コンテナを 1 つの Cloud Run サービスにまとめていましたが、コンポーネントごとのリソース制御やオートスケールが効かないという課題がありました。そこで現在は、全コンポーネントを独立した Cloud Run サービスとして分離し、個別のリソース割当・オートスケール・デプロイを実現しています。

Dify の機能で意図しないpublicアクセスのパスを遮断するため、Cloud Load Balancing + IAP（Identity-Aware Proxy）を導入し、社外からのアクセスを遮断しています。Webhook など外部アクセスが必要な API パスのみ URL Map で個別に除外する構成としました。

ストレージについては、当初 Filestore を利用していましたが、最小構成でも月額 3 万円 × 2 環境＝ 6 万円のコストが発生していました。Cloud Storage へ移行することで、使用量ベースの課金となり大幅なコスト削減を実現しています。

キュー監視については、Cloud Scheduler + Cloud Run Jobs で 5 分間隔の監視を実装し、Cloud Monitoring 経由で Slack に通知する仕組みを構築しました。月額約 1 ドルで運用できています。

導入の背景・解決したかった問題

導入背景

ツール導入前の課題

弊社では社内業務の自動化を進めるにあたり、LLM を活用したアプリケーションを迅速に構築・運用する基盤がありませんでした。また、社の機密情報を扱う業務が多く、外部サーバーにデータを保存する SaaS 型のサービスは利用が難しい状況でした。

どのような状態を目指していたか

社内メンバーがノーコードで LLM アプリケーションを構築・運用できる環境
全データを自社管理下に置き、セキュリティ要件を満たした状態
ワークフローやチャットボットを手軽に作成・公開できるプラットフォーム

比較検討したサービス

n8n: ワークフロー自動化ツール
Dify Cloud: Dify の SaaS 版

比較した軸

LLM ネイティブな設計思想であるか
日本語対応・国内情報の豊富さ
UI の操作性と非エンジニアにとっての習得しやすさ
データの自社管理が可能か（セルフホスト対応）

選定理由

n8n はワークフローツールに LLM 機能を追加した形式ですが、Dify は LLM ネイティブな思想で設計されており、LLM アプリ構築に特化しています。公式で日本語化済みで国内コミュニティの情報も豊富なため、導入時の情報収集がスムーズでした。UI 操作性にも優れており、社内メンバーの利用ハードルが低い点も決め手となりました。セルフホスト対応で全データを自社管理下に置ける点も、弊社のセキュリティ要件に合致していました。

導入の成果

改善したかった課題はどれくらい解決されたか

5ヶ月で1500近くのワークフローができた。

どのような成果が得られたか

業務の自動化だけではなく、ワークフローへの理解、LLMへの理解も促進した。

導入時の苦労・悩み

サイドカー構成の限界が最初の大きな壁でした。複数コンテナを 1 サービスに詰め込むと、コンポーネントごとのリソース割当やオートスケールが効かず、全サービスを独立に再構成する必要がありました。特にtrigger機能がリリースされて、多くのwebhookのリクエストを効率よくに捌くのに効果を発揮しました。

また、API から Plugin Daemon への通信で RFC 9110 違反の GET + body リクエストが 400 エラーを起こす問題が発生しました。これは Dify 本体に PR を送って修正しています。

運用面では、Slack トリガーで数万件のワークフロー実行リクエストが未処理のまま滞留するキューオーバーフローが発生し、監視の仕組みを自前で構築する必要がありました。workerコンテナが適切にオートスケールするように設定を調整した。

Filestore のコストも課題で、最小構成でも月額 3 万円 × 2 環境＝ 6 万円がかかるため、Cloud Storage への移行を行いました。月額 2 千円 × 2 環境＝ 4 千円となり、95%削減しました。また、移行時に dify-cloud-kit のパス不具合を発見し、こちらも PR を送付しています。

バージョンアップへの追従も継続的な課題です。v1.10.0 の trigger 機能追加で Beat コンテナが新たに必要になるなど、Docker Compose 設定の差分を追跡し続ける運用が求められます。

マーケットプレイスのプラグインの網羅率が、他のワークフローツールと比較すると貧弱でした。自社専用のプラグインでBigQuery/Slack/Goolgle Sheets/Deckなど10数種類作って対応しています。また、プラグインの自動インストール機能を GitHub Actions で実装して、CDを行なっています。

導入に向けた社内への説明

上長・チームへの説明

ツール選定の方針について、特にセキュリティ的要件以外の部分についてチームの合意をとることを注力しました。LLMネイティブであるべき、ユーザーが馴染みやすいUIであるべき、国内でマーケティングが成功しているなど。

活用方法

よく使う機能

主にワークフロー機能を活用しており、API 経由でのワークフロー実行リクエスト受付や Slack トリガーによる自動実行を行っています。チャットフロー機能では社内向けチャットボットを構築しています。スケジュール実行で定期タスクの自動化も行っています。

ツールの良い点

LLM ネイティブな設計思想で、ワークフローツールに LLM を後付けした形ではなく、LLM アプリ構築に特化した設計になっています
公式で日本語化済みで、国内コミュニティの情報が豊富なため導入ハードルが低いです
非エンジニアでも習得しやすい直感的な UI を備えています
セルフホスト対応で全データを自社管理下に置け、セキュリティ要件を満たせます
OSS として公開されているため、問題発見時にソースコードを読んで原因を特定し、PR を送って修正できます
継続的にアップデートされており、新機能（trigger 機能など）が追加され続けています

ツールの課題点

セルフホストの運用負荷があり、バージョンアップ時に Docker Compose 設定の差分追跡が必要です。新コンポーネントの追加など破壊的変更への追従コストがかかります
特にバージョンアップ後は入念なQAが必要です。頻繁に基本的な機能が壊れるため、このバージョンでは何が壊れたのかを把握してからprd環境でもバージョンアップを行なっています

ツールを検討されている方へ

セキュリティ要件で SaaS の利用が難しい組織には、Google Cloud 上のセルフホストは現実的な選択肢です。月額 10〜12 万円で運用可能ですが、バージョン追従や監視構築などの運用負荷を担えるエンジニアリソースは必要になります。ざっくりですが立ち上げ時は専任1人月、運用時は0.5人月くらいという感覚です。社内利用とはいえ、SlackやGithubのwebhookを受けるようになったり使われれば使われるほど、それなりに問題も起きるのでSRE業をしつつスケールするためのリアーキを考えていく必要が出てくるでしょう。

問題が発生した際にソースコードを読んで調査・修正できる体制があると、セルフホストのメリットを最大限に活かせます。弊社では Claude Code などの AI ツールも活用しており、Cloud Logging からソースコードの調査、修正までのデバッグサイクルを効率化しています。