ChatGPTがコーディングスタイルを忘れる理由と、その解決策（2026年版）

チャットアプリにはルールファイルの役割を果たすものがない

これが構造的な最大の違いであり、回避策を説明する前に述べておく価値があります。Cursorの公式ドキュメントには、ルールファイルが存在する理由が次のように説明されています。「大規模言語モデルは、補完の間にメモリを保持しません。ルールは、プロンプトレベルで永続的かつ再利用可能なコンテキストを提供します。」

あなたのスタイルを覚えているように見えるすべてのコーディングツールは、ディスク上のファイルからリクエストごとに同じテキストを再提供するという処理を行っています。Cursorは .cursor/rules を読み込み、Claude Codeは CLAUDE.md を読み込み、Codexは AGENTS.md を読み込みます。そのため、Claudeがコーディングスタイルを忘れる問題やCursorがそれを忘れる問題は、通常、より優れたファイルを作成することで解決できます。

ChatGPTにはそのようなファイルはありません。回答する前に読み込むような、ローカルマシン上のパスは存在しないのです。そのため、他のすべてのツールでスタイルを永続化させている仕組みが単純に利用できず、その代わりとなる手段はどれもはるかに小規模なものに限られます。

メモリはスタイルガイドではなく、好みを保存するためのサイズ設計になっている

ChatGPTの保存されたメモリは、意図的に短く設計されています。すべてのプロンプトと一緒に送信されるため、そのサイズはリクエストごとのコストになるからです。公表されている数値はありませんが、出回っている推測では合計1,200〜1,400単語、または約200エントリーとされており、意見も一致していません。1〜2ページ程度と考えておくとよいでしょう。

本物のスタイルガイドは1〜2ページには収まりません。無理に収めようとすると上限に達してしまいます。メモリがいっぱいになると、何かを削除するまでChatGPTは新しい長期的な事実を追加しなくなります。これはそれ自体が別のストレスになります。OpenAIが2026年6月4日に発表した再構築されたメモリシステムは、これを改善しました。時間の経過とともに最新の状態に保たれる読み取り可能なメモリサマリーが提供され、PlusおよびProの容量が2倍になりました。しかし、1〜2ページを2倍にしたところで、やはりスタイルガイドには足りません。また、新しいシステムは正確な言葉を保存するのではなく統合（要約）するため、厳密に表現された規約が言い換えられて返ってくる可能性があることにも注意が必要です。

スタイルとは100の小さな決定の積み重ねであり、1つの指示ではない

「私たちのコーディングスタイルに従ってください」というのは、1つの指示のように見えます。しかし実際には、真偽値の命名、エラーハンドリングの形式、型の配置場所、バレルエクスポート（barrel export）を行うかどうか、プロパティの順序、コメントが必要なタイミング、ループを書く代わりにどのユーティリティを使用するか、テストの命名方法など、多岐にわたります。

これらのほとんどは、事前に明文化されることはありません。違反を目にして初めて気づくものです。つまり、スタイルガイドはチャットの中で段階的に発見されていくものであり、それぞれの発見はそれを指摘した場所にしか残りません。10回セッションを重ねる頃には、ChatGPTはあなたの規約の10個の異なるサブセットを教えられたことになりますが、そのどれも保持していません。

コピペは劣化する

誰もが最終的には、セッションの最初に規約ブロックをコピー＆ペーストするようになります。しかし、それは徐々に短くなっていきます。記憶を頼りにタイピングし、退屈な例外部分は省かれるため、4週目のコピペは1週目の半分程度の内容になってしまいます。あなた自身の規約の再表現がブレるため、スタイルもブレていくのです。これは手動でコンテキストを再説明するという、よくある問題の典型例です。

これと類似した問題として、カスタム指示に規約を入れたにもかかわらず無視されるという現象がありますが、それは指示が設定されているが適用されないという別の失敗パターンです。本記事は、規約がそもそも存在すらしていない状況について扱っています。

カスタム指示（Custom instructions）。 最初のステップとしては適切であり、いくつかの厳格なルールに対しては本当に効果的です。ただし、ブロックが小さいため、最も重要な5つの規約を選ぶ必要があります。また、すべての作業に適用されてしまうため、職場でGoを書き、自宅でTypeScriptを書くような場合には不都合が生じます。

