Managed hosting vs self hostingには人件費の計上が必要

20個の小さなツールは、大きな計算能力を必要としないことがほとんどです。しかし、証明書の期限切れ、気づかないバックアップ失敗、ログインを壊す依存関係の更新、誰にも届かないアラートが起こる機会は20個分あります。月額サーバー料金だけの比較では、正しい答えになりません。

この規模では、スタッフの時間と中断を金額にすると、通常はマネージドホスティングのほうが安くなります。共通基盤をすでに規律をもって運用しており、管理権限やデータ所在地の要件が作業を正当化するなら、セルフホスティングが勝つ場合もあります。判断材料は2つの料金ページではなく、総所有コストです。

仮想マシンではなく稼働中のサービスを比べる

公平な比較単位は、ユーザーが利用でき、担当者が復旧できるサービスです。コードを起動できるだけの仮想マシンではありません。安いサーバー料金には、デプロイ後もアプリを使える状態に保つ仕事の多くが含まれません。

両方に同じ境界を設定します。ランタイム、データベース、永続ファイル、DNS、TLS終端、シークレット、ログ、メトリクス、アラート、バックアップ保存先、復旧手順、デプロイ、ロールバック、セキュリティ更新、障害対応の所有者を含めます。マネージドプランに含まれる項目は明記し、利用者に委ねられる項目はセルフホスティング側と同じく費用化します。

インフラ管理とアプリの所有責任は別です。マネージド事業者はホストを更新し、故障した機器を交換できます。しかし昨日のスキーマ移行で列が消えたか、AI生成の認可処理が誤っているかは判断できません。セルフホスティングではOS、ネットワーク、データベース、監視まで担当範囲が広がり、アプリ側の仕事も残ります。

AWSの責任共有モデルでも、IaaSの顧客はゲストOS、パッチ、アプリ、ファイアウォール設定を管理すると説明されています。大手事業者から仮想マシンを借りても、アプリがマネージドになるわけではありません。物理層だけを事業者が運用します。

最初に責任表を作り、各行に担当者または事業者と約束する対応を書きます。「自動」だけでは不十分です。自動処理が止まったときに気づく人まで必要です。

この表は、完成したサービスと空のサーバーを比較する誤りを防ぎます。DB復旧や時間外対応を顧客に残すプランも見つけられます。

中断時間を請求する費用モデルを使う

実用的なモデルでは、定期的な現金支出、計画作業、突発作業を分けます。楽観的な月額にまとめると、最も変動する部分が隠れます。

Annual cost = 12 x recurring monthly cash
            + planned engineering hours x loaded hourly rate
            + expected incident hours x loaded hourly rate
            + expected outage impact
            + one-time migration or platform work amortized over its useful life

現金支出には計算資源、DB、ストレージ、バックアップ、外向き通信、監視、ログ保持、DNS、有料証明書、サポートを含めます。計画作業にはリリース、パッチ、バックアップ確認、復旧訓練、アクセス審査、依存関係更新、容量変更、文書化を含めます。障害時間には診断、修理、復旧、連絡、再発防止を含めます。

手取り給与ではなく、会社負担を含む時間単価を使います。創業者が夜に作業しても費用はゼロではありません。その時間に失われた製品開発、営業、顧客対応の価値を使います。無料労働を前提にすると、セルフホスティングの表は簡単に嘘をつきます。

障害を正確に予測したふりはせず、平穏、通常、悪化の3ケースを作ります。平穏には定例更新と小さな障害、通常にはデプロイ失敗、復旧依頼、過剰な通知、緊急更新、悪化には長時間復旧や認証情報の漏えいを含めます。整った単一値より範囲が重要です。

これは例であり一般的な基準ではありません。自社のリリース頻度、当番履歴、復旧要件、時間単価で置き換えます。履歴がなければ幅を広く保ち、3か月後に見直します。

再利用基盤の固定費も必要です。初期構築費をアプリ数と利用年数に配分します。最初のツールだけに全額を載せず、20個すべてから消してもいけません。

20個のツールは計算資源より運用面を増やす

小さなアプリはCPUとメモリを共有できますが、ドメイン、シークレット、利用者、DBスキーマ、リリース周期、依存関係、復旧目標はそれぞれ残ります。1台で20コンテナを動かしても、運用面は20個分です。

1アプリ6分の手作業は全体で2時間です。四半期ごとの確認なら年8時間になります。調整、失敗、文書化を加えると、小さな作業ではなくなります。

集約は現金を減らす一方、障害範囲を広げます。カーネル更新、ディスク満杯、プロキシ設定ミス、認証情報紛失で20個すべてが止まります。ホストを分ければ共通障害は減りますが、料金とパッチ作業は増えます。マネージド基盤はこの仕事を多くの顧客で分担します。

ツールを、廃棄可能な試作、再生成可能なデータを持つ社内ツール、正本データを持つ業務ツール、外部向けサービスに分類します。各分類に標準ランタイム、バックアップ、監視、復旧目標、廃止規則を設定します。

