はじめに

生成AI（CursorやGitHub Copilot、Claudeなど）の普及により、エンジニア・非エンジニアを問わず、アプリケーションや自動化ツールを驚異的なスピードで開発できる時代になりました。ノリと勢いでコードを書き進める「バイブコーディング」は、アイデアを最速で形にする手段として圧倒的な価値を持っています。

一方で、開発スピードが加速した結果、次のような課題に直面する現場も増えています。

把握しきれない「野良アプリ」の乱立
テストやレビューによる品質担保が追いつかないコードの生成
仕様を言語化・説明できる人が誰もいなくなるリスク

この構図は、かつてExcel VBA（マクロ）が現場主導で爆発的に普及し、その後に「ブラックボックス化」が問題となった時代（エンドユーザーコンピューティング：EUCの全盛期）と非常によく似ています。

本記事では、バイブコーディングが持つ「爆速で形にする力」を最大限に活かしつつ、かつてのVBA乱立のような技術的負債にしないために、私たちは過去の歴史から何を学び、どうシステムや仕組みで受け止めるべきかを考察します。

それぞれの状況を整理する

Excel VBA 乱立が起きた背景

2000年代から2010年代にかけて、多くの日本企業で「Excel マクロ（VBA）」が業務ツールとして広く使われました。正式なシステム開発の予算やリードタイムに間に合わない現場が、自分たちの PC 上でツールを作る。これを EUC（エンドユーザーコンピューティング） と呼びます。

現場にとって Excel は身近な道具でした。表計算の画面のまま、ボタン一つで集計や帳票出力ができる。IT 部門の承認を待たずに、困りごとをその日のうちに解消できる。こうした「即効性」が、マクロファイルの増殖を後押ししました。

しかし、数年経つと次のような状態に陥りがちでした。

「営業管理表（最新）」「営業管理表（修正版_田中）」のようにファイルが乱立する
数千行に及ぶ VBA を書いた担当者だけが触れる
その担当者が異動・退職すると、業務が止まる
経営判断に使う数値の根拠が、誰にも説明できない

結果として、情シスや SIer に「マクロの解析とシステム化」を依頼する案件が増えました。解析だけで数百万円規模、本格移行では数千万円規模になることも珍しくありません。

バイブコーディングが広がっている背景

バイブコーディングとは、生成AIに自然言語で指示を出し、出てきたコードをそのまま動かしながら形にしていく開発スタイルです。Cursor や GitHub Copilot、Claude などのツールが普及し、非エンジニアでも Web アプリや社内ツールを数日で立ち上げられる事例が増えています。

VBA 時代と同じく、動機は「正式な開発プロセスを待てない」ことです。ベンチャーでは特に、少人数で MVP を急ぎ、検証を先に回したい圧力が強い。AI はその圧力に応える最速の手段になり得ます。

ただし、生成されたコードには次のリスクがつきまといます。

書いた本人がロジックを説明できない
テスト・レビュー・権限設計が省略される
API キーや DB 接続情報がそのままコードに埋め込まれる可能性
クラウドに公開された瞬間から、社外からアクセス可能になる

はじめは「社内の小さな便利ツール」だったものが、気づけば顧客データを扱う本番サービスになっている。VBA 時代の「野良 Excel」が、今度は「野良 SaaS」として増えていく可能性があります。

共通点

VBA 乱立とバイブコーディングには、構造として次の共通点があります。

観点	Excel VBA 乱立	バイブコーディング
起点	現場の即時解決	現場の即時解決
作成者	非エンジニアを含む	非エンジニアを含む
資産の所在	個人 PC・共有フォルダ	GitHub・Vercel・個人アカウント
属人化	作成者しか触れない	プロンプトと設計意図が残っていない
品質管理	テスト・レビューが省略されがち	テスト・レビューが省略されがち
最終局面	SIer や情シスに解析を依頼	情シスや外部エンジニアに引き継ぎ依頼
ドメインの正しさ	計算根拠・業務ルールを説明できない	仕様・受入条件なしで AI が実装した

