GitHub Actions の Actions: Build custom images from custom images は、カスタムイメージ運用を「単体のVMイメージ管理」から「階層化されたビルド環境管理」に変えるアップデートです。既存のワークフローが直ちに壊れる変更ではありませんが、管理者は 誰がベースイメージを更新できるか、派生イメージの有効期限・コスト・監査をどう追跡するか を早めに確認する必要があります。
特に、GitHub-hosted larger runners の custom images をすでに使っている組織では、共通ツールを入れたベースイメージを用意し、各チームがその上に必要な依存関係を重ねる運用が可能になります。一方で、ベースイメージが汚染された場合の影響範囲も広がるため、権限、runner group、監査ログ、バージョン固定のルールを整えてから本番適用するのが安全です。
Actions: Build custom images from custom images で何が変わったのか
GitHub Changelog の発表では、GitHub Actions の custom images for GitHub-hosted runners に新しい機能が追加され、既存のカスタムイメージを土台にして別のカスタムイメージを作成できるようになりました。これにより、組織共通のツールを含む共有ベースイメージを作り、各チームが独自の依存関係を追加する「レイヤー型」のイメージ運用が可能になります。あわせて、ワークフロー内の snapshot キーワードに条件分岐を付け、いつ新しいイメージバージョンを生成するかを制御できるようになっています。(The GitHub Blog)
なお、GitHub Changelog の当該ページは本稿確認時点で「Improvement」と表示されています。社内向けの変更管理では、分類名そのものよりも「GitHub Actions の custom images 運用に影響する機能改善」として扱い、対象リポジトリと運用ルールの確認を優先するとよいでしょう。(The GitHub Blog)
この機能の対象は、一般的な Docker イメージや self-hosted runner の任意のVM管理ではなく、GitHub-hosted larger runners で使う custom images です。GitHub Docs では、custom images は GitHub-hosted larger runners の実行環境を事前に定義し、ツール、依存関係、設定をプリインストールすることで、ワークフローの高速化と実行環境の一貫性向上に役立つものとして説明されています。(GitHub Docs)
管理者が最初に確認すべき影響範囲
まず確認すべきことは、「カスタムイメージを使っているか」ではなく、「カスタムイメージを生成できる経路がどこにあるか」です。今回の変更により、1つのベースイメージが複数チームの派生イメージに影響する構成を取りやすくなります。そのため、管理対象はランナー単体から、ベースイメージ、派生イメージ、生成ワークフロー、runner group、権限、監査ログまで広がります。
| 確認項目 | 管理者が見るポイント | 放置した場合のリスク |
|---|---|---|
| 利用プラン | GitHub-hosted larger runners を利用できる組織・Enterpriseか | そもそも機能を使えず、移行計画が空振りになる |
| 既存の custom images | どのイメージが本番CI/CDで使われているか | 影響範囲が分からないままベースを更新する |
| ベースイメージ | 共通ツール、証明書、SDK、CLI、社内設定をどこに入れるか | チームごとに重複管理され、脆弱性対応が遅れる |
| 派生イメージ | チーム固有の依存関係をどこまで許可するか | ベースの標準化メリットが薄れる |
snapshot | どのブランチ・タグ・スケジュールで生成するか | 意図しないタイミングで新バージョンが増える |
| runner group | 生成用runnerと実行用runnerを分けているか | 開発・検証リポジトリから本番イメージを変更される |
| バージョン | Latest運用か、特定バージョン固定か | 新バージョン適用で突然ビルドが失敗する |
| 監査 | イメージ削除、ポリシー変更、生成ワークフローの実行履歴を追えるか | 変更者・変更理由を後から説明できない |
| コスト | 生成頻度、古いバージョン保持、ストレージ増加を見ているか | 不要なイメージバージョンが増え、請求が膨らむ |
GitHub Docs では、GitHub-hosted larger runners は GitHub Team または GitHub Enterprise Cloud の組織・Enterpriseで利用できるとされています。custom images を使う前に、対象Organizationのプラン、Actionsポリシー、runner groupの設計を確認してください。(GitHub Docs)
重要なのは「ベースイメージの所有者」を決めること
今回のアップデートで便利になるのは、たとえば次のような構成です。
| レイヤー | 管理主体 | 例 |
|---|---|---|
| GitHub提供またはクリーンOS | GitHub側または選択したベース | Ubuntu、Windows、Linux ARM64など |
| 組織共通ベースイメージ | プラットフォームチーム | 社内CA証明書、共通CLI、セキュリティスキャナー、標準Node.js/Python/.NETなど |
| 部門別ベースイメージ | 開発基盤チーム、SRE、データ基盤チーム | Androidビルド用、ML用、社内SDK込みなど |
| アプリ別派生イメージ | 各プロダクトチーム | 特定バージョンのビルドツール、テスト用DBクライアント、追加依存関係など |
この設計にすると、共通ツールの更新をベースイメージ側に集約できます。たとえば、社内証明書や脆弱性スキャナーの更新が必要になった場合、全チームが個別にワークフローを直すのではなく、ベースイメージを更新し、派生イメージを再生成する流れにできます。
ただし、ベースイメージの変更は広範囲に影響します。管理者は、ベースイメージの更新権限を一般の開発リポジトリに広く渡すのではなく、保護された専用リポジトリ、CODEOWNERS、レビュー必須のブランチ保護、専用runner groupを組み合わせて管理するべきです。
権限確認：誰が custom images を作成・管理できるか
GitHub Docs では、custom images を作成・管理するには、Organization ownerまたはEnterprise owner、CI/CD Adminロール、または必要なfine-grained permissionを持つロールが必要とされています。必要な権限として、custom imagesの表示、custom imagesの管理、organization runnersおよびrunner groupsの管理が挙げられています。(GitHub Docs)
管理者は次の3層で権限を見直してください。
| 権限レイヤー | 確認すること | 推奨 |
|---|---|---|
| Enterprise / Organization owner | 所有者が多すぎないか | 緊急対応者を含めつつ、常時権限は最小限にする |
| CI/CD Admin | Actions基盤を管理する担当者だけに付与しているか | 開発チーム代表者ではなく、基盤管理者中心にする |
| リポジトリwrite権限 | image-generation runnerにアクセスできるリポジトリで、誰が任意コードを実行できるか | 本番イメージ生成リポジトリでは保護ブランチとレビューを必須にする |
特に危険なのは、「本番イメージを生成できるrunner groupに、検証用リポジトリや多数の開発者がwrite権限を持つリポジトリを接続する」構成です。GitHub Docs でも、production imagesを生成するrunnerは専用runner groupに置き、productionとdevelopment/testのrunner groupを共有しないこと、public repositoriesにimage-generation runnersへのアクセスを許可しないこと、広範なwrite権限を避けることが推奨されています。(GitHub Docs)
runner group の確認：生成用と実行用を分ける
custom image を作るには、まず image-generation runner を用意します。GitHub Docs では、image-generation runnerを作成する際、生成したいイメージとrunnerのプラットフォームを一致させる必要があり、対応プラットフォームとして Linux x64、Linux ARM64、Windows x64 が示されています。また、既存のcustom imageをベースとして選択できるため、今回のようなレイヤー型イメージ運用が可能になります。(GitHub Docs)
管理者向けには、runner groupを次のように分けるのが実務的です。
| runner group | 用途 | アクセスを許可するリポジトリ |
|---|---|---|
image-gen-prod | 本番用custom imageの生成 | 保護された基盤リポジトリのみ |
image-gen-dev | 検証用custom imageの生成 | 開発基盤チームの検証リポジトリ |
runtime-prod | 本番CI/CDでcustom imageを使う | 本番ビルド対象のリポジトリ |
runtime-dev | 開発・検証CIでcustom imageを使う | 開発チームのリポジトリ |
Organization-level runner groupは、既定ではOrganization内の全リポジトリにアクセスが付与される場合があるため、必要なリポジトリだけに絞る設定が重要です。GitHub Docs では、runner groupを使ってlarger runnersへのリポジトリアクセスを制御できること、Organization-level runner groupでは制限しない限り全リポジトリにアクセスが付与されることが説明されています。(GitHub Docs)
snapshot の条件分岐でイメージ生成タイミングを制御する
custom image の生成は、image-generation runner上で snapshot キーワードを含むワークフローを実行して行います。GitHub Docs では、snapshot を含むジョブが成功するたびに新しいイメージバージョンが作成されること、複数ジョブに snapshot を入れるとジョブごとに別のイメージが作成されることが説明されています。(GitHub Docs)
今回のアップデートでは、snapshot に if 条件を付けられるため、タグビルドや検証ブランチではイメージを作らず、mainブランチや手動実行時だけ生成する、といった制御がしやすくなります。GitHub Docs の例でも、タグビルドではイメージ作成をスキップする条件指定が示されています。(GitHub Docs)
name: Build production base image
on:
workflow_dispatch:
schedule:
- cron: "0 18 * * 0"
jobs:
build-base-image:
runs-on: image-gen-prod-linux-x64
snapshot:
if: ${{ github.ref == 'refs/heads/main' }}
image-name: org-base-linux
version: 1.*
steps:
- uses: actions/checkout@v4
- name: Install common tools
run: |
sudo apt-get update
sudo apt-get install -y jq unzip
./scripts/install-company-ca.sh
./scripts/install-security-tools.sh実務では、snapshot を「ビルドのたびに何となく実行するもの」として扱わないことが大切です。新しいイメージバージョンの作成は、CI実行環境そのものの変更です。アプリケーションの依存関係更新より影響が大きい場合もあるため、生成条件、レビュー、承認、ロールバック方法をセットで設計してください。
バージョン管理：Latest と固定バージョンを使い分ける
custom image では、イメージ名とバージョンの扱いも管理ポイントになります。GitHub Docs では、イメージ名だけを指定した場合は初回が 1.0.0 となり、同名イメージがある場合は 1.1.0、1.2.0 のようにminor versionが増えると説明されています。mapping syntaxでmajor versionを指定した場合も、同じmajor versionが存在すればminor versionが増えます。また、patch versionはサポートされていません。(GitHub Docs)
さらに注意すべきなのが Latest です。GitHub Docs では、イメージの最新ワークフロー実行が常に latest としてタグ付けされること、runner作成時に Latest を選ぶと新しいイメージバージョンが利用可能になった際に自動更新され、特定バージョンに固定した場合は手動で更新が必要になることが説明されています。(GitHub Docs)
| 環境 | 推奨する指定 | 理由 |
|---|---|---|
| 開発・検証 | Latestでも可 | 新しいベースを早く試せる |
| ステージング | 期間限定でLatest、安定後に固定 | 本番前の影響確認に使える |
| 本番CI/CD | 特定バージョン固定を基本 | 意図しない更新でビルドが壊れるリスクを抑える |
| セキュリティ緊急対応 | 固定バージョンを短期間で更新 | 変更履歴を残しながら迅速に差し替える |
本番環境では、runnerに設定したイメージバージョンと、リリースしたアプリケーションのビルド番号を紐づけておくと、障害調査が楽になります。たとえば「アプリv3.8.2は org-base-linux の 1.12.0 でビルドした」と記録しておけば、後から同じ条件で再ビルドしやすくなります。
派生イメージの有効期限に注意する
custom imageからcustom imageを作る場合、派生イメージの有効期限は独立して考えられません。GitHub Docs では、custom imageが別のcustom imageから作られた場合、派生イメージはベースイメージのexpiration timelineを継承し、最大バージョン年齢は派生イメージの作成時点ではなくベースイメージの作成時点から計算されると説明されています。(GitHub Docs)
これは実務で見落としやすいポイントです。たとえば、ベースイメージAを月初に作り、そこから派生イメージBを月末に作った場合、Bは「作ったばかりだから長く使える」とは限りません。ベースAの有効期限に引きずられるため、派生イメージの再生成計画もベースイメージの更新スケジュールに合わせる必要があります。
対策として、管理台帳には少なくとも次の情報を入れてください。
| 管理項目 | 記録例 |
|---|---|
| ベースイメージ名 | org-base-linux |
| ベースバージョン | 1.12.0 |
| 派生イメージ名 | team-a-node-build |
| 派生バージョン | 2.4.0 |
| 生成元リポジトリ | platform/image-pipelines |
| 生成ワークフロー | .github/workflows/build-team-a-image.yml |
| 生成runner group | image-gen-prod |
| 利用runner | team-a-prod-runner |
| 利用リポジトリ | team-a/web-api |
| 本番適用日 | 2026-06-xx |
| ロールバック先 | 2.3.0 |
コスト確認：生成頻度と古いバージョン保持を見直す
custom imageは、ワークフローの高速化に役立つ一方で、生成頻度と保持バージョン数によってストレージ利用が増えます。GitHub Docs では、custom imagesを使うジョブはそのイメージを使うlarger runnerと同じ分単位料金で課金され、custom imagesのストレージはGitHub Actions storageとして別途課金されると説明されています。また、snapshot を含むジョブが成功するたびに新しいイメージバージョンが作られるため、頻繁な再ビルドと古いバージョン保持によりストレージ使用量が急増する可能性があります。(GitHub Docs)
管理者は、次のような基準で生成頻度を決めるとよいでしょう。
| 用途 | 生成頻度の目安 | 判断基準 |
|---|---|---|
| 組織共通ベース | 週1回または重要更新時 | セキュリティパッチ、共通ツール更新、証明書更新 |
| チーム別派生 | ベース更新後、または依存関係変更時 | ベース更新の検証後に再生成 |
| 緊急対応 | 必要時のみ | 脆弱性修正、証明書失効、ビルド障害の回避 |
| 実験用 | 短期・低保持 | 不要になったら削除する前提 |
GitHub Docs では、依存関係を最新に保ちセキュリティパッチを取り込むため、イメージ生成を週次のscheduled workflowとして構成することが推奨されています。ただし、すべての派生イメージを毎日生成するとコストと管理負荷が増えやすいため、本番系は「週次＋重要更新時」、検証系は短い保持期間で運用するなど、用途別に分けるのが現実的です。(GitHub Docs)
監査確認：何が変更されたかを追える状態にする
custom images はCI/CDの実行環境そのものです。監査では、アプリケーションコードの変更だけでなく、イメージ生成ワークフロー、runner group設定、custom image policy、イメージ削除、バージョン削除を追える状態にしておく必要があります。
GitHub Docs の組織監査ログイベントには、custom image関連として org.delete_custom_image、org.delete_custom_image_version、org.update_custom_images_policy が掲載されています。これらは、custom imageやバージョンが削除された場合、またはEnterpriseがOrganizationのGitHub Actions custom image policy settingsを更新した場合の確認に使えます。(GitHub Docs)
また、Organizationの監査ログは、誰が、何を、いつ実行したかを確認でき、action、actor、repo、created などの条件で検索できます。GitHub Docsでは、Organizationの監査ログには過去180日以内のイベントが含まれ、既定表示は過去3か月分であること、CSVまたはJSONでエクスポートできることも説明されています。(GitHub Docs)
監査で最低限見るべきクエリ例は次のとおりです。
action:org.update_custom_images_policy created:>=2026-06-18action:org.delete_custom_image created:>=2026-06-18action:org.delete_custom_image_version created:>=2026-06-18監査ログだけでなく、custom images画面、ワークフロー実行履歴、runner設定も組み合わせて確認してください。GitHub Docs では、Organizationの Settings から Actions、Custom images に進むことで、作成済みのcustom imagesを確認し、詳細情報の表示や不要なイメージ・バージョンの削除ができると説明されています。(GitHub Docs)
移行手順：単体イメージからレイヤー型運用へ移す
既存の custom images を使っている組織は、いきなり全チームをレイヤー型に移行するのではなく、影響の少ないチームから段階的に進めるのが安全です。
| 手順 | 作業内容 | 完了条件 |
|---|---|---|
| 1 | snapshot を含むワークフローを洗い出す | 生成リポジトリ、生成runner、イメージ名が一覧化されている |
| 2 | 本番で使われているlarger runnerを洗い出す | runner名、runner group、利用リポジトリ、イメージバージョンが分かる |
| 3 | 共通化できる依存関係を分類する | ベースに入れるもの、派生に残すものが決まっている |
| 4 | ベースイメージの所有者を決める | 更新権限、レビュー責任者、緊急更新ルールが決まっている |
| 5 | 生成用runner groupを分離する | 本番・検証・実行用が分かれている |
| 6 | snapshot.if を設定する | main、手動実行、スケジュールなど生成条件が明確 |
| 7 | 検証用runnerで派生イメージを試す | 代表リポジトリのCIが成功している |
| 8 | 本番runnerを固定バージョンで切り替える | ロールバック先バージョンが記録されている |
| 9 | 監査・コスト確認を運用に組み込む | 定期レビューの担当者と頻度が決まっている |
GitHub Docs では、custom imageの生成後、利用可能になるまで時間がかかる場合があり、runnerのサイズや構成によっては大きなrunnerで数時間かかる可能性があると説明されています。移行当日に「ワークフロー完了＝すぐ本番runnerで利用可能」と考えると、切り替え作業が遅れることがあります。(GitHub Docs)
周知ポイント：開発チームに伝えるべきこと
管理者だけで設定を変えると、開発チームは「急にCI環境が変わった」「ローカルでは通るのにActionsだけ失敗する」と感じやすくなります。周知では、機能の詳細よりも、開発者の行動に関係するルールを具体的に伝えることが重要です。
周知文には次の内容を含めると実務で混乱しにくくなります。
| 周知項目 | 伝える内容 |
|---|---|
| 何が変わるか | 共通ベースイメージをもとにチーム別custom imageを作る運用に移行する |
| 開発者が変更すること | 原則として通常のアプリCIは runs-on の指定以外を変更しない |
| 依存関係の追加方法 | ベースに入れるものは基盤チームへ申請、チーム固有のものは派生イメージで管理 |
| 禁止事項 | 本番image-generation runnerを検証用リポジトリから使わない |
| 障害時の連絡先 | イメージ更新によるCI失敗は基盤チームに連絡する |
| ロールバック | 本番runnerは固定バージョン運用にし、問題時は前バージョンへ戻す |
社内告知の例は次のとおりです。
GitHub Actions の custom images 運用を見直し、共通ベースイメージを利用したレイヤー型構成へ移行します。
今後、全社共通ツール、証明書、セキュリティスキャナーは基盤チーム管理のベースイメージに集約します。
各チーム固有のビルド依存関係は、チーム別の派生イメージで管理します。
本番用custom imageを生成できるrunner groupは、指定された基盤リポジトリからのみ利用できます。
アプリケーションリポジトリ側で本番用image-generation runnerを直接指定しないでください。
CI失敗がイメージ更新に起因する可能性がある場合は、ワークフロー実行ログの「Set up job」に表示されるイメージ名とバージョンを添えて、基盤チームへ連絡してください。失敗しやすいポイントと対策
開発用リポジトリから本番イメージを作れてしまう
最も避けたいのは、開発・検証用リポジトリのwrite権限を持つユーザーが、本番用custom imageを生成できる状態です。GitHub Docs でも、image-generation runnersにアクセスできるリポジトリにwrite権限を持つユーザーは、任意のブランチからコードを実行してイメージ生成を引き起こせる可能性があるため、最小権限を適用するよう注意されています。(GitHub Docs)
対策は、production用のimage-generation runnerを専用runner groupに置き、アクセスできるリポジトリを基盤管理用に限定することです。あわせて、生成ワークフローはmainブランチのみ、CODEOWNERSレビュー必須、手動実行権限の限定を組み合わせてください。
snapshot を複数ジョブに入れてイメージが増えすぎる
build、test、package の各ジョブに何となく snapshot を入れると、ジョブごとに別イメージが作られ、意図しないバージョン増加につながります。GitHub Docs では、1つのイメージまたは1つのイメージバージョンだけを生成したい場合、すべてのステップを1つのジョブに含める必要があると説明されています。(GitHub Docs)
対策は、イメージ生成専用ワークフローを作り、アプリケーションの通常CIとは分離することです。
本番runnerで Latest を使い、突然ビルドが変わる
Latest は便利ですが、本番CI/CDでは予期しない変更になります。新しいイメージが生成された瞬間に本番runnerが更新されると、ビルドツール、SDK、証明書、CLIの違いで失敗する可能性があります。
対策は、本番runnerでは特定バージョンを固定し、検証用runnerで Latest を試してから本番runnerを手動更新することです。GitHub Docs でも、runner作成時に Latest または特定バージョンを選択でき、固定した場合は後で手動更新が必要になると説明されています。(GitHub Docs)
派生イメージの有効期限を見落とす
派生イメージを作った直後でも、ベースイメージの有効期限が近ければ、派生イメージも長く使えない可能性があります。これはレイヤー型運用で特に見落としやすい点です。(GitHub Docs)
対策は、ベース更新後に派生イメージをまとめて再生成するスケジュールを作ることです。ベースだけ更新して派生を放置すると、各チームのCI環境が古いまま残ることがあります。
イメージ更新の責任範囲が曖昧になる
「共通ツールは基盤チーム」「アプリ固有の依存関係は各チーム」という境界を決めないと、依存関係の追加依頼がすべて基盤チームに集中します。逆に、各チームが自由に派生イメージを作りすぎると、標準化のメリットが失われます。
対策は、ベースに入れる条件を明文化することです。たとえば、3チーム以上で使うツール、セキュリティ上全社で統一すべきツール、ネットワークや証明書など環境標準に関わる設定はベースへ入れます。一方、特定アプリだけが使うテストツールや一時的な検証ツールは派生イメージに残します。
管理者向けチェックリスト
最後に、GitHub管理者が実際に確認すべき項目を整理します。
| 分類 | チェック内容 | 優先度 |
|---|---|---|
| 影響範囲 | custom imagesを使うlarger runnerを一覧化した | 高 |
| 影響範囲 | snapshot を含むワークフローを検索した | 高 |
| 権限 | custom images管理権限を持つユーザー・ロールを確認した | 高 |
| 権限 | CI/CD Adminロールの付与対象を見直した | 高 |
| runner group | image-generation runner用の専用runner groupを用意した | 高 |
| runner group | public repositoryから生成用runnerへアクセスできない | 高 |
| セキュリティ | 本番生成リポジトリにブランチ保護とレビューを設定した | 高 |
| バージョン | 本番runnerで Latest を使うか固定するかを決めた | 高 |
| 監査 | org.update_custom_images_policy などの監査ログ確認手順を用意した | 中 |
| コスト | イメージ生成頻度と保持バージョン数を決めた | 中 |
| 移行 | ベースイメージと派生イメージの命名規則を決めた | 中 |
| 周知 | 開発チーム向けに利用ルールと問い合わせ先を共有した | 中 |
| 運用 | ベース更新後に派生イメージを再生成する手順を決めた | 中 |
| 障害対応 | 前バージョンへ戻すロールバック手順を確認した | 高 |
今回の Actions: Build custom images from custom images は、GitHub Actions の実行環境を標準化しやすくする便利な機能です。ただし、管理者にとっては「イメージを作れるようになった」ではなく、「CI/CDの土台を階層的に管理できるようになった」と捉えるべき変更です。
まずは、既存のcustom images、image-generation runner、runner group、snapshot ワークフローを棚卸ししてください。そのうえで、ベースイメージの所有者、生成権限、監査ログ、バージョン固定、周知ルールを整えれば、ビルド高速化とガバナンス強化の両方を実現しやすくなります。
コメント