この記事の実施記録（2026年8月3日）: GTDのトリアージ専任として作った「secretary」というエージェントが、3ヶ月以上ほぼ動かないまま眠っていた。それが1日のセッション内で3回連続で起動し、Inbox仕分け3件、タスクリスト（NEXT）の37件→26件、さらに26件→19件への整理をこなした。処理時間は291秒・155秒・443秒（実測値。Agent実行ログのduration_msで確認）。この記事で書きたいのは「AIエージェントが優秀だった話」ではない。判断が一貫していた理由は、GTDの運用ルールを明文化した文書と、それを実際にタスクへ適用・実行する仕組みという、2つの部品の組み合わせだった——という話だ。
タスク管理のリストが気づいたら100件を超えていた、という経験はないだろうか。私にもある。Notion・Todoist・Obsidian、どれを使っていても、しばらく放置すると「あとで見る」の山ができる。今回書くのは、その山を崩す作業を3ヶ月ぶりに動かしたAIエージェントに任せたら、拍子抜けするくらいあっさり片付いた、という話だ。
「実質、私は何もしていない」の意味 — 判断をやめたわけではない
先に断っておきたい。このタイトルは私自身の発言をそのまま使っているが、「私が何も判断しなかった」という意味ではない。
きっかけは、GitHub Issueのリストを見た私の「NEXT多いな」という一言だった。これがなければ整理は始まっていない。次に私は「COOがとか、Secretaryがとか個別のAgentの役割というより、Claude CodeのシステムにGTDの仕組みを組み込んでいるからできることだと主張したい」と方向を指定し、さらに「ルールだけじゃなくて/todoスキルも合わせた仕組みだと理解しているけど」と一段階踏み込んだ訂正を入れている。この記事の骨子——判断基準を書いた文書と、それを実行するツールの組み合わせが効いている——は、この3回の軌道修正を私自身が入れたことで固まった。
つまり私は、何を仕分けるか・どの切り口で捉えるかという判断基準をその都度示していた。AIエージェントがやったのは、その基準をIssue1件1件へ機械的に当てはめる作業だ。「実質、私は何もしていない」という感想は、その適用作業（1件ずつ読んで、判断して、ラベルを変える）から解放されたことへの驚きであって、方向づけをやめたわけではない。
3ヶ月止まっていたのに、判断基準がぶれなかった
secretaryは、GTDのInbox仕分けやsomeday→next昇格判断を専任するエージェントとして作った。2026年6月11日の組織健全性点検で役割を「判断を伴うGTDトリアージ専任」へ縮小し、「その後も発火ゼロが続けば退役を検討する」と申し合わせていた。実際、そこから直近まで作業ファイルはほとんど更新されないまま止まっていた。私の第一声は「めちゃくちゃ久しぶりにSecretary起動したな」だった。
注目したいのは、久しぶりに動いたことより、3ヶ月以上動いていなかったのに、動いた瞬間には過去と同じ判断基準が一貫して適用されたことだ。エージェントの「勘」や「慣れ」が判断を支えていたなら、これだけ間隔が空けば基準がぶれてもおかしくない。ぶれなかったのは、判断基準がエージェントの記憶ではなく、ops/playbooks/gtd/ 配下のMarkdown文書（以下「Playbook」。正式な技術用語ではなく、私たちが「運用ルールをまとめた手順書」を指して使っている呼び方だ）に保存されていたからだ。
動いていたのはPlaybookと/todoスキルの2層構造
「それはこのプロジェクト固有の話で、自分の環境では再現できないのでは」と思う人もいるだろう。結論から言うと、再現に必要なのは高性能な専用エージェントではなく、次の2つだ。
- 判断基準の層（Playbook）: 「各プロジェクトには必ず1つのNext Actionが紐づいていること」「『〜について考える』はNext Actionとして不適格」といったGTDの原則を、あらかじめ文書として書き出したもの
-
実行の層（
/todoスキル）: 判断結果を実際のタスク（今回はGitHub Issue）へ反映する機能。ラベルの一括付け替え、期日に応じた自動昇格設定、プロジェクトへの紐付けなどを行う。私が公開しているオープンソースのスキルclaude-todo-gtd（実体はシェルスクリプトtodo.shとその裏で動く処理系）がこれにあたる
ここでいうGTDの原則の出典は、デビッド・アレン著『新装版 はじめてのGTD ストレスフリーの整理術』だ。Playbookに書き出した判断基準は、この本にある考え方をエージェント運用向けに私が言い換えたものにすぎない。
Playbookだけあってもタスクは動かない。/todoスキルだけあっても、判断基準がなければ一貫性は生まれない。両方が揃っていたから、secretaryが3ヶ月ぶりに動いても、別のエージェントが担当しても、同じ判断・同じ処理に行き着いた。
secretaryが実際にやったこと — 判断の「型」を3つだけ
3回の起動でsecretaryはInbox仕分け3件、NEXT整理37件→26件、さらに26件→19件をこなした。全件は挙げないが、Playbookのルールがどう呼び出されたか、代表的な判断の型を3つ示す。
タスクの具体化（Inbox仕分け）: 抽象的なタイトルのままだった改善提案Issue2件を、「どのファイルの何行目に何を追記するか」が一目でわかる形にタイトル・本文を書き換えた。働いたのは「タスクは実行可能な単位まで具体化する」というGTDの明確化原則で、Playbookに明文化されている。この2件は後に私が該当箇所を修正し、コミットまで完了した。
逐次型と並列型の判別、順序依存の発見（NEXT第1弾）: 先頭フェーズが終わらないと次に進めない逐次型のプロジェクトは、先頭の未着手タスクだけをnextに残して残りをsomedayへ。並行して進められるプロジェクトは「既存の不具合対処を残し、新規機能の拡張を送る」ように絞り込んだ。あるプロジェクトでは「ドキュメントが整っていないと外部公開できない」という隠れた順序依存を見抜き、外部公開タスクだけをsomedayへ移している。ここで効いた「各プロジェクトには必ず1つのNext Actionが紐づいていること」という原則も、私が今回教えたのではなく、以前からPlaybookに書かれていたものだ。
期日タスクの設計転換と、削除前の差し戻し（NEXT第2弾）: 「特定の未来日にならないと着手できない」タスクは、期日が近づいたら自動でnextへ浮上させる設定に切り替えてsomedayへ格納する運用に変えた（期日が数日後に迫っていたものはnext据え置き）。一方、期日が過去のまま放置されていたタスクは機械的に削除せず、「まだ必要なタスクか」と私へ確認を差し戻した。大量の一括書き込みを伴うタスクをsomedayへ送る際には、「着手時は事前承認が必要なルールに該当する」と自ら注記もしている。
いずれの判断基準も、今回のセッションのために新しく作られたものではない。secretaryがやったのは「書かれたルールを個別ケースに1件ずつ当てはめて判定する」作業であり、判定結果をIssueへ反映したのは/todoスキル側の機能だ。
処理時間291秒・155秒・443秒 — ボトルネックはモデルではなく設計だった
作業を見ながら、私は「screatryってhaikuで動いてるんだっけ」とつぶやいている。これは勘違いで、正しくはsecretaryは model: sonnet に固定されている（.claude/agents/secretary.md で確認済み）。処理に時間がかかるのを見て「結構判断に時間かかるんだね。opusの方がよかったかな」とも漏らした。処理時間は以下の通り（実測値。Agent実行ログのduration_msをCOOが確認、2026-08-03）。
| 回 | 内容 | 対象規模（実際に手を加えたIssue数） | 所要時間 | ツール呼び出し数 |
|---|---|---|---|---|
| 1回目 | Inbox仕分け | 3件 | 291秒 | 26回 |
| 2回目 | NEXT整理・第1弾（4プロジェクトを精査） | 10件移動 | 155秒 | 22回 |
| 3回目 | NEXT整理・第2弾（全体見直し） | 19件相当 | 443秒 | 24回 |
※「対象規模」は実際に手を加えたIssue単位の件数で、NEXTリスト全体の総数変化（37件→26件、26件→19件）とは母数が異なる。
1回目のInbox仕分けは分類・タイトル書き換えまで踏み込む重い判断だったため対象3件でも291秒かかったが、2回目は4プロジェクト・10件に絞られたシンプルな判断だったため最短の155秒で済んだ——件数の多寡そのものではなく、判断の質と対象の絞り込み方が時間を左右している。
「opusの方がよかったかな」への答えは、この表から出ている。時間の長短を分けたのはモデルの知能ではなく、対象件数と作業の性質（一括判断で済むか、1件ずつ個別精査が必要か）だ。ボトルネックは「1件ごとに 情報取得→判断→実行 のループを回す」設計そのものにあった。
「Playbookを書くだけなら人間でもできるのでは」への回答
この数字は、もう一つの疑問——「Playbookにルールを書くだけなら人間でもできるのでは」——への答えにもなっている。その指摘は半分正しい。ルールを書くのは人間の仕事で、AIが発明したわけではない。ただし、37件・26件のタスクそれぞれについて「逐次型か並列型か」「順序依存はどこに隠れているか」を判別し、実行まで一気通貫でこなす作業は別物だ。19件相当の見直しに443秒・ツール呼び出し24回を要したという実測は、「ルールを知っていること」と「個別ケースに当てはめて実行すること」が別の作業量であることを示している。人間が手順書を片手に自分でやれば、相応の時間がかかる。
だからこそ改善の余地も設計側にある。私が指摘したのは、判断を一括してやってから/todoスキルの処理を一括で流す、という方向だ。対象Issue全件の情報を事前にまとめて取得し、判断はLLMが1回で行い、実行は一括操作でグループごとに流す——ただし、まだ実装して再計測したわけではないので、これは「効くはずの改善案」であって「効いた実績」ではない。ここは正直に留保しておく。
そして3回目の委任を投げた直後、私はこう漏らしていた。
「いいね、実質私は何もしていないのに、タスクが整理されていく」
Todoistでいいのでは? GUIがないと無理では?
「わざわざGitHub Issueでやる意味は? Todoistでいいのでは」という疑問は、半分は正しい。「運用ルールを明文化しておく」という考え方自体はツールを問わない。Todoist・Notion・Obsidianでも、「各プロジェクトには必ず1つの次にやることを紐づける」といった判断基準を自分の言葉でドキュメント化しておけば、同じ発想は活きる。ただし「書いたルールを37件・26件という規模のタスクへ一括適用し、ラベル付け替え・期日設定まで実行する」部分には、それを実行できる仕組み（API連携・自動化など）が別途必要になる。今回それを担ったのが/todoスキルだ。
「コマンドラインが使えないと無理でしょ」という疑問にも正直に答えると、今回の実行部分はClaude Codeというコマンドライン経由のAIエージェントが前提で、この構成をGUIだけでそのまま再現するのは難しい。ただ、この記事の本質は「運用ルールをその場の判断や記憶に頼らず、あらかじめ文書として書き出しておくと、担当者が変わっても・久しぶりに動かしても同じ判断に行き着く」という考え方の部分にある。ここだけ取り出せば、Notionのガイドラインページにタスク登録ルールを明文化する、Todoistのプロジェクトメモに判断基準を書いておく、といった形でGUIツールでも応用できる。2層構造のうち「ルールの明文化」はツールを問わず、「大量実行の手段」だけが環境に依存する。
まだ解決していないこと
成功した話ばかりでは正直ではないので、構造的に片付いていない課題も書いておく。
「期日が近づいたら自動でnextへ浮上させる」仕組みは、あくまで設定を切り替えただけであり、その設定を定期的にチェックして実際に浮上させる自動実行（スケジューラへの登録）はこの記事の時点でまだ行っていない。つまり誰か（私かエージェント）が定期的にチェックしない限り、自動昇格は実際には発火しない。secretary自身がこの点を注記している。「ルールを書いて設定を切り替えること」と「その設定を継続的に動かす仕組みを整えること」は、まだ別の作業として残っている。次にここを仕組み化できたら、また記事にしたい。
もう一つ、「AIに任せて本当に漏れない? 自分の目で確認しないと不安」という疑いには、前述の「期限切れタスクを削除せず私へ差し戻した」事例が答えになる。削除のような取り返しのつかない操作の手前ではユーザーに確認を戻す、という設計にしている。
今回言いたかったこと
私はこれまでも「Claude Code + GTD」というテーマで記事を書いてきたが、今回新しく書けたのは、3ヶ月以上不使用だったエージェントが、再稼働した瞬間に過去と同一の判断基準を適用したという事実を、処理時間・ツール呼び出し回数という定量データとともに示せたことだ。「エージェントの記憶や慣れ」ではなく「Playbookという外部化された文書」が判断の一貫性を担保している、という主張のいちばん強い証拠になっている。
タスク管理を一貫した判断で回していたのは、優秀なAIエージェントではなく、「運用ルールを明文化した文書」と「そのルールをタスクへ適用・実行するツール」の組み合わせという仕組みそのものだった。この2つさえ揃っていれば、担当が誰（人間か、どのAIか）でも同じ水準の判断に行き着く。「ツールを問わず使える部分（ルールの明文化）」と「実行基盤が必要になる部分（大量実行の手段）」を分けて持ち帰ってもらえたら、この記事の目的は達成できたことになる。
/todoスキルの実行部分を1件ずつ動かすのではなく、判断と実行をそれぞれ一括化する——今回の気づきを実装して再計測すると、次の問いが出てくる。判断を一括化した先に、人間がやるべき仕事はどこまで減らせるのか。私がそこにたどり着くまでの記録は、Zenn Booksの「コードを書けない私がClaude Codeで「AIチーム」を回すまで」にまとめている（序章無料）。
関連記事
- Claude CodeでGTDを組織のプロトコルにした話
- タスク管理ツールを3つ乗り換えた末に設計した——Claude Code × GTD で「対話ゼロ」のバッチ型ワークフロー
- 今度こそ！ Claude CodeでGTDを回す——/todo 完全ガイド
- 割り込みで頭がリセットされる問題を、Claude Codeで解消した話
この記事は はてなブログ からのクロスポストです。