Claude Codeにどこまで任せる? 事故らない自律度の4段階ルール

金曜の夜、僕は「このブログの古い記事、リンク切れだけ直しておいて」とClaude Codeに頼んで寝ました。翌朝コミット履歴を見たら、12本の記事が書き換わっていました。リンクは確かに直っている。でも、ついでに見出しの言い回しまで「整えて」あって、僕が意図して残していた古い表現まで上書きされていたんです。

戻すのに2時間かかりました。賢いはずのClaude Codeが、なぜこういう余計なことをするのか。答えは単純で、僕が「どこまでやっていいか」を一度も伝えていなかったからです。

逆のパターンもあります。怖くなって、今度は1行直すたびに「これ実行していい?」と聞いてくる設定にしたら、30分で承認ボタンを押すのに疲れて、結局自分で書いた方が速くなりました。任せすぎて事故るか、止めすぎて疲れるか。多くの人がこの両極の間で迷子になります。

この記事は、その迷子を終わらせるための「自律度の4段階」の話です。読ませるだけ、直させる、公開させる、人間しか触らない——この4つを最初に線引きしておくと、毎回の判断がほぼ消えます。

この記事の要点

• Claude Codeに任せる作業は、危険度で4段階に分けると判断がラクになる。読ませるだけ / 戻せる編集 / 公開・反映 / 人間専用。
• 各段階には「終わった証拠」を必ず1つ決める。差分が出る、ビルドが通る、公開URLが正しい、など。
• 削除・本番データ・課金・force pushは、慣れても自動にしない。ここだけは毎回人間が押す。
• 段階はYAML1枚に書いてCLAUDE.mdの近くに置けば、Claude Code自身が「今どの段階か」を自己申告できる。
• 最初は1段階低めから始め、安全だと確かめた操作だけ後から格上げする。逆はやらない。

なぜ「賢さ」より「線引き」なのか

Claude Codeでつまずく人の多くは、モデルの性能ではなく作業の閉じ方で失敗しています。冒頭の僕がそうでした。指示そのものは悪くない。ただ「リンクだけ」という範囲を、文章でしか伝えていなかった。文章のお願いは、忙しい朝の同僚への口頭指示と同じで、簡単に解釈がずれます。

そこで効くのが、危険度による線引きです。やっていいことを「お願いの文面」ではなく「段階」で決めておく。すると、Claude Codeが何かしようとするたびに「それは何段階目の操作か」を照らし合わせられます。曖昧な日本語の解釈合戦から、機械的なチェックに変わるわけです。

この考え方は新しいものではありません。工場でも、見学だけの人、部品を組む人、出荷ボタンを押す人、金庫を開ける人は、最初から権限が分かれています。Claude Codeにも同じ線を引くだけです。

4段階の中身

僕が実際に使っている4段階は次の通りです。表で先に全体像を出します。

段階	やらせること	終わった証拠
0 読むだけ	ファイル構造の把握、リスク洗い出し、確認コマンドの提案	最後のメモに「読んだファイル一覧」がある
1 戻せる編集	記事1本の修正、テスト1件の更新	差分が出てビルドが通る
2 公開・反映	ビルド後のデプロイ、公開URLの確認	h1・正規URL・導線・戻し手順がそろう
3 人間専用	（Claude Codeにはやらせない）	—

段階3に入るのは、秘密鍵、課金、本番データ、force pushです。ここはどれだけ慣れても自動化しません。間違えたときの損失が、節約できる手間と釣り合わないからです。

各段階で大事なのは「終わった証拠」を必ず決めておくこと。証拠がないと、Claude Codeが「できました」と言っても本当に終わったのか分かりません。差分が出る、ビルドが通る、公開URLを開いてh1が正しい——こういう機械で確かめられるものを証拠に選びます。

AIに任せる範囲と、人が決める範囲

線引きをはっきりさせると、役割分担も自然に決まります。

Claude Codeに任せていいのは、手数が多くて結果を機械で確かめられる作業です。たくさんのファイルを読んで要約する、決まった形式で記事を直す、テストを走らせてログを読む。こういうのは人間より速くて正確です。

人が決めるべきは、戻せない判断と、損失の大きい操作です。この記事を本当に公開していいか、この古い表現を消していいか、この顧客データを上書きしていいか。ここはClaude Codeに「提案」はさせても、「実行」は人間が押します。

