この記事について: AIツールで日常業務をこなしながら、タスク管理だけは別のアプリに置いている人に向けて書いた。タスク管理をAIの作業環境の内部（コードや設定ファイルと同じ場所）に置くと何が変わるのかを、2026年8月時点の実測データ（完了Issue1,554件・稼働中のリカレンスタスク8件・エンジン本体4,824行）とともに解説する。
以前、Claude Code + GTDに切り替えたら、タスク管理が育ち始めたという記事で、作業しているAIと同じ場所にタスク管理を置くと「文脈が乗る」体験を書いた。今回はその先の話をする。
文脈が乗るのは結果であって、本質ではない。本質は、タスクの読み手と書き手が人間からAIに変わる、という構造の変化にある。この変化が起きると、タスク管理は「アプリ」ではなく、他の自動化から呼び出せる「部品」になる。
Claude Codeの内部にタスク管理を置くと何が変わるのか
私のタスク管理は GitHub Issues の上に構築している。GitHub Issues は Claude Code が普段からコードやドキュメントを操作している場所と同じで、gh コマンドを使えば AI が直接読み書きできる。
外部の SaaS だとこうはいかない。API連携を自分で組むか、開発元に機能要望を出して対応を待つか、どちらかしかない。タスク管理が「AIが作業している場所の外」にある限り、AIがタスクデータに触れる経路は必ず一段狭くなる。
「別に Notion でもいいのでは」と思うかもしれない。論点は Issues かどうかではない。AI の作業環境と、タスクを置く場所が同じかどうか、これに尽きる。たまたま私の環境では GitHub Issues が gh CLI 経由で AI から直接読み書きできる場所として機能している。Notion の API 等でも同じ条件（AIが直接読み書きできて、他のスキルからも呼べる）を満たせば同種の設計は成立しうるはずだが、そこは私自身検証していない。
具体的に何が起きているか——6つの実例
ここから紹介する6つの実例は、コードを書けなくても成立する。私自身、タスク管理エンジン（現在4,824行）のコードを1行も自分で書いていない。「こういう挙動にしてほしい」とClaude Codeに伝えただけだ。初版はわずか1.5時間の対話で出来上がっている（具体的な行数は後述する）。
1. AIがタスクを起票する側になる
セッションの会話履歴を解析し、修正指示・繰り返しパターン・ルール違反の指摘・フラストレーション・繰り返しエラーを「改善シグナル」として抽出し、Issueに自動登録するスキルを運用している。
フローはこうだ。
- 人間がスキルを起動する（人間のトリガーはここだけ）
- サブエージェントが会話履歴（JSONL）を解析し、改善シグナルをJSONで返す
- 承認を挟まず、そのままIssueが自動登録される
- 登録先は必ず「未処理（inbox）」ラベル
- 事後にIssue件数とタイトルが報告される
「AIに勝手にタスクを作られたら収拾つかないのでは」という不安はもっともだ。ただ、ここで効いているのは承認ボタンではない。inboxというGTDの緩衝材だ。自動起票されたタスクはinboxに入るだけで、「今やること（next）」に上がるにはトリアージという別の判断を通る必要がある。inboxは2026-08-11時点の実測で0件——起票されたものはすでに仕分け済みで、溜まっていない。
承認を人間が毎回挟むのではなく、AIには自由に書かせて、「何をnextに上げるか」の判断だけを人間が持つ。この分業のほうが、承認ボタンを押す作業をAIから取り返すより長続きする。
2. 定期タスクが自己再生成する
週次レビュー・週次アクセス分析・週次changelog記事といった繰り返し発生するタスクは、リカレンス設定を持つIssueとして登録してある。完了すると次回分を自動で複製する仕組みで、2026-08-11時点で8件が稼働中だ（実測）。人間は完了報告を待つだけになる。
3. 期限通知はAIを介さない
期限超過リマインドはLLMを呼ばず、シェルスクリプトが直接Slack通知・デスクトップ通知を送る。「AIっぽい処理」に見える部分こそ、実際は決定的なスクリプトに落としてコストと不確実性を下げている。
4. 他のスキルから同じ基盤を呼べる
健康記録用のスキルやセッション振り返りスキルは、いずれも同じタスク管理コマンドを経由してIssueを登録している。タスク管理は独立したアプリではなく、複数の自動化から再利用される「共通の下請け層」になっている。
5. 登録経路をルールで一本化できる
プロジェクトの共通ルールに「タスクの登録・更新は専用コマンド経由のみ。GitHub CLIでのIssue直接作成・編集は禁止」と明記している。ラベル体系・リカレンス設定・期限フォーマットのバリデーションが1箇所に集約されるので、AIが何百件Issueを作っても形式が崩れない。外部SaaSでは、Web UI・モバイルアプリ・APIという複数の入力経路がそれぞれ別々に検証ロジックを持つことが多く、この一本化は難しい。
6. 作った道具を配布できる
同じタスク管理エンジンをGitHub上の公開リポジトリとして配布している。外部SaaSを「使う」側で終わらず、「作って渡す」側に回れる。内部で育てたツールだからこそ発生する派生効果だ。
数字で見る成長——4ヶ月で4.5倍
「タスク管理ツールを自作するのはさすがに大げさでは」と感じる人もいるだろう。最初から4,824行を書く必要はない。私の場合も、最初は「Issueを1件登録するコマンドがある」状態から始まっている。
- 初版: 2026年4月5日、約1.5時間の対話で1,082行 + テスト123件が生成された
- 現在（2026-08-11実測）: エンジン本体4,824行、ラッパースクリプト177行
- 公開配布版のドキュメント: コマンド定義書306行 + マニュアル848行
約4ヶ月で1,082行から4,824行、約4.5倍に成長した。これは機能要望を出して開発元の対応を待った結果ではない。使いながら不満が出るたびに、その場で直した結果だ。
運用規模もあわせて書いておく。GitHub Issuesの完了件数は1,554件、Issue番号は#1798まで発行済みだ（2026-08-11時点の実測値。Issueの起票・完了は日々発生するため、測定するタイミングによって数件のブレが出る）。未完了の内訳は主要5カテゴリだけで次の通り（同時点の実測）。
- next（今すぐやること）: 19件
- someday（いつかやる）: 108件
- project（複数ステップの取り組み）: 21件
- waiting（相手待ち）: 4件
- inbox（未処理）: 0件
このほかに定期実行用のタスク（6件）や参照用のメモ（7件）といった別カテゴリも運用しており、未完了の総数はこの5カテゴリの合計とは一致しない。
Claude Codeのタスク管理でよくある疑問
Q. GitHub Issues以外の場所でも同じことはできますか？
条件は「AIの作業環境と同じ場所に置けるか」であって、Issuesであること自体が必須ではない。AIがAPI等で直接読み書きでき、他のスキルからも呼び出せる場所であれば、原理的には成立するはずだ。ただし私自身が検証したのはGitHub Issuesの範囲に限られる。
Q. 内製化にはどれくらい時間がかかりますか？
最初から全機能を作る必要はない。私も「Issueを1件登録するコマンドがある」状態から始めて、不満が出るたびに機能を足していった。最初の一歩にかかった時間は1.5時間、行数にして1,082行だった。
Q. AIが自動でタスクを作ると収拾がつかなくなりませんか？
起票は承認なしで自動的に行われるが、登録先は必ずinbox。「今やること」に上げるかどうかは別のトリアージ判断を通る。ここがある限り、AIが自由に書き込んでも運用が崩れることはない。
Claude Codeの内部でタスク管理が「部品」になるということ
タスク管理を「内部」に置くというのは、便利になるという話ではない。タスク管理そのものが、他の自動化から呼び出せる部品になる、という話だ。
AIがタスクを起票し、リカレンスが自己再生成し、スクリプトが期限を監視し、他のスキルが同じ基盤を呼び、ルールが登録経路を一本化し、育てた道具を配布する——これらはすべて、タスク管理がAIの作業環境の内側にあるから成立する。外部SaaSでは、API連携か機能要望の待ち行列にしかならない部分だ。
タスク管理を内部の部品として育てると、次の問いが出てくる——GTDのサイクル（収集・処理と整理・実行・振り返り）そのものを、AIにどこまで委ねてよいのか。自分のタスク管理をまるごとClaude Codeに任せていった記録を9パート・約7万字でまとめたのがZenn Booksシリーズの5冊目だ。とくに第7章「あなたの装置を作る」は、AIに話しかけるだけでGTDタスク管理ツールができるまでを扱っていて、この記事で紹介した実例の土台にあたる話になっている。
参考リンク
- 今度こそ！ Claude Code で GTD を回す /todo 完全ガイド
- Claude Code の /todo スキルをOSS化するまで——V1モノリスからV2三層設計へ
- タスク管理・リサーチ・記事公開を全部AIに振ったら、人間はどこで判断すればよくなったか
- saitoko/claude-todo-gtd（GitHub上の公開リポジトリ）
- はじめてのGTD ストレスフリーの整理術（デビッド・アレン）
この記事は はてなブログ からのクロスポストです。