Google Cloud Storage（GCS）と Amazon S3 の徹底比較

プライベートでAIのセッション保存場所としてGCSを検討しています。
今GCPにハマっているだけなので、GCPで構築するつもりですが、AWSでやるならという観点でGCSとS3を徹底比較してみました。

結論

Google Cloud Storage（GCS）と Amazon S3 は、どちらもクラウドの代表的なオブジェクトストレージです。基本的な用途はよく似ています。

• ファイル、画像、動画、ログ、バックアップ、データレイクの保存
• 静的コンテンツ配信
• アプリケーションの永続ストレージ
• 分析基盤やAI/ML基盤のデータ置き場
• 長期アーカイブ

ただし、選び方は単純な「どちらが高性能か」ではありません。

AWS中心のシステムならS3、Google Cloud中心のシステムならGCSが自然です。
そのうえで、細かく見るとS3は周辺機能とエコシステムが非常に広く、GCSはGoogle Cloudとの統合、シンプルな階層、強い整合性、BigQueryやVertex AIとの相性が強みです。

まず一言で言うと

観点	GCS	S3
立ち位置	Google Cloudの標準オブジェクトストレージ	AWSの標準オブジェクトストレージ
得意領域	Google Cloud連携、分析/AI/ML、シンプルな設計	AWS連携、機能の厚さ、成熟した運用パターン
データ構造	bucket + object。folder/managed folder/hierarchical namespaceも利用可能	bucket + object key。general purpose / directory / table / vector bucketなどがある
整合性	object・bucket操作に強いグローバル整合性	object PUT/DELETE/GET/LISTなどに強い整合性
ストレージクラス	Rapid, Standard, Nearline, Coldline, Archive	Standard, Standard-IA, Intelligent-Tiering, One Zone-IA, Express One Zone, Glacier系など
高性能系	Rapid Bucket、hierarchical namespace、Rapid Cache	S3 Express One Zone、directory bucket
アーカイブ	Archive storageも低レイテンシで取得可能。取得料・最低保存期間に注意	Glacier Instant/Flexible/Deep Archiveなど。復元時間の違いが大きい
イベント連携	Pub/Sub通知が中心	Event Notifications、EventBridge、LambdaなどAWS連携が厚い
アクセス制御	IAM中心。uniform bucket-level access推奨	IAM、bucket policy、access points、access grants。ACLは原則無効推奨
暗号化	デフォルトでサーバーサイド暗号化。CMEK/CSEK/クライアントサイド対応	デフォルトでSSE-S3。SSE-KMS、DSSE-KMS、SSE-C、クライアントサイド対応

基本モデルの違い

GCS

GCSは、Google Cloudのプロジェクト配下にbucketを作り、その中にobjectを保存します。Google公式ドキュメントでは、Cloud Storageは「objectsをbucketsに保存するスケーラブルなマネージドストレージ」と説明されています。

GCSの特徴は、Google Cloudのリソース階層と相性が良いことです。

• Organization
• Folder
• Project
• Bucket
• Object
• Managed folder

というGoogle Cloud IAMの世界に自然に乗ります。

また、最近のGCSは単なるフラットなオブジェクトストアだけでなく、folder、managed folder、hierarchical namespace、Rapid Bucketなど、データレイクやAI/MLワークロード向けの機能が強化されています。

S3

S3もbucketとobjectが基本です。objectはデータ本体とmetadataを持ち、bucket内のkeyで一意に識別されます。S3 Versioningが有効な場合は、bucket + key + version IDで特定のobject versionを識別します。

S3の特徴は、歴史が長く、AWS全体の基盤として非常に多くのサービスと統合されていることです。

また、現在のS3はbucketの種類も増えています。

• General purpose bucket
• Directory bucket
• Table bucket
• Vector bucket

General purpose bucketは従来型のS3 bucketです。Directory bucketは低レイテンシ用途、Table bucketはApache Iceberg形式の表データ、Vector bucketはベクトル埋め込み検索向けです。

整合性の比較

GCSの整合性

GCSは、object read-after-write、object listing、bucket listingなどに対して強いグローバル整合性を提供します。

成功レスポンスを受け取った後は、作成・更新したobjectをすぐ読める、listでも見える、削除後はすぐ存在しない状態として見える、というモデルです。

ただし、注意点があります。

