クラウドインフラ保守を任せる開発会社のチェックリスト｜監視・バックアップ・コスト可視化

クラウドインフラの導入は、物理サーバーの管理から解放される一方で、ソフトウェア定義のインフラ（IaC）を適切に「維持」し続けるという新たな課題を生みます。多くの企業が開発会社に保守を委託しますが、その内容は「サーバーが動いていることの確認」に留まり、潜在的なセキュリティリスクや無駄なクラウドコストを見過ごしているケースが少なくありません。

本記事では、AWSやGCPなどのクラウドインフラ保守を外部委託する際に、発注側が必ず確認すべき「監視・バックアップ・コスト・セキュリティ」のチェックリストを実務レベルで解説します。

クラウドインフラ保守における「失敗しない」外注の前提条件

まず理解すべきは、クラウド事業者が提供する「マネージドサービス」を利用していても、その上の設定やOS、ミドルウェアの責任はユーザー（および委託先）にあるという点です。

保守と運用の定義：なぜ「作って終わり」が通用しないのか

アプリケーションをリリースした瞬間から、インフラは「劣化」を始めます。ここで言う劣化とは、ハードウェアの故障ではなく、脆弱性の発見、ミドルウェアのサポート終了（EOL）、アクセス増によるリソース枯渇などを指します。保守を「現状維持」と捉えるのではなく、システムの健全性を継続的にアップデートする「運用」として定義する必要があります。

責任分界点（Shared Responsibility Model）の明確化

クラウド各社が提唱する「責任分界点モデル」をベースに、開発会社との契約範囲を明確にする必要があります。例えば、AWSの場合、データセンターの物理的保護はAWSの責任ですが、EC2上のOSパッチ適用や、S3のバケットポリシー設定ミスによる情報漏洩はユーザーの責任です。これらを「開発会社がどこまでカバーするか」を定義書に落とし込まなければなりません。

こうしたインフラの健全性は、バックオフィス業務の自動化やデータ連携においても土台となります。例えば、経理業務の自動化において、インフラの停止は業務そのものの停止を意味します。
楽楽精算×freee会計の「CSV手作業」を滅ぼす。経理の完全自動化のような高度な連携を実現する場合、APIが安定して動作し続けるためのインフラ保守が不可欠です。

監視設計のチェックリスト：死活監視からオブザーバビリティまで

「監視をしています」という報告だけでは不十分です。何を、どのような閾値で、どこに通知しているかを確認してください。

最低限必要な3つの監視レイヤー

• 外勤監視（死活監視）: 外部からHTTP/HTTPSリクエストを送り、システムが応答するかを確認。
• リソース監視: CPU使用率、メモリ空き容量、ディスクI/O、ネットワーク帯域の監視。
• ログ監視: アプリケーションエラー（5xx系エラー）や不審なログイン試行の検知。

通知設計：ノイズを減らし、重要アラートを埋もれさせない

よくある失敗は、些細なアラートをすべてメールやSlackに飛ばし、重要な通知が埋もれてしまうことです。開発会社には以下の運用を求めてください。

• 重要度別の通知先選別: Critical（即時対応）とWarning（日中確認）の分離。
• 自動復旧の実装: CPU負荷が高い場合に自動でインスタンスを増やす（オートスケーリング）や、プロセスを再起動する仕組み。

主要な監視ツールの比較と選定基準

開発会社がどのツールを使用しているか確認しましょう。以下は実務でよく使われるツールの比較です。

バックアップとDR（災害復旧）のチェックリスト

「バックアップを取っている」という言葉を鵜呑みにしてはいけません。復旧できないバックアップは無価値です。

RTO（目標復旧時間）とRPO（目標復旧時点）の合意

以下の2点を開発会社と定義してください。

• RPO (Recovery Point Objective): 「いつの時点の状態に戻すか」。例：1時間前のデータまで戻せれば良いのか、1秒前か。
• RTO (Recovery Time Objective): 「復旧までに何時間かけるか」。例：障害発生から3時間以内にサービスを再開する。

