長時間AI開発の現実 ―― コンテキストの壁とメモリ運用
目次
長く話すほど、AIは最初を忘れていく。コンテキストの壁と、その越えかた
AI と長時間、開発を続けていると、ある壁に必ずぶつかります。コンテキスト ―― これまでのやり取りの文脈 ―― が、少しずつ失われていくのです。
会話が長くなると、AI は過去のやり取りを要約して圧縮します（Compacting と呼ばれる仕組みです）。長い履歴をそのまま抱え続けられないので、これ自体は理にかなっている。けれど、要約は便利なぶん、細部を落とす。仕様の細かな数値、「なぜそう決めたか」の背景、一度ハマって避けると決めた落とし穴 ―― そういう細部が、要約の過程で薄れていきます。
コンテキストの壁
厄介なのは、要約された会話を頼りに作業を続けると、知らないうちに元の仕様からズレることです。
AI は、手元に残った（要約済みの）文脈をもとに、それらしく実装を進めてしまう。単体ではもっともらしく動くのに、最初に決めたはずの仕様とは食い違っている ―― 長時間セッションでいちばん多い手戻りは、ここから生まれます。「さっき確認したから大丈夫」という感覚そのものが、要約で薄まった記憶に乗っているかもしれない。
越えかたは、大きく2つ。事実を会話の外に置くこと。 そして、コンテキストをこまめに作り直すこと。 順に書きます。
正とするのは、spec と plan
まず、何を「正」とするか。会話の記憶ではなく、2つの文書 ―― spec（仕様）と plan（実装手順）―― を正とします。
- spec（仕様） は、何を作るかを決める文書です。設計の意図と、守るべき「契約」―― 画面とサーバーのやり取りの形、データベースの列の定義、関数の入出力 ―― を書く。
- plan（実装手順） は、それをどの順番で実装するかの段取りです。各段階の「完了とは何か」を、数値やコマンドで先に書いておく（「この検索が0件」「このテストが通る」のように、機械が判定できる形で）。
そして要(かなめ)が、spec の末尾に置く Appendix（付録） です。契約にかかわる値は、本文のあちこちに散らさず、ここに一箇所だけまとめる。しかも、推測で書かず、“現物”を直接確認した結果として ――「いつ・どの時点の何を確認したか」を添えて ―― 唯一の正として書き出します。本文も plan も、同じ値を書き直さず、「付録の A.1 を見よ」と参照するだけにする。
なぜ、ここまでするのか。同じ事実を二箇所に書くと、いつか片方だけが古くなって食い違う（ドリフトする）からです。一箇所に集約しておけば、要約で記憶が薄れても、付録にあたれば一次情報に戻れる。実装に入る前に、この spec / plan / 付録を毎回読み直す ――「メモリにあるから知っている」「以前これは確認した」と感じたときほど、手を止めて現物を取り直します。要約された自分の記憶より、ファイルに書かれた事実のほうが、つねに正しい。ついでに言えば、セッション開始時に渡される「現状はこうです」という状態すら、少し古いことがある。だから、分岐の前には現物を取り直してから動く。
コンテキストは、こまめに作り直す
もうひとつが、コンテキストそのものの扱い方です。
Compacting は自動で起きますが、その要約はこちらで選べません ―― 何が残り、何が落ちるかを制御できない。しかも、抱えるコンテキストが大きくなるほど、モデルは注意が散らばり、本来の性能を出しきれなくなります。文脈が膨らんだ状態は、人でいえば、散らかった机で考えごとをするようなものです。
そこで、コンテキストの残量を常に見ながら開発し、自動要約に入る前に、きりのいいところで自分からクリアして、新しいセッションを始めます。 クリアすれば、コンテキストはまっさらにリセットされ、モデルは身軽な状態で、本来の力を出せる。
一見もったいないようですが、自動要約に委ねるより、クリアして仕切り直すほうが、ずっと扱いやすい。どこで区切るか、何を次に持ち越すかを、自分で決められるからです。ぼんやりと要約された長い一本のセッションを引きずるより、きれいに区切られた短いセッションを重ねていくほうが、制御が効くし、質も保てます。
引き継ぎは、ファイルで ―― PC とオフィスをまたぐ
クリアする前に、次のセッションへの引き継ぎを残します。ここで使うのが、セッションの状態を書き出す2つの仕組みです。
ひとつは remember ―― Claude Code のプラグインです。いまのセッションの作業ログを、その日ぶんや「直近の数日」といった単位に束ねて書き出し、次の開始時に読み戻せるようにする。「どこまでやったか」を素早く取り戻すための、短期記憶のような役割です。
もうひとつが、自作の memory-write です。これは、こんな課題から生まれました ―― セッションが終わると、せっかくの学びや決定が消えてしまう。しかも、別の PC で続きをやろうとすると、その学びは引き継がれない。そこで、長く効く事実を恒久のメモリとして残すために、自分でプラグインを作りました。やることはこうです: 残したい事実を種類ごと ―― プロジェクトの規約、進行中の作業の状態、そして何より、過去にやらかした失敗とその教訓 ―― に分類し、メモリ用のファイルに書いて、索引を更新し、git にコミットする。
肝は、git に乗せることです。別の PC でも、別のオフィスでも、git pull すれば同じ学びがそのまま手に入る。「この書き方をすると、ここで壊れる」「この前提は間違っていた」―― そうした教訓を一度書いておけば、次のセッションの AI は、どの場所から再開しても、同じ罠を踏まなくなります。会話のコンテキストは持ち運べませんが、ファイルに逃がした事実と引き継ぎは、どこからでも手繰り直せる。場所が変わっても、糸が切れずにつながります。
任せられること、任せられないこと
ここまでをひっくるめると、線引きが見えてきます。
コンテキストの壁は、消えません。だから「全部ずっと覚えていてくれる」前提では使わない。覚えておくべき事実は、AI の記憶ではなく、外（spec・plan・メモリ）に置く。 AI に任せるのは、その事実をもとにした作業のほうです。任せられること（手を動かす作業）と、任せてはいけないこと（事実の保持）を分ける ―― この割り切りができて初めて、長時間でも崩れずに走り続けられる。
魔法のように何でも覚えている相棒ではなく、忘れることを前提に、忘れて困るものを外に置く。地味ですが、これが長時間AI開発のいちばん現実的な作法でした。
このメモリ運用にたどり着くまでの道のりは マイクロSaaSの技術スタックは、1年でこう変わった に、品質をどう担保するかは Claude と Codex の二刀流レビュー に書きました。開発まわりの他の記事は dev カテゴリ にまとめています。
そうして、忘れる相棒とうまく付き合いながら作り続けているマイクロSaaS が、PentaTrail です。外から見える攻撃面を AI で継続的に把握する、CTEM のサービスです。もしよければ、あなたの会社の「外から見える攻撃面」を、一度のぞいてみてください。