なぜChatGPTはアーキテクチャ設計の決定事項を忘れるのか、そしてその解決策（2026年版）

決定とは「制約」と「理由」の組み合わせである

「サービス間でデータベースを共有しない」というのは、決定の半分にすぎません。もう半分は、マイグレーションの順序が原因で2回の障害が発生し、スキーマを所有するチームがすべてのデプロイを監視するわけにはいかないからという理由です。この後半部分がなければ、前半部分は単なる「好み」になってしまいます。そして「好み」は、もっともらしく聞こえる代替案に毎回負けてしまうのです。

これこそが、ADR（アーキテクチャ決定記録）という手法が存在する理由です。ADRは、決定事項をそれを強いたコンテキスト（背景）およびその結果生じる影響とペアにします。なぜなら、単なる決定事項だけでは、新しいメンバーや新しい状況に直面したときに生き残れないことを、多くのチームが身をもって知っているからです。AIアシスタントは、セッションごとに「新しいメンバー」になるのです。

「理由」こそが要約されて消えてしまう

これが単なる「物忘れ」よりも厄介な仕組みです。ChatGPTの保存されたメモリは、すべてのプロンプトと一緒に送信されるため、意図的に短く設計されています。そして、OpenAIが2026年6月に発表したメモリの再構築以降、保存されるのは発言の記録ではなく、システムがあなたについて結論付けた内容を要約（合成）した「メモリサマリー」になりました。

要約（合成）は、小さなメモリを有効活用するためには正しいトレードオフですが、決定事項にとっては最悪のトレードオフです。「マイグレーションの順序が原因で2回の障害が発生したため、データベースを共有しない」を圧縮すると、当然ながら「サービス固有のデータベースを好む」という出力になります。制約は消え、好みが残り、その好みは上書き可能です。結果として、あなたのアーキテクチャを単なる「スタイルの好み」として半分だけ覚えているアシスタントが出来上がります。

却下された選択肢は決して書き留められない

アーキテクチャの議論において最も価値のあるコンテンツは、除外した選択肢のリストとその理由です。しかし、これは誰も記録しないコンテンツでもあります。なぜなら、何かを除外した瞬間には、それが当たり前のように感じられ、わざわざ書く価値がないように思えるからです。

チャットのワークフローでは、これが記録されることはありません。そのため、四半期ごとに同じ3つの代替案が提案され、そのたびに「なぜそれが機能しないのか」を再検証するために20分を費やすことになります。これが、アシスタントがすでに却下したアイデアを何度も蒸し返すパターンの背景にある原因です。

コーディングエージェントとは異なり、専用のファイルが存在しない

コーディングエージェントは、リクエストごとにファイルを読み込むことで、この問題の「可用性」の半分を解決しました。だからこそ、Cursorがアーキテクチャ設計の決定事項を忘れる問題は、通常、より優れたルールファイルを書くことで解決できます。

ChatGPTにはそれに相当するものがありません。回答前に読み込むパスは存在しません。カスタム指示（Custom instructions）は容量が小さく、グローバルに適用されます。プロジェクト（Project）の添付ファイルはそのプロジェクト内に限定されます。メモリは1〜2ページ程度です。これらはどれも決定ログではないため、あなたのアーキテクチャは、最後にそれを議論したチャットの中にしか存在しなくなります。

決定は変化するが、古い決定は撤回されない

アーキテクチャは、あなたがバージョン管理しているかどうかにかかわらず、バージョンが存在します。第3四半期にテナンシーモデルを改訂した場合、第2四半期のモデルに基づいて行われたすべての設計は、当時は正しかったことになります。チャットベースのワークフローには、ある決定が特定の日に別の決定に取って代わられたことを記録する場所がありません。そのため、過去の自分の仕事を解釈できなくなってしまいます。これこそが、ADRが「ステータス」フィールドによって防ごうとしている失敗パターンです。

毎回説明し直す。 一時的には機能しますが、徐々に劣化します。記憶を頼りに説明し直すことになるため、9月に書き込む内容は、7月に苦労して導き出した決定事項の「印象的な半分」だけになり、退屈な「制約」の部分は抜け落ちてしまいます。

主要な決定事項をカスタム指示に入れる。 2〜3個の重要な制約に対する最初のステップとしては正しく、試す価値があります。ただし、入力枠が小さいため、最も重要な決定を厳選する必要があります。また、グローバルに適用されるため、複数のシステムを並行して開発している場合には適していません。

