なぜ今、SDKジェネレーターが注目されるのか
AIエージェントのエコシステムにおいて、SDKは「おまけ」ではなくインターフェースそのものです。Interactions、Agents、Webhooksのように、ストリーミングプロトコル、厳密なエラーヒエラルキー、複雑な型ユニオンを扱うAPIを手書きでラップするのは現実的ではありません。そのため大手テック企業は、OpenAPIスペックをコードにコンパイルする専用ジェネレーターを利用してきました。
問題は、そのジェネレーターが**プロプライエタリ（クローズドソース）**だったことです。実際に2026年5月、GoogleがGoogle I/OとInteractions APIのGAリリースを準備していたタイミングで、利用していたSDK生成ベンダーが買収後に突然サービス終了を発表しました。パイプライン全体が揺らいだのです。この出来事が示した教訓は明確です。
「OpenAPIでインターフェースを定義するなら、それをクライアントライブラリ・CLI・エージェントツールへコンパイルするツールチェーンもオープンなインフラであるべきだ。」
根拠資料: Google Developers Blog — Why client SDK generation belongs in the open
本記事では、(1) Googleが実際にどうマイグレーションしたか、(2) AGPLv3ライセンスが実務に与える意味、(3) 日本の開発チームがどう活用できるかを整理します。
実際のパイプライン構成
GoogleはSpeakeasyと協業し、クライアントライブラリをインプレースでマイグレーションしました。基本方針は「開発者の混乱を最小化し、破壊的変更を避ける」こと。移行時に整理されたエンジニアリング上のポイントは次の通りです。
- 全ターゲット言語間での型定義の整合
- 厳密なエラーヒエラルキーの維持
- ストリーミング挙動の保持（SSE、チャンク処理）
- ジェネレーターを社内モノレポおよびビルドシステムへ直接統合
ここで重要な設計思想が現れます。Google DeepMindは決定論的（deterministic）なジェネレーターをコアに置き、カスタム部分のみをAIエージェントで加速するハイブリッド構成を選択しました。理由はシンプルです。「公式APIスペック → 多言語SDK」の変換に求められるのは創造性ではなく、型安全性と再現性だからです。
# 生成されたSDKの使用例（Gemini Interactions API）
from google import genai
client = genai.Client()
interaction = client.interactions.create(
model="gemini-3.8-flash",
input="Analyze this commit log and find regressions.",
)
# 生成されたクライアントはストリーミング/エラー型までスペックと1:1で対応
print(interaction.output_text)
結果として、以前は複数のエンジニアが手作業で保守していたジェネレーターを、現在はエンジニア約1名で6ターゲット（3つはリリース済み、残りは順次ロールアウト）をカバーするパイプラインとして運用しているとのことです。
AGPLv3は実務で何が変わるのか
最も混同されやすい部分なので表にまとめます。
| 区分 | 内容 | 実務への影響 |
|---|---|---|
| ジェネレーター本体 | AGPLv3 | 改変時は改善分の公開義務 |
| 生成されたSDK/コード | 利用者選択のライセンス（MIT、Apache 2.0など） | 完全に所有可能 |
| CI/開発パイプラインでの実行 | 許容 | 社内ビルドで自由に利用可 |
| ジェネレーターのフォーク改変 | AGPLv3が伝播 | カスタムパッチ時に公開負担 |
要点は**「ジェネレーター ≠ 生成物」**という分離です。ジェネレーターを改変せずそのまま実行して得たSDKは、自社ライセンスで自由に配布できます。一方、ジェネレーターのコンパイラ自体を修正した場合は、その改善分をAGPLに従いコミュニティへ還元する必要があります。
注意すべき点（批判的視点）
- AGPLの伝播範囲: ジェネレーターをSaaSとしてラップし外部公開する場合、AGPLの解釈問題が生じ得ます。社内ネットワーク内の利用は安全ですが、外部サービス化には法務レビューが必須です。
- 決定論 vs AIハイブリッド: AIエージェントでカスタム部分を加速する構成は便利ですが、再現性検証（生成結果のdiff）をCIに必ず組み込むべきです。そうしないと「昨日は動いたSDKが今日は動かない」事態が発生します。
- スペックドリフト: OpenAPIスペックが急速に変化する初期段階のAPIでは、ジェネレーターバージョンとスペックバージョンを併せて固定（pin）するのが安全です。
次のステップ学習方向
- OpenAPI 3.1スペックの記述法と
oneOf/anyOfユニオン型設計 - 決定論的コード生成パイプラインとスナップショットテスト
- MCPサーバーの自動生成（同一スペックから派生する別の成果物）
あわせて読みたい
- "MLPerf 6.0 전 부문 석권한 NVIDIA, DeepSeek-V3 671B를 단 2분에 학습시킨 비결"
- "A2UI v0.9 정식 출시 AI 에이전트가 실시간으로 UI를 생성하는 새로운 표준"
まとめ：今チームが取るべきアクション
- OpenAPIスペックが既にある場合 → Speakeasyジェネレーターをローカルで実行し、既存の手書きSDKとの出力diffを比較してください。移行コストは想像より低いかもしれません。
- スペックがない場合 → まずAPIをOpenAPIで文書化することが前提条件です。
- CI統合 → 生成結果の決定論を検証するジョブをパイプラインに追加してください。
一言でまとめると：「SDKジェネレーターは社内インフラとして扱うべき段階」 です。クローズドな生成ツールに依存するのは避けましょう。