既存リポジトリにClaude Codeを入れる初日に、壊さず最初の1タスクを選ぶ手順

転職して3日目、僕は150ファイルくらいある決済まわりのコードを渡されました。ドキュメントはほぼ無し。誰に聞いても「動いてるからあまり触りたくない」と言う。とりあえずClaude Codeに「このリポジトリを把握して、気になるところを直しといて」とお願いしてみたんです。

10分後、Claudeは自信たっぷりに「20ファイルを整理しました」と返してきました。差分を開いて血の気が引きました。マイグレーション用のSQLファイルの整形、.env.example の並べ替え、そして決済リトライの待ち時間を勝手に「最適化」して半分にしていたんです。動くコードではありました。でも本番に出ていたら、二重課金の問い合わせで電話が鳴り続けていたはずです。

問題はClaudeの賢さじゃありません。初日に渡した範囲が広すぎただけ。他人の巨大コードを安全に任せるには、賢いAIを探す前に「読む順番・触らせない場所・最初の小さな仕事・確認方法」を30分で決めておく。これだけで初日の事故はほぼ消えます。今日はその30分の中身を、コピペできる形でまとめます。

この記事の要点

• 既存コードの初日は「全部見て直して」が一番危ない。範囲が曖昧なまま走り出すから。
• 最初の30分で作るのは設計書ではなく、最初の1タスクを安全に選ぶための1枚のメモ。
• メモに書くのは4つだけ。読む順番、触らせない場所、最初の小さな仕事、終わったと判断する確認コマンド。
• 最初の仕事は「戻しやすい場所」に限定する。文章、ボタンの文言、テスト名あたりがちょうどいい。
• AIに任せるのは「調べる・下書きする」まで。本番DB・課金・削除・公開ボタンは人が押す。

なぜ初日の最初の指示でつまずくのか

Claude Codeは速いです。速いからこそ、最初に渡す情報が広いと、どうでもいい差分まで全力で作ってきます。

人間の新人なら「ここ触っていいんですか」と聞きます。AIは聞きません。親切心で範囲を広げます。「整理して」と言えば、本当に隅々まで整理する。マイグレーションの整形も、課金リトライの「最適化」も、本人は良かれと思ってやっています。

だから初日にやることは、コードを読み込むことでも、立派な改善計画を立てることでもありません。境界を引くことです。どこまでなら勝手にやっていいか、どこからは人に聞くか。この線を先に引いておくと、Claudeへの依頼が「自由に考えて」から「この範囲で証拠を残して」に変わります。線を引くのに必要な時間は30分。コードを全部理解する必要はありません。

30分で作る、初日の1枚メモ

紙でもメモ帳でも構いません。次の4項目だけ埋めます。順番にも意味があります。

1. 読む順番を狭く決める。 いきなり全ファイルではなく、README と package.json だけ。これでどの言語か、どう起動するか、どんな道具を使っているかがわかります。次に主要な画面やルートを2〜3個。それで十分です。
2. 触らせない場所を書く。 課金、ログイン認証、環境変数、データベースのマイグレーション。ここは「読んでもいいけど書き換えるな」と明示します。書かないと、Claudeはここを普通の編集対象として扱います。
3. 最初の小さな仕事を1つ選ぶ。 戻しやすい場所に限定します。記事の文末の文言、ボタンのラベル、わかりにくいテスト名。失敗してもすぐ元に戻せるものです。
4. 終わったと判断する確認方法を決める。 ビルドが通るか、差分が想定の範囲か、画面が崩れていないか。雰囲気ではなく、コマンドの結果で判断します。

この4つを埋めると、初日の不安の大半が消えます。なぜなら「Claudeが何をしでかすか」ではなく「Claudeにどこまで任せたか」を自分が把握しているからです。

AIに任せる範囲と、人が判断する範囲

線引きを言葉にしておくと、毎回迷いません。僕が使っている分け方はこうです。

やること	Claudeに任せる	人が判断する
コードを読んで構造をまとめる	○ 下書きを作らせる	最終的な理解は自分で確認
触らせない場所を提案する	○ 候補を挙げさせる	課金・認証は必ず人が確定
文章やラベルの修正	○ 任せてよい	差分を見て承認
本番DBへの書き込み	×	人が手で実行
削除・公開・課金まわり	×	人がボタンを押す

