公開：2026年9月18日, 最終更新：2026年9月18日
30秒サマリー
- Googleが採用していたSDK生成ツールが買収・突然終了、クローズドツールへの依存リスクが露呈
- SpeakeasyのOpenAPIクライアント生成スイートをAGPLv3でオープンソース化、7言語に対応
- 保守に複数人エンジニアを要した自社製ジェネレーターが、約1人体制に集約
何が起きたか
Google DeepMindのエンジニアチームは2026年9月17日、Speakeasyとの提携により同社のOpenAPIクライアント生成スイートをオープンソース化したと公式ブログで発表した。背景には深刻な調達リスクがある。2026年5月、Google I/OおよびInteractions APIの一般提供開始に向けた準備中、当時利用していたSDK生成ツールのプロバイダーが買収され、突然サービス終了を告知した。
GoogleはSpeakeasyと協力してクライアントライブラリを移行し、その条件としてジェネレーター本体のオープンソース化を確約した。移行にあたっては、対象言語をまたいだ型定義の整合、エラー階層やストリーミング挙動の維持、内部モノレポへの統合など技術的な課題を伴ったとしている。
今回オープンソース化されたのは、Python・TypeScript・Go・Java・C#・PHP・Rubyの7言語向けSDKジェネレーター、スタンドアロンCLIバイナリ生成機能、およびOpenAPIスペックをMCP（Model Context Protocol）サーバーへ変換するドキュメント用ジェネレーターの3種類。ライセンスはAGPLv3で、生成されたSDKコード自体はMITやApache 2.0など任意のライセンスで管理できるとしている。現時点でGoogleの本番パイプラインではPython・TypeScript・Goを含む6ターゲットに適用済みで、さらに追加ターゲットを順次展開中だという。
原典ハイライト
「プロプライエタリなクローズドソースのジェネレーターは許容できないプラットフォームリスクを生む。業界がOpenAPIでインターフェースを定義するなら、それをクライアントライブラリやCLI、エージェントツールにコンパイルするツールはオープンなインフラであるべきだ」（原文より要約）
出典: Google Developers Blog – AI（公式ブログ）
So What?（なぜ重要か）
開発インフラの重要コンポーネントがプロプライエタリである場合、ベンダー買収・廃業によって突然の移行を迫られるリスクが現実に生じることをGoogleの事例が示した。特にSDK生成のように、複数言語・複数チームが依存する中核ツールがクローズドであれば、その影響は広範かつ急速に波及する。今回のオープンソース化により、業界全体でOpenAPIベースのSDK生成が共有インフラとして安定運用できる基盤が整いつつある。
日本企業への示唆
自社の開発パイプラインにクローズドな外部SaaSやプロプライエタリツールが深く組み込まれている場合、ベンダーリスクの棚卸しが急務となる。とくに複数言語のSDK生成・API仕様管理・ドキュメント自動化といった「見えにくい中間レイヤー」は、代替手段の有無を事前に確認しておくべき領域だ。今回オープンソース化されたSpeakeasyのジェネレーターはAGPLv3であり、生成物の著作権は自社に帰属するため、社内CI/CDへの組み込みを検討する際のライセンスコストは低い。一方でAGPLの「ジェネレーター本体を改変した場合は公開義務」という条件を法務・OSS担当部門と確認した上で導入判断を行うことが求められる。
背景・経緯
GoogleはInteractions・Agents・Webhooks APIのSDKをSpeakeasyと共同で開発してきた。2026年5月にInteractions APIが一般提供（GA）を迎えるタイミングで利用中のSDK生成ツールベンダーが突然終了を告知したことが直接の契機。従来、SDK生成の保守には複数エンジニアが必要だったが、移行後は約1名体制に集約できたと報告されている。
