GitHub App installation token が長くなった後、Mac CI はどう検証する？2026

症状：installation tokenの形式変更後、一部のMac CIだけ認証に失敗する。
最短の対処：トークンを不透明な文字列として扱い、長さ、保存、Authorizationヘッダー、ログ秘匿を順に確認してください。形式変更だけを理由に、権限モデルやMacノードを作り直す必要はありません。

GitHub App管理者：トークンの発行、権限、リポジトリ範囲を管理し、既存連携への影響を確かめたい方。
GitHub Actions／Mac CI担当者：独自Action、プロキシ、ミドルウェア、認証情報の保存経路を保守する方。
セキュリティ・監査担当者：新旧形式のトークンが拒否されたり、ログに残ったりしないことを確認する方。

最終更新：2026年10月10日。形式と変更日はGitHubの公式告知およびinstallation tokenの公式ドキュメントで照合しています。

GitHub App installation tokenの長さ変更をMac CIで受け入れ確認する

変更点は、installation tokenを固定長とみなす実装が新形式に対応できるかどうかです。GitHubは2026年10月2日、無状態形式の段階的な展開完了を告知し、新たに発行されるトークンは引き続きghs_で始まる一方、長さは旧形式の40文字から約520文字になったと説明しています。公式告知

一方、権限、対象リポジトリ、有効期間、REST APIのエンドポイントは形式変更に伴って変わったものではありません。installation tokenの有効期間は1時間です。これらの条件はGitHubのトークン仕様で確認し、独自の設定変更を混ぜないでください。

判定点は、各行を「証拠付きで合格＝2」「未確認または証拠不足＝1」「失敗＝0」として記録します。認証・保存・ログ保護に0があれば本番投入を止め、1が残る場合は対象を限定して追加検証してください。これはチーム内の受け入れ基準であり、GitHubが定めた仕様値ではありません。

新しいトークンでCI認証が失敗するのはなぜか

CI認証の失敗を、直ちに権限不足と判断しないでください。古い長さを前提にしたActionやスクリプト、入力検証、データベース列でトークンが拒否・切り詰められていないか、まず発行元からAPI呼び出しまで追います。

手順1：発行元から利用箇所までを列挙する

GitHub Appからトークンを受け取る処理、ワークフローの環境変数、独自Action、スクリプト、APIクライアントを一覧にします。length == 40のような判定や、トークンの一部を切り出して内部形式を判別する処理を検索してください。プレフィックス確認だけでなく、全体の文字列を固定長として検査するコードも対象です。

GitHub Actionsのワークフロー認証は、どの認証方式を利用しているかを整理する際の基準になります。インストールトークンとGITHUB_TOKENを混同せず、今回検証する値がどこで発行され、どのジョブに渡るかを記録してください。

手順2：新旧形式の合成値で読み書きを試す

実トークンをテスト資料、チケット、共有ログに貼り付けてはいけません。安全な隔離環境で合成値を用意し、旧形式に近い長さと新形式に近い長さの値を使って、読み込み、受け渡し、書き込み、再読み込みの結果を比較します。

確認するのは、保存前後の値が一致すること、固定長バリデーターに拒否されないこと、Actionの入力や出力で欠落しないことです。トークンの内部構造を分解して解釈するのではなく、発行された文字列全体を不透明な値として扱います。

GitHub App tokenの保存領域は拡張すべきか

必要なのは一律の容量拡張ではなく、実際に値を保持する各境界の確認です。Secret、環境変数、データベース列、シークレット管理インターフェース、テンポラリーファイルをたどり、固定長や入力上限が旧形式に合わせて設定されていないか調べます。

手順3：受け渡しごとに切り詰めの有無を確認する

保管前と取り出し後の値を直接ログに出さず、テスト環境で安全に比較できる方法を用意します。たとえば、値の全体一致を検査して成否だけを記録すれば、テスト資料にトークンそのものを残さずに受け渡しを確認できます。

