新しいコードをいじらせる前に、まず既存コードの空気を読ませろ。ここを雑にやると、動くけど場違いな差分が増える。名前の付け方も、関数の切り方も、コメントの濃さも、ぜんぶちぐはぐになる。Claude Code でも同じで、「このリポジトリの作法に合わせて」と丸投げするより、見本を渡して真似させたほうがずっと安定する。
Claude Code は、渡した文脈の中でかなり素直に動く。だからこそ、既存コードの一部を「これと同じ調子で」と見せるのが効く。要するに、スタイルを抽象論で説明するのではなく、実例を食わせるやり方だ。ファイル整理や文書作成でも同じで、「このフォルダの命名規則に合わせて」「この報告書の文体に寄せて」と言い換えれば使える。
いちばん簡単なのは、対象のコードと、その周辺の見本を一緒に渡すことだ。たとえば新しい関数を追加したいなら、既にある似た関数を指定して、その流れを踏襲するよう頼む。
このリポジトリでは、既存の `src/users/*` の書き方に合わせてください。
特に次のファイルのスタイルを真似してください。
- `src/users/create-user.ts`
- `src/users/update-user.ts`
命名、エラーハンドリング、コメントの量、早期 return の使い方をそろえてください。
新しい実装を作るときは、まずこの2ファイルの書きぶりを観察してから進めてください。
これだけでも十分効くが、もっと効かせたいなら「何を真似して、何を真似しないか」を切るといい。人間はここを省きがちだが、Claude Code も遠慮なく広く学習してしまう。たとえば、ロジックは似せるが、古い書き方や廃止予定の API まで引き継いでほしくはない。そこは明示する。
次のファイルの作法に合わせて実装してください。
- `src/payments/charge.ts`
- `src/payments/refund.ts`
合わせてほしいもの:
- 関数名の付け方
- エラー時の戻し方
- ログの粒度
- 型の書き方
合わせなくていいもの:
- 古いコメントの言い回し
- 今は使っていないラッパー関数
- 明らかに冗長な分岐
この頼み方のコツは、「似せる対象」を見せることだ。抽象的に「このプロジェクトらしく」とだけ言うと、だいたい薄まる。Claude Code は手元の文脈を材料にするので、見本が少ないと、もっとも無難な中庸に寄る。悪く言うと、どこの現場にもあるような無難コードになる。そこは避けたい。
筆者は昔、似た機能の実装を丸ごと渡さず、「既存のやり方に合わせて」とだけ頼んで手戻りしたことがある。返ってきたコードは動いたが、例外処理だけ妙に別物で、レビューで止まった。結局、既存の似たファイル2本を指定して、差分の基準をはっきり書き直したら一発で収まった。AI に限らないが、作法は言語化しないと伝わらない。人間より素直なぶん、曖昧さの被害もそのまま出る。
もうひとつ大事なのは、見本を多く出しすぎないことだ。似たファイルを10本も投げると、Claude Code は共通点を拾うが、どれを優先すべきかがぼやける。結果として、クセの強い部分まで平均化される。スタイルを真似させたいだけなら、代表例は2〜3本で足りることが多い。むしろ「このファイルを主、こっちは補助」と順位をつけたほうがよい。
主に真似するのは `src/orders/create-order.ts` です。
補助として `src/orders/cancel-order.ts` も見てください。
ただし、コメントの付け方は `create-order.ts` を優先してください。
入力バリデーションの並べ方は `cancel-order.ts` を参考にしてください。
こう書くと、単に「似せる」よりずっとブレにくい。実装の骨格と、細かい作法を分けて渡せるからだ。
既存コードの作法に合わせる場面では、テストや lint の基準も一緒に触れておくと事故が減る。コードだけ似ていても、テストの書き方が違うとレビューで浮く。とくにリポジトリごとに「どこまでを unit test にするか」「どの階層でモックするか」が違うなら、そこは言葉にしたほうがいい。
このプロジェクトのテストの作法に合わせてください。
`tests/billing/*.test.ts` の書き方を基準にして、
- Arrange / Act / Assert の区切り
- モックの置き方
- エラーケースの粒度
をそろえてください。
注意したいのは、作法を真似させるのと、古い癖まで保守させるのは別物だという点だ。ここを混同すると、レガシーな冗長コードまで丁寧に再現される。筆者も一度、既存ファイルにあった不要なネストを「この書き方に合わせて」と雑に頼んで増やしてしまい、後で自分で読むのがだるくなった。真似させるのは、読みやすさや命名の一貫性であって、悪癖ではない。
だから、最後にひと押しだけ入れるといい。
既存コードの雰囲気には合わせてください。
ただし、冗長な分岐、不要な一時変数、意味の薄いコメントは増やさないでください。
読みやすさが落ちるなら、多少の書き換えは許可します。
この一文があるだけで、Claude Code は「似せる」と「劣化コピーする」の境目を越えにくくなる。実務ではここがかなり効く。
スタイルを真似させる頼み方は、コード以外にもそのまま流用できる。たとえば大量の文書をそろえるときも、「この議事録の見出しの切り方に合わせて」「この契約書の用語の統一に合わせて」と見本を渡せばよい。ファイル整理でも、「このフォルダにある命名規則を崩さないで」と言えば、勝手な改名を抑えられる。Claude Code は雑なお願いにも反応するが、丁寧に見本を示したほうが圧倒的に楽だ。既存コードの作法を守らせたいなら、抽象的な指示ではなく、実例を短く、強く、優先順位つきで渡す。これがいちばん手堅い。