2026年8月17日
2026年8月17日
GCPのCloud Storageの使い方(バケット作成・アップロード・公開設定・権限管理)
Google Cloud の Cloud Storage は、ファイルを「オブジェクト」として「バケット」に保存するオブジェクトストレージです。この記事では、gcloud コマンドでバケットを作り、ファイルを出し入れし、公開・非公開と権限を正しく設定し、ライフサイクルで古いデータを整理するところまでを説明します。WordPress のバックアップやメディアの保存先として使う場合の考え方も最後に触れます。
Cloud Storageの基本的な考え方
Cloud Storage は、サーバーのディスクのようにマウントして使うものではなく、HTTP の API でオブジェクトを置いたり取り出したりする仕組みです。まず次の用語を押さえておくと、画面やコマンドの意味が分かりやすくなります。
- バケット: オブジェクトを入れる箱。名前は Google Cloud 全体で一意である必要があり、後から名前やロケーションは変えられません。
- オブジェクト: 保存したファイル本体とメタデータ(Content-Type や Cache-Control など)。
images/2026/photo.jpgのような名前は「フォルダ」に見えますが、実際はスラッシュを含む1つの名前です。 - ロケーション: データを置く場所。単一リージョン(例: 東京の
asia-northeast1)、デュアルリージョン、マルチリージョンから選びます。 - ストレージクラス: Standard、Nearline、Coldline、Archive の4種類。後ろほど保存単価が下がる一方、取り出し料金と最小保存期間が設定されます。頻繁に読むデータは Standard、ほとんど読まないバックアップは Nearline 以降、という使い分けが基本です。
料金体系や各クラスの最小保存期間は改定されることがあるため、利用前に公式の料金ページを確認してください(2026年10月現在)。
事前準備
Google Cloud のプロジェクトを作成して課金を有効にし、手元の PC に Google Cloud CLI(gcloud)をインストールします。以前は gsutil コマンドが定番でしたが、現在 Google は gcloud storage コマンドの利用を推奨しています。古い記事の gsutil の手順は、多くが gcloud storage に置き換えられます。
gcloud auth login
gcloud config set project your-project-id
your-project-id は自分のプロジェクト ID に置き換えてください。思わぬ課金を防ぐため、課金アカウントに予算アラートを設定しておくと安心です。
バケットを作成する
東京リージョンに、Standard クラスのバケットを作る例です。
gcloud storage buckets create gs://your-bucket-name \
--location=asia-northeast1 \
--default-storage-class=STANDARD \
--uniform-bucket-level-access \
--public-access-prevention
ここで付けている2つのオプションには理由があります。
--uniform-bucket-level-access(均一なバケットレベルのアクセス)を有効にすると、権限をオブジェクトごとの ACL ではなく、バケット単位の IAM だけで管理するようになります。「どのファイルが誰に見えているか」を追いやすくなり、設定漏れによる情報公開を防ぎやすくなります。
--public-access-prevention(公開アクセスの防止)は、誤ってインターネット全体に公開する設定を入れられないようにするものです。公開用のバケットでない限り、最初から有効にしておくことをおすすめします。
バケット名は小文字・数字・ハイフンなどで構成し、他のユーザーとも重複できません。名前は公開 URL の一部になることがあるため、社名や内部のシステム名など、知られたくない情報を含めないようにします。
ファイルをアップロード・ダウンロードする
基本の操作は cp、ls、rm です。
# アップロード
gcloud storage cp ./backup.tar.gz gs://your-bucket-name/backups/
# フォルダごとアップロード
gcloud storage cp --recursive ./site-files gs://your-bucket-name/
# 一覧
gcloud storage ls gs://your-bucket-name/backups/
# ダウンロード
gcloud storage cp gs://your-bucket-name/backups/backup.tar.gz ./
# 削除(元に戻せないので対象を確認してから)
gcloud storage rm gs://your-bucket-name/backups/old.tar.gz
フォルダとバケットの内容を揃えるには gcloud storage rsync が使えます。削除も同期するオプションを付けると、ローカルで消したファイルがバケットからも消える点に注意してください。
アップロード後に「ブラウザで開くとダウンロードされてしまう」「文字化けする」という場合は、Content-Type が意図と違っていることが多いです。gcloud storage objects describe でメタデータを確認し、必要なら gcloud storage objects update で --content-type や --cache-control を設定し直します。
公開する場合と非公開で共有する場合
オブジェクトを外部に見せる方法は、大きく2つあります。
バケットを一般公開する
静的なファイルを誰でも読めるようにしたい場合は、公開アクセスの防止を解除したうえで、allUsers に閲覧ロールを付与します。
gcloud storage buckets update gs://your-public-bucket --no-public-access-prevention
gcloud storage buckets add-iam-policy-binding gs://your-public-bucket \
--member=allUsers \
--role=roles/storage.objectViewer
この設定はバケット内のすべてのオブジェクトに効きます。公開してよいファイルだけを入れる専用のバケットを分けて作るのが安全です。公開したオブジェクトは https://storage.googleapis.com/バケット名/オブジェクト名 の形式で参照できます。独自ドメインと HTTPS で配信したい場合は、外部アプリケーションロードバランサのバックエンドバケットとして使い、必要に応じて Cloud CDN を組み合わせる構成が一般的です。
署名付きURLで期限付きで渡す
非公開のまま特定の相手にだけファイルを渡したい場合は、署名付き URL を発行します。URL を知っている人は有効期限までアクセスできるため、期限は必要最小限にします。
gcloud storage sign-url gs://your-bucket-name/report.pdf \
--duration=10m \
--impersonate-service-account=signer@your-project-id.iam.gserviceaccount.com
署名にはサービスアカウントの権限が使われます。サービスアカウントの鍵ファイル(JSON)を発行して使う方法もありますが、鍵は漏えいすると長期間悪用されるおそれがあるため、上の例のようななりすまし(impersonation)で済むならそちらを選びます。必要なロールやオプションの細部は gcloud のバージョンで変わることがあるので、gcloud storage sign-url --help で確認してください。
権限はIAMで最小限に付与する
人やアプリケーションに渡す権限は、用途に合ったものに絞ります。よく使う定義済みロールは次のとおりです。
roles/storage.objectViewer: オブジェクトの閲覧と一覧roles/storage.objectCreator: オブジェクトの作成のみ(上書きや削除はできない)roles/storage.objectAdmin: オブジェクトの作成・上書き・削除を含む管理roles/storage.admin: バケット自体の設定変更も含む強い権限
たとえばサーバーからバックアップを送るだけなら、objectCreator をそのバケットにだけ付与しておくと、仮にサーバーが乗っ取られてもバックアップを消される心配が小さくなります。プロジェクト全体ではなく、バケット単位で付与するのがポイントです。
gcloud storage buckets add-iam-policy-binding gs://your-bucket-name \
--member=serviceAccount:backup-writer@your-project-id.iam.gserviceaccount.com \
--role=roles/storage.objectCreator
Compute Engine や Cloud Run から使う場合は、そのリソースにサービスアカウントを割り当てれば鍵ファイルなしで認証できます。Google Cloud の外にあるサーバーからは、Workload Identity 連携を検討し、どうしても鍵ファイルを使う場合はウェブ公開領域の外に置き、Git にコミットしないよう管理してください。
誤削除への備えとライフサイクル管理
バケットにはデータを守るための仕組みがいくつかあります。
- オブジェクトのバージョニング: 上書きや削除をしても、以前の世代を残します。
gcloud storage buckets update gs://your-bucket-name --versioningで有効にできます。 - 削除(復元可能)データの保持: 削除したオブジェクトを一定期間復元できる機能です。新しいバケットでは既定で有効になっていることがあり、保持期間中のデータにも保存料金がかかります。既定値と料金は公式ドキュメントで確認してください。
- 保持ポリシー: 指定期間はオブジェクトを削除・上書きできなくする機能。監査用のデータなどに使います。
バージョニングを有効にすると古い世代が溜まり続けるため、ライフサイクルルールで整理します。次の例は「現行でない世代を30日後に削除し、作成から90日経ったオブジェクトを Coldline に移す」ものです。
{
"lifecycle": {
"rule": [
{
"action": { "type": "Delete" },
"condition": { "daysSinceNoncurrentTime": 30 }
},
{
"action": { "type": "SetStorageClass", "storageClass": "COLDLINE" },
"condition": { "age": 90, "matchesStorageClass": ["STANDARD"] }
}
]
}
}
gcloud storage buckets update gs://your-bucket-name --lifecycle-file=lifecycle.json
gcloud storage buckets describe gs://your-bucket-name
ライフサイクルは条件に合ったものを自動で消すため、本番の前にテスト用のバケットで条件を確かめておくと安全です。Coldline などに移したデータは、最小保存期間より前に削除すると追加料金がかかります。
WordPressと組み合わせる場合
WordPress では、主に次の2つの用途で Cloud Storage が使われます。
1つ目はバックアップの保存先です。サーバーの外にバックアップを置いておけば、サーバー自体の障害や誤操作からも復旧できます。バックアップ系のプラグインには Google Cloud Storage を保存先に選べるものがありますが、無料版か有料版かで対応が分かれていることが多いので、導入前に各プラグインの説明を確認してください。WP-CLI でデータベースを書き出し、gcloud storage cp で送るスクリプトを cron で動かす方法もあります。
2つ目はメディアファイルのオフロードです。WP Offload Media のように、アップロードした画像を Cloud Storage に置いて配信するプラグインがあります。サーバーのディスクを節約でき、複数台構成にもしやすくなる一方、画像の URL が変わるため、既存記事の URL 書き換えや、プラグインを外したときの戻し方まで考えてから導入します。いずれの場合も、まずバックアップを取り、ステージング環境で動作を確認してから本番に反映してください。
まとめ
- Cloud Storage はバケットとオブジェクトで構成されるオブジェクトストレージで、ロケーションとストレージクラスは用途に合わせて選ぶ
- 操作は
gcloud storageコマンドが推奨。バケット作成時に均一なバケットレベルのアクセスと公開アクセスの防止を有効にしておくと安全 - 公開するならバケットを分けて
allUsersに閲覧ロールを付与し、個別に渡すなら有効期限の短い署名付き URL を使う - 権限はバケット単位・最小限で付与し、サービスアカウントの鍵ファイルはできるだけ使わない
- バージョニングとライフサイクルで誤削除に備えつつ、古いデータとコストを整理する