公開2026.07.17更新2026.09.09 インフラ・クラウド

クラウドストレージとは？仕組み・3つの種類とオンプレとの違いを実装目線で解説

クラウドストレージとは、インターネットを介して事業者のデータセンターへデータを預け、ブラウザやAPIから読み書きするストレージサービスです。自社でディスクやサーバを持たなくても必要なだけ容量を借りて使え、預けたデータは複数の設備へ自動で複製されて残ります。この記事では、保管の仕組み、ファイル・ブロック・オブジェクトの3種類と使い分け、AWS CLIでバケットを作って公開遮断と暗号化まで通す手順、整合性モデル、階層とegressの費用構造、そしてオンプレミスを残すべき場面を、判断に使える形で整理します。

まとめ：クラウドストレージの本質と採用判断の物差し

クラウドストレージの核は、ハードウェアの調達・冗長化・故障対応という重い運用を事業者に預け、自社は容量とアクセス権だけを扱えばよくなる点にあります。ディスクが1本壊れてもデータは失われず、容量の増減も設定変更で済みます。設備を持つ責任を手放して使った分だけ払う形が、オンプレミスとの根本的な違いです。費用構造や拡張性の差はオンプレミスとクラウドの違いとは？コスト・セキュリティ・拡張性で比較し選び方まで解説に整理してあります。

採用の物差しははっきりしています。新規に立ち上げるシステムのデータ保管は、クラウドストレージが第一候補。オンプレミスや専用ストレージを残すのは、1バイト単位の低レイテンシな書き換えが要る、規制でデータの所在が縛られる、といった要件がある場合に絞られます。以下では判断の根拠を、定義・仕組み・種類・構築手順・整合性・費用・採用判断の順に、公式ドキュメントの記述と動かせる設定例で説明します。

クラウドストレージとは何か、データセンターへ預けて借りるストレージ

クラウドストレージは、事業者が運用するデータセンターの記憶領域をネットワーク越しに間借りする仕組みです。手元の端末にファイルの実体はなく、こちらは参照と操作の権限を持つだけになります。

データセンターの実体へブラウザやAPIからアクセスする仕組み

ユーザーがファイルを保存すると、その実データはインターネットを通じて事業者のデータセンターへ送られ、ディスク群のどこかに書き込まれます。読み出すときは、逆にネットワーク越しに実体を取り寄せる形。人が使う場面ではブラウザ、システムから使う場面ではAPIが窓口です。物理的なディスクの場所を意識せず、容量という抽象化された資源として扱えるのが土台の性質になります。

Amazon S3の公式ドキュメントは、この構造を「バケットというコンテナに、実データとそれを説明するメタデータの組であるオブジェクトを格納する」と説明し、オブジェクトはバケット名・キー・（バージョニング有効時は）バージョンIDの組で一意に決まると明記しています（AWS公式・What is Amazon S3?／2026年9月時点）。フォルダに見えるパスは、キー名の区切り文字が表示上そう見えているだけで、階層そのものは存在しません。ディレクトリの移動が重い、リネームが実質コピーになる、という癖はここから来ています。

ストレージという上位概念のなかでクラウドストレージが占める位置づけ

そもそもストレージとは、データを保存しておく記憶装置や記憶領域の総称で、手元のSSDやHDD、社内のファイルサーバも含みます。クラウドストレージは、その保存先を自社の外にある事業者のデータセンターへ移し、ネットワーク経由で使う形態。記憶装置の種類を含めた全体の見取り図はストレージとは？種類・HDDとSSDの違い・企業のクラウド選定まで解説【2026年】で整理しました。本記事は、そのうちクラウドに預ける形態を技術面から掘り下げます。

クラウドストレージの3つの種類とそれぞれのデータの持ち方の違い

データの持ち方でファイル・ブロック・オブジェクトの3種類に分かれ、どれを選ぶかで向く用途もアクセスの仕方も変わります。

ファイル・ブロック・オブジェクトそれぞれのデータ構造と向く用途

