GitHub Modelsが7月30日に終了、AIアプリ開発者が今すぐ確認すべきこと｜2026年7月29日版
GitHub Modelsは、2026年7月30日に全面終了します。終了するのはモデル一覧やプレイグラウンドだけではありません。推論APIとBYOK（利用者が用意したAPIキーを使う機能）も対象です。
そのため、GitHub ModelsのAPIをアプリや検証環境から呼び出している場合、対応を先送りにはできません。移行先としてGitHubが案内しているのはMicrosoft Foundryです。一方、GitHub上でコーディング支援を使いたい場合はGitHub Copilotが選択肢になります。
- 終了日：2026年7月30日
- 対象：プレイグラウンド、モデルカタログ、推論API、BYOK、関連UI
- 影響：既存利用者を含むすべての顧客
- 今日の確認事項：API依存の有無、移行先、認証・モデル・評価基準
GitHub Modelsで何が終了するのか
GitHubは7月1日、GitHub Modelsを7月30日に全面終了すると発表しました。6月には新規顧客への提供を止めていましたが、今回は既存の利用者も対象です。
終了する機能は次のとおりです。
- ブラウザ上でモデルを試すプレイグラウンド
- 複数モデルを探すためのモデルカタログ
- アプリからモデルを呼び出す推論API
- 外部事業者のキーを接続するBYOKエンドポイント
- GitHub Modelsに関連する画面
GitHubは移行準備を促すため、7月16日と23日に一時的なサービス停止を実施しました。日本時間で7月29日を迎えた現在、残っているのは本番終了への対応です。
ここがポイント: 影響が大きいのは、GitHub Modelsを試用画面として使った人より、推論APIをコード、CI、社内ツール、デモ環境に組み込んだ開発者です。
なぜ単純な接続先変更では済まないのか
移行先で同じモデルを選べたとしても、APIのホスト名だけを書き換えて完了とは限りません。AIアプリは、モデル本体に加えて認証、デプロイ方式、制限、監視などに依存しているからです。
認証情報とエンドポイントが変わる
GitHub Models向けのトークンやエンドポイントを前提にしたコードは、移行先の認証方式に合わせて変更する必要があります。環境変数、シークレット管理、CI/CDの設定も確認対象です。
特に、次の場所に接続情報が残っていないかを調べる必要があります。
- アプリケーションの設定ファイル
- GitHub ActionsなどのCI/CD
- サーバーやコンテナの環境変数
- 社内向けの検証スクリプト
- ノーコード／ローコードの外部接続設定
モデル名が同じでも挙動は同一とは限らない
Microsoft Foundryは、Microsoft、OpenAI、Meta、DeepSeek、Hugging Faceなどのモデルを探索・比較・展開できる基盤です。ただし、モデルの提供方式やバージョン、利用できる地域、割り当て上限は個別に確認しなければなりません。
移行時には、少なくとも以下を再評価します。
- 出力品質とプロンプトの互換性
- 応答速度とタイムアウト
- トークン上限とレート制限
- 構造化出力やツール呼び出しの対応状況
- 料金、請求先、利用量の監視方法
- データの保存、処理地域、組織内の権限
Microsoftのドキュメントも、代替モデルへの移行では品質、遅延、コストを検証し、確認後に接続先を切り替える流れを案内しています。モデル移行はインフラ変更であると同時に、アプリの再テストでもあります。
CopilotとMicrosoft Foundryは役割が違う
GitHubが示した選択肢は、用途によって分かれます。
アプリからAIを呼び出すならMicrosoft Foundry
独自のWebサービス、社内ツール、エージェントなどにモデル推論を組み込む場合は、Microsoft Foundryが移行候補です。モデルの比較、評価、展開、監視までを扱えます。
ただし、GitHub Modelsからの自動移行が告知されているわけではありません。利用者側でリソースを用意し、モデルを展開して、アプリの接続設定を変更する作業が必要です。
GitHub上の開発支援ならGitHub Copilot
コード補完、チャット、エージェント型の開発支援が目的ならGitHub Copilotが対応します。これは、任意のアプリから汎用の推論APIとして利用するGitHub Modelsとは役割が異なります。
「モデルを試す」「製品に組み込む」「開発作業を支援してもらう」を一つのサービスで済ませていたチームは、終了を機に用途を切り分ける必要があります。
日本の開発者と企業が確認すべきチェックリスト
まず、GitHub Modelsへの通信が本番系だけでなく、開発・検証環境にも残っていないかを確認します。小規模なデモでも、顧客説明や社内業務に使っていれば停止の影響を受けます。
開発担当者
- リポジトリ内でGitHub ModelsのエンドポイントやSDK利用箇所を検索する
- モデル名、API仕様、レスポンス形式への依存を洗い出す
- 代替環境で正常系とエラー系を再テストする
- 旧接続先が失敗した際に無限再試行しないか確認する
運用・管理担当者
- 新しいクラウドリソースと請求先を確認する
- APIキーをシークレット管理へ登録し、権限を最小化する
- 利用量、エラー率、遅延を監視できるようにする
- 個人情報や社外秘データの取り扱い条件を再確認する
サービス責任者
- 7月30日の停止で影響する機能を利用者へ案内する
- 移行が間に合わない機能には一時停止や縮退運転を設定する
- 代替モデルの品質差が業務判断に影響しないか確認する
継続ウォッチ
GitHub Modelsの終了後も、AI開発基盤ではモデルの追加と廃止が続きます。Microsoft Foundryにもモデルのライフサイクルがあり、古いバージョンが恒久的に使えるとは限りません。
今後は次の点を追う必要があります。
- 7月30日の終了時刻と実際のエラー応答
- 移行先で利用するモデルの提供地域と割り当て
- モデル廃止予定を検知する運用ルール
- 特定モデルや単一事業者に接続処理が固定されていないか
今日のまとめ
GitHub Modelsの全面終了は、AIモデルを試す場所が一つ減るだけの話ではありません。推論APIまで停止するため、組み込み用途ではサービス障害に直結します。
7月29日時点で優先すべきなのは、次の3点です。
- GitHub Modelsを呼び出すコードと設定を特定する
- Microsoft Foundryなどの移行先でモデルを展開する
- 認証、出力品質、遅延、料金、エラー処理を再検証する
最初に見るべき場所は、リポジトリのソースコードだけではありません。CIのシークレット、環境変数、検証用スクリプトまで含めて接続先を検索することが、7月30日の停止を見落とさないための具体的な一手です。