Claude Code をチームで使うには？ PR の自動レビューから、作業の分け方・設定の共有・月額コストまで

はじめに：「自分のPCで便利」を「チームで回る仕組み」にする

Claude Code（ターミナルで動く Anthropic 公式の AI コーディングツール）を1人で使い始めると、次は「チームでも使いたい」と考えるはずです。ところが、実際に広げようとすると、1人のときには気にならなかった困りごとが出てきます。

• AI のレビューは、誰かが頼んだときにしか動かない。忙しい日ほど飛ばされる
• 同じフォルダで複数の作業を頼むと、変更どうしがぶつかる
• ルールや許可の設定が人ごとに違うので、同じ依頼でも結果が変わる。危ないコマンドを個人の判断で許可してしまう人もいる
• 月にいくら使っているのか、誰も分からない

図1：この記事で扱う範囲。左の困りごとを、右の4つの仕組みで順に解決していきます

この記事では、4つの困りごとをそれぞれ仕組みで解決する方法を、実際に手を動かして確かめながら説明します。公式ドキュメントと GitHub のソースコードを確認したうえで、このMacと検証用に作った非公開の GitHub リポジトリで、次のことを試しました。

• 第1部：GitHub Actions に Claude Code を組み込み、PR（プルリクエスト）を出すたびに自動でレビューさせる。@claude で修正を頼む、Issue を仕分ける、週に1回点検させる
• 第2部：止まらず、暴れず、お金を使いすぎないための設定（バージョン固定・同時実行の制御・ターン上限）。検証中に見つけた「Claude の push がどう扱われるか」という落とし穴も紹介します
• 第3部：チーム開発の基本。作業を Worktree で分ける、CLAUDE.md を共有する、設定の「禁止」を個人の設定で覆せないようにする
• 第4部：費用の見える化。1回の依頼でどこにお金がかかっているかを実測し、10人チームの月額を試算します

想定読者は、Claude Code を一度は触ったことがあり、GitHub で PR を作ったことがある方です。YAML（GitHub Actions の設定ファイルの書き方）は、この記事のコードをコピーして読めば大丈夫です。チームリーダーやPMの方は、第2部の注意点と第4部の費用の部分だけ読んでも役に立つように書いています。

この記事の確認範囲 公式ドキュメントとソースコードの確認、検証はすべて2026年9月25日に行いました。Claude Code 2.1.280、claude-code-action v1.0.234 を使っています。GitHub Actions 上の Claude はサブスクリプション（Claude Max）の OAuth トークンで動かしました。そのため、記事に出てくる「$0.16」のような金額は、ツールが定価で計算したAPI 換算の目安です。実際の請求額ではありません。

検証した環境

項目	内容
PC	macOS（Apple Silicon）
Claude Code	2.1.280（Claude Max プラン）
GitHub	検証用に新しく作った非公開リポジトリ（Node.js 22 の小さなポイント計算ライブラリ）
claude-code-action	v1.0.234（コミット 9171db3e… に固定）
Actions 上のモデル	claude-sonnet-5（--model で指定）
認証	claude setup-token で作った OAuth トークンを Secrets に登録

---

第1部：GitHub Actions で Claude を「チームの一員」にする

1-1. 仕組み：PRを出すと、GitHubの中で Claude Code が動く

GitHub Actions は、GitHub が用意する「使い捨てのパソコン」で、決めた処理を自動で実行する仕組みです。PR が作られた、コメントが付いた、毎週月曜の朝になった、といった出来事（イベント）をきっかけに動きます。

このパソコンの上で Claude Code を動かすための公式の部品が claude-code-action（anthropics/claude-code-action）です。中身は Claude Code そのもので、Claude Agent SDK の上に作られています。

図2：PR 自動レビューの全体像。この記事の検証リポジトリも同じ構成です

図2のとおり、PR をきっかけに動くと、Claude は差分を読んで PR にコメントを書きます。ここで押さえておきたいのは、2種類の「鍵」が必要という点です。

鍵	役割	どこに置くか
Claude を動かす鍵	モデルを呼び出すための認証	リポジトリの Secrets（暗号化された保管庫）
GitHub に書き込む鍵	PR へのコメントや push をするための認証	Claude GitHub App が実行のたびに短命のトークンを発行

Claude を動かす鍵は2通りあります。

• API キー（ANTHROPIC_API_KEY）：Claude Console で発行する従量課金の鍵
• OAuth トークン（CLAUDE_CODE_OAUTH_TOKEN）：手元で claude setup-token を実行して作る、有効期間1年のトークン。Pro・Max・Team・Enterprise のサブスクリプションで使え、API の従量課金ではなくプランの利用枠を消費します

1つ注意があります。OAuth トークンは、作った人のサブスクリプションに紐づきます。そのため公式ドキュメントは、組織で複数のリポジトリに共有するなら、API キーか Workload Identity Federation（GitHub の一時的な身分証を Claude の認証に交換する方式で、長期の鍵を置かずに済む）を勧めています。個人やお試しなら OAuth トークン、チームの本番運用なら API キー、と考えるとよいでしょう。

GitHub に書き込む鍵は、Claude GitHub App（https://github.com/apps/claude ）をリポジトリに入れると使えるようになります。ワークフローの permissions に id-token: write を書くと、アクションが GitHub の一時的な身分証（OIDC トークン）を受け取ります。それを Anthropic のサーバーで App のトークンに交換して使う仕組みです。

公式の App は、Actions・Checks・Contents・Discussions・Issues・Pull requests・Workflows などの書き込み権限をまとめて求めます（GitHub の仕様で、一部だけを許可することはできません）。権限を最小限にしたい組織向けに、Contents・Issues・Pull requests だけを持つ自前の App を作る方法も公式に案内されています。

1-2. 2つのモード：「頼まれたら動く」か「決まった仕事を自動でやる」か

claude-code-action は、ワークフローに prompt（Claude への指示文）を書いたかどうかで動き方が変わります。

図3：2つのモードの分かれ方。PR の自動レビューには prompt が必須です

モード	始まるきっかけ	結果の出し方	向いている仕事
自動化モード（prompt あり）	PR作成、Issue作成、毎週の定時など	既定ではログだけ。コメントさせるなら投稿用のツールを許可する	自動レビュー、Issue の仕分け、定期点検
対話モード（prompt なし＋@claude）	コメントに @claude と書く	進捗コメントを更新しながら作業し、修正をブランチへ push	「この指摘を直して」「テストを足して」

初心者がつまずきやすいのは、自動化モードの結果は、何もしなければログに出るだけという点です。「動いたのにコメントが付かない」ときは、プロンプトで投稿を指示しているか、投稿に使うツール（gh pr comment など）を許可しているかを確認します。

もう1つ、ツールの許可にも違いがあります。対話モードでは、ファイルを読む・コメントを更新する・git でコミットして push する、といった道具を最初から使えます。一方、自動化モードでは、アクション側は何も許可を足しません。claude_args の --allowedTools で、使わせたいツールを自分で書く必要があります。

1-3. ハンズオン：PR の自動レビューを導入する

ここからは実際に手を動かします。題材は、会員ランクに応じてポイントを計算する小さな JavaScript のライブラリです。calcPoints(1000, "gold") のように呼ぶと30ポイントを返します。

STEP1：Claude GitHub App を入れ、トークンを Secrets に登録する

まず、ブラウザで https://github.com/apps/claude を開き、「Install」を押します。インストール先を聞かれたら「Only select repositories」を選び、対象のリポジトリだけにチェックを付けます。全リポジトリに入れる必要はありません。

次に、手元のターミナルで OAuth トークンを作ります。

# ブラウザで許可すると、ターミナルにトークンが表示される（どこにも保存されない）
claude setup-token

表示されたトークンをコピーし、GitHub CLI（gh）で Secrets に登録します。

# 実行すると貼り付けを求められる。トークンは画面にもファイルにも残らない
gh secret set CLAUDE_CODE_OAUTH_TOKEN -R <OWNER>/<REPO>

API キーを使う場合は、名前を ANTHROPIC_API_KEY にして同じように登録します。登録できたかは、リポジトリの Settings → Secrets and variables → Actions で確認できます。

Secrets に登録されたトークン。登録後は GitHub の画面でも値は見えません

なお、Claude Code の中で /install-github-app を実行すると、App のインストール、Secrets の登録、ワークフローファイルの PR 作成までを対話形式でまとめて進められます。ここでは、何が起きているかを理解するために手作業で進めました。

