AIで製品を作った—動いているものを壊さずに改善する方法

モデルの活用について詳しくは、Ailootのドキュメントをご覧ください。

最も大変な作業がリリース後に始まるのはなぜ？#

夕方のうちにアプリを作り、リンクを公開して友人に送りました。ちゃんと動きます。ところが1週間後、初めての本物のユーザーがやって来て、少し変わった操作をしたら機能の半分が動かなくなりました。Claudeに修正を頼むと、ひとつは直ったけれど、別のところが壊れます。聞き覚えはありませんか？

ここで大きな疑問が浮かびます。最初のプロトタイプが動いた高揚感が過ぎた後、リリースした製品をどう維持していけばいいのでしょうか。これは「大人のためのバイブコーディング」と呼べるかもしれません。開発はワクワクするし、速く進みます。保守には冷静さが必要です。何を変えるのかを理解し、制御し続けなければなりません。多くの人がこの後半で失敗するのは、誰もその準備をしていないからです。

ある業界調査は2,444チームによる100万件以上のコード変更を分析し、AI開発に使われたお金の実際の行き先を算出しました。結果は次のとおりです。

この数字について詳しくは、「バイブコーディングに隠れたコスト」の記事をご覧ください。そちらでは、何にお金を払っているのかを説明しました。ここでの問いは別です。1ドルのうち44セントがバグ修正に使われています。この記事では、その割合がさらに増えないようにする方法を扱います。それを維持するための作業が保守です。

大人のようにバイブコーディングする人と、ニューラルネットの世話に追われるだけの人の違いは、リリース後に現れます。前者のコードベースは成長し、改善を加えても壊れません。1か月後、後者の製品は、怖くて触れないほどあちこちから漏れる仕組みになっています。ここからは、前者になる方法を説明します。

実際に何が壊れるのか：リリース後に起きる5つの災難#

以下は、AIで作られた実在の製品に関する公開済みの事後報告です。数値や日付も記載されています。地雷原の地図だと思ってください。地雷はすでに誰かのところで爆発しており、避け方も分かっています。

5件すべてに共通する根本原因があります。AIはデフォルトで、「今すぐ動く」ように作ります。「1か月後に負荷がかかっても安全に動く」ようには作りません。自分のコンピューターで開発している間は、その違いに気づけません。悪意を持った見知らぬ人が現れたときに初めて明らかになります。

問題は、コードを手作業で書かないことではありません。こうしたやり方で仕事をする人は大勢います。問題は「データベースは保護されているか」と確認しないことです。次に、その問いを代わりに確認するプロンプトを紹介します。

最初の安全網はgitと「昨日の状態に戻す」こと#

Claudeが何かを壊したとき、「昨日の状態に戻す」ボタンが必要です。技術的には、そのボタンはgitと呼ばれます。聞こえるほど難しくはありません。

プログラマーでなくても知っておきたい用語は3つです。

1. リポジトリ — 通常はGitHub上に保存するプロジェクトのフォルダーです。コードのコピーが保存され、コンピューターだけに置かれることはありません。
2. コミット — 復帰ポイントです。コードに「この状態で保存」と伝えるようなものです。各コミットは、戻ることのできる目印になります。
3. デプロイ — 移動です。コードはコンピューター上にあり、自分にしか動きません。デプロイすると外部サーバーに送られ、誰でも使えるようになります。

最近のコミットがあれば、何かが壊れても一言で元に戻せます。本当に一言です。

何かを壊してしまいました。昨日はすべて動いていたのに、今日は動きません。すべて問題なかった最新のコミットを見つけ、そこから何が変わったかを示して、その状態にプロジェクトを戻してください。

他の人に製品を見せる前に、すぐに徹底しておくべきルールが2つあります。

• リポジトリは非公開にする。 公開しないでください。そうしないと、誰でもコードとその中身を読めてしまいます。
• シークレットファイルを無視リストに入れる。 キー、パスワード、データベースの認証情報は別ファイル（通常は.env）に置き、そのファイルをリポジトリに入れないでください。.gitignoreに.envの行を追加すれば、シークレットは自分の手元に残ります。

Claude Codeで変更を安全に戻す方法については、別の記事があります：Claude Codeで変更をロールバックする方法。復帰ポイントなしで作業するのは、安全網なしで綱渡りをするようなものです。遅かれ早かれ落ちてしまいます。

/rewindで元に戻るものと、戻らないものは？#

