GitHub Actionsの保持期間を変更する方法|2026年10月の履歴削除に備える

2026年10月1日から、GitHub Actionsのchecks、workflow runs、statusesは、Artifactとログに使用されているActions保持期間に従って削除されるようになります。従来は設定にかかわらず400日超保持されていましたが、変更後は既定で90日です。([GitHub Blog][1])

保持期間を変更する場所は、リポジトリの場合、2026年9月11日時点でSettings > Actions > General > Artifact and log retentionです。公開リポジトリは1~90日、非公開リポジトリは1~400日の範囲で設定できます。ただし、OrganizationやEnterpriseで設定された上限を超えることはできません。([GitHub Docs][2])

90日を超えて実行履歴を残す必要がある場合は、2026年10月1日より前に保持期間を見直し、設定上限を超えるデータについては外部保管の方法を決めておく必要があります。

目次

2026年10月1日から何が変わるのか

今回の変更では、GitHub Actionsに関する次のデータが、同じ保持期間設定で管理されるようになります。

対象2026年9月30日まで2026年10月1日以降
Checks設定にかかわらず400日超保持Actions保持期間に従う
Workflow runs設定にかかわらず400日超保持Actions保持期間に従う
Statuses設定にかかわらず400日超保持Actions保持期間に従う
ArtifactsすでにActions保持期間に従う変更なし
LogsすでにActions保持期間に従う変更なし

設定が既定値の90日のままであれば、変更後は90日を過ぎたチェック結果、ワークフロー実行履歴、ステータスが削除対象になります。GitHubは、設定期間を超えたデータを自動的にクリーンアップすると案内しています。([GitHub Blog][1])

ここでいう「履歴」は、GitHub Actionsのワークフロー実行やチェックに関する履歴です。長期間にわたる障害調査、リリース記録、監査証跡としてワークフロー実行結果を参照している場合は、影響を受ける可能性があります。

リポジトリの保持期間を変更する手順

個別のリポジトリで保持期間を変更する場合は、次の手順で設定します。

  1. 対象リポジトリを開く
  2. リポジトリ上部の「Settings」を選択する
  3. 左側のメニューから「Actions」を開く
  4. 「General」を選択する
  5. 「Artifact and log retention」まで移動する
  6. 保持する日数を入力する
  7. 「Save」を選択する

2026年9月11日時点の設定経路は、次のとおりです。

Repository > Settings > Actions > General > Artifact and log retention

GitHubは、2026年10月の変更に合わせて、設定項目の表示名を「Check, workflow run, status, artifact and log retention」へ変更すると案内しています。実際の表示名はリリース時期やUI更新によって変わる可能性があるため、10月以降に「Artifact and log retention」が見つからない場合は、retentionを含む設定項目を確認してください。([GitHub Blog][1])

Organization単位で保持期間を変更する場所

Organization全体の上限や既定の保持期間を管理する場合は、Organizationの設定画面を使用します。

Organization > Settings > Actions > General > Artifact and log retention

設定手順は次のとおりです。

  1. 対象Organizationのページを開く
  2. 「Settings」を選択する
  3. 左側のメニューから「Actions」を開く
  4. 「General」を選択する
  5. 「Artifact and log retention」に日数を入力する
  6. 「Save」を選択する

Organizationで設定した値は、配下のリポジトリが設定できる保持期間の上限になります。たとえばOrganizationの上限が120日の場合、非公開リポジトリであっても、リポジトリ側から400日には設定できません。([GitHub Docs][3])

複数のリポジトリを管理している場合は、最初にOrganizationの設定を確認してから、例外的に長期保存が必要なリポジトリを個別に調整すると管理しやすくなります。

Enterprise単位で保持期間を変更する場所

GitHub Enterprise CloudのEnterpriseレベルでは、次の設定経路を使用します。

Enterprise > Policies > Actions > Artifact and log retention

Enterpriseの保持期間は、配下のOrganizationとリポジトリが設定できる最大値として機能します。Enterpriseで上限を設定した場合、Organizationやリポジトリ側でその値を超える設定はできません。([GitHub Docs][4])

設定階層は次のように考えると分かりやすくなります。