保存されたメモリ（Saved memory）。 「TypeScriptのstrictモードを使用する」といった、2〜3個の固定された好みに対しては機能します。しかし、ガイドを保存するコンテナとしては不適切であり、スタイルルールでメモリを埋めてしまうと、自分に関する他の情報を保存するための容量を消費してしまいます。

規約ファイルを添付したProject。 組み込みオプションの中では最善の選択肢です。そのプロジェクトにスコープが限定され、グローバルへの影響がなく、要約ではなく実際の実装ドキュメントを保持できます。制限としては、ChatGPT内に閉じていること、長いセッションではファイルがコンテキスト内に確実に残り続けないこと、そして通常のチャットで尋ねるちょっとした質問には役に立たないことが挙げられます。

指示にスタイルガイドを含めたカスタムGPT。 効果的であり、カスタム指示ブロックよりも指示を長く書けるため、確実なステップアップになります。ただし、プロジェクトごとに個別のアシスタントを管理し、それを忘れずに使用する必要があり、ガイドを更新するにはGPTを編集する必要があります。

セッションごとにガイドをコピペする。 原理的には確実ですが、実際には徐々に形骸化し、会話のたびにトークンを消費します。

リンターとフォーマッター。 機械的なすべての要素に対するプロフェッショナルな解決策であり、脚注ではなく主役として扱うべきものです。詳細は以下で説明します。

まず、スタイルを2つの半分に分割してください。なぜなら、その半分はプロンプトに含めるべきではないからです。

機械的な半分はツールに任せるべきです。 クォートのスタイル、セミコロン、インデント、インポートの順序、行の長さ、末尾のカンマ、およびほとんどの命名パターンは、Prettier、ESLint、Black、gofmt、rustfmt、またはお使いの言語の同等ツールによって強制できます。設定ファイルをリポジトリにコミットしておくだけです。フォーマッターが忘れることはありません。AIにインデントの好みを覚えておくよう求めるのは、言語モデルをリンターとして使っているようなものであり、本物のリンターよりも常に劣る結果になります。これは本記事の中で最も効果の高いアプローチであり、メモリとは一切関係ありません。

判断が必要な半分にはメモリレイヤーが必要です。 「サービスレイヤーでは継承を使用しない」「巧妙な1行のコードよりも名前付きヘルパーを優先する」「生成されたAPIクライアント内でのみ any を許可し、他では禁止する」「エラーメッセージはユーザー向けなので、それに合わせて記述する」といったことを表現できるフォーマッターはありません。これらは理由を伴う規約であり、理由があるからこそ、何度も議論を繰り返さずに済みます。

この後半部分こそ、ChatGPTがリクエストごとに読み込むストアに保存すべきものです。手動で再入力するコピペでも、他の情報と競合する2ページのメモリ予算でもありません。MemoryLakeは、そのためのメモリレイヤーです。規約ドキュメントは1つのストアに保存され、関連性があるときに取得され、Claude、Codex、その他のエージェントからも読み取ることができます。これにより、スタイルガイドがツールごとの成果物ではなくなります。

1つだけ率直な限界を述べておきます。規約を提供することで、それに従う頻度は確実に上がりますが、完全に遵守される保証はありません。モデルが読み取った内容に従って行動するかどうかは、モデルの振る舞いに依存するからです。だからこそ、機械的な半分はフォーマッターに任せるのです。強制する必要があるものには、強制力のあるツールを使用してください。

ステップ1：APIキーを作成する

キーを生成すれば、約30秒で最初のリクエストを送信できます。チャットに貼り付けたりコミットしたりせず、環境変数やシークレットマネージャーに保存してください。

ステップ2：最初のメモリをアップロードする

実際の規約が記載されたドキュメント、画像、ファイルをアップロードします。スタイルガイド、「サービスの書き方」ドキュメント、チームが議論の基準にするレビューチェックリスト、模範的とされるコードの例などです。理由も含めてください。理由のない規約は、不都合が生じた最初の機会に、モデルによっても、あなた自身によっても無視されてしまいます。

ステップ3：AIとエージェントを接続する

