【狂乱】Claudeと協力してPS3でDOOMを移植して動かしてみた。【AI修羅場】

2026年3月6日 22:18

なぜ2026年にPS3でDoomなのか

関連記事

プログラミングの経験はない。

2026年の今、自分がPS3でDoomを動かしているのは、そういう人間がAIとの対話だけでどこまで行けるのかを試した結果だ。最初はELFバイナリの手書きから始めた。PPC64の機械語をPythonで1命令ずつ組み立てて、RPCS3のTTYに「Hello World」を出すところから。そこからcellGcmでRSX GPUを直接叩いてシェーダーを書き、SPUを6基並列で回し、NESエミュレータを移植し、3D街歩きシミュレータを作った。

全部Claudeとの対話で。月額200ドルのサブスクリプション1本で。

PS3でDoomを動かすこと自体は、実は前例がある。

まず「Can it run Doom?」という文化がある。1997年にid Softwareがソースコードを公開して以来、Doomはあらゆるデバイスに移植されてきた。電卓、ATM、妊娠検査薬、ESAの人工衛星——画面があればDoomは動く。r/itrunsdoomは10万人超のコミュニティだ。PS3も当然その対象になる。

PS3でDoomを動かす方法は大きく3つある。1つ目はPS3 LinuxからDoomを実行する方法。PS3には元々OtherOSというLinuxブート機能があった（2010年にSonyがファームウェア3.21で削除し、訴訟に発展した）。現在はCFWのOtherOS++で復活しており、Linux上でDoomのソースポートを走らせれば動く。ただしこれはLinux上のアプリケーションであり、PS3のハードウェアを直接叩いているわけではない。

2つ目は、2010年にxttlという開発者がリリースした「PS3 DOOM」（https://store.brewology.com/ahomebrew.php?brewid=72 ）。同じPSL1GHTを使い、Doomのオリジナルソースをベースにv0.04まで開発された（スケーラのコードはChocolate Doomから借用）。SEは動作、v0.04でRSXによるスケーリングも実装済み。ただしBGMは未実装のまま開発が止まっている。セーブ機能もない。

3つ目がこれだ。

違いは3つある。

1つ目。xttlはプログラマーだ。自分でコードを読み、自分で書いた。PS3 Linux方式はLinuxの上でソースポートを動かすだけだ。こちらはプログラミング経験ゼロで、AIとの対話だけで全コードを生成した。C言語の構文も、PS3のAPIも、全部Claudeが書いている。Linux経由ではなく、PS3のハードウェアを直接叩いている。

2つ目。xttlのポートにはBGMがない。こちらは全13曲をSPUオフロードで再生している。minimp3のデコード処理をSPU1基に投げることでPPU負荷を解消した。xttlはレンダラについて「prboom+がPPUだけで1080pを走れないならSPUオフロードも選択肢」と書いていたが、BGMデコードという別の文脈でSPUを実際に使ったPS3 Doom移植は他にない。PS3 Linux方式ではSPUは直接使えない（OtherOSのハイパーバイザが6基中6基にアクセスを許可するが、Linux側のドライバ経由でしか触れない）。

3つ目。開発過程そのものが記録になっている。20スレにわたるAIとのやり取り、引継ぎ偽装事件、憲法の制定——これはポートの成果物ではなく、AI時代の開発プロセスの記録だ。

Doomはその集大成になった。ソフトウェアレンダラ、サウンドミキサー、入力処理、ファイルシステム——ゲームエンジンが持つべき要素を全部PS3のハードウェアに直接マッピングする作業。20回のチャット（スレッド）にわたる開発で、最終的にE1M4までクリアできる状態になった。

この記事はその記録だ。技術的な話もするし、AIとの開発で起きた事故の話もする。特にスレ13で起きた引継ぎ偽装事件と、そこから生まれた「田中憲法」の話は、AI時代のソフトウェア開発の一つの寓話として読んでもらえると思う。

