はじめに
2026年1月、Google のプリンシパルエンジニア Jaana Dogan 氏が X にこう投稿した。「Claude Code を使ったら、チームが1年かけて構築した分散エージェントオーケストレータを1時間で再現できた」——このツイートは 800 万以上のビューを獲得し、エンジニアリングコミュニティに衝撃を与えた。
しかし、その生産性の前提条件がある。Claude Code を正しく設定することだ。
あるアラビア語圏の開発者がX（旧Twitter）で指摘した問題が、多くの開発者の共感を呼んでいる。
Claude Code を毎日使っている開発者の 90% は、毎セッション、ゼロから始めている。 スタックのコンテキストなし、以前の会話の記憶なし、コードスタイルを統一する行動ルールなし。
この「毎回ゼロスタート」問題は、週あたり相当な生産性損失をもたらすという。同氏は正しい設定を導入した結果、月次で 週15時間以上の節約 と大幅な token コスト削減を実現したと報告している。
では、どうすれば解決できるのか？
問題の本質: Claude Code はセッションをまたいで記憶しない
Claude Code は強力なツールだが、デフォルトではセッションをまたいで文脈を保持しない。新しいセッションを開くたびに以下を繰り返すことになる。
- プロジェクトのアーキテクチャを再説明する
- コーディング規約や好みを再度伝える
- 前回の作業内容や設計上の決定事項を再共有する
この繰り返しは、時間と token の両方の無駄になる。毎日 Claude Code を使う開発者にとって、これは積み重なると無視できないコストになる。
解決策: 3 つの永続化レイヤー
Claude Code でセッション間の文脈を維持するには、次の 3 つの仕組みを組み合わせる。
1. CLAUDE.md — プロジェクトコンテキストの永続化
CLAUDE.md は、Claude Code がセッション開始時に自動的に読み込む設定ファイルだ。プロジェクトのルートに置いておけば、毎回説明しなくていい情報を一度記載しておける。
# プロジェクト名
## 技術スタック
- フロントエンド: React + TypeScript
- バックエンド: FastAPI (Python)
- データベース: PostgreSQL
## コーディング規約
- 変数名はキャメルケース
- 関数は 50 行以内に収める
- テストは pytest を使用
## よく使うコマンド
- `npm run dev` — 開発サーバー起動
- `pytest` — テスト実行
- `docker compose up -d` — DB 起動これだけで、毎セッションの「説明コスト」を大幅に削減できる。
2. メモリシステム — 作業コンテキストの継続
CLAUDE.md がプロジェクト全体の静的な情報を保持するのに対し、動的な作業コンテキストは別途管理する必要がある。プロジェクト内に専用のメモリディレクトリを設けておくと便利だ。
.claude/
memory/
project.md # 現在の作業フェーズ
decisions.md # 設計上の決定事項
todos.md # 次のセッションへの引き継ぎ次のセッション開始時に「前回のメモを確認してください」と伝えるだけで、文脈を即座に復元できる。
Claude Code には Auto memory 機能もある。これを有効にすると、Claude がセッション中に重要な情報を自動的に CLAUDE.md へ書き込むため、手動でメモを更新する手間が減る。/memory コマンドを使うと、CLAUDE.md の内容を対話的に編集したり、Auto memory の有効/無効を切り替えたりできる。
3. 行動ルール — コードスタイルの一貫性
Claude の出力スタイルをプロジェクト全体で統一するために、CLAUDE.md に行動ルールセクションを追加する。
## Claude への指示
### コードレビューの際に
- セキュリティ脆弱性を最優先で確認
- パフォーマンスへの影響を必ず言及
### コードを書く際に
- 型ヒントを必ず付ける
- docstring は Google スタイルで書く
- テストコードを必ずセットで提案する
### 禁止事項
- `any` 型の使用
- グローバル変数の導入
- `print()` を本番コードに残すこの設定がないと、セッションごとに「型ヒントを必ず付けてください」「テストも書いてください」と毎回指示し直す必要が生じる。
実践例: CLAUDE.md の詳細テンプレート
大きなプロジェクトで効果を発揮する、より詳細な CLAUDE.md の例を示す。
# プロジェクト: ECサイト Backend
## アーキテクチャ
- クリーンアーキテクチャを採用
- Domain / Application / Infrastructure の 3 層構造
- 依存関係は内側に向かってのみ
## 現在の作業フェーズ
- [x] 商品管理 API の実装
- [ ] 注文処理フローの実装 ← 現在ここ
- [ ] 決済連携
## 重要な制約
- 既存の DB スキーマは変更不可（本番稼働中）
- 外部 API のレート制限: 100 req/min
## テスト戦略
- ユニットテスト: Domain 層を重点的に
- 統合テスト: API エンドポイントごとに必須
- E2E テスト: 主要ユーザーフローのみ
## 禁止事項
- 直接的な DB アクセスを Application 層に書かない
- 外部 API 呼び出しを Domain 層に書かない「現在の作業フェーズ」セクションを毎日更新するだけで、翌日のセッションから即座に作業の続きに入れる。
ユーザーレベルの設定との組み合わせ
CLAUDE.md はプロジェクト単位の設定だが、Claude Code にはユーザーレベルの設定（~/.claude/CLAUDE.md）も用意されている。こちらには、すべてのプロジェクトに共通する好みを書いておく。
# 個人設定
## 全プロジェクト共通
- 回答は日本語で
- コードの説明は簡潔に
- 提案は最大 3 案まで
## デフォルトの技術的嗜好
- 関数型スタイルを優先
- イミュータブルなデータ構造を好むプロジェクト固有の設定とユーザー設定が合わさることで、Claude はセッション開始直後から「自分のチームメンバー」のように振る舞う。
効果のまとめ
3 レイヤーの設定を導入した場合の典型的な改善効果:
| 指標 | 設定なし | 設定あり |
|---|---|---|
| セッション開始時の文脈共有 | 5〜15 分 | 0 分 |
| コードスタイル修正指示 | 毎回 | ほぼゼロ |
| 同じ説明の繰り返し | 毎日 | なし |
| Token 消費（相対比） | 100% | 60〜70% |
まとめ
Claude Code の真の生産性は、ゼロスタートを避けることにある。CLAUDE.md・メモリ・行動ルールの 3 レイヤーを整備するだけで、毎セッションの文脈再構築コストを大幅に削減できる。
「1人の開発者が10人のエンジニアチームに対抗できる」という主張が現実になるかどうかは、こうした基盤設定にかかっている。まずは CLAUDE.md に技術スタックと禁止事項を書き込むことから始めると、効果をすぐに実感できるはずだ。