Calude Code によってGTDにおけるロングTODOリストはストレスフリーなチューリングマシンの意味的再現となった

Claude Code、GTD、そしてチューリングマシン `todo.md`がもたらす「ストレスフリー」なコーディングエージェントの運用論 > claude-code compaction --v2.1.3 INPUT STREAM SEQUENTIAL PROCESSING UNIT GTD STATE: CAPTURED GTD STATE: NEXT ACTION GTD STATE: COMPLETED ☑ initialize_project ☑ define_architecture ☐ implement_feature_A ☑ refactor_code_B ☐ run_tests ☐ deploy_staging ☑ update_documentation ☐ sequential_execution_C ☐ final_review GTD STATE: COMPLETED CONPACTION ALGORITHM v2.1.3 Based on the article by buildra ('太陽がまぶしかったから') | Focus: Claude Code v2.1.3, Compaction, Sequential Execution

Compaction問題の解決がもたらした、 52分間の連続実行 52:54 連続実行時間 Achieved by user @nummanali The News: • Claude Code v2.1.3は、コンテキス トリセット (Compaction) によって エージェントがプロジェクトの状態 を見失う問題を解決しました。 The Breakthrough: • 単にモデルが長く稼働するだけで はありません。複数のメモリリセ ット (Compaction) をまたいで、 意味的な一貫性を維持できるよう になった点が革新的なのです。 The Mechanism: • Plan Modeで包括的な`todo.md` を明示に作成させることで、計 画とタスクがCompactionの境界を 越えて永続化します。 Compaction Compaction Context 1 Context 2 Context 3 Compaction Compaction Compaction Semantic Consistency (意味的一貫性) Plan Mode todo.md Persistent State & Tasks Persistent Storage Compaction Agent Execution

`todo.md`を「外部記憶装置」として利用する実装フロー 1. Plan Mode (WBS作成) `plan.md`に階層構造を作成 2. Linearize (線形化) `todo.md`に順次実行リストを作成 3. Execute (実装) リストの先頭タスクを実行 4. Update (更新) `todo.md`のタスクを 完了(Done)にする 5. Compaction / Clear コンテキスト (内部メモリ) の リセット 6. Read (読み込み) `todo.md`から状態を復元 Note: `/clear`や`/compaction`を 実行しても、「真実」は外部ファイル (`todo.md`)にあるため安全です。

GTDの本質: 脳をワーキングメモリと して使わない CALM Inbox / System Offloading David Allen's Philosophy 「頭の中にあることをすべてインボックスに書き出 して外部化し、信頼できるシステムで管理する」 The Goal 認知負荷 (Cognitive Load) を下げ、ストレスなく 目の前のタスクに集中すること。 The Quote 「自らをとりまく世界に対して適切なかたちで関わ っていくこと」 AIへの適用: 人間がToDoリストを脳内に保持すべきでないのと同様 に、LLMもプロジェクト計画をコンテキストウィンドウ (短期記憶) だけに保持すべきではありません。

計算科学の基礎: 有限の内部状態と無限のテープ **Internal State (Finite) Finite State Control 有限状態制御部 Finite State Machine **External Memory (Infinite)** • The LLM Constraint: LLMのコンテキストウィンドウは「有限の内部状態」に相当します。 • The Solution: 52分以上計算を続けるには、内部状態がリセットされても情報が消えない「外部 テープ」が必要です。

Claude Codeは「意味的なチューリングマシン」の再現である Turing Machine Claude Code Workflow Tape (テープ) `todo.md` (The Todo List) Head Position (ヘッド位置) Current Task (現在のタスク) State Transition (状態遷移関数) LLM Inference (LLMの推論) Internal State (内部状態) Context Window (コンテキストウィンドウ) Write Operation (書き込み) Task Completion/Addition (タスクの完了・追加) Insight: Compactionは「内部状態」をリセットしますが、「テープ」(`todo.md`)は計算 結果を保持し続けます。これにより、エージェントは「Compactionの壁」を何度でも越える ことができます。

なぜ並列実行ではなく「シーケンシャル実行」なのか High Entropy (Parallel) Context Pollution コンテキスト汚染 Merge Conflict マージ競合 Context Pollution コンテキスト汚染 Isentropic (Sequential) Task 01 Task 02 Task 03 Task 04 Task 05 Task 06 **The Problem with Parallelism: 複数のウィンドウやブランチを走らせる と、エントロピー (無秩序) が増大しま す。コンテキスト汚染や複雑なマージ競合 は、人間の認知負荷のボトルネックとなり ます。 **The Solution: Isentropic (等エントロピー) なシステム を維持すること。シーケンシャル実行は、 状態遷移が予測可能であり、可逆的です。 「10本の絡まったテープより、1本の進み 続けるテープ」の方が管理しやすいのです。

並列化して良い条件: プロジェクト間の「疎」結合 Project A (Repo X) Project B (Repo Y) Project C (Format Z) **The Rule: 単一の複雑なプロジェクト (単一リポジトリ、単一コンテキス ト) 内では並列化しないこと。 **Exception: プロジェクト同士が「疎 (Sparse)」である場合のみ並列化 可能です。 ● 異なるリポジトリ ● 異なるプロジェクト ● 異なるフォーマット **Metaphor: 1台のチューリングマシンを複雑化 させるのではなく、独立した10台 のチューリングマシンを用意して、 10の異なる仕事をさせるイメージ です。

人間の新しい役割: コードを書く者から「状態」を管理する者へ Implementation (Code Writing) Requirement Definition (State Management) **Shift in Responsibility: 人間はコード (状態遷移) を書くのではなく、`todo.md`と`plan.md` (テープ) を管理する役割 に移行します。 **Activity: LLMとの「壁打ち」を通じて、要件と手順を精査する作業が中心となります。 **Emotional Reality: タスクを実行せず、タスクを作ってばかりいるため「本末転倒」に感じら れるかもしれません。しかし、これこそが「実装者」から「要件定義者」への進化なのです。

Editorial Engineering Blueprint 歴史とAIが交差する「ストレスフリー」な未来 [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] { } • Claude CodeのCompaction解決は、万能チューリングマシン理論の実用的応用を可能にしました。 • GTDの哲学は、このマシンを運用する人間の認知負荷を最小化するフレームワークを提供します。 • 私たちは「Coding」から「Context Engineering」の時代へ移行しました。 Trust the tape. Keep it sequential. Reduce your cognitive load.