AIエージェントに仕事を任せるようになって、最初にぶつかったのが「タスク管理をどうするか」でした。
JiraやNotionを繋ごうとして、やめました。理由はシンプルで、AIに使わせるとトークンばかり食う割に、肝心の「今どこまで進んだか」が更新されないからです。最終的にたどり着いたのは、tasks.md / projects.md / handoff.md というMarkdownファイル3枚でした。
この記事は、個人開発でAIエージェントを運用している中で確立した「タスク台帳」の実装パターンをまとめたものです。特別なツールもフレームワークも使いません。テキストファイルだけです。
なぜAIのタスク管理にJira/Notionが向かないのか
人間のためのプロジェクト管理ツールは、AIエージェントにとって相性が良くありません。運用してみて感じた理由は3つです。
- 読むのが高コスト: APIやMCP経由でチケット一覧を取ってくると、JSONのメタデータごと大量のトークンを消費する。本当に欲しいのは「タイトルと状態と一行メモ」だけなのに。
- 書き戻しが雑になる: AIにステータス更新を任せると、API呼び出しが増える割に更新漏れが起きる。人間なら画面を見て気づくが、AIは「更新するのを忘れる」。
- 文脈が分断される: コードとタスクが別システムにあると、AIは両方を行き来しないと状況を把握できない。
LLMのコスト最適化を突き詰めていた時期に、この「何を読ませるか」の設計がコストの9割を決めると痛感しました。あるプロジェクトでは、プロンプトの共通部分をシステム側に集約し、会話履歴を要約する仕組みを入れただけで、**トークン使用量を約60%削減（月5万円→2万円）**できたことがあります。タスク管理も同じで、AIに渡す情報は「薄く・構造化して・同じ場所に」置くのが正解でした。
その条件を全部満たすのが、リポジトリ内のMarkdownファイルでした。AIが直接 Read して Edit できる——これに勝る連携はありません。
台帳の全体像——3枚の役割分担
まず全体像を表にします。「何を、どのファイルで管理するか」を分けるのがポイントです。
| ファイル | 役割 | 更新頻度 | 主な読み手 |
|---|---|---|---|
tasks.md |
個々のタスク（ToDo・状態・担当・一行メモ） | 高（作業のたび） | 実行エージェント |
projects.md |
プロジェクト単位のゴール・進捗・依存関係 | 中（節目ごと） | 計画・判断する側 |
handoff.md |
セッション間の引き継ぎメモ（前回の続き） | セッション終了時 | 次のセッションのAI |
役割を分けている理由は、以前ひとつのエージェントに全部を詰め込んで失敗したからです。一人のAIに全業務を任せるとコンテキストが肥大化し、レスポンスが遅く・的外れになる。そこで役割別にエージェントを分割し、秘書エージェントがルーティングする構成に変えたところ、各エージェントの応答精度が約40%向上、処理速度も平均2倍になりました。
ファイルも同じで、「今日のタスク」と「プロジェクトの全体像」と「引き継ぎ」を1枚に混ぜると、読むたびに関係ない情報まで食わされます。関心事でファイルを割るのが軽量PMの肝です。
tasks.md——1タスク1行の台帳
tasks.md は「AIが今すぐ手を動かす対象」を並べます。1タスク1行、状態を絵文字か記号で先頭に置くと、AIも人間もひと目で分かります。
# タスク台帳
## 進行中
- [T-042] 🔄 ログイン画面のバリデーション実装 @cto
memo: メール形式チェックまで完了。パスワード強度が残り。
- [T-045] 🔄 請求書PDFテンプレの余白調整 @cto
## 未着手
- [T-046] ⬜ APIレスポンスのキャッシュ導入 @cto
depends: T-042
## 完了
- [T-041] ✅ 顧客一覧のページネーション（2026-07-18）
ポイントは memo: 行です。ここに**「どこまで終わったか」を一文で残す**ルールにしておくと、次にそのタスクを開くAIが、コードを読み直す前に文脈を復元できます。
実際、この一行メモが効いた場面がありました。本番で断続的に出る NullPointerException の原因が3日間わからず、tasks.md に「非同期処理が怪しい」とだけ書いて放置していたのですが、後日その一行を手がかりに過去24時間分のエラーログ約5,000行と関連ソース3ファイルをAIに読ませたところ、レースコンディションが原因だと15分で特定できました。台帳の一行が、調査の「入口」になったわけです。
projects.md——ゴールと依存を俯瞰する
tasks.md が「木」なら、projects.md は「森」です。プロジェクトのゴール・現在地・タスクの依存関係を書きます。
# プロジェクト台帳
## PJ-06 顧客管理システムのモダナイズ
- ゴール: レガシー画面をAPI+SPA構成に移行
- 状態: 🔄 実装フェーズ（40%）
- 関連タスク: T-042, T-045, T-046
- 判断待ち: 認証方式（セッション or JWT）→ CEO確認中
- 次アクション: T-046のキャッシュ設計レビュー
判断待ち の欄を設けているのがミソです。AIが自律的に進めていい範囲と、人間の判断が要る範囲を台帳の上で明示的に分ける。外部に影響するアクション（メール送信・本番デプロイなど）は、ドラフト生成→承認キュー→承認→実行の4ステップを挟む運用にしていて、この「判断待ち」欄がそのキューの起点になります。この仕組みを入れてから誤操作はゼロ、承認作業自体は1日5分程度で回っています。
handoff.md——セッションをまたぐ記憶
AIエージェントの弱点は「セッションが切れると文脈を忘れる」ことです。毎回ゼロから説明し直すのは、人間にとってもAIにとっても無駄です。
そこでセッション終了時に handoff.md へ引き継ぎメモを書き出すようにしました。
# 引き継ぎメモ
## 2026-07-19 セッション終了時
- 進行中: T-042（パスワード強度チェックが残り）
- 承認待ち: 請求書メールのドラフト1件（AQ-007）
- 直近の決定: 認証はJWTで確定（CEO承認済み）
- 次の一手: T-046のキャッシュ導入から着手
- 注意: ステージングDBを触った。本番反映はまだ。
構造を固定しておくと、次のセッションのAIはこのファイルだけ読めば数秒で文脈を復元できます。「前回どこまでやったっけ？」のやり取りがゼロになりました。既存コードからAPI仕様書を逆生成させたとき（80本のエンドポイントを2日でドキュメント化）にも痛感しましたが、AIは「今あるテキストを読んで書く」のが本当に得意です。だったら記憶もテキストに外部化するのが素直な解でした。
ハマったこと——台帳が肥大化してトークンを食う
順調に見えて、一度失敗しています。運用を続けるうちに tasks.md が数百行に膨れ、セッション開始のたびに台帳全体を読ませてトークンを浪費するようになりました。完了タスクの履歴まで毎回読み込んでいたのです。
対策はこうです。
-
完了タスクは別ファイル（
tasks-archive.md）へ退避し、tasks.mdには未完了だけを残す - 開始時に読むのは1タスク1行のスリムな索引（
tasks-index.md）だけにして、詳細メモが必要なタスクだけgrepで該当行を引く -
handoff.mdも全文ではなく「最新セクションだけ」読む運用にする
要は、台帳そのものにも情報設計が要るということでした。CLAUDE.md が肥大化したときと同じ教訓で、「AIに何を読ませないか」を決めるのが、実は一番効くチューニングでした。
導入チートシート
最小構成で始めるならこの4ステップです。
- リポジトリのルート付近に
tasks.md/projects.md/handoff.mdを作る（空でOK） - AIへの指示書（CLAUDE.md 等）に「作業開始時は台帳を読む／終了時に handoff を更新する」と一文追加する
- タスクは
[ID] 状態 タイトル @担当+memo:の1行ルールで書く - 台帳が育ってきたら、完了分をアーカイブに逃がし、索引だけ読ませる
この4つだけで、AIエージェントが「自分の仕事の状態」を自律的に管理し始めます。DBもSaaSも要りません。
まとめ
AIエージェントのタスク管理は、AIが直接読み書きできる場所に、薄く構造化して置く——この原則に尽きました。JiraやNotionが悪いのではなく、「AIに使わせる」という一点でMarkdownファイルが圧倒的に扱いやすかった、という話です。
-
tasks.md: 今すぐ動く対象（1タスク1行 + 一行メモ） -
projects.md: ゴールと依存と「判断待ち」 -
handoff.md: セッションをまたぐ記憶
小さく始めて、肥大化したら索引と割る。この繰り返しで十分に回ります。
この記事が参考になったら、いいね・ストック していただけると励みになります。
Claude Code・AIエージェント・業務自動化の実装Tipsを継続的に発信しています。フォロー しておくと新着が届きます。
みなさんはAIエージェントのタスク管理を何で回していますか？ Markdown派・ツール派、ぜひコメントで教えてください。