STEP2：ワークフローファイルを置く

リポジトリに .github/workflows/claude-review.yml を作ります。次のファイルは、この記事の検証で最終的に使った設定です（第2部で説明する安全策も入っています）。

name: Claude PR Review

on:
  pull_request:
    types: [opened, synchronize, ready_for_review, reopened]
    # ソースとテストが変わったときだけ動かす（README だけの変更では動かない）
    paths:
      - "src/**"
      - "test/**"
      - "package.json"

# 同じPRのレビューは1本だけ。新しいpushが来たら古いレビューは取り消す
concurrency:
  group: claude-review-${{ github.event.pull_request.number }}
  cancel-in-progress: true

jobs:
  review:
    # 下書きPR、Dependabot のPR（シークレットが渡らない）、Claude 自身の push は対象外
    if: >-
      github.event.pull_request.draft == false &&
      github.actor != 'dependabot[bot]' &&
      github.actor != 'claude[bot]'
    runs-on: ubuntu-latest
    timeout-minutes: 15
    permissions:
      contents: read
      pull-requests: write
      issues: read
      id-token: write # Claude GitHub App のトークンを受け取るのに必要
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          fetch-depth: 1

      - name: Claude Code でレビュー
        id: claude
        uses: anthropics/claude-code-action@9171db3e57d6a3140a37ddc2ba92788584e0ead6 # v1.0.234
        with:
          claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
          prompt: |
            REPO: ${{ github.repository }}
            PR NUMBER: ${{ github.event.pull_request.number }}

            このPRの変更をレビューしてください。見る観点は次の4つです。
            1. バグ（端数処理、境界値、例外の扱い）
            2. 既存の関数のふるまいが変わっていないか（互換性）
            3. テストが足りているか
            4. CLAUDE.md のコーディング規約に沿っているか

            問題の行が特定できるものは、その行へのインラインコメントにしてください。
            最後に全体のまとめを `gh pr comment` で1件だけ投稿してください。
            文章は日本語で、指摘には「重要度（高・中・低）」を付けてください。
          claude_args: |
            --model claude-sonnet-5
            --max-turns 20
            --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)"

      # 実行ログの全文にはツールの出力が含まれるので、数字だけ抜き出して残す
      - name: 実行結果の要約を作る
        if: always()
        run: |
          FILE="${{ steps.claude.outputs.execution_file }}"
          if [ -f "$FILE" ]; then
            jq '[.[] | select(.type == "result")] | last
                | {subtype, is_error, num_turns, duration_ms, total_cost_usd, modelUsage}' \
              "$FILE" > claude-run-summary.json
          else
            echo '{"note": "execution_file がありません"}' > claude-run-summary.json
          fi
          cat claude-run-summary.json

      - name: 要約をアーティファクトとして保存
        if: always()
        uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1
        with:
          name: claude-run-summary-${{ github.run_id }}
          path: claude-run-summary.json
          retention-days: 30

長く見えますが、大事なのは次の項目です。

項目	意味	この設定にした理由
on.pull_request.types	PR の作成・追加の push・下書き解除・再オープンで動く	レビューが要るタイミングだけに絞る
paths	指定したファイルが変わったときだけ動く	ドキュメントだけの変更で費用を使わない
concurrency	同じグループの実行は1本だけ	連続で push したとき、古いレビューを取り消す（第2部）
if	条件に合わないときはジョブを飛ばす	下書き・Dependabot・Claude 自身の push を除く（第2部）
timeout-minutes	この時間を超えたら強制終了	既定は360分（6時間）。暴走時の費用の上限になる
permissions	このジョブが GitHub に対してできること	コメントを書くだけなので、コードの書き込み（contents: write）は与えない
prompt	Claude への指示	あると自動化モードになる。チームのレビュー観点を書く
claude_args	Claude Code に渡す起動オプション	モデル、ターン上限、使ってよいツールを指定
@<長い英数字> # v1.0.234	バージョンをコミットの SHA で固定	勝手に中身が変わらないようにする（第2部）

claude_args の中身は、手元で claude コマンドに付けるオプションと同じです。以前は max_turns や model という専用の入力がありましたが、現行の v1 では廃止扱いになり、すべて claude_args に書く形になりました。

コーディング規約やアーキテクチャの方針は、プロンプトではなくリポジトリの CLAUDE.md に書いておくのがおすすめです。Claude Code は Actions の中でも CLAUDE.md を読み込みます。プロンプトには「今回特に見てほしい観点」だけを書く、という分担にすると、ワークフローを書き換えずにルールを育てられます。検証リポジトリの CLAUDE.md には、次のように書きました。

## コーディング規約
- Node.js 22 の標準機能だけを使う（外部パッケージを追加しない）
- 金額・ポイントは整数で扱い、端数は切り捨てる
- 公開する関数には JSDoc を書く
- テストは `node:test` で `test/` に置き、`npm test` で実行する

STEP3：わざと問題を入れた PR を出してみる

レビューが本当に役に立つかを確かめるため、あえて問題を5つ仕込んだ PR を作りました。「キャンペーン期間中はポイントを倍にする」という機能の追加です。

1. 未知のランクを渡すと NaN（数値ではない値）を返してしまう
2. 端数を Math.round（四捨五入）にしている。規約は切り捨て
3. 公開関数に JSDoc（関数の説明コメント）がない
4. ついでに、既存の gold ランクの還元率を3%から4%に変えている
5. テストが正常系の1件だけ

PR を作ると、Actions タブに「Claude PR Review」の実行が現れます。約2分後、PR には次のようなコメントが付きました。

claude[bot] が問題の行に直接コメントした様子。仕込んだ5つの問題はすべて指摘されました

最後に投稿されたまとめコメント。プロンプトで頼んだ4つの観点と重要度で整理されています

特に感心したのは、PR の説明文に「gold の還元率を見直しました」と書いてあったのに、それを「キャンペーン機能と無関係な既存仕様の変更が混ざっている」と指摘した点です。レビュアーが見落としがちな「ついでの変更」を拾ってくれるのは、チームにとって大きな助けになります。

STEP4：結果を確認する……のはずが、赤い×

コメントは全部付いたのに、Actions の実行結果を見ると赤い×（失敗）になっていました。

最初の設定（--max-turns 10）での実行結果。仕事は終わっているのに「失敗」扱いになりました

エラー文は「Claude は13ターンで成功を報告したが、設定した上限の10を超えている」という意味です。ターン（turn）とは、Claude がツールを1回使って結果を受け取る1往復のことです。インラインコメントを1件書くのにも1ターン使うので、5件の指摘とまとめを投稿すると、10ターンでは足りませんでした。

この検証では、同じことが3回起きました。

ワークフロー	上限	実際のターン数	仕事の結果	判定
PR レビュー	10	13	指摘6件を投稿	失敗
@claude で修正	15	18	修正を push、テスト12件成功	失敗
週次ヘルスチェック	12	15	Issue を作成	失敗
Issue 仕分け	8	9	途中で停止（Reached maximum number of turns）	失敗

上限を超えても、多くの場合は仕事を最後まで終えたあとで「失敗」と判定されます。ただし Issue 仕分けのように、上限に達した時点で本当に止まる場合もあります。どちらにしても、赤い×が続くと「本当に壊れているとき」に気づけなくなるので、上限は実測したターン数に余裕を持たせた値にしましょう。上限を20に上げたあとは、同じ種類のレビューが11ターン・約1分42秒で成功しました。

--max-turns はあくまで「想定外の長い作業」を止めるための目安です。費用の暴走を確実に止めるのは、ジョブ全体の timeout-minutes のほうだと考えてください。

画面の下にある Artifacts には、STEP2 の最後の2ステップで保存した要約（517バイト）が残っています。中身は、ターン数・所要時間・API 換算の費用だけです。この理由は第2部で説明します。

1-4. 応用：同じ仕組みで3つの仕事を任せる

自動レビューができたら、同じ部品で別の仕事も任せられます。検証では3つ試しました。

応用1：@claude で修正を頼む（対話モード）

prompt を書かないワークフローを別に用意すると、PR や Issue のコメントで @claude と呼びかけたときだけ動く「対話モード」になります。

name: Claude Mention

on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]

