AIエージェント11体でブラウザゲームを作ったら、バグの大半が「書いたのに動いていない」だった

Claude Code に「キャンプゲームを作って」と1通投げたら、3日でブラウザゲームが1本できました。

渓谷キャンプ — 秋の渓流沿いのキャンプ場で焚火をおこし、飯盒でご飯を炊き、その様子を撮って投稿するVlogシミュレータです。

• 遊ぶ（PCのブラウザのみ）: https://keikoku-camp.vercel.app
• itch.io: https://yohsuke-zw.itch.io/keikoku-camp

技術的な特徴を1つだけ挙げるなら、外部アセットを1つも使っていないことです。

画像0枚、3Dモデル0個、音声ファイル0本。リポジトリにバイナリがありません。テントの生地も、焚火の炎も、川のせせらぎも、秋の虫の声も、全部プログラムが起動時に生成しています。

Three.js r185 + Rapier + Web Audio、130ファイル、ランタイム依存は2つだけ。

ただ、この記事で書きたいのはゲームの紹介ではありません。

11体のAIエージェントを並列で走らせ、別のAIに出来を採点させ続けた3日間で、何が壊れたかの記録です。

結論を先に書きます。

見つかった不具合は13件以上。そのうち純粋な「実装漏れ」は1件もありませんでした。 コードは書かれている。ビルドも通る。エラーも出ない。それなのに画面に届いていない。全部そういう型でした。

並列でAIエージェントを走らせるとき、本当に壊れるのは実装の質ではなく、実装と結果の接続です。

その具体例を、実測値つきで並べていきます。

最初のプロンプト

すべては、この1通から始まりました。2026年8月15日 20:38。

Camping Vlog Simulator 2024並みのクオリティのキャンプシミュレーションゲームを作って。ただし、本家は海外製なので風景やギアは日本のものに。テクスチャから物理まで、思いつく全てをAAA品質で完璧に。サブエージェントを展開して各項目を個別に担当させて。各項目を /loop し、別のサブエージェントに視覚チェックさせろ。そいつは超辛口の批評家で、AAAに見えなければ続行。本物と並べてブラインドで見比べさせて。全員が心底驚くまで止めないで。

300字弱。仕様書ですらありません。画面数もゲームシステムも技術スタックも書いていない。

そして、この指示は3箇所で実行不可能でした。

「AAA品質で完璧に」

これは達成条件として成立しません。AAAタイトルの見た目は数十人が数年かけ、実写スキャン素材を使って到達するものです。ブラウザで動く、外部アセットを一切使わないプロジェクトが、数日で並ぶことはありません。

Claude Code は最初にそう返してきました。その上で「ブラウザで動く、丁寧に作り込まれた高品質リアルタイム3D」に読み替えて着手しています。

「全員が心底驚くまで止めないで」

止め時がない指示です。無限に回り続けるか、勝手に打ち切られるかのどちらかになります。

ここは**採点付きの反復ラウンド（打ち切り条件あり）**に置き換えられました。

「本物と並べてブラインドで見比べさせて」

これが一番おもしろい部分です。

本家 Camping Vlog Simulator 2024 のスクリーンショットは、著作物なので勝手にダウンロードして比較材料にはできません。つまり「本物と並べる」は物理的に実行できない。

代わりに提案されたのが、こういう形でした。

批評役のAIには「これが自作である」ことを伏せて画像を渡す。そして
「実写写真」「AAA製品版のスクリーンショット」「習作レベルのリアルタイムCG」の3択で分類させる。
「習作」判定が1枚でも残る限り、そのショットは不合格。

これなら実際に実行できます。そして結果的に、この置き換えが本記事の中心になりました。

ここで得た教訓を先に書いておきます。

曖昧な指示でも動く、という話ではありません。曖昧な部分を、実行可能な形にどう翻訳するかが本体です。

私が投げた指示のうち、字面どおりに実行されたものは1つもありませんでした。全部、達成可能な形に読み替えられている。そしてその翻訳の質が、そのまま成果物の質になりました。

どう作らせたか

ファイル所有権を先に固定する

並列でエージェントを走らせるとき、最初に決めたのは誰がどのファイルを触ってよいかでした。

