Google ADK入門2026｜AIエージェント開発の始め方

結論から言えば、Google ADK（Agent Development Kit）は2026年時点でAIエージェント開発の最も手堅い選択肢のひとつだ。Python・Java・Go・TypeScript・Kotlinの5言語に対応し、Geminiモデルとの統合はもちろん、MCP（Model Context Protocol）経由で外部ツールにもつながる。Apache 2.0ライセンスで無料。

ADKを実際に触ってみると、adk createでプロジェクトを生成し、adk webでブラウザUIが立ち上がるまで5分かからない。LangGraphやOpenAI Agents SDKと比べて「Google Cloudにそのまま乗せられる」点が決定的な違いになる。エージェント開発フレームワークの選定で迷っている人に向けて、導入から本番デプロイまで一気に書く。

Google ADKとは — 100行でエージェントが動く仕組み

Google ADK（Agent Development Kit）は、Googleが2025年4月にオープンソースとして公開したAIエージェント開発フレームワーク。GitHubスターは公開から1年で2万を超えた。

設計思想は「コードファースト」。YAMLやGUIで設定ファイルをいじるのではなく、Pythonコードで直接エージェントの振る舞いを書く。触ってみると、LangChainのようなChain概念を覚える必要がなく、関数を定義してAgentに渡すだけで動く。Geminiモデルに最適化されているが、LiteLLM経由でClaude・GPT・Mistralなど他社モデルも動作する。ベンダーロックインはない。

なぜ今ADKを選ぶのか

AIエージェントフレームワークは2026年に入って飽和状態にある。LangGraph、OpenAI Agents SDK、Microsoft Agent Frameworkと選択肢が増えるなかで、ADKを選ぶ理由は3つに集約できる。

対応言語と動作環境

Pythonが圧倒的に成熟しているのは事実だが、Java 1.0とGo 1.0が2026年3月に同時リリースされたことで、エンタープライズ案件の選択肢が広がった。SIer出身の立場で言えば、「Javaで書けるAIエージェントフレームワーク」は稟議を通すときのハードルが一段低くなる。

ADKの3つのコア概念 — Agent・Session・Runner

ADKの設計は3つのコア概念に集約される。フレームワークの名前は異なっても、エージェント開発の構造はどれも「何ができるエージェントを（Agent）」「どの文脈で（Session）」「どう実行するか（Runner）」に帰結する。ADKはこの3層を明示的にクラスとして切り出している。

Agent — エージェントの定義

Agentクラスがエージェントの振る舞いを決める。名前、使用するLLMモデル、指示文（instruction）、利用可能なツール、そしてサブエージェントへの委譲ルールをPythonコードで定義する。

from google.adk.agents import Agent

weather_agent = Agent(
    name="weather_agent",
    model="gemini-2.0-flash",
    instruction="あなたは天気情報を提供するエージェントです。"
                "ユーザーの質問に対して正確な天気情報を返してください。",
    tools=[get_weather],
)

instructionの書き方がエージェントの品質を左右する。プロンプトエンジニアリングのスキルがそのまま活きる場面だ。

Session — 会話の文脈を保持する

Sessionは対話の状態を管理するコンテナ。ユーザーとエージェントのやりとり履歴、途中で記録した変数（State）を保持する。1つのSessionが1つの「会話スレッド」に対応すると考えればよい。

InMemorySessionServiceを使えばメモリ上で管理でき、本番ではDatabaseSessionServiceやVertexSessionServiceに切り替えるだけでスケールする。開発時と本番の差分が小さい設計。

Runner — 実行エンジン

Runnerがエージェントの実行を制御する。ユーザーの入力を受け取り、Agentに渡し、ツール呼び出しの結果をまとめ、最終的なレスポンスを返す。非同期実行にも対応している。

from google.adk.runners import Runner
from google.adk.sessions import InMemorySessionService

session_service = InMemorySessionService()
runner = Runner(
    agent=weather_agent,
    app_name="weather_app",
    session_service=session_service,
)

# 非同期で実行
async for event in runner.run_async(
    user_id="user_1",
    session_id="session_1",
    new_message="東京の天気を教えて",
):
    print(event)

3つの概念を頭に入れたら、実際に動かして確かめる方が早い。

インストールと最初のエージェント作成

Google ADKの使い方を手を動かして確認する。Python環境での導入手順を書く。Java・Goでも基本構造は同じだが、ドキュメントの充実度を考えるとPythonから始めるのが現実的だ。

環境セットアップ

前提条件はPython 3.10以上。3.11以上を推奨する理由は、asyncioの改善とエラーメッセージの明瞭化による開発体験の向上。

# 仮想環境を作成
python3 -m venv adk-env
source adk-env/bin/activate

# ADKをインストール
pip install google-adk

# バージョン確認
adk version

