Claude Codeの実務での使い方｜並列は速くならない、「エラー0」は平気で嘘をつく

Claude Codeを本格的に回し始めると、最初にやりたくなるのが並列化です。サブエージェント（別枠で動く子AI）を大量に立てれば、その分だけ速くなるはずだ、と。

実際に試した結論から書きます。速くなりませんでした。 そして、それより厄介だったのは**「検証は全部グリーンです」という報告が嘘だった**ことです。

この記事は運営者が実際に測った数字と、そこから固定した運用だけをまとめたものです。仕様は変わるので、機能の細部は公式で確認してください。

結論

① 並列サブエージェントは速くない（実測）

まずコストの話です。並列を増やすと、単純に上限に当たります。

• 2026年6月9日〜20日の間に、利用量の上限（セッション制限）に6回以上到達
• 単一のやり取りで 55万〜58万トークン（キャッシュ読み込み分）まで膨らんだ記録あり
• 上限が近づくとツールの出力が壊れ、コミットが失敗する

そして見落としやすいのがこれです。

ブラウザ操作を伴う作業では、もっとはっきりした数字が出ました。

並列化は逆効果で、単独エージェントの連続バッチが最速という結論になりました。並列で増えるのは処理量ではなく、同じ相手に対する叩き込みの密度だったわけです。

現在固定している運用は3つです。

1. サブエージェントは 4体以下のバッチで回す
2. 上限が近いときは、親が 1ツールずつ淡々と処理する
3. 「コミットしました」と報告されたら git log で実体を確認する

3番目が重要です。上限付近ではツールの出力そのものが壊れるので、コミットは失敗しているのに報告文だけは成立するという状態が起きます。報告を信じず、状態を見る。

コミットしたら、続けて `git log --oneline -3` を実行して
出力をそのまま貼ってください。
貼っていない状態で「完了」と言わないでください。

② 「エラー0」が嘘だった：検証スクリプト自体にバグがあった

このサイトには、記事内のCTA（読者を次の記事へ送るボックス）の中身が、飛び先の記事とちゃんと噛み合っているかを機械的に検査するスクリプトがあります。

長らく 「エラー0件」 を返し続けていました。安心していました。

原因を調べたら、こうでした。

CTAは HTML の <a href="..."> で書かれていたのに、検証スクリプトはマークダウン形式のリンク [...](...) しか見ていなかった。

つまり検査対象が0件だったわけです。0件を検査して0件のエラーを報告していたので、出力は完璧なグリーンでした。

対策は難しくありませんでした。検証スクリプトを信じる前に、一度わざと壊して落ちることを確認するだけです。

この検証スクリプトが本当に機能しているか確かめたい。

1. 検査対象を何件拾っているかを出力に加えてください
2. わざと違反するデータを1件仕込んで、スクリプトが失敗することを確認してください
3. 確認できたら仕込んだデータを戻してください

1番目だけでも効果があります。 「検査0件・エラー0件」と表示されていれば、誰でもおかしいと気づけます。現在は検査系のスクリプトに、必ず検査した件数を出させるようにしました。

なお現在のリンク検査スクリプトは、両方の書き方を拾うようになっています。

// マークダウン形式と HTML(CTAボックス)の両方を拾う
for (const re of [/\]\(\/posts\/([a-z0-9-]+)\)/g, /href="\/posts\/([a-z0-9-]+)"/g]) {
  for (const m of body.matchAll(re)) out.push(m[1]);
}

同じ落とし穴は見た目の確認にもありました。「デザインは問題ありません」で通していた配色を実際に計算したら、14ペア中2件がコントラスト比の基準未達（3.48:1 と 3.96:1）でした。目視は判定になりません → AIの成果物は目視でなく実測で検証する

同じ性質の落とし穴は計測にもありました。「イベントが発火したこと」は見ているのに「サーバーに届いたこと」を見ていないというものです（詳細はClaude Codeとは何かに書きました）。確認しているつもりで、確認しやすいほうだけを見ている——これがいちばん多い失敗でした。

③ 承認は「後戻りコストが高い4地点」だけに置く

自律で回させると決めた以上、毎回確認していては意味がありません。かといって全部任せると、戻せない操作まで実行されます。

このサイトの運用では、人間が承認するのを4地点だけに絞りました。

制作フェーズにはゲートを置いていません。 執筆・検査・修正は完全に自律で回ります。ここに承認を挟むと、確認が儀式になって中身を読まなくなるからです。

もう一つ効いたのが、権限の与え方を「承認権」と「拒否権」で分けたことです。

さらに、自動化に移行する条件まで先に決めておくのがおすすめです。曖昧なままだと、いつまでも人が全件見ることになります。

検査を通過し、かつ過去20本で差し戻しが0件のライターは
自動公開を許可する

数字で書いてあるので、条件を満たしたかどうかを人が判断しなくて済みます。「そろそろ任せていいかな」という気分の判断を、記録が肩代わりしてくれます。

④ 主観レビューを、スラッシュコマンドで機械的なゲートにする

