S3 の「/」は本当にフォルダなのか - フラットな名前空間の真実とプレフィックスの仕組み
S3 にはフォルダという概念が存在せず、オブジェクトキーの「/」は単なる文字列の一部であるという事実から、プレフィックス検索の仕組み、コンソールがフォルダに見せるトリック、キー設計のベストプラクティスを解説します。
S3 にフォルダは存在しない
S3 のデータモデルは、バケットとオブジェクトの 2 階層だけで構成されるフラットな名前空間です。ファイルシステムのようなディレクトリ階層は存在しません。オブジェクトキー images/2024/photo.jpg は、「images フォルダの中の 2024 フォルダの中の photo.jpg」ではなく、「images/2024/photo.jpg という名前の 1 つのオブジェクト」です。「/」はキー名の一部であり、ファイルシステムのパス区切り文字とは本質的に異なります。この事実を確認する簡単な方法があります。AWS CLI で aws s3api list-objects-v2 --bucket my-bucket を実行すると、すべてのオブジェクトがフラットなリストとして返されます。フォルダという概念は一切現れません。一方、aws s3 ls s3://my-bucket/ を実行すると、あたかもフォルダ構造があるかのように表示されます。これは s3 コマンド (高レベルコマンド) が、「/」をデリミタとして使用し、共通プレフィックスをフォルダのように表示しているだけです。
コンソールがフォルダに見せるトリック
AWS マネジメントコンソールの S3 画面では、フォルダアイコンが表示され、フォルダの作成ボタンもあります。しかし、コンソールで「フォルダを作成」すると、実際には末尾が「/」のゼロバイトオブジェクト (例: images/) が作成されます。このオブジェクトは、コンソールがフォルダとして表示するためのマーカーに過ぎません。フォルダマーカーを削除しても、そのプレフィックスを持つオブジェクトは影響を受けません。images/ オブジェクトを削除しても、images/photo.jpg は存在し続けます。逆に、images/photo.jpg をアップロードすれば、images/ マーカーがなくてもコンソールは images フォルダを表示します。コンソールは ListObjectsV2 API の Delimiter パラメータに「/」を指定し、CommonPrefixes (共通プレフィックス) をフォルダとして表示しています。この仕組みを理解していないと、「フォルダを削除したのに中のファイルが消えない」「フォルダを作成していないのにフォルダが表示される」という現象に困惑します。
プレフィックスとパフォーマンスの関係
(2026 年 8 月時点) S3 のプレフィックスは、パフォーマンスに直接影響します。S3 は 2018 年にパフォーマンスの大幅な改善を行い、パーティション化されたプレフィックス 1 つあたり、少なくとも秒間 3,500 PUT/COPY/POST/DELETE または 5,500 GET/HEAD リクエストを処理できるようになりました。ここでの「プレフィックス」は、オブジェクトキーの先頭から始まる任意の長さの文字列で、キー名の上限である 1,024 バイトまで取り得ます。「/」で区切られた区間の単位でも、最後の「/」より前の部分でもありません。images/2024/01/photo.jpg というキーは、images/ や images/2024/ だけでなく、images/2024/01/p のように区切り文字の途中で終わる文字列もプレフィックスとして持ちます。どこがパーティションの境界になるかは、持続的なリクエストレートに応じて S3 がプレフィックス文字列の任意の位置に自動的に作成します。バケット内のプレフィックス数に上限はないため、キーを分散させれば読み書きのスループットを水平にスケールできます。ただし単純な掛け算にはなりません。PUT と GET が混在するワークロードでは 1 パーティションあたりの処理可能数が比率に応じて按分され、たとえば PUT/POST/DELETE が 30%・GET が 70% の構成なら、秒間 1,050 と 3,850 程度に下がります。またパーティションの自動追加は、上限を超える負荷が 30〜60 分続いたうえで約 20 分を要するため、その間のリクエストには 503 (Slow Down) が返ります。スパイクが事前に読めている場合は、AWS Support にプレフィックスのパーティションを用意してもらうよう依頼するのが確実です。2018 年以前は、S3 のパーティショニングがキーの先頭文字に基づいていたため、キーの先頭にランダムなハッシュを付加する (例: a1b2c3/images/photo.jpg) というベストプラクティスがありました。現在は一意なキー命名パターンを工夫する必要はなく、S3 が自動的にパーティションを最適化します。
オブジェクトキー設計のベストプラクティス
オブジェクトキーの設計は、S3 の運用効率に大きく影響します。第 1 に、キーの命名規則を統一することです。日付ベースのキー (logs/2024/01/15/access.log) は、時系列データの管理に適しています。S3 のライフサイクルルールは、プレフィックスのほかオブジェクトタグやオブジェクトサイズ (最小 / 最大)、およびそれらの組み合わせでも対象を絞り込めますが、日付をプレフィックスに含めておけばプレフィックスの指定だけで済みます。これにより、古いデータを自動的に S3 Glacier Flexible Retrieval や S3 Glacier Deep Archive へ移行したり、保持期限を過ぎたものを削除したりできます。第 2 に、キーに特殊文字を避けることです。S3 のオブジェクトキーには UTF-8 の任意の文字を使用できますが、スペース、日本語、特殊記号を含むキーは、URL エンコーディングの問題を引き起こすことがあります。英数字、ハイフン、アンダースコア、スラッシュに限定するのが安全です。第 3 に、キーの長さを意識することです。オブジェクトキーの最大長は 1,024 バイトです。深いフォルダ構造を模倣して長いキーを使用すると、この上限に近づきます。また、ListObjectsV2 のレスポンスにはキー名が含まれるため、キーが長いとレスポンスサイズが増加し、ネットワーク帯域を消費します。
フラットな名前空間の活用と中身を絞り込む選択肢
S3 のフラットな名前空間は、従来のファイルシステムの概念に慣れた開発者には違和感がありますが、大規模データ処理では大きな利点があります。フラットな名前空間では、ディレクトリのメタデータ管理が不要なため、数十億個のオブジェクトを格納してもパフォーマンスが劣化しません。ファイルシステムでは 1 つのディレクトリに含まれるファイル数が増えるほど列挙のコストが増大し、ファイルシステムの種別やキャッシュの状態によって待ち時間が大きく変わります。S3 では、オブジェクト数がどれだけ増えても ListObjectsV2 は 1 回のレスポンスあたり最大 1,000 件という一定の単位で返り、プレフィックスとデリミタの指定で必要な範囲だけを取り出せます。オブジェクトの中身を S3 側で絞り込みたい場合、かつては CSV や JSON に SQL クエリを実行する S3 Select が使われていました。ただし S3 Select は新規のお客様には提供されておらず、既存の利用者だけが従来どおり利用できる状態です (2026 年 8 月時点)。これから設計するなら、S3 上のデータに SQL を実行する Amazon Athena と、スキーマ管理と ETL を担う AWS Glue の組み合わせが現行の選択肢になります。GET の応答を独自の関数で加工する S3 Object Lambda も同じ用途に使えますが、S3 Select と同じく 2025 年 11 月 7 日に新規のお客様への提供が終了しているため、既存の利用者向けの選択肢です。いずれの構成でも、読み取り対象を必要なプレフィックスに限定できるかどうかがスキャン量とコストを左右するため、フラットな名前空間を前提としたキー設計がそのまま効いてきます。
参考資料 (AWS 公式)
本ページの一次情報は AWS 公式サイトおよび公式ドキュメントです。最新の仕様 / 料金は次の公式ページで確認できます。
本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。