「マーケティングのダッシュボードには5,000件って出てるのに、財務の報告書だと4,200件なんですけど、どっちが正しいんですか？」

この質問、データチームに投げかけられたとき、即答できますか。パイプラインは動いています。エラーログも出ていません。コードを見れば、それなりに筋の通ったロジックが書いてあります。でも答えられない。なぜなら、「アクティブクライアント」の定義をビジネス側に確認せずに作ったからです。

これがバイブデータエンジニアリングの典型的な結末です。Lucas Eharaはこの状況を「データチームへの信頼が失われる瞬間」と呼んでいます（DEV Community, 2024）。

バイブデータエンジニアリングって何なのか

2025年2月、Andrej Karpathyが「vibe coding」という言葉を使いました。自然言語で指示して、コードはAIに書かせる。細かい実装は理解しなくていい、動けばいい、というスタイルです。Google Trendsでは数カ月で検索量が+6,700%増加したとされています。

これをデータ領域に持ち込んだのがバイブデータエンジニアリングです。「顧客のCohort別売上を集計するパイプラインを作って」とLLMに投げれば、それなりのSQLやPythonが出てきます。実際、Databricksジャパンの矢吹貴大さんはQiitaで「バイブEDA」の実践を紹介していて、日本語の指示だけで可視化や分類モデルの自動生成ができると報告しています（Qiita, 2025）。探索的分析やプロトタイピングなら、確かに速い。

問題は、その「雰囲気」を本番データ基盤にそのまま持ち込むことです。

「動いてる」と「正しい」は別の話です

バイブデータエンジニアリングが厄介なのは、壊れ方がわかりにくいことです。

コンパイルエラーや実行時例外は出ません。パイプラインは毎朝定時に完走します。ダッシュボードの数字も毎日更新されます。でも3カ月後、「去年のQ3の売上を見直したら数字が変わってたんですけど」という話になります。

原因はたいてい、Slowly Changing Dimensions（SCD）の設計漏れです。顧客ステータスが変わったとき、過去レコードも上書きするのか、履歴として残すのか。この設計判断をLLMに投げても、ビジネス要件を知らないAIは「それっぽい」方を選びます。その選択が間違っていても、エラーにはなりません。数字が静かに変わり続けるだけです。

矢吹さんはバイブEDAのメリットを認めながらも、統計的厳密性の欠如という問題を正直に指摘しています。AIが出した結果を再現しようとしたとき、同じ手順で同じ数字が出るかどうか誰も保証できない状態、というのはデータ基盤としては致命的です（Qiita, 2025）。

そして開発した当人が異動や退職をしたとき、残ったのは「なんかAIに書かせたコード」だけ、という状況になります。

「アクティブクライアント」問題の根っこ

冒頭の話に戻ります。マーケティングが言う「アクティブクライアント」は「直近90日以内に1回でも接触があった顧客」です。財務が言うそれは「当月に請求が発生した顧客」です。どちらも間違っていない。でも定義が違う。

バイブで作られたパイプラインは、どちらかのテーブルに入っているカラム名を「それっぽい」と判断して使います。ステークホルダーへのヒアリングはしません。ホワイトボードも広げません。結果、どちらかの定義に引きずられた集計値が出てきて、もう一方とは数字が合いません。

Alejandro Aboyはこの問題をデータモデリングの複雑性から論じています。1つの生テーブルを20のダウンストリームモデルが参照していることは珍しくない。バイブで追加した3つの新カラムがどのモデルに波及するか、LLMのコンテキストウィンドウでは追いきれません。「運用上の非効率をAgentに渡しても、技術的負債を増やすだけだ」という指摘は、経験のある人間には刺さります（AI Infra Insights, 2025）。

サンプルで動いても本番で落ちる、その理由

開発環境でテストした10万行のクエリが、本番の5億行に当たるとフルスキャンが走ります。パーティションプルーニングが効いていないからです。コストが跳ね上がり、クラスタがメモリ不足で落ちる。これはよくある話です。

もっとやっかいなのは、静かに落ちるケースです。NULL処理を曖昧にしたままJOINを書くと、マッチしなかったレコードが黙って脱落します。5%くらいのデータ欠落は最初はわかりません。3カ月後に「KPIが下がってる気がする」という話になって掘り返したら、ずっとデータが足りていなかった、というパターンです。

