GitHubがApp installationトークン形式を変更：40文字から約520文字へ、CI/CDパイプラインに障害リスク

GitHubは2026年4月24日にApp installationトークン形式の重要な変更を発表し、2026年4月27日から段階的なプロダクション導入が始まります。この変更は、40文字という従来の固定長をハードコードしているインテグレーションやCI/CDパイプラインを壊す可能性があります——これにはプロダクション環境の多数のカスタムスクリプトやデータベーススキーマが含まれます。

新しい形式とは具体的に何ですか？

旧形式は次のとおりです：ghs_ + 36文字の英数字 = 合計40文字。新形式はghs_APPID_JWTプレフィックスを持つJWT（JSON Web Token）として構造化され、総長さは約520文字で、「その中に格納されたデータに基づいて変わる」と注記されています——言い換えれば、長さは固定ではなくコンテンツに依存します。JWTはJSON形式でデータを安全に転送するための標準化された形式（RFC 7519）で、サーバーへのコールバックなしに整合性を検証できるよう暗号学的に署名されています。GitHubの発表によると、JWTには「対象のインストール、アプリケーション、基本的な検証詳細などのトークンに関する詳細情報が含まれる」とのことです。

誰が、いつ影響を受けますか？

GitHubのロールアウトは2つのフェーズに分けられます。フェーズ1（2026年4月27日〜5月中旬）はGitHub Actions GITHUB_TOKENとDependabot、Slack、Teamsインテグレーションなどのいわゆるfeaturedインテグレーションをカバーします。フェーズ2（5月中旬〜2026年6月末）は、GitHub Enterprise CloudとData Residency要件（EU、オーストラリア、その他の地域）のある環境を含むすべてのApp installationトークンに変更を拡大します。実際には、CI/CDパイプラインでGitHub Appsを使用して認証しているすべての組織がすぐに準備すべきです。

開発者が必ずしなければならないことは？

GitHubは3つの重要なアクションについて非常に明確にしています：

1. データベーススキーマ： 「アクセストークン用のデータベースカラムが少なくとも520文字の文字列を収容できること」——トークンが保存されるすべてのカラムが520文字以上をサポートすることを確認してください。典型的なVARCHAR(40)やVARCHAR(64)はもはや機能しません。
2. 正規表現チェック： トークン形式の検証に使用されていたghs_[A-Za-z0-9]{36}タイプのすべての正規表現パターンを削除してください。新しい形式にはアンダースコアと旧パターンに一致しない文字が含まれます。
3. 長さチェック： 「アプリが特定の長さのアクセストークンへの依存を持たないこと」——40文字の固定長を前提とするすべてのロジックを修正する必要があります。

GitHubはなぜこれを行うのですか？

セキュリティとパフォーマンスの動機があります。JWT形式はステートレスな検証を可能にします——サーバーはトークンの有効性を確認するために各呼び出し時にDBルックアップを行う必要がなく、署名をローカルで検証できます。GitHubはこの変更が「負荷増大時のトークン発行パフォーマンスを向上させる」と「大規模でのより高い信頼性」をもたらすと述べています。言い換えれば——GitHubはAIエージェントと自動化ボットインテグレーションの爆発的な増加とともにやってくる呼び出し量の増加に向けて、認証インフラを準備しています。

変更を無視するとどうなりますか？

旧長を前提とするアプリケーションは、新しいトークンに最初に遭遇した時点でエラーが発生し始めます。最も一般的な症状：DBインサート失敗（文字列の切り捨て）、正規表現バリデーション拒否、Authorizationヘッダーパーサーエラー。ロールアウトが組織に追いつく前に、今後数日でプロアクティブにすべてのリポジトリとカスタムActionsを監査することをお勧めします。