長時間AI開発の現実：コンテキストの壁と、メモリ運用

長い履歴をそのまま抱え続けることはできないので、要約そのものは正しい設計です。問題は、何が残って何が落ちるかを、こちらが選べないことにあります。

確認したはずだから大丈夫、という感覚そのものが、薄まった記憶の上に乗っているのかもしれません。だから感覚ではなく、ファイルに書かれた事実のほうを見にいきます。

契約にかかわる値は本文へ散らさず、spec の末尾の付録にまとめました。しかも推測では書かず、現物を直接確認した結果として、いつ・どの時点の何を確認したかを添えて書き出します。本文も plan も同じ値を書き直さず、付録を参照するだけにしてあります。

同じ事実を二箇所に書くと、いつか片方だけが古くなって食い違うからです。一箇所に集約しておけば、要約で記憶が薄れても、付録にあたれば一次情報へ戻れます。「メモリにあるから知っている」と感じたときほど、手を止めて現物を取り直します。

クリアすればコンテキストはまっさらに戻り、モデルは身軽な状態で本来の力を出せます。ぼんやり要約された長い一本のセッションを引きずるより、きれいに区切られた短いセッションを重ねるほうが、制御が効いて質も保てるはずです。文脈が膨らんだ状態は、散らかった机で考えごとをするようなものです。

残すのは、プロジェクトの規約、進行中の作業の状態、そして何より過去の失敗とその教訓です。「この書き方をすると、ここで壊れる」「この前提は間違っていた」と一度書いておけば、次のセッションのAIは、どの場所から再開しても同じ罠を踏みません。会話のコンテキストは持ち運べませんが、ファイルへ逃がした事実は、どこからでも手繰り直せます。

覚えておくべき事実は、AI の記憶ではなく外に置きます。AI に任せるのは、その事実をもとにした作業のほうです。地味ですが、これが長時間AI開発の、いちばん現実的な作法でした。

• マイクロSaaSの技術スタックは、1年でこう変わった
• Claude と Codex の二刀流レビュー：別系統AIで盲点を炙り出す
• MCPとは：AIに「手」を持たせるということ
• 開発まわりの記事（dev カテゴリ）

こうした工夫を積み重ねて作っているのが PentaTrail / CTEM です。同じ「AIで継続的に見張る」発想は、会社の攻撃面にもそのまま使えます。