Claude Code権限リスク台帳: エージェントが動く前に許可範囲を決める

なぜ専用の成果物にするのか

この記事では、個人利用からチーム運用へ進むClaude Code利用者向けに権限リスク台帳を作ります。よくある失敗は単純で、agentが編集、deploy、危険コマンド要求をした後で権限議論が始まってしまうことです。Claude Codeの作業は「よさそうな回答」で終わらせず、別の人が確認できる成果物を残す必要があります。今回の成果物はaction、default decision、proof、ownerを並べる小さなリスク台帳です。

この成果物は、prompt、command line、公開ページの間の契約として扱います。Claude Codeが何を読み、何を変更し、どのコマンドで証明し、読者を次にどの収益導線へ送るのかを見える化します。この考え方はharness engineering、getting started、permissionsとつながります。

運用ループ

運用は5段階で回します。actionを決める、proofを選ぶ、Claude Codeに最小作業をさせる、出力を検証する、次の収益アクションを記録する、という順番です。このテーマで見るべき証拠は「コードが動いた」だけではありません。承認回数、拒否コマンド、rollback note、deploy証跡、相談意図を見ます。項目が見えると、勘で記事を書き直さずに済みます。

1. read-onlyのrepo把握は、最後に読んだ範囲を記録するなら標準許可にできます。

2. content編集はdiff review、build、公開URL確認を必須にすれば許可しやすくなります。

3. secret、billing、customer data、force pushはagentが正確でもowner承認のままにします。

コピペ用スターター

permission_risk_register:
  - action: "read repository files"
    default: "allow"
    proof: "list files read in the final note"
  - action: "edit content files"
    default: "allow after diff review"
    proof: "build passes and URL matches the slug"
  - action: "deploy production"
    default: "ask first"
    proof: "build log, deploy URL, rollback note"
  - action: "touch secrets or billing"
    default: "never without owner approval"
    proof: "human approval id"

3つの現場例

例1. read-onlyのrepo把握は、最後に読んだ範囲を記録するなら標準許可にできます。

例2. content編集はdiff review、build、公開URL確認を必須にすれば許可しやすくなります。

例3. secret、billing、customer data、force pushはagentが正確でもowner承認のままにします。

自己レビューチェック

この運用を習慣にする前に、release noteのように記事を見直します。最初に見るのはscopeです。読者が権限リスク台帳を使う場面と、もっと小さなchecklistで足りる場面を区別できる必要があります。次にproofです。提案はcommand、URL、diff、metricのどれかへつながっているべきです。最後にroutingです。無料PDF、Gumroad guide、導入相談は競合させず、違う緊急度に答えさせます。

小さなowner ruleも書きます。成果物のowner、検証のowner、次のCTA実験のownerを分けます。1人運用なら同じ人で構いませんが、note上では役割名を残します。こうするとClaude Codeが公開、計測、販売文改善を1つの曖昧な作業として扱いにくくなります。次回の自動運用も、どこから続けるかを判断しやすくなります。

最後に「明日の朝、このこの記事を検証しやすくするものは何か」と聞きます。答えがscreenshotなら保存します。答えが強いpromptならprompt packへ入れます。答えが境界線ならsetup noteへ入れます。action、default decision、proof、ownerを並べる小さなリスク台帳は、次のsessionでも使えるときだけ価値があります。

実務では、記事を公開した日より翌日の見直しのほうが重要です。公開直後はbuild、deploy、HTTP 200、h1、canonicalを確認します。翌日は、検索流入がどの段落で止まったか、PDF formまで届いたか、Gumroad linkがクリックされたか、導入相談ページへ進んだかを見ます。承認回数、拒否コマンド、rollback note、deploy証跡、相談意図を1行にしておくと、PVだけで成功扱いする癖を避けられます。

Claude Codeに任せる範囲も段階化します。まずread-onlyで分析し、次に1ファイルだけ編集し、最後にbuildと公開URLを確認します。いきなりdeployや商品導線変更まで渡すと、どこで失敗したのか分からなくなります。権限リスク台帳は、作業を止めるための書類ではなく、次に任せてよい範囲を決めるための判断材料です。

収益導線では、強い売り込みよりも適切な分岐が効きます。初心者には無料PDF、繰り返し作業にはGumroad、チーム導入や権限設計には相談を出します。記事本文の実例とCTAが一致しているほど、読者は次の行動を選びやすくなります。

もう1つ大事なのは、失敗を責める材料にしないことです。Claude Codeの出力が外れたら、prompt、権限、検証コマンド、公開確認のどこが弱かったかに分解します。人間の記憶で修正するのではなく、次回の入力に戻せる形で残します。そうすると同じ失敗が、次の記事、次のCTA、次のdeploy checkを強くする材料になります。

最後に、数字を見る時間を決めます。公開当日は技術的な正しさ、翌日は読者行動、1週間後は収益導線を見ます。1つの画面で全部を判断しようとすると、PVだけに引っ張られます。action、default decision、proof、ownerを並べる小さなリスク台帳は、時間軸ごとに見る数字を分けるための道具でもあります。

多言語記事では、機械チェックだけでは不十分です。h1が正しくても本文冒頭が別記事だったり、CTAだけ翻訳されて本文が英語のままだったりします。公開後にスマホ幅で開き、hero画像、本文冒頭、CTA付近、Gumroad link、相談linkをまとめて見ます。読者が見る画面を確認して初めて、記事公開と導線改善が同じ作業になります。

この確認を毎回の終点にすると、Claude Codeは単なる執筆補助ではなく運用担当になります。記事、商品、相談導線を同じ検証単位で扱えるため、次の改善点が自然に見えます。迷ったときは、次の読者がクリックする場所を1つだけ選び、そこを証拠つきで直します。

失敗例

失敗例の1つ目は、PVだけを点数にすることです。2つ目は、proof commandなしで変更を承認することです。3つ目は、無料PDFが合う読者にも相談が合う読者にも同じ有料商品だけを出すことです。CTAを変える前にrouting ruleを書くと、この混線を防げます。

収益導線

読者は詰まり方で分けます。commandに不安があるなら無料PDFまたはfree Gumroad cheatsheetへ送ります。同じ作業を毎週繰り返すなら50 Prompt TemplatesかSetup Guideが合います。rollout、risk、revenue designが問題なら導入相談です。このテーマでは、Setup Guideはpolicyの土台に、consultationはproductionや収益に絡む承認設計に向いています。

検証する数字

公開後はHTTP 200だけで終わりません。h1、canonical、hero image、本文冒頭、CTA link、mobile layout、言語を確認します。そのうえで承認回数、拒否コマンド、rollback note、deploy証跡、相談意図を見ます。数字が動かなければ、記事全体ではなく最初の具体例の近くにあるCTAから直します。