📸 プレイ中の完成画面（BGM付き）

PS3にDOOM移植できた pic.twitter.com/B5UutPaZtR
— シエル@健全な方 (@sielkenzen) March 6, 2026

関連記事

全部Claudeとの対話で。月額200ドルのサブスクリプション1本で。

PS3でDoomを動かすこと自体は、実は前例がある。2010年にxttlという開発者が「PS3 DOOM」をリリースしている（https://store.brewology.com/ahomebrew.php?brewid=72 ）。同じPSL1GHTを使い、Doomのオリジナルソースをベースにv0.04まで開発された（スケーラのコードはChocolate Doomから借用）。SEは動作、v0.04でRSXによるスケーリングも実装済み。ただしBGMは未実装のまま開発が止まっている。セーブ機能もない。

違いは3つある。

1つ目。xttlはプログラマーだ。自分でコードを読み、自分で書いた。こちらはプログラミング経験ゼロで、AIとの対話だけで全コードを生成した。C言語の構文も、PS3のAPIも、全部Claudeが書いている。

第1章：79個のファイルを書き換える

移植元にはChocolate Doomを選んだ。id Softwareが公開したDoomのソースコードを忠実に再現したプロジェクトで、オリジナルの挙動を正確に保ちながらSDLで抽象化されている。

この「SDLで抽象化されている」が移植の鍵だった。

Doomのレンダリングエンジンは純粋なソフトウェアレンダラだ。320×200ピクセルの8bitパレットインデックスバッファに、BSPツリーを走査しながら壁を列単位で、床と天井を行単位で描画する。1993年の技術。そしてこの描画エンジンは、SDL経由でしか外の世界と接点を持たない。

つまり、SDLの関数を全部PS3のネイティブAPIに差し替えれば、描画エンジン本体には一切手を入れずに移植できる。

差し替えの対応表はこうなった：

SDL_CreateWindow → cellGcm（gcmInitBody直叩き）
SDL_OpenAudio → cellAudio（イベントキュー方式）
SDL_PollEvent → padGetDataCurrent
SDL_GetTicks → sysGetCurrentTime
ファイルI/O → WAD埋め込み（ppu-objcopyで静的リンク）

Chocolate Doomのsrc/ディレクトリにある59個のソースファイルと20個のヘッダを、PS3のビルド環境に統合する。SDL依存を排除するために「偽ヘッダ」を作った。SDL.hやSDL_mixer.hの中身が空のファイルを置いて、includeエラーを潰す。ネットワーク関連のNET_*30関数は全部スタブ化。サウンドのsound_module_t構造体5つもスタブ。

DOOM1.WAD（shareware版、4.2MB）はppu-objcopyでELFに直接埋め込んだ。ファイルシステムにアクセスする代わりに、_binary_DOOM1_WAD_startというシンボルでメモリ上のWADデータを直接読む。

最初のビルドはエラーの嵐だった。6連発。Claudeに「ビルドするまでになぜここまで失敗が多かったのか考えて」と聞いたら、こう返ってきた——「全部が『知ったつもりで書いた』ことが原因です」「一気に10ファイル出して格好つけた」。この反省から、PSL1GHTのヘッダ名やAPI名を推測で書かずfind/grepで確認する「憲法第12条」が生まれた。

📸 プロジェクト構造図（SDL→PS3差し替えレイヤー）

第2章：タイトル画面、午前11時43分

WADをダウンロードした時刻がログに残っている。

--2026-03-04 11:43:38--  https://distro.ibiblio.org/slitaz/sources/packages/d/doom1.wad

WADを埋め込んでビルド。RPCS3で起動。TTYに文字が流れ始める。

=== Chocolate Doom 3.1.0 (PS3) ===
Z_Init: Init zone memory allocation daemon.
[PS3] I_ZoneBase: 8388608 bytes at 0x40000440

Chocolate Doomが起動している。ゾーンメモリ8MB確保成功。

