この記事の要点: GTD（Getting Things Done）の週次レビューが何年も続かなかった私が、その進行をAIに任せてみた記録だ。順番を決める役と抜け漏れを見つける役をAIに持たせ、私は提示された項目に判断を返すだけにした。使っているのは、Claude Code用の公開スキル /todo（GitHub Issuesをバックエンドに使うGTDタスク管理コマンド、GitHub公開・MIT License）と同じコマンドで自分用に組んだ週次レビューの手順だ。2026年4月18日の初回から9月27日までの約5ヶ月で13回完了している。途中で約2ヶ月ほぼ止まったが、8月11日に再開してからは、10日以上空いたことが一度もない。その間、AIは件数を数え間違え、的外れな警告を出した。私自身も、自分用に作った手順から見直し記録の操作を落としていて、空白期間中はその記録が止まっていた。空白をはさんだ継続の経過と、AIと私の間違いを、あわせて書く。今の状態は、習慣として根づき始めたところだと考えている。
週次レビューが続かなかった理由は、「意志が弱いから」ではなかった
GTDの本を読んで、inbox・next action・waiting for・someday・project・reference という6つのカテゴリでタスクを整理する、というやり方自体には何度も納得してきた。問題は「毎週、6カテゴリすべてを棚卸しする」という週次レビューの方だった。
続かなかった理由を振り返ると、実感に一番近いのは「何から手をつけるか決められない」ことと「そもそも着手する気力が湧かない」ことの、2つの詰まりが同時に起きていたことだ。片方だけならまだ対処のしようがあるが、両方が重なると、レビューを始める前の段階で止まってしまう。
なぜ「1人で棚卸し」は続かないのか
一般的なGTD実践では、6ステップを自分でリストを開いて1つずつ確認する。順番を決める、抜け漏れをチェックする、停滞しているプロジェクトに気づく——これを全部自分でやる必要がある。
項目数が増えるほど、この「順番を決める」負荷そのものが大きくなる。タスクを整理する前に、整理の仕方を整理しなければならなくなる。この負荷の正体に気づいてから、「順番を決める役」を自分以外に持たせられないかと考えるようになった。
AIに司会をやらせる、という解決策
私が公開しているClaude Code用のスキル /todo には、weekly-review というコマンドがあり、週次レビューを6ステップの対話形式で進行する。
- Inbox仕分け(未処理タスクを1件ずつ分類)
- Next Actions確認(まだ有効か、動かすべきものはないか)
- Waiting For確認(フォローアップや完了確認)
- Projects棚卸し(next欠落・停滞プロジェクトを自動検出)
- Someday見直し(30日以上見直していないものを優先表示)
- サマリー表示
「順番を決める」「抜け漏れを検出する」の部分をAI側が持ち、人間は各ステップで提示された項目に判断を返すだけになる。特に4番目と5番目は、手動だと見落としやすい部分を機械的に拾ってくれる設計だ。
「Todoistでもいいのでは」と思うかもしれない。 論点はTodoistかGitHub Issuesかではなく、AIが直接読み書きできる場所にタスクがあるかどうかだと考えている。GitHub Issuesはghコマンド経由でAIが直接読み書きできる場所で、この設計思想は以前の記事で詳しく書いた。要は「AIの作業環境とタスクを置く場所が同じかどうか」が、週次レビューの司会をAIに任せられるかどうかを分けている。同じ条件を満たせれば原理的にはGitHub Issues以外（Todoistなど）でも成立するはずだが、そこは私自身検証していない。
ここで断っておくと、公開スキル /todo にもこの週次レビューの手順があるが、私が実際に回しているのは、自分用に別に作った週次レビューの手順だ。使っているコマンドは公開スキルと同じだが、Zettelkastenの見直しなど、私の環境だけの工程も含んでいる。ここから先の実績と失敗談は、その運用の記録だ。公開スキルとの違いが結果に関わる箇所は、そのつど書く。
導入のハードルは、正直に書く
「エンジニアじゃないと使えないんでしょ？」という疑問には、前提条件から答えたい。 使う前提として、Claude Codeがインストール済みであること、GitHub CLI(gh)がインストール・認証済みであること、日付処理にNode.jsを使うこと、の3つが要る。「誰でも今すぐ」とは言えない。Claude Code自体も、有料プランまたはAPI利用が前提になる点は付け加えておく。
手順自体は難しくない。コマンドファイルを~/.claude/commands/と~/.claude/直下の2箇所に分けて置き、タスクを保存する非公開のGitHubリポジトリを作り、.envにリポジトリ名などを設定する。これでClaude Codeの中で/todoと入力すれば動作確認できる(ターミナルに打つコマンドではない)。ただ、この一連の作業を面倒に感じるかどうかは、GitHub操作にどれくらい慣れているか次第だ。GUIだけで完結する話ではない。
週次レビュー13回。2ヶ月止まったあと、7週間途切れずに続いている
週次レビューの完了記録を追うと、初回は2026年4月18日で、そこから9月27日までの約5ヶ月で13回完了している。間隔は最短5日、最長34日とばらついている。
最初から毎週回っていたわけでもない。空白が来る前の4月18日から6月7日までの間も、間隔は13日・26日・11日で、週1回のペースには届いていなかった。そのうえで、2026年6月7日から8月11日までの約2ヶ月間は、34日・31日という間隔で2回しか完了していない。毎週なら8〜9回はできているはずの期間に2回では、実質的にはほぼ止まっていたと言っていい。
流れが変わったのは、8月11日の再開からだ。そこから9月27日までの約7週間で8回完了していて、間隔は5日から9日の間に収まっている。10日以上空いたことは一度もない。
ただし、期日どおりに回っているわけでもない。この期間の期日はいずれも土曜日だが、8回のうち期日当日に終わったのは2回だけで、残りの6回は1〜3日遅れている。それでも、どの回も次の期日が来る前には終わっている。「遅れても、回は飛ばさない」というのが一番近い。
空白の2ヶ月から何がきっかけで戻れたのかを、この記録だけから特定することはできない。言えるのは、2ヶ月止まったあとでも再開でき、再開後の7週間は一度も途切れていない、という事実までだ。それでも、遅れながらも途切れずに続いているこの状態は、習慣として根づき始めたと言っていいと考えている。
それでも間違いは起きた
ここからが、この記事で一番書きたかったことだ。「AIに任せて本当に漏れないの? 自分の目で確認しないと不安」という疑問に、私は「漏れない」とは答えられない。実際に漏れたことがある。 ただ答えたいのは、「漏れるかどうか」ではなく「漏れた後どうなるか」の方だ。
件数を数え間違えた。 ある回では、一覧表示に出ていた注意マークを「next Actionが欠けている」という意味だと勘違いし、対象10件として提示した。実際は別の意味(見直しが長期間止まっているSomedayタスクの印)のマークで、本当にnext Actionが欠けているプロジェクトは22件あった。実行した処理自体には別の裏付けがあり実害はなかったが、数え間違えたこと自体は事実として残っている。なお、このときの自分用の手順は、プロジェクトの棚卸しコマンドを呼ばず、一覧表示の注意マークから件数を数えていた。公開版の手順はStep 4でこのコマンドを使って直接数えるので、公開版なら起きにくかったかもしれない。
自動検出が的外れな警告を出した。 ある週のプロジェクトの棚卸しで、要対応として16件が表示された。実際に確認していくと、そのうち複数件はすでに「保留」に格下げしたはずのプロジェクトだった。原因をAIと一緒に辿ると、以前の週に「保留に格下げした」という処理が中途半端に終わっていて、内部のラベル管理に矛盾が残っていたことが分かった。その週の表示件数とは別に、全プロジェクトを洗い出したところ、同じ原因を抱えていたのは通期で10件あった。直し方をAIと相談して決め、修正を反映した。直近の9月27日の回では、棚卸しの対象は6件で、休止中（保留）のプロジェクトは対象から除外した、と表示された。この回では、保留に格下げしたプロジェクトは要対応に出てこなかった。
見直し記録をつけるコマンドを、7週間呼んでいなかった。 Someday行きのタスクに見直し日を記録する操作を、一度も実行していない期間が続いた。この期間は、先に書いた空白の2ヶ月とほぼ重なる。その間に回した数少ないレビュー（7月11日と8月11日の2回）でも、見直し日を記録する操作は一度も呼んでいなかった。52件のタスクが、見直されないまま置かれ続けていた。
原因は、週次レビューの手順を自分用に作ったとき、私がこの操作を落としていたことだ。公開スキル側の手順には、呼び忘れが始まるより前から、見直し日を記録する操作が書かれていた。私が実際に使っていたのは自分用の手順のほうで、そこから抜けていた。AIのバグではなく、運用側の問題だ。今は自分用の手順にも、見直し日を記録する操作を明記してある。
スキルを自分用に改造したり複製したりすると、元の手順にあった操作が静かに抜け落ちることがある。今回はエラーが一度も出ないまま、見直し日の記録という働きだけが失われていた。自分用に手を入れたら、一度は元の手順と並べて見比べておくと安全だと思う。
3つの訂正までにかかった時間はバラバラだった。件数の食い違いはその場で気づいて訂正され、誤検知は表示されたその日のうちに原因を突き止めて直し、呼び忘れは7週間越しで気づいて自分用の手順に書き足した。気づくまでの早さは事例によってまったく違うが、共通しているのは、気づかれないまま放置され続けたものはひとつもない、ということだ。
間違いは今も続いている。直近の9月27日の回でも、AIはInboxの仕分けと、期限のない着手待ちタスクの見直しで、計2件をタイトルだけ見て扱いを決めた。Inboxの1件は「これから着手するもの」に振り分けたが、実際は修正が済んで結果の確認待ちだった。着手待ちの1件は「据え置き」にしたが、実際は実装して使い始めていた。どちらも、その週のうちに私がすでに手を付けていたものだ。これに気づいたのもAI自身で、私が指摘する前に、同じレビューの後半、その週のコミット履歴を確認する段階で食い違いを見つけ、自分から報告して訂正を提案してきた。私が承認して、2件とも正しい扱いに直した。なお、この段階は公開スキルの手順にはなく、自分用の手順にだけある工程だ。
これらの間違いが致命傷にならなかった理由は、AIが正確だからではない。間違いに気づくタイミングにはばらつきがあっても、放置されたままにはならない構造になっているからだ。「漏れないように完璧に見張る」という話ではなく、「間違えても、そのままにはならない」という話だと思っている。
詰まりは消えたのではなく、場所が動いた
Projects棚卸しは、以前は件数の多さから2回続けて先送りされていた。ある週は16件のnext欠落を「継続課題」として素通りし、次の回も20件中19件がnext欠落のまま持ち越された。
その後の回でまとめて処理し、25件あったプロジェクトのうちnext Actionが欠けていたものは22件から15件に、30日以上停滞していたものは10件から5件まで圧縮できた。
一方で、詰まりの主戦場はSomeday見直しに移った。ある週はSomeday行きのタスクが94件になり、全件が見直し待ち(⚠️)の状態になった。期限付きの6件だけ処理し、88件はその週も見直し待ちのまま残った。
翌週の8月23日には、30日以上見直していなかったタスクの見直し日をまとめて記録し、見直し待ちを64件から0件にした。ただしこれは1件ずつ中身を見直したのではなく、見直し日を一括で付け直した処理だ。その後、見直し待ちは9月7日に3件、9月19日に15件、9月27日には51件と、再び増えている。見直し待ちの印は「30日以上見直していない」ことなので、一括で付け直した日付は、30日たつとそろって期限を迎える。一度0件にした分が、30日後にまとめて見直し待ちに戻ってきているのだと考えている（51件のうちどれだけがその分なのかは確かめていない）。9月27日の回では、そのうち新しいもの15件を見直した。まだ片付いてはいない。
「詰まりが解消して終わり」ではなく、「詰まる場所が移動しただけ」というのが実態に近い。ただ、これは悪い話ではないと思っている。渋滞そのものが消えたわけではないが、渋滞がどこにあるかがレビューのたびに見えるようになった。次にどこを見ればいいかが分かる、というのは、見えていなかった頃とは違う状態だ。
まとめ:完璧な司会者を探すより、間違いが拾われる仕組みを作る
週次レビューが続かない原因は、意志の弱さではなく、「全部自分でやろうとする構造」にあると思う。AIに司会をやらせても、判断そのものは自分の仕事として残る。変わるのは、順番を決める負荷と、抜け漏れを検出する負荷が減ることだ。
そしてAIは完璧な司会者ではない。数え間違えるし、的外れな警告を出すし、中身を確かめずにタイトルだけで判断することもある。自分用に作った手順から操作が抜け落ちていたように、私の側の抜けもあった。それでも、間違いに気づくタイミングにばらつきはあっても、放置されたままにはならない構造があった。継続そのものも、一度は2ヶ月近く止まっている。仕組みを入れても、サボるときはサボる。記録から言えるのは、2ヶ月止まったあとでも再開でき、再開してからの7週間は、遅れながらも途切れていない、ということまでだ。何が戻るきっかけになったのかは分からないが、止まったところで終わりにはならなかった。
ここで紹介した/todoは、無料で公開しているClaude Code用のGTDスキルで、GitHubリポジトリからファイルを取得して使える。公開版の週次レビューには、私が自分用の手順で落としていた見直し日の記録も、手順として入っている。導入のハードルは正直に書いた通りある。それでも興味があれば、覗いてみてほしい。
この記事は はてなブログ からのクロスポストです。