結論から言う。Claude Codeで生産性に差がつくポイントは、指示の出し方じゃない。設定だ。
CLAUDE.mdの書き方、モードの使い分け、ツール制限、コンテキストの渡し方。この4つを整えるだけで、同じAIが別物みたいに動き始める。
自分はClaude Codeを半年以上使っていて、途中から『プロンプトを磨く』より『環境を整える』ほうが圧倒的にリターンが大きいと気づいた。そのきっかけと、具体的に何をどう変えたのかを書いていく。
・Claude Codeに指示を出してるのに、なんか噛み合わない
・毎回同じ説明を繰り返している気がする
・Auto Modeが暴走して余計なファイルまで触る
ここで止まってる人ほど見てほしい。
CLAUDE.mdは『設計書』じゃなくて『空気』を伝えるファイル
Claude Codeには、プロジェクトのルールや文脈を読み込ませるCLAUDE.mdという仕組みがある。Markdownファイルを置いておくだけで、Claude Codeがそれを読んで動いてくれる。
配置には3つの階層がある。
- グローバル:
~/.claude/CLAUDE.md（すべてのプロジェクトに適用） - プロジェクト:
./CLAUDE.md（リポジトリのルートに置く） - ディレクトリ:
./src/CLAUDE.md（特定ディレクトリだけに適用）
ディレクトリレベルのファイルはプロジェクトレベルの設定を引き継ぐから、親のルールを繰り返し書く必要はない。フロントエンドとバックエンドで別のルールにしたい場合なんかに効く。
で、このCLAUDE.mdに何を書くかが問題なんだけど、多くの人がやりがちな失敗がある。
ありがちな失敗3つ。
1つ目、抽象的すぎる。「TypeScriptのベストプラクティスに従ってください」って書いても、Claude Codeは具体的に何をすればいいか分からない。「関数は30行以内」「エラーハンドリングはResult型で統一」みたいに、判断基準を渡す必要がある。
2つ目、長すぎる。500行のルールブックを置いても、コンテキストウィンドウを圧迫するだけ。自分は最初、プロジェクトのアーキテクチャ全体を事細かに書いてた。でもそれをやると、肝心の作業指示に使える文脈が減る。本末転倒だった。
3つ目、実態とズレてる。コードを変えたのにCLAUDE.mdを更新してないパターン。これをやるとClaude Codeが古いルールに従って動くから、むしろ害になる。CLAUDE.mdはコードと一緒にメンテするもの。コードレビューのときにCLAUDE.mdも見る、くらいの感覚がちょうどいい。
自分がCLAUDE.mdに書いて一番効果があったのは、「なぜそうするのか」という理由だった。「テストはpytestで書く」じゃなくて「pytestを使う。unittestより短く書けて、fixtureの再利用がしやすいから」と書くと、Claude Codeがルールの意図を汲んで、書いてないケースでも筋の通った判断をしてくれる。ナビの目的地だけじゃなくて「なぜそこに行くのか」まで伝えるようなもの。
3つのモードを使い分けないと、半分損してる
Claude Codeには用途別に3つのモードがある。これを知らないまま全部デフォルトで使ってる人が意外と多い。
Ask Mode：聞くだけモード
ファイルを変更せず、質問に答えるだけのモード。アーキテクチャの相談、コードレビュー、新しいコードベースの理解に向いている。
自分はプロジェクトに初めて触るとき、まずAsk Modeで「このリポジトリの全体構成を教えて」「このディレクトリの責務は？」と聞いてから作業に入る。いきなりコードを書かせるより、地図を作ってから走るほうが速い。
Auto Mode：自律モード
Claude Codeがファイル編集、コマンド実行、テストまで自律的にやってくれるモード。複数ファイルにまたがるリファクタリングやテスト生成に強い。
ただし、このモードには注意が必要で、Claude Codeが「ついでにこれも直しておきますね」と勝手にスコープを広げることがある。自分も最初、認証まわりだけ修正してほしかったのに、関連するバリデーション処理やエラーメッセージまで書き換えられたことがあった。
対策はシンプルで、指示に境界を明示すること。「この認証フローだけ修正して。既存の認証コードは触らない。デプロイ設定も変えない。正常系と、認証失敗の1ケースだけ対応」と書くだけで、暴走がほぼなくなる。
Preview Mode：確認モード
変更内容を提案するだけで、実際にはファイルを書き換えないモード。本番に近い環境や、セキュリティに関わる変更のときに使う。「まず見せて。それからやる」という二段階にできる。
自分の使い分けはこうだ。調査→Ask。実装→Auto（境界指定付き）。本番系→Preview→確認→実行。この切り替えだけで、やり直しの回数がかなり減った。
ツール制限は『信頼の設計』
Claude Codeにはどのコマンドを実行させるか、どのディレクトリを編集させるかを制限する仕組みがある。
実行を許可するコマンドと、ブロックするコマンドを指定できる。たとえばgit、npm、dockerは許可するけど、rm -rf /やgit push --forceはブロックする、みたいな設定ができる。
ファイル編集も同様で、src/とtests/は触っていいけど、本番の秘密鍵が入ったディレクトリやインフラ設定は触れないようにできる。
これ、面倒に見えるけど設定する価値がある。制限が緩すぎると事故のリスクがあるし、厳しすぎるとClaude Codeが何もできなくなる。自分は最初、制限をほとんどかけずに使っていて、Claude Codeが意図せず設定ファイルを上書きしたことがある。それ以来、「触っていい場所」を明示的に決めるようにした。
この設計思想は、チームに新しいメンバーが入ったときと同じだと思う。信頼できる範囲を先に決めておけば、任せる側も任される側も安心して動ける。
プロンプトの『型』を知ると、指示の精度が上がる
設定を整えた上で、プロンプトの書き方もやっぱり大事だ。ただし「うまい文章を書く」という話じゃなくて、型を使うという話。
場所＋症状＋方針を1セットで渡す
弱い指示：「バグを直して」
強い指示：「src/api/users.tsの42行目でnull pointer exceptionが出る。user.organizationがundefinedのときに発生する。防御的なnullチェックよりも根本原因の修正を優先して」
場所、症状、方針の3点セット。これだけで精度がまるで違う。自分もこの型を使い始めてから、Claude Codeの1回目の出力で「これでいける」と思えることが増えた。試した。通った。速い。もう曖昧な指示には戻れない。
思考プロセスを要求する
設計判断のような複雑な問題には、「ステップバイステップで考えて」と明示的に頼む。「現在の負荷パターン、今後の成長見込み、チームの規模、運用の複雑さを考慮して、アーキテクチャの選択肢を検討して」のように、考慮すべき軸を並べると精度がさらに上がる。
境界を指定する
Auto Modeの話でも触れたけど、境界の指定はプロンプトの技術としても重要。「この機能だけ実装して。既存コードは変えない。デプロイ設定も触らない。対応するのは正常系と認証エラーの2パターンだけ」と書くと、スコープが明確になってClaude Codeが迷わない。
コンテキストの渡し方で、作業の「持久力」が決まる
Claude Codeのコンテキストウィンドウは有限だ。ここにどれだけ効率よく情報を詰められるかで、長いタスクを最後まで走りきれるかが決まる。
よくある失敗：50ファイルの中身を全部読み込ませる。これをやるとコンテキストが埋まって、肝心の作業中に文脈が抜け落ちる。
うまいやり方：関連する関数だけを行番号付きで渡す。型定義のうち必要な部分だけ抜き出す。アーキテクチャの制約を簡潔に伝える。
自分が実践しているのは段階的な開示だ。まず全体像をざっくり伝えて、次に対象モジュールの詳細、最後に関数レベルの具体的な作業指示。一気に全部渡すんじゃなくて、必要なタイミングで必要な情報を出していく。
それから、長いタスクの途中で「ここまでの進捗と残りの作業をまとめて。決定した方針とその理由も含めて」と頼むと、Claude Codeが会話履歴を圧縮してくれる。これで長時間の作業でも文脈が失われにくくなる。
ぶっちゃけ最初はこの「コンテキスト管理」の概念自体がピンとこなかった。でも使っていくうちに、Claude Codeが途中で的外れな回答を始める原因のほとんどがこれだと気づいた。性能不足じゃなくて、情報の渡しすぎ。
設定は育てるもの。一度決めて終わりじゃない
CLAUDE.mdもモードの使い分けもツール制限も、最初から完璧にする必要はない。自分も半年かけて少しずつ調整してきた。
大事なのは定期的に見直すこと。CLAUDE.mdの内容は今のコードと合っているか。ツール制限は厳しすぎないか、緩すぎないか。Auto Modeで余計な変更をされたパターンはないか。
こういう振り返りを月1回でもやると、Claude Codeとの「噛み合い」がじわじわ良くなっていく。設定って、一回書いて放置するものじゃなくて、コードと一緒に育てていくものだと思う。
これ、半年前に知ってたら最初の3ヶ月の試行錯誤は半分で済んだはずだ。
まとめ
- Claude Codeの生産性を上げる鍵は、プロンプトの巧さより「設定の質」
- CLAUDE.md、モード使い分け、ツール制限、コンテキスト管理の4つを整えるだけで別物になる
- 設定はコードと一緒に育てるもの。月1回の見直しで噛み合いが変わる
フリーランスエンジニアにおすすめのツール
AI開発環境を整えるなら、安定したサーバーは欠かせない。
カゴヤ・ジャパン — 法人利用実績も多く、開発用VPSやクラウドを手堅く運用したい人向け。
Qドメイン — 独自ドメインをサクッと取りたいときに。ブログやポートフォリオ用に。
※この記事にはアフィリエイトリンクを含みます
コメント