Claude Codeは、自ら変更を加える前に状態のスナップショットを取ります。/rewindコマンド（またはEscキーを2回押す操作）を使うと、ファイルと会話の両方が選択した時点まで戻ります。便利です。5分前に機能を壊したなら、5分前に戻れます。

ただし、初心者がデータを失う原因となる落とし穴があります。/rewindですべてが元に戻るわけではありません。

Anthropicはこう明言しています。スナップショットはローカルの「取り消し」ボタンで、gitは恒久的な履歴です。スナップショットはバージョン管理を補完しますが、置き換えるものではありません。

プログラマーでない人にとっての実際的な教訓は、Claudeが機能を壊したときには/rewindが助けになるということです。しかし、データベースの行を削除したり、コードをクラウドにアップロードしたりしてしまった場合、元に戻せるのはgitとデータベースのバックアップだけです。両方の層を維持しましょう。素早く戻すにはスナップショット、プロジェクトの恒久的な履歴にはコミットを使います。

動いているものを壊さずに改善するには？#

2人に1人は、このループにはまります。AIに小さなバグの修正を頼みます。もっともらしい変更が提案されます。その変更が別のものを壊します。新たな問題を直すよう頼むと、さらに2つ問題が出てきます。それが続きます。

このループが起きるのは、バイブコーディングの結果が一定しないからです。同じプロンプトでも、2回頼めば違うコードが出てきます。そのため、編集のたびに周囲のロジックがひそかに変わることがあります。割引のしきい値が10％から12％に動いたり、検証ルールの挙動が変わったりします。こちらで確認していなくても、警告がひとつも出なくても起きます。これはロジックのずれと呼ばれ、収益につながるもの、つまり価格、アクセス権、支払いを静かに損ないます。

このずれを防ぐルールがあり、壁に貼っておけるほど簡潔です。一語一句、ほかの人に説明できないコードはコミットしない、というものです。

実際には、動いているコードを変更する前に使える定型の指示にできます。AIに小さな手順で進めさせ、何が変わったかを正確に示させます。

コードを変更する前に、次のことをしてください。

現在の動作状態を、別の復帰ポイント（コミット）として保存してください。

何をどのファイルで変更する予定か、正確に言葉で説明してください。

私の依頼を解決するために必要な、可能な限り小さな変更だけを行ってください。余計なことはしないでください。

変更箇所を示し、それぞれを説明してください。私が別の人に説明できるようにしてください。
私が頼まない限り、価格設定、アクセス権、決済のロジックには触れないでください。

数週間を無駄にしないためのもうひとつの原則は、作業範囲を守ることです。ひとつの問題にひとつの変更、短時間で実装します。ひとつのプロンプトでプロジェクトの半分を書き直すようAIに頼んではいけません。プロの開発者でも、必要なのはボタンひとつなのにUber全体を作り始め、何か月もかけてしまうことがあります。そんなことをする必要はありません。

ここで説明していることはすべて、コンテキストの管理が土台になっています。AIが隣接するロジックを壊さないようにするには、プロジェクトのルールを覚えておく必要があります。

公開する前に変更を確認するには？#

「自分のコンピューターでは動く」と「誰にでも動く」の間には、初心者が飛ばしがちな中間段階があります。テスト用コピーです。実際のユーザーに見せる前に変更を確認できる、本番環境の別のスナップショットです。作業サイクルは次のようになります。

1. 変更を作り、自分で動作を確認する（開発）。
2. 本番環境のコピーで、実際のユーザーがいないステージングにデプロイする。
3. 主要なシナリオを実行し、何も変わっていないことを確認する。
4. その後で初めて本番環境にデプロイする。

リリース後に重要なのは、リリースには毎回リスクがあるからです。小さなコード変更でアカウントへのサインインが壊れることがあります。設定がひとつ足りないだけで、製品全体が停止することもあります。ステージングなら影響が出る前に問題を検出できます。本番環境では顧客を失います。

毎回すべてを手作業で確認しなくてすむように、重要な領域で新バージョンの動作が旧バージョンと同じかを比較するプロンプトをAIに渡しましょう。

変更をデプロイしようとしています。製品の主要なシナリオを順に確認し、これまでどおり動作することを確かめてください。

新規ユーザーの登録とサインイン。

決済と、決済後のアクセス権付与。

アクセス権：一般ユーザーが他人のデータや管理画面を見られないこと。

主要なビジネスロジックの数値（価格、割引、上限）が変わっていないこと。
以前のバージョンと動作が異なる点があれば、停止して、何が変わったかを正確に示してください。

シークレットはどこにある？初心者にとって最大の穴#

