Claude Codeを触り始めたとき、私は最初、いつものチャットAIの延長で考えていました。自然言語で頼めるなら、質問を投げて、返ってきた答えを見て、また聞けばいい。そんな感覚で入りました。
でも実際には、そこで少しずれました。Claude Codeは会話もできますが、会話だけをする道具ではありません。ファイルを読み、必要ならコマンドを動かし、結果を見て次の作業へ進むための道具です。
最初に詰まったのは、回答の質ではなく「どこまで作業を持たせていいのか」が自分の中で決まっていなかったことでした。便利そうだから任せたい。でも、何を読ませるのか、どこまで書き換えてよいのか、最後に何を確認するのかが曖昧だと、急に怖くなります。
- Claude CodeをチャットAIと同じ感覚で使うと、作業範囲や確認ポイントで詰まりやすいです。
- 最初の依頼では、背景を長く書くより、対象、目的、触ってよい範囲を短く決めるほうが動きやすくなります。
- 使い始めは、便利さよりも「監督しながら進める感覚」に慣れることが大事でした。
Claude Codeを質問する道具として扱うと、最初の一歩で迷いやすい
Claude Codeは会話できますが、使い始めで見るべきなのは会話のうまさだけではありません。むしろ、対象ファイルを読んで、変更候補を考えて、必要な確認を返してくるところに大きな違いがあります。
私は最初、普通のチャットAIに聞くように「このコードどう思う？」に近い頼み方をしていました。すると、返事は返ってきますが、作業としては進みきりません。どのファイルを見るのか、どの不具合を直したいのか、直した後にどう確認するのかが薄いままだったからです。
Claude Codeを使うなら、質問よりも作業単位で渡したほうが合っています。たとえば「この画面の表示崩れの原因を探して、関係しそうなファイルを読み、修正案と影響範囲を出してほしい」のように、読む、考える、戻すところまで含めると動きが見えやすくなります。
最初のBest Practicesを読んだ流れは、こちらに残しています。
この記事では、その後に実際の作業感覚として引っかかったところを、もう少し具体的に整理します。
最初に決めるべきなのは、何を直すかとどこまで触ってよいか
使い始めでいちばん迷ったのは、依頼文のうまさではありませんでした。どこまで触ってよいかを決めずに頼んでしまうと、Claude Codeが動ける範囲と、自分が安心できる範囲の間にズレが出ます。
私の場合、最初に決めると楽になったのは「対象」「ゴール」「禁止事項」「確認方法」の4つでした。対象は、どの画面、どのファイル、どの機能を見るのか。ゴールは、表示を直すのか、エラーを消すのか、読みやすくするのか。禁止事項は、関係ないファイルを触らない、仕様を変えない、公開設定を触らない、のような境界線です。
確認方法も意外と大事でした。「修正して」だけだと、直ったかどうかを最後に自分が探すことになります。先に「変更後にどのコマンドで確認するか」「実行できない場合は理由を説明してほしい」と入れておくと、作業の終わり方がはっきりします。
触ってよい範囲を決めないまま進めると、便利さより不安が先に出ます。これはClaude Codeが悪いというより、人間側の監督ポイントが空白になっている状態です。私はここを決めてから、かなり落ち着いて頼めるようになりました。
長い背景説明より、守りたい条件を短く渡すほうが動きやすい
最初のころは、背景を丁寧に渡さないと失敗すると思って、前提を長く書きすぎることがありました。もちろん文脈は大切です。ただ、作業を始める場面では、長い説明よりも、今回の判断に必要な条件が前に出ているほうが使いやすいと感じました。
Claude Codeへの初回依頼では、「なぜ困っているか」より先に「今回は何を変えたいか、何を変えたくないか」を置くほうが安定しました。たとえば記事制作のルールを直す作業なら、「本文の意味を変えない」「マーカーは既存文の強調に限定する」「保存形式より文章の自然さを優先する」と先に書く。これだけで、作業の向きがかなり変わります。
背景を全部消す必要はありません。むしろ、判断に必要な背景は残したほうがいいです。ただし、長い経緯をそのまま渡すより、作業に効く条件へ変換して渡したほうが、Claude Codeもこちらも迷いにくくなります。
- 今回の作業を一文で言う
- 触ってよい範囲と触ってはいけない範囲を分ける
- 完了前に確認してほしいことを先に出す
文脈をどう渡すかは、コンテキスト管理の記事ともかなりつながります。
長い会話を続けるほど安心、というより、作業単位ごとに必要な文脈を渡し直すほうが合う場面もありました。
便利さを感じたのは、読んで試して差分で戻る流れが見えたとき
私が「これは会話AIの延長ではない」と感じたのは、Claude Codeが対象を読んで、作業し、結果を差分として戻してくる流れが見えたときです。ただ答えをもらうのではなく、こちらの作業場に入って一緒に進めている感覚に近くなりました。
たとえば文章やコードの修正でも、いきなり完成形だけを出されると不安が残ります。でも、どこを見たのか、何を変えたのか、なぜその変更にしたのかが戻ってくると、こちらも確認できます。ここで初めて「任せる」ではなく「監督しながら進める」に近づきました。
この感覚が見えるまでは、私は細かく質問しすぎていました。質問を細かく刻めば安全だと思っていたからです。ただ、細かすぎる質問は、Claude Codeの強みである調査から修正までの流れを切ってしまうこともあります。
任せる単位は大きすぎても怖いですが、小さすぎても作業が進みません。まずは読み取りと提案まで任せる。次に差分を確認して、狭い範囲だけ反映する。この段階分けが、使い始めの私にはちょうどよかったです。
監督役として使うと、見るべきポイントが返答のうまさから変わる
Claude Codeを使っていて、自分の役割も少し変わりました。チャットAIのときは、返ってきた文章の良し悪しを見ることが多かったです。でもClaude Codeでは、文章のうまさだけでなく、作業の進め方を見ます。
私が確認するようになったのは、「対象を読み違えていないか」「関係ない範囲へ広げていないか」「変更理由を説明できるか」「検証結果があるか」です。ここが見えていると、多少やり取りが長くなっても安心できます。逆に、返事がきれいでも、この4つが抜けていると実務では採用しにくいです。
特に怖いのは、意図しない改善です。頼んでいないのに構成を大きく変える、名前を変える、本文の意味を変える、関係ないファイルまで整える。こういう変更は一見よく見えても、あとで差分を追うのが大変になります。
だから私は、Claude Codeを「全部任せる相手」ではなく、「作業を進めてもらいながら、自分が判断点を握る相手」として見るほうが合っていました。この見方に変えると、便利さに振り回されにくくなります。
次は初回依頼テンプレートと、詰まった場面の記録を残したい
今回わかったのは、Claude Codeで詰まる原因の多くが、ツールの性能不足だけではなく、こちらの渡し方にもあるということでした。特に使い始めは、会話AIの癖のまま入るので、作業単位、権限、確認方法を後から考えがちです。
次にやるなら、毎回ゼロから依頼文を考えるのではなく、初回依頼の小さなテンプレートを作りたいです。対象、目的、触ってよい範囲、触ってはいけない範囲、確認方法、最後に出してほしい報告。この6つを埋めるだけでも、かなり迷いが減ると思います。
あわせて、詰まった場面も記録しておきたいです。指示が長すぎたのか、対象が広すぎたのか、検証方法を決めていなかったのか。詰まり方を分類できれば、次に同じ失敗を減らせます。
Claude Codeは、最初から万能に使いこなすものではなく、こちらの仕事の渡し方を少しずつ整えながら育てていく道具だと感じました。質問する道具から、監督しながら前へ進める道具へ。この感覚の切り替えが、使い始めのいちばん大きな壁だったのだと思います。
