2026年10月8日に、AWS shared responsibility、S3 Versioning、AWSの復旧テスト、Google Cloudのshared responsibility、Google Cloud budgets、Azure shared responsibilityを再読しました。責任範囲はクラウド名ではなくサービス、設定、統合、法令で変わります。S3 Versioningは明示的に有効化する機能で、版ごとの保存料金があり、バックアップは実際に復旧してRTO/RPOとデータ整合性を確認します。予算通知と利用停止の仕組みも別に確認し、クラウド利用だけで安全・復旧・料金上限が自動化されるとは扱いません。
30秒で要点
クラウドは、計算する力、データを置く場所、完成したアプリなどを、ネットワーク経由でサービスとして利用する仕組みです。自社で機械を買ってすべて管理する以外の選択肢になります。
- 完成したアプリを使うSaaS、アプリを動かす基盤を使うPaaS、仮想マシンなどを使うIaaSがある。
- 事業者に任せられる作業は、会社名ではなく選ぶサービスで変わる。データや権限、公開設定の判断は残る。
- 安さ、安全性、バックアップ、無停止が自動で保証されるわけではない。費用・復旧・移行を含めて選ぶ。
メールやファイル共有でクラウドを使っているものの、会社のWebサイトや業務システムでも使うべきか迷っている方に向けた記事です。専門用語の意味から、契約前に確認する項目まで整理します。
1. 電気や水道に似ているところ、違うところ
自社で発電所を持たずに電気を使うように、計算資源や保存場所をサービスとして利用する、と考えると入り口がつかめます。必要な機能を使い、事業者が担う設備管理の一部を自社で抱えずに済む点が似ています。
ただし、料金が必ず「使った分だけ」になるわけではありません。利用者ごとの定額、基本料金、使用量、契約期間などが組み合わされることがあります。また、データの置き方や、誰に使わせるかまで事業者が決めてくれるわけではありません。
NISTの定義では、共有される資源を必要に応じて利用できること、資源を増減できること、利用状況を計測することなどが特徴として挙げられています。この2011年の文書は概念の整理に使います。現在の製品料金や、個別契約の保証を示すものではありません。NIST SP800-145:クラウドの定義
一般向けのサービスではインターネットを通じて利用することが多い一方、クラウドには組織専用の形態もあります。「ネットにつながるサービスは全部同じクラウド」「クラウドなら社外にすべて公開される」と一括りにはしません。
2. 身近な利用から、業務の仕組みまで
クラウドは一つの製品名ではありません。完成した機能を使う場合と、自分でアプリを作って動かす場合では、自社に残る仕事が違います。
表が収まらない場合は、横にスクロールできます
| やりたいこと | 利用のイメージ | 確認する点 |
|---|---|---|
| メールや予定を共有したい | 完成した業務アプリを利用する | 利用者、管理者、退職時の引継ぎ |
| ファイルを共同編集したい | 保存と共有の機能を利用する | 閲覧・編集・外部共有の範囲、履歴と復元 |
| 会社のWebサイトを公開したい | 公開機能やホスティングを利用する | 更新方法、独自ドメイン、停止時の対応 |
| 独自の予約・受注システムを動かしたい | アプリ実行基盤や仮想マシンを利用する | 開発、設定、更新、監視、データ管理の担当 |
端末が故障しても、サービス側に残っているデータを別の端末から利用できる場合があります。ただし、それはアカウント、アクセス権、ネットワーク、サービスの状態が整っていることが前提です。アカウントを失う、共有設定を誤る、データ自体を削除する、といった問題は別に考えます。
3. SaaS・PaaS・IaaSを、残る仕事で読む
三つの言葉は、「どこまでをサービスとして使うか」を整理するためのものです。名称を覚えるより、自社が管理する対象を確認すると理解しやすくなります。
SaaS:完成したアプリを使う
メール、共同作業、会計などの機能をアプリとして利用する形です。利用者がサーバーのOSを直接更新しない場合が多く、業務で使う設定や利用者管理に集中できます。
ただし、利用者の招待、権限、公開・共有範囲、データの保存方針は確認が必要です。ブラウザーだけで使うものも、端末側のアプリと組み合わせるものもあり、「SaaSは一切インストール不要」と決めつけません。
PaaS:アプリを動かす基盤を使う
開発したアプリを動かすための基盤を利用する形です。仮想マシンやOSの管理を事業者が担う範囲がありますが、自社のアプリ、データ、アクセス設定、使うライブラリなどの仕事は残ります。
「環境を何も設定しなくてよい」わけではありません。どの設定を自社が持ち、更新時に何を確認するかを、選ぶ製品に合わせて整理します。
IaaS:計算・保存・ネットワークの資源を使う
仮想マシンなどの資源を利用する形です。構成を選ぶ余地が大きい分、OSやアプリの更新、アクセス設定、監視などを利用者が担う範囲も広くなります。
たとえばAWSは、EC2を使う場合の利用者側のOSやアプリ等の管理を説明しています。一方、別の管理されたサービスでは、基盤側の責任の分担が異なります。AWSの共有責任モデル
同じ会社のサービスでも、分担は違う
AWS、Microsoft、Googleは、いずれも多くの種類のサービスを提供しています。会社名そのものをIaaSと分類したり、「この会社なら必ず安い・安全」と評価したりしないでください。
表が収まらない場合は、横にスクロールできます
| 公式資料で確認する例 | 分類を読む手掛かり | 名前だけで決めず確認すること |
|---|---|---|
| AWSのEC2と、より管理されたサービス | 資源を借りる範囲と、基盤を任せる範囲が異なる | OS、アプリ、データ、アクセス設定 |
| Azure Virtual Machines、App Service、Microsoft 365 | 仮想マシン、アプリ基盤、完成アプリという違い | 実際のプランと構成での管理範囲 |
| Google Compute Engine、App Engine、Google Workspace | 同じ事業者でも使う層が異なる | 利用者側に残るデータとアクセスの管理 |
AzureもGoogle Cloudも、サービスモデルと利用者の責任を説明しています。保存サービスなどの分類の仕方が各資料で同一とは限らないため、名称を横並びにするより、実際の作業を一つずつ照合します。Azureの責任分担、Google Cloudの責任分担
4. 便利さを生かせる条件を確認する
設備を自社で持つ負担を変えられる
自社で機械を購入・設置する代わりに、必要な機能を契約できます。ただし、導入、移行、設定、社内の運用、サポートの費用がなくなるわけではありません。購入費だけと月額料金だけを比べず、同じ機能と運用範囲で比較します。
必要に応じて資源を増減できる
サービスによって、計算能力、台数、保存容量などを変更できます。大きい資源へ変えることと、複数に分けることは同じではありません。どの資源を増やすと何が改善するかは、アプリの構造や処理によって変わります。
増やせる枠、設定、準備時間、費用も確認します。「クラウドだから急なアクセス増に何もしなくても対応する」とは言えません。自動で増減する機能を使う場合も、設定と上限、動作の確認が必要です。
複数の場所から使いやすくできる
ネットワークを通じて利用できるため、社外の端末から使う構成にもできます。ただし、本人確認やアクセス条件、端末の管理は必要です。逆に、自社設置の仕組みでも、適切な接続方法を用意すれば社外から使える場合があります。設置方式だけで利用場所の可否を決めません。
5. 「複数に保存」と「元に戻せる」を混同しない
保存場所を複数に分けることは、ある場所の故障に備える考え方です。一方、誤って消したデータや不適切に書き換えたデータを戻すには、戻したい時点のデータが残り、利用できる必要があります。
クラウドの保存サービスなら、何も設定しなくても望む期間の履歴がすべて残る、とは限りません。たとえばAmazon S3のバージョニングは、明示的に有効にする機能です。保存したバージョンは、それぞれ保存量に応じた費用に関わります。S3のバージョニングの説明
これは「S3ならすべてのバックアップが完成する」という意味でもありません。削除の仕組み、保持する世代、アクセス権、別の障害に備える必要などを、用途に合わせて確認します。
表が収まらない場合は、横にスクロールできます
| 言葉 | 分けて考えること |
|---|---|
| ストレージ | データを置くための資源。どこまでの履歴を残すかは別の条件 |
| 冗長化 | 一部の故障などに備える構成。誤削除からの復元と同じではない |
| バックアップ | 必要な時点へ戻すためにデータ等を保存する仕組み |
| 復元・復旧 | 保存したものから、データや必要な機能を使える状態へ戻す作業 |
バックアップの一覧が見えるだけでは、復旧できる確認にはなりません。AWSの指針でも、データが読み出せるか、許容するデータ損失と復旧時間に収まるかを試すことを説明しています。バックアップからの復旧確認
担当者には、「いつの何を戻せるか」「誰が戻すか」「どの確認まで終われば業務を再開できるか」を尋ねます。この記事で実際のクラウドへ接続したり、復旧を試したりしたわけではありません。
6. 費用は、使う量と管理する作業に分ける
料金を比較する前に、何の利用量が変わると費用が増えるのかを把握します。保存容量だけでなく、外へ送るデータ、処理回数、保存世代、支援の範囲など、実際に選ぶサービスの条件を確認してください。
次の表は計算方法を示す架空の料金です。実在サービスの価格、相場、見積もりではありません。税、通貨、ほかの機能の費用はこの例に含めていません。
表が収まらない場合は、横にスクロールできます
| 項目 | 仮の入力 | 小計 |
|---|---|---|
| 基本料金 | 月3,000円 | 3,000円 |
| データ保存 | 100GB × 20円 | 2,000円 |
| 外部へのデータ転送 | 50GB × 10円 | 500円 |
| バックアップ | 月1,000円 | 1,000円 |
| 合計 | 3,000 + 2,000 + 500 + 1,000 | 6,500円 |
同じ仮の単価で、転送だけが200GBに増えると、転送費は2,000円、合計は8,000円になります。容量が変わらなくても、別の利用量で合計が変わる例です。運用を担当する人の作業時間や、移行・復旧・終了時の費用も、請求額とは別に比較します。
予算通知と、利用を止める上限は別
通知を設定しただけで、それ以上の請求が発生しなくなるとは限りません。Google Cloudの現行資料も、alerts-onlyの予算は費用を通知するもので、利用や支出を自動的に制限しないと区別しています。Google Cloudの予算と通知
同じ資料には、サービスの対応条件がある支出上限機能のプレビューへの案内もあります。したがって、「クラウドの予算機能はどれも上限を設定できない」とも言い切れません。使う機能が通知なのか、制限なのか、対象外の費用はないかを、そのサービスの現行仕様で確認します。この説明ではプレビューの設定手順や対応範囲を検証していません。
予算を管理するなら、通知先だけでなく「通知を受けた人が何を判断するか」を決めます。自動停止が業務へ与える影響もあるため、単に止めればよいとは限りません。
7. 選ぶ前に、担当と取り出し方を決める
クラウドの導入で見落としやすいのは、契約時よりも、人が替わるときや利用をやめるときの作業です。最初から次の表を埋めておくと、事業者任せにしてよい範囲と、自社で決める範囲を分けられます。
表が収まらない場合は、横にスクロールできます
| 確認対象 | 契約前に尋ねること |
|---|---|
| 用途 | 完成したアプリで足りるか、独自の処理が必要か |
| データ | 何を保存し、誰が閲覧・編集・削除できるか |
| 管理者 | 契約名義、支払い、利用者管理を誰が引き継ぐか |
| 更新・障害 | アプリや設定を誰が更新し、異常時に誰へ連絡するか |
| 復旧 | どの範囲を、いつの状態へ、どの手順で戻せるか |
| 費用 | 通知先、利用量の変動、支援や取り出しの費用は何か |
| 移行・終了 | データをどの形式で取り出せるか、別の仕組みで使えるか |
たとえば、業務メールと文書共有が目的なら、まず完成したアプリの機能、権限、取り出し条件を比較できます。独自の予約処理を作るなら、アプリ基盤や仮想マシンの選択に加え、開発と更新を担う人が必要です。同じ「クラウドを使う」でも、必要な判断は違います。
最小の確認は、サービス名を一つ選び、自社と事業者の担当を書き分けることです。答えが分からない欄は、営業や運用担当への質問として残します。いきなり契約や移行を始める必要はありません。
クラウドは、仕事の一部をサービスとして利用する選択肢です。何を任せ、何を自社に残し、費用と復旧をどう確認するかが分かれば、有名な名称や曖昧な安心感に頼らず比較できます。