症状：ワークフローもリポジトリ名も変えていないのに、GitHub Actionsからクラウドへログインできなくなります。

最短の対処は、実際のOIDCトークンのsubを先に確認し、その値に合わせてクラウドの信頼条件を更新することです。長期的なクラウドアクセスキーへ戻してはいけません。OIDCは対応サービスの短期トークン交換に使えますが、Apple署名証明書やApp Store Connect APIキーの代替にはなりません。

今週の実施順：トークンを採取する、信頼条件を照合する、影響範囲を集計する、権限を絞る、Mac上の署名境界を検証する、という順番で進めてください。

この内容は、GitHub Actions OIDCとクラウドロールの信頼ポリシーを管理するプラットフォームエンジニア、企業IT担当者向けです。自社運用Runner、Xcodeビルド、製品リリースを担当するチームリーダーや、リポジトリ移転とOIDCテンプレートを統括するセキュリティ担当者にも適しています。

最終更新：2026年9月11日。 OIDCの既定sub形式とAPIの確認には、GitHub Actions OIDC公式リファレンスおよびOIDC REST API公式ドキュメントを使用しています。Appleの署名とAPIキーの境界は、Apple公式資料で照合しています。

01

身元判定は sub の実値から始める

2026年7月15日以降に作成されたリポジトリでは、GitHub公式文書上、owner IDとrepository IDを含む不変のsubject形式が既定になるとされています。既存リポジトリは従来形式を維持しますが、管理者が明示的に切り替えた場合は別です。リポジトリの名前変更や移転も、不変形式への切り替え要因になり得ます。公式のOIDC subject形式の説明を確認してください。

ここで重要なのは、リポジトリ名からsubを推測しないことです。失敗したジョブで実際に発行されたOIDCトークンを取得し、少なくとも次のクレームを記録します。

  • iss：発行者が想定したGitHubであるか
  • aud：クラウド側が受け付けるAudienceか
  • sub：リポジトリ、ブランチ、Environmentなどの主体条件
  • repository_id：リポジトリの識別子
  • owner_id：所有者の識別子

アカウント名、ロール名、内部リソース名はマスキングしてください。失敗ログだけでは、署名検証の失敗と主体条件の不一致を区別できません。

判定対象 旧形式・既定形式 不変形式 カスタムテンプレート
主な識別材料 リポジトリ名や所有者名を含む主体 owner ID、repository IDなどの識別子 組織が定義したクレーム構成
影響を受けやすい変更 名前変更、移転、Environment条件 信頼側が旧形式を固定している場合 テンプレート適用範囲の変更
最初に確認する値 実トークンのsub subとIDクレーム 組織設定と実トークン
修復の方向 現行形式を信頼条件へ反映 不変形式に合わせて更新 テンプレートと信頼側を同時管理

GitHub Actions OIDCが突然クラウドへログインできない場合、何を疑うべきですか。

最初に疑うのは、ワークフローの変更ではなく、GitHubが発行したsubとクラウド側の条件の差です。issやaudも同時に確認し、署名検証そのものが失敗している場合は、主体条件だけを広げないでください。

02

信頼ポリシーは受け取ったクレームと一対一で照合する

クラウド側が照合している条件を、全文で保存してください。確認対象は、完全なsub、ブランチ、Environment、Audience、再利用可能ワークフローの主体条件です。どれか一つでも想定値と異なれば、GitHub側のYAMLだけを修正しても復旧しません。

特に危険なのは、接続を戻すためにsubのワイルドカードを広げることです。これにより、別リポジトリや別ブランチのジョブまで同じクラウドロールを取得できる可能性があります。信頼条件の変更前に、次の証拠を1つのチケットへ紐付けます。

  1. 脱​​敏化した失敗ログ
  2. 実際のOIDCトークンのクレーム
  3. 現在のクラウド信頼ポリシー
  4. 変更後の許可主体と拒否主体
  5. ロールが発行する短期トークンの用途

クラウド側の短期トークンとGitHub Secretsは別物です。OIDCを使う設計では長期クラウドキーをワークフローへ置かない方向に進められますが、既存のSecretsをすべて削除してよいという意味ではありません。Appleのリリース認証情報は別の管理対象です。

リポジトリ名を変更した後、OIDCの信頼条件はどう直しますか。

変更後の名前を手入力するのではなく、対象ブランチまたはEnvironmentで新しいOIDCトークンを発行し、subの実値を取得します。その値をクラウド側の許可主体と比較し、旧主体をすぐ削除せず、短い重複期間と失敗ログを設定してから切り替えます。

03

組織テンプレートが変える範囲を先に測定する

同じ組織でも、すべてのリポジトリが同じ状態とは限りません。次の3状態を分けて一覧化してください。

  • 新規作成時から不変subject形式を使うリポジトリ
  • 既存形式から管理者が明示的に移行したリポジトリ
  • 組織のカスタムsubjectテンプレートを適用したリポジトリ

一覧にはリポジトリ、Environment、対象クラウドロール、リリース用ワークフロー、管理者、切り戻し条件を含めます。先に本番リポジトリを一括変更するのではなく、テスト用リポジトリで許可主体と拒否主体を検証します。

GitHub Enterprise Serverについては、GitHub.comの説明をそのまま適用しないでください。製品範囲や対応状況は環境ごとに公式資料で確認する必要があります。組織テンプレートを導入する場合も、対象リポジトリの管理者が既存の信頼ポリシーを把握しているかを確認してください。

