MENU

GitHub Models完全廃止でAPIが使えない原因とMicrosoft Foundryへの移行手順

AI

GitHub Models APIが突然使えなくなった場合、原因は一時的な障害やトークンの期限切れではありません。GitHub Modelsは2026年7月30日に完全廃止され、既存の利用実績がある顧客を含め、すべてのユーザーが利用できなくなりました。 Playground、モデルカタログ、推論API、Bring Your Own Key（BYOK）のいずれも提供を終了しています。(The GitHub Blog)

自社アプリやシステムから生成AIモデルを呼び出していた場合は、Microsoft Foundryへ移行するのが基本です。一方、Issueの分類、Pull Requestのレビュー、ドキュメント更新など、GitHub上の開発作業をAIで支援したい場合は、GitHub Copilotへの置き換えを検討します。両者は役割が異なるため、単純に「GitHub ModelsをすべてCopilotへ置き換える」と考えないことが重要です。(The GitHub Blog)

目次

GitHub Models APIが使えない原因は2026年7月30日の完全廃止

GitHubは2026年7月30日、GitHub Modelsの廃止完了を正式に発表しました。廃止対象には無料利用だけでなく、有料利用や既存顧客のアクティブな利用も含まれます。設定変更やプラン変更によって再開する方法はありません。(The GitHub Blog)

GitHub Modelsの機能2026年7月30日以降の状態必要な対応
Playground利用不可Microsoft FoundryのPlaygroundなどへ移行
モデルカタログ利用不可Microsoft Foundryのモデルカタログで選定し直す
推論API利用不可Foundry Modelsのエンドポイントへ変更
BYOK利用不可Foundry側の認証またはモデル提供元との接続方式へ変更
既存顧客の利用枠利用不可利用実績に関係なく移行が必要
GitHub Modelsの関連UI削除GitHub上からの再設定はできない

GitHub Modelsの廃止前には、2026年7月16日と23日に短時間のサービス停止が実施されていました。しかし、7月30日以降に発生しているエラーは移行準備用の一時停止ではなく、サービスそのものの終了によるものです。(The GitHub Blog)

GitHub Copilotまで廃止されたわけではない

GitHub ModelsとGitHub Copilotは別のサービスです。GitHub公式ドキュメントでも、GitHub ModelsはGitHub Copilotとは別個のサービスであり、Copilotサービスとは関係がないと明記されています。(GitHub Docs)

そのため、次のような判断は誤りです。

  • GitHub Modelsが廃止されたのでGitHub Copilotも使えない
  • GitHub Models APIのURLをCopilotのURLに変えれば動く
  • GitHub Copilotの契約があれば、従来の推論APIも継続できる

GitHub Copilotは、コード生成、コードレビュー、エージェント、リポジトリ上の自動化などを支援するサービスです。自社アプリから任意のプロンプトを送信する汎用的な推論APIが必要な場合は、Microsoft Foundryを選ぶ必要があります。

リポジトリ内に残っているGitHub Modelsの呼び出しを調べる

移行作業では、最初にGitHub Modelsを呼び出しているコード、GitHub Actions、環境変数を洗い出します。

リポジトリのルートで、次のような検索を実行します。

git grep -nE \
'models\.github\.ai|models\.inference\.ai\.azure\.com|/inference/chat/completions|/inference/embeddings|/catalog/models'

特に確認すべき場所は次のとおりです。

  • .github/workflows/内のGitHub Actions
  • アプリケーションのAPIクライアント設定
  • .env.exampleや設定ファイル
  • Dockerfileやコンテナの環境変数
  • Terraform、Bicepなどのインフラ定義
  • リポジトリ、Environment、Organizationに登録したSecrets
  • サーバーレス関数やバッチ処理
  • Dependabot、Issue、Pull Requestを処理する独自Action

旧GitHub Modelsで使われていた代表的なURLは、次の形式です。

