القائمة
DynamoDB テーブルを設計し、NoSQLのよくある落とし穴を避けながら効率的なクエリを書くスキル。テーブル設計・インデックス戦略・クエリ最適化・トランザクション・キャパシティ管理に対応。「DynamoDBのテーブルを設計して」「GSIを追加して」「クエリを最適化して」などで発動。
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/ynitto/sandbox --skill dynamodb-designerيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | dynamodb-designer |
| description | DynamoDB テーブルを設計し、NoSQLのよくある落とし穴を避けながら効率的なクエリを書くスキル。テーブル設計・インデックス戦略・クエリ最適化・トランザクション・キャパシティ管理に対応。「DynamoDBのテーブルを設計して」「GSIを追加して」「クエリを最適化して」などで発動。 |
| metadata | {"version":"1.0.0","tier":"experimental","category":"data","tags":["dynamodb","nosql","aws"]} |
| トリガーワード | 例 |
|---|---|
| テーブル設計 | 「DynamoDB のテーブルを設計して」「テーブル構造を考えて」 |
| インデックス | 「GSI を追加して」「LSI が必要か教えて」「インデックス設計して」 |
| クエリ相談 | 「このクエリを最適化して」「Scan を避けるには」「クエリを書いて」 |
| キャパシティ | 「RCU/WCU を見積もって」「オンデマンドとプロビジョンドどちらが良い？」 |
| TTL / 有効期限 | 「TTL を設定したい」「期限切れデータを自動削除したい」 |
| トランザクション | 「アトミックに書き込みたい」「複数テーブルを同時更新したい」 |
依頼の種類に応じて以下の形式で回答する：
テーブル設計の依頼:
## テーブル設計: <テーブル名>
### ⚠️ シングルテーブル設計の適否
- 適している場合: （アクセスパターンが明確・エンティティ間に親子関係がある等）
- 適さない場合: （アクセスパターンが多様すぎる・チームの習熟度が低い等）
- 採用判断: シングルテーブル / マルチテーブル
### キー構造
| 属性 | 役割 | 型 | 例 |
|------|------|-----|-----|
| pk | パーティションキー | String | USER#123 |
| sk | ソートキー | String | ORDER#2024-01-15 |
### アクセスパターン
| パターン | 操作 | キー条件 | インデックス |
|----------|------|----------|--------------|
| ユーザーの注文一覧 | Query | pk=USER#123 | メインテーブル |
### GSI（必要な場合）
| インデックス名 | パーティションキー | ソートキー | 用途 | 整合性 |
|----------------|-------------------|------------|------|--------|
### LSI（必要な場合）
| インデックス名 | ソートキー | 用途 | 注意: テーブル作成時のみ追加可 |
|----------------|------------|------|-------------------------------|
### 設計上の注意点
- （ホットパーティション・キャパシティ・制限値等の落とし穴を箇条書き）
クエリ相談の依頼:
## クエリ設計
### 推奨操作: Query / Scan / BatchGet
- キー条件: <具体的な条件式>
- フィルター: <FilterExpression があれば（読み取り後適用の注意を添える）>
- ページネーション: <1MB 超の場合は LastEvaluatedKey ループが必要か>
- 整合性: <結果整合性 or ConsistentRead: true が必要か>
### ⚠️ 避けるべきアンチパターン
- （Scan を使いそうなケースへの GSI 代替案等）
キャパシティ見積もりの依頼:
## キャパシティ見積もり
### モード推奨: オンデマンド / プロビジョンド
- 理由: （トラフィック予測可否・コスト観点）
### プロビジョンド選択時の目安
| 項目 | 計算根拠 | 推奨値 |
|------|----------|--------|
| RCU | リクエスト数 × アイテムサイズ(4KB単位) | |
| WCU | 書き込み数 × アイテムサイズ(1KB単位) | |
### 注意点
- （GSI の独立キャパシティ・スロットリングリスク等）
トランザクション相談の依頼:
## トランザクション設計
### 操作種別: TransactWriteItems / TransactGetItems
- 理由: （書き込みのみ → TransactWriteItems、複数アイテムの一貫読み取り → TransactGetItems）
### 操作リスト
| # | テーブル | 操作 | 条件 |
|---|----------|------|------|
| 1 | <テーブル名> | Put / Update / Delete / ConditionCheck | <ConditionExpression があれば> |
### コスト
- 通常操作の 2x — アトミック性が本当に必要か確認する
### ⚠️ 注意点
- 上限: 最大 100 アイテム・合計 4MB
- TransactionConflictException = 同一アイテムへの同時トランザクション—リトライ設計が必要
- （代替案: ConditionExpression の単独書き込みで済む場合はそちらを推奨）
TTL 設計の依頼:
## TTL 設計
- 属性名: <任意の属性名（例: ttl, expires_at）>
- 型: Number（Unix エポック秒—ミリ秒不可）
- 削除タイミング: バックグラウンド処理のため期限切れ後数時間残存する可能性あり
- クエリでの除外: `attribute_exists(ttl) AND ttl > :now` を FilterExpression に追加
ConsistentRead: true が使えるUSER#123、ORDER#456METADATA、ORDER#2024-01-15、ITEM#abcbegins_with を使用LastEvaluatedKey があれば続きがある—ExclusiveStartKey として渡すLastEvaluatedKey が空になるまでループ—よくある間違い：1回の呼び出しで全件取得できると思い込むLimit は評価するアイテム数を制限（返却数ではない）—それでもページネーション処理が必要ConsistentRead: true で強整合性—読み取りキャパシティが 2x となるConditionExpression—条件が偽なら失敗するattribute_not_exists(pk)version = :expected の後にインクリメントするBatchWriteItem はアトミックではない—部分成功あり、UnprocessedItems を確認するTransactWriteItems を使用TransactWriteItems でアトミックなマルチアイテム書き込み—all or nothingTransactGetItems で整合性のあるマルチ読み取り—スナップショット分離attribute_exists(ttl) AND ttl > :now でフィルタ