[Claude Code]Max の API クレジットでコードレビュー

2026年10月14日

Claude Code
Codex

ぬにょす(挨拶)。

個人開発のアプリを、Claude Code のセッションに作らせています。

[Claude Code / Herdr] 4プロジェクト＋秘書＋作業用、6ペインの実態 | amiiby1つのリポジトリの中の並列ではなく、プロジェクトごとに立てた Claude Code のセッションを同時並行で相手にし、プロジェクトをまたぐ用事は常駐の秘書セッションに任せる話。作業環境の図と、秘書の使い方つき。amiiby.com

書かせるのは簡単です。困るのはその後で、動作確認などしてみると、こっちはいいけどあっちはおかしい、みたいな。確かに依頼・注文・指摘したところはそうなってるが、それだと前後の文脈がおかしいよね？とか。まぁ、蓋を開けてみたらおいおいオイオイ…と思うような残念な結果になっていることがしばしば起きるのです。

そこで、実装したセッションとは別のプロセスでレビューを行い、指摘が出なくなるまで自分たちで回してもらっているのですが、レビューを回すほど、週ごとの枠は減っていきます。そこで、Max プランに付くようになった API のクレジットを有効活用しよう、というのが今回のお話のメインです。

基本的な流れ

1. セッションが実装して、コミットする

これは、いつもどおりです。

2. 別プロセスの Claude で `/code-review`

レビューは、実装したセッションにはやらせません。実装したときの思い込みを、そのまま引き継ぐからです。

何も知らない Claude を別に起こして、そちらで /code-review を流します。

claude -p "/code-review main...HEAD" \
  --model sonnet \
  --permission-mode dontAsk \
  --allowedTools Read Grep Glob "Bash(git diff:*)" "Bash(git log:*)" "Bash(git show:*)"

使える道具は、読むものと読み取りの git だけに絞っています。レビューに書き込みは要らないので。

3. 指摘を確かめて、直す

レビューの指摘には、外れが混じります。「それは起きない」「わざとそうしている」みたいなやつ。

なので、指摘は1件ずつコードで確かめてから、直すかを決めさせています。直さないと決めたものは、理由を添えて次の回の依頼に書き足します。書かないと、同じ指摘が毎回戻ってくるので。

直したら、もう一度見せます。指摘が出なくなるまで、2 と 3 の繰り返しです。

4. Codex でも、レビューと修正を繰り返す

こちらも別に起こして、読み取り専用で差分を見せます。モデルが違うと、引っかかる所も違います。

codex exec -s read-only \
  -c model_reasoning_effort=medium \
  -o result.md - < prompt.md

prompt.md は依頼文、result.md はレビューの結果です。model_reasoning_effort は low だと見落としが多かったので、medium にしています。

レビューは数分で返ってくるので、その間セッションは待つだけです。終わったら知らせが届きます。

5. 両方が「指摘なし」と言ったら、マージする

push して PR を作り、CI が通ればマージします。

マージの前に、私に確かめには来ません。来るのは、画面を見てほしいときと、決めてほしいことがあるときだけです。

週次枠を無駄なく使う

Claude にも Codex にも週ごとの枠があって、レビューを回すたびに減ります。レビューで使い切ると、肝心の実装が止まります。そこで、できるだけ無駄なく、かといって使い切らないような工夫をしています。

まず、`/code-review` を API のクレジットで流す

Max プランには、毎月 API のクレジットが付くようになりました。週の枠とは別の財布なので、こちらで流せば、レビューをいくら回しても実装に使う枠が減りません。

クレジットは、Console の組織をプランにつなぐと毎月入ります（公式の説明）。Max 5x なら月 $100 分で、繰り越しはできません。

claude -p に --bare を付けて API のキー（sk-ant-...）を渡すと、サブスクでなくクレジットから引かれます。

ANTHROPIC_API_KEY="sk-ant-..." claude --bare -p "/code-review main...HEAD" \
  --model sonnet \
  --permission-mode dontAsk \
  --allowedTools Read Grep Glob "Bash(git diff:*)" "Bash(git log:*)" "Bash(git show:*)"

--bare だと CLAUDE.md を読まないので、リポジトリの決まりは依頼文の中で読ませています。

ただし、公式の説明では、このクレジットの対象に Claude Code は入っていません。claude -p にキーを渡す形は Agent SDK の扱いになるようで、2026年10月13日の時点ではクレジットから引かれています。いつまで通るかは分かりません。

Sonnet で1回あたり 10 セント前後と安価なので、同じ差分を2つ同時に見させて、それぞれの結果を統合しています。

クレジットが残っているうちは、上の流れのとおり /code-review が先です。

クレジットが切れたら、余裕がある方を優先

クレジットを使い切ったら、/code-review はサブエージェントに任せて、週の枠で流すことになります。こうなると、2つ同時には流しません。

先に見せた側が指摘の大半を拾い、やり取りの往復もそちらに積もります。なので、上の流れの 2 と 4 の順は、状況次第で変わります。セッションがレビューに入るたびに Claude と Codex の週次枠使用率を測って、余っている側が先。

余っているかどうかは、以下のように判断しています。

着地見込み = 今の使用率 × 168h ÷ 週の頭からの経過時間
100% を超えるなら、使いすぎ
着地見込みが低い側が、余っている側

Claude の数字はステータスラインに出ている値から、Codex の数字は codex app-server に問い合わせて取ります。道具は yorozuya の weekly-pace に置いてあります。

どうやって守らせているか

指示ファイルに書いてあるのは、これだけです。

AGENTS.md

- main へ入れるときは、`ship-to-main` skill の流れ（コミット → コードの変更は二重のレビュー → push と PR → CI → main の取り込み → スカッシュマージ → 片付け）に従う。マージの前にユーザーに確かめない。

CLAUDE.md

- main に入れるコードの変更は、マージの前に `/code-review` と Codex の二重のレビューを通す。進め方と依頼文に入れる観点は `dual-review` skill に従う。
- `/code-review` は実装したセッション自身にやらせず、API で流す別のプロセスか、サブエージェントに任せる。Codex へは `codex-review` skill で投げる。

指示ファイルは入口だけで、手順はスキルに置いています。流れ全体の ship-to-main、レビューの回し方の dual-review、Codex への投げ方の codex-review の3つ。上のコマンドも、スキルの中に書いてあります。

スキルには、手順のほかに「やらないこと」と「終わる条件」を書いています。dual-review だとこんな感じ。

dual-review/SKILL.md

## やらないこと

- 実装したセッション自身が `/code-review` を流す — 同じ文脈のままだと、実装時の前提と盲点をそのまま引き継ぐ。
- 指摘を確かめずに直す — 指摘ごとにコード・一次資料・実例で確かめてから、直すかを決める。
- レビューの間に push する・PR を作る。

## 終わる条件

`/code-review` と Codex の両方が、最後の差分に指摘なしを返した。

効果

実際のところ、この二重のレビューでコードの品質がどれだけ向上しているかは不明です。なぜなら、私はコードを一切見ていないから。

私が見ているのは Claude がターミナルに出力する「指摘がありました」「直しました」「再レビューの結果を待っています」「指摘がなくなりました」などの状況報告だけ。

しかし、この方式にしてから、いわゆる「明らかなバグ」や「仕様・設計の矛盾」みたいなものは減った感じはしています。成果物の確認をしていて「お前はバカか！」と言いたくなる瞬間はかなり減りました。いや、言いたくなるだけで言いませんよ？

記事の一覧へ