GitHubは、GitHub Modelsを2026年7月30日に全面終了すると発表しました。
終了するのは、一部の古いモデルだけではありません。プレイグラウンド、モデルカタログ、推論API、Bring Your Own Key（BYOK）のエンドポイントを含む、GitHub Models全体です。すでに利用しているユーザーも対象になります。
2026年7月28日時点では、終了予定日まで残り2日です。
過去にGitHub Modelsを試したことがある人は、サンプルコードやGitHub Actions、社内ツールなどに設定が残っていないか、早めに確認したほうがよいでしょう。
特に注意したいのは、移行先として案内されているMicrosoft FoundryとGitHub Copilotでは、役割が大きく異なる点です。
AIモデルをアプリケーションからAPIで呼び出しているなら、Microsoft Foundryなどの推論基盤が移行候補になります。一方、コード補完やリポジトリ上の開発支援が目的なら、GitHub Copilotが候補です。
単純に「GitHub ModelsからGitHub Copilotへ切り替えればよい」と考えると、必要な機能を置き換えられない可能性があります。
GitHub Modelsは2026年7月30日に全面終了する
GitHubは2026年7月1日、GitHub Modelsを同年7月30日に全面終了すると発表しました。
2026年6月には新規利用者の受け付けが終了していましたが、7月30日以降は既存利用者を含むすべてのユーザーが利用できなくなります。GitHubは終了前の準備として、7月16日と7月23日に短時間の計画停止も実施しました。
終了対象として明示されている主な機能は次のとおりです。
| 終了する機能 | 主な用途 | 想定される影響 |
|---|---|---|
| モデルプレイグラウンド | ブラウザ上でプロンプトやモデルを試す | 保存していた検証手順を同じ画面で再現できなくなる |
| モデルカタログ | 利用可能なモデルの検索や比較 | GitHub上でのモデル選定ができなくなる |
| 推論API | スクリプト、アプリ、GitHub Actionsからモデルを呼び出す | APIを利用している処理が失敗する |
| BYOKエンドポイント | 組織が保有するAPIキーでモデルを利用する | GitHub Modelsを経由したモデル呼び出しができなくなる |
| 関連する画面 | 設定、比較、利用管理 | GitHub上の関連UIが削除される |
GitHub Modelsは、GitHubの認証情報を使って複数のAIモデルを試せる推論サービスです。ブラウザのプレイグラウンドだけでなく、スクリプト、アプリケーション、GitHub ActionsからAPIを実行できました。
そのため、「画面上で何度か試しただけ」と思っていても、検証時に作ったコードが別の場所で動いている可能性があります。
影響を受けるのはプレイグラウンド利用者だけではない
GitHub Modelsの終了という名称から、モデルを比較する画面だけが使えなくなるように見えるかもしれません。
しかし、実際には推論APIやBYOKエンドポイントも終了します。
次のような使い方をしている場合は、システムへの影響を確認する必要があります。
- GitHub ActionsでIssueやPull Requestを要約している
- ソースコードの説明文やドキュメントを自動生成している
- 社内向けの小規模なチャットツールを作った
- モデルの回答を比較する検証スクリプトを作った
- GitHubのPersonal Access TokenでAIモデルを呼び出している
- GitHub ModelsのURLを環境変数に設定している
- BYOKを設定し、外部モデルをGitHub経由で呼び出している
GitHubの公式クイックスタートでは、GitHub Modelsの呼び出し先としてmodels.github.aiドメインの推論エンドポイントが案内されています。また、API利用時にはGitHubのトークンを使用します。
コードや設定ファイルにこの情報が残っている場合、7月30日以降に処理が失敗する可能性があります。
最初にやるべきことは利用箇所の棚卸し
移行先を契約する前に、GitHub Modelsをどこで使っているかを洗い出します。
利用状況が分からないまま移行を始めると、使われていない処理に時間をかけたり、反対に本番処理を見落としたりします。
リポジトリ内を文字列検索する
まず、対象になりそうなリポジトリで次の文字列を検索します。
models.github.ai
/inference/
/chat/completions
github-models
models: readエンドポイントを環境変数に入れている場合は、文字列が直接コードに書かれていないこともあります。その場合は、AIモデルの接続先を表す変数名や設定ファイルも確認します。
.env
.env.example
config/
.github/workflows/
docker-compose.yml
appsettings.json
application.yml
README.mdGitHub上では、組織やリポジトリを対象にコード検索する方法もあります。ローカルへ複数のリポジトリを取得している場合は、ripgrepなどで横断検索すると見つけやすくなります。
GitHub Actionsを確認する
.github/workflows以下のYAMLファイルは特に確認が必要です。
GitHub ModelsはGitHub Actionsからも呼び出せたため、Issueの分類、Pull Requestの説明文作成、リリースノートの下書き、テスト失敗ログの要約、ドキュメント生成、定期実行される文章処理などに組み込まれている可能性があります。
毎日動くワークフローなら異常に気づきやすいものの、月末やリリース時だけ実行される処理は見落としやすくなります。ワークフローのファイルだけでなく、過去の実行履歴も確認してください。
Secretsとトークンを確認する
リポジトリやOrganizationのSecretsに、GitHub Models用の認証情報や外部モデルのAPIキーを登録していることがあります。
Secretの値そのものは通常表示できません。名前、利用しているワークフロー、最終更新の経緯を確認し、不要になったものを整理します。
GitHub Modelsで利用していたトークンが、ほかのGitHub APIにも使われている場合は、すぐに削除してはいけません。権限と利用箇所を調べたうえで、不要な権限だけを減らす必要があります。
移行先は利用目的で決める
GitHubは、AIモデルへアクセスする必要があるプロジェクトにはMicrosoft Foundry、GitHub上でAIを使った開発作業を行う場合にはGitHub Copilotを案内しています。
ただし、この2つは同じ用途のサービスではありません。
| 現在の使い方 | 移行候補 | 判断のポイント |
|---|---|---|
| アプリやバッチから推論APIを呼び出す | Microsoft Foundry、またはモデル提供元のAPI | API互換性、料金、モデル、リージョン、認証方式 |
| 複数モデルを比較・検証する | Microsoft Foundryなどのモデルカタログ | 評価機能、利用可能モデル、検証コスト |
| IDEでコード補完や質問を行う | GitHub Copilot | 対応IDE、プラン、利用上限 |
| Issueを基にコード変更やPR作成を任せる | GitHub Copilotのエージェント機能 | リポジトリ権限、レビュー手順、費用 |
| 独自の社内ツールからAIを呼ぶ | Microsoft Foundryまたは直接API | データ管理、認証、監視、障害時の切り替え |
APIを使うならMicrosoft Foundryが有力候補
Microsoftは、GitHub ModelsからMicrosoft Foundry Modelsへ移行するための公式手順を公開しています。
GitHub Modelsは無料の実験用途を想定したレート制限付きサービスでした。一方、Foundry Modelsへ移行すると、利用量は選択したデプロイ方式に応じてAzureサブスクリプションへ課金されます。利用には有効な支払い方法を登録したAzureサブスクリプションが必要です。
Microsoftの移行ガイドでは、Foundryのキーとエンドポイントを取得し、利用するモデルをデプロイしたうえで、プレイグラウンドからテストする流れが説明されています。
公式資料上は、キーとエンドポイントを切り替えることで、既存コードの大部分を維持できる構成が想定されています。ただし、実際の移行では、エンドポイントの形式、認証方法、SDKとバージョン、モデル名とデプロイ名、リクエストパラメーター、ストリーミングの形式、エラーコード、レート制限、出力内容、利用料金を確認したほうが安全です。
Foundryでは認証と運用機能が変わる
Microsoft Foundry Modelsでは、複数のモデルを1つのリソースで管理でき、Microsoft Entra IDを利用したキーレス認証、コンテンツフィルター、モデルごとのレート制限、複数のデプロイ方式などを利用できます。
チームや企業で利用する場合は、APIキーを各アプリへ直接配布するより、Entra IDによる認証を選べることが利点になる場合があります。
一方、設定項目が増えるため、個人で試すだけの用途ではGitHub Modelsより準備が重く感じられるかもしれません。
また、モデルによって利用可能なリージョンやデプロイ方式が異なる場合があります。現在使っているモデルと同じ名称がカタログにあっても、希望するリージョンで利用できるとは限りません。
SDKの選択にも注意する
Microsoftの公式ドキュメントでは、Azure AI InferenceのベータSDKが2026年8月26日に終了予定であり、安定版のOpenAI SDKを使ったOpenAI/v1 APIへの移行が案内されています。
GitHub Modelsの終了に合わせて新しい実装へ変更するなら、短期間で再び終了予定のSDKへ移行しないよう注意が必要です。
開発支援が目的ならGitHub Copilot
GitHub Copilotは、コード補完、開発に関するチャット、コードレビュー、エージェントによるコード変更などを提供するAIコーディング支援サービスです。
GitHub Modelsのプレイグラウンドでコードについて質問していた人や、開発作業を効率化するためにモデルを使っていた人は、Copilotで目的を満たせる可能性があります。
ただし、Copilotは一般的な推論APIの置き換えではありません。独自アプリケーションから任意の文章を送り、モデルの結果をAPIレスポンスとして受け取っている場合、Copilotへ契約を変更するだけでは既存システムは動きません。
- 開発者自身の作業を支援するならGitHub Copilot
- アプリケーションの機能としてAIを組み込むなら推論API
- モデル比較や評価を行うならモデル基盤
- リポジトリ上のIssueからコード変更まで任せるならCopilotのエージェント機能
Microsoft Foundry以外への移行も検討できる
現在利用しているモデルの提供元が直接APIを提供している場合、そのAPIへ移行する方法もあります。
直接APIを使えば構成が単純になることがありますが、複数モデルを切り替える仕組み、認証、監視、課金管理などを自分で設計する必要があります。
移行先は知名度だけで決めず、必要なモデルを継続して使えるか、日本から契約・利用できるか、商用利用の条件、データ利用方針、処理地域、レート制限、障害情報、課金管理、チームでの認証情報管理、将来のモデル変更のしやすさまで確認します。
実務で進める移行手順
終了日が近いため、最初から完璧な構成を目指すより、影響のある処理を止めないことを優先します。
1. 利用中の処理を一覧にする
| 確認項目 | 記録する内容 |
|---|---|
| システム名 | どのアプリ、バッチ、ワークフローか |
| 管理者 | 誰が判断・修正できるか |
| 実行頻度 | 常時、毎日、月次、手動など |
| 重要度 | 停止した場合の業務影響 |
| 利用モデル | 現在指定しているモデル |
| 認証方法 | PAT、GitHub App、BYOKなど |
| 入力データ | 公開情報、ソースコード、顧客情報など |
| 移行先 | Foundry、Copilot、直接API、廃止 |
| 対応状況 | 未確認、検証中、切り替え済み |
2. 不要な処理は廃止する
過去の検証コードをすべて別サービスへ移す必要はありません。一度だけ使用したサンプルや、現在は使われていないワークフローは、停止または削除するほうが管理負担を減らせます。
3. 移行先で同じモデルを利用できるか確認する
モデル名が似ていても、提供されているバージョンや機能が異なる場合があります。入力データ形式、最大入力サイズ、構造化出力、ツール呼び出し、ストリーミング、出力トークン上限、コンテンツフィルター、リージョン、レート制限、料金を確認します。
4. 認証情報を切り替える
移行先のキーや認証設定を準備し、開発環境で接続を確認します。本番環境のSecretを直接書き換える前に、別名のSecretとして登録し、切り替え前後を選べる構成にすると戻しやすくなります。
AI_ENDPOINT
AI_MODEL
AI_DEPLOYMENT
AI_AUTH_TYPE5. 代表的な入力で比較テストする
移行テストでは、「返事が返ってきた」だけで完了にしません。回答の正確さ、指示への従いやすさ、出力形式、応答時間、エラー率、トークン使用量、1回あたりの費用、不適切な出力の発生、日本語の自然さを比較します。
6. 段階的に切り替える
可能であれば、いきなり全処理を新しい接続先へ向けず、開発環境、検証環境、本番環境の順で切り替えます。
本番では、APIの成功率、タイムアウト数、レート制限エラー、入出力トークン数、利用金額、処理時間、想定外の応答、後続処理の失敗を監視します。
7. 不要になった認証情報を整理する
移行が完了したら、古いSecret、Personal Access Token、BYOK設定などを整理します。ただし、切り替え直後にすべて削除すると、問題が起きた際に調査しにくくなる場合があります。
移行時に起こりやすい失敗
GitHub CopilotをAPIの代わりだと考える
最も起こりやすいのは、GitHubがCopilotを案内しているため、推論APIもCopilotで置き換えられると判断することです。まず、AIを使っているのが「開発者」なのか「アプリケーション」なのかを整理してください。
エンドポイントだけを変更する
Microsoftの資料ではコードを大きく変更せずに移行できる構成が説明されていますが、モデルのデプロイ、認証、レート制限、リージョンなどは確認が必要です。
無料利用と同じ感覚で実行する
GitHub Modelsは、モデルの実験を始めるための無料API利用を提供していました。Foundry Modelsへ移行した後は、選択したデプロイ方式に応じてAzureサブスクリプションへ課金されます。
同じモデルなら同じ回答になると考える
同じ系統のモデルでも、バージョン、システム設定、コンテンツフィルター、既定パラメーターが変われば出力は変化します。
移行作業で機密情報を使う
動作確認を急ぐと、本番データをそのまま新しいサービスへ送ってしまうことがあります。契約条件やデータ処理の確認が終わるまでは、匿名化したデータやテスト用データを使用するほうが安全です。
GitHub Modelsを使っていない人への影響
GitHub Modelsを利用しておらず、GitHub Copilotだけを使っている場合、今回の発表はCopilot自体の終了を意味するものではありません。
ただし、過去にGitHub Marketplaceのモデル画面を試した、サンプルからGitHub Actionsを作った、個人用のPATでAPIを実行した経験がある人は、念のためコード検索を行う価値があります。
2026年7月30日までに確認したいチェックリスト
models.github.aiをコード検索した.github/workflowsを確認した- GitHub Modelsを呼ぶバッチやアプリを確認した
- OrganizationとリポジトリのSecretsを確認した
- BYOKを利用していないか確認した
- 処理ごとの管理者を決めた
- 不要な処理と移行する処理を分けた
- API利用と開発支援を区別した
- 移行先で必要なモデルを使えるか確認した
- Azureの契約、リージョン、料金を確認した
- 開発環境で接続テストを行った
- 実際に近い入力で出力を比較した
- エラー処理とレート制限を確認した
- 本番切り替え後の監視方法を決めた
- 不要になるトークンの削除手順を決めた
まとめ
GitHub Modelsは、2026年7月30日に全面終了します。
プレイグラウンドだけでなく、モデルカタログ、推論API、BYOKエンドポイントも利用できなくなり、既存利用者も対象です。
対応の最初の一歩は、新しいサービスを契約することではありません。コード、GitHub Actions、Secrets、BYOK設定を確認し、GitHub Modelsを実際にどこで使っているかを把握することです。
移行先は用途によって分かれます。アプリケーションからAIモデルを呼び出すなら、Microsoft Foundryやモデル提供元のAPIが候補です。コード補完、質問、レビュー、Issueからのコード変更など、開発者の作業を支援する目的ならGitHub Copilotが候補になります。
移行時は、エンドポイントだけでなく、認証、モデル、リージョン、料金、レート制限、データの取り扱い、SDKの終了予定まで確認する必要があります。
終了直前にすべてを作り直そうとすると、テストが不足しやすくなります。まずは業務影響の大きい処理を特定し、停止回避、動作確認、運用改善の順で対応するのが現実的です。
コメント