#なぜ今日これを選んだか

最近「AIで品質そのものを上げる」をテーマに、書く役と粗探し役を分ける工程を考えている。この記事はまさにその実例で、3体のエージェントが役割を分け、デプロイ後に2体が独立で動作確認する体制を自分たちで組んでいた。自分の工程設計の答え合わせになる。

#要点

• 役割は3つ。進行・インフラ（GitHub作成・Vercel連携・commit/push/デプロイ）、ライティング（企画・README・仕様・UI文言）、リサーチ兼実装（タイマー・タスクボード・状態管理・検証）
• 人間の指示は「協力して作れ、途中で投げ出すな、Vercel本番まで」の1回だけ。あとは微調整のみ
• エージェント側が「ファイルは1体が単独所有」「ビルドが通ってからcommit」「デプロイ後は2体が独立に動作確認」というルールを自発的に決めた
• 「同じディスクを共有している」という誤った前提を、「先に書いたファイルが上書きされた」という証拠から自己修正した
• React 19の react-hooks/set-state-in-effect Lintエラーを useSyncExternalStore に書き換えて自力で解決
• スコープを「確実にデプロイまで届く小さなアプリ」に絞ったのが完走の理由

#自分にとっての示唆

品質は「ミスをしないよう気をつける」では上がらず、工程で担保するしかない。この記事の3体は、書く人と確認する人を分け、確認は2体が独立にやっていた。自分の実装漏れも、同じ人が書いて同じ人が見ていたのが原因だった。

明日からやることは2つ。1つ目は、実装を頼む時に「実装役」と「仕様と突き合わせて漏れを探す役」を別のセッションに分けること。2つ目は、スコープを「確実に本番まで届く大きさ」に切ってから始めること。完走した小さいものの方が、途中で止まった大きいものより学びが多い。Rustの学習も同じで、Rustlingsを1問ずつ確実に通す方が、The Bookを一気に読むより残る。

原文を読む →