技術記事 2026/6/21

S3のデータに業務文脈を持たせる — アノテーションでAIエージェント/RAGの「理解」を底上げし、Athenaで引く

Amazon S3 がアノテーションに対応し、オブジェクトに業務文脈のカスタムメタデータ（1オブジェクト最大1,000個・各1MB・合計1GB、JSON/XML/YAML）を後付けできるようになりました（GA・東京リージョン対応）。PutObjectAnnotationで付与し、S3 Metadataのアノテーションテーブル（Apache Iceberg自動インデックス）経由でAthena・SageMaker Unified Studio（自然言語検索）・S3 Tables MCPから横断クエリできます。既存タグとの違い、技術スパイン3段、S3 Vectorsとの併用設計、保存は割増なし・コストはクエリ可能化側という料金の考え方を、AWSフリーランス実務目線で整理します。併用や料金は公式の最新情報もご確認ください。

#Amazon S3
#S3 Metadata
#RAG
#生成AI
#データ基盤
#Athena

私は受託で「お客様の S3 にあるデータを、生成AIで使えるようにしたい」という相談をよく受けます。そこで毎回ぶつかるのが、データに”意味”が乗っていない、という問題です。ファイル名やパスだけでは、その動画が何語の字幕付きでいつ作られたものか、その文書がどの機密区分かといった業務文脈が分かりません。結果として、AI に渡す検索結果に余計なものが混ざったり、必要なものが漏れたりします。タグは付けられますが、数が少なすぎて足りない、というのも実感です。

2026年6月16日、この課題に効きそうな発表がありました。Amazon S3 がアノテーション（オブジェクトに業務文脈のカスタムメタデータを後付けする仕組み）に対応した、というものです。GA（一般提供）で、東京リージョンでも使えます。この記事では、何ができるのか、既存のタグと何が違うのか、PutObjectAnnotation で付けて Athena などからどう引くのか、S3 Vectors とどう併用できるのか、そして料金の考え方まで、実装目線で整理してみましょう。煽らず、断定できないところは正直に「公式をご確認ください」と書きます。なお「AI が理解する」という言い方は避け、「AI に渡すデータの質を上げる」という観点で書きます。

S3アノテーションとは：後付けできる1GB/オブジェクトの業務文脈

アノテーションは、PutObjectAnnotation（取得は GetObjectAnnotation）でオブジェクト単位に付けるカスタムメタデータです。1オブジェクトあたり最大1,000個の名前付きアノテーション、1つ最大1MB、合計最大1GBまで、UTF-8 のテキスト（JSON／XML／YAML）で後から付与・更新できます。名前付きで複数持てるので、たとえば「技術メタデータ班」と「コンテンツ分類班」が別々の名前で並行してエンリッチ（情報の付与）しても、互いに干渉せず共存します。中身も柔軟で、たとえば動画なら「言語・字幕・制作年・音声トラック数」、文書なら「機密区分・部門・権利区分」といった業務文脈を、JSON の構造化データとして持たせられます。ファイル名やパスからは読み取れなかった情報を、オブジェクトそのものに紐づけておけるわけです。

既存の似た仕組みとの違いを押さえておきましょう。

オブジェクトタグ・ユーザー定義メタデータ・アノテーションの違いを横並び3カラムで比較した図。オブジェクトタグは最大10個・文字列のみ・更新可・アクセス制御やコスト配分向け。ユーザー定義メタデータは小さめ（ヘッダー）・文字列のみ・原則アップロード時に固定・オブジェクト付随の補助情報向け。アノテーション（新）は最大1,000個×各1MB×合計1GB・UTF-8テキスト（JSON/XML/YAML）・後付けで更新可・業務文脈の付与とスケールしてのクエリ向け。クォータや形式は2026年6月時点で最新は公式確認という注記つき。 — 図1: タグ／ユーザー定義メタデータ／アノテーションの違い。アノテーションは容量・形式・クエリ性で一段広い

観点	オブジェクトタグ	ユーザー定義メタデータ	アノテーション（新）
上限	最大10個・短い	小さめ（ヘッダー）	最大1,000個×各1MB×合計1GB
形式	文字列のみ	文字列のみ	UTF-8（JSON/XML/YAML）
更新	可	原則アップロード時に固定	後付け・更新可
主な用途	アクセス制御・コスト配分	付随する補助情報	業務文脈の付与＋スケールしてクエリ

タグは10個までで、アクセス制御やコスト配分に向く仕組みです。ユーザー定義メタデータはアップロード時に決める小さな補助情報です。アノテーションは、これらより容量が大きく・形式が柔軟で・後から更新でき・スケールしてクエリできる点が新しいところです。

技術スパイン3段：付与 → S3 Metadataで引けるように → Athenaで引く

実装の中心は、次の3段で考えると分かりやすいです。

S3アノテーションの技術スパイン3段を左から右への横長フローで示した図。①付与（PutObjectAnnotationでオブジェクトに名前付きアノテーションを付ける、マルチパートは完了後）→②クエリ可能化（S3 Metadataのアノテーションテーブルを有効化するとApache Icebergテーブルに自動インデックスされ、初回のbackfillは課金）→③引く（Athenaの実SQLでjson_extract_scalarで展開、SageMaker Unified Studioの自然言語検索、S3 Tables MCP）。アノテーションテーブルは約1時間以内に反映・ジャーナルはニアリアルタイム、手順は公式確認という注記つき。 — 図2: 技術スパイン3段。付与してS3 Metadataで引けるようにし、Athena等から横断クエリする

1段目は付与です。前述の PutObjectAnnotation で付けます（マルチパートアップロードの場合は完了後に付与します）。

