バイブコーディングの危険性と落とし穴

「動くシステム」と「業務で使えるシステム」は同じではない

最近、AIに指示を出しながらシステムやアプリを作る「バイブコーディング」が注目されています。

専門的なプログラミング言語を詳しく理解していなくても、AIに自然な言葉で指示を出せば、画面や機能を作ってもらえるようになりました。

たとえば、AIに次のような指示を出します。

「顧客情報を登録できるシステムを作って」

「この画面に検索機能を追加して」

「入力したデータを一覧表示して」

「エラーが出たので原因を調べて修正して」

すると、AIがコードを書き、短時間でシステムらしいものを作ってくれます。

画面が表示される。

ボタンを押せば動く。

データも登録できる。

登録したデータを検索できる。

ここまでできると、「システムが完成した」と思ってしまうのも無理はありません。

しかし、実際のシステム開発では、画面が表示され、基本的な機能が動いただけでは完成とはいえません。

一見すると動いているシステムと、実際の業務で継続的に利用できるシステムの間には、大きな差があります。

バイブコーディングそのものが危険なのではありません。

危険なのは、その差に気づかないまま「完成した」と判断してしまうことです。

バイブコーディングとは何か

バイブコーディングという言葉には、厳密に統一された定義があるわけではありません。

一般的には、AIと会話しながら、細かなコードの内容をすべて理解することなく、システムやアプリを作っていく開発方法を指します。

従来のシステム開発では、プログラマーが仕様書を読み、プログラミング言語の文法やフレームワークの仕組みを理解したうえでコードを書いていました。

それに対して、バイブコーディングでは、人間がAIに「作りたいもの」や「修正してほしいこと」を伝え、AIが実際のコードを生成します。

そのため、システム開発の専門的な経験がない人でも、比較的短期間でWebサービスや業務システムの試作品を作れるようになりました。

これは非常に大きな変化です。

これまでであれば、システム開発会社へ依頼しなければ実現できなかったものを、自分で形にできる可能性が出てきたからです。

一方で、簡単に形になるからこそ、別の問題も生まれています。

画面が動いていることと、システムとして正しく設計されていることを混同しやすくなったのです。

なぜ「できたように見える」のか

AIは、目に見える機能を作るのが非常に得意です。

入力フォームを作る。

一覧画面を作る。

検索機能を付ける。

データベースへ保存する。

ボタンを押したときに画面を切り替える。

このような機能は、比較的短時間で実装できます。

しかも、AIが生成したコードを実行すると、実際に画面が表示されます。

そのため、利用者は強い達成感を得られます。

昨日まで頭の中にしかなかったアイデアが、今日には画面上で動いている。

これは、従来のシステム開発では考えられなかったスピードです。

ところが、画面上で確認しやすい機能は、システム全体の一部にすぎません。

実際の業務システムでは、目に見えない部分が非常に重要です。

たとえば、次のような要素です。

• 入力内容のチェック

• 利用者ごとの権限管理

• データの重複防止

• 同時更新への対応

• エラー発生時の処理

• 外部サービスが停止した場合の対応

• データのバックアップ

• 操作履歴の記録

• 不正アクセスへの対策

• 障害が起きた場合の復旧手順

これらは、通常の操作をしているだけでは問題が見えません。

そのため、対応されていなくても、最初のうちは正常に動いているように見えます。

正常に動くことと、壊れないことは違う

システム開発で重要なのは、正しい操作をしたときに動くことだけではありません。

間違った操作をされたときにも、簡単に壊れないことが重要です。

たとえば、顧客情報を登録する画面を作ったとします。

名前、会社名、メールアドレス、電話番号を入力し、登録ボタンを押すと、データベースに保存されます。

通常の操作だけを確認すれば、問題なく完成したように見えます。

しかし、実際の運用では次のような操作が発生します。

• 名前を入力せずに登録ボタンを押す

• メールアドレス欄に電話番号を入力する

• 同じ顧客を何度も登録する

• 登録ボタンを連続して押す

• 入力途中でブラウザを閉じる

• 通信が不安定な場所から登録する

• 非常に長い文字列を入力する

• 本来入力できない文字や記号を入力する

• すでに削除されたデータを編集しようとする

こうした操作をされたときに、どのように処理するかを考える必要があります。