• IAM権限の付与・剥奪など、一部のアクセス制御変更はeventual consistency
• publicにcache可能なobjectは、Cache-Control次第で古い内容が見える可能性がある
• bucket設定変更は反映に時間がかかる場合がある

つまり、データ本体の読み書きはかなり扱いやすいが、権限や設定の反映は別物として考えるのが安全です。

S3の整合性

S3も、すべてのAWS RegionでobjectのPUT/DELETEに対してstrong read-after-write consistencyを提供します。新規作成、上書き、削除、GET、LISTなどで強い整合性があるとされています。

ただし、S3も設定系は別です。

• bucket configurationはeventual consistency
• versioningを初めて有効化した後は、書き込み前に少し待つことが推奨される
• 同一keyへの同時書き込みではlast-writer-wins的な挙動になる
• 複数keyにまたがるatomic updateはない

GCSもS3も、RDBのような複数objectをまたぐトランザクションストアではありません。強い整合性があるとはいえ、object単位の整合性 と考えるのが正しいです。

ストレージクラスの比較

GCSのストレージクラス

GCSの主なストレージクラスは以下です。

GCS class	主な用途	最低保存期間	取得料金
Rapid	I/O集約型、AI/ML、分析向けの高性能用途	なし	なし
Standard	頻繁にアクセスするhot data	なし	なし
Nearline	月1回程度アクセスする低頻度データ	30日	あり
Coldline	四半期に1回程度の低頻度データ	90日	あり
Archive	年1回以下の長期保存	365日	あり

GCSの良いところは、Nearline/Coldline/Archiveでも「オフライン復元待ち」のような体験ではなく、低レイテンシでアクセスできる点です。ただし、取得料金と最低保存期間が効くので、コスト設計は必要です。

また、GCSには Autoclass があります。これはbucket単位でアクセスパターンに応じたストレージクラス遷移をCloud Storage側に任せる仕組みです。

S3のストレージクラス

S3のストレージクラスはさらに多く、選択肢が細かいです。

S3 class	主な用途	最低保存期間	取得/復元
S3 Standard	頻繁にアクセスする一般用途	なし	ミリ秒
S3 Standard-IA	長期保存・低頻度アクセス	30日	取得料金あり
S3 Intelligent-Tiering	アクセスパターン不明・変化あり	なし	監視/自動化費あり、取得料なし
S3 One Zone-IA	再生成可能な低頻度データ	30日	取得料金あり、1 AZ
S3 Express One Zone	単一AZ内の低レイテンシ用途	なし	single-digit millisecond
S3 Glacier Instant Retrieval	四半期に1回程度のアーカイブ	90日	ミリ秒取得
S3 Glacier Flexible Retrieval	年1回程度のアーカイブ	90日	分〜時間
S3 Glacier Deep Archive	年1回未満の長期アーカイブ	180日	時間単位

S3はアーカイブの選択肢が非常に厚いです。特にGlacier系は、長期保存・コンプライアンス・バックアップでよく使われます。一方で、復元時間、最小課金、メタデータ課金、ライフサイクル遷移コストなどを理解しておかないと、思ったほど安くならないことがあります。

コスト設計の考え方

GCSとS3のコストは、単純なGB単価だけで比較すると危険です。実際には以下を含めて見る必要があります。

• 保存容量
• ストレージクラス
• 最低保存期間
• 取得料金
• リクエスト料金
• ライフサイクル遷移料金
• データ転送料
• 同一クラウド内のサービス連携時のネットワーク料金
• multi-region / dual-region / region / zoneの配置
• KMS利用料
• ログ、分析、監査関連の付帯コスト

実務では、次の3パターンに分けると設計しやすいです。

1. Hot data

頻繁に読むデータです。

• GCS: Standard
• S3: Standard

ここは機能差よりも、どのクラウド上のcomputeや分析基盤から読むかが重要です。

2. Warm / cool data

たまに読むが、すぐ読める必要があるデータです。

• GCS: Nearline / Coldline
• S3: Standard-IA / Intelligent-Tiering / Glacier Instant Retrieval

アクセス頻度が予測できないなら、GCS AutoclassやS3 Intelligent-Tieringを検討します。

3. Archive data

ほとんど読まないが、法令・監査・バックアップで残すデータです。

• GCS: Archive
• S3: Glacier Flexible Retrieval / Deep Archive

即時性が必要か、復元に数時間かかってよいかで選択が変わります。

