AI駆動開発で、作る・確かめる・運用する。

受託開発 / 導入支援 / 検証・商用化 / 技術顧問

株式会社ロク株式会社ロクRoku Inc. / AI-Native Engineering

Guide

AIプロトタイプを商用リリースする前のチェックリスト

当社が技術診断で実際に確認している13領域を、自己点検に使える形で公開しています。

はじめに

「動く」と「商用運用できる」の間には、画面から見えない差があります。

Claude Code、Codex、Cursor、v0、Bolt、Lovable などの普及で、「動くもの」を作るまでの時間は劇的に短くなりました。一方で、認証・権限、個人情報の扱い、決済、障害対応といった領域は、デモ画面では問題が見えないまま公開を迎えやすい部分です。

このページでは、リリース前の自己点検に使える13領域を、確認する観点とあわせて公開します。すべてを完璧にする必要はありません。重要なのは、満たしていない項目を把握したうえで、公開範囲を意図的に判断していることです。

For

こんな方のためのチェックリストです

バイブコーディングで作った

ChatGPT や AI コーディングエージェントとの対話で作った Web サービスを、そのまま公開してよいか判断したい方。

AIアプリビルダーで作った

v0、Bolt、Lovable、Replit などで作った MVP を、有料サービスとして提供したい方。

AI生成コードを引き継いだ

外注先や社内メンバーがAIで作った成果物を、リリース前に点検したい方。

Checklist

公開前に確認する13領域

「はい」と答えられない項目、「分からない」項目が、リリース前に確認すべき箇所です。

01

認証・権限設計

  • パスワードや認証トークンの保存方式は安全か
  • 管理者と一般ユーザーの権限は分離されているか
  • 退会・無効化したユーザーのアクセスは確実に遮断されるか
02

データベース設計

  • 個人情報がどのテーブルにどんな形式で保存されているか把握しているか
  • 本番データと開発・検証データは分離されているか
  • データが増えたときに遅くなる箇所を把握しているか
03

API設計

  • 認証なしで呼び出せるエンドポイントは意図したものだけか
  • 連続リクエストへの制限(レートリミット)はあるか
  • エラー時にスタックトレースなどの内部情報を返していないか
04

エラーハンドリング

  • 想定外の入力でアプリ全体が落ちないか
  • 決済など失敗が許されない処理は、安全に再試行できるか
  • ユーザーに見せるエラーと内部ログを分けているか
05

ログ・監視

  • 障害の発生に自分で気づける仕組みがあるか
  • 問題調査に必要なログが残っているか
  • パスワードや個人情報がログに平文で出力されていないか
06

テスト自動化

  • 登録・ログイン・決済など主要動線に自動テストがあるか
  • 修正のたびに全機能を手動確認する状態になっていないか
  • テストがAIの生成したままで、実は何も検証していない状態になっていないか
07

CI/CD

  • デプロイは誰がやっても同じ結果になる手順か
  • 壊れたデプロイを素早く前の状態に戻せるか
  • 本番反映前に自動でテスト・チェックが走るか
08

セキュリティ

  • APIキーやシークレットがコードやgit履歴に残っていないか
  • 依存ライブラリの既知の脆弱性を確認したか
  • 入力値の検証をサーバー側でも行っているか
09

決済・課金

  • 二重課金や課金漏れを検知できるか
  • 返金・解約・プラン変更のフローが決まっているか
  • 決済サービスからのWebhookを検証しているか
10

管理画面

  • 問い合わせ対応に必要な操作(利用状況の確認・停止・返金)を画面から行えるか
  • 管理画面自体のアクセス制限は十分か
  • 誰がいつ何を操作したかの記録が残るか
11

バックアップ

  • 何を・どの頻度で・どこに保存しているか即答できるか
  • バックアップからの復元を一度でも実際に試したか
  • 誤削除や障害の際、どの時点までデータが戻るか把握しているか
12

運用フロー

  • 障害発生時に誰が何をするか決まっているか
  • 利用規約・プライバシーポリシーの記載と実装が一致しているか
  • 問い合わせ対応の窓口とフローがあるか
13

AI生成コードの品質

  • そのコードの動作を、人間が自分の言葉で説明できるか
  • 同じ処理の重複実装や、使われていないコード・依存が大量に残っていないか
  • 次の機能追加を、壊さずに実装できる構造になっているか

Decision

リリース判断の目安

このまま公開しやすい状態

認証・セキュリティ・個人情報・バックアップに「分からない」がない。決済を扱わない、または手動で対応できる規模。

公開後も、監視と運用フローの整備は継続してください。

限定公開しながら整える状態

主要な動線は動くが、テスト・監視・運用フローが未整備。

利用者数や機能を絞った公開と並行して整備を進めるのが現実的です。

公開前に改善が必要な状態

認証・権限・個人情報・決済のいずれかに重大な不備がある。またはその状態を把握できていない。

先に該当箇所の確認と改善が必要です。範囲を絞れば短期間で対応できることも多い領域です。

Pitfalls

よくある落とし穴

「デモで動いた」と「本番で動く」の混同

デモは作った本人が正しい操作をする前提です。本番では同時アクセス、想定外の操作、悪意ある入力が初めて発生します。

シークレットの直書きとgit履歴

APIキーを後からコードから消しても、git履歴やAIチャットのログに残っている場合があります。漏えいした前提で無効化・再発行する判断が必要です。

法務文書と実装の不一致

プライバシーポリシーの記載と、実際のデータの扱いがズレているケースです。文面だけAIで生成し、実装と突き合わせていない場合に起きやすい問題です。

自己点検が難しい場合は、技術診断で代行します

このチェックリストは、対象システムの状態をある程度把握できることが前提です。「分からない」が多い場合や、第三者による確認が必要な場合は、技術診断(50万円〜・1〜2週間)でリスク一覧と改善優先度をレポートとして納品します。

FAQ

よくあるご質問

チェックリストをすべて満たさないと公開できませんか?
いいえ。サービスの性質によって必要な水準は変わります。個人向けの無料サービスと、決済や個人情報を扱うサービスでは、求められる項目が異なります。重要なのは、満たしていない項目を把握したうえで、公開範囲を意図的に判断していることです。
自分で確認できる項目はありますか?
あります。バックアップの復元テスト、APIキーの直書き確認、管理画面のアクセス制限などは、開発に使ったAIツールに質問しながらでも確認を進められます。一方、認証・権限設計やAI生成コードの構造的な品質は、第三者のレビューが有効な領域です。
診断だけ依頼して、改善は自分で実施してもよいですか?
可能です。技術診断はレポート納品が成果物で、改善の実施は必須ではありません。レポートには改善優先度と概算工数を含めるため、内製・外注いずれの判断材料にも使えます。