Google Cloud 完全攻略 Ep.5: Cloud Storageで学ぶオブジェクトストレージ運用入門｜SESエンジニア向け実践ガイド

⚡ 3秒でわかる！この記事のポイント

Cloud StorageはGCPの中核を担うオブジェクトストレージで、あらゆるサービスのデータ基盤として機能する
ストレージクラスの使い分け・ライフサイクル管理・署名付きURLなど、コスト最適化と運用自動化の実践テクニックを網羅
Cloud CDN連携やCloud Functionsとの自動化パイプラインなど、SES現場で差がつく応用パターンまで解説

📚 この記事は「Google Cloud 完全攻略」シリーズの一部です

SES案件でクラウドインフラに携わるエンジニアにとって、オブジェクトストレージは避けて通れないテーマです。Webアプリケーションの画像・動画ホスティング、ログの長期保管、データレイクの構築、バックアップ——あらゆる場面でストレージは必要になります。

Google Cloudにおけるオブジェクトストレージの中心がCloud Storageです。AWSのS3、AzureのBlob Storageに相当するサービスで、ほぼ無制限のスケーラビリティと99.999999999%（イレブンナイン）の耐久性を備えています。

本記事では、Cloud Storageの基本操作から、ストレージクラスの使い分け、ライフサイクル管理、署名付きURL、そしてCloud CDNやCloud Functionsとの連携まで、SES現場で即活用できる知識を体系的に解説します。

Cloud Storageとは？——GCPのデータ基盤を理解する

Cloud Storageは、Google Cloudが提供するフルマネージドなオブジェクトストレージサービスです。ファイルシステムのような階層構造ではなく、フラットな名前空間でオブジェクト（ファイル）を管理するのが特徴です。

Cloud Storageの基本概念

バケット（Bucket）: オブジェクトを格納するコンテナ。グローバルに一意な名前が必要
オブジェクト（Object）: バケット内に保存される個々のデータ（ファイル）
メタデータ: オブジェクトに付与される属性情報（Content-Type、カスタムメタデータなど）
ACL / IAM: アクセス制御の仕組み。IAMポリシーによる**均一アクセス制御（Uniform）**が推奨

SES案件での活用シーン

Cloud Storageは、GCPのほぼすべてのサービスと連携するため、SES案件での遭遇率は極めて高いサービスです。

Webアプリの静的アセット配信: 画像・CSS・JSファイルのホスティング
データレイク構築: Ep.3で紹介したBigQueryへの取り込み元として
ログ・監査データの長期保存: Coldline/Archive Storageでコスト最小化
機械学習データセット管理: Vertex AIの学習データ格納先
バックアップ・ディザスタリカバリ: Cloud SQLやFirestoreのエクスポート先

クラウドエンジニアのSES案件ガイドでも触れていますが、ストレージ設計の経験は、インフラ系案件では必須スキルです。

Cloud Storageのアーキテクチャ概要

バケットの作成と基本操作

バケットの作成

バケットはgsutilコマンドまたはgcloud storageコマンドで作成します。2026年現在、gcloud storageが推奨されています。

# バケットの作成（東京リージョン）
gcloud storage buckets create gs://my-app-assets-prod \
    --location=asia-northeast1 \
    --default-storage-class=STANDARD \
    --uniform-bucket-level-access

# バケットの一覧確認
gcloud storage buckets list

バケット作成時の主要オプションを整理します。

オプション	説明	推奨設定
`--location`	リージョンまたはマルチリージョン	`asia-northeast1`（東京）
`--default-storage-class`	デフォルトのストレージクラス	用途に応じて選択
`--uniform-bucket-level-access`	均一アクセス制御	常に有効推奨
`--public-access-prevention`	公開アクセス防止	内部利用時は`enforced`

オブジェクトのアップロード・ダウンロード

# 単一ファイルのアップロード
gcloud storage cp ./local-file.png gs://my-app-assets-prod/images/

# ディレクトリを再帰的にアップロード
gcloud storage cp -r ./dist/ gs://my-app-assets-prod/static/

# ダウンロード
gcloud storage cp gs://my-app-assets-prod/images/logo.png ./

# オブジェクトの一覧表示
gcloud storage ls gs://my-app-assets-prod/images/

# オブジェクトの削除
gcloud storage rm gs://my-app-assets-prod/images/old-file.png

メタデータとContent-Typeの設定

