AIと会話しながらアプリを作る「バイブコーディング」によって、プログラミングを専門的に学んでいない人でも、自分のアイデアをシステムとして形にできる時代になりました。

私自身もプログラマーではありません。

それでもAIと対話しながら、質問への回答入力、診断ロジック、診断結果の表示、PDF生成、自社ドメインからのメール送信、顧客データの保存、管理者画面までを備えた自社用の診断システムを一人で開発しました。

以前であれば、こうしたシステムを作ろうとすれば、仕様をまとめて開発会社へ依頼し、数十万円、数百万円という費用をかけることも珍しくありませんでした。

しかし現在は、AIへ「こういう機能が欲しい」「ここを直してほしい」と伝えながら、非エンジニアでも実際に動くものを作れる可能性があります。これは非常に大きな変化です。

一方で、実際に開発を続ける中で、私は何度も同じような失敗を経験しました。

それは、AIが「完成しました」と答えているのに、実際には完成していないという失敗です。

画面には「メール送信完了」と表示されているのに、実際のメールは届いていない。PDFは確かに生成されたのに、日本語が文字化けしている。データは保存できたのに、再デプロイしたら全部消えた。パスワード再設定メールは届いたのに、メール内のリンクを押しても画面が開かない。Google AI Studioでは修正済みなのに、GitHubには古いコードしかない。Cloud Runを削除したはずなのに、少しすると古い設定のサービスが再び作られる。

こうした経験を重ねて分かったことがあります。

バイブコーディングで本当に重要なのは、AIにコードを書かせる能力だけではありません。これから必要になるのは、「何をもって完成とするのかを決め、実際に確認する力」です。

AIは非常に優秀な実装者です。しかし、AIは最終責任者ではありません。

AIを使えば、自分自身のプログラミング能力を超えた成果物を作れる可能性があります。しかし、自分の責任までAIへ渡すことはできません。

この記事では、私自身の失敗をもとに、バイブコーディングで業務用アプリを本番利用するときに確認したい「本番完了6条件」を中心に解説します。

バイブコーディングで最も注意したいのは「完成」の定義

バイブコーディングでは、AIとの会話が非常にスムーズに進みます。たとえば「メール送信機能を追加してください」と依頼すると、AIがコードを修正し、「メール送信機能を実装しました」「修正が完了しました」「これで正常に動作します」と答えることがあります。

ここで最も注意したいのが、AIが意味する「完成」と、利用者が意味する「完成」は同じとは限らないということです。

AIにとっての「完成」と利用者にとっての「完成」は違う

AIが「完成しました」と答えるとき、主に見ているのは、その会話の中で依頼された作業です。たとえば、指定されたコードを書いた、エラーが出ない形に修正した、必要な関数を追加した、指示された画面を作った、という状態です。

しかし、業務で使う側が考える「完成」はもっと広いものです。たとえばメール送信機能であれば、次のような一連の動作まで確認する必要があります。

1. 送信ボタンを押せる

2. エラーが表示されない

3. SMTPサーバーへ接続できる

4. 実際にメールが送信される

5. 相手のメールボックスへ届く

6. メール本文が正しい

7. 再デプロイしても機能する

コードが完成したことと、業務で使えることは別です。

「コードが書けた」と「本番で使える」の間には複数の工程がある

私が開発している環境では、大まかに次のような流れで本番へ反映されます。

AI Studio・開発環境 → GitHub → Cloud Build → Cloud Run → 本番URL

AI Studio上でコードが修正されたとしても、GitHubに反映されていなければ、その修正は本番へ届きません。GitHubに最新コードが存在していても、Cloud Buildが失敗していれば、新しいアプリは作られません。

Cloud Buildが成功していても、Cloud Runで新しいRevisionへトラフィックが向いていなければ、利用者は古いバージョンを使い続ける可能性があります。そして、Cloud Runまで正常でも、最終的な本番URLで実際の操作をしてみなければ、本当に必要な機能が使えるかは確認できません。

AIの「完成」ではなく、「本番まで確認できたか」で完成を判断します。

筆者が経験した「完成していなかった完成」6例

ここからは、実際に私が経験した失敗を紹介します。どれもAI上では「修正済み」「実装済み」と見えていたものですが、本番利用という観点では完成していませんでした。

メール送信完了と表示されるのに実際のメールは届かなかった

診断システムでは、診断終了後に結果をメールで送信する機能を実装しました。画面上では「メールを送信しました」という表示が出ます。これだけを見ると、機能は完成したように思えます。

