Claude Codeの承認を迷わない：read/edit/run/deploy判断ログの作り方

金曜の夕方、僕はClaude Codeに「このページのリンクだけ直して」と頼みました。返ってきたのは画面いっぱいの確認メッセージ。「このコマンドを実行していいですか？」と聞かれて、疲れていた僕は中身をろくに読まずにEnterを押しました。

翌朝、本番サイトの料金表示が変わっていました。リンクのついでに、AIが価格を書いた別のファイルまで「ついでに」直していたんです。許可ボタンを押したのは、まぎれもなく僕でした。

問題はAIの賢さじゃありません。昨日OKした操作と、今日止めるべき操作の線引きが、僕の頭の中だけにあって毎回ブレていたこと。その日の気分で「まあいいか」が動くなら、事故は時間の問題です。今日は、この線引きを頭の外に出す「承認ログ」のつくり方を書きます。

この記事の要点

• Claude Codeの承認は「読む・直す・実行・公開」の4つに分けると迷いが消える。
• 各操作を「許可・確認・禁止」に振り分け、理由と確認コマンドを毎日1ファイルに残す。
• AIに任せるのは下調べと下書き、人が握るのは料金・本番公開・削除の4種類。
• コピペできるログの雛形と、AIに振り分けを下書きさせるプロンプトを置いた。
• 迷ったら「許可」にしない。これだけで「ついで事故」がほぼ消えた。

承認を「読む・直す・実行・公開」の4つに分ける

Claude Codeを使っていると、いろんな確認が飛んできます。これを全部ひとまとめに「YesかNoか」で考えるから、毎回しんどいんです。やることを4種類に割ると、判断が一気に軽くなります。

• 読む：ファイルやログの中身を見るだけ。基本は許可で困りません。
• 直す：ファイルを書き換える。記事の誤字なら気軽でいい。料金表は別物です。
• 実行：コマンドを走らせる。動作確認は気軽、けれど外に影響するものは慎重に。
• 公開：本番サイトへ反映する。ここはいつも最後の砦として扱います。

同じ「直す」でも、ブログ本文の誤字と、決済設定のファイルでは重みがまるで違います。だから僕は、操作の種類だけでなく「どのファイルか」までセットで決めるようにしました。

判断を3段階に振り分ける

4種類に分けたら、それぞれを3段階に振ります。難しい言葉はいりません。

段階	意味	例
許可	黙って進めてよい	記事フォルダを読む、本文の誤字を直す
確認	一度こちらに聞く	料金ファイルを直す、本番へ公開する
禁止	今回はやらせない	ファイルの一括削除、強制的な上書き

コツはひとつだけ。少しでも迷ったら「許可」に入れない。とりあえず「確認」へ置きます。あとで「これは毎回安全だな」と分かってから「許可」へ格上げすればいい。最初から全部に手綱を握らせて、安全だと確かめたものだけ手綱をゆるめる。この順番を守るだけで、冒頭の料金事故みたいな話は起きなくなります。

毎日1ファイルに残す：ログの雛形

頭で覚えようとするから破綻します。1日1ファイル、その日の振り分けを書き残すだけ。形式は何でもいいですが、僕はこの形に落ち着きました。コピペしてそのまま使えます。

{
  "date": "2026-06-07",
  "範囲": "記事本文と導線の入れ替えだけ",
  "読む":   { "許可": ["site/src/content/**", "site/src/lib/gumroadProducts.ts"] },
  "直す":   { "許可": ["新規の記事ファイル"], "確認": ["料金", "決済設定", "本番のシークレット"] },
  "実行":   { "許可": ["npm run build", "公開URLの表示チェック"], "確認": ["公開", "git push"] },
  "公開":   { "確認するまで": ["ビルドが通る", "公開URLのh1が正しい", "各言語の表示を目視"] },
  "次回メモ": "料金は今後も確認のまま。記事の導線入れ替えは安全確認後に許可へ。"
}

書くのは2〜3分です。でもこの2〜3分が、翌日「あれ、これ昨日どうしたっけ」と悩む10分を消してくれます。範囲 の一行が地味に効きます。今日の作業がどこまでかを先に書くと、AIがその外に出た瞬間に気づけます。

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

