--- title: "責任共有モデルとは。クラウドの事業者が守る範囲、利用者が守る範囲｜アメリア・テクノロジー株式会社" url: https://www.ameliatechnology.co.jp/blog/shared-responsibility-model-explained/ description: "責任共有モデルとは、クラウドの安全と運用の責任を、事業者と利用者が分け持つ考え方です。AWS・Microsoft・Google Cloud の公式の説明をもとに、事業者と利用者が守る範囲、両方が分担するもの、委託しても残る責任を整理します。" updated: 2026-11-14 publisher: "アメリア・テクノロジー株式会社" --- # 責任共有モデルとは。クラウドの事業者が守る範囲、利用者が守る範囲 責任共有モデルとは、クラウドの安全と運用の責任を、事業者と利用者が分け持つ考え方です。AWS・Microsoft・Google Cloud の公式の説明をもとに、事業者と利用者が守る範囲、両方が分担するもの、委託しても残る責任を整理します。 2026.11.14 [クラウドと運用](https://www.ameliatechnology.co.jp/blog/category/cloud/) 執筆 [石田誠](https://www.ameliatechnology.co.jp/blog/author/ishida/)（グループCTO） クラウドと運用（CLOUD & OPERATIONS）のコラム ## この記事の要点 - 事業者は、データセンター・機器・ネットワーク・仮想化の基盤といった「クラウドそのもの」を守ります - 利用者は、データ・アカウントとアクセスの権限・設定を守ります。この部分は、どのサービスの形でも利用者に残ります - 更新や設定の管理は両方が分担する仕事で、運用を外部に委託しても、利用者としての責任は残ります 責任共有モデルとは、クラウドの安全と運用の責任を、クラウドの事業者と利用者が分け持つという考え方です。事業者は基盤を守り、利用者は自分のデータ、アカウント、設定を守ります。この線引きを知らないまま使うと、「事業者が守ってくれているはず」と思っていた部分が、実は誰も見ていなかった、ということが起きます。 AWS・Microsoft・Google Cloud は、それぞれ自社の責任共有モデルを公開しています。言い回しは違いますが、基本の線引きは共通しています。この記事では、公式の説明をもとに、その線引きを整理します。 ## 責任共有モデルとは [責任共有モデル](https://www.ameliatechnology.co.jp/glossary/shared-responsibility-model/)は、「クラウドそのものの安全」と「クラウドの中に置いたものの安全」を分けて考える枠組みです。 AWS は、自社の責任を「クラウドのセキュリティ（Security of the Cloud）」、利用者の責任を「クラウドにおけるセキュリティ（Security in the Cloud）」と呼び分けています。AWS は、AWS のクラウドで提供するすべてのサービスを動かす基盤を守る責任を負い、利用者の責任の範囲は、利用者が選んだサービスによって決まる、と説明しています。 出典：[Shared Responsibility Model（AWS）](https://aws.amazon.com/compliance/shared-responsibility-model/) ## 事業者が守る範囲 事業者が守るのは、建物、機器、ネットワーク、仮想化の基盤といった、クラウドを成り立たせている部分です。利用者からは見えず、触れることもできない部分です。 Microsoft は、自社の責任として、データセンターの物理的な安全、データセンターの中のネットワーク、物理的なサーバー、仮想化の層（ハイパーバイザー）を挙げています。PaaS と SaaS では、OS、実行の環境、ミドルウェアも Microsoft が管理します。 出典：[Shared responsibility in the cloud（Microsoft Learn）](https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility) 利用者はこの部分を自分で点検できないため、事業者がどのように守っているかは、第三者による評価や認証の結果で確かめることになります。政府のクラウドの評価の仕組みである[ISMAP](https://www.ameliatechnology.co.jp/glossary/ismap/)も、その手がかりの一つです。 ## 利用者が守る範囲 利用者が守るのは、データ、アカウントとアクセスの権限、そして自分で決めた設定です。この3つは、サービスの形にかかわらず、利用者の責任として残ります。 Microsoft は、どの形で使う場合でも、データとアカウント（ID）は利用者のものであり、データ（分類・保護・暗号化の判断を含む）、端末、アカウント、アクセスの管理（多要素認証などを含む）の責任は、常に利用者に残ると説明しています。Google Cloud も、事業者は基盤とネットワークに常に責任を持ち、利用者はアクセスのポリシーとデータに常に責任を持つ、としています。 出典：[Shared responsibility in the cloud（Microsoft Learn）](https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility) 出典：[Shared responsibilities and shared fate on Google Cloud（Google Cloud）](https://docs.cloud.google.com/architecture/framework/security/shared-responsibility-shared-fate) AWS は、利用者の責任の例として、仮想サーバーの OS（更新とセキュリティパッチを含む）と、その上に入れたアプリケーションの管理、ファイアウォールにあたるセキュリティグループの設定、データと暗号化の選択の管理、[IAM](https://www.ameliatechnology.co.jp/glossary/iam/)による権限の設定を挙げています。 出典：[Shared Responsibility Model（AWS）](https://aws.amazon.com/compliance/shared-responsibility-model/) ## 境目は、サービスの形で動く 事業者と利用者の境目は、どのサービスを使うかで動きます。利用者が管理する層が多いサービスほど、利用者の責任は広くなります。 AWS は、仮想サーバーの Amazon EC2 では、利用者が必要なセキュリティの設定と管理の作業をすべて行う必要があると説明しています。一方、ファイルを保管する Amazon S3 のように抽象化されたサービスでは、基盤、OS、プラットフォームを AWS が運用し、利用者はデータを置いたり取り出したりする窓口を使います。Google Cloud も、IaaS では安全を守る仕事の大半が利用者にあり、SaaS では大半を Google が担うと説明しています。 サービスの形で動く、事業者と利用者の境目（AWS・Google Cloud の説明より） - **Amazon EC2（仮想サーバー）**：必要なセキュリティの設定と管理の作業を、**利用者がすべて行う** - **Amazon S3 など抽象化されたサービス**：基盤・OS・プラットフォームは AWS が運用。利用者はデータを置き、取り出す窓口を使う - **Google Cloud の IaaS**：安全を守る仕事の大半は利用者 - **Google Cloud の SaaS**：安全を守る仕事の大半は Google 形ごとの運用の仕事の違いは、[IaaS・PaaS・SaaS の違いと、運用の責任の分かれ目](https://www.ameliatechnology.co.jp/blog/iaas-paas-saas-responsibility/)で表にしています。 ### 両方が分担する仕事 一部の仕事は、事業者と利用者がそれぞれの範囲で同じ種類の対策をとる「分担」の形になります。 AWS は、両方が担う管理として、次の3つを挙げています。 - **更新（パッチ）の管理**：基盤の欠陥の修正は AWS、利用者の OS とアプリケーションの修正は利用者 - **設定の管理**：基盤の機器の設定は AWS、利用者の OS・データベース・アプリケーションの設定は利用者 - **教育**：AWS は自社の社員を教育し、利用者は自社の社員を教育する 出典：[Shared Responsibility Model（AWS）](https://aws.amazon.com/compliance/shared-responsibility-model/) なお、Google Cloud は、責任を分けるだけでは利用者の安全の向上を助けきれないとして、安全な初期の設定や設計のひな形などで利用者を支える「運命の共有（shared fate）」という考え方も打ち出しています。事業者が用意する初期の設定やひな形を使うと、利用者の側の作業の誤りを減らしやすくなります。 ## 委託しても、利用者の責任は残る 構築や運用を外部の会社に委託しても、利用者としての責任はなくなりません。委託した範囲を、委託先が正しく担っているかを確かめる仕事が加わります。 総務省の「クラウドの設定ミス対策ガイドブック」は、システム会社が行った設定であっても最終的な責任は利用者が負うため、利用者もその設定に注意しておく必要があると説明しています。システム会社が入ると責任の分担が複雑になるため、契約などでよく確かめること、委託先の作業の状況を把握することも挙げています。利用規約の免責の条項も確かめておきます。契約の個別の判断は、弁護士などの専門家にご確認ください。 出典：[クラウドの設定ミス対策ガイドブック（総務省、2024年4月）](https://www.soumu.go.jp/main_content/000944467.pdf) 利用者の側の設定の誤りが原因の事故と、その防ぎ方は[クラウドの設定ミスによる情報漏えいと、防ぎ方](https://www.ameliatechnology.co.jp/blog/cloud-misconfiguration/)で、委託先の確かめ方は[委託先・クラウドサービスの管理をどう確かめるか](https://www.ameliatechnology.co.jp/blog/vendor-cloud-oversight/)で説明しています。 ## 当社のご支援 当社の[クラウドの構築と運用管理](https://www.ameliatechnology.co.jp/service/cloud/)では、利用者の側に残る責任のうち、どこを当社が担い、どこを御社に残すかを、最初に表にして合意してから運用を始めます。いまの環境で、利用者の側の設定や権限に抜けがないかを確かめるには、クラウドのセキュリティ診断をご利用いただけます。当社が構築・運用している環境の診断は、自己点検として扱います。第三者の立場での確かめが必要な場合は、[システム監査](https://www.ameliatechnology.co.jp/service/system-audit/)の考え方もご覧ください。 - 責任共有モデル - クラウド - セキュリティ - 委託先の管理 ## この記事に出てくる用語 - [責任共有モデル](https://www.ameliatechnology.co.jp/glossary/shared-responsibility-model/) - [クラウド](https://www.ameliatechnology.co.jp/glossary/cloud/) - [AWS（Amazon Web Services）](https://www.ameliatechnology.co.jp/glossary/aws/) - [Google Cloud](https://www.ameliatechnology.co.jp/glossary/google-cloud/) - [仮想化](https://www.ameliatechnology.co.jp/glossary/virtualization/) - [サーバー](https://www.ameliatechnology.co.jp/glossary/server/) - [PaaS](https://www.ameliatechnology.co.jp/glossary/paas/) - [SaaS](https://www.ameliatechnology.co.jp/glossary/saas/) ## 関連する法令・指針（参考情報） - 指針 総務省「クラウドの設定ミス対策ガイドブック」（2024年4月（2024年4月26日公表）） 2022年10月の「クラウドサービス利用・提供における適切な設定のためのガイドライン」の内容を、クラウドサービスを使う側に向けて分かりやすく解説した資料です。責任共有モデル、設定ミスの原因（担当者・マニュアル・作業環境・組織の環境）、設定と権限の管理、ダブルチェック、CSPMなどの点検の仕組みを取り上げています。 [発行元の公式ページで開く](https://www.soumu.go.jp/main_content/000944467.pdf) 法令は2026年10月21日時点の内容です。要旨は当社がまとめたもので、条文・判決・指針の全文ではありません。個別の事案への当てはめは、弁護士・社会保険労務士などの専門家にご確認ください。表記の決まりは[法令・指針の参考情報と凡例](https://www.ameliatechnology.co.jp/knowledge/legal/)をご覧ください。 この記事を書いた人 [石田誠](https://www.ameliatechnology.co.jp/blog/author/ishida/) グループCTO インターネットの黎明期から、ホスティング事業の立ち上げや、インフラ・セキュリティのプロジェクトに携わってきました。現在は、AWS・Azure へのクラウド移行の支援と、業務アプリケーションの要件定義から実装までを担っています。 このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。 ## あわせて読みたい - [Windowsサーバーと Active Directory を Azure へ移すときの考え方](https://www.ameliatechnology.co.jp/blog/windows-ad-to-azure/) - [Google Cloud を選ぶ場面。データ分析と Google Workspace とのつながり](https://www.ameliatechnology.co.jp/blog/when-to-choose-google-cloud/) - [Well-Architected の柱で、いまの構成を確かめる](https://www.ameliatechnology.co.jp/blog/well-architected-review/) [クラウドと運用のコラムを見る](https://www.ameliatechnology.co.jp/blog/category/cloud/) [コラムの一覧に戻る](https://www.ameliatechnology.co.jp/blog/) ## 次の一歩 ### クラウドの構築と運用を任せる AWS・Microsoft Azure・Google Cloud の設計・構築・移行から、監視・運用・セキュリティまでを一つのチームで受け持ちます。監視は仕組みで24時間365日自動に回し、原因の調査と再発の防止は当社が担います。 [クラウドの構築と運用管理を見る](https://www.ameliatechnology.co.jp/service/cloud/) ### クラウドの状態を、無料で確かめる 15の設問に答えると、構成と管理・権限・守り・障害への備え・費用と体制の5つの分野の点数と、最初に取り組むことをまとめたレポートをその場でお届けします。 [クラウドの自己診断（無料）を受ける](https://www.ameliatechnology.co.jp/diagnosis/cloud/) ## ご関心に合わせて、お選びください。 [情報を集めている方へ会社案内、AI開発の例、セキュリティ診断の報告書の見本をお送りします。資料をダウンロード](https://www.ameliatechnology.co.jp/download/)[課題が見えている方へオンラインで30分、お話をうかがいます。費用はかかりません。無料で相談する](https://www.ameliatechnology.co.jp/contact/)[進め方を決めたい方へ2〜4週間で、優先順位と計画をまとめるAI活用の診断です。診断について見る](https://www.ameliatechnology.co.jp/pricing/#diagnosis) --- 出典：アメリア・テクノロジー株式会社「責任共有モデルとは。クラウドの事業者が守る範囲、利用者が守る範囲｜アメリア・テクノロジー株式会社」 https://www.ameliatechnology.co.jp/blog/shared-responsibility-model-explained/