パフォーマンスとスケール

一般的なobject storageとしてはどちらも非常に強い

通常のWebアプリ、ログ保存、データレイク、バックアップ用途では、GCSもS3も十分にスケールします。違いが出るのは、以下のようなケースです。

• 同じprefixや同じobject名に高頻度アクセスする
• 非常に小さいobjectを大量に読み書きする
• 低レイテンシがクリティカル
• AI/MLや分析で大量の並列読み込みをする
• 同一クラウド内のcomputeとの距離が効く

GCSの高性能系

GCSには、AI/MLや分析向けに以下のような機能があります。

• Rapid Bucket
• Rapid storage
• Hierarchical namespace
• Rapid Cache
• Cloud Storage FUSE

特にhierarchical namespaceは、フォルダ的な操作やHadoop系ワークロードと相性がよく、Google公式ドキュメントでは通常bucketより初期QPS上限が高いとされています。

S3の高性能系

S3では、S3 Express One Zoneとdirectory bucketが高性能用途の中心です。S3 Express One Zoneは単一AZ内でsingle-digit millisecondのアクセスを狙うストレージクラスです。

ただし、単一AZに寄せるということは、耐障害性や配置設計の考え方も変わります。低レイテンシを取る代わりに、multi-AZ耐性とは別の設計になります。

オブジェクトサイズとアップロード

現在の公式ドキュメント上では、GCSの最大object sizeは 5 TiB です。

S3はmultipart uploadの仕様上、最大object sizeとして 48.8 TiB が示されています。これは以前の一般的な「5 TB」という理解と異なるため、S3で巨大objectを扱う場合は、必ず最新の公式制限を確認したほうがよいです。

どちらも大きなobjectではmultipart/resumable upload系の仕組みを使います。

• GCS: resumable upload、XML API multipart upload、compose
• S3: multipart upload

実務では、巨大objectを1つにまとめるよりも、分析・再処理・再送・並列処理を考えて適切に分割する設計のほうが扱いやすいことが多いです。

アクセス制御

GCS

GCSのアクセス制御は、基本的にIAM中心で考えるのが安全です。

Googleは、bucket作成時に uniform bucket-level access を使うか、fine-grained accessを使うかを選ぶ設計にしています。uniform bucket-level accessではIAMだけで権限を管理します。fine-grained accessではIAMとACLを併用できますが、意図しない公開や監査の難しさが増えます。

GCSでは、特に機密データを扱う場合、uniform bucket-level accessを有効にしてIAMに寄せるのが基本方針です。

S3

S3も、現在はIAM・bucket policy・access pointを中心に考え、ACLは原則使わない方向です。

AWS公式ドキュメントでは、2023年4月以降に作成されたbucketはデフォルトでpublic accessをblockする設定になっています。また、S3 Object OwnershipのデフォルトではACLが無効化され、bucket ownerがobjectを所有し、policyでアクセス制御する形になっています。

S3のアクセス制御で強いのは、以下のような選択肢の厚さです。

• IAM identity-based policy
• Bucket policy
• Access Points
• S3 Access Grants
• Block Public Access
• Object Ownership
• VPC endpoint / PrivateLink系の設計

大規模組織で多数のbucket、prefix、チーム、アプリケーションを扱う場合、S3 Access PointsやAccess Grantsが効いてきます。

暗号化と鍵管理

GCS

GCSは、データをサーバーサイドで常に暗号化します。その上で追加の選択肢があります。

• Google管理の標準暗号化
• CMEK（Cloud KMSで管理する顧客管理鍵）
• CSEK（顧客提供鍵）
• クライアントサイド暗号化

GCSのCMEKは、Google Cloud KMSやCloud HSM、外部鍵管理と組み合わせられます。コンプライアンスや鍵ライフサイクル管理を重視する場合に使います。

S3

S3も、2023年1月5日以降、新規object uploadはデフォルトでSSE-S3により暗号化されます。

選択肢は以下です。

• SSE-S3
• SSE-KMS
• DSSE-KMS
• SSE-C
• クライアントサイド暗号化

AWS KMS、CloudTrail、S3 Inventory、S3 Storage Lensなどと連携して、組織全体の暗号化状態を監査しやすいのがS3の強みです。

バージョニング、削除保護、イミュータビリティ

GCS

GCSには以下があります。

• Soft delete
• Object Versioning
• Object holds
• Bucket Lock
• Object Retention Lock

