helper division
手伝いを並列に出すとき、任せる作業と任せない作業をどこで分けたか
Claude Codeで数十のサイトを運用していると、同じ形の作業が大量に出ます。落とす、数える、切る、置き換える、ビルドを確かめる。これを全部、判断の重いモデルに任せると、週の使用量が先に尽きます。この面は、2026年10月27日と11月2日に運営者が出した2つの方針と、それを手順に落とした記録です。複数のAIをどう配分するかの全体像は別の面に任せ、ここでは「手伝いを出す側が、何を渡し何を渡さないか」だけを書きます。
このサイトはAnthropicの公式サイトではありません。Claude Codeの機能・料金・提供範囲は変わる可能性があるため、重要な判断の前には公式のドキュメントと自分のアカウント設定を確認してください。
先に結論：線は「手順が決まっているか」で引く
任せる範囲の線は、作業の難しさではなく手順が先に書けるかどうかで引きました。手順が書ける作業は軽いモデル（Sonnet）に、手順を作ること自体が仕事になる作業だけを既定のモデルに残します。
| 作業の種類 | 渡す先 | 理由 |
|---|---|---|
| 動画の切り出し、ダウンロード、grepで数える、決まった置き換え、ビルドの確かめ、FTPの照合 | 軽いモデル（Sonnet） | 手順が決まっていて、結果が数や一致で確かめられる |
| 医薬品や法律にかかわる事実の確かめ | 既定のモデル | 誤りの代償が大きく、出典の読み分けが要る |
| SEOの原因の切り分け | 既定のモデル | 複数の仮説を立てて潰す判断が仕事そのもの |
| 網全体の決まりにかかわる直し | 既定のモデル | 1か所の判断が数十サイトに広がる |
もう1つの線は作る側と検品する側です。2026年11月2日に運営者が決めたのは、軽いモデルでちゃんと作れるなら軽いモデルで作り、上のモデルが「できているか」を調べ、だめなら直させてから上げる、という流れでした。作るのは安く、確かめるのは上で、という分担です。
手伝いを出す前に確かめる5つの手順
- 手順を3行で書けるか試す。書けないなら、まだ手伝いに出せる状態ではありません。判断を自分で済ませてから、決まった部分だけを切り出します。
- 結果を数や一致で言える形にする。「良くなったか」ではなく、「件数が何件から何件になったか」「本番と手元でバイト数が一致したか」で返してもらいます。
- 画像を見る回数を減らす。画像を見て判断する作業は重くなります。明るさや件数のような数値で判断させ、画像は最後の1回に絞ります。
- 報告は短くと頼む。長い報告は、受け取る側の読む量も使用量も増やします。「できた数、できなかった数、できなかった理由」の3点だけを返してもらいます。
- 受け取ったら、そのまま上げずに検品する。この検品のやり方は手伝いの「全部直しました」を鵜呑みにしない手順に分けて書きました。
手順の3つ目は、使ってみて効いた点です。画像の評価は人間にも揺れがあり、モデルに任せるとさらに揺れます。数値に置き換えると、同じ作業を何度流しても同じ結果が返ります。
実際にこの線を引いた経緯
きっかけは使用量でした。運営者が2026年10月27日に伝えたのは、使用量の軽い手伝い（Sonnet）に頼んだところ「これはいい、積極的に使ってほしい」という趣旨のことです。この日は週の使用量が84%まで進んでおり、運営者は使用量を使いすぎないよう言っていました。手伝いに出す作業の多くは、もともと決まった手順で足りるもので、重いモデルは要りませんでした。
指示を出す側にも理由があります。このサイトの運用では、横断の判断に使うべき容量を実装で消費すると、判断の質が落ちると整理しています。実績として、2026年8月4日に28サイトの展開を1つのセッションで抱え込み、1日で使用量を使い切りました。それ以降は、指示文を出す側と、実装する担当を分ける運用にしています。
この分担で大事なのは、手伝いを増やすほど出す側の検品の負担が増えることです。並列に10本出せば、報告も10本返ります。そのため、軽い手伝いには「短く返す」「数で返す」を必ず付けます。複数のAIの使用量をどう時間配分するかは複数のAIで運用するときの配分の記録に書いています。
任せなかったほうがよかった場面の見分け方
軽いモデルに出して後悔しやすいのは、次の3つの形です。
- 事実の確かめが混ざっている。「決まった置き換え」に見えても、置き換え先の文が事実として正しいかを判断する必要があるなら、それは判断の重い作業です。
- 範囲が曖昧。「全サイト」「全ページ」と書くと、手伝いは手元で見える範囲に狭めがちです。範囲は出す側が一覧で渡します。
- やり直しが効かない。本番に書き込む作業は、軽くても重くても失敗の代償は同じです。軽いモデルに出すのは、書き込む前までの準備と、書き込み後の照合までにします。
依頼文に必ず入れる4行
手伝いに出す依頼文は、長くするほど読み違いが増えます。次の4行だけは毎回入れました。
- 対象の一覧：「全部」ではなく、ファイル名やURLの一覧を渡す。範囲を決めるのは出す側の仕事です。
- やってよいこと、いけないこと：本番への書き込みを含むかを明記する。含まないなら「手元の確認まで」と書く。
- 返す形：できた数、できなかった数、できなかった理由の3点。長文の説明は要りません。
- 止まる条件：想定外の状態に当たったら、続けずに報告して止まる。
止まる条件は、軽いモデルほど効きます。想定外に当たると、手伝いは善意で先へ進み、後から取り消しにくい変更を残すことがあるからです。
よくある質問
手伝いは軽いモデルだけにすれば使用量は最小になりますか。
最小にはなりますが、検品が薄くなると、やり直しで結局増えます。作るのは軽いモデル、検品は上のモデル、という二段にしたのは、安さと確かさの両方を取るためでした。
どの作業を「判断が重い」と見なすか、迷ったらどうしますか。
手順を3行で書けるかで決めます。書けないものは判断が仕事なので既定のモデルに残し、書けた部分だけを軽いモデルに切り出します。
手伝いの報告が長くなって困るときは。
依頼の段階で「できた数、できなかった数、理由」の3点だけ短く返すよう書きます。長い報告を後から削るより、最初から短く頼むほうが読む側の負担も使用量も小さくなります。