Claude Codeの使い方で最初に決めておきたいこと｜始め方で詰まった経験から作った初回依頼テンプレート

Claude Codeを使い始めたとき、私はいつもの会話AIの延長で考えていました。

自然言語で頼めるなら、質問を投げて、返ってきた答えを見ながら進めればよいと思っていたからです。

ただ、実際に触ってみると、少し感覚が違いました。Claude Codeは質問に答えるだけではなく、ファイルを読み、必要に応じてコマンドを動かし、変更案まで作る道具です。

そこで最初に必要だったのは、うまいプロンプトを書くことよりも、何を目的にして、何ができたら完了とするのかを先に決めることでした。

ここが曖昧なままだと、AIの返答は自然でも、自分が安心して採用できる作業にはなりません。

この記事では、私がClaude Codeの使い方で最初に詰まったところから、現在も使っている初回依頼テンプレート、AGENTS.md、仕様メモまでを、実際の作業の流れに沿って整理します。

Claude Codeを会話AIの延長で使って、最初にずれたこと

Claude Codeを最初に触ったとき、私は「コードについて質問できるAI」という感覚で使い始めました。

普通のチャットAIに聞くように、「このコードはどう思うか」「このエラーは何か」と質問すれば、そのまま開発も進むだろうと思っていました。

もちろん、質問をする使い方でも役に立ちます。ただ、実際に使ってみて便利だと感じたのは、会話のうまさだけではありませんでした。

対象となるファイルを読み、どの変更が必要かを考え、結果をどう確認するかまで、ひとまとまりの作業として持たせられるところです。

私はここに気づくまで、「質問」と「作業依頼」を少し混ぜていました。

質問であれば、AIから返ってきた説明が自然で、内容を理解できればひとまず満足できます。

一方で、コードを変更してもらう作業では、それだけでは足りません。どのファイルを読んだのか、どこを変更したのか、何をもって修正できたと判断したのかが残っていないと、あとから不安になります。

会話AIの延長で頼むと、返事は返ってきても、作業の終わり方が見えにくくなります。

私が最初に詰まった原因は、Claude Codeの性能というより、自分の依頼の単位がまだ会話向けのままだったことでした。

今は、たとえば次のように、調査から確認までを含めて依頼するようにしています。

「この画面の表示崩れの原因を調べてください。関係しそうなファイルを確認し、修正案と変更後の確認方法まで出してください」

ただ「表示崩れを直して」と頼むよりも、何を調べ、どこまで戻してほしいのかが分かりやすくなります。

読む、考える、結果を戻すところまで含めて渡すと、AIに何を任せているのかを私自身も追いやすくなりました。

最初に決めるのは、目的と完了条件です

以前の私は、初回依頼で「対象」「ゴール」「禁止事項」「確認方法」をそろえることを重視していました。

この考え方自体は、今も変わっていません。ただ、実際に運用を続ける中で、項目の優先順位は少し変わりました。

現在、最初に置いているのは目的です。

何を作りたいのか。何を直したいのか。なぜ、その作業が必要なのか。

ここが曖昧だと、AIは何らかの作業を進められても、自分が考えていた方向とは違うところへ進んでしまうことがあります。

次に置くのが、完了条件となるKPIです。

KPIと書くと、大げさな事業指標のように見えるかもしれません。ただ、ここで言うKPIは、作業が終わったと判断するための基準です。

画面の修正であれば、「特定の幅で表示が崩れないこと」。

記事の修正であれば、「古いリンクがなくなり、新しいリンクに置き換わっていること」。

コードであれば、「指定したテストが通ること」。

このように、作業の終点を確認できる形にします。

初回依頼では、目的と完了条件を短く置くだけでも、AIが進める作業と、私が最後に確認する内容がかなりそろいやすくなりました。

一方で、「触ってよい範囲」と「触ってはいけない範囲」は、個人開発の最初の実装段階では、必ずしも細かく決めすぎなくてよいと感じています。

初期実装では、まず作りたいものが形になるかを確認したい場面があるからです。最初から対象範囲を狭くしすぎると、試作の途中で何度も制約を調整することになります。

ただし、実運用やデバッグに入ると話は変わります。

全体を見せたまま曖昧に頼むと、意図していなかった場所まで変更され、確認する範囲が広がることがあります。

