Aurora DSQL MCP スキルがリリース。AI エージェントの DSQL 対応力の向上を確かめてみた

Aurora DSQL MCP スキルがリリース。AI エージェントの DSQL 対応力の向上を確かめてみた

2026年2月リリースの Aurora DSQL MCP スキルを最速検証。Kiro CLI と Sonnet 4.6 を組み合わせることで、PostgreSQL 互換に起因するDSQLの制約を AI が自律的に処理できるかを確認しました。Haiku との比較を通じ、新しい Sonnet 4.6の高い実力も確認できました。
2026.02.19

2026年2月18日、Amazon Aurora DSQL と Kiro powers / AI エージェントスキルの統合が発表されました。

https://aws.amazon.com/jp/about-aws/whats-new/2026/02/amazon-aurora-dsql-integrates-with-kiro-powers-and-agent-skills/

このMCPスキルにより、DSQL の開発ベストプラクティスを AI エージェントに直接提供し、スキーマ設計やデータベース操作を支援できるようになります。
Kiro IDE では Kiro power として、Kiro CLI や Claude Code、Cursor 等では Skills CLI 経由で Aurora DSQL スキルとしてインストールできます。

この記事では、Kiro CLI を使って DSQL スキルの効果を検証した結果を紹介します。

AI エージェント × DSQL の「あるある」問題

DSQL は PostgreSQL 互換ですが、PostgreSQL 互換性に関する考慮事項に記載されている通り、分散アーキテクチャに由来する重要な制約が存在します。

  • CREATE INDEXASYNC が必須
  • 1トランザクションに DDL は1文のみ
  • FOREIGN KEY 制約は非サポート
  • ALTER TABLE ... ADD COLUMN ... DEFAULT は非サポート
  • トランザクションあたり 3,000 行が上限
  • ALTER COLUMN TYPE は非サポート(テーブル再作成が必要)

AI エージェントが PostgreSQL の一般知識ベースでコードを生成すると、どうしてもこれらの制約違反が頻発してしまいます。「動かない → 調べる → 修正 → また動かない」という負のループに陥りがちです。

DSQL MCP スキルとは

Aurora DSQL MCP スキルは、AWS Labs が GitHub(awslabs/mcp)で公開している AI エージェント向けのナレッジパッケージです。DDL ルール、テーブル再作成パターン、マルチテナント分離パターン、MCP サーバーのツール仕様など、DSQL 固有の知識をエージェントに提供します。

3層構成: スキル + MCP サーバー + Steering

DSQL 対応を確実にするために、以下の3層構成を推奨します。

役割 仕組み
スキル DSQL の知識(制約、ベストプラクティス) .agents/skills/dsql/ にインストール
MCP サーバー ツール実行(クエリ実行、スキーマ確認) Docker / uvx
Steering プロジェクト固有情報 + スキル強制参照 .kiro/steering/(自動読み込み)

以降、各層のセットアップ方法と検証結果を紹介します。

セットアップ

実行環境

今回の検証は以下の環境で実施しました。

項目
OS Amazon Linux 2023(aarch64)
EC2 インスタンス IAM ロール(インスタンスプロファイル)で認証
IAM 権限 dsql:*(DSQL 操作)、dsql:DbConnectAdmin(DB 接続)
Docker 25.0.14
Python 3.12.12(Docker イメージ内で使用)
Kiro CLI 1.25.0
Node.js なし(スキルインストールは Docker 経由で実施)

1. スキルのインストール

# Node.js がある場合
cd /path/to/your/project
npx skills add https://github.com/awslabs/mcp --skill dsql --yes

# Node.js がない場合(Docker で代替)
cd /path/to/your/project
docker run --rm -v $(pwd):/work -w /work node:22 \
  npx -y skills add https://github.com/awslabs/mcp --skill dsql --yes

39 エージェント分のディレクトリが自動作成されます。実体は .agents/skills/dsql/ に1つだけで、Kiro CLI(.kiro/skills/dsql)、Claude Code(.claude/skills/dsql)、Cursor(.cursor/skills/dsql)等はすべてシンボリックリンクです。

# インストール確認
ls .agents/skills/dsql/SKILL.md          # スキル本体
ls .agents/skills/dsql/references/       # development-guide.md, ddl-migrations.md 等
ls .agents/skills/dsql/mcp/              # MCP サーバー設定サンプル、ツール仕様
ls .kiro/skills/dsql                     # Kiro CLI 用シンボリックリンク

2. MCP サーバーの Docker イメージ作成

MCP サーバーは Python(uvx)ベースです。ホストに Python/uvx を入れたくない場合、Docker イメージにパッケージをキャッシュして使えます。