ツールごとに仮想マシンを与える案は分かりやすいものの、パッチ、監視エージェント、証明書、設定、遊休資源を複製します。依存関係の衝突、機密性、異なる復旧目標など明確な理由がある場合だけ強い分離を使い、残りはコンテナや共通基盤に載せます。

逆に、すべてを未文書化のcomposeファイルに入れるのも見せかけの節約です。資源制限、名前付き永続ボリューム、ヘルスチェック、一貫したルーティング、データ所有者が必要です。なければ暴走したエクスポートがディスクを埋め、1アプリの不具合が全体停止になります。

廃止済みツールも数えます。AI支援で作成が安くなり、放置された試作が増えます。毎月、所有者、利用者、最近のデプロイがないサービスを調べます。使わないサービスの削除は、数円の最適化より確実にリスクと作業を減らします。

バックアップは復元が必要になるまで安く見える

バックアップとは、テスト済みの手順でサービスに戻せるコピーです。定期ジョブがファイルを送信しただけでは、コマンドが動いた証拠にしかなりません。

各分類に「編集を1営業日分まで失ってよく、4営業時間以内に戻す」のような言葉で損失と復旧時間を書きます。転送フォームと、顧客の正本を持つCRMでは許容値が異なります。

費用はコピー作成、保存、十分な履歴保持、復元証明の4つです。最後が多くの作業を占めます。訓練には空の復元先、認証情報、ダウンロード、DB起動、アプリ確認、復元状態の合否判断が必要です。

PostgreSQL文書は、論理オブジェクトとデータを戻すpg_dumpと、ベースバックアップとWALを組み合わせて時点復旧する継続アーカイブを区別します。WALはベースバックアップまで連続していなければなりません。両方を「日次バックアップ」と呼ぶと能力差が消えます。

小規模DBでは、1日分の損失を許せるなら暗号化dumpで足りる場合があります。ホスト外に複数世代を置き、鍵の所有者を記録し、実際に復元します。削除直前に戻る必要があれば、その機能を持つマネージドDBか、正しく運用したWALアーカイブが必要です。

service: inventory-tool
backup_object: inventory-tool/2026-07-12T020000Z.dump
restore_started: 09:14 UTC
restore_finished: 09:31 UTC
application_check: login, search, create and delete test record passed
recovery_point: 02:00 UTC
operator: initials

この記録で、使ったコピーと確認内容を証明できます。障害時に使えない可能性がある監視システム内だけでなく、運用文書と一緒に保管します。

マネージドバックアップでも、保持期間、地域、暗号化、エクスポート、削除、新DBを作るのか既存DBを上書きするのかを確認します。アップロードファイルとシークレットが含まれるかも確認します。仕組みは事業者が担当しても、方針選択と実復元は顧客の仕事です。

SSLと監視は所有者がいる自動化である

TLS証明書は無料でも作業を生みます。DNS、チャレンジ、プロキシ再読み込み、期限通知がすべて動く必要があります。

Let's Encryptは、短い有効期間が自動化を促すと説明しています。しかし「Let's Encryptを使う」は手順ではありません。ACMEクライアント、実行周期、チャレンジ方式、DNS権限、再読み込み、期限通知、失敗時の担当者まで書きます。

20ドメインを手動管理してはいけません。発行と更新を自動化し、ホスト外から結果を検査します。外部確認なら、ディスク上で更新済みなのにプロキシが未読込の証明書、DNSミス、サーバー停止も検出できます。

Prometheusは、利用者に影響する症状で通知し、行動できないページを避けるよう勧めています。CPU、メモリ、コンテナ、DB、プロキシのアラートをコピーすると、誰が困っているか分からない通知が大量に生まれます。

外部可用性、エラー率、遅延、ディスク容量、バックアップ鮮度、証明書期限から始めます。すぐに人が必要なときだけページし、容量や保守は日中のキューへ送ります。各アラートに所有者、短い診断経路、抑止方法が必要です。

監視自体も監視します。最低1つの検査と通知経路をホストの障害領域外に置きます。マネージド基盤が実際のアプリ経路を検査するか、通知が自社の対応要件に合うか確認します。

ログ保持も費用です。チャット生成ツールは冗長なリクエスト、警告、同じスタックトレースを書きがちです。用途別に期間を決め、シークレットと個人データを除外します。無期限保持は高価で危険、保持なしは最初の障害を長引かせます。

更新すると生成コードは自社のコードになる

AI生成ソフトを公開した時点で、保守責任は運用者に移ります。生成モデルはパッケージを更新せず、ランタイム更新を試験せず、半年後に消えた間接依存を説明しません。

OS、ベースイメージ、言語、フレームワーク、パッケージ、DB、プロキシ、監視、デプロイツールを費用化します。マネージド基盤はホストとランタイムを減らせても、アプリ依存は残ります。ソース出力は移行手段であり、自動運用ではありません。

依存関係の固定、少数の自動テスト、ヘルスエンドポイント、明示的なDB移行、既知の前リリースを標準契約にします。これがなければ、更新のたびに生成コードを発掘することになります。

定期保守枠を設け、低リスク更新をまとめ、イメージを再構築し、代表ツールで試してから同じ分類へ広げます。セキュリティ修正は速い経路を使います。サポート切れランタイムを一覧化します。

