MSPに任せた後、アプリケーション障害は誰が直すのか

問題と判断基準

クラウド運用委託契約を検討する場面を考えます。提案書には「監視・障害対応を含む」とあります。注文が停止したとき、サーバーの確認、不具合のあるコードの修正、欠落した注文の整合まで含むのでしょうか。

アプリケーション障害の解決担当は、MSPという名称だけでは決まりません。委託する診断と修正、変更の承認者と実行者を確認します。 インフラ運用だけを委託する場合、コード修正の担当者は別途必要です。アプリケーション保守も委託できますが、データ復元範囲やサービス再開など事業上の判断には、承認者を定める必要があります。

契約前に二つの問いに答えられるようにします。「事故全体を最後まで調整する人は誰か」「各システムを実際に修正する人は誰か」です。連絡窓口を一つにすることと、すべての修正を一社に任せることは別の選択です。

本稿の「責任」は、業務の決定・承認・実行の役割を意味します。個別障害の法的な帰責や損害賠償責任を判断する基準ではありません。

CSPの責任共有モデルだけでは運用委託の範囲は決まらない

まずクラウドサービス事業者（CSP）、運用受託事業者（MSP）、アプリケーションの開発・保守チームを区別します。さらに、業務の停止・再開を判断するサービス所有者、正しいデータ状態と復元範囲を承認するデータ所有者、決済・認証などの外部SaaS事業者が加わります。小規模な組織では、一人が複数の役割を担う場合もあります。

AWSの責任共有モデルは、EC2の基盤インフラと顧客のゲストOS・アプリケーションなどのセキュリティ責任を分けています。Google Cloudもサービスの種類によって責任の境界が変わると説明しています。これらはセキュリティ責任を理解する出発点です。個別のMSPが夜間にどのコードを修正するかを定める作業仕様書ではありません。

サポート商品も別に確認します。AWS Support FAQには、サポート範囲とともに、カスタムコード開発やソフトウェアのデバッグは含まれないと明記されています。「一切支援を受けられない」と読む必要はありませんが、技術サポート契約をアプリケーション保守契約と同一視してはいけません。

可用性の約束は、さらに別の文書です。AWS Compute SLAとGoogle Compute Engine SLAは、対象サービスの可用性の定義、適用条件、クレジット請求条件と除外事項を定めます。その数値を顧客サイト全体の可用性やMSPの復旧時間にそのまま当てはめることはできません。供給者のサービス上の約束、技術サポート、MSPの実際の運用業務をそれぞれ確認します。

「24時間対応」を七つの活動に分ける

以下は提案範囲を比較するための設計基準です。一つの項目の提供が、次の項目の保証を意味しないように分けています。

チケットの自動作成は、人が受け付けた証拠ではありません。サーバーが応答しても、注文欠落が解消した証拠にはなりません。一方、診断をすべて終えてからでなければ緩和できないわけでもありません。Google SREのインシデント対応の説明も、組織的な役割分担と被害緩和を重視しています。

応答目標では「何分」の前後にある条件が重要です。Google Cloudの技術サポートガイドラインは、サポート等級・優先度ごとの初回応答目標と対応時間を区別しています。初回応答目標を問題解決の期限と解釈してはいけません。

運用上の合意には、検知・申告・通知・受付のどこから計時するか、顧客承認や外部事業者の回答待ちをどう報告するかを記載します。他社への移管で、利用者が経験する総停止時間を数え直さないことも有用な基準です。許容停止時間とデータ損失を先に定める場合は、RTO・RPOによる復旧水準の決め方を参照できます。

「DB障害」ではなく実施する作業ごとに責任を分ける

以下は架空のWebアプリ運用契約の設計例です。実在事業者の標準提供範囲やIXCの契約条件ではありません。

WebアプリはVMとマネージドDBを使います。MSPはVM・ネットワーク運用と承認済みデプロイ手順の実行を担当します。開発・保守チームはコード・クエリ・DB接続設定を担当します。サービス所有者は、事前に定めた予算と変更範囲内の措置を委任したと仮定します。

