今週は、組織の実際の監査・調査期間に照らして保留設定を確認し、長期保存が必要なCI証拠を別途エクスポートして保管してください。設定を変更しても削除済みデータは復元できず、ビルド成果物の独立した保管方針にもなりません。
企業IT担当者は、組織とリポジトリの設定および上限を確認する際にお読みください。
セキュリティ・コンプライアンス担当者は、公開判断と実行記録の追跡性を点検できます。
Mac CI担当者は、ログと成果物を分けた保管・復元検収に活用できます。
最終更新：2026年10月21日。生効日と対象範囲はGitHubの公式変更告知およびGitHub Actionsの組織向け保留設定を照合しています。実際の設定は対象組織でも確認してください。
保留対象を記録種別ごとに切り分ける
2026年10月1日から、GitHub Actionsの保留設定はチェック、ワークフロー実行、コミットステータスにも適用されます。GitHubは、Actionsとサードパーティー連携が作成した関連するチェックおよびステータスも対象とすることを告知しています。これは、表示される状態情報と、ダウンロード可能なファイルが同じものではないことを意味します。公式告知
変更後に、どの記録が自動的に保留対象になるのでしょうか。 チェック結果、ワークフロー実行、コミットステータスは、それぞれ別の記録として棚卸しします。一方、ログやワークフロー成果物は、実行に関連していても保存・取得方法を分けて確認します。チェック実行のAPI仕様とコミットステータスのAPI仕様を参照し、記録の種類を取り違えないようにします。
| 証拠の対象 | 主な確認元 | 保管の確認点 | 復元検収で確かめること |
|---|---|---|---|
| チェック結果・コミットステータス | Actionsの記録と関連API | 保留設定の適用範囲と記録の参照方法 | 対象コミットと結果の対応を説明できる |
| ワークフロー実行 | 実行履歴 | 実行ID、対象コミット、実行結果の関連付け | 指定した実行を検索し、結果を確認できる |
| ログ | 実行ログ | ダウンロード、外部保管先、閲覧権限 | 保管物を読み出し、実行と結び付けられる |
| テスト報告・ビルド成果物 | ワークフロー成果物と外部保管先 | GitHub上の保留と外部保管を別々に管理 | ファイルの内容と出所を確認できる |
GitHubのワークフロー成果物は、実行記録や状態情報そのものではありません。ワークフロー成果物の説明を確認し、ログ、テスト報告、アーカイブファイル、シンボルファイルなど、監査で必要なファイルを個別に定義してください。
チェックやステータスが画面に残っていることだけでは、必要なログやビルドファイルが取得できる証明になりません。記録の存在確認とファイルの復元確認は、別々の検収項目にします。
公開判断から証拠までの追跡性を確認する
監査証拠として必要なのは、単独の成功表示ではなく、「どのコミットが、どのワークフローで処理され、どのチェック結果や状態を経て公開判断に至ったか」を説明できるつながりです。企業の監査要件に応じて、承認記録や関連する外部システムの情報も範囲に含めます。
ステータスとワークフロー実行記録は、どう組み合わせて残せばよいでしょうか。 コミット識別子を起点に、実行記録、チェック結果、ステータスの提供元を相互に照合できるようにします。サードパーティー連携が作成したチェックやステータスも棚卸し対象に含め、社内の承認記録と対応付ける必要があるかを監査担当者が判断します。
GitHub Actions checks retentionの変更を受けて確認する際は、保存対象の名称だけでなく、記録を誰が取得し、どこで検索できるかまで記録します。例えば、実行記録が参照可能でもログのエクスポートが済んでいなければ、監査や事後調査に必要な詳細を別の場所から復元できるとは限りません。
保留設定と監査期間の適合性を点検する
設定画面の値をそのまま監査期間と見なさず、企業・組織・リポジトリの各設定と、上位設定による制限を照合します。リポジトリ側の設定だけを見て判断せず、組織で有効な保留期間や管理上の上限を、組織向け設定ドキュメントに沿って確認してください。
保留期間を延ばせば、すでに削除されたチェック記録も戻るのでしょうか。 戻りません。変更前に削除された記録の復元手段として設定変更を扱わず、必要な証拠が存在しない場合は、社内のインシデント・監査手順に従って不足を記録します。今後の記録については、監査ウィンドウや調査要件と現行設定を項目ごとに照合し、統一の保留期間を根拠なく決めないことが重要です。
Mac CIのログと成果物を別々にアーカイブする
Mac CIの監査留存では、状態・実行情報、ログ、テスト報告、ビルド成果物の保存責任を区別します。GitHub Actions上の保留設定だけに依存せず、必要な証拠については外部エクスポートと検索用インデックスを設計します。ワークフローログのダウンロード手順とワークフロー成果物の削除方法も確認し、ログと成果物それぞれの扱いを決めます。
ログ、ステータス、成果物をそれぞれどう保管するべきでしょうか。 まず社内要件から必要な証拠を選び、保存先、アクセス権、検索キーを割り当てます。保管先を用意しただけで完了とせず、コミットや公開バージョンから対象の実行記録、ログ、ファイルへ到達できるかを検収します。
| 選択肢 | 保留設定の確認 | 外部保管の設計 | 向いている使い方 |
|---|---|---|---|
| GitHub Actions内の記録を参照 | 必要。組織とリポジトリの適用範囲を確認 | 長期保管が必要な対象は別途検討 | 現行設定内で参照できる記録を確認する |
| 必要な証拠を外部へエクスポート | 必要。対象記録と取得タイミングを定義 | 保存先、索引、アクセス権を設計 | 監査・調査期間に合わせて証拠を保持する |
| エクスポート後に復元検収 | 設定確認に加えて実施 | 読み出しと関連付けを実地確認 | 保管済み証拠を後日使えることまで確かめる |
復元検収と担当者の責任を記録する
「エクスポート済み」は「復元可能」と同じではありません。次の順番で作業すると、設定の証跡、保存物、検索性、権限の確認を分離して記録できます。
- 企業・組織・リポジトリの保留設定を確認し、上位設定と適用上限を記録します。
- 監査・調査要件から、必要なチェック、実行記録、ステータス、ログ、成果物を特定します。
- 対象ごとに取得元、保管先、索引に使う識別情報、アクセス権の責任者を決めます。
- 実際のコミットまたは公開バージョンを起点に証拠を検索し、ログとファイルを読み出します。
- 読み出した内容が対象の実行と結び付くこと、必要な担当者が適切な権限で参照できることを検収記録に残します。
- 例外の承認者、定期的な設定レビューの担当者、検収結果の保管先を明文化します。
記録用の一覧は、例えば次のように、設定の証拠と復元試験を分けて管理できます。
対象コミット: <commit-id>
ワークフロー実行: <run-reference>
チェック・ステータスの取得元: <source-reference>
ログの保管先: <archive-reference>
成果物の保管先: <artifact-reference>
アクセス確認: <review-record>
復元検収: <test-record>
出力例の値は実環境で確認した参照情報に置き換えます。企業管理者は設定、リポジトリ管理者は実行と成果物の取得、安全担当者は保管先とアクセス審査、Mac CI担当者はエクスポートと復元検収を担う形にすると、設定変更の承認者と証拠を実際に使えることの確認者を混同しにくくなります。
今週の見直しをMac CI基盤の選定につなげる
まず証拠マトリクスを使い、現在の設定、外部アーカイブ、復元検収のどこが未確認かを洗い出してください。現在のMac環境を維持する方法は、既存の管理や物理アクセスに向く一方、端末の調達・保守、開発者ごとの環境差、共有ビルド機の運用負担が残る場合があります。リモートMacを使う方法も、証拠のエクスポートや監査要件を自動的に満たすものではありません。
専用のmacOSビルドノードが必要なら、NodeMiniのリモートMac環境を、アクセス制御やチームの運用要件に照らして比較できます。既存のMac miniを調達する場合は、Mac miniの調達方法も選択肢です。いずれの構成でも、GitHub Actionsの記録とビルド成果物の保管・復元責任は別途設計してください。