マルチエージェントAI基盤をGCPで設計する方法

気候予測データを単一のダッシュボードに表示するだけでは、現場の意思決定者が動けない。こうした問題意識から生まれたのが「El Niño 2026 Decision Copilot」で、Google Cloud上に構築されたマルチエージェント型の意思決定支援基盤です。SREやインフラエンジニアの視点から見ると、このシステムが採用したアーキテクチャ上の判断は、汎用的な分散データ処理基盤の設計指針として読み解けます。

BigQueryを「単一の信頼源」に据える設計判断

外部APIへの直接問い合わせをすべてのコンポーネントが行う設計は、障害伝播やレート制限の影響を受けやすくなります。このシステムでは、Google Earth Engine、OpenWeatherMap、CWC（中央水資源委員会）のダムレポート、CGWB（中央地下水委員会）の地下水データなど、十数種の公開データセットを一度取り込んだうえで、BigQueryを唯一の読み取り元（Single Source of Truth）として確立しています。

この設計には明確なメリットがあります。ダウンストリームのAIエージェントが外部APIの障害を直接受けないため、依存サービスの可用性がシステム全体のSLOに直接影響しない構造になります。SLO（Service Level Objective、サービス品質目標値）の設計においても、外部依存を内部ストレージへの依存に変換することで、測定点を一箇所に集約できます。

たとえば、農業指標のAPIが一時的に応答不能になっても、BigQueryにキャッシュされた最新データを参照し続けられます。データの鮮度が多少落ちても意思決定を継続できる、という可用性と整合性のトレードオフを意図的に選んでいる点が重要です。

エージェント分割とべき等性の確保

このシステムはGoogle ADK（Agent Development Kit、エージェント構築用フレームワーク）を使い、責務ごとに三つのエージェントを分けています。優先度を判定するTriage Agent、資源配分を決定するAllocation Agent、農家向け勧告を生成するFarmer Advisory Agentです。

設計上、特筆すべきはAllocation Agentの扱いです。水タンクや緊急資金の配分ロジックはLLM（大規模言語モデル）の推論に委ねず、決定論的（deterministic）な計算として実装されています。決定論的とは、同じ入力に対して常に同じ結果が返ることを指します。LLMはサンプリングのランダム性があるため、監査やコンプライアンスが求められる資源配分には向かない場合があります。

この分割は、SRE観点での障害切り分けにも直結します。Triage AgentとFarmer Advisory AgentはLLMを呼び出しますが、Allocation Agentは独立した計算ロジックです。そのためLLM APIのレイテンシ上昇や障害が、資源配分の結果に波及しない構造を持ちます。オブザーバビリティ（可観測性、システム内部の状態を外部から計測できる性質）の設計においても、エージェントごとに異なるメトリクスを収集する分離がしやすくなります。

BigQuery MLと解釈可能性の選択

リスクスコアの算出にはBigQuery MLを採用しています。BigQuery MLとは、BigQuery内のSQLライクな構文でMLモデルを学習・推論できる仕組みです。ニューラルネットワークではなく解釈可能なモデルを意図的に選んだ点は、インフラ設計にも影響します。

ブラックボックスモデルを採用した場合、推論結果の根拠をトレースするために別途説明AI（XAI）レイヤーが必要になります。解釈可能モデルを選ぶことで、降水量の異常・NDVI（植生指数）・土壌水分などの特徴量の寄与が直接スコアに反映され、ログとして残せます。これはインシデント発生時の「なぜこのリスクスコアが出たか」の追跡を大幅に簡易化します。

IaC（Infrastructure as Code、インフラ構成をコードで管理する手法）でこの基盤を再現する場合、Terraformを使ったBigQueryデータセットとBigQuery MLモデルのプロビジョニングは以下のような構成になります。

resource "google_bigquery_dataset" "elnino" {
  dataset_id = "elnino_decision"
  location   = "asia-northeast1"
}

resource "google_bigquery_table" "district_risk" {
  dataset_id = google_bigquery_dataset.elnino.dataset_id
  table_id   = "district_risk_scores"
  deletion_protection = true
}

データセットのリージョンをasia-northeast1（東京）に指定することで、日本や南アジアのユーザーへのレイテンシを抑えつつ、データ主権の要件にも対応できます。

設計から持ち帰れるポイント

このシステムの構成を整理すると、複数外部APIを抱える基盤共通の設計指針が見えてきます。

外部依存を内部ストレージに変換してSLO測定点を集約する
LLMを使うコンポーネントと決定論的コンポーネントを明示的に分離する
解釈可能なモデルを選ぶことでオブザーバビリティコストを下げる
エージェントを機能単位で分割し障害の伝播範囲を制限する

コスト最適化の観点では、BigQuery MLはクエリベースの課金体系であるため、常時起動のMLサーバーを持たずに推論を実行できます。外部LLM APIの呼び出し回数を最小化し、ルーティング可能なタスクは決定論的処理に任せる設計は、クラウドコストの削減にも直接寄与します。

マルチエージェント基盤の安定運用は、個々のエージェントの品質だけでなく、データフローの設計と障害分離の構造によって決まります。気候危機対応というドメインは特殊に見えますが、採用されたアーキテクチャのパターンは、在庫管理や物流配分、インフラリソース割り当てなど、複数データソースを横断する意思決定システムに広く応用できます。