Claude Codeを作った本人が「自分はこう使っている」と公開した瞬間、世界中の開発者がそのファイルを参照しはじめた。

注目を集めたのはコードの出来映えではなく、1つのMarkdownファイルだった。CLAUDE.mdと呼ばれる、わずか100行の設定ファイル。多くの開発者が500〜1,000行のファイルを用意する中、Claude Code作者本人のファイルはその10分の1で、それでも最高の成果を出すという。

この記事では次のポイントを解説する。

  • CLAUDE.mdがAIのワークフローにどう機能するか
  • Boris ChernyのCLAUDE.mdに書かれた6つのルールの中身
  • 自己改善ループとサブエージェント戦略の使い方
  • 10〜15セッション同時起動のパワーユーザー運用術

https://howborisusesclaudecode.com/

CLAUDE.mdとは何か

CLAUDE.mdはプロジェクトのルートに置くMarkdownファイルで、Claude Codeがセッション開始時に自動で読み込む。いわばAIへの「永続的な指示書」だ。

セッションをまたぐとAIはコンテキストをリセットする。CLAUDE.mdはその問題を解決する。毎回手動で説明しなくても、プロジェクトのルール、チームの慣習、過去の失敗から学んだ知見を毎回読み込ませられる。

Boris Chernyが語る原則はシンプルだ。「Claudeが何かを間違えたら、CLAUDE.mdに書き足して二度と繰り返させない」。チームのCLAUDE.mdはGitで管理され、週に複数回更新される。

Boris Chernyとは

Boris ChernyはAnthropicのStaff Engineerであり、Claude Codeの作者だ。TypeScriptの型システムにも深く関わってきた開発者で、2026年1月に自身のClaude Codeワークフロー全体をX上で公開した。「Mastering Claude Code in 30 minutes」と題したYouTubeトークでも同様の内容を解説している（nibzard.com による書き起こしあり）。

CLAUDE.mdの構造と6つのルール

BorisのCLAUDE.mdは3つのセクションに分かれている。最初のセクション「ワークフロー設計」に、開発者が特に参照する6つのルールがある。

1. プランモードをデフォルトにする

3ステップ以上の非自明なタスクは必ずプランモードから始める。途中で詰まったら、コーディングを続けるのではなく立ち止まって計画を立て直す。仕様を詳細に書くことで、あいまいさを事前につぶす。

2. サブエージェントを積極的に使う

サブエージェントはメインのコンテキストウィンドウを守るために使う。調査、探索、並列分析はサブエージェントに任せ、複雑な問題には計算リソースを多く投入する。サブエージェントごとにタスクを1つに絞るのがポイントだ。

3. 自己改善ループを回す

修正が発生するたびに、tasks/lessons.md を更新させる。同じミスが起きないルールを書かせ、ミス率が下がるまで繰り返す。Borisはセッション開始時にこのレッスンファイルを参照することを習慣にしている。時間が経つほどClaude は特定のプロジェクトに適応していく。

4. 完了前に必ず検証する

「スタッフエンジニアならこれを承認するか？」と自問する。テストを走らせ、ログを確認し、正しく動いていることを示してから完了とする。証明なしに完了とみなさない、というのが鉄則だ。

5. 洗練を求める（ただしやりすぎない）

単純な修正にはスキップしていい。非自明な変更には「もっとエレガントな方法があるか？」と一度立ち止まる。ハックに見えるコードには「今の知識を踏まえて、洗練された実装に作り直して」と一言で指示できる。

6. バグ修正は自律的に行う

バグレポートを渡したら、指示を待たずに修正まで進む。ログ、エラー、失敗したテストを手がかりに解決する。Borisが実際に使うプロンプトは「Fix.」の1単語だ。

タスク管理の6ステップループ

ワークフローセクションに続き、タスク管理のループが定義されている。

  1. tasks/todo.md にチェックリスト形式で計画を書く
  2. 実装前に計画を確認する
  3. 完了したアイテムをマークしていく
  4. 各ステップで変更内容の概要を説明する
  5. tasks/todo.md にレビューセクションを追加する
  6. 修正後に tasks/lessons.md を更新する

6番目が核心だ。Claudeが間違いを犯して修正されるたびに、同じ間違いを防ぐルールを自分で書かせる。これを繰り返すと、Claudeはプロジェクト固有の知識を蓄積していく。

3つのコア原則

ファイルの末尾には3つの原則がある。短いが、BorisのClaude Codeに対する哲学をそのまま示している。

  • Simplicity First — 変更は最小のコードで。追加するより削除できるなら削除する
  • No Laziness — 根本原因を探す。一時的な修正はしない。シニア開発者の水準を保つ
  • Minimal Impact — 必要なものだけを触る。修正しながら別のバグを作らない

パワーユーザーの運用術

Borisは常時10〜15のClaude Codeセッションを同時に走らせている。ターミナルのタブに5本、Webに5〜10本、時にはスマートフォンからも起動する。各セッションにはGitのworktreeを割り当て、変更が衝突しないようにしている。

プロンプトは細かい手順指示をしない。結果を伝えて方法はClaudeに任せる。実際に使っているプロンプトの例は次のとおりだ。

  • 「この変更について厳しく問い詰めてくれ。テストに合格するまでPRを出すな」
  • 「これが動いていることを証明して」
  • 「知っていることをすべて踏まえて、最初から洗練された実装を作り直して」

CLAUDE.mdの4つの配置レイヤー

CLAUDE.mdは1か所だけでなく、4つのレイヤーで重ねて管理できる。

ファイルパス 適用範囲
/<enterprise root>/CLAUDE.md 組織全体（企業ポリシー）
~/.claude/CLAUDE.md 個人の全プロジェクト
<project-root>/CLAUDE.md プロジェクト固有（Git管理）
<project-root>/CLAUDE.local.md ローカルのみ（Gitに含めない）

プロジェクトルートのCLAUDE.mdはGitにコミットしてチームで共有する。ローカルファイルは、外部に出せない認証情報や一時的な設定を書く場所だ。

100行に絞る理由は明快だ。コンテキストウィンドウにも上限があり、読み込ませる情報が多いほどメインの作業に使えるトークンが減る。Borisの言葉を借りると「すべての行が実際の問題から生まれている」。それが、短くても機能する理由だ。