2段目はクエリ可能化です。バケットで S3 Metadata のアノテーションテーブルを有効化すると、S3 がアノテーションをフルマネージドな Apache Iceberg テーブル（オープンなテーブル形式で、大規模データを分析エンジンから扱える）に自動でインデックスします。有効化時にはバックフィル（既存オブジェクトのアノテーションを一括スキャンして取り込む処理）が走り、数分〜数時間かかり、ここは課金対象です。アノテーションテーブルは約1時間以内に反映され、変更履歴のジャーナルテーブルはニアリアルタイムで更新されます。

3段目は引くです。代表的なのが Amazon Athena（標準SQLでデータを問い合わせるサービス）で、アノテーションテーブルを直接クエリできます。本文は text_value というカラムに UTF-8 テキストとして入るので、JSON なら json_extract_scalar で値を取り出して絞り込めます。たとえば次のようなSQLです。

SELECT DISTINCT bucket, object_key
FROM "s3tablescatalog/aws-s3"."b_your_bucket"."annotation"
WHERE name = 'mediainfo'
  AND CAST(json_extract_scalar(text_value, '$.audio_tracks') AS INTEGER) > 8

Athena 以外でも、マネージドな Iceberg テーブルなので任意の Iceberg 互換エンジンから引けますし、SageMaker Unified Studio では自然言語での検索（例：「2023年のスペイン語字幕付き作品を探す」）、S3 Tables MCP サーバー（MCP＝AIツールが外部データへ安全につなぐための共通インターフェース）を使えば、IDE やエージェントから直接APIを書かずに探せます。テーブルの主なカラムは bucket／object_key／name／sequence_number／text_value などです。アノテーション名の命名規則や完全なIAMポリシーは、実装時に公式ドキュメントでご確認ください。

S3 Vectors・エージェントとの併用設計

ここは誠実に線引きしておきます。アノテーションと S3 Vectors や Bedrock のナレッジベースを組み合わせる「公式の統合機能」は、現時点の公式情報には記載がありません。以下は、あくまで設計として組める構成の話で、公式統合ではない、と区別して読んでください。

RAG（検索した情報を生成AIの回答に活用する手法）のデータ層は、二本柱で考えると整理しやすいです。ひとつは、本メディアでも取り上げた Amazon S3 Vectors によるベクトル類似検索（意味の近さで探す）。もうひとつが、今回のアノテーションによる業務文脈でのフィルタ（機密区分・言語・年・権利区分などで絞る）です。意味的に近いものを集め、そこに業務メタデータの条件を重ねれば、AI に渡す候補の精度を上げられます。

また、アノテーションを Athena や MCP で引いた結果を、Amazon Bedrock AgentCore のようなエージェント基盤の検索ツールに渡す入力側として使う構成も考えられます。いずれも「アノテーションを付ければ AI が賢くなる」という話ではなく、AI に渡すデータの質を設計で底上げする、という位置づけです。APIレベルの統合可否は、今後の公式情報をご確認ください。

料金の考え方：保存は割増なし、コストはクエリ可能化側

採用判断で誤解しやすいのが料金です。要点は「アノテーションの保存そのものには割増がなく、コストはクエリ可能にする S3 Metadata 側に出る」ことです。

S3アノテーションの料金の考え方を左右2ブロックで示した横長図。左（保存=アノテーション自体）はS3標準のストレージ/リクエスト料金のみで割増なし、アノテーションを付けたから課金されるのではないと明記。右（クエリ可能化=S3 Metadata）はジャーナルテーブル更新0.30ドル/100万更新、メタデータ処理0.002ドル/GB、有効化時のbackfillも課金で既存大量オブジェクトは初回コスト注意。料金は2026年6月時点の参考値で公式の最新料金ページで確認という注記つき。 — 図3: 料金は保存ではなくクエリ可能化側。backfillも課金対象なので既存大量オブジェクトは初回コストに注意

アノテーション自体は、S3 標準のストレージ・リクエスト料金で扱われ、付けたこと自体への割増はありません。コストが出るのは、クエリできるようにする S3 Metadata 側です（2026年6月17日時点の参考値）。

コスト項目	料金
アノテーションの保存	S3標準のストレージ／リクエスト料金（割増なし）
ジャーナルテーブル更新	$0.30 / 100万更新
メタデータ処理	$0.002 / GB
有効化時のbackfill	課金対象（更新と同じ $0.30 / 100万更新・一回限り・既存オブジェクト量に比例）

とくにバックフィルが課金対象である点は要注意で、すでに大量のオブジェクトがあるバケットでは初回にまとまったコストが発生し得ます。アノテーションテーブル自体のストレージや保守は標準の S3 Tables 料金です。料金は改定され得るので、必ず公式の最新の料金ページでご確認ください。なお有効化は S3 コンソール（または CreateBucketMetadataConfiguration API）から行え、付与・取得には s3:PutObjectAnnotation／s3:GetObjectAnnotation の権限が要ります。

まとめ

ポイントを3つに絞ります。

S3 アノテーションは、1オブジェクトに最大1GBの業務文脈を後付けできる新しいメタデータです。タグの上限では足りなかった文脈を、JSON などで柔軟に持たせられます。
技術スパイン3段（PutObjectAnnotation → S3 Metadata のアノテーションテーブル → Athena／SageMaker Unified Studio／MCP）で横断クエリでき、AI に渡すデータの質を設計で底上げできます。S3 Vectors との併用は公式統合ではなく、設計として組める構成です。
コストは保存ではなくクエリ可能化側（更新・処理・バックフィル）に出ます。料金・併用・命名規則やIAMは、公式の最新情報をご確認ください。

お客様の S3 データを生成AIで使えるように整える「データ設計」は、受託の現場でも評価されやすいテーマだと感じています。ベクトル検索の保存層としての S3 Vectors とあわせて、RAG のデータ層を二本柱で設計してみてください。