実践Claude Code

「これは単なるツールではない。開発そのものの再定義だ」

Claude Codeとの出会い

2025年の春、私はあるターミナルコマンドを叩きました。

claude

たった一語。それが、私のエンジニア人生を根本から変えることになるとは、そのときはまだ知りませんでした。

当時の私は、CursorでMCPを動かしては「便利だ！」と興奮していました。正直なところ、LLMそのものよりも周辺ツールの進化に目を奪われていたのです。さらに言えば、Claude CodeもGitHub Actionsで一発で動かすことが重要なのだと勘違いしていました。AIコーディングツールの本質を、まるで理解していなかったのです。

Claude Codeを初めて使ったとき、最初の数分で違和感を覚えました。これまでのAIツールとは、何かが根本的に違う。コードを提案するだけではなく、プロジェクト全体を理解し、設計意図を汲み取り、時にはこちらが気づいていない問題点を指摘してくる。まるで、優秀なペアプログラマーがターミナルの向こう側にいるかのような感覚でした。

なぜこの本を書いたのか

Claude Codeを使い始めてしばらく経った頃、私はある確信を持つようになりました。このツールの真価は、単にコードを生成する能力にあるのではなく、コンテキストを理解する能力 にあるのだと。

そして、その能力を最大限に引き出すためには、使い手の側にも「コンテキストを設計する」というスキルが求められます。私はこれを Context Engineering と呼んでいます。

世の中にはClaude Codeの使い方を紹介する記事はたくさんあります。しかし、その本質を体系的にまとめた書籍はまだありませんでした。設計思想も含めて、なぜCLAUDE.mdが重要なのか、どうすればAIとの協働を最大化できるのか、チーム開発でどう活用すべきか。そういった問いに正面から答える本がなかったのです。

だから、自分で書くことにしました。

本書は、私がClaude Codeを実務で使い倒す中で得た知見を、余すところなく詰め込んだ一冊です。成功した手法だけでなく、失敗から学んだことも含めて、できるだけ正直に書いています。

本書の読み方ガイド

本書は大きく4つのパートで構成されています。

第1部：基礎編 (第1章〜第3章) Claude Codeの誕生背景から、ターミナルベースという設計思想の意味、そしてAIネイティブ開発がなぜ今必要とされているのかを解説します。Claude Codeを初めて使う方は、ここから読んでください。

第2部：CLAUDE.md実践編 (第4章〜第7章) 本書の核心部分です。CLAUDE.mdの設計思想、ドキュメントファースト開発、実践パターン、チーム開発での活用法を詳しく解説します。すでにClaude Codeを使っている方にとっても、新しい発見があるはずです。

第3部：実務活用編 (第8章〜第14章) 日常のワークフローから、設計統合、テスト自動化、マルチツール連携、非エンジニアとの協働、ナレッジ自動化、ビジネス活用まで。実際の開発現場でどう使うかを具体的に示します。

第4部：未来編 (第15章〜第19章) 生産性革命の本質、AIエージェントの進化、セキュリティとポリシー、エンジニアという職業の変容、そしてこれからの未来について考察します。

必ずしも最初から順番に読む必要はありません。目次を眺めて、気になった章から読み始めていただいても大丈夫です。ただし、第4章と第5章は本書の土台となる考え方を説明していますので、早めに目を通していただくことをおすすめします。

それでは、Context Engineeringの世界へようこそ。

この続きはKindleで →

「今、何の音楽を聴いてる？」その一言から、すべてが始まった。

Claude Code誕生の名場面 — 偶然のプロトタイプから生まれた4つの設計判断

「今、何の音楽を聴いてる？」

2024年9月のある夜、Anthropicのエンジニア Boris Cherny は、自社APIの動作確認のために簡単なターミナルチャットアプリを書いていました。

最初のツールは bash ただ一つ。公式ドキュメントのサンプルコードをほぼそのまま使った、何の変哲もないプロトタイプです。動作確認のつもりで、彼はこう入力しました。

What music am I listening to?

