CircleCI 無料プランでクレジットを最大活用する方法と有料移行の判断基準

2026年6月15日

もっとスキルを活かしたいエンジニアへ

スポンサードリンク

働き方から選べる

無料で使えて良質な案件の情報収集ができるサービス

エンジニアの世界では、「いつでも動ける状態を作っておけ」とよく言われます。
技術やポートフォリオがあっても、自分に合う案件情報を日常的に見れていないと、いざ動こうと思った時に比較や判断が難しくなってしまいます。
普段から案件情報が集まる環境を作っておくと、良い案件が出た時にすぐ動きやすくなりますよ。
筆者自身も、メガベンチャー勤務時代に年収1,500万円を超えた経験があります。振り返ると、技術だけでなく「どんな案件や働き方があるか」を日頃から見ていたことが、キャリアの選択肢を広げるきっかけになりました。
このブログを読んでくれた方に感謝を込めて、実際に使っている情報収集サービスを紹介します。

フルリモート・週3日・高単価、どんな条件も妥協したくないなら

フリーランスボードに無料会員登録する

利用者10万人以上。業界最大規模45万件の案件。AIマッチ機能や無料の相場情報が人気。

年収800万円以上のキャリアアップ・ハイクラス正社員を視野に入れているなら

Beyond Careerに無料相談する

内定獲得率90%以上。紹介先企業とは役員クラスのコネクションがある安心と信頼できるエージェント。

Contents

1 無料プランの概要とクレジット制度
2 リソースクラスとクレジット消費モデル
- 2.1 クレジット計算の実例
3 Free プランの主要制限事項
4 キャッシュ & Workspace の活用テクニック
- 4.1 キャッシュの基本と設定例
- 4.2 Workspace の共有方法
5 テスト結果永続化と store_test_results Orb
- 5.1 設定手順とサンプル
6 並列実行・ワークフロー設計で効率化
- 6.1 parallelism の基本と例
- 6.2 ワークフロー最適化のベストプラクティス
7 クレジットモニタリング・アラート設定、そして有料プランへの移行判断
8 まとめ
- 8.1 参考文献

スポンサードリンク

無料プランの概要とクレジット制度

CircleCI の Free プランは、月間 30,000 クレジット が無償で提供されます。クレジットはジョブ実行時間と選択したリソースクラスに応じて消費され、毎月の残量は UI と API の両方から確認できます。
本セクションでは、無料枠の構成要素と利用開始時に抑えておくべき基本的なルールを解説します。

クレジット上限：30,000 クレジット／月（繰り越しなし）【[1]】
リセットタイミング：各カレンダー月の開始時に自動リセット
適用対象：プライベートリポジトリ・パブリックリポジトリとも同一

ポイント：クレジットは「リソースクラス × 実行時間（分）」で計算されるため、ジョブ設計時にリソースクラスと実行時間のバランスを意識することがコスト最適化の鍵です。

リソースクラスとクレジット消費モデル

CircleCI ではビルド環境ごとに リソースクラス が定義されており、各クラスは分単位で消費するクレジットが公式に決められています。以下の表は2024 年 6 月時点の公式料金ページから抜粋したものです。

リソースクラス	CPU / メモリ	クレジット消費率 (分あたり)
`small`	1 vCPU / 2 GB	1 クレジット/分【[2]】
`medium`	2 vCPU / 4 GB	2 クレジット/分【[2]】
`large`	4 vCPU / 8 GB	4 クレジット/分【[2]】
`xlarge` (GPU)	8 vCPU / 16 GB + GPU	8 クレジット/分（GPU 利用時）【[2]】

根拠：公式ドキュメント「Pricing – Credit Usage」では、上記のクレジット消費率が明示されています。

クレジット計算の実例

small ジョブを 30 分間実行 → 30 × 1 = 30 クレジット
medium ジョブを 15 分間実行 → 15 × 2 = 30 クレジット
同一ジョブ内でリソースクラスを変更した場合は、各ステップごとに消費率が適用されます。

Free プランの主要制限事項

Free プランでは、クレジット以外にもいくつかのハードリミットがあります。公式ドキュメントに基づき、正確な数値を掲載します。

項目	制限内容	参考
同時実行ジョブ数	1（プライベート）／2（パブリック）【[3]】	-
合計ビルド時間 (分)	約 2,500 分/月（パブリック向け無料ビルド分）【[4]】	パブリックリポジトリ限定。プライベートはクレジット制御
キャッシュ保存容量	5 GB/プロジェクト（上限、超過分は自動削除）【[5]】	-
アーティファクト保持期間	30 日まで保存可能【[5]】	-

