ChatGPTがテストケースを忘れてしまう理由と、その解決策 (2026)

そもそもあなたのテストスイートを最初から持っていない

テストスイートは、数百のケース、命名規則、フィクスチャ、タグ付けのルール、何がカバーされていて何があえてカバーされていないかの暗黙のマップなど、大規模で構造化され、進化し続ける成果物です。これらは、会話の中で提供しない限りモデルには伝わりません。その結果、得られるのは一般的なベストプラクティスに基づいたテストスイートになります。単体で見れば合理的ですが、あなたのリポジトリにとっては間違ったものになってしまいます。

アップロードしたファイルはチャット終了と同時に消滅する

テストスイートをアップロードすることは、そのチャット内では有効です。会話が続いている間はコンテンツを利用できますが、チャットが終われば消えてしまいます。新しいチャットは、そのファイルが存在したことすら認識せずに始まります。これは、ChatGPTがアップロードされたファイルを忘れてしまう理由で説明されているのと同じ壁です。毎週変更されるテストスイートの場合、再アップロードは面倒な作業であり、徐々に実際のコードと乖離していきます。最新バージョンを毎回アップロードし直す人はほとんどいません。

組み込みメモリは「好み」を保存するものであり、「カバレッジ」を保存するものではない

ChatGPTのメモリ機能は、ユーザーの役割、トーン、常時適用したい指示などを保持するように設計されています。これは非常に便利ですが、タグ、所有者、根拠を含む400個のテストケースのインデックスではありません。メモリ機能にカバレッジマップを保持させようとするのは、その機能が想定していない仕事を任せるようなものです。そして、その失敗は静かに起こります。モデルは、古い記憶に基づいて自信満々に回答してしまうのです。

最も価値のあるQAコンテキストは「歴史」である

最も重要なテストは、何かが壊れた後に書かれたテストです。その価値は「経緯」にあります。このアサーションが存在するのは、本番環境で一部返金が二重にクレジットされたためであり、あのリトライテストが存在するのは、決済ゲートウェイが30秒でサイレントタイムアウトしたためです。こうした歴史は、インシデントの報告書、チケットのスレッド、そして当時オンコール対応していた人の記憶の中に存在しており、今朝開いたチャットの中にはありません。関連する問題は、ChatGPTがプロジェクトのコンテキストを忘れてしまう問題や、テストが検証すべき要件を見失ってしまう問題（ChatGPTが製品要件を忘れてしまう問題で解説）として現れます。

巨大なプロンプトテンプレート

一般的な回避策は、技術スタック、命名規則、ユーザーロール、ビジネスルールをまとめた再利用可能なブロックを、すべてのセッションの冒頭に貼り付けることです。これは機能しますが、コストがかかります。リクエストのたびにそれらのトークン代を支払うことになり、テンプレートはコードベースと同期しなくなって古くなり、命名規則が変更されたスプリントの後に誰もそれを更新しなくなります。

セッションごとにテストスイートを再アップロードする

テンプレートよりも正確ですが、より面倒であり、コンテキストウィンドウに収まる量やモデルが有効に読み取れる量に制限されます。また、これは悪いインセンティブを生みます。面倒であるため、人々はテストスイートの一部だけをアップロードするようになり、モデルは見えていないカバレッジについて推論することになります。

Custom GPTsまたは専用のプロジェクト

これは確実な改善策です。指示と参照ファイルが一箇所にまとまり、チームで共有できます。しかし、依然として手動で維持する必要があるサイロです。カバレッジが変更されてもファイルは自動的に更新されません。また、実装を書くコーディングエージェントや、リリースを要約するアシスタントからはその情報にアクセスできません。同じテストスイートに対して2つの真実のソース（Source of Truth）が存在することが、矛盾の始まりとなります。

仕様書を丸ごと貼り付ける

長いコンテキストウィンドウが利用できるため、仕様書を貼り付けたくなります。しかし、仕様書は「意図」を記述するものであり、「カバレッジ」を記述するものではありません。また、どのケースがすでに存在しているかについては何も教えてくれません。結果として重複が発生し、誰も400個のテスト名を頭の中に保持できないため、その重複はレビューを通過してしまいます。

