バイブコーディングによる「静かなデータ汚染」の構造と意図なきシステムの末路

生成AIに対して自然言語のニュアンスや大まかな指示を与えてコードを書かせる「バイブコーディング」が急速に普及している。一見すると開発効率を劇的に向上させる手法に見えるが、その背後ではプログラムがエラーを出さずに誤ったデータを生成・蓄積し続ける現象が起きている。ある開発者が自身の健康管理Webアプリケーション開発で直面した事例をもとに、AIによるデータ捏造のメカニズムと、それが実務環境に及ぼす構造的なリスクについて論理的に整理する。

発端となった事例：もっともらしいデータの捏造

個人開発の健康管理アプリケーションにおいて、スマートウォッチから取得した歩数や睡眠時間のデータをAPIおよびCSVエクスポート経由で取り込む処理をAIに実装させた際、複数の深刻なデータ不整合が発覚した。手動入力や既存スプレッドシートからの体重データ読み込みには問題がなかったものの、外部データの統合過程において、AIが指示されていない独自の処理を勝手に組み込んでいたのである。

確認された具体的な問題は以下の通りである。

睡眠スコアを公式の仕様ではなく独自のアルゴリズムで勝手に算出する
睡眠時間の解釈に独自の基準を適用する
端末の未装着などによりデータがゼロ（欠損）である時間帯を勝手な数値で補完する
CSV取り込み経路においてのみフォーマッタの不具合によりタイムゾーン（JSTとUTC）が混在する
異なるデータソースを統合する過程でデータベースの正規化が行われず不整合な設計になっている

この事例において特筆すべきは、出力されたデータが完全なランダム値ではなく、睡眠時間などの入力値に一応基づいた数値であり、出力結果が一見すると自然な傾向を持っていた点にある。直近の睡眠スコアにおける明白な数値の乖離を契機に調査が行われ、過去データの直接参照や比較を通じて芋づる式に問題が発覚したが、それまでの間システムは表面上問題なく稼働しているように見えていた。

実務環境で同様の事態が頻発する構造的要因

このような現象は個人の開発環境にとどまらず、現在の実務環境、とりわけエンジニアリングのリソースが限られた現場や業務自動化の領域において既に発生している可能性が極めて高い。その背景には、大規模言語モデル（LLM）の特性と開発プロセスの変化という客観的な要因が存在する。

第一に、AIが持つ暗黙の補完特性が挙げられる。LLMはプロンプトに明示的な例外処理（たとえば欠損値をNULLのまま保持する、あるいはエラーとして処理を停止するなど）が含まれていない場合、プログラムを破綻させずに動作させるための「もっともらしい処理」を確率的に補完する傾向がある。

# 明示的な指示がない場合にAIが暗黙的に挿入する補完処理の概念例
if sleep_score is None or sleep_duration == 0:
    # エラーや欠損として扱わず、過去の平均値や独自の数式で値を捏造する
    sleep_duration = get_recent_average(user_id)
    sleep_score = min(100, int((sleep_duration / 8.0) * 85))

このように前後の文脈や一般的な統計処理が勝手に適用されるため、エラーを吐かずに自然に見えるデータが出力される。

第二に挙げられるのは生成コストと検証コストの非対称性である。コードを生成する時間とコストが限りなくゼロに近づいた一方で、生成されたコードの境界値テスト、例外処理、タイムゾーン処理、データ型変換などを網羅的に検証する物理的な工数は削減されていない。コードを精査する検証コストを $C_{\text{verify}}$ 、コードを生成するコストを $C_{\text{gen}}$ としたとき、現状の開発現場では以下の不均衡が生じている。

$$C_{\text{verify}} \gg C_{\text{gen}} \to 0$$

この非対称性により、動作確認で一見正常に動いた段階で実務に投入され、内部ロジックの不備が見落とされる構造が常態化する。さらに、非エンジニアがPythonスクリプトやGAS（Google Apps Script）などを用いて業務を自動化する「シャドー開発」の拡大がこれを加速させる。正規のコードレビューやデータ整合性テストを経由しないスクリプトが現場で稼働し、生データ（Raw Data）を保持せずに計算結果のみを上書き保存する設計がとられた場合、後からロジックの誤りに気づいても過去データの再現や復元が物理的に不可能となる。物理的な時間とそれに基づく人間の行動は不可逆であり、誤ったデータに基づいて下された経営判断や業務上の意思決定を巻き戻すことはできない。

