Zenn Dev Tottoko Hamu Articles 2026 06 10 152352

Claude CodeでGTDを組織のプロトコルにした話

URL: https://zenn.dev/tottoko_hamu/articles/2026-06-10-152352
日付: 2026-06-25
Tier: Tier 3
要旨: Claude Code 複数体の運用で GitHub Issues のカスタムラベル @claude + GTD ラベル (next・waiting・someday) を使い、人間と AI が同じタスク管理システムに入る委任プロトコル。AI メモリの「いつか確認しよう」堆積が GTD の「オープンループ」問題と同型だと発見。メモリ整理 (58 件→35 件) と並行して週次レビューで Issue に転記。@claude ラベルで「Claude が担当するタスク」を明示、スキルバグ修正・公開待ち・分析判断の 3 パターン、タイトル+本文+ラベルで Claude が判断なしで動ける状態作成。

詳細

Claude Code メモリ整理 (58→35 件) 中に発見: AI メモリの「いつか確認」堆積が GTD の「オープンループ」と同型。オープンループとは処理されないまま頭(またはメモリ)に残る情報。人間の頭部にも AI メモリにも同じ問題が現れる。

メモリの 3 分類: 本当に必要な運用メモ(残す)・タスク (Issue 転記後削除)・解決済み判断メモ(削除)。これが GTD の「収集→処理→整理」と対応。

気づき: 自分の GitHub Issues 管理も無意識に GTD 構造を再発明していた。Issue=Inbox・next ラベル=Next Action・waiting ラベル=Waiting・someday ラベル=Someday。

@claude ラベルの仕組み: 人間担当=@me、Claude 担当=@claude。GTD ラベル (next/waiting/someday) と組み合わせで「Claude が次にやること」を一覧化。

実装パターン (累計 38 件、2026-05-29):

スキル修正 (Issue #1321): バグ報告・再現手順・修正案 (A/B/C)・SSoT ファイルパスを明記。Claude は skill-dev 経由で修正・完了時 Issue close。
公開待ち (Issue #1374): 時刻指定は人間・実行は Claude (スクリプト実行・結果確認・close)。waiting + @claude で「タイミング待ちの Claude 担当」を可視化。
分析→判断委任 (Issue #1351): GSC データ + URL → Claude がスラッグ特定→クエリ取得→writer へのリライト判断委任。「分析後どう扱うか」を本文に記載で Claude が迷わず動く。

共通パターン:

タイトル: 「誰が何をする」明記 ([skill-dev] プレフィックス等)
ラベル: @claude + GTD ラベル
本文: 手順・SSoT・完了条件。Claude が判断なしで動ける状態。

最小手順: (1) @claude ラベル作成 (Settings→Labels) (2) Issue に委任内容・手順・完了条件記載+@claude+next ラベル (3) 週次レビューで @claude Issue 確認・完了 close・新規登録。既存 GTD 習慣にラベル 1 個追加で開始可。

メモリ管理との並行: 週次レビューで AI メモリ確認→Issue 転記できるものは転記→削除。メモリとIssue の役割分担が自然と整う。

未完成点: @claude Issue を Claude が自律的に拾うサイクルはまだ手動トリガー (週次GTD レビュー時)。自動化は今後課題。

原則: GTD は人間の脳の問題を解いたフレームワークだが、「未処理情報が溜まるとシステム機能低下」という同じ問題を持つ全システム (脳・AI メモリ・タスク管理) に適用可能。オープンループを外に出すことで、システムの処理能力が本来の仕事に集中。

Zenn Dev Syunpp Articles A6398e9fabccd4 Zenn Dev Ytkdm Articles Codex Auto Review