GitHub Models を使っている場合、今回の「GitHub Models is being fully retired on July 30, 2026」で最初に確認すべきことは明確です。2026年7月30日以降、GitHub Models の Playground、モデルカタログ、Inference API、BYOK は利用できなくなります。 既存利用者も対象で、新規ユーザーだけの制限ではありません。GitHub は移行準備のため、2026年7月16日と7月23日に短時間のサービス中断、いわゆる brownout も予定しています。(The GitHub Blog)
特に注意が必要なのは、GitHub Actions、CLI拡張、独自スクリプト、検証用アプリなどから GitHub Models の API や gh models を呼び出しているケースです。単に画面上の機能が消えるだけでなく、AI要約、プロンプト検証、モデル比較、BYOK 経由のモデル利用などが停止する可能性があります。この記事では、GitHub を利用する管理者、開発者、一般ユーザーが確認すべき変更点と、実務で取るべき対応を整理します。
GitHub Models の廃止で何が変わるのか
GitHub Models は、GitHub 上でAIモデルを試し、プロンプトを管理し、出力を評価するための開発者向け機能でした。公式ドキュメントでは、モデルカタログ、プロンプト管理、定量的な評価などを含む開発者向けツール群として説明されています。(GitHub Docs)
今回の更新では、その GitHub Models が段階的な終了ではなく、2026年7月30日に完全廃止されることが示されました。GitHub は2026年6月16日の時点で新規顧客への提供を停止していましたが、7月1日の更新で、既存利用者を含む全顧客が対象になる最終スケジュールが明らかになりました。(The GitHub Blog)
| 項目 | 変更内容 | 実務上の意味 |
|---|---|---|
| 廃止日 | 2026年7月30日 | 以降は GitHub Models 前提の運用を継続できない |
| 対象者 | すべての顧客 | 既存利用中の組織・Enterprise・個人も対象 |
| 対象機能 | Playground、モデルカタログ、Inference API、BYOK、関連UI | 画面操作だけでなくAPI連携や自動化も影響を受ける |
| 事前中断 | 2026年7月16日、7月23日に短時間の brownout | 一時的にリクエストがエラーになり、復旧後に再開される想定 |
| 推奨先 | Azure AI Foundry、GitHub Copilot | 用途に応じて移行先を分ける必要がある |
「GitHub が使えなくなる」わけではない
今回の対象は GitHub Models です。GitHub のリポジトリ、Issues、Pull requests、Actions、Packages、GitHub Copilot そのものが一括で終了するという発表ではありません。
混同しやすいのは、GitHub Models と GitHub Copilot の違いです。GitHub Models は、複数のAIモデルを試したり、APIで推論リクエストを実行したり、プロンプトをリポジトリで管理したりするための機能でした。一方、GitHub Copilot は、エディタ、GitHub、CLI、開発ワークフロー上でコード作成やレビューなどを支援するAI機能です。GitHub の発表でも、GitHub 上でAIを活用したワークフローを構築する選択肢として GitHub Copilot が案内されています。(The GitHub Blog)
影響が小さいユーザー
次のような使い方であれば、今回の影響は限定的です。
- GitHub をコード管理だけに使っている
- GitHub Copilot のコード補完やチャットだけを使っている
- GitHub Models の Playground や API を使ったことがない
- Organization の Models 設定を有効化していない
ただし、組織内の一部チームが検証目的で GitHub Models を使っている可能性はあります。管理者は「自分は使っていない」ではなく、組織・リポジトリ・Actions・Secrets・ドキュメントに痕跡がないかを確認するのが安全です。
影響を受けやすい利用パターン
GitHub Models は、画面で試すだけでなく、REST API、GitHub Actions、CLI拡張、.prompt.yml ファイルなどと組み合わせて使われるケースがありました。公式ドキュメントでも、Inference API、モデルカタログ、Embeddings、GitHub Actions からの利用例、models: read 権限などが案内されています。(GitHub Docs)
開発者が確認すべき箇所
まずは、リポジトリ内に GitHub Models 依存の設定やコードが残っていないかを確認します。特に次のような文字列は、依存箇所を探す手がかりになります。
rg -n "models.github.ai|gh models|github/gh-models|models: read|\.prompt\.ya?ml|marketplace/models|BYOK|Custom models" .ripgrep を使っていない環境では、grep -R でも構いません。重要なのは、アプリケーションコードだけでなく、.github/workflows/、README、運用手順書、検証用スクリプト、社内テンプレートまで含めて確認することです。
| 確認対象 | 見落としやすいポイント | 対応の方向性 |
|---|---|---|
| アプリケーションコード | 推論APIの呼び出し先が GitHub Models のまま | Azure AI Foundry など別APIへ移行 |
| GitHub Actions | Issue要約、PR説明生成、テスト結果要約などで gh models を利用 | ワークフローを削除、または別プロバイダー呼び出しに変更 |
.prompt.yml | プロンプトがリポジトリに保存されているだけで、運用側が把握していない | 移行先で使う形式に変換、不要ならアーカイブ |
| Secrets / Variables | BYOK や外部モデル用キーが残っている | 不要なキーを失効し、移行先の権限設計に合わせて再発行 |
| 社内ドキュメント | 「GitHub Modelsで試す」といった古い手順が残る | 新しい検証手順に更新 |
管理者が優先して確認すべきポイント
Organization や Enterprise の管理者は、個別リポジトリの修正だけでなく、ガバナンス面の整理が必要です。GitHub Models には、組織で利用できるモデルや発行元を制御する設定、BYOK による独自APIキー連携などがありました。(GitHub Docs)
Organization と Enterprise の設定を棚卸しする
管理者は、まず GitHub Models を有効化していた Organization があるかを確認します。過去に検証目的で有効化しただけでも、チームがその後にワークフローやスクリプトを作っている可能性があります。
確認する観点は次の通りです。
| 観点 | 確認内容 |
|---|---|
| 利用組織 | どの Organization / Enterprise で Models を有効化していたか |
| 利用チーム | 誰が Playground、API、CLI、Actions を使っていたか |
| 利用目的 | 検証、社内ツール、CI/CD、ドキュメント生成、Issue要約など |
| 権限 | models: read、GitHub App、fine-grained PAT の利用有無 |
| キー管理 | BYOK で登録した外部APIキーの有無 |
| コスト管理 | 外部モデルや移行先サービスに移した場合の課金責任者 |
ここで重要なのは、単に「機能が廃止されるからオフにする」ではなく、どの業務が止まるのかを先に洗い出すことです。GitHub Models を試験的に使っていたつもりでも、いつの間にかチームの定例作業に組み込まれていることがあります。
brownout を障害訓練として扱う
GitHub は、完全廃止前の2026年7月16日と7月23日に短時間の brownout を実施すると発表しています。brownout 中は GitHub Models のリクエストが一時的にエラーを返し、その後サービスが復旧する予定です。(The GitHub Blog)
この日は単なる「避けるべき日」ではありません。移行が間に合っていない環境では、次の確認に使えます。
- GitHub Models 依存のジョブがどれだけ残っているか
- エラー時に通知が飛ぶか
- リトライが無限ループにならないか
- 失敗しても本番リリースやデータ処理に影響しないか
- 代替経路へ切り替える手順が実際に機能するか
ただし、brownout の具体的な開始時刻や長さは、記事執筆時点の公式発表だけでは細かく示されていません。運用チームは GitHub Status や公式Changelog、社内の監視アラートを併せて確認できる体制にしておくべきです。
開発者向け：移行作業の進め方
GitHub Models の移行は、単純なURL差し替えだけでは終わらないことがあります。モデルID、認証方式、レスポンス形式、ストリーミング、レート制限、コスト、ログの扱いが移行先によって変わるためです。
まず依存箇所を3分類する
移行作業では、GitHub Models の利用箇所を次の3つに分けると判断しやすくなります。
| 分類 | 例 | 対応 |
|---|---|---|
| 廃止してよいもの | 過去の検証スクリプト、使われていないデモ | 削除またはアーカイブ |
| 置き換えるもの | Issue要約、PR説明生成、社内FAQ生成 | Azure AI Foundry などに移行 |
| Copilot で代替できるもの | コード説明、レビュー補助、開発者個人の調査 | GitHub Copilot の利用手順に変更 |
すべてをAPI移行しようとすると、不要な運用コストが増えます。逆に、業務に組み込まれている自動処理を Copilot の手作業に戻すと、品質や再現性が落ちます。自動化が必要な処理はAPI移行、開発者の作業支援はCopilot活用という切り分けが現実的です。
API移行で確認すべき項目
GitHub Models の Inference API は、チャット補完リクエスト、ストリーミング、モデルID、models: read 権限、組織への利用帰属などを扱っていました。移行先では、これらの対応関係を確認する必要があります。(GitHub Docs)
| 確認項目 | なぜ重要か |
|---|---|
| 認証方式 | GitHub token から Azure / 外部プロバイダーの認証に変わる可能性がある |
| モデルID | openai/gpt-4.1 のようなIDがそのまま使えるとは限らない |
| レスポンス形式 | JSON構造、エラー形式、ストリーミング形式の差で既存コードが壊れる |
| レート制限 | CI/CDやバッチ処理で大量実行している場合に失敗しやすい |
| ログと監査 | プロンプトや出力をどこまで保存するかを再設計する必要がある |
| コスト | テスト用モデルと本番用モデルを分けないと費用が膨らみやすい |
| データ取り扱い | 入力データに個人情報、顧客情報、ソースコードが含まれる場合は確認必須 |
GitHub Actions の置き換えは早めに着手する
GitHub Models は GitHub Actions と組み合わせて、Issue の要約などを自動化する例が公式ドキュメントでも紹介されていました。ワークフロー内で models: read 権限を付与し、gh-models 拡張をインストールして推論を実行する流れです。(GitHub Docs)
このタイプの処理は、廃止日を過ぎるとCI/CDの一部が失敗する可能性があります。特に、Pull request のチェックに組み込んでいる場合は注意が必要です。AI要約が失敗しただけなのに、ブランチ保護ルールによってマージできない、といった副作用が起こることがあります。
対応としては、まずAI処理を必須チェックから外せるか確認します。そのうえで、必要な処理だけを移行先APIに置き換え、失敗時には警告に留めるのか、ジョブ全体を失敗させるのかを決めます。
移行先は Azure AI Foundry と GitHub Copilot を使い分ける
GitHub の発表では、AIモデルアクセスが必要な新規・既存プロジェクトには Azure AI Foundry、GitHub上でAIを活用したワークフローを構築する用途には GitHub Copilot が案内されています。(The GitHub Blog)
Azure AI Foundry が向いているケース
Azure AI Foundry は、アプリケーションや業務システムからAIモデルを呼び出す用途に向いています。特に、API経由の推論、モデル選定、デプロイ、監視、権限管理、コスト管理をきちんと設計したい場合は、GitHub Copilot よりもこちらを検討する場面が多くなります。
向いている例は次の通りです。
- 社内ツールからAI要約や分類を実行している
- GitHub Actions で自動コメントやレビュー補助を行っている
- 独自アプリケーションにAI機能を組み込んでいる
- モデルごとのコストや性能を比較したい
- Azure の認証、ネットワーク、監査ログと統合したい
ただし、Azure AI Foundry へ移せば自動的に同じ挙動になるわけではありません。モデルの種類、リージョン、認証、課金、コンテンツフィルター、データ保持の考え方は、移行前に確認する必要があります。
GitHub Copilot が向いているケース
GitHub Copilot は、開発者の作業支援に向いています。コードの説明、修正案の作成、テストコード生成、Pull request の理解、CLIでの補助など、人が開発作業を進める場面では有力な代替になります。
一方で、GitHub Copilot は「アプリケーションがAPIとして呼び出す推論基盤」の置き換えではありません。たとえば、毎日定時にIssueを要約してコメントする処理や、ユーザー入力を受けてアプリ内で回答を返す処理は、Copilot ではなくAPI型の移行先を検討する必要があります。
BYOK を使っていた組織の注意点
BYOK は、組織が自分たちのLLM APIキーを GitHub Models に持ち込み、カスタムモデルや外部モデルを利用するための仕組みでした。公式ドキュメントでは、BYOK により、ガバナンス、コスト管理、可視性、柔軟性を高める目的が説明されています。(GitHub Docs)
今回の完全廃止では、BYOK も利用できなくなる対象に含まれます。つまり、外部プロバイダーの契約やAPIキー自体が残っていても、GitHub Models を経由する利用経路は使えなくなるという点に注意が必要です。(The GitHub Blog)
BYOK 利用組織は、次の対応を優先してください。
| 対応 | 理由 |
|---|---|
| 登録済みAPIキーの棚卸し | 使われていないキーを放置するとセキュリティリスクになる |
| 移行先でのキー再発行 | 権限スコープやローテーション方針を見直す機会になる |
| GitHub Secrets の整理 | 古いキー名が残ると、誤って旧経路を使い続ける可能性がある |
| 請求先の確認 | GitHub経由から外部プロバイダー直接課金に変わる場合がある |
| 利用ログの確認 | どのチームがどのモデルを使っていたかを把握する |
特に、個人が検証用に作ったAPIキーを Organization に登録していた場合は危険です。退職・異動・権限変更後もキーが生きていると、移行作業中に管理不能な経路が残ります。
7月30日までにやるべき実務チェックリスト
2026年7月30日までの期間は長くありません。すでにGitHub Modelsを使っている組織は、調査、移行、テスト、削除を並行して進める必要があります。
| 期限の目安 | やること | 完了条件 |
|---|---|---|
| すぐ | Organization、リポジトリ、Actions、Secrets を棚卸し | GitHub Models 依存箇所の一覧がある |
| 7月16日まで | 主要な自動化処理の移行方針を決める | 廃止、Azure AI Foundry移行、Copilot代替の分類が済んでいる |
| 7月16日の brownout | 残存依存とエラー通知を確認 | どの処理が失敗するか把握できている |
| 7月23日まで | 重要処理を移行または停止 | 本番運用に必要な処理が GitHub Models に依存していない |
| 7月23日の brownout | 最終リハーサル | エラーが出ても業務影響がない |
| 7月30日まで | 古い設定、キー、ドキュメントを削除 | 旧経路を呼び出すコードや手順が残っていない |
このチェックリストで最も重要なのは、移行作業を「コード修正」だけで終わらせないことです。運用手順、監視、権限、コスト管理、社内説明まで含めて完了と考える必要があります。
よくある誤解と注意点
GitHub Copilot を使っていれば影響はない？
GitHub Copilot のコード補完やチャットだけを使っている場合、今回の GitHub Models 廃止の直接影響は基本的に限定的です。ただし、Copilot とは別に GitHub Models の API や Playground を使っているチームがある場合は影響を受けます。組織管理者は、Copilot の契約状況だけで判断しない方が安全です。
Playground の実験結果は残る？
GitHub の発表では、廃止後に Playground や関連UIが利用できなくなるとされています。重要なプロンプト、比較結果、評価メモを画面上だけに置いている場合は、廃止前にリポジトリ、ドキュメント、移行先ツールへ退避しておくべきです。(The GitHub Blog)
GitHub Models は本番利用前提だったのか？
公式ドキュメントでは、GitHub Models は学習、実験、PoC用途を想定しており、本番用途向けには設計されていない旨が説明されています。(GitHub Docs) そのため、本番相当の処理に組み込んでいた場合は、今回の廃止を機に、SLA、監視、データ保護、コスト管理を含めたAI基盤へ移すのが現実的です。
brownout でエラーが出なければ安心？
安心とは限りません。brownout は短時間の予定中断であり、すべての依存箇所が必ずその時間に実行されるとは限りません。定時バッチ、手動実行のスクリプト、月次処理、特定イベント発火のActionsは、brownout中に動かない可能性があります。コード検索とログ確認を併用してください。
まとめ：GitHub Models 利用者は「使っているか分からない」をなくすことが最優先
「GitHub Models is being fully retired on July 30, 2026」は、GitHub Models の完全廃止を知らせる重要な更新です。2026年7月30日以降、Playground、モデルカタログ、Inference API、BYOK、関連UIは利用できなくなり、既存利用者も対象になります。さらに、7月16日と7月23日には brownout が予定されています。(The GitHub Blog)
まず行うべきことは、GitHub Models を使っているかどうかを曖昧にしないことです。リポジトリ、GitHub Actions、.prompt.yml、gh models、models.github.ai、BYOK、Secrets を確認し、廃止してよいもの、Azure AI Foundry などへ移すもの、GitHub Copilot で代替するものに分けましょう。
管理者は、キーや権限、請求、社内手順の整理まで含めて対応する必要があります。開発者は、API差し替えだけでなく、レスポンス形式、エラー処理、レート制限、コスト、ログ設計を確認してください。7月30日を待つのではなく、brownout を移行リハーサルとして使い、廃止日までに GitHub Models 依存をゼロにすることが安全な対応です。
コメント