商用やプロダクトに近い文脈では、意図しない変更や、気づかないまま残ったバグが問題につながる可能性もあります。

そのため私は、最初からすべての依頼に同じ厳しさを求めるのではなく、作業の段階に応じて範囲の指定を変えるようにしています。

初回依頼テンプレートは今も更新しながら使っています

現在、私がClaude CodeやCodexへ依頼するときは、初回依頼を毎回ゼロから考えないようにしています。

テンプレートというほど堅いものではなくても、最初に渡す項目を決めておくだけで、作業の立ち上がりが楽になります。

現在の最小形は、次のようなものです。

• 目的: 何を達成したいか
• 完了条件: 何が確認できれば終わりか
• 対象: 見てほしいファイル、画面、記事、機能
• 確認方法: テスト、差分、表示、本文確認など
• 必要に応じた制約: 触らない範囲、変えない挙動、保留する判断

このテンプレートは、使い始めた当初から同じ内容ではありません。現在も運用しながら、項目や優先順位を更新しています。

今の優先順位は、最重要が目的、その次が完了条件です。

対象や確認方法、制約も必要ですが、目的と完了条件が曖昧なままでは、ほかの項目を細かく書いても作業全体の方向がそろいません。

反対に、目的と完了条件が明確であれば、短い依頼でも進めやすいことがあります。

ここで大事なのは、最初から完璧なテンプレートを作ることではありません。

項目を細かくしすぎると、依頼を書くこと自体が負担になり、作業を始める前に手が止まってしまいます。

私はまず、目的と完了条件だけは外さないようにしています。そのうえで、必要な制約を作業段階に応じて足していく形です。

個人開発の初期実装であれば、試作を優先してAIに広めに調べてもらうことがあります。

実運用中の修正やデバッグであれば、触ってよい範囲や変更してはいけない挙動を先に絞ります。

AIに任せる範囲を最初から固定するのではなく、今が試作なのか、運用なのかによって切り替える感覚です。

私はこのテンプレートを、AIに正解を出させるために使っているわけではありません。

自分が最後に確認できる形で、作業結果を戻してもらうために使っています。

AIの説明が自然かどうかだけを見るのではなく、最初に決めた完了条件へ近づいているかを確認できることのほうが重要でした。

Best Practicesを読んでも、毎回きれいには進められませんでした

Claude CodeのBest Practicesを読んだとき、調査、設計、実装を分けることや、AIに自己検証させることは、考え方として理解できました。

テストやスクリーンショット、期待する出力を渡し、AI自身が作業結果を確認できるようにするという内容です。

ただ、内容を理解したからといって、実際の作業で毎回きれいに実行できるわけではありませんでした。

急いでいるときは、つい「これを直して」とだけ頼みたくなります。

AIは短い依頼でも何らかの答えを返してくれるため、なおさら雑に頼めてしまいます。

私が実際に引っかかったのは、依頼が短いこと自体ではありませんでした。

問題だったのは、作業の分解がないまま短くなっていることです。

短い依頼でも、目的と完了条件が入っていれば進めやすくなります。

反対に、長い背景説明を書いても、何を確認できれば終わりなのかがなければ、作業の終点はぼやけます。

実際に使ってみると、長く説明することよりも、作業単位を分けて渡すほうが効く場面がありました。

まず調べる。次に方針を出す。内容を確認してから実装する。

このように分けておけば、調査結果を見た段階で「この方針は採用しない」と止められます。

いきなり実装まで進めてもらうより、途中で自分の判断を入れやすくなります。

ここでAIに任せているのは、私の代わりに正しい判断をしてもらうことではありません。

関係するファイルを読み、考えられる候補を出し、検証の手順を用意してもらうことです。

その戻りを見て、どの案を採用するのか、どこまで作業を進めるのかを私が決めます。

Best Practicesをそのまま再現するというより、自分が途中で止められる作業の流れへ置き換えることで、少し使いやすくなりました。

AGENTS.mdは長く書くほどよいわけではありません

AIコーディングを続けていると、毎回同じ前提を説明していることに気づきます。

文章のトーン、触ってよい範囲、禁止する操作、レビューで優先すること、完了条件の確認方法などです。