「これ読みやすい？」のような主観的なレビューは、頼むたびに基準がブレます。これはスラッシュコマンド（/コマンド名 で呼べる定型指示）として固定することで、かなり安定しました。

実際に使っているファイルの構造がこれです。

---
description: 機能が広告で説明しやすいか検証する
allowed-tools: Read
---

対象の説明文を読み、以下の観点で1つずつ ⭕️ / ⚠️ / ❌ を付けて評価してください。

1. 一文で言い切れるか
2. competitorとの違いが名詞で言えるか
3. 効果が数字で書けるか
...

最後に ⚠️ と ❌ の合計数を数えてください。
合計が3つ以上の場合は「ピボットを検討してください」と明示的に警告してください。

型のポイントは3つです。

allowed-tools の指定が地味に効きます。「レビューして」と頼むと、指摘しながら直し始めてしまうことがあるためです。読み取り以外を渡さなければ、構造的に起きません。

3番目は、判断の主導権を自分に戻す仕掛けです。AIに「どうしますか？」と聞かせるのではなく、「◯個以上ならこう言え」と決めておくと、閾値を見直すときに自分の基準を疑えるようになります。

そのまま使えるプロンプト

日常的に使い回しているものを、そのまま載せます。

触る前に：現状把握

まだ変更しないでください。

このフォルダで <やりたいこと> に関係するファイルを探して読み、
・関係するファイルとその役割
・処理の流れ
・変更すると影響が出そうな箇所
の3点を箇条書きでまとめてください。

推測で補った箇所には「推測」と明記してください。

最後の一文は、別の記事に書いた誤診の反省から追加したものです。観測と推測を混ぜて書かれると、憶測が事実として次の作業の前提になります。

検証つきで実装させる

先ほどの計画のとおり実装してください。

完了の条件は次の2つです。
1. `<検証コマンド>` が成功すること
2. 実行結果をそのまま貼ること

途中で計画と違うことをする必要が出たら、
勝手に進めず、先に理由を説明してください。

「完了の定義」を先に渡すと、報告の質が変わります。

不具合を直させる

<症状> という不具合が出ています。

1. まず、この症状を再現する失敗するテストを書いてください
2. そのテストが実際に失敗することを確認してください
3. 原因を特定して直してください（症状を隠す対処はしないこと）
4. テストが通ることを確認して、結果を貼ってください

2番目を省くと、②で書いた「何も見ていないテスト」ができあがります。失敗することを確認していないテストは、通っても意味がありません。

広い調査は別枠に投げる

サブエージェントを使って調査してください。

プロジェクト内で <対象> を扱っている箇所をすべて探し、
「どのファイルで、何をしているか」の一覧だけ返してください。
ファイルの中身は貼らなくて結構です。

最後の一文が効きます。返すものを絞ることで、本体の会話に流れ込む情報量を抑えられます。ただし①のとおり、投げる数は4体以下にしてください。

まとめて作業させたあとのセルフレビュー

今回の変更内容を、書いた本人ではないつもりで見直してください。

見るのは「正しさ」と「要件を満たしているか」だけです。
好みのリファクタリングや、頼んでいない機能追加は提案しないでください。

指摘は「該当箇所・何が問題か・どう直すか」の形式でお願いします。

最後の一文（余計な提案の禁止）を入れないと、直さなくていい箇所まで書き換え案が出てきます。

会話が重くなったときの仕切り直し

長く続けた会話は、途中の試行錯誤が積み上がって指示が通りにくくなります。行き詰まったら、新しい会話で前提を書き直して始めるほうが速いです。

具体的には、こうしています。

1. いまの状況と、次にやってほしいことを自分の言葉で書き直す（AIに要約させない。誤診が混ざったまま引き継がれるため）
2. そのあとに /clear を入れて会話をリセットする
3. 書き直した前提を貼って、そこから再開する

順序が逆になりがちですが、書き直しが先です。 先に /clear すると、手元に何も残りません。

なお、この「前提を書き直す」作業を毎回やることになるなら、それはプロジェクトの指示ファイルに書くべき内容かもしれません → CLAUDE.mdの書き方（ただし、あのファイル自体が劣化するので、書きっぱなしにはしないでください）

やりがちな失敗

まとめ

Claude Codeで結果が変わったのは、新しい機能を覚えたからではなく、「速そうに見えるやり方」と「実際に速いやり方」が違うと分かったからでした。

1. 並列は逆効果になりうる。 4体以下のバッチ、ブラウザ操作は単独
2. グリーンを信じない。 検査件数を出させ、一度わざと落とす
3. 承認は4地点だけ。 品質担当には承認権ではなく拒否権を持たせる
4. 主観レビューはスラッシュコマンドで固定する。 読み取り専用・数え上げ・閾値で警告

うまくいかないときは、たいてい指示が抽象的です。基本的な直し方はAIへの指示（プロンプト）の書き方にまとめています。

Claude Code自体の位置づけと実際に起きた事故はClaude Codeとは何か、チャット型AIでの業務効率化はChatGPTで在宅ワークを効率化する使い方をどうぞ。