Google ADKで作るマルチエージェント・データ分析パイプライン入門｜Pythonで統計・可視化・レポートを自動化

Google ADKとは、Googleが提供するマルチエージェント型AIアプリ構築用のオープンソースフレームワーク。

データ分析の自動化を単一LLMで組もうとして、「出力が長くなるとプロンプトが破綻する」「ツール呼び出しと解釈が混ざって制御できない」といった壁にぶつかった経験はありませんか。読み込み・前処理・統計検定・可視化・レポート化までを1つのモデルに抱え込ませる構成は、最初は動いても、運用に乗せた瞬間に責務の境界が曖昧になり破綻しやすい。そこで注目されているのが、役割ごとに専門エージェントを分け、マスターが調整役になるADK（Agent Development Kit）の構成です。

本稿ではベースとなるチュートリアルを写経するのではなく、「なぜマルチエージェント化するのか」という観点から整理し、環境構築・ツール実装・統合・運用上の詰まりどころを三層で見ていきます。

Google ADKとマルチエージェント構成の意義

Google ADK（Agent Development Kit）はGoogleが公開するエージェント構築フレームワークで、公式ドキュメントGoogle ADK 公式ドキュメントではPython・TypeScript・Go・Javaの4言語に対応すると明記されています。単体エージェント（Agent）の定義から、SequentialAgentのような複数エージェントの直列実行、マスターが子エージェントを呼び出すハブアンドスポーク型まで、複数のパターンをネイティブに提供。中身は素のLLM呼び出しではなく、セッション管理・ツール呼び出し・状態共有といった「アプリ化に必要な配管」を標準で備えています。

ADKの基本構造と対応言語

ADKの最小単位はAgentクラスで、LLMモデル・プロンプト（instruction）・使えるツール（関数群）をセットにして定義します。今回のパイプラインではgoogle.adk.agentsのAgent、google.adk.models.lite_llmのLiteLlm、google.adk.sessionsのInMemorySessionService、google.adk.runnersのRunner、ツールのコンテキスト参照に使うgoogle.adk.tools.tool_contextのToolContextが中核。これらの組み合わせで、エージェントを走らせながら状態をセッションに保持し、ツール間で同じデータを参照できる仕組みが成立します。実装はGitHubリポジトリgoogle/adk-pythonで公開されており、Apache 2.0ライセンスで配布されています。

なぜ「マスター＋専門エージェント」構成にするのか

単一LLMに「CSVを読んでt検定して可視化してレポート書け」と頼むと、途中のどこかで引数の型を崩したり、生成文の途中でツール呼び出しを忘れたりしがち。これはLLMの一般的な弱点です。統計・検定・可視化は古典的アルゴリズムが強く、「生成と意味解釈」はLLMが強い。役割が違うのだから、同じエージェントに混ぜないのが素直な構成判断です。

一方で、エージェントを増やしすぎると推論回数が増え、応答遅延とコストが跳ね上がる副作用も。アンサンブル構成は推論時のオーバーヘッドが累積するため、マルチエージェント構成でも「分けすぎない」線引きが重要です。専門化は便利だが、分けすぎない線引きが肝心です。

エージェント設計パターンの比較

ADKが提供する主要な構成パターンを並べると、タスクの定型度と柔軟性のトレードオフが選択軸になります。

パイプライン全体像と環境構築

今回組み立てるパイプラインは、マスターアナリストエージェントを司令塔に、6つの専門ツールを呼び分ける構造。データロード → 探索（基本統計量・欠損・型確認）→ 統計検定（t検定・相関・カイ二乗など）→ 変換（欠損処理・スケーリング・集計）→ 可視化 → レポート生成、という流れで処理が進みます。各ツールは独立した関数として実装し、共通の中央データストア（セッション状態）を介してDataFrameや中間結果を受け渡す構造。

6つの専門ツールと中央データストア

中央データストアを1つに集約する理由は、ツールごとにDataFrameを引数で持ち回るとLLM側がJSON化を試みてサイズ超過やシリアライズ失敗を起こすため。ADKではToolContext経由でセッション状態（tool_context.state）にアクセスでき、ツール呼び出し時にはキーだけをやり取りし、実体はセッション側に置く方針が安定です。詳細はADK公式 Tools ガイドを参照。チュートリアル冒頭のmake_serializable関数のようなNumPy型→Python標準型の変換ヘルパーも、LLMに返す結果をJSON化可能にする安全弁として機能します。

