■ 1. 背景と課題
- 著者はLayerX Ai Workforce事業部でAIエージェント向けデータ基盤を開発しており、複数プロジェクトの並走管理に課題を抱えていた
- 過去5年間Markdownベースのライトなタスク管理を運用してきたが、以下の問題が顕在化した:
- 期限のないタスクが後回しになる
- dailyノートからプロジェクト側への情報の書き戻し漏れが発生する
- 忙しい時期はdailyノート自体が作成されない
- 真実が二重化し、実態とのズレが拡大する
■ 2. LLM全面導入の失敗と教訓
- LLMにタスク管理を完全に任せる試みを実施したが失敗した
- 失敗原因:
- 判断に必要な文脈をwikiに書き切れていなかった
- エージェントの提案の信頼度が低下し、人間側も全体把握が困難になった
- 得られた教訓:
- 教訓1: 構造化には維持コストがかかり、属性更新・親子整合・ビュー再生成をすべて人間がメンテナンスするのは現実的でない
- 教訓2: LLMに丸投げすると判断と把握を失い、システムが崩壊する
■ 3. 新しい設計原則: 判断は人間、更新はエージェント、計算はスクリプト
- 3つの責務分担により、保守コストを機械側に分担しながら判断権は人間に残す設計を実現した
- ファイル構造:
- tasks/配下に_タスク.md（アウトラインの木）、タスクビュー.base（Obsidian Basesの属性ビュー）、ガントチャート.md・依存関係図.md（派生ビュー）、_scripts/（決定論スクリプト）、items/
/<タスク名>.md（1タスク=1ファイル）を配置する - 2つの原則:
- 1タスク=1ファイル:
- タスク属性（status・期間・優先度・依存）をfrontmatterに記載し、これを唯一の真実とする
- frontmatterにはtitle、project、status（todo/in_progress/done）、end（期限）、priority、estimate、depends_on（依存タスクのリンク）を記載する
- ビューはすべて派生:
- アウトライン、ガントチャート、依存関係図、Basesのテーブルはすべてタスクファイルから機械的に再生成し、手では編集しない
■ 4. NotionやJiraではなくMarkdownを選択した理由
- 最大の理由: エージェントを働かせる場所として、ローカルテキストファイルが圧倒的にやりやすい
- 具体的な利点:
- 全タスク対象の集計がPython数行で実装可能
- ファイル書き込みにhookが直接反応する
- SaaSのAPI認証・rate limit・pagination・スキーマ変換が不要
- Plain textはコーディングエージェントのホームグラウンドである
- Git履歴・diff・rollbackが無料で付属する
- 一括リネームがワンライナーで実行可能
- 知識ノートと同じvaultに置くとリンク接続できる
- チーム共有はNotionの方が向いているため、手元はローカル、共有用はNotionという役割分担を実施する
■ 5. 責務分担の詳細設計
- 状態更新はサブエージェントに一本化:
- タスクファイルを書き換える経路を「task-manager」という専用サブエージェント一本に限定する
- 定義は約240行の詳細仕様であり、10個の不変条件を守りながら原子的に実行する
- 不変条件の例:
- ファイル名=title
- frontmatterスキーマの厳守
- statusの遷移規則遵守
- 木とファイルの整合性保持
- ファイル作成と木のリンク追加を同一操作で実行
- closeはファイル削除と木からのリンク削除を同時実行
- 判断はさせない:
- 優先度の決定、完了条件充足の判断、closeの是非はすべて人間が決定する
- エージェントは自然言語指示を具体的なファイル操作に翻訳するのみとし、指示が曖昧な場合は確認事項として差し戻す
- 経路を一本化する理由: 複数経路があると命名規約や木とファイルの整合が必ず破れる
- 計算処理はスクリプトへ移譲:
- 親タスク期日の子の最遅日への自動引き上げ、見積もりの子タスク合計への自動集計、ガントチャート生成、依存関係図生成、属性ビューの再生成を決定論的なPythonスクリプトに寄せる
- 理由:
- 精度: 計算と整合チェックは決定論コードの方が信頼性が高い
- コスト: 全タスクファイルをLLMに読ませて集計するよりPythonスクリプトが圧倒的に安価
- 保証: 「計算は決定論の方が確実で安い」はモデル進化によっても変わらない構造的真実である
- 実行タイミングの自動化:
- 当初はサブエージェントがスクリプト実行を担当していたが、実行忘れのリスクがあった
- Claude CodeのPostToolUse hookでタスクファイル書き込みを検知し、スクリプトが自動実行される仕組みに変更した
- ビューの再生成をエージェントの善意に頼らず、サブエージェントのpromptから実行手順記述を削除できた
- 公式ガイダンスとの一致:
- Claude Code Best Practicesの「指示は助言、毎回確実に起きてほしいことはhookに」と同形である
- Agent Skillsのガイダンスの「決定論が必要な処理はコードに任せる」とも一致する
- LLM周りの仕組みには2種類がある:
- モデル能力不足補完型: モデル進化で不要になるため、作り込むほど負債化する
- 精度・コスト保証型: 構造的真実は不変であり、安心して作り込める
■ 6. チームへの見せ方
- 方針: 個人の細かい分解をチームには見せず、Notion側にはproject単位でopt-inで同期し、マイルストーン相当の粗いタスクのみ掲載する
- 除外の仕組み:
- 除外したいサブツリーの根にフラグを立てるのみで、除外集合は木の構造から機械的に算出される
- 除外の意思はfrontmatterで一度だけ表明すれば波及は自動計算され、後から子タスクを追加しても自動的に除外側に入る
- 安全規則:
- 自分がownerのタスクだけローカルをSSoTとしてNotionへ書き戻す
- 他メンバー主導タスクは読み取り専用として扱う
- closeしたタスクはNotion側で削除ではなくDone状態で保持し、週次報告素材はNotion側の履歴から拾える
■ 7. 日々の運用方法
- 4つのモードで回転し、すべてtask-managerサブエージェント経路に統一する
- モード1 バックログ操作:
- タスク追加、変更、close
- モード2 計画:
- 週次計画、朝の計画、日報
- 朝の計画はコマンド一発で下書きが出力され、数分の微調整で完了する
- モード3 タスク消化ループ:
- 「次のタスクやって」という指示で日中を回し、エージェントが依存と優先度を踏まえた次の一手を提示する
- 自分がメンバーとして手を動かし、エージェントがマネージャー的に次の一手を差し出す構図である
- ただし提案された一手をやるか、優先入れ替え、closeの判断は毎回人間が決定する
- モード4 日次メンテ:
- 棚卸し、整合確認
■ 8. 3週間運用後の振り返り
- 運用実績:
- 運用期間23日、タスク数100件（closed 49 / todo 47 / in_progress 4）、プロジェクト数9本
- 過去2方式との比較:
- 第1期（Markdownライト運用、5年継続）:
- 破綻原因は書き戻し漏れとビューのズレ
- 現在は書き換え経路一本化とhookによる自動再生成で「仕組み上起こり得ない」設計とした
- 第2期（LLM全面導入、失敗）:
- 破綻原因は文脈不足の判断
- 現在は判断を人間に残すことで「発生しない」設計とした
- 破綻の原因を意思ではなく仕組みの側で潰せたため、継続の見込みに根拠がある
■ 9. 本業との連動と結論
- 個人タスク管理で使った考え方が、業務でエージェント基盤を設計する際の判断と同じであると気づいた
- 共通原則:
- 仕事はいちばん信頼できる実行者に降ろす
- LLMにやらせないことを先に決める
- 破綻は意思ではなく仕組みで防ぐ
- 個人タスク管理はこの原則を毎日試せる小さな実験場になっている
- 結論:
- タスク管理ツールの乗り換え問題はツール選択ではなく、責務分担から設計する必要がある
- 「判断は人間、更新はエージェント、計算はスクリプト」であり、人間に残っているのが判断だけだから続けられる