Claude Code を使ってみたいけれど、最初に少し身構える人は多いと思います。
普通のチャットAIなら、返ってきた答えを読んで終わりです。Claude Code はそこから一歩進んで、手元のプロジェクトを読み、必要ならファイルを編集し、テストや確認コマンドも実行します。
便利です。けれど、便利なぶんだけ距離が近い。
tomo「聞くだけ」のつもりで開いたら、ファイル名やコマンドが出てきて急に怖くなる。最初はその感覚があっていいです。
この記事では、Claude Code で何ができるのかを整理しながら、初心者がどこで止まって確認すればよいかを説明します。最初から全部を任せる必要はありません。まずは、読ませる、調べさせる、小さく直させる、差分を見る。この順番で始めると、何をしているのかを追いやすくなります。
Claude Code は「全部を丸投げする道具」ではなく、コードを一緒に読み、作業範囲を決め、小さい変更を確認しながら進めるための開発アシスタントとして使うと扱いやすくなります。
Claude Codeは相談相手ではなく作業できる相手
Claude Code を理解するときは、まず「相談だけで終わらない」道具だと考えると分かりやすいです。
コードの意味を聞くだけなら、ふつうのチャットでもできます。Claude Code の強さは、プロジェクトフォルダを前提にして、複数のファイルを読み、必要なファイルを探し、作業の流れまで組み立てられるところにあります。
チャットだけで終わらないところが便利
たとえば、初めて見るプロジェクトで「どこから読めばいいか分からない」とします。
そのとき Claude Code には、次のように頼めます。
このプロジェクトの構成を説明してください。主要なファイルと、最初に読むとよさそうな場所を教えてください。まだファイルは編集しないでください。この依頼なら、ファイルは変わりません。Claude Code はフォルダ内を見て、設定ファイル、入口になりそうなファイル、README、テストなどを手がかりに説明します。
エラー原因の調査にも向いています。
このエラーがどのファイルから起きているか調べてください。原因候補を出してください。まだ修正はしないでください。ここで大事なのは、調査と編集を分けることです。原因を聞く段階では、まだ直させなくて構いません。まず「どこが怪しいのか」を知るだけでも、作業の見通しはかなり良くなります。
手を動かせるから確認が必要になる
Claude Code は、ファイルを読めるだけではありません。許可すれば、ファイル編集やコマンド実行もできます。
README の古い手順を直す。エラーメッセージを分かりやすくする。テストを実行して失敗箇所を見る。こうした作業は、使いどころが合えばかなり助かります。
一方で、手を動かせる道具だからこそ、人間が見る場所もあります。ファイル削除、設定ファイルの上書き、依存パッケージの変更、外部サービスへの書き込み、本番データに関わる操作。ここは流れで許可しないほうがいいです。
削除、上書き、秘密情報、本番環境に関わる操作は、Claude Code が提案しても一度止まってください。対象と理由を読めないまま承認しないことが大事です。
最初に頼みやすい作業
最初から「アプリを作って」「全部直して」と頼むと、変更範囲が広がりやすくなります。
初心者のうちは、ファイルを変えない依頼から始めます。次に、1ファイルか2ファイルで終わる小さな修正へ進む。これくらいの段階で十分です。
プロジェクトの構成を説明してもらう
最初の依頼は、読み取りだけにします。
このプロジェクトの目的を説明してください。主要なファイルを5つまで挙げて、それぞれ何をしているか教えてください。まだファイルは編集しないでください。この聞き方だと、Claude Code はプロジェクト全体をざっと見て、入口を作ってくれます。自分で全部のファイルを開いて追う前に、地図を作る感覚です。
出力してもらう形を指定すると、さらに読みやすくなります。
次の形でまとめてください。- このプロジェクトの目的- 起動や実行に関係しそうなファイル- 画面やAPIに関係しそうなファイル- まだ分からないこと「まだ分からないこと」を入れておくと、Claude Code が読んだ範囲と、まだ推測が混ざっている範囲を分けやすくなります。
エラーの原因だけ調べてもらう
次に試しやすいのは、原因調査です。
このエラーの原因を調べてください。関係しそうなファイル名と、なぜそう考えたかを説明してください。まだ修正はしないでください。ここでも「まだ修正はしないでください」を入れます。
いきなり直させると、原因が違っていたときに差分だけが増えます。先に原因候補を出してもらい、自分が納得できるかを見ます。納得できたら、次の依頼で小さく直せば大丈夫です。
tomo調査だけで止める依頼は、初心者ほど効きます。ファイルが変わらないので、Claude Code の読み方を落ち着いて見られます。
READMEや文言だけ小さく直してもらう
読み取りと調査に慣れたら、小さい編集を頼みます。
README のセットアップ手順だけ、今の package.json に合わせて直してください。変更後に、どこを直したか短く説明してください。または、エラーメッセージの文言だけを直すような依頼も向いています。
この関数のエラーメッセージだけ、初心者にも分かる文に変えてください。仕様や処理の流れは変えないでください。このくらいなら、あとで差分を見たときに追えます。
最初の編集は、派手でなくていいです。むしろ、少し物足りないくらいが安全です。自分が読める差分で終われると、次の依頼がしやすくなります。
任せすぎると危ない作業
Claude Code は便利ですが、何でも同じ温度で任せてよいわけではありません。
ここからは、初心者が特に止まったほうがよい作業を整理します。どれも「絶対に頼んではいけない」という話ではなく、承認前に人間が見るべき作業です。
削除と上書きは止まって見る
削除と上書きは、後から戻しにくいことがあります。
たとえば、「不要なファイルを整理してください」と頼むとします。Claude Code は、使われていなさそうなファイルを探し、削除を提案するかもしれません。けれど、そのファイルが本当に不要かどうかは、プロジェクトの運用や手元にない環境で変わります。
設定ファイルも同じです。package.json、.env.example、ビルド設定、CI設定、デプロイ設定。これらは小さな変更でも影響が広がります。
削除や上書きが出てきたら、次のように聞き返します。
削除または上書きしようとしているファイルを一覧にしてください。それぞれ、なぜ変更が必要なのか説明してください。まだ実行しないでください。説明を読んで、必要だと思えたものだけ進めます。分からないものは、分からないまま許可しないほうがいいです。
コマンド実行は意味を聞いてから許可する
Claude Code は、調査や確認のためにコマンドを使います。
git status や npm test のように見慣れたものなら、意味を判断しやすいです。見慣れないコマンド、長いコマンド、削除や移動が入っていそうなコマンドは、先に説明してもらいます。
そのコマンドは何を確認するものですか？ファイルを変更しますか？外部サービスにアクセスしますか？この一手間で、かなり落ち着いて判断できます。
特に rm、del、Remove-Item、mv、Move-Item、curl、Invoke-WebRequest、認証情報を使うコマンドは、一呼吸置きます。コマンド名が分からなければ、Claude Code に日本語で説明させてから許可します。
秘密情報と本番環境は雑に渡さない
APIキー、トークン、.env、本番DBの接続情報、管理画面の認証情報。このあたりは、初心者でも最初から線を引いておきたい場所です。
エラー調査で必要そうに見えても、.env の中身を丸ごと貼る必要はありません。まずは、キー名だけ、エラー文だけ、接続先を伏せた設定例だけで説明します。
.env の中身は貼りません。エラー文と、関係しそうな環境変数名だけを見て原因候補を出してください。本番環境も同じです。ローカルのファイル修正と、本番DBや外部サービスへの変更は重さが違います。
Claude Code に任せる前に、自分の中で「これはローカルだけの作業か」「外に影響する作業か」を分けます。外に影響するなら、下調べと手順作成までに止めて、人間が最後の実行を持つほうが安全です。
人間が見るべきポイント
Claude Code を使うと、人間の仕事は「全部を手で書くこと」から、「何を頼むか決めること」と「結果を確認すること」に寄ります。
ここを面倒に感じるかもしれません。でも、ここを飛ばすと、あとから差分が読めなくなります。
依頼の範囲を小さくする
悪い依頼は、範囲が広すぎます。
このプロジェクトをいい感じに直してください。この依頼だと、Claude Code は何をもって「いい感じ」なのかを推測します。見た目、設計、README、テスト、依存関係。いろいろ触る理由ができてしまいます。
最初は、目的、対象、やらないことを入れます。
README のセットアップ手順だけを直してください。対象は README.md と package.json の確認だけです。依存パッケージの追加や設定ファイルの変更はしないでください。変更後に差分の要点を説明してください。このくらい書くと、差分が読めるサイズに収まりやすくなります。
編集後は差分を見る
Claude Code に編集させたら、最後は差分を見ます。
Git を使っているなら、まずこれです。
git diffVS Code のソース管理ビューでも構いません。見るポイントは、頼んだ範囲だけ変わっているか、知らないファイルが変わっていないか、削除が混ざっていないかです。
差分を読んで分からないところがあれば、そのまま次の依頼に進まず、説明を求めます。
この差分のうち、私が依頼していない変更がないか確認してください。変更した理由をファイルごとに説明してください。差分を見ないまま次の依頼を重ねると、どの変更が原因で壊れたのか分かりにくくなります。小さく頼んで、小さく確認するほうが戻りやすいです。
複数ファイルなら先に計画だけ出してもらう
複数ファイルにまたがる作業では、編集前に計画だけ出してもらいます。
まず計画だけ出してください。どのファイルを読むか、どのファイルを変更するか、確認方法を説明してください。まだファイルは編集しないでください。計画を見れば、触ってほしくない場所が含まれていないか確認できます。
もし計画が広すぎるなら、ここで狭めます。
今回は変更範囲を小さくしたいです。README と package.json の確認だけに絞って、計画を出し直してください。この段階なら、まだ差分は出ていません。あとから戻すより、編集前に方向を直すほうがずっと軽いです。
最初の30分で試す流れ
初回の目標は、大きな成果物を作ることではありません。
Claude Code がどんなふうにプロジェクトを読み、どう提案し、どのくらいの差分を出すのかを見ることです。最初の30分は、次の流れで十分です。
まず読ませる
作業フォルダで Claude Code を起動したら、最初は読み取りだけを頼みます。
このプロジェクトの目的と主要なファイルを説明してください。まだファイルは編集しないでください。返ってきた説明を読んで、知らないファイル名が出てきたら、そこだけ追加で聞きます。
その中で、最初に読むべきファイルを3つに絞ってください。それぞれ何を見るためのファイルか説明してください。次に調査だけ頼む
次は、ファイルを変えない調査です。
README と package.json を読んで、セットアップ手順にズレがないか確認してください。まだ編集しないでください。この依頼なら、実ファイルに基づいて問題候補を見つけられます。ここでも、まだ直しません。
調査結果に納得できなければ、別の聞き方をします。
確認できた事実と、推測を分けて書いてください。この一文は、読み違いを減らすのに役立ちます。
最後に小さい修正を頼む
最後に、小さな修正を1つだけ頼みます。
README の npm コマンド説明だけ、今の package.json に合わせて直してください。変更後に、差分の要点を短く説明してください。修正が終わったら、git diff や VS Code の差分画面を見ます。
小さい修正で、差分を見て、自分で納得して終われたら十分です。そこまでできれば、次はもう少し大きな依頼に進めます。
tomo最初の成功体験は、小さいほどいいです。「これなら何が変わったか分かる」と思えるサイズで終わると、次の作業が怖くなくなります。
まとめ
Claude Code は、プロジェクトを読み、ファイルを編集し、コマンドを実行できる開発アシスタントです。だから、最初は便利さよりも、止まる場所を決めておくほうが大事です。
最初に見るポイントは、このあたりです。
- 読み取り、原因調査、小さい修正から始める
- 「まだ編集しないでください」を使い、調査と修正を分ける
- 削除、上書き、秘密情報、本番環境に関わる作業は流れで承認しない
- 分からないコマンドは、実行前に意味を聞く
- 編集後は
git diffや VS Code の差分画面を見る - 複数ファイルの変更は、先に計画だけ出してもらう
Claude Code に任せられる作業は、慣れるほど増えていきます。ただ、最初から全部渡す必要はありません。
読ませる。調べさせる。小さく直させる。差分を見る。
この順番で触るだけで、Claude Code が何をしているかを見失いにくくなります。安全に使うというのは、怖がって何もしないことではありません。止まれる場所を残したまま、少しずつ任せることです。