必要ライブラリと動作環境

インストールは4行で完結。pip install google-adk、pip install litellm、pip install pandas numpy scipy matplotlib seaborn、pip install openpyxl の順で入れておきます。動作環境はADK 公式インストールガイドを参照してください。Google Colab 上での動作確認が手軽で、多くのチュートリアルも Colab 前提で書かれています。

APIキーはgetpass.getpass()で対話的に入力させ、os.environに格納する作法が一般的。コード中にハードコードしないこと、.envで管理する場合もGitに上げないこと、この2点は死守してください。

LiteLlmでプロバイダを切り替える利点

ADKはGoogle純正のGemini系モデルだけでなく、google.adk.models.lite_llmのLiteLlmラッパーを使うことでOpenAIやAnthropicなど多様なプロバイダに接続できます。LiteLLMは多数のLLMプロバイダを統一インターフェースで扱えるOSSライブラリで、対応プロバイダの一覧はLiteLLM 公式プロバイダドキュメントに列挙されています。例えばLiteLlm(model=”openai/gpt-4o-mini”)のように指定でき、プロバイダ名/モデル名のスラッシュ区切りが書式。分析用途では精度とコストのバランスから軽量モデルを使い、生成タスクで詰まるなら上位モデルにフォールバックさせる二段構えが現実的です。

主要モデルの特性比較

LiteLlm経由で使える主要モデルの傾向を整理します。料金や上限値は変動するため、本番採用前にOpenAI API PricingとAnthropic API Pricingの最新公式ページで再確認してください。

専門ツールを定義する

専門ツールは、Pythonの関数にデコレータや型ヒントを付けてAgentのtools引数に渡す形が基本。関数のdocstringがLLMへのツール説明になるため、「このツールは何を受け取り、何を返し、いつ呼ぶべきか」を明確に書いておくとマスター側のオーケストレーション精度が上がります。

データロード・探索ツール

ロードツールはCSV・Excel・JSONを受け付け、pandasで読み込んだDataFrameを中央データストアに格納し、キー（dataset_id）と基本情報（行数・列数・列名・型）を返す形。探索ツールは格納済みのdataset_idを受け取り、df.describe()・欠損値集計・ユニーク値カウント・相関行列などを走らせます。pandasのIO仕様や統計関数の挙動はpandas 公式ドキュメントを参照。ここでNumPy由来の型（np.int64等）をそのまま返すとJSONシリアライズで詰まるため、冒頭で定義したmake_serializableで変換してから返却するのが定石です。

統計検定と変換ツール（scipy活用）

統計検定ツールはscipy.statsのttest_ind（2群のt検定）、pearsonr（ピアソン相関）、chi2_contingency（カイ二乗独立性検定）などを内部で呼び出す。各関数の引数・戻り値の正確な仕様はSciPy stats モジュール公式リファレンスを参照。引数は検定タイプと対象列名にして、LLM側に「この検定を使って」と指示されたら該当関数にディスパッチする形。戻り値は統計量・p値・自由度・効果量、そしてp値に応じた定性評価（「有意差あり/なし」）を含めておくと、後段のレポート生成が書きやすくなります。

変換ツールは欠損値処理（平均埋め・中央値埋め・削除）、スケーリング（標準化・正規化）、集計（groupby→agg）などを提供。変換後のDataFrameは元データを上書きせず、新しいキーで中央データストアに保存し、マスターが「元データと変換後を比較してレポート」のような依頼を受けても両方参照できるようにしておくのが実務的です。

可視化・レポート生成ツール

可視化ツールはmatplotlib・seabornで描画し、plt.savefigでPNG出力するか、io.BytesIOにバイナリ保存してbase64エンコードで返却する2パターンが主流。Colab環境なら前者、APIとして提供する場合は後者が便利です。seabornのsns.set_palette(“husl”)のようなスタイル指定はツール定義の冒頭で一度だけ行い、ツール呼び出しごとに変えないのが見栄えを保つコツ。