他のどんな問題よりも多くの製品を停止させる最大の地雷について、詳しく説明します。AIがコードを書くとき、キーをすぐ使える場所、つまりブラウザーで開くページのコードに直接入れるのが最も簡単です。開発中はその違いに気づきません。しかし、ブラウザーに届くものは何でも、開発者ツールを開けば誰でも読めます。

顧客に$87,500が請求された創業者は、後になって、ひとつのプロンプトで防げたはずだと話しました。請求は最終的に取り消されましたが、返金されない手数料と失われた安心は戻りませんでした。そのプロンプトを紹介します。

プロジェクト全体を確認して、秘密鍵がブラウザーに渡ることがないようにしてください。

データベース、決済システム、外部サービスのすべてのキーを見つけてください。

それぞれがサーバー上の環境変数にのみ保存され、ページのコードには含まれていないことを確認してください。

プロジェクトの履歴も確認してください。過去にキーが誤って含まれたことはありますか？
シークレットが見つかった場所をすべて一覧にし、それぞれに必要な対応を示してください。

近くにある次の地雷は、ブラウザー側だけでアクセス権を確認することです。ページのコードが「管理画面を表示するか」を判断しているなら、誰でもその判断を回避できます。アクセス権は必ずサーバーで確認してください。データベースは権限のあるユーザーにだけデータを返さなければなりません。そのための仕組みが行レベルセキュリティ（RLS）であり、すべてのテーブルで有効にする必要があります。

アクセスを販売したり、ほかの人に使ってもらったりする前に、製品のセキュリティ全般を監査してください。

攻撃者の視点でプロジェクトを調べ、セキュリティ上の穴を見つけてください。

ブラウザーに渡るコードやプロジェクトの履歴に、秘密鍵が保存されていませんか？

すべてのデータベーステーブルで行レベルセキュリティ（RLS）が有効になっていますか？ また、アクセス権はブラウザーだけでなくサーバーでも確認されていますか？

データベースの自動バックアップは設定されていますか？ そこから復元できることを確認したことはありますか？

本番データベースは、AIエージェントが実行される環境から隔離されていますか？
各項目について、問題ないか、または何を修正する必要があるかを正確に教えてください。

バイブコーディングのセキュリティについては、別の詳しい記事があります：バイブコーディングで作ったアプリを安全にする方法。ルールは単純です。AIがデフォルトで行ったことは、確認が済むまで安全でないものとして扱ってください。

製品のホスティング先：ホスティングの段階#

最初から自分のサーバーを借りて手作業で設定する必要はありません。始めたばかりの時期には難しく、時間を奪われます。製品の成長に合わせて、次の段階を進めていきましょう。

1. 無料ホスティング（たとえばVercel）—自分用、テスト、小規模プロジェクト向けです。利用者のいる地域でプラットフォームが使え、個人データを保存しない場合に適しています。
2. 1つのコマンドでデプロイできるプラットフォーム（Railway）—バックエンドとデータベースがある場合に使います。1つのコマンドでデプロイでき、サーバーを設定する必要はありません。始めるハードルは低いです。
3. 専用サーバー —負荷が高く、すべてを自分で管理する必要がある場合に使います。プラットフォームの上限に達してから移行しましょう。

リリースしたばかりでプログラマーではない人にとって、最も簡単なのは、手動でサーバーを設定せずに1つのコマンドでデプロイできるプラットフォームを使うことです。自分のサーバーへの移行は後で構いません。具体例を使ってこの手順を進めたい場合は、Coolifyを使ってバイブコーディング製プロジェクトを自分のサーバーにデプロイする方法をご覧ください。

アプリ、データベース、バックアップを分けるのはいつ？#

アプリ、データベース、バックアップの3つをひとつのかごに入れてはいけません。ユーザーが少ないうちは、すべてが一緒にあっても問題ありません。しかし、いつ分けるべきかを示す明確な兆候があります。

• アプリとデータベースを別々のマシンに置く。 兆候は、ピーク時にCPUとメモリの使用率が70～80％を超えた状態が続き、リクエストが遅くなり、アプリとデータベースが同じリソースを奪い合うことです。分離すれば、アプリに触れずにデータベースを強化でき、その逆も可能になります。
• 3-2-1バックアップルールに従う。 データのコピーを3つ、異なる種類の媒体に2つ、オフサイトに1つ置きます。これにより、ハードウェアの故障やランサムウェアから守れます。重要なのは、バックアップを自動化することです。

