「生成AIを業務に組み込みたいが、外部へのデータ送信が怖い」
多くの日本企業が直面しているこのジレンマを、技術的に解決する手段があります。
それが、ワークフロー自動化ツールn8nのセルフホスト（自社運用）。
AIの利便性を享受しながら、データの物理的な保管場所は100%自社のコントロール下。
さらにローカルLLMと組み合わせれば、インターネットにすら出ない完全閉域のAI自動化も実現可能。
しかし自社で運用するということは、セキュリティの全責任を自社で負うこと。
この記事では、n8nセルフホストのメリットと、求められる運用体制についてご説明します。
読んでいて「そこまではできない！」と感じた方も、ブラウザバックは少し待ってください。
記事の後半では、現実的な選択肢としてのクラウド版のセキュリティ仕様についても解説しています。セルフホストの壁が高いと感じた方は、ぜひこちらもご一読ください。
n8nとは？セキュリティ重視の企業が「セルフホスト」を選ぶ理由
業務自動化ツールは数多くありますが、データの管理場所を自分たちでコントロールできるものは限られます。このセクションでは、n8nというツールの概要と、なぜセルフホストという選択肢が注目されているのかを整理します。
n8nの基本：ノーコードでつくるAI×業務自動化
n8nは、異なるアプリケーションやサービスをノーコード・ローコードでつなぎ、業務フローを自動化するオーケストレーションツールです。ブラウザ上のビジュアルエディタでノード（処理の単位）を配置し、ドラッグ＆ドロップで接続するだけで、複雑なワークフローを構築できます。
たとえば、フォームに送信されたデータをAIで分析し、結果をSlackに通知しつつCRMに登録する、といった一連の処理をひとつのワークフローにまとめることが可能です。400を超える外部サービスとの連携ノードが用意されており、HTTP Requestノードやコードノードを使えば、APIを持つサービスであればほぼすべてに接続できます。
n8nの特徴的な点は、AIとの親和性の高さです。OpenAI、Anthropic Claude、Google Geminiなどの主要なLLMとの連携ノードが標準で用意されており、LangChainベースのAIエージェントノードやRAG（検索拡張生成）の構築にも対応しています。単なるタスク自動化にとどまらず、AIを組み込んだ判断・分類・要約・生成の自動化まで実現できる点が、他のワークフロー自動化ツールとの大きな差別化ポイントです。
なぜ今、セルフホスト（自社運用）なのか
n8nにはクラウド版とセルフホスト版の2つの利用形態があります。クラウド版はn8n社が管理するサーバー上で動作し、ユーザーはサインアップするだけですぐに使い始められます。一方、セルフホスト版は自社のサーバーやクラウドインフラ上にn8nをインストールして運用する方式です。
クラウド版は手軽ですが、ワークフローの実行データは必然的にn8n社の管理するサーバーを経由します。これは多くの企業にとって問題にならない場合もありますが、個人情報や機密性の高い業務データを扱う企業にとっては、データの所在地や経路を自社でコントロールできないことがリスクになりえます。
セルフホスト版を選ぶ企業が増えている背景には、いくつかの要因があります。まず、2022年4月に全面施行された改正個人情報保護法により、個人データの越境移転に関する規律が強化されました。外国にある第三者にデータを提供する場合、提供先の国の制度に関する情報を本人に提供した上で同意を取得するか、基準適合体制の整備が求められるようになっています。海外SaaSを利用する場合、この対応が必要になるケースがあります。
また、AI活用が進む中で、社内の機密データをLLMに入力する機会が増えています。クラウドベースのAI APIを使う場合、入力データは外部のサーバーに送信されます。セルフホスト環境であれば、ローカルLLMと組み合わせることで、データを一切外部に出さずにAIを活用できます。コンプライアンスとAI活用を両立させたい企業にとって、セルフホストは合理的な選択肢です。
n8nセルフホストで「データを社外に出さない」が実現する理由
セルフホストの最大の強みは、データの流れを自社の管理下に置けることです。ただし、ひとくちにデータを社外に出さないといっても、その範囲にはレベルがあります。ここでは、セルフホストで実現できるデータ管理の段階と、日本の法規制との関係を解説します。
【前提】「データを社外に出さない」の2つのレベル
n8nをセルフホストしたからといって、すべてのデータが自動的に社外に出なくなるわけではありません。どこまで閉じた環境にするかは、設計次第で段階的に選択できます。
レベル1：ワークフロー情報・認証情報を自社管理（API通信は発生）
セルフホストの時点で、n8nの本体（ワークフローの定義、実行ログ、認証情報のデータベース）はすべて自社サーバー内に保持されます。クラウド版では、これらの情報がn8n社のサーバー（ドイツ・フランクフルトのMicrosoft Azure上）に保存されますが、セルフホストではその必要がありません。
ただし、ワークフローの中でGmailやSlack、OpenAI APIなどの外部サービスを呼び出す場合、その通信は当然ながら社外に出ます。この段階では、n8nの基盤は社内に閉じつつ、業務上必要な外部連携は許容する、というバランスです。
多くの企業にとって現実的なのはこのレベルです。ワークフローの設計情報や認証情報が外部に漏れるリスクを軽減しつつ、実務に必要な外部サービスとの連携は維持できます。
レベル2：ローカルLLM連携による完全閉域化（完全オフラインも可能）
より厳格なデータ保護が求められる場合、外部APIへの通信も遮断し、すべての処理を自社ネットワーク内で完結させることも可能です。
n8nはOllama（ローカルLLM実行環境）との連携をサポートしており、n8n公式のSelf-hosted AI Starter Kitを使えば、n8n、Ollama、ベクターデータベースのQdrant、PostgreSQLをDocker Composeで一括構築できます。Llama 3.2などのオープンソースLLMをローカルで実行し、n8nのAIエージェントノードからそのまま呼び出す構成です。
この構成では、AIへの入力データも、その処理結果も、すべて自社サーバー内にとどまります。インターネット接続が不要なため、物理的に隔離されたネットワーク環境（エアギャップ環境）での運用も技術的には可能です。
機密性の高い文書の要約、社内ナレッジベースへの質問応答、顧客データの分類・分析など、外部に出せないデータを扱うAIワークフローに適しています。
n8nセルフホストで実現する「日本基準」のコンプライアンス対応
データを自社管理下に置けるということが、具体的にどのような法規制やガイドラインへの対応につながるのかを整理します。
データの物理的な所在を「自社サーバー」に固定できる強み
2022年4月に全面施行された改正個人情報保護法（令和2年改正法）では、個人データの越境移転に関する規律が大幅に強化されました。外国にある第三者に個人データを提供する場合、提供先の国における個人情報保護制度に関する情報を本人に提供した上で同意を取得することが必要です。また、相当措置（基準適合体制の整備）を根拠に移転する場合でも、定期的な確認と本人への情報提供義務が追加されました。
この規律は、外国のクラウドサービスを利用する場合にも関係します。クラウドベンダがサーバーに保存された個人データを取り扱わない契約になっており、適切なアクセス制御が行われていれば、外国にある第三者への提供には該当しないとされています。しかし、この場合でも安全管理措置としての外的環境の把握義務は発生します。つまり、サーバーが所在する外国の個人情報保護制度を調査し、それに応じた安全管理措置を講じる必要があるのです。
n8nをセルフホストし、サーバーの所在地を日本国内に固定すれば、こうした越境移転に関する複雑な対応の多くを回避できます。データの物理的な所在地が明確であることは、社内のコンプライアンス部門や法務部門にとっても判断がしやすく、管理コストの削減につながります。
金融・医療・自治体、厳格な業界ガイドラインへの適合
業界によっては、個人情報保護法よりもさらに厳格なガイドラインが存在します。
金融業界では、FISC（金融情報システムセンター）の安全対策基準がシステムの設計・運用に大きな影響を持ちます。データの保管場所やアクセス管理に関する詳細な要件が定められており、外部SaaSの利用には慎重な審査が求められます。
医療分野では、厚生労働省の医療情報システムの安全管理に関するガイドラインが、患者情報を含むデータの取り扱いに厳しい要件を課しています。データの国内保管やアクセスログの管理が重要な要素となります。
自治体においても、総務省のガイドラインに基づき、住民情報の外部保管には高いハードルがあります。三層分離モデルにより、インターネット接続系と業務系のネットワークが分離されている環境では、クラウドSaaSの導入自体が制約を受ける場合もあります。
こうした業界において、n8nセルフホストは自社環境内にすべてを閉じた運用が可能であるため、ガイドラインへの適合を示しやすくなります。
稟議が通る：外部SaaSへのデータ痕跡を残さない設計
技術的に優れたツールであっても、社内の承認プロセスを通過できなければ導入には至りません。特に大企業では、新しいSaaSを導入する際にセキュリティチェックシートの記入、ベンダーの第三者認証の確認、データフローの説明など、多くのプロセスが発生します。
外部SaaSを利用する場合、データがどの国のどのサーバーに保管されるのか、暗号化の方式は何か、ベンダーの従業員がデータにアクセスできるのか、といった質問に対して、ベンダーの公開情報をもとに回答しなければなりません。ベンダーのセキュリティポリシーが変更されれば、再審査が必要になることもあります。
セルフホストであれば、こうした審査プロセスが大幅にシンプルになります。データは自社のサーバーにあり、ネットワークの設計も自社のポリシーに従って管理されている、と説明できるからです。情報システム部門やセキュリティ部門にとって、自社でコントロール可能な環境は、リスク評価の観点からも承認しやすい選択肢です。
n8nセルフホストは甘くない、導入前に知っておくべき運用体制
セルフホストの利点を理解した上で、次に考えるべきは運用の現実です。セルフホストは自由度が高い反面、すべてを自社の責任で管理する必要があります。ここでは、どのようなエンジニアが必要で、具体的にどんな保守運用タスクが発生するのかを整理します。
結論：どんなエンジニアが必要か
n8nのセルフホスト運用に必要なのは、Linuxサーバーの基本的な運用経験を持つインフラエンジニアです。具体的には、以下のスキルセットを備えた人材が最低1名は必要になります。
DockerおよびDocker Composeを使ったコンテナ管理の実務経験。n8nの標準的なデプロイ方式はDockerベースであり、コンテナのビルド、起動、停止、ログ確認といった基本操作を日常的に行えることが前提です。
NginxやCaddyなどのリバースプロキシの設定経験。n8nを外部に公開する場合、SSL/TLSの終端処理やドメインの設定が必要です。
PostgreSQLの基本的な運用知識。n8nはデフォルトでSQLiteを使用しますが、本番環境ではPostgreSQLが推奨されています。バックアップの取得やリストア、基本的なクエリの実行ができる程度の知識が求められます。
加えて、ネットワークの基本（ファイアウォール設定、ポート管理、VPN構築）とSSH接続によるサーバー操作に慣れていることも必要です。
専任である必要はありませんが、兼任であっても週に数時間はn8n環境の状態確認やアップデート対応に時間を割ける体制が理想です。
まつインフラに明るい人材がいない組織の場合、後述するクラウド版をおすすめします。
インフラ管理（サーバー・Docker・リバースプロキシ）
セルフホストの基盤となるのは、サーバーインフラの管理です。n8nをDockerで運行する場合、docker-compose.ymlの設定管理が運用の中心になります。
サーバーのスペックは、小〜中規模（同時実行ワークフロー数が数十程度）であれば、2〜4コアCPU、4〜8GBのRAM、50GB以上のストレージが目安です。ローカルLLMを併用する場合は、GPUを搭載したサーバーが別途必要になるか、CPU推論に対応したモデルを選択することになります。
リバースプロキシは、n8nのWebインターフェースやWebhookエンドポイントをHTTPSで公開するために必要です。Let’s Encryptなどを利用したSSL証明書の自動更新設定も含めて、初期構築時にしっかりセットアップしておくことで、その後の運用負荷を下げられます。
アップデートとバージョン管理
n8nは活発に開発が進んでおり、頻繁にアップデートがリリースされます。新機能の追加やバグ修正だけでなく、セキュリティパッチも含まれるため、定期的なアップデートの適用は必須です。
Dockerベースの運用では、新しいバージョンのイメージをpullし、コンテナを再作成するという手順が基本です。ただし、メジャーバージョンアップの際にはデータベースのマイグレーションが発生することがあり、事前にバックアップを取得した上で、リリースノートを確認してから適用する慎重さが求められます。
本番環境とは別にステージング環境を用意し、アップデートの影響を事前に検証できる体制があると安心です。
バックアップとリストア
n8nのデータは主にデータベース（ワークフロー定義、認証情報、実行ログ）とファイルシステム（アップロードされたファイルなど）に保存されます。これらを定期的にバックアップする仕組みが必要です。
PostgreSQLを使用している場合、pg_dumpによる論理バックアップが一般的です。日次でのバックアップスケジュールを設定し、バックアップファイルは本番サーバーとは異なる場所（別のサーバーやオブジェクトストレージ）に保管します。
重要なのは、バックアップが実際にリストアできることを定期的に検証することです。バックアップを取っていても、リストア手順が確認されていなければ、障害時に復旧できない可能性があります。半年に1回程度はリストアのテストを実施することを推奨します。
監視・ログ・障害対応
n8nが正常に動作しているかを継続的に監視する仕組みも必要です。最低限、以下の項目を監視対象にします。
n8nのプロセスが稼働しているか（ヘルスチェック）、サーバーのCPU・メモリ・ディスク使用率、ワークフローの実行エラーの発生状況です。
n8nはエンタープライズ版ではDatadogなどの外部サービスへのログストリーミングに対応しています。コミュニティ版でも、Dockerのログ出力をfluentdやLokiなどのログ収集ツールに接続することで、集中的なログ管理が実現できます。
障害発生時の対応手順を事前に整備しておくことも重要です。n8nのプロセスが停止した場合の再起動手順、データベース接続エラーへの対処、ディスク容量不足への対応など、想定されるシナリオごとに手順をまとめておくと、障害時の復旧時間を短縮できます。
セキュリティ（認証・ネットワーク・暗号化）
セルフホスト環境のセキュリティは、すべて運用者の責任です。n8nはいくつかのセキュリティ機能を備えていますが、それを適切に設定・運用するのは自社のエンジニアです。
認証については、n8nはユーザーアカウントベースの認証を標準でサポートしています。エンタープライズ版ではSAMLやLDAPによるSSO（シングルサインオン）にも対応しており、既存の社内認証基盤と統合できます。
ネットワーク面では、n8nの管理画面へのアクセスをVPN経由に限定する、WebhookエンドポイントにはIPホワイトリストを適用する、といった対策が有効です。
データの暗号化については、n8nは認証情報（クレデンシャル）をN8N_ENCRYPTION_KEYという環境変数で指定した鍵を使って暗号化してデータベースに保存します。この鍵の管理は運用者の責任であり、鍵を紛失すると保存済みのクレデンシャルが復号できなくなります。ディスク全体の暗号化と合わせて、データの保護を多層的に実施することが推奨されます。
n8nクラウド版という選択肢、セルフホストが難しい場合の現実解
ここまでの内容を読んで、セルフホストの運用負荷は自社には重いと感じた方もいるかもしれません。その場合、n8nクラウド版は検討に値する選択肢です。ここでは、クラウド版がセルフホストと比べて何を肩代わりしてくれるのか、そしてどこに限界があるのかを客観的に整理します。
クラウド版で不要になる運用タスク
n8nクラウド版を選択した場合、前のセクションで挙げた保守運用タスクの多くが不要になります。
サーバーのプロビジョニングとインフラ管理は完全にn8n社が担当します。Docker環境の構築やリバースプロキシの設定、SSL証明書の管理も不要です。アップデートは自動的に適用され、リリースノートの確認や手動でのバージョンアップ作業は発生しません。
バックアップもn8n社が日次で自動実行しており、災害復旧のためのレプリケーション（同一国内の別リージョンへのバックアップ）も含まれています。監視やログ管理もn8n社のインフラチームが対応するため、自社側での対応は不要です。
つまり、前のセクションで述べた保守運用タスクのうち、インフラ管理、アップデート、バックアップ、監視のすべてをn8n社に委託できます。自社のエンジニアは、ワークフローの構築と業務ロジックの設計に集中できるようになります。
クラウド版のセキュリティとデータ保護
クラウド版を検討する際に最も気になるのは、データがどこに保管され、どのように保護されるかでしょう。
データの所在地とGDPR準拠
n8nクラウド版のデータは、Microsoft AzureのGermany West Centralリージョン（フランクフルト）に保存されます。EU域内でのホスティングであり、GDPRに準拠した運用がなされています。
ただし、現時点ではリージョンの選択はできません。日本国内にデータを置きたい場合、クラウド版ではその要件を満たすことができません。これは日本企業にとって重要な判断材料です。
改正個人情報保護法の観点では、EU（EEA）は日本と相互に十分性認定を行っている地域であるため、個人データの越境移転に関する規律の面では、他の外国と比較して対応がシンプルになります。ただし、安全管理措置としての外的環境の把握義務は引き続き必要です。
認証・アクセス制御・監査ログ
n8nクラウド版のセキュリティ対策は、n8n社のセキュリティページで公開されています。主な対策をまとめると、通信はSSL/TLSで暗号化され、保存データはAES256（FIPS 140-2準拠の実装）で暗号化されています。データベースはパブリックインターネットからアクセスできないプライベートネットワーク内に配置されています。
ビジネスプラン以上では、SAMLやLDAPによるSSO連携が可能です。エンタープライズプランでは、監査ログのストリーミングやロールベースのアクセス制御（RBAC）も利用できます。
クレデンシャル（外部サービスの認証情報）は、暗号化された状態でデータベースに保存されます。OAuth認可を利用する場合は、n8n社のOAuthアプリケーションを経由するため、その点は認識しておく必要があります。
クラウド版の限界：それでもセルフホストが必要なケース
n8nクラウド版は多くの企業にとって合理的な選択肢ですが、以下のケースではセルフホストが依然として必要です。
データを日本国内に物理的に置く必要がある場合
n8nクラウドのサーバーはEU（フランクフルト）にあり、日本リージョンは現時点で選択できません。国内データ保管が要件として定められている業界や企業では、この一点だけでクラウド版は選択肢から外れます。
完全閉域化が求められる場合
ローカルLLMと組み合わせてインターネット接続なしで運用したいケースでは、クラウド版は構造的に対応できません。
実行数やリソースの制限を避けたい場合
クラウド版にはプランごとに月間実行数の上限（Starterプランで2,500回、Proプランで10,000回など）があります。セルフホストのコミュニティ版では、実行数に制限はありません。
既存の社内認証基盤やネットワークポリシーとの統合が必要な場合
VPN経由のみでアクセスを許可したい、社内のActive Directoryと統合したい、といった要件がある場合、セルフホストの方が柔軟に対応できます。
逆に、これらの要件に該当しないのであれば、クラウド版は運用負荷とセキュリティのバランスが取れた選択肢です。セルフホストかクラウド版かは、自社の要件に照らし合わせて判断すべきものであり、どちらが優れているという話ではありません。
まとめ
n8nセルフホストは、ワークフロー情報・認証情報の自社管理からローカルLLMによる完全閉域化まで、段階的にデータ保護のレベルを選択できる自動化基盤です。改正個人情報保護法における越境移転規制や、金融・医療・自治体の業界ガイドラインへの対応においても、データの物理的所在地を自社に固定できる点が大きな強みになります。
一方で、Docker・PostgreSQL・リバースプロキシなどの運用スキルを持つエンジニアの確保が前提であり、インフラ管理・アップデート・バックアップ・監視・セキュリティの各領域で継続的な保守が必要です。
こうした運用体制の構築が難しい場合は、n8nクラウド版（EU・フランクフルトホスティング、GDPR準拠）も現実的な代替案となります。自社の要件に照らし合わせて、最適な運用形態を選択してください。