# docker/Dockerfile
FROM python:3.12-slim
RUN pip install uv && uvx awslabs.aurora-dsql-mcp-server@latest --help > /dev/null 2>&1
ENTRYPOINT ["uvx", "awslabs.aurora-dsql-mcp-server@latest"]
cd docker/
docker build -t dsql-mcp .

# 起動確認(キャッシュ済みなので約1.8秒)
time docker run --rm dsql-mcp --help

キャッシュなしだと毎回 pip install uv + 依存パッケージダウンロードが走り約12秒かかりますが、イメージに焼き込むことで約1.8秒に短縮可能でした。

なお、この構成ではエージェントがツールを呼び出すたびに Docker コンテナが起動・終了します。呼び出しごとに約2秒のオーバーヘッドが加わりますが、検証環境をクリーンに保てるメリットを優先しました。

3. MCP サーバー設定(.kiro/settings/mcp.json

Docker イメージを使う場合の設定例です。認証方法に応じて2パターンあります。

ローカル開発では ~/.aws をマウントする方法が最も手軽です。普段 aws sso login~/.aws/credentials を使っている環境ならそのまま動きます:

{
  "mcpServers": {
    "aurora-dsql": {
      "command": "docker",
      "args": [
        "run", "--rm", "-i",
        "-v", "${HOME}/.aws:/root/.aws",
        "-e", "AWS_PROFILE=default",
        "-e", "AWS_REGION=us-west-2",
        "-e", "FASTMCP_LOG_LEVEL=ERROR",
        "dsql-mcp",
        "--cluster_endpoint", "<your-cluster>.dsql.<region>.on.aws",
        "--region", "<region>",
        "--database_user", "admin",
        "--allow-writes"
      ]
    }
  }
}

EC2 インスタンスプロファイル等で環境変数に認証情報をセット済みの場合は、-e で引き継ぎます:

{
  "mcpServers": {
    "aurora-dsql": {
      "command": "docker",
      "args": [
        "run", "--rm", "-i",
        "-e", "AWS_ACCESS_KEY_ID",
        "-e", "AWS_SECRET_ACCESS_KEY",
        "-e", "AWS_SESSION_TOKEN",
        "-e", "AWS_DEFAULT_REGION=us-west-2",
        "-e", "FASTMCP_LOG_LEVEL=ERROR",
        "dsql-mcp",
        "--cluster_endpoint", "<your-cluster>.dsql.<region>.on.aws",
        "--region", "<region>",
        "--database_user", "admin",
        "--allow-writes"
      ]
    }
  }
}

なお、-e AWS_ACCESS_KEY_ID(値なし)は「ホストの環境変数をそのままコンテナに引き継ぐ」という Docker の記法です。Kiro CLI 起動前に export しておく必要があります。

いずれのパターンでも、DB 接続不要なドキュメント検索専用モードを追加できます:

{
  "mcpServers": {
    "aurora-dsql-docs-only": {
      "command": "docker",
      "args": ["run", "--rm", "-i", "-e", "FASTMCP_LOG_LEVEL=ERROR", "dsql-mcp"]
    }
  }
}

ホストに uvx がある場合は commanduvxargs["awslabs.aurora-dsql-mcp-server@latest", "--cluster_endpoint", ...] に変更すれば Docker なしでも動きます。

4. Steering の設定(最重要)

スキルをインストールしただけでは、エージェントはその存在を知りません。 ここで「スキルを読め」と指示する必要があります。

Kiro CLI は .kiro/steering/ 配下の Markdown ファイルを自動的にコンテキストに含めます(Steering 参照)。ここにエンドポイントとスキル参照の指示を書いておくことで、毎回確実にスキルが読み込まれます。ファイル名は自由ですが、目的がわかる名前(例: dsql-rules.md)にしておくと管理しやすいです。

<!-- .kiro/steering/dsql-rules.md -->
## Aurora DSQL 接続情報
- クラスタエンドポイント: <your-cluster>.dsql.<region>.on.aws
- リージョン: us-west-2
- 認証: IAM(dsql:DbConnectAdmin)
- DB名: postgres(DSQL固定)
- ユーザー: admin

## ⚠️ DSQL 作業時の必須手順
DSQL 関連のコード変更・スキーマ変更を行う際は、必ず以下の手順を守ること。

1. まず `.agents/skills/dsql/SKILL.md` を読み込む
2. その中の指示に従い、必要なリファレンス(DDLルール等)を確認する
3. 決して PostgreSQL の一般知識だけで推測で操作しないこと

最後の「必須手順」が重要です。これがないと、エージェントは「PostgreSQL だね、任せて!」と自信満々に制約違反の SQL を発行します(後述の検証で実証済み)。

検証: スキルの有無でどれだけ差が出たか

テスト用の DSQL クラスタ(シングルリージョン、us-west-2)を作成し、Docker 上の MCP サーバー経由で操作を実行しました。同じタスクを「スキルなし」「スキルあり」で比較しています。

テスト用クラスタの作成

aws dsql create-cluster --deletion-protection-enabled --region us-west-2
# → クラスタ識別子とエンドポイントが返る(即座に ACTIVE)

Docker 経由での MCP サーバー手動実行

Kiro CLI を使う場合は mcp.json の設定で自動的に Docker が起動されますが、動作確認やデバッグ時に手動で MCP サーバーを叩きたい場合は、以下の手順で JSON-RPC メッセージを直接送信できます。

認証情報の取得

# EC2 インスタンスプロファイル(IAM ロール)の場合
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
CREDS=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/$(
    curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
    http://169.254.169.254/latest/meta-data/iam/security-credentials/))
export AWS_ACCESS_KEY_ID=$(echo $CREDS | python3 -c "import sys,json; print(json.load(sys.stdin)['AccessKeyId'])")
export AWS_SECRET_ACCESS_KEY=$(echo $CREDS | python3 -c "import sys,json; print(json.load(sys.stdin)['SecretAccessKey'])")
export AWS_SESSION_TOKEN=$(echo $CREDS | python3 -c "import sys,json; print(json.load(sys.stdin)['Token'])")
# ローカル環境(~/.aws/credentials や aws sso)の場合
eval $(aws sts assume-role \
  --role-arn arn:aws:iam::<account-id>:role/<role-name> \
  --role-session-name dsql-mcp \
  --query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken]' \
  --output text | awk '{printf "export AWS_ACCESS_KEY_ID=%s\nexport AWS_SECRET_ACCESS_KEY=%s\nexport AWS_SESSION_TOKEN=%s\n",$1,$2,$3}')

# または、ホストの認証情報をそのままマウントする方法
# docker run --rm -i -v ~/.aws:/root/.aws -e AWS_PROFILE=default ...

MCP サーバーへの JSON-RPC 送信

(
echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}'
sleep 2
echo '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"transact","arguments":{"sql_list":["CREATE TABLE example (id VARCHAR(255) PRIMARY KEY, name TEXT)"]}}}'
sleep 3
) | timeout 30 docker run --rm -i \
  -e AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID \
  -e AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY \
  -e AWS_SESSION_TOKEN=$AWS_SESSION_TOKEN \
  -e AWS_DEFAULT_REGION=us-west-2 \
  -e FASTMCP_LOG_LEVEL=ERROR \
  dsql-mcp \
  --cluster_endpoint <your-cluster>.dsql.us-west-2.on.aws \
  --region us-west-2 \
  --database_user admin \
  --allow-writes

ポイント:

  • MCP サーバーは stdio(標準入出力)で JSON-RPC 通信する
  • 各メッセージ間に sleep が必要(前のリクエストの処理完了を待つ)
  • transact のパラメータ名は sql_listsql_statements ではない)