レポート生成ツールはここまでの解析結果（探索結果・検定結果・変換サマリ・可視化パス）をセッション状態から集め、Markdown形式でまとめる役。ここはLLMが最も得意な「構造化された文章生成」領域なので、素直にマスターエージェント経由で書かせて問題ありません。

マスターエージェントで全体を統合する

マスターアナリストエージェントは、上記6ツールをすべてtoolsに登録したAgentインスタンスとして定義します。instruction（プロンプト）には「あなたはシニアデータアナリストです。ユーザーの依頼を受けたら、必要なツールを順番に呼び出し、最終的にMarkdownレポートを返してください」といった役割定義に加え、「先に探索ツールで全体像を掴んでから検定する」「可視化は検定結果を裏付ける目的で選ぶ」といった手順の指針を具体的に書き込むのが効きます。

ADK is a flexible and modular framework for developing and deploying AI agents.（ADKはAIエージェントの開発とデプロイのための柔軟でモジュラーなフレームワーク）— Google ADK 公式トップページ

Runnerで非同期実行する流れ

エージェント実行はInMemorySessionServiceでセッションを作成し、Runnerにエージェント・アプリ名・セッションサービスを渡してインスタンス化、runner.run_asyncでユーザーメッセージを投げて非同期イテレータで結果を受け取る流れ。types.Contentとtypes.Partでユーザーメッセージを構造化して渡す書式はGemini互換のため、LiteLlm経由でOpenAI系モデルを使う場合もこの形式で統一されます。詳細はADK Runtime ガイドを参照。

非同期イテレータから流れてくるイベントには、モデルの思考・ツール呼び出し・ツール結果・最終応答が混在。実運用ではイベントタイプでフィルタして「最終応答だけ表示」「ツール呼び出しログだけ保存」のように使い分けることになります。

SequentialAgentとの使い分け

ADKにはSequentialAgentという「固定順でエージェントを直列実行する」ビルトインもあり、今回のように「順番が毎回変わる」ケースではマスターエージェント型が適していますが、「必ずロード→探索→検定→レポート」のように手順が固定ならSequentialAgentのほうが挙動が予測可能でデバッグしやすい。柔軟性が必要な探索的分析はマスター型、定型レポートはSequentialAgent型、と使い分けるのが素直な判断軸です。

つまずきやすいポイントと対処法

ここからは元記事では触れられていない、実装時に詰まりがちな箇所を整理。別のソースで示唆された「アンサンブルは重い」「本番デプロイで詰まる」という教訓も踏まえて対処法を並べます。

症状①: ツール間でデータが受け渡せない

最も頻出するのが、前のツールで処理したDataFrameが次のツールで見つからないパターン。原因の多くは、DataFrameを戻り値でそのままLLMに返そうとしてトークン制限に引っかかったか、別のセッションで実行されてstateが分離していること。対処は以下の順で確認してみてください。

1. ツール関数の引数にtool_context: ToolContextを入れているか確認する
2. データ本体はtool_context.state[“dataset_id”] = dfのように保存し、戻り値にはdataset_id文字列と要約情報のみを返す
3. セッションIDを固定し、Runnerを使い回しているか確認する
4. make_serializable相当の変換を通してから戻り値をLLMに返す

この4点を押さえれば、受け渡し起因のエラーはほぼ解消します。

症状②: 応答が遅い・API課金が想定以上

エージェントが増えるほどLLM呼び出しが重なり、応答時間とコストが線形以上で伸びる現象。別のソースの知識蒸留の事例が示す通り、「精度のためにモデルを足す」と運用が苦しくなる構造は、マルチエージェント設計でも同じです。対処としては、まず軽量モデル（gpt-4o-mini等）でオーケストレーションを回し、重い推論が必要な箇所だけ上位モデルにフォールバックする二段構え。次に、ツール呼び出しの並列化（asyncio.gatherで独立タスクを束ねる）。そして、統計計算など決定的な処理はLLMではなくpandas/scipyに完全委譲し、LLMは「呼び出すツールの選択と結果の要約」だけに絞る。この3点で、応答時間を目に見えて縮められます。

症状③: ローカルから本番環境への移行で詰まる