するとモデルは自発的にAppleScriptを書き、Macの音楽プレーヤーを操作し、再生中の曲名を返しました。

Boris はこのとき「初めてAGIを感じた」と語っています。モデルは指示されていないにもかかわらず、 ツールを使いたがっていた のです。「モデルはツールを使いたがっている。ただそれだけだ」。この発見が、Claude Codeのすべての始まりでした。

Boris Chernyという人物

Claude Codeの誕生を語るには、まず生みの親である Boris Cherny について知る必要があります。

彼はO’Reilly社から出版された『Programming TypeScript』の著者として知られる、型システムとプログラミング言語設計の専門家です。TypeScriptの設計思想には「プログラマーの書き方を変えさせず、型システムのほうを合わせる」という哲学があります。この思想は、のちにClaude Codeの設計原則へと直結していきます。

Anthropicに入社した Boris は、当初はClaude Codeのようなプロダクトを作る予定ではありませんでした。彼がやりたかったのは、自社のAPIをもっと深く理解すること。そのために作った小さなターミナルアプリが、結果として世界で最も使われるAIコーディングエージェントの一つになるとは、本人も予想していなかったはずです。

私がこのエピソードに強く惹かれるのは、自分自身の経験と重なるからです。私もロボット開発に携わっていた時代、フランス人エンジニアと共同で作った小さなプロトタイプが、予想外の方向に発展していった経験があります。最初から壮大な設計図を描くのではなく、 手を動かした先に発見がある という感覚は、エンジニアなら誰しも覚えがあるのではないでしょうか。

社内ハッカソンから生まれた偶然

Claude Codeの誕生は、計画されたプロダクト開発ではありませんでした。Boris がAPIの動作確認用に作ったターミナルアプリは、あくまで個人的な実験ツールです。

しかし、このツールには2つの偶然が重なっていました。

偶然その1: CLIにしたこと

Boris がCLIを選んだ理由は、極めて実用的なものでした。 UIを作らなくてよかったから です。最も安いプロトタイプとしてターミナルを選んだだけ。WebのUIもデスクトップアプリも不要。ただテキストを入出力するだけの、最もシンプルな形を選びました。

この「手抜き」が、結果として最高の設計判断になりました。ターミナルは開発者が最も慣れ親しんだ環境であり、モデルにとっても最も自然にツールを使える環境だったのです。

偶然その2: bashを最初のツールにしたこと

ドキュメントのサンプルコードにあったbashツールをそのまま使ったことで、モデルは自由にコマンドを実行できる環境を手に入れました。これは意図的な設計ではなく、たまたまそうなっただけです。しかし、この自由度がモデルの「ツールを使いたがる」性質と完璧にマッチしました。

このプロトタイプを社内で共有したところ、予想外の反応が返ってきました。Anthropic社内のエンジニアたちが、このツールを 日常的に使い始めた のです。

「誰も求めていなかったが、誰もが必要としていた」

2024年後半の時点で、AIコーディングツールの市場にはすでにCursorやGitHub Copilotといった有力なプレーヤーが存在していました。IDE統合型のAIアシスタントが主流であり、「ターミナルでAIと対話しながらコードを書く」というアプローチを求める声はほとんどありませんでした。

しかし、Claude Codeが社内で急速に広まった事実は、ある重要な真実を示していました。 人は、自分が何を必要としているか、事前にはわからない ということです。

Boris はこれを 「潜在的需要 (Latent Demand)」 という概念で説明しています。エンジニアたちは、すでにターミナルで作業していました。Claude Codeは、その既存のワークフローの中に自然に溶け込むツールだったのです。いつも使っているターミナルで、いつものように作業するだけ。ただし、隣にClaude がいる。

この「既存の行動パターンの延長線上にプロダクトを置く」という発想は、Claude Codeの成功を支えた最も重要な要因の一つです。詳しくは第3章で解説します。

Anthropicの企業文化が生んだもの

Claude Codeの誕生を語る上で、Anthropicという企業の文化を無視することはできません。