正しいContent-Typeを設定することで、ブラウザでの表示やCDN配信が適切に動作します。

# Content-Typeを指定してアップロード
gcloud storage cp ./data.json gs://my-app-assets-prod/ \
    --content-type="application/json"

# カスタムメタデータの設定
gcloud storage objects update gs://my-app-assets-prod/report.pdf \
    --custom-metadata="department=engineering,version=2.1"

# メタデータの確認
gcloud storage objects describe gs://my-app-assets-prod/report.pdf

ストレージクラスの使い分け——コスト最適化の鍵

Cloud Storageには4つのストレージクラスがあり、データのアクセス頻度に応じて使い分けることでコストを大幅に削減できます。

ストレージクラス比較

クラス	最低保存期間	保存料金/GB/月	読み取り料金/GB	ユースケース
Standard	なし	$0.023	$0.012	頻繁にアクセスするデータ
Nearline	30日	$0.013	$0.01 + 読取料	月1回程度のアクセス
Coldline	90日	$0.006	$0.02 + 読取料	四半期に1回程度
Archive	365日	$0.0025	$0.05 + 読取料	年1回以下・長期保管

※料金は東京リージョン（asia-northeast1）の2026年3月時点の参考値です。

使い分けの判断フロー

毎日アクセスするデータ → Standard
月に数回アクセスするバックアップ → Nearline
四半期ごとのレポートやアーカイブ → Coldline
法令で保存義務があるが通常参照しないデータ → Archive

# Nearlineクラスでバケットを作成
gcloud storage buckets create gs://my-backup-nearline \
    --location=asia-northeast1 \
    --default-storage-class=NEARLINE

# 個別オブジェクトのストレージクラスを変更
gcloud storage objects update gs://my-app-assets-prod/old-report.pdf \
    --storage-class=COLDLINE

Ep.1のGCP基礎で設定した予算アラートと組み合わせれば、ストレージコストの急増を即座に検知できます。

ライフサイクル管理——運用の自動化

ストレージクラスの手動変更は非現実的です。ライフサイクルルールを設定すれば、条件に基づいてオブジェクトのクラス変更や削除を自動化できます。

ライフサイクルルールの設定

JSON形式でルールを定義し、バケットに適用します。

{
  "rule": [
    {
      "action": {
        "type": "SetStorageClass",
        "storageClass": "NEARLINE"
      },
      "condition": {
        "age": 30,
        "matchesStorageClass": ["STANDARD"]
      }
    },
    {
      "action": {
        "type": "SetStorageClass",
        "storageClass": "COLDLINE"
      },
      "condition": {
        "age": 90,
        "matchesStorageClass": ["NEARLINE"]
      }
    },
    {
      "action": {
        "type": "SetStorageClass",
        "storageClass": "ARCHIVE"
      },
      "condition": {
        "age": 365,
        "matchesStorageClass": ["COLDLINE"]
      }
    },
    {
      "action": {
        "type": "Delete"
      },
      "condition": {
        "age": 730
      }
    }
  ]
}

# ライフサイクルルールの適用
gcloud storage buckets update gs://my-app-logs \
    --lifecycle-file=lifecycle.json

# 現在のルールを確認
gcloud storage buckets describe gs://my-app-logs \
    --format="json(lifecycle)"

上記の設定では、オブジェクトが以下のように自動遷移します。

Standard（0〜30日）→ Nearline（30〜90日）→ Coldline（90〜365日）→ Archive（365〜730日）→ 削除

これだけで、手動管理なしにストレージコストを最大で90%以上削減できます。SES案件のインフラ設計レビューでも、ライフサイクル設定の有無は必ず確認されるポイントです。

署名付きURL——セキュアなファイル共有

バケットを公開せずに、一時的なアクセスURLを発行するのが署名付きURL（Signed URL）です。ユーザーへのファイルダウンロードや、クライアントからの直接アップロードに活用します。

署名付きURLの生成

# ダウンロード用の署名付きURL（有効期限1時間）
gcloud storage sign-url gs://my-app-assets-prod/reports/monthly-2026-02.pdf \
    --duration=1h

# アップロード用の署名付きURL
gcloud storage sign-url gs://my-app-assets-prod/uploads/user-avatar.png \
    --duration=15m \
    --http-verb=PUT \
    --headers="Content-Type=image/png"

アプリケーションからの署名付きURL生成（Node.js）

Cloud Runなどのアプリケーションから動的に署名付きURLを生成するパターンは、SES案件で非常によく見られます。

