結論から書きます。筆者の考えでは、AIコーディングで作ったアプリや業務システムを本番運用するなら、多くは作り直さずに「直して使う」——壊れやすい箇所を後から補強する（これを「硬化」、英語でハードニングと呼びます）——のが、安く速い選択です。 ただし、データの持ち方や「誰が何を見てよいか」の設計が根本から業務と合っていない場合は、一部または全体を作り直すほうが安くなることがあります。どちらに当たるかは、デモの見た目ではなく、この記事の判断表にある確かめられるサインで決めます。
この記事は、次のような方に向けて書いています。
- Claude Code・Cursor・Lovable・v0・Bolt などで作ったアプリや業務システムが、すでに動いている、またはこれから本番で使う予定
- そのシステムが、顧客の個人情報・決済・業務の要（受発注、請求、在庫など）を扱っている
- 個人事業主や経営者、またはCTO（技術の最終責任者）がいない会社で、開発の責任を負っている
コードが読めなくても判断できるように書いています。エンジニア向けの詳細は、後半の「エンジニア向け」の節に分けました。
先にお断りしておくと、筆者はAIで作ったアプリの診断や開発を有料で引き受けています。だからこそ、お金をかけなくてよいケースも、はっきり書きます。
1. 判断表 — 直して使う／一部作り直す／作り直す
表の前に、用語を2つだけ説明します。データモデルは「どんな情報を、どんな単位とつながりで保存するか」の設計です。認可モデルは「ログインした人が、誰のデータを見て・変えてよいか」のルールです。ログイン（本人確認）とは別の仕組みで、筆者の見るところ、AIで作ったアプリで抜けやすいのはこちらです。
もう1つ、表を使う前の前提があります。「何が正しい動作か」を説明できることです。これは直すか作り直すかを分けるサインではなく、どちらを選ぶにも必要な前提です。誰も説明できないなら、直したつもりが仕様の変更になる危険があり、作り直しても「何を作り直すのか」が決まりません。説明する人は、あなたでかまいません。どちらを選ぶにしても、まずそれを書き出すのが最初の作業です（書き方は3章）。
| 確かめるサイン | 直して使う（硬化） | 一部作り直す | 作り直す |
|---|---|---|---|
| 問題の散らばり方 | 特定の機能に集中している（例: 決済の処理だけ） | 1つの領域の全体に広がっている（例: 権限の判定すべて） | 同じ種類の問題が、ほぼすべての画面・処理にある |
| データモデル | 業務の実態と合っている | 一部の表だけ実態と合わない | 根本の単位が違う（例: 会社ごとに分けるべきデータに、会社の区別が無い） |
| 認可モデル | ルールは正しく、書き漏れや、画面側にしかない判定があるだけ（サーバー側に移せば済む） | 一部の領域だけ、権限の考え方そのものが無い・間違っている（例: ある機能だけ、データがどの会社のものかを区別していない） | データを分ける境界が、設計のどこにも無い |
| 自動テスト | 主要な流れにある、または足せる | 一部の処理が絡み合っていて足しにくい | 処理全体が絡み合い、テストを足す足場が無い |
| 本番の顧客データ | 入っている（作り直すとデータ移行が伴う） | 入っている（作り直す領域の分だけ移す） | まだ無い、または捨ててよい |
| 他の人が保守できる構成か | 広く使われている構成で、コードが手元にある | 一部が特殊なサービスに依存している | 作ったツールの外に持ち出せない／扱える人が見つからない |
| これから足したいこと | 今の延長 | 一部の領域で大きく変わる | 作るもの自体が変わった |
読み方は単純です。ほとんどの行が左の列に入るなら、直して使う。 右の列に入る行があっても、それが1つの領域に限られるなら、その領域だけを作り直す。右の列が複数の行にまたがり、しかも本番の顧客データがまだ無い——このときに初めて、全体の作り直しが安い候補になります。
では、右の列が複数の行にまたがるのに、本番の顧客データがすでに入っている場合はどうするか。たとえば、会社ごとに分けるべきデータに会社の区別が無いまま、実際の顧客が使っている場合です。筆者が勧めるのは、画面ごとに判定を足して継ぎはぎすることではなく、根本に問題のある層——データの持ち方や権限の判定——だけを、データの移行も含めて作り直すこと（一部作り直す）です。
表の読み違い（反例）
- 「AIが書いた」「コードが汚い」は、作り直しの理由になりません。 見た目が整っていなくても、構造が素直なら直すほうが安く済みます。
- 「穴が多い」も、それだけでは理由になりません。 見つかった穴が多くても、原因が共通の処理の書き漏れ1か所なら、直す場所は1つです。数より、散らばり方と根の深さを見ます。
- 「テストが無い」も理由になりません。 テストは後から足せます。硬化の作業の中心は、むしろテストを足すことです。
- 逆に「動いているから、直せば使える」とも限りません。 会社ごとにデータを分ける境界が設計に無いのに、画面ごとに判定を足していくと、継ぎはぎが増えて漏れやすくなります。
- 「作り直せばきれいになる」とも限りません。 同じ作り方——AIの出力を確かめずにそのまま使う——で作り直せば、同じ種類の穴がまた入ります。
デモで決めない
デモ（画面を操作して見せること）で分かるのは、うまくいく場合に動くかだけです。他人のデータが見えないか、同じボタンが同時に2回押されたらどうなるか、外部のサービスが落ちたらどうなるか——本番で問われるこれらは、画面を触っても分かりません。
ですから、デモの印象で「直せば使える」とも「作り直したほうが早い」とも決めないでください。判断の材料は、コードを読んだうえでの所見——どこに、どんな問題が、どれだけ散らばっているか——です。
決める順序
- 無料のセルフ診断で、明らかな穴があるかを確認する（3章）
- 「必ず成り立つべきこと」——何が正しい動作か——を書き出す（3章）
- コードを読んだ所見を、優先度つきで出してもらう
- 所見を上の判断表に当てはめる
- 直すなら、お金と個人情報に直結するものから順に直す
2. 放置すると何が起きるか
以下は、説明のために作った架空の例です。実在の会社・事例ではありません。AIで作ったアプリで抜けやすい箇所（6章）から起こりうる形を、業務の言葉に置き換えたものです。
架空の例1: 他の顧客の予約が見える
ある店の予約システムで、予約確認画面のURLの末尾にある番号を1つ変えると、別のお客さまの氏名と電話番号が表示される。画面のメニューには他人の予約へのリンクが無いため、作った本人は気づいていない。
これは「ログインしているか」は確かめていても、「その予約が本人のものか」を確かめていない状態です。個人情報保護委員会は、本人の数が1,000人を超える漏えいや、不正の目的をもって行われたおそれがある漏えいなどを、国への報告が義務となる事態として示しています（漏えいの「おそれ」の段階を含みます）。国への速報は「速やかに」行うこととされ、同委員会のガイドライン（通則編）は、その目安を、事態を知った時点から概ね3〜5日以内としています（個別の事案によります）。どの事態に当たるかは状況によるため、参考文献の同委員会のページとAIアプリを商用公開する前の法務チェックで確認してください。自分で確かめる手順は「ログインしてる風」と本物の権限チェックの違いにあります。
架空の例2: 注文が二重に作られる
ネットショップで、決済サービスから届く「支払い完了」の通知を受けて注文を確定している。通知が2回届いた日に、同じ注文が2件作られ、在庫が二重に減り、発送も2回手配された。
決済サービスから自動で届くこうした通知の仕組みを Webhook、それを受け取る窓口を Webhook エンドポイントと呼びます。決済サービスの Stripe は公式ドキュメントで、「Webhook エンドポイントは、同じイベントを複数回受信する可能性があります」と説明し、処理したイベントのIDを記録して、記録済みのものは処理しないようにする方法を示しています。通信エラーのあとに送り直した依頼が二重の処理にならないようにする仕組み（冪等性キー）も用意しています。受け取る側がこれらを作り込んでいなければ、二重の注文や二重の請求につながります。詳しくはAIに決済を作らせたとき、二重課金が起きる理由と防ぎ方で解説しています。
架空の例3: 漏れた鍵で、他人の利用分を請求される
AIの文章生成サービスを呼び出す鍵（APIキー）が、ブラウザに送られるコードや、公開されたGitHubのリポジトリ（コードの保管場所）に入っていた。第三者がその鍵で大量に呼び出し、翌月、身に覚えのない利用料の請求が届いた。
鍵がコードに入っていたなら、ファイルから消すだけでは足りません。GitHub の公式ドキュメントも、漏れた秘密情報への最初の対処は、履歴から消すことではなく、その鍵を無効化・再発行することだと説明しています。仕組みはAIが書いた「APIキー」がなぜ他人に見えるのか、上限の設定方法は公開したら請求が跳ねた — 従量課金の事故と、上限の設定方法にまとめています。
架空の例4: エラーは出ないのに、請求額が間違っている
社内の請求書作成システムで、割引の計算に条件の漏れがあり、一部の取引先への請求額が数か月にわたって少なかった。エラーは一度も出ていないので、誰も気づかなかった。
この「動いているのに間違っている」状態は、エラーの通知では見つかりません。「動いてるのに間違ってる」— AI生成コードの静かなバグで詳しく扱っています。
どの例も、画面を触るデモでは見つかりません。
3. 自分でできること・専門家に頼む目安・頼まなくてよいケース
頼まなくてよいケース
自分や仲間内だけで使う試作品で、ログインが無く、個人情報を保存せず、決済が無く、外から直接呼べる入口（公開API）もファイルのアップロード欄も無く、従量課金のサービス（AIのAPIなど）も呼んでいない——つまり、盗まれるもの・壊されるもの・請求されるものが無い——なら、お金を払って人に見てもらう必要は低いでしょう。無料のセルフ診断と、AIでの修正で足りることが多いです。
ただし、「ログインが無いから大丈夫」とは限りません。 次のどれかがあれば、ログインが無くても狙われるものがあります。
- 外から直接呼べる入口（API）がある: 画面を通さずに直接呼べば、画面に無い操作もできてしまいます
- ファイルのアップロード欄がある: 誰でも、何でも置けてしまうかもしれません
- データを保存している（問い合わせフォームの内容など）: 保存先が誰でも読める設定になっていないかが問題になります。たとえば Supabase の公式ドキュメントは、ブラウザに置く公開用の鍵について「誰でも読めるので、行レベルセキュリティ（RLS）が許す範囲にしか届かない」と説明し、すべてのテーブルで RLS を有効にするよう求めています。守っているのはログイン画面ではなく、データベース側の設定だということです
- 従量課金のサービスを呼んでいる（AIの文章生成など）: ログインが無いということは、誰でも呼べるということです。請求はあなたに来ます
判断の基準は「ログインがあるか」ではなく、盗まれるもの・壊されるもの・請求されるものが無いかです。「そもそも人のセキュリティ診断が要るのか」は、AIで作ったアプリに、人によるセキュリティ診断は必要？の判断表で、預かるデータごとに詳しく整理しています。
自分でできること
- 無料の20問セルフ診断: 公開前セルフ診断は登録不要で、「はい／いいえ／わからない」で答えると、危険な順に並んだ結果と、そのままAIに貼れる修正指示が出ます。回答はブラウザの外に送られず、保存もされません。
- URLの番号を変えてみる: 2つのアカウントを用意し、相手のデータが見えないかを確かめます（例1の確認）。
- 鍵がブラウザやGitHubに出ていないか確かめる: 出ていたら、消すだけでなく作り直します（例3）。
- 従量課金のサービスに上限を設定する: 鍵が漏れたときの被害に、天井を作れます。
- 「必ず成り立つべきこと」を書き出す: 「キャンセルした予約は売上に入らない」のような文で、10個ほど。これはあなたにしか書けず、直すにも作り直すにも、いちばん役に立つ材料です。
AIに「全部直して」と頼むこと自体は悪くありません。ただ、AIは目の前の指示を通すことを優先するので、全体の整合までは保証しません。直させたら別の箇所が壊れる、を繰り返しているなら、それは自力の範囲を超えたサインです。
専門家に頼む目安
次のどれかに当てはまるなら、本物の顧客データを入れる前に（すでに入っているなら、早めに）人の目を入れる価値があります。
- 他人の個人情報を業務で預かっている
- 決済がある、お金や在庫が動く
- 複数の会社やチームのデータを1つのシステムで扱う（法人向け）
- 請求・受発注・給与など、止まると業務が止まる処理を任せている
- セルフ診断で「わからない」が多く残った
- 直すか作り直すかを決めたい（これはコードを読まないと決められません）
人の診断で何が届くのかは、架空のアプリで作った公開前ライト診断のレポート見本で先に確認できます。直すか作り直すかまで決めたいときは、コードを読んだうえで、何から直すべきかを優先度つきで並べてもらう相談やレビューを頼み、その所見を1章の判断表に当てはめます。社内に技術の判断をする人がいないまま、この先も開発を続けるなら、外部の開発責任者（CTO代行・技術顧問）という形もあります。
4. 費用を上下させる要因
直す作業も作り直す作業も、金額は範囲が決まるまで出せません。範囲を大きく動かすのは、コードの量よりも次の要因です。
| 要因 | 費用が下がる方向 | 費用が上がる方向 |
|---|---|---|
| 問題の散らばり方 | 特定の箇所に集中している | 全体に散らばっている |
| つながっている外部サービス | 少ない | 決済・メール・AI・ファイル保存など多い |
| 利用者の役割 | 1種類 | 一般・管理者・会社ごとなど複数 |
| 頼む範囲 | 所見（何をどの順で直すか）まで | 修正の実装・テストの整備・再確認まで |
| 作り直す場合のデータ | 移すデータが無い | 本番データの移行がある |
このほか、何が正しい動作かのメモがあるか、本番と手元のコードが一致しているか、試験用の環境があるかといった準備の状態も金額を動かします。こちらは依頼する側が前もって整えられるので、エンジニアに相談・引き継ぐときの準備の「見積もりが決まる要因」の表にまとめています。
この記事では、直す・作り直す作業の金額は示しません。依頼の形と、公開している料金（いずれも「〜」からの目安）は次のとおりです。
- 公開前ライト診断（約3営業日）: 公開してはいけない致命的な穴——RLS（データベースの行ごとの閲覧制限）の未設定、秘密情報の露出、所有者チェックの欠落、決済の二重処理——の有無の判定、非エンジニア向けのレポート、AIに貼れる優先度つきの修正指示、30分の説明通話。料金はレポート見本のページに載せています。範囲を致命的な穴に絞った診断なので、直すか作り直すかの判断は含みません。
- 既存のコードを読んでもらう相談: 料金ページのスポット技術相談（¥15,000/時間〜。既存コードのレビューにも使えます。初回30分は無料）で受けられます。
- 修正の実装や作り直し: 範囲を決めてから、料金ページのプランの形で見積もります。監査で見つかったセキュリティの穴の修正は、監査・修正の実装・再監査をまとめた「伴走・修正実装」としても承っています（監査のページ）。
5. 依頼する前の準備
準備の全体はエンジニアに相談・引き継ぐときの準備に、チェックリストつきでまとめています。最低限は次の4つです。
- コードの置き場所（GitHubなど）と、いま本番で動いているURL
- 使っている外部サービスの一覧（決済、メール、AI、データベースなど）
- 環境変数（鍵や接続先を、コードの外に置いておく設定項目）の「項目名」の一覧。鍵の値そのものは渡さないでください
- 「必ず成り立つべきこと」のメモ（3章）
コードを見せることが不安なら、秘密保持契約（NDA）を先に結ぶのが普通です。筆者の場合、NDAは商談の前から結べます。依頼先の選び方そのものは、システム開発の発注 完全ガイドで扱っています。
6. エンジニア向け：AI生成コードが本番で壊れる5つの場所
ここから先は、エンジニア（または、エンジニアに説明を求めるとき）向けの節です。読み飛ばしても、ここまでの内容で判断はできます。
筆者の見るところ、AI生成コードで抜けやすい箇所には傾向があります。筆者が自分の開発で検証を重点的に置いているのは、次の5箇所です。
① 入力の境界検証
外部からの入力（フォーム、API、Webhook、ファイル）を「正しい前提」で扱いがちです。境界で型付きのスキーマ（TypeScript なら Zod など）で parse し、通らないものは処理に入れません。
② エラー処理
ハッピーパス（うまくいく場合）は書けても、失敗時の扱いが抜けます。外部APIのタイムアウト、冪等な操作に限った指数バックオフでの再試行、失敗の記録とアラートを足します。OWASP Top 10 の2025年版にも、「Mishandling of Exceptional Conditions（例外的な状況の不適切な処理）」が A10 として入っています。
③ 認可
認可を「画面のif文」で実装しがちです。サーバー側・データベース側で強制しないと、APIを直接叩かれて突破されます。OWASP Top 10:2025 の A01 は「Broken Access Control（アクセス制御の不備）」で、IPA の「安全なウェブサイトの作り方」も「アクセス制御や認可制御の欠落」を取り上げています。
Supabase なら、公開用キー（publishable key、旧 anon キー）はブラウザに出る前提で、データを守るのは RLS です。秘密鍵（secret key、旧 service_role キー）は、利用者のアクセストークン（ログインした人を示す情報）を伴わないリクエストでは RLS を迂回するので、ブラウザに出してはいけません。
④ 同時実行と冪等性
「読む→計算する→書き戻す」処理は、同時に走ると競合（レース）を起こします。決済・在庫・予約では、一意制約や条件付き更新で原子的にします。外部からの通知は処理済みのイベントIDを記録して二重処理を防ぎ（Stripe のドキュメントが示す方法）、外部APIへの作成リクエストには冪等性キーを付けます。発注者向けの整理は二重課金を防ぐ決済システムの作り方と発注チェックリストにあります。
⑤ テスト
AIは頼めばテストも書きますが、境界や異常系を突いているかは別問題です。正常系をなぞるだけのテストは、改修時の退行を止めません。3章の「必ず成り立つべきこと」をそのままテストにするのが、最も効く順番です。
硬化の順序
AIで作ったアプリ（骨格は活かす）
│
├─ 1. 漏れた鍵を無効化・再発行し、秘密情報をサーバー側の環境変数／秘密管理へ移す
├─ 2. 認可をサーバー／DB側で強制する（所有者チェック・RLS・テナント境界）
├─ 3. お金と在庫の処理を冪等・原子的にする（イベントIDの記録、冪等性キー）
├─ 4. 境界に型付きの入力検証を置く
├─ 5. エラー処理・タイムアウト・失敗の記録とアラートを足す
└─ 6. 「必ず成り立つべきこと」をテストにし、CIで毎回実行する
↓
本番運用に耐える状態へ（「完全に安全」ではない）
判断表のサインを、コードで確かめる
| サイン | コードで見る場所 |
|---|---|
| 問題の散らばり方 | 認可・入力検証が1か所（ミドルウェア、ポリシー、共通関数）に集まっているか、各ルートに散っているか |
| データモデル | テナントや所有者を表す列が主要なテーブルにあるか。スキーマ変更がマイグレーションとしてリポジトリにあるか、管理画面で直接変えられているか |
| 認可モデル | 判定がサーバー／DBにあるか、クライアントのコンポーネントにしか無いか。RLS が有効で、条件が「ログインしていれば全行」になっていないか |
| 何が正しい動作か（前提） | 仕様・テスト・Issue のどこかに期待値が書かれているか |
| 自動テスト | 副作用（DB・外部API）が関数の奥に埋まり、テストから差し替えられない構造になっていないか |
| 本番と手元の一致 | リポジトリから本番を再現できるか（デプロイの経路、環境変数の一覧、IaC） |
| 秘密情報 | Git の履歴に鍵が残っていないか。残っていれば、履歴の書き換えより先に鍵を無効化・再発行する |
検証ファースト
NIST の SSDF（SP 800-218）は、人が読めるコードのレビュー・解析（PW.7）と、実行できるコードのテスト（PW.8）を実践として挙げ、自動化された方法は脆弱性の検出にかかる労力を下げると説明しています。SSDF は、ソフトウェアを買う側が調達で供給者とやり取りするときの共通語彙としても使えると位置づけられています。
| 検証ゲート | 防ぐもの |
|---|---|
| 境界の型付き検証 | 不正な入力、想定外のデータ形状 |
| 自動テスト（単体・統合・E2E） | 改修による退行、異常系の見落とし |
| 静的解析・型チェック | 潜在バグ、型の抜け穴 |
| 依存関係・秘密情報のスキャン | 既知の脆弱性、コードに入った鍵 |
| CIでの強制 | 「レビューを忘れた」を構造的に無くす |
| 攻撃者視点の監査 | 自動のツールでは見えない、認可や業務ロジックの穴 |
筆者自身の案件での実例を2つ挙げます。どちらも筆者が最初から作ったもので、AIで作られたアプリを引き取った事例ではありません。示したいのは、検証の仕組みです。
- AI動画ローカライズ基盤: バックエンドのテストカバレッジ100%をCIで必須化し（未達ならビルド失敗）、mypy strict で型をゼロエラーに保ち、スポットGPUが強制停止されても完了済みの区間から再開できる設計にしました。
- 木材流通のB2B SaaS（経済産業大臣賞受賞）: 4ラウンドの自主セキュリティ監査を行い、実在する15のロールでの自主ペネトレーションテストで、全221エンドポイントの認証欠落0件を確認しました。
7. 限界と反例
- 判断表は、筆者の考えに基づく目安です。 最終的な判断は、コードを読んだ所見で行います。表の上で同じ位置でも、事業の事情（止められない期間、予算、これからの計画）で答えは変わります。
- 硬化しても「完全に安全」にはなりません。 できるのは、既知の重大なリスクを潰し、再発を防ぐ仕組み（テストと、変更のたびにテストを自動で走らせるCI）を残すところまでです。
- 作り直しが正解の場合もあります。 要件が変わって作るもの自体が違い、しかも利用者も本番データもまだ無い——このときは、直す費用より作り直す費用が小さいことがあります。
- ツールの仕様は変わります。 6章で触れた Supabase の鍵の呼び名のように、AIツールやクラウドの仕様は変わるので、設定の細部は公式ドキュメントで確認してください。
- 法令の判断は、この記事の範囲外です。 個人情報が漏えいしたときの報告義務などは、個人情報保護委員会の情報と専門家で確認してください。
8. チェックリスト
- 直すか作り直すかを、デモではなく、コードを読んだ所見で決めることにした
- 問題が特定の箇所に集中しているか、全体に散らばっているかを把握した
- データの持ち方と「誰が何を見てよいか」が、業務の実態と合っているか確かめた
- 「必ず成り立つべきこと」を10個ほど書き出した
- 本番に本物の顧客データがあるか、試験用の環境があるかを把握した
- 鍵がブラウザやGitHubに出ていないか確かめ、出ていたら作り直した
- 従量課金のサービスに上限を設定した
- 無料セルフ診断で「わからない」が残った項目を控えた
- コードとクラウドのアカウントが自分（自社）の名義にあり、他の人も保守できる構成か確かめた
まとめ
AIで作ったこと自体は、問題ではありません。問題になるのは、確かめないまま本番で使い続けることです。
筆者の考えでは、多くの場合は、直して使うのが安く速い選択です。全体の作り直しが安い候補になるのは、データの持ち方や「誰が何を見てよいか」の設計が根本から違う、作るもの自体が変わった、といった問題が重なり、しかも本番の顧客データがまだ無いときです。顧客データがすでに入っているなら、問題のある層だけをデータの移行ごと作り直します。判断はデモの印象ではなく、コードを読んだ所見で行ってください。最初の一歩は、無料のセルフ診断と、「必ず成り立つべきこと」の書き出しです。