この記事についてClaude（Anthropic）との共同編集により作成されました。
要約
- 個人開発の「タスク管理どうする問題」を Backlog.md^1 + その MCP サーバ^2 に倒したら、Claude Code との相性がかなり良かった
backlog/tasks/*.mdがそのままタスクの実体になり、Claude が直接読み書きできるので「Claude に渡す材料置き場」と「人間のタスクボード」が一致するbacklog board export --readmeで README のボード部分が自動更新される。公開リポジトリでも進捗が一目で見える- AC（受け入れ条件）を先に書く運用が Claude Code との認識合わせを速くする。tobari の MVP（永遠/深海/幕開けの 3 ページ）はこのフローで 1 日くらいで Cloudflare Pages まで到達した
- tobari 自体の話は前日の紹介記事に書いた。本記事はその裏側の運用記録
前日の記事で tobari という小さな Web アプリを公開した話を書いた。今回はその開発側、個人開発のタスク管理を Claude Code + Backlog.md MCP に倒したらどうだったか の記録。
結論から書くと、Claude Code との相性がかなり良かったので、似たような個人開発の規模感の人には推せる構成。以下、具体的にどう運用したか・何が便利だったか・何で詰まったかをまとめておく。
題材: tobari の MVP は 3 ページのマイクロアプリ
詳細は紹介記事に譲るが、tobari は「視界に帳を下ろす」だけの超軽量 Web アプリ群で、MVP として以下 3 ページを Cloudflare Pages に置いた。
- 永遠の帳（
/towa/）— ずっと暗いだけ - 深海の帳（
/shinkai/）— ダークブルー + 泡 + ゆらぎ - 幕開けの帳（
/makuake/）— 60 分周期でゆっくり明滅
HTML + CSS + Vanilla JS のみ、フレームワークなし、1 ファイル完結。スコープが小さいぶん、開発フロー側のしくみを試す題材としてちょうど良かった。
構成: Claude Code + Backlog.md MCP の役割分担
使ったツールはシンプルに 3 つ。
| ツール | 役割 |
|---|---|
| Claude Code | 実装・レビュー・コミット |
| Backlog.md | タスクをローカル Markdown で永続化（backlog/tasks/*.md） |
| Backlog.md MCP サーバ^2 | Claude Code から Backlog を CLI/MCP 経由で操作する経路 |
Backlog.md は「タスクをローカルの Markdown ファイルとして管理する」コマンドラインツールで、Git でそのまま履歴管理できる。各タスクが backlog/tasks/task-N - <title>.md という 1 ファイルに対応する、ローカル完結の Issue Tracker のような立て付け。
MCP サーバが付属しているので、Claude Code から backlog.create_task backlog.update_task 相当の操作を直接呼べる。Claude が同じ Markdown ファイルを「読む対象」「書く対象」の両方として触れるのがこの構成の肝。
実際の運用フロー
tobari では最初に SPEC.md（仕様メモ）を書いて、それを Claude にざっくり読ませた上で「タスクに割って」と頼んだ。出てきたのが以下。
| ID | タイトル | 状態 |
|---|---|---|
| TASK-1 | 現状のドキュメントを git にコミット&プッシュ | Done |
| TASK-2 | 永遠の帳を実装する | Done |
| TASK-3 | 永遠の帳を Cloudflare Pages へ初回リリース | Done |
| TASK-4 | 深海の帳を実装する | Done |
| TASK-5 | 深海の帳をリリース | Done |
| TASK-6 | 幕開けの帳を実装する | Done |
| TASK-7 | 幕開けの帳をリリース | Done |
「実装」と「リリース」を別タスクに割ったのは結果的に正解で、Cloudflare Pages の初回セットアップ（プロジェクト作成・URL 構成決定・デプロイ手順記録）は実装とはまったく別の作業として独立させたほうが、Claude にも自分にもやることが明確になる。
各タスクの中身は Backlog.md の標準セクションを素直に使った。
- Description — そのタスクで何を達成するか
- Acceptance Criteria（AC） — 受け入れ条件のチェックリスト
- Implementation Plan — 実装方針（Claude が書く）
- Implementation Notes — 実装中・実装後のメモ
- Final Summary — 完了時の要約
このセクション分けが、後述するように Claude Code との相性に効いてくる。
いちばん便利だったのは backlog board export --readme
backlog board export --readme を一発叩くと、README の特定区間（<!-- BOARD_START --> から <!-- BOARD_END --> まで）に現在のタスクボードを Markdown テーブルとして書き込んでくれる。
tobari の README はこれで自動更新される運用にしてあって、git push するたびに最新のボードが GitHub 上で見える（tobari のリポジトリは非公開だが、ここでは形だけ抜粋すると以下のような表が README に並ぶ）。
| To Do | In Progress | Done || --- | --- | --- || **TASK-8** - ブログ掲載記事を公開 | | **TASK-7** - 幕開けの帳をリリース || | | **TASK-6** - 幕開けの帳を実装する || | | **TASK-5** - 深海の帳をリリース || ... |何が嬉しいか。
- README を開けば進捗が見える。別ツール（Notion / Linear / GitHub Issues）を行き来しなくていい
- 公開リポジトリでもそのまま使える。タスクの中身までは見せたくなくても、ボードだけは出すという中間運用ができる
- Claude にも「現状」が常に共有される。Claude Code は CLAUDE.md を必ず読むが、その並びで README も視界に入る
「タスクの実体（Markdown）」と「人間が眺めるボード（README の表）」が同じソースから出ているので、ズレようがない。
これは自分の経験で言うと、Kaggle のときは結局 .md ファイル 1 枚にメモを書き溜めて、それを毎回 Claude Code に読ませる運用にしていた。軽快ではあるが、進捗の俯瞰には弱い。一方で業務だと既存の課題管理 SaaS を使っていて、こちらは進捗の俯瞰は強いが、MCP の口が無くて Claude と結合できないので、課題側の文脈を Claude に渡すたびにコピペが発生する。Backlog.md + MCP は、その間を埋めるちょうどいい位置にある。
AC は会話の中で固める — 流れは「memo → 仕様 → Backlog 登録 → ロードマップ → 課題登録」
運用してみての実感として、Acceptance Criteria（AC）はかなり効く。ただし「実装前に AC を全部書き上げてから Claude に投げる」というよりは、Claude との会話の中で AC が固まっていくのが実際の流れだった。
tobari でやった順番はこう。
- ネタメモ（
my-thinking/配下の.md）にぼんやり構想を書く - それを Claude に読ませて、まず
docs/SPEC.md（仕様）に書き起こす - SPEC の章立てに沿って Backlog.md にタスク登録（
backlog task create ...） - タスク同士の依存関係を
dependencies:で繋いで、軽いロードマップを敷く - 個別タスクの中で Description / AC を書き、開発を開始
この 1→5 の各ステップで Claude と会話するので、AC は「事前に書く」というより「会話の終盤に文字起こしされて Backlog に残る」感じになる。
例として、TASK-2「永遠の帳を実装する」の AC は最終的にこうなった。
- [x] #1 開いた瞬間に暗転する- [x] #2 時間変化なし(常に暗い状態を維持)- [x] #3 UI・ボタン・設定・説明が一切表示されない- [x] #4 HTML/CSS/Vanilla JS のみで実装(フレームワーク不使用)- [x] #5 色は純黒ではなく墨色/深紺ベース5 項目だけ。これらは SPEC 起こしの段階で「UI なし」「フレームワーク不使用」「墨色」と決めた内容が、Backlog 登録の段階で AC のチェックリストとして再構成されたもの。SPEC を経由しているので、Claude が「達成すべき条件」を取り違えない。
AC が ✅ で並ぶと、その時点で「やり切った」が客観的に確認できるのも個人開発ではありがたい。「もうちょっと作り込めるかも」みたいな終わらない衝動を、AC で物理的に切れる。
PLAN / NOTES / FINAL_SUMMARY の使い分け
最初は Description だけで回そうとしていたが、Claude Code の出力を毎回どこかに溜めたくなる場面が出てくる。Backlog.md の標準セクションを愚直に分けたら、これがハマった。
| セクション | 入れたもの |
|---|---|
| Implementation Plan | 着手前の方針。擬似コード・色・式・採択判断など。Claude に「実装に入る前にここを書いて」と指示 |
| Implementation Notes | 実装中・実装後のメモ。詰まった点、ドライランの数値、補足判断など |
| Final Summary | 完了時の要約。後から自分やブログ用に読み返す用 |
具体例として、TASK-6「幕開けの帳を実装する」の Implementation Plan には Claude が考えた台形フェードの擬似コードが残っていて、Implementation Notes には主要時刻でのドライラン結果（t=0/55:00/55:30/56:00/…で明るさが期待値どおりか）が残っている。実機で 55 分待たないと確認できない挙動を、数式評価で詰めたのがこの記事の運用上のヒットだった。
これらは Markdown ファイルにそのまま残るので、後から記事化するときの 1 次資料としても使える（この記事もそう）。
詰まった点・反省点
うまくいった話ばかりだとフェアじゃないので、引っかかった点も書いておく。
AC を後から足したくなる問題
実装途中で「あ、これも条件にしておくべきだった」と気づく瞬間が普通にある。Backlog.md は AC を後から追加できるが、すでに ✅ が付いているチェックリストに後付けで未達項目を混ぜると、ボード上で「Done 寄りなのに未達がある」状態になって少し気持ち悪い。
運用としては、AC を増やすときはタスクを分割するのが結局すっきりした。「永遠の帳に Wake Lock を入れる」は別タスクで切る、みたいな感じ。
Wake Lock の検証は MCP では完結しない
Screen Wake Lock API はブラウザ・OS の挙動依存で、MCP 経由のドライランでは確認しきれない。「タブを裏に回したら自動解放されるか」「戻ってきて再取得されるか」みたいな部分は実機で目視するしかない。AC に「実機で 1 分以上画面オフ抑止が機能することを確認」みたいな項目を入れておくのが正解だった、と振り返ると思う。
Cloudflare Pages 初回セットアップは独立タスクで切るべき
これは引っかかったというより、最初からやって良かった話。TASK-3 で「永遠の帳をリリース」をひとつのタスクに切ったのは正しくて、Pages プロジェクト作成・URL 構成決定（サブドメイン分離 vs 単一プロジェクト + サブパス）・デプロイ手順記録は、実装とは完全に別の頭の使い方になる。
まとめ — 個人開発のタスク管理は「Claude が触れる場所」に置くと早い
今回の構成のいちばんの本質は、タスクの実体（Markdown）と AI への指示書きが同じ場所に置かれていることだと思う。
- 人間がタスクの状況を把握する手段（README のボード）
- Claude が次に何をすべきか判断する材料（
backlog/tasks/*.md） - 完了の客観基準（AC）
これらが全部ローカル Markdown 1 セットに収まっているので、「Claude に渡す」「人間が見る」の間に変換が要らない。Notion や GitHub Issues を間に挟む構成だと、どうしても「AI 用に書き直す」「人間用に書き直す」の二度手間が出るが、それがない。
個人開発の規模（タスク数 10 個前後、1 人で回す、公開・非公開どっちもあり得る）にハマる構成として、ひとまず推せる。
tobari 自体のほうは紹介記事からどうぞ。次の帳を増やすときも同じフローで回す予定。
参考文献
- Backlog.md 公式サイト https://backlog.md/
- Backlog.md MCP ドキュメント https://backlog.md/docs/mcp
- tobariの紹介記事（前日記事） https://yurudeep.com/posts/web/2026/20260515/
- Screen Wake Lock API - MDN https://developer.mozilla.org/en-US/docs/Web/API/Screen_Wake_Lock_API