データ分析

Google Dataflow で費用対効果に優れた高スループットな生成 AI ワークフローを構築する

2026年8月27日

Reza Rokni

Group Product Manager

Danny McCormick

Software Engineer, Google Cloud

Try Gemini Enterprise today

The front door to AI in the workplace

Try now

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

リアルタイムストリーミングパイプラインは現代の企業において運用のバックボーンとなっており、カスタマーサポートでのやり取りからトランザクションログまで、あらゆるデータを処理し続けています。従来のストリーミング DAG は静的なものであり、一度デプロイされると、その処理ロジックや実行パスは変更できなくなります。しかし、生成 AI エージェントを統合すれば、静的なロジックから適応型の実行へと移行することが可能です。これにより、データの内容に応じてストリーミングワークフローが実行時にプランを動的に立案し、データベースへのクエリや独自の修復処理を自律的に開始できるようになります。

たとえば、注文品の破損について顧客から不満を示すメッセージが届いた際、パイプラインの役割は単なるエラーログの記録や、ダッシュボードへのフラグ立てにとどまるべきではありません。顧客の注文と在庫の記録を保持するデータベースで注文情報を検索し、修復アクション（交換品の発送や払い戻しなど）を自ら判断して、顧客へのメール送信から最終的な対応結果の記録までを一貫して行うべきです。

しかし、生成 AI ワークフローをストリーミングシステムに実行しようとすると、スケール、レイテンシ、コストという、エンジニアリング上の根本的な障壁に直面することになります。すべての未加工イベントを、外部データベースとメールツールを備えた高負荷なモデルやマルチステップエージェントに直接送信すると、コストが跳ね上がり、レイテンシも増大します。また、API のレート制限もすぐに使い果たしてしまいます。

ここで紹介するパターンは、Google Dataflow（Google Cloud が提供する Apache Beam のフルマネージドサーバーレス実行サービス）と Agent Development Kit（ADK）を組み合わせてハイブリッドストリーミングパイプラインを構築することで、スケーラビリティと複雑さという課題に対処します。軽量で CPU バウンドな ML モデルをアップストリームで使用してイベントをフィルタリングし、評価することで、パイプラインの費用対効果を高く保ち、複雑なケースのみをダウンストリームエージェントにルーティングします。ケースを受け取ったエージェントは、実行するアクションを動的に決定し、パイプラインの静的 DAG に膨大な数の条件付きステップをハードコードすることなく、ストリームに動的分岐を導入します。

大規模ストリーム向けのユニバーサルなブループリント

以下ではカスタマーサポートにおけるトリアージのシナリオを例にしていますが、この「事前フィルタ + エージェントによるアクション」というパターンは、幅広い分野に適用できる普遍的モデルです。このパターンは、イベントの大多数（90% 超）が定型的であり、複雑なコンテキスト推論を必要とするイベントはごくわずかである、以下のようなストリームに適用できます。

IT 運用と DevOps: 数百万件の定型的なシステムログを CPU 上でフィルタリングし、重大な異常が検知された場合にのみエージェントをトリガーして診断を実行し、バグチケットを開く。
金融詐欺のトリアージ: 数百万件のトランザクションを軽量なローカルルールでスクリーニングし、疑わしいパターンが検出された場合にのみエージェントを呼び出してマルチデータベース検索ツールを実行する。
産業用 IoT: エッジで定常的なテレメトリーをモニタリングし、突発的な異常をエージェントにルーティングして、機器のシャットダウンやフィールドエンジニアへの通知など一連の対応を調整する。

アーキテクチャ: ストリーミングイベントを事前にフィルタする理由

高スループットなストリームの場合、メッセージの大部分は複雑な推論や修復を必要としません。その多くは、肯定的なフィードバック、中立的な問い合わせ、単純な質問などです。

すべてのイベントを高負荷な LLM ワークフローにルーティングすると、主に 3 つのボトルネックが発生します。