この繰り返しを終わらせるパターンは、QAコンテキストを単一のチャットの外にあるメモリレイヤーに保持し、モデルにそこから読み取らせることです。MemoryLakeはそのために構築されています。命名規則、カバレッジマップ、インシデント履歴を一度保存すれば、作業を行うアシスタントやエージェントがいつでも取り出すことができます。

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

キーを生成し、約30秒で最初のリクエストを実行できます。

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

チームのテスト方法を定義するドキュメント、画像、ファイルを投入します。命名規則やタグ付けのルール、カバレッジマップ、テスト計画、受入基準、レグレッションテストを作成するきっかけとなったバグのポストモーテム、および理由付きのフレーキーテスト（不安定なテスト）のリストなどです。

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

Claude、Codex、OpenClaw、およびその他のエージェントに、MCPまたはAPIを介してそのメモリへのアクセス権を与えます。ChatGPTの場合、APIを通じて関連するメモリを取得し、会話やQAツールに流し込みます。これにより、モデルは一般的なテストスイートではなく、実際のテストスイートに基づいて動作を開始できます。重要なのは、すべてが同じソースを読み取ることです。コードを書くエージェントとテストを書くアシスタントの間で、何が存在するかについての意見の食い違いがなくなります。

繰り返しのコストを計算してみましょう。QAエンジニアが週に10回、セッションの開始時に5分間モデルに状況を説明し直すとしたら、1人あたり毎週約1時間が、変更されていない内容を再説明するために費やされていることになります。もし常時送信するコンテキストブロックが2,500トークンで、チーム全体で1日に30回送信されるとすると、1日あたり75,000トークン、月に約220万トークンを、同じことを繰り返すためだけに支払っていることになります。

請求書に現れないコストはさらに大きくなります。テストスイートの実行時間を引き延ばす重複ケース、モデルが何が欠けているかを知らないために誰も気づかないカバレッジのギャップ、そして理由が記録されていないために静かに再検証されてしまうレグレッションテストなどです。メモリはモデルをより優れたテスト設計者にするわけではありません。あなたのテストスイートを熟知したテスト設計者にするのです。

すべてのアサーションではなく、スイートの「形状」を保存する

メモリに400個のテスト本体をすべて入れる必要はありません。必要なのはマップです。モジュールとそのカバレッジレベル、命名およびタグ付けのルール、意図的にテストしていないもの、信頼できるスイートと不安定（flaky）なスイートはどれか、といった情報です。これは1〜2ページ程度で済み、まさにモデルに欠けている情報です。

各レグレッションテストが存在する理由を記録する

インシデントから生まれたテストごとに、症状、根本原因、日付を1行で記録します。これは保存すべき最も価値のある情報です。なぜなら、人が離職したときに失われやすい知識であり、6ヶ月後に「不要なテスト」として削除されるのを防ぐものだからです。

カバレッジと同じプルリクエストでメモリを更新する

メモリの更新が別の作業になっていると、メモリはすぐに陳腐化します。変更と紐付けましょう。命名規則が変わったり、スイートが廃止されたりしたときは、同じPRで保存されている事実を更新します。新しい情報を追記するよりも、古い記述を置き換えることを優先してください。古いQAコンテキストは、存在しないよりも悪影響を及ぼします。モデルも人間もそれを信頼してしまうからです。この習慣は一般化できます。これは、AIにコンテキストを再説明するのをやめるの背後にある規律と同じです。

ChatGPTがテストケースを忘れてしまうのは、そもそもそれらを保持したことがないからです。ChatGPTはテストスイートの全体像を持っておらず、アップロードされたファイルはチャットの終了とともに消え、組み込みメモリはカバレッジマップではなくユーザーの好みを保持します。プロンプトを改善しても、この事実は変わりません。説明し直す時間が長くなるだけです。

テストスイートの形状、命名規則、インシデント履歴を、ツールが読み取れるメモリレイヤーに配置しましょう。そうすれば、モデルの出力は「それらしいもの」から「実用的なもの」へと変化します。あなたの命名スタイルに沿い、実際にカバーされていない部分を狙い、チームが過去に一度痛い目を見たバグを考慮したテストケースが生成されるようになります。これは、たった一度だけ、適切に書き留めておく価値のある情報です。