Claude Codeに今日どこまで任せる？承認ラインを4段階で決めるワークシート

金曜の夕方、僕はステージング環境に小さな修正を入れるだけのつもりでした。

「ドキュメントの誤字を直して、ついでにビルドが通るか見ておいて」とだけ頼んだら、Claude Codeは誤字を直したあと、勝手に依存パッケージを2つ更新して、.env.production の参照まで書き換えていました。ローカルのビルドは通っていたので、本人（AI）は「完了しました」と涼しい顔です。

僕がヒヤッとしたのは、差分を最後まで見るまでそれに気づかなかったことです。AIが悪いというより、「どこまでやっていいか」を僕が一度も言葉にしていなかったのが原因でした。

逆に、別の日には「許可しますか？ Yes/No」が30回くらい連続で出て、コミットを1つ作るだけで握力を使い果たしたこともあります。広げすぎると事故り、絞りすぎると進まない。この記事は、その間でちょうどいい線を引くための一枚のワークシートの話です。

この記事の要点

• Claude Codeに任せる作業を「読むだけ」「直すだけ」「公開する」「秘密情報を触る」の4段階に分ける。
• 段階ごとに「誰が最後にOKを出すか」と「何を見れば安全と言えるか（証拠）」を先に決めておく。
• 段階0と1はAIに任せ、段階2は人が確認、段階3は担当者だけが手を動かす。
• 朝に「今日はここまで」と一文で宣言してから作業を始めると、承認の数が一気に減る。
• コピペで使える台帳コードと、毎朝1分で決めるテンプレートを用意した。

なぜ「承認の予算」を先に決めるのか

承認で消耗する原因は、Claude Codeの性能ではありません。今日どこまで許すかを決めずに走り出していることです。

決めていないと、人は2つのうちどちらかに転びます。面倒だからと全部に「許可」を押し続けて、ある日まずい操作まで通してしまう。あるいは慎重になりすぎて、誤字修正にまで確認を挟み、仕事が進まなくなる。どちらも、判断を「その場の気分」に任せているのが共通点です。

そこで使うのが「承認の予算」という考え方です。お金の予算と同じで、今日はこのレーンまで自由、その先は人が判断と先に枠を決めておく。枠があると、AIの返事を見て毎回ドキドキする必要がなくなります。見るべきは「AIが賢いかどうか」ではなく「どのレーンで止まったか」になります。

判断の基準を言葉にしておくと、チームでも揉めません。「なんとなく不安だから止めた」ではなく「これは段階2だから人が確認する番」と言えるからです。権限設計の考え方そのものは Claude Code 入門ガイド でも触れていますが、ここではもっと泥臭く「今日の線引き」に絞ります。

任せる作業を4段階に分ける

まず、Claude Codeにやらせたい作業を、危なさの順に4つの段階へ仕分けします。難しく考えず、「やり直せるか」「公開されるか」「お金や秘密に触るか」だけで分けます。

段階	作業の例	最後にOKを出す人	安全と言える証拠
0	ファイルを読む、構成を把握する	AIに任せる	読んだ範囲の一覧
1	やり直せる1ファイルを直す	AI（人が差分を見る）	差分とビルド結果
2	公開サイトに反映する	人が判断	公開URLと巻き戻し手順
3	秘密情報・課金・顧客データを触る	担当者だけ	文書での承認

この表の肝は、右の2列です。「誰がOKを出すか」と「何を見れば安全と言えるか」を、作業を始める前に決めておく。後から決めると、AIが「完了しました」と言った勢いに流されて、確認を飛ばしてしまうからです。

段階1の「やり直せる」がポイントです。誤字修正やコメント追加は、間違えてもすぐ戻せます。だからAIに任せて、人は差分をさっと見るだけでいい。一方、依存パッケージの更新は段階2に上げます。一見小さくても、影響範囲が読めないからです。冒頭の僕の事故は、まさにこれを段階1扱いにしていたのが原因でした。

AIに任せる範囲と、人が判断する範囲

線引きをもう少しはっきりさせます。AIに任せていいのは、間違えてもすぐ気づけて、すぐ戻せる作業です。人が判断すべきなのは、一度実行すると外に影響が出る作業です。

• AIに任せる: 読む、調べる、下書きを作る、やり直せる1ファイルを直す、テストを走らせる
• 人が最後に判断する: 公開する、本番のデータを変える、外部サービスへ登録する、依存を更新する、削除する