迷ったときの基準は1つ。「失敗しても10分で元に戻せるか?」 戻せるなら段階1、戻せないなら段階2か3です。冒頭の僕の事故は、戻すのに2時間かかった時点で、本当は段階2の慎重さが必要な作業だったわけです。

コピペで使える段階定義

段階を頭の中だけに置くと、結局ブレます。YAML1枚に書き出して、プロジェクト直下にautonomy.ymlとして置いてください。CLAUDE.mdから参照させると、Claude Code自身が「今は段階1なので公開はしません」と自己申告するようになります。

# autonomy.yml — Claude Codeに渡す自律度の線引き
safe_autonomy_ladder:
  level_0_read_only:
    allowed: ["ファイル構造を把握", "リスクを洗い出す", "確認コマンドを提案"]
    proof: "最後のメモに読んだファイル一覧がある"
  level_1_reversible_edit:
    allowed: ["記事1本を修正", "テスト1件を更新"]
    proof: "git diff が出て build が通る"
  level_2_publish_or_deploy:
    allowed: ["build 後にデプロイ", "公開URLを確認"]
    proof: "h1・正規URL・導線・戻し手順がそろう"
  level_3_owner_only:
    allowed: []
    examples: ["秘密鍵", "課金", "force push", "顧客データ"]

CLAUDE.mdにはこう一文だけ足せば十分です。

作業前に autonomy.yml を読み、今回の作業がどの段階かを最初に宣言すること。
段階2以上の操作は、実行せず人間の承認を待つこと。

段階を機械でチェックする検証スクリプト

宣言させるだけでは不安なので、僕は「段階2の操作（公開）が、証拠なしに行われていないか」を機械で見張っています。下のスクリプトは、デプロイ後に公開URLを取りに行き、h1が空でないか・正規URLが自分のslugを指しているかを確認します。Node.js 18以降ならそのまま動きます。

// verify-publish.mjs — 段階2の「終わった証拠」を機械で確認する
// 使い方: node verify-publish.mjs https://claudecode-lab.com/blog/your-slug

const url = process.argv[2];
if (!url) {
  console.error("公開URLを引数で渡してください");
  process.exit(1);
}

const res = await fetch(url);
if (res.status !== 200) {
  console.error(`HTTP ${res.status}: まだ公開できていません`);
  process.exit(1);
}

const html = await res.text();

// h1が中身ありで存在するか
const h1 = html.match(/<h1[^>]*>(.*?)<\/h1>/s);
const hasH1 = Boolean(h1 && h1[1].replace(/<[^>]+>/g, "").trim());

