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

心当たりがあるなら

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。テスト 139 件、CI 2 本が通っています。

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

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

そのあと、同じ構成で 4 本

1 本目で終わりにすると「たまたま」と区別が付きません。同じ人格構成のまま、 用途の違う CLI をあと 4 本作って MIT で公開しています。どれも依存ゼロです。

ツール	何を見るか	テスト
ccheck	.claude/ の設定。書けているのに効いていないものを、 公式ドキュメントの出典つきで指摘	74
scopecheck	開いている Issue のうち、同時に走らせられない組	全通過
sharedfiles	git の履歴から、並列作業がぶつかる場所。宣言も設定も要らない	全通過
transdrift	翻訳が原文から取り残されていないか。公開準備中	43

ccheck は、公式が「エラーになる」「スキップされる」「無視される」と 明記しているものだけをルールにしています。 正しい設定を「壊れている」と言う検査は、無いほうがマシだからです。 何を検査しないと決めたかも公開しています。

指摘の根拠にしている表そのものも読めます — 正しく書いたのに何も起きない設定の全一覧 （hook イベント 33 種、設定キー 223 個のうち 71 個、権限ルール 5 通りなど）。

mdlinkcheck の履歴 リファレンス

2 つの構成

PACKAGES

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

Quartet を GitHub で見る 実践ガイドを読む（¥1,500） Quintet を購入

読み物だけでよければ、3冊セットがあります（¥3,500）。 実践ガイドに加えて、初期費用ゼロで記事と製品を出す仕組みの本と、 小さなツールを作って公開するまでの本。EPUB と、印刷用スタイル付きの HTML と Markdown。 読み物3冊セット
1冊目の内容は Quintet に同梱されています。 キットを買うなら、こちらは2冊目と3冊目のために買うことになります。

実践ガイド 11 章は Zenn Book でも単体で読めます（2 章まで無料）。 Quintet にはこのガイドの全文が含まれるので、一式を買う場合に本を別途買う必要はありません。

「Quintet を購入」は個人版（¥4,980）に繋がります。 チーム版と企業版は BOOTH に商品として並べていないので、 ショップのフッターにある「ショップへのお問い合わせ」、 またはライセンスの問い合わせから、 区分と人数を書いて送ってください。購入用のページを用意します。 請求書が必要な場合はその旨も書いてください。BOOTH では発行できないため、別の方法を相談します。 pixiv のアカウントを作らずに問い合わせたい場合は後者を使ってください（公開の Issue になります）。

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 も正しいと判定します。対処は、受け入れ条件に実行可能な検証を 入れることです。