Claude Code と多エージェントで6日間でプロダクトを作った開発体制の話

Tsumu は、着手から6日間で「認証・15カテゴリの記録・画像アップロード・横断検索・エクスポート・コミュニティ・セキュリティ強化」まで実装し、本番公開に到達しました。AI に丸投げしたら速かった、という話ではありません。速度の源泉は体制の方だったので、その中身を書きます。

ハーネス: 4つの品質ゲート

開発は Claude Code を中心にした多エージェント体制ですが、どんな変更も4つのゲートを通さないと本番に出せないルール(社内標準「ハーネス v3」)で回しています。

1. build クリーン: 型エラー・lint エラー0
2. diff 査読: 実装した本人とは別の独立エージェントが、既知の落とし穴チェックリストと照合して GO / NO-GO を出す
3. 実機スモーク: デプロイ直後に Playwright で主要導線を実機確認。コンソールエラー0が通過条件。通過するまで次の実装に着手しない
4. 決定ログの即時記録: 「あとでまとめて」を禁止。判断はその場で残す

査読は Claude と Codex の2モデル相互チェックも併用しています。同じモデルだけで書いて同じモデルだけでレビューすると、盲点まで共有してしまうからです。

経営会議方式: 作る前に反対させる

実装に入る前に、収益化・デザイン・情報設計・マーケ・セキュリティ(レッドチーム)の5つの観点で、それぞれ別のエージェントに監査レポートを書かせました。多レンズで並列に監査し、重要な指摘には別のエージェントが反証を試み、最後に議長役が統合して優先順位を付ける——小さな経営会議のような流れです。「一元化アプリは過去に何度も失敗している」という耳の痛い指摘も、この段階で正面から出てきます。

人間が裁定するのは、製品名・課金・実費・後戻りできない公開といった少数の意思決定だけ。それ以外は体制の内部で決めて、決定と根拠を報告する形にしています。

失敗もあった

順風満帆ではなく、本番障害も1件起こしました。画像処理ライブラリ sharp の Linux バイナリがデプロイに含まれず、API が 500 を返した件です。実機スモークのゲートで即検知し、依存設定の修正で解消しました。「デプロイ直後に必ず実機で叩く」というルールに救われた形です。

6日間という数字よりも、1ループ=本番に出せる検証済みの1改善という単位を守り続けたことが、この開発の本体だったと思います。