GCSのObject Versioningは、削除や上書きされたobjectをnoncurrent versionとして残す機能です。ただし、Googleは accidental / malicious deletion への保護としては、Object Versioningよりsoft deleteを推奨する説明をしています。Object Versioningはbucket削除には効かないためです。

Bucket Lockは、bucket retention policyをロックする機能です。一度ロックすると保持期間を短くしたり削除したりできません。法令対応や監査向けには強力ですが、不可逆なので慎重に使う必要があります。

S3

S3には以下があります。

• S3 Versioning
• S3 Object Lock
• Retention period
• Legal hold
• MFA Delete

S3 Versioningはデフォルトでは無効です。有効にすると、削除時にはdelete markerが入り、上書き時には新versionが作られます。

S3 Object LockはWORMモデルを提供します。retention periodとlegal holdを使って、object versionが削除・上書きされることを防げます。Compliance modeではroot userでも保持期間中は削除できないため、規制対応では非常に重要な機能です。

ライフサイクル管理

GCS

GCSのObject Lifecycle Managementでは、条件に合ったobjectに対して以下を実行できます。

• Delete
• SetStorageClass
• AbortIncompleteMultipartUpload

条件にはage、createdBefore、customTime、noncurrentTime、prefix/suffix、storage classなどを使えます。

また、GCSではAutoclassを使うと、アクセスパターンに応じたストレージクラス遷移を自動化できます。

S3

S3 Lifecycleは非常に定番の機能です。

• Transition action: 低コストなstorage classへ移す
• Expiration action: 期限切れobjectを削除する

S3では、StandardからStandard-IA、Intelligent-Tiering、Glacier系、Deep Archiveなどへ段階的に移す設計がよく使われます。

ただし、S3 Lifecycleの削除や遷移はbucket policyでは止められない点に注意が必要です。ライフサイクルルールは強力なので、誤設定すると大量削除・大量遷移につながります。

レプリケーションとDR

GCS

GCSでは、bucket locationとしてregion、dual-region、multi-region、zoneなどを選びます。dual-regionやmulti-regionでは、地理的に離れた場所にデータを置く設計ができます。

また、cross-bucket replicationやTurbo Replicationもあります。Google Cloud内での分析やAI/MLの配置に合わせて、データの置き場所を考えるのが重要です。

S3

S3では、bucketは特定のAWS Regionに作ります。objectは明示的に転送・複製しない限り、そのRegionから出ません。

DRや多拠点構成では、以下がよく使われます。

• Cross-Region Replication
• Same-Region Replication
• Multi-Region Access Points
• S3 Replication Time Control

AWS内でマルチリージョン設計をする場合、S3は選択肢が非常に豊富です。一方で、レプリケーション、KMS、ownership、delete marker、versioning、IAMの組み合わせを正しく設計する必要があります。

イベント連携

GCS

GCSはPub/Sub notificationsを使って、object作成・削除・metadata変更などをイベントとして流せます。

代表的な連携先は以下です。

• Pub/Sub
• Cloud Functions
• Cloud Run
• Eventarc
• Dataflow

Google Cloud上のイベント駆動アーキテクチャでは、GCS + Pub/Sub + Cloud Run / Cloud Functionsが自然です。

S3

S3はイベント連携が非常に強いです。

• S3 Event Notifications
• Amazon EventBridge
• AWS Lambda
• SQS
• SNS

画像アップロード後のサムネイル生成、ログ投入後のETL、データレイク更新通知など、AWSのイベント駆動アーキテクチャではS3が入口になることが多いです。

分析・データレイク・AI/ML

GCSが向くケース

GCSは、Google Cloudの分析・AI/ML基盤と相性が良いです。

• BigQuery
• Vertex AI
• Dataflow
• Dataproc
• GKE
• Cloud Run

特にBigQueryやVertex AIを中心にデータ基盤を作るなら、GCSは自然なlanding zoneになります。

また、Cloud Storage FUSE、hierarchical namespace、Rapid Bucketなどにより、AI/MLやHadoop系ワークロードでも扱いやすくなっています。

S3が向くケース

S3は、AWSのデータレイクの中心です。

• Athena
• Glue
• EMR
• Redshift Spectrum
• SageMaker
• Lake Formation
• OpenSearch
• Bedrock

