DynoTable

Local secondary indexes must be specified at table creation

TL;DR — ローカルセカンダリインデックス（LSI） は、そのテーブルの作成時にのみ作成でき、後から追加・変更・削除できません。UpdateTable に LSI 用の操作はないため、稼働中のテーブルへ LSI を追加しようとするとバリデーションに失敗します。新しい LSI を得るには、LSI を持つ新しいテーブルを作成してデータを移行するか、オンラインで追加 できる グローバルセカンダリインデックス（GSI） を使う必要があります。

意味

ValidationException: One or more parameter values were invalid: Local secondary
indexes can only be created when a table is created

LSI はベーステーブルとパーティションキーを共有し、代替のソートキーを追加します。DynamoDB は書き込み時にアイテムのパーティションと同じ場所に配置します。この物理的な結合のため、LSI はテーブルの最初の書き込みから存在している必要があります。UpdateTable は GSI の追加/削除をサポートしますが、LSI パラメータは まったく ないため、後付けするために送れるリクエストすら存在しません。正確なメッセージは経路によって異なります（SDK/CLI 呼び出しはクライアント側でパラメータ検証に失敗する場合があり、IaC ツールは独自の表現を出します）が、サービス側の形式は HTTP 400 の ValidationException であり、リトライ不可です。この操作は既存のテーブルでは単にサポートされていません。

発生する理由

  • 稼働中のテーブルへ LSI を追加 — すでに存在するテーブルに新しい LocalSecondaryIndexes エントリを導入するため UpdateTable を呼び出す（または CloudFormation/Terraform テンプレートを編集する）。
  • 既存の LSI を変更 — そのキースキーマやプロジェクションは作成時に固定されており、編集は拒否されます。
  • 再作成 vs. 更新となる IaC の差分 — ツールが、DynamoDB は作成時にしか許可しない LSI の変更をインプレースで更新しようとする。

修正方法

  1. 新しいテーブルを作成 し、LSI を前もって定義してからデータを移行します（スキャンして書き込む、またはオンデマンドのエクスポート/インポート）。
  2. アクセスパターンが許すなら代わりに GSI を使います — GSI は既存のテーブルへオンラインで追加でき、同じパーティションキーを必要としません:
    aws dynamodb update-table --table-name <Table> \
  --attribute-definitions AttributeName=gsi_sk,AttributeType=S \
  --global-secondary-index-updates '[{"Create":{"IndexName":"gsi1", ...}}]'
  3. モデリング時に LSI を計画します — 代替のソートキーは後付けできないため、テーブルが存在する前に決めましょう。

DynoTable でサイズを確認する

LSI のためにテーブルを作り直す前に、DynoTable でアクセスパターンを検証しましょう — ⌘K でテーブルを開き、GSI へのクエリで同じ要件を満たせるかどうかを試します。クエリビルダーは、新しいインデックスが応えるべき KeyConditionExpression を生成します。

料金計算ツールで、LSI の書き込み増幅と GSI を使う案を比べてみましょう。プロファイルの切り替えは ⌘P です。AWS に接続するとインストールを参照してください。

出典

関連するエラー

参考資料

最終検証日 2026-07-13、上記にリンクした公式 AWS ドキュメントに照らして確認しました。

Console なしで DynamoDB を扱う

DynamoDB では実行できない本物の SQL（JOINs、GROUP BY、集計）を実行する高速な DynamoDB デスクトップクライアント。ビジュアル編集と、あなた自身の Bedrock キーで動く AI エージェントを備えています。

ダウンロード料金を見る

30日間無料トライアル、クレジットカード不要 — その後は期限のない Free プラン。