Claude Codeを入れた最初の30分でやったこと（とやらかしたこと）

claude と打ってEnterを押した瞬間、僕が最初にやったのは「このリポジトリ全部読んで、いい感じにリファクタして」でした。

結果は覚えています。10分くらい待って、12ファイルの差分がどさっと出てきて、僕はその差分を1行も理解できませんでした。良い変更なのか、地雷なのか、判断がつかない。怖くて全部捨てました。

あのとき分かったのは、最初の30分は「Claude Codeに何ができるか」を試す時間じゃないということです。「自分がこの相棒をどう信じていくか」を決める時間なんですね。だから今日は、機能の網羅じゃなくて、僕が実際にたどった30分の流れをそのまま書きます。最初にやらかしたことも込みで。

なお、インストール手順そのものや料金の話はこの記事では深追いしません。そっちが知りたい人は途中でリンクを置くので、そこへ寄り道してから戻ってきてください。この記事は「入れたあと、最初の30分で具体的に何をして何をしないか」の体験談に振り切ります。

この記事の要点

• 最初の30分は機能検証の時間ではなく、小さな成功を1個積んで相棒を信じ始める時間。
• 僕の最大の失敗は1分目の「全部リファクタして」。広い依頼は判断不能な差分を生んで、結局ゼロになる。
• 流れはたった4ステップ。(1) 何でもいいから1問質問する → (2) ファイルを限定した小タスクを1個通す → (3) 差分を自分の言葉で説明できるか確認 → (4) うまくいったやり方を覚える。
• 設定（CLAUDE.md・権限）はこの30分では最小でいい。深掘りは別記事へ送る。
• 30分後のゴールは「派手な自動化」ではなく「触ってみただけ」を卒業すること。

0〜5分：インストール直後、いきなり頼まない

インストールが終わると、ターミナルでこう打つだけで起動します（Windowsなら事前に PowerShell で irm https://claude.ai/install.ps1 | iex、Mac/Linux/WSLなら curl -fsSL https://claude.ai/install.sh | bash を1回。詳しい手順は後述のクイックスタートへ）。

cd path/to/your/project
claude

初回は自動でログインを求められます。ブラウザが開くので、そのまま認証すれば終わり。バージョン・モデル名・作業ディレクトリが上に表示されて、入力待ちになります。

ここで僕がやらかしたのが冒頭の「全部リファクタして」でした。今ならぜったいに止めます。理由はシンプルで、起動直後はまだ「この相棒の差分を読む目」が自分にできていないからです。いきなり大きい仕事を投げると、出てきたものが良いのか悪いのかを判断できず、結局その出力は使えません。検証ですらなく、ただの賭けです。

だから最初の5分でやるべきことは、頼むことではなく質問すること。たとえばこう打ちます。

このプロジェクトは何をするもの? 主要なディレクトリ構成と、エントリーポイントを教えて

これだけ。Claude Codeは必要なファイルを自分で読みにいって、要約を返してくれます（こちらが手動でファイルを貼る必要はありません）。返ってきた説明が、自分の理解と合っているか。ここで初めて「お、ちゃんと読めてるな」とか「あれ、この理解はズレてるな」という感触が手に入ります。この感触が、あとで差分を信じるかどうかの土台になります。

ちなみに、もしインストールがまだ／うまくいかない人は、ここで無理に進めずClaude Code 始め方：5分で最初の1コマンドを動かすクイックスタートへ寄り道してください。最初の1コマンドが動く状態を作ってから戻ってくるほうが、絶対に早いです。

5〜15分：ファイルを限定した「小タスク1個」だけ通す

質問で感触をつかんだら、次はいよいよ作業を1個だけ頼みます。ここがこの30分の山場です。

僕が決めているルールは1つだけ。対象ファイルを自分で指定する。広い依頼が事故るのは、Claude Codeが悪いからではなく、こちらが「どこまで読ませるか」を放棄しているからです。範囲を絞れば、出力の良し悪しも自分で判断できます。

最初の1タスクは、成果が見えやすくて、失敗しても捨てやすいものを選びます。僕がよく最初に選ぶのはこの3つ。

タスクの種類	なぜ最初に向くか
エラーメッセージの原因調査	答え合わせが「直ったか」で一瞬。捨てても痛くない
既存コンポーネントの小さなUI修正	変更が画面に出るので良し悪しが目で分かる
テストを1個追加	既存コードを壊さず、緑になれば成功と明確