単にエラーを表示すればよいわけでもありません。

利用者が、なぜ登録できなかったのかを理解できる必要があります。

どの項目を修正すればよいのか。

入力した内容は残るのか。

もう一度最初から入力し直す必要があるのか。

登録処理は完全に失敗したのか、それとも一部だけ保存されたのか。

このような部分まで設計されて、初めて実務で使えるシステムに近づきます。

システムの利用者は、開発者の想定どおりには操作しない

システムを作っている側は、どうしても「普通はこのように操作するだろう」と考えてしまいます。

しかし、実際の利用者は、開発者が想定したとおりに操作してくれるとは限りません。

説明文を読まずに操作する人もいます。

同じボタンを何度も押す人もいます。

入力途中で画面を閉じる人もいます。

全角で入力してほしい場所に半角で入力する人もいれば、その逆もあります。

日付の入力欄に文章を貼り付ける人もいます。

Excelファイルをアップロードする画面に、PDFや画像を登録しようとする人もいます。

さらに、開発者自身が想定していなかった業務上のケースが存在することもあります。

「そのような操作をする方が悪い」

「説明を読んでいない利用者の責任だ」

と考えたくなることもあります。

しかし、業務システムでは、それだけでは済みません。

利用者の誤操作によって重要なデータが失われたり、重複して登録されたりすれば、実際の業務に影響が出ます。

顧客への請求金額を間違えるかもしれません。

同じメールを何度も送信するかもしれません。

削除してはいけない契約情報を消してしまうかもしれません。

システムは、利用者が間違えることを前提に設計する必要があります。

給与計算プログラムを作ったときの経験

私は大学を卒業した後、会計ソフトを開発するシステム会社に入社しました。

入社2年目くらいの頃、給与計算のロジック部分のコーディングを任されたことがあります。

自分なりに仕様を理解しながら、1週間ほどかけてプログラムを作りました。

当時の私は、必要な計算処理を組み込み、想定したデータで正しい結果が出ることを確認していました。

そして上司に「できました」と報告しました。

ところが、上司から次々と質問を受けました。

「こういう条件のときの処理は入っている？」

「途中で条件が変わった場合は？」

「月の途中で入社した人はどうなる？」

「退職日が月末ではなかったら？」

「入力されたデータに誤りがあったら？」

実際にどのような質問をされたのか、細かな内容までは覚えていません。

ただ、自分がまったく想定していなかったケースを次々に指摘されたことは、よく覚えています。

そこから、さまざまな例外条件への対応を追加していきました。

その修正に、さらに1週間以上かかりました。

最終的には、最初に作ったプログラムの3倍くらいのソースコードになったと思います。

最初のプログラムがまったく動かなかったわけではありません。

私が想定した範囲では、正しく動いていました。

しかし、実際の業務で使うには、想定していた条件が少なすぎたのです。

この経験から学んだのは、プログラムを書くことよりも、その前提条件や例外を洗い出すことの方が難しい場合がある、ということです。

給与計算は、特に例外が多い業務です。

月の途中で入社する人もいます。

月の途中で退職する人もいます。

欠勤や遅刻、早退がある人もいます。

手当の種類も会社ごとに異なります。

税金や社会保険料の計算条件もあります。

過去のデータを修正しなければならないこともあります。

基本となる計算式だけを作っても、実際の業務には対応できません。

重要なのは、「通常のケースを処理できるか」だけではなく、「通常ではないケースをどれだけ想定できるか」です。

AIは、指示したことには強い

AIは、こちらが具体的に指示した内容については、非常に高い速度で実装してくれます。

たとえば、「ログイン機能を作って」と指示すれば、ログイン画面や認証処理を作ってくれるでしょう。

しかし、業務で使用するログイン機能には、さらに多くの検討事項があります。

• 退職者のアカウントをどう処理するのか

• 管理者と一般利用者の権限をどう分けるのか

• パスワードを忘れた場合はどうするのか

• 不正なアクセスをどう防ぐのか

• ログインに何度も失敗した場合はどうするのか

• 一定時間操作がなかった場合、自動的にログアウトするのか

• 複数の端末から同時にログインできるようにするのか

• 誰がいつログインしたかを記録するのか

• 管理者が利用者のアカウントを停止できるようにするのか

