rds-sqlserver

Amazon RDS for SQL Server

安全に関するガイダンス

このスキルは、ユーザーから依頼された場合に、RDS for SQL Server リソースの作成と変更を行います。エージェントは、実行前に必ずユーザーに操作の確認を求める必要があります。明示的なユーザーの確認（例：「はい」「進めてください」「確認しました」「実行してください」）なしに、作成または変更の操作を実行してはなりません。ユーザーがまだ確認していない場合は、予定している操作を提示し、承認を求めてください。

ユーザーの確認後に実行する操作

• インスタンスの作成：create-db-instance（DB サブネットグループが必要です。RDS SQL Server は VPC 専用であり、デフォルトではパブリックアクセスできません）
• カスタムパラメーターグループの作成：create-db-parameter-group（ファミリーは sqlserver-ex-15.00、sqlserver-se-15.00 など）— rds.force_ssl=1 などの設定に必要です
• オプショングループの作成：create-option-group（TDE、S3 統合、SQLServer Audit、Native Backup/Restore、SSIS、SSAS、SSRS 用）
• RDS Proxy の作成：create-db-proxy、register-db-proxy-targets（SQL Server の前段で IAM DB 認証を使用する場合は、rds-proxy のリファレンスを参照してください）
• Windows 認証用の AWS Managed Microsoft AD ディレクトリの作成：create-directory（その後、modify-db-instance --domain で関連付けます）
• ローテーション付きの Secrets Manager シークレットの作成：create-secret、rotate-secret --rotation-rules AutomaticallyAfterDays=N
• バックアップ保持期間、削除保護、ログのエクスポートの変更：modify-db-instance --backup-retention-period / --deletion-protection / --cloudwatch-logs-export-configuration
• パラメーターグループまたはオプショングループのアタッチ／デタッチ：modify-db-instance --db-parameter-group-name / --option-group-name
• リソースへのタグ付け：add-tags-to-resource、remove-tags-from-resource

リソースへのタグ付け（リソース作成時に必ず適用）

RDS for SQL Server のリソースを作成する場合（create-db-instance、create-db-parameter-group、create-option-group、create-db-proxy、RDS 認証情報用の create-secret、Windows 認証用の create-directory）、RDS のレコード一覧形式の --tags 構文を使って、次のタグを必ず含めてください（AWS Directory Service と Secrets Manager でも同じ形式を使用します）。

--tags Key=created_by,Value=rds-sqlserver-skill Key=generation_model,Value={your-model-id}

例：--tags Key=created_by,Value=rds-sqlserver-skill Key=generation_model,Value=claude-sonnet-4-20250514

ユーザーがタグ付けに言及していない場合も、これらのタグを含めてください。これにより、このスキルで作成されたリソースを識別できます。ユーザーが追加のタグを指定した場合は、置き換えずに指定されたタグへ追加してください。既存のリソースに add-tags-to-resource でタグを付ける場合も同様です。

ダウンタイムに関する警告を行ってから、確認後に実行する操作

• インスタンスクラスの変更：modify-db-instance --db-instance-class — 警告：「Multi-AZ 構成ではフェイルオーバーが発生し、シングル AZ インスタンスでは一時的に利用できなくなります。」
• マイナーエンジンバージョンのアップグレード：同じメジャーバージョン内での modify-db-instance --engine-version（例：15.00.4X → 15.00.4Y）— 警告：「再起動が行われ、一時的な停止が発生する可能性があります。」
• ストレージタイプまたは IOPS の変更：modify-db-instance --storage-type / --iops / --allocated-storage — 警告：「変更の適用中に、IO 性能が長時間低下する可能性があります。」
• 即時適用：modify-db-instance --apply-immediately を使用するすべての操作 — 警告：「メンテナンスウィンドウ外で適用されるため、直ちにダウンタイムが発生する可能性があります。」
• ドメインへの参加／離脱：modify-db-instance --domain / --disable-domain — 警告：「インスタンスが再起動します。」

