[アップデート] Amazon Redshift が Agent Toolkit for AWS と統合され AI エージェントから管理できるようになったので試してみました
クラウド事業統括本部の石川です。Amazon Redshift が Agent Toolkit for AWS と統合され、AI エージェント向けの Redshift skills が提供されましたので、Claude Codeで実際に試してみました。
Amazon Redshift が Agent Toolkit for AWS と統合され、Claude Code や Kiro、Cursor といった AI エージェントから、Amazon Redshift のデータウェアハウスやデータレイクの構築・クエリ・トラブルシューティング・移行が直接行えるようになります。追加料金なし、既存インフラへの変更も不要で利用できるため、日常的に Amazon Redshift を運用されている方はすぐに試せるアップデートです。
Agent Toolkit for AWS とは
Agent Toolkit for AWS は、AI コーディングエージェントが AWS 上で効果的に構築を行えるようにするためのツール群です。2026 年 5 月に発表され、以下の 3 つの要素で構成されています。
-
Agent Skills(エージェントスキル)
特定のタスクを完遂するための手順・スクリプト・リファレンス資料をまとめたパッケージ。エージェントは必要なスキルだけをオンデマンドで読み込むため、コンテキストウィンドウの消費を抑えられます
-
AWS MCP Server
フルマネージドの MCP(Model Context Protocol)サーバー。IAM ベースのガードレール、CloudWatch / CloudTrail による監視、サンドボックス化されたコード実行環境を備え、ユーザーに代わって認証済みの AWS API を実行します
-
Agent Plugins(エージェントプラグイン)
AWS MCP Server の設定と厳選されたスキルセットを 1 回のインストールにまとめたもの
今回の統合は、この AWS MCP Server と Amazon Redshift 向けのスキル(Redshift skills)を組み合わせたものです。
アップデート内容
今回の統合では、認証済みの AWS API 実行を担う AWS MCP Server と、Amazon Redshift 向けの知識を提供する Redshift スキルが組み合わされます。
Redshift skills とは
Agent Skills は、特定のタスクを完遂するための手順・スクリプト・リファレンス資料をまとめたパッケージです。エージェントは必要なスキルだけをオンデマンドで読み込むため、コンテキストウィンドウの消費を抑えられます。
Redshift skills はその Amazon Redshift 版で、SQL 構文リファレンス、メタデータディスカバリー、データロードパターン、マテリアライズドビューのベストプラクティス、関数とデータ型のガイダンス、そして Qualify・Pivot・Super といった拡張機能をカバーします。スキルは次のような構成になっていました。
エージェントは SKILL.md の Routing Table に従い、質問の意図に一致したファイルだけを読み込みます。
導入方法
aws-data-analytics プラグインをインストールすると、AWS MCP Server の設定と Redshift skills がまとめて導入されます。
Claude Code の場合
claudeコマンドを実行して、インタラクティブモードで以下のコマンドを順に実行してください。
/plugin install aws-data-analytics@claude-plugins-official
/reload-plugins
AWS CLI(バージョン 2.36.35 以降)を利用している場合は、対話型のセットアップウィザードで、インストール済みの AI コーディングエージェントを検出してスキルのインストールと AWS MCP Server の接続設定を一度に行えます。
% aws configure agent-toolkit --region us-east-1
Detecting installed AI coding agents...
✓ Claude Code — ~/.claude/skills
✗ Cline — ~/.cline/skills (not found)
✓ Codex — ~/.agents/skills/
✓ Cursor — ~/.cursor/skills
✓ Gemini CLI — ~/.agents/skills/
✓ Kiro — ~/.kiro/skills
✗ OpenClaw — ~/.openclaw/skills (not found)
✗ OpenCode — ~/.agents/skills (not found)
✗ Pi — ~/.pi/agent/skills (not found)
✗ Windsurf — ~/.agents/skills (not found)
Select agents to configure (space to toggle, up/down arrows to navigate, enter t
o confirm):
[x] Claude Code — ~/.claude/skills
[x] Codex — ~/.agents/skills/
[x] Cursor — ~/.cursor/skills
[x] Gemini CLI — ~/.agents/skills/
[x] Kiro — ~/.kiro/skills
ウィザードは Kiro、Cursor、Claude Code など複数のエージェントに対応しています。
なお、AWS MCP Server にアクセスできるエージェントであれば、事前インストールなしにランタイムでスキルを検出・読み込むことも可能です。
Redshift skills の中身
Redshift skills は GitHub 上でオープンソースとして公開されているため、中身を確認できます。ここが今回のアップデートで最も興味深い部分でした。
スキルカタログを確認する
AWS CLI にはバージョン 2.35.0 以降で aws agent-toolkit コマンドが追加されており、スキルの検索やインストールができます。まずは Amazon Redshift 関連のスキルを検索してみます。Agent Toolkit の API 自体は us-east-1 でのみ提供されています。
% aws agent-toolkit search-skills --search-query "redshift SQL" --region us-east-1
{
"skills": [
{
"name": "redshift-guide",
"description": "Amazon Redshift is NOT PostgreSQL — corrects PostgreSQL-derived LLM mistakes; covers Redshift-specific SQL, DDL, COPY/UNLOAD, system views, metadata discovery, and operational patterns. Applies ONLY when the task is about Redshift itself (cluster, Serverless workgroup, or Redshift SQL). Pushes back on: CREATE INDEX, string_agg, pg_catalog, text type, SERIAL, stl_query, LATERAL, RETURNING. Triggers on: Redshift SQL, Redshift CREATE TABLE, Redshift COPY/UNLOAD, slow Redshift query, Redshift permission denied, Redshift disk full, Redshift system views, QUALIFY, PIVOT, MERGE, Redshift Data API, Redshift WLM, concurrency scaling, Redshift resize, Redshift Spectrum external tables. Does NOT apply to (defer to that service's own skill): Amazon S3 storage/bucket policies, Athena or Glue queries/catalogs, data-lake or Iceberg work outside Redshift, Aurora, RDS, or DynamoDB — but S3/Glue ARE in scope for Redshift COPY, UNLOAD, or data-lake queries (external schemas/tables on S3).",
"skillVersion": "v1",
"categories": []
},
:
:
:
{
"name": "querying-aws-sagemaker-catalog",
"description": "Runs SQL analytics on SageMaker Catalog asset metadata tables exported as Apache Iceberg in S3 Tables. Covers governance queries, asset growth tracking, ownership audits, time-travel over catalog state, and metadata quality analysis. Applies when querying catalog inventory, finding assets without descriptions, comparing catalog snapshots, or auditing data ownership. Trigger phrases: catalog inventory SQL, how many assets, assets without descriptions, asset growth over time, who owns this data, catalog governance, data quality audit, catalog analytics.",
"skillVersion": "v1",
"categories": []
}
]
}
redshift-guide の説明文が「Amazon Redshift is NOT PostgreSQL」から始まっています。続く記述には「Pushes back on: CREATE INDEX, string_agg, pg_catalog, text type, SERIAL, stl_query, LATERAL, RETURNING」とあり、LLM が PostgreSQL の知識で書いてしまう SQL を押し返すことが目的だと明記されていました。
スキルの中身を取得する
スキルがどのようなファイルで構成されているかを確認します。
% aws agent-toolkit get-skill-metadata --skill-name redshift-guide --region us-east-1
{
"name": "redshift-guide",
"skillVersion": "v1",
"description": "Amazon Redshift is NOT PostgreSQL — corrects PostgreSQL-derived LLM mistakes; covers Redshift-specific SQL, DDL, COPY/UNLOAD, system views, metadata discovery, and operational patterns. Applies ONLY when the task is about Redshift itself (cluster, Serverless workgroup, or Redshift SQL). Pushes back on: CREATE INDEX, string_agg, pg_catalog, text type, SERIAL, stl_query, LATERAL, RETURNING. Triggers on: Redshift SQL, Redshift CREATE TABLE, Redshift COPY/UNLOAD, slow Redshift query, Redshift permission denied, Redshift disk full, Redshift system views, QUALIFY, PIVOT, MERGE, Redshift Data API, Redshift WLM, concurrency scaling, Redshift resize, Redshift Spectrum external tables. Does NOT apply to (defer to that service's own skill): Amazon S3 storage/bucket policies, Athena or Glue queries/catalogs, data-lake or Iceberg work outside Redshift, Aurora, RDS, or DynamoDB — but S3/Glue ARE in scope for Redshift COPY, UNLOAD, or data-lake queries (external schemas/tables on S3).",
"categories": [],
"files": [
{
"path": "SKILL.md"
},
{
"path": "references/redshift-sql-ddl-copy.md"
},
{
"path": "references/redshift-sql-extensions-semantics.md"
},
{
"path": "references/redshift-sql-functions-types.md"
},
{
"path": "references/redshift-sql-materialized-views.md"
},
{
"path": "references/redshift-sql-metadata.md"
},
{
"path": "references/redshift-sql-recipes-load-api.md"
},
{
"path": "references/redshift-sql-syntax.md"
}
]
}
エントリポイントの SKILL.md と、7 つのリファレンスファイルという構成でした。個別のファイルは get-skill-file で取得できます。このコマンドが列挙するのは AWS CLI 経由でインストールしたスキルです。
なぜ LLM は Amazon Redshift を PostgreSQL と間違えるのか
疎通確認を兼ねて version() を叩いたところ、答えがそのまま返ってきました。
SELECT version();
PostgreSQL 8.0.2 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.4.2 20041017 (Red Hat 3.4.2-6.fc3), Redshift 1.0.416217
自称が「PostgreSQL 8.0.2」です。LLM がこの文字列を見て PostgreSQL の作法で SQL を書き始めるのは、ある意味で当然の反応と言えます。スキルが SELECT version() では Serverless かプロビジョンドかを識別できないと明記しているのも頷けます。
やってみた
前提条件
- AWS CLI: 2.36.35
- 検証リージョン: ap-northeast-1(Amazon Redshift)、us-east-1(Agent Toolkit)
- Amazon Redshift Serverless / Amazon Redshift バージョン: 1.0.416217
PostgreSQL 流の SQL は通るのか
ここからが本題です。リファレンスの redshift-sql-syntax.md には、PostgreSQL の感覚で書くと失敗するパターンが表でまとめられています。まず string_agg を試してみます。
SELECT string_agg(v, ',') FROM (SELECT 'a' AS v UNION ALL SELECT 'b') t;
ERROR: function string_agg(character varying, "unknown") does not exist
Hint: No function matches the given name and argument types. You may need to add explicit type casts.
記載どおり失敗しました。スキルが提示する代替は LISTAGG です。
SELECT LISTAGG(v, ',') WITHIN GROUP (ORDER BY v) AS joined
FROM (SELECT 'a' AS v UNION ALL SELECT 'b') t;
joined
a,b
こちらは成功しました。
システムビューはどうか
redshift-sql-metadata.md には、STL_ や STV_ はプロビジョンドの単一 AZ 限定であり、どの構成でも動く SYS_ 系を使うべきだと書かれています。Serverless ワークグループで stl_query を参照してみます。
SELECT * FROM stl_query LIMIT 1;
ERROR: permission denied for relation stl_query
参照できませんでした。ただし、返ってきたエラーは「リレーションが存在しない」ではなく「permission denied」でした。スキルの記述は「Serverless には存在しない」という表現ですが、実際の挙動としては権限エラーとして表面化するようです。エージェントがこのエラーだけを見ると権限不足と誤認する可能性があるため、ここは把握しておきたい差分です。
推奨されている SYS_ 系のビューも確認します。
SELECT query_id, status FROM sys_query_history ORDER BY start_time DESC LIMIT 3;
query_id status
1412360 running
1412359 success
1412358 success
こちらは問題なく参照できました。
Redshift 独自拡張 QUALIFY を試す
redshift-sql-extensions-semantics.md には「Extensions LLMs under-use」という節があり、QUALIFY がその筆頭に挙げられています。ウィンドウ関数の結果をサブクエリで包まずに絞り込める構文です。
SELECT v FROM (SELECT 'a' AS v UNION ALL SELECT 'b' UNION ALL SELECT 'c') t
QUALIFY ROW_NUMBER() OVER (ORDER BY v DESC) = 1;
v
c
サブクエリで row_number を計算して外側で絞り込む、という書き方をせずに済みました。
リーダーノード限定関数の罠
SKILL.md には「SUBSTR() is leader-node-only — works on literals but errors on table columns」と書かれ、想定されるエラーメッセージまで記載されています。まずは定数から作ったサブクエリで試してみました。
SELECT SUBSTR(v,1,1) FROM (SELECT 'abc' AS v UNION ALL SELECT 'def') t;
substr
a
d
期待に反して成功しました。定数のみで構成されたサブクエリはリーダーノードで評価されるため、記述どおりの条件になっていなかったようです。そこで、実際にデータを持つシステムビューの列に対して同じ関数を適用してみます。
SELECT SUBSTR(status,1,3) AS s FROM sys_query_history LIMIT 1;
ERROR: SUBSTR() function is not supported (Hint: use SUBSTRING instead)
code: 8001
今度はエラーになりました。SKILL.md に記載されていたエラーメッセージと完全に一致しています。スキルの記述が正しいことと、検証するなら実際の列に対して行う必要があることの両方が確認できました。
代替として提示されている SUBSTRING も試します。
SELECT SUBSTRING(status,1,3) AS s FROM sys_query_history LIMIT 1;
s
suc
同じ列に対して正常に動作しました。
比較セマンティクスを確認する
redshift-sql-syntax.md には、末尾の空白の扱いについて「Two bare literals are NOT equal」という記述があります。
SELECT ('abc ' = 'abc') AS literal_eq;
literal_eq
False
記述どおり false になりました。列との比較では末尾の空白が無視される一方、リテラル同士では無視されないという挙動の違いは、意図しない結果を生みやすいポイントです。
検証結果のまとめ
今回確認した内容を整理します。
| 検証内容 | スキルの記述 | 実測結果 | 一致 |
|---|---|---|---|
string_agg |
非対応 | function ... does not exist |
一致 |
LISTAGG |
代替として使用 | 成功 | 一致 |
stl_query(Serverless) |
Serverless には存在しない | permission denied |
概ね一致(エラー内容は相違) |
sys_query_history |
どの構成でも動作 | 成功 | 一致 |
QUALIFY |
独自拡張として推奨 | 成功 | 一致 |
SUBSTR(システムビュー列) |
リーダーノード限定でエラー | エラーメッセージまで一致 | 一致 |
SUBSTRING |
代替として使用 | 成功 | 一致 |
| リテラルの末尾空白比較 | 等しくならない | false |
一致 |
なお、text 型が VARCHAR(256) になる挙動や CREATE INDEX が存在しない点については、CREATE TABLE を伴うため今回の読み取り専用の検証方針では確認していません。
考察
検証を通して感じた点を整理します。
-
スキルに書かれている内容の精度が高い
特に
SUBSTRのエラーは、メッセージの文言まで実機と一致していました。LLM が生成しがちな SQL がどこで失敗するかを、実際のエラー文字列レベルで押さえた内容になっています。 -
検証の条件設定には注意が必要
SUBSTRを定数のみのサブクエリで試したときは成功してしまい、実データを持つ列に対して初めて再現しました。スキルの記述は正確でしたが、その条件を読み違えると誤った結論に至ります。 -
リージョンの制約
aws agent-toolkitコマンドは us-east-1 でのみ提供されており、AWS MCP Server のエンドポイントも執筆時点では us-east-1 と eu-central-1 の 2 つです。ただしこれは接続先の話であり、操作対象のリージョンは別に指定できます。東京リージョンの Amazon Redshift を扱う場合は、MCP Server の設定でAWS_REGIONメタデータパラメータを指定します。 -
stl_queryのエラーがpermission deniedとして返るスキルの記述は「Serverless には存在しない」となっており、対処法としては同じ結論に至りますが、エラーメッセージから原因を切り分ける場面では差が出る可能性があります。
なお、SKILL.md には Safety Guardrails として、DROP DATABASE や WHERE 句のない DELETE をブロックする、RESIZE や VACUUM は警告して確認を取る、といった 3 段階の制御も定義されています。ただしこれはスキル側の指示であり、実際に AWS API を実行するのは AWS MCP Server が引き受ける IAM 権限です。IAM ポリシー側でも権限を絞り込んでおくことをおすすめします。
今後の期待としては、text 型や DDL 系の挙動も含めた検証をしやすくするサンプル、および Serverless 固有のエラーメッセージへの追随が挙げられます。
最後に
Amazon Redshift が Agent Toolkit for AWS と統合され、Claude Code や Kiro、Cursor から Amazon Redshift の構築・クエリ・トラブルシューティング・移行が行えるようになりました。追加料金なし、インフラ変更不要で、プロビジョンドクラスターと Amazon Redshift Serverless の両方に対応しています。
単なる API 連携ではなく、「Amazon Redshift は PostgreSQL ではない」という前提のもとに LLM が陥りやすい誤りを矯正する知識が公式から提供された点が、今回のアップデートの本質だと感じました。AI エージェントに Amazon Redshift の SQL を書かせて期待どおりに動かなかった経験のある方は、まず aws-data-analytics プラグインの導入から検討してみてはいかがでしょうか。









