クラウド時代の責任分界点：発注者が本当に聞きたい「ここから先は誰の責任？」

クラウド案件の打合せで、こんな会話になったことはありませんか？

発注側：「もし障害や情報漏えいが起きたら、どこまで御社の責任なんですか？」受注側：「クラウド事業者との責任分担モデルがありまして……」発注側：「いや、その“モデル”は分かりました。　　　　御社と当社の間では、どこまで見てくれるんですか？」

クラウドでは、よく「共有責任モデル」という図が出てきます。

• IaaSならここまでクラウド事業者、ここからお客様

• SaaSならアプリは事業者、データはお客様 ……といった話です。

でも発注者が本当に知りたいのは、

• 「AzureやAWSの責任範囲」ではなく

• 「クラウド事業者／受注会社／自社の3者の中で、ここから先は誰が面倒を見てくれるのか」

という**実務的な“線引き”**です。

今回は、発注者視点でこの「責任分界点」を整理しつつ、

「受注会社がここまで説明してくれると、発注側は本当に助かる」

というポイントをお伝えします。

1. 発注者が不安に思っているのは、典型的にこの3つ

まず、発注側の法務・情シス・現場がクラウド案件でモヤモヤしているポイントから。

不安① 障害が起きたとき、どこまでベンダが動いてくれるのか

• クラウド事業者側の障害情報をウォッチするのは誰？

• ステータスページを眺めるだけで終わり？

• ユーザー・経営層への説明文を作ってくれるのか？

• 復旧までにとる暫定対策を考えるのは誰？

「クラウドが落ちたので、うちの責任範囲外です」と言われてしまうのが一番怖いのです。

不安② セキュリティ設定ミスがあったとき、誰の責任になるのか

• ネットワークやファイアウォールの設定

• ストレージの公開範囲（“世界中から読み取り可”になっていないか）

• ID・権限・多要素認証の設定

• バックアップの有効化・テスト

これらの**“設定ミス”で情報漏えいが起きたとき**、

「クラウドの仕様です」「設定はお客様側でお願いします」

と言われると、発注者としてはたまりません。

不安③ バックアップ・ログ・インシデント対応

• データのバックアップがどこまで取られているか

• 誰がリストア手順を理解しているか

• いつまで遡ってログを追えるのか

• 何か起きたとき、「誰が」「どこまで」原因調査をやるのか

紙の上では「ログ取得」「バックアップ」と書いてあっても、

実際にトラブルが起きた瞬間、「ここから先は御社で」と言われたらどうしよう

という不安が常に付きまといます。

2. クラウド事業者／受注会社／発注会社の“三層モデル”で考える

責任分界点を整理するとき、山崎行政書士事務所ではよく、こんな三層構造で考えます。

1. クラウド事業者（IaaS/PaaS/SaaS）

   • データセンター、電源、ネットワーク

   • ハイパーバイザ、物理・論理インフラ

   • SaaSならアプリケーション基盤

2. 受注会社（SI・開発ベンダ・運用ベンダ）

   • システム設計・構築・設定

   • ミドルウェア・アプリの品質

   • 運用・監視・一次対応

3. 発注会社（ユーザー企業）

   • 利用ルール・アカウントの発行／廃止

   • エンドユーザー端末の管理

   • 社内での教育・運用体制

クラウド事業者の「共有責任モデル」図は、このうち1層目だけの話です。

発注側が本当に知りたいのは、

2層目と3層目の間に、どんな“線”が引かれているのか

という点です。

3. 発注側から見た「ここだけはハッキリ書いてほしい責任分界」

細かい分類はいろいろありますが、発注側から見ると、最低限この8項目について、

「クラウド事業者／受注会社／発注会社のどこが主担当か」

が分かるだけで、安心感がぐっと変わります。

① インフラ障害・クラウド基盤の稼働

• クラウド事業者の責任：

  • SLAに基づく基盤の稼働

  • データセンタ・ネットワークの維持

