authoring-mwaa-workflow

MWAA ワークフローの作成

AWS MCP サーバー（任意ですが推奨）： このスキルで AWS CLI コマンドを実行する際に AWS MCP サーバーを使用すると、サンドボックス内での実行と監査ログ記録が可能になります。ここに記載されているすべてのコマンドは通常の AWS CLI でも動作するため、このスキルを使うのに MCP サーバーや MCP 専用ツールは必要ありません。

Amazon MWAA 用の本番環境品質のワークフロー成果物を作成します。Python DAG（プロビジョニング済み）または YAML ワークフロー（Serverless）のいずれかのパスに振り分けます。

実行に関する注意 — 個別のステップでポーリングしてください： AWS の操作が終了状態または準備完了状態に達するまで待つ場合は、呼び出しごとにステータスを 1 回だけ確認し、再度確認するかどうかは独自のループで判断してください。操作の種類や所要時間にかかわらず、1 つのコマンドやスクリプト内で完了まで待機しないでください（完了するまで while と sleep を繰り返す方法は使わないでください）。

ガードレール — このスキルのファイルの場所（MCP とローカルインストール）

このスキルは 2 通りの方法で読み込まれ、同梱ファイルの参照先がそれぞれ異なります。参照ファイルを読む前に、スキルがどの方法で読み込まれたかを確認してください。

• AWS MCP の retrieve_skill ツール経由で読み込まれた場合： このスキルはローカルファイルシステムにインストールされていません。各参照ファイルは retrieve_skill の file パラメーター（例：file="references/authoring-provisioned-dag.md"）を使って取得し、返された内容を読んでください。これらのパスはディスク上に存在しないため、ローカルで file_read を使って読んではいけません。
• ローカルにインストールされている場合（例：.kiro/skills/authoring-mwaa-workflow/ または ~/.claude/skills/authoring-mwaa-workflow/）：相対パスを使って、ローカルのスキルディレクトリからファイルを読んでください。

この区別は、スキルに同梱されたファイルにのみ適用されます。ユーザーデータとセッションの成果物は、常にユーザーの作業ディレクトリから読み書きしてください。retrieve_skill を介して顧客データを取得または書き込んではいけません。

ステップ 0：パスの振り分け

次の順序で判断してください。

1. 解決可能なターゲットが指定されていますか？ ターゲットの参照は、他のキーワードにかかわらず、確定的な振り分けの指標です。
   • プロビジョニング済み環境（arn:aws:airflow:<region>:<account>:environment/<name> のような ARN、または aws mwaa get-environment で解決可能な名前）→ パス A に進みます。
   • Serverless ワークフロー ARN（arn:aws:airflow-serverless:<region>:<account>:workflow/<name>）→ パス B に進みます。
2. 両方のパスのキーワードが含まれていますか？ 解決可能なターゲットがなく、リクエストに両方のパスのキーワードが含まれている場合は、意図を確認して振り分けます。
   • PythonOperator は Serverless でサポートされているため、パス B の手掛かり（yaml、serverless、ワークフロー ARN）とともに、オペレーター単位の python に関する手掛かり（PythonOperator、python_callable、「Python function/task」）がある場合は、曖昧ではありません → パス B に進みます。
   • 変換の文脈（「Python DAG を serverless に変換して」など）→ このスキルの対象外であり、変換には対応していません。
   • 明確なプロビジョニング済み環境の手掛かり（Python DAG、provisioned）と Serverless の手掛かりがあり、ターゲットが指定されていない場合 → 確認の質問をしてください。
3. パスを示すキーワードが 1 つだけですか？ パス A の手掛かりとして扱うのは、デプロイ先を示す用語のみです。provisioned、Python DAG、または「環境用の .py」→ パス A に進みます。yaml または serverless → パス B に進みます。オペレーター単位の Python への言及は、パス A の手掛かりではありません。
4. 振り分けの手掛かりがありませんか？ 「DAG」または「Workflow」だけでは曖昧であり、パスを示すものではありません。ターゲットが MWAA プロビジョニング済み（Python DAG） か MWAA Serverless（YAML） かを尋ねてください。

---

パス

振り分けられたパスの参照に従ってください（もう一方のパスの参照は不要です）。

• パス A — Python DAG（MWAA Provisioned）： references/authoring-provisioned-dag.md
• パス B — YAML Workflow（MWAA Serverless）： references/authoring-serverless-workflow.md

振り分けられたパスの Write ステップの後、以下の Deploy & Test に進んでください。

デプロイとテスト（任意、作成後）

デプロイと再デプロイはすべて作成の担当範囲です。詳細は references/deploying-mwaa.mdを参照してください。

手順

1. 確認する — 成果物にスケジュールがあるかどうかに応じて、選択肢を提示します。 パスに適した表現で質問します。

   • プロビジョニング型：「このDAGを環境にデプロイする」（DAGは環境のS3バケットにアップロードされます）。
   • サーバーレス：「このワークフローをデプロイする」（ワークフローは独立したリソースです。「環境にデプロイする」とは決して言わないでください）。

   DAG／ワークフローにスケジュールがある場合：

   • デプロイしてテストする — デプロイし、非一時停止状態にして、今すぐ実行をトリガーする
   • デプロイして非一時停止にする — デプロイし、非一時停止状態にして、スケジュールに従って実行させる（すぐにはトリガーしない）
   • デプロイのみ — S3にアップロードし、一時停止状態のままにする

   DAG／ワークフローにスケジュールがない場合（手動トリガーのみ）：

   • デプロイしてテストする — デプロイし、今すぐ実行をトリガーする
   • デプロイのみ — S3にアップロードし、一時停止状態のままにする（スケジュール設定の対象がないため、「非一時停止にする」選択肢はありません）

   ユーザーはすべての選択肢を辞退することもできます。

