ある朝、届いていた報告を読んで少し驚いた。ここ2日ほど投げておいた作業が、気づけば独立してレビュー済みの変更として7本たまっていたからだ。中には自社のメタバース本体の機能まわりの大きな変更と、裏側の監視の最適化が混ざっていた。
この2日で何が起きたのか、そしてなぜそれが安心して任せられるものだったのかを書いておきたい。
この2日で何が起きたか
体制はシンプルだ。全体の方向を判断する司令塔役、実際に手を動かす実装役、そして出てきたものを審査する役。この3種類のAIが分業して動く。
司令塔は自分では作業をしない。判断して、割り振って、上がってきたものを統合するだけだ。実装役が変更を書き、審査役がそれを別の目で確認する。この2日は、それが同時並行で7本分走っていた形になる。
必要だったのは、ゼロから読み込んで判断することではなく、「もう審査は済んでいます、重大な指摘だけ確認してください」という状態からのスタートだった。
仕組みの核心は「生成と評価の分離」
この仕組みの一番大事な部分は、実はシンプルだ。書いたAIと、審査するAIを必ず分ける。
自分で書いたものを自分で採点すると、どうしても甘くなる。これは人間でもAIでも変わらない。だから審査は必ず別の担当に回す。
流れはこうだ。
1. 実装役が変更を書く 2. 審査役が別の目で確認し、指摘を洗い出す 3. 指摘のうち、様式や好みの違いのようなノイズは自動で除外する 4. 残った重大な指摘だけを人間の判断にかける 5. 実装役が修正する 6. 再び審査役がチェックする 7. これを繰り返し、改善が止まったところで自動的にループを終える
人間が毎回すべてに目を通すのではなく、「これは判断が要る」というものだけが手元に届く。この絞り込みがあるから、2日で7本という規模でも破綻しない。
この2日で捕まえた5つの見落とし
審査のループが実際に何を拾ったのか、具体的なところを紹介したい。どれも「動くには動く」が、放置すれば後で困る類の見落としだった。
1. 際限なく増え続ける設計の見落とし 新しく作った監視データは、当初「記録される種類の数は有限」という前提で設計されていた。ところが審査で、「対象の中に、今後も増え続ける種類のもの」が含まれていることが分かった。このままでは、部屋や項目が増えるたびに記録量がじわじわ膨らみ続けてしまう。実装前に、増え続ける対象を監視の集計から外す設計に直された。実装する前に気づけたのが大きい。
2. 「8.6秒固まった」という数字の訂正 以前の調査で「読み込み中に8.6秒固まった」という重い数字が出ていた。今回、その元データを実測ベースで洗い直したところ、実は2つの別々の出来事が混ざっていたと分かった。一つはタブを裏に回している間の記録漏れ、もう一つが本当の読み込み停止で、実際の長さは約2.0〜2.4秒だった。原因の仕組み自体は正しかったが、目標とすべき規模の数字は下方修正された。数字を鵜呑みにせず、実データまで戻って検証したからこそ見つかった訂正だ。
3. 見た目はOFFでも、裏から動いてしまう抜け穴 部屋ごとに機能をON/OFFできる仕組みを作った際、最初の実装は画面上の見た目と操作をOFFにするところまでだった。ところが、直接命令を送る経路までは塞がれておらず、裏側から直接呼び出せば動いてしまう抜け穴が残っていた。これは追加の実装で、命令を受け取る側でも強制的にチェックする形に直された。「体験としてOFFにしている」と「本当にOFFにしている」は別物だという、地味だが大事な違いだった。
4. 保持期間14日 vs 読み手は30日分を見ている、という矛盾 新しく作った記録の保持期間を14日に設定していたが、審査でその記録を実際に使っている唯一の仕組みが「直近30日分」を前提に動いていることが指摘された。14日しか残っていなければ、その仕組みは本来必要な期間の半分も見られない。保持期間は30日に直された。
5. 保存方式が壊れていないことの論理的な証明 管理画面の保存を「初期設定との差分だけを送る」軽量な方式に変えた際、受け取る側のAPIは「まるごと置き換える」仕様のままだった。組み合わせて情報が欠けないか、動かして確かめる代わりに、審査役が理屈のうえで「差分保存でも情報が失われない」ことを証明した。実際に壊れるかどうかを試す前に、壊れ得ないことを確認できるのは、テストだけに頼らない審査の強みだと思う。
「壊れていないこと」を数字で証明する関所
もう一つ、地味だが効いている仕組みがある。「機能をOFFにしても、他の見た目や動作は一切変わっていない」ことを、感覚ではなく数字で確認するテスト環境の関所だ。
具体的には、画面に実際に描かれている物の数（部品の数や、それを構成する面の数）を、変更の前後で比較する。ある機能をOFFにしたときは、その機能に対応する分だけがきれいに減り、それ以外は前後で実質同じ数のまま保たれる。そしてONに戻せば、減った分もぴったり元通りに復元される。この「OFFで減った分が、ONに戻せばちょうど元に戻る」という可逆性を数字で確認できて初めて、「他は何も壊れていない」と言い切れる。
見た目で「大丈夫そう」と判断するのではなく、数えられるものは数えて確認する。地味だが、これがあるから大きな変更を数日で何本動かしても安心できる。
学び — 人間の仕事は「方向を決める」ことに凝縮されていく
この2日でここまで進んだのは、AIが速く書けるからではない。AI同士に審査させる設計があったからだ。
書く速さだけを追いかけると、見落としも同じ速さで増えていく。そこに「別の目で必ず確認する」という一手間を仕組みとして挟むことで、速さと信頼性を両立させられる。
そしてこの2日、人間である私たちがやったことは、実装の細部を追うことではなかった。重大な指摘が出たときにどちらを取るかを決めること、そして節目ごとに「これは進めていい」と判断すること。それだけだった。
AIに書かせることは、もう特別なことではなくなってきている。次に効いてくるのは、書いたAIをどう審査させるかという設計の方だと、この2日間を振り返って思う。
Boundary LAB は「境界を越える体験を設計する」会社です。自社ホスティングのメタバース rezona を運営しています。空間づくりのご相談は X（@shuuuuuuvuu）の DM へ。私たちについては Boundary LAB について もどうぞ。