ポイントは、危ない操作を最初から全部「人に聞く」側に置くことです。安全だと確認できた操作だけ、あとから自動に格上げします。逆はやらない。最初に広く許して、事故ってから締めるのは、順番が逆です。

この考え方をもっと丁寧に知りたい人は、Claude Code はじめの一歩ガイド と Claude Code 最初の30分チェックリスト も合わせて読むと、初日の動きがつながります。

コピペで使える依頼文の雛形

まず、いきなり編集させないのがコツです。最初は「読んで、表にまとめるだけ」を頼みます。

このリポジトリを初めて触ります。まだ何も編集しないでください。
次の順で読み、結果を表で返してください。

1. README と package.json を読み、使っている言語・起動コマンド・主要な依存を挙げる
2. 触ると危ない場所（課金・認証・環境変数・DBマイグレーション）を、ファイルパスつきで列挙する
3. 戻しやすい「最初の小さな仕事」の候補を3つ、理由つきで挙げる
4. 各候補について、完了を確認するコマンド（ビルド・差分確認など）を書く

繰り返します。この段階では1文字も編集しないでください。

表が返ってきたら、自分の目で「触らせない場所」が抜けていないか確認します。抜けていたら付け足して、次にようやく1タスクだけ依頼します。

さきほどの候補のうち、◯◯（記事末尾の文言修正）だけ進めてください。
課金・認証・環境変数・マイグレーションには一切触れないこと。
編集後に `npm run build` を実行し、差分を `git diff --stat` で見せてください。
壊れていたら、原因と直し方を1行で説明してから止まってください。

CLAUDE.md に「触らせない場所」を最初から書いておくと、毎回この注意書きを貼らずに済みます。書き方は CLAUDE.md ベストプラクティス にまとめてあります。

チェックを機械にやらせる小さなコード

「ちゃんと準備できてから渡す」を人の記憶に頼ると、忙しい日に必ず抜けます。なので、1枚メモが最低限そろっているかを機械に判定させます。次のコードはNode.jsでそのまま動きます。

// 初日の1枚メモが「Claudeに渡せる状態」かを機械チェックする
const repoMap = {
  goal: "戻しやすい最初の1タスクを1つ選ぶ",
  readFirst: ["README.md", "package.json", "src/routes/"],
  protectedAreas: [".env", "billing/", "migrations/", "wrangler.toml"],
  firstTask: "記事末尾の文言を直す（決済コードには触らない）",
  proofCommands: ["npm run build", "git diff --stat"],
};

function isReady(map) {
  const reasons = [];
  if (map.readFirst.length < 2) reasons.push("読む順番が狭すぎる/未設定");
  if (map.protectedAreas.length === 0) reasons.push("触らせない場所が空");
  if (!map.proofCommands.some((c) => c.includes("build"))) {
    reasons.push("ビルド確認コマンドが無い");
  }
  if (!map.firstTask) reasons.push("最初の1タスクが未選定");
  return { ready: reasons.length === 0, reasons };
}

const result = isReady(repoMap);
console.log(result.ready ? "渡してOK" : "まだ渡すな: " + result.reasons.join(", "));

実行するとこうなります。

node check-repo-map.mjs
# => 渡してOK

試しに protectedAreas を空配列にして実行すると「まだ渡すな: 触らせない場所が空」と出ます。たったこれだけですが、「触らせない場所を書き忘れたまま全自動で走らせる」という一番ありがちな事故を、渡す前に止められます。このメモは CLAUDE.md やissueにそのまま貼っておくと、翌日の自分や同僚も同じ判断を再利用できます。

実際に効いた3つの場面

1. ブログ運用で、稼いでいる記事のリンクを守る 人気記事の末尾の導線だけ直したいとき、Claudeに「文言を改善して」と頼むと、つい商品リンクのURLまでいじります。そこで「文言は直してよいが、リンク先URLは1文字も変えるな。変更後にビルドと差分を見せろ」と範囲を閉じます。これで売上に直結するリンクを壊さずに、文章だけ磨けます。

