GitHub Models終了、AIモデル実験環境はMicrosoft Foundryへ｜2026年8月1日版

GitHubは2026年7月30日、GitHub Modelsの提供を全面終了しました。プレイグラウンドだけでなく、モデルカタログ、推論API、BYOK（利用者自身のAPIキーを使う機能）も既存利用者を含めて停止しています。

影響を受けるのは、GitHub Modelsを試用画面として使っていた人だけではありません。APIをアプリや検証スクリプトから呼び出していた開発チームは、接続先、認証、モデルの配備、料金管理をMicrosoft Foundryなどへ移す必要があります。

• GitHub Modelsは7月30日付で全面終了
• プレイグラウンド、モデルカタログ、推論API、BYOKが利用不可
• GitHubは移行先としてMicrosoft Foundryを案内
• 移行後はAzure契約、モデル配備、課金、リージョンを管理する必要がある

終了した機能と影響範囲

GitHubの終了告知によると、対象は一部のプランや新規利用者に限られません。既にAPIを使っていた顧客も含め、すべての利用者が対象です。

終了した主な機能は次の4つです。

• ブラウザ上でモデルを比較・試用するプレイグラウンド
• 利用可能なモデルを探すモデルカタログ
• アプリからモデルを呼び出す推論API
• 外部事業者のキーを登録するBYOKエンドポイント

GitHubは6月16日に新規顧客の利用を停止し、7月1日に全面終了日を発表していました。7月16日と23日には、移行準備を促す短時間の計画停止も実施。そのうえで7月30日にサービスを終了しました。

したがって、現在発生する呼び出しエラーを一時的な障害として扱うべきではありません。再試行では復旧せず、利用先の変更が必要です。

Microsoft Foundryへの移行で何が変わるか

GitHubは、独立したアプリからAIモデルを呼び出す場合の移行先としてMicrosoft Foundryを案内しています。GitHub内でAI支援を利用したい場合はGitHub Copilotが別の選択肢です。

Microsoft Foundryは、モデル、エージェント、ツールをAzure上の管理単位にまとめる開発基盤です。公式ドキュメントでは、Microsoft、OpenAI、Anthropic、Metaなどのモデルを含む1,900以上のモデルを扱えると説明されています。

「すぐ試す」から「配備して管理する」へ

GitHub Modelsでは、あらかじめ用意されたモデルを選び、無料利用枠の制限内で試せました。Foundryでは、利用するモデルをリソースへ追加し、配備したうえでAPIから指定します。

移行後に開発者が管理する項目は増えます。

• Azureサブスクリプションと支払い方法
• Foundryリソースとプロジェクト
• 使用するモデルの配備
• APIの接続先と認証情報
• リージョンごとのモデル提供状況
• 従量課金、プロビジョニング、バッチなどの配備方式
• レート制限とコンテンツフィルター

これは単なるサービス名の変更ではありません。無料の実験環境から、課金・権限・配備を伴う本番向け基盤へ運用責任が移ります。

ここがポイント: APIの呼び出しコードを大幅に書き換えずに移せる場合でも、接続先、キー、モデル配備、課金設定まで自動で引き継がれるわけではありません。

認証とガバナンスは強化できる

FoundryではAPIキーに加え、Microsoft Entra IDを使ったキーレス認証を選択できます。組織はRBAC、ネットワーク分離、Azure Policy、コンテンツフィルターを組み合わせ、誰がどのモデルを利用できるかを管理できます。

さらに、トレース、監視、評価なども同じ基盤で扱えます。個人の検証では設定項目の増加になりますが、企業利用では権限と利用状況を一元管理しやすくなる点が重要です。

移行時に確認すべき技術項目

まず、GitHub ModelsのURLやトークンがソースコード、環境変数、CI/CDのSecretsに残っていないかを調べます。停止したAPIへ再試行を続けると、ジョブの遅延や不要なエラーログにつながります。

1. 利用箇所を洗い出す