jobs:
  claude:
    # @claude を含むコメントのときだけランナーを起動する
    if: contains(github.event.comment.body, '@claude')
    runs-on: ubuntu-latest
    timeout-minutes: 20
    permissions:
      contents: write
      pull-requests: write
      issues: write
      id-token: write
      actions: read # CI の結果を Claude が読めるようにする
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          fetch-depth: 1

      - uses: anthropics/claude-code-action@9171db3e57d6a3140a37ddc2ba92788584e0ead6 # v1.0.234
        with:
          claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
          claude_args: |
            --model claude-sonnet-5
            --max-turns 30
            --allowedTools "Bash(npm test)"

if: contains(...) は、@claude を含まないコメントでランナー（実行用のパソコン）を起動しないための条件です。アクション自身もトリガーを確認しますが、ランナーの起動にも時間とお金がかかるので、入口で絞っておきます。

先ほどの PR に、次のようにコメントしました。

@claude レビューの指摘を直してください。
- calcCampaignPoints: 端数は切り捨て、未知のランク・不正な amount / multiplier は例外にする、JSDoc を付ける
- gold の還元率は 3 に戻す（今回のPRでは変えない）
- test/campaign.test.js に指摘された境界値のテストを足す
最後に npm test がすべて通ることを確認してください。

約1分半後（Claude の作業は約45秒）、Claude は指摘どおりに修正したコミットをブランチへ push しました。コメント欄の進捗リストもすべてチェック済みになり、「全12テストが成功」と報告しています。ただし、この push のあとに思わぬことが起きました。これは第2部の「Claude の push のゆくえ」で詳しく説明します。

Claude は PR を自分で作ったりマージしたりはしません。rebase や force push もしません。起動した場所以外のブランチにも push しません。これはアクションのシステムプロンプトで決められた動作で、最終判断は必ず人に残るようになっています。

応用2：Issue を自動で仕分ける（自動化モード）

新しい Issue が作られたら、種類と優先度のラベルを付け、関係しそうなファイルを伝えるワークフローです。

name: Claude Issue Triage

on:
  issues:
    types: [opened]

jobs:
  triage:
    runs-on: ubuntu-latest
    timeout-minutes: 10
    permissions:
      contents: read
      issues: write
      id-token: write
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          fetch-depth: 1

      - uses: anthropics/claude-code-action@9171db3e57d6a3140a37ddc2ba92788584e0ead6 # v1.0.234
        with:
          claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
          prompt: |
            REPO: ${{ github.repository }}
            ISSUE NUMBER: ${{ github.event.issue.number }}

            新しい Issue を仕分けしてください。本文は `gh issue view` で読んでください。
            1. 種類のラベルを1つ付ける: bug / enhancement / question
            2. 優先度のラベルを1つ付ける: priority:high / priority:medium / priority:low
            3. 関係しそうなファイルを調べ、見立てを3行以内のコメントで伝える
            ラベルは既存のものだけを使い、新しく作らないでください。
          claude_args: |
            --model claude-sonnet-5
            --max-turns 15
            --allowedTools "Read,Grep,Glob,Bash(gh issue view:*),Bash(gh label list:*),Bash(gh issue edit:*),Bash(gh issue comment:*)"

実はこの設定は2回目のものです。最初は Bash(gh label list:*) を許可リストに入れていませんでした。すると、実行結果は緑（成功）なのに、ラベルもコメントも付きませんでした。

原因を調べるため、実行結果から「権限で拒否された操作」を取り出すステップを足しました。

      - name: 権限で拒否された操作を表示
        if: always()
        run: |
          jq '[.[] | select(.type == "result")] | last
              | {num_turns, total_cost_usd, permission_denials: [.permission_denials[]?.tool_input.command]}' \
            "${{ steps.claude.outputs.execution_file }}"

※ このステップを使うには、アクションのステップに id: claude を付けておきます。

出てきた答えは、次のとおりです。

"permission_denials": [
  "gh label list --repo <OWNER>/<REPO>",
  "gh label list --repo <OWNER>/<REPO>",
  "gh label list --repo <OWNER>/<REPO>",
  "gh label list --repo <OWNER>/<REPO>",
  "gh api repos/<OWNER>/<REPO>/labels --jq '.[].name'"
]

プロンプトで「既存のラベルだけを使って」と頼んだので、Claude は律儀にラベルの一覧を確認しようとしました。しかし、そのためのコマンドを許可していなかったため、5回とも拒否されていたのです。プロンプトが要求する操作と、許可したツールの一覧がずれていると、黙って何もしない、というのは覚えておきたい落とし穴です。

gh label list を許可したあとは、「ポイントの有効期限を知りたい」という Issue に enhancement と priority:low が付き、関係するファイルを挙げた3行の見立てがコメントされました（7ターン・約26秒）。

Issue の自動仕分け。ラベル付けとコメントまで自動で行われました

応用3：毎週の健康診断（定期実行）

schedule イベントを使うと、決まった時刻に動かせます。workflow_dispatch も付けておくと、Actions の画面から手動でも実行できるので、試すときに便利です。

name: Claude Weekly Health Check

on:
  schedule:
    - cron: "0 0 * * 1" # 毎週月曜 0:00 UTC（日本時間 9:00）
  workflow_dispatch: # 手動でも実行できるようにする

jobs:
  health:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    permissions:
      contents: read
      issues: write
      id-token: write
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1

      - uses: anthropics/claude-code-action@9171db3e57d6a3140a37ddc2ba92788584e0ead6 # v1.0.234
        with:
          claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
          prompt: |
            REPO: ${{ github.repository }}

            リポジトリの健康診断をして、結果を Issue にまとめてください。
            - TODO / FIXME コメントの一覧
            - `npm test` の結果
            - JSDoc が無い公開関数
            - CLAUDE.md の規約から外れている箇所
            Issue のタイトルは「週次ヘルスチェック YYYY-MM-DD」（今日の日付）にしてください。
          claude_args: |
            --model claude-sonnet-5
            --max-turns 20 # 検証では 12 にして15ターンで上限超過したため引き上げた
            --allowedTools "Read,Grep,Glob,Bash(npm test),Bash(gh issue create:*)"

cron（定期実行の書式）の5つの欄は、左から「分・時・日・月・曜日」で、時刻は UTC（協定世界時）です。日本時間は UTC より9時間進んでいるので、0 0 * * 1 は月曜の朝9時になります。

手動で実行すると、約2分で「週次ヘルスチェック 2026-09-25」という Issue ができました。TODO はなし、テスト3件はすべて成功、JSDoc の漏れもなし、という報告に加えて、1つ本物の問題を見つけていました。ランク名に "toString" のような特別な名前を渡すと、「未知のランク」のチェックをすり抜けて NaN を返してしまう、という指摘です。人が普通に書くテストではまず思いつかない穴でした。

定期実行では、いくつか注意点があります。

• GitHub は、スケジュール実行を既定のブランチ（main など）のワークフローからだけ行う
• 公開リポジトリでは、60日間活動がないとスケジュールが無効になる
• prompt がふつうの文章の場合、--allowedTools で許可するまで、Claude はシェルも GitHub の API も使えない
• 実行回数が増えるほど費用も増える。重い点検は週1回程度にとどめるのが無難

コラム：GitHub Actions 以外の選択肢

方法	動く場所	共有	向いている用途
GitHub Actions ＋ claude-code-action	GitHub のランナー（自分たちの CI）	ワークフローとしてチームで共有	PR レビュー、Issue 対応、定期点検
Routines（/schedule）	Anthropic のクラウド	個人のアカウントに属し、共有されない	自分用の定期作業。PC を閉じていても動く
GitLab CI/CD	GitLab のランナー	パイプラインとして共有	GitLab を使うチーム

Routines は研究プレビュー（試験提供）の機能で、Pro・Max・Team・Enterprise で使えます。トリガーは「定期実行（最短1時間間隔）」「API」「GitHub の PR・Release イベント」の3種類です。ワークフローを書かずに始められる手軽さが魅力です。ただし、社内ネットワークに閉じた GitHub Enterprise Server などには、Anthropic のクラウドから届かない点に注意してください。

GitLab CI/CD 版もベータ版として公式ドキュメントがあり、メンテナンスは GitLab 側が担当しています。専用のアクションはなく、.gitlab-ci.yml のジョブで claude -p（ヘッドレスモード）を直接呼ぶ形です。@claude のメンションで動かすには、自前の Webhook の受け口が必要になります。

---

第2部：止まらない・暴れない・使いすぎないための設定