Anthropicは「AI安全性」を企業のコアミッションに据えている、業界でもユニークな存在です。AIの能力を最大化することと、その安全性を確保することを同時に追求するという、一見矛盾した目標を掲げています。

この文化が Claude Code にどう影響したかは、いくつかの設計判断に表れています。

ツール実行の権限管理

Claude Codeでは、モデルがファイルを変更したりコマンドを実行したりする際に、ユーザーの承認を求める仕組みが組み込まれています。「AIに自由にやらせる」のではなく、 人間がコントロールを保持する という設計思想です。

Claude wants to run: rm -rf node_modules && npm install

Allow? (y/n)

このプロンプトは、一見すると面倒に思えるかもしれません。しかし、これはAnthropicが重視する「人間の監督(human oversight)」を技術的に実装したものです。

コードを外部に送信しない設計

Claude Codeは、ユーザーのコードベースをベクトルDBに保存したり、外部サーバーにインデックスを構築したりしません。モデルがgrep/globでローカルファイルを直接検索するアーキテクチャは、 セキュリティの観点からも優れた選択 でした。

この判断も、当初は技術的な理由(RAGよりAgentic Searchの方が精度が高かった)から行われたものですが、Anthropicの安全性重視の文化と見事に合致しています。

ASL(AI Safety Level)への意識

Boris 自身、インタビューの中でASL4(再帰的自己改善モデルのリスクレベル)や生物兵器・ゼロデイ悪用といったリスクについて率直に言及しています。AIコーディングツールの開発者がこうしたリスクを公然と議論すること自体、Anthropicの文化を反映しています。

私がClaude Codeを使い始めたとき、最初に感じたのはこの「安全性への配慮」でした。他のAIコーディングツールと比較して、Claude Codeは できることを意図的に制限している部分があります。しかし、それは制約ではなく設計です。自由にやらせるのではなく、人間と協働する。この思想が、結果として実務での信頼性につながっています。

1日20本のプルリクエスト

Claude Codeの有効性を示す最も説得力のあるデータは、Anthropic社内の実績です。

Boris 自身の働き方は、Claude Code導入前後で劇的に変化しました。

• Opus 4.5以降、コードの 100% をClaude Codeで書いている
• IDE(統合開発環境)をアンインストール済み
• 1日に 20本 のプルリクエストを出している

チーム全体でも、以下のような成果が報告されています。

• エンジニアあたりの生産性が 150%向上
• CEOのDarioが予測した「90%のコードがClaudeで書かれる」が実現
• チームによって差はあるが、 70-90% のコードがAI生成

元Googleのエンジニア Steve Yegge は「Anthropicのエンジニアは全盛期Googleの1000倍の生産性」と評しています。これは誇張かもしれませんが、生産性の次元が変わったという感覚は、私自身もClaude Codeを使い込む中で実感しています。

私の場合、少人数の法人で5つのプロジェクトを並行して回しながら、オープンカレッジの受講や新規事業の準備を同時進行しています。こうした「一人で何役もこなす」働き方が可能になったのは、Claude Codeの存在が大きいです。コードを書く時間が劇的に短縮されたことで、 意思決定とレビューに集中 できるようになりました。

6ヶ月前のコードは1行も残っていない

Claude Codeの開発チーム自体が、興味深い開発手法を実践しています。

Boris によると、Claude Codeのコードベースでは 6ヶ月前のコードが1行も残っていない そうです。数週間ごとにツールを追加・削除し、コードの寿命は数ヶ月。常にモデルの進化に合わせてコードを書き直しています。

これは「Scaffolding = 技術的負債」という彼の哲学を反映しています。

モデル周辺のコード(scaffolding)で10-20%の性能改善は可能。だが次のモデルで改善が打ち消される。作るか待つかの常にトレードオフ。

Boris のオフィスには、Rich Sutton の論文 「The Bitter Lesson」 が額装して掲げられているそうです。この論文の核心は「長期的には、計算能力のスケーリングが人間の工夫を凌駕する」というもの。つまり、モデルの周辺に複雑な仕組みを構築するより、 モデル自体の進化に賭ける 方が正しいということです。

