背景・目的
普段の開発では Kiro を使って AWS リソースの操作やコード生成をしています。最近は Redshift 関連の操作やツール開発にも活用していました。
AWS What's New を眺めていたところ、2026年8月27日に Agent Toolkit for AWS へ Redshift 専用スキルが追加されたアナウンスを見つけました。中身を確認してみると現在の開発に関連しそうだったので、セットアップから試してみることにしました。
まとめ
| 項目 | 内容 |
|---|---|
| これは何 | AI エージェント（Kiro等）から Redshift を操作するための MCP スキルセット |
| 何ができる | テーブル設計相談・COPY エラー調査・クエリチューニング・メタデータ探索・マイグレーションガイドを自然言語で依頼できる |
| 導入コスト | 追加課金なし・インフラ変更不要。MCP 設定の追加のみ |
| 特徴 | SKILL.md 冒頭で「Redshift ≠ PostgreSQL」の差異を列挙し、LLM が PostgreSQL 前提で回答するのを防ぐ |
| 対応環境 | Provisioned / Serverless 両対応。質問文から判定し、不明なら確認してくれる |
概要
用語の整理
-
Agent Toolkit for AWS: AWS が提供する MCP サーバー＋スキル群の総称。AIエージェントが AWS API を認証付きで実行できる基盤 -
MCP（Model Context Protocol）: AI エージェントが外部ツールを呼び出すためのプロトコル -
スキル（Skills）: 特定の AWS サービス向けにキュレーションされた手順書＋リファレンス集。AI エージェントがタスクに応じて自動ロードする -
aws-data-analytics プラグイン: MCP Server 設定と Redshift スキルをバンドルしたプラグイン。1コマンドで導入可能 -
ワイヤプロトコル: クライアントとサーバー間の通信手順。Redshift は PostgreSQL のワイヤプロトコルを採用しているため、psqlや PostgreSQL 用の JDBC ドライバでそのまま接続できる
アーキテクチャ
構成はシンプルです。
AI エージェント（Kiro / Claude Code / Cursor）
↓ MCP プロトコル
AWS MCP Server（認証付き API 実行・監査ログ）
↓ AWS CLI / Redshift Data API
Amazon Redshift（Provisioned or Serverless）
AWS MCP Server は認証済みの AWS API 実行をサンドボックス環境で代行します。AI エージェントが直接 AWS クレデンシャルを扱うのではなく、MCP Server が IAM 認証を仲介する設計です。
The plugin bundles the AWS MCP Server configuration and a curated set of agent skills in a single install.
プラグインは AWS MCP Server の設定と、厳選されたエージェントスキル群を1回のインストールでまとめて提供します。
https://docs.aws.amazon.com/agent-toolkit/latest/userguide/quick-start.html
Redshift Skills の中身
スキルの実体は GitHub リポジトリ上の SKILL.md と references/ 配下の7つのリファレンスファイルです。
| ファイル | 内容 |
|---|---|
| SKILL.md | エントリポイント。ルーティングテーブル・セーフティガードレール・セキュリティ考慮事項 |
| redshift-sql-syntax.md | PostgreSQL との差異一覧。LLM が最初に読むべきファイル |
| redshift-sql-ddl-copy.md | CREATE TABLE（DISTKEY/SORTKEY/ENCODE）、COPY/UNLOAD、IAM_ROLE、Iceberg 対応 |
| redshift-sql-functions-types.md | LISTAGG、DATEADD/DATEDIFF、型マッピング（text->VARCHAR(256)） |
| redshift-sql-extensions-semantics.md | QUALIFY、PIVOT/UNPIVOT、MERGE、SUPER型、JSON/PartiQL |
| redshift-sql-metadata.md | SHOW コマンド、SYS_ ビュー、権限、「relation does not exist」診断フロー |
| redshift-sql-recipes-load-api.md | COPY エラー調査、Data API 非同期クエリ、ポーリングパターン |
| redshift-sql-materialized-views.md | MV の AUTO REFRESH、staleness 検出 |
「Redshift ≠ PostgreSQL」の対応
これまで AI エージェントに Redshift の SQL を聞くと、PostgreSQL 前提の回答が返ってくることがありました。Redshift は PostgreSQL のワイヤプロトコルを採用しているため、LLM は「PostgreSQL と同じだろう」と判断しがちです。しかし実際には DDL や関数に独自仕様が多く、PostgreSQL の知識で書いたコードがそのまま通らないケースがあります。今回のスキルはこの差異を Redshift 固有のリファレンスとして持っているので、正しい回答が期待できます。
SKILL.md の冒頭には以下のように書かれています。
Redshift speaks PostgreSQL's wire protocol and shares much of its surface syntax, so LLMs assume PostgreSQL behavior carries over -- it frequently does not.
Redshift は PostgreSQL のワイヤプロトコルで会話し、構文の多くを共有しています。そのため LLM は PostgreSQL の振る舞いがそのまま通用すると思い込みますが、実際にはかなりの頻度で通用しません。
主な差異は以下の通りです（SKILL.md の Critical Facts セクションから抜粋して整理）。
| PostgreSQL の書き方 | Redshift での正解 | 理由 |
|---|---|---|
CREATE INDEX |
使えない | Redshift にインデックスは存在しない |
string_agg() |
LISTAGG() |
関数名が異なる |
text 型 |
VARCHAR(256) |
暗黙変換される。明示的に VARCHAR(max) を使う |
SERIAL |
IDENTITY 列 |
シーケンスが存在しない |
UNIQUE / PRIMARY KEY
|
情報的のみ（非強制） | 重複行が入ってもエラーにならない |
SUBSTR(col, ...) |
SUBSTRING(col, ...) |
SUBSTR はリーダーノード限定。テーブル列には使えない |
pg_catalog |
SHOW コマンド / SYS_ ビュー |
pg_catalog は不完全 |
セーフティガードレール（Safety Guardrails）
AI エージェントが危険な操作を実行しないよう、3段階の制御が組み込まれています。
BLOCK: DROP DATABASE, DELETE without WHERE, publicly-accessible=true, GRANT ALL ON ALL
WARN then confirm: RESIZE, RESTORE, VACUUM on large tables, ALTER PASSWORD, WLM config change
Confirm: CREATE, GRANT specific, COPY, UNLOADBLOCK（即拒否）: DROP DATABASE、WHERE なし DELETE、publicly-accessible=true、GRANT ALL ON ALL
WARN->確認: RESIZE、RESTORE、大テーブルの VACUUM、ALTER PASSWORD、WLM 設定変更
確認: CREATE、個別 GRANT、COPY、UNLOAD
分類の基準は破壊性とリカバリ可能性です。
- BLOCK（即拒否）: 復旧不能または広範囲に影響する操作。
DROP DATABASEはデータベース全体の消失、WHERE なしDELETEは全行削除、publicly-accessible=trueはネットワーク的な露出 - WARN->確認: 復旧可能だが影響が大きい操作。
RESIZEはダウンタイムを伴い、VACUUMは大テーブルで長時間ロックする可能性がある - 確認: 通常の DDL/DML 操作。
CREATEやCOPYは日常的に使うが、意図しない実行を防ぐために確認を挟む
COPY が BLOCK ではなく「確認」止まりなのは、データの追加はアペンドであり DELETE で取り消せるためです。一方 DROP DATABASE が BLOCK なのは、ポイントインタイムリカバリ以外に戻す手段がないためです。
ルーティングテーブル
ユーザーの質問内容に応じて、どのリファレンスファイルをロードすべきかをマッピングする仕組みです。
When a question matches a row below, you MUST load and read the referenced file BEFORE answering.
ユーザーの質問が以下の行に該当する場合、回答の前に必ず該当ファイルをロードして読むこと。
例えば「COPY failed」と聞かれたら redshift-sql-recipes-load-api.md を、「list tables」なら redshift-sql-metadata.md を自動ロードします。これにより、AI エージェントが必要な知識だけをコンテキストに読み込む設計になっています。
リファレンスの分割構成
SKILL.md 自体は約300行のエントリポイントで、ドメイン知識は7つのリファレンスファイルに分離されています。ルーティングテーブルで質問の意図を判定し、該当するリファレンスだけをロードする仕組みです。
各ファイルの分担は以下の通りです。
| 分割軸 | ファイル | 想定される質問 |
|---|---|---|
| SQL 方言の差異 | redshift-sql-syntax.md | 「PostgreSQL との違いは？」「どの構文が使える？」 |
| DDL とデータロード | redshift-sql-ddl-copy.md | 「テーブル定義」「COPY/UNLOAD」「Iceberg」 |
| 関数と型 | redshift-sql-functions-types.md | 「LISTAGG」「DATEADD」「型変換」 |
| 拡張構文と意味論 | redshift-sql-extensions-semantics.md | 「QUALIFY」「MERGE」「JSON/SUPER」 |
| メタデータと権限 | redshift-sql-metadata.md | 「テーブル一覧」「権限エラー」「SHOW コマンド」 |
| COPY エラーと Data API | redshift-sql-recipes-load-api.md | 「ロード失敗」「非同期クエリ」 |
| マテリアライズドビュー | redshift-sql-materialized-views.md | 「MV リフレッシュ」「staleness」 |
Serverless と Provisioned の差異吸収
Redshift には Serverless（ワークグループ）と Provisioned（クラスター）の2つのデプロイモデルがあり、使える API やシステムビューが異なります。SKILL.md はこの差異を以下のように吸収しています。
Establish this before answering -- APIs, system tables, and capabilities differ.
回答の前にどちらかを確定すること。API、システムテーブル、使える機能が異なる。
具体的な差異を表にまとめます（SKILL.md の STEP 0 セクションより）。
| 項目 | Provisioned | Serverless |
|---|---|---|
| 識別子 | クラスター（--cluster-identifier） |
ワークグループ（--workgroup-name） |
| システムビュー |
SYS_ + SVV_ + STL_ + STV_ + SVL_ + SVCS_（単一AZのみ。Multi-AZ では無効） |
SYS_ + SVV_ の一部のみ |
| クレデンシャル API | redshift:GetClusterCredentials |
redshift-serverless:GetCredentials |
STL_ や STV_ は Provisioned 単一AZ でしか使えないため、Serverless 環境で stl_load_errors を参照しようとするとエラーになります。SKILL.md は「COPY デバッグには sys_load_error_detail を使え」と明記しており、どちらのデプロイモデルでも動く方法を優先して案内する設計です。
実践
1. 前提条件の確認
以下が必要です。
-
uvがインストール済み（MCP プロキシに必要） - AWS CLI v2.35.0 以降がインストール済み
- AWS IAM クレデンシャルがローカルに設定済み
- Kiro がインストール済み
-
uv のインストールを確認します
uv --version -
AWS クレデンシャルの設定を確認します
aws sts get-caller-identity
2. Kiro に AWS MCP Server を設定する
-
Kiro の MCP 設定ファイル（
~/.kiro/settings/mcp.json）に以下を追加します{ "mcpServers": { "aws-mcp": { "command": "uvx", "timeout": 100000, "transport": "stdio", "args": [ "mcp-proxy-for-aws==1.6.3", "https://aws-mcp.us-east-1.api.aws/mcp", "--metadata", "AWS_REGION=us-west-2" ] } } }AWS_REGIONは自分のリージョンに合わせて変更します（例:ap-northeast-1）。 -
Redshift スキルをインストールします
aws agent-toolkit add-skill --skill-name redshift-guide --agent kiro --region us-east-1
利用可能なスキルは aws agent-toolkit search-skills --search-query redshift --region us-east-1 で検索できます。
MCP Server の設定も一括で行いたい場合は、aws configure agent-toolkit でインタラクティブウィザードを起動する方法もあります。エージェントの自動検出->MCP Server 接続->スキルインストールをまとめて行えます。
3. 接続確認
-
Kiro で新しい会話を開始し、以下を聞きます
利用可能なAWSリージョンはどれですか？ === 利用可能なAWSリージョンは以下の37リージョンです。 ## アジア太平洋 (13) ・・・・ 合計37リージョンです。特定のリージョンでのサービス提供状況を確認したい場合はお知らせください。 -
AWS リージョンの一覧が返ってくれば接続成功。認証エラーが出た場合は AWS クレデンシャルの設定を確認
4. Redshift に話しかけてみる
接続確認ができたら、Redshift 関連の質問を試します。MCP 経由なので日本語でも英語のどちらでも問題ありません。
メタデータ探索
-
メタデータを探索します。※
${WORKGROUP_NAME}には、実際に利用しているものを指定しますRedshift Serverless ワークグループ ${WORKGROUP_NAME} のテーブル一覧を見せて ==== > ワークグループ ${WORKGROUP_NAME}（東京リージョン）のテーブル一覧です。 > ユーザーテーブルは別データベース ${DATABASE_NAME} にありました。 ## データベース一覧 - dev（既定・ユーザーテーブルなし。pg_auto_copy.copy_job_detail ビューのみ） - ${DATABASE_NAME}（ユーザーテーブルあり） ## ${DATABASE_NAME} のテーブル（public スキーマ） | データベース | スキーマ | テーブル | 種別 | |---|---|---|---| | ${DATABASE_NAME} | public | daily_sales_summary | TABLE | | ${DATABASE_NAME} | public | sales | TABLE | | ${DATABASE_NAME} | public | stg_test | TABLE | svv_all_tables で全DB横断取得し、システムスキーマ（pg_catalog / information_schema / pg_internal 等）は 除外しています。 特定テーブルのカラム定義や行数、DDL を確認したい場合はテーブル名を指定してください。
エージェントは Data API 経由で SQL を実行し、結果を返します。
COPY エラー調査
COPY エラーの調査を行います。
-
事前にテーブルを準備します
Redshift Serverless のワークグループ ${WORKGROUP_NAME} に、テスト用テーブルを作ってください。 id INTEGER, name VARCHAR(10), created_at TIMESTAMP の3列で === > テーブルを作成しました。作成後にカラム定義を確認済みです。 作成先: ${WORKGROUP_NAME} / ${DATABASE_NAME} / public.test_table | カラム | データ型 | 桁数 | |---|---|---| | id | integer | -- | | name | character varying | 10 | | created_at | timestamp without time zone | -- | 指定通り id INTEGER / name VARCHAR(10) / created_at TIMESTAMP の3列で作成できています。 -
次に、わざと型が合わないCSVを作成します
今作ったテーブルに対して、わざと型が合わないCSVをローカルに作ってください。 === > 作成しました: ~/test_table_bad.csv 仕込んだ型不一致は以下の通りです（ヘッダ行付き、8データ行）。 | 行 | id | name | created_at | 狙った違反 | |---|---|---|---|---| | 1 | 1 | Alice | 2026-08-30 10:00:00 | 正常（対照） | | 2 | abc | Bob | ... | id が非整数（文字列） | | 3 | 3 | ThisNameIsWayTooLong(20字) | ... | name が VARCHAR(10) 超過 | | 4 | 4 | Carol | not-a-timestamp | created_at が不正な日時 | | 5 | 12.5 | Dave | ... | id が小数（INTEGER 不一致） | | 6 | 6 | Eve | 2026-13-45 99:99:99 | created_at が範囲外の日時 | | 7 | 空 | Frank | ... | id が空（NULL/型変換） | | 8 | 8 | Grace | 空 | created_at が空 | -
CSVをS3にアップロードします
先ほど作成したCSVを ${S3_BUCKET}/test_table/ 下に配置してください。 === > アップロードしました。 - 配置先: s3://${S3_BUCKET}/test_table/test_table_bad.csv - サイズ: 234 B（HeadObject で確認済み） -
COPYコマンドを実行します
このCSVを先ほどのテーブルにCOPYしてください -
エラーを調査します
S3 からの COPY が失敗しました。sys_load_error_detail を確認してください === > 完了しました。MAXERROR 100 で全行を試行し、型不一致を全件ログできました。 ## 検出された型不一致エラー（sys_load_error_detail） | CSV行 | 列 | 型 | code | エラー | 元の値 | |---|---|---|---|---|---| | 3 | id | int4 | 1207 | Invalid digit, Value 'a' | abc（非整数） | | 4 | name | varchar | 1204 | String length exceeds DDL length | ThisNameIsWayTooLong（20字 > VARCHAR(10)） | | 5 | created_at | timestamp | 8001 | Invalid data | not-a-timestamp | | 6 | id | int4 | 1207 | Invalid digit, Value '.' | 12.5（小数） | | 7 | created_at | timestamp | 8001 | Invalid data | 2026-13-45 99:99:99（範囲外） | 仕込んだ違反がすべて期待通りに検出されました。 ## ロードされた行（3件） | id | name | created_at | 備考 | |---|---|---|---| | 1 | Alice | 2026-08-30 10:00:00 | 完全な正常行 | | 8 | Grace | (null) | created_at 空 -> NULL として許容 | | (null) | Frank | 2026-08-30 10:30:00 | id 空 -> NULL として許容 | ## 学びのポイント - 空文字は型エラーにならず NULL 扱いになる（id/created_at が空の行はロードされた）。 「型不一致」として弾きたいなら NOT NULL 制約や COPY の BLANKSASNULL/EMPTYASNULL の扱いを設計する必要がある - MAXERROR 0（既定）は最初の1件で停止、MAXERROR N で N 件までスキップして継続。 エラー調査時は大きめの値で全件ログさせるのが定石 - Serverless では COPY 用ロールはネームスペースへの関連付けが必須 （ARN 直指定だけでは不可）
エージェントは sys_load_error_detail を照会し、エラーの原因（型不一致・NULL 制約違反等）を特定します。
クエリチューニング
-
事前にテスト用テーブルを2つ作ります（DISTKEYをわざと不適切にする）
ワークグループ ${WORKGROUP_NAME} で以下を実行してください。 ローカルからのデータ転送は不要です。Redshift 上の SQL だけでテストデータを生成してください。 1. テーブル作成（DISTKEYは指定せず EVEN 分散にする） - orders: order_id INT, customer_id INT, amount DECIMAL(10,2), order_date DATE - customers: customer_id INT, name VARCHAR(100), region VARCHAR(50) 2. customers に1万行を INSERT（generate_series で customer_id を 1〜10000） region は 'Tokyo','Osaka','Nagoya','Fukuoka','Sapporo' の5値をローテーション 3. orders に100万行を INSERT（generate_series で order_id を 1〜1000000） customer_id は 1〜10000 のランダム、amount は 100〜10000 のランダム、order_date は直近1年のランダム === > 完了しました。${DATABASE_NAME} にテストデータを生成し、検証済みです。 ## 作成結果 | テーブル | 行数 | 分散 | |---|---|---| | customers | 10,000 | DISTSTYLE EVEN | | orders | 1,000,000 | DISTSTYLE EVEN | ## 実装メモ（Redshift特有の対応） - generate_series はリーダーノード専用で INSERT ... SELECT に使えないため、 0〜9の桁テーブルをクロス結合して連番を生成（customers=10^4、orders=10^6） - 乱数は FLOOR(RANDOM()*N) 系でコンピュートノード上で生成 - 両テーブルとも DISTSTYLE EVEN（DISTKEY なし）。orders JOIN customers ON customer_id では再分散（DS_BCAST/DS_DIST）が発生するので、チューニング題材として好適 -
クエリを実行し、分析させます
結論から言うと、「遅い」の正体はプラン品質ではなくRedshift Serverlessのコールドスタートでした。以下がやり取りの詳細です。
```bash
以下のクエリの実行計画を分析してください。遅い場合は改善案を出してください
SELECT c.region, COUNT(*), SUM(o.amount)
FROM orders o JOIN customers c ON o.customer_id = c.customer_id
GROUP BY c.region
ORDER BY SUM(o.amount) DESC
===
> 実行計画と実測が取れました。
## 現状の実行計画の問題点
XN Hash Join DS_BCAST_INNER (cost=... rows=50000000 ...) <- ①customersを全ノードにブロードキャスト
Hash Cond: (o.customer_id = c.customer_id)
-> Seq Scan on orders (rows=1000000)
-> Hash -> Seq Scan on customers (rows=10000)
----- Tables missing statistics: customers, orders ----- <- ②統計情報なし
- 実測 約27.8秒（サーバ実行時間）と遅い
- ① DS_BCAST_INNER: EVEN分散のため、join時に customers を全ノードへブロードキャスト
- ② 統計情報なし（ANALYZE未実行）: join出力を 5000万行と見積もり（実際は100万行）。
オプティマイザが盲目状態で、メモリ配分・プランが最適化されない
改善を段階的に適用して実測比較します。まず一番効く ANALYZE、次に分散方式の変更を試します。
## 結論：このクエリのプランは適切。遅かったのは「初回コールドスタート」
sys_query_history の時間内訳（同一クエリの推移）:
| 実行 | elapsed | compile | execution | 状況 |
|---|---|---|---|---|
| 1回目 | 18.2s | 1.16s | 16.79s | コールド（初回） |
| 2回目 | 0.26s | 0.07s | 0.14s | ウォーム |
| 3回目 | 0.00s | 0.00s | 0.00s | 結果キャッシュヒット |
- 初回の遅さは execution 16.8秒が大半で、コンパイル(1.16s)ではなかった
- 同じプランのまま2回目は execution 0.14秒
-> 遅さの正体はプラン品質ではなく、Redshift Serverless のコールドスタート
（コンピュートのウォームアップ＋マネージドストレージからのブロックキャッシュ未ロード）
- 3回目が 0.00s なのは結果キャッシュ（同一クエリ・データ不変で即返し）
## 実行計画そのものの評価
- DS_BCAST_INNER（customers を全ノードにブロードキャスト）は、この形では最適。
10,000行の小さなディメンションを配るのは安価で、むしろ正しい選択。
「DS_BCAST＝悪」ではない
- ANALYZE前は join出力を 5000万行と誤見積もり -> ANALYZE後は 102万行と正しく見積もり。
プラン構造は変わらなかったが、統計は入れておくべき（メモリ配分やより複雑なクエリで効く）
## 改善案（優先度順）
1. ANALYZE を実行しておく（実施済み） -- 統計の鮮度確保。効果は本クエリでは限定的だが基本の衛生
2. 「遅い」を測るときは2回目以降で測る／コールドを除外
-- Serverless は初回にコンピュート起動＋キャッシュ充填が入る。
SET enable_result_cache_for_session TO off; で結果キャッシュだけ切れば、実行部分を正しく測れる
3. 本当に broadcast を消したいなら
-- 小さい customers を DISTSTYLE ALL（全ノード複製）にすると DS_DIST_NONE になる。
ただし本件は warm で0.14sなので効果はごく僅か
4. orders に SORTKEY（例 order_date）
-- 今回の全件集計では効果薄。日付範囲フィルタを足すクエリなら効く
```
遅いクエリを作ろうとしたが、エージェントが「遅いのはコールドスタートであってプランは適切」と正直に教えてくれました。
テーブル設計相談
-
あまり前提を伝えずに雑に設計相談を投げてみます
売上データのファクトテーブルを作ります。DISTKEY と SORTKEY はどうすべきですか === > DISTKEY / SORTKEY は「どんなクエリで使うか」で決まります。 > まず判断基準を示し、売上ファクトの典型パターンでの推奨を出します。 ## 決め方の原則（Redshift） | キー | 役割 | 選ぶ基準 | |---|---|---| | DISTKEY | ノード間のデータ配置。join の再分散を消す | 最も大きい/頻繁な join の結合キー | | SORTKEY | ブロック内の並び。ゾーンマップで不要ブロックをスキップ | WHERE の範囲フィルタ列（特に日付） | ## 売上ファクトの典型推奨 ### DISTKEY - 第一候補: customer_id（＝顧客ディメンションとの join キー）。ただし条件付き - customers 側も同じ customer_id を DISTKEY にすれば co-located join（DS_DIST_NONE） - ただし顧客ディメンションが小さい（数万〜数十万行）なら、 customers を DISTSTYLE ALL（全ノード複製）にする方が簡単で速いことが多い - skew に注意: 特定顧客に売上が偏ると、そのノードにデータが集中して遅くなる - 支配的な join が無い/複数ディメンションと均等に join するなら DISTSTYLE EVEN が無難 ### SORTKEY - 第一候補: order_date（日付列）を先頭にした COMPOUND SORTKEY - 売上分析は WHERE order_date BETWEEN ... が定番 -> ゾーンマップで対象外ブロックをスキップでき、スキャン量が激減 ## 迷うなら AUTO（実運用の既定推奨） Redshift の Automatic Table Optimization（DISTSTYLE AUTO / SORTKEY AUTO）は、 実際のワークロードを観測して自動調整します。設計が固まっていない初期は AUTO で始め、 svv_table_info の skew や svv_alter_table_recommendations を見て手動固定に切り替えるのが現実的です。 ## 精度を上げるための確認事項 的確に決めるには以下を教えてください: 1. 主な join 相手とその行数 2. customer_id（や join キー）の偏り 3. 典型クエリの WHERE 4. データ規模（行数・増加ペース）
エージェントはアクセスパターンに基づいて DISTKEY/SORTKEY の推奨を返します。また必要に応じて、設計を詳細化するために質問してくれます。
考察
- Redshift 固有の差異（PostgreSQL との違い）をスキル側で吸収する設計は、同じ問題に何度もハマる運用チームにとって実用的。特に
CREATE INDEXやUNIQUE非強制は初見で引っかかりやすい - セーフティガードレールの3段階設計（BLOCK/WARN/確認）は、sandbox 環境での利用を前提にしても安心感がある。
DROP DATABASE即拒否は正しい - Provisioned と Serverless でシステムビューが異なる点を SKILL.md のルーティングテーブルで吸収している点は嬉しい。ユーザーが違いを意識しなくてよい
- スキルのインストールがシンプル。
aws-data-analyticsプラグイン1つで完結するのは導入障壁が低い - SKILL.md のルーティングテーブル方式（質問->参照ファイルのマッピング）は、自前のスキルを作る際のデザインパターンとしても参考になった
参考