S3 TablesやS3 Vectorsのように、S3自体が分析・AI向けの専用bucketタイプを持ち始めているのも注目です。

AWS上でデータレイク、ML基盤、ログ分析、セキュリティ分析を作るなら、S3はほぼ標準の置き場です。

互換性と移行

S3は事実上のオブジェクトストレージAPI標準のような位置にあります。多くのツール、ライブラリ、SaaS、オンプレ製品がS3互換APIをサポートしています。

GCSもAmazon S3互換ツールとの相互運用性を意識した機能を持っています。HMAC keysやXML API、interoperabilityの仕組みを使うことで、S3向けツールからGCSを扱う設計も可能です。

ただし、完全互換と考えるのは危険です。以下は必ず差分確認が必要です。

• bucket naming
• IAM / policy model
• ACLの扱い
• storage class名
• versioning semantics
• lifecycle rule
• event notification
• signed URL / signature
• metadata header
• checksum
• multipart upload挙動
• object lock / retention

移行時は、aws s3 sync 的な単純コピーだけでなく、権限・保持・ライフサイクル・イベント・暗号化まで設計対象に入れるべきです。

実務での選び方

AWS中心ならS3

次の条件ならS3が自然です。

• アプリケーションがAWS上にある
• Lambda / ECS / EKS / EC2 / Glue / Athena / Redshift / SageMakerと連携する
• 既存ツールやSaaSがS3前提
• 監査やセキュリティ基盤がAWS IAM / CloudTrail中心
• アーカイブやデータレイク機能を細かく使いたい

Google Cloud中心ならGCS

次の条件ならGCSが自然です。

• アプリケーションがGoogle Cloud上にある
• BigQuery / Vertex AI / Dataflow / Dataproc / GKE / Cloud Runと連携する
• Google Cloud IAMやorganization policyで統制したい
• dual-region / multi-regionの配置をGoogle Cloud内でシンプルに扱いたい
• AI/ML向けにRapid BucketやCloud Storage FUSEを検討したい

マルチクラウドなら設計を分ける

マルチクラウドでは、「S3かGCSか」よりも、以下を決めるほうが重要です。

• system of recordはどちらか
• 片方向同期か双方向同期か
• オブジェクト名・metadata・checksumの基準
• 削除伝播のルール
• versioningやretentionの差分
• 誰がアクセス権限を持つか
• データ転送料を誰が負担するか

オブジェクトストレージのマルチクラウドは、データそのものよりも、権限・削除・保持・課金・イベント が難所です。

よくある落とし穴

1. ACLとIAMを混ぜて事故る

GCSでもS3でも、ACLはレガシー寄りです。原則はIAM/policy中心に寄せるべきです。

GCSではuniform bucket-level access、S3ではObject OwnershipのBucket owner enforcedとBlock Public Accessを基本にすると安全です。

2. lifecycle ruleで消しすぎる

ライフサイクルルールは便利ですが、誤設定すると大量削除になります。

特にS3ではbucket policyでLifecycle削除を止められない点に注意が必要です。GCSでもsoft deleteやretention policyとの関係を理解しておく必要があります。

3. アーカイブを安さだけで選ぶ

アーカイブは保存単価だけでなく、復元時間・取得料金・最低保存期間・リクエスト料金を見ないと失敗します。

「いざという時すぐ読める必要がある」なら、Deep Archive的な選択は合わないことがあります。

4. versioningを有効化して放置する

versioningは削除や上書きから守る一方で、古いversionが増え続けます。必ずlifecycle ruleとセットで設計するべきです。

5. 同じobject名への高頻度更新を設計してしまう

GCSには同じobject名への書き込みレート制限があります。S3も同一keyへの同時書き込みではlast-writer-winsの考え方になります。

オブジェクトストレージは「頻繁に同じファイルを更新するDB」ではありません。更新頻度が高いなら、DBやログ構造、append可能な別サービスを検討するべきです。

AIのセッションを入れるなら

AIエージェント、チャット、Claude Code/Codexの実行ログ、RAG、評価データ、プロンプト改善のための会話履歴を保存するなら、GCS/S3はかなり有力です。

ただし、最初に分けて考えるべきです。

• ライブ中のセッション状態
• セッション完了後のログ・履歴・添付ファイル
• 分析・評価・再学習・RAG用のデータ