迷ったら段階を1つ上げる。これだけ覚えておけば、大きく外しません。安全だと確信できた操作だけ、後から1段階ずつ下げて自動化していく。最初から全自動を目指さないのがコツです。この「段階的に格上げ」の考え方は、プロジェクトのルールを書く CLAUDE.md の書き方 とも相性がいいので、決めた線引きはファイルに残しておくと再現できます。

コピペで使える承認台帳

言葉だけだと、つい忘れます。そこで、4段階を機械が読める形にして、「今日はどこまで」をフィルタで出せるようにします。Node.jsがあればそのまま動きます。

// 承認台帳: 作業ごとに「危なさの段階」「担当」「証拠」を持たせる
const approvalBudget = [
  { action: "ファイルを読む",            level: 0, owner: "AI",          proof: "読んだ範囲の一覧" },
  { action: "やり直せる1ファイルを直す",  level: 1, owner: "AI（人が確認）", proof: "差分とビルド結果" },
  { action: "公開サイトに反映する",      level: 2, owner: "人",          proof: "公開URLと巻き戻し手順" },
  { action: "秘密情報や課金を触る",      level: 3, owner: "担当者のみ",    proof: "文書での承認" },
];

// 今日の上限。0なら読むだけ、1ならやり直せる修正までAIに任せる
const todayMax = Number(process.env.APPROVAL_MAX ?? 1);

const allowedToday = approvalBudget.filter((item) => item.level <= todayMax);
const needsHuman   = approvalBudget.filter((item) => item.level > todayMax);

console.log(`今日AIに任せる上限: 段階${todayMax}`);
console.table(allowedToday);
console.log("人が判断する作業:");
console.table(needsHuman);

実行はこれだけです。環境変数で「今日の上限」を切り替えられます。

# 今日は「やり直せる修正」まで任せる
APPROVAL_MAX=1 node approval-budget.mjs

# 今日は読むだけにしておく
APPROVAL_MAX=0 node approval-budget.mjs

項目名はそのままに、action と proof の中身を自分のプロジェクトに合わせて書き換えてください。Claude Codeにこのコードを渡して「うちのリポジトリ向けに値を埋めて」と頼むと、たたき台がすぐできます。

毎朝1分で決めるプロンプト雛形

台帳ができたら、作業を始める前にAIへ「今日の枠」を伝えます。次の文をコピーして、空欄を埋めるだけです。

今日の作業の枠を先に決めます。

- 今日の目的: （例: ブログ記事1本の誤字とリンク切れを直す）
- 読んでよい範囲: site/src/content/blog/ のみ
- 直してよい範囲: 上記の中の1ファイルだけ（やり直せる変更に限る）
- 実行してよいコマンド: npm run lint、テストの実行
- 触らないもの: .env、本番デプロイ、依存パッケージの更新、削除

ルール:
- 段階2以上（公開・本番データ・依存更新・削除）は、必ず僕に確認してから止まること。
- 直したら、変更の差分とビルド結果を「証拠」として最後にまとめて見せること。
- 「完了しました」だけで終わらせず、どのコマンドで確認したかを書くこと。

この一文があるだけで、AIは「とりあえず全部やる」をやめて、枠の中で動くようになります。慣れてきたら、この内容を CLAUDE.md の書き方 に沿ってプロジェクトのルールファイルに移すと、毎朝貼り付ける手間も消えます。

こんな現場で効く（3つ）

1. ブログや資料の量産チェック 「記事を直して」だけだと、AIは本文も画像パスもリンクもまとめて書き換えてしまいます。承認台帳で「本文の誤字は段階1、公開反映は段階2」と分けておくと、文章は任せつつ、公開ボタンは自分の手元に残せます。差分とビルド結果を証拠に出させれば、夜中の見直しがぐっと楽になります。

2. 問い合わせの仕分け 来た問い合わせを読んで分類するのは段階0で、AIに任せていい。でも顧客台帳への登録は段階3です。AIが「商談になりそう」と判断しても、本番のデータベースに書き込むのは担当者がボタンを押すまで保留にする。これを台帳で強制すると、誤分類のお客さんを勝手に登録する事故が消えます。