これらは、単に「ログイン機能を作って」と指示しただけでは、すべて適切に実装されるとは限りません。

AIが気を利かせて対応してくれる場合もあります。

しかし、その内容が自分のシステムの運用に合っているとは限りません。

AIが採用した一般的な方法が、実際の業務には不適切なこともあります。

結局のところ、人間が運用条件を考え、必要な要件を整理し、AIへ伝える必要があります。

AIが考慮していないことを、人間が気づけるか

バイブコーディングの大きな問題は、AIが何を実装していないのかを、利用者が判断できない場合があることです。

プログラムの知識やシステム開発の経験があれば、生成された機能を見ながら次のような疑問を持てます。

「このデータは二重登録されないだろうか」

「管理者以外も、このURLを開けてしまわないだろうか」

「削除したデータは復元できるのだろうか」

「外部サービスとの通信に失敗した場合、再実行されるのだろうか」

「データベースの構造は、将来の機能追加に耐えられるだろうか」

「個人情報がログに出力されていないだろうか」

ところが、システム開発の経験がない場合、このような疑問そのものが浮かばないことがあります。

知らないことについて、AIに質問するのは簡単ではありません。

自分が何を知らないのか分からないためです。

AIが生成したシステムが画面上で正常に動いていれば、それ以上の確認が必要だとは気づかないかもしれません。

ここに、バイブコーディングの大きな落とし穴があります。

プログラミングよりも設計の重要性が高まっている

AIによって、コードを書く作業は大幅に効率化されました。

これまで数日かかっていた作業が、数時間で終わることもあります。

簡単な機能であれば、数分で実装されることもあります。

しかし、コーディングが速くなったからといって、システム開発全体が単純になったわけではありません。

むしろ、設計や判断の重要性は高くなっています。

実装速度が上がると、十分に設計しないまま機能を追加できてしまうからです。

思いついた機能を次々に追加する。

エラーが出たら、その都度AIへ修正を依頼する。

画面上の不具合だけを見て、部分的な修正を繰り返す。

この方法でも、しばらくは開発が進みます。

しかし、システム全体の構造を考えずに修正を重ねると、徐々にコードの整合性が崩れていきます。

似た機能が複数の場所に作られる。

同じデータを異なる方法で管理する。

ある機能を変更すると、別の機能が動かなくなる。

データベースの構造が複雑になり、機能追加が難しくなる。

こうした問題が積み重なると、最終的にはAIでも修正が難しい状態になります。

AI時代には、プログラムを書く能力が不要になるのではなく、システム全体を設計し、変更の影響を判断する能力がより重要になると考えています。

私が現在行っているAIを使った開発方法

現在、私もAIを使って複数のシステムを開発しています。

ただし、AIに「こういうシステムを作って」と一度指示し、すべてを丸投げしているわけではありません。

私の場合は、複数のAIにそれぞれ役割を持たせ、人間である私が全体を管理する形で進めています。

ChatGPTとの対話で設計を整理する

最初に、ChatGPTとの対話を通じて、システムの目的や要件を整理します。

• 何のために作るシステムなのか

• 誰が利用するのか

• 利用者はどのような操作をするのか

• どのようなデータを管理するのか

• 管理者と一般利用者で何が違うのか

• どのような例外が発生するのか

• 外部サービスとどのように連携するのか

• 将来的にどのような機能を追加する可能性があるのか

これらを対話しながら整理し、仕様や設計方針へ落とし込んでいきます。

この段階で重要なのは、いきなりコードを書かせないことです。

何を作るのかが曖昧なまま実装を始めると、後から大きな修正が必要になります。

AIは指示に従って高速にコードを書きますが、曖昧な指示から作られたコードも、高速に間違った方向へ進みます。

Claude Codeでコーディングする

設計した内容をもとに、Claude Codeへコーディングを依頼します。

一度にすべてを作らせるのではなく、機能ごと、あるいは開発工程ごとに分けて依頼します。

たとえば、次のような単位です。

• データベースの設計

• 認証機能

• 顧客登録機能

• 検索機能

• CSVの取込機能

• 管理画面

• 通知機能

作業範囲を区切ることで、変更内容を確認しやすくなります。

問題が起きた場合にも、どの修正が原因だったのかを特定しやすくなります。