Claude、Codex、OpenClaw、その他のAIエージェントに、MCPまたはAPI経由でメモリへのアクセスを許可します。ChatGPTにはMCPクライアントがないため、APIを使用します。関連する規約を取得し、プロンプト、カスタムGPTの指示、またはモデルを呼び出すワークフローに注入します。MCPに対応しているツールは、同じストアを直接読み取ることができます。これこそがポイントです。1つのスタイルガイドを、すべてのアシスタントで共有できます。

最初の変化は、規約が縮小しなくなることです。ChatGPTが見るのはあなたの記憶ではなくドキュメントそのものであるため、20週目の出力も1週目と同じ基準に保たれます。

2つ目の変化は、ガイドが正しく成長することです。レビューの途中で新しい規約に気づいたとき、すぐに終了してしまうチャットに1文を追加するのではなく、ドキュメントに1行追加するようになります。数ヶ月も経てば、これは本物のスタイルガイドと「なんとなくの記憶」との決定的な差になります。

3つ目は、レビューが有用になることです。「これは私たちの規約に合致していますか？」という問いは、規約が取り出し可能であって初めて意味を持ちます。現状、その回答は一般的なベストプラクティスに終始してしまいます。これこそ、ChatGPTがプロジェクトのコンテキストを持たずに参加すると、そのコードレビューが自信に満ちていると同時に的外れに感じられる理由でもあります。

そして、これはChatGPT特有のものではなくなります。規約はコードベースの属性であり、アシスタントの属性ではありません。共有ストアに保存されていれば、別のツールに移行しても、再学習をやり直す必要はありません。

表現可能なすべての要素について、リンターを信頼できる唯一の情報源（Source of Truth）にする

設定ファイルをコミットし、プロンプトで制御するのではなく、AIの出力をリンターでチェックするようにします。これにより、記憶しておくべき内容が本当に判断を必要とする部分だけに絞り込まれ、違反が議論の余地なく可視化されます。

規約は理由を添えたルールとして記述する

「早期リターンを使用する」というのは単なる好みであり、無視されがちです。「早期リターンを使用する。このコードベースでは、ネストされた条件分岐によってelseブランチが見落とされ、本番環境で2件のバグが発生したため」と書けば、根拠のあるルールになります。また、理由を書いておくことで、その規約が形骸化したときにも気づきやすくなります。

文章だけでなく、模範例（コード）を含める

スタイルを伝える最も早い方法は、あなたが正しいと考える短いファイルを示すことです。モデルは、形容詞のリストよりも具体的な例からの方が確実に一般化できます。また、模範例には、あなたが言語化していない何十もの小さな決定事項が含まれています。

常に読み込ませる部分は小さく保つ

すべてのリクエストに注入されるもの（カスタム指示や短い規約ヘッダーなど）は、ガイド全体ではなく、最も違反されやすい5つのルールに絞るべきです。残りは検索（retrieval）に任せます。すべての質問の前にスタイルのルールが壁のように立ちはだかると、肝心の質問が埋もれてしまいます。

例外を明示的に記載する

実際のコードベースには、必ず「Yの場合を除き、Xを行う」というルールがあります。明文化されていない例外があると、AIは提示されたルールに厳密に従っているにもかかわらず、最も間違っているように見えてしまいます。そして、その修正がガイドに反映されないため、同じ修正を何度も繰り返すことになります。

ChatGPTがコーディングスタイルを忘れるのは、回答する前に読み込むファイルが存在しないからです。コーディングエージェントは、リクエストごとに読み込まれるルールファイルでこの問題を解決しています。一方、チャットアプリが提供するのは、小さなカスタム指示ブロック、ガイドではなく好みを保存する程度のメモリ、およびProjectのスコープ限定機能だけであり、結局のところ規約は最後に説明した会話の中にしか残りません。

解決策は、単一のアプローチではなく、役割を分けることです。機械的なものはすべて、設定ファイルをコミットしたフォーマッターとリンターに任せてください。フォーマッターが忘れることはありませんし、言語モデルがインデントの処理において専用ツールより優れることは決してありません。判断が必要な半分（理由付きの規約、例外、模範例）は、アシスタントがリクエストごとに読み込むストアに保存します。そうすれば、ガイドがあなた自身の記憶のスピードで劣化することはなくなり、特定の製品だけに依存することもなくなります。