目標
Roads Management Insights(RMI)ADK エージェントは、Google BigQuery に保存されている RMI データをクエリして分析するための自然言語インターフェースを提供します。Google の Agent Development Kit(ADK)と Gemini 大規模言語モデルを活用することで、複雑な SQL クエリを手動で作成することなく、大規模な道路ネットワークと交通データセットから実用的な分析情報を抽出できます。
リファレンス アーキテクチャ
このアーキテクチャは、ルート エージェントがユーザー インタラクションを計画してオーケストレートし、特定のデータ取得タスクと SQL 生成タスクを専門のサブエージェントに委任する階層型エージェント システムで構成されています。
コンポーネント
1. RMI エージェント(ルート エージェント)
- ロール: 主要な会話型インターフェースとタスク オーケストレーター。
- 責任:
- マルチターンの会話のコンテキストを維持する。
- 自然言語リクエストを実用的な分析タスクに分解する。
- 構造化データ取得タスクを BigQuery エージェントに委任する。
- サブエージェントから返された未加工の表形式データを、簡潔で人が読める形式の分析情報に統合する。
2. BigQuery エージェント(サブエージェント)
- ロール: 特殊な SQL 変換とデータベース実行エージェント。
- 責任:
- ルート エージェントからの自然言語の指示を、最適化された BigQuery SQL クエリに変換する。
- 構成された BigQuery データセットに対してクエリを直接実行する。
- 未加工のクエリ結果をルート エージェントに返す。
3. BigQuery データセット
- ロール: クラウドネイティブな分析データ ウェアハウス。
- コンテンツ: RMI BigQuery スキーマに従って構造化された、
historical_travel_timeやrecent_roads_dataなどの Roads Management Insights(RMI)テーブル。
4. Google GenAI
- ロール: 推論と言語生成のコアエンジン。
- モデル: Google Gemini モデル(
gemini-3.5-flashなど)を活用して、エージェントのオーケストレーション、自然言語の理解、SQL 生成を行います。
実行フロー
- ユーザー リクエスト: ユーザーが自然言語で質問を送信します(例: 「昨日の国道 66 号線の平均移動時間はどのくらいでしたか?」)。
- 計画とオーケストレーション: RMI エージェント がリクエストを受け取り、過去の交通データが必要であることを特定し、サブエージェントに具体的な取得手順を策定します。
- 委任: RMI エージェント が、 構造化された手順と関連する時間的制約または空間的制約を使用して BigQuery エージェント を呼び出します。
- SQL の生成: BigQuery エージェント は、RMI スキーマの理解に基づいて、最適化された BigQuery SQL クエリを生成します。
- 実行とデータの取得: BigQuery エージェント は、基盤となる BigQuery データセットに対してクエリを実行し、結果の表形式レコードを取得します。
- レスポンスの統合: BigQuery エージェント は、未加工の データを RMI エージェント に返します。RMI エージェント は、結果を解釈し、欠落している 道路 ID を解決して、ユーザー向けの明確な自然言語レスポンスを作成します。
例
課題
都市計画担当者は、大都市圏の道路ネットワーク全体の交通渋滞を評価して、夕方の通勤ラッシュ時に信号のタイミングを調整する必要があるかどうかを判断する必要があります。
ソリューションのワークフロー
ユーザー クエリ: 計画担当者は、CLI または ウェブ UI を使用してエージェントとやり取りし、次のように質問します。
「先週の金曜日の午後 5 時にボストン市内で最も渋滞したルートを上位 5 つ特定してください。」
エージェントの処理:
- RMI エージェント がリクエストを解析します。ターゲットの場所(「ボストン市内」)、時間枠(「先週の金曜日の午後 5 時」)、分析の目的(「最も渋滞したルートの上位 5 つ」)を特定します。「渋滞」は、リアルタイムの移動時間と静的な時間(
duration_in_seconds/static_duration_in_seconds) の比率として測定する必要があると判断します。 構造化された手順で、データ取得を BigQuery エージェント に委任します。
「ボストン市内の道路セグメントを検索し、2026 年 1 月 9 日(金)午後 5 時の渋滞率が最も高い上位 5 つを返してください。」
- RMI エージェント がリクエストを解析します。ターゲットの場所(「ボストン市内」)、時間枠(「先週の金曜日の午後 5 時」)、分析の目的(「最も渋滞したルートの上位 5 つ」)を特定します。「渋滞」は、リアルタイムの移動時間と静的な時間(
データの取得:
- BigQuery エージェント は、この手順を
historical_travel_timeテーブルを対象とする SQL クエリに変換し、渋滞率を計算して結果を並べ替え、上位 5 つのセグメントを特定します。 - BigQuery に対してクエリを実行します。
- BigQuery は、
(segment_id, display_name, duration_in_seconds, static_duration_in_seconds, congestion_ratio)などの未加工の表形式の結果を返します。
- BigQuery エージェント は、この手順を
分析情報の生成:
- BigQuery エージェント は、セグメントの未加工のリストを RMI エージェント に渡します。
- RMI エージェント は、レコードを分析し、表示名が欠落している道路セグメントや ID のみの参照を処理して、データをエグゼクティブ サマリーに統合します。
エージェントが最終的なレスポンスを作成します。
「2026 年 1 月 9 日(金)午後 5 時、ボストン市内で最も渋滞したルートでは、通常の静的な時間よりも移動時間が大幅に長くなりました。交通状況を考慮した時間と静的な時間の比率に基づく、最も渋滞したセグメントの上位 5 つは次のとおりです。ルート道路/CgkJZ-tTXuNcW4s: このセグメントは最も渋滞しており、移動時間は 66 秒でしたが、静的な時間はわずか 6 秒でした(渋滞率は 11.0 倍)。..」
まとめ
会話型インタラクションとナラティブ統合を低レベルの SQL 生成とデータ取得から切り離すことで、階層型 RMI ADK エージェントのアーキテクチャは、複雑な地理空間データ ウェアハウスとエンドユーザーの間のギャップを埋めます。 専門のサブエージェント内でデータベースの実行を分離することで、モジュール性、保守性、運用上の安全性が向上し、意思決定者は自然言語を通じて検証可能な分析情報を迅速に抽出できます。
次のステップ
- ユースケースに合わせてカスタマイズする: このマルチエージェント アーキテクチャと プロンプト設計を、特定の地理空間または組織のユースケースに合わせて調整します。
- 専門のプランナー エージェントで拡張する: 専用のプランナー エージェントを組み込んで、複雑なマルチステップ分析ワークフローをオーケストレートします。
- マルチモーダル データソースを統合する: RMI データと、気象 イベント、工事スケジュール、リアルタイムのインシデント フィードなどの追加の空間レイヤを組み合わせることで、交通状況と道路管理の 分析情報を強化します。
- 本番環境にデプロイする: Gemini Enterprise Agent Platformでホストされている ADK エージェントを登録して 管理するガイドに沿って、エージェントをプロトタイプから 本番環境のエンタープライズ環境に移行します。
寄稿者
Kel Markert | Cloud Geographer