スナップショットとロールバックは復旧を速めますが、DB計画を置き換えません。破壊的移行後にコードだけ戻すと、古いコードが新しいスキーマを見ることがあります。フィールド追加、両状態対応コード、データ移行、後のリリースで旧フィールド削除という互換手順を使います。

計画モードがあれば、生成アプリを変える前に範囲、データ変更、影響部品を確認できます。Koder.aiは計画、デプロイ、ホスティング、独自ドメイン、スナップショット、ロールバックをまとめ、ソース出力も提供します。それでも公開した動作の責任は残るため、アプリ保守費は必要です。

デプロイコマンドの成功だけで更新完了にしません。ログイン、読み取り、書き込み、バックグラウンド処理、変更機能を確認します。目的のある5項目は、所有者のいない緑色のテストより役立ちます。

障害対応の請求は最悪の時に届く

障害費用には中断も含まれます。社内ツールの停止は経理を止め、20人を待たせ、誤りやすい表計算へ戻すことがあります。公開ツールは直接売上がなくても問い合わせを生みます。

セルフホストの例を追います。大きなエクスポートがボリュームを埋め、ディスク警告は古いメールへ届きます。夜に満杯となり、PostgreSQLと他のコンテナが書けなくなります。朝に容量を空けて再起動すると、不完全なDBファイルが見つかります。夜間dumpはありますが9か月復元しておらず、暗号鍵は退職した委託者の所有でした。

サーバー料金はほぼ変わりません。高いのは多層の診断、バックアップへの不安、影響を受けた人の時間、復旧、連絡、再発防止です。範囲によってマネージドサービスはディスクやDB問題を防げますが、悪いエクスポートや利用者連絡までは直しません。

時間外アラートの受信者、応答時間、DNS変更、復元、シークレット更新、状況連絡の権限、休暇時の代替を決めます。「開発者」と答えるなら、アクセス、文書、支払われる時間を確認します。

20ツールで24時間当番が必要とは限りませんが、サービス時間は明示します。翌営業日まで待てる社内ツールもあります。利用者へ伝え、アラートを合わせます。

障害後の恒久修正を正しい選択肢へ計上します。ディスク掃除、証明書修理、監視保守の繰り返しはセルフ側、事業者のデプロイ失敗や遅いサポートはマネージド側です。費用モデルは苦い経験を忘れてはいけません。

セルフホスティングが勝つには共通基盤と理由が要る

保守済み基盤、余剰運用能力、マネージド製品では満たしにくい要件があれば安くなります。仮想マシン1台が安いだけでは勝てません。

信頼できる計画には標準テンプレート、自動デプロイ、集中シークレット、外部監視、自動TLS、別保存先のバックアップ、復旧試験、パッチ所有者、資源制限、廃止手順があります。新ツールごとに新しい構成図が要るなら、共通基盤は固定費を回収していません。

データ所在地、ネットワーク分離、特殊ランタイム、予測可能な高利用、既存の規制境界は管理権限を正当化できます。その価値または必須条件を書きます。「管理したい」だけでは請求書と比較できません。

小チーム、不均一な利用、頻繁な作成と削除、運用担当不在ならマネージドが強い初期値です。制限、バックアップ、ログ、地域、独自ドメイン、ロールバック、エクスポート、サポート応答を確認します。

self_hosting_saving = managed_annual_cash - self_hosted_annual_cash
hours_available = self_hosting_saving / loaded_hourly_rate

年6,000ドル節約し時間単価が100ドルなら、年間60時間、月5時間で20ツールのパッチ、監視、バックアップ、復旧訓練、失敗、障害を処理します。この計算は勝者を決めませんが、無理な計画を見せます。

障害時間を倍にし、2人目を加え、3ツールに時点復旧を要求して感度を調べます。小さな仮定で答えが逆転するなら、安定した費用優位を主張せず、リスク許容度と管理要件で選びます。

90日間の運用試験で決める

最も説明しやすい判断は、自社で測った作業を使います。代表グループを90日運用し、すべての支出と作業を記録して20ツールへ投影します。

廃棄可能な試作、DB付き社内ツール、外部公開アプリを含めます。変更をデプロイし、証明書を更新し、空の環境へ復元し、1リリース戻し、シークレットを更新し、アラートを発生させ、1ツールを廃止します。平穏な稼働だけを測る試験では足りません。

作業時間と待機時間を分けます。ダウンロード中に別作業はできますが、15分の中断にも切替費用があります。両方に同じ規則を使います。

90日目に定例作業を年換算し、初期作業を分離し、3ケースを比較します。DNS復旧、地域配置、サポートエスカレーションなど未試験の責任は「不明」と記録します。

多くのチームでは、計算資源が最も小さな論点になります。追加料金が残る責任より多くのスタッフ時間を買うならマネージドが勝ち、再利用基盤が損益分岐以下に作業を保ち、管理権限に明確な目的があればセルフが勝ちます。

復元、パッチ、アラート、障害の横に担当者名が書かれるまで、安く見える計画を承認しないでください。サーバーは交換できます。確実な所有責任こそ不足します。