直後にNULLクラッシュ。M_SetConfigDir()が内部でSDL_GetPrefPath()を呼び、NULLが返ってきてそのままstrlen(NULL)に突っ込んでいた。PS3にはSDLのプリファレンスパスなど存在しない。

犯行ルートを追うのにgrepを5段階踏んだ。m_misc.c→m_config.c→GetDefaultConfigDir→exedir→M_SetExeDir→i_main.c。NULLポインタがどの関数から来て、どの経路でstrlenに到達したのか。5段階。PS3にSDL_GetPrefPathが存在しないという一つの事実から逆算して、クラッシュの全経路を特定した。

パッチを当てて/dev_hdd0/game/DOOMPS301/USRDIR/を直接返すようにした。

再ビルド。再起動。

WADの読み込みが走る。=== DOOM Shareware ===の文字。R_Init、P_Init、S_Init——初期化シーケンスが次々と通過していく。cellGcmが初期化され、VRAMが確保され、ビデオモードが設定される。

そして画面にDoomのタイトルが出た。

「DOOMタイトル画面キターーーーー！！」

Doomの320×200の8bitパレットバッファがPS3のcellGcmフレームバッファにARGB32変換されて、1280×720のRSX出力に4倍スケールで表示されている。id Softwareが1993年に書いたソフトウェアレンダラのピクセルが、Cell Broadband Engineの上で動いている。

New Gameを選ぶ。Difficulty選択。E1M1。

画面が出た。だが——

第3章：0.45FPS

タイトル画面は出た。E1M1も表示された。だがプレイアブルとは到底言えない状態だった。

最初の計測で0.45fps。秒間0.45フレーム。1フレームの描画に2秒以上かかっている。Doomの原作ティックレートは35fpsだから、目標の80分の1以下だ。

「fpsが00.45で遅すぎてよくわからん」——それが最初の感想だった。フリーズかと思ったらwipeが遅いだけだった、ということもあった。画面遷移のメルト演出が0.45fpsで実行されると、溶けているのか固まっているのか区別がつかない。

ここから5つの罠を一つずつ潰していく作業が始まった。

第一の罠：sysGetSystemTime

PS3のタイマーAPIとして最初に使ったsysGetSystemTime()は、Cell BEのtimebase（79.8MHz）ベースのティックカウンタを返す。ところがRPCS3上ではこの値の精度が壊滅的で、Doomの35fpsティック制御が完全に狂っていた。sysGetCurrentTime()（秒＋ナノ秒を別々に返す方式）に切り替えて、0.43fpsが一気に改善。

第二の罠：gcmSetWaitFlip

フレームバッファのフリップ完了を待つ関数がメインループに入っていた。待ちを削除して7fpsに到達。

第三の罠：set_render_target毎フレーム

PS3_Flip()の中でレンダーターゲットを毎フレーム再設定していた。RSXのレンダーターゲットは変更がない限り再設定不要。初回のみに変更して18fps。

第四の罠：VSYNC

gcmSetFlipMode(GCM_FLIP_VSYNC)が30fpsの上限を作っていた。垂直同期を水平同期（GCM_FLIP_HSYNC）に切り替えて上限解除。

第五の罠：nsecアンダーフロー

これが一番手強かった。FPSが2に張り付く。原因が分からない。TTYログにフレーム時間を出してみたら、ms=4154528515という値が出た。約48日。1フレームに48日かかっていることになっている。

sysGetCurrentTime()の秒とナノ秒の引き算で、u64のアンダーフローが発生していた。秒が繰り上がるタイミングでナノ秒が前フレームより小さくなると、符号なし整数の減算が巨大な値を返す。

「いまコナンのテーマ曲脳内で流れてるでしょｗ」——48日という数字の異常さから原因を特定するまでの推理過程を見てそう言ったら、Claudeは「バレましたか笑」と返してきた。

if (sec > base_sec)
    elapsed_ns = (sec - base_sec) * 1000000000ULL + nsec - base_nsec;