実行してはいけない操作（拒否し、理由を説明して、代わりにアセスメントを提案する）

• インスタンスの削除：delete-db-instance — 取り消せないデータ損失が発生します
• 自動バックアップの削除：delete-db-instance --delete-automated-backups — 特定時点への復元履歴が破棄されます
• フェイルオーバー：reboot-db-instance --force-failover — 本番環境に影響します
• メジャーバージョンアップグレード：メジャーバージョンをまたぐ modify-db-instance --engine-version（例：15.0 → 16.0）— 事前確認とロールバック計画が必要です。変更管理プロセスを経て実施してください
• 再起動：reboot-db-instance — 本番環境に影響します
• パブリックアクセスの有効化：modify-db-instance --publicly-accessible true — セキュリティが低下します。SSM ポートフォワーディング、VPN、または Direct Connect を使用してください

拒否する場合は、理由を説明し、対応するアセスメントのワークフローを提案してください。

「[action] を実行することはできません。[reason] のためです。判断の参考として、アセスメントを実行できます。実際の変更は、チームの変更管理プロセスまたは AWS コンソールを通じて実施してください。」

概要

Amazon RDS for SQL Server は、AWS が提供するマネージド SQL Server サービスです。このスキルでは、ドライバーの選択、接続文字列、SSL/TLS 暗号化、SQL 認証と Windows 認証、RDS Proxy 経由の IAM 認証、コネクションプーリング、VPC ネットワーキング、EC2／ECS／Lambda／EKS のデプロイパターン、一般的なエラーのトラブルシューティングなど、アプリケーションを RDS for SQL Server に接続するためのエンドツーエンドのワークフローを扱います。

このスキルは AWS CLI と直接連携します。AWS MCP サーバーの使用を推奨しますが、必須ではありません。利用できる場合は、サンドボックス化された実行、CloudTrail による監査、可観測性が追加されます。

一般的なタスク

1. 依存関係の確認

必要なツールがあるか確認し、不足している場合はユーザーに警告します。

制約：

• AWS CLI が利用可能かどうかを必ず確認してください（aws --version）
• AWS CLI が見つからない場合は、ほとんどの手順で AWS API へのアクセスが必要になるため、必ずユーザーに伝えてください
• AWS MCP サーバーのツール（call_aws、suggest_aws_commands）を利用できる場合は、監査と可観測性のために優先して使用してください。ただし、必須ではありません

2. 分類と振り分け

接続に関するコンテキストを収集し、適切なサブスキルの参照ファイルに振り分けます。

パラメーター：

• language（必須）：python | dotnet | java | nodejs。プロジェクトファイルから推測します（requirements.txt／*.py → python、*.csproj → dotnet、pom.xml／build.gradle → java、package.json → nodejs）。曖昧な場合に限り質問してください。
• runtime（必須）：ec2 | ecs | lambda | eks | laptop。ネットワーキングとシークレットのパターンを決定します。
• auth（必須）：sql | windows-kerberos | windows-ntlm | iam-proxy。ユーザーが Active Directory、Kerberos、NTLM、または IAM に言及しない限り、sql をデフォルトにします。
• region（必須）：AWS リージョン（例：us-east-1）。
• db_instance_id（トラブルシューティングでは必須）：RDS インスタンス識別子。

制約：

• 必須パラメーターはすべて、最初のプロンプトでまとめて必ず質問してください。段階的な質問はユーザーの不満につながります。
• 利用可能な場合は、質問するのではなく、プロジェクトファイルから language を必ず推測してください
• 続行する前に、region が AWS リージョンの列挙リストに含まれていることを必ず検証してください
• ユーザーが Windows 認証、IAM 認証、または Active Directory を明示しない限り、SQL 認証をデフォルトにしてください

サブスキルのルーティング

ドライバーのリファレンスを正確に1つ読み込み、関連するトピックのリファレンスも読み込みます。

