Claude Code のマルチエージェント環境でタスク管理 Web アプリを作ってみた 〜要件定義から実装までの実況中継〜

はじめに

前回の記事 では、macOS 上に Claude Code のマルチエージェント開発環境(tmux + Claude Code + 設定ファイル 2 つ)を構築するところまでをまとめました。

今回はその続編として、構築した環境を実際に使って 小規模なタスク管理 Web アプリ を作っていきます。

進め方は以下の通り。

  • 4 人体制(マネージャー / フロントエンド / バックエンド / QA)
  • フェーズ 1: planモードで 要件定義
  • フェーズ 2: acceptEdits モードで 実装
  • 題材: シングルユーザー・ローカル動作のタスク管理アプリ(技術スタックはエージェントに提案させる)

「マルチエージェントで実際にどこまで作れるのか」を確かめるのが今回のテーマです。事前に細かい指示は出さず、議論で要件を補完してもらう前提で進めました。

体制と進め方

要件定義と実装の 2 フェーズに分け、それぞれで Claude Code のモードを切り替えました。

フェーズモード役割
要件定義plan議論と計画立案のみ。コードもファイルも作らせない
実装acceptEditsファイル作成・編集を自動承認しながら実装を進める

モード切り替えは Claude Code の入力欄で Shift + Tab を押すだけです。

フェーズ 1: 要件定義

投入したプロンプト

要件はあえて最低限だけ書き、議論で補完させる方針で投げました。

今回、マルチエージェント機能を使って小規模なタスク管理 Web アプリの開発を進めたい。
4人体制で要件定義フェーズを進めて欲しく、必ず split panes で分割して進めて。

体制:
- 1人はマネージャー: 指示出し・差し戻し判断・最終取りまとめを担当
- 3人はエンジニア:
  - フロントエンド: UI/UX、操作感、画面構成、視覚要素を担当
  - バックエンド(データ層): データ構造・localStorage設計・状態管理を担当
  - QA: 整合性チェック、エッジケース、考慮漏れの指摘、議論の取りまとめ役

進行ルール:
1. マネージャーは下記の要件を確認し、エンジニア側に「考慮漏れ・追加機能・矛盾」を3人で議論するよう伝える
2. QAは議論をまとめ、報告前に他2人から追加情報がないかを必ず確認する
3. エンジニア側は意見がまとまったらマネージャーに報告
4. マネージャーは報告内容に考慮漏れや矛盾が無いか考え、必要なら差し戻して再議論を指示する
5. マネージャーが最終確認できたら、要件定義の最終版をこちらに報告する
6. このフェーズではプログラムは絶対に作成しないこと(plan モードなので)

要件(最低限。これを叩き台に、議論で必要な要素を補完してほしい):
- シングルユーザー、ローカル動作のタスク管理 Web アプリ
- データはブラウザに保存(localStorage 等)
- タスクの追加・編集・削除ができる
- タスクには「未着手」「進行中」「完了」のステータスがある
- ステータスごとに表示を分ける(カンバン形式想定)
- モダンなブラウザで動作する単一ページアプリ
- 技術スタックは未指定。エンジニア側で議論して提案してほしい

(他にも、「最終的に技術スタック・機能要件・非機能要件・スコープ外項目を整理して報告」する旨を末尾に書いています)

プロンプト送信後、画面が 5 ペイン(メイン + 4 メンバー)に分割され、エージェント同士の議論が始まりました。

議論のリアル

しばらく見ていると、プロンプトで指示した以上のことが起きていました。

  • 当初の最低限要件には書いていない論点を QA がエッジケース観点で次々に提示
  • フロントエンドが「アクセシビリティを守るならドラッグ&ドロップにキーボード代替が必須」と発言
  • バックエンドが localStorage の容量制限を懸念し、IndexedDB に切り替える提案 を提出
  • 3 者の合意ドラフトに対して、フロントエンドとバックエンドからそれぞれ 3 点ずつの修正指摘 が入ってループ

QA の取りまとめ → マネージャーへの報告 → 内容チェック → 必要なら差し戻し、というプロセスがそれなりに機能していて、画面右に流れる発言を眺めているだけでも面白い体験でした。

完成した要件定義書

合計 約 1 時間 20 分 の議論を経て、REQUIREMENTS.md として 153 行の要件定義書が出力されました。当初の最低限要件と比較すると、相当に膨らんでいます。