設定階層主な役割下位設定への影響
EnterpriseEnterprise全体の最大値を管理Organizationとリポジトリの上限になる
OrganizationOrganization内の最大値を管理配下リポジトリの上限になる
Repository個別リポジトリの実際の保持期間を設定上位の上限以内で変更できる

リポジトリ側で希望する日数を入力できない場合は、入力ミスだけでなく、OrganizationまたはEnterpriseの上限を確認してください。

設定できる保持期間

GitHub ActionsのArtifactとログの保持期間は、リポジトリの公開範囲によって上限が異なります。

リポジトリの種類設定できる期間
Public repository1~90日
Private repository1~400日
Internal repository1~400日

Internal repositoryは、GitHub Enterprise Cloudなどで利用される公開範囲です。OrganizationやEnterpriseで管理されている場合は、表の上限よりも上位設定が優先されます。([GitHub Docs][2])

公開リポジトリでは90日を超えて設定できない

公開リポジトリは最大90日です。180日や400日を入力して長期保存することはできません。

公開リポジトリで90日を超える履歴が必要な場合は、GitHub上の保持期間を延ばすのではなく、必要なデータを別の保管先へ保存する運用を検討します。

非公開リポジトリでも必ず400日にできるとは限らない

Private repositoryやInternal repositoryの仕様上の上限は400日ですが、OrganizationやEnterpriseの上限が90日や180日に設定されていれば、その値を超えることはできません。

「非公開だから400日にできる」と判断せず、次の順番で確認してください。

  1. Enterpriseの上限
  2. Organizationの上限
  3. Repositoryの設定値

既存データに遡って保持期間が延びるわけではない

保持期間を変更するときに特に注意したいのが、既存データへの適用です。

GitHubの現行ドキュメントでは、Artifactとログの保持期間を変更しても、新しいArtifactとログにだけ適用され、既存のオブジェクトには遡及しないと説明されています。たとえば保持期間を90日から400日に変更しても、すでに作成済みのArtifactやログが一律に400日保存へ切り替わるとは限りません。([GitHub Docs][2])

一方、2026年10月の変更では、checks、workflow runs、statusesが、設定済みのActions保持期間に従って削除されるようになります。GitHubは、必要な履歴を保持できる期間になっているか、10月1日より前に設定を確認するよう案内しています。([GitHub Blog][1])

対象と適用時点を整理すると、次のようになります。

操作・変更影響
Artifact・ログの保持期間を変更原則として変更後に作成される新しいArtifact・ログに適用
2026年10月の新ポリシー開始Checks、workflow runs、statusesがActions保持期間の対象になる
削除後に保持期間を延長すでに削除されたデータは復元されない

「削除されてから保持期間を延ばせば戻せる」という運用はできません。残す必要がある履歴は、削除対象になる前に対応する必要があります。

保持期間は何日に設定すべきか

すべてのリポジトリを最大日数に設定する必要はありません。次の観点から必要期間を決めます。

障害を何日前まで遡って調査するか

障害やデプロイ失敗が発覚するまでの期間を確認します。

毎日確認しているCIであれば90日以内で足りる場合があります。一方、四半期ごとのリリースや、数か月後に問い合わせが発生するシステムでは、90日では不足する可能性があります。

リリースサイクルを何回分残すか

月次リリースなら90日で約3回分ですが、半年ごとのリリースでは前回の実行履歴が残らない可能性があります。

単純な日数ではなく、「何回分のリリース履歴を参照したいか」で判断すると、必要期間を決めやすくなります。

監査や証跡として必要か

ワークフローの実行結果を監査資料や変更管理の証跡として使っている場合は、組織内の保存ルールを確認します。

公開リポジトリでは最大90日、非公開・Internal repositoryでも最大400日です。必要期間が上限を超える場合は、GitHub上の設定だけでは要件を満たせません。

Artifactとログの保存容量を許容できるか

checks、workflow runs、statusesのメタデータ自体は、GitHub Actionsのストレージ課金対象ではありません。ただし、保持期間を延ばすと、それらに関連するArtifactとログも長期間保存されるため、課金対象のActionsストレージ使用量が増える可能性があります。([GitHub Blog][1])

