Claude Agent SDKとGoogle ADKの違い — エージェント定義とモデル非依存性

Claude Agent SDKは「Claude Codeのエージェントを自分のアプリに組み込むライブラリ」で、Google ADK(Agent Development Kit)は「モデルとツールと指示からエージェントを組み立てるフレームワーク」です。同じ「エージェント開発キット」でも、出発点が違います。違いは、定義するもの、使えるモデル、MCPのつなぎ方、複数エージェントの制御の4点に集約されます。

何を定義するのか — エージェント本体か、サブエージェントか

ADKでは、アプリの中心にあるエージェントそのものを定義します。Agent SDKでは、エージェントループはClaude Code側に用意されており、開発者が定義するのは主に「呼び出し方」と「サブエージェント」です。

ADKのLlmAgent

ADKのLlmAgent(Agentの別名で使われる)には、IDにあたるname、他のエージェントがルーティング判断に使うdescription、動かすモデルを指すmodelを渡します。nameは必須で、userのような予約名は避けます。modelも必須です。descriptionは任意ですが、マルチエージェントでは付けることが勧められています。

from google.adk.agents import LlmAgent
 
capital_agent = LlmAgent(
    model="gemini-flash-latest",
    name="capital_agent",
    description="Answers user questions about the capital city of a given country.",
    instruction="Answer the user's question about capital cities.",
)

エージェントの挙動はinstructionで導き、toolsにPython関数などを渡して能力を足します。ツールには他のエージェントをAgentToolとして渡すこともでき、これがエージェント間の委譲の入口になります。

Agent SDKのAgentDefinition

Agent SDKではquery()にプロンプトとオプションを渡して、エージェントループを走らせます。専門役を足したいときにagentsパラメーターへAgentDefinitionを渡す形です。必須項目はdescription(Claudeがいつ使うかを判断する文)とprompt(そのサブエージェントのシステムプロンプト)の2つだけです。

import asyncio
from claude_agent_sdk import query, ClaudeAgentOptions, AgentDefinition
 
 
async def main():
    async for message in query(
        prompt="認証モジュールのセキュリティ上の問題をレビューして",
        options=ClaudeAgentOptions(
            allowed_tools=["Read", "Grep", "Glob", "Agent"],
            agents={
                "code-reviewer": AgentDefinition(
                    description="コードの品質・セキュリティ・保守性をレビューする専門役。",
                    prompt="あなたはコードレビューの専門家です。",
                    tools=["Read", "Grep", "Glob"],
                    model="sonnet",
                )
            },
        ),
    ):
        print(message)
 
 
asyncio.run(main())

toolsを省くと、サブエージェントが使えるツールをすべて引き継ぎます。上のように絞れば、読み取り専用のレビュー役になります。.claude/agents/にMarkdownファイルを置くファイルベース定義でも同じ役割を作れます。2つの定義方法の使い分けはAgent SDKのサブエージェント定義にまとめています。

ここに最初の設計差が出ます。ADKはルートも含めて全員をLlmAgentとして宣言します。Agent SDKは、ファイル編集やコマンド実行といった道具立てを備えたエージェントが最初からいて、そこに専門役を足す構造です。

どのモデルで動かせるのか — モデル非依存性の差

違いが最も大きいのはここです。

ADKはモデルを差し替える前提

ADKのモデル連携は2系統あります。Gemini系のようにモデル名の文字列を渡すと、内部のレジストリが対応するバックエンドに解決する方式が1つ。もう1つは、ApigeeやLiteLLMなどのコネクタクラスをmodelに渡す方式です。ローカルのOllama、vLLM、LiteRT-LMのホスティングや、実行時にモデルを切り替えるルーティングの案内もあります。

Claudeを使う場合、ADKのClaude向けページは経路を言語ごとに分けています。

LiteLLM経由ならPythonだけでOpenAI、Anthropic、Ollama、Mistral、DeepSeek、Cohereなど100以上のモデルに届きます。書き方はmodelにラッパーを渡すだけです。

