総合評価③ 長期メンテ・運用・ベンダーロックイン
📖 このページのゴール：5つの選択肢を「作ったあと、ずっと面倒を見続ける手間」で横並びに比べる。日々の運用、バージョン上げ、夜中の障害対応、そして「抜け出しにくさ（ロックイン）」まで。最後に行き着く結論は——技術の優劣より「運用に何人割けるか」で決まることが多い、です。 ← 目次・はじめにへもどる
アプリは「作って終わり」ではありません。動かし続けるあいだ、ずっと面倒を見る必要があります。家にたとえると、建てた瞬間からが本番。屋根の修繕、配管の点検、設備の入れ替え——住んでいる限りずっと続きます。このページは、その「住み続けるコスト」を5つの選択肢で比べます。
🔧 日々の運用って、具体的に何をするの？
「運用」と言われてもピンと来ないので、まず中身をほどきます。アプリを動かし続けるには、ざっくり次のような仕事がずっと発生します。
| 運用の仕事 | どういうこと？ | たとえ（家） |
|---|---|---|
| パッチ当て | OS やミドルウェア（DB・Webサーバー）の修正を当て直す | 設備の不具合を直す・部品交換 |
| EOL 対応 | EOL（イー・オー・エル＝End of Life／提供終了）でサポートが切れる前に、新しいバージョンへ上げる | 製造終了した設備を、壊れる前に新型へ入れ替え |
| 監視 | 動いているか・遅くないか・容量は足りるかを見張る | ガス漏れ・水漏れの警報器 |
| 障害対応 | 落ちた・遅い・つながらない、を調べて直す | 急な水漏れに駆けつける |
| オンコール当番 | 障害は深夜・休日も来るので、誰かが待機して呼ばれたら起きる | 真夜中の警報で飛び起きる当番 |
🟢 ポイントは EOL。ソフトには「サポート終了日」があり、放っておくと自動で古くなる。期限が来る前にバージョンを上げないと、セキュリティの穴が放置されたり、ある日急に動かなくなったりします。作ったまま放置はできない、というのが運用のいちばんの実感です。
🧩 任せるほど、運用は楽になる
ここで背骨の「はしご」が効いてきます。上に行く（任せる）ほど、上に挙げた仕事をクラウドが肩代わりしてくれます。
オンプレ ＞ IaaS ＞ コンテナ ＞ PaaS ＞ サーバーレス/BaaS
（運用は全部自分）──────────────→（更新も監視もお任せ・楽）
- オンプレ / IaaS：OS のパッチも、ミドルの更新も、EOL での入れ替えも、監視も当番も全部自分。借りた「土地」や「箱」の中身は、住人（あなた）が面倒を見ます。
- コンテナ（マネージド）：箱の外側（土台・OS）はクラウドが面倒を見てくれることが多い。ただし箱の中身（アプリと同梱した道具）の更新は自分。
- PaaS / サーバーレス・BaaS：OS もミドルもランタイムもクラウドが勝手に更新。あなたはコードとデータに集中。夜中に起きる当番も、土台の部分はクラウド側が持ちます。
| 選択肢 | OS の更新 | ミドル/ランタイムの更新 | だれが夜中に起きる？ |
|---|---|---|---|
| オンプレ | 👤 自分 | 👤 自分 | 👤 自分（全部） |
| IaaS | 👤 自分 | 👤 自分 | 👤 自分（土台から） |
| コンテナ | ☁ だいたいクラウド | 👤 自分（箱の中） | 👤＋☁ 分担 |
| PaaS | ☁ クラウド | ☁ クラウド | ☁ 土台はクラウド／👤 アプリは自分 |
| サーバーレス/BaaS | ☁ クラウド | ☁ クラウド | ☁ 土台はクラウド／👤 自分のコードは自分 |
🔧 ただしどこまで任せても、自分のアプリのコードとデータは自分の責任。「うちのアプリのバグで落ちた」「設定を間違えた」は、サーバーレスでもあなたが対応します。クラウドが面倒を見るのはあくまで土台まで、と覚えておきましょう。
🔧 ベンダーロックインって何？
ベンダーロックイン（vendor lock-in）とは、特定のサービスに深く依存してしまい、あとで別のところへ引っ越す（移行する）のがすごく大変になること。「ロック（鍵）」で「イン（中に閉じ込められる）」イメージです。
たとえると、専用の道具に慣れきってしまった状態。ある会社の独自レール・独自ネジで家具を組んでしまうと、引っ越し先で同じものが使えず、全部バラして組み直しになります。便利な専用ツールほど、手放すときの痛みも大きい——これがロックインです。
なぜ「任せる」ほどロックインが強くなるのか：
- PaaS / BaaS は「独自のやり方」が多い：そのサービス専用の API（命令の作法） や、独自のデータベースを使います。たとえば Firebase の Firestore は Firebase 独自。他社には同じものが無いので、引っ越すには作り直しが要ります。
- コンテナや標準技術はロックインが緩い：Docker の箱は「どの台所でも同じ味」が売り。箱ごと別のクラウドへ持っていけます。データベースも、PostgreSQL（ポストグレス） のようなみんなが使う標準なら、他社にも同じものがあり、引っ越しやすい。
- だから「移行しやすさ」は技術の選び方で変わる：同じ「楽さ」でも、独自API漬けなら抜けにくく、標準技術を選んでおくと将来の逃げ道が残ります。
| 選択肢 | ロックインの強さ | なぜ？ |
|---|---|---|
| オンプレ | 弱 | 自前なので、別のどこへでも持っていける（その代わり全部自分） |
| IaaS | 弱〜中 | サーバーの中身は標準技術なら移しやすい。各社の周辺サービスに頼ると中くらいに |
| コンテナ | 中（緩め） | 箱ごと運べるので比較的逃げやすい。標準が効く |
| PaaS | 中〜強 | 独自の作法・専用の周辺機能に馴染むほど抜けにくい |
| サーバーレス/BaaS | 強 | 独自API・独自DBに深く依存。便利な分、引っ越しは作り直しに近い |
🟢 ロックインは「悪」ではありません。スピードと引き換えです。「今は速さが命、移行は将来そのとき考える」と割り切るのも、立派な戦略。大事なのは、割り切っていると自覚した上で選ぶことです。
🔧 移行コストの現実
「いざとなったら引っ越せばいい」と思いがちですが、現実の引っ越し（移行）は思った以上に重いです。
- 独自API・独自DBに合わせて書いたコードは、移行先のやり方に丸ごと書き直し。
- 動いている本番を止めずにデータを移す段取りが要る。
- 「今のままで困っていない」ので、移行はいつも後回しになり、依存はさらに深まる。
🔧 だからこそ「最初の選択」が効きます。標準技術（PostgreSQL・Docker など）を土台に選んでおくと、将来の引っ越し代が安くなる「保険」になります。
🧩 チーム規模との釣り合い（ここが本丸）
運用の話は、結局「運用に何人割けるか」に行き着きます。割ける人数で、向く選択肢が変わるのです。
| 運用に割ける人数 | 向いている方針 | 理由 |
|---|---|---|
| 0〜1人（少人数・個人） | 任せるが正義（PaaS / サーバーレス / BaaS） | 当番を回せない。夜中の障害をクラウドに肩代わりしてもらう。作ることに集中 |
| 数人（中堅ベンチャー） | IaaS＋マネージドコンテナ＋一部PaaS | 少人数の運用担当（SRE）で、自前と委任のいいとこ取り。コスト最適化も効き始める |
| 大規模チーム | オンプレ/IaaS＋マネージドKubernetes も選べる | 自前で握って細かく最適化する価値が、人数で回収できる。規制対応の体力もある |
🟢 ざっくり言うと——少人数ほど「任せる」、大規模ほど「自前で最適化」。これは「持ち家 vs 賃貸」の選び方に似ています。自分で修繕できる人手と腕があるなら持ち家（自前）、忙しくて手が回らないなら大家さんに任せる賃貸（マネージド）。どちらが偉いという話ではなく、手持ちの人手しだいです。
📊 運用・ロックイン早見表
5つの選択肢を「運用の手触り」でまとめると、こうなります。
| 選択肢 | 運用負荷 | 更新の手間（OS/ミドル） | ロックインの強さ | 移行しやすさ |
|---|---|---|---|---|
| オンプレ | 最大 | 全部自分 | 弱 | しやすい（でも自前が重い） |
| IaaS | 大 | 自分 | 弱〜中 | しやすい〜ふつう |
| コンテナ | 中 | 箱の中だけ自分 | 中（緩め） | しやすい（箱ごと運べる） |
| PaaS | 小 | お任せ | 中〜強 | ややしにくい |
| サーバーレス/BaaS | 最小 | お任せ | 強 | しにくい（作り直しに近い） |
読み取り方：
- 左へ行くほど（オンプレ寄り）：運用は重いが、抜け出しやすい（自由）。
- 右へ行くほど（サーバーレス寄り）：運用は楽だが、抜け出しにくい（依存）。
- 「楽さ」と「抜けやすさ」は逆向き——ここが運用評価のいちばんの勘どころです。
🔧 コンテナが「中くらいで、緩め」の良いポジションにいるのが分かります。そこそこ任せつつ、箱ごと運べる逃げ道も残す——だから中堅以上で人気なのです。
📝 ことばメモ
- EOL（イー・オー・エル／提供終了）：そのOS・ソフトのサポートが終わる日。来る前に新しい版へ上げる必要がある。
- オンコール当番：障害に備えて待機し、呼ばれたら（深夜でも）起きて対応する役割。
- ベンダーロックイン：特定サービスに深く依存し、他へ引っ越しにくくなること。独自API・独自DBほど強い。
- 移行（マイグレーション）：別のサービス・基盤へ引っ越すこと。思った以上に重い作業。
- 標準技術：みんなが広く使う共通の技術（PostgreSQL／Docker など）。どこにでもあるので逃げ道になる。
- マネージド：クラウドが運用（更新・監視・障害対応）を肩代わりしてくれる形。
🟢 ひとことで言うと
長期メンテは「作ったあと、ずっと面倒を見続ける手間」の勝負。任せる（右）ほど運用は楽になり、自前（左）ほど自由で抜けやすい——この2つは逆向きです。BaaS/PaaS は独自API・独自DBでロックインが強め、コンテナや PostgreSQL などの標準技術は緩め。そして最後は技術の優劣より「運用に何人割けるか」で決まることが多い。少人数は“任せる”が正義、大規模は自前で最適化が効く、と覚えておけば十分です。