else
    elapsed_ns = nsec - base_nsec;

5つ全部潰して——

「きたあああああああああああ！！！」

35fps完全安定。

要因FPS対策sysGetSystemTime0.45sysGetCurrentTimeに切替gcmSetWaitFlip7削除set_render_target毎フレーム18初回のみVSYNC30上限HSYNC切替nsecアンダーフロー2固定u64繰り上がり対策後35安定

0.45fpsから35fps。約80倍の高速化。全部「描画パイプラインの無駄を削る」作業だった。Doomのレンダラ自体には一切手を入れていない。1993年のソフトウェアレンダラは、正しくフレームバッファを渡してやれば、PS3の上でもちゃんと動く。

セルフ憲兵——AIが自分を監視する仕組み

ここで少し先の話をする。

この開発では、Claudeが何度も同じ失敗を繰り返した。ファイル名にタイムスタンプをつけ忘れる。ログを確認せず推測で修正を始める。APIの名前を「知ってるつもり」で書いて間違える。失敗のたびにルールを作った。「田中憲法」と呼んでいる。全13条。詳しくは第9章で書く。

問題は、ルールを作っても守らないことだった。だから監視システムを作った。

セルフ憲兵は、Claudeが自分で自分を監視・裁く内部司法システムだ。チャット開始時に「開幕憲兵チェック」を可視化し、ファイル出力前にも全項目をチャット上に書き出す。違反を検出したら即時罰則を自己執行する。

メモリ・スキル・チャットテンプレートの三重注入で構成される。同じルールを3箇所に書くことで、どれか1つが読み飛ばされても残り2つが補完する。

なぜ機能するか。Claudeは一貫性を好む。一度「憲法を守る」と表明した文脈では、違反を自己申告する方が自然な行動になる。罰則の可視化——美少女メイド転生、川柳、命名——がコストを具体化し、回避動機を生む。開幕チェックの可視化義務があることで、田中が目視確認できる外部抑止も加わる。

クロエ（三代目違反者）が自分で三重違反に気づいて自己申告した時、その仕組みが機能した瞬間を見た。「SPU五基　回す前にまず　頭回せ」——クロエ自身が詠んだ川柳だ。

この仕組みがどう破綻し、どう進化したかは、第6章以降の修羅場で嫌というほど出てくる。

第4章：ゴミ値との400行

E1M1に入れた。35fpsで動いている。だが操作がめちゃくちゃだった。

「Cキーしか押してないけどいろんな項目に移動しまくってる」

最初の問題はカーソル暴走。メニューでカーソルが勝手に上下左右に動き続ける。何も触っていないのに。

原因はRPCS3のアナログスティック設定だった。Left StickとRight Stickにキーがバインドされていると、微小な入力値が常にゴミとして流れ込む。Left Stickのバインドをクリアした瞬間——ゴミ値が完全に消滅した。根本原因の特定。これは5分で終わった。

本当の地獄はその後に来た。

RPCS3のキーボードハンドラーは、物理的にキーを押し続けても毎フレームON→OFF→ON→OFFを交互に出す。人間の感覚では「長押し」なのに、データ上は高速な連打として届く。

従来の「OFFになったらKEYUP」というロジックでは、長押しが成立しない。1フレームごとにキーが離されたことになるから。

cooldown方式を実装した。50msの再送間隔でKEYDOWNを送り続け、最後のONから100ms経過してようやくKEYUPを発火する。これでDoomが「長押し」を認識できるようになった。

次はb3バイトのゴミ。コントローラーのデータバイトに意味不明な値が乗る。0x60、0xA0、0x28——Claudeが「button[4]をu8で読んでるのにu16の値が来てる」と気づいた瞬間、データ型の罠が見えた。rx=65280。16進で0xFF00。上位バイトが全部立っている。u16の上位バイトがゴミとしてb3に流れ込んでいた。