• 受注会社の責任：

  • 障害情報の監視

  • 発注者への状況連絡・影響範囲の説明

  • 必要に応じた暫定措置（切り戻し・縮退運転など）

• 発注会社の責任：

  • 自社業務側の判断（どこまで止めるか）

  • 社内・顧客へのアナウンス

提案書や契約書に、

「基盤障害時には、弊社がクラウド事業者の情報を確認のうえ、御社への一次報告・復旧見込みの共有を行います」

と一言書いてあるだけで、発注側はだいぶ安心します。

② OS・ミドルウェアのパッチ適用・バージョンアップ

• IaaSの場合：

  • OS・ミドルウェアのパッチは誰が当てるのか

  • その結果生じた不具合の切り分けを誰がやるのか

• PaaS／SaaSの場合：

  • 事業者側で自動更新される部分にどう追随するか

ここがグレーだと、

「脆弱性が放置されていたのは誰の責任か」

という話になったときに、揉めます。

「OS・ミドルウェアのパッチ適用は弊社が責任を持ちます」なのか、「基本ポリシーは弊社が定め、実作業は御社運用チームで」なのか、どちらでもよいので書いておいてほしいポイントです。

③ アプリケーションのバグ・性能問題

ここは比較的分かりやすいですが、

• 機能不具合や性能劣化があったとき、「クラウド環境のせいなのか」「アプリのせいなのか」

• どこまで受注会社が切り分けを手伝ってくれるのか

を明記しておくと、発注側は安心します。

「パフォーマンス問題が発生した場合、まず弊社にてアプリケーションレイヤの確認を行い、必要に応じてクラウド事業者への問い合わせを実施します」

といった一文があるだけでも違います。

④ ID・権限・認証（誰がどこまで管理するか）

クラウド時代で一番“責任のなすりつけ合い”になりがちなのがここです。

• ユーザーアカウントの発行・削除

• 権限ロールの設計

• 多要素認証（MFA）の必須化

• パスワードポリシー

よくあるまずいパターン

• 受注側：「ID管理はお客様側の責任です」

• 発注側：「ロール設計も含めて提案してくれると思っていた」

発注側が本当に知りたいのは、

• 「ロール設計」「利用ルール」は誰が主導するのか

• 発行・削除の作業はどこまで自動化・運用設計してくれるのか

• 不正ログインが疑われるとき、誰がログを見てくれるのか

です。

⑤ データ保護（バックアップ・リストア）

• どのデータを

• どの頻度で

• どこに

• どの世代まで残すか

というバックアップ設計と、

• 実際に復元が必要になったときに誰が操作して、どこまでサポートしてくれるのか

が責任分界ポイントです。

発注側が見たいのは、「バックアップを取ります」ではなく、

「バックアップ設計の責任：受注会社」「バックアップ運用（監視・失敗対応）：受注会社」「リストアの実行：原則受注会社が行い、御社に確認のうえ切り替え」

といった具体的な役割分担です。

⑥ ログ・監視・アラート

• インフラ・アプリのログを

  • どこまで収集するか

  • どこまでモニタリングするか

  • どれくらいの期間保管するか

• 異常値やエラーを検知したときに

  • 誰にアラートを上げるか

  • 誰が一次分析をするか

ここが曖昧だと、

「ログは取っていましたが、誰も見ていませんでした」

という、クラウド時代あるあるの事故になります。

⑦ セキュリティ設定・脆弱性対応

• FW／セキュリティグループ／WAF／DDoS対策のポリシー設計

• 重要な設定（パブリックアクセス禁止・暗号化必須など）の標準化

• 脆弱性情報を収集し、優先度を付けて対応する役割

発注側の感覚としては、

「“クラウドらしい”セキュリティ設定は、できればプロである受注会社に主導してほしい」

というのが本音です。

⑧ インシデント対応（情報漏えい・不正アクセスなど）

最後に一番重い話です。

• インシデントの検知（ログ監視・ユーザーからの通報）

• 初動対応（アクセス遮断・証拠保全）