2. デプロイする：

   • プロビジョニング型： DAGを環境のSourceBucketArn／DagS3Pathにアップロードします。デプロイ後の検証（deploying-mwaa.mdを参照）を実行し、スケジューラーが新しいファイルをインポートエラーやdag_idの競合なしに解析したことを確認します。環境が存在せず、ユーザーが承認した場合は、インラインで作成します（計画・検証・実行＋明示的な確認）。その後、CREATINGからAVAILABLEになるまでポーリングします（約20～40分）。ユーザーが既存の環境を指定することもできます。
   • サーバーレス： CreateWorkflow（新規）またはUpdateWorkflow（再デプロイ）を実行します。ここでYAMLが同期的に検証されます。ワークフローでPythonOperator／BashOperatorを使用する場合は、まずコードパッケージをビルドしてS3にアップロードし、--codeで渡します（references/serverless-code-packaging.mdおよびreferences/deploying-mwaa.mdを参照）。ユーザーが既存のARNを指定することもできます。
   • 再デプロイ（修正ループ）： 同じアップロード／UpdateWorkflowのパスを使用します。testing-mwaa-workflowがARTIFACTまたはENVIRONMENTの修正を委任したときにも再利用されます。

3. 「デプロイして非一時停止にする」を選択した場合 — 手順2に従ってデプロイし、その後、非一時停止状態にします。実行をトリガーしたり、testing-mwaa-workflowを呼び出したりしないでください。

4. 「デプロイしてテストする」を選択した場合 — 手順2に従ってデプロイし、該当する場合は非一時停止状態にしてから、解決済みのターゲット（環境名＋dag_id、またはワークフローARN）を指定してtesting-mwaa-workflowを呼び出します。この引き継ぎは、テスト側の委任呼び出しモードです。

必須条件： テストがリクエストされた場合は、最初からのリクエスト（「デプロイしてテストする」）でも、会話の後半でのリクエスト（「テストして」「実行して」「試して」）でも、必ずtesting-mwaa-workflowを呼び出してください。DAGの実行を手動でトリガー、監視、検証してはいけません。 「デプロイして非一時停止にする」はテストのリクエストではなく、デプロイのみの操作です。

• 本番環境の安全性： create-environment、update-environment、create-workflow、update-workflowは状態を変更するため、それぞれ影響を説明したうえで確認してください。本番環境を示す名前のターゲットについては警告してください。

トラブルシューティング

エラー	原因	対処方法
dagrun_timeout によって DAG が早期終了する	呼び出されたサービスに設定されたタイムアウトより短い	dagrun_timeout を延長するか、サービスのタイムアウトを短くします
YAML 検証でワークフローが拒否される	型またはパラメーターが誤っている	timedelta 形式を使用し、許可リストを確認します
Serverless でオペレーターが見つからない	許可リストに含まれていない	サポート対象のオペレーターである PythonOperator、BashOperator、または Lambda を使用します
Serverless の実行時に、コードを抽出できない／環境が破損している	コードパッケージに問題がある	ファイルを zip のルートに配置し、__pycache__ を含めず、250 MB 以下にして、再パッケージします
Serverless の Python タスクで ImportError が発生する	依存関係が不足しているか、プラットフォームに合わない wheel がある	manylinux2014_x86_64／Py3.12 の wheel として同梱します。プリインストール済みのパッケージは同梱しないでください
テンプレート変数が未定義	バージョンが一致していない	使用中の Airflow バージョンに対応する変数を確認します

参考資料

• references/dag-patterns.md — Python DAG テンプレート
• references/yaml-schema.md — MWAA Serverless 形式
• references/deploying-mwaa.md — デプロイ、インラインでの環境作成、再デプロイ
• references/serverless-code-packaging.md — Python／Bash コードのパッケージ化、プリインストール済みパッケージ、制限
• references/authoring-provisioned-dag.md — パス A：プロビジョニング済み Python DAG の作成手順（A1～A7）
• references/authoring-serverless-workflow.md — パス B：Serverless YAML の作成手順（B1～B5）

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

• 状態を変更する操作（create／update-environment、 create／update-workflow、S3 DAG アップロード）には、影響を明示したうえで 明示的な確認が必要です。prod を含む名前のターゲットには警告してください（Deploy HARD-GATE を参照）。
• 最小権限の IAM：A5 の確認では、成果物に必要な正確な Action／Resource の組み合わせのみを追加します。*FullAccess や service:* は決して指定しないでください。
• シークレット／エンドポイントをハードコードしない：Secrets Manager または SSM Parameter Store をバックエンドとする Airflow Variables／Connections を使用します。DAG コードや CLI の例に認証情報を出力しないでください。
• Serverless コードパッケージには、ユーザー自身のモジュールと、バージョンを固定したプラットフォーム対応の wheel のみを含めます。レビューされていないサードパーティ製バイナリは含めないでください。
• データ保護：機密データを SNS／CloudWatch の通知ペイロードやログに含めないでください。これらの暗号化を利用してください。
• インラインで作成するリソースのセキュアなデフォルト設定：このスキルで作成する S3／MWAA／SNS／CloudWatch リソースは暗号化し、アクセスを制限してください。deploying-mwaa.md の「Secure defaults」を参照してください。
• AWS セキュリティのベストプラクティス：実行時に、MWAA User Guide のセキュリティのベストプラクティス のページ（およびMWAA Serverless の同等ページ） を参照して、セキュリティ態勢を確認してください。AWS はこれらを随時更新します。deploying-mwaa.md の「Secure defaults」も参照してください。