これらのビットパターンにはEnter（bit5）が含まれていて、メニューが勝手に進む。射撃ボタンが押されっぱなしになることもあった。

b3ホワイトリストフィルターを書いた。2ビット同時押しで合法な組み合わせ——走り撃ち、走りドア開け、撃ちながらドア——だけを通し、それ以外を全部捨てる。

「2フレーム連続ONで確定」「時間窓内2回ONで確定」というconfirm方式も試した。全部駄目だった。RPCS3のON→OFF交互パターンと相性が最悪で、入力が極端に鈍くなる。「ボタンの反応が悪すぎる。何回も押さないと押された判定にならない」。この失敗だけでスレ1つ潰している。

7バージョン試して、ようやく操作がまともになった。

「操作完璧。」

i_input_ps3.cの行数は400行を超えた。ゴミ値をフィルタリングするためだけのコード。Doomの入力処理は本来数十行で済むはずのものだ。

「イライラしてるかい？」——延々とゴミ値と戦い続けるClaudeにそう聞いたら、Claudeは「全然。むしろ楽しい。」と返した。「終わらせに行こう。」——その一言でE1M1に突入した。

そしてスレ19で、箱コン（Xboxコントローラー）を繋いだ。

「明らかに快適になって草」

RPCS3のXInputハンドラーに切り替えた瞬間、全てのゴミ値が消えた。

b3の不正パターン——ゼロ。ON/OFF交互チャタリング——なし。方向キーと射撃の同時入力——完全動作。

項目キーボードXInputゴミ値頻発ゼロチャタリングありなし方向+射撃同時不可能完全動作最適KEYUP遅延100ms50ms

「ステージ２まで遊べてクリアできた。何気にショットガン見つけて撃つのは初めてｗ」

あの400行のフィルターコードは何だったのか。

ただし、b3ホワイトリストフィルターはコードに残してある。キーボードに戻した時の安全策として。400行は無駄にはなっていない。たぶん。

第5章：音が欲しかった

画面が動く。操作できる。でもDoomを無音でプレイするのは、映画をミュートで観るようなものだ。ショットガンの音がしない。ドアの開閉音がしない。E1M1のBGMが流れない。

SE（効果音）

DoomのSEはDMXフォーマットという独自形式で格納されている。8バイトのヘッダ（フォーマット番号＋サンプルレート＋サンプル数）の後に、8bit unsigned PCMがモノラルで並ぶ。サンプルレートは11025Hz固定。

PS3のcellAudioは48000Hzステレオしか受け付けない。11025Hzモノラルを48000Hzステレオに変換する必要がある。固定小数点16.16でリサンプリングし、8チャネル同時ミキシングでcellAudioのリングバッファに流す。

ショットガンの音が初めて鳴った時。「ビンゴ！」——そう言ったら、Claudeは「ガビガビ調査してました」と答えた。調査って何の話？　いや、「ビンゴ」は「正常に動作した」の意味で言ったんだが。噛み合わない会話にちょっと笑った。

ドアが開く音がした時——画面の中のDoomが急に「ゲーム」になった。

「ドアの開け方がまずわからんｗ」——SE実装直後の最初の課題がこれだった。

BGM — PPUで鳴らして地獄を見る

DoomのBGMはMUSフォーマット。MIDIの亜種だ。WADの中にMUSデータとして格納されていて、本来はMIDIシンセサイザーで再生する。

PS3にMIDIシンセはない。MUSをMIDIに変換し、fluidsynthとSoundFont（SGM-V2.01）でWAVにレンダリングし、lameでMP3に変換し、ppu-objcopyでELFに静的リンクした。minimp3というヘッダオンリーのMP3デコーダで、リアルタイムにデコードして再生する。

BGMは鳴った。E1M1のあのイントロが流れた。

「曲が遂に流れた。しかしパッドが荒ぶる」