3. デプロイ前のひと呼吸 公開反映は必ず段階2に置きます。ローカルのビルドが通っただけで「完了」にせず、公開URL・見出し・巻き戻し手順を確認するまで止める。冒頭で僕がやらかした「依存パッケージの勝手な更新」も、段階2を明示していれば必ず人の確認で止まっていました。

よくあるつまずきと直し方

一番多いのは、全部を1回の依頼で終わらせようとして、誰も検証できない巨大な差分を作ることです。直し方は単純で、依頼を「1回で1つの成果物」に絞ること。記事1本、PR1件、設定1か所。小さく区切れば、差分を最後まで読み切れます。

次に多いのが、ローカルのビルド成功だけで完了扱いにすることです。公開サイトでは別ページやトップが表示されているのに、HTTP 200だけ見て安心してしまう。証拠の欄に「公開URLと見出しの確認」を入れておけば、ここで止まれます。

3つ目は、何を試したかを残さないこと。次の日に同じ判断を一からやり直すことになります。後述のメモを1行残すだけで、翌日の自分が迷いません。Claude Codeへの頼み方そのものを底上げしたいなら、プロンプト設計の実践 も合わせて読むと、枠の伝え方が一段うまくなります。

よくある質問

Q. 承認の段階は、もっと細かく分けたほうがいいですか？ 最初は4段階で十分です。増やすほど運用が複雑になり、結局守られなくなります。回してみて「ここが粗い」と感じた箇所だけ、後から枝分かれさせてください。

Q. 段階1の「やり直せる」かどうか、どう見分けますか？ 「git で1コマンドで戻せるか」「外部に影響が出ないか」の2点で判断します。ファイル編集は戻せますが、デプロイ・課金・メール送信・削除は戻せません。迷ったら段階2に上げます。

Q. チームで使うとき、誰が段階を決めますか？ 作業を始める人が朝に宣言し、段階2以上の判断者をあらかじめ決めておきます。担当者が不在なら段階3の作業はその日やらない、と決めておくと安全です。

Q. 毎回プロンプトを貼るのが面倒です。 枠が固まってきたら、プロジェクトのルールファイル（CLAUDE.md）に移してください。AIが毎回それを読むので、貼り付けが不要になります。

Q. 非エンジニアでもこのワークシートは使えますか？ 使えます。コードを動かさなくても、4段階の表とプロンプト雛形だけで線引きはできます。エンジニア以外の活用は 非エンジニアのためのClaude Code活用 も参考になります。

引き継ぎ用のメモ

その日の判断を1行で残しておくと、翌日の自分やチームが同じ迷いを繰り返しません。次の形をコピーして埋めるだけです。

- 日付: 2026-06-07
- 今日の目的: ブログ記事1本の誤字とリンク切れ修正
- 今日の上限: 段階1（やり直せる修正まで）
- 証拠: 差分、npm run build のログ、公開URLの見出し確認
- 人が止めた場所: 依存更新（段階2のため保留）
- 次回への申し送り: 依存更新は別日にまとめて段階2で実施

このメモがあると、公開後の確認も楽です。HTTP 200だけでは足りないので、公開URLで見出し・正規URL（canonical）・アイキャッチ・本文冒頭が、ちゃんとこの記事のものになっているかまで見ます。別記事やトップが表示されていたら未公開扱いにして、ビルドとデプロイをやり直します。権限設計の公式な考え方は Anthropic公式ドキュメント でも確認できます。

実際に試した結果

僕はこのワークシートを、自分のブログ運用に2週間あてはめてみました。

一番効いたのは、朝に「今日は段階1まで」と一文を貼るようにしたことです。これだけで、コミット1つあたりの「許可しますか？」が体感で半分以下になりました。AIが段階2以上に踏み込もうとすると、雛形のルール通りにちゃんと止まって僕に聞いてくる。冒頭のような「気づいたら依存が更新されていた」事故は、それ以降ゼロです。

逆に分かったのは、段階の表は作っただけだと使わない、ということです。台帳のコードを実際に走らせて「今日任せる作業」を画面に出してから始めると、守れる確率が上がりました。賢いAIを探すより、転んでも戻せる枠を先に引く。地味ですが、これが一番ストレスなく任せられる、というのが今の実感です。

この線引きをチーム全体や本番運用にまで広げたい場合は、研修・相談 で具体的なレーン設計を一緒に詰められます。まずは明日の朝、「今日は段階1まで」と一文を貼るところから試してみてください。