GitHub Appトークン長変更：40文字前提の連携を点検する
新しいトークンだけで連携が失敗するなら、権限を増やす前に文字列の通り道を見ましょう。発行成功はDBやプロキシが値を保持した証拠にはなりません。
GitHubは2026年10月2日、App installation tokenのstateless移行完了を発表しました。既定はghs_APPID_JWTで、ghs_を維持しつつ40文字から約520文字になります。個人トークン全体の規則ではありません。
形式とアクセスを分ける
権限、リポジトリ範囲、1時間の有効期限、発行REST APIは変わりません。文字列の切断を権限拡大で直そうとせず、発行と利用を別々に調べます。
一時的なX-GitHub-Stateless-S2S-Tokenヘッダーは2026年11月30日に廃止予定です。両形式を検証して期限前に削除し、担当者と期限を記録します。
文字列を最後まで保持する
トークンは不透明な文字列として扱います。40文字固定の検証、小さいDB列、秘密保管庫の制限、長いAuthorizationヘッダーの拒否を確認します。
まず合成値で保存・取得・転送を試し、長さと結果だけ記録します。約520を新しい固定上限にせず、経路ごとの文書化された制約を確認してください。
エラーログも確認する
旧形式のマスキングでは長い値の一部が残る可能性があります。合成値で拒否、再試行、例外の経路も確認します。
GitHubの安全指針には最小権限、マスキング、ログ確認があります。本記事では保存担当とログ担当の共同点検を提案します。認証成功だけでは安全性を確認できません。
小さく試して期限を残す
実務上の問いは、既存システムが文字列を端から端まで保つかです。公式案内から導いた問いで、コミュニティの総意とは主張しません。
非本番で合成値試験、最小権限の実呼び出し、ログ点検を終えてから広げます。これは本記事の提案です。失敗箇所、担当、ヘッダー削除期限をまとめましょう。