ChatGPTがデザインシステムを忘れる理由
読み込むべきファイルが存在しない
コーディングエージェントは、リクエストごとにファイルを読み込ませることで、この「利用可能性」の問題を解決しました。だからこそ、Cursorがコーディングスタイルを忘れる問題は通常、より優れたルールファイルを作成することで解決でき、Lovableがデザインシステムを見失うという同様の不満に対しても、ナレッジファイルを用意するという解決策が存在します。
しかし、ChatGPTにはそれに相当する経路がありません。カスタム指示は小さくグローバルなブロックであり、2〜3個の常時適用ルールには便利ですが、コンポーネントのインベントリを置くには不向きで、どのプロダクトで作業しているかに関係なくすべてのチャットに適用されてしまいます。プロジェクト（Project）機能では添付ファイルがそのプロジェクト内に限定されますが、通常のチャットでちょっとした質問をするときには役に立ちません。そしてメモリはせいぜい1〜2ページ程度です。この製品のどこにも、デザインシステムを収めるのに適した仕組みはありません。
メモリはシステムに関する構造化された事実ではなく、ユーザーに関する文章を保存する
これが、単に情報が存在しないことよりも厄介な点です。2026年6月のメモリ機能の再構築以降、ChatGPTが保持するのは、あなたの言葉そのものではなく、システムが導き出した結論を時間の経過とともに更新した「要約されたサマリー」です。サードパーティによる容量の推定値は1,000語程度、または数百エントリー前後とされています。OpenAIは具体的な数値を公表していないため、これらはあくまで目安の規模感として捉えてください。
要約（synthesis）は、好みを保持する小さなメモリにとっては適切なトレードオフですが、デザインシステムにとっては完全に間違ったアプローチです。トークンテーブルはうまく圧縮できません。「余白のスケールは4, 8, 12, 20, 32であり、16は存在しない」というルールは、「一貫した余白を好む」という記述に変換されてしまいます。あなたが重視している例外こそが、要約によって真っ先に削ぎ落とされるディテールであり、結果として残るのは「制約」ではなく、なんとなくの「雰囲気」だけになってしまいます。
トークンが「制約」ではなく「ドキュメント」になっている
2026年現在、AIを活用した開発について執筆しているデザインシステムの実践者たちは、ある1つの診断にたどり着いています。それはモデル自体の問題ではありません。ほとんどの組織において、トークンやコンポーネントの規約は「人間が遵守することを期待されたドキュメント」として存在しており、「何らかのシステムがチェックする制約」になっていないのです。チャットウィンドウの機能は、パレットにない色が使われた出力を拒絶することはできません。
つまり、モデルは記憶と「善意」だけでその仕事をこなすよう求められているのです。仮にモデルがあなたのパレットを完璧に記憶していたとしても、それは強制力（enforcement）を持ちません。それは、もっともらしく見える他の何百万ものデザインシステムを学習したAIによる、「知識に基づいた提案」に過ぎないのです。
ブレ（drift）はセッション間だけでなく、単一のセッション内でも発生する
多くの人が報告する最も不可解な失敗は、同じ会話内の連続する2つのプロンプトの間で一貫性が失われる現象です。スレッドの最初の方で生成されたコンポーネントと、今生成されたバリアントが一致せず、誰も変更を指示していないにもかかわらず仕様が変わってしまいます。
これは、ロングコンテキスト（長文コンテキスト）における一般的な問題が、特定の形で現れたものです。長い入力の中央にある情報は、最初や最後にある情報よりも利用される信頼性が低くなります。これが、ChatGPTが同じ会話の前の発言を忘れるメカニズムです。最初に貼り付けたトークンリストはスレッドの最上部にあります。メッセージが40件目になる頃には、その情報は入力の中で最も注意が向きにくい位置に追いやられ、モデルは不足した情報を「それらしい何か」で埋めてしまうのです。
捏造されたトークン名は最も見つけるのが難しいエラーである
ハルシネーション（幻覚）によるAPIエラーは例外をスローします。しかし、ハルシネーションによるトークン名は単なる文字列です。var(--color-brand-600) はエラーを出さずにサイレントに失敗するか、フォールバックされるか、あるいはレビューをすり抜けるほど近い色でレンダリングされます。あなたの命名規則に沿って捏造された名前は、ランダムな名前よりも危険です。なぜなら、いかにも本物らしく見えるからです。
開発チームがデザインシステムのブレを「破壊」ではなく「蓄積」と表現するのはこのためです。エラーは発生せず、個々の差分（diff）は問題なさそうに見えますが、6週間後にはプロダクトに4つの異なるボタンスタイルが存在することになります。
よく試される対策
毎回トークンとコンポーネントのリストを貼り付ける。 効果はありますが、徐々に衰退します。スレッドの最初の3メッセージ目までは最もよく機能しますが、タスクのたびに貼り付けるコスト（トークン消費）が発生します。また、スレッドが長くなりやすいため、位置による情報のブレ（positional drift）が発生する原因にもなります。
重要なルールをカスタム指示に含める。 余白のスケール、2つのフォントルール、「トークン名を絶対に捏造しない」など、いくつかの重要な制約を課すには正しいアプローチです。ただし、このブロックは小さくグローバルに適用されるため、すべての作業において最も重要な5つの事実を厳選する必要があります。これは実用的ですが、部分的な解決にしかなりません。また、これは設定した指示が反映されないという別の問題とは区別する必要があります。
デザインシステムのドキュメントを添付したプロジェクト（Project）を作成する。 標準機能の中では最善の選択肢です。スコープが適切に限定され、言い換えではなく実際のドキュメントを保持できます。制限としては、ChatGPT限定であること、長いセッションではアップロードされたファイルがコンテキストから外れてしまうこと、そしてプロジェクト外でちょっとした質問をしたときには機能しないことが挙げられます。
Figmaのスクリーンショットを渡す。 レイアウトの意図を伝えるには適していますが、名前の指定には役に立ちません。ボタンの画像を見せても、プロパティのシグネチャは伝わりませんし、見た目が似ている4つのボタンのうちどれが非推奨（deprecated）なのかを判別することも不可能です。
システムを詰め込んだカスタムGPTを作成する。 一歩前進ですが、メンテナンスがネックになります。デザインシステムは毎週更新されますが、カスタムGPTのファイルは誰かが手動で更新しない限り古いままです。古くなったシステムが自信満々に適用されるのは、システムが全くない状態よりも厄介です。
AIを実際のコンポーネントライブラリに接続する。 これこそが、ループを完全に閉じる（解決する）方向性であり、単なる補足以上の価値があります。同期されたライブラリ、Code Connectスタイルのマッピング、またはデザインシステム用のMCPサーバーを介して、生成を「実在するコンポーネント」に制限すれば、ブランドから外れた出力は記憶力（recall）の問題ではなくなります。チームがここに投資できるのであれば、ぜひそうすべきです。チャットウィンドウが提供するどのような方法よりも堅牢です。
このリストに共通するパターンは、機能するものはすべて「強制（enforcement）」か「検索（retrieval）」のどちらかであるということです。失敗するものはすべて「繰り返しによる記憶（memory-by-repetition）」に頼っています。
解決策：ChatGPTにシステムを与え、パイプラインに強制力を持たせる
問題を冷静に切り分けましょう。なぜなら、問題の半分はメモリの問題ではないからです。
機械的な半分は、ビルドプロセスの役割です。 トークンをコードが消費する成果物（artifact）にコンパイルし、システムに存在しない値が解決されないようにします。生の16進数カラーコード、スケール外の余白、未知のトークン名を拒否するリントルールを追加し、CIで実行します。コンポーネントライブラリを、コンポーネントの唯一の信頼できる情報源（source of truth）として維持してください。リントルールは忘れることがなく、もっともらしい名前に騙されることもなく、会話がどれだけ長くなったかも気にしません。この方法で表現できるものはすべて、メモリではなくこの方法で表現してください。
強制できないもう半分の情報は、検索可能（retrievable）にする必要があります。 なぜコンパクトなテーブルバリアントが存在するのか、アクセシビリティ監査の後に古いモーダルが非推奨になった理由、特定のパターンが2回却下された背景、あるいは一見どちらも正しそうに見える2つのコンポーネントのうちどちらが最新のものなのかを、リインター（linter）は知り得ません。こうした知識は文章（prose）であり、変化するものであり、あなたが現在AIに何度も説明し直している内容そのものです。これは、コピペ用のバッファではなく、アシスタントがリクエストごとに読み込めるストアに保存されるべきです。
MemoryLake は、この後半部分のためのメモリレイヤーです。デザインシステムのドキュメント、トークン定義、非推奨情報、そしてその背景にある決定事項を1つのストアにまとめ、API経由でChatGPTから、またMCP対応ツールを介してClaudeやCodexから直接読み取ることができます。境界線を明確にしておくと、MemoryLake自体は何も強制しませんし、デザインシステムそのものでもありません。強制するのはあなたのパイプラインであり、MemoryLakeはシステムを利用可能かつ最新の状態に保つためのものです。
ステップ 1: APIキーを作成する
キーを生成すれば、約30秒で最初のリクエストを送信できます。キーはチャットウィンドウに貼り付けるのではなく、環境変数やシークレットマネージャーに保存してください。
ステップ 2: 最初のメモリをアップロードする
現在コピペしているドキュメント、画像、ファイルをそのまま投入します。実際に定義されているトークン定義、コンポーネントのAPIリファレンス、日付付きの非推奨リスト、アクセシビリティに関する決定事項、却下されたパターンとその理由などです。整理されたサマリーではなく、ソースファイルをそのままアップロードしてください。サマリーにしてしまうと、「16pxのステップは存在しない」が「一貫した余白を好む」に変換されてしまいます。
ステップ 3: AIとエージェントを接続する
Claude、Codex、OpenClaw、その他のAIエージェントに、MCPまたはAPI経由でメモリへのアクセス権を付与します。ChatGPTにはMCPクライアントがないため、APIを介してシステムの関連部分を取得し、プロンプト、カスタムGPTの指示、またはモデルを呼び出すワークフローに注入します。MCPに対応したツールは同じストアを直接読み込みます。コンポーネントを記述するエージェントには、それを設計するアシスタントと同じシステムが必要であるため、これは非常に重要です。
実務における変化
第一の変化は、捏造されたトークン名がほとんど現れなくなり、万が一すり抜けた場合でも確実に検知されるようになることです。検索（retrieval）が生成時に本物の名前を提供し、リインターがコミット時にそれ以外のものを拒否します。どちらか一方だけでは不十分であり、両者が組み合わさることでループが完成します。
第二に、スレッドを長く保つ必要がなくなります。リクエストと同時にシステム情報が提供されるため、3,000トークンものパレット情報を最初から詰め込み、それが40番目のメッセージまで残っていることを祈る必要はありません。モデルが最も信頼性を発揮するのは短いスレッドであり、コンテキストを何度も説明し直す必要がないからこそ、短いスレッドを気軽に使い回すことができます。
第三に、非推奨（deprecation）の仕組みがようやく機能するようになります。現状では、前四半期に廃止したコンポーネントがモデルの世界にはまだ存在しています。それはあなたの命名規則に似ており、コードベースにも登場したことがあり、それが廃止されたことを示すマークはどこにもありません。日付とステータスが記録されて初めて、現在のものと過去のものを区別できます。これは、アーキテクチャの決定にその理由を付随させる必要があるのと同じ理由です。
そして、これはChatGPT特有の問題ではなくなります。デザインシステムは、チャットウィンドウだけでなくコーディングエージェントも同様に制約します。プロジェクトのコンテキストを持たずに起動するアシスタントは、あらゆるツールで共通する課題です。1つのストアを、すべてのリーダー（ツール）が参照するようになります。
AIとデザインシステムのためのベストプラクティス
機械的なものは強制し、文脈的なものは検索する
値、名前、スケール、コンポーネントの境界は、トークンとリントルールに落とし込みます。根拠、非推奨情報、例外、却下されたパターンは、検索可能なレコードに保存します。この切り分けをどちらか一方に誤ることが、多くの不満の根本原因です。開発チームは意図をリントしようとしたり、値を記憶させようとしたりしてしまいます。
システムのマシンリーダブル（機械可読）なバージョンを提供する
トークンがFigmaファイルやスライド資料の中にしか存在しない場合、人間であれモデルであれ、すべての利用者は推測に頼ることになります。信頼できる情報源から生成されたJSONやCSSの成果物こそが、強制と検索の両方を可能にするものであり、このリストの中で最もレバレッジの高い取り組みです。
非推奨には日付を明記し、古いエントリーも残しておく
廃止されたコンポーネントをドキュメントから削除してしまうと、それをまだ使用しているコードについて説明する手段が失われます。非推奨マークを付け、日付を明記し、代替となるコンポーネント名を記載してください。コードベースと乖離している日付のないデザインシステムは、「7月時点」と正直に書かれているシステムよりも不親切です。
常時読み込ませる情報は「厳格な制約」に限定する
すべてのリクエストに注入する情報は、単に「作法に反する」だけでなく、「出力として完全に誤り」となるルールに限定すべきです。例えば、余白のスケール、パレット、「トークン名を絶対に捏造しない」などです。コンポーネントの完全なリファレンスは検索（retrieval）に任せるべきです。すべての質問の前にデザインシステムの膨大な歴史を突きつけると、肝心の質問が埋もれてしまいます。
コードを要求する前に、使用する名前を答えさせる
規模の大きな作業では、モデルに使用予定のトークンとコンポーネントをまず列挙させ、そのリストを確認してから生成に進ませます。90行のCSSを注意深く読み込む代わりに、5つの名前を30秒でレビューするだけで済み、特に「もっともらしい名前の捏造」を効果的に防ぐことができます。
AIにシステムを定義させない
魅力的な近道として、モデルにトークンを提案させ、その出力を正典（canon）として扱ってしまうことがあります。しかし、それでは誰も決定に関与していないシステムが出来上がってしまいます。モデルはデザインシステムの「消費者」であり、「作成者」ではありません。
結論
ChatGPTがデザインシステムを忘れるのは、製品内にデザインシステムを保持する場所がないからです。ルールファイルはなく、カスタム指示は小さくグローバルであり、プロジェクトファイルは限定的で、メモリはトークンテーブルではなく好みを要約した1ページ程度の情報を保存するだけです。さらに、多くの組織においてトークンは制約ではなくドキュメントとして扱われているため、仮に完璧に記憶していたとしても、それは単なる「知識に基づいた提案」に留まります。
解決策は2つの側面からなり、どちらも欠かすことはできません。トークンをコンパイルし、違反をリントし、実在するコンポーネントに生成を制限します。リントルールは決して忘れないからです。そして、リインターでは表現できない部分（理由、非推奨、例外、却下されたパターン）を、アシスタントがリクエストごとに読み込める1つのストアに保存します。そうすることで、パレットは「毎回貼り付けるもの」から「システムが最初から知っているもの」へと変わるのです。