コーディングスタイルが定着しない理由
メモリ機能が有効になっていない可能性、そして2つの異なるバージョン
まず、どちらのUIバージョンを使用しているか確認してください。設定の切り替え場所が異なるためです。ドキュメントに記載されている確認方法：Settings > Memoryに「Memory」が表示されていれば新しいバージョンです。「Settings > CapabilitiesにMemoryが表示されている場合は、レガシー（旧）メモリ機能を使用しています。」
新しいバージョンでは、メモリはユーザーごとのオプトイン機能であり、手動で有効にする必要があります。Settings > Memoryに移動し、Generate memory from chatsをオンにしてください。この機能は「free、Pro、MaxプランのClaudeユーザー」が利用可能で、Web、Claude Desktop、Claude Mobileに適用されますが、「現時点ではCoworkでは利用できません」。Enterpriseプランの場合、さらなる制限があります。メンバーは「組織のオーナーがこの機能を有効にしている場合にのみ、個別に有効にすることができます」。
これら2つのバージョンは、修正の反映方法においても動作が異なります。新しいバージョンは「カテゴリごとに整理された個別のエントリのセットとしてメモリを構築」し、「固定された日次のスケジュールではなく、チャット中にリアルタイムでこれらのエントリを読み取り、書き込み、更新」します。一方、レガシーバージョンは「24時間ごとに更新される」サマリーです。レガシーの場合、今日の午後に指示したスタイルの修正が、まだメモリに反映されていない可能性があります。
Anthropicはロールアウトを順次進行中と説明しているため、思い込まずにどちらのバージョンを使用しているか再確認することをお勧めします。
プロジェクトメモリは独立している（これがほとんどの場合の真の原因）
これこそが、「さっきも言ったのに」という状況を最も頻繁に引き起こす境界線です。プロジェクト内のメモリはそのプロジェクト内に留まります。プロジェクト以外のチャットには独自のスペースがあります。そのため、システムが正常に動作していても、あなたのスタイルが消えてしまう現実的なシナリオが3つあります。
プロジェクト以外のチャットで学習させ、その後プロジェクト内で作業を開始した場合。プロジェクトAで学習させ、プロジェクトBを開いた場合。あるいは、チームが新しいサービスのために新しいプロジェクトを立ち上げ、まっさらな状態からスタートした場合です。
これらはバグではありません。ドキュメントでは、各プロジェクトを「焦点を絞り、関連性が高く、分離された」状態に保つための意図的な設計として説明されています。しかし、これはメモリ機能単体では、すべての作業において一貫したコーディングスタイルを維持できないことを意味します。どこかに「信頼できる唯一の情報源（正本）」を置く必要があります。
メモリはチャットから生成されるものであり、あなたが直接執筆するものではない
メモリは会話から自動生成されます。これは自分で何も書く必要がないため便利ですが、同時に、保存される内容があなたのスタイルガイドそのものではなく、Claudeによる好みの「要約」になってしまう理由でもあります。「タブを使用、幅4、セミコロンは絶対に使用しない、名前付きエクスポートのみ、テストは同ディレクトリに配置」というのは仕様（スペック）です。メモリが保持するのは、それに近い「印象」のようなものです。
また、設計上除外されるカテゴリが2つあります。シークレットチャット（Incognito chats）はメモリに寄与しません。「このモードがオンの場合、Claudeはチャットを記憶しないため、Claudeのメモリやチャット履歴には保存されません。」また、1回のチャットで指摘しただけで二度と繰り返さなかった修正は、記憶するに値する基準を満たさなかった可能性があります。
他の誰かの指示があなたの指示を上書きしている可能性がある
TeamまたはEnterpriseプランを利用している場合、あなたより上位のレイヤーが存在します。組織の指示（Organization instructions）により、「TeamおよびEnterpriseプランの管理者以上は、組織全体のすべての会話でClaudeが従うカスタム指示を設定」できます。そして、その優先順位は明確に示されています。「両方が設定されている場合、組織の指示が優先されます。個人の指示が組織の指示と直接矛盾する場合、Claudeは組織レベルの指示を優先します。」
知っておくべきなのは、その可視性です。「管理者以上のみが組織の指示を表示または編集」できます。つまり、組織レベルで設定されたフォーマットや言語の標準が、あなたの個人の好みを上書きしている可能性があり、あなたはその指示テキスト自体を見ることはできません。あなたの個人指示は、「組織の指示が対応していない事項に対してのみ適用」されます。どの指示コンテナが優先されるかの全体像は、how to stop Claude forgetting your system prompts（Claudeがシステムプロンプトを忘れるのを防ぐ方法）で解説しています。
よく試されるアプローチ
修正を何度も繰り返し、定着することを期待する。 うまくいくこともあります。それがメモリ機能の目的だからです。しかし、確認ステップがないため、3週間経っても本当に定着したのか確信が持てない原因になります。
すべてのチャットにスタイルガイド全体を貼り付ける。 確実ですが、コスト（トークン）がかかります。これはhow to stop re-explaining context to AI（AIにコンテキストを何度も説明するのをやめる方法）で説明されているループそのものです。
スタイルガイドをプロジェクトのナレッジ（Project Knowledge）に入れる。 直感としては正しいですが、スコープが間違っています。プロジェクト単位であるため、複数のコピーをメンテナンスすることになり、内容が乖離（ドリフト）していきます。この問題の一般的なケースは、giving Claude permanent domain knowledge（Claudeに永続的なドメイン知識を与える方法）で扱っています。
個人用の指示（Personal Instructions）に「優れたプラクティスに従う」と書く。 曖昧すぎて実行できません。Anthropic自身の指示に関するガイドラインが解決策を示しています。「『プロフェッショナルであること』のような曖昧な指示の代わりに、『フォーマルな英語で回答してください。短縮形、スラング、絵文字は使用しないでください』といった具体的な指示を与えてください。」コードスタイルも同様に扱う必要があります。
リンターがやるべきことをメモリでカバーしようとする。 フォーマッタで強制できるフォーマットルールは、そもそもプロンプトレベルで要求すべきではありません。指示は、ツールでは判断できない選択肢のために残しておきましょう。
チームの規約と個人のスタイルを同一視する。 これらはスコープが異なり、配置すべき場所も異なります。チーム側の問題については、why Claude forgets your house conventions（Claudeが社内規約を忘れる理由）で解説しています。
解決策：スタイルを一度書き出し、すべてのプロジェクトが参照できる場所に配置する
3つのステップを踏みます。1つ目は、メモリを思い通りに機能させること。2つ目は、重要な部分を決定論的（確実）にすること。3つ目は、コピーのメンテナンスをやめることです。
メモリパネルを開き、直接編集する。 これは多くの人が見落としがちなステップです。Settings > Memoryに移動します。「メモリパネルには、Claudeがあなたについて記憶しているすべての内容がカテゴリ別にリストされます。エントリを選択すると、そのサマリーと詳細が表示されます。エントリを変更するには、『Tell Claude what to change or remove（変更または削除する内容をClaudeに伝える）』ボックスを使用します。エントリを完全に削除するには、『Delete』を選択します。」技術的な好みについて、実際に何が保存されているかを確認してください。間違っているエントリを修正し、3月に放置したプロジェクトのエントリを削除しましょう。
会話を通じて追加することもできます。Claudeに記憶してほしい内容を伝えるだけで、チャットを離れることなく更新されます。レガシーバージョンでは、この方法で行われた編集は「次の会話に即座に適用されるため、日次の統合処理が実行されるのを待つ必要はありません」。
妥協できないルールはメモリではなく「指示（Instructions）」に記述する。 コードレビューのコメントに該当するような内容は、すべて個人用の指示に含めるべきです。検証可能なほど具体的に記述してください。「Reactは関数コンポーネントのみ、名前付きエクスポートを使用し、デフォルトエクスポートは禁止。テストは *.test.ts として同ディレクトリに配置。セミコロンは使用しない。」メモリは「傾向」を学習しますが、指示は「ルール」を規定します。Anthropic自身の注意書きも念頭に置いておいてください。「指示の優先順位付けはプロンプトレベルの指示に依存します。直接矛盾する指示が含まれる稀なエッジケースでは、動作が異なる場合があります。指示をテストして、期待通りの結果が得られるか確認してください。」
フォーマットはフォーマッタに任せる。 インデント、クォーテーション、行の長さなどは、実行可能な設定ファイル（config）に任せるべきです。プロンプトの指示リソースは、ツールでは判断できないアーキテクチャ上の好みのために残しておきましょう。
仕様書の置き場所を1つに絞る。 これこそが、メモリでも指示でも解決できない部分です。メモリは設計上プロジェクト単位です。プロジェクトナレッジも定義上プロジェクト単位です。個人用の指示は常に有効な短いテキストブロックであり、ドキュメントではありません。そのため、理由が添えられた本物のスタイル仕様書は、複製されるか、あるいはどこにも存在しない状態になってしまいます。
これを解決するのがMemoryLakeです。永続的な好みとその理由を、ツールが読み取るレイヤーに保持するため、すべてのプロジェクトとすべてのアシスタントが同じバージョンを参照できます。セットアップは3つのステップで完了します。
ステップ1：APIキーを作成する
MemoryLakeにサインインし、APIキーを作成します。接続するすべてのツールで共通の認証情報として使用できます。
ステップ2：最初のメモリをアップロードする
短いエントリで、1つの主張につき1エントリにします。ルールや通常のメモリではなく、ここに配置すべき内容は以下の通りです。
理由が添えられたスタイルの選択。 「共有パッケージにおいてバンドラーのツリーシェイキングがデフォルトエクスポートを漏らすため、名前付きエクスポートのみを使用する。」ルールに書けるのは前半部分だけです。理由を添えることで、そのルールがまだ設定されていない新しいプロジェクトでも、不要な提案が繰り返されるのを防ぐことができます。
エコシステムのデフォルトとは異なる規約。 十分にトレーニングされたモデルの直感としては合理的であっても、あなたのコードベースにとっては誤りであるような事項です。これらは、新しいプロジェクトを始めるたびに何度も指摘している内容に該当します。
意図的に不採用にしたパターン。 過去に試して断念した抽象化とその理由。これは設定ファイルやコミットメッセージには残らないため、新しいセッションが始まるたびにAIから再び提案されてしまいます。
あなたのスタックに特有の語彙。 あなたのプロジェクトにおける「サービス」、「ハンドラー」、「モジュール」の定義など、レビューコメントでは前提とされているものの、新しいエージェントが把握していない言葉です。
ステップ3：AIとエージェントを接続する
お使いのツールを接続します。MemoryLakeはMCP（Model Context Protocol）およびAPI経由でアクセス可能です。そのため、Claude Code、Codex、OpenClawなどのMCPネイティブなエージェントはMCPサーバーを指定するだけで接続でき、その他のアシスタントはAPIを介して同じメモリを読み取ることができます。これにより、一度書いたスタイル仕様を、エディタのエージェントもまったく同じように参照できるようになります。
3つの現実的な制限事項があります。MemoryLakeは、Claudeのメモリや指示（Instructions）を直接書き換えるわけではありません — これらはAnthropicの機能であり、ツールが接続されていないチャットを制御するために、引き続き適切に設定しておく必要があります。また、MemoryLakeはあなたやエージェントが入力した内容のみを保持するため、ステップ2は手動で行う必要があります。さらに、これはあくまで「コンテキスト（文脈）」の提供であり、強制力はありません。フォーマッタやリンターでチェックできる内容については、設定ファイルこそが最も確実な保証となります。
導入後に変わること
「本当に記憶しているか？」を目で確認できるようになる。 メモリパネルにはカテゴリ別にエントリが表示されます。これを開いて技術的な好みを確認し、間違っている部分を修正できます。推測に頼る必要はありません。
新しいプロジェクトが「まっさらな状態」からのスタートではなくなる。 プロジェクトメモリが分離されているのは設計上の仕様です。これに抗うのではなく、プロジェクトが参照できる場所に信頼できる仕様書を置いておくことが解決策になります。
指示（Instructions）がより短く、具体的になる。 理由や背景を別の場所に逃がすことで、常に有効な指示ブロックは、検証可能な最小限のルールだけに整理できます。
エディタとチャットの認識が一致する。 ブラウザ上のClaudeも、IDE内のエージェントも、まったく同じ好みを読み取ります。この詳細については、what persistent memory actually means（永続メモリの本当の意味）で解説しています。
チームの標準と個人の好みが衝突しなくなる。 組織の指示は個人の指示よりも優先されるため、個人のレイヤーは組織の指示と競合させるのではなく、組織がカバーしていない部分を補完するために使用すべきです。
Claudeにコーディングスタイルを守らせるためのベストプラクティス
まず、どちらのメモリ機能を使用しているか確認する。 Settings > Memoryがあれば新しいバージョン、Settings > Capabilitiesの下にMemoryがあれば、サマリーが24時間ごとに更新されるレガシーバージョンです。
月に一度はメモリパネルを確認する。 誤った内容が記憶されている可能性があり、誤ったエントリは指示と競合するため、何もないよりも悪影響を及ぼします。
検証可能なほど具体的にルールを書く。 「関数コンポーネント、名前付きエクスポート」は検証可能ですが、「モダンなReactのプラクティスに従う」は検証不可能です。
リンターで強制できることにメモリを頼らない。 フォーマットは設定ファイルに任せ、プロンプトは判断が必要な設計判断に集中させます。
プロジェクトの分離を前提として計画を立てる。 あるプロジェクトで学習させたスタイルは、次のプロジェクトには届きません。信頼できる唯一のバージョンをプロジェクトの外部に保持しましょう。
シークレットチャットはメモリに一切寄与しないことを忘れない。 シークレットチャットでどれだけ丁寧に説明しても、それは保存されません。
TeamやEnterpriseプランでは、組織の指示内容を確認する。 組織の指示が優先され、管理者以上しか表示できないため、意図しない上書きが発生している場合は、組織の指示が原因である可能性があります。
ルールの隣に理由を保存する。 正当な理由が添えられたスタイルの選択は、新しいプロジェクト、新しいツール、新しいチームメンバーにも受け入れられます。ルール単体では形骸化しがちです。この一般的なケースは、why agents ignore the instruction files you wrote（エージェントが作成した指示ファイルを無視する理由）で解説しています。
まとめ
Claudeのメモリ機能は「技術的な好みとコーディングスタイル」を記録するとドキュメントに明記されているため、基本的には機能するはずだと考えるべきです。機能しない場合は、具体的な障害が存在します。通常、それは次の4つのいずれかです。メモリがオフになっているか、24時間更新のレガシーバージョンを使用しているか、プロジェクトの境界を越えて別のメモリスペースに入ってしまったか、好みがルールではなく単なる「傾向」として学習されてしまったか、あるいは表示できない組織の指示があなたの指示よりも優先されているかです。
そのうち3つは、10分ほどで解決できます。メモリを有効にし、メモリパネルを開いて内容を修正し、妥協できないルールを検証可能なほど具体的な指示に移動させるだけです。4つ目の「プロジェクトの分離」は意図的な設計であり、設定でオフにすることはできません。
だからこそ、スタイル仕様そのものを、単一のプロジェクトやツールの外部に配置する必要があるのです。一度だけ理由を添えて書き出し、すべてのツールが読み取るレイヤーに置く。そうすれば、新しいリポジトリ、新しいプロジェクト、新しいエージェントを立ち上げても、まっさらな状態から同じ会話を繰り返すことなく、すでに説明済みの規約を適用した状態でスタートできます。