GitHub rate_limit APIのcode_scanning_upload削除とは？影響範囲と移行ポイント

GitHubの「Removal of code_scanning_upload field from rate_limit API endpoint」は、コードスキャン機能の廃止ではありません。2026年5月19日以降、GET /rate_limit のレスポンスに含まれていた resources.code_scanning_upload が削除され、コードスキャン結果のアップロードに関するレート制限は core を参照する形に整理されました。/rate_limit の結果をパースして監視・制御しているスクリプト、CI/CD、社内ツールは、code_scanning_upload を直接参照していないか確認する必要があります。(The GitHub Blog)

GitHubのRemoval of code_scanning_upload field from rate_limit API endpointとは

今回の変更は、GitHub REST APIの GET /rate_limit エンドポイントに関するレスポンス仕様の変更です。

従来は、resources オブジェクト内に code_scanning_upload という項目が表示されることがありました。これはSARIFなどのコードスキャン結果をGitHubへアップロードする際のレート制限を示すように見える項目でした。

しかしGitHubの公式発表によると、code_scanning_upload は独立したレート制限枠ではなく、実際には core の制限プールと結合されていました。そのため、別枠の上限があるように誤解されやすく、2026年5月19日に rate_limit APIのレスポンスから削除されました。コードスキャンアップロード自体は、引き続き標準の core レート制限で管理されます。(The GitHub Blog)

何が変わったのか

変更点はシンプルです。GET /rate_limit の resources に code_scanning_upload が出なくなりました。

項目	変更前	変更後
resources.code_scanning_upload	表示される場合があった	表示されない
コードスキャン結果のアップロード制限	code_scanning_upload を見ているように扱われるケースがあった	core を参照する
代替フィールド	必要に見える場合があった	代替フィールドは不要
コードスキャン機能	継続	継続
SARIFアップロード	継続	継続

重要なのは、APIレスポンスの見え方が変わっただけで、code scanning uploadsの制限管理は core に統一して考えればよいという点です。

変更前後のレスポンスイメージ

変更前は、次のように core と code_scanning_upload が並んで見えるケースがありました。

{
  "resources": {
    "core": {
      "limit": 5000,
      "used": 100,
      "remaining": 4900,
      "reset": 1779200000
    },
    "code_scanning_upload": {
      "limit": 5000,
      "used": 100,
      "remaining": 4900,
      "reset": 1779200000
    }
  }
}

変更後は、code_scanning_upload がなくなり、確認すべき対象は core になります。

{
  "resources": {
    "core": {
      "limit": 5000,
      "used": 100,
      "remaining": 4900,
      "reset": 1779200000
    }
  }
}

実際の https://api.github.com/rate_limit のレスポンスでも、resources には core、search、code_search、graphql などが含まれ、code_scanning_upload は表示されない状態になっています。(GitHub API)

影響を受ける可能性がある対象者

この変更で影響を受けるのは、GitHubのコードスキャンを使っているすべての利用者ではありません。影響が出るのは、主に /rate_limit のレスポンスを機械的に処理している実装 です。

対象	影響の可能性	確認ポイント
CI/CDでSARIFアップロード前にレート制限を確認しているスクリプト	高	resources.code_scanning_upload を参照していないか
GitHub APIの社内ラッパー、SDK拡張	高	型定義や必須フィールドに含めていないか
Datadog、Grafana、CloudWatchなどの監視ダッシュボード	中	メトリクス名に code_scanning_upload を使っていないか
GitHub App、OAuth App、PATを使う自動化ツール	中	/rate_limit の戻り値を厳密に検証していないか
手動でGitHubのCode scanning画面を見るだけの利用者	低	基本的に対応不要
CodeQLやコードスキャン結果の閲覧のみをしている管理者	低	API連携がなければ影響は限定的

特に注意したいのは、「コードスキャンが失敗するかどうか」ではなく、「アップロード前にレート制限を確認する自作処理が壊れるかどうか」です。

起きやすい不具合

code_scanning_upload の削除で起きやすい不具合は、API制限そのものよりも、レスポンスの前提崩れです。

undefined や KeyError で処理が止まる

JavaScriptやTypeScriptで次のように直接参照している場合、code_scanning_upload が存在しないためエラーや undefined の扱いミスが起きます。

const remaining = data.resources.code_scanning_upload.remaining;

Pythonでも同様です。

remaining = data["resources"]["code_scanning_upload"]["remaining"]

