AIエージェントSDK三つ巴｜Strands・ADK・OpenAI徹底比較

「AIエージェントを作りたいけど、SDKが多すぎてどれを選べばいいか分からない…」

正直、この悩みはもっともだ。2026年3月時点で、AWS・Google・OpenAIの3社がそれぞれ独自のエージェントSDKをオープンソースで公開し、開発者の選択肢は一気に広がった。AWS Strands Agents、Google ADK（Agent Development Kit）、OpenAI Agents SDK――どれも「数行でエージェントが作れる」とうたっているが、実際に触ってみると設計思想がまるで違う。

この記事では、3つのSDKを同じタスク（ツール呼び出し付きエージェント）で実装し、モデル対応・マルチエージェント・デプロイ・エコシステムの4軸で比較する。「自分のプロジェクトにはどれが合うのか」が、読み終わる頃にはクリアになるはずだ。

スペック比較：3つのSDKを並べてみる

項目	AWS Strands Agents	Google ADK	OpenAI Agents SDK
初リリース	2025年5月	2025年4月	2025年3月
言語	Python / TypeScript	Python / Java	Python / TypeScript
対応モデル	12+プロバイダー（Bedrock・OpenAI・Anthropic・ローカル）	Gemini中心、他モデルも可	OpenAIモデル中心
マルチエージェント	Graph・Swarm・Workflowパターン	階層型エージェントツリー	Handoffパターン
通信プロトコル	A2A対応	A2A対応	MCP対応
ガードレール	Bedrock AgentCore Policy	GCP IAM + カスタム	ビルトインInput/Output検証
可観測性	OpenTelemetry（X-Ray/CloudWatch）	UI/CLIトレーシング	ビルトイントレーシング
ライセンス	Apache 2.0	Apache 2.0	MIT
GitHub Stars（参考）	約5,300+	約18,500+	約20,000+

注目ポイント：モデル対応の幅がSDK選定を大きく左右する。Strands Agentsは12以上のプロバイダーに対応しており、特定のLLMにロックインされたくない開発者には最も柔軟な選択肢だ。

同じタスクを3つのSDKで実装する

百聞は一見にしかず。「都市名を受け取って現在時刻を返すエージェント」を、3つのSDKで書いてみよう。

AWS Strands Agents

# 動作環境: Python 3.10+, strands-agents>=0.1
# pip install strands-agents strands-agents-tools
# 事前設定: AWS_REGION, AWS認証情報（Bedrock利用時）

from strands_agents import Agent

def get_current_time(city: str) -> dict:
    """指定した都市の現在時刻を返す"""
    import datetime, pytz
    tz_map = {"tokyo": "Asia/Tokyo", "new_york": "America/New_York", "london": "Europe/London"}
    city_key = city.lower().replace(" ", "_")
    if city_key not in tz_map:
        return {"error": f"{city}のタイムゾーンデータがありません"}
    now = datetime.datetime.now(pytz.timezone(tz_map[city_key]))
    return {"city": city, "time": now.strftime("%Y-%m-%d %H:%M:%S %Z")}

agent = Agent(
    system_prompt="都市の現在時刻を教えるアシスタントです。get_current_time ツールを使ってください。",
    tools=[get_current_time]
)

response = agent("東京の今の時間は？")
print(response)
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

ポイント：Agent クラスにツール関数をリストで渡すだけ。モデル指定を省略するとBedrock上のClaudeがデフォルトで使われる。LiteLLM経由で他プロバイダーも利用可能。

Google ADK

# 動作環境: Python 3.10+, google-adk>=1.0
# pip install google-adk
# 事前設定: GOOGLE_API_KEY（Google AI Studio発行）

from google.adk.agents.llm_agent import Agent, Tool

def get_current_time(city: str) -> dict:
    """指定した都市の現在時刻を返す"""
    import datetime, pytz
    tz_map = {"tokyo": "Asia/Tokyo", "new_york": "America/New_York", "london": "Europe/London"}
    city_key = city.lower().replace(" ", "_")
    if city_key not in tz_map:
        return {"error": f"{city}のタイムゾーンデータがありません"}
    now = datetime.datetime.now(pytz.timezone(tz_map[city_key]))
    return {"city": city, "time": now.strftime("%Y-%m-%d %H:%M:%S %Z")}

root_agent = Agent(
    model="gemini-2.0-flash",
    name="time_agent",
    description="都市の現在時刻を教えるエージェント",
    instruction="get_current_time ツールを使って、ユーザーが指定した都市の時刻を返してください。",
    tools=[Tool(name="get_current_time", func=get_current_time,
                description="指定した都市の現在時刻を返す")]
)
# adk run で実行: adk run my_agent
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

