データベース on 或る阿呆の記

【バイブコーディング】AIがデータを捏造していた

Sun, 18 Oct 2026 00:00:00 +0900

最近こんなのばっかりですが、以前AIに機能を捏造されていた記事を書きましたが、今回はデータの捏造です。しかも完全にデタラメの値ではなく、取り込んだ値を使って何か勝手なロジックにより勝手な値を算出するというもので、それによってパッと見の傾向がなんとなく正しそうに見えて、気づくのに遅れました。コイツほんとにそれらしさを作る天才だな。

よくもぼくをォ！！だましたなァ！！

対象アプリケーションは、私がダイエット日誌のために作り始めたHealth Dashboardという自作Webアプリです。体重などは私が元々つけていたスプレッドシートを読み込ませ、また手動による入力をしていました。これは問題ありませんでした。

問題が生じたのは、Fitbitのデータを、APIとGoogleからのエクスポートしたCSVで過去分のデータを取り込もうとした時です。特に歩数および睡眠時間のデータを取り込もうと考えました。これは指示するとなんとなくそれらしいものが出来たように見えました。

嘘でした。確認できただけで、以下のような複数の問題がありました。

睡眠スコアを勝手に独自のアルゴリズムで捏造する
睡眠時間の解釈が独特
時計をしなかった時などのデータゼロを勝手な値で補完する
データ取り込み経路のみ、JSTとUTCで混ざっている（API経由のときは問題ない）

これらはけっこう厄介で、パッと見はけっこうそれっぽいんです。睡眠スコアは一応睡眠時間にもとづきます。睡眠時間の解釈は独特ですが一貫しているため傾向はあっています。ゼロデータの時はレアだしいつ歯抜けがあるべきかなんて覚えちゃいませんので、そこをそれらしく補完されているとどうにもなりません。また過去の値はCSV取り込みだが最新値はAPIなど経路が異なっており、かつCSV取り込みのみで起きる不具合（フォーマッタの不具合）についても、これも最新値はそれっぽいので騙されやすい。

やめて…森の中に木を隠すのやめて…

破綻に気づいたのは直近の睡眠スコアの捏造というホームラン級のファウルがあったからですね。直近の値はさすがに確認するでしょう。で、明らかに数値が異なるので、これは気づきました。そしてその原因調査の過程で、過去データなども直接参照・比較するなどして、芋づる式におかしさに気づいた、という感じです。こっちが指摘するまでAI言わないこと多いですよ本当に。でも全然言わないわけでもないんです。だから余計に気づきづらい。木を隠すなら森の中メソッドやめろ。

ついでに調べている中で、データベース設計自体が正規化されていないクソ設計であることも発覚しました。これも「なんで正規化されてないのか」と言って「おっしゃるとおりです！正規化しますか？」と返され確かな殺意を感じました。

この部分の直接的な原因は、元々の体重入力データと、あとからきたFitbit経由の歩数・睡眠時間データの考え方をあわせる調整が必要だったから、という感じでしたかね。実際、再設計にあたって固定カラムにするかEAVにするか…ということはちょっと考えさせられました。まぁAIの「固定カラムのテーブルいっぱい作ってアプリケーションでなんか適当に帳尻あわせってそれっぽくするぞ💪」は許されませんが…設計悩むところは聞いてくれ…。

実はちょっと大丈夫かなぁと思ってはいたんですけどね。以前DB設計は見るべきとか言ってましたがめんどくさくなってた🥺

こんな感じでパンドラの箱でも開けたのかというほど悍ましい何かが次々と飛び出てきたので、対応はだいぶ時間がかかりました。内部設計の抜本的な変更、さらにその確認、その適用に、3日くらいわけでやったと思います。疲れました。仕事かよ。まぁ仕事だったら許されんエラーなのですが…。

そんな過去は嘘である

しかし思ったことは、恐らく仕事でも同じことになっている現場、けっこうあるんじゃないですかね。特にエンジニアのいない、少ない現場だと本当にありそう。しかもこれ、時限爆弾ですからね。

このAIによるデータ捏造問題はけっこう深刻ですよ。ロジックは修正できますが、データの修正は必ずしもできません。たとえばデータにする過程で、計算した結果を正規データとして保存し計算元を破棄するようなものだと、あとで嘘だったとわかったときにもはや再現不可能です。

理想的にはデータの入力元はすべて残せ！となりますが膨大なデータになる可能性もあり、その負荷は必ずしも現実的ではありませんし、場合によっては物理的に不可能です。またデータの取得プログラムレベルで混入されていたら終わりです。とはいえ、可能な限り入力ソースは可能な限り信頼できるところからの一次データを残すべきでしょう。

