プレーンテキストファイル 1 つが、開発者が AI コーディングを使う方法を永久に変えた。
新しいモデルではない。
高額な IDE ではない。
また別の「 AI エージェント」スタートアップでもない。
たった 1 つのファイル：
CLAUDE.md
そしてそれは静かに、GitHub 上で最も急成長している開発者セットアップの 1 つになった。
82,000+ スター。
数千のフォーク。
スタートアップからエンタープライズチームまでのエンジニアが、一晩でプロジェクトにコピーしている。
なぜなら、開発者たちがついにあることに気づいたからだ：
Claude Code が失敗するのは、モデルが弱いからではない。
セッション開始ごとに記憶喪失になるからだ。
Claude Code を開くたびに、それは忘れる：
・ あなたのスタック
・ あなたのアーキテクチャ決定
・ あなたの命名規則
・ あなたのコーディング標準
・ 先週何が既に失敗したか
・ 絶対に変更すべきでないもの
・ なぜあるフレームワークを別のものより選んだか
・ どのファイルに触るのがリスクが高すぎるか
だからモデルは、コンテキストなしで AI がやること、つまり推測をする。
そしてその推測がめちゃくちゃ高くつく。
1 つの関数を直してほしいと頼む。
すると 3 つのファイルを書き換える。
意図的に選んだ変数名を変更する。
正常に動いているコードをリファクタリングする。
あなたのアーキテクチャと互換性のないツールを提案する。
「クリーンアップ」のためにものを削除する。
誰も触れと言っていないフォーマットを変える。
そして次の 1 時間をその「助け」を元に戻すのに費やす。
それが誰も話さない AI コーディングの隠れた税金だ。
あるエンジニアリングマネージャーは、チームが毎週ほぼ 8 時間を失っていると推定した。その内訳は：
→ プロジェクトコンテキストの再説明
→ 許可されていない変更の差し戻し
→ 誤った前提の修正
→ アーキテクチャ判断の再教育
→ スコープクリープの阻止
それは AI の問題ではない。
記憶の問題だ。
そして CLAUDE.md はそれを最もシンプルな方法で修正する。
それは単にプロジェクトのルートに置かれたプレーンテキストファイルだ。
しかし Claude はセッション開始時に自動的にそれを読む。
つまり、あなたの AI はついにカオスではなくコンテキストから始まる。
その違いは大きい。
CLAUDE.md なし：
「 AI アシスタント」
CLAUDE.md あり：
「あなたのプロジェクトを既に知っているエンジニア」
ファイルには通常 3 つのレイヤーが含まれる。
━━━━━━━━━━━━━━━
- デフォルトルール
━━━━━━━━━━━━━━━
このセクションは、あなたの働き方を Claude に教える。
応答の詳細度。
あなたのスタック。
コミュニケーションの仕方。
あなたが既に知っているコンテキストの量。
使用する文体。
やってはいけないこと。
例えば：
→ フィラーフレーズを使わない
→ 回答はタスクの複雑さに比例させる
→ 前提を持つ前に質問する
→ 基本概念を過剰に説明しない
→ 私のコーディングスタイルに完全に合わせる
→ プロジェクトの制約を自動的に守る
小さく聞こえる。
しかし何百ものプロンプトを積み重ねると？
これが膨大な繰り返しを排除する。
ほとんどの開発者は、毎日 20～40 分を AI にコンテキストを再教育することに無意識に費やしている。
毎回。毎セッション。
それをエンジニアリングチーム全体で掛け算する。
つまり毎月数千ドルが、ただ同じことを繰り返すだけに無駄になっている。
━━━━━━━━━━━━━━━
- 動作制御
━━━━━━━━━━━━━━━
これは、開発者が何ヶ月も前に欲しかったと思っているセクションだ。
なぜなら、ここで Claude が「創造的に破壊的」になるのを止めるからだ。
次のようなハードな境界を定義する：
→ タスクに直接関連するファイルだけに触れる
→ 無関係なコードをリファクタリングしない
→ 何かを削除する前に確認する
→ 破壊的なアクションの前に確認する
→ 承認なしに既存の構造を書き換えない
→ 変更点を常に正確に表示する
→ 自動的にデプロイしたりマイグレーションを実行したりしない
このたった 1 つのセクションが、ほとんどの AI コーディングの恐怖話を防ぐ。
もう予期しない書き換えはない。
もうアーキテクチャのずれはない。
もう「これをきれいにしておいたよ」という惨事はない。
AI は予測可能になる。
それがまさにエンジニアが実際に望むものだ。
━━━━━━━━━━━━━━━
- 記憶 + プロジェクトブレイン
━━━━━━━━━━━━━━━
ここからが本当に強力になる。
開発者たちは CLAUDE.md を次のようなファイルと組み合わせ始めた：
MEMORY.md
ERRORS.md
これで Claude は記憶できる：
・ チームが既に下した決定
・ 失敗したアプローチ
・ 却下されたツール
・ 本番インシデント
・ 技術的制約
・ アーキテクチャのトレードオフ
・ クライアント固有のルール
つまり AI は、何ヶ月も前に既に却下したものを推奨しなくなる。
忘れなくなる。
それがすべてを変える。
なぜなら、AI コーディングの本当のボトルネックはもはやコード生成ではないからだ。
それは持続的なコンテキストだ。
そしてほとんどの人はまだこれに気づいていない。
━━━━━━━━━━━━━━━
それをバイラルにした 4 つのルール
━━━━━━━━━━━━━━━
このセットアップは、開発者たちが Andrej Karpathy の AI システムとの作業アプローチに触発された 4 つのシンプルなルールを共有し始めてから爆発的に広まった。
それらは見かけほど基本的だ：
- 前提を持つ前に質問する。
- まず最もシンプルな解決策を使う。
- 無関係なコードに触れない。
- 不確かならすぐに知らせる。
それだけだ。
しかしこの 4 つのルールが、ほとんどの AI コーディングの失敗を解決する。
なぜなら最大のダメージは通常、AI が十分なコンテキストなしに自信満々に行動することから生じるからだ。
最高の結果を得ている開発者は「より多くの AI」を使っているわけではない。
彼らは曖昧さを減らしている。
そしてこれを一度見ると、見なかったことにはできない。
━━━━━━━━━━━━━━━
AI コーディングにおける本当の分断
━━━━━━━━━━━━━━━
今、Claude Code を使う開発者には基本的に 2 つのタイプがいる。
グループ 1：
毎セッションをゼロから始める。
毎日コンテキストを繰り返す。
不要な変更をクリーンアップする。
絶えずスコープクリープと戦う。
AI を一時的なオートコンプリートのように扱う。
グループ 2：
永続的な指示を使う。
動作ルールを固定する。
プロジェクト記憶を維持する。
スコープを厳密に制御する。
AI を長期的なエンジニアリング協力者として扱う。
同じモデル。
まったく異なる結果。
だからこそこのファイルはこれほど速く広まった。
なぜなら Claude が一度以下を持つと：
・ ルール
・ 記憶
・ スタック認識
・ 動作制約
・ プロジェクトコンテキスト
…それはチャットボットのように感じられなくなる。
そしてインフラのように感じられ始める。
━━━━━━━━━━━━━━━
ここから始めよう
━━━━━━━━━━━━━━━
あなたのプロジェクトを開く。
次の名前のファイルを作成する：
CLAUDE.md
そしてまずこれらの 4 つのルールを貼り付ける：
・ 前提を持つ前に質問する
・ まず最もシンプルな解決策
・ 無関係なコードに触れない
・ 不確かさを明示的に知らせる
これだけで、Claude の振る舞いはすぐに改善される。
そして時間をかけて徐々に拡張する：
→ あなたのスタック
→ コーディング標準
→ アーキテクチャルール
→ 禁止アクション
→ 決定ログ
→ プロジェクト記憶
ほとんどの開発者はまだこれをやっていない。
つまり、平均的な AI 支援コーディングとエリート AI 支援コーディングの差は、モデルに関するものではなくなりつつある…
…そして、誰がコンテキストを適切に構造化する方法を知っているかに関するものになりつつある。
ブックマークしておこう。
なぜなら 6 ヶ月後には、永続的な AI プロジェクト記憶は、今日の GitHub リポジトリと同じくらい普通に感じられるようになるだろうから。
