Claude Code初心者が最初の30分でやること7選 | 失敗しない始め方
Claude Codeを入れた直後にやるべき7つの手順を、コピペできる設定例つきで解説。初心者がハマりやすい失敗例と、無料PDF・テンプレート活用までまとめました。
Claude Code を入れたばかりの人が最初に困るのは、機能不足ではなく「何から触ればいいかわからない」ことです。私も最初の頃は、いきなり大きいリファクタリングを投げて雑な差分を出させたり、権限設定を後回しにして不要な確認ダイアログに疲れたりしました。
いま振り返ると、最初の30分でやることはかなり絞れます。この記事では、導入直後にやるべきことを7つに絞って、コピペできる設定ファイル、最初に試すプロンプト、失敗例までまとめます。
Claude Code 自体のインストールがまだなら、先にClaude Code入門ガイドを見てから戻ってきてください。料金の考え方を先に知りたい人はClaude Codeの料金プランと活用対効果も合わせてどうぞ。CLIの基本仕様や最新の使い方は、必要に応じてAnthropic公式のClaude Codeドキュメントでも確認できます。
この記事のゴール
30分後に次の状態になっていれば成功です。
- どのプロジェクトで Claude Code を動かすか決まっている
CLAUDE.mdと権限設定の最低限が入っている- 1つの小さなタスクを安全に完了できている
- 無料PDFやテンプレートを使うべきタイミングがわかっている
1. 練習用の小さいリポジトリを1つ決める
最初から本番案件や巨大モノレポに入ると、Claude Code の良さより怖さが先に来ます。最初は次のどれかを選ぶのが無難です。
- 個人開発の小さい Next.js / React リポジトリ
- テストがすでにある業務外の検証リポジトリ
- 失敗しても困らないサンプルアプリ
私は最初、数千ファイルある業務リポジトリで始めて失敗しました。Claude Code が悪いのではなく、こちらが「どこまで読ませるか」を決めていなかっただけです。最初は100〜300ファイルくらいのプロジェクトがちょうどいいです。
失敗例
いきなり複数サービスにまたがる本番運用リポジトリを開くと、調査対象が広すぎて、良い出力か悪い出力かの判断も難しくなります。最初は「直す場所を自分で説明できる」小ささを優先してください。
2. CLAUDE.md を5分で作る
Claude Code は、毎回の指示が曖昧だと「親切だけど遠回り」になりがちです。そこで効くのが CLAUDE.md です。要するに、このリポジトリで守るべき開発ルールを最初に渡しておくメモです。
まずは /init を実行して雛形を作り、そのあと最低限だけ追記してください。
claude
/init
最初の版はこの程度で十分です。
# Project Rules
- TypeScript の型エラーを残さない
- 既存の命名規則に合わせる
- 変更前に関連ファイルを読んでから編集する
- テストがある場合は変更後に必ず実行する
- 大きい変更は小さいステップに分ける
失敗例
CLAUDE.md を空のまま使うと、毎回「このプロジェクトでは named export を使います」「テストは Vitest です」などを説明する羽目になります。結果として、1回ごとの作業はできても、2回目以降の速度が落ちます。
より詳しく整備したい場合は、CLAUDE.mdの書き方ガイドをあとで読むと深掘りできます。
3. 権限を最初に絞る
初心者が最初にやりがちな失敗が、「なんとなく全部許可する」ことです。これは後で怖くなります。逆に厳しすぎると何も進みません。最初はよく使う読み取り系とテストだけ許可するのが扱いやすいです。
たとえば .claude/settings.json はこう始めれば十分です。
{
"permissions": {
"allow": [
"Read",
"Bash(npm test)",
"Bash(npm run lint)",
"Bash(npx tsc --noEmit)"
]
}
}
なぜこれでいいのか
Readがあれば関連ファイルを調べられるnpm testとlintがあれば変更確認ができる- 破壊的なコマンドはまだ明示的に許可しない
権限設計を後回しにすると、承認ダイアログを反射で押す癖がつきます。安全運用を先に固めたい人はClaude Code権限設定ガイドも役立ちます。
4. 最初の依頼は「小さく、ファイルを限定して」出す
最初の1タスクは、成果が見えやすくて、やり直しも簡単なものを選びます。おすすめは次の3つです。
- エラーメッセージの原因調査
- 既存コンポーネントへの小さなUI修正
- テスト追加
悪い依頼と良い依頼の差はかなり大きいです。
悪い依頼:
このアプリを改善して
良い依頼:
src/components/ProfileCard.tsx と src/lib/formatDate.ts を読んで、
プロフィールカードの日付表示が崩れる原因を調べて。
必要なら修正案を出し、最後に変更理由を3行でまとめて。
ここで重要なのは、対象ファイル・目的・出力形式をセットで伝えることです。これだけで暴走率がかなり下がります。
5. まず1回、レビュー用途でも使う
Claude Code はコードを書く用途だけでなく、レビュー用途でもかなり強いです。最初から実装を任せるのが不安なら、まずは読ませて要約させるだけで十分価値があります。
たとえばこんな依頼は安全で効果が高いです。
src/features/billing 配下を読んで、
1. この機能の責務
2. 危ない分岐
3. テスト不足の箇所
を箇条書きでまとめて
私が実務でよく使うのは、実装前に「地雷の洗い出し」をさせる使い方です。これだけで、自分が把握していなかった依存関係に早めに気づけます。
6. コピペで使える最初の3プロンプト
ここはそのまま使って大丈夫です。
プロンプト1: バグ調査
次の不具合を調べてください。
- 症状: 保存後に一覧へ戻ると日付が "Invalid Date" になる
- 調査対象: src/features/orders/ と src/lib/date.ts
- やってほしいこと:
1. 原因候補を絞る
2. 最小修正案を出す
3. 影響しそうな箇所を2つ挙げる
プロンプト2: 小さな改善
src/components/Header.tsx を読んで、
モバイルでCTAボタンが2行に崩れないように修正して。
変更後は、なぜそのCSSにしたかも説明して。
プロンプト3: テスト追加
src/lib/calcPrice.ts を読んで、
境界値を中心に Vitest のテストを追加して。
想定ケースを先に列挙してから実装して。
この3つで、調査・実装・検証の基本がひと通り回せます。
7. 30分でやらないほうがいいこと
最初に避けたほうがいいものもあります。
- 大規模リファクタリング
- 本番DBや本番インフラが絡む作業
- 「全部読んで改善して」のような広すぎる依頼
- テストがないのに大量変更を任せること
典型的な失敗例 1: いきなり全部任せる
このリポジトリ全体をモダン化して
これを最初にやると、Claude Code の能力検証ではなく、単なる賭けになります。広い依頼は、使い慣れてからで十分です。
典型的な失敗例 2: エラー文を貼らずに聞く
npm run build が落ちる。直して
これでは調査の入口が足りません。少なくともログの末尾、対象ファイル、直前の変更内容は渡してください。エラー解読を先に楽にしたいなら、記事末の無料PDFより一段詳しい内容をまとめた教材も後述のテンプレート集と相性がいいです。
実務での使い分け
最初の30分が終わったら、その後は次の順で広げると失敗しにくいです。
- 調査とレビュー
- 小さい修正
- テスト追加
- 新規実装
- 自動化や運用設計
特に、繰り返し使う依頼はテンプレート化すると一気に楽になります。毎回ゼロから考えたくない人は、記事下に置いている note のテンプレート集がそのまま時短になります。
8. 次の一手は「無料PDF → テンプレート → 相談」で十分
初心者がここで迷いやすいのは、「次に何へ課金すればいいのか」「まだ相談するほどでもないのでは」という点です。結論から言うと、次の順で進めれば十分です。
- まずは記事下の無料PDFで、基本コマンドと最初の依頼文を手元に置く
- 2回目以降も毎回プロンプトを考えるのが面倒なら、教材一覧からテンプレートや設定ガイドを見る
- チーム導入や業務自動化まで進めたい段階なら、導入相談で現場に合わせた運用設計を詰める
この順番にしている理由はシンプルです。いきなり相談に進むより、まずは無料で基本を固めたほうが会話が早いからです。一方で、「自分だけでは権限設計やレビュー運用が不安」「社内へどう展開するか整理できない」という段階なら、相談のほうが早く元が取れることもあります。
この記事の手順を実際に試した結果
この流れで、最初の30分を「調査1件、UI修正1件、テスト追加1件」の3ステップに絞って試すと、途中で権限や指示の出し方に迷う回数がかなり減りました。逆に、最初から大きい依頼を投げた日は、結果の良し悪しよりもレビュー負荷の高さが先に来ました。初心者ほど、派手な自動化より小さい成功体験を3回積むほうが定着しやすいです。
迷ったらこの順で進める
「結局、今日どこまでやればいいのか」を一文で言うなら次の順です。
- 小さいリポジトリを開く
CLAUDE.mdを作る- 権限を絞る
- 小さい依頼を1つ通す
- うまくいったプロンプトを保存する
ここまでできれば、もう“触ってみただけ”の状態は卒業です。
次に読むべき記事
- まず基本操作を固める: Claude Code入門ガイド
- 指示の質を上げる: プロンプト改善の5つのコツ
- ルールファイルを整える: CLAUDE.mdの書き方ガイド
- コスト感を把握する: Claude Codeの料金プランと活用対効果
まとめ
Claude Code 初心者が最初の30分でやるべきことは、難しいことではありません。環境を整えて、小さい成功体験を1つ作ることです。ここを飛ばして大きい仕事を任せると、「便利そうだけど怖い」で終わります。逆にここを丁寧にやると、そのあと調査、レビュー、実装、自動化まで自然に広げられます。
まずは記事下の無料PDFで基本コマンドを手元に置いてください。すぐ実務で使う定型プロンプトが欲しいなら教材一覧や note のテンプレート集が次の一手です。チーム導入や業務自動化まで一気に進めたい場合は、導入相談で設計から一緒に詰めるのが最短です。
無料PDF: Claude Code はじめてのチートシート
まずは無料PDFで基本コマンドと最初の使い方をまとめて確認してください。登録後はそのままテンプレート集や導入相談にも進めます。
スパムは送りません。登録情報は厳重に管理します。
Claude Codeを仕事で使える形にしませんか?
無料PDFで基礎を固めたあと、すぐ使えるテンプレート集で試し、必要なら業務自動化や導入相談まで進められます。
この記事を書いた人
Masa
現役DX室長|Claude Code でゼロから多言語AI技術メディア運営中。実務直結の自動化、AI開発相談・研修受付中。
関連書籍・参考図書
この記事のテーマに関連する書籍を楽天ブックスで探せます。
※ 当サイトは楽天市場のアフィリエイトプログラムに参加しています。上記リンクから商品をご購入いただくと、運営者に紹介料が支払われる場合があります。
関連記事
Claude Codeで既存コードを読む最初のプロンプト7選 | 初心者が迷わない始め方
Claude Codeを既存プロジェクトで使い始めるときに、そのまま貼れる最初のプロンプト7個を紹介。失敗例、質問の切り分け方、無料PDFとテンプレートの使い分けまでまとめました。
Claude Codeの料金プランと費用対効果の考え方
Claude Codeの料金体系をわかりやすく解説。各プランの違い、コスト最適化の方法、費用対効果の考え方を具体的な数字とともに紹介します。
非エンジニアでも使えるClaude Code入門:ノーコード的活用法
プログラミング経験がなくてもClaude Codeを活用する方法を解説。ターミナルの基本操作からWebサイト作成まで、非エンジニア向けに丁寧にガイド。