ここまでの育ち方

このリポジトリは 2026-07-13 に始まり、8週間で 2,887 コミットになりました（2026-09-07 時点）。その間に作り方そのものを何度も変えています——その区切りが下の年表です。

今の仕組みは ParallelAgents.md にあります。 この文書は、そこへどうやって辿り着いたかだけを扱います。

一目で

timeline
    title 作り方の移り変わり
    section 7月
        07-13 issue を Copilot に割り当てる : Unity 2D の骨組み<br/>画面まわりのPRが半日で9本
        07-14 Claude とチャットで詰める : 1本のブランチから43本のPR<br/>宣言の文法がここで形になる
        07-16 試験と CI が入る : EditModeテストが回り始める
        07-25 Unity を捨て Vite + TypeScript へ : GUIを人が触らないと進まない土台をやめる<br/>実装 9.5千行 / 試験 8.6千行
        07-30 絵を自分で出せるようにする : ComfyUI + SDXL<br/>絵 14枚
    section 8月
        08-05 Qwen Image Edit を足す : 既存の絵から派生でき<br/>アートスタイルが揃う
        08-13 文書の書き方を定型化 : 確定と暫定が読み分けられるように<br/>文書 9千行
        08-15 生データを別リポジトリへ : 同じ絵を二度生成しない<br/>絵 131枚
        08-22 サブエージェントで負債を棚卸し : 229ファイル / 宣言 4,178件
        08-23 並列作業へ移行 : 価値観と取り決めを文字にする<br/>issue でタスクを配り始める
        08-25 司令塔が見張る形になる : PRの決着をシェルが出す
        08-28 2つ目のエージェントを同格にする : Copilot CLI にも同じ既定が載る<br/>ただし以後のコミットは1本だけ
        08-29 司令塔の手順を仕組みへ出す : 盤面・投入・マージを3本のスクリプトへ<br/>差分はレビュアーのセッションが読む
        08-30 確定の印を規約と検査にする : 実装 4.7万行 / 試験 4.9万行
        08-30 一次レビューを出す側へ足す : レビューの投入が1本あたり平均2.0回<br/>導出値の写しをやめる
        08-31 使用量の枠が尽きて止まる : 4日間でPRは5本<br/>設計はリポジトリの外で進む
    section 9月
        09-04 盤面の設計を積む場所を作る : 中心は機械的な処理だけに絞ると決める
        09-05 司令塔を廃してデーモンにする : 盤面を回すのがシェルになる<br/>モデルのコストが中心から消える
        09-06 判断の要る仕事を周期の係へ割る : 棚卸し・分析・価値観を畳む係
        09-07 デーモンを起こす係を外に置く : 実装 4.9万行 / 試験 5.9万行

何を減らそうとして変えてきたか

変えてきた動機は、どれも「人間の手数を減らして、同時に流せる量を増やす」ことです。 減らす相手は毎回違いました。

「AIが確かめられない」ことを潰したのも、このうちの1つでした——確かめられないものは人間が 確かめるしかないので、そこがそのまま人間の手数になります。ただし全部がそこから来たわけでは ありません。 上の表のうち、確かめられるかどうかの話なのは Web への一本化（の一部）と、 書き方の定型だけです。

規模の推移

この表と下の図は手で埋めません。 npm run stats:history（scripts/historyStats.mjs）に 区切りの日を渡すと、そのまま出ます。先頭の 07-13 は渡していません——どこで作り方が 変わったかは選ぶものですが、いつ始まったかは履歴の側に在るので、道具が付けます。

npm run stats:issues
npm run stats:history -- --svg docs 2026-07-18 2026-07-25 2026-08-01 2026-08-13 2026-08-23 2026-08-26 2026-08-30 2026-09-04 2026-09-07

issue の列だけはgitに無いので、先に npm run stats:issues （collectIssueHistory.mjs）がGitHubから集めて stats/issues.tsv へ置き、表を作る側はそれを読みます。表を作る側は網へ 出ません——出ると、gh も網も無い環境ではこの列だけが落ちた表が出て、貼り直した先で今ある値を 失います。集め直していない日の行には （持ち越し） が付くので、付いたまま貼らないこと。

測っているのは、その日の最終コミット（日本時間）の状態です。 行数は git grep -c ''。置き場は C#期とTS期をまたぐので、両方を合併した1つの式で数えています。

道具 は、リポジトリの運用を回すプログラム——盤面のデーモン、使用量を集める道具、 セッションのフック、絵を出す道具。本番のプログラムではないので 実装 とは別の列ですが、 書かれた量としては数えます。 拡張子の一覧は historyStats.mjs の TOOL_EXTENSIONS。