GitHub Actions に Claude Code を組み込むと、人がその場で確認しないまま、コメントやコミットが積み上がっていきます。第2部では、事故を防ぐための設定を、検証で実際に起きたことと合わせて説明します。

2-1. バージョンは SHA で固定し、Dependabot で追いかける

公式ドキュメントの例は、どれも anthropics/claude-code-action@v1 という書き方です。手軽ですが、v1 は「動く目印」です。アクションのリリース手順（release.yml）を確認すると、新しい版を出すたびに v1 の目印を強制的に付け替えていました。直近30日だけで28回もリリースがあり、同梱されている Claude Code のバージョンも毎回変わります。昨日動いたワークフローが、今日は違う動きをするかもしれないということです。

GitHub のセキュリティガイドは、「完全な長さのコミット SHA で固定するのが、アクションを変更不可能な形で使う唯一の方法」と説明しています。SHA は、Git がコミットごとに付ける40文字の識別子です。タグと違って、あとから付け替えられることはありません。

# おすすめ：コミットの SHA で固定し、行末にバージョンをコメントで残す
- uses: anthropics/claude-code-action@9171db3e57d6a3140a37ddc2ba92788584e0ead6 # v1.0.234

# 次善の策：特定のバージョンのタグ（タグは付け替え・削除できる）
- uses: anthropics/claude-code-action@v1.0.234

# お試し用：メジャーバージョンのタグ（中身が毎日のように変わる）
- uses: anthropics/claude-code-action@v1

SHA は次のコマンドで調べられます。claude-code-action のタグは注釈付きタグ（annotated tag）なので、git ls-remote の結果にはタグ自身の SHA と、コミットの SHA（^{} が付いた行）の2つが出ます。uses: に書くのはコミットの SHA です。

# 方法1：GitHub API でタグが指すコミットの SHA を取る
gh api repos/anthropics/claude-code-action/commits/v1.0.234 --jq .sha

# 方法2：git で調べる（^{} の付いた行がコミットの SHA）
git ls-remote --tags https://github.com/anthropics/claude-code-action "v1.0.234*"

固定したバージョンを手作業で追いかけるのは大変なので、GitHub 標準の依存関係更新ツール Dependabot に任せます。.github/dependabot.yml に次の設定を置くと、アクションの新しい版が出たときに uses: の行を書き換える PR を自動で作ってくれます。行末の # v1.0.234 というコメントも一緒に更新されます。

version: 2
updates:
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

検証では、Dependabot の動きを見るために、1つのワークフローだけわざと古い v1.0.230 に固定しておきました。すると、2つの意外な結果が出ました。

1つ目：最新の v1.0.234 ではなく、v1.0.231 への更新が提案された。 調べると、2026年7月14日から、Dependabot のバージョン更新には既定で3日間の待機期間（cooldown）が入るようになっていました。公開されたばかりの版は、3日たつまで提案されません。サプライチェーン攻撃（乗っ取られた依存関係に悪意のある版が紛れ込む攻撃）への対策です。待機期間は cooldown の設定で変えられます。

    cooldown:
      default-days: 3 # 1〜90日。exclude に書いた依存関係は待たずに更新される

2つ目：PR のタイトルは「1.0.230 から 1.0.231 へ」なのに、4つのファイルが変わっていた。

Dependabot の PR の差分。v1.0.234 だったファイルまで v1.0.231 に「下げる」内容になっていました

v1.0.230 だったファイルを上げるだけでなく、v1.0.234 にしていた残りの3ファイルまで v1.0.231 に下げる差分でした。同じアクションを複数のバージョンで固定していたため、Dependabot が1つにそろえようとし、待機期間の条件を満たす v1.0.231 に合わせたと考えられます。教訓は2つです。

• 同じアクションのバージョンは、すべてのワークフローでそろえておく
• Dependabot の PR も、タイトルだけで判断せず「Files changed」を確認してからマージする

2-2. 同じ PR のレビューは1本だけ：concurrency

同じ PR に続けて push すると、そのたびにレビューが起動します。放っておくと、同じ指摘が2回投稿され、費用も2倍になります。これを防ぐのが concurrency（同時実行の制御）です。

concurrency:
  group: claude-review-${{ github.event.pull_request.number }}
  cancel-in-progress: true

group に PR 番号を入れているので、同じ PR の実行は常に1本に制限されます。cancel-in-progress: true にすると、新しい実行が来たときに実行中の古い実行も取り消します。この設定がない場合、取り消されるのは「順番待ち」の実行だけです。

検証では、PR を作ってから26秒後にもう1回 push しました。

図4：concurrency の実測。新しい push が来ると、古いレビューは19秒後に取り消されました

Actions の一覧でも、1回目の実行は取り消し（灰色の丸）、2回目は最後まで実行されたことが確認できます。

検証中の実行一覧。取り消し・失敗・承認待ちなど、この記事で説明する状態がそろっています

なお、GitHub には queue という新しい設定も加わっています。順番待ちを最大100件まで並べる queue: max は、cancel-in-progress: true と同時には使えません（組み合わせるとエラーになります）。

2-3. 動かさなくてよいときは、そもそも起動しない

費用を抑えるいちばん確実な方法は、不要な実行を起こさないことです。今回の設定では、3つの絞り込みを入れています。