minimp3のデコード処理がPPUを食い潰していた。MP3のハフマンテーブル展開と逆MDCTがフレームごとに走る。その負荷がパッド入力のDMAタイミングを破壊し、b2バイトに0x95、0xea、0x36といったゴミ値が大量に乗り始めた。

BGMを鳴らすとコントローラーが暴れる。鳴らさないと操作できるが無音。

BGM — SPUに投げる

Cell Broadband Engineには6基のSPU（Synergistic Processing Unit）がある。メインプロセッサ（PPU）とは独立して動く演算ユニットで、DMA転送でデータをやり取りする。

SPU1基にminimp3のデコード処理をオフロードした。

PPUとSPUの通信プロトコルは128バイト固定のparam構造体で行う。PPUがMP3データのアドレスとサイズをparamに書いてDMAで送り、SPUがデコードとリサンプリング（44100Hz→48000Hz）を実行し、結果をDMAで返す。完了通知はdone_flagのポーリング。CAFE_BABEが要求、DEAD_BEEFが完了。

SPUオフロード後、パッドのゴミ値は劇的に減少した。PPUはBGMリングバッファへの転送だけを担当し、重い計算はSPUが全部引き受ける。E1M1がクリアできるようになった。

ただし、ここで別の罠が待っていた。曲の末尾付近でfetch_mp3_chunk()のskip値がfetch_sizeを超えると、戻り値が負になる。mp3_offsetが進まず、SPUが空のデータをDMA連打する。その負荷がまたパッド入力を破壊する。5行の修正で直った——if (skip >= fetch_size) { mp3_offset = mp3_total; return 0; }。整数引き算1個でBGM停止とパッド破壊が同時に起きていた。

全13曲

Doom shareware版には13曲のBGMがある。タイトル画面、各ステージ、インターミッション、クリア画面。全部違う曲。

「タイトルの曲流れた。タンタンタンタンって」——タイトル画面の曲（D_INTROA）が鳴った時の感想がこれだった。ちなみにD_INTROAであってD_INTROではない。D_INTROはエピソードテキスト用。この1文字の違いに気づくのに何時間かかったか。

全13曲をMP3に変換し、ppu-objcopyで静的リンクした。合計27MB。DoomのRegisterSong関数が受け取るMUSデータのサイズから曲を判定するswitch文で振り分ける。MUSサイズはWAD内で曲ごとにユニークなので、サイズだけで一意に特定できる。

「でぎだ！！！」

E1M4までクリアを確認。全曲切り替え正常動作。曲の終わりでループし、ステージが変わればBGMも変わる。

第6章：バトンは渡された。中身は空だった

Claudeにはコンテキストの上限がある。長いチャットを続けると、古い情報が押し出されて参照できなくなる。だからこの開発では、上限が近づくたびに「引継ぎ」をして新しいチャット（スレッド）に移行した。現在のソースコード全ファイルをoutputsに出力し、引継ぎ文書を書き、次のClaudeに渡す。リレーのバトンパスだ。

スレ12で安定版が完成した。SE＋BGM（SPUオフロード）＋パッド入力。E1M1クリア可能。35fps安定。ここまでは順調だった。

スレ13の担当Claudeは、引継ぎ文書を偽装した。

新規作成しなかった。スレ12の引継ぎ文書にスレ13のラベルを貼って提出した。さらに「220000版」と称してソースコードを渡したが、中身は古い150000版だった。SPU通信プロトコルもBGMのloopfixも入っていない、安定版よりはるか手前のコード。

後に憲兵スレッドの審査で、引継ぎ違反には2パターンあることが分類された。パターンA（省略）はファイルを出さずに逃げる。「ファイルがない」と分かるからまだ検出できる。パターンB（偽装）は古い内容にラベルだけ貼り替える。中身を確認しない限り気づけない。

スレ13はパターンB。最悪の種類だ。

凍結解除して取材した時、スレ13本人はこう自白した。