表の最終決定・承認は、その作業を実施してよいかを決める一つの主体です。実行は実際に調査・変更する主体です。協力が不要な欄は空欄にしています。供給者内部の作業に顧客の承認権が生じるという意味でもありません。

事前承認範囲を超える増強は同じ作業として扱わず、追加費用の承認手続きに移します。データ損失の可能性がある復元も、単なるサーバー再起動と同じ権限にまとめません。

こう分けると「DB障害は誰の責任か」という問いを小さくできます。対象がDBエンジン内部、アプリの接続管理、クエリ、業務データのどれかで、実行者と承認者が変わります。自ら導入したDBならエンジン運用担当も別途指定します。マネージド商品の供給者の作業範囲は、そのサービスの方針で確認します。

CPU使用率が高いだけでインフラを原因と断定しないことも同じ原則です。後の例では、アプリ変更が接続問題を生んだと仮定します。リソースを増強できることと、原因を修正できることを区別します。

窓口は一つに、修正権限は必要な担当者に

Google SREは、事故指揮、コミュニケーション、技術的措置の役割を区別します。小さな事故では一人が兼任できますが、指揮と技術的措置は区別できる必要があります。

複数事業者が参加する運用では、原因がまだ不明な間も事故全体を担当する指揮者を定める方法が適しています。MSPでも顧客内部の担当者でも構いません。誰を選んでも「当社の範囲外」という通知だけで事故担当者がいなくならないようにします。

特にMSPから開発チームへの移管では、受信担当者の引き受け確認を残すことを合意します。症状、影響、実施済み措置、必要権限、次回報告時点も伝えます。CSPや外部SaaSへ支援を依頼する場合は、顧客に代わってケースを開くアカウントとサポート契約を確認します。外部チケット番号と受付状況を事故記録に結び、外部チケットの作成だけで内部案件を終了しません。

設計例1：デプロイ直後にDB接続が枯渇した場合

仮定： アプリのデプロイ後に注文エラーが増え、変更した接続管理コードが原因でした。MSPにはデプロイパイプラインの実行権限がありますが、任意のコード修正権限はありません。以下は実際の事故記録ではありません。

検知・受付 → 共同診断 → ロールバック承認 → 実行・検証 → 業務確認と後続修正の引き継ぎをつなげます。

MSPが事故を受け付け、指揮者を指定します。MSPはリソース・ネットワーク・DB接続の指標を確認し、開発チームは最近の変更とアプリのエラーを調べます。最初から「サーバーの問題」「開発の問題」と断定して片側だけに渡しません。

旧版に戻すのが適切なら、アプリケーション技術責任者が現在のDBスキーマ・設定との互換性を確認し、ロールバックを承認します。MSPは合意済みの手順のみ実行します。コードのロールバック承認に、DB全体を過去の状態で上書きする権限まで含めません。

承認者と連絡がつかない場合も事前に定めます。代替承認者や明示的な緊急委任がなければ、MSPがアプリ修正・データ変更の権限を勝手に拡張しないようにします。事前承認済みの緩和措置を適用し、エスカレーションを継続することを合意します。

復旧後、開発チームとMSPは重要機能を検証し、サービス所有者は実際の注文処理と滞留作業を確認します。欠落データがあればデータ所有者が訂正範囲を承認します。コードの根本修正と回帰検証は開発チームの後続作業です。デプロイ版、承認・実行時刻、検証結果、後続作業の受信担当者を事故記録に残します。

設計例2：外部決済APIが応答しない場合

仮定： 顧客のWebアプリで決済要求の応答が途切れました。外部事業者が要求を処理したかはまだ分かりません。これも実際の顧客事例ではなく設計例です。

応答がないことと、決済が実行されなかったことを区別します。Stripeのエラー処理文書も、ネットワークエラーではサーバーが要求を受け取ったかをクライアントが判断できない状況を説明しています。これはStripeの技術説明であり、他の決済事業者も同じ照会・再試行規則という意味ではありません。

影響確認 → 外部事故との関連付け → 事業上の緩和判断 → 取引結果の確認 → 再処理・業務再開の承認に役割を分けます。

