GitHub Actions 2026実践設計: ABAC・実行分離・プライベートネットワーク耐障害性
GitHub Actionsの直近アップデートは、CIをYAMLを書く場所からポリシーで運用する実行基盤へ移す流れを明確にしています。特に重要なのは、OIDCトークンへリポジトリのカスタムプロパティをクレームとして含め、実質的なABAC（属性ベースアクセス制御）を現場で回せるようになった点です。
参考: https://github.blog/changelog/2026-04-02-github-actions-early-april-2026-updates/
いま何が変わったのか
多くの企業はすでに長期シークレットからOIDC連携へ移行しています。ただし現実には、repo と branch だけで権限を切る粗い設計がまだ多く、モノレポや複数事業の共存で破綻します。
カスタムプロパティクレームを使うと、例えば以下をIAM条件に直接反映できます。
- criticality: high
- data_classification: restricted
- deployment_tier: production
- owner_team: payments-platform
命名規則依存を減らし、監査可能な権限判断に寄せられるのが最大の価値です。
実装時の3層モデル
1. GitHub側で属性語彙を固定する
自由入力を避け、選択肢ベースで運用します。ポリシーで使う属性はデータ型と許容値を明示してください。
2. クラウドIAMでクレームを直接評価する
YAML内部で条件分岐を増やすより、信頼ポリシー側に寄せた方がドリフト検知しやすくなります。
3. 実行前ゲートで fail closed
必須クレーム欠落時は即失敗にします。曖昧成功を残すと運用が数週間で形骸化します。
実行分離は必須条件
AI支援開発でコミット速度が上がるほど、CIで危険なスクリプトや依存が混入する確率も上がります。そこでワークフローを最低でも2系統に分けます。
- 信頼済みデプロイ系（厳格ABAC + 保護ブランチ + 承認）
- 非信頼入力の検証系（PR検査中心、資格情報発行を制限）
この分離がないまま運用で気をつけるは、ほぼ必ず破綻します。
プライベート依存テストの耐障害化
内部DBやAPIに依存する統合テストでは、ネットワーク障害時の振る舞いを先に設計しておく必要があります。
- ランナーの経路を決定論的にする
- 代替経路の検証を定例化する
- 非クリティカル試験は段階的に縮退させる
セキュリティパッチ配布が内部網の一時不調で全面停止する設計は避けるべきです。
運用で効く管理表
ワークフローごとに次の3軸を固定します。
- Identity: 必須クレーム、許可ロール、トークン寿命
- Execution: ランナークラス、外向き通信制限、署名要件
- Release: 環境ゲート、ロールアウト方式、ロールバック条件
属人化を防ぐには、まず表に落とすのが最短です。
45日導入計画
- 1-2週: 資格情報払い出し可能なworkflow棚卸し
- 2-3週: リポジトリ属性体系の定義
- 3-4週: 重要デプロイ経路をABACへ移行
- 4-5週: 実行分離とegress制御を適用
- 6週: クレーム不整合とネットワーク障害のゲームデー
追うべき指標
- ABAC条件適用済みデプロイ率
- クレーム不足による拒否件数（初期増加は正常）
- CIインシデント時のポリシー切り分け時間
- 部分障害時のデプロイ成功率
まとめ
2026年のGitHub Actions運用は、CIをセキュリティプロダクトとして扱えるかで差がつきます。ABAC付きOIDC、実行分離、耐障害ネットワークを一体で設計することが、速度と安全性の両立に直結します。
