長時間AI開発の現実：コンテキストの壁と、メモリ運用
目次
AIと長く開発していると、必ず同じ壁にぶつかります。AIが、最初のほうを忘れていくのです。
会話が長くなると、AIは過去のやり取りを要約して圧縮します（Compactingと呼ばれる仕組みです）。長い履歴をそのまま抱え続けられないので、仕組みとしては理にかなっています。ただ、要約は便利なぶん、細部を落とします。仕様の細かな数値、「なぜそう決めたか」の背景、一度ハマって避けると決めた落とし穴といった細部が、要約のたびに薄れていきます。
コンテキストの壁
厄介なのは、要約された会話を頼りに作業を続けると、知らないうちに元の仕様からズレることです。
AIは、手元に残った（要約済みの）文脈をもとに、それらしく実装を進めてしまいます。単体ではもっともらしく動くのに、最初に決めたはずの仕様とは食い違っています。長時間セッションでいちばん多い手戻りは、ここから生まれます。「さっき確認したから大丈夫」という感覚そのものが、要約で薄まった記憶に乗っているのかもしれません。
正とするのは、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は、何でも魔法のように覚えてくれるわけではありません。忘れることを前提に、忘れて困るものを外に置きます。地味ですが、これが長時間AI開発の、いちばん現実的な作法でした。
このメモリ運用にたどり着くまでの道のりは マイクロSaaSの技術スタックは、1年でこう変わった に、品質をどう担保するかは ClaudeとCodexの二刀流レビュー に書きました。開発まわりの他の記事は dev カテゴリ にまとめています。
こうした工夫を積み重ねて作っているのが、PentaTrailです。自分たちの開発の話をしてきましたが、同じ「AIで継続的に見張る」発想は、会社の攻撃面にもそのまま使えます。
