GitHub Modelsが7月30日に終了、AI推論API移行で確認すべき点｜2026年7月24日版
GitHub Modelsは、2026年7月30日に全面終了します。プレイグラウンドだけでなく、モデルカタログ、推論API、BYOKエンドポイントも利用できなくなるため、検証コードや社内ツールからAPIを呼び出している場合は移行が必要です。
GitHubが移行先として案内しているのはMicrosoft Foundryです。ただし、認証情報を置き換えるだけで終わるケースでも、モデルのデプロイ、課金、リージョン、レート制限を事前に確認しなければなりません。
- 終了日：2026年7月30日
- 対象：既存利用者を含むすべての顧客
- 終了する機能：プレイグラウンド、モデルカタログ、推論API、BYOK
- 主な移行先：Microsoft Foundry
GitHub Models終了で何が止まるのか
今回の終了は、一部モデルの提供停止ではありません。GitHub Modelsというサービス全体が対象です。
GitHubの公式発表によると、7月30日以降は次の機能が利用できなくなり、関連する画面も削除されます。
- ブラウザ上でモデルを試すプレイグラウンド
- 利用可能なモデルを探すモデルカタログ
- アプリケーションから呼び出す推論API
- 利用者自身のAPIキーを接続するBYOKエンドポイント
6月には新規顧客の受け付けが終了していました。今回は既存顧客にも範囲が広がるため、現在動いている処理も例外ではありません。
GitHubは7月16日と23日に短時間のブラウンアウトを予定していました。これはリクエストを一時的にエラーにし、依存箇所を発見しやすくするための事前停止です。7月24日時点では、全面終了まで残された確認期間はわずかです。
移行先のMicrosoft Foundryは何が違うのか
Microsoft Foundryでも、複数の提供元からモデルを選び、API経由で推論できます。一方、GitHub Modelsの無料実験環境と同じ感覚では扱えません。
モデルを自分のリソースへ追加する
GitHub Modelsでは、対応モデルがあらかじめ利用できる状態でした。Foundryでは、利用予定のモデルをリソースへ追加し、デプロイしてから呼び出します。
Microsoftの移行ガイドは、対応する構成であればアプリケーションコードの大幅な変更は不要と説明しています。主にキーとエンドポイントを切り替えますが、その前に次の作業が発生します。
- AzureサブスクリプションとFoundryリソースを用意する
- 使用するモデルを選択してデプロイする
- プレイグラウンドで応答を確認する
- 新しいキーとエンドポイントをアプリへ設定する
- 実データに近い入力で回帰テストを行う
ここがポイント: APIの書式が近くても、利用できるモデル、認証情報、課金主体、リージョン、制限値は環境ごとに確認が必要です。
無料枠からAzure課金へ変わる
GitHub Modelsは、リクエスト数やトークン数などに上限がある無料の実験環境として提供されていました。Foundryへ移ると、選択したデプロイ方式に応じてAzureサブスクリプションへ料金が発生します。
Foundryの主な実行方式には、以下の違いがあります。
- サーバーレスデプロイ：Microsoftが管理するAPIを利用し、一般に入出力トークン量に応じて課金
- マネージドコンピュート：専用の計算資源へモデルを配置し、使用する仮想マシンのコア時間などに応じて課金
モデルによって選べる方式は異なります。移行時は単価だけでなく、想定トークン量、同時実行数、待ち時間も含めて見積もる必要があります。
開発者が7月30日までに確認する項目
最優先は、GitHub Modelsへの依存箇所を漏れなく探すことです。個人の検証スクリプトだけでなく、CI、デモ環境、社内ボット、教材のサンプルコードも対象になります。
1. エンドポイントとシークレットを検索する
リポジトリ、CI/CD設定、シークレット管理サービスを確認し、GitHub Models用のエンドポイントやトークンが残っていないか洗い出します。
確認対象は次の通りです。
- アプリケーションの環境変数
- GitHub ActionsなどのCI設定
- 組織・リポジトリ単位のSecrets
- 開発者PCのローカル設定
- 手順書やサンプルコード
- 定期実行バッチと検証用Notebook
2. 同じモデルが移行先で使えるか調べる
Foundryのカタログには、Microsoft、OpenAI、Meta、Mistral、NVIDIA、Hugging Faceなどのモデルがあります。ただし、すべてのモデルが同じリージョンやデプロイ方式で使えるわけではありません。
同名のモデルが見つからない場合は、代替モデルで次の項目を比較します。
- 出力品質と指示追従性
- コンテキスト長と最大出力
- ツール呼び出しや構造化出力への対応
- 応答時間と同時実行性能
- 入出力トークンの料金
- データ処理条件と利用規約
モデルを変更すると、文章の長さやJSONの形式、拒否応答の傾向が変わることがあります。疎通確認だけでなく、代表的な入力セットによる回帰テストが必要です。
3. 認証と障害時の動作を見直す
移行後はAPIキーに加え、Microsoft Entra IDを使ったキーレス認証も選択できます。業務システムでは、固定キーを配布するよりも、権限と有効期間を管理しやすい認証方式を検討する価値があります。
同時に、次の失敗を想定した処理も確認します。
- 認証エラー
- レート制限
- モデル未デプロイによるエラー
- 対象リージョンでの利用不可
- タイムアウトや一時的なサービス障害
GitHub Copilotは推論APIの代替ではない
GitHubは、GitHub上でAI支援を使う選択肢としてGitHub Copilotも案内しています。ただし、CopilotとFoundryでは役割が異なります。
- GitHub Copilot：コード作成、レビュー、GitHub上の作業支援
- Microsoft Foundry：アプリケーションへ組み込むモデルの選択、デプロイ、推論APIの提供
そのため、GitHub Modelsをアプリのバックエンドとして使っている場合、Copilotへ置き換えるのではなく、Foundryなどの推論基盤へ移すのが基本です。
日本の開発現場への影響
影響を受けやすいのは、GitHub Modelsを「無料で試せるAPI」として採用し、そのまま検証環境や小規模ツールに残しているチームです。
担当者は、7月30日までに少なくとも以下を終える必要があります。
- 利用中のエンドポイントとモデルを一覧化する
- 移行先のモデル、リージョン、料金を決める
- 新しい認証情報を安全に配布する
- 主要プロンプトと構造化出力を再テストする
- 旧API停止時に利用者へ表示するエラーを確認する
教材やハンズオンを公開している組織も注意が必要です。古い手順は、読者がそのまま実行しても7月30日以降は動きません。リンク、画面キャプチャ、環境変数名まで含めた更新が求められます。
継続ウォッチ
GitHub Modelsの終了後も、モデル移行は一度で完了するとは限りません。Foundry側でもモデルの廃止やバージョン更新が行われるためです。
今後は次の点を継続して確認します。
- 使用モデルの提供地域と廃止予定
- デプロイ方式ごとの料金・クォータ変更
- 旧エンドポイントへのアクセスが残っていないか
- 代替モデルでの品質、速度、コストの変化
7月30日までに必要なのは、まず旧APIへの依存をなくすことです。 そのうえで、モデル名を設定から切り替えられる構成や回帰テストを整えれば、次のモデル更新にも対応しやすくなります。