主な内容:

  • 採用技術スタック: TypeScript + React 18 + Vite + Zustand + Tailwind CSS + Radix UI + @dnd-kit + React Hook Form + Zod
  • 永続化: タスクは IndexedDB(idb-keyval)、設定は localStorage
  • ID 設計: UUID v7、並び順は fractional-indexing
  • アーキテクチャ: UI / State / Domain / Persistence の 4 層構成、Repository パターンで差し替え可能
  • 受け入れ基準 AC-1〜AC-10: QA がエッジケース観点で 10 個の検証シナリオを定義
  • アクセシビリティ: WCAG 2.1 AA 準拠、@axe-core/playwright を CI で検査
  • テスト: Vitest + React Testing Library + Playwright
  • 想定実装フェーズ計画: Phase 0(セットアップ)〜 Phase 10(ハードニング)を提案

これは「シングルユーザー・ローカル動作のタスク管理アプリ」に対する仕様としてはちょっと過剰すぎるくらいの本格仕様で、個人の小規模プロジェクトというより業務系アプリの企画書に近いものになりました。

良くも悪くも、議論を任せると 想定以上に深掘りされる のがマルチエージェントの特徴のようです。

中間判断: 実装スコープを絞る

要件定義書を読んでから少し悩みました。Phase 0〜10 を全部実装させると数時間〜半日コースになりそうです。

そこで、実装は Phase 0〜4 までの MVP コアに絞る ことにしました。

Phase内容スコープ
0セットアップ(Vite + TS + Tailwind + Lint + テスト基盤)実装
1ドメイン基盤(Zod スキーマ、Repository interface、InMemory 実装)実装
2永続化基盤(IndexedDB Repository、hydration、quarantine、マイグレ基盤)実装
3状態管理 + 基本 UI(Zustand、CRUD、リストビュー、フォーム)実装
4カンバン + D&D(@dnd-kit、3 カラム、キーボード代替)実装
5 以降検索/フィルタ、ゴミ箱、Undo、PWA、i18n、最適化 ほかスコープ外

要件は本格的に立てて、実装スコープは別で切る という運用は、マルチエージェントとも相性が良さそうです。要件定義の議論で出てきた検討事項は将来資産として残しつつ、今すぐ作る範囲だけ動かせばいいので。

フェーズ 2: 実装

投入したプロンプト

スコープを絞った前提で、実装フェーズのプロンプトを投げました。

実装フェーズに入ります。先ほど作成した REQUIREMENTS.md を読んで、その仕様に従って実装を進めてください。
4人体制で進めて、必ず split panes で分割して進めて。

(中略)

実装スコープ(MVPコア):
今回は REQUIREMENTS.md の Phase 0〜4 のみ実装してください。
- Phase 0: セットアップ(Vite + TS + Tailwind + ESLint/Prettier + Vitest + Playwright + jsx-a11y)
- Phase 1: ドメイン基盤(Zod スキーマ、純粋関数、Repository interface、InMemory 実装、ユニットテスト)
- Phase 2: 永続化基盤(IndexedDB Repository、SettingsStore、hydration、quarantine、マイグレ基盤)
- Phase 3: 状態管理 + 基本 UI(Zustand、CRUD、リストビュー、フォーム RHF+Zod)
- Phase 4: カンバン + D&D(@dnd-kit、3カラム、order=fractional-indexing、キーボード代替)

完了条件:
- npm run dev で起動できる
- ブラウザでタスクの追加・編集・削除・ステータス変更ができる
- カンバンビュー上で D&D で並び替え・状態変更ができる
- データがブラウザのリロード後も保持される
- ユニットテスト(Vitest)が通る

それでは進めてください。

進行ルールには「各 Phase 完了時に QA がチェック」「全 Phase 完了後に IMPLEMENTATION_REPORT.md を保存」も含めています。

並列実装の様子

実装が始まると、各エージェントがそれぞれ動き始めました。

  • マネージャーが REQUIREMENTS.md を読んで Phase ごとに作業を割り振り
  • バックエンドが Phase 1(Zod スキーマ、ドメイン純粋関数、Repository interface、InMemory 実装)から先に着手
  • フロントエンドは Phase 0(プロジェクト初期化、ビルド/Lint/テスト基盤)を担当
  • QA は仕様の把握とテスト観点の整理を並行で進める

しばらくして、マネージャーから残作業見積もりの表が左ペインに上がってきました。担当別に「Phase 2 完了 20〜40 分」「Zustand 結合 15〜30 分」「D&D 仕上げ 10〜20 分」のように粒度感まで出ていて、自走している感がよく出ていました。

トラブル

順調に進んでいるかと思いきや、途中で 一部エンジニアが応答停止 する場面もありました。具体的には、フロントエンドが Phase 0 のコマンド実行に着手したまま idle 状態が続き、その後にバックエンドも応答が鈍る瞬間がありました。

これに対して、こちらから「進捗を教えて」と一度介入したところ、マネージャーが状況を把握 → 別の frontend-eng-2 を新規追加して作業を引き継ぎ → さらに自分自身で代行実装にも入る という形で進行を立て直してくれました。

