あるとき、私のNotionとGitHubのタスクボードが同時に崩壊した。
Claude Codeにフィーチャー実装を頼んだら、エージェントが自律的にサブタスクを生成して自分のTodoリストに書き込み始めたのだ。私の「今週やること」リストには、私が書いたタスクとClaudeが書いたタスクが混在していた。優先度も、担当者も、完了基準も曖昧なまま。「これは誰が何をするタスクだっけ」と考えるたびに作業が止まった。
これはツールの設定ミスではなく、「AIエージェントが自律的にタスクを作る時代」に私たちのワークフロー設計がまだ追いついていないという構造的な問題だった。
Todoリストが2層化する「新しいカオス」
Microsoft Work Trend Index 2025 によると、ナレッジワーカーが1日に中断される回数は平均275回、約2分に1回のペースで集中が途切れる。中断後に集中を取り戻すには平均23分以上かかるという Gloria Mark らの研究 もある。職場で使うSaaSの数も年々増え続けており（Okta Businesses at Work 2025 によれば1社あたりのアプリ数は過去最多）、ツールを跨ぐコンテキストスイッチは無視できないコストになっている。
こうした状況に対して、GTDやカンバン、WIPリミットといった手法が処方箋を提示してきた。インボックスに全てを入れ、外部化することで認知負荷を下げるというGTDの考え方は、2026年時点でも有効だ。
しかしAIエージェントは、GTDが想定していなかった問題を持ち込んだ。エージェントが「やるべきことを自律的に見つけて追加する」機能を持つようになると、インボックスは人間が書いたタスクだけでなく、エージェントが生成したタスクで膨張する。人間のTodoとエージェントのTask listが同じ場所に混在すると、「これは誰が判断して、誰が実行するのか」という問いに答えられなくなる。
WIPリミットを徹底するチームほどリードタイムが短く、コンテキストスイッチも減るというのはカンバン運用の経験則だ（Atlassian: Kanban WIP Limits 参照）。だがエージェントが新しいタスクを次々と追加し続ける環境では、WIPリミットを人間側にだけかけても解決しない。エージェント側にも同様の制約が必要になる。
Claude Code TaskツールのTodoWrite→Task管理への進化
Claude Codeは、この問題をツール設計の変更で応えようとしている。
旧バージョンの TodoWrite / TodoRead は、セッション内のTodoリストを1回の呼び出しで配列ごと上書きするシンプルな仕組みだった。セッションをまたいで状態は消え、依存関係も設定できなかった。
Claude Code v2.1.142以降で導入された TaskCreate / TaskUpdate / TaskGet / TaskList は、設計思想が根本的に変わっている。公式ドキュメント に基づくと、設計思想の変わった点は次のとおりだ。
タスクがディスクに永続化される
生成されたタスクは ~/.claude/tasks/ に保存され、セッションをまたいで参照・更新できる。複数のターミナルセッションが CLAUDE_CODE_TASK_LIST_ID 環境変数を共有すれば、複数のClaudeセッションが同一のタスクボードを参照して協調できる。複数エージェントを並列で動かすチームなら、これは大きな違いになる。
依存関係が設定できる
TaskUpdate の addBlockedBy パラメータで、「T002はT001の完了後に開始」といった依存関係を記録できる。メルカリが Agent-Spec Driven Development（ASDD） でMarkdownのSpecファイルにT001〜T009の依存関係を記述していた実務に近い構造を、Claude Code自体が持つようになった。
タスクのライフサイクルが明確になる
pending → in_progress → completed という状態遷移が明示的に管理される。エージェントが「どこまで進んだか」を人間がリアルタイムで確認できる可視性は、「今何が動いているか分からない」という不安を減らす。
ただしこれはあくまでClaude Code内部のタスク管理だ。ExternalのJiraやLinearと自動同期する機能ではなく、統合は自分で設計する必要がある。
主要ツールのAI統合——2025〜2026年の現在地
タスク管理ツール側でもAI統合が急速に進んでいる。競合の動きを把握しておくと、どのツールに自社のワークフローを乗せるかの判断材料になる。
Linear AIとLinear Agents
LinearのAI機能は、新しいIssueの自動トリアージ・ラベリング・ルーティング、コメントスレッドのサマリー、重複検出といった機能を提供している。2026年の大きな変化は「humans and agents as peers（人間とエージェントをチームメンバーとして同等に扱う）」という思想が具体化したことだ。Claude CodeやDevin、GitHub Copilotといったサードパーティのエージェントが、LinearワークスペースのメンバーとしてOAuthスコープ付き権限でIssueをアサインされる。チームで「チケットからPRまでのサイクルが20〜40%速くなった」という報告もある（buildbetter.ai, 2026）。
Notion Custom Agents
2025年9月のNotion 3.0でAgentsが正式リリースされ、2026年2月のNotion 3.3でCustom Agentsがスケジュール・トリガーによる24時間完全自律実行に対応した（Notion公式ブログ）。Rampは300以上のQ&Aエージェントをデプロイして製品ロードマップへの問い合わせに自動回答し、Remoteはタスクルーティングエージェント1体で週20時間の作業を削減・チケットの95%超を自動トリアージして25%以上を自律解決したという事例が公開されている。
GitHub Copilot Coding Agent
2025年9月にGAとなったCopilot Coding Agentは、GitHub IssueをPlain Englishで書くとエージェントがリポジトリを調査してプランを立て、コードを書き、Draft PRを自動で開く。2026年3月からはレビューコメントをエージェントに直接渡してfixするPRを自動生成できるようになった。2026年6月17日にGAとなったCopilotデスクトップアプリ（GitHub公式ブログ）は、Issue・PR・ブランチに紐づいたエージェントセッションを起動・監視・検証・出荷する管制塔として機能する。
Heightが示した教訓
ここで触れておきたいのが、AI-native PMツールのパイオニアとして注目されたHeightの終了だ。受信バグのトリアージ、バックログのグルーミング、ブロッカーのサーフェシングをAIが自律実行するというコンセプトは先進的だったが、Heightは2025年9月24日にサービスを終了した。AI自律化だけでは差別化にならず、チーム協働・インテグレーション・長期的な信頼性が必要だという現実を、この事例は示している。ツール選定では「AIが何をしてくれるか」と同時に「そのツールがどれだけ長く使えるか」も問わなければならない。
人間TodoとエージェントTask listの統合パターン
では実際に、どう統合するか。実務で機能しそうなパターンをいくつか整理する。
親子パターン（人間 = Epic、エージェント = Sub-task）
最もシンプルな構造だ。人間が大きな方向性（Epic）を書き、エージェントがその下に実行タスクを生成する。
[人間のTodo]
Epic: 認証モジュールのリファクタリング（優先度: High）
├── [Agent Task] T001: JWTライブラリの依存関係更新
├── [Agent Task] T002: リフレッシュトークン実装（T001に依存）
└── [Agent Task] T003: 既存テストの修正（T001・T002に依存）GitHub Issues + Copilot Coding AgentやLinear AI + Claude Codeの組み合わせがこのパターンに近い。人間はEpicレベルの意思決定に集中し、サブタスクの実行はエージェントが管理する。リスクはEpicの定義が曖昧だとエージェントが意図しないサブタスクを生成することだ。Issueを書く際に「何をしてほしくないか」を明示するのが現場での対処になる。
並行レーンパターン（Human Lane / Agent Lane）
同一プロジェクトボードに2本のレーンを作り、人間の意思決定タスクとエージェントの実行タスクを物理的に分離する。
Projectボード
├── Human Lane: 設計・レビュー・意思決定
│ ├── PRD作成（PdM）
│ ├── Agent Specレビュー（エンジニア）
│ └── 品質ゲート確認（EM）
└── Agent Lane: 実行・変換
├── T001: 実装（Human Laneのレビュー完了後に開始）
├── T002: テスト生成
└── T003: PR作成メルカリのASDDで公開されているStream A/B/C設計はこのパターンに近く、LinearやAsana AI Studioのボード設計でも実現できる。人間とエージェントの進捗を同一ビューで確認できることで、ボトルネックが可視化される。注意点はAgent Laneのタスクが爆発的に増えてボードが混雑することで、WIPリミットはAgent Laneにも設定しておく方がいい。
承認ゲートパターン（提案→承認→実行）
エージェントがアクションを提案する段階と実行する段階を明示的に分け、人間の承認をゲートとして挟む設計だ。
エージェント: タスクを分析・アクション候補を生成（propose）
↓ [承認ゲート]
人間: レビュー・承認・棄却
↓（承認の場合）
エージェント: 実行（commit）→ 完了報告 + 次の候補を提示すべてのアクションをゲートに通すとボトルネックになる。実際の運用では「不可逆なアクション」「本番システムへの書き込み」「コスト発生を伴うAPI呼び出し」にはゲートを設け、読み取り専用・内部ドキュメントのサマリー生成などはゲートなしで自動実行するというルールを最初に決めておく。エスカレーション率を10〜15%程度に設計できると、人間の負荷が適切に保たれる。
Notion Agentsの公式ドキュメントでも「見慣れないコンテンツへのアクセスを許可する前にレビューを推奨する」と明記されており、最小権限の原則はエージェント管理でも基本だ。
メルカリASDDから学ぶ「上流は人間、下流はエージェント」
これらのパターンを整理するための判断軸を、メルカリの公式テックブログが2025年末に公開したASDDのレポートが明確に示している。
メルカリは2025年7月にAI Task Forceを組成し、開発プロセスを「Vibe CodingからAgentic Codingへ」転換する実験を進めてきた。ASDDの核心は2段階の分業だ。まずエンジニアが資料・コードベース・Slackログを統合して「Agent Spec」を生成し、タスクIDと依存関係を定義する。次にSpecに基づいてエージェントが独立したタスクを並列実行する。PRを「合理的かつ動作可能な最小単位」に細分化することで、AIが書いたコードでもレビューのストレスがないと報告されている。
このプロジェクトで発見した最重要の気づきが「上流がボトルネックになる」という点だ。実装・テスト・変換といった下流の作業はエージェントに委任できる。しかし仕様確定・設計判断・受け入れ基準の合意という上流は、むしろエージェント導入後に人間の時間が求められる場所になった。「全プロセスを非同期化してエージェントに渡せばいい」という発想が通用しないことを、この事例は具体的に示している。
SmartHRも類似の役割分担を採用している。「AI側：データ変換・整備・パターン認識・提案生成、人間側：最終意思決定・戦略判断・倫理的責任」という分類は、タスク管理の設計にそのまま使える判断基準だ。
統合設計で見落としやすいリスク
タスクの自動生成によるノイズ
エージェントが自律的に生成したタスクと人間のTodoが混在すると優先度判断が機能しなくなる。Human LaneとAgent Laneを物理的に分離し、エージェントが生成できるタスク数にもWIPリミットを設ける。エージェント生成のタスクには「提案元・生成理由・影響範囲」のメタデータを必ず付与することで、後から人間が判断しやすくなる。
エージェントの想定外スコープ拡大
依頼スコープを超えたファイル変更や本番システムへの書き込みが起きるリスクがある。最小権限の原則は基本として、不可逆アクションには承認ゲートを設置する。Claude Codeでは CLAUDE_CODE_ENABLE_TASKS=false で旧TodoWriteモードに戻すオプションも残されているため、段階的な移行も可能だ。
可視性の喪失
マルチエージェントが並列でタスクを実行すると「今何が動いているか」が人間から見えなくなる。Strata.ioの調査では「ガバナンスなしに可視性もなし。エージェントが何をするかが見えなければ最小権限原則の施行も不可能」と指摘されている。Claude Codeの TaskList ツールと ~/.claude/tasks/ の永続ストレージ、Notion AgentsやLinearの実行ログを組み合わせて可視性を担保する。
責任所在の曖昧化
マルチエージェント環境では「どのエージェントが何をしたか」の追跡が難しくなる。全エージェントアクションに実行者ID・タイムスタンプ・実行根拠を記録し、AIが書いたコードのPRには「AI generated」タグを付けて人間がレビュー責任を持つことを明確にする。
今週から試せること
まず現在のTodoリストを「人間にしかできない判断（設計・承認・意思決定）」と「エージェントに委任できる実行（実装・テスト・変換）」に分けてみてほしい。この分類自体は30分あればできる。
次に、LinearでもNotionでもGitHub Issuesでも、Agent Lane専用のカラムかラベルを一つ作って、エージェントが生成するタスクをそこに集める。まず「見える化」するだけで、混在状態より大きく改善する。
Claude CodeのTaskツールは ~/.claude/tasks/ への永続化と CLAUDE_CODE_TASK_LIST_ID による複数セッション共有が効く。チームで並列作業するときに最も差が出る。公式ドキュメント に沿って、まず自分一人のタスクで試してからチームに広げていく。
McKinseyの State of AI 2025 でも、生成AIを業務に組み込んでいる組織は前年比で大幅に増え、エージェント型AIの試験運用も急拡大している。多くの組織がすでに「エージェントをチームに迎える」段階にあり、問題は「使うかどうか」ではなく「どう統合するか」に移っている。
Todoリストが2層化して混乱した私の経験から言えば、「Human LaneとAgent Laneを分ける」というシンプルな設計判断が、その後のワークフロー設計の基点になった。どのパターンを選ぶかは後でいい。まず「人間とエージェントのタスクを混在させない」ところから手をつけてほしい。
コメント