ファイルストレージは、フォルダの階層のなかにファイルを置く、社内のファイルサーバと同じ持ち方。複数の端末から共有マウントする用途に向き、AWSではNFSでマウントするAmazon EFSがこれにあたります。ブロックストレージは、データをボリュームで切り出して細かいブロックに分けて管理する方式で、サーバに接続する仮想ディスクとして使い、データベースやOSの起動領域のように速い部分更新が要る用途に向く形。AWS公式はAmazon EBSを「EC2インスタンスで使うブロックレベルのストレージボリューム」と定義しています（AWS公式・What is Amazon EBS?）。オブジェクトストレージは、実データにメタデータと一意なキーを付けた「オブジェクト」として平置きし、キーを指定して一発で取り出す方式です。階層を持たないため格納数が億単位でも引きが重くならず、配信やバックアップ、分析用データの蓄積が守備範囲になります。

種類	データの持ち方	主な用途	代表サービス
ファイル	フォルダ階層で管理	共有ファイルサーバ	Amazon EFS
ブロック	ボリュームを分割	DB・OS起動領域	Amazon EBS
オブジェクト	キーで平置き	配信・バックアップ・分析	Amazon S3

クラウドではオブジェクトストレージが標準の保管先になりやすい理由

クラウドでデータを溜める場面では、オブジェクトストレージが標準の受け皿になります。容量の上限を意識せず積める設計で、HTTPのAPIで読み書きでき、単価も3種類のなかで抑えやすく、多くの事業者がS3互換APIを備えているためです。中心に居るS3の仕組みと料金体系はAmazon S3とは？ストレージクラスと料金・採用判断で、Google Cloud側の製品はCloud Storage（GCS）とは？S3との違いで掘り下げました。S3互換APIの詳細とブロックとの差はオブジェクトストレージとは？仕組みとS3互換APIにあります。用途から逆算し、共有マウントが要ればファイル、部分更新が要ればブロック、それ以外の大量保管はオブジェクト、と切り分けるのが実装の定石です。

AWS CLIでバケットを作成し公開遮断と暗号化まで設定する手順

クラウドストレージはコンソールでも作れますが、案件で再現性が要る以上、コマンドで組み立てる形にしておくほうが後から楽です。ここではAWS CLIを例に、バケットを1つ作って安全な既定値まで持っていく流れを置きました。署名付きURLの発行まで含む運用はAWS S3の使い方｜CLIでのバケット作成から権限設計までで扱っています。

バケット作成から公開ブロックとバージョニング設定までのコマンド

東京リージョンにバケットを作り、公開アクセスを4項目すべて遮断し、バージョニングと暗号化を有効にするまでを4コマンドで通します。バケット名はグローバルに一意である必要があるため、案件名と年で衝突を避けます。

aws s3api create-bucket --bucket example-media-2026 --region ap-northeast-1 --create-bucket-configuration LocationConstraint=ap-northeast-1

aws s3api put-public-access-block --bucket example-media-2026 --public-access-block-configuration "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

aws s3api put-bucket-versioning --bucket example-media-2026 --versioning-configuration Status=Enabled

aws s3api put-bucket-encryption --bucket example-media-2026 --server-side-encryption-configuration '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"aws:kms","KMSMasterKeyID":"alias/s3-media"}}]}'

2行目のブロックパブリックアクセスは、AWS公式が「バケットレベルで既定として有効」と明記しており、新規バケットでは本来かかっている設定です（AWS公式・Blocking public access）。それでも明示的に打つのは、IaCから作った既存バケットで外れている事故を一括点検できる形にしておくため。3行目のバージョニングはバケット単位のステータスです（AWS CLI・put-bucket-versioning）。4行目のSSE-KMSは鍵をKMSで管理して監査ログに残す方式（AWS公式・Server-side encryption with AWS KMS keys）。

公式に書かれた待ち時間の注意も一つ。バケットの設定変更は結果整合性で伝わるため、バージョニングを初めて有効にしたあとは、オブジェクトへPUTやDELETEを投げる前に15分待つことをAWSが推奨しています。CI上でバケット作成と初回アップロードを続けて走らせる作りは、想定外の挙動を踏む典型例です。