人員追加と代行までマネージャーの判断で動くというのは少し驚きで、こうした自己修復的な挙動はマルチエージェントの面白いところです。とはいえ、ハマり始めた時点で人間側からの一声があった方が確実なのも事実なので、放置しすぎは禁物だと感じました。

完成

最終的に、約 4 時間 で MVP コアが完成しました。

完成したアプリがこちらです。

  • Task Manager という見出しの下に「カンバン」「リスト」のビュー切替
  • 右上に「+ 新規タスク」ボタン
  • 3 カラム(未着手 / 進行中 / 完了)、各カラムにタスク件数バッジ
  • タスクカードにはタイトル、ステータスバッジ(▶ 進行中 / ✓ 完了 など)、ステータス変更プルダウン、編集 / 削除リンク、左端に D&D ハンドル(:: アイコン)
  • 各カラム下部に「+ タスクを追加…」のクイック追加入力欄

要件定義で議論された通りに、ドラッグ&ドロップだけでなく プルダウンによるステータス変更 も併設されていて、キーボードユーザーや D&D が使いにくい状況でも操作できるようになっています。

実装結果のサマリー

マネージャーから提出された IMPLEMENTATION_REPORT.md には、以下のような検証結果が記録されていました。

項目結果
ユニットテスト(Vitest)87 / 87 passed
ビルドgreen、bundle 340KB / gzip 107KB(目標 200KB クリア)
Linterrors 0
D&D 並び替え + 状態変更キーボード代替 + ARIA アナウンス込みで実装
リロード後の保持IndexedDB 経由で保持確認済み
AC-5 (quarantine)テスト済み
AC-6 (migration)テスト済み
AC-10 (InMemory フォールバック)テスト済み

要件定義時に QA が定義した受け入れ基準のうち、MVP 範囲のものはきちんと検証されていて、報告書としての体裁も整っていました。

振り返り

今回の取り組みで感じたことを整理します。

良かった点

  • 議論で要件が深まる。最低限要件 7 項目を投げただけで、技術スタック選定・受け入れ基準 10 個・実装フェーズ計画 11 段階まで自動で出てきた
  • 品質が高い。ユニットテスト 87 / 87 グリーン、バンドルサイズも目標達成、a11y 配慮込み
  • 自己修復が効く。応答停止のような不測事態でも、マネージャーが人員追加や代行で進行を立て直す
  • 役割分担が機能する。QA がエッジケースを掘る、フロントが UX を主張する、バックエンドが永続化を設計する、というように観点が分かれて深掘りされる
  • 要件定義と実装でモードを切り替えられる。plan で議論、acceptEdits で実装、と段階を分ける運用が綺麗にハマった

苦戦した点

  • 時間がかかる。MVP コアでも合計約 5 時間半(要件定義 1.5 時間 + 実装 4 時間)。今回は深夜作業になった
  • 要件が膨らみすぎる。「シングルユーザー・ローカル動作」のシンプルなアプリのはずが、PWA / 複数タブ同期 / マイグレーション / i18n 構造まで議論された。スコープを別途絞る判断は必要
  • トラブル時には介入が必要。完全放置だとハマったまま動かないこともある。「進捗を教えて」と一声かけるだけで復旧するので、定期的な様子見は必要
  • 見守る側の体力。並列で動くペインを追うのは楽しい反面、長丁場になると疲れる

向いている用途・向かない用途

向いていると感じたのは:

  • 要件が曖昧で、議論で詰めたい段階のタスク(企画やプロトタイプ初期)
  • 複数の観点(UX / データ / QA など)で深掘りが必要なタスク
  • 「動くもの」を一定品質で出したいケース(テスト・Lint・a11y まで含めて)

逆に向いていないかもと感じたのは:

  • 要件が明確で、コードの一部だけ書きたいタスク(オーバーキル)
  • 短時間で結果が欲しいタスク(数分で済ませたい場合は単体 Claude Code の方が速い)
  • 使い捨ての検証スクリプト(役割分担のオーバーヘッドが見合わない)

まとめ

シングルユーザー・ローカル動作のタスク管理アプリを、Claude Code のマルチエージェント機能だけで作ることができました。

特に印象的だったのは、「最低限の要件 + 役割分担」 だけを与えると、複数視点で勝手に深掘りされる という点でした。一人で作ると「とりあえず localStorage で実装」で終わりそうなところを、議論の中で IndexedDB への切り替えやキーボード代替の必須化まで自動で拾われるのは、想像以上の体験です。

時間はかかるので業務でホットなタスクには不向きですが、企画段階のプロトタイプや「ちゃんと作りたい個人プロジェクト」では強い味方になりそうです。

スポンサーリンク

コメント

タイトルとURLをコピーしました