pip install "litellm>=1.84"
export ANTHROPIC_API_KEY="YOUR_ANTHROPIC_API_KEY"

from google.adk.agents import LlmAgent
from google.adk.models.lite_llm import LiteLlm
 
agent_claude_direct = LlmAgent(
    model=LiteLlm(model="anthropic/claude-3-haiku-20240307"),
    name="claude_direct_agent",
    instruction="You are an assistant powered by Claude Haiku.",
)

これはADKのドキュメントにある例の形で、モデルIDは例示です。実際に使うIDはAnthropicのモデル一覧で選びます。

LiteLLMページの冒頭には、2026年3月24日にPyPI上のLiteLLM 1.82.7と1.82.8へ不正なコードが混入したというセキュリティ告知があります。その期間にLiteLLMを入れた場合は、認証情報のローテーションが必要とされています。ADK Pythonでevalや拡張のextrasを使っているなら、ADKを最新にするよう案内されています。

Agent SDKはClaude専用で、入口だけ複数ある

Agent SDKの動力はClaude Codeです。モデルをGPTやGeminiに差し替える仕組みは、SDKの概要ページにも、クイックスタートの認証の節にもありません。選べるのは「どの経路でClaudeに届くか」です。Anthropic APIキーのほか、次の環境変数で第三者プロバイダー経由のClaudeに切り替えられます。

Claude Platform on AWSにはCLAUDE_CODE_USE_ANTHROPIC_AWS=1とANTHROPIC_AWS_WORKSPACE_IDを使います。つまりGoogle Cloud上のモデルを呼ぶ構成でも、Agent SDKが話す相手はClaudeです。

モデルの選び分けはサブエージェント単位で行います。AgentDefinitionのmodelには'fable'・'opus'・'sonnet'・'haiku'のエイリアスか完全なモデルID、親のモデルを使う'inherit'を指定できます。省略すると、Claude Codeのサブエージェントのモデル決定順に従います。役割ごとのモデル配分の考え方はClaude Codeサブエージェントのモデル配分設計にあります。

つまり「モデル非依存性」の意味が違います。ADKは別会社のモデルまで差し替えられる自由度、Agent SDKはClaudeの中でサイズと経路を選ぶ自由度です。

MCPサーバーはどうつなぐのか

どちらもMCP(Model Context Protocol)のクライアントとして外部ツールにつなげます。つなぎ方の流儀が違います。

ADKではMcpToolsetをエージェントのtoolsに入れます。接続方式は接続パラメーターのクラスで選びます。ローカルのプロセスならStdioConnectionParams、リモートならStreamableHTTPConnectionParamsやSseConnectionParamsです。

from google.adk.agents import LlmAgent
from google.adk.tools.mcp_tool import McpToolset
from google.adk.tools.mcp_tool.mcp_session_manager import StdioConnectionParams
from mcp import StdioServerParameters
 
root_agent = LlmAgent(
    model="gemini-flash-latest",
    name="filesystem_assistant",
    instruction="Help users manage local files.",
    tools=[
        McpToolset(
            connection_params=StdioConnectionParams(
                server_params=StdioServerParameters(
                    command="npx",
                    args=["-y", "@modelcontextprotocol/server-filesystem", "./accessible_files"],
                ),
            ),
            tool_filter=["list_directory", "read_file"],
        )
    ],
)

tool_filterで公開するツールを絞ることが、ADKのチェックリストで勧められています。本番へ出すエージェントはagent.pyの中でMcpToolsetを同期的に定義する必要があり、非同期の動的な初期化はローカルデバッグか自前のランナーに限られます。

Agent SDKでは、mcpServersオプションにサーバー設定を渡します。コマンド起動型はcommandとargs、リモートはtypeに"http"か"sse"を指定してURLを渡します。設定ファイルの.mcp.jsonから読む経路もあります。

options = ClaudeAgentOptions(
    mcp_servers={
        "filesystem": {
            "command": "npx",
            "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/projects"],
        }
    },
    allowed_tools=["mcp__filesystem__*"],
)

