Claude Code リポジトリ初回オンボーディングマップ: 最初の1タスクを安全に選ぶ方法

既存コードに Claude Code を入れる最初の日に、いきなり「全体を見て改善して」と頼むのは危険です。便利そうに見えて、読む範囲も責任範囲も曖昧なまま始まるからです。

この記事では、最初の30分で作るリポジトリオンボーディングマップを扱います。目的は大きな設計書ではなく、Claude Code が安全に最初の1タスクを選べるだけの地図です。

あわせて読む: claude-code-getting-started-complete, claude-code-existing-codebase-map, claude-code-first-30-minutes-checklist. 公式の前提条件は Anthropic Claude Code getting started.

なぜ最初のコマンド前に必要か

このテーマの中心は 読む順番、保護領域、最初の変更、証拠コマンド です。Claude Code は速く動けますが、最初に渡す情報が広すぎると、重要ではない差分、古い仮説、収益に関係しない整形まで同じ重さで扱います。

既存コードを初めて触る初心者から中級者 にとって大切なのは、作業を大きく見せることではありません。読むもの、触らないもの、最初に試すもの、失敗したときに戻る場所を短く決めることです。これは記事運用でもプロダクト開発でも同じです。

実務で使う手順

1. README と package.json だけで技術スタックと起動方法を確認する
2. 課金、認証、環境変数、マイグレーションを保護領域として先に書く
3. 最初の作業は文章、CTA、テスト名など戻しやすい場所に限定する
4. build、diff、公開 URL など証拠に残る確認方法を決める

この順番にすると、Claude Code への依頼が「自由に考えて」から「この範囲で証拠を残して」に変わります。作業の自由度は残しつつ、危ない場所だけを先に閉じられます。

場面	安全な進め方	確認する証拠
ブログ運用	人気記事の末尾 CTA だけ直し、Gumroad リンクが変わっていないか確認する	build, diff, URL
SaaS	請求処理には触れず、設定画面の説明文だけ改善する	build, diff, URL
社内ツール	CSV 出力の列名だけ直し、サンプルデータで確認する	build, diff, URL

この証拠があると、Claude Code の返答を雰囲気ではなく作業結果で判断できます。

コピペ用プロンプトとコード

このリポジトリを初回オンボーディングしてください。まず README、package.json、主要な routes だけを読み、保護領域、最初に触る小さなタスク、実行する証拠コマンドを表にしてください。まだ編集しないでください。

const repoMap = {
  goal: "find one safe first task",
  readFirst: ["README.md", "package.json", "src/routes/"],
  protectedAreas: [".env", "billing/", "migrations/", "wrangler.toml"],
  firstTask: "improve one article CTA without touching payment code",
  proofCommands: ["npm.cmd run build", "git diff --stat"],
};

function readyForClaudeCode(map) {
  return map.readFirst.length >= 2 &&
    map.protectedAreas.length > 0 &&
    map.proofCommands.some((command) => command.includes("build"));
}

console.log({ ready: readyForClaudeCode(repoMap), firstTask: repoMap.firstTask });

コードは小さなチェック用です。実際のプロジェクトでは、この出力をそのまま CLAUDE.md、issue、または handoff note に貼ると、次のセッションでも同じ判断を再利用できます。

実例と失敗例

場面	安全な進め方	確認する証拠
ブログ運用	人気記事の末尾 CTA だけ直し、Gumroad リンクが変わっていないか確認する	build, diff, URL
SaaS	請求処理には触れず、設定画面の説明文だけ改善する	build, diff, URL
社内ツール	CSV 出力の列名だけ直し、サンプルデータで確認する	build, diff, URL

• 最初から全ファイルを読ませると、重要度の低い整形に時間を使います。
• 保護領域を書かないと、Claude Code は支払い、認証、デプロイ設定を普通の編集対象として扱います。
• 証拠コマンドがないと、完了報告が正しいか人間が毎回推測することになります。

失敗例の共通点は、Claude Code の能力不足ではなく、入力の境界が薄いことです。境界が薄いと、AI は親切心で作業を広げます。収益導線がある記事では、無料 PDF、Gumroad、相談のどれへ送るかも境界の一部です。

実務で使うときは、さらに「誰が最後に確認するか」まで書いておくと安定します。読む順番、保護領域、最初の変更、証拠コマンド は、Claude Code だけのためのメモではありません。翌日見返す自分、レビューする同僚、相談を受ける相手にも、なぜその小さな作業を選んだのかを説明する記録です。特に記事や商品導線を触る場合は、文章の自然さだけでなく、読者がどの段階にいるかを残します。まだコマンドに慣れていない人には無料 PDF、実務で繰り返す人には Gumroad、チームや本番運用で迷う人には相談、という判断を書いておくと、CTA が感覚でぶれにくくなります。

もう一つのコツは、最初の完了条件を小さくすることです。大きな改善を一度に頼むと、Claude Code は親切に範囲を広げます。最初は一つの slug、一つの component、一つの command に絞り、build とスクリーンショットまで見てから次へ進みます。これだけで、作業速度を落とさずに事故の戻し時間を減らせます。

最後のレビューでは、差分の量よりも「読者が次に何をするか」を見ます。タイトルと h1 が検索意図に合っているか、本文冒頭で約束した作業がコード例まで続いているか、CTA が無料 PDF、Gumroad、相談の順に無理なく並んでいるかを確認します。ここで商品リンクだけ強くすると、初心者は離脱します。逆に無料 PDF だけだと、実務で困っている読者を次の教材や相談へ送れません。小さな記事改善でも、読者段階、証拠、次の行動を同時に見ることが収益導線の基本です。公開後のスクリーンショットでは、h1 だけでなく本文冒頭と CTA 付近を同時に見ます。翻訳済みの見出しに英語本文が残っていないか、ボタンがスマホ幅で折り返しても読めるか、Gumroad と相談リンクが別の記事意図にずれていないかまで確認して完了です。数字を見る日を決めておくと、次回の改善が感覚ではなく、PDF 登録、教材クリック、相談導線のどこが弱いかから始められます。迷ったら、読者が今日すぐ実行できる一手と、明日買う理由が自然につながっているかを基準にします。この小さな基準が、毎日の改善を売上に近づけます。継続して見ます。

無料PDF・Gumroad・相談へのつなぎ方

まだ基本コマンドが曖昧なら 無料チートシート で毎日の型を固めます。設定、権限、CLAUDE.md、MCP、CI まで整える段階なら Setup Guide が次の有料ステップです。レビュー、デバッグ、リファクタリングの依頼文を毎回考えているなら 50 Prompt Templates が合います。チーム導入や収益導線まで含めて設計したい場合は 導入相談 に進み、教材比較は products で確認できます。

記事本文の CTA は最後に一つだけ置けばよいわけではありません。導入部では無料 PDF、実装例の後では Gumroad 教材、チームや本番運用の話では相談というように、読者の不安が強くなった場所で次の選択肢を出すほうが自然です。

公開後に見る数字

次は、この slug から無料PDFクリック、Setup Guide クリック、/en/training/ への移動が増えるかを見ます。

公開後は PV だけでなく、本文冒頭の読了、内部リンククリック、無料 PDF 登録、Gumroad クリック、相談ページ移動を分けて見ます。HTTP 200 だけでは成功ではありません。h1、canonical、heroImage、CTA、本文の言語がそろって、読者が次の行動を選べる状態まで確認します。