GitHub Actions OIDCカスタムプロパティ実践ガイド: 2026年版ABAC移行

2026年4月のGitHub Actions更新で、OIDCトークンにリポジトリのカスタムプロパティを含められるようになりました。これは「小さな機能追加」に見えますが、実際にはCI/CDの権限管理を、リポジトリ名の列挙依存から属性ベース制御（ABAC）へ移行するための分岐点です。

参考: https://github.blog/changelog/2026-04-02-github-actions-early-april-2026-updates/。

なぜ今この変更が効くのか

多くの組織では、まだ次のどれかで運用しています。

リポジトリごとにクラウドロールを作る
複数リポジトリで広い共通ロールを使い回す
一部で静的キーが残っている

前者は運用負荷が増え、後者は事故時の影響範囲が広がります。カスタムプロパティをクレームとして渡せるようになると、信頼判断を「repo名」ではなく「そのrepoがどの属性か」で書けるため、ガバナンスとIAMが一致しやすくなります。

まず決めるべき属性設計

例えば次のような属性を定義します。

data_classification: public / internal / restricted
runtime_tier: dev / staging / prod
owner_domain: payments / growth / platform
compliance_scope: none / soc2 / pci

この属性をクラウド側のOIDC信頼ポリシーで条件化し、個別repo名の大量列挙を減らします。AWS/Azure/GCPいずれでも同じ思想で展開できます。

失敗しにくい移行ステップ

フェーズ1: 観測のみ

重要repoから属性付与を開始
既存ポリシーは維持
クレーム値の欠損・不正値を監査ログで可視化

フェーズ2: 併用運転

旧来のrepo名条件を残す
追加でABAC条件を評価
「旧条件OK / 属性条件NG」をアラート化

フェーズ3: 属性優先へ切替

repo名ベース条件を段階的に撤去
緊急時のみ使うブレークグラス権限を別管理
新規repo作成テンプレートに属性必須チェックを組込

運用で必須のガードレール

属性スキーマの所有者を固定する

属性はセキュリティ要件そのものです。許可値リストをバージョン管理し、変更権限を限定します。ここが曖昧だとABACは形だけになります。

ドリフト検知を日次で回す

台帳上の期待値
GitHub上の実値
クラウド監査ログのクレーム値

この3点照合で乖離を早期検知します。乖離を放置すると「正しく見えるが危険な状態」が長く続きます。

実行環境境界を強制する

runtime_tier=prod だけが本番デプロイ権限を取得できるよう、信頼ポリシーで明示的に分離します。開発系ワークフローの権限混入を止める最短ルートです。

よくある詰まりどころ

1つの属性に複数意味を詰め込む
クレーム欠損時にfail-openになる
高影響属性を誰でも変更できる

ABAC移行で重要なのは「属性を増やすこと」ではなく、「意味が分離された属性を、失敗時に必ず閉じる条件で使うこと」です。

成果を示す指標

IAMロール数の削減率
OIDC専用認証ワークフロー比率
属性不整合の修復時間
ワイルドカード権限の削減件数

この4つを追うと、セキュリティ改善と運用効率化を同時に説明できます。

まとめ

OIDCカスタムプロパティは、CI権限管理を「名前ベース」から「意味ベース」へ変える実装可能な選択肢です。リポジトリ増加や自動化拡大に先回りして、今のうちにABACへ移る組織ほど、事故率と運用コストの両方を下げられます。