ここを混ぜると事故ります。線引きをはっきりさせておきます。

AIに任せていいこと

• どのファイルが関係しそうか探す
• 変更の下書きを作る
• 変更前後の差分を見せる
• 「ビルドが通るか」を確認するコマンドを走らせる

人が必ず握ること

• 料金・決済・申し込みフォームに触る変更
• 本番サイトへの公開（公開ボタンは自分で押す）
• ファイルやデータの削除
• 戻し方を説明できない作業

僕のルールはシンプルで、「お金」「本番」「消す」「戻せない」の4つが絡んだら、必ず自分の手で最終判断する。逆に言えば、それ以外の下調べや下書きは遠慮なくAIに投げます。この線引きの考え方はエンジニアじゃない人向けのClaude Code入門でも触れていますが、専門知識がなくても「お金と本番だけは自分」と決めれば十分守れます。

AIに振り分けを下書きさせるプロンプト

振り分けそのものをAIに手伝わせることもできます。ただし、出てきた結果を鵜呑みにせず、最後は自分で見ます。次の指示文をそのまま貼って使えます。

今日のClaude Code作業について、操作を「許可・確認・禁止」に振り分けてください。
対象は次の4種類です：読む / 直す / 実行 / 公開。

各項目について、次を返してください：
1. 許可してよい操作の一覧
2. 一度確認すべき操作の一覧
3. 今回は禁止する操作の一覧
4. 安全を確かめるための確認コマンド（例: npm run build）
5. 次回に向けたメモ（確認 → 許可へ上げる条件）

料金・決済・本番公開・削除に関わる操作は、迷ったら「確認」に入れてください。

ポイントは最後の一行です。これを入れておくと、AIが勝手に「これは許可でいいでしょう」と判断を緩めるのを防げます。プロンプトの書き方をもっと詰めたい人はClaude Codeのプロンプト設計も合わせてどうぞ。

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

1. ブログ記事の入れ替え 人気記事の下にある申し込みリンクを1つだけ差し替えたい。こういう時に「関連しそうなところを直して」と頼むと範囲が広すぎます。先に「触っていいファイル」「触らないファイル」「確認する公開URL」をログに書いておく。すると作業後の確認が「なんとなく良さそう」から「この根拠なら公開していい」に変わります。

2. 問い合わせの仕分け 来た問い合わせをAIに読ませて、見込みのありそうなものだけ教えてもらう。読むのは「許可」で構いません。でも顧客リストへの登録は「確認」に残す。AIが分類を間違えても、勝手に本番のデータへ書き込む前に止まります。

3. 多言語記事の公開前チェック frontmatterの言語設定が正しくても、本文が英語のまま残っていることがあります。各言語で見出し・冒頭・導線まわりを見て、その言語の読者が次の行動を理解できるかを確認する。この目視を「公開するまでの確認項目」としてログに固定しておきます。

コピペで動く：承認ログのチェックスクリプト

ログを書いても、肝心の「公開前の確認」を飛ばしたら意味がありません。そこで、公開前に必ず通すチェックを1本のスクリプトにしておきます。ビルドが通るか、本番URLの見出しが正しいかを機械に確かめさせる例です。Node.jsがあれば動きます。

node check-before-deploy.mjs https://claudecode-lab.com/blog/claude-code-permission-decision-log/

中身はこれだけ。

import { execSync } from "node:child_process";

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

// 1. ビルドが通るかを確かめる（ここで落ちたら公開しない）
try {
  console.log("ビルドを確認中...");
  execSync("npm run build", { stdio: "inherit" });
} catch {
  console.error("ビルドが失敗しました。公開を止めます。");
  process.exit(1);
}

// 2. 公開URLにh1見出しが1つあるかを確かめる
const res = await fetch(url);
const html = await res.text();
const h1Count = (html.match(/<h1[\s>]/g) || []).length;