ところが、実際のメールボックスを確認してもメールが届いていませんでした。ここで重要なのは、画面上の成功表示と、実際の外部処理の成功は同じではないということです。

アプリの内部では送信処理を実行したつもりでも、SMTP設定、認証情報、パスワード、環境変数、Secret、接続先などに問題があれば、実送信は成功しません。

メール機能を確認するときは「送信完了と表示されたか」ではなく、実際に受信側へメールが届いたかまで確認する必要があります。

PDFは出るが日本語が文字化けする

次に経験したのがPDFです。診断結果をPDFにしてダウンロードできるようにしました。PDFファイル自体は正常に生成されます。そのため、最初は「PDF機能は完成した」と思いました。

しかし、ファイルを実際に開いてみると、日本語部分が正常に表示されていませんでした。つまり、PDFファイルが生成されたことと、PDFの内容が正しいことは別です。

日本語をPDFへ出力する場合、フォントへの対応も重要になります。ボタンを押してファイルが保存されたからといって、そこでテストを終えてはいけません。

実際にPDFを開き、日本語が表示されるか、文字化けしていないか、改行が崩れていないか、必要な内容が欠けていないかまで確認する必要があります。

データは保存できるが再デプロイすると消える

これは非常に重要な失敗でした。診断した人の回答や管理情報を保存する機能を作り、実際に保存できることも確認しました。管理画面を開けば、保存されたデータも表示されます。

ところが、アプリを修正してCloud Runへ再デプロイしたあと、保存していたデータが消えていました。原因は、永続保存されるデータベースではなく、実行環境内のローカルファイルに保存していたことでした。

その瞬間だけ見ると保存できています。しかし、再デプロイ後にもデータが残るかという確認をしていなかったのです。

業務システムでは、「今保存できる」だけでなく、再起動、再デプロイ、新Revision作成、インスタンス変更などが起きても必要なデータが残る設計かを確認する必要があります。

パスワード再設定メールは届くがリンク先が動かない

管理画面へログインするためのパスワード再設定機能も作りました。メールアドレスを入力すると、再設定メールが届きます。ここまで確認すると、機能は正常に見えます。

しかし、届いたメール内のリンクをクリックすると、目的の画面が開きませんでした。メール送信自体は成功しています。問題はその後です。

メール内に生成されたURL、本番ドメイン、パス、ルーティング、トークンの受け渡し、再設定画面のどこかに問題があれば、利用者はパスワードを変更できません。

つまり、パスワード再設定機能の完成条件は、メールが届くことではなく、リンクを押して実際に新しいパスワードを設定できることです。

Cloud Runを削除しても古いトリガーが再作成する

不要になったCloud Runのサービスを削除したこともあります。管理画面からサービスが消えたので、「削除完了」と考えていました。

しかし、その後、同じようなサービスが再び作成されました。原因を追っていくと、自動デプロイを行うCloud Buildのトリガーが残っていました。

つまり、結果として存在しているCloud Runだけを消しても、それを作り出す仕組みが残っていれば再び作られるということです。

目の前に見えているものだけでなく、「誰がこれを作っているのか」「何をきっかけに動くのか」まで確認する必要があります。

AI Studioでは修正済みだがGitHubへ反映されていない

これも何度か経験しました。Google AI Studio上では、確かに修正された画面が表示されています。AIとの会話上でも「修正しました」と答えています。

ところが本番を開くと何も変わっていません。原因を確認すると、GitHub側には修正前のコードしかありませんでした。

つまり、開発環境上の修正と、GitHubへの反映は別の作業だったということです。GitHubを開き、最新コミットはいつか、どのファイルが変更されたか、mainブランチに反映されているか、最新のコミットSHAは何かを見る必要があります。

ここから私は、本番確認では各工程を一つずつ追うことが重要だと考えるようになりました。

バイブコーディングの本番完了を判断する6つの条件

ここまでの失敗を経験してから、私は「完成」の判断基準を変えました。現在は、少なくとも次の6条件を確認してから本番完了と判断するようにしています。

1. GitHubのコミットSHA確認

2. Cloud Build成功の確認

3. Cloud Runの新Revision確認

4. 本番トラフィックの確認

5. 本番URLで実際に操作

6. 必要な機能が再デプロイ後も維持されることを確認

条件1．GitHubのコミットSHAを確認する

