はじめに さくらのナレッジ編集部の法林です。 2026年8月1日(土)に、さくらインターネットの大阪本社でもあるBlooming Campにおいて「きのこカンファレンス 2026 in 関西」が行われました。本記事ではこ […]

英語版ブログ： “ Executive Insights from the Inaugural AWS Life Sciences Symposium EMEA ” 基調講演の全編録画： YouTube で視聴する はじめに ライフサイエンス業界は転換点に立っています。技術は揃い、ユースケースも実証されている。それにもかかわらず、多くの企業が有望なパイロットと本番規模のインパクトの間で足踏みを続けています。初開催となった Amazon Web Services (AWS) Life Sciences Symposium Zurich （チューリッヒ）には、製薬・バイオテック・医療機器のリーダーが数百名集まり、このパラドックスに向き合いました。参加者に共通していたのは、AI への投資を、最終的に患者の健康改善につながる成果へと転換したいという思いです。 冒頭の基調講演で、AWS の Director of Life Sciences を務める Dr. Boris Bogdan は、このパイロットから本番への壁に正面から取り組み、パイロット段階で停滞する企業と成功する企業を分ける 4 つの戦略的差別化要因を示しました。 戦略的差別化要因 1：部門横断で統一した戦略をつくる 新しい取り組みや新興技術の多くと同様に、ライフサイエンス企業の多くは AI をサイロ化したプロジェクトとして扱い、部門ごとにパイロットを走らせています。研究開発部門は独自のパイロットを回し、臨床開発部門は別のロードマップを持ち、コマーシャル部門はさらに独立して実験しています。 この進め方でも価値ある実証は得られます。しかし、スケールしません。 このパターンは、スタートアップからグローバル大手バイオファーマまで業界を通じて共通しています。AI 投資から段階的に大きなリターンを得ている企業は、スケールするイノベーションを可能にする「つながった基盤」を整えています。具体的には、全社共通のオントロジー、共通データモデル、メタデータとコンテキスト、エージェントインフラストラクチャ、そして AI ガバナンスです。これらが揃うことで共通基盤が成立し、各部門は統一されたプラットフォーム上で、それぞれのイノベーションを進められるようになります。 戦略的差別化要因 2：デュアルトラックの発想がもたらす力 経営層は、短期的な成果を出しながら、同時に長期の AI 戦略を定義して投資するという二重のプレッシャーに直面しています。ここで必要になるのが、クイックウィンとスケーラブルな AI 基盤への計画的な投資を両立させる、デュアルトラックの発想です。 そのため私たちは、ユースケースを 2 つのトラックに分けて考えます。「Track 1」のユースケースは、優先度の高い特定領域で漸進的な価値を生むもので、多くは既存プロセスの上に AI を載せる形をとります。この取り組みから相当な価値が生まれていることは間違いありません。プロジェクト期間を数か月から数日へ短縮する、コストを二桁パーセント削減するといった成果が、モメンタムを維持し、クイックウィンを示してくれます。ただし前述のとおり、サイロ化したプロジェクトは長期的な変化を生みません。 そこで登場するのが「Track 2」のユースケースです。これはプラットフォームの構築を強制するもので、基盤レイヤーの設計と整備を促すために意図的に選ばれます。直接的な価値と、それによって確立される全社的なケイパビリティの両面から選定されるのです。好例がコマーシャルエージェントの開発です。これは価値の高いユースケースであり、医師からの問いに答えるためにセマンティックハブの構築を必要とします。実在する課題を解決しつつ、セマンティックレイヤーの整備を前に進めます。もう一つの例は、臨床データ変換の優先化です。これには AI 対応のデータプラットフォームが不可欠になります。変換プロセスを加速する価値を得ながら、将来の治験に必要な基盤インフラストラクチャを同時につくることができます。Track 1 のユースケースだけに注力する組織は、一度解決してスケールさせる基盤に投資する代わりに、同じ課題を複数の部門で何度も解き直していることが少なくありません。 成熟したユースケースポートフォリオは、両方のトラックのバランスを取ります。Track 1 がモメンタムを保ち、Track 2 が四半期ごとに基盤を成長させる。その結果、次の四半期のユースケースは、それ以前よりも速く、安く、強力になります。 戦略的差別化要因 3：構造的な独立性 ほとんどの組織は、既存組織の枠内でイノベーションに取り組みます。つまり、インセンティブ設計、標準業務手順書、ガバナンス、既存のチーム階層という境界の内側です。漸進的な改善には、この進め方がよく機能します。 しかし AI の真価は、レガシーなプロセスや手順を問い直し、再設計することから生まれます。「この期間を 50% 短縮するにはどうするか」から「AI があるいま、何が可能になったのか」へと問いを組み替えることです。 これは新しいモデルではありません。Apple が iPhone を、Toyota が Lexus を生み出したときと同じやり方です。組織構造と地理的配置の両面でサテライトを設けることで、チームは既存の延長線上の改善ではなく、再構想に集中できるようになります。たとえば Basel の本社の外にチームを置き、London の AI/ML チームと並走させるといった形です。要点は、制約なく革新できる自由を持った、構造的に独立したチームをつくることにあります。 戦略的差別化要因 4：AI アーキテクチャを自ら所有する 自社データを自ら所有することの重要性は、すでに広く共有されています。同じ考え方が AI にも当てはまります。差別化された AI 基盤を築いている組織は、自社のアーキテクチャを、自社固有の要件と目標に合わせた独自の投資対象として捉えています。AI アーキテクチャの切り分け方は数多くありますが、最も成功しているのは 3 層構造のアプローチです。 レイヤー 1 — 参入障壁：データとセマンティクス。 組織を AI 対応にするためのレイヤーです。データ、タクソノミー、オントロジー、セマンティクス、SOP、そしてビジネス上の関係性が含まれます。AI を自社にとって機能するものにする、その土台です。 レイヤー 2 — 優位性：エージェントとオーケストレーション。 AI における優位性を築く層です。ここではアーキテクチャの選択が重要になります。オープンスタンダードの上に構築し、ロックインを避けることで、選択肢と適応力を維持できます。 レイヤー 3 — 選択の自由：モデルとインテリジェンス。 選択肢を最大限に保ちます。設計段階からマルチモデルのアーキテクチャを維持し、モデルが規制対象のワークフローに入る場面ではバージョン管理を確実に行います。 AI をビジネスの差別化要因にするのは、単一のモデルではありません。自社のデータ、自社のコンテキスト、自社のワークフロー、そしてその下で回る学習ループです。アーキテクチャの原則はシンプルです。データとセマンティックレイヤーはしっかり握る。エージェントとオーケストレーションのレイヤーは慎重に選ぶ。モデルは柔軟性を確保する。 オペレーティング原則の価値 エンタープライズ AI で成果を出している組織を分けているのは、アーキテクチャ、組織構造、ユースケースの優先順位づけだけではありません。オペレーティング原則も決定的な役割を果たします。 ニューヨークで開催された AWS Life Sciences Symposium で Dan Sheeran が語った とおり、初日から本番を前提に構築し、ビルダー文化をつくることが必要です。 初日から本番を前提に構築する。 多くの Track 1 ユースケースがプロトタイプで止まってしまう理由は共通しています。本番へスケールする段階で、性能、スケーラビリティ、セキュリティ、ガバナンスの課題に直面するのです。プロトタイプが失敗したからではありません。それを支える周辺インフラストラクチャが追いついていないからです。Eli Lilly は、統合データプラットフォームである Cortex を初日から本番前提で構築した事例を、示唆に富む形で共有してくれました。 ビルダー文化をつくる。 AI の最も革新的な活用は、開発者ではなく、課題を深く理解している現場のエンドユーザーから生まれることがあります。適切なガードレールのもとで誰もが構築できる文化とインフラストラクチャを整えることが決定的に重要です。ここで世界中のライフサイエンス企業を支えているのが Amazon Quick です。 Amazon Quick は、一行もコードを書かずに、組織の誰もをビルダーに変えます。マーケティングチームは、直近の成功事例から得たインサイトをポジショニングに反映させたセールスデッキを生成できます。薬事チームは、確立された SOP や過去の承認内容を参照して申請文書のドラフトを作成し、サイクルタイムを大幅に短縮できます。 まとめとおすすめ資料 初開催となった欧州シンポジウムからのメッセージは明確です。孤立した AI 実験から、統合された本番グレードの基盤へと踏み出した組織が、測定可能で持続的なインパクトを手にしています。技術は揃っています。ユースケースは実証されています。差をつけるのは実行です。統合された戦略、デュアルトラックのポートフォリオ、サテライトを設ける組織的な勇気、自ら所有するアーキテクチャ、そして本番対応とビルダー文化を優先するオペレーティング原則です。この節目となるイベントにご参加いただいたすべてのお客様とパートナーの皆様に感謝申し上げます。そこで交わされた議論は、私たちの確信を強めるものでした。ライフサイエンスのリーダーが正しい基盤に投資したとき、患者へのインパクトは漸進的なものではなく、変革的なものになります。今後もこの対話を続けてまいります。次の AWS イベントで皆様にお会いできることを楽しみにしています。 推奨アクション EMEA 基調講演の全編録画を視聴する ニューヨークシンポジウムのエグゼクティブインサイトを読む AWS European Sovereign Cloud について知る Amazon Quick を試す — 誰もをビルダーに 亀田　俊樹 ( Toshiki Kameda, Ph.d., MBA ) ヘルスケア・ライフサイエンス事業開発部 シニア事業開発マネージャー。製薬業界で 20 年以上の経験を持ち、特にメディカルアフェアーズ、コマーシャルと製薬デジタル戦略（DTx 含む）を得意としている。慶應義塾大学で医療政策・管理学の博士号を取得し、ポスドク研究員として医療データ分析、アウトカムリサーチを学びました。趣味はドライブと BBQ。