このようなコードは、core を参照する形に変更します。

const remaining = data.resources.core.remaining;

remaining = data["resources"]["core"]["remaining"]

監視アラートが「メトリクス消失」として発火する

監視ツールで github.rate_limit.code_scanning_upload.remaining のような独自メトリクスを作っている場合、フィールド削除後に値が取れず、アラートが発火する可能性があります。

この場合は、メトリクス名を単純に置き換えるだけでなく、アラート条件も見直してください。

例えば、以前の条件が次のような内容だったとします。

code_scanning_upload.remaining < 100

変更後は次のように core を見る必要があります。

core.remaining < 100

ただし、core はコードスキャンアップロード専用ではありません。通常のREST API呼び出しも同じプールを消費するため、アラートのしきい値は運用実態に合わせて再調整した方が安全です。

スキーマ検証テストが失敗する

APIレスポンスをJSON Schemaやスナップショットテストで検証している場合、code_scanning_upload を必須項目として定義しているとテストが落ちます。

この変更では、code_scanning_upload を「任意項目」にするよりも、参照自体を削除して core を使う方が自然です。GitHubの公式発表でも、代替フィールドは不要で core を使うよう案内されています。(The GitHub Blog)

管理者・開発者が確認すべきポイント

まず、コードや設定ファイル全体から code_scanning_upload を検索してください。見つかった箇所を、用途別に仕分けると対応漏れを防げます。

確認場所	探す文字列の例	対応
アプリケーションコード	code_scanning_upload	core 参照に変更
CI/CD設定	/rate_limit、jq、remaining	resources.core.remaining を使う
監視設定	code_scanning_upload.remaining	メトリクスとアラート条件を更新
テストコード	スナップショット、JSON Schema	必須フィールドから削除
ドキュメント	手順書、運用Runbook	古い参照を修正
SDKや型定義	RateLimitResource など	code_scanning_upload 前提を削除

GitHubのレート制限状況は、各APIレスポンスヘッダーの x-ratelimit-limit、x-ratelimit-remaining、x-ratelimit-used、x-ratelimit-reset、x-ratelimit-resource でも確認できます。GitHub Docsでは、可能な場合はレート制限確認のためだけに /rate_limit を呼ぶより、レスポンスヘッダーを利用することが推奨されています。(GitHub Docs)

移行時の実装例

JavaScript・TypeScriptの場合

変更前のコードが次のような形なら、code_scanning_upload を直接参照しているため修正が必要です。

const res = await fetch("https://api.github.com/rate_limit", {
  headers: {
    Authorization: `Bearer ${token}`,
    Accept: "application/vnd.github+json"
  }
});

const data = await res.json();
const remaining = data.resources.code_scanning_upload.remaining;

if (remaining < 10) {
  throw new Error("Code scanning upload rate limit is too low");
}

変更後は core を参照します。

const res = await fetch("https://api.github.com/rate_limit", {
  headers: {
    Authorization: `Bearer ${token}`,
    Accept: "application/vnd.github+json"
  }
});

const data = await res.json();
const core = data.resources?.core;

if (!core) {
  throw new Error("GitHub rate limit response does not include core resource");
}

if (core.remaining < 10) {
  throw new Error("GitHub core rate limit is too low");
}

実務では、単にフィールド名を置き換えるだけでなく、core が存在しない場合のエラー処理も入れておくと安全です。APIレスポンスの仕様変更や認証ミスを早期に検知できます。

Pythonの場合

変更前は、次のようなコードがよくあります。

import requests

response = requests.get(
    "https://api.github.com/rate_limit",
    headers={
        "Authorization": f"Bearer {token}",
        "Accept": "application/vnd.github+json",
    },
    timeout=10,
)

data = response.json()
remaining = data["resources"]["code_scanning_upload"]["remaining"]

変更後は core を参照します。

import requests

response = requests.get(
    "https://api.github.com/rate_limit",
    headers={
        "Authorization": f"Bearer {token}",
        "Accept": "application/vnd.github+json",
    },
    timeout=10,
)
response.raise_for_status()

data = response.json()
core = data.get("resources", {}).get("core")

if core is None:
    raise RuntimeError("GitHub rate limit response does not include core resource")

remaining = core["remaining"]

Pythonでは data["resources"]["code_scanning_upload"] のような直接アクセスを続けると、削除後に KeyError が発生します。運用スクリプトでは、例外が起きたときにCI全体を止めるのか、アップロードだけをスキップするのかも決めておきましょう。