GCS/S3が得意なのは、主に2つ目と3つ目です。つまり、AIセッションのアーカイブ、監査、分析、再利用のための保管庫 として使うのが向いています。

逆に、会話中に毎ターン高速更新する「現在のセッション状態」だけをGCS/S3に置くのはあまり向きません。object storageはobject単位の保存・取得には強いですが、低レイテンシで細かく更新する状態管理DBではありません。

推奨アーキテクチャ

AIセッション基盤では、だいたい次のように分けると扱いやすいです。

データ	向いている保存先
現在の会話状態、短期メモリ、途中状態	Redis、Firestore、DynamoDB、Spanner、PostgreSQLなど
完了済み会話ログ、ツール実行ログ、添付ファイル	GCS / S3
検索・分析用の整形済みログ	BigQuery / Athena / Redshift / OpenSearch
ベクトル検索用データ	Vertex AI Vector Search、OpenSearch、pgvector、S3 Vectorsなど
監査・コンプライアンス保存	GCS Bucket Lock / S3 Object Lock

つまり、GCS/S3は「AIセッションDB」ではなく、AIセッションのデータレイク と見るのがよいです。

何を保存するか

AIセッションを保存するなら、最低限このあたりを分けておくと後で効きます。

• session_id
• tenant_id / workspace_id
• user_id または匿名化ID
• agent_id
• model
• started_at / ended_at
• message history
• tool calls
• tool results
• file attachments
• final output
• user feedback
• cost / token usage
• latency
• error / retry情報
• policy / guardrail判定
• human approval履歴

保存形式は、最初はJSONでよいですが、分析量が増えるならJSONLまたはParquetに寄せると扱いやすくなります。

オブジェクトキー設計

AIセッションログでは、object key設計がかなり重要です。

例:

sessions/
  tenant_id=acme/
    date=2026-07-09/
      agent_id=project-lead/
        session_id=01JZ.../
          messages.jsonl
          tool-calls.jsonl
          artifacts/
          summary.json
          metadata.json

分析を重視するなら、日付・tenant・agent単位でpartitionしやすい形にしておくとよいです。

一方で、1メッセージごとに1 objectを作ると、小さいobjectが大量に増えて管理・コスト・分析が面倒になります。基本は、1 sessionごと、または一定時間ごとにまとめる のが実務的です。

GCSを選ぶとよいAIセッション基盤

次の条件ならGCSが向いています。

• Gemini / Vertex AI中心
• BigQueryで会話ログを分析したい
• Dataflowでログを整形したい
• Cloud Run / Cloud Functionsでセッション完了イベントを処理したい
• Google Cloud IAMでプロジェクト・フォルダ・組織単位の統制をしたい
• Vertex AI評価、RAG、学習データ整備とつなげたい

構成例:

App / Agent Runtime
  -> Firestore or Redis: live session state
  -> GCS: raw session logs and artifacts
  -> Pub/Sub: session completed event
  -> Dataflow / Cloud Run: normalize logs
  -> BigQuery: analytics and evaluation dataset
  -> Vertex AI: eval, tuning, RAG pipeline

GCSは、BigQueryやVertex AIに流しやすいのが強みです。特に「AI workflowの改善」をテーマにするなら、セッションログをBigQueryに入れて、失敗パターン、ツール利用率、承認待ち箇所、token costを分析しやすいです。

S3を選ぶとよいAIセッション基盤

次の条件ならS3が向いています。

• Bedrock / SageMaker中心
• Lambda / Step Functions / EventBridgeでワークフローを組みたい
• Athena / Glue / Redshiftでログ分析したい
• OpenSearchやBedrock Knowledge Basesとつなげたい
• AWSアカウントやIAM、CloudTrailで監査したい
• 既存のS3前提ツールやSaaSが多い

構成例:

App / Agent Runtime
  -> DynamoDB or ElastiCache: live session state
  -> S3: raw session logs and artifacts
  -> S3 Event Notifications / EventBridge
  -> Lambda / Step Functions: normalize and route logs
  -> Glue Data Catalog + Athena: analytics
  -> OpenSearch / Bedrock / SageMaker: retrieval, eval, model workflow

S3は、AWS内でのイベント駆動と監査が強いです。セッション完了時にS3へログを置き、EventBridgeやLambdaで評価ジョブ、要約、PII検出、チケット作成などを回す設計が作りやすいです。

セキュリティ設計