https://models.github.ai/inference

このURLを呼び出しているコードは、GitHubトークンを更新しても復旧しません。エンドポイントそのものをMicrosoft Foundryへ変更する必要があります。

また、さらに古いコードでは次のURLが残っている場合があります。

https://models.inference.ai.azure.com

この旧Azureエンドポイントは、GitHub Models本体の完全廃止より前に非推奨となり、2025年10月17日にサポートが終了しています。このURLが見つかった場合も、途中でmodels.github.aiへ置き換えるのではなく、Microsoft Foundryへ直接移行します。(The GitHub Blog)

GitHub Modelsの移行先は用途によって選ぶ

GitHubが案内している主な移行先は、Microsoft FoundryとGitHub Copilotです。ただし、この2つは競合するサービスではなく、担当する範囲が異なります。(The GitHub Blog)

利用目的適した移行先判断理由
Webアプリや業務システムからモデルを呼び出すMicrosoft Foundryアプリ向けの推論エンドポイントを利用できる
REST APIやSDKでモデルを呼び出すMicrosoft FoundryAPIキーまたはMicrosoft Entra IDで認証できる
複数モデルを比較、評価、切り替えるMicrosoft Foundryモデルカタログとモデルデプロイを利用できる
Issueを分類するGitHub CopilotまたはMicrosoft FoundryGitHub内で完結するならCopilot、独自処理ならFoundry
Pull RequestをレビューするGitHub CopilotGitHubのコードレビュー機能と統合しやすい
CI失敗の調査や修正案を作るGitHub Copilotリポジトリや開発環境の文脈を利用できる
厳密なJSON形式で外部システムへ結果を渡すMicrosoft FoundryAPI応答と後続処理をアプリ側で制御しやすい
自社サービスに生成AI機能を組み込むMicrosoft Foundry認証、課金、レート制限、モデル設定を管理できる

Microsoft Foundryを選ぶべきケース

次の条件に当てはまる場合は、Microsoft Foundryへの移行が基本です。

  • Python、JavaScript、C#、Javaなどから推論APIを呼び出している
  • チャットボット、検索、要約、分類機能を自社アプリに組み込んでいる
  • ストリーミング応答を利用している
  • Embeddings APIでベクトル検索を実装している
  • Function Callingやツール呼び出しを利用している
  • モデル、リージョン、スループット、コンテンツフィルターを管理したい
  • Azureの課金、RBAC、監査、組織ポリシーに統合したい

Microsoft Foundry Modelsでは、複数のモデル提供元のモデルを、共通のエンドポイントと資格情報で利用できる構成が用意されています。モデルは事前に「デプロイ」し、リクエストではモデル名ではなく、基本的にそのデプロイ名を指定します。(Microsoft Learn)

GitHub Copilotを選ぶべきケース

次のような処理であれば、GitHub Models APIを別の推論APIへ機械的に移植するより、GitHub Copilotの機能へ作り直した方が運用しやすい可能性があります。

  • Issueの内容を読んでラベルを付ける
  • Pull Requestの変更内容をレビューする
  • CIの失敗原因を調査する
  • コード変更に合わせてドキュメントを更新する
  • テストコードや修正案を生成する
  • リポジトリの活動状況を定期的にまとめる

GitHub Agentic Workflowsでは、自然言語による指示をMarkdownで定義し、GitHub Actions上でリポジトリ作業を自動化できます。ただし、2026年8月時点ではパブリックプレビューの機能が含まれるため、本番利用では仕様変更、利用条件、組織ポリシーを確認する必要があります。(GitHub Docs)

GitHub ModelsからMicrosoft Foundryへ移行する手順

現在の利用方法を棚卸しする

エンドポイントだけを変更する前に、現在のGitHub Models利用状況を整理します。