この考え方から導かれるのが、Claude Code開発の中核原則です。

今日のモデルではなく、6ヶ月後のモデルのために作る。

今のモデルに最適化してPMF(Product Market Fit)を見つけても、次のモデルで他社に追い越される。だから、モデルの能力の境界を感じ取り、6ヶ月後に解消されるであろうフロンティアに賭ける。

この原則は、Claude Codeを使う私たちにとっても重要な示唆を含んでいます。CLAUDE.mdの書き方も、ワークフローの設計も、「今のモデルの弱点をハックで補う」のではなく、 モデルの進化を前提に、シンプルに保つ ことが大切なのです。

偶然から始まり、必然へ

Claude Codeの誕生は偶然でした。API確認のためのターミナルアプリ、サンプルコードのbashツール、「UIを作るのが面倒だった」というCLI選択。どれも意図されたものではありません。

しかし、その偶然の先に広がった風景は、必然と呼ぶにふさわしいものでした。

• エンジニアはすでにターミナルで働いていた → CLI
• モデルはツールを使いたがっていた → bash
• セキュリティとシンプルさが求められていた → Agentic Search
• 人間のコントロールが必要だった → 承認ベースの権限管理

すべてが、 既にそこにあった需要 に応えるものだったのです。

私がこの本で伝えたいのは、Claude Codeの使い方だけではありません。Claude Codeが生まれた背景にある思想 — 「モデルに逆らうな」「潜在的需要を掘り起こせ」「6ヶ月後のために作れ」 — を理解することで、単なるツール活用を超えた、 AIと共に開発するための原則 が見えてくるはずです。

次章では、「なぜターミナルなのか」という問いをさらに深掘りし、Claude Codeの設計思想の核心に迫ります。

✅ この章のポイント

• Claude Codeは計画された製品ではなく、API動作確認用ツールから偶然生まれた
• 「モデルはツールを使いたがっている」という発見がすべての始まり
• ターミナル・bash・Agentic Searchの選択はすべて「既存の需要」への回答だった
• Anthropicの安全性文化が、人間のコントロールを保持する設計思想につながった
• 「今のモデルではなく、6ヶ月後のモデルのために作る」がClaude Code開発の中核原則

---

参考文献

• Boris Cherny, “Inside Claude Code With Its Creator” — Y Combinator The Light Cone (2026-02-17)

この続きはKindleで →

CLAUDE.mdは「モデルへの命令書」ではない。「プロジェクトの知識ベース」だ。

Boris Chernyの2行

第1章で触れた事実をもう一度確認しましょう。Claude Codeの生みの親 Boris Cherny 本人のCLAUDE.mdは、 たった2行 です。

# CLAUDE.md
- PRを出したらautomergeを有効化
- PRを出したら内部Slackチャンネルに投稿

これだけです。コーディング規約もアーキテクチャの説明も、テストの指針も書かれていません。

一方、Claude Codeの実践者たちは100行以上のCLAUDE.mdを書いています。プロジェクトの技術スタック、コーディング規約、ファイル構成、テスト戦略、デプロイ手順。ありとあらゆる情報を詰め込んだ巨大なCLAUDE.mdです。

この落差は何を意味しているのでしょうか。

なぜBorisは2行で済むのか

答えはシンプルです。Boris のCLAUDE.mdが2行なのは、残りの情報が チーム全体のCLAUDE.md に集約されているからです。

Claude Codeプロジェクトでは、個人のCLAUDE.mdとは別に、リポジトリルートにチーム共有のCLAUDE.mdが存在し、 週に複数回更新 されています。Boris 個人が2行なのは、共有CLAUDE.mdがチームのコンテキストをカバーしているためです。

つまり、「CLAUDE.mdは短くていい」という結論を安易に導くのは危険です。正確に言えば、 個人のCLAUDE.mdは短くてもいいが、プロジェクトのコンテキストはどこかに存在しなければならない のです。

CLAUDE.mdの功罪