決定事項をメモリに保存する。 安定したいくつかの決定事項であれば問題ありませんが、すぐに2つの壁にぶつかります。1つは容量不足（メモリがいっぱいになり、新しいエントリを受け付けなくなる）、もう1つは、生き残るのが論理的根拠ではなく要約されたパラフレーズ（言い換え）になってしまうことです。

アーキテクチャドキュメントを添付したプロジェクト（Project）を作成する。 標準機能の中では最善の選択肢です。スコープが適切で、要約ではなく実際のドキュメントを保持できます。ただし、ChatGPT限定の機能であり、長いセッションではファイルの内容がコンテキスト内に確実に残り続けるとは限りません。また、通常のチャットでのちょっとした質問には役に立ちません。

リポジトリにADRを書き出す。 これがプロフェッショナルとしての回答であり、曖昧にせず明確に述べる価値があります。決定、コンテキスト、結果、ステータスを記載した、連番付きの docs/adr/ ディレクトリを作成し、コミットしてレビューを受ける。これこそが、アーキテクチャの論理的根拠を保存する本来の方法です。メンバーの離職にも耐え、差分（diff）を確認でき、特定のベンダーに依存しません。もしあなたのチームがまだこれをやっていないなら、今すぐ始めてください。この記事の他のどの内容よりも価値があります。

課題は、リポジトリにあるADRが、あなたが実際に思考を共にしているアシスタントからは見えないということです。せっかく論理的根拠を書き留めても、ChatGPTはそれを参照できないため、関連するADRをコピー＆ペーストするか、あるいは（多くの場合）ペーストするのを忘れてしまいます。

次の2つのステップを、この順序で実行します。

簡易的であっても、決定事項をADRの形式で書く。 タイトル、ステータス、それを強いたコンテキスト、決定内容、除外したもの、受け入れた結果、そして日付。ツールよりも「形式」が重要です。これによって、制約に理由が紐づいた状態を維持できます。これこそが、この記事で指摘している失敗を防ぐ鍵です。「検討した代替案（Alternatives-considered）」はオプションのセクションではありません。同じ議論の蒸し返しを防ぐための最も重要な部分です。

次に、その記録をアシスタントからアクセス可能にする。 コピペするのではなく、自動で「取得（リトリーバル）」させます。アシスタントがリクエストごとに読み込むストアを用意することで、決定事項が要約されることなく、あなたが書いたそのままの形式で、理由、日付、却下された代替案とともに届くようになります。

MemoryLake は、そのために構築されたメモリレイヤーです。決定記録、制約、ソースドキュメントを1つのストアにまとめ、API経由でChatGPTから、またMCP（Model Context Protocol）対応ツールを介してClaudeやCodexから直接読み込むことができます。これにより、同じ決定事項が、設計の議論、マイグレーションコードを書くコーディングエージェント、そして9月に新しく加わったエンジニアのすべてに共有されます。

明確にしておくべき境界線が2つあります。第一に、メモリレイヤーはチームガバナンスのための「コミットされたADR」に代わるものではありません。バージョン管理されていない決定記録はレビューできず、レビュー可能であることこそがADRの実践の目的の半分を占めるからです。第二に、決定事項を確実に提供することで、AIがそれを遵守する確率は大幅に上がりますが、100%遵守することを保証するものではありません。それはモデルの挙動に依存するからです。変わるのは、制約とその理由が、欠落したり言い換えられたりすることなく、最新の状態でそこに「存在する」ようになるという点です。

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

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

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

決定事項が実際に記載されているドキュメント、画像、ファイルをそのまま投入します。ADR、設計書、制約の原因となったインシデント報告書、誰かが書き全員が合意したRFCなどです。整理された要約ではなく、ソース（一次情報）をそのままアップロードしてください。要約してしまうと、「2回の障害が発生したため」が「サービス固有のデータベースを好む」に変換されてしまいます。

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

Claude、Codex、OpenClaw、その他のAIエージェントに、MCPまたはAPI経由でメモリへのアクセス権を付与します。ChatGPTにはMCPクライアントがないため、APIを使用します。関連する決定事項を取得し、プロンプト、カスタムGPTの指示、またはモデルを呼び出すワークフローに注入します。MCPに対応しているツールは、同じストアを直接読み込むことができます。コードを書くエージェントが、設計を行うアシスタントと同じ制約を必要とするため、これは非常に重要です。