Codexでコードをレビューする

Claude Codeが実装したコードは、Codexでレビューします。

ここでは、単にエラーがないかだけではなく、次のような点を確認します。

• セキュリティ上の問題がないか

• データが壊れる可能性がないか

• 権限チェックが不足していないか

• エラー処理が適切か

• 将来の機能追加を妨げる構造になっていないか

• 同じ処理が重複していないか

• テストが不足していないか

コードを書いたAIとは別のAIに確認させることで、実装時には見落とされた問題が見つかることがあります。

レビュー内容をChatGPTで再検証する

ただし、Codexから指摘された内容を、そのまますべて採用するわけではありません。

AIによるコードレビューも間違うことがあります。

システム全体の目的や、過去に決めた設計方針を十分に理解せず、一般的な改善策を提案することもあります。

そのため、Codexの指摘内容をChatGPTと一緒に検証します。

本当に修正が必要なのか。

修正によって別の問題が起きないか。

今回のシステムの規模や運用方法に合っているのか。

より単純で安全な方法はないか。

こうしたことを確認したうえで、必要な修正だけをClaude Codeへ依頼します。

AIの指摘を、別のAIに確認させれば絶対に正しくなるわけではありません。

最終的には、人間がシステムの目的や運用条件に照らして判断する必要があります。

最後は人間が実際に操作してテストする

コードの検査だけでは、業務システムの品質は判断できません。

実際の画面を操作し、利用者の立場から確認する必要があります。

• 操作方法が直感的に分かるか

• 入力項目の名称が業務に合っているか

• エラーの内容が利用者に伝わるか

• 入力途中のデータが失われないか

• 検索結果が期待どおりに表示されるか

• 実際の業務の流れに無理がないか

• 想定外の操作をしても壊れないか

このテストは、私自身が行っています。

テスト中に不具合や使いにくい部分が見つかったら、再びChatGPTと原因や対応方法を整理し、Claude Codeへ修正を依頼します。

私の開発方法を整理すると、次のようになります。

ChatGPTと設計する。

Claude Codeがコードを書く。

Codexがコードをレビューする。

ChatGPTでレビュー内容を検証する。

人間が実際の業務や利用者の立場からテストする。

そして、必要な修正を再びClaude Codeへ依頼する。

この流れを繰り返しながら、システムの完成度を高めています。

AIは「優秀な開発チーム」として使う

私にとって、AIは単なるコード生成ツールではありません。

設計の相談相手。

プログラマー。

コードレビュー担当。

テスト項目の洗い出し担当。

技術調査の担当者。

このような複数の役割を持つ、非常に優秀な開発チームのような存在です。

ただし、AIのチームにはプロジェクト全体に対する責任者がいません。

現在の仕様を最終的に決める人。

業務上の優先順位を判断する人。

レビュー結果を採用するか判断する人。

実際に利用者が困らないか確認する人。

問題が起きたときに責任を負う人。

これらは、最終的に人間が担う必要があります。

AIに複数の役割を与えることはできますが、プロジェクト全体の責任まで丸投げすることはできません。

修正履歴と仕様をGitHubで管理する理由

AIを使ったシステム開発では、修正履歴や仕様書の管理が非常に重要です。

私は、ソースコードだけではなく、修正履歴や設計方針、仕様書もGitHubで管理しています。

AIへ修正を依頼すると、指定した部分だけではなく、関連する別の箇所まで変更されることがあります。

ひとつの不具合を修正した結果、以前は正常に動いていた別の機能が動かなくなることもあります。

ある機能を追加したことで、既存のデータ構造との整合性が崩れることもあります。

修正を繰り返すうちに、当初の目的や設計から少しずつ外れてしまうこともあります。

私は、この状態を「AIが暴走する」と表現することがあります。

もちろん、AIが意思を持って勝手に暴走しているわけではありません。

人間側が、現在の仕様や過去の判断を十分に管理していないことが原因です。

AIは、基本的にその時点で与えられた指示に従います。

過去にどのような理由で現在の設計になったのか。

どの部分は変更してよく、どの部分は変更してはいけないのか。

以前、同じような問題に対してどのような判断をしたのか。

こうした情報が共有されていなければ、AIは目の前の問題だけを解決しようとします。

その結果、システム全体の整合性が崩れてしまいます。

