GitHub App インストールトークンの新形式導入に関するお知らせ
GitHubは2026年4月下旬から、GitHub Appインストールトークンの形式をステートレスJWT方式へ段階的に移行し、発行パフォーマンスとAPI信頼性を向上させる方針を発表した。
キーポイント
トークン形式の技術的変更
既存の固定長40文字から、データ量に応じて変動する約520文字のステートレスJWT形式（ghs_APPID_JWT）へ移行し、内部発行者署名による検証は不要とする。
段階的なロールアウト計画
2026年4月下旬からActionsおよび主要統合アプリ向けに開始し、5月下旬〜6月末までに全GitHub Appインストールトークンへ適用するスケジュールを提示。
スコープと既存トークンの扱い
GitHub Enterprise CloudおよびData Residency環境が対象でEnterprise Serverは影響なし。有効期限内の既存トークンはそのまま使用可能だが、形式変更依存コードの修正が必要。
移行テストとサポート体制
ブラウンアウト期間を設けて形式変更依存の統合を検出し、Actionsワークフローへの影響がある場合はサポート経由で一時的な無効化（opt-out）が可能。
トークンの扱いと検証の緩和
トークンを固定パターンで検証せず、特定の長さや形式に依存しないようコードを調整する。
データベーススキーマの拡張
トークン保存用のカラム長を少なくとも520文字に設定し、新形式のトークンを格納できるようにする。
コミュニティ議論への参加
GitHub Community上での変更関連ディスカッションに参加し、最新情報を共有・確認する。
影響分析・編集コメントを表示
影響分析
本変更はGitHubプラットフォームの認証基盤を現代的なステートレス形式へ移行するもので、大規模なAPI負荷増加に対応するインフラ強化策である。開発者は既存のトークン解析ロジックを廃止し、移行期間中のブラウンアウトテストを活用して自社のGitHub AppやCI/CDパイプラインの互換性を確保する必要がある。これにより、GitHub ActionsやCopilot関連フローを含むエコシステムの安定運用が担保される。
編集コメント
プラットフォームの認証トークンをステートレスJWTへ移行する試みは、大規模なAPI運用におけるスケーラビリティ確保の標準的な進化である。開発者は「トークンの中身は解析せず透過的に扱う」という原則を再確認し、ブラウンアウト期間中のテストを積極的に活用して移行リスクを最小限に抑えるべきだ。
2026年4月27日より、今後数週間にわたって段階的ロールアウト（staged rollout）を開始し、新たに発行されるGitHub Appインストールトークンの形式を更新します。これによりパフォーマンスが向上し、APIサーフェス（API surface）の信頼性も高まります。もしアプリケーションがインストールトークンの長さが正確に40文字であることを前提としている場合、この新しいトークン形式を正しく処理できない可能性があります。
What is changing?
現在、GitHub Appインストールトークンのために新しいステートレス（stateless）トークン形式をサポートしており、これにより負荷増加時のトークン発行パフォーマンスが向上し、大規模なスケールでのより高い信頼性の提供が可能になります。
新たに発行されるGitHub Appインストールトークンは、以下の更新された形式を使用します。
トークンの全体的な長さはより長くなり（約520文字）、内部に格納されるデータに応じて変動します。
インストールトークン（ghs_ トークン）の形式は、ghs_APPID_JWT に変更されます。
注：GitHubのトークンタイプのプレフィックスは変更されず、インストールトークンは引き続き ghs_ で始まる点にご注意ください。
このJWT（JSON Web Token）はGitHub内部の発行者によって署名されており、クライアントアプリケーションで検証することはできませんし、行うべきでもありません。これにはターゲットのインストール先やアプリケーション、基本的な検証情報などのトークンに関する詳細が含まれています。すべてのアクセストークン（access token）と同様、クライアントアプリケーションはこのJWTの内容に依存してはいけません。
Scope
既存のAppインストールトークンは、有効期限が切れるまで引き続き動作します。
この変更は、GitHub Enterprise Cloud および Data Residency 環境に適用されます。GitHub Enterprise Server はこの変更の影響を受けません。
今後のロールアウトでは、Actions の GITHUB_TOKEN を含む GitHub App インストール サーバー間トークン（server-to-server tokens）のみに対して、新しいトークン形式が適用されます。
現時点では対象外ですが、Copilot のコードレビューフロー（code review flows）で使用されるユーザーからサーバーへのトークン（user-to-server tokens）に関する形式変更の詳細については、今後数週間で共有いたします。
今後数週間で予想されること
今後数週間で、GitHub App インストールトークンの形式変更に関する段階的なロールアウト（staged rollout）を実施いたします。
4月27日～5月中旬（2026年）：更新された形式の段階的なロールアウトを、GitHub Actions が発行する GITHUB_TOKEN およびその他の公式ファーストパーティ統合（例：Dependabot、Slack、Teams）に発行される GitHub App インストールトークンに対して開始いたします。既存の Actions ワークフロー（Actions workflows）には影響しないはずです。この変更が Actions ワークフローに影響を与えており、一時的に変更をオプトアウト（opt-out）したい場合は、GitHub サポートまでお問い合わせください。
2026年5月中旬から6月下旬にかけて：更新された形式をすべてのGitHub Appインストールトークンに対して段階的な展開（staged rollout）を開始します。今後数週間で、この変更をより広く展開する前に、これらの新しいトークンをローカルでテストしてGitHub Appが期待どおりに動作し続けることを検証する方法に関するさらなるガイダンスを提供します。トークンの形式に関する前提条件にまだ依存している統合を特定するためのブラウンアウト期間（brownout period）を導入し、その後で更新された形式の広範な有効化を行います。
この変更への準備方法
トークンを透過性のない文字列（opaque string）として扱い、ハードコードされたパターンに対して検証しないことを推奨します。
この変更への準備を支援するために、以下の事項を確認してください：
アプリケーションがアクセストークン（access token）の特定の長さに依存していないこと。
コードベース内にトークンを検証する正規表現（regex）が ghs_[A-Za-z0-9]{36} のように存在しないこと。これらは新しいトークンと一致しない可能性があります。
アクセストークン用のデータベースカラムが、少なくとも520文字の文字列を格納できるサイズであること。
GitHubコミュニティ内のディスカッションに参加してください。
「GitHub Appインストールトークンの今後の新形式に関するお知らせ」の記事は、The GitHub Blog で最初に公開されました。
原文を表示
Starting April 27th 2026 and over the coming weeks, we will begin a staged rollout that updates the format of newly minted GitHub App installation tokens, making them more performant and improving the reliability of our API surface. If your application expects or relies on installation tokens being exactly 40 characters long, it may not handle this new token format correctly.
What is changing?
We’re now supporting a new, stateless token format for GitHub App installation tokens that improves token issuance performance under increased load and helps us deliver higher reliability at scale.
Newly issued GitHub App installation tokens will use an updated format with the changes below:
The overall length of the tokens will be longer (~520 characters) and will vary based on the data stored within it.
The token format for installation tokens (ghs_ tokens) will be changing to ghs_APPID_JWT.
Note that the prefixes for any of the GitHub token types is not changing and installation tokens will still be prefixed with ghs_.
The JWT is signed using a GitHub-internal issuer and cannot nor should not be validated by a client app. It contains details about the token such as the target installation, the application, and basic validation details. As with all access tokens, client apps must not take a dependency on the contents of this JWT.
Scope
Existing App installation tokens continue to work until they expire.
This change applies to GitHub Enterprise Cloud and Data Residency environments. GitHub Enterprise Server isn’t impacted by this change.
Upcoming rollouts will apply the new token format only to GitHub App installation server-to-server tokens, including Actions GITHUB_TOKEN.
Not in scope yet, but we’ll share more details in the coming weeks on planned format changes for user-to-server tokens used in Copilot code review flows.
What to expect over the next few weeks
In the coming weeks, we will be doing a staged rollout for the format changes to GitHub App installation tokens:
April 27 – mid-May 2026: We’ll begin a staged rollout of the updated format to GitHub Actions-issued GITHUB_TOKEN and the GitHub App installation tokens issued to all the other first-party featured integrations (e.g., Dependabot, Slack, and Teams). This should not impact your existing Actions workflows. Reach out to GitHub Support if you see this change affecting your Actions workflows and want to temporarily opt-out of the change.
Mid-May to late-June 2026: We’ll begin a staged rollout of the updated format to all the GitHub App installation tokens. We will be providing more guidance over the coming weeks on how to test these new tokens locally to validate that your GitHub Apps continue to work as expected before we roll out the change more broadly. We’ll introduce a brownout period to identify integrations that still depend on token format assumptions, followed by broad enablement of the updated format.
How to prepare for this change
It’s recommended that you treat tokens as opaque strings and avoid validating them against hardcoded patterns.
To help prepare for this change, ensure that:
Your apps do not take a dependency on access tokens being a certain length.
There are no regexes in your codebase such as ghs_[A-Za-z0-9]{36} that validate a token. These may not match the new tokens.
Any database columns for access tokens can fit at least a 520 character string.
Join the discussion within GitHub Community.
The post Notice about upcoming new format for GitHub App installation tokens appeared first on The GitHub Blog.
関連記事
GitHub のエージェント計画に関する Kyle Daigle とのインタビュー
Microsoft の Satya Nadella 氏と共同で AI Engineer World's Fair に参加し、Kyle Daigle が GitHub のエージェント戦略や Copilot の稼働率について質問に答えた。
リポジトリ内の全プロジェクトの Git 設定を編集可能に
Vercel は、モノレポで多数のプロジェクトを展開するユーザー向けに、各プロジェクトの Git 設定（コミットステータスやリポジトリディスパッチイベントなど）を一括で管理・適用できる機能を追加した。これにより、個別の設定画面へのアクセスが不要となり、効率的な運用が可能になった。
GitHub で統合コミットステータスが利用可能に
Vercel は、モノレポにおいてプルリクエストごとに単一の統合コミットステータスを設定できる機能を GitHub に提供し、多数のプロジェクトを持つチームがブランチ保護ルールを一元管理できるようにした。