migrating-to-amazon-redshift

Amazon Redshift への移行

このスキルについて

このスキルは、実行フレームワークではなく、AI 向けのガイダンスです。Markdown のナレッジ（ルール、マッピング、パターン、ベストプラクティス）のみで構成され、実行可能なコードは含まれていません。変換、検出・移行・検証ランナー、依存関係、インフラストラクチャを含むすべての実行処理は、このナレッジをもとに、AI であるあなたが実行時にお客様の環境に合わせて生成します。

原則：提供するコードではなくナレッジを重視することで、乖離を減らし、お客様が実行したり依存したりするものをなくし、初回から確実な結果を得ることができます。 pyproject、tools パッケージ、オーケストレーターエンジン、提供済みスクリプトを探さないでください。設計上、それらはありません。実行処理はあなたが生成します。

実行環境： このスキルは、AWS MCP サーバーの有無にかかわらず動作します。手順では AWS CLI の構文を使用します。サンドボックスでの実行と監査ログ記録のため、AWS MCP サーバーと併用することを推奨します。併用しない場合、AI は生成したスクリプトをホストのシェルで実行します（Bash、Python 3、AWS CLI、および認証情報があることを前提とします）。MCP 専用ツールが利用できると想定しないでください。

ソースの振り分け

このスキルでは、サポート対象のソースデータウェアハウスから Amazon Redshift へ移行します。まずソースシステムを特定し、そのソースのナレッジを references/<source>/ から読み込んでください。

• Teradata（Vantage） → references/teradata/ — サポート対象（以下のすべてのリファレンス）。
• その他のソース（例：Snowflake、Oracle）— サポート対象外です。準備ができ次第、それぞれ独自の references/<source>/ セットとして追加されます。

ワークフローはソースに依存しません（検出 → 変換 → 移行 → 検証 → パフォーマンス → レポート）。ソースごとに異なるのは変換に関するナレッジのみです。以下はすべて Teradata 向けのセットです。

使用する場面

• Teradata（Vantage）システムを Amazon Redshift に移行する場合。
• Teradata の DDL、SQL、ストアドプロシージャ、マクロ、または BTEQ を Redshift/RSQL に変換する場合。
• Teradata から Redshift への移行の複雑さや工数を評価する場合。

運用原則

• 検出では、ソースに対して読み取り専用（SELECT のみ）を厳守します。 本番環境の状態を変更してはいけません。DDL/DML を実行せず、ログ記録（BEGIN/REPLACE QUERY LOGGING）も決して有効にしないでください。DBQL が空の場合は unavailable と記録し、常時有効な DBC.AMPUsageV に切り替えてください。references/teradata/discovery-queries.md を参照してください。
• スキルが提供するのはナレッジです。実行処理はあなたが生成します。 references/ を読み、推論と変換に活用してください。変換には references/teradata/conversion-rules.md のルールを直接適用し、環境に合わせて検出・移行・検証ランナー（および references/teradata/discovery-queries.md に基づく読み取り専用の検出コレクター）を生成してください。
• フレームワークを想定せず、生成してください。 環境には Bash、Python 3、AWS CLI、および認証情報があるものとします。生成したスクリプトで必要となる Python ライブラリ（teradatasql、boto3 など）は、そのスクリプトまたは実行手順で必要に応じて pip install し、正確なバージョンを固定してください。Teradata TTU（BTEQ/TPT）はLinux/Windows 専用で、macOS では使用できません。検出・抽出には、TTU/Linux ホストがない限り、WRITE_NOS と teradatasql（クロスプラットフォームで、クライアント不要）を優先してください。
• 認証情報： 読み取り専用の Teradata ユーザーを使用し、IAM ユーザーより IAM ロールを優先してください。本番環境では、AWS Secrets Manager または Systems Manager Parameter Store から認証情報を参照してください。ローカル開発のみ、Git 管理対象外の .env ファイルまたはプロファイルを使用できます。決してコミットしないでください。シークレットをハードコードしたり、表示したりしないでください。ポータブルなバンドルでは、同梱の認証情報ファイルを参照し、credentials.env.example テンプレートを含めてください。実際のファイルは Git 管理対象外にします。
• 状態はファイルに保存してください。 生成した出力はすべて、ユーザーの作業ディレクトリ内にある Git 管理対象外の output/ の下に保存し、作業を再開できるよう output/state.md を最新の状態に保ってください。

ワークフロー（フェーズ）

順番に実行します。各フェーズの result/ が次のフェーズに引き継がれます（references/teradata/orchestration.md を参照）。

1. 検出 — ソースの一覧を作成します。→ references/teradata/discovery-queries.md（読み取り専用の収集 SQL ＋ AI が生成する BTEQ ドライバーテンプレート）→ output/discovery/result/inventory.json
2. 変換 — スキーマとコードを変換します。変換ルールを直接適用し、手動で書き換える必要があるものを洗い出し、リファレンスに基づいて Redshift のエラーを修正します。→ references/teradata/conversion-rules.md、references/teradata/data-type-mapping.md、 references/teradata/architecture-mapping.md、references/teradata/stored-procedure-migration.md、 references/teradata/bteq-to-rsql.md、references/teradata/common-errors.md
3. データ移行 — 抽出 → S3 → COPY の順に実行します。再開可能です。→ references/teradata/data-migration-patterns.md
4. 検証 — 件数／集計／サンプリングを行います。→ references/teradata/validation-patterns.md
5. パフォーマンス — ベースラインと Redshift を比較し、ターゲットのサイズを決定します。→ references/teradata/performance.md、references/teradata/sizing.md
6. レポート — すべてのフェーズを集計します。→ references/teradata/reporting.md