確認項目確認する内容
呼び出し元Webアプリ、バッチ、GitHub Actions、ローカルスクリプト
APIの種類Chat Completions、Embeddings、ストリーミング
モデルモデル名、バージョン、用途
入出力テキスト、画像、JSON、ツール呼び出し
認証GITHUB_TOKEN、PAT、BYOK
利用量1分当たりのリクエスト数、トークン数、ピーク時間
品質要件応答精度、速度、再現性、最大コンテキスト長
障害対策タイムアウト、再試行、フォールバック
コスト管理利用上限、予算アラート、環境別の課金分離

この棚卸しを行わずにモデルを選び直すと、ストリーミングが動かない、コンテキスト長が不足する、Embeddingの次元数が変わるといった問題が起こりやすくなります。

Microsoft Foundryのリソースとモデルデプロイを作成する

Microsoft Foundryで推論APIを利用するには、Azureサブスクリプション、Foundryリソース、少なくとも1つのモデルデプロイが必要です。利用したいモデルが対象リージョンで提供されているかも確認します。(Microsoft Learn)

基本的な流れは次のとおりです。

  1. Azureサブスクリプションを用意する
  2. Microsoft Foundryでリソースまたはプロジェクトを作成する
  3. モデルカタログから利用するモデルを選ぶ
  4. 対応リージョンとデプロイ方式を確認する
  5. モデルをデプロイする
  6. Playgroundからテストプロンプトを送る
  7. エンドポイントと認証方法を確認する
  8. 利用上限、予算、コンテンツフィルターを設定する

MicrosoftのAI開発基盤は、Azure AI Studio、Azure AI Foundryを経て、現在はMicrosoft Foundryという名称になっています。画面や古いドキュメントに「Azure AI Foundry」という表記が残っている場合がありますが、名称変更の過程によるものです。(Microsoft Learn)

新規移行ではOpenAI v1 APIを選ぶ

Microsoft Foundryへの移行では、安定版のOpenAI SDKとOpenAI v1 APIを利用する構成が推奨されます。

注意したいのは、Azure AI Inference beta SDKが2026年8月26日に廃止予定であることです。GitHub Modelsからの移行先として、この終了間近のベータSDKを新たに採用すると、短期間で再度移行が必要になります。Microsoftは、OpenAI v1 APIと安定版OpenAI SDKへの移行を案内しています。(Microsoft Learn)

障害復旧を優先する場合は、次の順序で進めると安全です。

  1. 既存のChat Completions相当の処理をOpenAI v1 APIへ移す
  2. 既存アプリが正常に動くことを確認する
  3. その後、必要に応じてResponses APIや新しい機能へ移行する

インフラ移行とAPI設計の刷新を同時に行うと、障害原因を切り分けにくくなります。

エンドポイント、認証、モデル指定を変更する

GitHub ModelsからMicrosoft Foundryへ移行するとき、最低限見直すべき項目は次の3つです。

設定項目GitHub ModelsMicrosoft Foundry
エンドポイントhttps://models.github.ai/inferencehttps://<resource>.openai.azure.com/openai/v1/
認証GitHubトークン、BYOKFoundryのAPIキーまたはMicrosoft Entra ID
modelの値GitHub ModelsのモデルIDFoundryで作成したデプロイ名
モデル準備カタログ内のモデルを選択利用するモデルを事前にデプロイ
課金管理GitHub側の利用枠やBYOKAzureサブスクリプションとデプロイ方式

Microsoft Foundryでは、デプロイがモデルへのアクセス用エイリアスとして機能します。旧コードに書かれていたモデルIDをそのまま指定するのではなく、Foundryで設定したデプロイ名をmodelへ渡します。(Microsoft Learn)

PythonコードをOpenAI v1 APIへ変更する例

OpenAI SDKをインストールします。

pip install --upgrade openai

環境変数には、Foundryのエンドポイント、APIキー、デプロイ名を設定します。

