私は、社内向けの業務ツールやOSSを Proxmox 上に複数のVMとして構築し、必要なものを必要なだけ運用しています。このブログ自体も、レンタルサーバーではなく 自宅（自社）の回線＋自前サーバー から公開しています。
クラウドが当たり前になった今、あえてオンプレ寄りの選択をしている理由は単純です。業務用ツールやシステムは、一度課金し始めると“抜けられない沼”になりやすい。料金が上がっても簡単には移行できず、気づけば固定費が積み上がっていきます。
一方オンプレは、電気代やハードウェア代、保守の手間はかかりますが、手元のリソース範囲内で“使い放題”です。課金のメーターを気にせず試作でき、少人数運用でも現実的に回しやすい。私はこの「現実的に回ること」を最優先にしています。
なぜクラウドを「沼」と感じるのか
最初に誤解がないように書いておくと、私はクラウド自体を否定していません。必要なサービスには課金しています。ただ、業務ツールのように「日常運用の中核」に入ってくるほど、クラウドはこうなりがちです。
- 便利さに比例して固定費が増える（インスタンス、ストレージ、バックアップ、監視、転送量など）
- 構成が積み上がるほど移行が難しくなる（依存関係、認証、ネットワーク、権限設計、運用手順）
- 料金改定の影響を避けづらい（「代替に移れない」状態になりやすい）
特に業務ツールは「慣れ」が強いです。一度業務フローに入ると、移行は技術課題というより組織の摩擦になります。だからこそ私は、次の方針を基本にしています。
- 握るべきもの（業務の核）はオンプレで自前運用
- 外部に置く価値が高いもの（入口・バックアップ・一部SaaS）だけ課金
「全部クラウド」「全部オンプレ」ではなく、ハイブリッドで現実解を取る、という考え方です。
自宅回線で公開する難しさ：アクセス数が少なくても関係ない
自宅回線でWebサーバーを公開する場合、アクセス数が少なくても関係ありません。公開した瞬間から“見つけに来る”トラフィックは常に存在します。
- グローバルに晒した瞬間から 常時スキャン は飛んでくる
- CMSや管理画面は 攻撃対象として分かりやすい
- 「小さいサイトだから狙われない」は基本的に期待しない方が良い
つまり、オンプレ公開は「作る」より守る・更新する・戻すが本体です。ここを舐めると普通に事故ります。
私の基本構成：VPSを“入口”、自宅サーバーは“奥”に置く
私が採っている設計は、イメージとしては VPSが玄関、自宅サーバーが奥の部屋です。外部からの入口を一箇所に寄せ、奥は極力見せない。
構成イメージ（概念）
インターネット | | (HTTPS) v VPS（リバースプロキシ / 入口） | | (許可した経路のみ) v 自宅回線（動的IP） → 自宅サーバー（Proxmox上のWeb VM 等）
- VPS（外側）：公開の入口、TLS終端、必要ならアクセス制御・ログ集約
- 自宅サーバー（内側）：Web/業務ツール本体（原則、直接触らせない）
自宅側はファイアウォールでVPSのIPからの通信のみ許可し、それ以外は原則遮断という考え方に寄せています。これだけでも「無差別に殴りに来る系」のノイズはかなり減ります。
動的グローバルIP問題：ネットボランチDNS（DDNS）で吸収する
自宅回線は多くの場合、グローバルIPが固定ではなく変わります（動的IP）。このまま運用すると、VPSから自宅へ繋ぐ先が変わってしまい「辿れない」問題が起きます。
そこで使うのが DDNS（Dynamic DNS） です。難しく言うとDDNSですが、感覚としてはこうです。
自宅の“住所（IP）”が変わっても、同じ“名前（ホスト名）”で追いかけられる仕組み
Yamahaルーターを使っている場合、ネットボランチDNSはその代表例です。VPS側は固定IPではなく、固定のホスト名で自宅側へ接続できるようになります。これで「自宅回線の弱点（動的IP）」を運用で吸収します。
重要：セキュリティは“これだけ”では足りない（完璧はない）
リバースプロキシ＋IP制限は「入口の守り」として有効ですが、それだけで安全になった気になるのは危険です。セキュリティは多層（レイヤー）で積むもので、しかも完璧はありません。
私も「これで完成」という感覚はなく、足りないところは必ずあると思っています。だからこそ、優先順位をつけてできる対策から積み上げ、改善し続ける運用にしています。
私が意識している“多層”の考え方（例）
- 露出面を最小化：公開するサービス・ポートを絞る／管理画面は原則外に出さない
- 入口対策：VPSでTLS・リバースプロキシ／必要なら国・UA・レート制限など
- 認証：強いパスワード、2FA、鍵運用、管理パスの保護
- 更新：OS・ミドルウェア・アプリを「溜めずに」更新する仕組み（通知含む）
- 監視：ログ、失敗ログイン、異常トラフィック、ディスク逼迫などを検知できる状態
- 復旧：バックアップと復元手順（手順書レベルで）
特に「更新」と「復旧」は軽視されがちですが、公開運用ではここが最後の生命線です。
いちばん安全なのは「外部に公開しない」設計
これは結論として明確です。どれだけ対策しても、公開している限り「狙われる前提」から逃げられません。可能なら、次の順に安全性が上がります。
- 社内LAN内だけで完結（外部公開しない）
- 外から使う必要がある場合は VPN経由（“入口を一つにする”）
- どうしても必要なものだけを 最小限に公開（公開対象を絞る）
私も、業務システムや社内ツールは「外に出さない」が基本方針です。公開が必要なものだけをVPSの入口で受け、奥は見せない。この発想が、少人数運用ではいちばん効きます。
「公開しない運用」の具体例：いちばん安全で、しかも運用がラク
外部公開を前提にすると、どうしても「攻撃される前提」で設計・更新・監視・復旧まで考える必要が出てきます。逆に言うと、公開しないだけで、セキュリティ難易度は一気に下がり、少人数運用でも安定させやすくなります。
ここでは、私が現実的だと思う「公開しない（＝インターネットに晒さない）」運用パターンを、目的別にまとめます。
パターン1：社内LAN限定（外からは一切入れない）
最強にシンプルで安全です。社内のPC・タブレット・スマホ（社内Wi-Fi接続時）だけが使える状態にします。
- 業務ツール（在庫、工程、原価、帳票、社内Wikiなど）を 社内IPのみ に限定
- ルーターで ポート開放を一切しない
- サーバー側もファイアウォールで LANセグメント以外を拒否
これだけで「外から殴られる」問題が消えます。現場主体の業務なら、まずこの形が一番現実的です。
パターン2：VPN経由だけ許可（外から使う人がいる場合の現実解）
社外から使う必要がある場合でも、Webを直接公開するのではなく、VPNで社内ネットワークに入ってから使う形にします。
- 社外アクセスは VPNで1か所に集約（入口を一つにする）
- 業務ツールは社内IPでしか開かないまま（公開しない）
- ログや接続履歴もVPN側で取りやすい
ポイント：VPNを入れるなら、社内ツール側は「VPN接続時しか見えない」状態のままにしておくと、設計が一気にラクになります。
パターン3：管理画面やバックエンドは“LAN限定”、公開するのはフロントだけ
Webサイトなど「外に見せたいもの」があっても、管理画面まで公開する必要はありません。
- WordPress等の 管理画面（wp-admin） はLAN限定
- 外部からは記事閲覧だけできる状態にする
- 更新作業は社内Wi-Fi or VPN接続時のみ可能にする
これだけで管理画面への攻撃リスクを大きく減らせます。「公開するもの」と「公開しないもの」を分ける発想です。
パターン4：SSHや管理系ポートは「公開しない」＋踏み台/VPNに寄せる
運用でありがちなのが「メンテのためにSSHを開けっぱなし」。SSHは特にスキャンされやすく、攻撃も多い入口です。
- SSHは LAN限定（またはVPN接続時のみ）
- 外から管理するなら 踏み台（VPS） or VPNに一本化
- どうしても開けるなら 接続元IPを固定で絞る（ただし基本は非推奨）
管理系は「入口を増やさない」ほど強くなります。
パターン5：機器・現場デバイス（ESP32等）は“現場ローカルのみ”で完結させる
現場機器は、特に「公開しない」が効きます。設定・閲覧は現場LAN内だけで完結させ、外へは必要最小限だけ送る設計にします。
- 設定画面は 現場LAN内だけ（HTTPでも可）
- 外に見せる必要があるデータだけを 外部のDB/APIへ送る（送信方向だけ）
- 外部から現場機器へ直接アクセスできない設計にする
「外から取りに行く」より「中から送り出す」方が安全設計にしやすいです。
パターン6：ゼロトラスト系（アプリ単位で“見せる”）を使う
VPNを張るほどでもないが外部から限定的に使いたい場合は、アプリ単位で公開する方式も選択肢になります。
- ネットワーク全体を開けず、必要なアプリだけにアクセスさせる
- 認証（SSO/2FA）を前提にできる
- 公開範囲を最小化できる
ただし、サービス選定や運用設計の相性があるので、「何をどこまで外に見せたいか」が明確な場合に検討するのが良いです。
結論：公開しない運用は「攻撃されない」だけでなく「運用コストが下がる」
- 監視や防御の負担が減り、運用が軽くなる
- 更新や検証がしやすくなり、改善が回る
- 少人数でも「回る仕組み」になりやすい
公開は最後の手段で、必要最小限に絞る。それが結果として一番強いと思っています。
VM・Docker・Kubernetes（K8s）…結局どれが現実解か
仮想化やコンテナ基盤は選択肢が多いですが、流行りよりも運用者の体力と保守性で選ぶのが現実的です。私の整理は次の通りです。
VM（Proxmoxなど）：境界が強い、切り分けがしやすい
- OSごと分離でき、役割分担が明確
- 依存関係が壊れても「VM単位で戻す・捨てる」ができる
- ネットワーク分離や権限分離の設計がしやすい
- 一方で、OS管理（更新など）はVMの数だけ増える
Docker：立ち上げが速い、試作がとにかく早い
- 「とりあえず動かす」が最速で、検証や試作に強い
- composeで再現性を持たせやすい
- 一方で、永続データ（Volume）、更新互換性、ネットワーク公開などで運用が複雑化する瞬間がある
私は「検証・試作はDocker、本番はVM寄り」に倒しがちです。少人数運用では“切り分けやすさ”が正義になりやすいからです。
Kubernetes（K8s）：強力だが、小規模では過剰になりやすい
- 本来は多数コンテナをスケールさせるための仕組みで、設計も運用も“組織で回す”寄り
- 学習コスト・運用コストが重く、障害時に復旧が遅くなるリスクもある
必要な要件があるなら強い。ただ、少人数運用では「強さ」がそのまま「重さ」になり得るので、使いどころが明確な時だけ採用が安全です。
Proxmoxのクラスタ化は強力。ただしネットワーク設計の難易度が一段上がる
Proxmoxにはクラスタ化という強力な拡張ルートがあります。うまく設計できれば運用の自由度が上がります。
- 複数ノードの管理が統合される
- VM移動（ライブマイグレーション）がやりやすくなる
- 構成次第でHA（高可用）も視野に入る
- ノード増設で段階的にスケールできる
ただし、ここから先は「サーバー」だけではなくネットワークが主役になります。ネットワークが弱いとクラスタは途端に不安定になり得ます。
クラスタ化で要求される“ネットワークの筋力”（例）
- クラスタ通信の品質（遅延・パケットロスの少なさ）
- 管理系・ストレージ系・VMトラフィックの分離（VLANや物理NICの分離）
- スイッチや配線の信頼性（ここがボトルネックになりやすい）
- クォーラム（多数決）問題の理解（特に2台構成は割れやすい）
- 分散ストレージ等を絡めるなら帯域要件がさらに上がる
小規模運用では、まず単体構成で復旧できる／バックアップが回るところを固め、必要性が固まった段階でクラスタ化とネットワーク強化を検討する、という順番が現実的だと思っています。
オンプレ最大の弱点：天災・故障リスク。だからバックアップ設計が本体
オンプレの弱点は、物理で壊れることです。落雷、停電、浸水、火災、機器故障。クラウドのように「別ゾーンへ逃げる」が最初から用意されているわけではありません。
だからこそ、オンプレでやるならバックアップの設計が本体です。私が意識している方向性は次の通りです。
- ローカル：スナップショット／世代管理（戻せる状態を作る）
- 別媒体：外付けや別筐体へコピー（可能なら自動化）
- オフサイト：自宅以外へ重要データだけ退避（VPS/遠隔/物理退避）
そして最重要なのは、「バックアップがある」ではなく「復元できる」ことです。復元手順が曖昧なままだと、いざという時に時間だけが溶けます。
まとめ：課金すべきところは課金し、握るべきところは握る
- クラウドは便利。ただし業務の中核を寄せすぎると抜けられない沼になりやすい
- オンプレは電気代や保守の手間があるが、手元の範囲で使い放題という強烈な自由がある
- 公開する以上、セキュリティは多層で積む。そして完璧はない前提で改善を続ける
- 最も安全なのは、そもそも外部に公開しない設計（社内限定／VPN）
- オンプレ運用の最後の要は、バックアップと復元性
オンプレでいろいろ立てると、クラウドでは費用が膨らみがちなことも、現実的なコストで回せることがあります。万能ではありませんが、選択肢として「こういう運用もできる」ということが伝われば、判断材料になるはずです。
コメント