どこへ数えるかは、置き場ではなく中身の性質で決めています。 絵のレシピ（tools/**.json）は 置き場が道具と同じでもデータなので 定義 へ、運用の取り決め（agent-ops/ の *.md）は 文書なので 文書 へ入ります。

上の表の範囲に当たらないものは、どの列にも数えません。 agent-ops/ から 文書 へ数えるのは 取り決めとひな形だけで（実行されるものは階層を問わず 道具 へ入ります）、判断の履歴 （agent-ops/decisions/）と分析の書き出し（agent-ops/analysis/）、skill の本文はどの列にも 入りません。文書とは別のもので、 分ける必要が出たときに分類を作ります。.github/** とリポジトリ直下の *.md も入っていません。

PR は main へ入った累計（マージコミットと squash の両方を数え、main へ直接 push した分は 入りません）。1PRあたりと「同じPR」の割合は、1つ上の行からの区間の平均です（先頭の行だけは、 その日1日ぶん）。区間は1つ上の行の翌日から、その行の日までで、日数もこの数え方です——本文で 区間を名指しするときも、1日あたりを出すときも、この範囲で数えます。

右端の列の「文書」は、文書 の列とは範囲が違います——仕様の置き場（docs/・Documents/）だけで、 agent-ops/ の取り決めは入りません。実装と対で書かれるものではないので、対になっているかを見る この割合には数えません。

変更行 は、その区間のPRが動かした行（追加＋削除）の合計で、行数の列の増分（純増）とは 別のものです。書き直しと削除は純増に現れませんが、掛かったコストは同じなので、値段を割る 分母にはこちらを使います。1000 × コスト ÷ 変更行 が括弧の 千行 で、 変更行 ÷ その区間のPR本数（PR の列の、1つ上の行からの増分）が 1PRあたり の行数です。

09-04 で終わる区間（08-31〜09-04）は、ほとんど止まっています（下の「幕間（08-31〜09-03）」）。PRが 25本しか増えていないので、この行の「1本あたり」と「千行あたり」は、他の行より少ない標本の上に 乗っています。

コストは stats/usage/ から引いています（集め方と限界は scripts/usage/README.md）。クラウドのセッションも手元も入った額で、 括弧の中は同じ額をその区間の量で割ったもの（上の 変更行 の説明）。手元の分だけは換算値（ローカルの記録は金額を 持たないので、実測した係数を掛けている。±15%ほどの幅）で、クラウド側は実額です。

過去の時間は、測り直さずに持ち越しています。 手元の記録は古いものから消えるので、一度測った 時間は取り直すと痩せます（実際に、取り直しただけで8月頭の3日ぶんが $285 減りました）。 timeline.py に境目を渡すと、それより前は既にある集計の値を そのまま持ち越します。この表で測り直したのは 08-30 以降です。

最後の行は、その日の最終コミットに追いつきません——測る対象にこの文書自身が入るので、 書いた時点ではまだコミットされていない分だけ小さく出ます。同じ日付で数え直すと、値は少し 増えます。

横軸は実際の日数で取ってあります。 右端が詰まって見えるのは、08-23 以降を細かく測っている ためです。

時点の量と区間の量は、同じ日に置いていません。 行数や累計はその日の状態なので区切りの日に 置きますが、区間を平均した量は区間の真ん中へ置きます——区切りの日に置くと、区間の右端へ 張り付いたまま、区間の長さのぶんだけ点ごとに違うずれ方をします。区切りは「作り方を変えた日」で 決めていて幅が揃っていないので、ずれ方も点ごとに違います。

issue の数とPRの数は、成果ではなく方式の記録

issue が 08-23 の58件から08-30の499件へ跳ねているのは、仕事が9倍になったからではありません。 この日からタスクをissueで配り始めた（第5期）ためで、数はやり方の名残です。多いほうが良い ものではありません。

PRの数も、単独では読めません。 07-25 の週は1本あたり 13.4ファイル・1,020行でしたが、 並列化した直後の区間では、行数が4分の1以下・ファイル数が半分以下まで落ちました（その後の 戻りは下の「表の最後の区間」）。1本がぐっと小さくなっているので、本数が増えたぶんがそのまま 量ではありません。 1つのタスクを1セッションが持つ形にしたことで、PRの粒が「1セッションで 片付く大きさ」に揃ったのがこの列です。

08-23 で終わる区間の山（19.0ファイル・529行）は、負債の棚卸しで見つかった置き場の直しが 1本に固まったぶんです（点は区間の真ん中に在ります）。その次の区間で5.0ファイル・229行まで 落ちるのが、並列化でPRの粒が揃ったところです。

表の最後の区間（09-05〜09-07）では 9.5ファイル・306行へ戻っています。 この区間の139本を、 盤面を作り直すもの（.claude/**・scripts/**・.github/** を触る54本）とそれ以外（85本）で 割ると、10.0ファイル・436行 対 9.2ファイル・224行。 行数は倍近く違うのに、ファイル数はほとんど変わりません。 ファイル数が戻ったのが何によるかは、測れていません。

PR1本あたりの値段は、レビューを出した区間で倍になった

この図だけは、期の区切りを使っていません。 区切りは「作り方を変えた日」で決まっていて 幅が揃わないので、区間の量を区切りごとに出すと区切りを1日動かすだけで値が半分になり、総額の上下は 使ったペースではなく区間の長さを描くことになります。幅を固定した移動窓で、日ごとに出しています （scripts/historyStats.mjs の WINDOW_DAYS）。 表の区間ごとの値とは、割った幅が違うぶん食い違います。 右端の点は、まだ走っているセッションを 含まないぶん下側に出ます。

図の段ごとに割る先が違います（何で割ったかは段の見出しに出ています）。1本あたりは8月の半ば （08-03〜08-19）を $7.9〜$20.1 で動いていましたが、08-27 の $10.9 から 08-31 の $29.2 へ、 4日で3倍近くになっています。レビューを別のセッションへ出したのがこの間（08-29 21:38）です （第6期の「往復1周の値段」）。同じ4日で変更1千行あたりも $45 から $169 へ上がっているので、 PRが大きくなったからではありません。

その後も、レビューを出す前の水準へは戻っていません。 司令塔を廃した後（第7期）は $35 から $20 へ下がってきていますが、8月半ばの $10 前後には届いていません。 1本 $167 の司令塔が丸ごと消えてもここまでで、消えたぶんは下の内訳で別のところへ移っています。

枠が尽きて止まった 09-01〜09-02 が、1日あたりの段にそのまま出ています（$48 → $8）。

ただし1本あたりは、値段と粒度が混ざった数です。 PRの粒はこの期間で動いている（上の 「PRの数も、単独では読めません」）ので、同じ額でも1本が小さければ1本あたりは下がります。 動かした行で割ると別の形が出ます——変更1千行あたりは、08-31 の $169 から $80 前後へ 下がっています。 表の段で見ても、1本あたりが $20.4 から $23.3 へ上がったのは1本が 203行から 306行へ大きくなったからで、動かした行で見た値段（$100.2 → $76.1）はむしろ下がっています。

Copilot は桁が2つ違います。 全期間で $141 に対し、Claude は $17,404（2026-09-07 時点） ——1%を切ります（下の「Copilot に使ったクレジット」）。

試験は、実装が始まった週から実装とほぼ同じ量ある

表で試験が0なのは 07-13 だけです。この日に入っているのはUnityの骨組みと文書で、Tests/ と CIは実装が本格的に増える前の 07-16 に同時に入りました。その次の区切り（07-18）で 4,337行 対 4,300行、そこから追い越すまではどの時点でも試験は実装の3分の2を超えています （追い越した後は下の節）。入った後は跳ねた日がありません——TS移行でも、PR #166 の本文が 「C#実装（Domain/Loader、約4,600行）と NUnit テスト（約7,600行）を TypeScript/Vitest へ 移植した」と述べているとおり、移行は量の断絶ではなく置き換えです。

だから「試験が増えたことが並列化の前提になった」とは言えません。 試験は並列化の5週間前から CIで回っていて、1人のエージェントに書かせるときにも同じだけ要ります（この点は後述）。

8月末に試験が実装を追い越したのは、相手が実装の外へ出たことと、コードを試す分が厚くなったこと

08-26 と 08-30 のあいだで、試験の行数が実装を追い越します。 実装も止まってはいません——1日 あたり 948行（〜08-13）・1,159行（〜08-23）・1,187行（〜08-30）と、少しずつ速くなって います。同じ区間で試験は 600行/日 → 1,046行/日 → 2,834行/日。 伸びの差はここで開きました。

この節で「〜08-30」のように呼ぶ区間は、下の内訳表の列の刻みです——上の表の 09-04 の行は 挟みません（それ以外は上の表と同じ刻みです）。

試験を何を相手にしているかで割ると、こう伸びています。この内訳は手で測ったもので、 npm run stats:history からは出ません（測ったのは 2026-09-07。上の表の最後の行と同じ地点）。

割り方は置き場です——同梱の中身を試す置き場はリポジトリ自身が名前を持っており （tests/architecture/testKinds.test.ts の BUNDLED_CONTENT）、盤面の道具は tests/scripts/、文書は tests/docs/、残り全部がコードです。 過去の列は、その時点の置き場の名前で割ってあります——置き場は改名されるので、今の BUNDLED_CONTENT を過去のリビジョンへ当てても同じ数にはなりません。

各列の合計は、上の表の 試験 と一致します。

追い越しの区間（〜08-30）で増えた試験 15,257行の行き先を、それまでの厚み（実装1行に 0.49行）を基準にして割るとこうなります。

• 実装の外を相手にする分が 9,854行（65%） — 同梱の中身 6,932・盤面の道具 2,453・文書 469。
• コードを試す分のうち、従来の厚みで説明できる分が 2,740行（18%）。
• コードを試す分が厚くなった分が 2,663行（17%）。

3分の2は、実装 の列が数えない相手のものです。 実装 は src/**.ts しか数えないので、 世界の中身をYAMLで書けば 定義 の列へ、運用を回す道具を書けば 道具 の列へ入ります。 一方で 試験 の列は tests/** を全部数えるので、相手がどこにあっても1つの数へ乗ります。 この区間で同梱の定義は 1.6倍・盤面の道具は 2.7倍に伸びており（実装は 1.1倍）、増えた定義1行には 試験が1.7行、道具1行には試験が0.9行付いています（分母は上の表の相手ごとの範囲で、列そのものでは ありません）。実装 だけを見ていると、この伸びはどこにも出てきません。

残る3分の1は、コードを試す分が厚くなったぶんです。 実装1行あたりの試験は、区間ごとに 0.49行（〜08-23）→ 0.79行（〜08-26）→ 0.97行（〜08-30）→ 1.47行（〜09-07）。厚くなった 理由は測れていません。 同じ時期に起きたのは、実装を足したPR1本あたりの実装が 216行（〜08-23） → 96行（〜08-26）→ 81行（〜08-30）→ 74行（〜09-07） へ小さくなったことと、08-28 に CLAUDE.md へ「再現手順を最初にテストへ落とす」が入ったことです（この数だけは 実装 の列と同じ範囲への追加行を、それを足したPRの本数で割ったもの。刻みと測った地点は上と同じ）。

何にいくら掛かっているか

上の表が時系列の合計なら、こちらは何に使ったかの内訳です。 出どころは stats/usage/by_agent_kind.tsv（2026-09-05〜09-07——種別は セッションのタグで決まるので、タグが揃った範囲だけです）。司令塔を廃した後の内訳になります。

この表の読みどころ。

• 司令塔の行が消えました。 盤面を回しているのはシェル（デーモン）なので、中心にモデルの コストがありません。
• 消えた分は、人間の側のセッションへ移りました。 bridge が 26% で、1本 $41.90 は タスクの2.4倍です。判断と相談が、専用の長いセッションから人間との対話そのものへ移ったのが この行です。
• レビューは安く、タスクは高くなりました。 レビュー1本 $2.52、タスク1本 $17.12。 タスクの側では、PRを出す前の一次レビュー（サブエージェント）が1本あたり1.4回立っており （134回 / 96本）、1回 $0.96（cost_sub_usd が $127.98）です。

金額は各セッションの実額で、按分しているのは主エージェントとサブエージェントの内訳だけです （scripts/usage/README.md「数字の限界」）。デーモンを起こす係はこの表にも、上の時系列にも出ません ——Routine で立ったセッションはセッションの一覧に載らず、集計はその一覧から作っているためです。 抜けているのは 09-07 01:56 から 09-11 までの毎時1本ぶん（係をこのPCのタスクへ移して、 セッションが立たなくなるまで）なので、額としては小さく収まります。

司令塔が居た頃の内訳（2026-08-25〜08-31）

比べる相手として、当時の測定をそのまま残します。 イベントの生データはこのPCに残っておらず、 落とし直したのは 08-30 以降だけなので、司令塔期の内訳はもう測り直せません。

司令塔はたった7本で20%でした。1本 $167.43 はタスクの14倍で、1本が長く走り続ける ためです。この重さが、第7期で中心からモデルを外した理由です。

Copilot に使ったクレジット

Copilot の分は GitHub の使用レポートから（stats/usage/copilot_by_day.tsv。 下の表はその写しで、$ は割引前の額＝使った量の値段です）。クレジットが動いた日だけを並べます ——動かなかった日のほうが、圧倒的に多いです。

Copilot の合計は $141（14,110クレジット）。Claude は全期間で $17,404（2026-09-07 時点） なので、Copilot はその1%を切ります。枠に収まった分は請求されないので、実際に払ったのは $0.48 だけでした。

動いた日は、Copilot のコミットが入った日とほぼ一致します（copilot-swe-agent[bot] 名義で 07-13 に31本・07-14 に22本・07-18 に2本・07-20 に10本・07-21 に67本・08-04 に3本・08-07 に4本）。

第1期（07-13〜07-21）issue を Copilot に割り当てる

始まりは Unity 2D の Android アプリでした。C# のスクリプトと Assets/ の骨組みがあり、.github/copilot-instructions.md が初日に置かれています。

やり方: issue を書いて Copilot に割り当て、上がってきたPRを見る。1つの issue に1本のブランチが立ち、1本のPRで終わります。

この形の重さは、初日の画面まわりにそのまま出ています。 07-13 だけで画面まわりのPRが9本上がりました。

壊す → 直す → 作り直す → 捨てるが半日で1周しています。直すたびに issue を書き直すのは人間なので、この1周は丸ごと人間の手数でした。

割り当ては 07-21 まで続いています（copilot/ から main へ入ったPRは 07-13 に12本・07-14 に5本・07-18 に1本・07-20 に5本・07-21 に24本）。C#領域のカプセル化、containers.yaml の整理、CIの整備まで幅広く任せています。画面だけを任せていたわけではありません。

枠は2回尽きていて、どちらの日も使用レポートに出ている

Copilot は枠を2回使い切っています（上の「Copilot に使ったクレジット」で、枠を超えた課金が 立っている日）。

• 1回目は初日の 07-13。 使用レポートでは、この日から月の枠が 1,500 から 7,000 へ変わって います。上位プランへ変えたのもこの日です——当事者の証言では「1か月分を4時間ほどで 使い切った」。
• 2回目は 07-21。 ここから 08-01 のリセットまで枠は残っておらず、07-25 のわずかな分は割引が 1円も掛からず全額課金されています。

2回目が、PRの空白と一致します。 copilot/ からのPRが途切れた区間を並べます。

長いほうが枠切れです。 短いほうは枠が残っている時期なので、割り当てなかっただけです。

戻ってからは 08-04 のYAML修正1本と 08-07 のCI修正2本だけで、実装の割り当て先としてはここで 終わります。 08-28 に Copilot CLI として戻るまで（第6期）、書いていたのは Claude だけです。

注: この期の判断のうち、モックの壊れ方に手を焼いたことは当事者の証言です。枠切れと上位プランへの変更は使用レポートに出ています（リポジトリからは読めません）。リポジトリから読めるのはPRの本数・題・時刻・空白の長さ・クローズされた事実までで、上の表はその範囲で裏付けが取れたものだけを並べています。

第2期（07-14〜）Claude とチャットで文法を詰める

07-14 22:53、claude/japanese-instruction-6nfcpe という1本のブランチが立ち、07-20 22:38 までに そこから43本のPRが main へ入りました。 1つのブランチにPRを積み続ける形は、1つのチャットが 続いていることの跡です。

ここで宣言の文法が形になりました。 順に、効果システムの設計 → 世界記述YAML仕様書 → effects を対象キーの辞書型へ → modify を self/parent/child で共通化 → accumulate・ passive/active・on_zero の導入 → YAML定義ドキュメントを文法リファレンスへ、と積み上がっています。

issue を書いて渡す形との違いは、往復の細かさです。 issue では1往復が「issue を書く → PRを見る」になり、言い直しのたびに文章を書き直すのは人間でした。チャットでは訂正がその場で 返せて、自分だけでは決められないところを相談しながら決められます。 文法のように「どちらでも 動くが、後で全部に効く」判断が続く仕事では、ここが効きました。

第1期と第2期は重なっています。 07-14 から 07-21 までの8日間は、Copilot への割り当てと チャットが並走していました。片方へ乗り換えた日はありません。

第3期（07-25〜）Unity を捨て、Web へ一本化する

07-25 に Vite + TypeScript + Vitest の足場が入り（2e7fad80）、同じ日に Unity プロジェクトを 丸ごと削除しました（3455c3d2）。 src/domain も同じ日に生まれています。

理由は、Unity が GUI 操作を前提にしていることです。 シーンやプレハブの組み立て、実行、 確認が Unity エディタの中にあり、エージェントに渡せるのはコードだけでした。残りは全部 人間の手に残るので、どれだけ書かせても、そこで詰まります。

移行先を選ぶときには、画面表示を確かめられるかを調べています。 ただしそれは選定の条件で あって、移行そのものの理由ではありません。結果として、次の2つが同時に手に入りました。

• 画面を実ブラウザで撮れるようになりました（run skill が移行の直後 07-25 に project skill として入ります）。壊れたことがその場で分かります。
• 試験と画面が、同じ実行環境に載りました。 領域の試験は 07-16 からCIに載っていましたが、画面はその外で、HTMLモックを見張るものは何もありませんでした。移行で試験の量は増えていません（上の表）——増えたのは試験が届く範囲です。

移植にはサブエージェントを並べています。 メインのエージェントが規約を書き、それをサブへ 徹底させる形です。PR #166 の本文が、 「TypeScriptコーディング規約を Documents/Engine/CodingConventions.md に新設（複数エージェント での並行移植でもスタイルが揃うよう、機械的検査で担保できない規約のみを明文化）」と書いています。 1本のPRで247ファイル・18,573行の追加と17,273行の削除が入りました。

「規約を先に書いて、書く相手を増やす」形は、ここが最初です。 後の並列作業（第5期）で .claude/parallel-work.md がやっていることと、狙いは同じです。

幕間（07-30〜08-15）絵を自動で作れるようにする

期の区切りとは別に、ここが通っていないと全部が止まります。 物を1つ足すたびに絵が要るので、 絵だけ人手だと、コンテンツの追加がそこで詰まります。

絵の枚数: 07-31 に14枚 → 08-15 に131枚 → 08-30 に178枚（src/assets/** の画像。docs/ui の画面写真は数えていません）。

なぜ「生データを別リポジトリへ」が効いたか

生データは1枚1.2MB前後で、207枚・244MBあります（UnmappedIsland-art-raw・08-30）。本体へ入れると clone が重くなり、セッションを 立てるたびにその重さを払うことになります。本体に入っているのは後処理を通した178枚・39MBです。

分けたことで、build.py は生成の前に置き場へ訊き、同じ入力の絵が既にあれば ComfyUI へ投げません。 Qwen Image Edit は1枚90秒〜15分かかるので、後処理を1行直すたびにそれを払うかどうかの差になります。

選び方の軸

• Flux を捨てたのはライセンス（非商用）。絵が綺麗かどうかでは選んでいません。
• Qwen を足したのは、SDXL では出せない被写体があったから。 skill には「SDXLが持っていない被写体は、 何枚振っても出ない」と実例つきで書いてあります——振り直しで解決しないものを、振り直しで解決しようと しないための記録です。
• 生データを分けたのは、確かめ直す速さのため。

第4期（08-13〜）書き方を定型にする

08-13 に DocumentStyle.md が入り、見出し・節番号・概要の定型・実装状況と確定度の表記が決まりました。

変えた理由: 文書が9千行に達し、どれが決まったことで、どれが検討中なのかが読み分けられなくなったためです。ドキュメント先行で書いた設計は、実装済みの節と未実装の節が同じ断定調で並びます。

読み分けられないと、エージェントは毎回訊きに来ます。 ここで入った 【確定】 の印が、後に 人間の判断を集める仕組み（確定待ちの issue）の土台になります——「覆すには人間の判断が要る」と 宣言できる場所が、先に必要でした。

幕間（08-22〜08-23）積み上がった負債を棚卸しする

これは作り方の変更ではなく、それまでに積み上がった技術的負債の整理です。 40日で実装が 3.7万行まで伸び、宣言がどこに置かれているか・何という名前かが、書いた順の都合で決まった ままになっていました。

08-22、src 配下の宣言を全部棚卸ししました（review/2026-08-22-placement/）。対象は 229ファイル / 約37,200行 / 宣言 4,178件。1件ずつ「そこに居るのが適切か」を5段階で判定しています。翌 08-23 には名前だけを見る調査（review/2026-08-23-naming/）も独立の観点として立ちました。

やり方: 1つのセッションが複数のサブエージェントへ領域を割り、結果を1箇所へ集める。読むだけの作業なので衝突しません。 第3期の移植と同じ形を、調べる側で使っています。

負債の整理として始めたものが、副産物を残しました。

• 領域を6つに割ると、1タスクの編集がだいたい1領域に収まる（この実測が、当時の所有権の地図になりました。この地図は後に捨てています——ファイルの衝突にしか効かず、主題で並ぶ文書には軸が合いませんでした）。
• 名前の妥当性は、他の観点の補足に混ぜると拾われない（27件が実際にそうなりました）。だから独立の観点として立て直しています。

1つ目が、翌日の担当の割り方にそのまま使われました。 ただしそのために調べたのではありません—— 数え終わって初めて、割り方が実測で出ていることに気づいた順です。

第5期（08-23〜）並列作業へ移行する

08-23、価値観と取り決めを文字にしました。

ここで issue の役割が変わりました。 それまでの issue は「Copilot へ渡す仕事」で、始まってから 1か月（08-13 まで）で51件しかありません。タスクを配る器にしてからの1週間（08-24〜08-30）で、 400件以上増えています（上の表）。

08-25 に見張り（watch-prs.sh）が入り、司令塔がシェルで待つ形になりました。 それまでは各セッションに自分のPRを見張らせていましたが、見張りは自分を起こす道具を要求し、それらは自動承認できないので、そのまま人間のタップになっていました。

この日1日で、同じ形の穴が5つ見つかっています——どれも「気づけない」形をしていました。塞いだ結果は ParallelAgents.md の10節にあります。

第6期（08-28〜）司令塔の手順を仕組みへ出す

並列で流せるようになった後、残った人間の手数は司令塔の側にありました。 見張りが決着を出しても、 振り分け・マージ・後片付け・レビューは人が順に叩くままだったからです。

この期の変更には、確かめられるかどうかの話が1つもありません。 減らしているのは、 決着したものを人が読んで次へ渡す手数だけです。

ただし、2つ目のエージェントは数に入っていません。 同格にした前日（08-27）に Copilot は8月の枠を 使い切っており、08-28 以降に Copilot 名義で入ったコミットは1本だけです。この期に書いているのは、 実質 Claude だけになります。

司令塔は「全部は読まない」つもりで、全部読んでいた

08-29 に気づいたのは、司令塔が上がってきたPRを結局すべて読んでいたことです。 読まない建前でしたが、 通してよいかを決めるには中身を見るしかありません。 読んだ分だけ司令塔の文脈が埋まり、後の判断が 痩せます。

そこでレビューを別のセッションへ出しました（08-29 21:38）。司令塔が受け取るのは「通してよい」か 「直しが要る」かの1行だけになります。仕組みは ParallelAgents.md 6節にあります。

差し戻しは想定より多く、往復はすべて司令塔を通った

（08-29 21:38〜08-31 00:08。レビューのセッションは1回の投入につき1本立ち、使い回しません。）

この往復が、そのまま司令塔の手数になります。 差し戻しは司令塔が受け取って元のセッションを起こし、 直ったらまたレビューを立てる——1周ごとに司令塔を2回通ります。 負荷を下げるために出した仕組みが、 往復の回数だけ負荷を戻していました。

立てたセッションの2/3がレビューになった

08-29 は、立てたセッションの数と入ったPRの本数がほぼ1対1です（65対66）。08-30 は、立てた数が 入った本数の約4倍（392対104）。増えた319本のうち254本がレビューです。

この増え方は、時間あたりの本数には出ません（08-29 11:03 に契約を最上位プランへ変えており、 同時に流せる本数が増えているため）。見るべきは1本あたりの値段です。

往復1周の値段は、タスク1本の3割

差し戻しが1周増えるたびに、レビューのセッションが1本立ちます（$3.51。上の「司令塔が居た頃の 内訳」）。タスク1本が $11.68 なので、往復が3周でタスク1本ぶんの値段になります。

上の277本のうち、141本が2周目以降です（136本のPRに277本）。レビューに掛かった $971.95 の、 おおよそ半分が差し戻しの往復にあたります。

この $3.51 に、司令塔の側の手数は入っていません。 差し戻しは司令塔が受け取り、直す側を起こし、 もう一度レビューを立てる——1周ごとに司令塔を2回通ります（司令塔は1本 $167.43 と、タスクの14倍）。 往復1周の本当の値段は、$3.51 より大きくなります。

1本を main へ入れるまでの値段は、2日で2.7倍になりました。

レビュアーを出したのは 08-29 21:38 なので、丸一日が入っているのは 08-30 だけです。1日ずつなので 他の変更も混ざります——プランを変えて同時に流せる本数が増えたこと（08-29 11:03）、一次レビューが 08-30 18:25 から入ったこと。

だからレビューは外さず、手前へもう1回足した

11回の往復は、レビュアーが厳しすぎたのではなく、PRにそれだけ抜けがあったということです。 それまでは 同じ点検が司令塔任せで、素通ししていた分がここで表に出ました。 品質の側では効いているので、 レビューを外すのではなく、往復のコストを手前で削ります。

08-30、PRを出す側が、出す前にサブエージェントへ同じ観点で読ませる形にしました （#1358）。観点の一覧 .claude/review-criteria.md は1つで、出す側とレビュアーが同じものを 読みます——外で見つかるものを、外へ出す前に1回通すためです。

この一次レビューの値段は、1回 $1.0（当時の内訳で、task の cost_sub_usd が60回で $60.47。 タスク1本の8%）。外のレビュー1周（$3.51）の3割です。

下は 2026-09-07 に測り直した値です（PRは最初のレビューが立った時刻で列へ振り分け、 そのPRに立ったレビューを全部数えています。第7期の列は、司令塔が居なくなった後の同じ測り方）。 第7期の列が期の始まり（09-04）ではなく 09-05 から始まるのは、司令塔が消えたのが翌日だからです ——09-04 に入ったのは作り直す設計で、盤面はまだ司令塔が回していました。

「後」の列は、当時 1.21回・16% と出ていました。 予告どおり低く出る側に偏っていたもので、 その後に立った2周目を数え入れると 1.68回・37% になります。それでも「前」の 2.37回からは 落ちており、時間を置いた第7期でも 1.46回のままです。一次レビューで削れた往復は、戻って いません。

導出値の写しが、コンフリクトを生んだ

自動で回り始めた結果、コンフリクトが大量に出ました。 レビュー待ちのPRが増えて同時に開いている 本数が伸びたことも効いていますが、当たっている場所は文書です。

同じ導出値・同じ一覧が、文書のあちこちへ書き写されていました。 レビュアーがその更新漏れを指摘する ようになった結果、同じ数値を各PRが上書きし合います。 AIは判断の根拠を残したがるので——数えた件数、 対象キーの一覧、相互参照——散らばっている分だけ、別々のタスクが同じ行で当たります。

08-30、導出値は文書に書かない側へ倒しました。 数え上げは唯一の一覧を指す形へ直し（この日 main へ 入っただけで14本）、stats/ から書き写した数値には出どころの印を付け、下位桁が主張に効いていないなら 粗さ（±）を書けるようにしています（docs/diagnostics/README.md）—— 厳密一致のままだと、定義を触るPRが結論に効かない桁まで書き直す義務を負い、同じ行でぶつかります。

コンフリクトの解決は、レビューの往復とも噛み合いました。 リベースのたびに差分が変わるのでレビューを 1周やり直すことになり、08-30 には例外を1つ置いていました——直前の周で「通してよい」が出ていて、その後の 差分がリベースの解決だけなら、一次レビューだけでマージしてよい、というものです。

09-07、この例外は取り下げました。 過去のPRで測ると、機械では解けずに人が解いていた解決はどちらも 解き方以外を動かしており——生成物の数値が動いたもの、両側の書き換えがどちらの版にも無い文へ畳まれた もの——「外が読んだ中身とマージする中身が同じ」という前提が成り立っていませんでした。 コンフリクトを解いた周も、外のレビューを1本立てます。

幕間（08-31〜09-03）枠が尽きて止まる

この4日間に main へ入ったPRは5本だけで、09-01 と 09-02 は1本も入っていません。 Claude の使用量の枠を使い切って動けなくなったためです。

この間、設計の側は止まっていません。 次の期の方針は、リポジトリの外で別のAIと詰めていました （当事者の証言。リポジトリから読めるのはコミットの空白だけです）。だから 09-04 は、 設計が既に一揃いある状態から始まります——.claude/board-design.md は立った当日のうちに、 「状態の持ち方」「機械ループの実行基盤」「使用量による自動の手綱」まで積まれています。

上の表で 09-04 で終わる区間（08-31〜09-04）だけ「1本あたり」が上に出ているのは、この空白です。 額そのものは $727 と前後の区間よりずっと小さいのですが、分母のPRが25本しかないので1本あたりでは高く出ます。

第7期（09-04〜）盤面を回す中心から、モデルを外す

第6期の終わりに残っていたのは、司令塔そのものでした。 手順はスクリプトへ畳んであるのに、 それを叩く順を決めるのは1本の長いセッションで、差し戻しの往復は1周ごとにそこを2回通ります。 1本 $167.43 はタスクの14倍（上の「司令塔が居た頃の内訳」）で、引き継ぎ・文脈・可用性が 全部そこへ集まっていました。

09-04 23:28、盤面を作り直す設計の置き場ができます（.claude/board-design.md）。向かう先は 「中心は機械的な処理だけに絞る。判断が要るものは非同期の別エージェントへ切り離す」。

この期が減らしたのは、司令塔を立て直して現在地を引き継がせる手数です。 仕組みは ParallelAgents.md にあります。

中心を外した分は、消えずに人間の側へ移った

内訳から司令塔の行が消えました（上の「何にいくら掛かっているか」）。デーモンはシェルなので、 中心にモデルのコストがありません。

それでも1本あたりの値段は下がっていません。 09-05〜09-07 は区間で $23.3 （末日は測った時点でまだ走っているセッションがあるので、下側の値）。司令塔が居た 08-27〜08-30 の $20.4 より高い水準です。移った先は bridge——このPCで人間が開いた セッションが全体の26%、1本 $41.90 です。判断と相談は、専用の長いセッションから、人間との 対話そのものへ移りました。

これは中心を外したことの帳消しではありません。 司令塔は居ないと盤面が止まる1本でしたが、 bridge は人間が話したいときにだけ立つので、単一障害点ではありません。 値段が同じでも、 落ちたときに何が止まるかが違います。

判断が要らないものだけを、中心に残す

中心が賢くなるほど、そこは引き継ぎ・文脈・可用性の単一障害点になります。 だから board-move.mjs は盤面を受けて手の並びを返すだけで、 GitHub も CCR も触りません。

判断が要るものは、全部そこから出してあります。

周期で起きる係が使ったのは $30.27（全体の1%）です。係を足す値段が安いことが、判断を中心から 出し続けられる条件になっています。

段はどう積み上がったか

並列作業は、それ以前の段が作ったもの全部の上に立っています。 ただし、すべての段が一列に 並んでいるわけではありません——書き方の定型（第4期）は、Webへ一本化したこと（第3期）とは 独立に、文書が積み上がったことから来ています。

flowchart LR
    A["Webへ一本化<br/>（第3期）"] -->|"絵を出して確かめられる"| E["絵の自動化<br/>（幕間）"]
    C["負債の棚卸し<br/>（幕間）"] -->|"領域の割り方が実測で出た"| D["並列作業<br/>（第5期）"]
    A -->|"画面も確かめられる"| D
    B["書き方の定型<br/>（第4期）"] -->|"判断を集める場所がある"| D
    E -->|"物を足すのに人手が要らない"| D
    D -->|"人が読む場所が司令塔へ寄る"| F["手順を仕組みへ<br/>（第6期）"]
    F -->|"叩く順を決める1本が残る"| G["中心からモデルを外す<br/>（第7期）"]

• 人間がGUIを操作しないと進まないなら、何本流しても人間の速さで進みます。 第3期はこれを外しました。
• 絵が人手のままなら、並列にしても詰まります。 物を1つ足すたびに絵が要るので、そこだけ人間を通すと、何本流しても待ち行列が1本に戻ります。
• 確定と暫定が読み分けられなければ、判断を集められません。 どれが訊くべきことかが決まりません。
• 領域の割り方が分からなければ、担当を配れません。 6分割は思いつきではなく、229ファイルを数えた結果です。ただし、そのために数えたのではありません——負債の棚卸しの副産物です。
• 並列にして初めて、司令塔の手数が全体の上限になりました。 第6期はそこを削っています。
• 手順を畳んでも、叩く順を決める1本は残ります。 第7期はそこからモデルを外しました。畳んでおいた からこそ外せたので、この2つは順に並びます。

1人でも要るものと、並列で初めて要るもの

上の図が言っているのは順番だけで、「前の段は並列のために在った」という意味ではありません。

試験・画面を確かめる道・絵の自動化は、エージェントに書かせる時点で要ります——1人でも同じです。 試験に至っては並列化の5週間前（07-16）から回っており、並列化が試験を始めさせたのでは ありません（量は動いています——実装1行あたりの試験は並列化のあとで厚くなり、盤面の道具を 試す分は並列化そのものが生みました。上の「8月末に試験が実装を追い越したのは、相手が実装の外へ 出たことと、コードを試す分が厚くなったこと」）。

並列で初めて要ったのは、ParallelAgents.md 1節が挙げているものです。 試験がここに関わるとすれば量ではなく、壊れたときの届く先のほうです。1人なら次の一手で気づく ものが、同時に走っていると、気づく前に他の作業がその上へ積まれます。だから並列で足したのは試験そのものではなく、人を通さずに必ず走る こと（CIの許可リストを外し、どのファイルを触っても検査が全部走る）と、揃わない所を検査に 変えること（同 10節）です。

変えなかったもの

作り方は変わりましたが、変えていない軸があります。

• 書く前に仕様を書く。 Claude Code が最初に書いたのは 07-14 22:47 の「効果システム設計ドキュメント」で、次が「世界記述YAML仕様書」（07-15 00:11）です。今も仕様書が実装の拠り所です。
• 人間は決めるだけ。 Copilot に割り当てていた頃から、書くのは機械で、決めるのは人間という分担は変わっていません。変わったのは決めさせ方の手数だけです——issue を書いて割り当てる形から、チェックを1つ付ける形まで下がりました。

「文書が先」はウォーターフォールではない

先に書くのは、その機能の仕様だけです。 書いたらすぐ実装へ移り、次の機能でまた書きます。 全部の設計を終えてから実装に入ったことはありません。

表の右端の列がそれです。文書と実装（試験を含む）を1本のPRの中で触った割合は、07-25 までが 3〜4割、それ以降は3〜7割で、リポジトリを作った日を除けば0になりません。 設計を全部 終えてから実装へ移る形なら、文書だけの期と実装だけの期に分かれるので、この列は両端でほぼ0に なり、混ざる区間が生まれません。

0%なのは 07-13 の1日だけです。この日は12本すべてが Copilot で、Unityの骨組み・コンセプト 文書・画面のモックがそれぞれ別のPRになっています。まだ実装と対にできる仕様が無い日で、 段階が分かれていたのとは違います。

割合が上がるのは 08-01 で終わる区間からで、Unity 期とWeb期の境目に当たります。 リポジトリを作った日を除けば、どの区間でも3割は混ざっているので、段階が分かれていた時期が あるわけではありません。

第2期の43本のPRが、この形の最初の実例です。「効果システムの設計」の次が「modify 効果を self/parent/child で共通化」、「レシピシステムの設計」の次がその実装、という並びになっています。