compaction 問題の解決がもたらした新しい開発体験
Claude Code v2.1.3 has solved the compaction issue
— Numman Ali (@nummanali) 2026年1月10日
Auto compaction works very well if you start with Plan Mode and explicitly ask the model to make a Comprehensive To Do list
Plans and To Dos persist across compaction
Runtime was 52m 54s with beautifully written code
⛩️ pic.twitter.com/NxYGfrX79L
Claude Code v2.1.3 で compaction 問題が解決されたという報告が X で話題になっている。plan モードで TODO リストを明示的に作成・更新しながら実行すると、compaction 後も計画と TODO が保持され、52 分以上の連続実行が可能になったという。
プラン内容は todo.md ファイルに書き出していき、これを確認・修正しつつ思いついたことを追記することで進捗管理をしながら完成に近づけていける。それでもコンテキスト汚染は起こっていくので、区切りごとに
/contextを確認し、/clearや/compaction 覚えておきたいことを実行させることが有効であった。
僕自身も plan 駆動開発と TODO 管理の重要性を実感しており、各機能の大分類から階層構造にブレークダウンしていく WBS（Work Breakdown Structure）を plan.md としてメンテナンスしつつ、個々のタスクを着手順の線形に並べた TODO リストを生成して実装させていくスタイルになってきている。その上で、明示的に /compaction をしなくても覚えておくべきものはファイルに書き出されて、それを元にシーケンシャルな実装をしていくことが可能になったということだ。
これは、20 年前に "ライフハック" として流行っていた GTD の再現であり、計算機科学の基礎となったチューリングマシンの意味的再現に他ならない。本稿では、GTD とチューリングマシンによる AI コーディングエージェントの運用方式について考察したい。
GTD とチューリングマシンとしての Claude Code
そもそも GTD（Getting Things Done）とはデビッド・アレンが提唱したタスク管理手法で、「頭の中にあることをすべてインボックスに書き出して外部化し、信頼できるシステムで管理する」という思想である。脳をワーキングメモリとして使うのではなく、TODO リスト自体は外部記憶に委ねることで認知負荷を下げ、目の前のタスクに集中できるようにする。
GTD では、物事をこなしていくことに比重を置いているわけではなくて、「自らをとりまく世界に対して適切なかたちで関わっていくこと」を主眼としている。ある時点で何をすべきかについて最善の選択をし、現時点で行なっていないことに対して思い悩んだりストレスを感じたりしないようにする手法だ。
LLM のコンテキストウィンドウも人間の認知と同じような制約を持っており、いま集中すべきことでコンテキストウィンドウを満たし、終わったら忘れて次を探すようにコンテキストを精製することが実装の精度と速度を上げていく。
もう一つ重要なのは「実行順序」の問題である。TODO のシーケンシャル実行をしていくと成果物の状態遷移が線形に作られていくようになる。TODO リストの項目を一つずつ消化していく過程は、テープを一方向に進めながら状態を書き換えていくチューリングマシンのモデルに近い。各ステップでの状態が明確であり、問題が発生しても「どこで何が起きたか」を特定しやすい。TODO リストをチューリングマシンのテープに見立てると以下の対応関係が見えてくる。
| チューリングマシン | TODO リスト実行 |
|---|---|
| テープ | TODO リスト |
| ヘッド位置 | 現在のタスク |
| 状態遷移関数 | LLM の推論 |
| 読み取り | タスク内容の解釈 |
| 書き込み | タスクの完了/追加 |
チューリングマシンは有限の内部状態と無限のテープを持つ。LLM のコンテキストウィンドウは「有限の内部状態」に相当し、TODO リストファイルは「外部テープ」として機能する。compaction は内部状態をリセットさせるが、外部テープ（TODO リスト）の再読み出しによって、計算を継続できる。
この観点からすると、52 分という実行時間は単なる「長時間動いた」という話ではない。compaction 境界を複数回越えながらも、TODO リストという外部記憶を参照することで、一貫した計算を継続できたということだ。これは LLM が「万能チューリングマシン」としての性質を、より明示的に発揮できるようになったことを意味している。
シーケンシャル実装を保つことによる認知負荷の削減
ここまでの議論を踏まえると、一つの疑問が浮かぶ。シーケンシャルに TODO を消化していくスタイルは、流行りの並行実装と相性が悪いのではないか。
かつての開発といえば、1 ウィンドウ、1 ブランチ、1 人称視点が常識だったが、AI コードエージェントによる自動生成部分が増えていくのにあたっていかに単位時間あたりの命令を生成しておくかが重要になった。コード生成時間にシーケンシャルに待っていたり、遊んでいるのであれば楽にはなったが生産性自体は上がっていない。ひとつのソフトウェアにおいて、AI エージェントの力を最大限に発揮するためには複数ウィンドウで、単一リポジトリのコードクローンを作って、異なるモジュールに対して同時多発的にプルリクを創造する必要がある。
実のところコーディングエージェントが出始めた頃から並行実行を試行していたのだけども、どうしても古い実装を元に書かれた部分が出てきたり、コンフリクト対応が複雑化していき、それが最大のボトルネックである僕自身の認知負荷を高めてしまうと感じている。
個人開発の良いところはブランチを複雑化する必然性があまりないところにもあるため、同じプロジェクト内でコーディングエージェントを並列実行させたくないと感じるようになってきた。長大な TODO リストのシーケンシャル実行とロングランにこそ系をアイセントロピック（等エントロピー、つまり可逆で予測可能な状態遷移）に保ってマージ処理のボトルネックを解消する効果があるからだ。コードベースの状態遷移が予測可能で、いつでも巻き戻し可能な状態を維持できる。
その一方で、互いに疎なプロジェクト同士の並列であればいくらでもして良いと思っている。異なるプロジェクト、異なるリポジトリ、異なるフォーマットと、それぞれが独立しているものであれば並列化の恩恵を受けて時間あたりの成果を最大化できる。1台のチューリングマシンを複雑化するのではなく、10 台のマシンを用意するということだ。
人間のためのシステムが人工知能に接続していく面白み
GTD においてはまず TODO リストを作ることに集中し、それをシーケンシャルに実行するのも自分であることがキモだったのだけれども、実行の大半は Claude Code がやってくれる。なので、人間としての自分は LLM と壁打ちしながら実現したかった事とそのための手順をメンテナンスすることが主な仕事になる。
その意味ではすでに抱えていたモヤモヤを書き出すというよりもモヤモヤ自体を作り出すことが必要になったりもして、それはそれでちょっと本末転倒を感じたりもする。要件定義から要求開発にってやつだ。
何にせよ、人間の認知負荷をさげるための GTD の実行系が実現されたことでチューリングマシンの意味的再現が可能になり、それが現在の LLM コンテキストエンジニアリングにも有効であることに歴史とマン・マシンインターフェイスの面白さを感じる。
