業務システムの基盤をクラウドに移す際、IaaS・PaaS・SaaSの違いを曖昧にしたまま契約を進めてしまうプロジェクトが見られます。
この記事は、既存の社内システムをクラウド化・再構築する立場のエンジニアやPMに向けて、サービスモデルの選び間違いがどんな形で保守の重荷になるかを整理するものです。
結論を先に言うと、問題は技術選定そのものではなく「誰が何を管理し続けるのか」を合意しないまま進めることにあります。
何が起きるか：管理責任の境界があいまいになる
クラウドサービスには大きく3つの提供形態があります。
IaaS（Infrastructure as a Service、サーバーやネットワークなどインフラ部分だけを借りる形態）、PaaS（Platform as a Service、OSやミドルウェアまで用意された開発・実行環境を借りる形態）、SaaS（Software as a Service、完成済みのソフトウェアをそのまま使う形態）です。
たとえばAWSのEC2やAzure VMはIaaS、HerokuやGoogle App EngineはPaaS、Microsoft 365やSlackはSaaSに分類されます。
この3つは「自分たちで何を管理するか」の範囲が全く違います。
IaaSを選ぶとOS・ミドルウェア・ランタイムの保守は自社の責任になりますが、SaaSならアプリケーションもデータも提供側が面倒を見ます。
現場で起きがちなのは、初期構築時に「とりあえず動かしたいからIaaSで」と決めたものの、運用フェーズに入ってからOSパッチ適用やミドルウェアのバージョンアップが放置される事態です。
基幹システムの一部だけIaaS上に残り、他はSaaS化が進んだ結果、誰がどこまで責任を持つのかチーム内で説明できなくなっているケースも珍しくありません。
影響範囲は保守コストだけに留まりません。
セキュリティパッチの適用漏れ、障害時の切り分けの遅れ、監査対応での「このサーバーの管理者は誰か」という問いに即答できない状況にもつながります。
なぜ起きるか：契約時の判断基準が技術選定に偏っている
原因を段階的に見ていきます。
第一に、初期検討で「速く動かせるか」「コストが安いか」だけが評価軸になり、長期の運用責任が議論から抜け落ちます。
PaaSはデプロイが速い一方、提供側の仕様変更やサポート終了（EOL）に合わせてアプリ側を追従させる必要があります。
この追従コストが見積もりに入っていないプロジェクトは少なくありません。
第二に、組織内の役割分担とサービスモデルの管理範囲が一致していないことがあります。
インフラチームがIaaSの仮想マシンを管理し、アプリチームがその上のミドルウェアを触る、という体制だと、ミドルウェアの脆弱性対応がどちらの担当か宙に浮きます。
第三に、業務要件側の事情です。
金融・医療など規制の強い業種では、データの保管場所や暗号化方式を自社で細かく制御したい要求があり、IaaSやオンプレミス寄りの構成が選ばれがちです。
ところがその要求と、開発チームが望む「PaaSで素早くリリースしたい」という希望が衝突し、どちらの要件を優先するか合意されないまま構築が進むことがあります。
自分のプロジェクトが該当するか確認する方法
次の観点で、今関わっているシステムを棚卸ししてみてください。
- 契約・設計ドキュメントに「OSパッチの適用責任者」が明記されているか
- インフラ構成図で、各コンポーネントがIaaS/PaaS/SaaSのどれに属するか色分けできるか
- クラウドベンダーの管理コンソール（AWSならIAMやEC2のタグ、AzureならResource Groups）で、サーバー単位に「管理責任チーム」のタグが付いているか
- サービス提供元のEOLロードマップ（例：Herokuの無料枠廃止、特定ランタイムのサポート終了告知など）を定期的に確認する担当が決まっているか
- 障害対応手順書に「このレイヤーの不具合はベンダー問い合わせ、ここから下は自社対応」という切り分けが書かれているか
これらのうち2つ以上が「ドキュメント化されていない」「口頭の了解だけ」という状態なら、管理責任の境界が曖昧になっている可能性が高いです。
対策の手順
1. 責任分界点をコンポーネント単位で棚卸しする
システム構成図を開き、各コンポーネントの横に「IaaS/PaaS/SaaS」のラベルを振ります。
そのうえで、OS・ミドルウェア・ランタイム・アプリ・データの5層それぞれについて、管理主体を自社かベンダーかで埋めていきます。
表形式で可視化すると、どこが抜け漏れているか一目で分かります。
2. タグ付け・命名規則で運用上の可視性を上げる
クラウドリソースに管理チーム名や責任範囲をタグ付けする運用を導入します。
aws ec2 create-tags --resources i-0abcd1234 --tags Key=OwnerTeam,Value=infra-team Key=ServiceModel,Value=IaaSこうしたタグはAWS Resource GroupsやAzure Tagsで横断検索できるため、棚卸し作業を継続的に回せるようになります。
3. EOL・仕様変更の監視を定例業務に組み込む
PaaSやSaaSはベンダー都合でランタイムやAPI仕様が変わります。
ベンダーの変更履歴ページやリリースノートを確認する担当とタイミング（例：月次の運用会議）をあらかじめ決めておきます。
4. 業務要件側の制約を技術選定より先に確定する
規制業種であれば、データ保管場所・暗号化方式・監査ログの保持期間といった業務要件を先に文書化します。
そのうえで、その要件を満たせるサービスモデルを逆算して選びます。
順序を逆にすると、後から要件に合わないことが発覚し、移行し直すコストが発生します。
まとめ
クラウド移行の失敗は、技術選定の巧拙よりも「誰が何を管理し続けるか」の合意不足から生まれることが多いです。
次の一歩として、まずは今のシステム構成図にIaaS/PaaS/SaaSのラベルを振り、5層（OS・ミドルウェア・ランタイム・アプリ・データ)それぞれの管理責任者を表にまとめてみてください。
併せて、クラウドリソースへのタグ付け運用とベンダーのEOL情報を確認する担当を決めておくと、将来の保守コストを事前に見積もりやすくなります。