Claude Code最初の1週間コマンドマップ: 初心者が順番に実行する12コマンド

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

この記事では、Claude Codeを入れた直後で、落ち着いて最初の一週間を進めたい初心者向けに最初の1週間コマンドマップを作ります。よくある失敗は単純で、インストール直後に大きな依頼へ飛び、どのコマンドで進捗を証明するか決められないことです。Claude Codeの作業は「よさそうな回答」で終わらせず、別の人が確認できる成果物を残す必要があります。今回の成果物は読む、1つ編集する、検証する、引き継ぐまでの日別コマンドマップです。

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

運用ループ

運用は5段階で回します。actionを決める、proofを選ぶ、Claude Codeに最小作業をさせる、出力を検証する、次の収益アクションを記録する、という順番です。このテーマで見るべき証拠は「コードが動いた」だけではありません。build成功、小さいdiff、承認事故の減少、初心者記事からのPDF開始を見ます。項目が見えると、勘で記事を書き直さずに済みます。

1. 1日目はread-onlyにし、patchを頼む前にファイル、コマンド、危険ディレクトリを把握します。

2. 3日目は戻せる1編集だけ許可し、編集前に検証コマンドを決めます。

3. 5日目はhandoff noteを書き、次回の作業を記憶ではなく証拠から始めます。

コピペ用スターター

$checks = @(
  "git status --short",
  "rg --files | Select-Object -First 40",
  "npm.cmd run build"
)

foreach ($cmd in $checks) {
  Write-Host "NEXT:" $cmd
}

3つの現場例

例1. 1日目はread-onlyにし、patchを頼む前にファイル、コマンド、危険ディレクトリを把握します。

例2. 3日目は戻せる1編集だけ許可し、編集前に検証コマンドを決めます。

例3. 5日目はhandoff noteを書き、次回の作業を記憶ではなく証拠から始めます。

自己レビューチェック

この運用を習慣にする前に、release noteのように記事を見直します。最初に見るのはscopeです。読者が最初の1週間コマンドマップを使う場面と、もっと小さな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へ入れます。読む、1つ編集する、検証する、引き継ぐまでの日別コマンドマップは、次のsessionでも使えるときだけ価値があります。

実務では、記事を公開した日より翌日の見直しのほうが重要です。公開直後はbuild、deploy、HTTP 200、h1、canonicalを確認します。翌日は、検索流入がどの段落で止まったか、PDF formまで届いたか、Gumroad linkがクリックされたか、導入相談ページへ進んだかを見ます。build成功、小さいdiff、承認事故の減少、初心者記事からのPDF開始を1行にしておくと、PVだけで成功扱いする癖を避けられます。

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

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

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

最後に、数字を見る時間を決めます。公開当日は技術的な正しさ、翌日は読者行動、1週間後は収益導線を見ます。1つの画面で全部を判断しようとすると、PVだけに引っ張られます。読む、1つ編集する、検証する、引き継ぐまでの日別コマンドマップは、時間軸ごとに見る数字を分けるための道具でもあります。

多言語記事では、機械チェックだけでは不十分です。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が問題なら導入相談です。このテーマでは、free cheatsheetは日々のコマンド確認に、Setup Guideはチームルール化に向いています。

検証する数字

公開後はHTTP 200だけで終わりません。h1、canonical、hero image、本文冒頭、CTA link、mobile layout、言語を確認します。そのうえでbuild成功、小さいdiff、承認事故の減少、初心者記事からのPDF開始を見ます。数字が動かなければ、記事全体ではなく最初の具体例の近くにあるCTAから直します。

追加メモ: 最初の一週間は、速く進めるよりも失敗の場所を小さく保つことを優先します。検証できる一歩を積み上げるほど、無料PDF、Gumroad、導入相談の分岐も自然に選べます。