本記事は、2026 年 8 月 6 日 に公開された Event-driven pipeline orchestration with Amazon MWAA and Airflow 3.0 を翻訳したものです。翻訳はクラウドサポートエンジニアの山本が担当しました。 複数の AWS アカウントで Apache Airflow を運用しているデータエンジニアリングチームは、連携という根強い課題を抱えています。チームやビジネスユニットごとに独立した Amazon Managed Workflows for Apache Airflow ( Amazon MWAA ) 環境を管理している場合、環境間でワークフローを連携させる仕組みが標準では用意されていません。環境をまたぐオーケストレーションは従来、時間ベースのポーリング、複雑なカスタムセンサー、API ベースのトリガーに頼るしかなく、レイテンシーと信頼性の懸念が伴いました。Apache Airflow の Datasets 機能 (バージョン 2.4 で導入) により、単一の Amazon MWAA 環境内で有向非巡回グラフ (DAG。タスクとその実行順序を定義するワークフロー定義) のデータ認識スケジューリングが可能になりました。しかし、複数アカウントで Airflow を運用するチームには、環境間でワークフローを連携させる手段が依然としてありませんでした。 この課題を解決するのが Apache Airflow 3.0 です。このバージョンを利用できるようになった Amazon MWAA 3.0 では、ポーリングの負荷や環境間の密結合なしに、上流のイベント発生に応じて動作するクロスアカウントのイベント駆動オーケストレーションを実現します。Amazon Simple Queue Service ( Amazon SQS ) をメッセージブローカーとして使い、Asset Watcher がポーリングベースのセンサーをイベント駆動のトリガーに置き換えます。この方式でオーケストレーションのレイテンシーが数分から数秒に短縮され、ポーリングセンサーが占有していたワーカーリソースを解放できます。さらに、コンシューマー環境が一時的に利用できない状態でも Amazon SQS が連携シグナルを保持するため、メッセージの信頼性も向上します。 本記事では、Airflow 3.0 のアセットベーススケジューリングと Amazon SQS の連携を使って、クロスアカウントのオーケストレーションパターンを設計・デプロイする方法を説明します。Asset Watcher の仕組み、プロデューサー DAG からアセットイベントを発行する方法、下流の Amazon MWAA 環境で依存ワークフローをトリガーする方法を取り上げ、複数アカウントにまたがる応答性の高い疎結合なパイプラインを構築します。 AI コーディングアシスタントでインフラストラクチャを構築・デプロイしている場合、ソリューションのリポジトリには Agent Skills 標準に基づくエージェントスキルが含まれており、本記事のアーキテクチャとベストプラクティスを組み込んでいます。 ソリューション概要 本ソリューションでは、次のような複数の Amazon MWAA 環境によるオーケストレーションアーキテクチャを示します。 プロデューサー Amazon MWAA 環境 (アカウント A) がデータ処理ワークフローを実行し、データセットの作成・更新時に Amazon SQS キューへアセットイベントを発行します。 Amazon SQS キュー がメッセージブローカーとして働き、プロデューサー環境とコンシューマー環境を疎結合にします。 コンシューマー Amazon MWAA 環境 (アカウント B) が Asset Watcher で Amazon SQS キューを監視し、関連するアセットイベントが届くと下流の DAG を自動的にトリガーします。 主なメリット イベント駆動のアプローチには、従来のポーリングと比べていくつかの利点があります。 ポーリングの負荷が不要: 継続的なセンサーのポーリングを、イベント到着時に反応する Asset Watcher に置き換えられます。 ほぼリアルタイムの応答: スケジュールされたポーリング間隔を待つことなく、下流の DAG が数秒以内にトリガーされます。 環境の独立性: プロデューサーとコンシューマーの Amazon MWAA 環境に直接的な依存関係がないため、各チームは互いに影響を与えずに環境をスケールしたり更新したりできます。 確実なメッセージ配信: コンシューマー環境が一時的に利用できない場合でも、Amazon SQS が耐久性の高いメッセージ配信を担います。 明確なチームオーナーシップ: 自チームの Amazon MWAA 環境を維持しながら、複雑なクロスアカウントワークフローを連携できます。 実装の高速化: 要件を自然言語で記述すれば、エージェントスキルが本記事のベストプラクティスを組み込んだ、デプロイ可能なプロデューサー DAG とコンシューマー DAG を生成します。 アーキテクチャ概要 次のアーキテクチャでは、AWS アカウントをまたいで独立した Amazon MWAA 環境を接続します。一方の環境でパイプラインが完了すると、環境間の直接的な結合やポーリングの負荷なしに、もう一方の環境で依存ワークフローが自動的にトリガーされます。 図 1: Amazon SQS を使った Amazon MWAA 環境間のクロスアカウントイベント駆動オーケストレーション アーキテクチャのコンポーネント アーキテクチャは 4 つの主要コンポーネントで構成されます。プロデューサー DAG はアセットをアウトレットとして定義し、タスクが正常に完了すると Amazon SQS キューへイベントを発行します。Amazon SQS キューはアカウントをまたぐ耐久性の高いメッセージブローカーとして働き、AWS Identity and Access Management (IAM) ポリシーでプロデューサーにメッセージ送信の権限、コンシューマーに受信の権限を付与します。コンシューマー側では Asset Watcher がキューを監視し、メッセージが届くとアセットの状態を更新します。そのアセットをスケジュールに指定したコンシューマー DAG が自動的にトリガーされます。 前提条件 本ソリューションを実装する前に、次のものを準備してください。 Apache Airflow 3.0 以降を実行する Amazon MWAA 環境 2 つ (同一の AWS アカウントでも、別々のアカウントでも構いません)。各環境で triggerer コンポーネントを有効にしておく必要があります。 IAM ポリシーに関する中級レベルの知識 (クロスアカウントのロール信頼関係やリソースベースポリシーを含む)。 Apache Airflow の DAG 作成に関する中級レベルの知識 (Python による DAG 定義やタスクオペレーターを含む)。 本記事のコードサンプルを読んで応用できる基本的な Python の経験 (Python 3.8 以降)。 クロスアカウントの権限を設定した Amazon SQS 標準キュー (「クロスアカウント IAM」セクションを参照)。 両方の Amazon MWAA 環境と Amazon SQS キューにアクセスできる権限を持つ認証情報で設定した AWS Command Line Interface (AWS CLI)。 所要時間: 約 90 分 (GitHub リポジトリの手順に従った場合)。 推定コスト: 2 つの Amazon MWAA 環境と Amazon SQS キューの実行には AWS 料金が発生します。 Amazon MWAA の料金ページ と Amazon SQS の料金 ページで、お使いのリージョンと使用量に応じたコストを見積もってください。継続的な課金を避けるため、完了後はリソースを削除してください。 実装 本記事で説明するソリューションをデプロイできる GitHub リポジトリ を用意しています。Amazon MWAA 環境とクロスアカウントの Amazon SQS キューのセットアップから、Asset Watcher を使ったプロデューサー DAG とコンシューマー DAG のデプロイまで、実装手順を進めていきます。本記事で提供する DAG ファイル、IAM ポリシー、requirements の設定などのコードサンプルは、デモ目的のみを想定しています。本番環境にデプロイする前に、十分なテスト、セキュリティレビュー、固有の要件やコンプライアンス基準への適合確認を必ず実施してください。 考慮事項 Asset Watcher は Airflow の scheduler ではなく triggerer 上のバックグラウンドプロセスとして動作します。イベント駆動で DAG がトリガーされる前提として、コンシューマー側の Amazon MWAA 環境で triggerer が正常に稼働していることを確認してください。triggerer が停止していると、Amazon SQS メッセージはキューに溜まるものの、triggerer が復旧するまで下流の DAG はトリガーされません。詳細は Asset Watcher のドキュメント を参照してください。 Amazon SQS メッセージのデフォルトの保持期間は 4 日です (最大 14 日まで設定可能)。コンシューマー環境が保持期間を超えて利用できない状態が続くと、メッセージは失われます。処理に失敗したメッセージを捕捉するデッドレターキューの設定を検討し、復旧要件に合わせて MessageRetentionPeriod を調整してください。 クロスアカウントの Amazon SQS アクセスには、プロデューサーの実行ロールに付与する IAM アイデンティティポリシーと、Amazon SQS キューのリソースベースポリシーの両方が必要です。どちらかが欠けていたり、設定が誤っていたりすると、メッセージ配信はエラーを出さずに失敗します。クロスアカウントアクセスのパターンについては、 Four ways to grant cross-account access on AWS を参照してください。 Amazon SQS の VisibilityTimeout は、Asset Watcher がメッセージを処理するのに要する想定時間より長く設定してください。タイムアウトが短すぎると、メッセージが再配信されて DAG が重複実行される可能性があります。この値を調整する際は、 Amazon SQS の可視性タイムアウトのドキュメント を確認してください。 Amazon MWAA 環境には、DAG 数、triggerer 数、DAG の同時実行数に上限があります。複数の Asset Watcher で異なる Amazon SQS キューを監視する構成にスケールする予定がある場合は、設計を決める前に現在の Amazon MWAA のクォータを確認してください。 アセット URI は、Asset Watcher の定義とコンシューマー DAG の schedule パラメータで完全に一致させる必要があります。大文字小文字や末尾の文字が異なるだけでも、コンシューマー DAG はトリガーされません。不整合を避けるため、アセットは単一の DAG ファイルで定義してください。 プロバイダーパッケージ apache-airflow-providers-amazon と apache-airflow-providers-common-messaging は、Airflow と互換性のあるバージョンに固定してください。互換性のないバージョンではインポートエラーが発生し、triggerer が起動しないことがあります。依存関係の競合を避けるため、本記事で説明する constraints ファイルを使用してください。 エージェントスキル AI コーディングアシスタントは、一般的なプログラミングパターンだけでなく、対象のアーキテクチャや制約に関するコンテキストを持っているときに最も役立ちます。Anthropic が開発し、2025 年 12 月に公開標準としてリリースされた Agent Skills は、この目的に適した可搬性の高いフォーマットです。 SKILL.md ファイルに手順の知識、ベストプラクティス、ワークフローを記述しておくと、対応する AI コーディングエージェントが必要に応じて検出して適用できます。この標準は現在、Kiro、Strands Agents、Anthropic Claude Code、OpenAI Codex、Cursor、Gemini CLI などのツールでサポートされています。ここで提供するソリューションには、この標準に基づくエージェントスキル ( agent-skill/ ) が含まれ、本記事のクロスアカウントオーケストレーションアーキテクチャと運用のベストプラクティスが記述されています。「注文パイプライン用にクロスアカウントの Amazon MWAA DAG を書いて」のように AI コーディングアシスタントに指示すると、スキルがエージェントを一連のワークフローに沿って導きます。 Amazon SQS キュー URL の収集。 正しく構成されたプロデューサー DAG とコンシューマー DAG のファイル生成。 必要に応じて Amazon MWAA 環境へのデプロイ。 このスキルでは、AWS アカウント ID や Amazon MWAA 環境名を事前に指定する必要はありません。ローカルに設定された AWS CLI 認証情報を使って aws mwaa list-environments と aws sts get-caller-identity を実行して環境を自動検出し、どちらがプロデューサーでどちらがコンシューマーかの確認を求めます。 スキルには 2 つのモードがあります。 サンプルモード : クロスアカウントの動作をすばやく検証するためのリファレンス実装として、プロデューサー DAG とコンシューマー DAG を生成します。入力は Amazon SQS キュー URL のみです。 カスタムモード : DAG テンプレートを固有のビジネスロジックに合わせて調整します。たとえば、プロデューサーが AWS Glue の抽出、変換、ロード (ETL) ジョブを実行し、コンシューマーが data build tool (dbt) のモデル更新をトリガーする構成です。このモードでは、正しい Asset Watcher のパターンを保ちながら、DAG ID、タスク名、スケジュール、処理ロジックをカスタマイズします。 コード生成に加えて、スキルには自動デプロイのフローも含まれます。デプロイフローは既存の Amazon MWAA 環境を検出し、事前チェック (Amazon Virtual Private Cloud (Amazon VPC) のネットワーク、プロバイダーのバージョン、triggerer の健全性、Amazon SQS キューへのアクセス可否) を実行し、正しい Amazon Simple Storage Service (Amazon S3) バケットに DAG をアップロードして、エンドツーエンドで準備が整っているかを検証します。インフラストラクチャを変更するステップでは、いずれもユーザーの明示的な確認が必要です。使い方については GitHub リポジトリ も参照してください。 ベストプラクティス Amazon SQS を使った Airflow の Asset Watcher が常に最適とは限りません。適した場面であっても、センサーベースのポーリングとは異なる運用上の考慮事項が生じます。 本セクションでは、環境間オーケストレーションのパターンをどう選ぶか、Asset Watcher が依存するインフラストラクチャ (IAM、Amazon VPC、依存関係) をどう設定するか、本番環境で信頼性の高いプロデューサー DAG とコンシューマー DAG をどう設計するかを説明します。 クロスアカウント IAM プロデューサーの実行ロールには sqs:SendMessage と sqs:GetQueueUrl が必要です。 sqs:* を避け、対象キューの ARN に絞って付与します。 Amazon SQS キューのリソースポリシーでは、プロデューサーロールに sqs:SendMessage 、コンシューマーロールに sqs:ReceiveMessage 、 sqs:DeleteMessage 、 sqs:GetQueueAttributes 、 sqs:GetQueueUrl を許可する必要があります。 DAG をデプロイする前に、AWS CLI でクロスアカウントアクセスをテストします。Airflow のタスクログから AWS IAM をデバッグするのは、CLI レベルで設定ミスを見つけるよりはるかに手間と時間がかかります。 本番環境のキューでは Amazon SQS のサーバー側暗号化を有効にします。 triggerer の健全性 Airflow の Asset Watcher は scheduler ではなく triggerer で動作します。コンシューマー DAG をデプロイした後、Airflow UI で triggerer の健全性を確認します。 health API は、コンポーネントが壊れていても healthy と報告することがあります。Triggerer のロググループに Amazon CloudWatch のログストリームが存在するかを併せて確認してください。 airflow-<ENV>-Triggerer の CloudWatch ログで ClientError 、 QueueDoesNotExist 、 ImportError を監視します。 Amazon SQS の ApproximateNumberOfMessagesVisible と、デッドレターキュー (DLQ。受信試行の上限回数を超えても処理できなかったメッセージを捕捉するキュー) の深さに Amazon CloudWatch アラームを設定します。 依存関係の競合を防ぐため、constraints ファイルでプロバイダーのバージョンを固定します。 Amazon VPC のネットワーク プライベートサブネットは 0.0.0.0/0 を NAT ゲートウェイにルーティングする必要があります。設定していないと、ウェブサーバーは正常に見えるのに、ワーカーと triggerer がエラーを出さずに失敗します。 本番環境の高可用性のため、NAT ゲートウェイはアベイラビリティーゾーンごとに 1 つ、合計 2 つ使用します。 プライベートルーティングモードでは、NAT の代わりに Amazon VPC エンドポイント (Amazon S3、Amazon SQS、Amazon CloudWatch Logs、Amazon Elastic Container Registry (Amazon ECR)) を使用します。 Scheduler、Worker、DAGProcessing、Triggerer の Amazon CloudWatch ログストリームが存在するか確認します。ロググループが空の場合、コンテナが動作していません。 セキュリティグループは、自己参照のインバウンドトラフィックと制限のないアウトバウンドを許可する必要があります。 依存関係の管理 プロバイダーのバージョンは == で固定し、constraints ファイルを使用します。固定していないと、環境の更新時に動作しなくなります。 デプロイ前に MWAA Docker イメージ でローカルに依存関係をテストします。 更新後は requirements_install_ip のログストリームを確認します。環境の作成時にネットワークが利用できなかった場合は、新しい requirements-s3-object-version で再インストールを強制します。 バージョンの競合を避けるため、 requirements.txt に追加する前にプリインストール済みのベースパッケージを確認します。 オーケストレーションパターンの選択 環境間の依存関係すべてに Asset Watcher が必要なわけではありません。Airflow 3.0 には主に 3 つのオーケストレーションパターンがあります。Amazon SQS を使った Asset Watcher、 MwaaTriggerDagRunOperator 、そしてセンサーベースのポーリングで、それぞれ応答時間、結合度、リソース消費のトレードオフが異なります。実装を決める前に、次の表でユースケースに合ったパターンを選んでください。 パターン 仕組み 応答時間 結合度 ワーカー占有 適した用途 Asset Watcher + SQS (本記事) コンシューマーの triggerer が SQS を監視し、メッセージ到着時に DAG をトリガーする 数秒 疎結合 なし クロスアカウントのパイプライン、ファンアウト、独立したリリースサイクル MwaaTrigger DagRunOperator プロデューサーが MWAA API を呼び出して別環境の DAG を開始する 数秒 密結合 あり ( wait_for_completion 使用時) 同一アカウント内の 1 対 1 のトリガー センサー (ポーリング) コンシューマーが定期的に条件を確認する ポーリング間隔 中程度 あり (deferrable でない場合) 状態が持続する条件、環境内の依存関係 状態が持続するトリガー ( S3KeyTrigger など) を Asset Watcher に組み込むのは避けてください。条件が解除されないため、継続的に発火してしまいます。 DAG の作成 モジュールレベルのコードは最小限にします。DAG ファイルはサイクルごとに再パースされ、重いインポートはパースループ全体を遅くします。 1 回実行しても複数回実行しても同じ結果になるようにタスクを設計します (べき等性と呼ばれる性質です)。リトライ時に Amazon SQS メッセージが重複することがあるため、重複レコードを避けるには INSERT ではなく UPSERT (挿入または更新) を選びます。 シークレットは DAG ファイルやメッセージ本文に含めません。代わりに Airflow の Connections ( aws_conn_id ) を使用します。 S3 にアップロードする前に、 python your_dag.py でローカルに DAG のインポートをテストします。 S3 へのアップロード後は DAG のパースが完了するまで待つか、 dags reserialize で強制します。 プロデューサー DAG の設計 コンシューマーがプロデューサーに問い合わせずにルーティングできるよう、Amazon SQS メッセージに dag_id 、 run_id 、 logical_date 、データセット固有のコンテキストを含めます。 生の boto3 パッケージではなく SqsHook を使用します。 aws_conn_id の設定が反映され、Airflow のロギングとも統合されます。 発行の失敗はそのまま例外として上げ、Airflow のリトライ機構で再配信を処理させます。 コンシューマー DAG の設計 メッセージはキューを直接読むのではなく triggering_asset_events 経由で参照します。Amazon SQS メッセージは Asset Watcher がすでに消費しています。 メッセージのペイロードは防御的に検証します。プロデューサーはスキーマを変更していく可能性があります。 複数アセットにまたがる複雑な依存関係には、条件付きのアセットスケジューリング (& / |) を使用します。 リソースのクリーンアップ 継続的な AWS 料金を避けるため、本ソリューションで作成したリソースは完了後に削除してください。GitHub リポジトリには、Amazon SQS キュー、Amazon MWAA 環境、IAM ロールとポリシー、Amazon S3 バケットを削除する手順を段階的に用意しています。 プロビジョニングしたリソースの削除については、 GitHub リポジトリのクリーンアップ手順 を参照してください。 まとめ Apache Airflow 3.0 のアセットベーススケジューリングと Asset Watcher により、ポーリングの負荷や密結合なしに Amazon MWAA 環境間でワークフローを連携させる実用的な手段が手に入ります。Amazon SQS を信頼性の高いメッセージブローカーとして使うことで、従来のポーリング機構の運用負荷を伴わずに、複数の Amazon MWAA 環境と AWS アカウントにまたがる応答性の高い疎結合なデータパイプラインを構築できます。 Asset Watcher を使うことで環境間オーケストレーションのレイテンシーは数分から数秒に短縮され、カスタムセンサーは宣言的なアセットベーススケジューリングに置き換わります。複雑なワークフローを連携させながら、チームごとに独立した Amazon MWAA 環境を維持する柔軟性も得られます。Amazon SQS の耐久性のあるメッセージ配信により、環境が一時的に停止している間でもシグナルを失うリスクが下がります。 始めるには、次の手順を進めてください。 アーキテクチャの確認 (5 分): リポジトリのアーキテクチャ図を開き、どの Amazon MWAA 環境がプロデューサーで、どれがコンシューマーになるかを確認します。 Amazon SQS キューのセットアップ (15 分): クロスアカウントの Amazon SQS 標準キューを作成し、「クロスアカウント IAM」セクションの IAM アイデンティティポリシーとリソースベースポリシーを適用します。次に進む前に AWS CLI でアクセスを確認します。 DAG サンプルのデプロイと検証 (30 分): 「実装」セクションのプロデューサー DAG とコンシューマー DAG のスニペットを Amazon MWAA 環境にコピーし、プロデューサー DAG を手動でトリガーして、コンシューマー DAG が自動的に実行されることを確認します。 事前チェックの実行 (20 分): 「ベストプラクティス」セクションの Amazon VPC ネットワーク、プロバイダーバージョン、triggerer の健全性のチェックを進めます。環境の準備完了とする前に、Triggerer のロググループに Amazon CloudWatch のログストリームが存在することを確認してください。 必要に応じてエージェントスキルを使う: AI コーディングアシスタントを使っている場合は、リポジトリからスキルをインストールし、ビジネスロジックを自然言語で記述して、パイプラインに合わせたデプロイ可能な DAG を生成します。 複数のアカウントや AWS リージョンにデータ運用をスケールしていくうえで、Asset Watcher によるアセットベーススケジューリングは、AWS 上でモダンなイベント駆動データアーキテクチャを構築する基盤になります。まずは基本的なプロデューサー・コンシューマーのパターンから始め、オーケストレーションの要件が増えるにつれて複数アセットにまたがる複雑な依存関係へ段階的に発展させてください。 詳細は次の資料を参照してください。 Apache Airflow 3 on Amazon MWAA Launch Blog Post 。 Apache Airflow のドキュメント 。 Amazon MWAA ユーザーガイド 。 Amazon SQS のドキュメント 。 AWS IAM のクロスアカウントアクセス 。 Amazon MWAA の Amazon CloudWatch モニタリング 。 Airflow の外部で人による承認ステップや複雑な分岐ロジックを必要とするオーケストレーションパターンには AWS Step Functions 。 AWS Well-Architected Framework — Data Analytics Lens 。 Amazon MWAA のクォータ 。 Amazon VPC のネットワークに関するベストプラクティス。 著者について Satya Chikkala オーストラリアのメルボルンを拠点とする Amazon Web Services のシニアソリューションアーキテクトです。エンタープライズのお客様が成長と効率化につながるスケーラブルなクラウドソリューションを設計できるよう支援しています。仕事以外では、仮想のクラウドを実際の雲と交換し、岩壁を登り、山のトレイルを歩き、その光景をカメラのレンズに収めています。 Corrine Tan AWS のクラウドアーキテクトで、金融サービス、行政、スタートアップにわたるデータプラットフォームの設計を専門としています。コンサルティングの経験を背景に、クラウドネイティブ技術を使ったスケーラブルでドメイン指向のアーキテクチャを構築しています。専門分野はストリーミングパイプライン、Airflow によるオーケストレーション、データ品質、そしてデータ・モデル・アプリケーションを統合するフルスタックシステムで、取り込みから活用までを担うリアルタイムプラットフォームを提供しています。 Haofei Feng AWS のシニアクラウドアーキテクトで、DevOps、IT インフラストラクチャ、データアナリティクス、AI において 20 年以上の専門経験を持っています。組織のクラウド移行や生成 AI の取り組みを導き、AWS 上でスケーラブルかつセキュアな生成 AI ソリューションを設計することを専門としています。オーストラリアのシドニーを拠点とし、お客様向けのソリューション設計をしていないときは、家族とボーダーコリーとの時間を大切にしています。