• 原因調査（どのレイヤで、どんなミス／攻撃があったのか）

• 再発防止策の検討

特に原因調査と再発防止策について、受注会社がどこまで責任を持つのかを提案書・契約書で明確にしておくと、

「何かあったときも、一緒に考えてくれる会社だ」

と評価されやすくなります。

4. 「責任分界表」を1枚作るだけで、発注側の印象は激変する

上の8項目を、縦軸：項目横軸：クラウド事業者／受注会社／発注会社

に並べて、「○」「△（共同）」「－（原則対象外）」をつけた“責任分界表”を1枚作っておくだけで、発注側からの見え方は大きく変わります。

たとえば：

• インフラ基盤の稼働：

  • クラウド事業者：○

  • 受注会社：監視・連絡△

  • 発注会社：－

• ID・権限設計：

  • クラウド事業者：－

  • 受注会社：設計○／運用支援△

  • 発注会社：運用○

• バックアップ：

  • クラウド事業者：機能提供△

  • 受注会社：ポリシー設計・設定○

  • 発注会社：リストア指示△

といった形です。

この1枚があるだけで、

「“クラウドだから”とあいまいにされてしまうところが、ちゃんと整理されている」

と感じてもらいやすくなります。

5. 提案書・契約書で「ここまで書いてあれば安心」というライン

発注者視点で言うと、提案書や契約書に最低限これだけ書いてあれば安心できる、というラインはこうです。

提案書に書いておいてほしいこと

• クラウド事業者／受注会社／発注会社の三者の関係図

• ざっくりとした責任分界表（さきほどの8項目レベル）

• 障害時・インシデント時の連絡フロー図

• 「御社にお願いしたい作業」の一覧

  • 例：アカウント発行依頼、権限承認、社内教育など

契約書・基本合意書で押さえておきたい条項

• データの帰属（誰のものか）と、利用目的

• クラウド事業者の障害時に、受注会社が行う対応の範囲

• バックアップ・ログ保管・リストアの責任分担

• 再委託（クラウド事業者・運用ベンダ・オフショア拠点）に関するルール

• インシデント発生時の報告義務・原因調査・再発防止策の扱い

• 損害賠償の範囲と上限（クラウド事業者のSLAとどう接続するか）

ここまで書いてあれば、

「どこから先が“うちの責任”になるのか」「ベンダと一緒にどこまでやってもらえるのか」

が見えるので、発注側として社内を説得しやすくなります。

6. 山崎行政書士事務所がお手伝いできること

山崎行政書士事務所では、クラウド法務を専門として、

• 既存のクラウド構成・運用実態をヒアリングしたうえでの「責任分界表」のたたき台作成

• 提案書・RFP回答用の三者の責任分担図・説明スライドの作成支援

• クラウド事業者のSLA・共有責任モデルと整合の取れた契約条項案（責任・データ・再委託・インシデント対応）のドラフト

• 発注側向けに、「ここから先は誰の責任か」を分かりやすく説明する文章のブラッシュアップ

といったお手伝いをしています。

「クラウドは得意だが、責任分界の説明になるといつも“ふわっとした言い回し”になってしまう」 「発注側から“ここは誰の責任？”と聞かれたときに、スッと出せる紙と図がほしい」

と感じている受注側の会社さんには、一度責任分界表と契約のドラフトをセットで作っておくと、その後のRFP・提案でも使い回せる武器になります。

静岡県内のSI・クラウドベンダー・IT部門の方には、オンライン・訪問のどちらでも対応可能です。

クラウド時代の「責任分界点」は、曖昧にしておくほど、トラブル時に揉めます。

逆に言えば、

• 最初から三者の責任分担を整理して

• 提案書と契約書に落としておけるベンダー

は、発注側から見ると

「何かあっても一緒に整理してくれそうな、長く付き合える相手」

として、選ばれやすくなります。

その“見える化”の部分を、山崎行政書士事務所のクラウド法務で一緒に形にしていきましょう。