絞り込みの場所が違うことに注目してください。ADKはツールセット側のtool_filterで見せるツールを選びます。Agent SDKはmcp__<サーバー名>__<ツール名>という名前でallowed_toolsに列挙し、自動承認の範囲を決めます。サブエージェントごとに別のMCPサーバーを持たせたいときは、AgentDefinitionのmcpServersに名前かインライン設定を渡します。

認証の扱いも異なります。ADKのMcpToolsetは、認証が必要なリモートサーバーに対して認証情報の注入とトークン管理を引き受けます。HTTPヘッダーを手で足すより、auth_schemeとauth_credentialを使うよう案内されています。Agent SDKは、ブラウザを開く対話型のOAuthフローを走らせません。認可の要求に応える保存済みトークンがなければ、そのサーバーのツールなしで実行が続き、サーバーの状態がneeds-authになります。状態はTypeScriptのmcpServerStatus()かPythonのget_mcp_status()で確認できます。

AIコーディングエージェント各製品のMCP対応を比べたい場合は、AIコーディングエージェントのMCP対応状況を比較するが参考になります。

複数のエージェントをどう束ねるのか

ここでも設計思想が分かれます。ADKは「実行の流れをコードで決める」方向に伸び、Agent SDKは「Claudeに判断を任せ、上限で囲う」方向です。

ADKのワークフローには4種類あります。

ADKのドキュメントは、単一エージェントから分割する理由として、指示の追従性能、コンテキストの限界、コードの再利用性、そして「非決定的なAIと決定的なコードの混在」を挙げます。AIに全体の進行を任せず、決まった手順はコードで固定する発想です。サブエージェントの扱いも細かく、エージェント転送を制限するdisallow_transfer_to_parentとdisallow_transfer_to_peersのようなオプションがあります。

Agent SDKのサブエージェントは、ClaudeがAgentツールで呼び出します。いつ、何体呼ぶかはClaudeが決めます。その代わり、暴走を防ぐ上限がSDK側に用意されています。

サブエージェントは独立した会話で動き、途中のツール呼び出しと結果は親に戻りません。親に返るのは最終メッセージだけです。コンテキストを守りたい調査系の分業には向きますが、親の会話履歴は子に渡らず、渡せるのはAgentツールのプロンプト文字列だけです。必要なファイルパスやエラーメッセージは、そのプロンプトに書き込みます。

ADK側の同じ論点はinclude_contentsで、'none'にすると、そのエージェントは直前までの会話履歴を受け取らず、指示と今回の入力だけで動きます。コンテキストの切り方を、Agent SDKは「サブエージェントの境界」で、ADKは「エージェントごとの設定」で表現している違いです。

どちらを選ぶか — 判断の分かれ目

選び方は、使うモデル、持たせたい道具、制御の置き場所で決まります。

組み合わせる道もあります。ADKのLiteLlmでClaudeを動かせるため、ADKの枠組みの中にClaudeを置く構成は成立します。ただしその場合、toolsに渡したものがエージェントの能力の中心になります。Claude Codeの組み込みツールや権限制御を使うのではなく、ADK側でツールを用意する前提です。逆にAgent SDKからGeminiを動かす経路は、SDKの案内にありません。

どちらのキットも、運用面の選択肢は別途あります。Anthropicがエージェントを動かす基盤をホストするManaged Agentsとの切り分けはManaged AgentsとAgent SDKとClaude Codeの違いで扱っています。

まとめ

名前は似ていても、2つは役割が違います。Agent SDKは「Claudeという特定のエージェントを自分のアプリに住まわせる」ためのライブラリで、ADKは「どのモデルでも動くエージェントを設計図から組む」ためのフレームワークです。モデルを選ぶ自由が要るならADK、Claude Codeの完成した道具立てが要るならAgent SDK。この一点が、MCPのつなぎ方や制御の置き場所にまで影響します。