こうした共通ルールを、毎回の会話とは別の場所へ置くために、私はAGENTS.mdのようなルールファイルを使っています。

ただし、AGENTS.mdは長く書けば書くほどよくなるものではありません。

現在の運用では、AGENTS.mdは毎回プロンプトのコンテキストに含まれます。そのため、内容が長くなるほどトークン消費も増えます。

さらに、細かいルールをすべて書き込むと、AIがどれを優先すればよいのか分かりにくくなる可能性があります。

禁止事項、文体、作業手順、例外、レビュー観点を同じ重さで並べてしまうと、本当に守ってほしいルールが埋もれてしまいます。

指示の数を増やしたからといって、必ずしも作業精度が上がるわけではありません。詳細を書きすぎることで、かえって精度が落ちる可能性もあります。

私の場合は、毎回守りたい核となるルールだけをAGENTS.mdに置き、細かい手順は必要なときに別ファイルへ分けるほうが扱いやすいと感じています。

これは、ルールを減らすというより、置き場所を分ける感覚です。

プロジェクト全体で守る姿勢や、毎回変えたくない前提はAGENTS.mdに置く。

記事ごとの条件や、特定作業だけで必要になる注意事項は、ticketや個別ファイルへ置く。

こうしておくと、AIだけでなく私自身も、何を毎回守るべきなのかを確認しやすくなります。

バイブコーディングでも、戻る場所が必要になりました

バイブコーディングは、頭の中にある「こういうものが欲しい」をAIに渡し、まず形にできるところが魅力です。

私も、最初のたたき台を早く作れる軽さにはかなり助けられています。

ただ、画面が増え、条件が増え、修正を何度も重ねていくと、途中から何を直しているのかが混ざりやすくなります。

最初は一つの画面を作るだけだったのに、保存、並び替え、表示条件、エラー対応と、別の論点が同じ会話へ積み上がっていきます。

その状態になると、AIだけではなく、私自身も最初の前提を見失います。

そこで必要になったのが、重い設計書ではなく、判断に戻るための仕様メモでした。

最初に書くのは、次の程度です。

• 目的
• 対象
• 入力
• 出力
• 完了条件

最初からきれいに文章化しようとすると、今度は仕様を書くこと自体が負担になります。

そのため、私は箇条書きで置くようにしています。

仕様メモがあると、AIから新しい提案が出てきたときに、「便利そうかどうか」だけで判断せず、「今回の目的に合っているか」で見られるようになります。

提案されたものをすべて採用するのではなく、今回入れるものと、見送るものを分けやすくなりました。

勢いよく作る良さを残しながら、途中で別のものへ変わってしまうのを防ぐためのメモです。

仕様メモは、AIのためだけに書いているわけではありません。

むしろ、自分が判断に戻るためのものです。

AIが新しい案を出してきたときや、修正が増えてきたときに、最初の目的から外れていないかを確認する場所として役立ちました。

Claude Codeを始めるときは、上手な指示より先に終点を決める

Claude Codeの使い方で最初に整えたいのは、目的、完了条件、作業単位です。

ここが見えていると、AIに何を頼み、どこから自分で確認するのかが分かりやすくなります。

初回依頼テンプレートやAGENTS.md、仕様メモも、AIに正しい判断を保証してもらうためのものではありません。

AIには、情報の整理、候補出し、関係するファイルの調査、検証手順づくりを手伝ってもらいます。

その結果を見て、採用するかどうかを決めるのは人間側です。

ただ、実装が進んでくると、次に気になるのは安全に使うための境界線です。

どのフォルダまで見せるのか。どのファイルを書き換えてよいのか。どの操作は、人間の確認へ戻すのか。

ここを決めないまま使い続けると、便利さがそのまま確認範囲の広さに変わることがあります。

私にとってClaude Codeの始め方は、「AIに全部任せる方法」ではありませんでした。

AIに作業してもらいながら、自分が内容を確認し、次の判断をできる形で戻してもらう方法を作ることでした。

書き込み範囲やレビューのルールについては、AIコーディングを安全に使うためのガードレール設計で整理しています。

Claude Codeを動かすことには慣れてきたものの、どこまで作業を任せるべきか迷い始めたときに、次の記事として読んでもらう想定です。