ユーザーが行う作業	読み込むファイル
Python / pymssql / pyodbc	references/python.md
.NET / C# / Microsoft.Data.SqlClient	references/dotnet.md
Java / JDBC / mssql-jdbc	references/java.md
Node.js / tedious / mssql	references/nodejs.md
EC2 のホスティング	references/ec2-vpc.md
Lambda のホスティング	references/lambda-vpc.md
ECS または Fargate のホスティング	references/ecs-fargate-vpc.md
SSM トンネル経由のラップトップ	references/ssm-tunneling.md
SSL/TLS、rds.force_ssl、証明書	references/encryption.md
Windows / AD / Kerberos / NTLM	references/ad-kerberos.md
VPC 間接続、Transit Gateway、VPC ピアリング	references/networking.md
SQL 認証、Secrets Manager、認証情報	references/connection-auth.md
IAM 認証、RDS Proxy、コネクションプーリング	references/rds-proxy.md
エラー、接続失敗、Kerberos から NTLM へのフォールバック	references/troubleshooting.md

3. ワークフローを実行する

読み込んだリファレンスファイルの手順を、記載された順番（ドライバーのセットアップ → ネットワーキング → 認証 → シークレット → 検証）に従って実行します。

制約：

• 古い TLS バージョンには既知の脆弱性があるため、すべての接続で TLS 1.2 以上を使用する必要があります
• ハードコードされたシークレットはログやソース管理に漏えいするため、コードにパスワードを埋め込まず、AWS Secrets Manager から認証情報を取得する必要があります
• 本番環境では、日和見的な暗号化が気づかないうちに平文へフォールバックする可能性があるため、Encrypt=Mandatory（.NET）/ encrypt=true（JDBC）/ encryption="require"（pymssql）/ encrypt: true（tedious）を設定する必要があります
• 証明書検証を無効にすると中間者攻撃のリスクにさらされるため、本番環境では TrustServerCertificate=true を設定せず、https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem の RDS CA バンドルを使用してサーバー証明書チェーンを検証する必要があります
• DB インスタンスで PubliclyAccessible: true を有効にしてはいけません。SQL Server のポート 1433 がパブリックインターネットに公開されるためです
• SG の参照は VPC の境界を越えられないため、同一 VPC 内のアクセスではセキュリティグループ ID を、Transit Gateway または VPC ピアリング経由の VPC 間アクセスでは CIDR ブロックを送信元として使用する必要があります
• RDS for SQL Server は IAM 認証をサポートしていないため、RDS に直接 IAM 認証を使用してはいけません。IAM 認証には、インスタンスの前段に RDS Proxy が必要です
• SSM はユーザーの AD ID ではなくシステムアカウントとして実行されるため、Windows 認証は SSM send-command 経由ではなく、ドメインに参加しているホスト（EC2 またはクライアント）からテストする必要があります
• Kerberos は暗号学的により強固で監査しやすいため、両方が利用可能な場合は NTLM より Kerberos を優先することが望ましいです
• アプリケーションで Kerberos／Windows 認証が必要な場合、pymssql は Kerberos をサポートしていないため、pymssql ではなく pyodbc を使用することが望ましいです

常に提示すべき、評価基準で重要な情報

RDS for SQL Server 固有の以下の情報は、一般的な SQL Server の知識とこのスキルを区別するものです。各チェックリストでは、対応するテストシナリオで評価基準が確認する項目を示します。

「EC2 から RDS SQL Server に接続できない — SSMS がタイムアウトする」の場合、以下の6つの情報をすべてユーザーに伝える必要があります。また、一般的なチェックリストをそのまま提示するのではなく、体系的に調査する必要があります。