if (res.status !== 200) {
  console.error(`URLが開けません（状態コード: ${res.status}）。公開を見直します。`);
  process.exit(1);
}
if (h1Count !== 1) {
  console.error(`h1見出しが${h1Count}個あります。1個になるよう直してから公開します。`);
  process.exit(1);
}

console.log("ビルド・URL・見出しの確認が通りました。公開して大丈夫です。");

このスクリプトが緑になって初めて「公開」を許可する。逆に言えば、緑にならないものは何があっても公開しない。判断を人の気分ではなく、機械の○×に預けるのがコツです。

やりがちな失敗と、その直し方

正直に書くと、僕は一通りやらかしました。

理由を書かずに設定だけ変える。 設定ファイルだけ更新して「なぜそうしたか」を残さないと、翌日の自分が同じ迷いを繰り返します。直し方は単純で、ログの「次回メモ」に一行だけ理由を書く。「料金は信頼に直結するから確認のまま」のように。

勢いで公開を許可にする。 ビルドが通った勢いでそのまま公開まで許可してしまう。けれど公開前の確認は別物です。本番URLの見出し・表示崩れ・スマホ表示まで見る項目を「確認するまで」に固定して、機械チェックを通すまで公開しない。

軽い作業と重い作業を同じ扱いにする。 本文の誤字直しと、申し込みリンクや価格の変更を同じ「許可」で回すと、いつか冒頭の事故が起きます。gumroadのリンクや料金、フォームに触る作業は、誤字直しとは別の棚に分ける。この線引きはCLAUDE.mdの書き方にルールとして書いておくと、毎回考えずに済みます。

よくある質問

Q. 承認ログとセキュリティ設定は何が違いますか？ A. セキュリティ設定は「何を許すか」を固定するもの、承認ログは「今日その判断をなぜ下したか」を残すものです。設定はルール、ログは日記に近い。両方あると、翌日の自分やチームが同じ判断を再現できます。

Q. 毎日書くのは面倒です。続けるコツは？ A. 完璧を狙わないことです。最初は「直す」と「公開」の2列だけでも十分効きます。2〜3分で書ける形にして、作業を始める前の最初の入力として貼る習慣にすると続きます。

Q. AIが提案する振り分けは信用していい？ A. 下書きとしては便利ですが、最終判断は人がします。特に料金・本番・削除に関わる行は、AIが「許可でいい」と言っても自分で確認に落とす。判断の手間を減らすのが目的で、判断そのものを丸投げする道具ではありません。

Q. チームで使うときの注意は？ A. ログを1か所に集め、「許可」に入れる操作は誰が見ても同じ判断になる理由を書くことです。理由のない許可は、人によって解釈がブレて事故のもとになります。承認を段階的に広げる考え方は安全に自律性を上げる手順も参考になります。

Q. 小さなブログでもここまで必要ですか？ A. 規模が小さいほど、料金やリンクの事故が直接売上に響きます。むしろ個人や小チームこそ「お金と本番だけは確認」のルール1つから始める価値があります。

参考リンク

• Claude Code 権限ガイド
• Claude Code はじめ方ガイド
• Anthropic公式：Claude Code settings ドキュメント

実際に試した結果

この承認ログを2週間ほど続けて、いちばん効いたのは意外にも「軽い作業」でした。記事の誤字直しは安心して許可に置けますが、料金やリンク、申し込みフォーム、公開設定は確認に残す。この区別を先に書いておくだけで、AIの返答を読んだあとに「これは許していい作業だっけ」と毎回考え直す手間が消えました。

迷いが出やすかったのは、やはり「実行」と「公開」です。ビルドは許していい、けれど本番URLを確認しないままの公開はまだ早い。一度、見出し・表示崩れ・スマホ表示まで目で確かめてからは、同じ種類の公開を次から許可に上げられました。こうやって段階が記録に残るので、承認ログは堅苦しいセキュリティ文書というより、毎日の判断を軽くするためのメモとして使うのがいちばん現実的だ、というのが今の実感です。

権限の線引きを自分のチーム向けに整えたい、本番公開のルールを一緒に詰めたいという場合は、研修・相談で具体的な運用に落とし込めます。