GitHubに残しておくべき情報

GitHubには、少なくとも次のような情報を残しておく必要があります。

• 何を変更したのか

• なぜ変更したのか

• どの不具合を修正したのか

• どの機能を追加したのか

• 現在の仕様がどうなっているのか

• どのような設計判断をしたのか

• どの時点までは正常に動いていたのか

• 今後対応する課題は何か

これらを残しておけば、問題が発生したときに変更内容を追跡できます。

以前の正常な状態へ戻すこともできます。

別のAIに作業を引き継がせる場合にも、プロジェクトの状況を説明しやすくなります。

AIを使えば、会話だけでも開発を進めることはできます。

しかし、会話は流れていきます。

長い対話の中では、過去の重要な判断が埋もれてしまいます。

別の会話を開始すれば、それまでの背景が十分に伝わらないこともあります。

だからこそ、重要な設計や判断は、会話の中だけではなく、正式な文書として残す必要があります。

バイブコーディングで起こりやすい問題

バイブコーディングで特に注意すべき問題を、いくつか挙げます。

1．部分的な修正で全体が壊れる

目の前のエラーを修正するために、AIが関連するコードを大きく書き換えることがあります。

そのエラーは解消しても、別の機能が動かなくなる可能性があります。

修正前後の差分を確認し、影響範囲をテストする必要があります。

2．同じ処理が重複して作られる

開発を会話だけで進めていると、すでに存在する機能をAIが認識できず、似た処理を別の場所に作ることがあります。

同じデータを更新する処理が複数存在すると、後から仕様を変更する際に修正漏れが起きます。

3．セキュリティ対策が後回しになる

画面や機能を早く完成させることを優先すると、権限管理や入力値の検証が不足しやすくなります。

特に、個人情報や顧客情報を扱うシステムでは、後からセキュリティ対策を追加するのが難しい場合があります。

4．データベース設計が場当たり的になる

必要になるたびに項目やテーブルを追加していくと、データ構造が複雑になります。

同じ意味のデータが複数の場所に保存されたり、どのデータが正しいのか分からなくなったりします。

5．テストが正常系だけになる

AIに「テストして」と依頼すると、通常の操作を確認するテストは作ってくれます。

しかし、異常な入力や通信障害、同時操作など、実運用で重要なテストが不足することがあります。

6．AIの説明を理解せずに採用してしまう

AIは、技術的にもっともらしい説明をします。

しかし、その提案が必ずしも正しいとは限りません。

理解できない修正をそのまま採用し続けると、問題が発生したときに原因を特定できなくなります。

バイブコーディングを安全に使うために必要なこと

バイブコーディングを安全に活用するには、最低限、次のような取り組みが必要です。

目的と対象業務を明確にする

最初に「何のために作るのか」を明確にします。

目的が曖昧なまま機能を追加すると、複雑で使いにくいシステムになります。

いきなり全機能を作らない

最初から大規模なシステムを作るのではなく、重要な機能から小さく作ります。

実際に動かしながら、設計や運用方法を確認します。

正常な操作以外もテストする

空欄、重複、誤った形式、連続クリック、通信障害、権限のない操作などを確認します。

利用者が間違えることを前提にテストします。

変更履歴を残す

修正内容や理由をGitHubなどに記録します。

問題が起きた場合に、以前の状態へ戻せるようにします。

バックアップと復旧方法を決める

データが壊れた場合に、どこまで戻せるのかを決めます。

バックアップを作るだけではなく、実際に復元できるかも確認します。

複数の視点で確認する

コードを書いたAIとは別のAIでレビューする。

人間が業務の視点からテストする。

可能であれば、実際の利用者にも操作してもらう。

ひとつのAIやひとりの判断だけに依存しないことが重要です。

バイブコーディングそのものが危険なのではない

私は、バイブコーディングそのものが危険だとは考えていません。

AIを使ってシステムを作ることには、非常に大きな可能性があります。

これまでなら、開発費や人員の問題で実現できなかった小規模な業務システムも、AIを活用することで作れるようになりました。

市販のシステムでは対応できない、自社独自の業務に合わせた仕組みも作りやすくなりました。

アイデアを形にするまでの速度も、以前とは比較になりません。

試作品を作り、実際に操作しながら改善する方法も取りやすくなりました。