const { Storage } = require('@google-cloud/storage');
const storage = new Storage();

async function generateSignedUrl(bucketName, fileName) {
  const options = {
    version: 'v4',
    action: 'read',
    expires: Date.now() + 60 * 60 * 1000, // 1時間
  };

  const [url] = await storage
    .bucket(bucketName)
    .file(fileName)
    .getSignedUrl(options);

  return url;
}

// アップロード用
async function generateUploadUrl(bucketName, fileName, contentType) {
  const options = {
    version: 'v4',
    action: 'write',
    expires: Date.now() + 15 * 60 * 1000, // 15分
    contentType,
  };

  const [url] = await storage
    .bucket(bucketName)
    .file(fileName)
    .getSignedUrl(options);

  return url;
}

この手法を使えば、アプリケーションサーバーを介さずに、クライアントから直接Cloud Storageにファイルをアップロードできます。Ep.2のCloud Runと組み合わせれば、スケーラブルなファイルアップロード機能を構築できます。

Cloud CDN連携——グローバル配信の高速化

Cloud StorageをCloud CDN（Content Delivery Network）のオリジンとして使用すると、世界中のエッジサーバーからコンテンツを高速配信できます。

Cloud CDNバックエンドの設定

# バケットをCDNバックエンドとして登録
gcloud compute backend-buckets create my-cdn-backend \
    --gcs-bucket-name=my-app-assets-prod \
    --enable-cdn

# URLマップの作成
gcloud compute url-maps create my-cdn-map \
    --default-backend-bucket=my-cdn-backend

# HTTPSプロキシの設定
gcloud compute target-https-proxies create my-cdn-proxy \
    --url-map=my-cdn-map \
    --ssl-certificates=my-ssl-cert

# フォワーディングルールの作成
gcloud compute forwarding-rules create my-cdn-rule \
    --global \
    --target-https-proxy=my-cdn-proxy \
    --ports=443

キャッシュ制御

# オブジェクトにキャッシュ制御ヘッダーを設定
gcloud storage objects update gs://my-app-assets-prod/static/app.js \
    --cache-control="public, max-age=31536000, immutable"

# HTMLファイルは短いキャッシュ
gcloud storage objects update gs://my-app-assets-prod/index.html \
    --cache-control="public, max-age=300, must-revalidate"

静的アセット（JS/CSS/画像）は長いキャッシュ期間、HTMLファイルは短い期間に設定するのがベストプラクティスです。

Cloud Functionsとの連携——自動処理パイプライン

Ep.4のCloud Functionsで紹介したCloud Storageトリガーを活用すれば、ファイルのアップロードをトリガーに自動処理を実行できます。

実践的なパイプライン例

[ユーザー] → 署名付きURLでアップロード → Cloud Storage (raw/)
                                              ↓ トリガー
                                     [Cloud Functions: バリデーション]
                                              ↓
                                     Cloud Storage (validated/)
                                              ↓ トリガー
                                     [Cloud Functions: 画像リサイズ]
                                              ↓
                                     Cloud Storage (processed/)
                                              ↓
                                     Cloud CDNで配信

// validateUpload.js - アップロード時の自動バリデーション
const functions = require('@google-cloud/functions-framework');
const { Storage } = require('@google-cloud/storage');

const storage = new Storage();
const MAX_FILE_SIZE = 10 * 1024 * 1024; // 10MB
const ALLOWED_TYPES = ['image/jpeg', 'image/png', 'image/webp'];

functions.cloudEvent('validateUpload', async (cloudEvent) => {
  const file = cloudEvent.data;
  const bucket = storage.bucket(file.bucket);
  const object = bucket.file(file.name);

  // raw/ プレフィックス以外は無視
  if (!file.name.startsWith('raw/')) return;

  const [metadata] = await object.getMetadata();

  // ファイルサイズチェック
  if (parseInt(metadata.size) > MAX_FILE_SIZE) {
    console.error(`ファイルサイズ超過: ${file.name} (${metadata.size} bytes)`);
    await object.delete();
    return;
  }

  // Content-Typeチェック
  if (!ALLOWED_TYPES.includes(metadata.contentType)) {
    console.error(`不許可のファイル形式: ${metadata.contentType}`);
    await object.delete();
    return;
  }

  // バリデーション通過 → validated/ に移動
  const destPath = file.name.replace('raw/', 'validated/');
  await object.move(destPath);
  console.log(`バリデーション通過: ${file.name} → ${destPath}`);
});

