40文字の保存欄で、長いトークンを受け取ったら

GitHub Appは、GitHub上の作業を自動化するアプリです。このアプリは、導入先の許可されたリポジトリを操作するとき、期限付きの認証用文字列である「インストールトークン」を使います。たとえば、自動テストや社内ツールがこの文字列を受け取り、GitHubへ送る場面があります。[1]

ここで、保存先が40文字までしか受け付けない自作の連携を、説明用の例として考えます。約520文字の新トークンが来れば、保存を拒否されたり、途中で切られたりする可能性があります。トークンが正しく届かなければ、自作の連携はGitHubへの認証に失敗し得ます。GitHubは、こうした固定長の前提を点検するよう案内しています。[2]

従来のトークン発行や認証の手順は使えます。利用側が見直すのは、古い長さや形だけを許す周辺の実装です。新形式は、情報を文字列で表すJWT（JSON Web Token）形式になり、トークンが長くなります。GitHubは、発行・検証の性能と、プログラムから操作を呼ぶ窓口であるAPIの信頼性を改善するために移行したと説明しています。JWTの扱いは後で説明します。[6, 7]

移行確認に使う一時的な指定（ヘッダー）は、2026年11月30日に廃止されます。両形式を確認したら、その日より前に本番コードから外すようGitHubは案内しています。[12]

何が変わり、どの環境が対象か

GitHubは2026年4月27日に段階移行を始め、10月2日に完了を発表しました。現在、対象トークンの新規発行では、新しい形式が既定です。[3]

対象はクラウド提供版のGitHub Enterprise Cloudの、GitHub Appインストール用サーバ間トークンです。データの保存地域を選べるData Residency環境も対象に含まれます。[4]

GitHub上で処理を自動実行するGitHub Actionsが、処理の認証用に発行する GITHUB_TOKEN も含みます。自社環境に設置するGitHub Enterprise Serverは対象外です。個人用アクセストークン（PAT）も、今回の告知対象と混同しないでください。[4]

新形式は ghs_APPID_JWT と呼ばれます。旧形式の40文字に対し、新形式は約520文字ですが、含まれるデータによって長さが変わります。長さは520文字に固定されておらず、先頭の ghs_ は従来と同じです。[5]

比較する点従来形式新形式
長さ40文字約520文字。データに応じて変動
先頭の文字ghs_ghs_
権限・リポジトリ範囲従来の許可範囲変更なし
発行APIで得るトークンの有効期限発行から1時間発行から1時間
発行方法インストールトークン発行API同じAPI

権限やリポジトリ範囲、有効期限、発行用の窓口は変わりません。ここでの1時間は、発行APIで取得するトークンの期限です。GitHub Actionsの GITHUB_TOKEN を運用する場合は、公式の有効期間の説明も確認してください。[1, 4]

移行前に発行したトークンも、その有効期限までは使えます。新形式になったことだけで、アプリに与える権限が広がるわけではありません。[6]

新形式には情報が入るが、利用側は文字列全体を扱う

JWTは、情報を文字列で表すトークン形式です。この新トークンは署名付きですが、利用側が中身を確かめるためのものではありません。新しいインストールトークンには、導入先やアプリ、基本的な検証用の情報が含まれます。GitHub側の発行元がトークンに署名します。GitHubは、利用側がこのJWTを検証したり、中身に依存した処理を作ったりしないよう案内しています。[8]

アプリがトークンの発行要求で使うJWTと、GitHubが返すインストールトークンは役割が別です。ここでの対応は、返された文字列全体をそのまま受け取り、認証情報として送れるようにすることです。[1, 8]

GitHubは、負荷が増えたときの発行性能や、大規模運用での信頼性を改善するために新形式を導入すると説明しています。GitHubのこれらの案内には、具体的な性能向上率は載っていません。そのため、新形式を使うだけで一定の高速化が得られるとは判断できません。[7, 8]

後輩JWT形式なら、自分で中身を読んで権限を判断するんですか？

先輩このトークンでは中身に依存しないようGitHubが案内しているよ。まず、受け取った文字列を切らずに届けられるかを確認しよう。

点検するのは、検査・保存・中継・ログの4か所

点検するのは、トークンが通る4か所です。認証の手続きを助けるSDK（ソフトウェア開発キット）に発行処理を任せていても、その周辺の設定は別に確認します。[13]

  • 自作の形式検査：40文字だけを許すチェックや、旧形式だけに合う文字列パターンがないかを探します。文字数や形だけでトークンの有効性を判断しません。
  • 保存先の上限：データベースの保存欄や、秘密情報の保存先を確認します。設定値をプログラムへ渡す環境変数の扱いを確認します。GitHubはデータベースの保存欄について、少なくとも520文字を格納できるよう案内しています。ただし、新形式の長さは可変なので、520文字ちょうどの固定長に置き換えるだけで終わらせないようにします。[9]
  • 途中の転送処理：認証情報を送る Authorization ヘッダーを、中継サーバや中間ソフトウェアが切り詰めたり、長さを理由に拒否したりしないかを確認します。
  • ログの秘匿設定（マスキング）：旧形式だけを隠す設定では、新形式の文字列がログに残る可能性があります。点検やテストで、実トークンや秘密鍵をログに出さないようにします。[10]

試験用ヘッダーは11月30日より前に外す

5月15日の案内では、一時ヘッダー X-GitHub-Stateless-S2S-Token で形式を試せました。値を enabled にすると新形式、disabled なら従来形式という説明です。これは移行確認のための一時機能です。10月2日の完了発表では、通常の新規発行はすでに新形式が既定になっています。[11]

GitHubは、アプリやワークフローで両形式を確認したら、2026年11月30日より前に本番コードからこのヘッダーを外すよう案内しています。その日以降、このヘッダーによる形式指定は無効になり、対象アプリには新形式が発行されます。旧形式を使い続けるための恒久設定にはできません。[12]

App運用者や連携の開発者はまず、自分の環境とトークンが対象かを確認します。対象なら、固定長などの形式依存を取り除き、受け取りから保存・転送・ログまでの経路を点検します。従来の発行手順で足りる部分は維持し、両形式を確認した後に一時ヘッダーを外す、という順で対応できます。[6, 13]