AIに読ませて、書かせない——監査で41件出たけれど、その報告にも嘘が混じっていた
このサイトには、公開していない開発メモが73ファイル・約20,000行あります（2026年9月2日時点）。ゲームごとの仕様、規約、過去にやらかした記録。書いた時点では正しいのですが、コードのほうが先に進むので、放っておくと静かに嘘になります。
全部を自分で読み直すのは無理でした。1ファイル1体ずつAIを当てて、並列で読ませることにしました。
書かせないから、並列にできる
この監査役に渡してある道具は、読む・中身を探す・名前で探す・シェルを叩くの4つだけです。ファイルを編集する道具は渡していません（シェルは通るので、最後のところは約束ごとです）。
最初は「見つけたその場で直させたほうが早いのでは」と思っていました。まずいのは、並列で走っているぶん同じファイルに同時に手が入ることです。壊れます。それに、担当が違えば同じ数字を別の根拠で直そうとする。片方が「34種」に、もう片方が「43種」に書き換えて、あとから見た私にはどちらが後勝ちしたのか分かりません。
報告だけ集めて、全部読んでから直す順番を自分で決める。この形に落ち着きました。副産物として、直す価値のないものを捨てる判断も自分の手元に残ります。
1回の監査で41件
返ってきたものは、想像より重い内容でした。
カード報酬プール 34種と書いてあった → 実測30種（34は初期専用込みの数） カードずかん 全34枚 → 実測43枚 キャリア称号 10種 → 17種 カード画像 .png と書いてあった → 実体は .webp のみ 遊び方ページ 「noindex・単独ページ」→ とっくに公開済み
3ファイルぶんで41件です。ほとんどは私が数え直しをサボった結果で、読んでいて情けなくなりました。
ただ、この中の1つは、ドキュメントを直すだけでは終わりませんでした。カード画像の .png / .webp は、43枚とも本番で実際に404になっていました。実体はとっくに .webp なのに、メモもコードも .png のままだった。つまり同じ間違いが2箇所に住んでいて、片方は本番を壊していました。この件は別に書きましたが、机上のズレを洗うつもりで走らせたものが、本番の壊れを引き当てたわけです。
その報告にも、嘘が混じっていた
ある監査役が、CSSに付けるキャッシュ用のクエリについてこう書いてきました。「git log -S 'style.css?v=' -- games/yonjubyo/index.html を実行したが該当が0件。この記述は最初から存在しなかった」。もっともらしい。実際に自分で同じコマンドを打ったら、2件ヒットしました。最初のコミットから存在していて、途中のコミットで全部消していたんです。
結論そのもの（いま付いていないのが正しい）は合っていました。合っていたぶん、危うい。根拠だけが空想で、そのまま信じていたら「昔からそうだった」という間違った歴史をドキュメントに書き足していたところでした。
ここから決めたのは1つです。結論ではなく根拠を見る。それも、こちらが再実行できる形で出させる。実行したコマンド、ファイル名、行番号。この3つが揃っていない主張は、いったん保留にします。数が多くて全部は追えないので、少なくとも「直す前に1回自分の手で打つ」だけは守るようにしました。
私も同じ嘘をつく
公平を期すために書いておくと、これはAIに限った話ではありませんでした。ゲームのソースを開いた人向けに、ファイルの先頭へ短いコメントを入れる作業をしていたときのことです。「みんなでわたる。」の冒頭に、群衆の実装について説明を書きました。1体ずつ座標を持たせている、画像は使わず図形で描いている、と。書きながら「たしかそうだったはず」という感触だけがありました。
念のため開いたら、群衆は let crowd = 1; というただの数値でした。座標なんて持っていません。画像の描画呼び出しは14箇所ありました。全部逆です。しかもこれ、公開されるファイルに入れる文章です。危ないところでした！
この経験から、公開ページに出る文章は出す前に実装で裏を取ることにしています。数え上げ（作品数・記事数・種類数）と、書いた当時から仕様が変わっていないか。制作ノートを書き溜めて後から出す運用なので、寝かせているあいだにコードが動くんです。
消す前に、中身を見る
もう1つ、ブランチの掃除をしていたときの話です。マージ済みに見える古いブランチが3本ありました。名前も日付も、もう用済みに見える。まとめて消そうとして、念のため main との差分を取りました。2本に、mainへ入っていない作業が残っていました。片方は2,800字ほど書き進めた記事、もう片方はBGMの試聴ツール一式。どちらも自分で書いたのに、すっかり忘れていました。
結局、消したのは1本だけです。残り2本は中身を回収してからにしました。判断としては、こう言い換えられます。戻せない操作の前だけは、必ず自分の目で中身を見る。
いまの落としどころ
整理すると、こうなりました。
- 並列にするのは「同じ観点 × 多数の対象」のときだけ。1ファイル1体、1ゲーム1体。ひとつの機能をみんなで直させるのは、たぶん向いていません
- 並列で走るものには書き込みを渡さない。集めてから、直す順は自分で決める
- 結論より根拠。コマンド・ファイル名・行番号が無い主張は保留
- 同じ説明を2回したら、手順として書き出す。3回目は書いたものを読ませる
- 消す・強制的に上書きする系は、そもそも禁止しておく
言葉にすると、新人と仕事をするときに気をつけることとあまり変わりません。違うのは、こちらは10人同時に来ることと、疲れないぶん自信の強さが一定なことでしょうか。堂々と間違ったことを言うので、口調では見分けがつきません。
それでも、41件はどれも本当のズレで、全部直しました。別の監査で作り話を1件つかまされたからといって、この41件を捨てるのは、さすがにもったいないです。