API のコスト: フロンティアモデルはトークン単位で課金されます。高スループットの場合、コストはストリームのボリュームに比例して増加します。
レイテンシ: データベース参照や外部 API 呼び出しを含むマルチステップワークフローには数秒かかるため、ストリーミング DAG のボトルネックになります。
割り当て: 外部 API には厳格なレート制限があり、ストリーミングワーカーがその枠をすぐに使い切ってしまうおそれがあります。

これを防ぐため、Apache Beam と Dataflow を使用して、事前フィルタリングされたパイプラインを構築します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/image1_XYX8VCT.max-1100x1100.jpg

パイプラインフロー

取り込み: Google Pub/Sub から未加工の顧客メッセージを読み取ります。
軽量の感情分類器（CPU）: Apache Beam の RunInference 変換を使用して、軽量の CPU ベースの Hugging Face モデル（distilbert-base-uncased-finetuned-sst-2-english）ですべてのメッセージを処理します。これは Dataflow ワーカーの CPU でローカルに実行されるため、外部 API の費用は発生しません。
事前審査ゲート: シンプルな DoFn でストリームをフィルタします。感情が POSITIVE または NEUTRAL と判定されたメッセージは、確認応答を返したうえで破棄されます。
自動修復（ADK）: メッセージが NEGATIVE に分類された場合にのみ、ADKAgentModelHandler を介して gemini-3.5-flash を基盤とする生成 AI エージェントをトリガーします。エージェントは各種ツールを活用して、BigQuery でのユーザー検索、注文情報の取得、対応策の選定、Gmail API を介した通知メールの送信までを自律的に実行します。

適応的実行: Beam DAG の動的な構成

従来のストリーミングアーキテクチャでは、パイプラインの有向非巡回グラフ（DAG）は固定されています。Dataflow にデプロイされると変換のシーケンスが固定されるため、新しいタイプのアラートを処理したり、特定のイベントのルーティング方法を変更したりする必要が生じた場合はパイプライン全体を変更、テスト、再デプロイする必要があります。

感情の事前フィルタのダウンストリームに生成 AI エージェントを配置することで、静的な DAG 内に動的で適応性のあるノードを導入できます。

全レコードの 95% を占める肯定的または中立的なデータは、パイプライン上の高速な静的パスに沿って処理されます。しかし、フィルタがネガティブなレコードを検知すると、エージェントはペイロードを評価し、実行時に API ツールの適切な実行順序（データベースへのクエリ、在庫確認、メール通知など）を動的に選択します。これにより、パイプラインで複雑な決定木を動的に実行できるようになり、静的な Apache Beam コードに膨大な数の条件分岐をハードコードして構築、保守し続けるといった煩雑な作業が不要になります。

パイプラインの実装

Google Agent Development Kit（ADK）と RunInference フレームワークを活用した Apache Beam での実装例を以下に示します。

1. 軽量な感情モデルの定義

HuggingFacePipelineModelHandler を使用して、アップストリームの CPU モデルを定義します。このモデルは、ワーカーインスタンス上で感情を POSITIVE、NEUTRAL、NEGATIVE に分類します。

読み込んでいます...

2. 高負荷な ADK エージェントの構築

ADK エージェントは修復アシスタントとして機能します。このエージェントに、次の 3 つのツールを実装します。

lookup_user: BigQuery に顧客のメールアドレスをクエリします。
lookup_orders: BigQuery に顧客の注文と現在の商品在庫をクエリします。
send_email: Gmail API を使用して対応メールを顧客に送信します。

読み込んでいます...

def make_adk_tools(project: str, dataset: str = "sentiment_demo"):
    def lookup_user(user_id: int) -> dict:
        """Look up user information (email address) from BigQuery by user ID."""
        from google.cloud import bigquery

