なぜClaude Codeは毎回コードベースを再読み込みするのか
現在のClaude Codeによるリポジトリの扱い方
セッション内では、Claude Codeは真の理解を構築します。ファイルを読み込み、依存関係を追跡し、何がどこにあるかを学習します。その理解はコンテキストウィンドウの状態（ステート）です。セッションが終了するか、ウィンドウがいっぱいになって古いコンテンツが圧縮されて消去されると、そのマップは失われます。次のセッションでは、永続的な入力はディスク上のファイルとCLAUDE.mdにあるものだけになるため、昨日知っていたことを再構築するために再びgrepと読み込みを行います。
記憶が定着しない技術的な理由
Claude Codeがセッション間で保持するコードベースの永続的なインデックスは存在しません。CLAUDE.mdは手書きのルールブックであり、規約には適していますが、モジュールや責任範囲、各パーツの接続方法を示す生きたマップではありません。そのため、すべてのセッションで探索を通じてそのマップを再構成することになり、大規模なリポジトリでは、作業を開始する前に時間とトークンの両面でコストがかかることになります。
これによるコスト
起動時の「税金」はセッションごとに発生します。grepやファイルを開くための数分間は作業時間として消費され、API課金の場合はトークンとして支払われます。大規模なコードベースではこれが最悪の事態を招きます。再発見すべきファイルが増え、タスクではなく再発見のためにコンテキストウィンドウの多くが消費されてしまいます。しかも、これは冗長です。構造的な知識は週単位で安定しているにもかかわらず、毎回破棄され、再構築されているのです。
Claude Codeの組み込みの回避策（とその限界）
CLAUDE.md
ビルドコマンド、規約、高レベルのアーキテクチャノートなど、安定した事実を記述するのに適しています。その限界は、手動かつ浅いという点です。大規模なコードベースの完全で最新のマップをMarkdownファイルで手動メンテナンスする人はいません。そのため、Claudeは依然としてギャップを埋めるために再探索を行います。
セッションの再開
最近のセッションを継続すると、その1つのトランスクリプトのコンテキストが回復するため、文脈を引き継ぐのに役立ちます。しかし、永続的なコードベースモデルは得られず、トランスクリプトが長くなるとコンテキストの上限に達し、再開した目的である詳細そのものが圧縮されて消去されてしまいます。
より大きなコンテキストウィンドウ
ウィンドウが大きくなると、Claudeは一度にリポジトリのより多くの部分を保持できるようになり、セッション内では役立ちます。しかし、セッション間で何も永続化されません。毎朝、より高いトークンコストを支払って、同じ再発見でより大きなウィンドウを再充填しているだけです。
共通の壁：これらはいずれも、セッション間で存続する、クエリ可能な永続的コードベースモデルではありません。これは、Claude Codeがプロジェクトのコンテキストを忘れてしまう理由の背後にある根本的なギャップと同じです。
解決策：Claude Codeに永続的なコードベースメモリを与える
永続的なセットアップとは、リポジトリの永続的なモデル（アーキテクチャ、モジュールの役割、重要な決定事項など）を保持するメモリレイヤーです。これにより、Claudeはモデルを再構築するのではなく、それを取得（リトリーブ）します。MemoryLakeは、その知識を一度保存すれば、検索可能でGitスタイルのバージョン管理が行われるため、アーキテクチャの進化を追跡できます。また、エンドツーエンドで暗号化されているため、コードの安全性も保たれます。
ステップ 1: APIキーを作成する
MemoryLakeにサインインし、キーを生成して、最初のリクエストを送信します。約30秒で完了します。
ステップ 2: 最初のメモリをアップロードする
コードベースの永続的なモデル（アーキテクチャの概要、モジュールの役割、主要なAPIやデータフローのドキュメント、およびその背景にある決定事項など）を投入します。ドキュメント、画像、その他のファイルすべてに対応しています。セッションごとではなく、構造が実際に変更されたときに更新します。
ステップ 3: AIとエージェントを接続する
Claude CodeはネイティブでMCPに対応しています。APIキーを使用してMCP設定にMemoryLakeを追加すると、タスクの開始時に再grepして再構成する代わりに、コードベースモデルを取得します。同じメモリは、MCPまたはAPIを介してCodex、OpenClaw、その他のエージェントでも利用可能です。すべてのツールとマシンで1つのコードベースモデルを共有できます。
再発見が実際にもたらすコスト
時間とトークンにおける起動時の「税金」
セッションごとに大規模なリポジトリを再発見することは、実際の時間を消費し、従量制の利用においては実際のお金を消費します。探索自体がトークンを消費し、タスクで使用できたはずのコンテキストウィンドウのスペースを消費します。これを、チームのすべての開発者がすべてのセッションで個別に同じ壁に突き当たる回数分、掛け合わせてみてください。
再grepの代わりにリトリーバル（取得）を使用する
永続的なモデルがあれば、Claudeはゼロから導き出すのではなく、必要に応じて「このサービスはこのように構成されている」という情報を引き出します。起動が速くなり、実際の作業に使えるウィンドウがより多く残り、支出も抑えられます。MemoryLakeのトークン削減計算ツール（Token Saving Calculator）で、あなたの使用状況からその効果を予測できます。
コードベースメモリのベストプラクティス
コードではなくマップを保存する
ディスクからすでに読み取ることができる生のソースコードをダンプするのではなく、Claudeが再構築することになるモデル（アーキテクチャの概要やモジュールの役割）をメモリに保持します。価値があるのはファイルの内容ではなく、構造です。
実際の構造変更時に更新する
セッションごとではなく、新しいサービスや大規模なリファクタリングなど、アーキテクチャが実際に変化したときにメモリを更新します。安定したマップこそが、再発見を不要にするものです。
リポジトリごとにスコープを設定する
リポジトリごとに1つのメモリ・スコープを設定することで、正確なリトリーバルが維持され、各プロジェクトのClaude Codeセッションが独自のマッピングのみを取得できるようになります。
結論
Claude Codeは強力なペアプログラマーですが、毎朝リポジトリをゼロから再学習するという儀式を行っています。この儀式は、セッションごとに時間、トークン、コンテキストウィンドウのスペースを消費し、最も役立つはずの大規模なコードベースで最も多くのコストがかかります。コードベースの永続的なモデルを提供すれば、再発見はストップします。必要な情報を取得して、他のエージェントとともに、どのマシンでもすぐに作業を開始できます。自分のコードを再説明するためにコストを支払うのはもうやめましょう。