実際の増加量は、ワークフローの実行回数、ログ量、Artifactのサイズによって変わります。保持期間を90日から400日にしただけで、費用が一定額増えるわけではありません。

90日を超えて履歴が必要な場合の対応

設定可能な上限を超えて履歴を残す必要がある場合は、2026年10月1日より前に外部保管の計画を立てます。

GitHubの告知でも、設定した保持期間を超えて必要になるデータは、エクスポートまたはアーカイブするよう案内されています。([GitHub Blog][1])

ただし、単にデータを保存するだけでは、実務で利用できないことがあります。少なくとも次の項目を決めておく必要があります。

  • どのリポジトリを保存対象にするか
  • どのワークフローや実行結果を残すか
  • 何年間保存するか
  • 誰が保存作業を担当するか
  • 保存先へのアクセス権をどう管理するか
  • 実行日時、コミット、ブランチ、結果をどう検索できるようにするか
  • 保存データが監査や障害調査で利用できるか

具体的な取得方法や復元方法は、利用しているGitHubプラン、必要なデータ、社内の保管基盤に応じて事前検証してください。未検証の取得手順を本番運用に組み込むのは避けるべきです。

よくある設定ミス

Cache retentionを変更してしまう

GitHub Actionsには、Artifactとログとは別にCacheの保持設定があります。

Cache retentionを変更しても、2026年10月からchecks、workflow runs、statusesに適用される保持期間を変更したことにはなりません。確認する項目は、2026年9月時点では「Artifact and log retention」です。([GitHub Docs][2])

リポジトリだけ確認して上位設定を見落とす

リポジトリに400日を入力できない場合、OrganizationやEnterpriseの上限が原因になっている可能性があります。

複数階層で管理している環境では、リポジトリだけでなく上位ポリシーも確認します。

10月1日以降に確認すればよいと考える

保持期間を過ぎたデータは削除対象になり、削除済みデータは保持期間を延ばしても戻りません。長期保存が必要な場合は、変更開始前の確認が必要です。([GitHub Blog][1])

最大日数にすれば安全だと考える

保持期間を長くすると調査可能な期間は広がりますが、Artifactとログの保存期間も延びます。必要性を確認せず全リポジトリを400日にすると、Actionsストレージ使用量が増える可能性があります。

重要度やリリース周期に応じて、リポジトリを分類して設定する方が現実的です。

2026年10月1日までに確認するチェックリスト

変更に備えて、次の順番で確認します。

  • Enterpriseの保持期間上限を確認する
  • Organizationの保持期間上限を確認する
  • 各リポジトリの現在値を確認する
  • 90日を超えて必要な履歴があるか整理する
  • Public repositoryで90日を超える履歴が必要か確認する
  • Private・Internal repositoryで必要な日数を決める
  • Artifactとログのストレージ使用量への影響を確認する
  • 上限を超えて必要な履歴の外部保管を計画する
  • 変更後の設定値と判断理由を記録する

最初に行うべきことは、対象リポジトリのSettings > Actions > Generalを開き、現在の保持期間を確認することです。

既定の90日で問題なければ、設定変更は必須ではありません。90日を超える実行履歴が必要な場合は、上位ポリシーと課金への影響を確認したうえで日数を延長します。設定上限を超える保存が必要なら、2026年10月1日より前に外部保管の対象と方法を決めてください。
[1]: https://github.blog/changelog/2026-08-27-actions-retention-will-cover-checks-workflow-runs-and-statuses/ “Actions retention will cover checks, workflow runs, and statuses – GitHub Changelog”
[2]: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository “Managing GitHub Actions settings for a repository – GitHub Docs”
[3]: https://docs.github.com/en/organizations/managing-organization-settings/configuring-the-retention-period-for-github-actions-artifacts-and-logs-in-your-organization?utm_source=chatgpt.com “Configuring the retention period for GitHub Actions artifacts and logs in your organization – GitHub Docs”
[4]: https://docs.github.com/en/enterprise-cloud%40latest/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise?utm_source=chatgpt.com “Enforcing policies for GitHub Actions in your enterprise – GitHub Enterprise Cloud Docs”

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次