設計と実装とレビューを、
同じ人格にやらせない。

心当たりがあるなら

SYMPTOMS

• 認証まわりを頼んだのに、ついでにエラーハンドリングの共通化まで入っている
• 差分が 40 ファイルあり、全部読む気力が湧かないので雰囲気で承認する
• 3 日後、なぜこの実装になっているのか自分でも説明できない
• 並列で走らせたいが、競合が怖くて結局 1 本ずつ回している
• 作らせた画面が、毎回どこかで見た形になる

これは能力の問題ではありません。1 つの人格に、設計も実装もレビューも マージもやらせているからです。自分で決めた設計を自分で実装し、自分でレビューして 自分でマージする。人間のチームなら、この構成は誰も許可しません。

やることは、権限を落とすこと

PERMISSIONS

5 つの人格は、どれも同じモデルです。賢さに差はありません。 違うのは何をしてよいかだけです。

AI は与えられた文脈の中で、もっともらしい次の手を選びます。 「ログイン機能を作って」なら、関係しそうなことを全部やるのがもっともらしい。 「src/auth/** の中だけを変更して、この 3 つの受け入れ条件を満たせ」なら、 もっともらしい次の手はまったく別のものになります。

流れ

FLOW

依頼 → [Architect] Issue に分割（scope が重ならない組を作る）
         │
         ├─ [Coder] issue/12-xxx ─┐
         ├─ [Coder] issue/13-yyy ─┤ 並列
         └─ [Coder] issue/14-zzz ─┘
                                   │ PR ごとに1件ずつ
                                   ▼
                            [Reviewer] 受け入れ条件と scope を確認 → マージ
                                   │
                                   └─ コンフリクト → [Conflict Resolver] → Reviewer

実装は並列、マージは直列。 3 つ同時にマージすると、それぞれ単体では 正しくても組み合わせで壊れたときに切り分けができません。結局 3 つとも調べ直すことになり、 直列より遅くなります。

この構成で作ったもの

EVIDENCE

説明より、動いた記録のほうが確かめやすいはずです。この 4 人格構成だけで 小さな CLI を 1 本作り、その過程をすべて公開しています。

mdlinkcheck — Markdown の相対リンク切れを検出する CLI。テスト 87 件、CI 2 本が通っています。

• Issue — 各 Issue に担当範囲・依存・受け入れ条件が、コードより先に書かれている
• Pull request — 各 PR が 1 つの Issue に対応し、宣言した範囲に収まっている
• 並列の記録 — 3 つの Issue が別々の作業ツリーで同時に実装され、マージは 1 件ずつ

履歴は後から整形していません。うまくいかなかった記録も残しています。 担当範囲の記述が実態と違っていた件、土台の不足で実装者が止まって報告した件、 そして作ったツール自身が README のリンク切れ 17 件を検出した件。 差し戻しが 1 件も無い履歴は、レビューが機能していない証拠にしかなりません。

履歴を見る

2 つの構成

PACKAGES

内容はどの区分も同じです。違うのは使える人数と、社内で配れるかどうかだけです。 上位への変更は差額で行えます。条項は同梱の LICENSE.txt にあります。

Quartet を GitHub で見る Quintet を購入（準備中）

UI が毎回同じ形になる理由

WHY YOUR SCREENS LOOK GENERATED

全画面中央揃えのヒーロー。アイコン付き 3 カラムの等幅カード。紫のグラデーション。 純黒の文字に純白の背景。見た瞬間に分かりますし、分かると信用されません。

原因は、Coder に造形を判断させていることです。色も書体も余白も指定されていない状態で 判断を求められたら、学習データの中でもっとも頻度の高い形が出ます。 AI の美的センスの問題ではなく、入力の欠落の問題です。

Quintet は、実装より先に UI Designer が仕様書を書きます。構造 → トークン → 状態 → モーション → コピー の順に確定させ、Coder は仕様書を唯一の入力として実装します。 書かれていない造形が必要になったら、実装を止めて差し戻します。

向かないとき

WHEN NOT TO USE THIS

これはオーバーヘッドです。1 タスクあたりの手数は確実に増えます。

• 探索・プロトタイプ（受け入れ条件を書けない段階）
• 1 ファイルで完結する変更（タイポ修正に PR を通す意味はない）
• 依存が本質的に一直線の作業（分割しても並列にならない）
• 30 分で終わる作業

限界もあります。Reviewer は Coder と同じモデルなので、モデルが体系的に 持っている誤りは見抜けません。あるライブラリの API を一貫して間違えて覚えていれば、 Coder が間違え、Reviewer も正しいと判定します。対処は、受け入れ条件に実行可能な検証を 入れることです。