AWS DynamoDBのテーブル作成と操作方法｜キー設計・CLIでの読み書き・バックアップ設定

Amazon DynamoDB でテーブルを作るときに最初に決めるのは、パーティションキー（とソートキー）と、キャパシティモードの2つです。この2つさえ決まれば、テーブル作成自体はコンソールでも CLI でも数分で終わります。この記事では、キーの決め方、AWS CLI でのテーブル作成とデータの読み書き（put / get / query / update / delete）、本番で有効にしておきたい保護設定までを順に説明します。

DynamoDB の機能や制限値、コンソールの表示は更新されることがあります（2026年10月現在）。ここで挙げる値は目安として読み、細かい仕様は AWS の公式ドキュメントで確かめてください。

テーブルを作る前に決めること

キーはアクセスの仕方から決める

DynamoDB は、リレーショナルデータベースのように後から自由な条件で検索する用途には向きません。「どのキーで、どんな範囲を取り出すか」を先に決め、それに合わせてキーを設計します。

• パーティションキー：データを分散させるためのキーです。値ごとに保存場所が決まるため、ユーザー ID のように値の種類が多く、アクセスが偏らないものを選びます。
• ソートキー（任意）：同じパーティションキーの中で並び順を決めるキーです。日時を入れておくと「あるユーザーの、ある期間の注文」を範囲で取り出せます。

例として、注文データを「顧客 ID ＋ 注文日時」で管理するテーブルを作ります。顧客ごとの注文履歴を日付順に取り出すという使い方に合わせた設計です。

キャパシティモード

• オンデマンド：リクエスト数に応じて自動で処理能力が調整されます。アクセス量が読めない段階や、試験的な利用に向いています。
• プロビジョンド：読み込み・書き込みの処理能力をあらかじめ指定します。負荷が安定していて予測できる場合に使い、Auto Scaling と組み合わせるのが一般的です。

迷ったらオンデマンドで始め、利用状況が見えてから見直す方法が安全です。料金体系は改定されることがあるため、選ぶ前に料金ページを確認してください。

ステップ1：テーブルを作成する

AWS CLI でテーブルを作る例です。キーに使う属性だけを --attribute-definitions に書きます。キー以外の属性は、データを入れるときに自由に追加できます。

aws dynamodb create-table \
  --table-name Orders \
  --attribute-definitions \
      AttributeName=CustomerId,AttributeType=S \
      AttributeName=OrderDate,AttributeType=S \
  --key-schema \
      AttributeName=CustomerId,KeyType=HASH \
      AttributeName=OrderDate,KeyType=RANGE \
  --billing-mode PAY_PER_REQUEST \
  --deletion-protection-enabled

# 作成完了（ACTIVE）まで待つ
aws dynamodb wait table-exists --table-name Orders
aws dynamodb describe-table --table-name Orders --query "Table.TableStatus"

HASH がパーティションキー、RANGE がソートキーです。属性の型は S（文字列）、N（数値）、B（バイナリ）から選びます。日時をソートキーにする場合は、2026-10-28T09:00:00Z のような ISO 8601 形式の文字列にしておくと、文字列の並びがそのまま時刻の順になります。

--deletion-protection-enabled は削除保護の指定で、誤ってテーブルを消す事故を防ぎます。本番のテーブルでは有効にしておくことをおすすめします。

ステップ2：データを書き込む・読み出す

CLI では、値を {"S": "..."} のように型付きの JSON で書きます。

# 書き込み（同じキーが既にあれば上書きされる）
aws dynamodb put-item \
  --table-name Orders \
  --item '{
    "CustomerId": {"S": "C001"},
    "OrderDate":  {"S": "2026-10-28T09:00:00Z"},
    "Amount":     {"N": "3200"},
    "Status":     {"S": "paid"}
  }'

# キーを指定して1件取得
aws dynamodb get-item \
  --table-name Orders \
  --key '{"CustomerId": {"S": "C001"}, "OrderDate": {"S": "2026-10-28T09:00:00Z"}}'

put-item は同じキーの項目があると黙って上書きします。新規作成のときだけ書き込みたい場合は、--condition-expression "attribute_not_exists(CustomerId)" を付けると、既に存在するときはエラーになります。

query で範囲を取り出す

顧客 C001 の2026年10月の注文を取り出す例です。

aws dynamodb query \
  --table-name Orders \
  --key-condition-expression "CustomerId = :c AND begins_with(OrderDate, :m)" \
  --expression-attribute-values '{":c": {"S": "C001"}, ":m": {"S": "2026-10"}}'

query はパーティションキーの一致が条件として欠かせず、ソートキーには =、<、BETWEEN、begins_with などの条件を付けられます。