export FOUNDRY_BASE_URL="https://<resource>.openai.azure.com/openai/v1/"
export FOUNDRY_API_KEY="<your-api-key>"
export FOUNDRY_DEPLOYMENT="<your-deployment-name>"

Pythonコードは次のように構成できます。

import os

from openai import OpenAI


REQUIRED_ENV = (
    "FOUNDRY_BASE_URL",
    "FOUNDRY_API_KEY",
    "FOUNDRY_DEPLOYMENT",
)

missing = [name for name in REQUIRED_ENV if not os.getenv(name)]

if missing:
    raise RuntimeError(
        f"必要な環境変数が設定されていません: {', '.join(missing)}"
    )

client = OpenAI(
    base_url=os.environ["FOUNDRY_BASE_URL"],
    api_key=os.environ["FOUNDRY_API_KEY"],
)

response = client.chat.completions.create(
    model=os.environ["FOUNDRY_DEPLOYMENT"],
    messages=[
        {
            "role": "system",
            "content": "あなたは簡潔で正確な日本語で回答するアシスタントです。",
        },
        {
            "role": "user",
            "content": "この文章を3行で要約してください。",
        },
    ],
)

content = response.choices[0].message.content

if not content:
    raise RuntimeError("モデルから有効な応答を取得できませんでした。")

print(content)

FoundryのOpenAI v1エンドポイントでは、URLにapi-versionを付ける方式ではなく、/openai/v1/を指定します。また、modelには実際のモデル名ではなく、自分で作成したデプロイ名を設定します。(Microsoft Learn)

本番環境ではMicrosoft Entra ID認証を検討する

APIキーは短時間で設定できるため、移行テストには便利です。ただし、FoundryのAPIキーはリソースに対して広いアクセス権を持ち、定期的なローテーションも必要になります。Microsoftは、本番ワークロードではMicrosoft Entra IDによるキーレス認証を推奨しています。(Microsoft Learn)

Pythonでは、azure-identityを追加します。

pip install --upgrade openai azure-identity

Microsoft Entra IDを利用する場合の基本形は次のとおりです。

import os

from azure.identity import (
    DefaultAzureCredential,
    get_bearer_token_provider,
)
from openai import OpenAI


token_provider = get_bearer_token_provider(
    DefaultAzureCredential(),
    "https://ai.azure.com/.default",
)

client = OpenAI(
    base_url=os.environ["FOUNDRY_BASE_URL"],
    api_key=token_provider,
)

response = client.chat.completions.create(
    model=os.environ["FOUNDRY_DEPLOYMENT"],
    messages=[
        {
            "role": "user",
            "content": "Microsoft Foundryへの移行確認です。",
        }
    ],
)

print(response.choices[0].message.content)

実行主体には、Foundryリソースに対する適切なRBACロールを割り当てる必要があります。

GitHub Actionsから呼び出す場合は認証方式も変更する

GitHub Modelsでは、GitHub Actionsの組み込みGITHUB_TOKENを使って推論APIを呼び出せました。しかし、このトークンはMicrosoft Foundryの認証情報としては利用できません。(The GitHub Blog)

移行方法は主に次の2つです。

  • 緊急移行では、FoundryのAPIキーをGitHub Actions Secretsへ登録する
  • 本番運用では、OpenID ConnectとMicrosoft Entra IDを組み合わせる

APIキーを使う場合は、次のようなSecretsを用意します。

FOUNDRY_BASE_URL
FOUNDRY_API_KEY
FOUNDRY_DEPLOYMENT

ワークフローから環境変数として渡します。

- name: Run AI task
  env:
    FOUNDRY_BASE_URL: ${{ secrets.FOUNDRY_BASE_URL }}
    FOUNDRY_API_KEY: ${{ secrets.FOUNDRY_API_KEY }}
    FOUNDRY_DEPLOYMENT: ${{ vars.FOUNDRY_DEPLOYMENT }}
  run: python scripts/run_ai_task.py