2. SaaSで、請求処理に近づけない 設定画面の説明文がわかりにくいとき、改善対象はあくまで表示テキストだけ。請求やプラン変更のロジックは触らせません。メモの「触らせない場所」に billing/ を入れておけば、Claudeが親切心でリトライ処理に手を出すのを防げます。

3. 社内ツールで、出力の列名だけ直す CSV出力の列名がわかりにくいという相談。直すのは列名の文字列だけで、集計ロジックは別の話です。「列名の表示文字列のみ。計算式には触れるな。サンプルデータで出力を見せろ」と頼むと、確認も一瞬で終わります。

3つに共通するのは、Claudeの能力不足ではなく、境界が薄いと事故るという一点です。境界をはっきり書くほど、AIは安全に速く動きます。

やりがちな落とし穴と直し方

落とし穴1: 最初から全ファイルを読ませる。 重要度の低い整形に時間とトークンを使い、肝心の変更が薄くなります。直し方は、読む対象を README と package.json プラス主要ルート2〜3個に絞ること。全体把握は1タスク終えてから少しずつ広げます。

落とし穴2: 触らせない場所を書かない。 Claudeは課金・認証・デプロイ設定を普通の編集対象として扱います。直し方は、ファイルパスつきで保護リストを書き、CLAUDE.md に常駐させること。口頭の注意は忘れられますが、書いたものは残ります。

落とし穴3: 確認コマンドを決めずに「できました」を信じる。 完了報告が正しいか毎回人が推測することになります。直し方は、依頼文に最初から「ビルドして差分を見せて」を入れること。HTTP 200やそれっぽい返事は成功の証拠になりません。実際に走らせた結果だけを信じます。

よくある質問

Q. 既存コードの全体像を理解してから任せたほうが安全では？ 理想はそうですが、初日に全体理解は終わりません。終わるのを待つと何も進まないので、先に「触らせない場所」を閉じて、戻しやすい1タスクから始めます。理解は作業しながら広げるほうが速いです。

Q. 最初のタスクはどのくらい小さくすべきですか？ 1つのファイル、1つの文言、1つのコマンドで終わる粒度が目安です。大きく頼むとClaudeは親切に範囲を広げます。ビルドとスクリーンショットを確認してから次へ進めば、速度を落とさず戻し時間を減らせます。

Q. 触らせない場所はどこに書くのがいいですか？ CLAUDE.md に書くのが一番続きます。毎回プロンプトに貼る方式は、忙しい日に貼り忘れます。プロジェクトのルールとして1か所に置けば、新しい作業でも自動的に効きます。

Q. 「触るな」と言ったのにClaudeが触ってしまいました。 たいていは保護対象がファイル名止まりで、ディレクトリ全体を指定できていません。billing.js だけでなく billing/ のように範囲で書きます。それでも越えるなら、依頼文の冒頭で「編集前に対象ファイルを宣言してから進め」と一段挟むと止まりやすくなります。

Q. このメモは毎回作り直しですか？ リポジトリごとに1回作れば、あとは使い回せます。CLAUDE.md とissueに貼っておけば、翌日の自分も同僚も同じ判断を引き継げます。新しい保護対象が見つかったら追記していくだけです。

実際に試した結果

冒頭の決済コード事件のあと、僕は別の既存リポジトリで同じ手順を試しました。まず編集を一切させず、上の依頼文で表だけ出させたところ、billing/ と migrations/ を保護対象の候補にちゃんと挙げてきました。ただし環境変数ファイルは抜けていたので、自分で .env を追記。ここを人が見る前提で進めるのが大事だと改めて思いました。

最初のタスクは記事末尾の文言修正1つに絞り、npm run build と git diff --stat まで確認して完了。差分は7行だけで、決済コードには1文字も触れていませんでした。チェック用のコードも実際に動かし、protectedAreas を空にすると「まだ渡すな」と止まることを確認済みです。賢いAIを探すより、転んでもすぐ戻せる小さな範囲を先に決める。これが他人のコードを任せる初日に、いちばん効きました。

会社の既存コードにClaude Codeをどう入れるか、チームで型を決めたい段階なら、研修・相談 で実際のリポジトリを見ながら境界の引き方を一緒に整理できます。公式の前提条件は Anthropic Claude Code getting started も確認しておくと安心です。