1. シャドウ IT（影のシステム）として増殖する

どちらも、IT 部門の管理外で生まれる シャドウ IT です。現場の生産性は一時的に上がりますが、組織全体の一覧表には載りません。「何があるか分からない」状態が、監査・セキュリティ・事業継続のリスクになります。

2. 「動いている」と「正しい」が別問題になる

マクロも AI 生成コードも、見た目は動きます。しかし、入力チェック・例外処理・権限・監査ログが欠けたまま運用されると、壊れ方が分からない 状態になります。VBA 時代に「検算できない集計マクロ」が問題になったのと同じ構図です。

3. 技術的負債の返済コストが後から跳ねる

小さく始めたツールほど、放置された際の改修コストが膨らみます。SMBC 日興証券の事例では、Excel マクロで属人化していた業務をローコード開発基盤へ移管し、ブラックボックス化の解消とリスク管理の強化を図っています（TechTarget ジャパンの報道）。「後から直す」選択は、必ずしも安くはありません。

4. 個人の注意力に依存する運用は限界がある

「作る人が気をつければ大丈夫」という運用は、人数と時間が増えるほど破綻します。VBA 時代も「マクロ禁止の社内ルール」を敷いた企業はありましたが、現場の反発や形骸化で効果が薄れる例も多かった。仕組みで縛らない限り、同じ問題は繰り返されます。

5. ビジネスドメインの正しさを証明できない

技術的に「動く」ことと、業務ルールとして正しい ことは別です。VBA 乱立でもバイブコーディングでも、後から問題になるのは後者のほうが多いと私は感じています。

VBA 時代の典型例は、歩合計算・経費按分・締め日処理のような ドメイン固有の計算 です。セル参照と If 文が何百行も重なったマクロは、作成者に「なぜこの式なのか」と聞いても答えが曖昧なことがありました。監査や経理から「この数字の根拠は？」と問われても、コードを読み返すだけでは説明に耐えない。結果として、検算用の別 Excel を用意して「出力が一致すれば正しい」と運用していた、という話も聞きます。

バイブコーディングでも構図は同じです。「月末締めで未払いを集計して」「消費税は内税で計算して」といったプロンプトから、AI がビジネスロジックを生成します。しかし、プロンプトに書かれていない例外（返品、値引き、端数処理）は AI の推測に委ねられがちです。作成者がドメインを深く理解していなければ、仕様書も受入テストもなく 本番に載せることになります。

どちらも共通しているのは、「誰が、どの業務ルールに基づいて、正しいと判断したのか」という証跡が残らない 点です。コードレビューがあっても、ドメインの正しさまでは担保できません。経営判断やコンプライアンスに関わる処理ほど、この欠落は致命的になります。

相違点

似ている一方で、バイブコーディングには VBA 時代にはなかった特性もあります。

観点	Excel VBA 乱立	バイブコーディング
作成速度	数日〜数週間	数時間〜数日
公開範囲	基本は社内 PC・ファイル共有	クラウド公開が容易
技術スタック	Excel + VBA に集中	言語・FW・DB がバラバラ
コードの出所	人が書いた（ただし理解は浅いことも）	AI が生成（人の理解がより薄いことも）
バージョン管理	ファイル名の「最新」「修正版」	Git を使えば履歴は残せる（使わないことも多い）
セキュリティ	マクロ有効化・ファイル持ち出し	API キー漏洩・公開 URL・DB 直結

速度が「試作」と「本番」の境界を溶かす

VBA でも「いつの間にか業務の本体になっていた」事例はありました。しかし AI 時代は、その速度が一段上がっています。プロトタイプと本番の間に「棚卸し・レビュー・移行判断」の時間を挟む余裕が、組織側に残りにくい。これが最大の相違点だと私は考えています。

外部公開リスクが最初からついて回る

