8月22日、AWSが「Agentic Data Operations Platform (ADOP): Data engineering into hours」と題した記事を公開した。新規データソース1件の追加に数週間を要していたデータエンジニアリング業務を、AIエージェントの活用で数時間に短縮する参照アーキテクチャ「ADOP」の詳細が公開されている。最大の特徴は、エージェントを開発環境専用のビルドツールとして扱い、本番環境ではエージェントを一切動かさないという設計思想だ。LLMをランタイムに組み込み続ける多くのAIエージェントアーキテクチャとは根本的に異なるアプローチで、金融・ヘルスケアなど規制の厳しい業界への適用を強く意識した構成となっている。
データエンジニアリングの「数週間」を「数時間」に
データエンジニアリングチームが新規データソースを1件追加するだけで、ETL記述・品質チェック・セマンティックモデル更新・コンプライアンス検証に数週間を費やす——これがADOPが解決しようとする問題だ。
近年、dbtやAirbyteといったツールがデータ変換・取り込みの自動化を進めてきたが、いずれも「エンジニアが設定を書く」前提から抜け出せていない。ADOPはその一歩先として、自然言語によるプロンプトからパイプライン全体を生成するAIエージェント層を導入する。
ADOPは**Amazon Bedrock** 上に構築された参照アーキテクチャ（リファレンスアーキテクチャ）で、Claude Code・Kiro・Cursor・Codexといった任意のAIコーディングツールと組み合わせて動作する。特化型AIエージェントがデータのBronze（生データ）→Silver（クレンジング済み）→Gold（分析用集計） の全ライフサイクルを自動化する設計だ。このBronze-Silver-Goldの三層構造はMedallionアーキテクチャとも呼ばれ、データレイクハウス設計の標準的パターンとして広く採用されている。
リポジトリはGitHubで公開されており、以下の2ステップで試せる。
git clone https://github.com/aws-samples/sample-Agentic-Ai-Data-Operations.git
次に、S3またはローカルストレージにデータセットをアップロードし、以下のようなプロンプトを実行する。
/onboard-workflow
Onboard attendance data from s3://amzn-s3-demo-source-bucket/demo_landing/attendance.csv into Silver with dedup on (employee_id, check_in)
and not-null policy on employee_id and check_in, and into a flat denormalized Gold Iceberg table aggregated daily-per-employee with derived
measures (hours_worked_clean, attendance_rate, late_arrival_flag, overtime_hours, absence_category).
Run daily at 03:00 UTC.
Apply data governance controls: hash/pseudonymize PII fields in Silver, suppress or mask sensitive fields in Gold, enforce retention policies,
and log processing metadata.
Please profile the data first, then propose your recommended quality thresholds and transforms before generating any code.
自然言語でデータソースを記述するだけで、スキーマ推論・ETL・品質チェック・セマンティックレイヤー更新までエージェントが一貫して処理する。
最重要設計原則：「エージェントは開発環境だけで動かす」
ADOPの設計で最も特徴的な点は、エージェントをビルド時専用ツールとして扱い、本番環境ではエージェントを動かさないという原則だ。
エージェントは開発環境で推論・提案・コード生成を行い、エンジニアがレビューする。CI/CDが生成された確定的なアーティファクト（PySpark・SQL・Airflow DAG・IAMポリシー・Cedar認可ポリシー）をステージングおよび本番に昇格させる。本番環境はモデルを呼び出さず、静的で監査可能なコードのみで動作する。
なお、Cedar認可ポリシーとは、AWSが開発したオープンソースの属性ベースアクセス制御（ABAC）言語で、きめ細かいアクセス権限をポリシーファイルとして宣言的に記述できる。ADOPではエージェントが生成するIAMポリシーと並んで、このCedarポリシーがサブエージェントの権限制約に使われる。
これは「ランタイムにLLMを組み込み続けるアーキテクチャ」とは根本的に異なる。コストの予測可能性と監査対応力を優先した設計で、特に金融・ヘルスケアなど規制の厳しい業界向けワークロードを念頭に置いている。なお、ランタイムでのモデル推論が必要な場合はAmazon Bedrockエンドポイントで拡張可能とされている。
アーキテクチャの構成要素
Data Onboarding Agentがメインエージェントとして起動し、Claude CodeのDynamic Workflow機能を使って以下の専門サブエージェントを生成する。
- メタデータ生成・データオントロジー推論
- データ品質チェック
- ETL変換
- オーケストレーション（AirflowまたはAWS Step Functions）
要件はユーザーとの会話を通じて反復的に補完され、すべてのアーティファクトはローカルで検証後、人間の承認（human-in-the-loop） を経てAWSへデプロイされる。
Decision Engine（AIクローン） は、組織のアーキテクチャ標準・技術方針・設計思想をビルドプロセスに直接埋め込む仕組みだ。汎用コーディングツールを使うとエンジニアごとに異なるアーキテクチャが生まれる問題を、この「意見を持つ設計」で防ぐ。
ガードレールとして、ツールルーティングルール・Cedar認可ポリシー・インラインコンプライアンスプロンプトがサブエージェントを制約する。コンプライアンス対応は「ガバナンスフレームワークごとに1つの規制プロンプト」を適用する設計で、法務チームがレビューするのはプロンプトファイルであり、アプリケーションコードではない。
すべてのエージェント判断はAgentTraceでトレースされる。AgentTraceはADOP独自のトレーシング機構で、エージェントの意図・選択したツール・実行結果・推論コストを記録し、Amazon CloudWatchまたはOpenTelemetryシンクに出力できる。LLMを使ったシステムで問題になりがちな「なぜその判断をしたか」を後から検証できる点が、規制対応上の重要な要素となる。
セキュリティ設計
エージェント駆動開発でよくある懸念に対し、ADOPは以下の設計で対応している。
- シークレット管理：データベース認証情報・APIキーはAWS Secrets Managerで管理し、エージェントのコンテキストには渡さない。エージェントが参照するのはシークレットのARNやプレースホルダー変数のみ。
- データ分離：エージェントはスキーマメタデータ・サンプル行数・カラム統計を扱うのみで、生の本番データには触れない。プロファイリングが必要な場合も、スコープを絞ったサンドボックス内で実行し、結果を要約してからエージェントに返す。
- モデル通信の非保持：Amazon Bedrockを経由したClaudeとの会話はモデルのトレーニングに使用されず、プロンプトと応答はセッション中のみ存在する（Amazon Bedrock Data Privacy and Security FAQ参照）。
- ネットワーク分離：デフォルトでエージェントは開発者マシンまたはVPC内で動作し、明示的な設定なしにデータがネットワーク外に出ない。
責任あるAI利用に関する注意点
ADOPはAI生成の成果物に対して必須の人間レビューを要求している。特にコンプライアンス制御や規制対応コントロールについては、有資格エンジニアが本番昇格前にレビューする必要がある。
LLMはもっともらしいが誤った論理を生成することがある（ハルシネーション）。生成されたマスキングルール・保持ポリシー・アクセス制御は、法務・プライバシー・コンプライアンスチームによる検証なしに規制上の義務を満たすものとして扱ってはならないと明記されている。
導入タイムラインと変化管理
記事では12週間の段階的ロールアウトが提示されている。
- Phase 1（1〜3週）：エンジニア2〜3名のパイロット。非重要データソース1件を対象に実施し、アーキテクチャ契約を精査。
- Phase 2（4〜6週）：プラットフォームチーム全体に拡大。複雑度の異なる3〜5件のソースを追加オンボーディング。
- Phase 3（7〜12週）：組織全体への展開。新規ソースのオンボーディングは全てADOP経由。既存パイプラインはメンテナンスウィンドウで順次移行。
初期は「パイプライン構築」ではなく「アーキテクチャ標準のエンコード」に時間がかかる一方、契約（architectural contract）が完成した後は各新規ソースが「プロジェクト」ではなく「プロンプト1つ」になるとされている。
詳細はAgentic Data Operations Platform (ADOP): Data engineering into hoursを参照していただきたい。