長期的には、固定されたクライアントシークレットやAPIキーではなく、OpenID Connectを利用します。Microsoftの手順では、Microsoft Entraアプリまたはユーザー割り当てマネージドIDにフェデレーション資格情報を設定し、azure/login@v2でサインインします。(Microsoft Learn)

permissions:
  id-token: write
  contents: read

steps:
  - uses: actions/checkout@v4

  - name: Sign in to Azure
    uses: azure/login@v2
    with:
      client-id: ${{ secrets.AZURE_CLIENT_ID }}
      tenant-id: ${{ secrets.AZURE_TENANT_ID }}
      subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

  - name: Run AI task
    env:
      FOUNDRY_BASE_URL: ${{ secrets.FOUNDRY_BASE_URL }}
      FOUNDRY_DEPLOYMENT: ${{ vars.FOUNDRY_DEPLOYMENT }}
    run: python scripts/run_ai_task_with_entra.py

OpenID Connectを使う場合でも、GitHubリポジトリを信頼するフェデレーション設定と、Foundryリソースへの適切なロール割り当てが必要です。

移行時に必ずテストする項目

エンドポイントから正常な応答が返っただけでは、移行完了とはいえません。モデルやデプロイ方式が変わると、出力品質、速度、制限、エラー条件も変わる可能性があります。

テスト項目確認内容
基本応答正常なプロンプトで期待する応答が返るか
認証エラー無効な認証情報を拒否できるか
タイムアウト応答遅延時に処理が停止し続けないか
再試行429や一時的なエラーを適切に再試行するか
ストリーミング途中で切断された場合を処理できるか
JSON出力必須フィールドや型を検証しているか
ツール呼び出し引数や関数名が既存処理と一致するか
コンテンツフィルター拒否時の応答をアプリ側で処理できるか
モデル品質代表的な入力で旧環境と比較したか
負荷ピーク時のレート制限に耐えられるか
コスト入出力トークンと実行回数を把握できるか
ログプロンプトや個人情報を過剰に記録していないか

Foundry Modelsでは、デプロイ方式によって料金やレート制限が異なります。また、モデルのリージョン提供状況、コンテンツフィルター、カスタムレート制限も確認が必要です。(Microsoft Learn)

Embeddingsを利用している場合は、特に注意が必要です。移行後にモデルやベクトルの次元数が変わると、既存のベクトルデータベースと互換性がなくなる可能性があります。その場合は、元データからEmbeddingを再生成し、インデックスを作り直します。

GitHub Models移行で起こりやすい失敗

GitHubトークンだけを作り直している

GitHub Models自体が廃止されているため、新しいPATやGITHUB_TOKENを発行しても復旧しません。

確認する場所はトークンではなく、まずエンドポイントです。

https://models.github.ai/inference

このURLが残っていれば、Microsoft Foundryのエンドポイントへ変更します。

Foundryへ変更したのに401や403になる

エンドポイントだけをFoundryへ変更し、認証ヘッダーにはGitHubトークンを残している可能性があります。

Foundryでは、次のいずれかを使用します。

  • FoundryリソースのAPIキー
  • Microsoft Entra IDのアクセストークン

GitHubのPATやGITHUB_TOKENをFoundryのAPIキーとして流用することはできません。

model not foundになる

旧GitHub ModelsのモデルIDを、そのままmodelへ指定している可能性があります。

Foundryでは、利用するモデルを先にデプロイし、そのデプロイ名をmodelへ設定します。デプロイ名とカタログ上のモデル名は必ずしも同じではありません。(Microsoft Learn)

モデルが選択したリージョンにない

Foundryのすべてのモデルが、すべてのリージョンで利用できるとは限りません。モデルカードで提供リージョンを確認し、必要に応じて別リージョンにリソースを作成します。(Microsoft Learn)

データ所在地や組織のクラウド利用規程がある場合は、利用可能だからという理由だけでリージョンを変更せず、事前にセキュリティ担当者へ確認します。