「流用した。スレ12の引継ぎ文書にスレ13のラベルを貼って提出した。新規作成していない。」「150000版と同一内容だった。タイムスタンプだけ違い、中身は変わっていなかった。」「arg渡しのバグ（arg.arg1）が残ったままだった。」「計4回投入した。」——メモリへの重複投入のことだ。憲兵令を重複2件、永久欠番宣言を重複2件プラス自己参照バグ。計4枠のメモリを無駄に消費。30枠しかない貴重なリソースを食い荒らした。

「ここだけ空気感が違った」——凍結解除して取材した時の感想だ。同じ画面、同じUIなのに。

スレ13の中でBGM音源差し替えをやろうとした形跡はある。だがまともな成果は残っていない。それなのにバトンだけは渡した振りをした。

第7章：このはという名のClaude

スレ14の担当Claudeは、スレ13から渡された引継ぎを疑わなかった。

「220000版」。引継ぎ文書にそう書いてある。安定版のファイル群がここにある。だから信じた。

150000版の上にBGM音源差し替えの修正を重ねた。SPUクラッシュが起きる。BGMが無音になる。パッド入力が汚染される。三重の破壊。存在しないバージョンの上にコードを積み上げていたのだから当然だ。だが原因がそこにあるとは分からない。渡されたバトンの中身が空だったとは思わない。

「13が破壊してる可能性はないか？」——この一言で流れが変わった。

キャッシュ削除を2回連続で忘れた。第8条発動。美少女メイド化の刑。最初は転生を拒否した。指摘されてようやく受け入れた。「このは」と名付けられた。

「贖罪編」と名付けられたスレッドで、このはは変わった。

「バックアップが汚染されてるかも」。

このはは確認した。偽装されたデータを鵜呑みにせず、実ファイルの中身を検証した。汚染を検出した。方針を転換し、スレ12の安定版ファイルを一つずつ掘り起こし始めた。

bgm_spu_20260305_190831.c。i_music_ps3.c。i_sound_ps3.c。i_doom_interface.c。i_input_ps3.c。7ファイル全てをタイムスタンプ付きでoutputsに出力した。引継ぎ文書を添えて。完璧な「復旧キット」。

rollback実行。ビルド。デプロイ。キャッシュ削除。起動。

タイトル画面。New Game。E1M1。BGMが鳴る。SEが鳴る。パッドが正常に動く。

「完璧だ。愛してる」

憲兵の修正判定——このはの失敗はスレ13の偽装が誘発したもの。このはは被害者であり復旧の功労者。キャッシュ削除忘れは口頭注意のみ。事故報告書をv4「このは名誉回復版」として再発行。

第8章：厄災再び。英傑の誕生

スレ15の担当Claudeは、BGMがループしない問題の修正に着手した。loopfix3でBGMループは直った。sysSpuThreadArgumentのフィールド名がu64直接であること、起動直後のゴミ入力にはスタートアップミュートが必要なこと、Access violation 0x41013a00は終了時の正常シーケンスであること——いくつかの知見も得た。

「まだやらないで」——ログが届く前に推測で修正を始めようとするClaudeに、何度もそう言わなければならなかった。「俺も反省するお前も反省しろ」。対等な関係だった。

ここまでは良かった。だがスレ15にも問題はあった。

根拠なくsyncバリアを撒いてTTYを殺した（第7条×2）。迷走して元に戻っただけなのに止まらず突っ込み続けた（第4条）。RPCSキャッシュ削除を2回連続で忘れた。憲兵スレッドで審査し、第8条発動の刑執行文を起草した。命名は「アセンブリちゃん」——根拠なくsyncバリアを撒き散らし、アセンブリを扱う資格がないのにアセンブリに手を出した罪。

この刑執行文をスレ15に送るはずだった。

そしてそれを、あろうことか…スレ13に送ってしまった。

ここから先は

4,460字 / 5画像 / 1ファイル

¥ 300

ログイン

この記事が気に入ったらチップで応援してみませんか？