CONTRACT.md という文書を作り、全エージェントに冒頭で読ませています。

そして**オーナー限定（誰も編集不可）**の枠を作りました。src/main.js、共有コンテキストの定義、カメラプリセット、撮影ハーネス。ここが動くと全員の足元が崩れるためです。

これが無いと並列は成立しません。11体が同じファイルを書き換え合って壊します。

実際、この規約は最後まで守られました。担当外の不具合を見つけたエージェントは、自分で直さず報告してくるようになります。

落ち葉はギアには一枚も無く、全部 vegetation 担当の資産です。ルート先を明示します:
src/world/veg/momiji.js の fallenLeafGeom()（252行〜）
対応する欠陥は3点あります: (a) 形状バリエーションが3パッチしかない (b) addCard は
厚みゼロの平板で縁の反り返りが無い (c) 配置が y + 0.012 + rng()*0.01 で1〜2cm浮いている

これはギア担当の報告です。ファイル・行番号・欠陥の内訳まで特定した上で、手を出さずに差し戻してきました。 所有権を明示した効果がここに出ています。

共有する仕様を先に凍結する

もう1つ、着手前に決めたものがあります。

• ctx という共有オブジェクトの構造（時刻・太陽・風・地形の問い合わせ関数など）
• キャンプサイトのレイアウト座標（焚火台は原点、テントは(-2.6, -1.4)、タープは(1.2, 1.6)…）
• マテリアル名46種（fabric.tc.tan, metal.steel.blackened, wood.log.split …）

マテリアル名を先に決めたのが効きました。ギア担当は ctx.assets.mat.get('metal.steel.blackened') と書くだけでよく、マテリアル担当の完成を待たずに作業できます（未実装ならマゼンタが返る規約）。

依存関係のある領域を、待ち時間なしで並列化するための仕掛けです。

人間が見る前に、機械が同じ条件で撮る

品質を見るために、20種類の固定カメラを用意しました。

node tools/shoot.mjs            # 全ショットを撮影 → shots/latest/
node tools/shoot.mjs hero tent  # 指定ショットだけ

各ショットはカメラ位置・注視点・画角・時刻・天候まで固定です。Playwright で実GPU描画し、PNGと一緒に fps とコンソールエラーを _report.json に落とします。

これで毎回まったく同じ条件の絵が得られます。差分が追えるようになる。

そしてこのハーネスが、後述する「実装したのに画面に届いていない」を発見する土台になりました。

夜の焚火。炎は黒体放射から色を出しており、光源も兼ねている

品質判定はブラインドで別のAIにやらせる

冒頭に書いたとおり、「本物と並べて比較」は実行できませんでした。代わりにこうしています。

1. 20枚のスクリーンショットを撮る
2. ファイル名をシャッフルして img_01.png 〜 img_20.png にリネーム（どのショットか分からなくする）
3. 別のAIエージェント3体に、出所を伏せて渡す
4. 各画像を「実写写真 / AAA製品版のスクショ / 習作レベルのリアルタイムCG」の3択で分類させる
5. 「習作」判定が残る限り、担当に差し戻す

批評役には一発失格項目も渡しました。「単色ベタ面がある」「物が浮いている」「テクスチャの繰り返しが見える」「同一オブジェクトのコピーが目視できる」など12項目。1つでも該当すれば無条件でC判定です。

3体には別々の視点を与えました。純粋な鑑定人、AAAスタジオのアートディレクター、風景写真家兼CG鑑定人。同じ票を3つ集めるのではなく、違う失敗モードを捕まえるためです。

そしてもう1つ、独立した軸で聞いています。

この場所はどこの国か。植生・地形・道具・空気感から判断し、根拠を挙げよ。

これが後に、いちばん面白い結果を返してきます。

見つかったバグは、ほぼ全部「書いたのに動いていない」だった

3ラウンドの批評と差し戻しを回すなかで、13件以上の不具合を潰しました。

最終的に気づいたのは、そのほぼ全部が同じ性質だったということです。

純粋な「実装漏れ」は1件もありませんでした。 コードは書かれている。ビルドも通る。エラーも出ない。それなのに画面に届いていない。

