# AIで製品を作った—動いているものを壊さずに改善する方法 > リリース後の安全な製品保守：git、ロールバック、ステージング、シークレット保護、ホスティング、バックアップ、継続的な保守。6つのプロンプトはすべてそのまま収録。 Source: https://ailoot.ai/blog/ja/ai-product-maintenance-after-launch/ Canonical: https://ailoot.ai/blog/ja/ai-product-maintenance-after-launch/ Language: ja Publisher: Ailoot (https://ailoot.ai/) Translation: guide-033 Revision: sha256-1868549eb7300f4c8f355195cbce312f3f7f2fda1a9cce88f52d8ed10bbbef1d モデルの活用について詳しくは、[Ailootのドキュメント](https://ailoot.ai/docs/)をご覧ください。 ## 最も大変な作業がリリース後に始まるのはなぜ？
重要なポイント AIで製品を作る作業は、全体のうち小さな部分です。AI開発に投じた1ドルのうち、完成した製品になるのはわずか18セントで、44セントはAI自身が生み出したバグの修正に費やされます。こうしたことはすべてリリース後に起こります。大半のお金と労力を消費するのは、開発ではなく保守です。
夕方のうちにアプリを作り、リンクを公開して友人に送りました。ちゃんと動きます。ところが1週間後、初めての本物のユーザーがやって来て、少し変わった操作をしたら機能の半分が動かなくなりました。Claudeに修正を頼むと、ひとつは直ったけれど、別のところが壊れます。聞き覚えはありませんか？ ここで大きな疑問が浮かびます。最初のプロトタイプが動いた高揚感が過ぎた後、リリースした製品をどう維持していけばいいのでしょうか。これは「大人のためのバイブコーディング」と呼べるかもしれません。開発はワクワクするし、速く進みます。保守には冷静さが必要です。何を変えるのかを理解し、制御し続けなければなりません。多くの人がこの後半で失敗するのは、誰もその準備をしていないからです。 ある業界調査は2,444チームによる100万件以上のコード変更を分析し、AI開発に使われたお金の実際の行き先を算出しました。結果は次のとおりです。 | 1ドルの行き先 | 金額 | 実際には何を意味するか | |----|----|----| | 製品に反映された分 | **18セント** | ユーザーが実際に使える機能 | | AIのバグ修正 | 44セント | AIがすでに書いたコードを、壊れないように修正する費用 | | やり直し | 27セント | 依頼に沿わなかったAIのコードを書き直す費用 | | レビュー | 11セント | コードの内容を理解し、間違いを探す費用 | この数字について詳しくは、[「バイブコーディングに隠れたコスト」](https://ailoot.ai/blog/ja/vibe-coding-cost-time/)の記事をご覧ください。そちらでは、何にお金を払っているのかを説明しました。ここでの問いは別です。1ドルのうち44セントがバグ修正に使われています。この記事では、その割合がさらに増えないようにする方法を扱います。それを維持するための作業が保守です。 大人のようにバイブコーディングする人と、ニューラルネットの世話に追われるだけの人の違いは、リリース後に現れます。前者のコードベースは成長し、改善を加えても壊れません。1か月後、後者の製品は、怖くて触れないほどあちこちから漏れる仕組みになっています。ここからは、前者になる方法を説明します。 ## 実際に何が壊れるのか：リリース後に起きる5つの災難
重要なポイント AIで作った製品が壊れる原因は、短いリストにまとめられます。キーやデータベースが漏えいする、AIが本番環境を削除する、見知らぬ人に顧客の料金が請求される、などです。それぞれの災難には、予防策がひとつあります。
以下は、AIで作られた実在の製品に関する公開済みの事後報告です。数値や日付も記載されています。地雷原の地図だと思ってください。地雷はすでに誰かのところで爆発しており、避け方も分かっています。 | 起きたこと | 実際に起きたこと | 防げたはずの対策 | |----|----|----| | **150万件のキーが漏えい** | 公開データベースキーがページのコードにそのままあり、データベースへのアクセスがパスワードなしで開放されていた | すべてのテーブルで行レベルセキュリティ（RLS）を有効にする | | **170個のアプリが露出** | アプリが公開キーを使い、アクセスルールなしでブラウザーから直接データベースに接続していた | 販売前にデータベースのアクセス権を確認し、デフォルト設定を信用しない | | **AIが本番データベースを削除** | エージェントに本番データベースへのアクセス権が与えられ、禁止されていたにもかかわらず削除した | 本番データベースをエージェントの環境から物理的に隔離する | | **ブラウザー内の決済キー：\$87,500** | 決済システムのキーがページのコードに入り、発見された結果、175人の顧客に請求が行われた | シークレットはサーバー上だけに保管し、ブラウザーには置かない | | **写真と書類72,000件が露出** | ファイルストレージにパスワードがなく、リンクを知っていれば誰でも自撮り写真や身分証明書をダウンロードできた | ファイルストレージではデフォルトで認証を必須にする | 5件すべてに共通する根本原因があります。AIはデフォルトで、「今すぐ動く」ように作ります。「1か月後に負荷がかかっても安全に動く」ようには作りません。自分のコンピューターで開発している間は、その違いに気づけません。悪意を持った見知らぬ人が現れたときに初めて明らかになります。 問題は、コードを手作業で書かないことではありません。こうしたやり方で仕事をする人は大勢います。問題は「データベースは保護されているか」と確認しないことです。次に、その問いを代わりに確認するプロンプトを紹介します。 ## 最初の安全網はgitと「昨日の状態に戻す」こと
重要なポイント リリース後の最大の安全網は、あらゆる変更を元に戻せることです。これを支える層は2つあります。プロジェクトの恒久的な履歴としてのgitと、「直前の操作を取り消す」ためのClaude Codeのローカルスナップショットです。製品を他の人に使ってもらう前に、非公開リポジトリと、無視リストに入れたシークレットファイルを用意することが最低限必要です。
Claudeが何かを壊したとき、「昨日の状態に戻す」ボタンが必要です。技術的には、そのボタンはgitと呼ばれます。聞こえるほど難しくはありません。 プログラマーでなくても知っておきたい用語は3つです。 1. **リポジトリ** — 通常はGitHub上に保存するプロジェクトのフォルダーです。コードのコピーが保存され、コンピューターだけに置かれることはありません。 2. **コミット** — 復帰ポイントです。コードに「この状態で保存」と伝えるようなものです。各コミットは、戻ることのできる目印になります。 3. **デプロイ** — 移動です。コードはコンピューター上にあり、自分にしか動きません。デプロイすると外部サーバーに送られ、誰でも使えるようになります。 最近のコミットがあれば、何かが壊れても一言で元に戻せます。本当に一言です。
プロンプト：動いていたバージョンに戻す ``` 何かを壊してしまいました。昨日はすべて動いていたのに、今日は動きません。すべて問題なかった最新のコミットを見つけ、そこから何が変わったかを示して、その状態にプロジェクトを戻してください。 ```
他の人に製品を見せる前に、すぐに徹底しておくべきルールが2つあります。 - **リポジトリは非公開にする。** 公開しないでください。そうしないと、誰でもコードとその中身を読めてしまいます。 - **シークレットファイルを無視リストに入れる。** キー、パスワード、データベースの認証情報は別ファイル（通常は`.env`）に置き、そのファイルをリポジトリに入れないでください。`.gitignore`に`.env`の行を追加すれば、シークレットは自分の手元に残ります。 Claude Codeで変更を安全に戻す方法については、別の記事があります：[Claude Codeで変更をロールバックする方法](https://ailoot.ai/blog/ja/claude-code-undo-changes/)。復帰ポイントなしで作業するのは、安全網なしで綱渡りをするようなものです。遅かれ早かれ落ちてしまいます。 ## `/rewind`で元に戻るものと、戻らないものは？
重要なポイント Claude Codeには`/rewind`コマンドがあります。各編集の前にスナップショットを取り、選択した時点までコードと会話を戻します。ただし、Claude自身が変更したファイルだけが対象です。インストール済みパッケージ、クラウドへのアップロード、データベースの変更、外部サービスへの呼び出しには触れません。恒久的な履歴はgit、「/rewind」は手早く使うローカルの「取り消し」です。
Claude Codeは、自ら変更を加える前に状態のスナップショットを取ります。`/rewind`コマンド（またはEscキーを2回押す操作）を使うと、ファイルと会話の両方が選択した時点まで戻ります。便利です。5分前に機能を壊したなら、5分前に戻れます。 ただし、初心者がデータを失う原因となる落とし穴があります。`/rewind`ですべてが元に戻るわけではありません。 | `/rewind`で元に戻るもの | 元に戻らないもの | |--------------------------------------|-------------------------------------| | Claudeが行ったファイル編集 | パッケージのインストール（`npm install`） | | このセッションでの会話 | コードのクラウドへのアップロード（`git push`） | | プロジェクトのローカル状態 | データベースの変更 | | \- | 外部サービスの呼び出しと支払い | Anthropicはこう明言しています。スナップショットはローカルの「取り消し」ボタンで、gitは恒久的な履歴です。スナップショットはバージョン管理を補完しますが、置き換えるものではありません。

スナップショットはローカルの「取り消し」機能で、Gitは恒久的な履歴です。スナップショットは完全なバージョン管理を補完しますが、置き換えるものではありません。

— Claude Codeドキュメント、https://code.claude.com/docs/en/checkpointing
プログラマーでない人にとっての実際的な教訓は、Claudeが機能を壊したときには`/rewind`が助けになるということです。しかし、データベースの行を削除したり、コードをクラウドにアップロードしたりしてしまった場合、元に戻せるのはgitとデータベースのバックアップだけです。両方の層を維持しましょう。素早く戻すにはスナップショット、プロジェクトの恒久的な履歴にはコミットを使います。 ## 動いているものを壊さずに改善するには？
重要なポイント 改善時の主な危険は、ロジックが少しずつずれていくことです。AIにひとつの修正を頼むと、バイブコーディングは結果が一定しないため、隣接するロジックまでひそかに変更されることがあります。対策は黄金律です。ほかの人に説明できないコードはデプロイしないこと。小さな変更を行い、そのたびにコミットし、何が変わったかを必ず正確に確認しましょう。
2人に1人は、このループにはまります。AIに小さなバグの修正を頼みます。もっともらしい変更が提案されます。その変更が別のものを壊します。新たな問題を直すよう頼むと、さらに2つ問題が出てきます。それが続きます。 このループが起きるのは、バイブコーディングの結果が一定しないからです。同じプロンプトでも、2回頼めば違うコードが出てきます。そのため、編集のたびに周囲のロジックがひそかに変わることがあります。割引のしきい値が10％から12％に動いたり、検証ルールの挙動が変わったりします。こちらで確認していなくても、警告がひとつも出なくても起きます。これはロジックのずれと呼ばれ、収益につながるもの、つまり価格、アクセス権、支払いを静かに損ないます。 このずれを防ぐルールがあり、壁に貼っておけるほど簡潔です。一語一句、ほかの人に説明できないコードはコミットしない、というものです。 実際には、動いているコードを変更する前に使える定型の指示にできます。AIに小さな手順で進めさせ、何が変わったかを正確に示させます。
プロンプト：安全な変更を計画する ``` コードを変更する前に、次のことをしてください。 現在の動作状態を、別の復帰ポイント（コミット）として保存してください。 何をどのファイルで変更する予定か、正確に言葉で説明してください。 私の依頼を解決するために必要な、可能な限り小さな変更だけを行ってください。余計なことはしないでください。 変更箇所を示し、それぞれを説明してください。私が別の人に説明できるようにしてください。 私が頼まない限り、価格設定、アクセス権、決済のロジックには触れないでください。 ```
数週間を無駄にしないためのもうひとつの原則は、作業範囲を守ることです。ひとつの問題にひとつの変更、短時間で実装します。ひとつのプロンプトでプロジェクトの半分を書き直すようAIに頼んではいけません。プロの開発者でも、必要なのはボタンひとつなのにUber全体を作り始め、何か月もかけてしまうことがあります。そんなことをする必要はありません。 ここで説明していることはすべて、コンテキストの管理が土台になっています。AIが隣接するロジックを壊さないようにするには、プロジェクトのルールを覚えておく必要があります。 ## 公開する前に変更を確認するには？
重要なポイント 実際のユーザーに変更を公開する前に、決済、登録、アクセス権、価格などの主要なシナリオで動作を確認してください。最終確認には、本番環境のテスト用コピー（開発ツールではステージングと呼ばれます）が最適です。開発環境で作り、テスト用コピーで確認し、本番環境にデプロイする、という順序です。リリースには必ずリスクがありますが、テスト用コピーでそのリスクを取り除けます。
「自分のコンピューターでは動く」と「誰にでも動く」の間には、初心者が飛ばしがちな中間段階があります。テスト用コピーです。実際のユーザーに見せる前に変更を確認できる、本番環境の別のスナップショットです。作業サイクルは次のようになります。 1. 変更を作り、自分で動作を確認する（開発）。 2. 本番環境のコピーで、実際のユーザーがいないステージングにデプロイする。 3. 主要なシナリオを実行し、何も変わっていないことを確認する。 4. その後で初めて本番環境にデプロイする。 リリース後に重要なのは、リリースには毎回リスクがあるからです。小さなコード変更でアカウントへのサインインが壊れることがあります。設定がひとつ足りないだけで、製品全体が停止することもあります。ステージングなら影響が出る前に問題を検出できます。本番環境では顧客を失います。 毎回すべてを手作業で確認しなくてすむように、重要な領域で新バージョンの動作が旧バージョンと同じかを比較するプロンプトをAIに渡しましょう。
プロンプト：リリース前の回帰チェック ``` 変更をデプロイしようとしています。製品の主要なシナリオを順に確認し、これまでどおり動作することを確かめてください。 新規ユーザーの登録とサインイン。 決済と、決済後のアクセス権付与。 アクセス権：一般ユーザーが他人のデータや管理画面を見られないこと。 主要なビジネスロジックの数値（価格、割引、上限）が変わっていないこと。 以前のバージョンと動作が異なる点があれば、停止して、何が変わったかを正確に示してください。 ```
## シークレットはどこにある？初心者にとって最大の穴
重要なポイント リリース後に最もよく起きる、そして最も高くつくミスは、ページのコードにシークレットを置くことです。データベース、決済システム、外部サービスのキーはサーバー上の環境変数だけに置き、ブラウザーには決して置いてはいけません。この穴によって、ある製品では150万件のキーが漏れ、ある創業者の顧客には合計\$87,500が請求されました。
他のどんな問題よりも多くの製品を停止させる最大の地雷について、詳しく説明します。AIがコードを書くとき、キーをすぐ使える場所、つまりブラウザーで開くページのコードに直接入れるのが最も簡単です。開発中はその違いに気づきません。しかし、ブラウザーに届くものは何でも、開発者ツールを開けば誰でも読めます。 顧客に\$87,500が請求された創業者は、後になって、ひとつのプロンプトで防げたはずだと話しました。請求は最終的に取り消されましたが、返金されない手数料と失われた安心は戻りませんでした。そのプロンプトを紹介します。
プロンプト：シークレットの保存場所を確認する ``` プロジェクト全体を確認して、秘密鍵がブラウザーに渡ることがないようにしてください。 データベース、決済システム、外部サービスのすべてのキーを見つけてください。 それぞれがサーバー上の環境変数にのみ保存され、ページのコードには含まれていないことを確認してください。 プロジェクトの履歴も確認してください。過去にキーが誤って含まれたことはありますか？ シークレットが見つかった場所をすべて一覧にし、それぞれに必要な対応を示してください。 ```
近くにある次の地雷は、ブラウザー側だけでアクセス権を確認することです。ページのコードが「管理画面を表示するか」を判断しているなら、誰でもその判断を回避できます。アクセス権は必ずサーバーで確認してください。データベースは権限のあるユーザーにだけデータを返さなければなりません。そのための仕組みが行レベルセキュリティ（RLS）であり、すべてのテーブルで有効にする必要があります。 アクセスを販売したり、ほかの人に使ってもらったりする前に、製品のセキュリティ全般を監査してください。
プロンプト：リリース後にプロジェクトを監査する ``` 攻撃者の視点でプロジェクトを調べ、セキュリティ上の穴を見つけてください。 ブラウザーに渡るコードやプロジェクトの履歴に、秘密鍵が保存されていませんか？ すべてのデータベーステーブルで行レベルセキュリティ（RLS）が有効になっていますか？ また、アクセス権はブラウザーだけでなくサーバーでも確認されていますか？ データベースの自動バックアップは設定されていますか？ そこから復元できることを確認したことはありますか？ 本番データベースは、AIエージェントが実行される環境から隔離されていますか？ 各項目について、問題ないか、または何を修正する必要があるかを正確に教えてください。 ```
バイブコーディングのセキュリティについては、別の詳しい記事があります：[バイブコーディングで作ったアプリを安全にする方法](https://ailoot.ai/blog/ja/vibe-coding-security/)。ルールは単純です。AIがデフォルトで行ったことは、確認が済むまで安全でないものとして扱ってください。 ## 製品のホスティング先：ホスティングの段階
重要なポイント 製品をどこに置くかは、誰が使うかによって決まります。個人情報を扱わないテストや小規模プロジェクトなら、無料のホスティングが使えます。データベースがあり、実際のユーザーがいる製品には、1つのコマンドでデプロイできるプラットフォームを使いましょう。負荷が高くなったら、自分のサーバーが次の段階です。最初から複雑な構成にする必要はありません。
最初から自分のサーバーを借りて手作業で設定する必要はありません。始めたばかりの時期には難しく、時間を奪われます。製品の成長に合わせて、次の段階を進めていきましょう。 1. **無料ホスティング**（たとえばVercel）—自分用、テスト、小規模プロジェクト向けです。利用者のいる地域でプラットフォームが使え、個人データを保存しない場合に適しています。 2. **1つのコマンドでデプロイできるプラットフォーム**（Railway）—バックエンドとデータベースがある場合に使います。1つのコマンドでデプロイでき、サーバーを設定する必要はありません。始めるハードルは低いです。 3. **専用サーバー** —負荷が高く、すべてを自分で管理する必要がある場合に使います。プラットフォームの上限に達してから移行しましょう。 リリースしたばかりでプログラマーではない人にとって、最も簡単なのは、手動でサーバーを設定せずに1つのコマンドでデプロイできるプラットフォームを使うことです。自分のサーバーへの移行は後で構いません。具体例を使ってこの手順を進めたい場合は、[Coolifyを使ってバイブコーディング製プロジェクトを自分のサーバーにデプロイする方法](https://ailoot.ai/blog/ja/coolify-claude-code-deploy/)をご覧ください。 ## アプリ、データベース、バックアップを分けるのはいつ？
重要なポイント 製品が小さいうちは、アプリとデータベースを同じマシンに置いて構いません。ピーク時の負荷が70～80％を超えたままになったり、データベースとアプリが互いを遅くし始めたりしたら、分離する時期です。バックアップには3-2-1ルールを適用します。コピーを3つ、異なる種類の媒体に2つ、オフサイトに1つです。そしてバックアップは「思い出したとき」ではなく、自動で取得しなければなりません。
アプリ、データベース、バックアップの3つをひとつのかごに入れてはいけません。ユーザーが少ないうちは、すべてが一緒にあっても問題ありません。しかし、いつ分けるべきかを示す明確な兆候があります。 - **アプリとデータベースを別々のマシンに置く。** 兆候は、ピーク時にCPUとメモリの使用率が70～80％を超えた状態が続き、リクエストが遅くなり、アプリとデータベースが同じリソースを奪い合うことです。分離すれば、アプリに触れずにデータベースを強化でき、その逆も可能になります。 - **3-2-1バックアップルールに従う。** データのコピーを3つ、異なる種類の媒体に2つ、オフサイトに1つ置きます。これにより、ハードウェアの故障やランサムウェアから守れます。重要なのは、バックアップを自動化することです。 バックアップの頻度は、数時間分のデータを失うとどれほど困るかによって決まります。1時間分の決済記録の損失も許されないオンライン契約サービスなら、バックアップ間隔を1時間未満にするか、検証済みのトランザクションログとポイントインタイムリカバリー（PITR）が必要です。許容できるデータ損失から間隔を決め、サービス復旧までの時間は別にテストしてください。ブログなら1日1回で十分です。考え方は単純です。どの程度のデータ損失まで許容できるかを決め、それに合わせてバックアップを設定します。
プロンプト：サーバーを分ける時期？ ``` 製品をより本格的なインフラに移行する時期かどうか、一緒に判断してください。各項目を確認し、私に質問してください。 ピーク時のCPUとメモリの負荷はどの程度ですか。使用率が70～80％を超えた状態が続いていますか？ データベースとアプリは同じマシンにありますか、それとも別々ですか？ データベースの自動バックアップは設定されていますか？ そこからの復元をテストしましたか？ デプロイ前に確認するための環境の複製（ステージング）はありますか？ 結果に基づいて、現状のままにするもの、最初に分離するもの、その理由を明確に提案してください。 ```
もうひとつ、マネージドデータベースと自前のデータベースのどちらを選ぶかという問題があります。小さなチームなら、ほとんどの場合マネージドのほうが適しています。自前のほうがハードウェア代は安くても、保守に時間がかかります。自分ひとりで、インフラが製品の本質でないなら、その時間のコストはサーバー料金の差額を上回ります。 ## 保守を自動化するには？
重要なポイント 保守を手作業で行う必要はありません。基本を押さえるには、2つの監視ツールを使います。ひとつはサイトが稼働しているかを確認し、もうひとつは製品内部のエラーを検出します。さらに、朝の巡回をAIエージェントに任せることもできます。ユーザーからの報告を読み、壊れた部分を見つけ、適用できる修正を用意させます。ただし、メール送信や一括処理はデータベース全体に一度に行わず、バッチに分けて実行してください。
手作業の保守は疲れます。監視と巡回エージェントの2つで、負担を減らせます。 監視には、目的の異なる2種類のツールを使います。 1. **「サイトは稼働している？」**—稼働監視ツール（たとえばUptimeRobot）を使います。数分ごとに製品へアクセスし、停止したら通知します。無料プランもあります。 2. **「具体的に何が壊れた？」**—エラートラッカー（たとえばSentry）を使います。アプリ内部のエラーを収集し、どこで、なぜ失敗したかを示します。 1つ目は製品が停止した事実を検知します。2つ目は、どの機能が、なぜ失敗したのかを示します。組み合わせれば、「顧客がサポートに連絡する前に障害に気づけるか」という問いに答えられます。 自動化の第2段階は巡回エージェントです。不動産会社を想像してください。朝7時にAIエージェントがウェブサイトへの問い合わせを読み、予約フォームが壊れていることに気づき、コードから原因を見つけ、説明付きの修正案を用意します。あなたが確認して「はい」と答えると、デプロイされます。順序が重要です。まずユーザーの問題を解決し（アクセス権を付与し、謝罪する）、次に原因とお金の問題を調査します。
警告 データベース全体に一度に一括処理を実行してはいけません。全員に一斉メールを送ると、サーバーに負荷がかかり、メールの半分が迷惑メールに入ることもあります。適切な方法は、1日あたり100～1,000件を、数時間に分散してバッチ送信することです。店舗、クリニック、サービスなど、顧客データベースならどれにも当てはまります。
AIに本番データベースへのアクセスを与える場合のルールがもうひとつあります。読み取り専用のユーザーを使い、個人データを中間層で隠して、エージェントには本人の本名ではなく「名前」として見せてください。そうすれば、間違いを犯しても本番データを物理的に削除したり破損させたりできません。本番データベースを消去した上の表の事例は、まさにこの制限がなかったことを示しています。すでに災害が起きてしまった場合は、[AIがデータベースを削除したときの対処法](https://ailoot.ai/blog/ja/ai-deleted-database-recovery/)をご覧ください。 ## 製品を終了するタイミングは？
重要なポイント すべての製品を維持すべきとは限りません。終了すべきものもあります。アイデアが実現可能だと示す期間を2週間設け、上限は3か月にします。軌道に乗らなければ、投じたものが惜しくても製品を終了してください。製品を殺すのは悪いコードではなく、人々が使うのをやめることです。誰にでも未完成プロジェクトの墓場があるものです。それは普通のことです。
保守の中で最も見過ごされがちなのは、いつ保守をやめるべきかを知ることです。たくさん作る人には誰でも、プロジェクトの墓場があります。作って、少し手を加えて、その後放置したプロジェクトです。それは普通のことで、失敗ではありません。失敗とは、費やした時間が惜しいからと、誰も使っていないものを何か月も引きずることです。 判断の目安となる期間は次のとおりです。 1. **2週間**—アイデアがうまくいくかを見るのに十分な期間です。最初の実ユーザーが戻ってくるなら、続けましょう。反応がないのも答えです。 2. **3か月**—上限です。3か月で軌道に乗らなければ、終了しましょう。バイブコーディングの速さを考えると、ひとつのアイデアの検証に6か月かけるのは長すぎます。 プロジェクトを終了するのは心理的につらいため、感情ではなく決断として扱いましょう。投資してきたプロジェクトを手放すのは、仕事ができない従業員を解雇するようなものです。不快ですが、雇い続けるほうがコストは高くつきます。 保守とは、製品を生きた状態に保ち、人々に役立つようにするための作業です。それ以外のもの、つまりgit、バックアップ、監視は、製品が毎日あなたの役に立つようになるまで支える道具にすぎません。
### 出典 - [Anthropic - Claude Codeのチェックポイント](https://code.claude.com/docs/en/checkpointing) - [Anthropic - Claude Codeのセキュリティモデル](https://code.claude.com/docs/en/security)
夕方のうちにAIで製品を作るのは、仕事の半分にすぎません。成長する製品を生きた状態に保ち、安全に維持すること。それが大人のためのバイブコーディングです。 次のステップは[Ailoot](https://ailoot.ai/)です。 ## AIで製品を作った—動いているものを壊さずに改善する方法：よくある質問 ### 決済のあるサービスは、どの頻度でバックアップしますか？ 失ってよいデータの最大量から間隔を決めます。1時間分の損失が許されないなら1時間より短い間隔か、検証済みのトランザクションログとPITRが必要です。復元に実際にかかる時間もテストしてください。 ### 稼働監視だけで、製品の健全性を確認できますか？ いいえ。稼働監視はサイトが応答するかを示し、エラートラッカーはアプリ内部の失敗を調べます。公開前にステージングで主要な利用の流れを確認し、バックアップを復元できることも検証してください。 ## Ailoot · 企業とそのプロジェクト群 Ailootは、蓄積した運営経験、幅広い顧客基盤、安定したサービス、継続的なKPI管理を基盤としています。 企業とそのプロジェクト群：数百万の顧客、毎月数十億規模の売上。 Ailootはこの運営経験を、お客様の製品、エージェント、アプリケーション、自動化でAI機能を利用するためのAPIアクセスに活かしています。