Claude Code Permission Receipt Pattern: 許可、証拠、ロールバックを残す運用

権限設定は一度書いて終わりではありません。実務では、今回の作業で何を許可し、何を承認待ちにし、どの証拠を残したかを毎回短く記録する必要があります。それが permission receipt です。

なぜこの型が必要か

Claude Codeに許可を広げるほど速度は上がりますが、事故の説明責任も増えます。receipt があれば、なぜそのコマンドを実行したのか、どのファイルが対象だったのか、導入相談やGumroadリンクを確認したのかを後から追えます。

あわせて読む: あわせて読む 1, あわせて読む 2, あわせて読む 3.

実務での進め方

作業前に allowed、requiresApproval、filesInScope、proof、rollback を1つの短いJSONかMarkdownで書きます。認証、課金、秘密情報、メール送信、本番deployに触れる場合は止めます。作業後は build と公開URL確認を receipt に追記します。

コピペできる最小セット

{
  "request": "update article CTA links",
  "allowed": ["Read", "Grep", "Edit content files", "npm run build"],
  "requiresApproval": ["deploy production", "change product price", "send email"],
  "proof": ["build passed", "public URL checked", "CTA clicked"],
  "owner": "content-ops"
}

Before acting, write a permission receipt.
Include allowed actions, actions requiring approval, files in scope, commands to verify, and rollback note.
If the task touches billing, auth, secrets, email sending, or production deploy, stop and ask for approval.

export function needsHumanApproval(receipt) {
  const risky = ["billing", "auth", "secrets", "email", "production deploy"];
  return receipt.requiresApproval.some((item) =>
    risky.some((word) => item.toLowerCase().includes(word))
  );
}

実例

• 記事CTAの修正なら content files と build は許可し、商品価格変更は承認待ちにします。
• 無料PDFフォームの改善なら送信テストは証拠に入れますが、実メール送信は承認待ちにします。
• チーム導入では CLAUDE.md に receipt のテンプレートを置き、毎回同じ粒度で残します。

運用チェックリスト

この型は一度読んで終わりではなく、毎回のClaude Code作業で短く確認するためのものです。特に記事、商品ページ、問い合わせ導線を触る日は、次の項目を紙のチェックリストのように扱うと事故が減ります。

• 作業前に目的を1文で書き、対象外のファイルや機能を明記する。
• Claude Codeへ渡す前に、読むべきファイルと読まなくてよいファイルを分ける。
• 実装後に必ず1つ以上の証拠コマンドを残す。記事ならbuildだけでなく公開URLを見る。
• 無料PDF、Gumroad教材、導入相談のリンクが本文と記事下CTAの両方で矛盾しないか確認する。
• 多言語記事ではtitle、h1、本文冒頭、CTAが同じ言語になっているか見る。
• 無関係なdirty fileをstageしない。必要ならcommit前に差分をもう一度分ける。
• 次回の作業者が迷わないよう、残ったリスクと次に見る数字を短く書く。

どの商品や相談につなげるか

読者がまだコマンドに慣れていないなら、最初の出口は無料チートシートです。作業が毎週繰り返されるなら Prompt Templates でレビュー、デバッグ、記事更新の指示を固定します。権限、CLAUDE.md、hooks、MCP、CI/CDまで揃えたい読者には Setup Guide が合います。チームの責任分界、公開前検証、収益導線の設計まで含むなら、記事内リンクだけで完結させず導入相談へつなげます。

handoffに残すべきこと

Claude Codeの作業は、その場で終わったように見えても、翌日の確認や別担当者のレビューで価値が決まります。handoffには、何を変えたかだけでなく、なぜその範囲に絞ったか、どの証拠を見たか、次に失敗しそうな場所はどこかを書きます。記事なら、本文の改善点、内部リンク、外部リンク、heroImage、公開URL、CTAの遷移先をまとめます。プロダクトや導入相談に近いページなら、無料PDFで十分な読者、Gumroad教材を買う読者、相談が必要な読者を分けて書きます。このメモがあると、次の自動化実行で同じ判断を繰り返さずに済みます。たとえば、記事公開のhandoffには、作成したslug、対象言語、使った画像、build結果、deploy結果、公開URLで確認したh1、canonical、本文言語、CTAの行き先を書きます。既存記事のリライトなら、どの検索意図に寄せたか、どの段落を足したか、どの売上導線を強めたかも残します。これにより、あとから「PVは増えたが登録が増えない」場合も、CTAの問題なのか、記事テーマの問題なのか、公開検証の漏れなのかを切り分けられます。

次に見る数字

公開後に見るべき数字はPVだけではありません。検索流入が増えても、無料PDF登録、Gumroadクリック、問い合わせフォーム到達が増えなければ収益導線は弱いままです。記事単位では、公開後24時間のindex状況、国別流入、CTA付近のスクロール、Gumroadリンククリックを見ます。既存人気記事を直した場合は、修正前後で直帰率と次ページ遷移を比べます。Claude Codeに次回依頼するときも、この数字を先に渡すと、単なる記事作成ではなく、導線改善として判断しやすくなります。さらに、記事の種類ごとに期待する次アクションを分けます。初心者向け記事では無料PDFのクリックが最初の成果です。設定や権限の記事ではSetup Guideへの遷移が重要です。レビュー、デバッグ、運用記事ではPrompt Templatesへのクリックを見ます。チーム、権限、公開検証、売上導線まで含む記事では導入相談ページへの遷移を優先します。この分け方をしておくと、PVが少ない記事でも高い価値を持つ導線として残すか、リライトするかを判断できます。数字を見るときは、記事だけを責めないことも大切です。CTAの文言、リンク先の価格、フォームの入力項目、ページ速度、翻訳品質のどれかが詰まっている場合があります。だから次回の改善では、記事本文、CTA、商品ページ、相談ページのうち一番弱い場所を1つだけ選び、小さく直して公開確認まで行います。

失敗例

• 権限を設定ファイルだけで管理すると、実際に何を許可したか作業単位で追えません。
• 承認待ちを曖昧にすると、価格、メール、deployのような戻しにくい変更へ進みます。
• 証拠欄がないと、build成功と公開URL成功を混同します。

無料PDF、Gumroad、導入相談への分岐

まず無料PDFで日々のコマンドを固定し、繰り返す作業はGumroad教材で型にします。チーム導入、権限設計、公開前レビューまで含む場合は導入相談へ進むのが自然です。記事本文のCTAは、読者の現在地を見て置きます。まだ不安が強い読者には無料PDF、具体的な型がほしい読者には教材、組織で失敗したくない読者には相談を出します。この順番を守ると、売り込みではなく次の作業を助ける導線になります。特に日本語読者は、英語教材へ直接飛ばすだけだと迷いやすいため、本文内で「何を得られるか」「どの悩みに向くか」を一文で補足します。これだけでクリック後の納得感が変わります。公開後はこのCTAが本当に見えているか、スマホ幅で押せるか、リンク先が404や別商品になっていないかも確認します。最終判断は、読者が次の小さな行動を迷わず選べるかです。迷う場合は、記事末尾のCTAだけでなく本文中にも自然な文脈リンクを置きます。ここまで含めて公開作業です。

• 無料 Claude Code チートシート
• 50個の Claude Code Prompt Templates
• Claude Code Setup Guide
• 教材一覧
• 導入相談

検証メモ

この記事は permissions guide、permission budget loop、approval sandbox guide へ接続し、無料PDF、Setup Guide、Prompt Templates、導入相談への導線を本文内で明示しています。