Claude Codeを入れてはみたけれど、「思ったより賢くない」と感じている人へ。

ほとんどの場合、原因はツールではなく使い方です。受託開発で毎日使っている立場から、精度と速度が明確に変わる7つの習慣を書きます。

前提：筆者は React / Next.js / TypeScript を中心に受託開発を行う現役エンジニアです。機能や料金は改定が速いので、詳細は公式サイトでご確認ください。

習慣1：作業を始める前に「今の状態」を説明させる

いきなり指示を出す前に、AIに現状を把握させるとその後の精度が変わります。

このプロジェクトの構成を説明して。どんな技術を使っていて、どこに何があるか

これを最初にやると、以降の指示で「どのファイルのことか」が通じるようになります。人間の新人に初日でいきなり実装させないのと同じです。

習慣2：プロジェクトのルールを文書として置いておく

毎回同じ説明を繰り返しているなら、それは文書に書いてAIに読ませるべき情報です。

  • 使っている技術と、その理由
  • 命名規則やディレクトリの方針
  • やってはいけないこと（「このファイルは触らない」など）

多くのAIコーディングツールは、プロジェクト内の指示書を読み込む仕組みを持っています。ここに書いておけば、毎回の説明が不要になります。

特に効くのは「やってはいけないこと」です。禁止事項を先に渡しておくと、事故が明確に減ります。

Claude Codeの場合、プロジェクト直下に CLAUDE.md（または .claude/CLAUDE.md）を置くと、そのプロジェクトを開くたびに読み込まれます。個人用のメモをバージョン管理に含めたくない場合は CLAUDE.local.md を使う方法もあります。ゼロから書くのが面倒なら、/init コマンドでコードベースを解析させ、雛形を自動生成させてから手を加えるほうが早いです（2026年9月6日にClaude Code公式ドキュメントcode.claude.com/docs/en/memoryで確認）。同ドキュメントでは、ファイルを200行程度に収めたほうが指示への追従率が落ちにくいとも説明されています。

習慣3：1指示1目的を守る

最も効果が大きく、最も守られていない習慣です。

悪い例

ログイン機能を作って、デザインも整えて、テストも書いて

良い例

ログイン機能を作って。まずは入力欄と送信ボタンだけでいい

まとめて頼むと、AIが優先順位を自分で決めます。その判断がずれると、全部が微妙にずれます。小さく区切って積むほうが、結果的に速いです。

習慣4：対象を先に絞る

「バグを直して」ではなく「components/Header.tsx のスマホ表示が崩れている。そこだけ直して」。

対象を絞ると、精度が上がるだけでなく費用も下がります。エージェント型のツールは、指示を実行するためにプロジェクト内のファイルを読むからです。読む量が減れば、速くて安くて正確になります。

習慣5：会話が長くなったら区切る

やり取りが長引くほど、AIが抱える前提が増えて濁ります。話題が変わったら新しく始めるのが基本です。

「さっきから直らない」という状態の多くは、前提が汚れているのが原因です。言い方を変えて粘るより、リセットしたほうが早く解決します。

話題自体は変わらないのに、テストだけ別枠で書かせたいといった「派生作業」なら、会話を分けなくても済む場合があります。Claude Codeには今の会話の内容を引き継いだまま副作業を切り出す仕組みがあり、2026年8月時点では新規セッションで標準で有効になっています（2026年9月6日にClaude Code公式ドキュメントcode.claude.com/docs/en/whats-new/2026-w33で確認）。ただし話題そのものが変わったときは、この仕組みではなく素直に新しい会話を始めたほうが前提は汚れません。

習慣6：出力を読んで、動かして、それから次へ

AIの出力をそのまま次へ積み上げると、間違いの上に間違いを積むことになります。しかも本人はどこが原因か分かりません。

  1. 出てきたものを動かす
  2. 期待どおりか自分の目で確認する
  3. 違っていたらどう違ったかを伝える（「動かない」ではなく「押しても何も起きない。エラーは出ていない」）

理解できないコードが出たら「これは何をしている？」と聞いてください。説明できる状態を保つのが、結局いちばん速い進み方です。

習慣7：実装させる前に相談する

いきなり作らせるより、先に方針だけ相談するほうが手戻りが減ります。

◯◯を作りたい。実装方針の候補を2つ挙げて、それぞれの長所と短所を教えて

方針を決めてから実装に入ると、「作ったけど作り直し」がほぼなくなります。設計はまだ人間の仕事です。

やりがちな失敗

やりがち どうするか
エラーを要約して伝える 全文そのまま貼る。行番号もファイル名も手がかり
同じ指示を言い換えて連投 3回で見切り、会話を新規にするか作業を割る
実装方法まで指定する 望む結果を伝え、実現方法はAIに任せる
動いたら完成とする 公開前のセキュリティ確認は自分の責任

指示の書き方そのものは7つのコツに、つまずきの対処は失敗7つにまとめました。

それでも限界はある

正直に書くと、次の場面ではまだ人間が主導する必要があります。

  • 要件が固まっていないとき（何を作るべきかはAIには決められない）
  • 性能や設計の判断が絡むとき（トレードオフの選択）
  • 公開してよいかの最終判断

つまり、AIに任せるほど判断の仕事だけが手元に残ります。楽になるのは書く作業で、確かめる作業は減りません。ここを引き受けられる人が、いちばん恩恵を受けます。

まとめ

  • 最初に現状を説明させる。新人にいきなり実装させないのと同じ。
  • ルールと禁止事項を文書化して読ませる。事故が減る。
  • 1指示1目的・対象を絞る・会話を区切る。この3つで精度も費用も変わる。
  • 実装前に方針を相談すると手戻りが消える。
  • 残るのは判断の仕事。そこが価値になる。

よくある質問

Q. CLAUDE.mdはどこに置けばいいですか？ A. プロジェクトのルートに CLAUDE.md（または .claude/CLAUDE.md）を置くと、そのプロジェクトを開くたびに自動で読み込まれます。自分だけのメモにしたい場合は、バージョン管理に含まれない CLAUDE.local.md を使う方法もあります。

Q. CLAUDE.mdはゼロから自分で書く必要がありますか？ A. いいえ。/init コマンドを実行すると、Claude Codeがコードベースを解析してビルドコマンドやディレクトリ構成などを含む雛形を自動生成します。まずはそれを叩き台にして、AIが自力では気づけない「やってはいけないこと」などを書き足していくほうが早いです。

Q. 会話を区切る以外に、長くなった会話への対処法はありますか？ A. 話題自体は変わらず、テストの追加など「今の会話内容を踏まえた副作業」を切り出したいだけなら、会話を分けなくても済む場合があります。ただし話題そのものが変わったときは、素直に新しい会話を始めるほうが前提は汚れません。

Q. 7つの習慣を一度に全部試すべきですか？ A. 一度に全部は不要です。まずは効果を体感しやすい「1指示1目的を守る」と「対象を先に絞る」の2つから始めると、変化が分かりやすいです。

Q. 習慣を試しても改善しない場合は、どうすればいいですか？ A. まずはエラーメッセージを要約せず全文貼っているか、対象のファイル名まで具体的に指定しているかを見直してください。1〜2週間試しても状況が変わらない場合の判断基準は、バイブコーディングでよくある失敗7つにまとめてあります。

次に読む