バックアップの「3-2-1ルール」とクラウドでの実践

クラウド時代でも基本は変わりません。3つのデータコピー、2つの異なるメディア、1つのオフサイト保管。AWSであれば、同一リージョン内のSnapshotだけでなく、別リージョン（東京から大阪など）へのレプリケーションを検討すべきです。

リストア（復元）テストの実施頻度

保守項目の中に「年に1〜2回のリストア試験」が含まれているか確認してください。手順書が古く、いざという時に復旧できないリスクを排除するためです。

クラウドコスト可視化と最適化のチェックリスト

インフラ保守の重要な役割の一つに「コスト管理」があります。使っていないリソースに課金され続ける状態を防がなければなりません。

不要なコストを削ぎ落とす考え方は、インフラに限らずSaaS全体の管理にも通じます。
SaaSコストとオンプレ負債を断つ。バックオフィス＆インフラの「標的」と現実的剥がし方で解説されているように、無駄なリソースを特定し、契約を最適化するプロセスを保守に組み込みましょう。

コスト増大を招く3つの主要因

1. 未使用リソース: 開発環境の消し忘れ、アタッチされていないストレージ（EBSボリューム）。
2. オーバープロビジョニング: 必要以上に高いスペックのインスタンス選定。
3. データ転送量: 想定外のログ出力や、外部通信による課金。

開発会社に求めるべき「コスト削減提案」の内容

保守レポートに以下の項目が含まれているか確認してください。

• リザーブドインスタンス（RI）/ Savings Plansの適用提案: 継続利用が確実なリソースの予約購入による割引。
• 最新世代への移行: AWSのGravitonプロセッサ搭載インスタンスへの変更など、コストパフォーマンスが高い新技術への切り替え提案。

セキュリティ保守と脆弱性対策のチェックリスト

セキュリティは「一度設定すれば終わり」ではありません。攻撃手法は日々進化しています。

OS・ミドルウェアのパッチ管理サイクル

「緊急度の高いパッチ（CVEのスコアが高いもの）」が出た際、どのようなリードタイムで適用するか。また、その際のサービス停止の有無を確認してください。

IAM（アイデンティティ管理）の最小権限原則

開発会社のエンジニアに「AdministratorAccess」などの全権限を常時渡してはいませんか？ 必要な時に必要な権限のみを付与する、あるいは特定のIPアドレスからのみアクセスを許可するなどの制限が必要です。退職者のアカウント削除漏れも深刻なリスクになります。
SaaS増えすぎ問題と退職者のアカウント削除漏れを防ぐ。自動化アーキテクチャを参考に、ID管理の自動化を検討する価値があります。

開発会社選定・契約時に確認すべき運用体制

最後に、契約書やSLA（サービス品質保証）に盛り込むべき実務的な項目を整理します。

SLA（サービス品質保証）の現実的なライン

「稼働率99.9%」などの数値だけでなく、以下の具体的な対応時間を定義します。

• 初報時間: 障害検知から何分以内に連絡があるか。
• 目標復旧時間: 重大障害発生時の目安。

ただし、厳しすぎるSLAは保守費用の高騰を招くため、事業への影響度に合わせて調整してください。

保守費用（月額）の相場と内訳の妥当性

一般的な保守費用の相場は、開発費の10%〜20%/年、あるいは月額固定（例：5万〜30万円＋インフラ実費）ですが、以下の作業が含まれているか内訳を確認してください。

• 月次レポート作成: 稼働状況、コスト推移、今後の課題の報告。
• 定例会議: 運用上の改善点（パフォーマンスチューニング等）の提案。
• 小規模設定変更: セキュリティグループの変更など、軽微な作業の包含。

まとめ：自社でコントロールを失わないための「インフラ保守」

クラウドインフラの保守を開発会社に丸投げすることは、自社のビジネスの命綱を他者に握らせることと同義です。本記事で紹介したチェックリストを活用し、開発会社と「攻め」の運用体制を構築してください。特に、可視化と自動化をキーワードにインフラを整備することで、長期的なコスト削減とセキュリティの向上が実現できます。