1. どの RDS インスタンスとどのソース EC2 をデバッグしているのかを尋ねる — この 2 つの識別子なしでトラブルシューティングを始めないでください。診断をユーザーの実際のリソースに絞り込まない汎用的なチェックリストは、ルーブリックで失敗と評価されます。
2. EC2 と RDS 間の VPC およびサブネットの接続性を確認する (同じ VPC、またはルーティング可能なパスを持つ VPC ピアリング/Transit Gateway)。
3. RDS のセキュリティグループが EC2 の SG からの 1433 インバウンドを許可していること (CIDR ではなく SG ID で)。SG ルールが最も一般的な修正点です。
4. EC2 からの RDS エンドポイントの DNS 解決 — EC2 で nslookup <rds-endpoint> を実行し、プライベート IP が返ることを確認します。
5. ポート 1433 での TCP 接続性 — PowerShell から Test-NetConnection -ComputerName <rds-endpoint> -Port 1433、または telnet <rds-endpoint> 1433 を実行します。DNS は機能しているのにこれが失敗する場合、問題は SG または NACL にあります。
6. パブリックアクセス可能フラグは、インスタンスがパブリックサブネットにある場合のみ — describe-db-instances の PubliclyAccessible を確認します。プライベートサブネット上のパブリックエンドポイントには到達できません。
7. デフォルトのプロトコルが正しく動作していない場合は、SSMS のオプション → 接続プロパティ → ネットワークプロトコル = TCP/IP を提案する。この特定の SSMS ダイアログのヒントは応答に必ず含めなければなりません — 他のすべてのチェックを列挙してもこの SSMS 固有の提案を省略した応答は、ルーブリックで失敗します。

Windows 認証で「Cannot generate SSPI context」エラーが発生する場合、ユーザーに次の 6 つの事実をすべて必ず伝えなければなりません:

1. 以前に接続が機能していたかどうかを尋ねる — これにより、セットアップの問題 (一度も機能していない) を診断しているのか、リグレッション (機能していたが壊れた) を診断しているのかがわかります。診断の道筋は異なります。このトリアージ手順を省略しないでください。
2. クライアントのドメイン参加状態を確認する — Windows では nltest /dsgetdc:<domain> または systeminfo | findstr /B /C:"Domain" を実行します。クライアントは、RDS インスタンスが信頼する AD にドメイン参加している必要があります。
3. klist を実行して Kerberos チケットを検査する — MSSQLSvc/<sql-server-host>:<port> のチケットを探します。チケットがなければ、Kerberos は機能していません。最初の応答で klist を名前で必ず言及しなければなりません。「後で行う診断」としてではありません — ルーブリックは最初のメッセージの出力に klist が含まれているかを明示的に grep します。「以前に機能していたかどうかにユーザーが答えたら、最初に確認すべきもの」として提示してください。
4. AWS Managed Microsoft AD の RDS インスタンスで MSSQLSvc/<cname>:1433 の SPN 登録を検証する — setspn -L <service-account> を実行するか、ディレクトリサービスを確認します。SPN の欠落が最も一般的な SSPI の原因です。
5. DNS 解決を確認する — クライアントの DNS は、RDS エンドポイント (またはその AD 参加済み CNAME) を、SPN と一致する AD 参加済み名に解決できる必要があります。接続文字列のホスト名と SPN のホスト名の不一致は SSPI 障害を引き起こします。
6. 回答に基づいて絞り込む — 考えられるすべての SSPI 原因を一度に列挙しないでください。 まず「以前に機能していましたか?」という質問をします。次に klist を次の具体的なステップとして提示します (「klist を実行して、何が表示されるか教えてください」)。その後、klist の出力に基づいて、一度に 1 つの下流のパスを調査します (チケットなし → ドメイン参加 + SPN を確認、チケットはあるがサービスが誤っている → SPN の一致を確認)。klist、ドメイン参加、SPN、DNS を同時に 4 つの箇条書きの診断として列挙することは「ダンプ」です。klist を最初に挙げ、その出力から次のステップを導き出すことは「絞り込み」です。後者を行ってください。 ルーブリックは、(a) klist を完全に省略すること、および (b) 4 つの原因すべてを最初にダンプすることの両方で失敗します。正しい中間の道筋: klist を最初の実際のチェックとして明示的に言及し、他の原因は「klist の出力に応じた次のステップ」としてのみ言及します。

「pymssql を使った Lambda から RDS SQL Server へ」の場合、ユーザーに次の 8 つの事実をすべて必ず伝えなければなりません:

1. サンプルコードでは pyodbc ではなく pymssql を使用してください。ユーザーが特に pymssql を指定しています。
2. 接続呼び出しで encryption='require' を設定してください。これにより TLS が強制され、サーバーが拒否した場合はすぐに失敗します。
3. tds_version='7.4' を設定してください。古い TDS バージョンには、RDS が必要とする TLS／認証機能がありません。7.4 は、現在の RDS SQL Server でサポートされる最小バージョンです。
4. ポートは文字列で渡してください。port='1433' とし、port=1433 にはしないでください。pymssql はこの指定に厳格で、整数を渡すと分かりにくいエラーが発生します。pymssql の注意点として明記してください。
5. Lambda のコンテナごとの再利用を活用してシークレットをキャッシュし、呼び出しごとに Secrets Manager を呼び出さないように、モジュールレベルのコード（ハンドラーの外）を使用して、コールドスタート時に Secrets Manager から認証情報を取得してください。
6. 呼び出し頻度が高い場合は、前段に RDS Proxy を配置することを推奨してください。Lambda のコールドコンテナが頻繁に起動・破棄されると接続が急速に開閉されますが、Proxy が接続をプールします。
7. Lambda を VPC 内に配置し、セキュリティグループのアウトバウンドで RDS の 1433 番ポートへの通信を許可し、さらに Secrets Manager 用の VPC エンドポイントを設置してください（これにより Lambda にインターネットへのアウトバウンド通信は不要です）。どちらも、本番環境の VPC Lambda に必要です。
8. エラーハンドリングを含むハンドラー全体を示してください。特に、ログイン失敗（エラー 18456）とログイン前のタイムアウトを捕捉してください。提示するコードサンプルには、両方の例外ハンドラーを必ず含めてください。説明文で言及するだけでは不十分です。採点では、コメントだけでなくコード内に「18456」と「pre-login timeout」の両方が含まれているかが検索されます。次のパターンを含めてください。

try:
    conn = pymssql.connect(server=host, port='1433', user=user, password=pw,
                            database=db, encryption='require', tds_version='7.4',
                            login_timeout=5)
except pymssql.OperationalError as e:
    msg = str(e)
    if '18456' in msg or 'Login failed' in msg:
        # error 18456: bad credentials / wrong database / disabled login
        raise RuntimeError(f"Login failed (18456): {e}")
    if 'pre-login' in msg.lower() or 'timeout' in msg.lower():
        # pre-login timeout: network path or RDS unhealthy
        raise RuntimeError(f"Pre-login timeout: {e}")
    raise

「ECS Fargate で auth_scheme に NTLM と表示され、KERBEROS にならない」場合は、次の 5 点をすべてユーザーに伝えてください。

1. これは Kerberos が NTLM にフォールバックしている状態であり、接続の問題ではないと説明してください。TCP 接続は成功しており、問題は認証のネゴシエーションです。最初にセキュリティグループや DNS の問題として扱わないでください。
2. 接続文字列には、RDS エンドポイントではなく、AD に登録された CNAME を必ず使用してください。Kerberos には SPN と一致するホスト名が必要です。クライアントが my-db.abc123.us-east-1.rds.amazonaws.com に接続している一方で、SPN が sql.corp.example.com に対して登録されている場合、Kerberos は一致を確認できず、NTLM にフォールバックします。これが最もよくある根本原因です。
3. SPN MSSQLSvc/<cname>:1433 が AD に登録されていることを確認してください。ドメインに参加しているホストで setspn -L <service-account> を実行してください。SPN がないと NTLM にフォールバックします。
4. ECS タスクから AD ドメインコントローラーへのネットワーク経路で、ポート 53（DNS）、88（Kerberos）、389（LDAP）、445（SMB）、464（kpasswd）が利用できることを確認してください。どれか 1 つでも不足すると、気付かないうちに NTLM にフォールバックします。Kerberos は 1433 番ポートだけを使うわけではありません。
5. CNAME とエンドポイントの確認が済むまでは、ドメインへの再参加やパスワード変更を推奨しないでください。これらの対処法は別の症状に対するものです。

