「AIコーディングツールを作った本人はどうやって使っているのか」——これほど参考になる情報はない。Claude CodeのクリエイターであるBoris Chernyが明かしたワークフローは、Claude Codeを本格的に使いこなす上での指針になる。
Claude Codeを「試してみた」レベルで使っている人と、「日常的に20〜30PR/日を出す」レベルで使っている人では、何が違うのか。その答えがここにある。
プロジェクトのコーディング規約、アーキテクチャの決定事項、過去のミスパターンをCLAUDE.mdに書き込んでおく。
「Claudeが何か間違えるたびに、その内容をCLAUDE.mdに追記する。次回以降は同じミスをしなくなる」
CLAUDE.mdはClaude Codeがセッション開始時に読み込む設定ファイルだ。ここを育てていくことで、「毎回同じことを説明しなくてもいい」状態になる。チームで使う場合はgitにコミットしておけば全員で共有できる。
いきなりコードを書かせるのではなく、まずプランを生成させてシニアエンジニアの目線でレビューしてから実行に移す。
この「計画→批評→実行」のフローを守るだけで、手戻りが大幅に減る。Claude CodeのShift+Tabでプランモードに切り替えられる。
# プランモードで確認してから実行する流れ
1. タスクを与える（例：「認証周りをJWTに移行して」）
2. Claude Codeがプランを提示
3. 自分でレビューして「この順序は逆じゃないか」「テストを先に書くべき」などフィードバック
4. 修正したプランで実行開始5〜15個のClaude Codeインスタンスを別々のターミナルタブやブラウザウィンドウで同時に動かす。
これにより、順番に処理していた仕事が並列に走り、1日に出せるPR数が桁違いになる。注意点は、インスタンス間で同じファイルを編集させないようにすること。Worktreeを使って作業領域を分離するのがおすすめだ。
# 複数のworktreeで並列作業
git worktree add ../feature-auth feature/auth
git worktree add ../feature-api feature/api
# それぞれのディレクトリでclaude起動コード品質のチェックをサブエージェントに任せる。人間がレビューする前の段階で、AIが自動的にテストを走らせ、品質基準を満たしているか検証するフローを作ることで、レビューの負荷を下げられる。
毎日繰り返す作業はスラッシュコマンドにしてしまう。コマンドは.claude/commands/以下のMarkdownファイルで定義でき、gitにコミットしてチームで共有できる。
# .claude/commands/pr-review.md
このPRをレビューして：
- バグの可能性がある箇所を指摘
- テストが不足している部分を列挙
- セキュリティ上の懸念があれば報告以降は/pr-reviewと入力するだけでこのレビューが走る。
Claude Sonnetなどの軽量モデルで無駄に試行錯誤を繰り返すより、Claude Opus with extended thinkingを使う方が、総合的なコスト・時間が少なくなることが多い〜と思われる。
「モデルが小さいから安い」ではなく「誘導に必要な手間が減る分、大きいモデルの方がトータルで安い」という考え方だ。
各セッションで得た気づきをCLAUDE.mdに反映していく。これを繰り返すことで、Claude Codeの応答品質が徐々に向上していく「複利効果」が得られる。
Boris Chernyの言葉を借りれば：
「Claude Codeを1つのチャットボットとして使うのではなく、スケジュール可能な作業者の群れとして扱うこと」
この視点の転換が、使いこなしの分岐点になる。
CLAUDE.mdを作り、コーディング規約と「やってはいけないこと」を書く.claude/commands/にまとめるこの3つだけで、Claude Codeの使い方は大きく変わるはずだ。