Colabでは動いたのに、VPSやクラウドに持っていくと起動しないケース。別のソースのMLモデルVPSデプロイ記事が指摘する通り、「作った後のデプロイ段階で詰まる」のはML全般の通病です。ADK特有の落とし穴としては、InMemorySessionServiceはプロセス再起動で状態が消えるため、本番ではRedisやFirestoreなどの永続ストアに差し替える必要があること。ADKのデプロイガイドはADK Deploy ドキュメントで本番化の選択肢が示されています。また、非同期実行の都合でFastAPIやLitestar等の非同期Webフレームワークでラップするのが素直。APIキーは環境変数や秘密管理サービス経由に切り替え、Colabで書いたgetpassロジックはそのまま持ち込まないのが鉄則です。

症状別の対処マップ

頻出する詰まりどころを症状・原因・対処の対応表にまとめます。実装時の自己診断に使ってください。

よくある質問

Q. Google ADKは無料で使えますか？

ADK本体はオープンソースで無料で利用可能です。ただし、内部で呼び出すLLM（Gemini、OpenAIのGPT-4o-mini等）のAPI利用料は各プロバイダの従量課金が発生します。分析タスクでは入出力トークン次第で月数ドル〜数十ドルが目安。

Q. LiteLlm経由でOpenAI以外のモデルも使えますか？

はい。LiteLlmはAnthropicのClaude、Google Gemini、ローカルのOllama等、主要プロバイダを横断的にサポートしています。モデル名をanthropic/claude-3-5-sonnetのようにプロバイダ名付きで指定するだけで切り替え可能。プロバイダ固有のAPIキーを環境変数にセットするのを忘れずに。

Q. SequentialAgentとマスター＋ツール構成はどう使い分けますか？

処理手順が固定で毎回同じ順に走らせたい場合はSequentialAgentが予測可能で安全。対して、ユーザーの依頼によって呼ぶツールや順番が変わる探索的分析では、マスターエージェントにツール選択を委ねる構成が柔軟です。定型レポートは前者、インタラクティブ分析は後者という線引きが分かりやすい。

Q. 商用サービスに組み込んでも問題ありませんか？

ADKはオープンソースライセンスで公開されており、商用利用は可能です。ただしLLM側の利用規約（OpenAIの商用制限やデータ学習ポリシー等）は別途確認が必要。医療・金融など規制業界で使う場合は、データ送信先と保持ポリシーを各プロバイダで必ず精査してください。

Q. 既存のLangChain資産から移行するメリットは？

LangChainがチェーン中心の抽象なのに対し、ADKはマルチエージェント・セッション管理・ツール状態共有が一体になった構造。複雑なエージェント間連携を組むほどADKの恩恵が出やすい。逆に単純なRAGや短い変換ならLangChain系の既存資産を流用する方が早い場面もあるので、用途で選び分けるのが現実的です。

Q. ADKでのテストや評価はどう書きますか？

ADKには評価用ユーティリティが用意されており、入力に対する期待出力をJSONLで定義してバッチ評価する流れが標準。ツール単体はpytestで通常の関数テストとして書き、エージェント全体は評価セットでリグレッションを抑える二段構えが現実的です。詳細は公式の評価ドキュメントを参照してください。

まとめ

Google ADKを使うと、データ分析という「古典的アルゴリズムとLLMの生成能力が混在する」タスクを、役割分担の明確なマルチエージェント構成に落とし込めます。設計の肝は3つ。専門ツールで責務を分離すること、中央データストアを通じて状態を共有すること、マスターエージェントにはオーケストレーションだけを任せること。ここさえ守れば、ベース記事のチュートリアルを自分のデータに置き換えて拡張していく道筋が見えてきます。

次の一歩は、手元のCSVで最小構成（ロード＋探索＋レポート）を走らせて、動作感を掴むこと。そこから検定・可視化・変換を足していき、応答が重くなったら軽量モデルへの切り替えやツールの統合を検討する。本番化を視野に入れるなら、InMemorySessionServiceを永続ストアに差し替え、FastAPIでAPI化する流れが現実的な落としどころです。

本記事は AIツール図鑑編集部 が記載時点の情報をもとに執筆。製品アップデートや第三者ベンチマーク・価格・対応ランタイム等の変動で評価が変わる可能性がある。一定期間経過した内容は再検証を推奨する。