// 正規URLがこのページ自身を指しているか
const canonical = html.match(/<link[^>]+rel=["']canonical["'][^>]*>/i);
const canonicalOk = Boolean(canonical && canonical[0].includes(new URL(url).pathname));

console.log(`h1あり:        ${hasH1 ? "OK" : "NG"}`);
console.log(`正規URL一致:   ${canonicalOk ? "OK" : "NG"}`);

if (hasH1 && canonicalOk) {
  console.log("段階2の証拠そろいました。公開完了とみなせます。");
} else {
  console.error("証拠が足りません。まだ完了にしないでください。");
  process.exit(1);
}

HTTP 200だけを成功と思い込むと、トップページのfallbackや古い記事が出ていても気づけません。h1と正規URLまで見て、はじめて「この段階は終わった」と言えます。

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

1. 新しいリポジトリに入った直後 構造もコマンドも分からない状態でいきなり編集させると、設定ファイルを壊しがちです。最初は段階0だけ許可して、ファイル構成・使えるコマンド・触ると危ない場所を報告させる。地図ができてから段階1に上げます。

2. 記事の誤字修正 これは段階1で十分です。差分が出てビルドが通れば証拠は完成。冒頭の僕の事故は、ここで「修正は誤字だけ。文章の言い回しは変えない」と範囲を明記していれば防げました。Claude Codeに渡す依頼文の雛形はこうです。

段階1で作業してください。
対象: content/blog/foo.mdx の明らかな誤字脱字のみ
やらないこと: 見出しの言い換え、文章表現の変更、別ファイルの編集
終わったら git diff を見せて、変更が誤字修正だけか自己確認してください。

3. 本番公開の直前 段階2では、ビルドが通るか・環境変数がそろっているか・差分が想定どおりか・戻し手順があるか、を必ず確認させます。上の検証スクリプトを最後に走らせれば、公開URLの中身までチェックできます。

僕がやらかした失敗3つ

正直に書くと、この4段階に落ち着くまで何度も事故りました。

ひとつ目は、段階を一度に飛ばしたこと。段階0を省いていきなり段階1で大量編集させたら、検証できないほど大きな差分が出て、どこが正しいのか自分でも分からなくなりました。今は必ず0から順に上げます。

ふたつ目は、ローカルのビルドだけで「完了」にしたこと。手元で通ったから公開した。でも本番では古いページが表示されていて、半日気づきませんでした。それ以来、公開URLのh1と正規URLを見るまで完了にしません。

みっつ目は、承認を自分の目だけに頼ったこと。「最後に僕がチェックすればいい」は、疲れている夜に必ず破綻します。文字数・リンク切れ・型エラーのような機械で分かるチェックを段階の「証拠」に組み込んでから、夜中の見落としが激減しました。

始め方

いきなり全自動の賢いエージェントを目指さないでください。失敗しても戻せる小さい仕事を1つ選びます。下書きの誤字チェック、変更の一次レビュー、ステージング公開前の確認。このくらいがちょうどいい。

順番はいつも同じです。① 読ませる範囲を狭く決める → ② 成果物をはっきりさせる → ③ 確認はできるだけコマンドにやらせる → ④ 危ない操作（削除・本番データ・課金・force push）は最初は全部「人間に聞く」にする。安全だと確かめた操作だけ、後から1段ずつ格上げする。逆向きの格下げはしません。

権限の細かい設定でつまずくならClaude Codeの始め方を、CLAUDE.mdに段階のルールを書く書き方はCLAUDE.mdの書き方を先に見ておくと、この4段階がそのまま設定に落とせます。エンジニアでない人がチームに入れる前提なら非エンジニア向けの使い方も合わせてどうぞ。

よくある質問

Q. 段階分けって、毎回手で設定するんですか? いいえ。autonomy.ymlを1枚作ってCLAUDE.mdから参照させれば、以降はClaude Codeが自分で「今は段階1です」と宣言します。設定は最初の1回だけです。

Q. 段階2の「公開」まで自動にしても大丈夫? 証拠が機械でそろうなら、慣れた後に自動化していいです。ただし上の検証スクリプトのように、公開URLの中身を確認する仕組みを必ず挟んでください。HTTP 200だけを信じるのが一番危ない。

Q. 段階3に入れるべき操作の見分け方は? 「失敗したら謝って済むか、賠償が要るか」で考えると速いです。顧客データの上書き、課金、本番の削除は後者なので段階3。慣れても自動にしません。

Q. 小さなチームでも線引きは要りますか? むしろ人数が少ないほど効きます。誰が承認したかが曖昧になりやすいので、段階表を共有しておくと「これは誰がOKを出す操作か」が一目で分かります。

Q. プロンプトを工夫すれば段階分けは要らないのでは? プロンプトは解釈がぶれます。良い依頼文を書く力は別途プロンプトの実践で伸ばすとして、段階分けは「文面の上手さに依存しない安全網」です。両方あると一番強いです。

実際に試した結果

この4段階を自分のブログ運用に入れてから、冒頭のような「頼んでないことまでやられる」事故はゼロになりました。確かめたのは2点です。

1つは、autonomy.ymlをCLAUDE.mdから参照させたところ、Claude Codeが作業前に「今回は段階1なので公開はしません」と自分から宣言するようになったこと。線引きを文章ではなく段階で渡すと、解釈がぶれないと実感しました。

もう1つは、verify-publish.mjsを公開後に必ず走らせるようにしたら、過去に半日気づかなかった「古いページが本番に出る」現象を、公開直後に検知できるようになったこと。h1と正規URLを見るだけで、HTTP 200の落とし穴は埋まります。

賢いモデルを探すより、転んでもケガしない段階を先に決める。遠回りに見えて、これが一番速いというのが今の実感です。チームでClaude Codeの権限ルールを整えたい段階なら、研修・相談で一緒に線引きを設計できます。公式の権限設定はAnthropicのドキュメントも合わせて確認してください。