ポイント：ADKでは Agent と Tool を明示的に分離して定義する。adk run や adk web コマンドでCLI/ブラウザから即テスト可能なのが便利。

OpenAI Agents SDK

# 動作環境: Python 3.10+, openai-agents>=0.1
# pip install openai-agents
# 事前設定: OPENAI_API_KEY

from agents import Agent, Runner, function_tool

@function_tool
def get_current_time(city: str) -> str:
    """指定した都市の現在時刻を返す"""
    import datetime, pytz
    tz_map = {"tokyo": "Asia/Tokyo", "new_york": "America/New_York", "london": "Europe/London"}
    city_key = city.lower().replace(" ", "_")
    if city_key not in tz_map:
        return f"{city}のタイムゾーンデータがありません"
    now = datetime.datetime.now(pytz.timezone(tz_map[city_key]))
    return f"{city}: {now.strftime('%Y-%m-%d %H:%M:%S %Z')}"

agent = Agent(
    name="TimeAgent",
    instructions="ユーザーが指定した都市の現在時刻を教えてください。",
    tools=[get_current_time]
)

result = Runner.run_sync(agent, "東京の今の時間は？")
print(result.final_output)
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

ポイント：@function_tool デコレータで関数をそのままツールに変換できる。Runner がエージェントループの管理を担うため、開発者はロジックに集中できる。

4つの軸で深掘り比較

軸1：モデル対応の柔軟性

ここが3つのSDKで最も差が出る。

SDK	デフォルトモデル	他モデル利用	ローカルモデル
Strands Agents	Bedrock Claude	OpenAI・Anthropic API・LiteLLM経由で多数対応	LiteLLM経由で対応
Google ADK	Gemini	他モデルもサポートするが最適化はGemini向け	限定的
OpenAI Agents SDK	GPT-4o / GPT-5系	SDK自体はOpenAI API向け設計	非対応

マルチクラウドや「ベストモデルを都度選びたい」チームには、Strands Agentsのモデル非依存設計が有利だ。一方、OpenAIモデルだけで完結するなら、Agents SDKのシンプルさは圧倒的。

軸2：マルチエージェントの設計思想

複数エージェントの協調方法に、各SDKの哲学がよく現れる。

• Strands Agents：Graph（有向グラフ）・Swarm（自律分散）・Workflow（逐次実行）の3パターンを提供。A2Aプロトコル対応で、異なるフレームワークのエージェント間でも通信可能
• Google ADK：階層型エージェントツリー。親エージェントが子エージェントにタスクを委譲する構造。A2A対応で外部エージェントとの連携も想定
• OpenAI Agents SDK：Handoff（引き継ぎ）パターン。エージェントAが「この質問はBの担当だ」と判断し、会話コンテキストごと別エージェントに転送する

正直、どのパターンが「正解」かはユースケース次第だ。CRM×在庫×配送のように独立性が高いドメインを並列処理するならSwarmやGraph。コールセンターのような段階的エスカレーションにはHandoff。上下関係が明確な組織型にはツリー構造が自然に馴染む。

軸3：デプロイと運用

項目	Strands Agents	Google ADK	OpenAI Agents SDK
推奨デプロイ先	Bedrock AgentCore / Lambda / EKS	Vertex AI / Cloud Run	OpenAI API（クラウド依存なし）
ガバナンス	Bedrock Policy + IAM	GCP IAM + Vertex AI Governance	ビルトインガードレール
コスト管理	AWS Cost Explorer連携	GCP Billing連携	API使用量ダッシュボード
CI/CD	CodePipeline / CDK対応	Cloud Build / Terraform対応	標準Python CI（GitHub Actions等）

既存のクラウドインフラがある企業は、そのクラウドのSDKを選ぶのが自然だ。OpenAI Agents SDKはクラウド非依存で動くぶん、インフラを自前で組む柔軟性がある。ただしエンタープライズ向けのガバナンス機能はAzure OpenAI Serviceとの組み合わせで補完する形になる。

軸4：エコシステムとコミュニティ

SDK単体の機能よりも、周辺のツール・ドキュメント・コミュニティの厚みが長期的な開発体験を左右する。

• Strands Agents：strands-agents-toolsパッケージで20以上のビルトインツールを提供。AWSの公式ドキュメント・チュートリアルが充実。ただしコミュニティはまだ成長途中
• Google ADK：adk create でプロジェクトを即生成、adk web でブラウザUI付きデバッグ環境が起動。Vertex AI Agentとの統合が深い。GitHub Stars約18,500
• OpenAI Agents SDK：GitHub Stars約20,000と大きなコミュニティ。dev.toやMediumの記事も多い。ただしAssistants API廃止（2026年8月予定）への移行で一部混乱が見られる