最初に確認するのはGitHubです。AI StudioやClaude Codeなどで修正したからといって、そのコードが必ずGitHubに存在するとは限りません。そこで、「本番へ反映させたいコードが、GitHubに存在するか」を確認します。

ここで役立つのがコミットSHAです。コミットSHAは、初心者向けに考えるなら「その時点のコードを特定する番号」です。

本番反映で問題が起きたとき、「最新のはず」と考えるのではなく、どのコミットが本番へ反映されようとしているのかを確認することが重要です。

GitHubで最低限確認したいのは、mainブランチに変更があるか、最新コミット日時、最新コミットの内容、コミットSHAです。AI上の画面だけで判断せず、ソースコードの管理場所を確認します。

条件2．Cloud Buildが成功していることを確認する

GitHubに最新コードがあれば、それだけで本番更新が完了したわけではありません。次に確認するのがCloud Buildです。

Cloud Buildでは、GitHub上のコードをもとに、本番で実行するためのコンテナを作る処理などが行われます。重要なのは、ビルドが実際に成功しているかを見ることです。

GitHubへのpushをきっかけに自動デプロイする仕組みを作っていても、途中でビルドエラーが起きれば本番は更新されません。

できれば、GitHubで確認したコミットSHAと、Buildの対象になっているコミットを照合します。これによって、自分が修正したコードと、実際にビルドされたコードが同じかを判断しやすくなります。

条件3．Cloud Runに新しいRevisionが作成されているか確認する

Cloud Buildが成功したら、次はCloud Runです。Cloud Runではデプロイのたびに、新しいRevisionが作成されます。

Revisionは初心者向けに言えば、Cloud Run上で実際に動かすアプリの新しいバージョンと考えると分かりやすいでしょう。

ここで確認するのは、新しいRevisionが作成されたか、作成時刻は想定どおりか、デプロイした変更と時系列が一致しているかです。Cloud Buildが成功していても、Cloud Run側に新Revisionが作られていなければ、本番反映の途中で止まっている可能性があります。

条件4．新しいRevisionへ本番トラフィックが向いているか確認する

新しいRevisionが存在していても、それだけでは安心できません。次に見るのがトラフィックです。

Cloud Runでは、どのRevisionへ実際のアクセスを送るかを管理できます。つまり、新しいRevisionが存在していても、利用者が古いRevisionへアクセスしている可能性があるということです。

そこで、「最新Revisionがある」ではなく、「本番アクセスが最新Revisionへ向いている」ところまで確認します。特に「デプロイは成功しているのに、本番画面だけ古い」という場合は、トラフィックの確認が重要です。

条件5．本番URLを自分で実際に操作する

ここが最も重要です。GitHubが正常、Cloud Buildも成功、Cloud Runにも新Revisionがある、トラフィックも正しい。それでも、私は本番完了とは判断しません。

最後は必ず、本番URLを自分自身で開いて操作します。たとえば診断システムであれば、最初のページが開く、質問へ回答できる、次の画面へ進める、診断結果が表示される、PDFが生成できる、PDFを開いて内容を確認する、メールが実際に届く、データが保存される、管理画面へ反映される、パスワード再設定が最後までできる、などを確認します。

重要なのは、画面が表示されたことをもってテスト完了にしないことです。利用者が実際に行う操作を、最初から最後まで行います。

条件6．必要な機能が再デプロイ後も維持されることを確認する

最後の条件が、再デプロイ後の確認です。この条件を入れるようになったのは、保存データが消えた経験がきっかけです。

一度正常に動いたからといって、その状態がずっと維持されるとは限りません。新しい修正を加え、再びCloud Runへデプロイしたとき、データ、環境変数、Secret、認証設定、外部連携、必要なファイル、管理画面などが維持されているかを確認します。

特に業務アプリでは、今後も修正が続きます。そのたびにデータが消えたり、メール送信設定がなくなったりしていては、本番システムとして利用できません。

そのため、「初回だけ動く」ではなく、「次の修正後も動く」ところまでを完成条件に含めることが重要です。

6条件を一枚で確認｜バイブコーディング本番公開チェックリスト

本番公開前は、次の6項目を順番に確認すると原因を切り分けやすくなります。

大切なのは、一気に原因を探そうとしないことです。たとえば本番が更新されていないのであれば、「AIがおかしい」と考える前に、AI Studio、GitHub、Cloud Build、Cloud Run、本番URLと順番に見ていきます。どこまで新しい状態になっているのかを確認すれば、問題の場所を絞り込みやすくなります。