次の場所を確認します。

• アプリケーションの環境変数
• GitHub ActionsなどのCI/CD設定
• ローカル開発用の.envやサンプル設定
• バッチ、評価スクリプト、社内デモ
• 運用監視のヘルスチェック

特に、試作コードが定期処理へ転用されている場合は見落としやすいため注意が必要です。

2. 同じモデルを利用できるか確認する

Foundryでは、利用したいモデルを先に配備してからmodelパラメーターで指定します。ただし、モデルの提供状況はリージョンや配備方式によって異なります。

同名モデルへ移せない場合は、代替モデルを選び、次の項目を再評価します。

• 応答形式と指示への追従性
• 最大コンテキスト長
• 構造化出力やツール呼び出しへの対応
• レイテンシーとレート制限
• 入出力トークンの料金
• コンテンツフィルターによる挙動差

モデルを差し替えただけで本番投入せず、既存の評価データを使って結果を比較する必要があります。

3. 接続先と認証を切り替える

Microsoftの移行ガイドでは、Foundry側でモデルを配備し、取得したエンドポイントと認証情報をアプリへ設定する流れが示されています。

API契約が対応していれば、アプリの主要ロジックを保ったまま接続設定を切り替えられる場合があります。一方、APIキーをそのままコードへ埋め込むのではなく、本番環境ではシークレット管理やEntra IDの採用も検討すべきです。

4. 料金と上限を監視する

GitHub Modelsの無料APIには、分・日単位のリクエスト数、トークン数、同時実行数などの制限がありました。Foundryへ移行すると、選んだ配備方式に応じてAzureサブスクリプションへ課金されます。

移行直後は少なくとも次を設定します。

• 予算とコストアラート
• リクエスト数、トークン数、エラー率の監視
• タイムアウトと再試行回数の上限
• 開発・検証・本番環境の分離
• 不要になったモデル配備の停止手順

日本の開発チームへの実務影響

個人開発者にとって最大の変化は、GitHubアカウントだけで完結していた試用経路がなくなったことです。小規模な教材やデモでも、Foundryを選ぶならAzureの契約とリソース設定が必要になります。

企業では、移行を機に検証用APIの扱いを見直せます。担当者個人のトークンで動く仕組みを残さず、組織のID、権限、予算、監視へ組み込むことが重要です。

対象ごとの確認点は次のとおりです。

• 開発者: APIエンドポイント、SDK、モデル名、環境変数を確認する
• 運用担当者: 終了したAPIへのエラーと再試行を監視する
• 管理者: Azureの権限、予算、利用可能リージョンを決める
• プロダクト責任者: モデル変更による品質、速度、料金の差を承認する

継続ウォッチ

今回の終了で見るべきなのは、移行作業の完了だけではありません。

• GitHub Models向けサンプルやテンプレートがどの移行先へ更新されるか
• Foundryで必要なモデルが日本から利用するリージョンに提供されるか
• モデル変更後も構造化出力やツール呼び出しが同じ品質で動くか
• 試作段階の開発者が使える低コストなモデル検証経路がどう整備されるか

今日のまとめ

GitHub Modelsは既に終了しており、待っても復旧しません。推論APIを利用していたチームは、まず参照箇所を洗い出し、Foundryなどの代替基盤へ接続を切り替える必要があります。

最初に行うべき作業は明確です。停止したエンドポイントを探し、影響するジョブを止め、移行先で同じモデルと必要なリージョンを利用できるか確認すること。 コードの変更量より先に、認証、配備、料金、評価の4点を確認するのが安全です。

参照リンク

• GitHub Models is now retired（GitHub Changelog）
• GitHub Models is being fully retired on July 30, 2026（GitHub Changelog）
• GitHub Models is no longer available to new customers（GitHub Changelog）
• Upgrade from GitHub Models to Microsoft Foundry Models（Microsoft Learn）
• What is Microsoft Foundry?（Microsoft Learn）