Excel マクロは、原則として社内ファイルの範囲で完結しやすかった。一方、Next.js や Supabase を AI に生成させて Vercel にデプロイすれば、設定ミス一つでインターネット上に公開されます。セキュリティの問題は「社内の Excel ファイル」から「全世界に見えるサービス」へとスケールし得ます。

AI は「解析コスト」を下げるが、問題を消すわけではない

近年は、生成 AI を使って VBA コードから仕様を復元する手法も現実的なコストになってきました。解析は楽になる一方、なぜその設計になったか や 本番運用に耐えるか の判断は、依然として人間の責務です。ツールが進化しても、ガバナンスの必要性自体は消えません。

当時の企業が取った対策

VBA 乱立への対策は、大きく 3 つのアプローチに整理できます
参考：自動化ドットコムの整理

アプローチ A：ガバナンスで縛る（組織・運用ルール）

IT 部門がルールを定め、現場の作成・改修を制御する方法です。

マクロ付き Excel の棚卸し（ファイル名・作成者・利用頻度・重要度）
新規マクロ作成の原則禁止、例外は承認フロー
編集権限の限定、共有フォルダの統制
処理概要書・改修履歴・エラー対応手順の必須化
マクロ有効化ポリシー、デジタル署名の検討

効果：コストを抑えつつ、増殖の速度を落とせる

限界：現場の反発、ルールの形骸化、「禁止されたからこそ個人 PC に置く」という逆効果

アプローチ B：既存 VBA を改善する（活 Excel）

全部捨てず、Excel 上で品質を上げる方法です。

コードのモジュール分割、コメント・命名規則の統一
共通ライブラリ化、バージョン管理（Git 等）の導入
Office Scripts や Power Automate への段階的移行
生成 AI による VBA 解析と仕様書の復元

効果：既存資産を活かしつつ、属人化を緩和できる

限界：Excel の構造上の限界（同時編集、権限、監査）は残る

アプローチ C：別システムへ移行する（脱 Excel）

根本解決として、Web システム・SaaS・ローコード基盤へ移す方法です。

重要業務から優先的に Web 化（権限管理・変更履歴・同時利用）
既存マクロと並行運用し、数値の一致を検証してから切り替え
SIer や内製チームによる本開発、ローコード（OutSystems 等）の活用
移行後は「Excel マクロ新規作成禁止」を徹底

効果：属人化・ファイル乱立・セキュリティリスクを構造的に解消しやすい

限界：費用と期間が大きい。移行先ツール自体が新たな属人化の温床になるリスクもある

多くの企業は、A で増殖を止め、B または C で重要度の高いものから順に手を入れました。いきなり全部をシステム化するのではなく、棚卸し → 優先順位 → 並行運用 → 切り替え という段階的な進め方が、失敗例の報告からも繰り返し語られています。

バイブコーディング時代に活かせる教訓

VBA 時代の対策を、そのまま AI 開発に写像すると、次のようになります。

VBA 時代の対策	バイブコーディングへの写像
マクロの棚卸し	社内ツール・個人アカウント上のデプロイ一覧の把握
新規マクロ禁止	「AI 生成コードの本番直デプロイ禁止」ルール
処理概要書の必須化	README・ADR・操作手順の必須化
活 Excel（Git 管理）	Git + PR レビュー + CI の最低ライン
脱 Excel（Web 化）	情シス管轄の正式環境への移管
SIer への解析依頼	外部レビュー・セキュリティ診断の計画

仕組みで縛る：個人の善意に頼らない

「AI を使う人がセキュリティに気をつけて」では足りません。次のような 仕組み が有効です。

本番デプロイ権限を IT 部門または限定ロールに集約する
シークレットは環境変数管理し、コードへの直書きを CI で検知する
顧客データを扱うツールは、最初から正式なリポジトリとレビュー経路を通す
「プロトタイプ用」と「本番用」のインフラを分離する

小さく作ることと、管理下に置くことは両立できる

ベンチャーで MVP を急ぐ必要は理解できます。ただし、最初から管理不能な場所に置く のと、後から移せる形で置く のでは、数年後のコストがまったく違います。Git 管理・環境分離・最低限のREADMEだけでも整理しておくだけで、数年後の負担が変わってきます。

