■ 1. todo.txtへの回帰
- 2006年からのGTD運用:
- タスク管理手法のGTDを2006年から使い続けている
- 途中で何度もツールを乗り換えたが、結局ただのテキストファイルに戻ってきた
- 前記事からの継続:
- todo.txtを布教したいという記事をQiitaに2024年末に書いた
- 相変わらずtodo.txtを使い続けており、本稿はその続きにあたる
- 2026年の今、同じtodo.txtがどう進化してどう回っているかを扱う
■ 2. 素のtodo.txtの限界
- GTDの5リスト:
- Inbox、Next Actions、Waiting、Someday、Referenceの5つがある
- 素のtodo.txtは1ファイル思想のため、全部を1本に押し込むにはタグで擬似的に分けるしかない
- 分ける手段はプロジェクトタグとコンテキストタグに限られる
- InboxとNext Actionsの混在:
- 一番のネックは両者が同じ視界に混ざってしまうこと
- GTDでは収集と処理は別のタイミングでやる動作にあたる
- 収集と処理の分離:
- 頭の外にポンと出す瞬間と、次に何をするかまで落とし込む瞬間は分離したい
- 同じファイルに書くと収集した瞬間にNext Actionsへ入り、処理のタイミングを選べない
- 教科書通りには回っていなかった:
- ある意味割り切って使っていた部分があり、長年GTDの教科書の形では回っていなかった
- InboxなしでいきなりNext Actionsらしきものをtodo.txtに書く運用に近かった
■ 3. torudoのGTDモード拡張
- 自作TUI torudo:
- todo.txtを日々触るのにRust製の自作TUI torudoを使っている
- つい最近、v0.10からv0.12にかけて大きく変わった
- 5モードのGTDレイアウト:
- inbox.txt / todo.txt / waiting.txt / ref.txt / someday.txtをそれぞれ別ファイルとして持つ
- Tab / Shift+Tabで切り替え、各タブに件数が表示される
- sプレフィックスでモード間移動:
- siでinbox、swでwaiting、srでref、ssでsomeday、stでtodoへ移動する
- GTDの処理ステップがキー2打で終わる
- 直接エディタでファイル移動してもよいが、TUI上のほうが処理に集中でき即座に反映される
- 完了はtodoモードのみ:
- 他のモードから完了したくなったらstで一度todoへ送る
- 実行対象はtodo.txtだけという単純さを維持するため
- waitingから直接完了したい場面はありそうで、未だに悩んでおり変えるかもしれない
- 5モードはopt-in:
- 従来のtodo.txt/done.txt以外のファイルは初回書き込みまで作られない
- 従来通りtodo.txtとdone.txtだけで使っても何も問題ない
■ 4. 収集を楽にするinbox add
- GTDの本丸は収集:
- 頭の中のものを全部システムに出すことがGTDの本丸
- 思いついた瞬間にすぐ収集できることが大事で、溜めるのはよくない
- torudo inbox add:
- 収集のプロセス改善のためv0.11で足したサブコマンド
- TUIを起動していなくても外から直接inbox.txtに追記できる
- 仕様上の工夫:
- JSONでidなどの追加結果が返り、他のコマンドへのインプットにしやすい
- 作成日は自動で挿入される
- TUIが起動中ならfile watcherが拾って即Inboxタブに反映される
- 作成日を入れる理由:
- 元は作成日いらない派だった
- 後で分析するときにいつ作られたタスクかが分かるとかなり捗る
- 長期間完了していなければ粒度がデカすぎたか、といった判断ができる
- 投入経路の広がり:
- シェルエイリアス、エディタのキーバインド、Claude Codeのフックやスキル、他のCLIのパイプからInboxに入れられる
- alias i='torudo inbox add' として短縮して使える
- Claude Codeのstop hookから残タスクを自動でinboxにpushする使い方も考えられるが、やっていない
- 残る課題:
- 外出先からのスマホ経由の投入手段はまだ無く、一旦保留している
- Slackやメールに特定ルールで投げ込んでおけば勝手に拾う、くらいが理想
- 結局普段はinbox.txtをエディタで直接編集するのが一番早い
- 自動収集という理想:
- メール、issue tracker、各種チャットツールから勝手に収集してInboxへ入れたいが、まだそこまでいっていない
- 夕方前の急ぎの問い合わせに退勤間際で気づくような最悪のケースを避ける仕組みを作りたい
■ 5. t:とdue:のタグ
- t:YYYY-MM-DDはthreshold:
- 未来日付が付くと列の最下部に非活性っぽい見た目で並び、当日以降になると通常表示に戻る
- topydo互換の挙動
- 具体的な着手日が決まっているタスクに設定しておくと便利
- レビュー依頼を出して明日には返ってくるはずという連絡待ちは、waiting.txtよりt:のほうが良さそう
- due:YYYY-MM-DDは締切日:
- 期限が到達すると赤枠でハイライトされる
- 締切日表示もしたほうがいいかもしれないが、そこまではやっていない
■ 6. icaruと組み合わせた朝の計画
- icaruとの連携:
- icaruは仕事・プライベート・学校の予定をまとめてLLMに食わせるCLIで、カレンダーからLLMへ予定を渡す導線
- torudo側は単なるテキストファイルの集合体なので、そのままcatでLLMに読ませられる
- 朝のClaudeスキルにicaruの出力とtodo.txt群をまとめて食わせる
- LLMによる計画立案:
- 午前の定例までにXを片付けて午後の空き時間でY、といった具体的な計画をLLMが立てる
- GTDの5ステップのうち処理〜レビューは主にtorudoで行う
- 実行の手前の計画立案はClaudeに任せ、この形になってから脳の負荷がかなり減った
- /start-dayと/end-day:
- クラスメソッドのClaude CodeでAI駆動GTD × Zettelkastenで紹介された/morningと/daily-logスキルの発想を取り込んだ
- 自分のワークフローに落とし込んで運用を回し始め、まだ数日だがいい感じに回り始めている
- 日次ログによる精度向上:
- torudo単体ではtodo.txtがその時点のスナップショットでしかなかった
- 毎日の記録を別途mdファイルにログとして残し、それを参照しつつLLMと常に相談できる状態にした
- 今日どの順番で仕事を進めるべきかの精度と解像度がかなり上がった
- 根拠に基づく意思決定:
- 感覚に頼っていた部分が減り、明確な根拠に基づいた適切な判断がしやすくなった
- 体調がよくないとき、進捗が芳しくないとき、逆に調子がいいときなどをLLMと共有する
- 昨日の状況、翌日の予定、今週の残り時間等を考慮に入れた意思決定が実現している
■ 7. テキスト×ターミナルとLLM
- 枯れたフォーマット:
- todo.txtは10年ほど前からある枯れたフォーマット
- 1行1タスク、プロジェクトタグ(+project)とコンテキストタグ(@context)、完了日と作成日だけの形式
- LLMに食わせやすい理由:
- 人間可読かつ機械可読、かつLLM可読でトークン効率よく構造が取れる
- grepでき、diffが読め、gitで追える
- SaaSのタスク管理ツールならAPIを叩いてJSONを整形する必要があるが、cat inbox.txtだけでClaudeに渡せる
- 時代が追いついた:
- 枯れたプレーンテキストが結果的にLLMフレンドリーになっている
■ 8. 2026年もtodo.txtを布教したい
- 3段スタック:
- 枯れたフォーマット × 薄い自作ツール × Claude Codeという構成
- プレーンテキストの強み:
- 手元のデータは全部プレーンテキストで、ベンダーロックインもゼロ、エクスポートもいらない
- 過去の履歴はgitに残っている
- 新しいツールを試したくなったら、cat todo.txtで食わせて差し替えればよい
- 2026年、むしろ今こそtodo.txtを布教したい