GitHub Models、7月30日に全面終了へ。推論アプリケーションは独立したデプロイメントエンドポイントへの移行が必要

GitHub Modelsは2026年7月30日に全面的に廃止される。これに伴い、プレイグラウンド、モデルカタログ、推論API、Bring Your Own Key（BYOK）インターフェースのすべてが停止し、現在もトラフィックがある既存顧客も対象となる。GitHubは7月16日と23日に短時間のサービス中断を設定し、同サービスに依存するシステムのエラー処理上の問題を事前に顕在化させている。そのため、7月23日のブラウンアウトは、エンジニアリングチームがフォールバック経路、再試行回数の上限、アラートの有効性を検証できる最後の機会の一つとなる。

GitHubは、汎用的なモデルアクセスを必要とするプロジェクトにはMicrosoft Foundryへの移行を、GitHub内のAIワークフローのみが必要な場合にはCopilotの利用を推奨している。ただし、Microsoft Foundryは「リソース—デプロイメント—エンドポイント」モデルを採用している。各デプロイメントには、モデル名、バージョン、容量またはプロビジョニング方式、コンテンツフィルタリング、レート制限の設定が紐づき、呼び出し時にはデプロイメント名を使用する。従来のGitHub Modelsのモデル識別子をそのまま流用できると想定すべきではない。FoundryはOpenAI互換の`/openai/v1/`パスに対応し、APIキーまたはMicrosoft Entra IDによる認証を利用できる。Entra IDを採用する場合は、アクセス許可、トークンスコープ、サービスIDもデプロイプロセスに組み込む必要がある。

移行における主なリスクは、構文ではなくセマンティクスにある。SDKとリクエスト形式に互換性があっても、モデルのバージョン、システムプロンプトの処理、コンテンツフィルタリング、ツール呼び出し形式、ストリーミングイベント、コンテキスト上限、レート制限ポリシーの違いによって、出力が変化する可能性がある。チームはまず、GitHub Modelsの全エンドポイントとBYOKへの依存関係を棚卸しし、代替モデルのバージョンを固定する必要がある。そのうえで、構造化出力、ツール呼び出し、長いコンテキスト、回答拒否のシナリオを含む回帰テストセットを構築し、少量のトラフィックで新旧環境を並行稼働させて、レイテンシ、エラー率、品質、コストを比較すべきだ。キーを新しい環境へ直接コピーしてはならない。より安全なのは、新しいIDを作成し、最小権限の原則を適用したうえで、古い認証情報をローテーションする方法である。

もう一つ注意すべき日付がある。Microsoftのドキュメントによると、Azure AI Inference beta SDKは8月26日に廃止される予定であり、安定版のOpenAI SDKとOpenAI/v1 APIへの移行が推奨されている。今から移行する場合、まもなく廃止されるSDKを経由する構成は避けるべきだ。そうしなければ、1カ月以内に2度目の改修が必要になる可能性がある。また、モデルとリージョンの可用性、クォータ、データガバナンスにも注意が必要であり、価格がGitHub Modelsと同一になる保証もない。