AIセッションには、ユーザー発話、社内情報、コード、ファイル、個人情報、業務判断が入りがちです。通常のログよりも慎重に扱うべきです。

最低限やるべきこと:

• bucketはprivate前提
• public access block / public access preventionを有効化
• IAM/policyは最小権限
• KMS鍵を分ける
• tenantごとにprefixまたはbucketを分ける
• PIIや機密情報のredactionを検討
• retention policyを明確化
• lifecycleで不要ログを削除またはアーカイブ
• 本番ログと評価用ログを分ける
• ユーザー削除要求や法務保持に対応できる設計にする

コンプライアンスや監査目的なら、S3 Object LockやGCS Bucket Lockも選択肢です。ただし、ロック系機能は強力で不可逆に近い運用になるため、テストbucketで十分に検証してから使うべきです。

AIセッションでの選び方

要件	おすすめ
Gemini / Vertex AI / BigQuery中心	GCS
Bedrock / SageMaker / Athena中心	S3
セッション完了イベントで処理したい	GCS + Pub/Sub / S3 + EventBridge or Lambda
会話ログを分析してAI workflow改善に使いたい	GCS + BigQuery または S3 + Athena/Glue
ライブの会話状態を置きたい	GCS/S3ではなくDB・cache
長期監査・WORM保存	GCS Bucket Lock または S3 Object Lock
マルチクラウドAI基盤	object storageをraw archive、metadata/indexは別DBに分離

実務的な結論

AIセッションを入れるなら、GCS/S3は 「実行ログと成果物の保管庫」 として使うのが最も安全です。

ライブ状態はDBやcacheに置き、セッション終了時にGCS/S3へJSONL/Parquet/添付ファイルを保存する。そこからBigQuery/Athenaに流して、品質評価、コスト分析、プロンプト改善、ツール利用分析、失敗パターン抽出に使う。この形が一番テストしやすく、後から伸ばしやすいです。

判断表

要件	おすすめ
AWS上の標準ストレージ	S3
Google Cloud上の標準ストレージ	GCS
BigQuery / Vertex AI中心	GCS
Athena / Glue / SageMaker中心	S3
S3互換ツールが多い	S3が無難。GCS interoperabilityも検討
シンプルなIAM中心の設計	GCSは扱いやすい
アクセス制御を大規模に細かく分けたい	S3 Access Points / Access Grantsが強い
アーカイブ選択肢の細かさ	S3
低頻度データでも即時アクセスしたい	GCS Archive / S3 Glacier Instant Retrievalを比較
単一AZ内の超低レイテンシ	S3 Express One Zone / GCS Rapid Bucketを比較
WORM・規制対応	S3 Object Lock / GCS Bucket Lockを要件で比較
マルチクラウド移行	API互換だけでなく権限・保持・イベント差分を確認

まとめ

GCSとS3は、どちらも「クラウドのファイル置き場」ではありません。実際には、アプリケーション、分析、AI/ML、監査、バックアップ、イベント駆動処理の基盤です。

選び方の軸はシンプルです。

• AWS中心ならS3
• Google Cloud中心ならGCS
• データレイクやアーカイブの細かい選択肢を重視するならS3
• BigQuery / Vertex AI / Google Cloud IAMとの統合を重視するならGCS
• マルチクラウドなら、API互換ではなく運用セマンティクスまで比較する

最終的には、保存単価だけでなく、アクセス頻度、復元要件、権限モデル、イベント連携、KMS、ライフサイクル、リージョン配置、データ転送料まで含めて判断するのが現実的です。

参考リンク

• Cloud Storage overview - Google Cloud
• Cloud Storage classes - Google Cloud
• Cloud Storage consistency - Google Cloud
• Cloud Storage access control - Google Cloud
• Cloud Storage encryption options - Google Cloud
• Cloud Storage Object Lifecycle Management - Google Cloud
• Cloud Storage Object Versioning - Google Cloud
• Cloud Storage Bucket Lock - Google Cloud
• Cloud Storage quotas and limits - Google Cloud
• What is Amazon S3? - AWS
• Amazon S3 storage classes - AWS
• Amazon S3 access control - AWS
• Amazon S3 encryption - AWS
• Amazon S3 lifecycle management - AWS
• Amazon S3 Versioning - AWS
• Amazon S3 Object Lock - AWS
• Amazon S3 multipart upload limits - AWS
• Amazon S3 Event Notifications - AWS