AIは非常に優秀な実装者だが最終責任者ではない

ここまで読むと、「バイブコーディングは危ないのではないか」と感じる人もいるかもしれません。しかし、私はそう考えていません。むしろ、AIによる開発には非常に大きな可能性があると感じています。

AIを使えば自分の能力を超える成果物を作れる

私はプログラマーではありません。それでもAIを使うことで、診断画面、ロジック、PDF生成、メール、顧客データ保存、管理機能、Cloud Runへの公開といった、自分一人では以前作れなかったものを形にできました。

これはAIの非常に大きな価値です。今後は、「プログラムを書けるか」だけでなく、「何を作りたいのかを考え、AIと一緒に形にできるか」が重要になるでしょう。

自分の責任までAIへ渡すことはできない

AIへ実装を任せることはできます。しかし、「このシステムを顧客に使ってもらって大丈夫か」「このデータ保存方法で問題ないか」「本当にメールが送信されているか」「パスワード再設定が最後まで動くか」という最終判断は、人間側に残ります。

特に企業が利用するシステムでは、不具合が起きたとき、「AIが完成と言ったから公開しました」では済みません。顧客や社員から見れば、そのシステムを提供している会社が責任を持つことになります。

AIは実装者として最大限活用しながら、最終確認は自分たちで行うことが重要です。

これからのバイブコーディングで必要なのは「確認力」

ここでいう確認力は、一般的なAI活用スキルの話ではありません。バイブコーディングで実際に業務アプリを本番利用するための、品質保証としての確認力です。私は大きく4つあると考えています。

何を作るのかを確認する

最初に必要なのは、何を作るかを明確にすることです。「顧客管理システムを作りたい」だけでは完成条件が分かりません。誰が使うのか、何を入力するのか、何を保存するのか、何を出力するのか、管理者は何を見るのか、外部サービスと何を連携するのかまで整理します。作るものが曖昧なら、完成したかどうかも判断できません。

何をもって完成とするかを確認する

次に必要なのが完成条件です。たとえばメール機能であれば、「メール送信機能を実装した」ではなく、「本番URLから送信操作を行い、指定したメールアドレスへ正しい件名・本文のメールが実際に届く」と定義します。PDF機能なら、本番環境から生成し、ダウンロードして開いたときに日本語を含む必要な内容が正常に表示されるところまでを完成条件とします。

何を確認するかを決める

完成条件が決まったら、その条件をどう確認するかを決めます。たとえばデータ保存機能なら、データを入力して保存し、一度画面を閉じ、再度開き、再デプロイした後にも残っているかを確認します。AIに「テストしてください」と任せるだけでなく、利用者としてどんな操作を行えば確認できるかを考えます。

どこにリスクがあるかを考える

すべての機能を同じ強さで確認する必要はありません。ボタンの色が少し違うことと、顧客データが消えることでは影響がまったく異なります。「壊れたときに誰へどの程度影響するか」を考え、リスクが大きい機能ほど人間による確認を厚くします。

特に慎重に確認したい本番機能

顧客データ・個人情報の保存

顧客名、メールアドレス、回答内容などを保存する場合は、正しく保存されるか、他人から見えないか、再デプロイ後も残るか、不要な情報まで保存していないかなどを確認します。「保存できた」だけで終わらせないことが重要です。

メール送信

メールはアプリ内部だけで完結しません。外部のメールサーバーや認証情報などが関係するため、送信操作、実際の受信、件名、本文、URL、送信元まで確認します。画面の「送信完了」だけを信用しないようにします。

認証・パスワード再設定

ログインやパスワード再設定はシステムの入口です。正規ユーザーが入れない、本来入れない人が入れる、パスワードを忘れたら復旧できない、といった問題につながるため、メールが届くだけでなくリンク先から最後まで操作します。

PDFなどのファイル生成

ファイルがダウンロードできることと、その内容が正しいことは別です。文字化け、レイアウト崩れ、欠落、誤った内容がないかを実ファイルで確認します。

外部APIやSecretを使う機能

APIキー、SMTPパスワードなどを利用する機能は、開発環境と本番環境で設定が異なることがあります。開発画面で動いていても、本番に必要なSecretが設定されていなければ動かないため、本番環境で実際に確認します。

自動デプロイ・トリガー