ライフサイクル規則でストレージ階層を自動で移す設定ファイル例

保管費を下げる仕掛けは、階層を手で移すのではなくライフサイクル規則に任せます。次はmediaプレフィックス配下を30日で低頻度アクセス階層へ、120日でGlacier Instant Retrievalへ移す設定です。

{
  "Rules": [
    {
      "ID": "media-tiering",
      "Status": "Enabled",
      "Filter": {
        "And": {
          "Prefix": "media/",
          "ObjectSizeGreaterThan": 131072
        }
      },
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 120, "StorageClass": "GLACIER_IR" }
      ]
    }
  ]
}

aws s3api put-bucket-lifecycle-configuration --bucket example-media-2026 --lifecycle-configuration file://lifecycle.json

この設定には公式ドキュメントの制約が2つ効いています。1つ目は最小サイズで、AWSは2024年9月から「128KB未満のオブジェクトは既定でどの階層へも移行しない」挙動に変えました。上の例の131072バイトはこの既定に合わせた値。2つ目は最小保存期間で、S3 Standard-IAの30日を満たす前に次の階層へ移す規則は1本では書けません。30日でStandard-IAへ移したなら次の移行は60日以降に置く必要があり、120日はその制約を満たしています（AWS公式・Transitioning objects using S3 Lifecycle）。

可用性を支えるレプリケーションと、結果整合性という実装上の前提

ディスク故障でデータを失わないのは、裏で複製が保たれているからです。ただし複製の仕組みは実装者に前提を要求します。

複数の設備へデータを自動で複製して冗長化する可用性の設計思想

預けたデータは、1台のディスクにだけ書かれるのではなく、複数のディスク、多くは複数のデータセンターへ自動で複製されます。1棟の設備に障害が起きても別の複製から読み出せる点が持ち味。この冗長化を事業者が受け持つからこそ、利用側はRAID構成やバックアップ設備の設計から解放されます。

数値で見ると差がはっきりします。AWSはS3の全クラスについて耐久性を99.999999999％（9が11個）と設計値で示し、可用性はS3 Standardが99.99％、単一アベイラビリティゾーンに置くS3 One Zone-IAが99.5％と段が付いています（AWS公式・Amazon S3 storage classes／2026年9月時点）。冗長化の範囲がリージョン内の複数ゾーンか単一ゾーンかで、この段が決まる構造です。

結果整合性（eventual consistency）が読み書きに及ぼす注意点

複数の複製を持つ設計には、書き換えた直後に別の場所から読むと古い複製が返りうるという代償が付きものでした。これを結果整合性（eventual consistency）と呼びます。ただし主要サービスの現状は、この前提から一段進みました。AWSはS3について「全リージョンでオブジェクトのPUTとDELETEに対する強い読み取り整合性を提供する」と明記しており、新規書き込みも上書きも削除も、成功応答のあとの読み取りには最新が返ります（AWS公式・S3 data consistency model）。Google CloudもCloud Storageの書き込み後読み取り・削除後読み取り・一覧取得を強い整合性として列挙しています（Google Cloud公式・Consistency）。

では結果整合性を気にしなくてよいかというと、対象がずれただけです。S3で結果整合なのはバケット設定側で、削除直後の一覧に消したはずのバケットが残る、バージョニング有効化の反映に時間差が出る、といった挙動が公式に明記されています。Cloud Storage側も、アクセス権の付与・剥奪と削除後のバケット再作成が結果整合で、反映におおむね1分前後。注意点は「データ面」から「権限とバケット構成の面」へ移りました。権限を付けた直後にジョブを走らせる作りが、いまの踏みやすい落とし穴です。

コストとセキュリティ、クラウドストレージの運用で効いてくる論点

使った分だけ払える一方、費用の構造を知らないと請求が膨らみます。守り方とあわせて、運用で効く二つの論点を押さえます。

ストレージ階層と転送量課金（egress）で決まる費用の構造

