Claude Code CLAUDE.md Permission Recipe: 毎回の説明と危険な権限を減らす

Claude Codeの失敗は、モデルが弱いからではなく、毎回の前提説明が揺れることで起きることがあります。CLAUDE.mdに方針を書き、権限ルールで実行できる範囲を分けると、初回セットアップでもチーム導入でも事故が減ります。

この記事は、初心者が最初に作るべきCLAUDE.mdとpermission recipeを扱います。目的は厳しく縛ることではなく、読み取り、質問、実行、禁止の境界を明確にすることです。

あわせて読む: permission safety ladder, Obsidian to CLAUDE.md workflow, getting started guide.

なぜこの型が効くのか

CLAUDE.mdは記憶ではなく、作業契約です。どのコマンドで検証するか、どのディレクトリを触らないか、CTAや商品リンクを壊さないことまで書くと、記事作成にも開発にも効きます。

permission recipeは、その契約を行動に変えます。read-only、ask-before、never-touch、proof commandsを分けるだけで、Claude Codeが勝手に危ない操作へ進む確率を下げられます。

実務フロー

1. CLAUDE.mdに目的、品質基準、検証コマンド、収益導線を短く書く
2. read-only、ask-before、never-touchの3層でファイル領域を分ける
3. 自動実行できるproof commandsを明示する
4. deployや削除など不可逆操作は必ず人間確認にする
5. 公開後にh1、本文冒頭、CTA、Gumroadリンクをスクショで見る

場面	安全な進め方	確認
個人サイト	記事本文は編集可、フォームとAPIはask-beforeにする	buildと公開URL
チームPR	差分のレビューは許可し、pushやdeployは明示指示まで止める	PR diff
収益ページ	商品リンク、価格、相談フォームを保護領域にする	クリック確認

そのまま使えるプロンプトとコード

このプロジェクト用のCLAUDE.md permission recipeを作ってください。read-only、ask-before、never-touch、auto proof commands、公開URLチェック、無料PDF/Gumroad/導入相談の保護ルールを含めてください。

const permissionRecipe = {
  readOnly: ["README.md", "package.json", "src/routes/"],
  askBefore: ["site/src/layouts/", "scripts/", "wrangler.toml"],
  neverTouch: [".env", "billing/", "customer-data/"],
  proofCommands: ["npm.cmd run build", "git diff --stat"]
};

function canRunWithoutAsking(command) {
  return permissionRecipe.proofCommands.includes(command);
}

console.log(canRunWithoutAsking("npm.cmd run build"));
console.log(canRunWithoutAsking("wrangler pages deploy"));

この例は設定ファイルそのものではなく、考え方をコードで表したものです。実際にはチームの権限、CI、デプロイ手順に合わせて調整します。

3つの実例

初回セットアップ

READMEとpackage.jsonだけを読ませ、編集前にCLAUDE.mdを作ります。最初の編集は1ファイルに限定すると、成功と失敗が分かりやすくなります。

多言語記事

slugとfrontmatterだけでなく、本文冒頭とCTAが各言語になっていることをルールに入れます。スクショ確認をproofにすると漏れが減ります。

導入相談前

現状の権限表、禁止領域、検証コマンドを持って相談すると、抽象的なAI相談ではなく実務改善の会になります。

避けたい失敗例

• CLAUDE.mdに理念だけを書き、具体的な禁止領域を書かない。
• 便利だからとdeployや削除を自動実行に入れる。
• 商品リンクや相談フォームを通常ファイルと同じ扱いにする。

ルールは長すぎると読まれません。最初は短く、毎回の失敗を1つずつ追記する方が実務では続きます。

無料PDF / Gumroad / 導入相談へのつなぎ方

まだ基本操作が不安なら 無料チートシート を手元に置きます。CLAUDE.md、権限、hooks、MCP、CIをまとめて整えるなら Setup Guide が近道です。

レビューやデバッグの依頼文を標準化したい場合は 50 Prompt Templates を使います。チームのルール設計や収益導線まで含めるなら 導入相談 が合います。教材比較は 商品一覧 から確認できます。

公開前後に見るところ

公開前に、新しいCLAUDE.mdや記事が権限ルールと矛盾していないか見ます。公開後は各言語のh1、本文冒頭、CTA、商品リンクをスマホ幅で確認します。

次に見る数字

このslugでは、Setup Guideクリック、無料PDF開始、相談ページ遷移、権限関連記事への回遊を見ます。権限記事から相談が増えるなら、読者はテンプレートより運用設計を求めています。

30分運用レビューで確認すること

CLAUDE.md permission recipeを実務に入れるときは、記事を読み終えた直後よりも、翌日の運用レビューが重要です。まず前日のログを見て、Claude Codeに任せた範囲、実際に変更されたファイル、実行した検証、公開後に見た画面を1つのメモにまとめます。ここで曖昧な言葉を残さないことが大切です。「確認した」ではなく「スマホ幅でh1、本文冒頭、CTA、Gumroadリンクを見た」と書けば、翌日も同じ品質で再現できます。

次に、読者の行動と作業者の安心を分けて見ます。作業者側では、禁止領域に触れていないこと、buildと公開URLが同じslugを指していること、翻訳本文が英語のまま残っていないことを確認します。読者側では、無料PDFへ進む人、Gumroad教材を見る人、導入相談へ進む人がどの段落の後で動きそうかを考えます。PVが増えてもこの分岐が弱ければ、記事はまだ収益導線として完成していません。

最後に、次回のClaude Code依頼へ戻せる形にします。失敗があれば「次回はこのファイルをask-beforeにする」「このCTAは公開URLで必ずクリックする」「この言語はスクショで本文冒頭を拡大して見る」のように、1つだけルールを足します。ルールを一気に増やすと運用されません。小さなルールを毎日1つ足す方が、記事品質、商品導線、多言語公開のすべてで効果が残ります。

小さな検証ログを残す

この型を続けるなら、最後に1行だけ検証ログを残します。書く内容は、作業日、slug、主CTA、build結果、公開URL、スクショで見た言語、次に直す候補です。長い日報にする必要はありません。むしろ短い方が翌日読み返せます。Claude Codeに次の作業を頼むときも、この1行があるだけで「前回どこまで確認したか」「どの商品導線を強めたか」「どの言語を必ず見るべきか」がすぐ伝わります。記事運用は毎回ゼロから考えると崩れます。小さなログを積むほど、無料PDF、Gumroad、導入相談の導線も改善しやすくなります。

翌週に直す優先順位

翌週の改善では、最初に流入がある記事を見ます。PVが少ない記事に大きな変更を入れるより、すでに検索されている記事でCTAの迷いを減らす方が成果につながります。無料PDFのクリックがあるのにGumroadへ進まないなら、商品説明の前に「どの作業が楽になるのか」を1段落足します。Gumroadはクリックされるのに購入が弱いなら、記事側で価格ではなく成果物を具体化します。相談ページへ進む読者がいるなら、問い合わせ前に準備する情報を記事内で説明します。この順番で見ると、Claude Codeの記事改善が単なるリライトではなく、収益導線の改善になります。

最後の判断基準

最後は「読者が次の作業を選べるか」で判断します。読み終えた人が、無料PDFで試す、Gumroad教材で型を手元に置く、導入相談で自分の運用に落とす、のどれかを自然に選べるなら記事は役に立っています。どれも選べないなら、情報は多くても導線は弱いままです。

公開後の確認で迷ったら、PVよりも読者が次の行動へ進めたかを優先して判断します。そして、迷いが残った箇所はメモに残し、翌週の改善で最初に手を入れます。小さな修正でも、流入のある記事ほど成果に直結します。