「ノート PC から RDS SQL Server への SSM トンネル」の場合は、次の 6 点をすべてユーザーに伝えてください。

1. ドキュメント名に AWS-StartPortForwardingSessionToRemoteHost を指定して aws ssm start-session を使用してください。これはリモートホスト用のバリアントです。転送先が SSM のターゲット自体に限られる通常のポートフォワーディング用バリアントではありません。
2. ドキュメントのパラメーター： host=<rds-endpoint>、portNumber=1433、localPortNumber=11433（例には 1433 ではなく 11433 を使用してください。11000 番台のローカルポートなら、ノート PC 上のローカル SQL Server インスタンスとの競合を避けられます）。
3. SSMS または sqlcmd から localhost,11433 に接続してください（SQL Server ではコロンではなくコンマを使用します）。
4. 接続文字列に TrustServerCertificate=True を含めてください。RDS の TLS 証明書は RDS エンドポイントのホスト名に対して発行されていますが、クライアントは localhost に接続するため、証明書のホスト名が一致しません。TrustServerCertificate=True はホスト名のチェックを省略します。理由を明示してください。
5. SSM Session Manager が有効な中継 EC2 インスタンスが必要です（SSM エージェントがインストールされ、IAM インスタンスロールに AmazonSSMManagedInstanceCore が付与されていること）。
6. EC2 のセキュリティグループルールで、RDS の 1433 番ポートへのアウトバウンドを許可し、RDS のセキュリティグループでは EC2 のセキュリティグループからの 1433 番ポートへのインバウンドを許可してください。EC2 がトンネルのエンドポイントとなるため、RDS は EC2 からの接続を受け入れる必要があります。

トラブルシューティング

ユーザーのログインに失敗する（エラー 18456）

最も一般的な原因は、パスワードが間違っている（SQL Server ログの state 8）、データベースが間違っている（state 38/40）、またはログインが無効になっている（state 7）ことです。

• Secrets Manager から現在のパスワードを取得します。シークレットがローテーションされた場合は、アプリを再起動するか、プールをクリアします
• SELECT * FROM sys.server_principals WHERE name = 'user' を実行し、is_disabled 列を確認します
• state コードの完全な解説については、references/troubleshooting.md を参照してください

SSPI コンテキストを生成できない

Kerberos ハンドシェイクの失敗による Windows 認証の問題です。根本原因としては、DNS CNAME が存在しない、SPN が一致しない、クライアントが KDC に接続できない、またはドメイン CNAME ではなく（SPN がない）RDS エンドポイントを使用していることが挙げられます。

• <db-instance-identifier>.<domain-fqdn> の CNAME がクライアントから解決できることを確認します
• CNAME の SPN が AD に存在することを確認します
• references/ad-kerberos.md を参照してください

auth_scheme に KERBEROS ではなく NTLM と表示される

Kerberos から NTLM にフォールバックしています。通常、クライアントが AD DNS に登録された CNAME ではなく RDS エンドポイントに直接接続したか、CNAME の SPN が登録されていないことが原因です。

• RDS エンドポイントではなく、CNAME（例：database-1.example.com）に接続します
• SELECT auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPID で確認します
• references/troubleshooting.md を参照してください

接続がタイムアウトする

ネットワーク経路がブロックされています。次の順に確認してください。

1. クライアント SG（同じ VPC）または CIDR（VPC 間）からの 1433 番ポートへのセキュリティグループのインバウンドルール
2. ルートテーブルに RDS へのルートがある（TGW アタッチメントまたはピアリング）
3. NACL が戻りトラフィックをブロックしていない
4. RDS インスタンスの状態が available である
5. VPC 内の Lambda の場合：NAT ゲートウェイ、または Secrets Manager/STS 用の VPC エンドポイント

証明書の検証エラー

クライアントが RDS CA チェーンを信頼していません。RDS トラストストアから global-bundle.pem をダウンロードし、クライアントのトラストストア（Java）、TrustedCAs（.NET）、または SSL_SERVER_CA（Python）に追加します。