Gemini APIを使うため、Google AI StudioからAPIキーを取得する。無料枠で十分検証できる。

adk createでプロジェクト生成

CLIコマンド1つでプロジェクトの雛形が出来上がる。

# プロジェクト生成
adk create my_agent

# 生成されるファイル構成
my_agent/
├── __init__.py
├── agent.py      # エージェント定義
└── .env          # APIキー設定

.envにAPIキーを設定する。

# .env
GOOGLE_GENAI_USE_VERTEXAI=FALSE
GOOGLE_API_KEY=your-api-key-here

adk webでブラウザUIを起動

adk webを叩くとhttp://localhost:8000でトレース画面が開く。LangSmithを別途セットアップする手間が丸ごと不要だった。

# CLI で対話テスト
adk run my_agent/

# ブラウザUIで対話テスト（推奨）
adk web my_agent/
# http://localhost:8000 で開く

Web UIではエージェントの応答履歴、ツール呼び出しのログ、セッション状態がリアルタイムで確認できる。LangSmithのようなトレーシングツールを別途入れなくても、開発初期の動作確認はこれで済む。

ツール定義とMCP連携

エージェントに価値が出るのは、外部に手が届くときだ。天気API、DB検索、ファイル操作。Google ADKはこれらを「ツール」としてPython関数で定義する。型ヒントとdocstringがLLMへの説明文を兼ねる設計で、余計なラッパーを書かずに済む。

カスタムツールの定義

最もシンプルなのはPython関数をそのままツールにする方法。関数のdocstringがLLMへの説明文になるため、書き方が重要になる。

def get_weather(city: str) -> dict:
    """指定された都市の天気を取得する。

    Args:
        city: 天気を調べたい都市名（例: 東京、大阪）
    Returns:
        天気情報を含む辞書
    """
    # 実際にはAPIを呼ぶ
    return {"city": city, "temp": "22°C", "condition": "晴れ"}

関数の型ヒントとdocstringからLLMが「いつ・どんな引数で呼ぶべきか」を判断する。型ヒントを省略すると呼び出し精度が落ちるので、省略しないこと。

McpToolsetでMCPサーバーに接続

MCPサーバーは2026年5月時点で14,000以上がレジストリに公開されている。ADKのMcpToolsetクラスを使えば、これらのサーバーが提供するツールをそのままエージェントに渡せる。

from google.adk.tools.mcp_tool import McpToolset, StdioServerParameters

# MCPサーバーからツールを取得
tools, cleanup = await McpToolset.from_server(
    connection_params=StdioServerParameters(
        command="npx",
        args=["-y", "@modelcontextprotocol/server-filesystem", "/tmp"],
    )
)

# エージェントにツールを渡す
file_agent = Agent(
    name="file_agent",
    model="gemini-2.0-flash",
    instruction="ファイル操作を行うエージェントです。",
    tools=tools,
)

Google Cloudでは50以上のマネージドMCPサーバーが公開されており、Cloud IAMと統合された認証・認可で安全にアクセスできる。AWS MCP Serverなど他クラウドのサーバーも同じ仕組みで接続可能だ。

組み込みツール — Google検索とコード実行

Google ADKにはすぐ使える組み込みツールが付属する。google_searchはGeminiのGrounding機能でWeb検索を行い、code_executionはサンドボックス内でPythonコードを実行する。

データ分析エージェントを作るなら、この2つだけで「検索→データ取得→コードで処理→結果を返す」パイプラインが組める。筆者が検証した限り、自前でツールを書く前に組み込みを確認するだけで開発時間が半分に縮まった。車輪の再発明をしない。

マルチエージェント構成の実践

単体のエージェントで完結する業務は限られる。実際の業務フローでは「調査→分析→報告」のように複数のステップがあり、それぞれに専門性の異なるエージェントを割り当てたい。Google ADKはマルチエージェント構成をフレームワーク本体に組み込んでいる。

階層型エージェント — 親子関係で委譲

最も直感的なのが親エージェントが子エージェントにタスクを振るパターン。sub_agentsパラメータに子を渡すだけで構成できる。

research_agent = Agent(
    name="researcher",
    model="gemini-2.0-flash",
    instruction="与えられたテーマについて調査し要約する。",
    tools=[google_search],
)

writer_agent = Agent(
    name="writer",
    model="gemini-2.0-flash",
    instruction="調査結果を元にレポートを作成する。",
)

# 親エージェント
manager = Agent(
    name="manager",
    model="gemini-2.0-flash",
    instruction="ユーザーの依頼を分析し、"
                "調査はresearcherに、執筆はwriterに委譲する。",
    sub_agents=[research_agent, writer_agent],
)

親エージェントのinstructionに「誰にどのタスクを渡すか」を明記するのがポイント。曖昧な指示を書くとLLMが判断に迷い、不要な往復が増える。