自動化は便利ですが、自分が意識していないところで処理が動く特徴もあります。古いトリガーが残っていれば、意図しないデプロイが発生する可能性があります。「何をきっかけに、何が作られるのか」を把握しておくことが重要です。

バイブコーディングの本番利用で注意したいこと

ここまでのポイントを整理すると、バイブコーディングの本番利用では、AIの回答を確認するのではなく、実際の成果物を確認することが重要です。

AI：「メール送信機能を実装しました」 → 実メールが届くか確認する。

AI：「PDF出力機能を実装しました」 → PDFを開いて中身を見る。

AI：「データ保存機能を実装しました」 → 再デプロイ後にもデータを見る。

AI：「修正しました」 → GitHubのコミットSHAを見る。

AI：「デプロイしました」 → Cloud Build、Revision、トラフィック、本番URLを見る。

この習慣を持つだけでも、バイブコーディングの本番トラブルは発見しやすくなります。

まとめ｜「AIが完成と言った」ではなく「自分が確認した」で終わらせる

バイブコーディングによって、非プログラマーでも自分でアプリを作れる可能性は大きく広がりました。私自身、プログラマーではありませんが、AIと会話しながら、自社で利用する診断システムを形にできました。

その意味で、AIは非常に優秀な実装者です。一方で、実際の開発では、メール送信完了と表示されてもメールが届かない、PDFは出ても日本語が文字化けする、データを保存できても再デプロイで消える、パスワード再設定メールは届いてもリンク先が動かない、Cloud Runを削除しても古いトリガーから再作成される、AI Studioでは修正済みでもGitHubへ反映されていない、という「完成していなかった完成」を経験しました。

そこで現在は、本番完了を6条件で確認しています。

1. GitHubのコミットSHAを確認する

2. Cloud Buildの成功を確認する

3. Cloud Runの新Revisionを確認する

4. 新Revisionへの本番トラフィックを確認する

5. 本番URLを実際に操作する

6. 再デプロイ後も必要な機能・データが維持されることを確認する

バイブコーディングで求められる人間の役割は、すべてのコードを自分で書くことではありません。むしろ、何を作るか、何を完成とするか、何を確認するか、どこにリスクがあるかを考えることが重要になります。

AIを使えば、自分の能力を超える成果物を作れる可能性があります。しかし、自分の責任までAIへ渡すことはできません。AIは非常に優秀な実装者ですが、最終責任者は人間です。

「AIが完成と言ったから完成」ではなく、「自分が本番を確認したから完成」と言える状態を目指すことが、これからのバイブコーディングでは重要です。

よくある質問

AIが「テストに成功しました」と言えば、本番確認は不要ですか？

不要にはなりません。AIや開発環境でのテストが成功しても、本番環境では設定、Secret、URL、外部サービス、デプロイ状態などが異なる場合があります。本番URLから実際の利用手順を操作して確認することが重要です。

プログラミングが分からなくても、本番完了6条件は確認できますか？

基本的な状態確認は可能です。すべてのコードを読める必要はありません。GitHubに最新コードがあるか、Cloud Buildが成功しているか、新しいRevisionがあるか、本番で実際に動くか、と工程ごとに確認することが重要です。

開発画面で正常に動けば、本番環境でも同じように動きますか？

必ずしも同じとは限りません。本番環境では環境変数、Secret、URL、データ保存先、外部サービスとの接続条件などが異なる場合があります。そのため本番環境で別途確認してください。

バイブコーディングで業務システムを作っても大丈夫ですか？

AIを使って業務システムを作ること自体ではなく、どのような用途で使い、どのような情報を扱い、どこまで品質やセキュリティを確認できているかが重要です。顧客情報や重要業務を扱う場合ほど慎重な確認が必要です。

どこまで確認すれば「完成」と判断できますか？

本記事で紹介した6条件を基本にしながら、そのシステム固有の重要機能を追加してください。特にデータ保存、認証、メール、PDF、外部APIなど、問題が起きたときの影響が大きい機能は実操作による確認が必要です。

AIを使った業務改善のご相談

AIを活用すれば、非プログラマーでもこれまで専門家へ依頼しなければ作れなかった業務システムを形にできる可能性があります。一方、本番利用では「作れるか」だけでなく、「どこまで確認すれば安心して使えるか」という視点が重要です。

自社業務をAIでどこまで仕組み化できるのか、現在作っているシステムをどのように整理すればよいのか、本番利用に向けて何を確認したらよいのか迷っている場合は、一度ご相談ください。

AIを使った業務改善について相談する