【要注意】SDK選定でよくある失敗パターン

失敗1：クラウド戦略を無視してSDKを選ぶ

❌ 「GitHub Starsが多いから」でOpenAI Agents SDKを選び、後からAWS環境との統合で苦労する

⭕ 自社のクラウドインフラ（AWS/GCP/Azure）を最初に確認し、対応するSDKを候補に入れる

なぜ重要か：エージェントは本番で動かしてこそ価値がある。デプロイ・モニタリング・セキュリティは既存インフラとの相性が9割だ。

失敗2：モデルロックインを軽視する

❌ 特定モデルに最適化されたSDKを選び、モデルの性能低下や値上げ時に身動きが取れなくなる

⭕ 将来的にモデルを切り替える可能性があるなら、モデル非依存のSDK（Strands Agents）を検討する

なぜ重要か：LLMの性能差は急速に縮まっている。今はGPT-4oが最適でも、半年後にGeminiやClaudeが逆転する可能性は十分ある。

失敗3：マルチエージェントを最初から作り込みすぎる

❌ 初日から5つのエージェントが連携する複雑なシステムを設計する

⭕ まず1エージェント＋1ツールで動くものを作り、必要に応じてエージェントを追加する

なぜ重要か：マルチエージェントはデバッグの難易度が指数的に上がる。単一エージェントで解決できる問題を、わざわざ分散させる必要はない。

失敗4：Assistants API廃止への対応を先延ばしにする

❌ OpenAI Assistants APIを使い続け、2026年8月の廃止期限ギリギリで慌てて移行する

⭕ 今のうちにResponses API（Agents SDK）への移行計画を立て、段階的にコードを書き換える

なぜ重要か：移行には会話状態の再設計が伴う場合がある。特にThreads機能に依存している場合は注意が必要だ。

筆者のおすすめ：こんな人にはこのSDK

3つのSDKはそれぞれ得意領域が違う。万能な「最強SDK」は存在しない。

あなたの状況	おすすめSDK	理由
AWSインフラが主体で、複数モデルを使いたい	Strands Agents	Bedrock AgentCoreとの統合が深く、モデル切り替えが容易
GCPユーザーで、Geminiを活用したい	Google ADK	Vertex AI・BigQueryとの連携が強力。adk webでデバッグが楽
OpenAIモデルに集中し、速く作りたい	OpenAI Agents SDK	最小限のコードで動くエージェントが作れる。コミュニティも最大
クラウド非依存・オンプレで動かしたい	Strands Agents + LiteLLM	ローカルモデル対応で、特定クラウドへの依存を避けられる
ノーコードで非エンジニアも使いたい	Google ADK + Vertex AI Agent Builder	ノーコードUIとコードの両方で構築可能

迷ったら、まず自社のクラウド環境を確認すること。それがAWSならStrands、GCPならADK、クラウド非依存ならOpenAI Agents SDKかStrandsから試すのが効率的だ。

まとめ

AIエージェントSDKは「どれが一番優れているか」ではなく「自分のチーム・インフラ・ユースケースに合うか」で選ぶべきだ。

• モデルの自由度を最優先するなら → Strands Agents
• Googleエコシステムとの一体化なら → Google ADK
• 最速プロトタイピング＋巨大コミュニティなら → OpenAI Agents SDK

どのSDKも活発に開発が進んでおり、半年後にはまた勢力図が変わっている可能性がある。だからこそ、1つに賭けるのではなく、SDK間の抽象化レイヤーを意識しておくことが、長期的には最良の戦略になる。

AIエージェントの基本概念や構築パターンについては、AIエージェント構築完全ガイドで体系的にまとめている。

あわせて読みたい：

• Google ADKでAIエージェントを構築する実践ガイド — 環境構築からデプロイまでの具体的な手順
• AIエージェント構築ツール実力比較｜Dify・n8n・LangGraph・CrewAI — ノーコード〜フルコードの選択肢を網羅

参考・出典

• Strands Agents 公式ドキュメント — Python Quickstart（参照日: 2026-03-22）
• Google ADK 公式ドキュメント — Quickstart（参照日: 2026-03-22）
• OpenAI Agents SDK GitHub リポジトリ（参照日: 2026-03-22）
• AWS公式ブログ — Introducing Strands Agents（参照日: 2026-03-22）
• OpenAI Community — Assistants API Deprecation Notice（参照日: 2026-03-22）

---

AIエージェント導入・SDK選定のご相談はお問い合わせフォームからお気軽にどうぞ。

この記事はAIgent Lab編集部がお届けしました。