このパターンは、ユーザーがプロフィール画像やドキュメントをアップロードするWebアプリケーションで広く使われています。

セキュリティのベストプラクティス

均一アクセス制御（Uniform Bucket-Level Access）

ACL（アクセス制御リスト）ではなく、IAMポリシーのみでアクセスを管理する方式です。2026年現在、新規バケットではこの方式が強く推奨されています。

# 均一アクセス制御を有効化（作成時）
gcloud storage buckets create gs://my-secure-bucket \
    --uniform-bucket-level-access

# 既存バケットに適用
gcloud storage buckets update gs://my-existing-bucket \
    --uniform-bucket-level-access

公開アクセス防止

意図しない公開を防ぐため、組織ポリシーまたはバケット単位で公開アクセスを禁止します。

# バケット単位で公開アクセスを防止
gcloud storage buckets update gs://my-secure-bucket \
    --public-access-prevention=enforced

バージョニング

誤削除や上書きからデータを保護するため、重要なバケットではバージョニングを有効化します。

# バージョニングの有効化
gcloud storage buckets update gs://my-app-assets-prod \
    --versioning

# 過去バージョンの一覧
gcloud storage ls --all-versions gs://my-app-assets-prod/config.json

# 特定バージョンの復元
gcloud storage cp gs://my-app-assets-prod/config.json#1234567890 \
    gs://my-app-assets-prod/config.json

暗号化

Cloud Storageのデータは**デフォルトでGoogleが管理する鍵（Google-managed encryption）**で暗号化されます。より厳密な制御が必要な場合は、**CMEK（Customer-Managed Encryption Keys）**を使用します。

# Cloud KMSの鍵でバケットを暗号化
gcloud storage buckets update gs://my-secure-bucket \
    --default-encryption-key=projects/my-project/locations/asia-northeast1/keyRings/my-ring/cryptoKeys/my-key

Cloud Storage vs 他のGCPストレージ——使い分けガイド

GCPにはCloud Storage以外にも複数のストレージサービスがあります。適切に使い分けることが重要です。

サービス	種類	ユースケース
Cloud Storage	オブジェクトストレージ	ファイル保存、静的配信、バックアップ
Cloud SQL	リレーショナルDB	トランザクション処理、構造化データ
Firestore	ドキュメントDB	モバイル/Webアプリのリアルタイムデータ
Bigtable	広カラムDB	IoT、時系列データ、大規模分析
Memorystore	インメモリDB	キャッシュ、セッション管理
Filestore	ファイルストレージ	NFSマウントが必要なレガシーアプリ

判断の目安: 「ファイルとして保存・配信するもの」はCloud Storage、「クエリで検索・集計するデータ」はデータベースサービス（Cloud SQL、BigQuery等）を選びましょう。

gsutil vs gcloud storage——どちらを使うべきか

従来のCLIツールgsutilと、新しいgcloud storageコマンドの違いを整理します。

観点	gsutil	gcloud storage
位置づけ	レガシー	推奨（後継）
パフォーマンス	良好	大容量転送で高速
並列転送	`-m`オプション	デフォルトで並列
統合性	独立ツール	gcloud CLIの一部

新規開発ではgcloud storageを使用し、既存スクリプトのgsutilは段階的に移行するのが推奨です。

まとめ——Cloud Storageを制する者がGCPを制す

Cloud Storageは、GCPエコシステムのデータハブです。ほぼすべてのGCPサービスがCloud Storageと連携するため、このサービスを深く理解することは、GCP全体の理解に直結します。

ストレージクラスの使い分けでコストを最大90%削減
ライフサイクル管理で運用の完全自動化
署名付きURLでセキュアかつスケーラブルなファイル共有
Cloud CDN連携でグローバル配信を高速化
Cloud Functions連携でイベント駆動の自動処理パイプラインを構築

まずはGCPの基礎（Ep.1）でプロジェクトを作成し、本記事のコマンドを実際に試してみましょう。Ep.3のBigQueryと組み合わせて「Cloud Storageのログを自動的にBigQueryで分析する」パイプラインや、Ep.4のCloud Functionsと組み合わせたファイル処理の自動化は、SES案件のポートフォリオとして高く評価されます。

次回のGoogle Cloud 完全攻略もお楽しみに！

出典・参考資料

関連記事