数週間から数分へ: データ パイプラインの新たなエージェント時代

※この投稿は米国時間 2026 年 9 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。

データ パイプラインは現代の企業のバックボーンですが、オーケストレーションには参入障壁があり、多くのデータ専門家がこの重要な機能を利用できない状況にあります。Google Cloud NEXT ’26 での発表で Orchestration Pipelines フレームワークを紹介したことで、この状況は根本的に変わろうとしています。

この強力なフレームワークを実務担当者に直接提供するため、Google は Data Agent Kit を提供しています。これは、データ エンジニアリングとデータ サイエンスのツールを統合した、自由に利用できるオープンソースのコレクションで、お好みの IDE や CLI（VS Code、Claude Code、Codex など）に直接統合できます。

Data Agent Kit は、Orchestration Pipelines フレームワークを 2 つの異なる方法でワークフローにシームレスに組み込みます。まず、包括的なパイプライン管理のための専用の [データ エンジニアリング] タブが用意されています。2 つ目は、自然言語を使用して本番環境グレードの Apache Airflow® DAG を作成、デプロイ、トラブルシューティングできるように設計された、専門的なエージェント スキルです。

これらの専門的なエージェント スキルを宣言型の YAML DSL と組み合わせることで、アナリストから ML エンジニアまで、あらゆるデータ担当者が複雑な Python Airflow ボイラープレートを回避できます。このフレームワークは、高レベルのオーケストレーション ロジックを基盤となるコンピューティング実行から切り離し、データ組織全体で強力な MLOps 機能へのアクセスを民主化します。

この投稿では、MLOps の模範的なユースケースを例に、これを簡単に実現する方法を説明します。

環境設定

最初のオーケストレーション パイプラインを作成する前に、ローカル開発環境を設定する必要があります。2 分もかからずに開始できます。

1. 拡張機能をインストールして構成する

VS Code、VS Code フォーク、Antigravity、Claude Code、Antigravity CLI、Codex など、お好みの IDE または CLI に拡張機能をインストールし、Google Cloud アカウントで認証するには、公式ドキュメントの Google Cloud Data Agent Kit インストール ガイドに記載されている手順に沿って設定します。

2. オーケストレーション パイプラインのスキルを確認する

インストールしたら、必要なエージェント スキルが有効になっていることを確認します。

1. VS Code アクティビティ バーで [Google Cloud Data Agent Kit] パネルを開きます。

2. [設定] > [スキル] の順に移動します。

3. 「gcp-pipelines-orchestration」スキルが有効になっていることを確認します。

このスキルにより、エージェントは、パイプライン構文、変数置換、シークレット管理、Airflow 実行の自動インシデント診断に関する深い背景知識を得ることができます。

3. 最初のパイプラインを構築する

自然言語プロンプトを使用して、VS Code 互換の IDE 内で直接オーケストレーション パイプラインの作成、構築、検証を開始するには、公式の構築ガイド（パイプライン構築ガイド）をご覧ください。

ビジネス上の問題の例: プロアクティブなサプライ チェーン管理

ビジネス上の問題の例を見ていきましょう。物流および小売業界では、顧客満足度は正確な配達予定に左右されます。注文が予告なく遅延すると、顧客離れが急増し、サポート費用が膨らむ可能性があります。

これに対処するため、倉庫の場所、顧客の場所、注文の特性に基づいて正確な配送日数（日数単位）を予測するエンドツーエンドの MLOps アーキテクチャを構築しています。出荷前にこうした遅延を予測することで、運用チームはサービスレベル契約（SLA）に違反する前に、顧客に事前に通知したり、配送レベルを自動的にアップグレードしたりできます。

このアーキテクチャを完全に再現可能にするため、BigQuery の一般公開データセットである bigquery-public-data.thelook_ecommerce を使用します。デモの目的上、この静的データセットをトレーニング セットと推論セットに分割します。実際のシナリオでは、推論は新たに入ってくるデータに対して行われます。このデータセットは、実際の運用上の複雑さを提供します。

• 地理データ: 顧客の住所（users）と配送センター（distribution_centers）の緯度と経度。

• 時間データ: 注文ライフサイクルの詳細なタイムスタンプ（created_at、shipped_at、delivered_at）。

• 注文属性: 商品カテゴリ、価格、フルフィルメント ステータス（orders、order_items）。

このデータセットを BigQuery、Managed Service for Apache Spark サーバーレス、Gemini Enterprise Agent Platform、dbt と組み合わせることで、トレーニング、毎日のバッチ推論、モデルドリフト評価を処理する、自動化された自己修復型の MLOps ループを構築する方法を実証します。

エージェント ワークフロー: プロンプトからパイプラインまで、わずか数分で

拡張機能を構成すると、DAG 作成用のボイラープレート Python を完全にバイパスできます。VS Code 内で Data Agent Kit チャットを開き、単一の自然言語プロンプトを入力するだけで、継続的な MLOps フィードバック ループを定義しました。

注: 詳細なプロンプトは、このブログ投稿のために、再現性を考慮して作成されました。実際のシナリオでは、パイプラインごとに、より会話調で同じ結果を達成できます。完全なプロンプトと生成されたすべてのファイルは、Orchestration-pipelines GitHub リポジトリで入手できます。

注: Orchestration Pipelines スキルを備えたフロンティア モデルは、多くの場合、1 ステップで完全なワークフローを骨組みを作成できますが、LLM のレスポンスは、モデルのバージョン、ワークスペースのコンテキスト、トークンの深さによって当然異なります。最初のパスで特定のパラメータ、データセット パス、依存関係が省略された場合は、短いフォローアップ プロンプトを入力します。