注意点：本記事ではプライベートリポジトリ向けのクレジット制限（30,000 クレジット）と、パブリックリポジトリ向けの「ビルド分」上限（2,500 分）を併記しています。利用形態に応じて適切な指標でモニタリングしてください。

キャッシュ & Workspace の活用テクニック

キャッシュと workspace は、同一ジョブ間・異なるジョブ間でビルド成果物や依存関係を再利用できる仕組みです。正しく設定すれば、実行時間が短縮されクレジット消費も抑えられます。

キャッシュの基本と設定例

キャッシュはキーを基にヒット判定が行われます。キーにハッシュ化した依存ファイルを組み込むことで、変更時のみ新しいキャッシュが作成されます。

version: 2.1
jobs:
  build:
    docker:
      - image: cimg/node:lts
        resource_class: small   # 1 クレジット/分
    steps:
      - checkout
      - restore_cache:
          keys:
            - node-modules-{{ checksum &quot;package-lock.json&quot; }}
            - node-modules-
      - run: npm ci
      - save_cache:
          paths:
            - ~/.npm
          key: node-modules-{{ checksum &quot;package-lock.json&quot; }}-v1

version: 2.1

jobs:

build:

docker:

- image: cimg/node:lts

resource_class: small # 1 クレジット/分

steps:

- checkout

- restore_cache:

keys:

- node-modules-{{ checksum "package-lock.json" }}

- node-modules-

- run: npm ci

- save_cache:

paths:

- ~/.npm

key: node-modules-{{ checksum "package-lock.json" }}-v1

ポイント：restore_cache のキーは上位互換性を持たせるためにフォールバック（2 行目）を設定し、キャッシュが無い場合でもビルドが止まらないようにします。

Workspace の共有方法

Workspace はジョブ間でファイルシステム全体（または一部ディレクトリ）を受け渡すための仕組みです。以下はテスト結果を次ジョブへ引き継ぐ例です。

jobs:
  test:
    docker:
      - image: cimg/node:lts
        resource_class: small
    steps:
      - checkout
      - run: npm test -- --outputFile=results.xml
      - persist_to_workspace:
          root: .
          paths:
            - results.xml

  deploy:
    docker:
      - image: cimg/node:lts
        resource_class: small
    steps:
      - attach_workspace:
          at: .
      - run: ./deploy.sh results.xml

jobs:

test:

docker:

- image: cimg/node:lts

resource_class: small

steps:

- checkout

- run: npm test -- --outputFile=results.xml

- persist_to_workspace:

root: .

paths:

- results.xml

deploy:

docker:

- image: cimg/node:lts

resource_class: small

steps:

- attach_workspace:

at: .

- run: ./deploy.sh results.xml

ポイント：persist_to_workspace と attach_workspace を組み合わせることで、ビルド成果物の再ダウンロードが不要になり、総実行時間とクレジット消費を削減できます。

テスト結果永続化と `store_test_results` Orb

テスト結果を CircleCI の UI に自動表示させる公式 Orb が circleci/store-test-results です。保存された結果は次回同一コミットで再利用でき、失敗したケースだけをリトライするフローが構築可能です。

設定手順とサンプル

orbs:
  test-results: circleci/store-test-results@0.1

jobs:
  test:
    docker:
      - image: cimg/python:3.11
        resource_class: small
    steps:
      - checkout
      - run:
          name: Run pytest with JUnit output
          command: |
            pytest --junitxml=results.xml
      - test-results/store:
          path: results.xml

orbs:

test-results: circleci/store-test-results@0.1

jobs:

test:

docker:

- image: cimg/python:3.11

resource_class: small

steps:

- checkout

- run:

name: Run pytest with JUnit output

command: |

pytest --junitxml=results.xml

- test-results/store:

path: results.xml

ポイント：store_test_results はジョブ終了時にレポートを CircleCI のテストタブへ送信し、同一コミットでの再実行時は結果がキャッシュとして扱われます。これにより不要なビルド時間（＝クレジット）を削減できます。

並列実行・ワークフロー設計で効率化

Free プランは 同時ジョブ数 1 の制限がありますが、単一ジョブ内で parallelism を利用すれば複数コンテナに分割して処理できます。これにより総実行時間を短縮しつつ、クレジット消費は「使用した合計分」に比例します。

`parallelism` の基本と例