CLAUDE.mdは Claude Code の最も革新的な機能の一つですが、同時に 最も誤解されやすい 機能でもあります。書籍『実践Claude Code入門』の著者である吉田真吾氏は、スペック駆動開発(SDD)の文脈でCLAUDE.mdの功罪を分析しています。

功: プロジェクト知識の永続化

CLAUDE.mdの最大の利点は、 /clear しても残る唯一のコンテキスト であることです。

Claude Codeのセッションは一時的です。コンテキストウィンドウがいっぱいになったり、/clear でリセットしたりすると、それまでの会話はすべて消えます。しかし、CLAUDE.mdに書かれた情報は永続的にプロジェクトに残り、次のセッションでも自動的に読み込まれます。

セッション1: 「テストはVitestで書いて」と指示 → 完了
  ↓ /clear
セッション2: 「テストを追加して」→ Vitestのことを覚えていない ❌

CLAUDE.mdに書いておけば:
セッション2: 「テストを追加して」→ CLAUDE.mdからVitest使用を認識 ✅

これはつまり、CLAUDE.mdが 長期記憶 として機能しているということです。

罪: 肥大化問題

しかし、CLAUDE.mdが長期記憶として機能することは、同時に 肥大化の原因 にもなります。

セッション中にClaude が間違えるたびに「次からはこうして」とルールを追加する。プロジェクトが成長するたびに新しいコンテキストを追加する。気づけば、CLAUDE.mdは300行、500行、1000行と膨れ上がっていきます。

肥大化したCLAUDE.mdには、以下の問題があります。

問題1: モデルが指示を無視し始める

LLMには「入力の先頭と末尾に重みが偏る」という特性があります。巨大なCLAUDE.mdの中間部分に書かれた指示は、モデルに無視される可能性が高くなります。

問題2: 矛盾する指示が蓄積する

長期間にわたって追記を繰り返すと、古い指示と新しい指示が矛盾することがあります。「テストはJestで書く」という古い指示と「テストはVitestに移行済み」という新しい指示が共存してしまう。

問題3: コンテキストウィンドウの浪費

CLAUDE.mdはセッション開始時に丸ごと読み込まれます。1000行のCLAUDE.mdは、実際のタスクに使えるコンテキストウィンドウを大きく圧迫します。

Boris 自身、この問題について明確なアドバイスを出しています。

CLAUDE.mdが長くなりすぎたら 削除して最初からやり直せ 。モデルが脱線したら少しずつ戻せ。モデルが進化するたびに、追加する量は減る。

CLAUDE.md 7つの原則

CLAUDE.mdの功罪を踏まえた上で、実践的な運用原則を整理します。コミュニティで蓄積された知見をもとに、7つの原則としてまとめました。

原則1: 小さく・絞って書く

# ✅ 良い例: 必要最小限
このプロジェクトはNext.js 14 App Router + TypeScript + Prisma。
テストはVitest。`npm test` で全テスト実行。
日本語コメント推奨。

# ❌ 悪い例: 情報過多
このプロジェクトはNext.js 14 App Router + TypeScript + Prismaで
構築されたECサイトです。2024年3月に開発を開始し、
チームメンバーは3名で...(延々と続く)

目安は 300行以下、指示は150-200個まで です。/init による自動生成は冗長になりがちなので、生成後に必ず手動で整理しましょう。

原則2: コードスタイルはLint/Formatterに任せる

# ❌ CLAUDE.mdに書くべきでないこと
インデントはスペース2つ。
セミコロンは省略。
文字列はシングルクォート。

# ✅ 代わりにやるべきこと
.prettierrc と .eslintrc を設定しておく
→ CLAUDE.mdには「コードスタイルはLint/Formatterに従う」の1行で十分

これは第2章で解説した「モデルに逆らうな」の実践です。フォーマットの制御はツールに任せ、CLAUDE.mdには モデルに判断してほしいこと だけを書きます。

原則3: 必須3要素

CLAUDE.mdに最低限書くべき内容は3つです。

# CLAUDE.md

## プロジェクト概要
Next.js 14のECサイト。商品管理・注文・決済機能を持つ。