数分以内で、Data Agent Kit が、基盤となる PySpark スクリプト、dbt 構成、3 つの宣言型 YAML パイプラインを生成しました。

生成された YAML パイプラインと、その視覚的な図を以下に示します。このパイプラインは、Orchestration Pipelines の機能を説明するために簡略化した例です。実際には、本番環境の MLOps の推奨設定は、具体的なユースケースや運用上のニーズによって異なります。

パイプライン 1: トレーニング エンジン

このパイプラインは、高負荷のコンピューティング エンジンとして機能します。エージェントは、まず BigQuery にクエリを実行して過去に完了した注文を抽出する YAML 定義を生成しました。その後、Managed Spark サーバーレス クラスタを動的にプロビジョニングして、地理的な距離を計算し、本番環境で使用するモデルをトレーニングします。最後に、トレーニング済みモデルを Gemini Enterprise Agent Platform Model Registry に push します。

パイプライン 2: 日次推論

日々の運用ワークフローでは、この軽量なパイプラインが、トレーニング済みのモデルを現在配送中のすべての注文に適用します。BigQuery ジョブを介してデータセットをクエリし、Gemini Enterprise Agent Platform を介して推論ジョブを実行し、結果を BigQuery テーブルに書き戻して、カスタマー サポート チームに SLA 違反の可能性を通知します。

パイプライン 3: 自動評価と分岐

日次評価パイプラインは、自動品質ゲートとして機能します。dbt モデルをトリガーして予測を実際の配送タイムスタンプと結合し、絶対誤差と SLA 違反を計算します。

パイプラインは、組み込みのロジックを使用して、これらの指標を自動的に評価します。モデルのエラー率が許容しきい値を超えた場合、条件に応じて「training-pipeline」がトリガーされ、新しいモデルが生成されます。

Managed Service for Apache Airflow への自動デプロイ

パイプライン ロジックの作成は、作業の半分にすぎません。本番環境に安全かつ確実にデプロイする段階で、データチームはこれまで貴重な時間を失ってきました。

Orchestration Pipelines を使用すると、標準的な CI / CD プラクティスを通じてデプロイが合理化されます。デプロイ スクリプトを手動で作成したり、複雑な環境境界を構成したりする必要はありません。Data Agent Kit が、ワークスペースに必要な継続的インテグレーション ワークフロー（GitHub Actions など）を自動的に生成します。

つまり、commit をクリックするだけで、フレームワークが Orchestration Pipelines Bundle をシームレスにパッケージ化し、Managed Airflow 環境に直接デプロイします。

これらの自動化されたワークフローを既存の CI / CD パイプラインに統合するための包括的なガイドについては、公式ガイド「Orchestration Pipelines のデプロイ」をご覧ください。

Day 2（2 日目からの）運用: モニタリングとエージェントによるトラブルシューティング

これらのパイプラインのメンテナンスは、構築と同じくらい直感的に行えます。Data Agent Kit は、オーケストレーション コントロール プレーンを IDE に直接組み込むことで、ブラウザタブを頻繁に切り替えることなく、Managed Airflow の実行をリアルタイムでモニタリングできるようにします。

インフラストラクチャやデータの問題は避けられません。たとえば、季節的なデータの急増により Managed Spark クラスタでメモリ不足の例外が発生したり、BigQuery の割り当ての上限に達したりすることがあります。これらの問題を解決するために、何千行もの未加工の実行ログを調べる必要はもうありません。

パイプラインが失敗した場合、Data Agent Kit はすぐに使えるエージェント型トラブルシューティングを提供します。IDE で [トラブルシューティング] ボタンをクリックするだけで、データ エンジニアリング エージェントが失敗のコンテキストを分析します。インフラストラクチャの割り当て上限とコードレベルのバグを正確に区別し、根本原因の概要を即座に提供して、インライン修正（コンピューティング テンプレートのスケールアップなど）を提案します。

まとめ: 価値創出までの時間を短縮

レジリエントな MLOps アーキテクチャの構築（過去のデータの抽出、dbt 変換の実行、Managed Spark ML コンピューティングのプロビジョニング、モデル レジストリと推論のための Gemini Enterprise Agent Platform のインテグレーション、DAG 間の条件付きトリガーの構成）には、従来、プラットフォーム エンジニアリング チームが複雑な Python Operator ロジックを記述するのに数週間かかっていました。

Orchestration Pipelines と Data Agent Kit を使用することで、このライフサイクル全体を数分で作成、デプロイ、簡単にメンテナンスできました。ボイラープレート インフラストラクチャ コードを、宣言型の、エージェント対応の標準に置き換えることで、データ組織がパイプラインのオーケストレーションに費やす時間を減らし、具体的なビジネス価値の創出に多くの時間を割けるようにしています。

使ってみる:

• Orchestration Pipelines のドキュメントを確認する。

• お好みの IDE または CLI に Data Agent Kit をインストールし、ワークスペースを構成する。

• エコシステム全体の詳細については、最近のブログ投稿「Data Agent Kit は IDE または CLI にデータ処理のスキルとツールを提供」を確認する。

• Data Agent Kit のドキュメントでリファレンス アーキテクチャを確認する。

- リード プロダクト マネージャー、Piotr Wieczorek

- ソフトウェア エンジニア、Alexandre Moueddene