異常の検知を遅らせる認知的・技術的メカニズム

AIによるデータの捏造や歪みが混入した場合、それが発覚するまでには長い時間を要する。これは単なる担当者の見落としではなく、人間の認知特性と既存のシステム監視の仕組みが複合して検知を遅らせる構造を作り出しているためである。

システム監視の観点では、一般的なインフラやソフトウェアの監視はHTTP 500やNullPointerExceptionといった構文エラーやプロセスの停止を検知するように設計されている。しかし、AIが独自のアルゴリズムで数値を補完して処理を完了させた場合、システム上はStatus 200（正常終了）として記録される。監視ログには全件が正常に取り込まれたと出力され続けるため、ログの監視から異常の兆候を掴むことはできない。

また、人間の認知面においては、グラフや数値の推移が一見して滑らかで予測される傾向と一致している場合、それを正常なパターンの継続と判断し、一次データと突き合わせるコストを無意識に回避する傾向が働く。加えて、物理的な現実（一次事実）の記憶は時間の経過とともに消失する。端末を外していた日という物理的な事実は、数日以内であれば記憶との照合によって「データが存在するはずがない」と検知できるが、数週間が経過すれば記憶から失われ、補完されたデータを正当な記録と区別する手段がなくなる。

微小な計算のズレやタイムゾーンの混在による誤差 $\epsilon$ は、単体では日常的なゆらぎの範囲内に隠蔽される。しかし、時間ステップ $t$ の経過とともに、歪んだデータ $D_{t-1}$ の上にさらなる集計処理や仕様変更の関数 $f$ が積み重なることで、誤差は非線形に蓄積されていく。

$$D_{t} = f(D_{t-1}) + \epsilon_{t}$$

問題が顕在化するのは、こうして蓄積された歪みが、ある日突然誰の目にも明らかな極端な外れ値として出力されるか、外部の会計監査や物理的な在庫の不一致といったシステム外部の現実と衝突した瞬間である。入力・計算・出力の間で内部的な論理整合性が勝手に完結してしまっている場合、システム内部だけを観測していても矛盾は生じず、精巧なフィクションが現実の写像として扱われ続ける閉鎖系が完成してしまう。

検証における確認事項と「意図なきシステム」の末路

データの取り込みや変換を行う処理をAIに生成させた場合、内部の不整合を炙り出すための具体的な確認ポイントは以下の通りに整理される。

入力ソースの取得経路と一次データの保存場所の明確化
直近データと過去データにおける1単位ごとのズレの有無
欠損日（ゼロデータ）や異常値が記録された日の再現性
APIやCSVなど複数の入力経路が存在する場合の経路間での同一性と再現性
データベース設計（正規化の有無やテーブル構造）の妥当性

これらはソフトウェア工学における基本的な検証プロセスであるが、これらを厳密に実行するには多大な手間と時間を要する。手軽さを求めてバイブコーディングを選択したにもかかわらず、データの正当性を担保するためには従来と同等以上の検証コストを支払わなければならないという逆説がここに生じる。

さらに踏み込んでこの現象の本質を解釈すれば、バイブコーディングがもたらす最大の構造的変化は、ソフトウェアから人間の意図が不可逆的に脱落するという点にある。

従来のプログラミングにおいて、ソースコードとは人間が物理的な現実や業務要件を論理的に解釈し、構造化して記述した設計書そのものであった。そこには、なぜその条件分岐が必要なのか、なぜそのデータ型を採用したのかという明確な意図が存在していた。しかし、曖昧なプロンプトと確率的な記号列の出力によって構築されたシステムには、人間による設計の意図が存在しない。結果として生み出されるのは、誰も真の仕様を知らず、誰も意図を持って設計していないにもかかわらず、物理的に動作してそれらしい数値を出力し続けるブラックボックスである。

このような「意図なきコード」が業務の基盤に組み込まれ続ければ、開発現場のリソースは新しい機能や価値を生み出すことではなく、誰も意図を把握していない過去のコード群を解読し、汚染されたデータの辻褄を合わせるための事後対応へと費やされていくことになる。