## よく使うコマンド
- `npm run dev` — 開発サーバー起動
- `npm test` — テスト実行
- `npm run build` — ビルド
- `npx prisma migrate dev` — DBマイグレーション

## プロジェクト固有の罠
- If: Prismaスキーマを変更した → Then: `npx prisma generate` を必ず実行
- If: 環境変数を追加した → Then: `.env.example` も更新すること
- If: APIルートを追加した → Then: `src/lib/api-client.ts` の型定義も更新

3番目の「プロジェクト固有の罠」が特に重要です。罠の書き方は、禁止事項だけでなく 「If X, then Y」(トリガー+アクション)形式 で書くと、モデルが正確に理解しやすくなります。

原則4: 段階的開示(Progressive Disclosure)

すべての情報をCLAUDE.mdに書く必要はありません。詳細はサブディレクトリの専用ファイルに分離し、CLAUDE.mdからは参照だけを書きます。

# CLAUDE.md(ルート)
詳細なAPI仕様は docs/api-spec.md を参照。
テスト戦略は docs/testing-strategy.md を参照。
デプロイ手順は docs/deploy.md を参照。

CLAUDE.mdは階層配置 — 作業対象のディレクトリ階層に応じてClaude Codeが必要な情報だけを自動で読み分ける

Claude Codeは、作業対象のディレクトリにあるCLAUDE.mdを自動的に読み込みます。認証機能を触っているときは src/auth/CLAUDE.md が、決済機能を触っているときは src/payment/CLAUDE.md が読み込まれる。 必要な情報を、必要なときだけ 提供する設計です。

原則5: 重要ルールは冒頭に置く

LLMは入力の先頭と末尾に重みを置く傾向があります。最も重要なルールはCLAUDE.mdの 冒頭 に配置しましょう。

# CLAUDE.md

<!-- 最重要ルール：ここに配置 -->
⚠️ 本番DBには絶対に直接接続しない。必ずステージング環境を使用。
⚠️ .envファイルをコミットしない。

## プロジェクト概要
...

原則6: 生きたドキュメントとして育てる

CLAUDE.mdは一度書いたら終わりではありません。Claude が同じミスを繰り返したら、その教訓を1行追加する。プロジェクトの状況が変わったら更新する。 継続的にメンテナンス するドキュメントです。

ただし、追加だけを続けると肥大化します。定期的に見直し、不要になったルールは削除しましょう。Boris が言うように、「長くなりすぎたら削除して最初からやり直す」勇気も必要です。

原則7: スコープを意識する

CLAUDE.mdの配置場所によってスコープが変わります。

~/.claude/CLAUDE.md          # グローバル(全プロジェクト共通)
~/project/CLAUDE.md           # プロジェクトルート
~/project/src/auth/CLAUDE.md  # モジュール固有
~/project/claude.local.md     # 個人設定(.gitignore推奨)

チーム共有のルールはプロジェクトルートのCLAUDE.md に、個人の好みは claude.local.md に分離することで、 共有知識と個人設定を明確に分ける ことができます。

「コンテキストとは何か」の本質論

CLAUDE.mdの設計を深く考えていくと、 「コンテキストとは何か」 という本質的な問いに行き着きます。

コンテキストとは、モデルが正しい判断を下すために必要な情報です。しかし、「必要な情報」は状況によって変わります。

• プロジェクトの全体像を把握したいとき → アーキテクチャの説明
• 特定のバグを修正するとき → そのモジュール固有の罠
• テストを書くとき → テスト戦略とテストツールの設定
• デプロイするとき → デプロイ手順と環境設定

すべての情報を一度に渡すと、コンテキストウィンドウを圧迫し、重要な情報が埋もれます。必要な情報だけを、必要なタイミングで渡す。これが コンテキストエンジニアリング の本質です。

CLAUDE.mdは、このコンテキストエンジニアリングを実践するための仕組みにすぎません。

スペック駆動開発(SDD)への接続

吉田真吾氏が提唱する スペック駆動開発 (Spec-Driven Development) は、CLAUDE.mdの思想をさらに推し進めたアプローチです。