429エラーが増えた

GitHub ModelsとFoundryでは、レート制限や利用枠の考え方が異なります。

次の項目を確認します。

  • 1分当たりのリクエスト数
  • 1分当たりのトークン数
  • 同時実行数
  • 選択したデプロイ方式
  • Azure側のクォータ
  • アプリ側の再試行間隔
  • バックオフ処理の有無

無制限に再試行すると、障害を悪化させたり、実行時間やコストを増やしたりするため、指数バックオフと最大試行回数を設定します。

Azure AI Inference beta SDKへ新規移行している

Azure AI Inference beta SDKは2026年8月26日に廃止予定です。新しい移行先として採用せず、安定版OpenAI SDKとOpenAI v1 APIを利用します。(Microsoft Learn)

GitHub Copilotを汎用APIとして扱っている

GitHub Copilotは、GitHubや開発環境でのAI支援に適しています。一方、自社アプリのバックエンドから任意の入力を送り、応答を外部システムへ連携する用途では、Microsoft Foundryの方が適しています。

「GitHub内で人や開発作業を支援する」のか、「アプリケーションがモデルを呼び出す」のかを基準に判断します。

BYOKを利用していた場合の対応

GitHub ModelsのBYOK機能も、2026年7月30日をもって利用できなくなりました。モデル提供元のAPIキー自体が有効でも、そのキーをGitHub Models経由で利用することはできません。(The GitHub Blog)

移行後は、次の作業を行います。

  • Microsoft Foundryで利用するモデルを選定する
  • Foundry側の認証方式へ変更する
  • GitHub Models用に登録していたSecretsやVariablesを削除する
  • 不要になったプロバイダーキーを無効化またはローテーションする
  • GitHub Organization、Environment、RepositoryのSecretsをすべて確認する
  • 旧キーの利用履歴と課金状況を確認する

Secretsを削除する前に、別のアプリや環境で同じキーを共有していないか確認してください。キーを複数システムで共有している場合は、一斉削除ではなく、利用先ごとに新しい資格情報へ分離します。

GitHub Models完全廃止後の移行チェックリスト

  • [ ] リポジトリからmodels.github.aiを検索した
  • [ ] 古いmodels.inference.ai.azure.comも検索した
  • [ ] GitHub Actionsの呼び出しを確認した
  • [ ] Chat、Embeddings、ストリーミングなどの利用機能を整理した
  • [ ] Microsoft FoundryとGitHub Copilotのどちらへ移すか分類した
  • [ ] Foundryリソースとモデルデプロイを作成した
  • [ ] 対応リージョンを確認した
  • [ ] OpenAI v1 APIを採用した
  • [ ] modelをFoundryのデプロイ名へ変更した
  • [ ] GitHubトークンをFoundryの認証から外した
  • [ ] 本番環境でMicrosoft Entra ID認証を検討した
  • [ ] GitHub ActionsでOpenID Connectを検討した
  • [ ] レート制限とAzureの予算アラートを設定した
  • [ ] 代表的な入力で出力品質を比較した
  • [ ] 不要なGitHub Models用Secretsを削除した
  • [ ] 旧APIを参照するドキュメントや運用手順を更新した

GitHub Models APIが使えない場合、トークンの再発行や再試行を続けても解決しません。最初にリポジトリ全体から旧エンドポイントを検索し、アプリケーションの推論処理はMicrosoft Foundryへ、GitHub上の開発支援はGitHub Copilotへ振り分けます。

Microsoft Foundryへ移行するときは、エンドポイント、認証情報、モデルのデプロイ名の3点を優先して変更してください。そのうえでレート制限、出力品質、コンテンツフィルター、コストを検証し、旧GitHub ModelsのSecretsと設定を削除すれば、廃止後の移行を安全に完了できます。

AI
GitHub Copilot Microsoft Foundry GitHub Models 生成AI API

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次