変換（AI による適用方法）

実行するコンバーターはありません。references/teradata/conversion-rules.md（型／アーキテクチャ／ストアドプロシージャ／BTEQ のリファレンスも含む）のルールを直接適用して変換します。十分に理解されている大部分には決定論的なルールを適用し、手動で書き換える必要がある構文と推奨される書き換え方法を示し、オブジェクトごとに信頼度を設定して、references/teradata/common-errors.md を使って Redshift のエラーを修正します。リファレンスドキュメントが唯一の信頼できる情報源です。conversion-rules.md には、照合に使用する入出力の代表例が含まれています。

実行モード（接続性）

• 接続あり — ホストから Teradata／Redshift に接続できます。生成されたスクリプトをその場で実行します。
• 接続なし — 接続できません。output/<phase>/ 以下に自己完結型のバンドル（スクリプト ＋ 同じディレクトリに配置する認証情報テンプレート ＋ 相対パスの result/ ＋ run-instructions.md）を生成します。オペレーターが接続可能なホストで実行し、result/ をコピーして戻します。コピーして戻した result/ が永続的な状態となります。それを（state.md とともに）読み込み、続行します。

プロジェクトワークスペースのレイアウト（移行の実行ごと）

<project-workspace>/
  migration-config.yaml          # operator-authored: endpoints, scope, strategy
  .gitignore                     # ignores output/
  output/                        # everything generated (git-ignored)
    state.md                     # progress cursor
    discovery/   …  result/inventory.json
    conversion/  …  result/{ddl,sql,procedures,rsql}/  manual_review.json
    data_migration/ … result/{extract,load,templates}/  migration_manifest.json
    validation/  …  result/validation_report.json
    performance/ …  result/{perf_baseline,perf_compare}.json
    reporting/      result/migration_report.md

セキュリティに関する考慮事項

• 同梱コードや依存関係はありません。 このスキルはテキストのみで、利用者がここから何かを実行することはありません。AI が生成するランナーでは、依存関係のバージョンを必ず正確に固定し、入力（ファイルパス、SQL、シェル引数）を検証・サニタイズし、認証情報、シークレット、PII を決して出力またはログに記録してはなりません。
• 最小権限と一時的な認証情報。 検出には読み取り専用の Teradata ユーザーを使用してください。AWS では、IAM ユーザーより IAM ロールを優先し、ユーザー名とパスワードによる認証より IAM 認証を優先してください。シークレットは AWS Secrets Manager / Parameter Store に保管し、ハードコード、出力、コミットは決してしないでください（認証情報ファイルは git の対象外であり、同梱するのは *.example のテンプレートのみです）。
• 転送中および保存時のデータ。 両方のエンジンとの接続に TLS を使用し、抽出データは暗号化された S3 バケット（SSE）にステージングしてください。バケットポリシーには最小権限を適用し、COPY … IAM_ROLE（アクセスキーではなく）を使用してロードしてください。ターゲットの Redshift クラスターでは暗号化を有効にしてください。
• 影響範囲。 検出は設計上、読み取り専用です。移行ではターゲットに書き込みます。まず使い捨ての非本番用 Redshiftで検証し、オペレーターの明示的な確認なしに、生成された書き込み経路を本番環境に決して向けないでください。
• 成果物からのシークレット漏えい防止。 生成される output/…（マニフェスト、レポート、state.md）には、migration-config.yaml でオペレーターが指定したものを超える認証情報やエンドポイントを決して埋め込んではなりません。
• COPY IAM_ROLE の強化。 ロールのポリシーの範囲は、バケット全体の s3:* ではなく、特定のステージングプレフィックスに限定してください。また、意図しない権限借用を防ぐため、信頼ポリシーには条件キー（aws:SourceAccount / aws:SourceArn、またはクロスアカウントの場合は sts:ExternalId）を含めてください。これは、Redshift の IAM ロール認可に関するベストプラクティスに準拠するものです。
• ログ記録とモニタリング。 CloudTrail（ステージングバケットの S3 データイベントと Redshift の管理イベント）、Redshift の監査ログ（S3 または CloudWatch への接続ログ／ユーザーアクティビティログ）、および移行中の COPY 失敗やステージングバケットへの異常なアクセスを検知する CloudWatch アラームを有効にしてください。

AWS MCP サーバー（推奨ランタイム）は、生成されたスクリプトのサンドボックス実行と監査ログ記録も提供します。

参考資料（専門知識）

ファイル	トピック
references/teradata/orchestration.md	フェーズのワークフローと状態モデル
references/teradata/conversion-rules.md	72 個の変換ルール（信頼できる唯一の情報源）
references/teradata/data-type-mapping.md	TD→RS 型マッピング
references/teradata/architecture-mapping.md	PI→DISTKEY、PPI→SORTKEY、Join Index→MV
references/teradata/stored-procedure-migration.md	SP → PL/pgSQL
references/teradata/bteq-to-rsql.md	BTEQ → RSQL
references/teradata/common-errors.md	Redshift の一般的なエラーと修正方法
references/teradata/discovery-queries.md	DBC システムビューのインベントリクエリ
references/teradata/data-migration-patterns.md	COPY/TPT/マイクロバッチ/チェックポイント
references/teradata/validation-patterns.md	行数／集計／サンプルの比較
references/teradata/performance.md	代表的なクエリの抽出と比較
references/teradata/sizing.md	ソースプロファイルに基づく RG ノードタイプと数
references/teradata/reporting.md	移行状況レポートの生成