client = bigquery.Client(project=project)
        query = (
            f"SELECT user_id, user_email "
            f"FROM `{project}.{dataset}.users` "
            f"WHERE user_id = @user_id"
        )
        job_config = bigquery.QueryJobConfig(
            query_parameters=[bigquery.ScalarQueryParameter("user_id", "INT64", user_id)]
        )
        try:
            results = list(client.query(query, job_config=job_config).result())
            if results:
                row = results[0]
                return {"user_id": row.user_id, "user_email": row.user_email}
            return {"error": f"No user found with user_id={user_id}"}
        except Exception as exc:
            return {"error": str(exc)}

def lookup_orders(user_id: int) -> dict:
        """Look up a user's orders and current product inventory from BigQuery."""
        from google.cloud import bigquery

client = bigquery.Client(project=project)
        query = (
            f"SELECT p.order_id, p.product_id, pr.remaining_inventory, pr.price "
            f"FROM `{project}.{dataset}.purchases` p "
            f"JOIN `{project}.{dataset}.products` pr ON p.product_id = pr.product_id "
            f"WHERE p.user_id = @user_id"
        )
        job_config = bigquery.QueryJobConfig(
            query_parameters=[bigquery.ScalarQueryParameter("user_id", "INT64", user_id)]
        )
        try:
            results = list(client.query(query, job_config=job_config).result())
            orders = [
                {
                    "order_id": row.order_id,
                    "product_id": row.product_id,
                    "remaining_inventory": row.remaining_inventory,
                    "price": float(row.price),
                }
                for row in results
            ]
            return {"orders": orders}
        except Exception as exc:
            return {"error": str(exc)}

def send_email(to_address: str, subject: str, body: str) -> str:
        """Send a plain-text email to the customer via the Gmail API."""
        import google.auth
        import googleapiclient.discovery
        import email.mime.text
        import base64

try:
            creds, _ = google.auth.default(
                scopes=["https://www.googleapis.com/auth/gmail.send"]
            )
            service = googleapiclient.discovery.build("gmail", "v1", credentials=creds)

mime_msg = email.mime.text.MIMEText(body)
            mime_msg["to"] = to_address
            mime_msg["subject"] = subject
            raw = base64.urlsafe_b64encode(mime_msg.as_bytes()).decode("utf-8")
            service.users().messages().send(userId="me", body={"raw": raw}).execute()
            return "Email sent successfully"
        except Exception as exc:
            return f"Failed to send email: {exc}"

return [lookup_user, lookup_orders, send_email]

LlmAgent を構成し、ADKAgentModelHandler に組み込みます。

読み込んでいます...

3. Dataflow DAG の組み立て

パイプライン全体を明確に定義します。アップストリームの感情推論の結果はフィルタリングステップ（FilterNegativeADK）に直接渡され、フィルタリングステップはダウンストリームの ADKInference を条件付きで実行します。

読み込んでいます...

コストとパフォーマンスのメリット

このフィルタリングステップを導入すると、エンジニアリング面と運用面の両方で大きなメリットがあります。

1. 大幅なコスト削減

すべての受信イベントに対して料金を支払うのではなく、顧客のネガティブな感情が含まれる一部のメッセージ（通常は 5% 未満）に対してのみ Gemini の入出力トークンの料金を支払うだけで済みます。残りの 95% は CPU インスタンスでローカルに分類されるため、API の追加費用はかかりません。

2. 高いストリーミングスループット

Dataflow は、CPU による分類ワークロードを多数のインスタンスに分散して処理します。CPU 推論はミリ秒単位で完了するため、パイプラインを水平方向にスケールして高スループットのイベントストリームを処理できます。ツール実行のためにリクエストごとに数秒を要する高負荷な LLM エージェントは、呼び出し回数を最小限に抑えることで、バックログの発生を防いでいます。

3. ネイティブな Apache Beam 統合

DAG にエージェントを追加するのに、複雑なオーケストレーションロジックや手動のスレッドプールは一切必要ありません。ADKAgentModelHandler を Beam ネイティブの RunInference 変換と併用することで、並列ワーカースレッド、バッチ処理、統合の処理が自動化され、コードベースをクリーンでメンテナンスしやすい状態に保てます。