GitHub Actions の custom images を使っている組織は、今回の「Actions: Build custom images from custom images」により、既存のカスタムイメージを土台にして新しいカスタムイメージを作れるようになりました。要点は、共通ツールを入れたベースイメージを中央管理し、各チームがその上に必要な依存関係を追加できるようになったことです。あわせて、snapshot に条件分岐を付けられるようになり、イメージの新バージョンを作るタイミングをより細かく制御できます。GitHub Changelog では 2026年6月18日付の更新として掲載されていますが、日本時間で確認する場合は 2026年6月19日頃の変更として扱われるケースがあります。(The GitHub Blog)
Actions: Build custom images from custom images は何が変わった？
今回の変更は、GitHub-hosted larger runners 向けの custom images を使うチームに影響します。従来は、各チームが個別にイメージ生成ワークフローを持つと、同じセットアップ処理やツール導入が重複しやすい構成になりがちでした。今回の更新により、既存のカスタムイメージをベースにして別のカスタムイメージを作れるため、共通部分とチーム固有部分を分けやすくなります。(The GitHub Blog)
たとえば、全社共通のベースイメージに Node.js、Java、セキュリティスキャン用CLI、社内証明書、共通設定を入れておきます。その上で、フロントエンドチームは Playwright や pnpm、バックエンドチームは Maven や .NET SDK、モバイルチームは専用ビルドツールを追加した派生イメージを作る、といった運用がしやすくなります。
もう一つの変更点は、snapshot キーワードに条件分岐を指定できるようになったことです。これにより、タグ作成時はイメージを作らない、main ブランチへのマージ時だけ作る、週次スケジュール実行時だけ作る、といった制御がしやすくなります。(The GitHub Blog)
| 変更点 | これまで起きやすかった課題 | 期待できる効果 |
|---|---|---|
| 既存のカスタムイメージをベースに新しいカスタムイメージを作成可能 | チームごとに同じツール導入処理を繰り返していた | 共通レイヤーを再利用し、重複を減らせる |
| レイヤー型のイメージ運用が可能 | ベース環境とチーム固有環境の責任範囲が曖昧だった | プラットフォームチームと開発チームで管理範囲を分けやすい |
snapshot に条件分岐を設定可能 | 不要なイメージバージョンが作成されやすかった | テスト、検証、本番反映のタイミングを制御しやすい |
影響を受ける対象者
今回の変更を確認すべきなのは、主に GitHub Actions で GitHub-hosted larger runners と custom images を使っている組織です。GitHub Docs では、GitHub-hosted larger runners は GitHub Team または GitHub Enterprise Cloud を利用する organization / enterprise 向けとされています。(GitHub Docs)
特に、次のような運用をしている場合は確認優先度が高いです。
- CI 実行前に毎回大量のツールや依存関係をインストールしている
- 複数リポジトリで似たような GitHub Actions のセットアップ処理を繰り返している
- organization または enterprise 単位で runner や runner group を管理している
- セキュリティパッチ適用済みの標準ビルド環境を各チームに配布したい
- custom images のバージョンが増えすぎて、管理やストレージ使用量が気になっている
一方で、通常の GitHub-hosted runner だけを使っている場合や、self-hosted runner を自前で管理しているだけの場合は、今回の変更による直接の影響は限定的です。ただし、CI 時間短縮や標準環境の統一を検討しているなら、larger runners と custom images の採用判断材料になります。
すぐ確認したい設定と運用ポイント
まず確認すべきなのは、自社の organization または enterprise で custom images が有効になっているかです。GitHub Docs では、custom images を作成するにはポリシーで有効化されていること、作成・管理には organization / enterprise owner、CI/CD Admin ロール、または必要な細かい権限が必要とされています。(GitHub Docs)
| 確認項目 | 確認する理由 | 見直しの目安 |
|---|---|---|
| custom images の利用ポリシー | 組織全体で機能が有効かを確認するため | enterprise / organization の Actions policy を確認 |
| image-generation runner の runner group | 誰がイメージ生成できるかに直結するため | 本番用と検証用を分ける |
| ベースイメージの管理者 | 共通環境の変更が全チームへ波及するため | プラットフォームチームが管理する |
| 派生イメージの所有者 | チーム固有の依存関係を誰が更新するか明確にするため | リポジトリまたはチーム単位で責任者を決める |
snapshot の条件 | 不要なバージョン作成を防ぐため | main、schedule、手動実行などに限定する |
| イメージの有効期限と保持方針 | 古いイメージや派生イメージの期限切れを防ぐため | 保持期間と更新頻度をセットで設計する |
実務で使いやすい構成例
おすすめは、「全社共通ベース」「チーム別ベース」「リポジトリ固有」の3層に分ける考え方です。すべてを1つの巨大なイメージに詰め込むと、変更の影響範囲が広くなり、不要なツールまで全ジョブに含まれてしまいます。逆に、リポジトリごとに完全に別イメージを作ると、重複が増えて保守が難しくなります。
| レイヤー | 入れるものの例 | 管理者 |
|---|---|---|
| 共通ベースイメージ | OS標準設定、共通CLI、セキュリティツール、証明書、基本ランタイム | プラットフォームチーム |
| チーム別イメージ | Node.js系ツール、Java系ツール、.NET SDK、テストフレームワーク | 各開発チーム |
| リポジトリ固有設定 | 特定プロジェクトだけで使うビルドツールや依存関係 | リポジトリ担当者 |
この構成にすると、セキュリティパッチや共通ツールの更新はベースイメージ側で管理し、各チームは自分たちに必要な依存関係だけを追加できます。CI の高速化だけでなく、「どの環境でビルドされたのか」を追跡しやすくなる点もメリットです。
snapshot 条件分岐で不要なイメージ作成を防ぐ
custom images の生成では、snapshot キーワードを含むジョブが成功すると新しいイメージまたは新しいバージョンが作成されます。GitHub Docs では、snapshot の文字列構文と mapping 構文が説明されており、今回の更新により mapping 側で if 条件を使ってスナップショット作成を制御できます。(GitHub Docs)
たとえば、タグビルドではイメージを作らず、それ以外の実行時だけ作る場合は次のような考え方になります。
jobs:
build:
runs-on: my-image-generation-runner
snapshot:
if: ${{ ! startsWith(github.ref, 'refs/tags/') }}
image-name: my-custom-image
version: 2.*
steps:
- name: Install dependencies
run: |
echo "Install tools here"実務では、次のように条件を決めると運用しやすくなります。
| 作成タイミング | 向いているケース | 注意点 |
|---|---|---|
| 週次スケジュール | セキュリティパッチや依存関係を定期更新したい | 生成後の動作確認を自動化する |
| main ブランチへのマージ時 | ベース環境の変更をコードレビュー後に反映したい | 軽微な変更でもイメージが増えすぎないようにする |
| 手動実行 | 検証後に任意のタイミングで作りたい | 実行者の権限管理を厳格にする |
| タグ作成時は除外 | リリースタグ作成とイメージ生成を分けたい | リリース手順書にイメージ更新タイミングを書く |
バージョン管理と Latest 指定の注意点
custom images では、同じイメージ名で生成を繰り返すとバージョンが増えていきます。GitHub Docs では、初回は 1.0.0、同名イメージが存在する場合は 1.1.0、1.2.0 のようにマイナーバージョンが増える挙動が説明されています。また、mapping 構文で major version を指定すると、その major version 配下で新しい minor version が作成されます。(GitHub Docs)
注意したいのは、runner 側で Latest を使うか、特定バージョンに固定するかです。Latest を選ぶと新しいイメージバージョンが利用されやすくなりますが、予期しない依存関係更新の影響を受ける可能性があります。安定性を重視する本番ビルドでは、検証済みの特定バージョンに固定し、更新時だけ明示的に切り替える運用が安全です。
| 指定方法 | メリット | 注意点 |
|---|---|---|
| Latest | 最新の共通環境を自動的に使いやすい | 変更の影響が突然出る可能性がある |
| 特定バージョン固定 | 再現性を確保しやすい | 更新作業を手動で行う必要がある |
| major version 指定で生成 | 大きな更新単位を分けやすい | 古い major に新しい minor を作ると Latest の扱いに注意が必要 |
派生イメージでは有効期限に注意する
既存のカスタムイメージをベースに派生イメージを作る場合、見落としやすいのが有効期限です。GitHub Docs では、カスタムイメージから作られた派生イメージは、ベースイメージの有効期限タイムラインを引き継ぐと説明されています。つまり、派生イメージを作った日ではなく、ベースイメージが作られた日を基準に期限が計算されます。(GitHub Docs)
たとえば、ベースイメージAを月曜日に作り、水曜日に派生イメージBを作った場合でも、保持ポリシーによってはBの期限がAに引きずられます。派生イメージだけを新しく作ったつもりでも、ベースが古いままだと想定より早く期限切れになる可能性があります。
このため、レイヤー型のイメージ運用を始めるなら、次の順序で更新するのが安全です。
- 共通ベースイメージを更新する
- ベースイメージのテストを実行する
- チーム別の派生イメージを再生成する
- 主要リポジトリのCIで検証する
- runner の image version を切り替える
コストとストレージ使用量の見直しも必要
custom images は CI の高速化に役立ちますが、作成頻度を上げすぎるとイメージバージョンが増え、ストレージ使用量も増えます。GitHub Docs では、custom images を使うジョブは対象の larger runner と同じ分単位料金で課金され、custom images のストレージは GitHub Actions storage として別途課金されると説明されています。(GitHub Docs)
特に、snapshot を含むジョブが成功するたびに新しいイメージバージョンが作成される点は重要です。不要なブランチや検証用コミットで毎回イメージを作る設定にすると、短期間で古いバージョンが増えます。今回の snapshot 条件分岐は、この問題を抑えるためにも活用できます。
セキュリティ面で確認すべきこと
custom images は、CI 環境の土台そのものです。悪意あるコードや不適切な設定がイメージに入ると、そのイメージを使う複数のリポジトリに影響します。GitHub Docs では、image-generation runner を専用 runner group に分けること、本番用と開発・検証用の runner group を共有しないこと、public repository に image-generation runner へのアクセスを許可しないことなどがベストプラクティスとして示されています。(GitHub Docs)
実務では、少なくとも次の3点を確認してください。
| 確認項目 | 推奨対応 |
|---|---|
| image-generation runner にアクセスできるリポジトリ | 必要最小限に限定し、定期的に棚卸しする |
| 本番用イメージ生成ワークフロー | protected branch、CODEOWNERS、レビュー必須の運用と組み合わせる |
| write 権限を持つユーザー | 任意ブランチからイメージ生成できないよう、権限とトリガー条件を見直す |
特に、本番用イメージを生成できる runner group を開発・検証用リポジトリにも開放する運用は避けるべきです。便利に見えますが、意図しない変更が本番CI環境に混入するリスクが高くなります。
GitHub利用者が今すぐやるべきこと
今回の変更は、すぐに既存ワークフローを壊すタイプの変更ではありません。ただし、custom images をすでに使っている組織にとっては、CI環境の設計を整理する良いタイミングです。
まず、現在の custom images と runner group を棚卸ししてください。次に、共通化できる依存関係をベースイメージへ移し、チーム固有の依存関係は派生イメージに分ける構成を検討します。そのうえで、snapshot に条件分岐を追加し、不要なイメージ生成を抑えます。
最後に、バージョン固定、Latest 利用、有効期限、ストレージ使用量、アクセス権限をセットで確認してください。レイヤー型の custom images は便利ですが、管理者不在で増やすと、どのイメージが安全で最新なのか分からなくなります。小さく始めるなら、まずは「全社共通ベースイメージを1つ作り、1〜2チームで派生イメージを試す」運用から始めるのが現実的です。
コメント