#devops#ci/cd#security#platform-engineering#automation
GitHub Actions最新運用: カスタムイメージGAとAgentic Workflow可視化で統制を作る
GitHub Changelogで、GitHub-hosted runner向けのカスタムイメージGAや、Agentic Workflowの実行情報を確認しやすくする更新が続いています。これは単なる機能追加ではなく、CI/CDを「速さ重視」から「統制可能な実行基盤」へ移す転換点です。
AI支援開発が増えるほど、どの自動化が何を行ったかを説明できる設計が必要になります。
カスタムイメージが効く理由
従来のホステッドランナーでは、毎回セットアップスクリプトで環境を作る運用が多く、以下の問題が起きがちでした。
- 起動ごとに環境差分が出る
- 依存解決が重く、所要時間が読みづらい
- 監査時に「何が入っていたか」を証明しにくい
カスタムイメージを使うと、ツールチェーンを固定化し、再現性と監査性を一気に上げられます。
実務で使う3イメージ戦略
- Build image: 言語ランタイム、ビルドツール
- Security image: SAST、SBOM、秘密情報検査
- Release image: 署名、attestation、デプロイCLI
それぞれに所有者、パッチ適用SLA、廃止期限を持たせると、運用が属人化しません。
Agentic Workflow可視化の使い方
AIが関与するワークフローでは、次を追跡できることが重要です。
- どの設定で実行されたか
- どの権限でどのリポジトリを触ったか
- 承認がどこで必須/省略されたか
実行サマリーに、workflowハッシュ、ポリシーバージョン、主体ID（人間＋bot）、保護ブランチ判定を紐づけると、障害・インシデント時の再現が容易になります。
統制モデル（4層）
- Repo層: Branch protection、CODEOWNERS、必須レビュー
- Workflow層: 再利用workflowの入力固定
- Runner層: 許可イメージ制、外向き通信制限
- Identity層: OIDCクレームでアクセス境界を定義
4層を同時に回すと、一箇所の設定ミスが重大事故に直結しにくくなります。
サプライチェーン観点での必須項目
- Action参照はcommit SHAで固定
- 成果物にprovenance attestationを付与
- イメージの依存更新窓を定義
- 公開前にイメージ内容をスキャン
- 署名鍵を定期ローテーション
Runnerイメージは「ただの土台」ではなく、供給連鎖そのものです。
導入ステップ
- Phase 1: 高リスクリポジトリからカスタムイメージ適用
- Phase 2: 許可外イメージをブロック
- Phase 3: 重要デプロイに実行証跡の提出を必須化
- Phase 4: 古いイメージの自動廃止ルールを有効化
まとめ
カスタムイメージとAgentic Workflowの可視化をセットで運用すると、AI活用の速度を落とさずに統制を維持できます。先に統制を設計したチームほど、後からの監査対応コストが小さくなり、結果として開発速度が上がります。
参考: GitHub Changelog
