Dify・n8nのセルフホスト運用：導入前に決める保守と責任分担

Dify・n8nを社内で使い始める前に、対象の業務、使う人、接続する先、扱うデータ、止まってもよい時間、運用の担当を決めます。画面でフローを作って試しに動かせることと、業務で使い続けられることは別です。

Difyは、生成AIを使ったアプリや、社内文書を検索して回答に使うRAG、ワークフローを画面で組むための基盤です（Dify：GitHub）。n8nは、SaaSやAPIの間でデータを受け渡す処理を、画面のフローとコードを組み合わせて作るサービスです。どちらにもAIの処理とフローの機能があり、二つを組み合わせて使う場合もあります。

自動化する業務の選び方はZapier/MakeとAI連携で進める業務自動化で、AIに任せる処理の品質と範囲の確かめ方は生成AIを業務へ組み込む方法で扱っています。この記事では、そのうえで基盤を運用し続けるための配置、版、保存、更新、担当を扱います。

フローが動くことだけでは、本番で運用する条件はそろいません。止まったときに誰が気付くか、誰が停止を判断するか、どこまで戻せるかが決まっていなければ、業務を任せる範囲は広げられません。

Cloudは提供元が用意した環境を使う形、セルフホストは自社や委託先が管理する環境に置く形です。n8nは、Cloudかセルフホストかと、版やプランの二つを選ぶ流れを示しています（n8n：Choose how to use n8n）。次の表で、どちらを選ぶ場合でも確認する分担を整理します。

表は横にスクロールできます →

Cloudで提供元が担う範囲は、製品、プラン、契約によって異なります。どのCloudにも同じ復旧や保存の機能があるとは限らないため、使うプランの説明で確かめます。Cloudでも、業務のルール、接続先の権限、送るデータ、結果の確認、社内への連絡は自社に残ります。

セルフホストでは、置く環境や構成を選べる分、OS・コンテナ・DB・保存領域などの保守を担います。どの部品が必要かは配置によって異なります。社内に担当がいない場合は、Cloudを使う、保守を委託する、対象を絞って試す、導入を見送る、という選択肢もあります。社内のサーバーに置いたから外部へデータを送らない、Cloudだから何も制御できない、とは限りません。

Dify・n8nでは、次の権限を分けて考えます。

• フローやアプリを編集・公開する人：処理の内容や接続先を変えられる
• 基盤を管理する人：サーバー、設定、更新、バックアップを扱える
• アプリやフローを使う人：決められた入力をして、結果を受け取る
• 接続先で許される操作：連携に使うアカウントやAPIキーで、外部のSaaSに対してできること

SSOなどの機能は、版やプラン、対象の画面によって使えるかどうかが変わります。n8nではSSOなどの機能が有料のプランで提供され、DifyもSSOや権限の細かな管理を企業向けの版の機能として案内しています（n8n：Choose how to use n8n、Dify：GitHub。確認日：2026年10月現在）。無料の版で必要な機能がすべて使えるとは限りません。また、管理画面のログインを守っても、公開したアプリや、WebhookやAPIの受け口まで使う人が制限されたことにはなりません。受け口ごとに、誰がどこから呼び出せるかを確認します。

データの経路は、入力 → Dify・n8n → AIのモデルやAPI → 検索や外部のSaaS → ログ・監視・保存先、の順にたどって確認します。使わない経路は対象外にしてかまいませんが、セルフホストというだけで、閉じたネットワークの中だけで動く、外部へデータを送らない、とはなりません。外部のモデルやSaaSを呼び出せば、その先へデータが送られます。

n8nの追加のノードやDifyのプラグインのように後から加える機能も、提供元、コードの内容、使うアクセス権、更新の状況を確認します。n8nのセキュリティ監査も、使われていない認証情報、ホストでコードを実行できるノードやコミュニティのノード、保護されていないWebhook、古い版などを点検の対象にしています（n8n：Run security audits）。

APIキーや個人情報は、確認票や問い合わせの文面に書き込みません。記録するのは、保管している場所と管理する人だけにします。扱ってよい情報の区分は企業のAI利用ルールブックで扱っています。

本番で使い始める前に、次の8項目を記録します。分かっていることと、まだ確かめていないことを分けて書くと、次に誰が何を確認するかが決まります。

表は横にスクロールできます →

この確認票は、すべての行を「確認済み」で埋めるためのものではありません。自社で確認した根拠、未確認の点、次に確認する担当と期限を書きます。鍵やパスワードの値は記入せず、安全に保管している場所の参照と、見られる人だけを記録します。チェックの数を、安全性や成熟度、本番で使えるかどうかの点数に置き換えません。

バックアップの対象は、フローの定義だけではありません。製品と配置によって、保存しておくものが変わります（確認日：2026年10月現在）。

