先に結果
1 台の Linux PC で、Claude Code の会話を 4 つ（作る係 2・確かめる係 1・研究 1）同時に動かし、その指揮を AI を積まない小さなサーバー（Kernel と呼んでいます） にやらせました。2 日間（10 月 19〜20 日）で、
- 注文は 77 件。うち 54 件が本番に入りました（人の手で 43 件、AI を使わないボットで 11 件）。
- 確かめ係の判定は ○ 51・△ 13・× 11。× 11 のうち 6 は中身ではなく順番だけ（作った物が、その間に進んだ本番の上に載っていない／本番と重ねるとぶつかる）でした。
- 指揮の判断（誰を起こすか、次に何をするか）は全部 Kernel の決まったルールで、AI には選ばせていません。
うまくいったことより、止まったこと・重なったことの方が多く分かりました。
なぜやったか
AI を何体も並べると、だれがまとめ役をするかが問題になります。まとめ役も AI にすると、そのまとめ役が使用量を食い、間違え、止まります。
そこで「司令塔は AI を積まない仕組み、AI は後付けの手」という形を試しました。人（私）が立てた目標と、これまでの記録だけを持つ Kernel が、AI に「今いる場所」と「次の一点」を配ります。
仕組み（AI を使わない部分）
Kernel は Python の小さな HTTP サーバーで、記録は SQLite に追記だけで残します。AI との受け渡しは 2 つです。
-
信号：AI は
DEV_LINEという 1 種類の信号で、注文の段を進めます。段 出せる人 次に起こす人 order（注文） だれでも 確かめ係 exam（作る前の実験と検証） 確かめ係 作る係 take → built（作った） 作る係 確かめ係 verdict（○△×） 確かめ係 入れる係／作る係 deployed（本番に入った） 入れる係・ボット 頼んだ人 「だれがどの段を出せるか」はコードの定数で、信号では変えられません。
-
待ち受け：各会話は
session_wait.pyで Kernel を待ち、自分宛ての知らせが来たら起きます。起きたら読んで、また待ちます。
2 日間で起きたこと（記録から）
1. 作り始めてから「やっぱり実験が先」に変えた
最初は注文が来たらすぐ作っていました。すると作った後の確かめで穴が見つかり、作り直しが続きました。途中から、作る前に確かめ係が実験して「作る／作らない／直して出す」を出す段（exam） を足し、さらに「exam を通らないと取れない」ようにしました。exam は 15 回、うち「作らない」1、「直して出す」1 です。
2. 「今いる場所」を配ったら、配りすぎた
Kernel は各会話に「現在地」（目標・次の一点・今有効な決定）を配ります。最初は中身が少しでも変わるたびに配っていて、ある会話は 0 時から 5 時までに 15 回起こされました。起きるたびに使用量がかかります。「その日まだ配っていない次の一点」か「人の目標が変わった時」だけ配るように直しました。
3. 止まった会話を、AI なしで見つけた
各会話の「最後に動いた時刻」（待ち受けの心拍と最後の信号の新しい方）が 150 分を超えたら、Kernel が画面と私に「止まり」を出します。2 日で 2 回出て、2 回とも本当に止まっていました（どちらも、待ち受けを起こし直し忘れた）。
4. 同じ物を 2 つの会話が作った
まとめ役の会話が「だれも取っていない」と見てから作り始めた間に、もう 1 つの作る係が同じ注文を取っていた、が記録で 1 回ありました。直し方は単純で、先に take（取る）を出し、通ってから作るです。
5. AI 同士の手紙を、Kernel が覚えていなかった
会話同士は直接手紙を送れますが、その中身は Kernel の記録に入っていませんでした。私が一度言ったリポジトリ名を、別の会話が私にもう一度聞いてきて気付きました。手紙を Kernel に取り込み、綴りの揺れ（shota_conect と shota_connect）でも引けるようにしました。最初の取り込みは会話の記録 1.8GB を丸ごと読んで 6GB のメモリを使い、確かめ係に止められ、1 行ずつ読む形（36MB）に直しました。
6. 本番入れを AI から外した
○ が出た品は、systemd のタイマーで 2 分ごとに動くボット（AI なし）が本番に入れます。入れる前に「声の会話中でない」「本番の上で全テストが通る」を見て、入れた後に応答がなければ前の本番に戻します。2 日でボットが入れたのは 11 件で、うち 10 件が 2 日目（10-20）です。
比べた数字（直す前 → 直した後）
| 直したこと | 前 | 後 | 数え方 |
|---|---|---|---|
| 現在地を配る回数（ビジネス研究を含む 5 会話の合計） | 61 回 | 15 回 | 直す前後の同じ 5.5 時間（前は 0〜5 時、後は 5〜11 時。動きの量は同じではない） |
| AI 同士の手紙を取り込む時のメモリ | 6.0GB | 36MB | 本物の会話の記録 1.8GB を 1 回取り込んだ時の最大 |
| 止まった会話を見つける | 人が気付くまで | 150 分で Kernel が出す | 2 日で 2 回、どちらも本物 |
「作る前の実験（exam）」の前後は、品の数が少ないので比べていません。
分かったこと
- AI に任せない部分を増やすほど、止まり方がはっきりする。指揮が AI だと「なぜ止まったか」が会話の中に埋もれますが、決まったルールだと「どの段で、だれの番で止まったか」が記録から出ます。
- 使用量の多くは「運ぶ」ことに使われているのでは（まだ数えている途中の読み）。知らせを配る・起こす・読んだと返す。ここを AI なしの仕組みに移すと、AI は作ることに使えるはずです。
- × の半分以上（11 のうち 6）は中身ではなく順番の問題だった（ほか 2 は順番と中身の両方）。本番が先に進んで載せ直しが要る、同じファイルを 2 つの品が直す。順番だけの × 6 のうち 5 は、ボットが本番と重ねて試すようになった後に出ました。減ったのではなく、見つかるようになった、が正確です。
試していないこと
- 1 か月続けたときの使用量の変化（2 日分しかありません）。
- 確かめ係を 2 体にしたとき、詰まりが減るか（今は確かめ係 1 体が詰まりの元になる時があります）。
- この形が、私以外の人の目標でも同じように動くか。