開發者平台/API
GitHub Modelsが正式にサービス終了、推論API、モデルカタログ、BYOKも同時に提供終了
GitHubは7月30日、Modelsのplayground、モデルカタログ、推論API、bring-your-own-key(BYOK)機能を終了した。既存の有料ユーザーも例外ではない。同サービスのエンドポイントに依存するアプリケーションは、Microsoft Foundry、別のモデルgateway、または自前のプロバイダー抽象化レイヤーへ移行する必要がある。

GitHub Modelsは7月30日、正式にサービスを終了した。今回の措置はブランド変更や新規顧客の受け入れ停止ではなく、playground、モデルカタログ、ホスト型推論API、bring-your-own-key(BYOK)エンドポイントの完全な廃止である。既存顧客や、現在もトラフィックが発生していた顧客も、呼び出しを継続できない。GitHubはまず6月に新規顧客の受け入れを停止し、7月16日と23日に短時間のbrownoutを実施した後、予定どおりサービスを終了した。
Modelsはもともと、開発者がほぼ統一されたAPIを通じて複数ベンダーのモデルを試し、GitHubのインターフェース上でプロンプトと出力を比較できるサービスだった。その終了は、特に実験的なプロジェクトに技術的な影響を及ぼす。コード内にGitHubのエンドポイント、モデルID、トークン形式、レスポンスschemaをハードコードしている場合、リクエストは現在、そのまま失敗する。Microsoft Foundryへ接続先を変更したとしても、モデル名、rate limit、content filtering、tool calling形式、streaming event、error codeに完全な互換性があるとは想定できない。
GitHubは公式に、モデルカタログとAPIを必要とするアプリケーションにはMicrosoft Foundryを、GitHub workflow内でAIを利用するチームにはCopilotを推奨している。ただし、両者はいずれも一対一の代替製品ではない。Foundryでは、Azureプロジェクト、リージョンごとの可用性、デプロイ名、認証設定への対応が必要となる。一方、Copilotは開発workflow向けの製品であり、任意のアプリケーションで利用できる汎用推論backendとしては使えない。BYOKを介して複数のプロバイダーへのアクセスを統一していたチームも、鍵とroutingをクラウドプラットフォーム、サードパーティーgateway、自前のproxy layerのいずれで管理するのか、改めて決める必要がある。
移行時には、まずエンドポイントとモデルIDを棚卸しし、次にcontract testを使用してJSON schema、function calling、stream終了シグナル、retry条件、content safetyによる拒否を検証する必要がある。base URLを置き換えるだけでなく、latency、token課金、リージョンごとのデータ処理ポリシーも再測定しなければならない。今回のサービス終了は、モデル集約サービスそのものが全面的に撤退する可能性を、エンジニアリングチームに改めて示している。本番システムでは、プロバイダーSDKをadapterの背後に隔離し、offline evaluationに加えて、切り替え可能な認証情報、routing、fallback戦略を用意しておくことが望ましい。