AWSがAIエージェントでデータ基盤構築を自動化する「ADOP」参照アーキテクチャ公開

ADOPとは何か

ADOP（Agentic Data Operations Platform）は、AWSが公開したデータエンジニアリング向けの参照アーキテクチャです。Amazon BedrockとClaude CodeなどのAIコーディングツールを組み合わせ、データソースの追加から、Bronze/Silver/Goldの各レイヤー構築までをAIエージェントが自動化します。データエンジニアリングチームは通常、1つのデータソースを立ち上げるのに数週間かかるとされてきました。ADOPはこの期間を大幅に短縮することを目指しています。

具体的には、ETLの記述、手作業の品質チェック、セマンティックモデルの更新、コンプライアンス検証といった作業をエージェントが支援するという構成です。対象読者として、VPoEやChief Data Officer、データ基盤のディレクター層が想定されています。実装の詳細はプラットフォームエンジニア向けに後半で説明されています。

開発と本番の分離

ADOPの最大の特徴は、AIエージェントが動作するのは開発環境だけで、本番環境では生成されたコードを実行するという点です。開発中はClaude Codeなどのエージェントが、ETLコード、品質チェック、セマンティックレイヤーの定義、規制対応の制御を生成します。エンジニアはその出力をレビューし、CI/CDの仕組みを通じて本番環境に昇格させます。昇格されるのは、PySparkやSQL、Airflow DAG、IAMとCedarのポリシーといった決定的な成果物です。

デフォルトでは、本番環境はモデルを呼び出さず、静的なコードだけで動作します。実行時に推論が必要な場合はAmazon Bedrockのエンドポイントを使って拡張できますが、生成されたパイプラインコード自体は静的で監査可能な状態を保ちます。これは、コストの予測可能性と、規制対象データの監査を重視した設計と言えます。

汎用アシスタントとの違い

汎用のAIコーディングアシスタントは、あらゆるコードを生成できる一方で、範囲が広すぎるという問題があります。データ基盤にそのまま使うと、エンジニアごとに異なるアーキテクチャができあがる可能性があります。ADOPは意図的に選択肢を狭め、データエンジニアリング向けのスキルとプロンプトに特化しています。企業の標準をアーキテクチャ契約として組み込み、モデルが設計図を自由に描くのではなく、設計図に沿って埋める役割に徹するという方針です。

また、ADOPではポリシーと規制のガードレールをビルド時に適用します。コンプライアンス用のプロンプトをオンボーディング時に適用することで、法務部門はアプリケーションコードではなく、プロンプトファイルをレビューすることができます。このような制御を組み込むことで、「開発者を速くする」汎用ツールではなく、「すべての開発者を一貫させる」方向性を打ち出しています。

アーキテクチャの構成

中核となるのは、Amazon Bedrock上で動作するData Onboarding Agentです。Claude CodeのDynamic Workflow機能を使って、パイプライン構築の各段階を担当するサブエージェントを起動します。サブエージェントは、メタデータ生成、データオントロジー推定、データ品質チェック、ETL変換、AirflowまたはAWS Step Functionsによるオーケストレーションを担当します。要件はユーザーペルソナとの対話を通じて反復的に補完され、各成果物はAWSにデプロイする前にローカルで検証されます。

Decision Engineは、企業の設計判断をAIでエンコードした存在です。組織のガイドラインや技術標準をビルドプロセスに埋め込み、エンジニアによるバラつきを抑えます。また、ツールのルーティング規則やCedar認可ポリシー、不変条件、コンプライアンス用プロンプトといったガードレールがサブエージェントを制限します。エージェントの動作はAgentTraceで記録され、意図や選択したツール、結果、コストをCloudWatchやOpenTelemetry経由で監査できます。

導入手順と注意点

導入は、GitHubリポジトリをクローンし、データをAmazon S3またはローカルストレージに置いて、所定のプロンプトを実行するという2ステップです。公開されている例では、勤怠データをSilverレイヤーに取り込み、個人情報をハッシュ化または仮名化し、Goldレイヤーでは集計済みのテーブルを生成するという指示が示されています。ただし、初期の数週間は企業標準をアーキテクチャ契約としてコード化する作業が中心になります。

セキュリティ面では、シークレットがエージェントに渡らないようにする設計が言及されています。また、開発中にエージェントが規制対象データや個人情報を処理する可能性があるため、アクセス制御を適切に設定し、責任あるAIのポリシーを確認してから本番に昇格させる必要があるとされています。コンプライアンス対応の最終責任は顧客側にある点も明記されています。