ダメな開発者だからではありません。最初からメンタルモデルが間違っているからです。
多くの人はClaude Codeを開いて、賢い補完（autocomplete）のように扱います。関数を書かせます。バグを直させます。コンポーネントを生成させます。すると、なぜ出力をそんなに修正する必要があるのか、なぜ数回のセッションで文脈が失われるのか、なぜコラボレーションというより世話を焼いているように感じるのかが分からなくなります。
問題はClaude Codeではありません。あなたが与えた仕事内容（ジョブディスクリプション）です。
間違ったメンタルモデル
Claude Codeをコーディングアシスタントとして使うとき、あなたはそれに「速いタイプ係」をお願いしています。コードを書かせ、あなたがそれをレビューして、直して、次に進む。
それは機能します。自分で全部書くより速いです。でも、レバレッジ（効果が大きくなるポイント）はそこではありません。
レバレッジは、Claude Codeをタイプ係ではなく請負業者（コントラクター）として扱うことです。つまり、適切なブリーフィングを渡せば、バックエンド、フロントエンド、テスト、ドキュメントまで、機能をエンドツーエンドで実行できる請負業者です。
タイプ係と請負業者の違いは、スキルではありません。文脈（コンテキスト）です。
Claude Codeが本当に必要としているもの
Claude Codeには、セッション間の永続的なメモリがありません。新しい会話を始めるたびに、完全に最初からスタートします。あなたのアーキテクチャ上の判断、命名規則、既知のバグ、前回どこまでやったかは分かりません。
多くの人は、毎回のセッションの最初にすべてを改めて説明することで解決しようとします。それは間違った解決策です。遅いです。不完全です。そして、いつも大事な何かを忘れます。
正しい解決策は、あなたに代わって説明をやり直してくれる「単一のファイル」です。
私はそれをCLAUDE.mdと呼んでいます。すべてのプロジェクトのルートに置きます。Claude Codeは毎回、セッション開始時に自動的にそれを読み込みます。
そこには4つのセクションがあります。
Current State（現在の状態） — 動いていること、壊れていること、どこから再開するか。毎回のセッションの終わりに更新します。
Architecture Decisions（アーキテクチャの意思決定） — 何を作ったかではなく、なぜそうしたのかです。たとえば「メモリ内セッションを使っています。永続化レイヤーを追加すると、ホムラボユーザー向けのDocker設定が複雑になるからです」。そうでなければあなたの頭の中だけに留まっていたであろう推論です。
Conventions（規約） — Claude Codeが必ず従わなければならない具体的なルール。「きれいなコードを書け」ではありません。役に立ちません。代わりに、実際のデバッグセッションで学んだ正確なパターンを記述します。ドキュメントなしで再発見しようとすると30分かかるようなことです。
Known Issues（既知の課題） — 既に分かっているバグや制約だが、まだ修正されていないもの。意図的に「そのまま」にしてあるものを、Claude Codeが「直してしまう」ことを防ぎます。
このファイルがないと、すべてのセッションがゼロから始まります。あれば、Claude Codeはあなたがやめたところからまさにその通りに再開します。
第2の間違い：1タスクずつ進めてしまうこと
多くの人はClaude Codeを順番に使います。1つを終えて、次へ進む。
Claude Codeにはサブエージェント機能があり、複数の並行する作業ストリームを同時に動かせます。関連する5つのコンポーネントを作る必要があるなら、1つずつ作る必要はありません。
メンタルシフトは「次のタスクは何か」から「並行して動かせるのは何か」へです。同じ機能のためのフロントエンドとバックエンド。実装を書いている最中にユニットテスト。コードがレビューされている間にドキュメント。
ここでアウトプットのマルチプライヤーが効いてきます。2倍速いわけではなく、5倍に近いです。ボトルネックがもはやClaude Codeのスピードではなくなるからです。効いてくるのは、並行して動かせる作業を設計するあなたの能力です。
第3の間違い：標準（スタンダード）ドキュメントがないこと
Claude Codeを複数のセッションやプロジェクトの複数の箇所にまたがって使うと、整合性はすぐに崩れます。1回目のセッションのボタンスタイルが3回目のセッションと一致しません。あるモジュールのエラーハンドリングパターンが別のものと矛盾します。
解決策は、CLAUDE.mdに標準（スタンダード）ドキュメントを置くことです。人間向けのスタイルガイドではありません。Claude Codeが毎回、必ず、リマインドされなくても従うべきルールのセットです。
色の値。コンポーネントのパターン。APIレスポンスの形。認証フロー。コードベース全体で一貫しているべきあらゆる意思決定を、1度書き出し、自動的に強制します。
それがないと、あなたは作業のブレを直すのに時間の半分を使うことになります。あれば、Claude Codeはあなた自身よりもあなたの標準をうまく守らせます。疲れないし、忘れないからです。
第4の間違い：アップデートのための強制関数（forcing function）がないこと
CLAUDE.mdの明白な弱点は「古くなる（staleness）」ことです。更新しなければ、それは無意味どころか、害になります。自信満々にClaude Codeを間違った方向へ導くからです。
規律は機能しません。更新を忘れてしまうセッションこそが、まさに何か重要なことが起きたセッションです。
解決策はシンプルです。毎回のセッションの終わりに、Claude Codeに対してクローズする前にCurrent Stateセクションを更新するよう依頼します。
「終わる前に、CLAUDE.mdのCurrent Stateセクションを今日やったこと、うまく動いていること、そして次回どこから再開するかを反映するよう更新して。」
30秒です。文脈がまだ新鮮なうちに。モデルは、あなたが書き留めるのを忘れがちなことよりも、いま起きたことを要約するのが得意です。
おそらく80%のセッションは拾いきれます。残りの20%は中断されたセッションです — ターミナルを閉じた、IDEがクラッシュした、時間が足りなかった。これらは完全には解決できません。とはいえ、80%あればシステムは機能します。
これを正しくやると何が変わるか
出力が、もはや「AI支援によるコーディング」に感じられません。あなたのコードベースを理解し、あなたの標準に従い、あなたがやめたところから正確に再開でき、しかも複数のことを同時に進められる請負業者がいるように感じます。
あなたが実際にやる仕事が変わります。定型文（ボイラープレート）を書く時間が減ります。スタイルのブレを直す時間が減ります。文脈を改めて説明し直す時間が減ります。その代わり、アーキテクチャやプロダクト上の意思決定、そして本当に人間の判断が必要な問題に、より多くの時間を使えます。
それが、Claude Codeが作られたための仕事内容です。タイプ係ではありません。アーキテクトの実行部隊です。
多くの人は、適切なブリーフィングを渡さないため、そこには到達しません。
「CLAUDE.mdのアプローチ」と「サブエージェントのパターン」は、数週間かけて15個のツールから成るDocker管理プラットフォームを作ったことから生まれました。ファイルの構造化の具体については、ここで書きました：[previous articleへのリンク]