jqを使っている場合

シェルスクリプトで jq を使っている場合も確認が必要です。

変更前の例です。

curl -s -H "Authorization: Bearer $GITHUB_TOKEN" \
  https://api.github.com/rate_limit \
  | jq '.resources.code_scanning_upload.remaining'

変更後は次のようにします。

curl -s -H "Authorization: Bearer $GITHUB_TOKEN" \
  https://api.github.com/rate_limit \
  | jq '.resources.core.remaining'

CIの事前チェックで使うなら、値が null の場合に失敗させる処理も入れておくと、レスポンス異常を見逃しにくくなります。

remaining=$(curl -s -H "Authorization: Bearer $GITHUB_TOKEN" \
  https://api.github.com/rate_limit \
  | jq -r '.resources.core.remaining // empty')

if [ -z "$remaining" ]; then
  echo "core rate limit not found"
  exit 1
fi

移行で間違えやすいポイント

code_search に置き換えない

code_scanning_upload という名前を見ると、似た名前の code_search に置き換えたくなるかもしれません。しかし、code_search はコード検索のレート制限に関する項目です。コードスキャン結果のアップロードとは用途が違います。

今回の変更で見るべきなのは code_search ではなく、core です。

rate オブジェクトに戻らない

/rate_limit のレスポンスには、古くから rate オブジェクトが含まれる場合があります。しかしGitHub Docsでは、新規コードや既存コードの更新では rate ではなく core を使うよう案内されています。rate は core と同じ情報を持つ互換的な項目として扱われるため、移行先としては resources.core を選ぶのが安全です。(GitHub Docs)

「コードスキャンが無効になった」と判断しない

code_scanning_upload が消えたことを、コードスキャン機能やSARIFアップロード機能が無効になったサインと誤解しないでください。

今回の削除は、あくまで /rate_limit レスポンス内のフィールド整理です。CodeQL、サードパーティ製解析ツール、CI/CDからのSARIFアップロードを使っている場合でも、アップロード処理そのものではなく、レート制限確認処理を見直すのが主な対応です。

レート制限の監視を /rate_limit だけに頼りすぎない

GitHub Docsでは、GET /rate_limit はプライマリレート制限にはカウントされない一方で、セカンダリレート制限にはカウントされる可能性があると説明されています。また、可能な場合は各レスポンスに含まれるレート制限ヘッダーを使うことが推奨されています。(GitHub Docs)

つまり、監視や制御のために短い間隔で /rate_limit を叩き続ける設計は避けた方がよいです。API呼び出しの直後に返ってくるヘッダーをログ化し、必要に応じて集計する方が実運用では安定します。

チームで展開する際のチェックリスト

組織内でGitHub APIを複数チームが使っている場合は、次の順番で確認すると効率的です。

優先度	作業	目的
高	リポジトリ全体で code_scanning_upload を検索	直接参照の洗い出し
高	CI/CDの事前チェック処理を確認	SARIFアップロード前の停止を防ぐ
高	監視・アラートのメトリクス名を確認	不要な障害通知を防ぐ
中	JSON Schema、スナップショットテストを更新	テスト失敗を防ぐ
中	社内SDKや共通ライブラリを修正	各チームへの影響を一括で抑える
中	運用手順書を更新	障害対応時の誤判断を防ぐ
低	古いサンプルコードを整理	将来の再発を防ぐ

特に共通ライブラリを使っている組織では、各サービス側で個別対応するより、GitHub APIクライアントのレート制限取得処理を一箇所で直す方が安全です。

対応方針のまとめ

今回のGitHub API変更では、GET /rate_limit の resources.code_scanning_upload が削除されました。コードスキャン結果のアップロードは引き続き利用できますが、レート制限の確認には resources.core を使います。

対応としては、まずコード・CI/CD・監視設定から code_scanning_upload を検索し、見つかった箇所を core 参照へ移行してください。あわせて、code_search への誤置換、rate オブジェクトへの後戻り、/rate_limit の過剰呼び出しを避けることが重要です。

今日すぐ行うべきことは、次の3つです。

1. 全リポジトリと監視設定で code_scanning_upload を検索する
2. 該当箇所を resources.core 参照に変更する
3. CI/CDとアラートを実行し、フィールド欠落による失敗がないか確認する

この対応を済ませれば、Removal of code_scanning_upload field from rate_limit API endpointによる実務上の影響は、多くの環境で最小限に抑えられます。