バックアップの頻度は、数時間分のデータを失うとどれほど困るかによって決まります。1時間分の決済記録の損失も許されないオンライン契約サービスなら、バックアップ間隔を1時間未満にするか、検証済みのトランザクションログとポイントインタイムリカバリー（PITR）が必要です。許容できるデータ損失から間隔を決め、サービス復旧までの時間は別にテストしてください。ブログなら1日1回で十分です。考え方は単純です。どの程度のデータ損失まで許容できるかを決め、それに合わせてバックアップを設定します。

製品をより本格的なインフラに移行する時期かどうか、一緒に判断してください。各項目を確認し、私に質問してください。

ピーク時のCPUとメモリの負荷はどの程度ですか。使用率が70～80％を超えた状態が続いていますか？

データベースとアプリは同じマシンにありますか、それとも別々ですか？

データベースの自動バックアップは設定されていますか？ そこからの復元をテストしましたか？

デプロイ前に確認するための環境の複製（ステージング）はありますか？
結果に基づいて、現状のままにするもの、最初に分離するもの、その理由を明確に提案してください。

もうひとつ、マネージドデータベースと自前のデータベースのどちらを選ぶかという問題があります。小さなチームなら、ほとんどの場合マネージドのほうが適しています。自前のほうがハードウェア代は安くても、保守に時間がかかります。自分ひとりで、インフラが製品の本質でないなら、その時間のコストはサーバー料金の差額を上回ります。

保守を自動化するには？#

手作業の保守は疲れます。監視と巡回エージェントの2つで、負担を減らせます。

監視には、目的の異なる2種類のツールを使います。

1. 「サイトは稼働している？」—稼働監視ツール（たとえばUptimeRobot）を使います。数分ごとに製品へアクセスし、停止したら通知します。無料プランもあります。
2. 「具体的に何が壊れた？」—エラートラッカー（たとえばSentry）を使います。アプリ内部のエラーを収集し、どこで、なぜ失敗したかを示します。

1つ目は製品が停止した事実を検知します。2つ目は、どの機能が、なぜ失敗したのかを示します。組み合わせれば、「顧客がサポートに連絡する前に障害に気づけるか」という問いに答えられます。

自動化の第2段階は巡回エージェントです。不動産会社を想像してください。朝7時にAIエージェントがウェブサイトへの問い合わせを読み、予約フォームが壊れていることに気づき、コードから原因を見つけ、説明付きの修正案を用意します。あなたが確認して「はい」と答えると、デプロイされます。順序が重要です。まずユーザーの問題を解決し（アクセス権を付与し、謝罪する）、次に原因とお金の問題を調査します。

AIに本番データベースへのアクセスを与える場合のルールがもうひとつあります。読み取り専用のユーザーを使い、個人データを中間層で隠して、エージェントには本人の本名ではなく「名前」として見せてください。そうすれば、間違いを犯しても本番データを物理的に削除したり破損させたりできません。本番データベースを消去した上の表の事例は、まさにこの制限がなかったことを示しています。すでに災害が起きてしまった場合は、AIがデータベースを削除したときの対処法をご覧ください。

製品を終了するタイミングは？#

保守の中で最も見過ごされがちなのは、いつ保守をやめるべきかを知ることです。たくさん作る人には誰でも、プロジェクトの墓場があります。作って、少し手を加えて、その後放置したプロジェクトです。それは普通のことで、失敗ではありません。失敗とは、費やした時間が惜しいからと、誰も使っていないものを何か月も引きずることです。

判断の目安となる期間は次のとおりです。

1. 2週間—アイデアがうまくいくかを見るのに十分な期間です。最初の実ユーザーが戻ってくるなら、続けましょう。反応がないのも答えです。
2. 3か月—上限です。3か月で軌道に乗らなければ、終了しましょう。バイブコーディングの速さを考えると、ひとつのアイデアの検証に6か月かけるのは長すぎます。

プロジェクトを終了するのは心理的につらいため、感情ではなく決断として扱いましょう。投資してきたプロジェクトを手放すのは、仕事ができない従業員を解雇するようなものです。不快ですが、雇い続けるほうがコストは高くつきます。

保守とは、製品を生きた状態に保ち、人々に役立つようにするための作業です。それ以外のもの、つまりgit、バックアップ、監視は、製品が毎日あなたの役に立つようになるまで支える道具にすぎません。

夕方のうちにAIで製品を作るのは、仕事の半分にすぎません。成長する製品を生きた状態に保ち、安全に維持すること。それが大人のためのバイブコーディングです。

次のステップはAilootです。