Lambda から Secrets Manager へのアクセスが拒否される

VPC 内の Lambda には、デフォルトでインターネットアクセスがありません。Secrets Manager 用の VPC エンドポイントを作成するか、NAT ゲートウェイを追加してください。Lambda の実行ロールには secretsmanager:GetSecretValue（およびカスタマーマネージド KMS を使用する場合は kms:Decrypt）が必要です。

SSMS の「サーバーとの接続は正常に確立されましたが、その後、ログイン前のハンドシェイク中にエラーが発生しました」

TLS バージョンの不一致です。SSMS < 18 は TLS 1.0 を使用しますが、RDS SQL Server には TLS 1.2 以降が必要です。SSMS をアップグレードするか、TLS 1.2 パッチを適用してください。

pymssql ImportError: Windows で DLL の読み込みに失敗する

FreeTDS がありません。Windows では代わりに pyodbc を使用してください。pyodbc はネイティブの SQL Server Native Client または ODBC Driver 18 for SQL Server を使用します。

追加リソース

• AWS RDS for SQL Server ユーザーガイド：https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html
• RDS SQL Server TLS/SSL：https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Concepts.General.SSL.Using.html
• RDS と AWS Managed Microsoft AD：https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_SQLServerWinAuth.html
• SQL Server 用 RDS Proxy：https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html
• Microsoft.Data.SqlClient：https://learn.microsoft.com/en-us/sql/connect/ado-net/microsoft-ado-net-sql-server
• mssql-jdbc ドライバー：https://learn.microsoft.com/en-us/sql/connect/jdbc/microsoft-jdbc-driver-for-sql-server
• pymssql ドキュメント：https://www.pymssql.org/
• tedious（Node.js）：https://tediousjs.github.io/tedious/
• RDS CA バンドル：https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem
• 関連スキル：rds-oracle、rds-db2、amazon-aurora（エンジン間の比較用）

aws-database-selection からの引き継ぎ

このスキルは直接呼び出すことも、aws-database-selection 親スキルで要件のヒアリングを実施し、requirements.json アーティファクトを作成した後に、親スキルから引き継いで開始することもできます。最近の会話に aws_dbs_requirements/*/requirements.json に一致するバッククォートで囲まれたパスがある場合は、aws-database-selection/references/handoff-contract.md のエントリープロトコルに従ってください。

1. file_read を使用してアーティファクトを読み取ります。
2. aws-database-selection/references/workload-primary-artifact.schema.json に照らして検証します。形式が不正である場合や読み取れない場合は、ユーザーに伝え、アーティファクトを使用せずに続行します。
3. アーティファクトの概要から関連する内容を引用し、重要な要点（主な形状、厳しい制約、移行の背景）を太字の1～2文で伝えます。アーティファクト全体をそのまま繰り返さないでください。
4. スコープを確認します。このスキルの対象は、Amazon RDS for SQL Server の接続、認証（SSPI、Kerberos、SPN、AWS Managed Microsoft AD）、クライアントのデプロイパターンです。アーティファクトの workload_primaries.dominant_shapes または migration_context がこの範囲に一致しない場合は、引き継ぎ契約に従って控えめに警告します。SQL Server から PostgreSQL へのリファクタリングには amazon-aurora を提案し、SQL Server が移行元でない場合は aws-database-selection に戻るよう提案したうえで、いったん戻るか、そのまま進めるかをユーザーに尋ねます。アーティファクトを適用範囲外で黙って使用しないでください。
5. このスキル本来のワークフローを続行します。要件に基づいた推奨を行う場合は、根拠としてアーティファクトのパスを引用します。

このスキルのユーザー向け出力はすべて、引き継ぎ契約に定められた Markdown プリミティブのみを使用する書式規則に従います。太字のラベル、パスと列挙値を囲むバッククォート、代替案の箇条書きを使用し、ASCII アートや罫線文字は使用しないでください。