- 人間の入力は要件4回だけ。残りの22アクション（QA監査13と自動修正9）はループが自動で回した。
- 全4フェーズで停止条件（要修正バグ high/mid=0）に到達。同じものをループなしで作った対照群では、同一QAで5件残った。
- コストは、ビルドのみの約73分から、QA・修正込みの約3時間へ増えた。
実験
「AIにコードを書かせる」の次の問いは、人間がどこまで手を引けるかにある。 要件を出したあとの、作る、レビューする、直す、という工程を、人間ではなくループに任せられるか。 それを実際に回して確かめた。
題材は、20機能のブラウザ用ペイントアプリと、そのあとに順に投入する複雑改修3件である。
- 改修A：複数レイヤー（追加/削除/並び替え/表示切替/不透明度/結合）
- 改修B：選択範囲の自由変形（移動、拡縮、回転、プレビューの確定と取消、Undo対応）
- 改修C：アニメーション（フレーム/オニオンスキン/再生/連番PNG書き出し）
人間が出すのは、ベース仕様と改修3件の要件文だけである。
あとはループが回す。
各フェーズで、独立したQAエージェントがソースを精読して bugs.json を出力する。
要修正バグ（high/mid）が残れば、その全リストを自動で整形して修正担当のビルダーへ渡し、再QAにかける。
これを high/mid が0になるまで機械的に繰り返す（1フェーズあたり修正は最大4回）。
ビルダーとQAは別のエージェントで、Labもメモリも分けてある。 ビルダーは、これが比較実験であることを知らない。
使ったプロンプト（ベース＋改修A/B/C＋QA/修正テンプレート）：
▶ 全プロンプトをダウンロード（.txt）
人間はゴール（要件）を出すだけ。ビルド→独立QA→判定→自動修正→再QA を、要修正バグが0になるまでループが自動で回す。
反復QAと設計の一般化
この実験でいちばん興味深かったのは、反復するQAが、局所的な修正をコード全体の不変条件へ引き上げたことだ。
改修B（自由変形）で、独立QAは同じ型の欠陥を手を変え品を変え検出した。 変形セッションの進行中に、セッション外の破壊的な操作（保存、クリア、Undo/Redo、レイヤー結合）が入ると状態が壊れる、という指摘である。
修正ループはやがて個別のパッチをやめ、破壊的な操作の前に必ずセッションを自動確定する一元ガードへ集約した。 改修C（アニメーション）でも同じ構図が再現し、再生中のロックをすべての破壊的な編集経路へ集約する形へ収束した。
QAゲートは欠陥を潰すだけでなく、局所修正を設計上の一般則へ変えうる。 この動きは、ループを何度か回してはじめて見えた。
フェーズごとの手間もそれを裏づける。 状態の競合が多い自由変形とアニメーションでは、より多くのQA・修正ラウンドを要した（改修Cは、3ラウンド続けて mid を1件残したあと0へ落ちた）。
ループなしと比べる
同じ4つの要件文を、同じモデルと同じ設定の別のビルダーに順に渡す。 ただし、QAゲートも修正ループも挟まない（各回セルフサーベイのみ）。ふつうに「AIに作らせる」やり方である。
各フェーズで新たに出た要修正バグを、重複なく数えてみる。 ベースで2件、そのあとは各フェーズ +1件ずつだった。 ループなしはこれを直さないので、最終的に5件すべてが残る。
各フェーズの仕様追加で新たに出た要修正バグ（同じ不具合は初出フェーズで1回だけ計上・重複なし）。ループなしは直さないので累計5件が最終成果物に残る。ループありは各フェーズで即修正し残0。■ high / ■ mid
最終成果物での残存を並べると、次のとおり。
| 条件 | 残った要修正バグ (high/mid) | 稼働時間 |
|---|---|---|
| ループあり | 0 | 約3時間（QA・修正込み） |
| ループなし | 5 | 約73分（ビルドのみ） |
ループなしに残った5件（アニメ再生とUndo/Redoの競合、IMEの二重確定、マルチタッチ描画、自由変形とUndo/Redoの競合、消しゴムの合成モード残留）は、ループありでQAが検出し修正して0にした欠陥と同じ型だった。 直す仕組みがあったかどうかだけが違う。
ただし、操作した変数はループの有無だが、各条件1試行なので、この5件差がすべてループによるものとは断定できない。 今回の1試行での結果は、ループありは high/mid=0、ループなしは5件残った、である。
限界と結論
今回のアプリ、要件、モデル、QA基準、反復上限という条件では、ループは人間の介入なしに停止条件へ到達した。 そのうえで、線を引いておく。
- 「要件だけ」ではない。停止条件（high/mid=0）、severityの基準、修正上限（1フェーズ4回）、エージェント構成は、いずれも人間が事前に設計している。設計すべき対象が「タスク」から「止め方を含むループ」へ移っただけである。
- 同じ独立QAが、検出・停止判定・最終評価を兼ねている。ループが品質そのものではなく、そのQAが納得する状態へ最適化された可能性は排除できない。第三の評価者や実行テスト、E2Eを最終評価に加えると信頼性が上がる。
- 各条件1試行の小さなサンプルであり、生成の実行結果にはばらつきがある。severityの mid と low の切り分けにも主観が残る。
環境：自作のエージェント基盤 aidoc 上で、独立したエージェント2体（builder と QA-auditor、ともに claude-opus-4-8、メモリ非バインド、workspace は独立）を使った。状態はエージェントのメモリではなく workspace のファイルで持ち越す。ループなしの対照群も同一のプラグインセットで別のビルダーを1体立て、同じ4要件を1試行で計測した。総run26、総稼働は約3時間、最終成果物は30ファイル・約4,100行。