第一の変化は、却下された選択肢が却下されたままになることです。レポートサービスについて尋ねた際、共有スキーマのアプローチが再び提案されることはなく、障害の履歴が添付された状態で「すでに除外された案」として返ってきます。

第二に、設計の議論をより進んだ段階から開始できるようになります。最初の15分間を制約の再確認に費やす必要はなく、本来の問いに集中できます。これは複利的に効果を発揮します。記録に決定事項が蓄積されるほど、新しい会話が引き継ぐ前提知識が増えるからです。

第三に、古い決定事項が混乱を招くことなく、正しく解釈できるようになります。日付とステータスが記載された決定事項があれば、「そのサービスは8月以前のテナンシーモデルに基づいて構築された」と判断でき、「なぜこの設計になっているのか」と悩む必要がなくなります。これこそが、過去のアーキテクチャを解釈可能にする唯一の特性です。

そして、これはChatGPTに限った話ではなくなります。テナンシーに関する決定は、設計の議論だけでなく、コーディングエージェントをも制約します。プロジェクトのコンテキストを持たずにアシスタントが起動する問題は、あらゆるツールで共通の課題です。記録が共有ストアにあれば、すべてのツールがそれを継承できます。

決定を強いたコンテキスト（背景）を必ず書く

「注文にはイベントソーシングを使用する」という記述は、議論を誘発します。しかし、「財務部門が再構築可能な監査トレイルを求めており、以前の可変状態設計が第1四半期の監査で不合格となったため、注文にはイベントソーシングを使用する」と書けば、議論はそこで終わります。コンテキストこそが「好み」を「制約」に変えるものであり、記憶を頼りに説明し直す際に真っ先に失われる部分です。

選んだものだけでなく、却下したものも記録する

代替案ごとに2行で記録します。「何であったか」と「なぜ不採用なのか」です。これは最も価値が高く、最も書かれないセクションですが、四半期ごとに同じ提案が繰り返されるのを防ぐ唯一の方法です。決定事項そのもの以外に何も書かないとしても、これだけは書いてください。

すべてに日付を入れ、古い決定も残しておく

各決定に日付とステータスを付与します。決定が変更された場合は、古いものを削除するのではなく、新しいものを追加し、古いものに「置き換え済み（superseded）」のマークを付けます。古い決定を削除してしまうと、その決定に基づいて書かれたコードを理解する手がかりが失われます。日付のない矛盾した決定事項が存在することは、日付が明記された1つの決定事項があることよりもはるかに悪影響を及ぼします。

常に読み込ませるセットは最小限にする

すべてのリクエストに注入すべきなのは、一握りの「強力な制約」だけにすべきです。これは、単に「作法に反する」だけでなく、「回答そのものが誤りになる」ような制約です。完全な記録はリトリーバル（検索）に任せるべきです。すべての質問の前に膨大なアーキテクチャの歴史を突きつけると、肝心の質問が埋もれてしまいます。

それでもADRはコミットする

メモリレイヤーを導入している場合でも、記録はリポジトリのバージョン管理下に置いてください。ストアはアシスタントがアクセスできるようにし、リポジトリはチームがレビューできるようにします。誰もレビューしていない決定は、本当の意味でのチームの決定とは言えません。それぞれが得意とする用途で両方を活用してください。

ChatGPTがアーキテクチャ設計の決定事項を忘れるのは、制約ではなく「好み」を保持するからです。読み込むルールファイルはなく、メモリはリクエストごとに送信される1〜2ページ程度であり、現在のメモリシステムは保存内容を要約（合成）します。そのため、決定を拘束力のあるものにする「理由」の部分が、まさに圧縮されて消えてしまうのです。

解決策は、昔ながらのアドバイスに新しいステップを1つ加えたものです。決定事項をADRの形式（コンテキスト、決定、却下された代替案、結果、日付、ステータス）で書き、コミットしてください。これこそが、アーキテクチャの論理的根拠をメンバーの入れ替わりを超えて存続させる方法です。そして、その記録をアシスタントがリクエストごとに読み込める場所に配置します。これにより、あなたがペーストするのを忘れても、制約とその理由が常にセットで提供されます。そうすれば、7月に決着した議論は、9月になっても解決されたままになります。