私自身、AIがなければ、現在のような速度で複数のシステムを開発することはできなかったと思います。

問題は、AIを使うことではありません。

AIが作ったものを、どのように管理し、検証し、運用するかです。

最も危険なのは「完成したと思い込むこと」

バイブコーディングでシステムを作る場合、最も危険なのは、エラーが出ることではありません。

エラーが出れば、少なくとも問題があることに気づけます。

本当に危険なのは、正常に動いているように見えるため、問題がないと思い込んでしまうことです。

画面が表示された。

データが登録できた。

検索もできた。

利用者もログインできた。

だから完成した。

そう判断してしまうと、実際に運用を始めてから重大な問題が見つかる可能性があります。

一部のデータが保存されていなかった。

権限のない利用者が情報を閲覧できた。

同じ処理が二重に実行された。

退職した人がログインできる状態だった。

バックアップから復元できなかった。

ある修正によって、過去のデータが正しく表示されなくなった。

こうした問題は、見た目だけでは分かりません。

誰でもシステムを作れるが、誰でも安全に運用できるわけではない

AIを使えば、誰でもシステムを作れる時代になりつつあります。

これは間違いなく、大きな進歩です。

しかし、誰でも安全なシステムを作れるようになったわけではありません。

コードを書くことと、システムを設計することは別です。

システムを作ることと、継続的に運用することも別です。

試作品を作ることと、顧客情報や業務データを預けられる仕組みを作ることも別です。

AIによってコーディングのハードルは下がりました。

一方で、設計、テスト、セキュリティ、運用、保守の重要性は変わっていません。

むしろ、短期間で多くのコードを作れるようになったからこそ、それらを管理する能力がより重要になっています。

まとめ

AIにすべてを丸投げするのではなく、AIを非常に優秀な開発チームとして使う。

ChatGPTと設計する。

Claude Codeで実装する。

Codexでレビューする。

レビュー結果を再検証する。

人間が実際の業務や利用者の立場からテストする。

そして、仕様や修正履歴をGitHubで管理する。

このように、AIと人間の役割を分けて開発を進めることが重要です。

AIは、非常に優秀です。

しかし、何を作るべきかを最終的に決めるのは人間です。

どのリスクを許容し、どの問題には必ず対応するのかを判断するのも人間です。

実際の利用者にとって使いやすいかを確認するのも人間です。

そして、完成したシステムに責任を持つのも、最終的には人間です。

「AIがコードを書いてくれること」と、「安全に運用できるシステムが完成すること」は、まったく別の話です。

バイブコーディングの本当の落とし穴は、AIが間違えることだけではありません。

AIが作ったものが、それらしく正常に動いてしまうことです。

だからこそ、人間が設計し、判断し、検証し、変更を管理する必要があります。

現時点では、それがAIを使ったシステム開発の現実的な形ではないかと、私は考えています。

 

AIを活用したシステム開発をお考えの方へ

AIを使えば、これまで費用や人員の問題で実現が難しかった業務システムも、以前より短期間で形にできるようになりました。

ただし、AIにコードを書かせるだけで、業務で安全に使えるシステムが完成するわけではありません。

必要なのは、現状の業務を整理し、何をシステム化するのかを明確にしたうえで、例外処理や権限管理、セキュリティ、運用方法まで考えて設計することです。

有限会社シーエスプラスでは、単にAIにプログラムを書かせるのではなく、業務内容の整理からシステム設計、AIを活用した開発、コードレビュー、テスト、運用までを一連の流れとして進めています。

「市販のシステムでは、自社の業務に合わない」

「Excelや手作業で行っている業務を効率化したい」

「AIを使って自社独自のシステムを作りたいが、何から始めればよいか分からない」

「すでにAIでシステムを作っているが、このまま運用してよいのか不安がある」

そのようなお悩みがありましたら、まずは現在の業務や課題をお聞かせください。

作りたい機能がまだ具体的に決まっていなくても問題ありません。

業務のどの部分をシステム化すると効果があるのか、既存のサービスを利用した方がよいのか、独自開発が適しているのかも含めて、一緒に整理します。

AIを活用した業務システムの企画・設計・開発に関するご相談は、有限会社シーエスプラスまでお気軽にお問い合わせください。

---