第3回：ローカルLLMで数日開発するための“外部メモリ”戦略
サブタイトル：Token Limit Summaryの活用と、再現性を生む「コンテキスト・エンジニアリング」
はじめに
全3回の連載も、いよいよ最終回です。
第2回では、ローカルLLMの暴走を防ぐために、タスク分割とTOMLカスタマイズでコンテキストを制御する方法を紹介しました。
しかし、どれだけタスクを細かく分けても、中規模以上の開発を数日間続けていると、どうしても避けられない問題があります。
それが、コンテキスト制限による記憶の断絶です。
会話が長くなるほど、AIは過去の前提を見失いやすくなります。
その結果、
- 以前決めた仕様を忘れる
- 既に解決したバグを再び直し始める
- 同じ説明を何度も繰り返す
といったことが起こりやすくなります。
今回は、この問題を運用でどう乗り越えるか。
私たちが実際に試して効果があった、外部メモリ化の方法と、長期開発を支えるコンテキスト管理についてまとめます。
1. 最大の敵は「コンテキストの飽和」
ローカルLLMを数日単位で使っていると、チャット履歴や指示内容が少しずつ積み重なり、最終的には扱いきれなくなります。
具体的に起こること
- 会話履歴が長くなりすぎて、重要な前提が埋もれる
- 以前の仕様と最新のコードを取り違える
- 同じ修正を繰り返す
- 出力の途中で話がそれる
これは単なる「記憶力が悪い」という話ではなく、
コンテキストの上限に近づくほど、AIが判断に使える情報が雑になることが原因です。
特に、実装・修正・確認を何往復もする開発では、この問題が顕著になります。
2. セッションを壊して引き継ぐという発想
私たちが採用したのは、会話を無理に延命するのではなく、適切なタイミングで区切って再構築する方法です。
そのために使ったのが、引き継ぎ用ファイルである Token Limit Summary.md です。
これは、私たちが運用のために用意した外部メモリ用の要約ファイルです。
考え方
セッションが長くなりすぎる前に、
- 現在の進捗
- 解決済みの問題
- 未解決の課題
- 次にやるべきタスク
を1つのファイルにまとめておきます。
そして新しいセッションでは、そのファイルと仕様書を読み込ませることで、
会話履歴はリセットされていても、開発の文脈は維持する、という運用にします。
こうするメリット
- 履歴に引きずられにくい
- 古い前提が混ざりにくい
- セッションをまたいでも再現性が高い
- 長期開発でも迷子になりにくい
この方法は、単なるメモではなく、外部メモリとして機能させるのがポイントです。
3. Token Limit Summary.md に何を書くか
引き継ぎファイルは、長ければよいわけではありません。
大事なのは、次のセッションで本当に必要な情報だけを残すことです。
入れておくとよい内容
- 現在の実装状況
- 直近で修正した内容
- まだ残っている不具合
- 次に着手するタスクID
- 重要な設計上の前提
あえて入れすぎないほうがよい内容
- すでに終わった細かい議論
- 途中で却下した案のすべて
- 冗長なやり取りのログ
要するに、次のセッションがすぐ動けるようにするための、
最小限の要約ファイルとして扱うのがちょうどいいです。
4. モデルは「固定」より「使い分け」
長期開発では、常に同じモデルを使い続ける必要はありません。
むしろ、作業内容によってモデルを切り替えたほうが安定することがあります。
使い分けの考え方
- 実装が得意なモデル
- 速度が速いモデル
- 難しい判断が得意なクラウドモデル
このように、役割ごとに使い分けると作業しやすくなります。
実際の感覚
- 日常的な実装はローカルLLM
- 仕様の整理や複雑な判断はクラウドAI
- 詰まったときは別モデルで見直す
このように、「1つのモデルに全部やらせない」ことが、長く安定して開発するコツでした。
5. ローカルLLM運用に必要な設定の考え方
長期運用で重要なのは、モデルの性能そのものだけではありません。
どういう条件で動かすかも非常に重要です。
代表的なポイント
- コンテキストサイズ
- 温度設定
- 読み込むファイルの範囲
- 1回あたりのタスク量
たとえば、コーディング用途では、温度を低めにして、出力のブレを抑えるほうが安定しやすいです。
また、1回でやらせる仕事が大きすぎると、どれだけ高性能なモデルでも破綻しやすくなります。
6. 「プロジェクト憲法」で品質を揃える
個人運用では、ある程度の試行錯誤で回せます。
しかしチーム開発では、AIの出力品質を揃える必要があります。
そのために有効だったのが、constitution.md のようなルールファイルです。
これは、AIに毎回判断させるのではなく、開発時の原則を先に固定しておくためのものです。
例として入れていた方針
- テストを先に考える
- 1つの関数をむやみに大きくしない
- 仕様を推測で補完しない
- 明示的な許可なく既存コードを大きく消さない
こうしたルールがあると、誰が使っても一定の品質を保ちやすくなります。
これは何のためか
AIは強力ですが、毎回「その場で最適解を考える」設計にすると不安定になります。
そこで、判断の土台をあらかじめ文章化しておくことで、運用の揺れを減らします。
7. エンジニアの仕事は「コンテキストを設計すること」へ
ここまでの検証を通じて、強く感じたことがあります。
それは、これからのエンジニアに求められる価値は、単にコードを書くことだけではなく、
AIに何を渡し、何を渡さないかを設計することだということです。
重要になるのは次の3つです
- どの情報をAIに渡すか
- どのタイミングでセッションを切るか
- どうやって文脈を再構築するか
この考え方を、私たちは便宜的に
「コンテキスト・エンジニアリング」
と呼んでいます。
これは難しい理論ではなく、実務で使える運用の知恵です。
おわりに
ローカルLLMを長期開発に使うには、モデルの性能だけでなく、運用の設計が欠かせません。
- 仕様を先に固定する
- タスクを分ける
- セッションを適切に切る
- Summary.mdで引き継ぐ
- ルールを文章化して品質を揃える
この一連の流れができると、ローカルLLMは「その場しのぎのAI」ではなく、
長く付き合える開発パートナーになります。
3回にわたって見てきた内容をまとめると、ローカルLLM開発の要点は次の5つです。
- VRAM16GBが快適ラインになりやすい
- タスクは必ず分割する
- セッションはリセット前提で運用する
- Summary.mdで外部メモリ化する
- Specを真実の源泉にする
この連載が、ローカルLLMを実務で使う際の参考になれば幸いです。