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派・ツール派、ぜひコメントで教えてください。

関連記事