しかしそうした対応をしたところで、何をどうしても、間違えたデータにもとづいて決断されたアクションを巻き戻すことはできません。時間ばかりは不可逆です。自分一人なら罪も自分一人で引き受ければいいですけれど、これが他人を巻き込んだものだと、どうにもなりませんやね。

真面目な話、データを取り込む系の機能をAIに書かせたやつ、一度ちゃんと見たほうがいいと思いました。特に仕様改修を重ねているものなんかは、前の仕様に引きずられる可能性が高くなるので、要注意ですね。

一応軽く対応をまとめますと、チェックポイントは以下ですかね。

入力ソースはどこからどう取得したか。どこで保存されるか
直近のデータと過去のデータでそれぞれ、1単位でズレがないか
欠損や異常値が再現するか
入力経路が複数ある場合それぞれ実行し、再現性と同一性はあるか
（エンジニアは）DB設計の適切さ
（エンジニアは）システムの入力と出力を完全に、処理を定性的に説明できるか

まぁ基本といえばそうなんですが、これの実行は言うは易しでめんどくさいですよ本当に。結局最後は手間をどれだけかけるかなんだなぁ……。

<関連記事>

あわせて読みたい

バイブコーディングでジェンガが崩壊したらどうするのか？

バイブコーディングでDB不整合が生じる

Fri, 18 Sep 2026 00:00:00 +0900

バイブコーディングで破綻したらどうなるかなぁという記事を先日書いたばかりなのですが、なんか自分用アプリで早速破綻？しました。

データベース不整合

まぁ破綻というほどではないのですが、データベースで仕様上あってはならない不整合が生じた形ですね。具体的には、10の要素のうち1つのみenabledでほかはdisabledになる仕様のものがありましたが、最近追加した機能の利用により、意図せずして複数のenabledが生じる状態になりました。

そもそものデータベース設計に問題があるような気はしつつ、とりあえず修正し、そのうえでそもそもコードの行数が大きすぎないだろうか、とAIに聞いたところ例によって「まったくそのとおりです。リファクタリングが必要です」などと供述し…。

まぁこんな状態でした。

oh…。1000行以上が複数、最大で3000行近くのものもあり、といったところですね。さらに聞いてみるともっとも肥大化したdb.tsは15のドメインが単一ファイルに含まれているとのことで、どうしてこんなになるまで放っておいたんだみたいな状態でした。

ということで大規模なリファクタリング計画が実施されます。その計画自体はAIにさせましたが、十回以上に分割して、都度挙動を確認しながらやることになりました。修正自体はAIがやったとはいえ、確認はありますし、またけっこうな時間かかりましたね。

そもそも設計がおかしい

リファクタリングをした後に、そもそも論としてデータベース設計がおかしいよなぁということで、見直しました。状態は10のレコードがあって、それぞれstatusとしてenabled/disabledのboolをもち、1つだけenabledになる、という奇妙なものでした。この排他制御はアプリケーション側でやらざるを得ず、データベース上は不整合が生じうる状態です。

なのでこれは設計を変更し、一つのレコードのIDをactiveとして指定するようにしました。これによって、データベース上も不整合は生じなくなります。

最初からそうしとけばいいじゃないかという話なんですが、これもまた歴史的経緯によります。このアプリケーションは大昔自分がCLIで手作りしていたものがベースになっており、当時データはJSONファイルを扱うだけの簡易的なもので、IDの概念もリレーショナルの概念もありませんでした。

で、AIのおかげでGUIにできるし、DBもSQLiteにしたほうがいいぞなということで、いつだったか移行したんですけれど、その時に従前の仕様もかなり引きずられることになりました。正直この設計はよろしくない、とは思っていたのですけれど、なんか動いているんでまぁいいかと放置していました。

で、バグが生まれたってわけ。

それが僕には面倒くさかったから

まぁ、マイグレーションの時点で以前の設計はとりあえず残しておくのはいいと思うんですよ。まぁでも、おかしいよなと思った時点でさっさと手を付けるべきではありました。ただ設計変更ってどうしても考えてプロンプト打たないといけないので、結局面倒くさいんですよね…で、その結果もっと面倒くさいことになるといういつものあれ。

なので、バイブコーディングでDB不整合が生じたというより、人間がサボったので不整合が生じたというほうがいいのかもしれないんですが、しかし、移行などに伴って、以前の設計が現在適切ではないにも関わらず残ってしまう、はAIプログラミング時代において、気付ける人が限られるという点でけっこう深刻なんじゃないでしょうか、と強引にまとめて終わり。

<関連記事>

あわせて読みたい

バイブコーディングでジェンガが崩壊したらどうするのか？

/vibecoding-jenga/

あわせて読みたい

ワクチンは4回までらしい

/2022-11-21-22-vaccine/