バイブコーディング(「いい感じに作って」と丸投げ)との違いは明確です。

バイブコーディング:
  「ログイン機能を作って」→ AIが自由に実装 → 期待と違う

スペック駆動開発:
  1. 仕様書を書く(何を作るか明確化)
  2. CLAUDE.mdにステアリングポリシーを設定(どう作るか明確化)
  3. AIに実装させる → 仕様に沿った実装
  4. 結果を検証 → 仕様書を更新

SDDの核心は、 「AIへの指示」ではなく「仕様の定義」 に人間の労力を集中させることです。良い仕様書があれば、AIは正しい実装にたどり着けます。

これは、私が日常的に実践しているアプローチでもあります。コードを書く前に、まず仕様書を書く。CLAUDE.mdにプロジェクトの文脈を設定する。その上で Claude Code に実装を任せる。 書くべきは、コードではなく仕様 です。

この考え方は、次章で解説する「ドキュメント・ファースト開発」とも深くつながっています。

実践的なCLAUDE.mdテンプレート

最後に、私が実際に使っているCLAUDE.mdのテンプレートを紹介します。

# CLAUDE.md

## ⚠️ 重要ルール
- 本番環境に直接アクセスしない
- .envファイルをコミットしない
- 破壊的変更を含むマイグレーションは必ず確認を求める

## プロジェクト概要
[プロジェクト名]: [一行説明]

## 技術スタック
- フレームワーク: Next.js 14 (App Router)
- 言語: TypeScript (strict mode)
- DB: PostgreSQL + Prisma
- テスト: Vitest + Testing Library
- CI: GitHub Actions

## コマンド
- `npm run dev` — 開発サーバー
- `npm test` — テスト実行
- `npm run test:watch` — テストウォッチ
- `npm run build` — ビルド

## 罠(If → Then)
- If: 新しいAPIルートを追加 → Then: `src/types/api.ts` の型も更新
- If: Prismaスキーマ変更 → Then: `npx prisma generate` 実行
- If: 環境変数追加 → Then: `.env.example` 更新 + READMEに記載

## 参照
- API仕様: docs/api-spec.md
- テスト戦略: docs/testing.md

50行以内に収まっています。必要な情報は参照先のドキュメントに分離し、CLAUDE.mdは 索引としての役割 に徹しています。

Boris の2行CLAUDE.mdは極端かもしれませんが、方向性は正しい。 書かなくていいことは書かない 。必要な情報は、適切な場所に適切な粒度で配置する。それがCLAUDE.md運用の本質です。

✅ この章のポイント

• Boris Chernyの2行CLAUDE.mdは、チーム共有CLAUDE.mdがカバーしているから成立する
• CLAUDE.mdの肥大化は、指示無視・矛盾蓄積・コンテキスト浪費の3つの問題を引き起こす
• 7つの原則の中核は「小さく絞る」「Lintに任せる」「If-Then形式の罠」
• 段階的開示により、必要な情報を必要なときだけ提供する設計が重要
• CLAUDE.mdは「モデルへの命令書」ではなく「プロジェクトの知識ベース」として設計する

🎯 やってみよう

1. 自分のプロジェクトのCLAUDE.mdを書く: 現在取り組んでいるプロジェクトのCLAUDE.mdを、本章の7つの原則に従って50行以内で書いてみましょう。プロジェクト概要・コマンド・罠(If→Then形式)の3要素を必ず含めてください。
2. 肥大化したCLAUDE.mdのダイエット: もし既にCLAUDE.mdがある場合、本章の原則に照らして不要な記述を削除してみましょう。Lint/Formatterに任せるべき項目、重複する指示、古くなったルールを洗い出し、削除前後の行数を比較してください。

---

参考文献

• Boris Cherny, “Inside Claude Code With Its Creator” — Y Combinator The Light Cone (2026-02-17)
• 吉田真吾, “Claude Codeで実践するスペック駆動開発入門” — SpeakerDeck

この続きはKindleで →