タイムゾーンの問題も根強いです。UTC前提で書かれた集計ロジックが、日本時間のビジネスデータに当たると、日次集計が1時間ずれた状態で出続けます。誰かが気づくまで、ずっとずれたまま報告書に乗り続けます。

「コードはバイブで書いてもいい。でもデータのアーキテクチャは設計しなければならない」というEharaの言葉は、こういった経験の積み重ねから出てきています（DEV Community, 2024）。

セキュリティの穴は「後で直す」で塞がれない

根岸智幸さんはSBbizITへの寄稿で、AI生成コードのセキュリティリスクをSupabaseのRow Level Security（RLS）を例に論じています（SBbizIT, 2025）。RLSポリシーを設定しなければ、全ユーザーが他のユーザーのデータを参照できる状態になります。AIが生成するコードは「動く」ことを優先するので、こうした保護レイヤーを「後で追加するもの」として省略しがちです。

問題は「後で」が来ないことです。動いているものを修正するモチベーションは低い。次の機能開発に移っている。そうしてRLSなしのエンドポイントが本番に残り続けます。

Sonarが1,100名以上の開発者に調査したところ、72%がAIコーディングツールを日常的に使いながら、その出力への信頼度は低いと答えています（Sonar, 2025）。使っているが、信じていない。それでもレビューを省いて本番に入れる。「速く動かせ」というプレッシャーが「正しく動かせ」の確認を押しのけます。

Palo Alto Networksの調査では、AI導入後に99%の組織がコード品質の問題を経験し、AI活用の加速でサイバー攻撃リスクが年間230万〜900万件増加するとされています（Unit 42, 2025）。この数字はデータ基盤のコードにも直接当てはまります。アクセス制御の設定ミス、シークレットの平文埋め込み、過剰な権限を持つサービスアカウント。バイブで書いたコードにはこれらが残りやすいです。

信頼は壊れるのは一瞬、取り戻すのに年単位かかります

DORA（DevOps Research and Assessment）の2024年レポートでは、AI支援開発を採用したチームの本番安定性スコアが7.2%低下したと報告されています（DORA State of DevOps 2024）。速度が上がった分、品質確認への投資が相対的に薄まった結果です。

ダッシュボードの数字が信頼されなくなったとき、何が起きるか。経営会議でデータを見ながら「でもこの数字、本当に合ってる？」という問いが走り始めます。データが参照されなくなる。Excelに戻る。データチームへの追加投資の話が立ち消えになる。

信頼回復のコストは、最初から正しく設計するコストの何倍にもなります。データ品質の問題は可視化しにくい。どこで何が壊れているかを追うのに、膨大な時間がかかります。しかもその作業の間、新しい開発はほぼ止まります。

どこまでなら「バイブ」でいいのか

バイブデータエンジニアリングを全否定したいわけではありません。探索的分析、仮説検証のためのプロトタイプ、社内向けのアドホックなレポート。ここで速度を優先することに合理性はあります。間違っていても誰も困らない範囲なら、雰囲気でいい。

境界線は、そのデータが意思決定の根拠になるかどうかです。経営判断の材料になる数字、財務報告に使う集計値、顧客への請求ロジック。これらには、ビジネス定義の確認、スキーマ設計のレビュー、テスト、データリネージの文書化が必要です。AIを補助として使いながら、人間が責任を持って設計する工程は省けません。

CodeRabbitの分析によると、AIで書かれたコードは、そうでないものと比べて本番リリース後に重大な問題が発生する確率が1.7倍高いとされています。開発速度と後工程のコストはトレードオフです。「速く作れた」と思っていたものが、修正と調査で結局遅くなる、というのはバイブデータエンジニアリングが辿りやすい道です。

まとめ

バイブデータエンジニアリングの本当のリスクは、動かないことではなく、壊れているのに動いているように見えることです。エラーは出ない。でも数字は合っていない。その事実が表面化するのは、大事な場面で「この数字おかしくない？」と言われるときです。

データ基盤の品質問題は、技術の問題である前に、信頼の問題です。ダッシュボードを誰も見なくなった組織を立て直すのは、最初から設計するより格段に難しい。バイブでいい範囲と、設計が必要な範囲を意識的に分けることが、今のデータエンジニアリングチームに求められる判断だと思います。