創刊準備号 · 2026年秋English · RSS
AgentKoji

Claude Code×CIの費用と罠

Claude Code GitHub Actionsの費用はAPIと実行時間の2本立て。試算とキャッシュの罠、暴走の止め方をまとめた。

Claude Code を GitHub Actions で動かすと、費用は2か所から出ていきます。Claude の API（またはサブスク）と、GitHub Actions の実行時間です。この記事では、公式の単価で試算したうえで、運用して分かった罠と、止まらないジョブの防ぎ方をまとめます。プランの選び方は「Claude Codeの料金、実際いくら？」に書いたので、ここでは CI で回すときの費用だけを扱います。

費用は2本立て

公式ドキュメントは、1回の実行が2種類の資源を使うと書いています（出典：https://code.claude.com/docs/en/github-actions 、2026-10-16確認）。

GitHub Actions の単価と無料枠は次のとおりです（出典：https://docs.github.com/en/billing/concepts/product-billing/github-actions 、2026-10-16確認）。

項目公式の表示
public リポジトリの標準ランナー無料
self-hosted ランナーActions の課金なし
private の無料枠（月）Free 2,000分、Pro 3,000分、Team 3,000分
超過分 Linux 2コア$0.006／分
超過分 macOS$0.062／分

試算してみる

単価だけでは見えないので、仮の数字で試算しました。実行回数・分数・トークン数は仮定で、実測ではありません。 API の単価は Sonnet 5.5 の入力 $2／MTok、出力 $10／MTok を使いました（出典：https://platform.claude.com/docs/en/about-claude/pricing 、2026-10-16確認）。

RUNS = 100                       # 月の実行回数（仮定）
MIN_PER_RUN = 6                  # 1回の分数（仮定）
IN_TOK, OUT_TOK = 300_000, 20_000  # 1回のトークン（仮定、キャッシュは考えない）
API: $80.00/月  (1回 $0.80)
Linux 2-core: 600分 × $0.006 = $3.60/月
macOS: 600分 × $0.062 = $37.20/月

この仮定では、費用の大半は API 側 です。Linux なら、600分は private の無料枠（Free で2,000分）の中に収まります。一方で macOS のランナーは、分単価が Linux の約10倍です。macOS が要らないジョブを macOS で走らせると、同じ分数でも費用は約10倍になります。

API 側を抑える手として、公式は次を挙げています（出典：https://code.claude.com/docs/en/github-actions 、2026-10-16確認）。

止まらないジョブを、設定で止める

上の公式の推奨を、ワークフローに入れた例です。鍵は Secrets から参照し、ファイルには書きません。ここでの secret 名はダミーです。

on:
  issue_comment:
    types: [created]
concurrency:
  group: claude-${{ github.event.issue.number }}
  cancel-in-progress: false
jobs:
  claude:
    if: contains(github.event.comment.body, '@claude')
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v6
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.DUMMY_ANTHROPIC_API_KEY }}
          claude_args: --max-turns 10

この YAML は、actionlint 1.7.12 でエラーなしでした（2026-10-16）。試しに timeout-minutes を文字列にすると、expecting a single ${{...}} expression or float number literal で弾かれます。push する前に actionlint にかけると、こうした書き損じで CI が空振りするのを防げます。

timeout-minutes を付けておけば、エージェントが止まらなくなっても、Actions の時間は上限で切れます。API 側は --max-turns で抑えます。

鍵の扱いは、公式も「API キーや OAuth トークンをリポジトリに直接コミットしない。必ず GitHub Secrets に置く」と書いています（同出典）。ログや子プロセスからの漏れ方は「Claude Codeに秘密を渡さない」に書きました。

self-hosted ランナーで踏んだこと

Actions の枠を節約するために、常駐のマシンを self-hosted ランナーにしたことがあります。ここで3つ踏みました。

1. キャッシュが損になる：永続する self-hosted ランナーでは、actions のキャッシュの仕組みが純粋な損でした。パッケージマネージャーのストアがランナーのホームに残っているので、何もしない素の install が最速でした。GitHub ホストのランナー向けの定石を、そのまま持ち込まないことです。

2. ジョブをまとめたら半分以下に：ジョブを細かく分けすぎて、ランナーの同時実行数を超えていました。ワークスペース単位にまとめて、同時実行数以下に収めたら、全体の待ち時間が21〜25分から10分56秒になりました。

3. 共有マシンの鍵を上書きされた：デプロイ用の鍵を書き込むワークフローが、マシンにあった本物の鍵を上書きしました。古い秘密鍵は戻せませんでした。共有のマシンに CI を載せる前に、ワークフローがホームの下に何を書くかを読みます。

なお、public リポジトリには self-hosted ランナーを使っていません。GitHub の公式ドキュメントも、誰でも pull request を開けるので環境を乗っ取られうるとして、public リポジトリではほぼ使うべきでないと書いています（出典：https://docs.github.com/en/actions/reference/security/secure-use 、2026-10-16確認）。常駐マシンそのものの監視と安全設計は「AIエージェントをVPSで24時間動かす」に書きました。

CI が緑でも安心しない

エージェントに CI を通させると、「緑になったこと」がゴールになりがちです。テストが何も検査していなくても、CI は緑になります。その見抜き方は「緑のテストは何も証明しない」に書きました。

逆に、手元では通るのに CI だけ落ちるときの探し方は「ローカルは通るのにCIで落ちる」にまとめました。

まとめ