GitHub ActionsのSecretを使う場合は、公式のSecretに関する説明に沿って設定と利用箇所を確認してください。環境変数からシェル、Action、プロセス引数へ渡す途中で、値が空になる、改行などの扱いで変化する、独自の上限で拒否されるといった経路も調べます。

リバースプロキシは長いAuthorization値を切り詰めるか

プロキシやゲートウェイの挙動は製品・設定ごとに異なるため、すべての環境で問題が起きるとは限りません。HTTPのフィールドサイズに関する扱いは実装に左右されます。RFC 9110も踏まえ、自社経路で拒否、切り詰め、記録のどれが起きるかを実測してください。

手順4：Mac CIからGitHub APIまでの実リクエストを確認する

実際のビルドジョブが通る経路に沿って、HTTPクライアント、社内プロキシ、ゲートウェイ、独自ミドルウェアを一つずつ確認します。合成のAuthorization値を使った制御試験で、リクエストが意図した宛先に届くこと、途中で拒否・変更されないこと、診断ログに値が残らないことを記録してください。

「ヘッダー上限を超えた」というエラーが出た場合は、応答の発生箇所を絞り込みます。トークン形式変更だけで原因を断定せず、HTTPクライアントや中継機器の設定、エラー応答、ジョブログを照合して、どの境界で止まったかを示す証拠を残します。

GitHub Actionsのログ秘匿は新形式に対応しているか

マスキングが旧形式のパターンにだけ依存していると、新しい値が例外出力やデバッグログに露出するおそれがあります。GitHub Actionsの安全な利用に関する公式ガイドを参照し、ログフィルター、独自Action、エラー処理のそれぞれを確認してください。

手順5：合成値でログと監査記録を検査する

新旧の形式を模した合成値を使い、成功ログ、認証失敗、例外、デバッグ出力を発生させます。画面上のログだけでなく、保存済みのビルド出力やエラー報告にも値が残っていないか確認します。試験記録には「秘匿されたか」「どのフィルターが動作したか」を残し、実トークンは記録しません。

設定の変更後は同じ試験を再実行してください。マスキングが成功していても、トークンがリクエスト前に拒否される場合は別問題です。認証の成否とログ保護の成否を別々に判定すると、対策の抜けを発見しやすくなります。

形式変更の後も権限と移行手順を分けて扱う

本番に進む前に、GitHub Appの権限、対象リポジトリ、有効期間、利用するAPIエンドポイントを既存の承認内容と照合します。形式が変わったことを理由にアクセス範囲を拡大したり、トークンの有効期間を延ばしたりしないでください。どの属性が維持されるかはinstallation tokenの仕様で確認できます。

一時的なX-GitHub-Stateless-S2S-Tokenヘッダーを統合テストに使っている場合は、削除担当と切り替え記録を残してください。GitHubはこの一時ヘッダーが2026年11月30日以降に有効でなくなると告知しています。一時ヘッダーの公式告知を再確認し、日付や移行条件に更新がないか、廃止前に見直します。

最終判断では、長さ、保存、HTTP伝送、ログ秘匿、認可の各項目に証拠をひも付けます。すべての重要経路を確認できたら段階的に本番へ進め、未確認項目が残れば期限と責任者を決めて保留します。認証失敗が続く場合も、ノード交換や権限拡大ではなく、まず失敗した境界を特定してください。

既存のMac CIを自社で維持する方法は、ハードウェアの調達・保守に加え、共有環境の権限分離やログ監査も継続して担う必要があります。短期の検証環境や一時的なCI容量が必要なら、MacDateのMacレンタルを候補に加えると、実機の購入・保守を前提にせず必要な期間の環境を検討できます。固定負荷で長期運用する場合や、物理機器への直接接続が欠かせない場合は、自社保有との比較が先です。構成を比べる際はMac実機と仮想化環境の違いを、費用を検討する際はMac miniの料金ガイドも参照してください。