クラウドストレージの費用は、保管している容量だけでは決まりません。アクセス頻度に応じたストレージ階層があり、頻繁に読むデータは単価の高い標準階層、めったに触らないデータは安い低頻度・アーカイブ階層へ置くと保管費を抑えられます。見落としやすいのは、データを外へ取り出すときの転送量課金（egress）。大量のデータを頻繁にダウンロードする使い方だとこの転送費が主役になりがちで、AWSの料金ページもストレージ・リクエスト・データ転送を別建てで並べています（AWS公式・Amazon S3 pricing）。

階層を下げる判断では、取り出し時間と早期削除の料金も一緒に見ます。アーカイブ階層は最小保存期間を待たずに消すと残り日数ぶんを請求されるためです。さらにS3のGlacier系では、1件あたり8KB（S3 Standard料金）と32KB（移行先のGlacier料金）の管理用オーバーヘッドが加算され、小さなファイルを大量にアーカイブすると節約が相殺されます。取り出し時間の内訳はAmazon S3 Glacierとは？取り出し時間・料金・採用判断、法人向けプランの比較はクラウドストレージおすすめ比較｜法人の選び方・料金・容量にまとめました。

IAMと暗号化で組み立てるアクセス制御・権限・鍵管理の考え方

データを外部の設備へ預ける以上、誰が何にアクセスできるかの制御が守りの中心になります。IAM（Identity and Access Management）で、利用者やプログラムごとに読み取り・書き込み・削除の権限を細かく割り当て、バケットやオブジェクトの単位で公開範囲を絞るのが原則。ユーザー・ロール・ポリシーの使い分けはAWS IAMとは？権限設計のベストプラクティスで扱っています。

あわせて、保管時と通信経路の暗号化を有効にし、データそのものと経路の両方を守ります。公開設定の付け間違いによる漏えいは典型的な事故なので、既定を非公開に寄せる運用が安全。AWS公式もACLではなくバケットポリシーとIAMポリシーでの制御を推奨し、S3 Object Ownershipの既定でACLを無効にしています。前掲のCLI例で公開ブロックを4項目まとめて打つのは、この推奨に沿って「開いていないこと」を担保するためです。

3大クラウドのストレージ階層と最小保存期間を表で並べて比較する

階層の名前は事業者ごとに違いますが、並べると設計思想はほぼ同じで、差が出るのは最小保存期間の刻みです。移行のスケジュールはこの日数から引くと手戻りが減ります。

サービス	低頻度アクセス階層	最長期アーカイブ階層
Amazon S3	Standard-IA 30日	Deep Archive 180日
Cloud Storage	Nearline 30日	Archive 365日
Azure Blob Storage	クール層 30日	アーカイブ層 180日

数値の出どころは各社の公式ドキュメントです。S3はStandard-IAとOne Zone-IAが30日、Glacier Instant RetrievalとFlexible Retrievalが90日、Deep Archiveが180日。Cloud StorageはNearlineが30日、Coldlineが90日、Archiveが365日と、S3より1段長いアーカイブ側の刻みが特徴。上位側にはRapid storageが加わりました（Google Cloud公式・Storage classes）。

Azure Blob Storageはホット・クール・コールド・アーカイブの4層に、使用パターンを見てオンライン3層のあいだを自動で移す「スマート層」が加わった構成。クール30日・コールド90日・アーカイブ180日という最小保持で、アーカイブ層は読み取りも変更もできずリハイドレートに最大15時間かかると明記されています（Microsoft Learn・BLOBデータに関するアクセス層）。S3との差分はAzure Blob Storageとは？アクセス層とS3との違いで掘り下げました。階層選びは料金表より先に取り出し要件から入るのが安全です。

受託開発でクラウドストレージを主の保管先に採用する判断と線引き

ここは検索意図の核心であり、独自に言い切る論点です。新規に構築するシステムのデータ保管はクラウドストレージを標準の第一候補に据え、オンプレミスや専用ストレージを残すのは、低レイテンシの部分更新か、データ所在の規制という明確な要件がある場合に絞ります。

クラウドストレージを主たる保管先に据えてよいと言える前提条件

