7月4日、Tigera.ioが「Six AI agent SDKs for enterprise Kubernetes, compared」と題した記事を公開した。企業のKubernetes環境で実際に使われている6つのAIエージェントSDKを、モデルの自由度や運用特性の観点から比較している。
「どのSDKに標準化すべきか」という問いは少しずれている
プラットフォームや開発リーダーから頻繁に上がる問いが「KubernetesクラスタはどのエージェントSDKに統一すべきか」だ。だが記事の結論を先に言えば、ほとんどの企業は結果的に複数のSDKを同時に運用することになる。それが計画の失敗ではなく、健全に動いている組織の自然な姿だという。
オンプレミスやプライベートVPCで動かす企業にとって重要な絞り込み条件が2つある。「自分たちが管理するコンテナで動くこと」と「自前でホストできるモデルと通信できること」だ。この2つ目の条件が、驚くほど多くの選択肢を候補外にする。
6つのSDKの特徴と優劣
2026年中盤時点で実際に使われている6つを、モデルの自由度が高い順に紹介する。
LangGraph ― 複雑なステートフルワークフロー向け
LangChainの低レイヤーライブラリ。エージェントの動作を有向グラフとして定義し、状態をチェックポイントとして保存するため、長期実行のエージェントが中断・再開・巻き戻しに対応できる。「このワークフローは複雑で、再起動を乗り越えなければならない」という要件に最もマッチする。
オンプレミス運用は可能で、コアはMITライセンスかつモデル非依存。ただし本番環境ではPostgres（状態管理）とRedis（ストリーミング）が実質必要になり、運用コストは6つの中で最も重い。プラットフォーム層は商用ライセンス。
CrewAI ― 最速でチームが動かせる
「researcher」「writer」のようなロールを持つエージェントの「クルー」を定義して協調させるアプローチ。学習曲線は6つの中で最も低く、コアはMIT・LangChain非依存。OllamaやセルフホストのvLLMエンドポイントへの接続も容易だ。Kagentを使えばKubernetesのカスタムリソースとしてクルーを定義できる。
トレードオフは制御の粒度。各ステップで何が起きるかを細かく制御したい場合、ロールベースの抽象化が邪魔になる場面がある。
Google ADK ― A2Aプロトコル対応の階層型オーケストレーション
Google ADKはルートエージェントがサブエージェントに委譲する階層構造を採用し、A2A（エージェント間）プロトコルをネイティブサポートするため、異なるフレームワークで構築されたエージェント同士が連携できる。Apache 2.0ライセンスで、Python・TypeScript・Go・Java・Kotlinに対応。LiteLLM経由でClaude・Ollama・vLLMなど幅広いモデルに対応しており、見た目のGCPバインドよりもロックインは緩い。
Microsoft Agent Framework ― .NETチームの第一選択肢
AutoGenとSemantic Kernelを統合した後継にあたるフレームワーク。PythonとC#/.NETの両方をサポートすることが最大の差別化で、Microsoftスタックのチームには最も親和性が高い。LLM主導のルーズなオーケストレーションと、決定論的なビジネスロジック型オーケストレーションの両方を扱える点もユニークだ。オープンソースで提供されており、Ollama等のローカルモデルへのコネクターも用意されている。
OpenAI Agents SDK ― 最もクリーンな開発体験
Python・TypeScript対応で、APIサーフェスが小さく、OpenAI APIを使い慣れたチームなら午後一日で動かせる。モデルのロックインは名称が示すより緩く、vLLMやOllama等のOpenAI互換エンドポイントにbase URLを向けることでローカルモデルへの切り替えが可能。さらにLiteLLM・Any-LLM拡張で100以上のプロバイダーに対応するが、この広範なプロバイダー対応はベータ扱いであり、本番利用には注意が必要だ。OpenAIがデフォルトかつ最もよくサポートされているパスであることに変わりはない。
Anthropic Claude Agent SDK ― モデルは完全にClaude固定
Claude Codeのエンジンをライブラリとして提供したもの。CLIサブプロセスを生成してシェルと作業ディレクトリを持たせるアーキテクチャで、ステートレスなAPI呼び出しではなく長期稼働プロセスとして動作する点が他と大きく異なる。DockerfileやKubernetesマニフェストが提供されており、コンテナ化は容易だ。公式ドキュメントはdocs.anthropic.comを参照されたい。
ただし、6つの中で唯一、代替モデルへの差し替えが公式にサポートされていない。Amazon Bedrock・Google Gemini Enterprise Agent Platform・Azureを経由することでトラフィックを自社クラウド内に留めることはできるが、それらはいずれもClaudeのホスティングチャネルであり、ローカルのGPUで重みを動かすシナリオは存在しない。「トークンをネットワーク外に出したくない」という要件には対応できない。
一目で比較できる表
| SDK | 言語 | ライセンス | 強み | 弱み |
|---|---|---|---|---|
| LangGraph | Python, JS/TS | MIT | 耐久ステート、中断/再開 | 運用重い（Postgres+Redis必要） |
| CrewAI | Python | MIT | 最速で動く、低学習曲線 | ステップ単位の制御が弱い |
| Google ADK | Python, TS, Go, Java, Kotlin | Apache 2.0 | A2A対応、多言語、モデル非依存 | Gemini優先のデフォルト設定 |
| Microsoft Agent Framework | Python, .NET (C#) | MIT | 2種のオーケストレーション、Ollama対応 | 最も新しく、ホスト型サービスはAzure限定 |
| OpenAI Agents SDK | Python, JS/TS | MIT | 最もクリーンなDX | 広範なプロバイダー対応はベータ |
| Anthropic Claude Agent SDK | Python, TS | MITコード（利用はCommercial ToS） | Claude Codeエンジンをライブラリとして利用可 | Claude専用、ローカルモデル不可 |
SDKを超えた問題：クラスタ全体のガバナンス
記事が最後に指摘するのは、SDKの選択よりも根本的な問題だ。エージェントがPodとして動き始めた瞬間、SDKはそのプロセスの外を関知しない。どのエージェントがクラスタ内に存在するか、何にアクセスしてよいか、渡したクレデンシャルで実際に何をしたか——これらはどのSDKも管理しない。
6つのSDKのいずれも、それがSDKの役割ではないと記事は明言している。また、複数のフレームワークを同時に運用する現実においては、特定の実装方法にしか効かないガバナンスでは「艦隊」の大半を把握できないという指摘も重要だ。なお、Tigera.ioはKubernetesネットワークセキュリティ製品であるCalicoの開発元であり、本記事のガバナンスへの言及はその文脈でも読める。
まとめ：選び方の指針
- LangGraph ― ステートフルで複雑なワークフロー
- CrewAI ― 週内にマルチエージェントを動かしたい
- Google ADK ― A2Aと複数フレームワークの連携を重視
- Microsoft Agent Framework ― C#/.NETスタックのチーム
- OpenAI Agents SDK ― 開発体験優先、必要に応じてローカルモデルも（広範な対応はベータ）
- Claude Agent SDK ― Claude Code相当の動作が必要で、Bedrock等で十分
6つのうち5つはセルフホストモデルに対応している（ただしOpenAI Agents SDKの広範なプロバイダー対応はベータ扱い）。モデルの自由度がオンプレミス企業にとって最初の絞り込み条件であり、その後の選択は「グラフ・クルー・階層・ハンドオフ」のどの思考モデルがチームに合うかで決まる。
詳細はSix AI agent SDKs for enterprise Kubernetes, comparedを参照していただきたい。