たとえば僕が2回目の起動で実際に投げたのは、こういう依頼でした。広い「改善して」とは別物だと分かるはずです。

src/components/ProfileCard.tsx と src/lib/formatDate.ts を読んで、
プロフィールカードの日付が "Invalid Date" になる原因を調べて。
原因が分かったら最小の修正案を出して、最後に変更理由を3行でまとめて。

ポイントは、対象ファイル・目的・出力形式をワンセットで渡すこと。「どのファイルを見て」「何のために」「どんな形で返してほしいか」。この3点があるだけで、暴走率がガクッと下がります。1分目の僕に足りなかったのは、まさにこれ全部でした。

なお、Claude Codeはファイルを書き換える前に必ず確認を求めてきます（権限を緩めない限り）。だから差分を見て、Yes/Noを自分で押せます。この「押す前に止まる」感覚を、最初の1個でちゃんと体験しておくのが大事です。

ここで設定をいじり倒さない

最初の30分でやりがちなのが、ここで権限設定や CLAUDE.md を完璧に整えようとして時間を溶かすこと。僕も一度やりました。30分のうち20分が設定いじりで終わって、肝心の「タスクを1個通す」をやらないまま満足してしまった。本末転倒です。

この30分では、設定は最小で十分。CLAUDE.md は /init で雛形だけ作っておけばいいし、権限はデフォルト（書き込み前に毎回聞いてくる状態）のまま進めて問題ありません。むしろ最初は毎回確認が出るほうが安全です。

設定をちゃんと作り込むのは、相棒の挙動が分かってきた「次の日」でいい。腰を据えて権限やルールを整える話は、別記事にまとめてあります。

• 権限を安全に絞る早見表は Claude Code 権限設定リファレンス
• ルールファイルの粒度は CLAUDE.mdは「何を書かないか」で決まる

15〜25分：差分を「自分の言葉」で説明できるか

タスクが返ってきました。ここで多くの人（昔の僕含む）がやる失敗が、中身を読まずにYesを押すことです。

最初の30分でいちばん大事な習慣は、たぶんこれです。出てきた差分を見て、「この変更は要するに何をしているか」を自分の言葉で1行に言えるかを確認する。言えたら採用、言えなかったら採用しない。これだけ。

さっきの日付バグの例なら、たとえば「formatDate に渡る値が文字列じゃなくて undefined のケースをガードした」と自分で言えるなら、それは信じていい差分です。言えないなら、Claude Codeにこう聞き返します。

さっきの修正、なぜこの変更で直るのか、初心者にも分かるように3行で説明して。
あと、この変更で壊れそうな箇所があれば2つ挙げて

この「説明して」が効くんです。Claude Codeは理由を言語化してくれるので、自分の理解の穴が埋まる。しかも「壊れそうな箇所」を聞くと、自分が見落としていた依存関係に気づけることが多い。僕は実装を任せる前に、この「地雷の洗い出し」をさせる使い方をいちばん信頼しています。

ここで身につくのは、Claude Codeを疑う技術です。賢いAIを盲信するんじゃなくて、出力を自分のサイズに噛み砕いて、納得できたものだけ通す。これができると、最初の30分のあとも事故りません。

25〜30分：うまくいったやり方を「型」として残す

最後の5分。せっかく1個うまくいったので、それを使い捨てにしないでおきます。

具体的には、さっき効いた依頼文をどこかにコピーしておく。メモアプリでも、リポジトリ内の prompts.md でも何でもいい。次に同じ種類の作業をするとき、ゼロから考えずに済みます。Claude Codeを毎日使うようになると、結局この「効いた型」の数が生産性に直結してきます。

参考までに、僕が最初の数日で型として固定した3つを置いておきます。そのままコピペして、ファイル名だけ自分のものに変えれば動きます。

# 型1: バグ調査
次の不具合を調べて。
- 症状: 保存後に一覧へ戻ると日付が "Invalid Date" になる
- 調査対象: src/features/orders/ と src/lib/date.ts
- やってほしいこと:
  1. 原因候補を絞る
  2. 最小の修正案を出す
  3. 影響しそうな箇所を2つ挙げる

# 型2: 小さなUI修正
src/components/Header.tsx を読んで、
モバイルでCTAボタンが2行に折り返さないように直して。
変更後、なぜそのCSSにしたかも説明して。