• Dify：版と構成、環境設定のファイル、DB、アップロードされたファイルなどの保存領域、ナレッジのベクトルデータ、認証情報の復号に必要な鍵の保管先などを、実際の配置に合わせて確認します。Docker Composeの標準の構成では、保存用のディレクトリ一式をバックアップする案内がありますが（Dify：Storage & Migration）、外部のDBや保存領域を使う場合は、それぞれ別に保護します。SECRET_KEYはログインの状態やファイルのURLの署名、一部の外部連携の認証情報の暗号化に使われます。モデルの提供元のAPIキーなど、ワークスペースごとの認証情報は別の鍵で暗号化されます（Dify：Environment Variables）。一つの鍵だけを残せば復旧できるとは考えず、どの鍵がどこにあるかを記録します。
• n8n：ユーザーフォルダ（認証情報の暗号化鍵を含む設定）、使っているDB、ファイルなどを外部に保存している場合はその保存領域、追加したノードなどを確認します。フローと認証情報を書き出しても、ユーザーと権限、実行の履歴、変数、インスタンスの設定は含まれず、それだけでは全体を復旧できません。暗号化された認証情報を戻すには、対応する暗号化鍵が必要です（n8n：Back up and restore）。

フローを書き出して別の環境へ取り込むこと、構成全体を復旧すること、外部のSaaSに加えた変更を取り消すことは、それぞれ別の作業です。動いている最中のDBやファイルを単純にコピーしても、整合したバックアップになるとは限りません。n8nも、標準のSQLiteを使う場合は、止めてからコピーするよう案内しています。どの時点まで戻せるか、戻すときに対応する版・設定・鍵がそろうか、復元した環境が本番の送信先へ通知や書き込みをしないかを確認します。復元を試して記録する方法は、バックアップ復元テストの進め方で扱っています。

更新では、対象の版のリリースノートと、変わった設定や依存するサービスを読みます。Difyは版によって更新の手順が異なり、設定のひな形と実際の設定の差を確かめるよう案内しています（Dify：Deploy Dify with Docker Compose）。n8nは、こまめに更新し、互換性のない変更をリリースノートで確かめ、試験用の環境で先に試すことを勧めています（n8n：Update n8n）。試験用の環境は、有料のEnvironmentsの機能に限らず、本番と分けた環境とテスト用のデータで、代表的な処理と接続・権限を確かめる形でも用意できます。

DBの構造が変わる更新の後は、古い版に戻すだけでは元の状態に戻らない場合があります。更新の前にバックアップを取り、戻すときのデータと設定、更新の後に入った処理の扱いも決めておきます。変更の依頼から承認・反映までの手順は、システム変更管理の進め方で扱っています。

監視では、次を分けて見ます。

• 画面やAPIに到達できるか、DBにつながっているか
• ワーカーや処理待ちが滞っていないか
• 期限までに処理が終わった件数
• 外部のAPI・認証・利用量の上限
• 処理の結果が業務として正しいか

n8nの/healthzは、応答200でインスタンスに到達できることを示しますが、DBの状態は示しません。DBにつながり、受け付ける準備ができているかは、別の/healthz/readinessで確かめます（n8n：Monitor n8n）。どちらも業務の処理が成功したことまでは示さないため、「正常」の表示だけで業務が終わったとは判断しません。

ログには入力や出力が残る場合があります。Difyも、詳しいログを出す設定は機密の情報を残すおそれがあるとして、本番では勧めていません（Dify：Environment Variables）。保存する範囲、期間、見られる人、削除の方法を決めます。障害に気付いた人、止める権限を持つ人、業務責任者、再開を承認する人と、それぞれの代理も決めておきます。

次の表は、止まったときに再開を判断する例です。製品の機能ではなく、運用の決め方の例として示します。

表は横にスクロールできます →

応答がないことだけで、処理が実行されなかったとは決めつけません。外部のサービス側で結果を照会し、処理済みと未処理を分けてから、必要な対象だけを再実行します。全件をそのまま再実行すると、二重の登録や通知が起きる場合があります。再実行の基本的な考え方は、Zapier/MakeとAI連携で進める業務自動化で扱っています。

費用は、同じ期間、処理の件数、利用者の数、データを保存する条件をそろえて、次の項目を洗い出します（確認日：2026年10月現在）。

• 製品：版やプランの費用、追加の機能、利用量の上限
• 基盤：サーバー、DB、保存領域、通信、バックアップの保管
• モデル・API：AIのモデルや外部のAPIの利用料
• 作業：構築、更新、監視、復元の確認、問い合わせ、引継ぎの工数

金額が分からない項目を0円にはしません。確認できた範囲の小計と、未確認の項目を分けて示し、小計だけで割安かどうかを判断しません。

ライセンスの条件も、使う形に合わせて確かめます。Difyは、Apache License 2.0に追加の条件を加えたライセンスで、商用での利用を認めたうえで、複数の利用者に向けたマルチテナントの運用や、画面のロゴ・著作権の表示の変更などには、提供元の許可や商用のライセンスが要るとしています（Dify：LICENSE）。n8nのセルフホストの無料版はSustainable Use Licenseで提供され、社内の人だけがフローを作る使い方などと、社外の人がフローを作ったり設定したりできる提供や、n8nをサービスとして提供する使い方とで、必要なライセンスが分かれます（n8n：Which license do I need for my use case?）。

社内での利用、顧客の環境の構築を手伝うこと、他社向けにホスティングや編集の機能を提供することは、同じ扱いではありません。受託や商用の利用を一律に禁止とも、一律に自由とも考えず、利用の形と現行の条件で確認します。解釈が必要な場合は、提供元へ問い合わせます。

運用を始める前に、次の項目を確認します。未確認の項目には担当と期限を付けます。重要な条件が未確認のままなら、対象を限って始める、追加で確認する、開始を見送る、という選択肢があります。すべてを自動化すること自体を目標にはしません。