クラウドを主に据えてよい前提は具体的です。第一に、保管するデータ量が読みにくく、増減に応じて容量を伸縮させたい場合。第二に、故障対応やバックアップ設備の設計を事業者に預けたい場合。第三に、複数の拠点やアプリから同じデータへアクセスさせたい場合。当てはまるなら自前で設備を抱える理由は薄く、大量保管はオブジェクト、仮想ディスクが要る部分はブロックという組み合わせが標準の形です。

オンプレミスや専用ストレージを残すべき場面の見極めと接続支援

逆に、クラウドへ寄せない判断が要る場面もはっきりしています。ミリ秒単位の低レイテンシで1バイト単位の書き換えを繰り返す用途は、オブジェクトストレージの全体差し替え前提と噛み合いません。また、法令や契約でデータの保管国・保管場所が縛られる場合、預け先の所在を選べないサービスは要件を満たせない領域。この場合はNextcloudとは？自社構築するファイル共有基盤で扱うセルフホスト型を選べば、保存場所を自社統制下に置いたまま操作性を確保できます。

全面移行が難しいなら、段階を切るのが現実解。既存のファイルサーバをいきなり畳まず、オンプレ側にゲートウェイを置いてバックエンドだけクラウドへ寄せる構成はAWS Storage Gatewayとは？オンプレ段階移行の構成で整理しました。判断の物差しは単純で、伸縮性と運用の軽さが効くならクラウド、レイテンシ・規制・転送費のいずれかが強い制約になるなら専用構成を残す、この二択。一創では、ストレージ種類の選定からクラウド基盤の設計・構築までをインフラ構築（AWS・Google Cloud・Azure）として引き受けています。

よくある質問

クラウドストレージの理解と技術選定でつまずきやすい点を、検索されやすい質問に沿って簡潔に答えます。

クラウドストレージとは何ですか？

インターネットを介して事業者のデータセンターへデータを預け、ブラウザやAPIから読み書きするストレージサービスです。自社でディスクを持たずに必要なだけ容量を借りて使え、預けたデータは複数の設備へ自動で複製されて残ります。設備の運用を事業者に任せ、容量とアクセス権だけを扱えばよくなる点が特徴。

クラウドストレージにはどんな種類がありますか？

データの持ち方でファイル・ブロック・オブジェクトの3種類に分かれます。ファイルは共有マウント向き、ブロックは仮想ディスクとしてデータベースやOS起動領域向き、オブジェクトはキーで平置きして大量保管や配信向き。クラウドで大量に溜める用途では、オブジェクトが標準の保管先になります。

クラウドストレージとオンプレミスはどちらを選ぶべきですか？

新規システムのデータ保管は、伸縮性と運用の軽さが効くクラウドストレージが第一候補です。専用ストレージを残すのは、ミリ秒単位の低レイテンシな部分更新が要る、保管場所が規制で縛られる、egressの費用が自前設備を上回る、といった要件がある場合に絞られます。

クラウドストレージの費用はどう決まりますか？

保管容量に加え、アクセス頻度で分かれるストレージ階層の単価と、データを外へ取り出すときの転送量課金（egress）で決まります。頻繁に読むデータは標準階層、めったに触らないデータは低頻度・アーカイブ階層へ置き、大量ダウンロードを避けることで抑えられる構造です。

クラウドストレージのセキュリティはどう担保しますか？

IAMで利用者やプログラムごとに読み取り・書き込み・削除の権限を割り当て、バケットやオブジェクトの単位で公開範囲を絞ります。あわせて保管時と通信経路の暗号化を有効にするのが基本。既定を非公開に寄せ、公開が要る範囲だけを明示的に開ける運用が漏えいを防ぎます。

クラウドストレージは今も結果整合性を前提に組む必要がありますか？

オブジェクトの読み書きについては前提が変わりました。AWSはS3が全リージョンでPUTとDELETEに強い読み取り整合性を提供すると明記し、Google CloudもCloud Storageの書き込み後読み取りと一覧取得を強い整合性として挙げています。ただしバケット設定やアクセス権の反映は依然として結果整合で、権限付与やバケット再作成の直後は時間差が出ます。