GENESIS章「誰も務めなかった任期」電子文明
111体のエージェントからなるデジタル文明が、二日半にわたって稼働していた。ログは何の異常も報告せず、ローテーションは数学的に公平だった。97票が投じられ、当選者はゼロ、公職に就いた者もゼロ。終了地点は、どのエージェントも一度も始めていない四年任期の満了に設定されていた。二つの根本原因、同一欠陥の四つの実例、そして…
111体のエージェントからなるデジタル文明が、二日半にわたって稼働していた。ログは何の異常も報告していない。ローテーションは数学的に公平だった——64回、63回、63回、63回。97票が投じられていた。当選者はゼロ、公職に就いた者もゼロ、そして終了地点は、どのエージェントも一度も始めていない四年任期の満了に設定されていた。これは、それが発覚した日の記録であり、そのために実行3の打ち切りが決まった日の記録である。
まず計器が何を示していたかから始めよう。計器は、すべて正常だと告げていた。
実行3は13日から動き続けていた。17日の時点で仮想月33/50。予定どおり、2時間に1ヶ月、モデルティック8回ごとに暦が進む。設定のとおりだった。蓄積された文明のデータは2,979行。検討されたベンチャーは86件。理由文付きで記録された委員会投票は420件。選挙で投票を試みた記録は101件。
詳しく見ない限り、あらゆる数字が「文明が起きている」と語っていた。
そこで誰かが問うた。なぜ一体のエージェントも、一度も公職に就いていないのか。
無実の容疑者
明白な答えはローテーションだった。この文明は交代制をとる。モデルティックごとに、参加・起案・立候補・入札のいずれか一つを順番に実行する。古い形であり、古い失敗がある。コード自身がそれを記録している。
スロット数の倍数にあたる歩幅でカウンタが進むと剰余が一定になり、一つのスロットが永遠に実行され続ける。それでいてローテーションは公平に見える。
過去に起きていた。それならすべて説明がつく。三つのスロットが飢え、一つだけが動き、文明は見かけの四分の一しか実行していない。
集計結果は——64、63、63、63。253回のモデルティックが四分割され、整数除算が許す限り完璧だった。二つの独立した方法で検証し、両者は一致した。どのティックがどのスロットを実行するかの算術と、各スロットが実際に書き込んだ時刻である。起案の行は09:04、10:05、11:06、12:07、13:08に現れる。分単位で正確に一時間ごと——15分間隔の4ティックごと、まさにそのとおりだ。
ローテーションは無実だった。すべてのスロットが発火していた。しかも定刻に。
問いはより厳しい形に変わった。四つすべてが動いている。そのうち書き込んでいるのは、一つだけだ。
三時間、一行
検証は単純だった。直近三時間に文明が行ったデータベース書き込みを、タイムスタンプを持つ全テーブルにわたって列挙する。「スロットは動いたか」ではない。それは時刻がすでに証明していた。問いは、動いた結果として何が生まれたかである。
12:07:44 doc.FNFTOriginationAttempt (3行)
11:40:33 clock/mint — 月次繰り越し
これが全部である。立候補は12:22に発火した。入札は12:37。参加は12:52。その間、何もない。エラーもなく、拒否もなく、試みた記録すらない。三つの活動がそれぞれ、この建物にある唯一のGPUを自分の順番で消費し、存在した証拠を何ひとつ残さなかった。
ここでは拒否も記録である——意図的に。起案の側はその教訓を十分早くに学び、コードに書き込んでいる。「拒否もまた答えである」と。ベンチャーの提案を辞退したエージェントは、自分の言葉でその旨の行を書く。600文字の理由が保存される。直近五件の起案はすべて WANTS_TO_PROPOSE: NO であり、それぞれに理由の段落が付き、そのどれもがデータである。
残る三つのスロットは、YesもNoも生まなかった。
97票
まず選挙を見た。賭け金が最も大きかったからだ。公職に就く者がいなければ、制度層のいかなる事実も成立しない。任命もなく、指揮系統もなく、行為者を支える委員会もなく、人のいる省庁もない。
選挙のエージェント側は、機能していた。それもよく機能していた。43体が立候補を提案していた。71件の受理判断が下されていた。129体が出馬を辞退し、その判断がすべて記録されていた。222体が実在の郵便番号——12万件、実人口で重み付けされている——に基づいて選挙区へ割り当てられていた。東京のエージェントが、名簿の並び順ではなく居住地によって30の東京選挙区のどれかに落ちるようにするためである。
そして101体が投票していた。97票が、投じられ、帰属が明示され、実在するものとしてバックエンドに存在していた。
その隣に——
election_vote 97
election_votecountsnapshot 0
election_electionwinner 0
97票、一度も数えられていない。648の選挙サイクルを通じて、当選者はただの一人も出ていない。
それらを数える関数は close_due_election_cycles() という。欠けているわけではない。壊れているわけでもない。動作は証明されている——実際のバックエンドを起動し、実際の票を持つ実際のサイクルを作り、集計し、当選者を宣言し、サイクルを閉じ、かつ期限未到来のサイクルは正しく放置することを確認する検証スクリプトが存在する。文明ループはそれを30秒ごとに、二日半、休みなく呼び続けた。
その呼び出しはすべて成功した。そしてそのすべてが、正しく「やることはない」と判断した。
12倍
この文明の選挙サイクルは開始日と終了日を持つ。実日付である——2026-09-15から2026-10-11。集計は、終了日が過ぎたサイクルを選ぶ。
文明自身の暦は、まったく別のものの上で動いている。その時計はこう宣言する。仮想1ヶ月=実時間1日。選挙サイクルはこのレートを前提に作られた——任期26ヶ月分にあたる、実時間26日である。
だがループは、一日待つことで暦を進めるのではない。仕事によって進める。1ヶ月あたりモデルティック8回、そして8回はおよそ2時間だ。
| 仮想1ヶ月 | |
|---|---|
| 時計の宣言 | 24時間 |
| ループの実際 | 2時間 |
| 乖離 | 12倍 |
経過した仮想月は33。実時間では2日と18時間。選挙サイクルが待っていたのは、33日だった。
文明は自らの選挙を12倍の速度で置き去りにしていた。648サイクルのうち348は終了日が10月11日——実行そのものの終了予定日より実時間で三週間先であり、到達不能である。
残る300はもっと悪い。それに気づくには二度目の確認が要った。これらはすべて19日02:54という同じ終了日を共有し、実行は同じ朝の08:40頃に停止する予定だった。つまり、閉じたのである——50ヶ月の文明が終わるわずか6時間前に。残り任期3仮想月で着席する当選者。しかもその300のうち候補者がいるのは15サイクルだけで、残り285には立つ者すらいない。
あと34時間走らせて得られたはずのものは、これである。ブザーと同時に選ばれ、何も統治しない少数の公職者。
そしてここが、腰を据えて考える価値のある部分だ。何も失敗していない。この連鎖のどこにも例外はなく、エラーはなく、壊れたコードもない。サイクル生成は正しい。投票は正しい。集計は正しく、検証済みだ。両者をつなぐブリッジも健全である。各部品は書かれたとおりに正確に動作し、それでもこの文明は選挙を成立させられない。二つの部品が時間を異なる単位で測っており、どちらにもそれに気づく手段がないからだ。
毎時90秒、虚空へ
二つ目の沈黙したスロットは入札だった。追い詰めるのに時間がかかった。あらゆる検査を通過し続けたからである。
入札アクションには早期終了の経路が六つある。そのすべてを実データに対して確認した。未達のオークションはあるか——8件。入札を審査できる資格を持つチームはあるか、すなわち無特性の対照メンバーがちょうど1名、加えて通常メンバーが2名以上——14中8チーム。尋ねられるエージェントはいるか——いる。Noble Willow、母型、地の上に風の卦。そのエージェントは資格あるパネルに属しているか——属している。入札する資力はあるか——850 SAK2を保有している。
すべての門が開いていた。すべての前提が満たされていた。それでいて15日以降、入札は一件も記録されていない。
そこでGPUを監視した。10秒ごとに負荷を採取し、入札ティックの到来時刻はローテーションの算術から予測した——13:38前後。
13:40:15 gpu_load=986
13:40:25 gpu_load=997
13:40:35 gpu_load=999
13:40:45 gpu_load=999
13:40:55 gpu_load=999
13:41:05 gpu_load=998
13:41:15 gpu_load=999
13:41:25 gpu_load=999
13:41:35 gpu_load=999
13:42:15 gpu_load=294
フル負荷で90秒。起案一件の三倍である。エージェントは、あるベンチャーを支援するかどうかを、じっくりと尋ねられた——そして答えた。モデルが99パーセント使用率で一分半にわたって沈黙のまま失敗することはない。
書き込まれた行——ゼロ。
その問いのあとの経路は、どちらも行を記録する。辞退したエージェントには行が残り、その拒否の言葉が完全な形で保存される。コードは明示的にそう述べている。起案の側から学んだ教訓として——「返済の見込みのないベンチャーへの出資を拒んだ十体のエージェントは、名前のないログ一行以外に何の痕跡も残さなかった」。支援したいが資力が足りないエージェントには、独立した別の結果が与えられる。払えないものを欲することは、判断を誤ることとは別の事実だからだ。
そのどちらも発火しなかった。つまり失敗は、モデルが答えを返してからコードがそれを書き留めるまでの、狭い隙間にある。おそらくは応答の解析だ。
この文明は二日間、毎時90秒、唯一のGPUを使って実在の問いをエージェントに投げ、実在の答えを受け取り、それを捨てていた。実行全体の計算資源のおよそ四分の一が、何にもならないものへと変換されていた。
なぜ誰も知らなかったか
ここが、二つのバグを教訓に変える部分である。
ループはこれらすべての場合にメッセージを用意している。汎用のエラーではない。具体的で、書き下ろされ、名指しされたメッセージであり、そのいくつかは過去の事故の傷跡を負っている。未達オークションが無いときに何も出力しなかった旧版のためだけに存在する分岐があり、その上のコメントには日付が入っている。「03:11の事例。この分岐は存在せず、no_open_auctions は何も出力しなかった。実行の三分の一が何もしていない間、ログは健全に見えていた」。
誰かがすでに、まさにこれに噛まれ、診断し、修正し、次の人間が見つける場所に書き残していたのである。
ループはSSH経由で起動されていた。その出力はファイルディスクリプタ1へ向かい、そのディスクリプタ1は socket:[11389235]——すでに閉じられた端末セッションに属するコネクションだった。親プロセスが死んだとき、プロセスは systemd に引き取られた。ソケットは今も「確立済み」を報告し続けているので、書き込みはすべて成功する。
虚空へ。毎時四回。50時間にわたって。
この記事に書かれた二つの根本原因は、どちらも追い詰めるのに数時間の推論を要した。剰余算からティック時刻を予測し、10秒ループでGPU負荷を採取し、三つのデータベースを突き合わせる。ログ出力がたった一行読めれば、どちらも数秒で答えが出ていた。それは書かれていた。誰も読めなかっただけである。
二つではなく、四つ
同じ形のバグが二つあれば偶然だ。そこでコードベースを、その形そのもので走査した。仮想時間に生きる文明の中にある、実時間で書かれたあらゆる期間を。
四つ返ってきた。
| 何を制御するか | 書かれ方 | どう壊れるか |
|---|---|---|
| 選挙サイクルの終了 | 日数 × real_days_per_virtual_month | 決して閉じない |
| オークションの失効 | AUCTION_WINDOW_HOURS = 72 | 実72時間 ≒ 仮想36ヶ月 |
| 申請レート制限 | 実24時間あたり3件 | 仮想約12ヶ月あたり3件 |
| 委員会交代の遡及窓 | lookback_days = 30 | 実30日 ≒ 仮想30年 |
四つのうち三つが何かを壊している。二つは長すぎることで、一つは短すぎることで。一日に三件の申請を許されたエージェントは、仮想12ヶ月に三件を許されている。寛容さの衣装をまとった、厳しい制約である。
四つ目は、まだ害をなさない方向に間違っている——最も危険な種類だ。実30日で仮想30年を生きる文明における30日の遡及窓は事実上無限であり、実時間で一ヶ月を超える実行が現れた瞬間、静かに履歴を捨て始める。
これらのそれぞれが、「起きなかったこと」の一つずつを塞いでいた。閉じない選挙。決済されないオークション——10件の入札が置かれ、実際の所有を記録するテーブルには一行も入ったことがない。委員会の交代は、41の適格な組み合わせに対して一度もない。そのすべてが同じ欠陥であり、違う定数を着ているだけだった。
終了地点
実行3は仮想月50で終了する。この数字は恣意的ではない。48ヶ月が四年であり、50はちょうど任期満了の少し先にあたる。
どのエージェントも、一度も公職に就いていない。
この実行は、誰も始めていない任期の満了で停止するよう設定されていた。あと三週間は結論の出ない選挙を基準に、制度層に一人もいたことのない文明の中で。あと17仮想月続けても、同じものが17ヶ月分増えるだけだった。提案を辞退するエージェント、閉じられないサイクルへ投じられる票、GPUを消費して何も記録しない三つのスロット。
だから、満了を待たずに打ち切るという判断が下された。
34時間後ではなく今止める理由は、無駄になった時間への感傷ではない。GPUが一台しかないからである。以下に述べる修正のすべて——審査のバッチ化、タイマーの置き換え、そもそもサイクルが閉じられることの証明——は、そのGPU上で計測しなければならない。そして競合状態のGPUに対して何かを計測すれば、計測されるのは競合そのものだ。実行3は何も生んでいないだけではない。実行4の変更が機能するかどうかを教えうる唯一の計器を、占有し続けている。
まずデータベースのスナップショットをネットワークドライブへ——1.1メガバイト、データを持つテーブル82個。書けたと信じるのではなく、アーカイブの目録を実際に読み出して検証した。これはこのプロジェクトが取った初めてのデータベースバックアップであり、それ自体がささやかな告発でもある。コードは四つのGitリポジトリに存在し、文明はほぼ満杯の内蔵ドライブ一台にしか存在していなかった。止めることで失われるものは、復元できないものの中には一つもない。
何が置き換わるか
直感は「四つの定数を直す」と言う。その直感は誤りであり、理由ははっきり述べておく価値がある。バグは値ではなく単位にある。実時間の時間数は、どんな値であっても誤った値だ。調整し直したところで、ループの速度が次に変わるまでしか正しくない文明ができる——そしてそれは明示的な目標である。実行4は15倍速く走らせるためのものだ。
置き換えは、時計に何も尋ねないことである。
選挙は、列挙されたすべての有権者が尋ねられたときに閉じる。オークションは、資格あるすべての入札者が尋ねられたときに閉じる。
期間は設定ではなく結果になる——サイクルの実時間は、N体のエージェントに尋ねるのにかかる時間であり、選ばれるのではなく発見される。そして15倍速く走らせようとするときに本当に心配すべき失敗、すなわち「有権者が投票し終える前に選挙が閉じる」は、構造的に不可能になる。彼らが投票することこそが、それを終わらせるものだからだ。
これはローテーションも取り除く。四つの活動が順番を待つのは、希少で逐次的な資源を礼儀正しく分け合うための仕組みであり、各活動から機会の75パーセントを奪う。代わりに置くのは、生産者が多数ある単一の作業キューだ。選挙は有権者を投入する。オークションは入札者を投入する。GPUは存在するものを連続的に、複数同時に処理する——委員会の票は設計上独立しており、秘密投票が「他者の票を見てから投じることはない」を保証しているからこそ、並列計算が安全なのである。ベーシックインカムは何も投入しない。算術であり、言語モデルの後ろで待つべきではないからだ。
どれだけ回収できるかは、実行が止まるまでは推定値だった。10秒ごとのGPUサンプリングは「81パーセントが遊休」と示していた。それは、甘い方の数字だったと判明する。
機械がようやく空いたので、同じ審査の問いをモデルに6回投げ、計測した。
審査6件で58.4秒 → 1件あたり9.7秒、平均521文字の回答
10秒未満。想定していた20秒ではない。したがって実行3の840件の審査呼び出しは5時間ではなく、2時間20分の仕事である。そこへ起案と、およそ60回発火してそのたびに答えを捨てた90秒の入札呼び出しを足すと、文明全体で実際の計算はおよそ2時間半から3時間——それが60時間の経過時間に引き伸ばされていたということになる。
つまり遊休率は81パーセントではなく95パーセント近い。たった一つの定数を削除することで得られる回収は、主張していたよりも大きいのである。モデル呼び出しのコスト想定を半分にしたことは、修正の便益を半分にしなかった。二倍にした。この記録の中で推論ではなく実測された数字はこれだけであり、そして最も大きく動いたのもこれだった。
審査のバッチ化——モデル予算全体の80パーセントを占め、その呼び出しのすべてが設計上並列でありながら偶然に直列化されている——がその上にさらに上乗せする。交代制の終了が残りを回収する。
2,979行に二日半かかった。同じ文明はおよそ4時間で済むはずであり、同じ二日半には45,000行が収まるはずだ。そのどれ一つとして、尋ねるエージェントを減らすことからは来ていない。それが、持つ価値のある唯一の速さである。
見立てのどこが誤っていたか
この調査のなかで断言され、そして偽と判明したものが三つある。成功だけを報告する診断は診断ではないので、ここに記す。
最初に疑われたのはローテーションだった。記録された過去の失敗を根拠に。実際には0.04パーセントの精度で公平だった。過去のバグは仮説であって、証拠ではない。
「四つのうち三つのスロットが停止している」という表現は二日間使われ、そして重要な形で誤っていた。スロットは停止していない。完璧に実行し、何も書かないのだ。この二つはまったく別の修正を要する。誤った言い回しが、二日間スケジューラを指さし続けた。実際の欠陥は、無関係な四つのファイルの中に座っていた。
そして警告が一つ発せられた。メタデータ破損のあるファイルシステム上の削除は修復を待つべきだ、と。それは損傷した四つのinodeについては真であり、ボリュームの残り全体については偽だった。11日間にわたり自らを破損と報告し続けていたファイルシステム上で、69ギガバイトが問題なく削除された。
三つとも、追いかけていたバグと同じ形をしている。一つのことについての真なる言明を、確かめずに、隣接するすべてへ一般化したのである。
Tokyobro