一方 scan はテーブル全体を読む操作です。条件で絞り込む --filter-expression を付けても、読み込んだ量に応じて処理能力を消費します。データが増えるほど遅く高くつくため、日常的な処理には使わず、query で取り出せるようにキーやインデックスを設計します。

ステップ3：更新と削除

# Status だけを更新（Status は予約語なので #s で置き換える）
aws dynamodb update-item \
  --table-name Orders \
  --key '{"CustomerId": {"S": "C001"}, "OrderDate": {"S": "2026-10-28T09:00:00Z"}}' \
  --update-expression "SET #s = :s" \
  --expression-attribute-names '{"#s": "Status"}' \
  --expression-attribute-values '{":s": {"S": "shipped"}}' \
  --return-values UPDATED_NEW

# 削除
aws dynamodb delete-item \
  --table-name Orders \
  --key '{"CustomerId": {"S": "C001"}, "OrderDate": {"S": "2026-10-28T09:00:00Z"}}'

Status や Date、Name のような単語は DynamoDB の予約語に含まれており、式の中に直接書くとエラーになります。#s のようなプレースホルダーを使い、--expression-attribute-names で実際の名前を割り当てるのが定番の回避方法です。

プログラムから操作する（Python の例）

アプリケーションからは SDK を使います。Python（boto3）では、型付き JSON を書かずに済む Table リソースが便利です。

import boto3
from boto3.dynamodb.conditions import Key

table = boto3.resource("dynamodb", region_name="ap-northeast-1").Table("Orders")

table.put_item(Item={
    "CustomerId": "C001",
    "OrderDate": "2026-10-28T09:00:00Z",
    "Amount": 3200,
    "Status": "paid",
})

resp = table.query(
    KeyConditionExpression=Key("CustomerId").eq("C001") & Key("OrderDate").begins_with("2026-10")
)
for item in resp["Items"]:
    print(item["OrderDate"], item["Amount"])

boto3 では数値が Decimal 型で返り、書き込むときも浮動小数点数（float）はそのまま渡せません。小数を扱う場合は Decimal("12.5") のように変換します。また、query の結果は1回あたりのデータ量に上限があるため、件数が多いときはレスポンスの LastEvaluatedKey を使って続きを取得します。

認証情報はコードに書かず、EC2 や Lambda に付けた IAM ロールから取得させます。ロールの権限は、使うテーブルと必要な操作（dynamodb:GetItem、dynamodb:Query など）だけに絞ります。

インデックスを追加するとき

ソートキー以外の属性で検索したくなった場合は、セカンダリインデックスを使います。

• グローバルセカンダリインデックス（GSI）：別のキーの組み合わせで query できるようにします。テーブル作成後にも追加できます。読み取りは結果整合性のみです。
• ローカルセカンダリインデックス（LSI）：パーティションキーは同じで、別の属性をソートキーにします。テーブル作成時にしか定義できません。

インデックスは書き込みのたびに更新されるため、作りすぎると書き込みのコストが増えます。アクセスパターンに必要な分だけ作ります。

本番運用で有効にしておきたい設定

• ポイントインタイムリカバリ（PITR）：一定期間内の任意の時点にテーブルを復元できます。誤った一括更新から戻せる手段になるため、本番では有効にしておきます。

aws dynamodb update-continuous-backups \
  --table-name Orders \
  --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true

• TTL（有効期限）：指定した属性に入れた Unix 時刻（秒）を過ぎた項目を、自動で削除します。セッション情報や一時データの掃除に向いています。削除は期限ちょうどではなく遅れて行われることがあるので、読み出し側でも期限を確認します。
• 削除保護：作成時に付けなかった場合も、update-table --deletion-protection-enabled で後から有効にできます。

1項目の大きさには上限（400KB）があるため、画像などの大きなデータは S3 に置き、DynamoDB にはその場所だけを保存する設計にします。

WordPress との関係

WordPress 本体のデータベースは MySQL / MariaDB で動く前提で作られており、DynamoDB に置き換えることはできません。DynamoDB を使うのは、WordPress とは別に動かすアプリケーションのデータ（アクセスカウンター、フォームの受付ログ、API 経由で連携するデータなど）を、Lambda などから読み書きする場面です。

まとめ

• テーブル作成前に、アクセスの仕方からパーティションキーとソートキーを決めます。キャパシティモードは迷ったらオンデマンドから始めます。
• CLI では型付き JSON で値を書きます。範囲の取り出しは query を使い、テーブル全体を読む scan は日常処理で避けます。
• 予約語は #name のプレースホルダーで回避し、上書きを防ぎたいときは条件式を付けます。
• 本番では削除保護と PITR を有効にし、IAM ロールの権限を必要な操作だけに絞ります。

• AWS IAMポリシーの書き方
• AWS LambdaとAPI GatewayでAPIを作る