jobs:
  test:
    docker:
      - image: cimg/python:3.11
        resource_class: medium   # 2 クレジット/分
    parallelism: 4               # 同一ジョブを 4 分割実行
    steps:
      - checkout
      - run:
          name: Run tests in parallel
          command: |
            pytest -n $CIRCLE_NODE_TOTAL --maxfail=1

jobs:

test:

docker:

- image: cimg/python:3.11

resource_class: medium # 2 クレジット/分

parallelism: 4 # 同一ジョブを 4 分割実行

steps:

- checkout

- run:

name: Run tests in parallel

command: |

pytest -n $CIRCLE_NODE_TOTAL --maxfail=1

消費クレジット：medium (2 クレジット/分) × 実行時間（分）× parallelism の総和
効果：テスト全体の壁時計時間が約 1/4 に短縮され、結果的に同じクレジットで処理できるケースが増える

ワークフロー最適化のベストプラクティス

手法	内容	メリット
ステージ分割	ビルド → テスト → デプロイを明示的に分離	失敗時の早期停止で無駄なクレジット消費防止
条件付き実行 (`when`, `filters`)	変更がないモジュールはテストをスキップ	不要ジョブの削減
キャッシュ共有	ビルドジョブとテストジョブで同一キャッシュキー使用	再利用率向上、`npm ci` 等の時間短縮

ポイント：これらの設計は「クレジットあたりの処理量」を最大化することを目的にしています。

クレジットモニタリング・アラート設定、そして有料プランへの移行判断

Free プランでもクレジット使用状況は UI と API の両方でリアルタイムに取得できます。閾値ベースのアラートを設定すれば、予算超過リスクを未然に防げます。

ダッシュボードと API

ダッシュボード：左メニュー → Usage → Credits で月間使用量と残量がグラフ表示【[1]】
API エンドポイント：GET https://circleci.com/api/v2/me/credits（認証トークン必須）【[6]】

curl -s -H &quot;Circle-Token: $CIRCLE_TOKEN&quot; \
     https://circleci.com/api/v2/me/credits | jq .

curl -s -H "Circle-Token: $CIRCLE_TOKEN" \

https://circleci.com/api/v2/me/credits | jq .

アラート設定手順

「Credits」ページ右上の Set Alert をクリック。
「Threshold（例：80 %）」「通知先（メール / Slack）」を選択。
保存すると、クレジット使用率が閾値に達した瞬間に指定チャネルへ通知されます。

有料プラン（Performance）への移行タイミング

以下の条件が同時に見られた場合は、有料プランへの切り替えを検討してください。

クレジット使用率が 80 % を超える
同時実行ジョブ数の増加が必要（Performance プランではデフォルト 3〜10）【[7]】
ストレージ・キャッシュ上限に頻繁に到達

Performance プランは「追加クレジット $15 / 25,000 クレジット」の従量課金が可能です（公式料金ページ参照）【[1]】。必要な分だけ購入できるため、突発的なビルド増加にも柔軟に対応できます。

まとめ

CircleCI Free は 30,000 クレジット／月 が提供され、クレジットは「リソースクラス × 実行時間」で消費されます（small = 1、medium = 2、large = 4）【[2]】。
主要制限は 同時ジョブ数 1 と パブリック向けビルド分上限約 2,500 分／月 です【[3][4]】。
cache と workspace を適切に設定すれば、ビルド時間とクレジット使用量を大幅に削減できます。
store_test_results Orb によるテスト結果永続化は、再実行コストの低減と可視性向上を同時に実現します。
parallelism とワークフロー設計で「クレジットあたりの処理量」を最大化しつつ、Free プランの制限内で効率的な CI を構築できます。
ダッシュボード・API とアラートを活用してリアルタイムにモニタリングし、使用率が 80 % 前後になったら有料プラン（Performance）への移行や追加クレジット購入を検討しましょう。

参考文献

CircleCI Pricing – Credits & Limits, https://circleci.com/pricing/
CircleCI Docs – Credit Usage by Resource Class, https://circleci.com/docs/credits/#resource-class-credits
CircleCI Docs – Concurrency limits for Free plan, https://circleci.com/docs/concurrency/
CircleCI Docs – Build minutes for free tier (public repos), https://circleci.com/docs/build-minutes/
CircleCI Docs – Artifacts & Caching Limits, https://circleci.com/docs/artifacts/#storage-limits
CircleCI API v2 – Get user credits, https://circleci.com/api/v2/#operation/getUserCredits
CircleCI Performance Plan Overview, https://circleci.com/pricing/performance/