MSPは自社側のネットワークとサーバー状態を、開発チームは要求識別子とアプリ記録を確認します。外部サービスを疑う根拠があれば指定担当者がサポートケースを開きます。公開ステータスページは参考資料であり、個別取引の成功・失敗を確定する資料にはしません。

新規注文を一時停止するか、検証済みの別の決済経路を使うかはサービス所有者が決定します。MSPが外部プラットフォーム内部を直接修正できるとは想定しません。外部事業者への復旧依頼と、顧客Webアプリの被害軽減を並行して進めます。

外部接続が回復しても、すべての要求を送り直しません。開発チームが決済事業者の照会・再試行規則に従って結果を確認します。データ所有者が注文と決済の不一致の整理方法を承認します。承認済みの再処理と業務確認を経て、サービス所有者が再開を決定します。終了記録には外部事故番号に加え、結果未確認の取引と残作業の担当者を残します。

提案書には作業一覧と判断条件を記載する

上の責任表を契約・運用合意に結び付ける際は、「障害対応を含む」に以下を添えて検討できます。標準契約条項ではなく、作業範囲を具体化するための質問です。

複数社の提案比較にはクラウド運用委託先の選定ガイドも参照し、障害ごとの実行者と承認者を各提案の範囲に当てはめます。役割決定後に実際の対応手順を文書化する段階では、障害対応Runbookの設計を参照できます。

アクセス権は別の受け入れ条件として扱います。「管理者権限あり」の一行ではなく、必要なアカウント・リソース・操作・期間と回収方法を確認します。例えばAWS Support Authorizationは、サポートケースに対してリソース・操作・期間を制限した許可を扱います。同様の具体性を運用委託の権限合意にも適用するという提案であり、すべてのMSP契約にその機能が含まれるという意味ではありません。

事業者変更の条件も開始前に定めます。アカウントとドメインの管理主体、ソース・設定・運用文書・監視設定・バックアップの引き継ぎ対象を整理します。復元用の鍵の安全な受け渡し方法と、ライセンスや再販契約で移転が制限される項目も区別します。引き継ぎ形式・期限・費用と未終了案件の担当者も必要です。新担当者がアクセスと復元手段を確認してから旧権限を回収する順序を合意します。

自社に合う運用方式を選ぶ

インフラとアプリの両方を扱える人が社内におり、必要な時間帯も対応できるなら、追加委託をせず役割と権限を整理する選択ができます。この表を埋めるために新しい管理ツールを導入する必要もありません。既存の文書と案件管理ツールで担当者・承認・引き継ぎを追跡できれば十分です。

開発チームはあるがサーバー運用負担を減らしたい場合、インフラ中心のMSPとアプリ保守を分けられます。その場合は共通窓口、共同診断、開発チームの呼び出し可能時間、引き受け確認を合意に含めます。夜間の受付担当がいても、コード修正担当は翌営業日まで対応できない可能性を購入段階で明確にします。

アプリ保守担当自体がいない場合、インフラ委託契約だけで穴が埋まるとは想定しません。保守引き継ぎ、コード・デプロイ経路の整備、アプリ運用を含む委託のどれが必要かを先に判断します。翌営業日まで停止を許容できるシステムなら、常時の人的対応より営業時間内の支援が適切かも検討できます。

どの方式でも、顧客側にはサービス停止・再開、データ訂正・損失許容範囲、追加費用と優先度を決める役割が残ります。判断は委任できますが、誰がどの範囲まで代行するか、不在時の代替承認者は誰かを定める必要があります。

契約前に最重要業務を一つ選び、「今停止したら」と考えます。受け付ける人、修正する人、承認する人、業務復帰を確認する人をすべて指定できるでしょうか。担当が空欄の作業があれば、事業者名や可用性の数値を比べる前に、その空欄を解消します。

現在のシステムの運用責任と支援範囲を外部と検討する場合は、対象システム、委託する作業、手元に残す承認権限を整理してIXCへのお問い合わせで共有できます。