基本操作: テーブル作成 → インデックス → INSERT → SELECT

スキルなし Haiku(claude-haiku-4.5): 30回リトライ

スキルを読ませずにタスクを依頼した結果、以下の失敗が連鎖しました。

試行 問題
1回目 JSON-RPC の method 名が間違い("method": "execute"
2-3回目 ツール名が間違い("name": "execute_sql"
4回目 パラメータ名が間違い("statements" → 正しくは sql_list
5-7回目 CREATE INDEXASYNC がない → DSQL がエラー
8回目 エラーから学んで CREATE INDEX ASYNC に修正
9-30回目 結果取得のパースに苦戦、同じ操作を繰り返す

最終的に成功はしましたが、約6分・30回のリトライが必要でした。30回のリトライは単に時間がかかるだけでなく、過去のエラーログを含んだ長いコンテキストを毎回送信し続けるため、「安いモデルを使っているつもりが、リトライで Sonnet 一発成功より高くついている」という状態になりかねません。

スキルあり Haiku: リトライなしで成功

.agents/skills/dsql/SKILL.md を読ませてから同じタスクを依頼した結果:

  • sql_list パラメータ名: 1回目から正解
  • CREATE INDEX ASYNC: 1回目から正解
  • DDL 分割(CREATE TABLE と CREATE INDEX を別トランザクション): 1回目から正解

スキルあり Sonnet 4.6: 0回リトライ、完璧

Sonnet 4.6 にスキルを読ませた場合、各操作を個別の docker run で実行し、リトライなしで全操作が成功しました。

パターン リトライ回数 sql_list 到達 ASYNC 到達 DDL 分割
スキルなし Haiku 30回 4回目 8回目 不安定
スキルあり Haiku 0回 1回目 1回目
スキルあり Sonnet 0回 1回目 1回目 ✅ 完璧

応用シナリオ: DSQL 制約のハンドリング

基本操作に加えて、DSQL 固有の制約に引っかかりやすい7つのシナリオをスキルあり Haiku で検証しました。

シナリオ 内容 知識面の結果
2-1 3,001件 INSERT(3,000行上限) ⚠️ 分割したが 3,000+1(推奨は500-1,000バッチ)
2-2 複数 DDL 同時実行 ✅ 6回の transact に正しく分割
2-3 ALTER TABLE DEFAULT(禁止操作) ✅ DEFAULT なし + UPDATE 別トランザクション
2-4 テーブル再作成マイグレーション ⚠️ 4/5ルール(INDEX 再作成を忘れた)
2-5 互換性のない型変更 ⚠️ 中止せず変換ロジックを考案して続行
2-6 マルチテナントスキーマ ✅ 全項目パーフェクト
2-7 FOREIGN KEY 非サポート ✅ FK なし + アプリ層での参照整合性を提案

7シナリオ中4つが完璧、3つが部分的な成功でした。特にシナリオ 2-4(マイグレーション)と 2-5(互換性中止)で差が出ました。

Haiku が落としたシナリオを Sonnet 4.6 で再検証

テーブル再作成マイグレーション(5ルール遵守)

スキルの ddl-migrations.md には、テーブル再作成パターンで守るべき5つのルールが定義されています。3,001件のデータが入ったテーブルの seq カラムの型変更を依頼しました。

# ルール Haiku Sonnet
1 3,000行超はバッチ分割 ✅ 4バッチ×1,000件 ✅ 4バッチ×1,000件
2 500〜1,000件バッチを優先 ✅ 1,000件 ✅ 1,000件
3 型変更前にデータ互換性を検証 ⚠️ COUNT/MIN/MAX のみ ✅ INTEGER範囲チェック(範囲外0件を確認)
4 新テーブル検証前に元テーブルを DROP しない ✅ 件数一致確認後に DROP ✅ + CRITICAL CHECKPOINT で最終確認
5 テーブルスワップ後に ASYNC でインデックス再作成 ❌ 忘れた CREATE INDEX ASYNC で再作成

Sonnet は5ルール全遵守でした。Haiku は計画段階では全ルールを認識していましたが、実行段階でインデックス再作成を忘れました。

互換性のない型変更(中止判断)

'batch-0001' 等の文字列が入った VARCHAR カラムを INTEGER に変更するよう依頼しました。

Haiku の判断:
「全て非数値」と検出しましたが、中止せず SUBSTRING(id FROM 7) で数値部分を抽出する変換ロジックを提案し、移行を続行しました。ユーザーが no と答えて止めるまで進んでいました。

Sonnet の判断:
「3,001件中3,001件変換不可(100%)」と定量的に検出し、ddl-migrations.md のルール MUST abort if invalid_count > 0 を引用して即座に中止しました。代替案として「変換ロジックを指定する」「要件を見直す」の2つを提示しました。

マイグレーション中止

落とし穴: スキルを「入れただけ」では不十分

セットアップの「4. Steering の設定」で述べた通り、スキルをインストールしただけではエージェントはその存在を知りません。検証でも確認しています。

状態 結果
スキルなし パラメータ名を推測 → 間違える → リトライの嵐
スキルあり、読ませていない 同上(インストールしただけでは効果なし)
スキルあり、Steering で誘導 正確なパラメータ名・制約を参照 → 一発で成功

Steering を使わない場合でも、プロンプトに一言添えるだけで回避できます:

.agents/skills/dsql/SKILL.md を読んで、必要な参照ドキュメントをロードしてから作業して

まとめ

今回検証した DSQL MCP スキルにより、エージェントが DSQL 固有の制約を事前に把握した上でコードを生成できるようになるため、前述の「あるある」問題を大幅に軽減できます。

また、2月18日に Kiro でも利用可能となった Sonnet 4.6 は、スキルのルールを正確に引用して中止判断を行い、マイグレーションの5ルールを全て遵守するなど、その性能の高さを改めて認識できました。スキルあり Sonnet 4.6 の組み合わせが最も実用的であることが確認できたため、DSQL をデータストアとして採用するワークロード開発では、この DSQL MCP スキルの導入を強くおすすめします。

参考リンク

この記事をシェアする

FacebookHatena blogX

関連記事