この記事の実施記録（2026年5月）: Claude Code でAIエージェント複数体を運用する中で、GitHub Issues の @claude ラベルを使った委任プロトコルを設計・運用中。2026-05-29時点で累計38件の委任実績あり。GTDの「Inbox/Next/Waiting」分類がそのままAI委任のインターフェースとして機能することを発見した記録。
AIとのやり取りが増えてきたある日、私はClaudeのメモリを整理しようとして、思いがけない発見をした。
メモリの件数が、最初は58件あった。週次レビューのたびに掃き出して、52件になり、さらに整理して、今は35件（2026-05-29実測）に落ち着いている。整理しながら気づいた。不要な「いつか確認しよう」が大量に溜まっていたのだ。「あとで使うかもしれない設定値」「もしかしたら必要になる運用メモ」。人間の頭の中と、まったく同じ状態になっていた。
これはGTDが言う「オープンループ」だ、と思った瞬間、視野がぐっと広がった。
メモリ整理をしていたら、GTDが見えてきた
GTDを知っている人には「そのまんまじゃないか」と言われそうだが、私は実際に整理作業の手を動かすまで、AIのメモリとGTDが同型の問題を持っているとは意識していなかった。
GTDの根本にある洞察は「頭の中に仕掛かりを置かない」ことだ。やろうと思っていること、気になっていること、いつか確認しようと思っていること——これらを頭の外に出し、信頼できるシステムに預けることで、頭は「いまここにある仕事」に集中できる。
AIのメモリも同じだった。メモリに「いつかやる」が溜まると、毎回のセッションで不要な情報を引き連れることになる。処理されないまま残るメモリは、GTDの言葉で言えばオープンループだ。
整理したメモリの中身を見ると、3つのパターンに分類できた。私はGitHub IssuesをGTDのtodoシステムとして使っており（詳しくは後述）、タスクはそこに転記している:
- 本当に必要な運用メモ → 残す
- todoに移せるタスク → Issueに転記してメモリから削除
- すでに解決済みの判断メモ → 削除
この3分類がそのままGTDの「収集→処理→整理」と対応していた。
AIのメモリとGTDは、構造が同じだった
「GTDって難しくない？」と感じる人も多いと思う。GTDには独特の用語体系があり、全体像を理解しようとすると書籍一冊分の概念が出てくる。ただ、この記事で使うGTDはもっとシンプルだ。「Inbox / Next / Waiting / Someday」という4つの分類だけ知っていれば十分で、ツールはGitHub Issuesとラベルだけで済む。
AIメモリとGTDの対応関係を整理するとこうなる:
| AIメモリの状態 | GTDの概念 | 対処 |
|---|---|---|
| 「いつか確認しよう」の堆積 | Inbox（未処理の収集） | 週次レビューで仕分け |
| 繰り返し必要になる手順・設定 | Next Action の素材 | Issueにタスクとして転記 |
| 「外部依存で動けない」状態 | Waiting | 外部イベント待ちIssueに |
| 削除できないが今は使わない | Someday | Issueに someday ラベルで |
「週次レビューでメモリを掃き出す」は今では毎週の習慣になっている。レビューの中でGitHub Issueに転記できるものはIssueへ、判断が済んだものは削除する。メモリには「Claude Codeが毎セッションで参照する運用上の事実」だけを残す。
この仕組みの最大の効果は、「メモリに置かなくてよい情報をIssueに預けることで、Claudeがセッション開始時に余分な情報を引きずらなくなった」ことだ。
GitHub Issueも、同じ解に収束していた
AIのメモリ管理でGTDの構造を発見したとき、ふと気づいた。私がGitHub Issueでタスク管理しているやり方も、同じ構造ではないか。
- Issue = 収集（Inbox）。気になったことは全部Issueに投げる
-
nextラベル = 次にやること（Next Action） -
waitingラベル = 外部待ち（Waiting） -
somedayラベル = いつかやる（Someday） - Milestone = プロジェクト
知らず知らずのうちに、GitHubのラベルシステムでGTDを再発明していたわけだ。
「人間もAIもツールも、オープンループという同じ問題を解こうとするとGTDに似た構造に収束する」という仮説が頭に浮かんだ。そして次の問いが生まれた: AIのタスクはどこに置くか？
人間のタスクはGitHub Issueで管理している。では、AIに委任したタスクも同じシステムで管理できないか。
@claude ラベルとは何か——GitHub IssueでAIに委任する仕組み
GitHub の @claude ラベルは、私が Claude Code 運用のために作ったカスタムラベルだ（公式機能ではなく、私が個人的に命名した独自の運用）。通常のタスクと区別するためだけのラベルで、「このIssueはClaudeが担当する」という意味を持たせている。
仕組みはシンプルだ。人間担当のタスクには @me（または単に担当者なし）、Claude担当のタスクには @claude ラベルを付ける。GTDラベル（next / waiting / someday）と組み合わせることで、「Claudeが次にやること」「Claudeが外部待ちのもの」が一目でわかる状態を作る。後述の /todo コマンドを使えばコマンドライン一発でIssue操作ができるが、ラベルを手動で付けるだけでも委任は成立する。
@claude ラベルで、人間とAIが同じシステムに入る
「実際に使えるの？」という疑問はもっともだ。なので具体的な運用実例を3つ紹介する。いずれも2026-05-29時点で実際に使っている仕組みだ（累計38件、オープン2件）。
GitHub Issueに @claude ラベルを作り、Claudeが担当するタスクに付ける。これだけでAIと人間が同じIssueトラッカーの中でタスクをやり取りできるようになる。
例1: スキルバグ修正の委任（Issue #1321）
タイトル: bug: /todo の --label オプション指定がタイトルに混入する
ラベル: next + @claude + p3
Issueの本文には「症状・再現手順・修正提案（A/B/C案）・SSoTファイルパス」を書く。私がIssueを登録して @claude ラベルを付ければ、次のClaude Codeセッションでこのタスクが拾われる。Claudeは skill-dev エージェント経由で修正し、完了後にIssueをcloseする。
鍵は「何を渡すか（再現手順）」「どこを直すか（SSoTファイルパス）」「どの案か（提案番号）」が本文に明文化されていることだ。Claudeが判断なしに動ける状態を作る。
例2: 公開待ちの管理（Issue #1374）
タイトル: はてな公開: claude-code-natural-consult-to-todo
ラベル: waiting + @claude + #公開待ち
スケジュール管理は私がする（公開時刻の指定）、実行はClaude（公開スクリプトの実行・結果確認・Issueのclose）。waiting + @claude の組み合わせが「タイミング待ちのClaude担当タスク」を一目で示す。
例3: 分析→判断の委任（Issue #1351）
タイトル: GSC観察由来のCTR低2記事リライト判断（writer委任）
ラベル: next + @claude + p2
私がGoogle Search ConsoleのデータとURLをIssueに記載して登録する。Claudeがスラッグ特定→クエリ取得→writerへのリライト判断委任を実行する。「分析した結果をどう扱うか（別タスクとして切る）」まで本文に書いておくと、Claudeが迷わず動ける。
3つの実例に共通するパターン
| 要素 | 書き方 |
|---|---|
| タイトル | 「誰が何をする」を明記（[skill-dev] プレフィックス、はてな公開: プレフィックス） |
| ラベル |
@claude + GTDラベル（next/waiting）の組み合わせ |
| 本文 | 手順・SSoT・完了条件が書いてある（Claudeが判断なしで動ける） |
この3点セットがあれば、私がセッションでIssueを開いてClaudeに「このIssue処理して」と言うだけで委任が成立する。
明日から試せる最小手順
「AIのメモリとか、ハードルが高い気がする」という感覚はわかる。でも始め方は驚くほどシンプルだ。GitHub IssuesとラベルがあればすぐGTD委任システムが動く。
ステップ1: @claude ラベルを作る
GitHubリポジトリの Settings → Labels から @claude ラベルを作成する。
- 色:
#FBCA04（黄色、目立つ） - 説明:
Claudeが担当するタスク
GTDラベルも合わせて作ると管理しやすい:
-
next（次にやること） -
waiting（外部待ち） -
someday（いつかやる）
このラベル体系と /todo スラッシュコマンドは claude-todo-gtd としてOSSで公開している。Claude Code の設定に組み込むことで、Issue操作をコマンド一発で行えるようになる。設定手順と全機能の使い方は「今度こそ！ Claude Code で GTD を回す /todo 完全ガイド」にまとめている。
ステップ2: AIへの委任をIssueに書く
委任したいタスクをIssueとして登録する。書くべき内容:
-
タイトル: 「[誰に][何を]してほしいか」（例:
[writer] GTD記事のH2-3を書く） - 本文: 手順・素材の場所・完了条件
-
ラベル:
@claude+next
コツは「自分がやるとしたら何をするか」を書くことだ。Claudeは手順書を読んで動ける。判断まで任せたいなら判断基準を、実行だけ任せたいなら手順を書く。
実際のIssue本文はこのくらいのボリュームで十分だ:
## やること
- `/todo` の `--label` オプション実装を skill-dev で修正する
## 再現手順
1. `/todo next "タスク" --label p1` を実行
2. タイトルに「--label p1」が混入する
## SSoT
workspaces/skill-dev/todo/SKILL.md
「何を・どこで・どう確認するか」の3点があれば、Claude は判断なしで動ける。
ステップ3: weekly reviewに「Claudeの担当Issue」を確認する
自分のGTD weekly reviewのタイミングで、@claude ラベルのIssueを確認する:
- 完了したIssueをcloseする
- 停滞しているIssueに追記する
- 新しく委任できることをIssueに登録する
このサイクルを1週間回すだけで、「AIと自分が同じGTDシステムにいる」状態になる。既存のGTD習慣にラベル1個追加するだけで始められる。週次レビューがコンテキストスイッチ後の復帰にどう機能するかは「割り込みで頭がリセットされる問題を、Claude Code で解消した話」で詳しく書いている。
なお、AIのメモリ管理（58件→35件への整理）は別の話だが、「週次レビューでメモリを確認してIssueに転記できるものは転記する」という習慣を並行して作ると、メモリとIssueの役割分担が自然と整っていく。
GTDは人間の認知の問題を解いたフレームワークだった
ここまで書いてきて、改めて確認できることがある。
GTDが「頭の中のオープンループを外に出す」という発明をしたのは、人間の脳という特定のシステムに向けたものだった。しかし実際には、AIのメモリ管理でも、GitHubのIssueトラッカーでも、「オープンループを持つシステムはすべてGTDが有効」という構造が現れる。
人間の脳、AIのメモリ、タスク管理ツール——どれも「未処理の情報が溜まるとシステムの機能が低下する」という同じ問題を持っている。GTDは特定のツールや技術のためのノウハウではなく、情報を処理するシステム全般に適用できる原則だったわけだ。
AIチームを持ったことで、私のGTDは個人の生産性ツールから、人間とAIの協働のプロトコルに変わった。@claude ラベルがそのインターフェースになっている。
一つ、正直に書いておく。この仕組みはまだ完成していない。@claude ラベルのIssueをClaudeが自律的に拾って処理するサイクルは、毎週のGTDレビューセッションで手動でトリガーしている。「Claudeが自分で自分のIssueを能動的に処理し始める」自動化は、今後の課題だ。
あなたのAIのInboxは今、何件溜まっていますか？
AIに何かを「あとで頼もう」と思ったまま、どこにも書き留めていないオープンループが、頭の中にいくつあるかを数えてみてほしい。それをGitHub Issueに書き出して @claude ラベルを付けるだけで、次のセッションから委任が始まる。
GTDが次に解くのは、あなたとAIの間に積み重なるオープンループかもしれない。
あわせて読む
- コードを書けない私がClaude Codeで「AIチーム」を作るまで（Zenn Book Vol.1）— AIチームをゼロから組み上げる過程
- コードを書けない私がClaude Codeで「AIチーム」を回すまで（Zenn Book Vol.2）— チームを継続運用する過程
- コードを書けない私がClaude Codeで「AIチーム」と書き続けるまで（Zenn Book Vol.3）— ブログ執筆ストーリー（仕込む・書く・届ける・回収する）
Amazon アソシエイトリンク: GTDの原典はデビッド・アレン著「ストレスフリーの仕事術 ─ 仕事と人生をコントロールする52の法則」（英語原著は "Getting Things Done"）。本記事で触れた「オープンループ」「Inbox」「Weekly Review」の概念が体系化されている。
この記事は はてなブログ からのクロスポストです。