AIを使えば、個人開発でもかなり複雑なアプリを作れるようになりました。
私も現在、約1,000人の住民が仕事をしたり、結婚したり、子どもを作ったり、犯罪を起こしたりする社会シミュレータ「統治者X」を開発しています。
Claude CodeやCodexのようなAIコーディングツールを使えば、実装速度そのものはかなり速いです。
「税金を追加して」
「住宅市場を作って」
「人手不足なら賃金を上げて」
「住民ごとに幸福度を計算して」
こんな指示でも、かなりのところまでコードを書いてくれます。
ところが、ここで大きな問題が出ました。
動くことと、正しいことは全く別でした。
別のAIにモデル全体を監査させてみたところ、叩けば叩くほどバグが出てきました。
今回の記事は、AIを使った個人開発、とくにシミュレーションやゲームを作る人向けに、「バイブコーディングで何に気を付けるべきか」を実際の失敗例からまとめます。
テストが通っているのに、モデルは壊れていた
開発中のシミュレータには自動テストを大量に用意しています。
記事執筆時点では278件のテストがあり、最終的にはすべて合格しています。
普通なら、
「テストが全部通った。ヨシ！」
となりそうです。
しかし、社会シミュレータではそれだけでは足りませんでした。
コードとして正常に動いていても、
「その処理、本当に意味として正しいの？」
という問題が残るからです。
たとえば、こんなバグが見つかりました。
- お金を払ったのに、実際にはサービス提供者が存在しない
- 医療や公共サービスが、働いている人がいなくても提供される
- 建設中に家の持ち主が死亡すると、完成後も死者が住宅を所有する
- 株主が存在しない企業から配当だけが消える
- 公務員と民間企業の社員を同時にやっている人物が発生する
- 誰も使わない空き家まで「修繕需要」として数えてしまう
- 財政が最初から構造的な赤字なのに、それを人口減少の影響だと誤解しかねない
どれもプログラム自体は停止しません。
むしろ普通に数字を出し続けます。
これが一番怖いところです。
国庫から21.75消えた原因を追ったら、とんでもない人物がいた
特に面白かったのが、国庫の数字が約21.75だけ合わない問題です。
台帳上の支出額と、実際の国庫残高を比較すると、どうしても差が出る。
そこで該当月の国庫の増減をすべて時系列で記録して調査しました。
すると、ある一人の人物にたどり着きました。
その人物は元々民間企業で働いていましたが、育児中に政権交代が発生し、警察官として再登用されました。
その後、育児期間が終わったため元の民間企業へ復帰。
ところが警察官としての役割だけが残っていました。
結果、
民間企業の給与を受け取りながら、公務員給与も受け取る人物
が誕生していました。
しかも公務員給与の「予算計算」と「実際の支払い」で対象者の判定方法が違っていたため、国庫の台帳だけが約21.75ずれるという状態になっていました。
コードとしては全部正常です。
でも社会としては明らかにおかしい。
これがシミュレーション開発の怖さです。
「人口が減った」は本当に社会問題なのか？
社会シミュレータを作っていると、つい結果を分析したくなります。
「出生率が低い」
「人口が減った」
「人手不足になった」
「財政破綻した」
数字が出ると、それっぽい考察ができます。
しかし内部モデルが壊れている状態で考察しても意味がありません。
実際、私のシミュレータでは建設業の人手不足が発生しました。
最初は、
「危険な仕事だから人が来ないのか」
「社会的地位が低いからか」
「高収入にしても駄目なのか」
などと考えていました。
ところが調べてみると、そもそも誰も使わない空き家まで全部修理しようとしていたことが分かりました。
その結果、必要な建設作業員が異常に多く計算されていたのです。
修繕需要を、
「本当に住んでいる」
「貸して収益になる」
「買い手や借り手がいる」
「修繕費を払える」
という経済的な需要に限定すると、必要人数は大幅に減りました。
つまり、
「建設業の深刻な人手不足」
だと思っていたものの一部は、
需要の定義ミス
でした。
こういう状態で「現代社会では建設業の人気がない」と結論づけていたら、完全にモデルに騙されています。
財政破綻も、実は税制が未完成だった
政府財政についても同じでした。
初期のモデルでは、国債がかなり早い段階で上限に到達していました。
福祉が削られ、生活が苦しくなり、死亡者も増える。
一見すると、
「高福祉社会の限界を再現できた」
ようにも見えます。
しかし税制を棚卸ししてみると、かなり事情が違いました。
実装されていたのは主に、
所得税
配当課税
相続税
です。
一方で、
法人税
消費税
社会保険料
固定資産税
住民税
家賃収入への課税
キャピタルゲイン課税
などは存在していませんでした。
それなのに、公務員、医療、教育、警察、福祉、公共調達などはかなり大きな政府として動いていました。
つまり、
歳出だけ現代国家っぽいのに、税制はほぼ所得税一本
という状態です。
これでは赤字になって当然です。
社会の問題というより、デフォルト設定の問題でした。
バイブコーディングの問題は「コードを書けること」
AIコーディングそのものが悪いわけではありません。
むしろ非常に便利です。
私自身、AIがなければこの規模のシミュレータを個人で作ろうとは思わなかったでしょう。
問題は、AIがかなり自然なコードを書いてしまうことです。
コードを読むと、それっぽい。
テストも通る。
画面も動く。
数字も出る。
そのため、
「完成したように見える」
のです。
ここで仕様全体を理解せず、
「次は犯罪組織を追加しよう」
「次は外交だ」
「次は株式市場だ」
と機能を追加していくと、内部の矛盾がどんどん見えなくなります。
これがいわゆるバイブコーディングの危険なところだと思います。
AIでシミュレーションを作るなら最初に確認したいこと
今回の経験から、少なくとも次の項目はかなり早い段階で監査した方がいいと感じました。
お金は保存されているか。
誰かが払った金額と、誰かが受け取った金額は一致しているか。国庫、企業、家計、海外をまたいで突然お金が消えたり増えたりしていないか。
物やサービスは本当に存在するか。
介護士が0人なのに介護サービスが提供される、建設作業員がいないのに家が修理される、といったことがないか。
人物の状態は矛盾していないか。
死亡しているのに家を所有している、公務員と民間企業社員を同時にやっている、結婚状態と配偶者データが一致しない、といった矛盾がないか。
需要は本物か。
欲しい人がいないのに需要として数えていないか。支払能力のない需要を、有効な市場需要として扱っていないか。
意思決定と結果が同じ尺度になっているか。
仕事を選ぶときには「高収入で幸福になる」と評価しているのに、実際の幸福度計算では収入がほとんど評価されない、といった食い違いがないか。
処理順序で結果が変わっていないか。
月初の職業情報を使う処理と、月途中で転職した後の情報を使う処理が混在していないか。
隠れた救済措置がないか。
人が足りないから自動的に補充する、食料不足だから勝手に供給する、人口が減ったから出生率を上げる、といった補正が入っていないか。
このあたりを確認して初めて、
「この結果はシミュレーションの結果です」
と言えるようになります。
「テスト278件合格」と「モデルが正しい」は別
今回かなり痛感したのがこれです。
自動テストは非常に重要です。
ただしテストは、
「自分が想定した仕様通り動いているか」
を確認するものです。
その仕様そのものがおかしければ、テストは普通に合格します。
たとえば、
「医療予算が100なら医療サービス100」
という仕様を書けば、そのテストは通せます。
でも医師が0人なら、
「誰が医療サービスを提供したの？」
という別の問題が出てきます。
これは単体テストだけでは見つけにくい問題です。
そこで必要になるのが、
モデル全体の意味の監査
です。
AIに「バグを探して」だけでは足りない
今回、別のAIに監査させるときも、単に、
「バグを探してください」
では十分ではありませんでした。
むしろ、
「金銭は保存されているか」
「サービス提供者は存在するか」
「所有権は正しいか」
「需要と供給は本当に接続しているか」
「人物の判断と結果は一致しているか」
「同じ原因を二重に評価していないか」
「更新順序で矛盾していないか」
といった観点を指定した方が、はるかに有効でした。
AI開発では、コードを書くAIとは別に、
壊す側のAI
を用意した方がいいかもしれません。
作るAIはどうしても「仕様を実現する」方向へ進みます。
監査側には、
「この仕様そのものがおかしくないか」
を疑わせる必要があります。
バイブコーディングはダメ、絶対……ではない
タイトルではかなり強めに書きましたが、実際にはバイブコーディングをやめるつもりはありません。
便利だからです。
個人開発でこれだけのモデルを作れるのもAIのおかげです。
ただし、
AIに作らせて、動いたから完成
は危険です。
特に、
シミュレーション
金融
会計
ゲーム内経済
統計モデル
AIエージェント
のように、内部状態が複雑に連鎖するものは注意した方がいいでしょう。
外側の画面は後から直せます。
UIもグラフも新聞表示も作り直せます。
しかし内部モデルが壊れていると、その上に作ったものすべてが怪しくなります。
今は新機能を増やすより、
「この世界は本当に内部で筋が通っているのか」
を一つずつ確認しています。
社会シミュレータを作っていたはずが、最近やっていることは会計監査と内部統制です。
たぶん、これが正しい順番なのでしょう。
AIコーディングで複雑なシステムを作るときの最低チェック
結果の原因を説明できるか
「なぜこの数字になったのか」を追跡できないなら、モデルがブラックボックス化している可能性があります。入力と出力に矛盾がないか
入れたデータと、最終的に出てくる結果の関係が説明できるか。途中で値が消えたり、勝手に増えたりしていないか。二重計上されていないか
同じ売上、給与、イベント、状態変化などを、別の処理で重複して数えていないか。処理漏れがないか
支払いはしたのに受取側に反映されない、状態を変更したのに関連データが更新されない、といった片側だけの処理がないか。状態同士が矛盾していないか
同じ対象が同時に成立しない状態を持っていないか。削除済み・死亡済み・無効化済みの対象が、別の処理では生きていないか。意図した仕様と、実装された仕様が一致しているか
「こう作ったつもり」と、実際にコードがやっていることが同じか。AIが勝手に補完した仕様や、古い仕様が残っていないか。同じ概念を複数の場所で別々に計算していないか
同じ値を複数箇所で再計算すると、条件が少しずつずれてバグの原因になります。更新する順番で結果が変わらないか
古い状態を参照する処理と、新しい状態を参照する処理が混在していないか。境界条件で壊れないか
0人、0円、最大値、最低値、対象者なし、所有者なし、途中で削除、保存・復元などで矛盾が出ないか。テストしているのは「コード」だけになっていないか
テストが通っていても、仕様そのものがおかしければ正しい結果にはなりません。
AIコーディングで一番怖いのは、エラーで止まることではありません。
間違った仕様のまま、もっともらしい結果を出し続けることです。
コメント