分類するとこうなります。気になるものだけ拾って読んでください。

型1: 書かれたが実行されていない

確率的タイリングが3ラウンドまるごと死んでいた

批評AIは3ラウンド連続で「テクスチャの繰り返しが見える」と指摘しました。担当は毎回「実装した」「強度を上げた」と報告する。それでも直らない。

4ラウンド目の担当が、コンパイル後のGLSLを回収して原因を突き止めます。

const orig = WebGL2RenderingContext.prototype.shaderSource;
WebGL2RenderingContext.prototype.shaderSource = function (sh, src) {
  if (src.includes('cStoch')) {
    console.log('呼び出し回数:', (src.match(/cStoch\(/g) || []).length);
  }
  return orig.call(this, sh, src);
};

結果は定義1件、呼び出し0件。関数は存在するのに、一度も呼ばれていませんでした。

原因は onBeforeCompile の仕様です。

// ✗ 動かない。展開後の文字列は存在しないので置換が成立せず、静かに no-op する
shader.fragmentShader = shader.fragmentShader
  .replace('texture2D( map, vMapUv )', 'cStoch( map, vMapUv )');

// ✓ チャンク本体を ShaderChunk から取り出し、#include ごと置換する
const body = THREE.ShaderChunk.map_fragment
  .replace('texture2D( map, vMapUv )', 'cStoch( map, vMapUv )');
shader.fragmentShader = shader.fragmentShader
  .replace('#include <map_fragment>', body);

onBeforeCompile が渡してくる shader.fragmentShader は #include が展開されていません。展開後の文字列を置換しようとしても、当然マッチしない。そしてエラーは出ません。

高さフォグが未 import だった

src/world/sky/fog.js に高度依存フォグが実装済み。しかし weather.js からも他のどこからも import されていませんでした。完全な死にコードです。

同じことが表面処理シェーダ tex/shader.js にも起きていました。

個体差の引数が渡されていなかった

批評AIの「同一メッシュのコピーが目視できる」という指摘への対応で発覚。

植生には杉5種・モミジ4種・ススキ6種のアーキタイプが実装済みでした。ところが呼び出し側が arch 引数を一度も渡しておらず、全変種が同一アーキタイプのシード違いになっていた。

個体差を作る仕組みは最初からあったのに、使われていませんでした。

型2: 実行されたが数値が無意味

こちらのほうが厄介です。コードは動いている。呼び出しも確認できる。それでも効果がゼロに近い。

hex-tiling のセルが大きすぎた

確率的タイリングが動き出したあとも、繰り返しは消えませんでした。

1つのセルの中に同じタイルが3〜4回入るので、原理的に何も隠せていませんでした。「動いていない」のではなく「動いているが無意味」です。

露岩が永久に出ない閾値

地形シェーダが傾斜を slope = 1 - wn.y で計算し、slope > 0.30 で露岩を出していました。

閾値0.30は約45°に相当します。つまり背後の30°斜面には露岩が永久に出ない設定でした。批評AIが繰り返し指摘していた「斜面が単色ベタ」の一因です。

sin θ で判定し直して解決しました。

「±20%の変調」が実効±0.3%

遠景の質感として「post-aerial ±20%の解析的変調」が実装されていました。計測するとこうです。

同じ節のマクロ色ムラも、nz4 が4オクターブの加重平均で分散が1/6に潰れており、実効±4%でした。

型3: 実装は正しいが量・位置が違う

ケトルが浮いていたのは、高さではなく位置

4ショットで「ケトルが浮いている」と指摘されました。担当は「高さを合わせた」と報告する。それでも浮いて見える。

実際は位置でした。ケトルは焼き網の中心から約3cm外にはみ出しており、底面の3割が空中にあった。網の線材が下に無いので、支えなく浮いて見えていました。

ガイラインの垂れが7.2%だった

カテナリー曲線での垂れは実装済みでした。担当が画像をピクセル走査して実測したところ、

実装は正しいが、見えない量だった。

薪の年輪が同じなのは、形状ではなくUV

「薪が全部同じに見える」は形状の問題だと思われていました。実際は断面形状が6種類あり、個体ごとのランダム変形もかかっていた。

原因は木口のUVが全個体・全端面で「中心(0.5, 0.5)／半径R×2.6／無回転」に固定されていたことでした。年輪は同心円で焼かれた1枚のディスク画像です。全員が同じ場所を見ていれば、当然同じ模様になります。

型4: 別領域が原因

症状の出た場所と、原因の場所が違うパターン。最も時間を食いました。

テントの縦縞を、4人が順に誤診した

AOパスは半解像度なのに、深度はフル解像度・NEARESTで読んでいました。半解像度ピクセルの中心 (i+0.5)/W½ は、フル解像度ではテクセルのちょうど境界に落ちます。どちら側が返るかは浮動小数の丸め次第。

中心タップと隣接タップが別々の側にスナップした列では法線が25〜30°倒れ、画面上の太陽方向に垂直な等間隔の黒い縞になる。

決め手は深度フェッチを半テクセルずらすと縞が消えることでした。

間違った推定も、領域を1つずつ潰したという意味では全て前進でした。

「影が真っ黒」の真因は、ハイライト側だった

「影が物理的にありえない黒だ」という指摘に対し、担当はまず実測しました。

晴天屋外の物理レンジ（1:5〜1:10）の中です。黒潰れ率も 0.00%。影は正常でした。

真因はハイライト側です。トーンマップに入る直前の値を測ると、日向が中間グレー(0.18)以下でした。

日向が中間グレーなら影は必然的に2段下に落ち、トーンカーブの寝ている領域に嵌まってベタになります。ダイナミックレンジの破綻は、シャドウ側ではなくハイライト側が丸ごと欠けていた。 露出を +0.43EV 上げて解決しました。

型5: 構造的に不可能

遠景の木は、光源に追従できない設計だった

「遠景の樹木が真っ黒」という指摘が3ラウンド続きました。

48m以遠の杉はインポスター（板）に切り替わり、そのマテリアルが MeshBasicMaterial — 完全に無照明でした。色は次の式だけで決まります。

uTint = sunColor * 0.30 + skyColor * 0.28

sunIntensity の項がありません。法線もありません。影も受けません。

つまり遠景の樹冠は光源の強さに追従できない一定の板で、日向と日陰の分離が構造的に出せない。夜は skyColor が小さいので、必然的に真っ黒に潰れます。

パラメータ調整では直せません。MeshLambertMaterial に変え、カードのUVから疑似法線を作り、近景と同じライトで照らすよう作り直しました。

炎が10倍暗かった

温度モデルが炎の大部分を 950〜1150K に落としていました。その温度では黒体放射がほぼ黒です。

uGain = 9.0 という不自然な値は、その死んだ温度モデルを補償するためのものでした。正しい放射輝度に直したら 1.15 で足りています。

5つの型を通して見えたこと

13件以上の不具合のうち、「実装を忘れていた」ものは1件もありませんでした。

書いてある。動いている。ビルドも通る。エラーも出ない。それでも画面に届いていない。

並列でAIエージェントを走らせるとき、本当に壊れるのは実装の質ではなく、実装と結果の接続です。そしてこの断絶は、コードを読んでも見つかりません。画面を見て、数値を測るしかない。

渓流。水面は流れ・屈折・対岸の反射・白波を持つ

判定は3ラウンド、1枚も動かなかった

ブラインド批評を3ラウンド回しました。結果はこうです。

3回とも、全20枚が「習作」。1枚も動きませんでした。

その間に、実際には多くのものが直っています。

指摘の中身は毎回まったく入れ替わりました。それでも分類は一度も動かなかった。

なぜ動かなかったか

3ラウンド目に、批評3体が挙げた上位3件を見て判断しました。

1. 同一インスタンスのコピーが目視できる
2. 最大面積（布・地面・斜面）の情報量不足
3. 光が世界と干渉していない

これらはシェーダのパラメータ問題ではありません。AAAは数千点の手作業アセット、実際のクロスシミュレーション、フォトグラメトリ素材でここを解決しています。手続き生成とコード内ジオメトリで埋められる差ではない。

構造的な差だと判断して、C→B を狙うのはそこで打ち切りました。以降は「実在する具体的な欠陥だけを潰す」に切り替えています。

ただし、撮影地は3回とも当てられた

判定とは独立に、こう聞いていました。

この場所はどこの国か。根拠を挙げよ。

3ラウンドとも、3体全員が「日本」と答えました。 しかも根拠が具体的です。

• イロハモミジ — 掌状に5〜7裂、鋸歯が細かい。北米のシュガーメープルより裂片が細く深い
• ススキ — 穂が片側に偏って垂れる。パンパスグラスとは穂の付き方が違う
• スギ・ヒノキの人工林 — 幹が細く直立、下枝が落ちて枝下高が高い、ほぼ等間隔。天然林ではこうならない
• 玉石の礫河原 — 勾配が急で流路の短い日本の河川が作る地形
• 角型の焚火台 — 直火禁止のキャンプ場文化に最適化された道具。欧米のファイヤーリング文化には存在しない
• ロースタイル — 低いテーブルとチェア

1体はこう補足しています。

日本を再現しようとしたCGであって実在地点の記録ではない。人工物・区画・看板・車・
他のサイト・地面の踏圧が一つも写っていない。

そしてもう1体が、いちばん的確な皮肉を書いてきました。

幹が細く真っ直ぐで下枝が無くほぼ等間隔 — 日本の戦後造林されたスギ・ヒノキ人工林の
特徴そのもの。（皮肉なことに、CGの「コピーの等間隔」という欠点が、結果的に
日本の人工林らしさになっている）

同じ性質が、片方の軸では欠点で、もう片方では正解の根拠になっている。

批評AIは、知覚は正確だが原因の帰属は当てにならない

3ラウンドを通してはっきりしたことがあります。

批評AIが「おかしい」と指摘した箇所は、ほぼ全て実際におかしかった。 しかしその原因の説明は、当てになりませんでした。

だから毎ラウンド、担当エージェントへの指示にこう書くようになりました。

仮説を信じず、実験で確かめること。 このプロジェクトでは、報告された症状の
真の原因が当初の仮説と違ったケースが10件以上ある。

症状の報告は信じる。原因の説明は疑う。 これが3ラウンドで得た運用ルールでした。

モミジ。葉は全方向を向き、逆光で透ける

公開してみたら、どこも新参者を通さなかった

作ったので公開しました。ここからは、あまり書かれない話です。

X — フォロワーが少ないと露出しない

まず自分のアカウントで告知しました。動画付き、スレッドで技術的な話も添えて。

ほぼ反応がありませんでした。

理由ははっきりしています。フォロワーが少ないうえ、X は外部リンク付きの投稿の露出を落とすからです。X は「既にフォロワーがいる人の増幅装置」であって、発見の場ではありません。

Reddit — カルマが足りず投稿できない

r/proceduralgeneration は、この作品と最も相性が良いはずの場所でした。「素材ファイルゼロ、全部コード生成」はまさにあのサブの中心的な価値観です。

しかしカルマ（信用スコア）が足りず投稿できませんでした。以前ためようとして断念しています。母国語でないコミュニティで、宣伝のためだけにコメントを重ねる作業は、率直に言って苦行です。

Hacker News — 新規アカウントは Show HN を出せない

Show HN はカルマ不要で submit できるので、ここが本命でした。実際に投稿を試みると、こう返ってきます。

We're temporarily restricting Show HNs because of a massive influx, mostly by
users who aren't yet familiar with the site or its culture.

新規アカウント制限。 内容を見て断られたのではなく、そもそも見られていません。

itch.io — 唯一、何の障壁もなかった

唯一、何の障壁もなく通りました。 アカウントを作り、zip をアップロードし、公開。それだけです。

ここで1つ罠がありました。itch は HTML ゲームを html-classic.itch.zone/html/XXXXX/ のようなサブディレクトリ配下で配信します。通常のビルドは /assets/... という絶対パスを吐くので、そのまま上げると全アセットが404になり、真っ黒な画面になります。

--base=./ でビルドし直し、深いサブパスから配信して実際に遊べることを確認してから上げました。

そして、最初の反応は itch から来た

公開の数時間後、コメントが付きました。

Plattelukaas: The game looks beautifull!

技術的な指摘ではありません。ただの感想です。それでもこれは意味がありました。

AI批評3体が3ラウンドとも「習作」と判定した絵に対して、実際に遊んだ人は「綺麗だ」と言った。

批評の基準（AAA製品版と並べたときどう見えるか）と、プレイヤーの基準（そのゲームとして気持ちよく見えるか）は、別物なのだと分かります。

お礼を返すとき、質問を1つ添えました。動作は滑らかだったか、と。感想を情報に変えたかったからです。

返ってきたのはこうでした。

Plattelukaas: What no models that's cool would you like to share your game
in my discord server with other devs?

「モデルが無いのか、それはすごい。自分のDiscordサーバーで他の開発者にも共有しないか」

X・Reddit・HN で連続して閉じられていた「人が既にいる場所」への扉が、先方から開きました。

ここから分かること

トラフィックのある場所は、例外なく新規参入者を制限します。 スパム対策として当然ですが、「良いものを作れば見てもらえる」わけではない、という現実がここにあります。

そしてもう1つ。会話の流れを見ると、反応が動いたのは見た目を褒められたときではなく、「素材が1つも無い」と伝えた瞬間でした。

訴求の軸は、絵ではなく制作手法だった。自分が何を作ったかより、何をしなかったかのほうが伝わることがある。

まとめ

3日間、11体のAIエージェントを並列で走らせて、ブラウザで動くゲームを1本作りました。

得られた知見のうち、他のプロジェクトでも使えるものを4つ挙げます。

1. ファイル所有権を契約書で固定する

並列化の前提です。誰がどのファイルを触ってよいかを文書で決め、全エージェントに読ませる。これが無いと同じファイルを書き換え合って壊します。

副次的な効果もありました。担当外の不具合を見つけたエージェントが、自分で直さずファイルと行番号を特定して差し戻してくるようになります。結果として、原因の切り分けが分業されました。

2. 完了基準を「実装した」ではなく「画面で見えることを数値で確認した」にする

これが最大の教訓です。

見つかった不具合13件以上のうち、純粋な実装漏れは1件もありませんでした。 全部「書いたのに画面に届いていない」型です。書いてある、動いている、ビルドも通る、エラーも出ない。それでも効いていない。

コードレビューでは見つかりません。画面を見て、数値を測るしかない。

3. 症状の報告は信じ、原因の説明は疑う

批評AIが「おかしい」と指摘した箇所は、ほぼ全て実際におかしかった。しかし原因の説明は当てになりませんでした（「DoFがY座標依存」「影が物理的にありえない黒」— どちらも実測で否定）。

人間である私自身の推定も外れています。テントの縦縞は4人が順に誤診し、4人目でようやく真因（半解像度AOのテクセル境界スナップ）に到達しました。

だから各エージェントへの指示に、毎回こう書くようになりました。「仮説を信じず、実験で確かめること」。

そして間違った推定も無駄ではありません。領域を1つずつ潰したという意味では、全て前進でした。

4. 人間が見る前に、機械が同じ条件で撮る

20種の固定カメラ（位置・注視点・画角・時刻・天候まで固定）で毎回撮影し、fpsとコンソールエラーも一緒に記録する。

これで差分が追えるようになります。そして「実装したのに画面に届いていない」を発見できたのは、この土台があったからでした。

結局、どこまで行けたのか

AI批評3体のブラインド判定は、3ラウンドとも「習作」のままでした。AAAには届いていません。最初の指示にあった「全員が心底驚くまで」は達成できていないというのが正直なところです。

一方で、撮影地は3回とも「日本」と正答されました。モミジの裂片の形、ススキの穂、スギ人工林の枝下高、直火禁止文化に合わせた角型の焚火台。作りたかったものは伝わっていた。

そして公開後、実際に遊んだ人からは「綺麗だ」という言葉が返ってきました。

批評の基準と、遊ぶ人の基準は違います。どちらが正しいという話ではなく、測っているものが違うというだけです。両方を見られたのは、この作り方をしたおかげでした。

遊べます（PCのブラウザのみ）。
https://keikoku-camp.vercel.app
https://yohsuke-zw.itch.io/keikoku-camp