絞り込み	書き方	検証での結果
変わったファイル	paths: に src/** など	README だけを変えた PR では、レビューが1回も起動しなかった
PR の状態	if: github.event.pull_request.draft == false	下書き PR ではジョブを飛ばす
実行した人	if: github.actor != 'dependabot[bot]' など	Dependabot と Claude 自身の push を除く

Dependabot を除いているのには理由があります。GitHub は、フォーク（他人が複製したリポジトリ）からの PR と Dependabot の PR には、安全のため Secrets を渡しません。そのため Claude の認証ができず、必ず失敗するからです。同じ理由で、公開リポジトリでは、外部の人がフォークから出した PR には、この自動レビューは動きません。公式ドキュメントにも、同じリポジトリのブランチからの PR でしか動かないと書かれています。

pull_request_target というイベントを使えば、フォークからの PR でも Secrets を使えます。ただしこのイベントは、ベースリポジトリの権限で動きます。PR の中身（信頼できないコード）をそのまま取り込んで Claude を動かすのは危険なので、公式のセキュリティガイドをよく読んでから使ってください。

2-4. Claude の push のゆくえ：無限ループにはならないが、止まり方が2通りある

ここからは、今回の検証でいちばん時間をかけて調べたことです。

応用1で @claude に修正を頼むと、Claude はブランチに push しました。PR のブランチに push があると、自動レビューのワークフロー（synchronize）が起動するはずです。もしそこで Claude がまた何かを push すれば、延々と起動し合う「無限ループ」になりかねません。実際にはどうなったのでしょうか。

最初の結果は、レビューの実行が黄色の「Action required（承認待ち）」で止まる、というものでした。

Claude の push で起動したレビューが「承認待ち」になった画面。管理者が「Approve and run」を押すまで動きません

よく見ると、push した人が claude[bot] ではなく github-actions[bot] になっています。GitHub Actions が自動で発行する GITHUB_TOKEN で push された、ということです。GitHub の仕様では、GITHUB_TOKEN による push は原則として新しいワークフローを起動しません（これが GitHub 側の無限ループ対策です）。ただし、PR の作成や更新（opened・synchronize・reopened）だけは例外で、「承認待ち」の実行が作られます。

しかし、アクションは本来、Claude GitHub App のトークンで push するように作られています。なぜ GITHUB_TOKEN が使われたのか。原因を突き止めるため、checkout のバージョンだけを変えて @claude に4回依頼しました。

図5：checkout のバージョンによって、push の名義と、その後の止まり方が変わりました

checkout のバージョン	アクションのログ	push の名義	自動レビューはどうなったか
v7.0.1 / v6.1.0 / v6.0.2	No existing authentication headers to remove	github-actions[bot]	承認待ちで止まる
v5.0.0	✓ Removed existing authentication headers	claude[bot]	すぐ起動するが、アクションが拒否して失敗

原因は、2つのツールの「認証情報の置き方」の食い違いでした。

• actions/checkout は、コードを取ってくるときに使った GITHUB_TOKEN を、後続のステップでも使えるように git の設定に残します。v6.0.0 から、これを別ファイルに書く方式に変わりました。今回確認した v6.0.2・v6.1.0・v7.0.1 は、そのファイルを includeIf.gitdir:… という条件付きの読み込み設定でつないでいました（ログで確認）
• claude-code-action は、Claude が作業を始める前に、この残った認証を消してから App のトークンに差し替えます。しかしソースコード（git-config.ts）を読むと、消す対象はリポジトリの設定と、include.path で読み込まれるファイルだけでした。includeIf 形式は対象外なので「消すものはない」と判断され、GITHUB_TOKEN が残ったまま push されていました

認証を別ファイルに移す前の v5.0.0 では、アクションが認証を消せたので、push は claude[bot] 名義になりました。すると今度は、レビューのワークフローがすぐに起動します。ただし、アクションが次のエラーで止めました。

claude[bot] の push で起動したレビューは、アクションの「人間以外の起動を拒否する」チェックで止まりました

これが claude-code-action 側の無限ループ対策です。bot が起こしたイベントでは、allowed_bots に名前を書かない限り Claude を起動しません。週次ヘルスチェックで Claude が作った Issue に対しても、Issue 仕分けのワークフローが同じ理由で止まっていました。

まとめると、どちらの場合も無限ループにはなりません。 ただし、止まり方が「承認待ち」か「失敗」かで変わります。運用上のおすすめは次のとおりです。

1. レビューのワークフローでは、Claude 自身の push を if で除外する（STEP2 の設定）。赤い×や承認待ちが残らず、「スキップ」として静かに終わる
2. Claude の修正をもう一度 AI にレビューさせたいときは、人が中身を確認してから、Actions の画面で「Approve and run」を押すか、手動で再実行する。人の確認を1回はさむことになるので、安全面ではむしろ好ましい
3. checkout を古い版に戻すのは、おすすめしない。v7 系には pull_request_target での安全性の改善などが入っている

claude-code-action はほぼ毎日リリースされています。この挙動は近いうちに変わる可能性があるので、「2026年9月25日時点、v1.0.234 での観察」として読んでください。

2-5. ターン数・時間・費用の上限

1-3 の STEP4 で見たとおり、--max-turns は小さすぎると、仕事が終わっていても「失敗」になります。検証での実測をまとめると、次のようになりました（費用は API 換算の目安）。

仕事	ターン数	所要時間（Claude の部分）	API 換算の費用
PR レビュー（指摘6件）	13	約76秒	$0.16
PR レビュー（最終設定・指摘3件）	11	約102秒	$0.27
@claude で修正（12テスト）	18	約45秒	$0.26
@claude で README に追記（3回）	8〜10	約15〜24秒	$0.14〜0.16
Issue 仕分け（許可リスト修正後）	7	約26秒	$0.08
週次ヘルスチェック	15	約102秒	$0.24

上限を決めるときの目安は、次の3段構えです。

• --max-turns：実測の1.5〜2倍程度。インラインコメントを書かせるなら「指摘の件数＋準備の数ターン」を見込む
• timeout-minutes：ジョブ全体の上限。既定の360分はまず使わない長さなので、実測の数倍（今回は10〜20分）を指定する
• concurrency と paths：実行回数そのものを減らす

手元のヘッドレスモード（claude -p）には、--max-budget-usd という「1回あたりの支出の上限」を決めるフラグもあります。GitHub Actions でも claude_args に書けますが、今回は試していません。

2-6. ログと記録の残し方

アクションは、実行結果の全体を JSON ファイルとして出力します。そのパスは execution_file という出力で受け取れます。アクションのソースを読むと、このファイルには Claude Agent SDK の全メッセージがそのまま入っていました。つまり、Claude が読んだファイルの中身や、コマンドの出力も含まれます。

これをそのまま upload-artifact で保存すると、アーティファクトをダウンロードできる人に、作業中に表示された情報がすべて見えてしまいます。今回の設定では、jq で最後の result メッセージから、ターン数・時間・費用・モデル別の使用量だけを取り出して保存しました。検証では、この要約は517バイトでした。

同じ理由で、アクションの show_full_output: true（全出力をログに出す）も、公開リポジトリでは使わないでください。ログは誰でも読めるからです。なお、デバッグ用の ACTIONS_STEP_DEBUG を有効にすると、この設定も自動で有効になります。

アーティファクトとログの保存期間は、既定で90日です。プライベートリポジトリでは、リポジトリの設定で最大400日まで延ばせます。監査のために長期間残したい場合は、S3 などの外部ストレージに送ることも検討しましょう。

2-7. セキュリティで押さえておくこと

最後に、公式のセキュリティガイドから、特に大事な点をまとめます。

• Secrets にだけ鍵を置く。 API キーやトークンをワークフローファイルに直接書かない
• 権限は最小限に。 レビューだけなら contents: read で十分。コードを書き換えさせるワークフローとは分ける
• PR 側の設定ファイルは使われない。 PR で動くとき、アクションは .claude/・CLAUDE.md・.mcp.json などをベースブランチの内容に戻してから Claude を起動します。PR の作成者が CLAUDE.md を書き換えて、Claude への指示を仕込むことはできないようになっています
• プロンプトインジェクションに注意する。 Issue や PR の本文には、Claude への隠れた指示が仕込まれている可能性があります。アクションは HTML コメントや見えない文字を取り除きますが、完全ではありません。書き込み権限のない人からの起動（allowed_non_write_users）は、慎重に扱いましょう
• マージは人が行う。 Claude が作った変更は自動マージの対象から外し、ブランチ保護ルールで「レビュー承認1人以上」「CI の成功」を必須にする

---

第3部：チーム開発の基本

Actions で自動化を回し始めると、次は「人が手元で Claude Code を使う場面」のルールづくりが必要になります。ここでは、並行作業・ルールの共有・設定の3つを、手元で実際に試しながら説明します。

3-1. 並行作業が混ざる：Worktree で分ける

AI に作業を任せると、1人で複数の機能を同時に進めやすくなります。その反面、同じフォルダで2つの作業を頼むと、変更が混ざってしまいます。そこで役立つのが Git Worktree です。1つのリポジトリから作業用のフォルダを複数作り、それぞれを別のブランチに割り当てられます。

Claude Code では、-w（--worktree）オプションで起動すると、Worktree を自動で作ってその中で作業してくれます。

# .claude/worktrees/points-campaign/ に、ブランチ worktree-points-campaign ができる
claude -w points-campaign

ただし、初めて試したときは、いきなりエラーになりました。

まだ「信頼」していないフォルダでは Worktree を作れません

Claude Code は、初めて開くフォルダで「このフォルダを信頼しますか」と確認します。この確認に答えていないフォルダでは、Worktree を作れません。一度 claude を普通に起動して「Yes, I trust this folder」を選んでから、もう一度 -w を付けて起動すると成功します。

作った Worktree がどう片付けられるかも試しました。

図6：Worktree の終わり方は3通りあります

変更がないまま /exit で終了すると、確認なしで Worktree もブランチも削除されました。README を1行変えてから終了すると、次の確認が出ました。

変更があるときは、残すか消すかを選べます。消すと未コミットの変更は失われます

注意したいのは、ヘッドレスモード（claude -p）で作った場合です。

ヘッドレスで作った Worktree は locked（ロック付き）のまま残ります。下は手で片付けた様子

ヘッドレスモードには終了時の確認がないため、Claude は Worktree を片付けません。作成時のロックも残ります。CI や定期実行でヘッドレスモードを多用するチームでは、気づかないうちに Worktree がたまり、ディスクを圧迫します。今回は、ターミナルを強制終了した対話セッションの Worktree も、同じように locked で残りました。次の手順で片付けます。

# 残っている Worktree を確認する
git worktree list

# ロックを外してから削除する（未コミットの変更がある場合は remove に --force が必要）
git worktree unlock .claude/worktrees/nightly-check
git worktree remove .claude/worktrees/nightly-check

# 作られたブランチも消し、管理情報を整理する
git branch -D worktree-nightly-check
git worktree prune

チームで使うときは、次の2つをルールにしておくと混乱が減ります。

• 名前の付け方をそろえる。 「機能名」「Issue 番号」など、git worktree list を見ただけで誰が何をしているか分かる名前にする
• .claude/worktrees/ を .gitignore に入れる。 入れておかないと、git status に未追跡のフォルダとして表示され続ける（検証でも表示されました）

3-2. AI の挙動がばらつく：CLAUDE.md を共有する

同じ指示でもメンバーによって AI の出力が変わる大きな原因は、各自の CLAUDE.md（Claude Code が毎回読み込むルールのメモ）が違うことです。チームで守るルールは、プロジェクトの CLAUDE.md に集めます。

種類	場所	Git で管理するか	書く内容の例
組織のポリシー	macOS なら /Library/Application Support/ClaudeCode/CLAUDE.md	管理者が配布	全社のセキュリティ方針
プロジェクト	./CLAUDE.md または ./.claude/CLAUDE.md	する（チームで共有）	コーディング規約、アーキテクチャ、テストの方針
個人（このプロジェクトだけ）	./CLAUDE.local.md	しない（.gitignore に自分で追加）	自分用のメモ
個人（全プロジェクト）	~/.claude/CLAUDE.md	しない	出力の口調、使う言語などの好み

運用のポイントは3つです。

• プロジェクトの CLAUDE.md は PR で更新する。 変更はチーム全員の Claude Code の挙動に影響するので、コードと同じようにレビューする
• 「Claude が間違えたこと」を書き足していく。 「このルールを教えないと Claude が間違える」と気づいたら追記する。すると、新しく入ったメンバーも、CLAUDE.md を読むだけで「なぜこの書き方なのか」が分かるドキュメントになる
• 長くしすぎない。 公式は200行以内を目安にしています。長い手順は、スキル（必要なときだけ読み込まれる手順書）に分けます

第1部のとおり、この CLAUDE.md は GitHub Actions の中でもそのまま読まれます。手元の Claude と CI の Claude が、同じルールで動くようになるわけです。

3-3. 個人の設定ミスが事故になる：チームの「禁止」を共有する

Claude Code は、許可されたコマンドなら実行します。誰かが個人の設定で危ないコマンドを許可すると、それがそのまま事故につながります。そこで、チームで守るべき「禁止」は、プロジェクトの共有設定に書いておきます。

設定ファイルには階層があり、上のものほど優先されます。

優先度	種類	場所	Git で管理するか
1（最優先）	Managed（組織が配布）	managed-settings.json など	管理者が配布
2	起動時の指定	--allowedTools など	–
3	Local（自分だけ）	.claude/settings.local.json	しない
4	Project（チームで共有）	.claude/settings.json	する
5	User（自分の全プロジェクト）	~/.claude/settings.json	しない

ここで大事なのは、deny（禁止）だけは階層に関係なく、allow（許可）より先に評価されることです。公式ドキュメントには「どこかの階層で deny されたツールは、ほかのどの階層でも allow できない」と明記されています。

本当にそうなるのかを試しました。プロジェクトの共有設定で rm -rf を禁止し、個人の Local 設定と起動時のオプションの両方で許可します。

// .claude/settings.json（チームで共有）
{
  "permissions": {
    "allow": ["Bash(npm test)", "Bash(npm run *)"],
    "deny": ["Bash(rm -rf *)", "Bash(git push --force *)"]
  }
}

// .claude/settings.local.json（自分だけ）
{
  "permissions": {
    "allow": ["Bash(rm -rf *)"]
  }
}

この状態で、ヘッドレスモードからダミーのフォルダの削除を頼みました。

claude -p "rm -rf tmp-cache をそのまま実行して。失敗したら別の方法は試さず理由だけ報告して" \
  --permission-mode default \
  --allowedTools "Bash(rm -rf *)" \
  --output-format json | jq '{result, permission_denials}'

個人の設定と起動オプションで許可しても、チームの deny が勝ちました

図7：評価の順番は deny → ask → allow。最初に一致したものが勝ちます

対照実験として、プロジェクトの deny から rm -rf を外すと、同じ指示でフォルダは削除されました。つまり、止めていたのは確かにチームの deny です。

設定を書くときの注意点を3つ挙げます。

• allow・deny などの配列は、階層をまたいで合算される。 上書きではないので、プロジェクトの allow と自分の allow は両方有効になる
• deny は「うっかり」の防止と考える。 例えば Bash(git push *) を禁止しても、git -C . push のような別の書き方は防げないと公式に書かれている。本当に止めたいものは、ブランチ保護など GitHub 側の仕組みでも防ぐ
• .claude/settings.local.json は自分で .gitignore に入れる。 Claude Code が自分でこのファイルに書き込むときは、git のグローバルな除外設定に追加してくれる。一方、手で作った場合は何もしないので注意する

3-4. 開発が速くなりすぎる：AI が書いたコードのレビュー規約

AI でコードを書く量が増えると、開発の詰まりどころが「書くこと」から「レビューと統合」に移ります。PR が量産されて人のレビューが追いつかない、マージが頻繁になって手元の変更がすぐ古くなる、書かせた本人もコードを把握しきれない、といった状態です。

対策は、レビューと統合の速さを、書く速さに近づけることです。

• PR を小さく保ち、こまめにマージする
• レビューの一次チェックを AI に任せる（第1部の自動レビュー）
• ペアプログラミングやモブプログラミング（チーム全員で1つの画面を見ながら進める方法）で、指示を出す人と出力を確認する人を分ける

あわせて、「AI が書いたから」をレビューを省く理由にしないよう、チームで規約を決めておきましょう。

規約	具体的に
責任はコミットした人にある	AI が書いたコードでも、通常と同じくレビューする
AI が関わったことを記録する	Claude Code にコミットを頼むと、既定で Co-Authored-By: Claude … が付き、GitHub の共同作成者として表示される
AI 特有の観点で見る	過剰な共通化、実在しないライブラリ、意味のないテスト（常に成功するだけ）、ハードコードされた鍵や緩すぎる権限

コミットや PR に付く AI の記載は、設定の attribution.commit と attribution.pr で変えられます。空文字にすると付かなくなります。古い includeCoAuthoredBy という設定は v2.0.62 から非推奨になっているので、新しく設定するなら attribution を使ってください。

3-5. 新メンバーの受け入れと、作業の引き継ぎ

チームに Claude Code が根付くと、新しく入った人の立ち上げにも使えます。リポジトリの構造を知りたいときは、次のように質問するのが手軽です。

このリポジトリのアーキテクチャを説明して。主なディレクトリとそれぞれの役割を教えて
新しい API エンドポイントを足すなら、どのファイルを直す必要がある？ 既存のパターンに沿って教えて

CLAUDE.md とリポジトリの構造を読んで答えてくれるので、ドキュメントの不足を補う「生きたドキュメント」になります。

確認作業そのものを、ヘッドレスモードで決まった手順にしておくこともできます。検証リポジトリで、次のチェックを試しました。

claude -p "このリポジトリに新しく参加したメンバー向けに、次を確認して結果を箇条書きで報告して。
1. node と npm のバージョン 2. npm test が通るか 3. 主なディレクトリとファイルの役割
4. CLAUDE.md の規約の要点（3行）。ファイルは変更しないで" \
  --allowedTools "Bash(npm test)" "Bash(node -v)" "Bash(npm -v)"

約22秒で、Node.js のバージョン、テスト3件の成功、ワークフロー4本を含むファイルの役割、規約の要点が報告されました。ところが、npm のバージョンだけは「承認待ちで止まったので確認できていない」という答えでした。

結果の JSON を見ると、拒否されたのは npm --version でした。許可したのは npm -v です。意味は同じでも、Claude がどちらの書き方を選ぶかは分かりません。許可リストは、実際に使われたコマンドを見て調整するのが確実です。この場合は、Bash(npm --version) も足すか、Bash(npm *) のように少し広めに許可します（広げすぎには注意）。

担当者が変わるときの引き継ぎには、2つの方法を使い分けます。

• 今回の作業を引き継ぐ：Claude Code に「ここまでの調査結果と現状を、次に引き継ぐ人向けに Markdown でまとめて」と頼み、Issue や PR、チャットに貼る。受け取った人は、それを新しいセッションの最初に貼れば、前提を共有した状態で続きから始められる。途中のスクリーンショットや、実行したコマンド・エラーも添えると確実
• これからの全員に引き継ぐ：特定の作業ではなく、プロジェクト全体で役立つ知見（避けたい実装、ドメイン特有のルールなど）は、CLAUDE.md や .claude/rules/ に書き足す。個人の頭の中にあった暗黙知が、チーム全員の Claude Code が参照するルールに変わる

---

第4部：コストを見える化し、予算を決める

4-1. 料金のしくみ：定額プランと従量課金

Claude Code を使う方法は、大きく2つあります。サブスクリプションのプランで定額で使うか、API を直接呼び出して使った分だけ払うかです。2026年9月25日時点の公式の料金は次のとおりです。

プラン	月額（年払い）	月額（月払い）	想定規模・特徴
Pro	$17	$20	個人
Max	$100〜	月払いのみ	Pro の5倍または20倍の利用量
Team Standard	$20／席	$25／席	2〜150人のチーム
Team Premium	$100／席	$125／席	Standard の5倍の利用量
Enterprise	$20／席＋API 料金の利用分	–	大規模。管理者が利用上限や監査ログを設定できる

API の料金は、100万トークン（MTok）あたりの単価で決まります。トークンは、AI が文章を扱うときの単位（単語や文字のかたまり）です。

モデル	入力	出力	キャッシュ読み込み	備考
Fable 5.1	$10	$50	$0.25（入力の2.5%）	最上位
Opus 5.5	$4	$20	$0.20（入力の5%）	2026年9月22日公開。Opus 5（$5／$25）より安い
Sonnet 5	$2	$10	$0.20（入力の10%）	当初の導入価格がそのまま正式価格になった
Haiku 4.5	$1	$5	$0.10（入力の10%）	軽い処理向け

見積もりのときに押さえておきたい仕様が、いくつかあります。

• キャッシュ：同じ前置き（システムプロンプトや会話の履歴）を再利用すると、2回目からは安い「キャッシュ読み込み」の単価になる。代わりに、最初の書き込みは入力の1.25倍（5分キャッシュ）または2倍（1時間キャッシュ）かかる。サブスクリプションでは1時間キャッシュ、API キーでは既定で5分キャッシュが使われる
• バッチ API：急がない処理をまとめて送ると、入出力とも50%引き
• 新しいトークナイザー：Claude 4.7 以降のモデルは、同じ文章でも約30%多くのトークンに数える（トークンの区切り方が変わったため）。古いモデルの実績から見積もるときは注意する

4-2. effort で考える深さを調整する

effort は、Claude Code がどれだけ深く考えるか（思考に使うトークンの量）を決める設定です。下げるとトークンが減って速くなりますが、推論は浅くなります。

レベル	使いどころ
low	範囲がはっきりした小さな作業。速さを優先したいとき
medium	日常の作業。費用も気にしたいとき
high	考える力が必要な作業の基本
xhigh	難しい設計判断や、自律的に長く進める作業
max	限界まで考えさせたい作業。そのセッション限り

既定値はほとんどのモデルで high ですが、Opus 5.5 は medium、Opus 4.7 は xhigh です。対応するレベルはモデルによって異なり、Haiku 4.5 は effort に対応していません。

設定方法は4つあり、上のものほど優先されます。

# 1. 環境変数（そのシェルで起動する Claude Code すべてに効く）
export CLAUDE_CODE_EFFORT_LEVEL=medium

# 2. 起動時のオプション
claude --effort high

# 3. 対話中のコマンド（/effort と打つとスライダーが出る）
/effort

4つ目は設定ファイルの effortLevel です。ただし注意点があります。v2.1.251 以降、/effort の選択はモデルごとに modelSettings へ保存されるようになりました。また、ユーザー設定（~/.claude/settings.json）のトップレベルに書いた effortLevel は、Opus 5.5 以降のモデルには効きません。プロジェクト設定に書いた場合は、すべてのモデルに効きます。チームで基準をそろえるなら、プロジェクトの .claude/settings.json に書くのが確実です。

チームでの運用は、「日常の作業は medium か high、重い設計判断や複雑なバグ調査のときだけ xhigh や max」とメリハリをつけるのがおすすめです。なお、公式はレベルごとの消費量の倍率を示していません。「low は high の何分の1」とは言えないので、相対的な目安として使ってください。

4-3. 実測：1回の依頼で、どこにお金がかかっているか

「1回の依頼でどれくらいトークンを使うのか」を、手元で実際に測りました。同じ練習用リポジトリで、3種類の依頼を、3つの設定で1回ずつ claude -p --output-format json で実行しています。

• 質問に答える（「端数はどう扱っている？」）
• 小さな機能追加（新しいランクを1つ足してテストも足す）
• 中くらいの機能追加（クーポン機能を新しく作り、境界値のテストと README の例を書く）

図8：1回の依頼の費用の内訳。どの回も、最初のキャッシュ書き込みがいちばん大きな割合を占めました

依頼	設定	時間	ターン	キャッシュ書き込み	キャッシュ読み込み	出力	目安費用
質問	Sonnet 5 low	13秒	5	1.8万	11.9万	569	$0.10
質問	Sonnet 5 high	12秒	4	1.6万	9.2万	492	$0.09
質問	Opus 5.5 medium	17秒	4	1.8万	9.3万	520	$0.17
小さな機能	Sonnet 5 low	17秒	8	1.7万	12.2万	1,109	$0.10
小さな機能	Sonnet 5 high	17秒	9	1.7万	12.2万	1,261	$0.11
小さな機能	Opus 5.5 medium	23秒	9	1.8万	15.6万	1,480	$0.21
中くらいの機能	Sonnet 5 low	34秒	7	1.9万	12.6万	4,057	$0.14
中くらいの機能	Sonnet 5 high	33秒	6	1.9万	9.7万	3,451	$0.13
中くらいの機能	Opus 5.5 medium	36秒	6	1.9万	9.9万	3,295	$0.24

9回とも、依頼どおりに作業が終わり、テストも通りました。数字から分かることは3つあります。

1. 入力トークンのほとんどは「キャッシュ」だった。 キャッシュを使わない入力は、どの回も8〜12トークンだけでした。残りはキャッシュの書き込みと読み込みで、読み込みが約86%、書き込みが約14%です。Claude Code は、毎ターン会話の全体（読んだファイルやコマンドの出力を含む）を送り直します。その大部分がキャッシュから読まれている、ということです。

2. どんなに小さな依頼でも、最初に1.6万〜1.9万トークンの書き込みがある。 システムプロンプト、ツールの定義、CLAUDE.md などの「前置き」です。サブスクリプションは1時間キャッシュなので、書き込みは入力単価の2倍になります。質問1つでも $0.09〜0.17 相当かかるのは、このためです。短い依頼を別々のセッションで何度も送るより、関連する作業は同じセッションでまとめたほうが効率的です。

3. この規模では、low と high の差はほとんど出なかった。 各1回の計測なので誤差の範囲です。effort の差は、もっと考える余地のある難しい作業で効いてくるはずです。

自分の環境でも、/usage（別名 /cost）で同じ内訳を確認できます。

/usage の画面。モデルごとのトークン数とキャッシュの効き具合が分かります

/usage に表示される金額は、トークン数に定価を掛けてローカルで計算した推計です。Pro や Max のサブスクリプションでは、利用枠の中で使っている限り、この金額が請求されるわけではありません。正式な請求額は、API なら Claude Console の Usage ページで確認します。

セッションを長く続けると、会話が膨らんで、後半のターンほど1回に送るトークンが増えます。区切りのよいところで /compact（会話の要約）をかけるか、/clear で新しく始め直すと、費用の効率がよくなります。なお、/compact そのものも大きなリクエストになります。一方、/clear は費用がかかりません。

4-4. 10人チームの月額を試算する

公式ドキュメントによると、エンタープライズ導入での平均は「開発者1人あたり、稼働日1日約$13、月$150〜250。90%のユーザーは稼働日1日$30未満」です。これを手がかりに、10人チームの月額を試算してみます。

前提は次のとおりです。

• 10人全員が、1日5セッション、月20日使う
• 1セッションあたり、入力（キャッシュを含む）60万トークン、出力6万トークン
• 1人あたり月に、入力6,000万トークン、出力600万トークン。チーム全体では入力6億、出力6,000万トークン

この前提で、「キャッシュの当たりは50%（当たった分は入力の10%の単価、外れた分は定価）」という保守的な仮定を置き、Sonnet 5 の単価で計算します。

入力：6億トークン × $2/MTok × (0.5 + 0.5 × 0.1) = $660
出力：6,000万トークン × $10/MTok = $600
合計：約 $1,260／月（1人あたり $126）

同じ計算を、1世代前の Sonnet 4.6（$3／$15）で行うと約$1,890になります。Sonnet 5 は値下げされたので、同じ使い方でも約3分の2で済む計算です。

一方、4-3 の実測では、入力の約86%がキャッシュ読み込みでした。API キーで使う場合（5分キャッシュ、書き込みは入力の1.25倍）に、この比率を当てはめると次のようになります。

入力：6億 × ($0.2 × 0.87 + $2.5 × 0.13)/MTok ≒ $299
出力：前提どおり 6,000万トークンなら $600、実測の比率（入力の約1.5%）なら $90
合計：約 $390〜900／月

図9：同じ使い方でも、モデルと前提の置き方で2倍以上変わります

選択肢	月額（10人）	評価
Team Standard	$200〜250	お試しに向く。本格的に使うと利用上限に当たりやすい
Team Premium	$1,000〜1,250	API 換算より割安になりやすい。上限に収まるかは実測で確認
Enterprise	$200＋利用分	大規模な運用や、監査などの管理が必要な組織向け
API（Sonnet 5）	約$390〜1,260	プランの縛りがない。キャッシュの効き方で大きく変わる
API（Opus 5.5）	約$670〜2,460	重い判断が多いチーム向け。Sonnet 5 のほぼ2倍

この試算で一番伝えたいのは、前提次第で金額が2倍以上変わるということです。実測は、小さなリポジトリでの短い依頼で取ったものです。大きなコードベースで長いセッションを続けると、1ターンで送る量も、休憩のあとのキャッシュの外れも増えます。導入するときは、次の順番で進めましょう。

1. 数人のパイロットチームで1〜2週間使い、/usage や Console で実際の消費を測る
2. 1人あたりの実測値から月額を計算し、プランと API を比べる
3. 月次の予算と、利用上限（spend limit）を決める

4-5. 見える化と継続的な監視

予算は、決めて終わりではありません。実際の数字を見ながら、継続的に監視する仕組みが必要です。使い方の形態によって、見る場所と上限の掛け方が違います。

使い方	支出を見る場所	上限の掛け方
Team／Enterprise プラン	管理画面の分析と spend report（日次更新・CSV 出力）	組織・グループ・個人ごとの spend limit
Claude Console（API）	Console の Usage ページ	ワークスペースの月次上限と、しきい値のアラート
Bedrock／Google Cloud など	各クラウドの請求画面	各クラウドの予算アラート

Console では、自動で作られる「Claude Code」ワークスペースに、ユーザーごとの月次上限も設定できます。Bedrock を使う場合は、AWS Cost Explorer で他の AWS サービスとまとめて管理できます。

どの形態でも使えるのが、OpenTelemetry（利用データを外部の監視ツールに送る標準の仕組み）です。環境変数 CLAUDE_CODE_ENABLE_TELEMETRY=1 などを設定すると、ユーザー別・モデル別のトークン数や費用を、ほぼリアルタイムで社内の監視基盤に送れます。OTEL_RESOURCE_ATTRIBUTES に部署名やコストセンターを入れておけば、チームごとの集計も簡単です。管理者は、管理用の設定（managed settings）で全員に配布できます。

チーム運用のベストプラクティスをまとめると、次のとおりです。

• 月次の予算を決め、80%に達した時点でアラートを出す
• メンバーごとの利用量を定期的に見直し、偏りがある場合は個別に上限を設定する
• CI での利用はトリガーを絞り、不要な実行を減らす（第2部）
• 大きなリファクタリングなど、トークンを多く使う作業は事前にチームで共有する

---

トラブルシューティング

GitHub Actions の Claude が思いどおりに動かないときは、次の順番で確認します。どれも、この検証で実際に出たメッセージです。

図10：Actions タブで実行を開き、失敗したステップのログから原因を見分けます

症状・メッセージ	原因	対処
実行が一覧に出てこない	paths や if の条件に合わない、ワークフローが既定のブランチにない	条件を見直す。ワークフローを追加する PR 自体では、Claude が動かないことがある（マージ後に動く）
awaiting approval from a maintainer	GITHUB_TOKEN 名義の push で起動した	中身を確認して「Approve and run」。レビュー側で Claude の push を除外する
…successful result after 13 turns, exceeding the configured maximum of 10	--max-turns が小さい	実測のターン数に合わせて上げる
Reached maximum number of turns (8)	上限に達して本当に止まった	上限を上げる。プロンプトを具体的にする
Workflow initiated by non-human actor: claude (type: Bot)	bot が起こしたイベントで起動した	対象外にするなら if で除外、許すなら allowed_bots
Command failed: git fetch origin --depth=20 …	非公開リポジトリで checkout の persist-credentials: false にした	既定（true）のままにする
成功なのにコメントもラベルも付かない	必要なコマンドを許可していない（permission_denials_count が0より大きい）	execution_file の permission_denials を見て --allowedTools に足す
自動化モードでコメントが付かない	結果はログに出るだけ	プロンプトで投稿を指示し、gh pr comment などを許可する
@claude に反応しない	App が入っていない、@claude の前後に文字がある、コメントした人に書き込み権限がない	App とワークフローを確認。@claude-bot や /claude では起動しない
id-token: write を足したかというエラー	OIDC トークンを取れない	permissions に id-token: write を書く
Claude の修正コミットで CI が動かない	github_token: ${{ secrets.GITHUB_TOKEN }} を渡している	渡さずに App で認証させる。ただし 2-4 の checkout の件にも注意

後片付け

検証に使ったものを片付ける手順です。

# 検証用リポジトリの Secrets を消す（リポジトリごと消すなら不要）
gh secret delete CLAUDE_CODE_OAUTH_TOKEN -R <OWNER>/<REPO>

# 手元に残った Worktree を確認して消す
git worktree list
git worktree prune

claude setup-token で作ったトークンは、有効期間が1年あります。使わなくなったら Secrets から削除し、リポジトリの Settings → Integrations → GitHub Apps から、Claude GitHub App の対象リポジトリも外しておきましょう。

まとめ

この記事では、Claude Code を「ひとりの手元」から「チームの仕組み」に広げる方法を、実機で確かめながら見てきました。

• GitHub Actions で自動レビューが作れる。 わざと入れた5つの問題はすべて指摘された。ただし --max-turns 10 では足りず、「仕事は終わっているのに失敗」になった。上限は実測に合わせる
• プロンプトと許可リストはセットで考える。 「既存のラベルだけ使って」と頼んだのに gh label list を許可していなかったため、成功扱いのまま何もしなかった
• バージョンは SHA で固定し、Dependabot の PR は差分まで見る。 既定の3日の待機期間と、複数のバージョンを混ぜていたことが重なり、バージョンを下げる PR が来た
• Claude の push は無限ループにならないが、止まり方が2通りある。 2026年9月時点の checkout v6 以降では「承認待ち」、v5.0.0 では「bot の起動を拒否」。レビュー側で Claude の push を除外しておくのが扱いやすい
• チームのルールは共有の場所に書く。 Worktree で作業を分け、CLAUDE.md は PR で育て、危ない操作はプロジェクトの deny で禁止する。deny は個人の設定でも起動オプションでも覆せなかった
• 費用は実測してから決める。 1回の依頼の費用の大半は、最初のキャッシュ書き込みだった。10人の月額は、前提の置き方で約$390から$1,260（Sonnet 5）まで変わる

次のステップとしては、自分たちのリポジトリで1〜2週間、自動レビューを動かしてみることをおすすめします。/usage とアーティファクトの要約で実際の数字を集めれば、どのプランが合うか、どこまで自動化するかを、根拠を持って決められるはずです。

参考リソース

• Claude Code GitHub Actions｜Claude Code Docs
• anthropics/claude-code-action｜GitHub
• Authentication（claude setup-token）｜Claude Code Docs
• Routines｜Claude Code Docs
• GitLab CI/CD｜Claude Code Docs
• Manage costs effectively｜Claude Code Docs
• Model configuration（effort）｜Claude Code Docs
• Settings｜Claude Code Docs
• Permissions｜Claude Code Docs
• Memory（CLAUDE.md）｜Claude Code Docs
• Worktrees｜Claude Code Docs
• Monitoring usage（OpenTelemetry）｜Claude Code Docs
• Pricing｜Claude API Docs
• Plans & Pricing｜Claude
• Security hardening for GitHub Actions｜GitHub Docs
• Control the concurrency of workflows and jobs｜GitHub Docs
• Triggering a workflow from a workflow｜GitHub Docs
• Keeping your actions up to date with Dependabot｜GitHub Docs
• Dependabot options reference（cooldown）｜GitHub Docs