# 型3: テスト追加
src/lib/calcPrice.ts を読んで、境界値を中心に Vitest のテストを追加して。
想定ケースを先に列挙してから実装して。

この3つで、調査・修正・検証という基本の3動作がひと通り回せます。30分の終わりにこれが手元にあれば、もう「触ってみただけ」ではありません。

ちなみに、既に動いている本番寄りのコードベースで最初に何を投げるか迷うなら、そこに特化した文例集を別でまとめています。新規の練習リポジトリではなく、いきなり既存プロジェクトで始める人はClaude Codeに既存コードで最初に投げるプロンプト集が近道です。手順を1枚で確認したい人はClaude Code最初の30分チェックリストもどうぞ。

この30分で絶対にやらないこと

逆に、最初の30分で手を出すと高確率で後悔するものを並べておきます。全部、僕が一度はやって痛い目を見たやつです。

• 「全部読んで改善して」みたいな広すぎる依頼（差分が読めず、判断不能になる）
• 大規模リファクタリングを初手で投げる（能力検証じゃなく、ただの賭けになる）
• 本番DBや本番インフラが絡む作業（戻せない事故は、慣れてからでも遅くない）
• テストがないのに大量変更を任せる（壊れたことに気づけない）
• 設定を完璧にしようと30分溶かす（タスクを1個も通さず満足してしまう）

共通しているのは「失敗したときに戻せるか／良し悪しを判断できるか」です。この2つを満たさない仕事は、最初の30分には早すぎます。

もう少しプロンプトの精度を上げたくなったら、プロンプト改善の5つのコツが次の一手になります。

よくある質問

Q. 最初の30分でインストールから全部終わらせるべき? いいえ。インストールでつまずいたら、無理に進めずクイックスタートで「最初の1コマンドが動く状態」だけ作ってください。30分の本番は、起動できてからで十分です。

Q. 最初のタスクは何を選べばいい? エラー調査・小さなUI修正・テスト1個追加、のどれか。共通点は「失敗しても捨てやすく、良し悪しが一瞬で分かる」こと。新規実装や自動化は、相棒の差分を読めるようになってからにしましょう。

Q. 権限設定は最初に作り込むべき? この30分では不要です。デフォルト（書き込み前に毎回確認が出る状態）で進めるのがいちばん安全。落ち着いて整えるのは翌日でよく、やり方は権限設定リファレンスにまとめています。

Q. 出てきた差分が良いか悪いか判断できません。 判断できない差分は採用しないのが正解です。「なぜこの変更で直るのか3行で説明して」と聞き返してください。自分の言葉で1行に言えるまで噛み砕いてから通す。これが最初の30分で身につけるべき唯一の習慣です。

Q. 練習用リポジトリと本番、どっちで始めるべき? 最初の1回は失敗しても困らない小さめのリポジトリが安全です。とはいえ既存プロジェクトで始めたい事情もあるので、その場合は範囲を絞った既存コード向けプロンプト集を使って、読ませる範囲を自分で限定してください。

実際に試した結果

この「質問1個 → 限定タスク1個 → 差分を説明させる → 型を残す」の流れを、自分でも改めて30分計って試してみました。途中で権限や指示の出し方に迷う回数が、初日とは比べものにならないくらい減りました。たぶん、迷う余地を最初から削っているからです。

逆に、検証のために「初日の自分」を再現して、いきなり大きい依頼を投げる日も作ってみました。やっぱりダメでした。出力の良し悪しより先に、12ファイルの差分を読むレビュー負荷が重くのしかかって、結局その日は1個も採用できずに終わった。

結論はずっと変わりません。最初の30分は、賢さを試す時間じゃなくて、小さい成功を1個きっちり積んで、相棒の差分を読む目を作る時間です。派手なことは翌日以降にいくらでもできます。今日はまず1個、自分の言葉で説明できる差分を通す。それだけで十分です。

---

最初の30分が終わって、もっと定型作業を楽にしたくなったら、よく使うプロンプトや設定をまとめた教材一覧が次の時短になります。チーム導入や業務自動化まで一気に進めたい段階なら、導入相談で現場に合わせた運用設計から詰めるのが最短です。CLIの最新仕様はAnthropic公式のClaude Codeクイックスタートでも確認できます。