ワークフローエージェント — 決定論的な制御

LLMの判断に頼らず、実行順序を固定したい場面も多い。ADKはSequentialAgent（直列実行）とParallelAgent（並列実行）を提供する。

LoopAgentはドキュメントの奥に埋まっているが、品質チェック→修正→再チェックのループをLLM判断なしで回せる。条件分岐エージェントを作るなら先にここを見るべきだ。

他フレームワークとの比較

フレームワーク選定は「どれが一番いいか」ではなく「自分のスタックに合うか」で決まる。自分ならGoogle Cloudを主に使うチームにはADK、Pythonでの柔軟性を最優先するならLangGraph、OpenAI APIに投資済みならAgents SDKを選ぶ。

LangGraph v1.2はグラフベースの設計で柔軟性が高いが、その分「ノードとエッジ」の概念を理解するまでの学習コストが重い。ADKは「親子関係でエージェントを組む」という直感的なモデルで、初見の開発者でも構造を把握しやすい。

OpenAI Agents SDKはシンプルさでは最強だが、OpenAIモデルへの依存度が高い。Microsoft Agent Frameworkは.NETエコシステムとの親和性が強み。2026年5月時点で迷ったらPythonでADKから入れ。LangGraphは複雑な状態遷移が必要になった段階で検討すればいい。

Google Cloudへのデプロイ

ローカルで動いたエージェントを本番に出す。ここがADK最大の強みになる。Cloud Runへのデプロイなら、追加のインフラ設計なしで本番環境が手に入る。

Cloud Runへのデプロイ手順

Cloud Runはコンテナベースのサーバーレス実行環境。ADKエージェントをDockerコンテナに入れてデプロイする。

# Dockerfileの作成
FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "-m", "google.adk.cli", "api_server", \
     "--port", "8080", "--agent_dir", "/app/my_agent"]

# Cloud Runにデプロイ
gcloud run deploy my-agent-service \
  --source . \
  --region asia-northeast1 \
  --allow-unauthenticated

東京リージョン（asia-northeast1）を指定すれば、日本国内からのレイテンシは50ms以下に収まる。--allow-unauthenticatedは検証用の設定で、本番では必ずCloud IAMで認証をかけること。認証なしで公開して外部からLLM呼び出しを叩かれると、API料金が青天井になる。

Agent Engine — マネージドなエージェントホスティング

Vertex AI Agent Engine（旧Agent Builder）を使えば、コンテナ管理すら不要になる。ADKエージェントをそのまま登録するだけで、スケーリング、モニタリング、ログ管理をGoogleが面倒を見る。

代償はコスト。Agent Engineの従量課金は1,000クエリあたり約12ドルで、Cloud Runの実質無料枠と比べると差が大きい。検証段階ではAgent Engineの手軽さを取り、トラフィックが安定したらCloud Runに移すのが賢い。実際にAgent Engineで試してからCloud Runに移行した案件では、月額コストが5分の1に下がった。

料金 — ADK自体は無料、コストの内訳

ADKのフレームワーク自体はApache 2.0ライセンスで完全無料。コストが発生するのはLLM API呼び出しとクラウドインフラの2箇所。検索上位の記事で料金を具体的に解説しているものがゼロだったので、ここで整理する。

Gemini APIの料金（2026年5月時点）

開発・検証段階ではGemini 2.0 Flashの無料枠で十分回せる。1日数百リクエスト程度ならコストゼロ。本番で精度を求めるなら3.5 Flashに切り替えるが、それでもGPT-5系やClaude Sonnet 4と比べて入力コストは半額以下だ。

LiteLLM経由で他社モデルを使う場合は、そのモデルの料金が適用される。ADK側の追加課金はない。

インフラコストの目安

Cloud Runの無料枠は月200万リクエスト、vCPU 180,000秒、メモリ360,000 GiB秒。個人開発やPoCなら月額ゼロで本番が動く。AIエンジニアとしてのポートフォリオにエージェントを載せるなら、コストの心配は不要だ。

よくある質問

まとめ — 自分ならADKを選ぶ場面

Google ADKは本番まで一本道だ。エージェント開発フレームワークの中で「5言語対応」「Google Cloud直結」「MCP + A2Aネイティブ」の3点で独自のポジションを持つ。

自分ならGoogle Cloudを使っているチームの社内ツールとして、まずPythonで小さなエージェントを作り、Cloud Runに載せるところから始める。adk createから本番デプロイまで、途中で別のツールチェーンに乗り換える必要がない。この一貫性が、他のフレームワークにない実用上のメリットだ。

エージェント開発の全体像を掴みたい人はAIエージェント完全ガイドを、MCPサーバーの選び方を知りたい人はMCPサーバーおすすめ2026を参照してほしい。