この作業では、リポジトリ名ではなくIDを台帳の主キーにすると、移転や改名による追跡漏れを抑えられます。名前を表示用に残し、owner_id、repository_id、Environment、クラウドロールを別列に分ける構成が適しています。

04

権限の最小化とMac署名の分離を同時に検査する

OIDCを修正した後に、権限を広げたままにしてはいけません。GitHub Actionsのジョブ単位で、必要なジョブだけにid-token: writeを付与します。contents権限、Environmentの承認、ブランチ条件も別々に確認します。

最低限、次の判定を残してください。

  • 許可される主体：対象リポジトリ、ブランチ、Environment
  • 拒否される主体：フォーク、未承認ブランチ、想定外の再利用ワークフロー
  • トークンの有効範囲：アクセス可能なクラウドサービスとリソース
  • 承認証跡：Environment承認者、変更申請、検証ログ
  • 失敗時の挙動：ロールを取得できず、署名処理へ進まないこと

自社運用のself-hosted runnerを使う場合、クラウド権限とApple署名権限を同じジョブへ集約しないでください。GitHubも自社運用Runnerについて、信頼されないコードが実行されるリスクを説明しています。自社運用Runnerの安全な利用に関する公式資料を確認し、フォークからのプルリクエストを無条件に同じノードへ送らない構成にします。

Apple Distribution証明書、Developer ID、App Store Connect APIキーは、OIDCで置き換えられる認証情報ではありません。Apple公式のApp Store Connect APIキー作成資料には、APIキーの作成と秘密鍵の扱いが示されています。また、Appleのクラウド管理証明書の説明も、クラウドロールとは別の証明書管理領域です。

GitHub Actions OIDCでApple署名キーも不要にできますか。

できません。OIDCは対応するクラウドまたは内部サービスが短期アクセストークンへ交換するための仕組みです。Apple署名証明書やApp Store Connect APIの秘密鍵を、OIDCだけで代替できるとはApple公式資料から導けません。

リモート Macの設計では、少なくとも次の層を分けます。

  • 信頼されないプルリクエストのビルド
  • OIDCによるクラウドリソース取得
  • Xcodeによる通常ビルド
  • Apple署名と本番公開

長期間共有するMacは、前のジョブのワークスペース、キーチェーン、環境変数が残りやすい点が弱点です。一時的なRunnerは残留を抑えやすい一方、起動、登録解除、キャッシュ再構築の設計が必要です。専用のリリースMacは境界を明確にできますが、稼働率、保守、障害時の代替ノードを別途考えなければなりません。

05

監査証拠と復旧判定を固定してから本番へ戻す

復旧を「ジョブが成功した」で終わらせないでください。テストリポジトリで、許可されたブランチ、Environment、再利用可能ワークフローだけが短期トークンを取得できることを確認します。未承認のフォーク、別リポジトリ、条件外のブランチは拒否される必要があります。

実施手順は次の通りです。

  1. 失敗したジョブのOIDCトークンを取得し、iss、aud、sub、repository_id、owner_idを保存します。
  2. 現在のクラウド信頼条件をエクスポートし、トークンの各クレームと照合します。
  3. 組織テンプレート、既定形式、不変形式、対象リポジトリの適用状態を棚卸しします。
  4. id-token: write、contents、Environment承認、ブランチ条件をジョブ単位で縮小します。
  5. クラウド権限を持つRunnerと、Apple署名用キーチェーンへアクセスできるMacを分離します。
  6. テストで許可と拒否を確認し、変更前後のログ、ポリシーバージョン、承認記録を保管します。
  7. 本番の自社運用MacでRunner再起動、タスク再ルーティング、ワークスペース消去、署名ノードの隔離、代替ノードへの切り替えを検証します。

Mac上の署名処理では、OIDCトークン、クラウド短期トークン、GitHub Secrets、App Store Connect API秘密鍵、Apple署名証明書を同じ保管場所として扱わないでください。それぞれの発行者、寿命、失効方法、ジョブからの参照経路を台帳化します。

既存のMac設備でノード分離が難しい場合は、まず専用のリモート Macを使った小規模な検証が現実的です。チームでMacを共用する場合は、Macのプライバシーポリシーと運用条件を確認し、物理アクセス、キーチェーン、管理者権限の扱いを社内基準と照合してください。導入前にMac実機レンタルの構成情報を確認しておくと、署名ノードと通常ビルドノードを分ける試験計画を作りやすくなります。

06

既存設備とリモートMacの境界を決める

現在の共有Macで運用を続ける場合、前のジョブの認証情報が残る、署名キーチェーンとクラウド権限が同居する、ハードウェア障害でクラウド認証とリリースが同時に止まる、という欠点があります。オンプレミスのMacを増やす方法もありますが、調達、保守、代替機、設置場所の管理が必要です。

一方、VpsMeshのリモート Macを専用のビルドまたは署名検証ノードとして試す方法なら、既存の共有ホストと権限境界を分けて検証できます。ただし、長期にわたる安定した高負荷処理、物理デバイス接続、社内規定で持ち出し禁止の秘密鍵には、専用購入機や自社設備の方が適する場合があります。

まずはOIDC信頼ポリシーの修正とMacの権限分離を別々に評価してください。クラウドログインが戻っただけで、Apple署名まで同じRunnerへ戻すのは避けるべきです。短期の試験環境や障害時の代替ノードが必要なら、VpsMeshのリモート Macで専用ノード構成と復旧手順を検証するのが、既存共有設備を直接変更するより安全な進め方です。