この記事について: 私が個人で作って公開している Claude Code のスキル /todo（GitHub Issues を使う GTD タスク管理ツール）には、条件が揃うと向こうから次の一手を提示してくる機能が3つある。完了時の次タスク提示、依存関係での自動昇格、時間経過での自動浮上だ。この記事では実際の出力文言と実運用での挙動を紹介する。中でも、時間が来ただけでは機械的に昇格させず「再開条件の確認が必要です」と聞いてくる resume_condition という機能は、2026年8月に私自身が誤動作を踏んで即日直したものだ。
AIタスク管理と聞いて何を想像するか
「AIでタスク管理」と聞くと、優先順位を勝手に並べ替えたり、次にやることを決めつけて提示してきたりする姿を想像する人が多いと思う。私自身、意図して作ったわけではないのに、既存の仕組みが結果的にそう動いてしまったことがある。
/todo は、Claude Code 上で動くスラッシュコマンドで、GitHub Issues をバックエンドにした GTD（Getting Things Done）タスク管理ツールだ。GitHub でソースコードを公開している。
このツールには、事前に条件（依存関係・時間経過・再開の質的な条件）を渡しておくと、条件が揃った瞬間にツール側から声をかけてくる機能が3つある。「勝手に決められたら困る」という不安には、3つ目の resume_condition が答えになる。以下、実際の出力文言と、動いた・動かなかった実例で見ていく。
機能1（--project）: 完了と同時に次のタスクを提示する
「プロジェクトに紐付けていないと使えないのでは」と思うかもしれないが、--project でプロジェクトに紐付けたタスクだけに発生する機能で、他のタスクには影響しない。
タスクを1件完了すると、そのタスクが project: フィールドを持っている場合、同じプロジェクト内でまだ昇格していないタスクを候補として提示してくる。実際の出力は以下の形式だ（~/.claude/todo-engine.js 実測）。
💡 プロジェクト #1641「claude-todo-gtd-webでモバイルGTDフローが成立し...」に昇格候補があります:
1. #1672「Web版のdone完了時にrecur再作成をフロントエンドへ通知する...」(🌈 someday)
番号を入力するか /todo move <#> next で昇格できます。
これは実際に何度も発火していて、Claude Code のセッションログを見ると2026年8月3日だけで4件のプロジェクトで複数回表示されている。1件だけ気になる連鎖があった。#1657 を完了した12:54に候補として #1672 が提示され、約22分後の13:16にその #1672 が実際に完了している。ただし、私がこのヒントを見て着手したという発言記録はなく、単に同じプロジェクトのタスクを順番に片付けていただけかもしれない。ここでは「時系列が一致した」という事実にとどめておく。
使い方はシンプルで、プロジェクトを作るときに --project で紐付けるだけだ。
/todo next 詳細設計を書く --project 42
機能2: 依存タスク完了で自動昇格する
--depends-on は、依存先のタスクが完了したタイミングで、このタスクが next へ自動昇格する機能だ。
/todo someday 記事を書く --depends-on 42
依存先の Issue（#42）が /todo done で完了すると、以下のような形で next へ昇格する（実際に発火したログではなく、コードのテンプレート文言に沿った再現例）。
✅ #43 「記事を書く」を next に昇格しました（#42 完了トリガー）
正直に書くと、この機能は2026年8月3日まで実際には動いていなかった。昇格チェックの入口が「完了させた Issue 自身が project か dependsOn を持っているか」という、本来判定すべき条件（他の Issue がこの完了 Issue に依存しているか）とは無関係なガードになっていたのが原因だ。依存元がシンプルな Issue の場合はこのガードに引っかかり、昇格チェックそのものが動かなかった。
同日中（2026-08-03 23:15、v2.5.0）にガードを撤去して修正し、ユニットテスト833件は全てパスした。ただし、実際にバグを踏んだ依存ペアそのものでの再現確認はまだできていない（依存先を再度クローズする機会が今後来ないため）。仕組みとしては直っているが、実運用での発火実績はまだ持っていない。
機能3: activate日到来で自動浮上する
「そんな定期実行、手元の環境で動かすの面倒そう」と思うかもしれないが、Mac なら launchd、Windows なら Task Scheduler で1日1回コマンドを叩くだけなので、環境依存する部分は最小限だ。
--activate は、指定した日付が来たら next へ自動浮上する機能だ。--before を使うと期限からの逆算で自動計算できる。
/todo someday 展覧会に行く --due 2026-09-21 --activate 2026-06-01
/todo someday 契約更新を検討 --due 2026-10-01 --before 14d
浮上させる処理自体は /todo promote を実行したときに走る。私の環境では毎日06:00 JSTに1回叩くよう自動実行を登録している。何も対象がなければ以下のように出力される。
昇格対象なし（activate日到来タスク: 0件）
対象があるとこう出る。
✅ #1318 「ピカソ meets ポール・スミス展に行く」を next に昇格しました（activate: 2026-06-01）
この定期実行を整備したのは2026年8月3日で、それまでは promote を呼ぶ仕組み自体が存在せず、activate 日を過ぎたタスクが放置されていた。整備後の初回実行では、#1318・#1088・#416・#1299 の4件が同時に next へ自動浮上した。このうち #1088（2026年5月1日 activate）は8月9日に、#416（2026年7月31日 activate）は8月8日にそれぞれ完了済みになっている（2026年8月16日時点で確認）。「activate日到来で next へ自動浮上し、その後実際に完了された」という時系列の事実は確認できているが、「自動浮上したから片付いた」とまでは言えない。浮上していなくても近いうちに気づいて着手していたかもしれないからだ。
機能3の発展形: 機械的に決めず、聞いてくる resume_condition
ここが一番書きたかった部分だ。時間が来ただけでは自動昇格させず、質的な条件が揃っているかを人間に確認させる仕組みがある。
きっかけは、上で紹介した初回の promote 実行そのものだった。同時に昇格した4件のうち、#1299 だけ事情が違った。この Issue の本文には「再開条件: ブログの Google 検索流入が観測できるレベルに育ったとき」という質的な条件を私が書いていたのに、promote は activate 日到来という時間条件だけを見て機械的に昇格させていた。条件自体はそのとき全く満たされていなかった。
私が作った仕組みに私自身が振り回された形だが、同日中に修正した（2026-08-04、v2.6.0）。Issue 本文に resume_condition を設定しておくと、activate 日が到来しても機械的には昇格させず、確認待ちとして提示するだけになる。
/todo edit 1299 --resume-condition "ブログの検索流入が観測できるレベルに育ったとき"
以降、activate 日が到来しても該当タスクは次のように表示される（これも実際に発火したログではなく、コードのテンプレート文言に沿った再現例。#1299 は resume_condition 新設前に activate をクリアして someday へ差し戻したため、この出力自体は発火していない）。
⏸ #1299 「◯◯」activate日到来ですが再開条件の確認が必要です: ブログの検索流入が観測できるレベルに育ったとき
⏸ 1件が再開条件の確認待ちです（次回 /todo weekly-review で確認してください）
条件を満たしたかどうかの判定はツール側では一切行わない。「本当に条件を満たしたか」を確認するのは私自身で、満たしていれば手動で promote するか --activate を再設定して昇格させる。満たしていなければ何もしない。resume_condition をクリアしたいときは --resume-condition clear を使う。
時間条件だけで機械的に決めていい場面と、人間の判断を残したい場面を区別する。これが今のところ、この3機能の中で一番「秘書っぽい」と感じている部分だ。
まとめ——事前に条件を渡しておくと、揃った瞬間に声がかかる
3つの機能に共通しているのは「人間が思い出さなくても、条件が満たされたタイミングでツール側から声をかけてくる」という構造だ。
- 完了トリガー（
--project）: プロジェクト内の次のタスクを提示する - 依存関係（
--depends-on）: 依存先の完了で自動昇格する - 時間経過（
--activate/--before）: 指定日到来で自動浮上する - 再開条件（
--resume-condition）: 時間だけでは決めず、質的な条件を確認してから昇格させる
セットアップは、todo.md / todo-engine.js / todo.sh を ~/.claude/ にコピーし、テンプレートDB（~/.claude/todo-templates.json）を初期化した上で、GitHub リポジトリを1つ用意して環境変数を設定すれば完了する。手順は公開リポジトリにまとめている。もう少し詳しい使い方は今度こそ！ Claude CodeでGTDを回す——/todo 完全ガイド、開発の経緯は/todo スキルをOSS化するまでに書いている。外出先からタスクを入れたい人向けに PWA 版（todo.saitoko.net の紹介記事）も用意している。
depends_on の実運用での再検証はまだ途中だ。--resume-condition はもう使えるので、--activate で日付管理していてまだ someday のまま昇格していないタスクがあれば1つ選んで条件を書き足してみてほしい（すでに next に昇格済みのタスクに設定しても promote 側のガードで無視される）。動きがあればまた書く。
よくある質問
Q. GitHub を使ったことがなくても使えますか？
A. GitHub アカウントと、タスク保存用のリポジトリが1つ必要です。リポジトリ自体は空でよく、gh repo create で数秒で作れます。
Q. resume_condition を設定していないタスクはどうなりますか？
A. これまで通り、activate 日到来で機械的に next へ昇格します。resume_condition は「設定したタスクだけ」確認待ちに変わる仕組みなので、既存の使い方に影響はありません。
Q. 個人のタスク管理以外にも使えますか？
A. Claude Code のエージェント運用でも使っていて、複数のエージェントが同じ GitHub Issue をタスクのハブとして参照する形で運用しています。
この記事は はてなブログ からのクロスポストです。