アンチパターン

「とりあえず AI に作らせて、動いたから本番」

動作確認と本番運用は別物です。権限設計、バックアップ、障害時の連絡先がなければ、それはまだ試作品です。

「禁止すれば解決する」だけのガバナンス

VBA 時代と同様、禁止だけでは現場のニーズは消えません。代替手段（正式な内製窓口、ローコード、短期開発枠）がなければ、シャドウ IT は地下化するだけです。

「後でエンジニアが直せばいい」という前提

引き継ぎコストは、作った本人がいるうちに記録しないほど跳ね上がります。AI 生成コードほど、意図の記録 が欠落しやすい。後回しにした説明責任は、必ず請求書として返ってきます。

生成AIは「守り」にも使える

ここまで、生成AIがシャドウITの増殖を加速させうる側面を書いてきました。ただし、同じ技術は 問題の解決 にも使えます。VBA 時代に高コストだった保守活動の一部は、すでに自動化されつつあります。

保守活動	VBA 時代	生成AI時代
仕様の復元	作成者へのヒアリング、手作業の読解	コードから処理概要・入出力仕様を生成
コード解析	SIer への解析委託（数百万円規模も）	数千行の VBA や生成コードの構造整理
テストケース作成	担当者の記憶と手入力に依存	仕様・コードから観点とケースのたたき台を生成
移行判断	全件手作業の棚卸し	重要度・リスクの分類支援

例えば、属人化した VBA マクロを解析する際、「何をしているコードか」を AI に整理させ、人間がドメイン知識をもとに検証する、という進め方は現実的なコストになってきています。

バイブコーディングで生まれたコードに対しても、同様です。README や ADR のたたき台、テスト観点の列挙、セキュリティ上の懸念箇所の洗い出し——記録と検証の土台作り は AI が担えます。

ただし、ここで重要なのは役割分担です。

AI が担える：コードの読解、文書化、テストケースの たたき台 生成
人間が担う：業務ルールとして正しいかの 最終判断、本番公開の承認

「ビジネスドメインの正しさ」は、AI が仕様書を書いても自動では証明されません。
生成AIは 説明不能を説明可能に近づける 道具であり、ガバナンスそのものの代わり にはなりません。

問題を生む側と、問題を整理する側、生成AIは両方に立てます。歴史を繰り返さないために必要なのは、AI で速く作ることと、AI で速く 整える ことの両方を、仕組みの中に組み込むことだと私は考えています。

まとめ

Excel VBA の乱立とバイブコーディングは、どちらも「現場の即効性」と「組織の統制」の間で起きる同型の問題です。野良アプリ、品質未担保、属人化、把握不能——これらは新しい現象ではなく、EUC 時代から繰り返されてきたパターンです。

決定的な違いは、作成速度の速さ と クラウド公開によるリスクの広がり です。だからこそ、VBA 時代より早い段階で「棚卸し・ルール・移行先」を決める必要があります。

当時の企業が学んだことは、禁止だけでは足りない、全部一度に捨てる必要もない、重要なものから段階的に正式な仕組みへ移す、という点に集約されます。AI は開発を速くしますが、責任の所在 を消してはくれません。

私は、バイブコーディングを否定しているわけではありません。道具としては強力です。ただし、VBA 乱立が企業を苦しめたのと同じ条件——管理外の資産増殖、説明不能なロジック、後から高い改修コスト——が、より短い周期で再現されうる、と考えています。

生成AIによって、現場主導でシステムを作る力は過去になく強くなりました。
だからこそ重要なのは、「作れるか」ではなく「作ったものをどう管理するか」です。
VBA 時代に起きた問題は、形を変えながら AI 時代にも現れています。
歴史は繰り返し得ますが、私たちは過去の失敗から学ぶこともできます。
作る速度だけでなく、整える速度も高めること。
それが AI 時代のガバナンスの一つの形ではないでしょうか。

参考リンク