- タスク管理ツールを3つ乗り換えた末に
- 全部の挫折に共通していたもの——NEXT 肥大化問題
- GTD の理論は正しい——でも「使い続けるコスト」が高すぎた
- Claude Code でタスク管理の仕分けコストが下がった理由
- バッチ型 GTD ワークフローという設計思想
- NEXT 肥大化の根本原因と、設計での対処
- AI が先生兼秘書という学び方
- 現時点の運用と今後の設計
- まとめ：設計思想の3点
- 今日から始めるなら、この1ステップだけ
この記事の要旨（2026年5月）: タスク管理ツールを TaskChute / Remember The Milk / ポモドーロまで試して全部挫折してきた。挫折の根本原因は「NEXT 肥大化」——GTD の Next Actions リストが無限に膨らんで、見る気を失う現象だ。その構造的な解決策として「バッチ型 GTD ワークフロー」を設計した。inbox.md に書いてコマンド1発、AI が仮仕分けして sorted.md を出力、人間は間違いだけ直す。「判断する」から「承認する」への認知シフトが、挫折ループを断ち切る鍵だった。
タスク管理ツールを3つ乗り換えた末に
私のタスク管理遍歴は、ある意味で典型的な「挫折コレクション」だ。
- TaskChute：タスクと時間を紐づけて可視化するアプローチ。「何をどれだけやったか」がトラッキングできる点に感心したが、記録し続けるコストに根負けした
- ポモドーロメソッド：25分集中 × 5分休憩という構造自体には今でも合理性を感じる。問題は「何のタスクに取り組むか」を決める部分——つまりタスク選択・優先順位付けには何も答えてくれない
- Remember The Milk：GTD ライクな整理ができて数年は使った。それでも最終的には「リストが膨らんで、開くのがつらくなる」という結末を迎えた
どのツールで挫折したかより、どこで挫折したかが重要だ。今は GitHub Issues × GTD × Claude Code という構成で動かしているが、それも「良いツールを見つけた」という話ではない。ツールが変わっても同じ場所で転んでいた——その「同じ場所」の正体を言語化できたことが出発点だ。
全部の挫折に共通していたもの——NEXT 肥大化問題
GTD（Getting Things Done）には「Next Actions」という概念がある。「次に取るべき具体的な行動」を一覧化するリストで、これが GTD の実行エンジンだ。
問題は、このリストが際限なく膨らむことにある。
仕事でも個人でもタスクは生まれ続ける。かたや完了するタスクは限られている。数週間もすると Next Actions リストは数十件を超え、開いた瞬間に「今日これ全部見るの？」という気持ちになる。結果として、リストを開く頻度が下がり、新しいタスクを追加するモチベーションも失せ、ある日「もうこのツールやめよう」という判断になる。
これを私は「NEXT 肥大化問題」と呼ぶことにした。
GTD の熟練者に言わせれば「それは Tickler ファイルや Someday/Maybe を正しく使えていないからだ」という話になる。そのとおりだ。ただ、Tickler を正しく運用するには GTD を深く理解した上で、毎日少しずつ手入れを続ける必要がある。その「毎日の手入れ」が続かないこと自体が問題の本体でもある。
「NEXT 肥大化」は道具の選択ミスではなく、システムの構造的な欠陥だった。この診断に至るまでに、3種類のツールと何年かが必要だった。
GTD の理論は正しい——でも「使い続けるコスト」が高すぎた
GTD の本質は3点に絞れる——「頭の外に出す」「次の物理的なアクションに分解する」「定期的に棚卸しする」。これ自体は今でも合理的だと思う。問題は、この3点を正しく動かし続けることの難しさだ。
なぜ挫折したか。仕分けのコストが高かった。タスクが溜まるたびに「これは Next か、Someday か、Waiting For か」を考え、コンテキストを付け、期限を設定し、プロジェクトに紐づける——この一連の作業が「GTD を動かし続けるためのオーバーヘッド」として重くのしかかる。
さらに、GTD の教科書を読んで理解するのと、実際に運用するのは別の話だ。「学んでいる」と「動かしている」が分離してしまう。本を読んで「なるほど」と思った翌週に崩れ始めるサイクルを何度か繰り返した。
Claude Code でタスク管理の仕分けコストが下がった理由
Claude Code を使い始めた 2026 年初頭から、タスク管理の景色が変わった。変わった最大の理由は「仕分けのコストが下がった」ことだ。
ただし、単純に「AI に話しかけて仕分けしてもらう」という使い方は、別の問題を生んだ。
AI の応答には数秒から数十秒かかる。対話型のワークフロー——「このタスクはどのカテゴリですか？」「Next です」「わかりました、次はこれです」——を繰り返していると、レスポンスを待つ時間がストレスになる。タスクを1件ずつ確認していくうちに集中が切れる。
「AI と対話しながら整理する」というアプローチは、想定していたより疲れた。（これは私の主観的な体感であり、対話型が合う人もいると思う。）
この体験から、別の設計を考え始めた。
バッチ型 GTD ワークフローという設計思想
私が「バッチ型 GTD ワークフロー」と呼んでいるのは（公式用語ではなく、私が個人的につけた名称だ）、次のような構造だ。
inbox.md に書く → コマンド1発 → sorted.md が出る → エディタで確認・修正 → コマンド1発 → Issue化
4つのステップに分解すると：
- 収集（人間がやる）：テキストエディタを開いて、思いついたことを箇条書きでバーッと書く。AI の応答を待たない。書くことだけに集中する。
- 仮仕分け（AI がやる）：コマンド1発で AI が仮タグ付きの結果を出力する。Next か Someday か、コンテキストは何か、期限の目安はどのくらいか、が全件に付いてくる。
- 承認（人間がやる）：エディタ上で AI の仮仕分けを確認し、間違っているものだけ直す。「判断」から「承認」への変換だ。
- Issue化（AI がやる）：コマンド1発で GitHub Issues に登録される。
inbox.md の最小フォーマットはシンプルだ。行ごとに1タスク、箇条書きで書くだけでよい：
- 請求書の確認 - Zennの記事レビュー - ウイスキーサイトのネタ、どこかでまとめたい - 耳鼻科の予約、来週までに
フォーマットの縛りはない。思いついたことをそのまま書く場所だ。AI はこの生のリストを読んで仮仕分けする。
コマンドの正体は、私の環境では Claude Code カスタムスキル（/todo）とシェルスクリプトの組み合わせだ（詳細は実装編で扱う）。ここで重要なのは仕組みではなく設計思想——「収集は素早く、判断はまとめて、人間がやることは承認だけ」という構造だ。紙とテキストエディタで手動再現することもできる（後述する）。
仮仕分けのアウトプットはこんなイメージだ：
✅ 請求書の確認 → Next / @経理 / 今週中 ✅ Zennの記事レビュー → Next / @writer / 明日 ✅ ウイスキーサイトのネタ → Someday / @note ❌ 耳鼻科の予約 → Next / @個人 / 今週中 ← 修正: Waiting（予約待ち）
ほとんどの行は AI の判断でよい。人間が直すのは ❌ のついた行だけだ。
この設計が重要なのは、認知の切り替えにある。「このタスクをどう分類しようか」という能動的な判断を繰り返すのではなく、「この AI の分類は合っているか」という検査的な承認に変わる。前者は積み重なると疲労するが、後者は比較的軽い。
NEXT 肥大化の根本原因と、設計での対処
バッチ型のフローを設計した後で改めて「NEXT 肥大化」を分析すると、原因が3層あることに気づいた。
第1層：仕分けコストが高くて Tickler が機能していない
GTD には「今じゃないけど、特定の日付が来たら取り掛かる」タスクを一時保管する Tickler（チクラー）という概念がある。「4月20日になったら思い出したいこと」を Tickler に入れておけば、それが来るまで NEXT に出てこない。
ところが、Tickler の運用には「毎日 Tickler を確認して、日付到来のタスクを NEXT に昇格させる」という手作業が必要だ。この手作業が続かなければ、Tickler に入れるより「とりあえず NEXT に入れておこう」という判断になる。結果として NEXT が肥大する。
第2層：期限なし NEXT が溜まり続ける
「いつかやる」が NEXT に入ると、ずっと居座り続ける。2週間前に入れたタスクが今週も来週も NEXT に残り、リストの見通しを悪くする。GTD では「2週間動いていない NEXT は Someday に落とすか削除する」という棚卸し（週次レビュー）を推奨しているが、これも続けるのが難しい。
第3層：「今日やること」が3件を超える
人間が1日にエネルギーを注げるタスクには限りがある。NEXT に30件あっても、実際に動けるのは3件前後だ。30件のリストから今日の3件を毎朝選ぶ作業が、それ自体のオーバーヘッドになる。
私の今の対処は：
- Tickler の仕組みを明示的に設計する：GitHub Issues のラベルで日付管理し、朝のセッションで日付到来の Issue を NEXT に昇格させる（詳細は実装編で扱う）
- Today リストを NEXT と分ける：朝のセッションで AI に「今日の3件」を選ばせる
- 2週間放置の NEXT を自動検出する：AI が定期的にスキャンして「Someday に落としますか？」と提案する
これらをコマンドベースで自動化することで、「続けるコスト」を下げることを狙っている。
AI が先生兼秘書という学び方
GTD の学習曲線についても触れておきたい。
通常の学び方は「本を読む → 自分で実践 → 挫折 → また本を読む」というループだ。本で理解した内容を実際の運用に落とし込む橋渡しが弱い。
AI と一緒に動かすと、この構造が変わる。「今これは Waiting For になりますか？」と聞けば、今のタスクに対してすぐ答えが返ってくる。「なぜ NEXT じゃないんですか？」と追加で聞けば、GTD の原則を文脈に即して説明してくれる。
理論の学習と実際の仕分けが同時進行する。これは本を読むだけでは得られない体験だった。
もっとも、AI の説明がすべて正確なわけではない。私自身がある程度 GTD を理解していなければ、間違った仕分けに気づけない。AI を「先生兼秘書」と表現したが、より正確には「下書きを作ってくれるアシスタント」であり、最終的な判断は人間がする、という関係だ。
現時点の運用と今後の設計
この記事で紹介したワークフローは今も発展途上だ。「動いているもの」と「まだ構想段階のもの」を正直に書いておく。
バッチ収集と仮仕分けは毎日動いている。inbox.md に書いてコマンドを叩き、sorted.md を確認して承認する——このサイクルは現在の日常になっている。「判断から承認へ」という認知シフトの効果は、使い始めてからの体感として実感がある。
週次レビューはまだ安定していない。GTD の肝である「週に一度、全リストを棚卸しする」習慣を私はまだ安定して実践できていない。現時点では月に1〜2回、気が向いたときに棚卸しするという運用でしのいでいる。AI がアシストする週次レビューの設計は実装編で扱う予定だ。
Tickler の自動昇格は手動運用の段階だ。朝のセッションで日付チェックをして期限到来のタスクを NEXT に昇格させる作業を手作業で行っている。GitHub Actions による自動化は設計段階にある（実装編に詳細を書く）。
コマンドは私個人の環境であり、汎用公開はしていない（2026年5月時点）。ただし設計思想そのもの——inbox を書いて、まとめて仕分けして、承認する——は、紙とテキストエディタでも今日から試せる（後述する）。
「全部うまくいきました」より「ここまで動いて、ここは課題」という話のほうが、同じ課題を持つ人には役に立つと思っている。
まとめ：設計思想の3点
バッチ型 GTD ワークフローの要点を整理する。
① 対話ゼロ設計：収集は人間がテキストで、仕分けは AI がバッチで、承認は人間がエディタで。AI との往復対話を設計から外すことで、「応答を待つストレス」を排除する。
② 「判断」から「承認」へ：タスクの分類をゼロから判断するのではなく、AI の仮仕分けを確認・修正するだけにする。認知コストを「作る」から「検査する」にシフトする。
③ NEXT 肥大化への構造的な対処：Tickler・Today リスト・腐った NEXT の自動検出の3つを組み合わせる。どれかひとつでは解決しない。
次の記事（実装編）では、GitHub Issues への実際の対応マッピング、Tickler の実装方法、週次レビューの AI 支援設計などを具体的に書く。バッチ型ワークフローの「対話ゼロ設計」がどう GitHub Issues という実行基盤と接続されているか——その実装の詳細が次回の焦点になる。
今日から始めるなら、この1ステップだけ
すでに inbox 的なメモを運用している人は、この節は読み飛ばして実装編へ進んでもらって構わない。これは「タスクの書き溜め場所がそもそもない人」のための入り口だ。
コマンドも Claude Code も必要ない。紙とテキストエディタで今日から試せる。
やること：テキストファイルを1つ作り、思いついた todo を10行書き溜める。
ファイル名は inbox.md でも todo.txt でも何でもよい。フォーマットは箇条書き1行1タスク。「仕事の◯◯を確認する」「△△に返信する」「いつかやりたい□□」を全部混ぜて書いていい。仕分けはしなくてよい。とにかく書き出すことが第一歩だ。
10行書き溜めたら、明日か週末にそのファイルを開く。「これは今週やる」「これは来月でいい」「これはもうやらない」の3択で振り分けるだけで、GTD の仕分けフローを手動で体験できる。
AI とコマンドは「この仕分けを自動化するツール」に過ぎない。仕組みを体で理解してから自動化すると、実装編の内容がずっと具体的に見えてくる。
本記事で触れた Next Actions・Tickler・週次レビューといった概念は、すべて GTD の原典が源流だ。理論をきちんと押さえたい人には、提唱者デビッド・アレンの『新装版 はじめてのGTD ストレスフリーの整理術』が出発点になる。「頭の外に出す」「次の物理的なアクションに分解する」「定期的に棚卸しする」という3点の意味が腹落ちすると、本記事の設計思想も具体的に見えてくる。
この記事でカバーしきれなかった設計・運用の全体像は、Zenn Books にまとめている。序章・第1部は無料で読める。
- コードを書けない私がClaude Codeで「AIチーム」を作るまで（¥900 / 序章・第1部無料）
- コードを書けない私がClaude Codeで「AIチーム」を回すまで（¥900 / 序章無料）
関連記事: - Claude Code で GTD 朝セッションを自動化した話 — バッチ型の前に動かしていた対話型アプローチ - GTD スキル Pro 機能を実装した記録 — 今回の設計に至る前段の試行錯誤
