GitHub Actions Freeプランのストレージ上限に達したときの対処法

2026年3月24日

1 はじめに
2 事の発端
3 Actions storageとは何か？
- 3.1 私の環境
4 ストレージ使用量の確認方法
5 キャッシュとアーティファクトの違い
6 アーティファクトの手動削除
- 6.1 GUIで1件ずつ削除する方法
- 6.2 GitHub CLIで一括削除する方法
7 アーティファクトが自動削除するようにビルド時に設定する
8 $0バジェットの確認

はじめに

いつもブログをご覧いただきありがとうございます。

ミジンコに転生したIPUSIRONです😀

IPUSIRONのプロフィールを見る

GitHub Actionsのストレージ使用量を削減する方法を紹介します。

事の発端

ある日、GitHubから"You have used 90% of the Actions storage included for the ipusiron account"というメールが届きました。

GitHub Actionsのストレージ使用量が90%（0.45GB / 0.5GB）に達したという警告のようです。

あと8日で月次リセットされるとはいえ、その間もガンガンとGitHub Actionsを使う予定です。つまり、解決策としては課金するか、GitHub Actionsの使用量を圧迫している不必要なファイルを削減するかになります。今回は後者の方法を選択しました。

アーティファクトはデフォルトで90日間保持され、その後自動的に削除されます。
頻繁にpushしていると90日経って古いものが消えるより先に新しいものが積み上がってストレージ上限に達しそうになり警告メールがきたというわけです。

Actions storageとは何か？

GitHub Actionsには2つの使用量メトリクスがあります。混同しやすいので注意が必要です。

メトリクス	内容	Freeプランの上限
Actions minutes	ワークフローの実行にかかるCPU時間	月2,000分
Actions storage	ワークフローが生成したキャッシュやアーティファクト（ビルド成果物）の保存容量	月0.5Gバイト

今回の警告は後者のActions storageです。つまり、ワークフローの「実行時間」ではなく、ビルドで生成されたPDFなどの「成果物の容量」が積み上がっていたわけです。

私の環境

私はRe:VIEWで技術同人誌を執筆しており、GitHubにpushするたびにGitHub ActionsでDockerベースのPDFビルドが走ります。具体的には、1回のビルドで印刷所入稿用PDF（トンボあり）と読者配布用PDF（トンボなし）の2つのアーティファクトが生成されます。

たとえば、120回のpushで240個のPDFが溜まっていた計算になります。

ちなみに、GitHub Actionsでアーティファクトを生成する方法は、以下の記事で紹介しています。

GitHub ActionsでRe:VIEWを自動ビルドする方法【ミジンコ環境向け・2026年版】

Re:VIEWのPDFビルドをGit Actionsにさせてしまう戦法です。 build.xmlをさらに改良した GitHub Actions ...

https://akademeia.info/?p=49108

ストレージ使用量の確認方法

1：GitHubのアイコンを押して、「Settings」を選びます。

2：「Setting」画面が表示されますので、「Billing and licensing」＞「Overview」を選びます。

真ん中にある「Metered usage」で、Actionsタブを選びます。

すると、以下の2つの使用量が表示されます。

Actions minutes：実行時間の使用量（例：212 min / 2,000 min）
Actions storage：ストレージの使用量（例：0.5 GB / 0.5 GB）

また、その下の「Usage by repository」セクションで、どのリポジトリがどれだけストレージを消費しているかも確認できます。

警告メールのとおり、残り0.5GBとなっています。
バーを見ても、空き残量が残り少ないことも一目瞭然です。

キャッシュとアーティファクトの違い

ストレージを消費するのは主に以下の2つです。

種類	説明	確認場所
Caches	依存関係などのキャッシュ	リポジトリ → Actions → 左サイドバー「Caches」
Artifacts	ビルド成果物（PDF、ログなど）	リポジトリ → Actions → 各ワークフロー実行の詳細ページ下部

私の場合、Cachesは0件でした。
つまり、ストレージを圧迫していたのはすべてアーティファクト（PDF）だったわけです。

アーティファクトの手動削除

GUIで1件ずつ削除する方法

リポジトリの「Actions」タブを開く
ワークフロー実行の一覧から、削除したい実行をクリック
ページ下部の「Artifacts」セクションに成果物が表示される
ゴミ箱アイコンをクリックして削除

しかしながら、今回のように240ファイル分を1つずつ消すのは現実的ではありません。
リセットまで残り数日で、数ファイル消せば耐えれるというときの対処法になります。

GitHub CLIで一括削除する方法

GitHub CLI（ghコマンド）を使えば一括削除できます。

$ REPO="ユーザー名/リポジトリ名"
$ gh run list --repo "$REPO" --limit 100 --json databaseId -q '.[].databaseId' \
  | xargs -I {} gh api "repos/$REPO/actions/runs/{}/artifacts" --jq '.artifacts[].id' \
  | xargs -I {} gh api -X DELETE "repos/$REPO/actions/artifacts/{}"

このコマンドは3段階で処理されます。

gh run listコマンド：直近120回分のワークフロー実行IDを取得
gh api …/artifactsコマンド：各実行に紐づくアーティファクトのIDを取得
gh api -X DELETEコマンド：各アーティファクトを削除

なお、事前にgh auth loginでGitHub CLIの認証を済ませておく必要があります。

私の場合は、以下のワンライナーコマンドを実行しました。

$ gh run list --repo ipusiron/book_ClaudeCodeCryptanalysis --limit 120 --json databaseId -q '.[].databaseId' | xargs -I {} gh api repos/ipusiron/book_ClaudeCodeCryptanalysis/actions/runs/{}/artifacts --jq '.artifacts[].id' | xargs -I {} gh api -X DELETE repos/ipusiron/book_ClaudeCodeCryptanalysis/actions/artifacts/{}

注意点

最新のビルド成果物も含めて全部消える。直近のPDFが必要なら、事前にダウンロードしておくこと。
処理には数分かかる。エラーが返らなければ正常に処理が進んでいる。
実行直後はSettingsのストレージ表示に反映されない（タイムラグがある）。ただし、Actionsタブから個別のワークフロー実行を開くと、アーティファクトが消えていることを確認できる。

アーティファクトが自動削除するようにビルド時に設定する

ワークフローのYAMLである"build.yml"ファイル内でretention-daysを設定しておけば、アーティファクトが自動的に削除されれます（デフォルトでは90日で削除されますが、指定日が経過することで削除できる）。

以下は、3日経過後に自動削除する設定です。

- name: Upload PBOOK_PDF
  uses: actions/upload-artifact@v5
  with:
    name: Book PBOOK_PDF
    path: articles/${{ env.BOOKNAME }}.pdf
    retention-days: 3

3日もあればビルド結果の確認には十分でしょう。