「AIに頼んだら、それっぽいアプリが動いたんです。これ、このまま公開しても大丈夫ですか？」
ここ最近、こうした相談を実際にいただくことが増えました。生成AIの進化で、専門知識がなくても「動くもの」を形にできる時代になりました。アイデアを思いついたその日のうちに、ログイン画面があって、データが保存されて、それっぽく動くWebアプリが手元にある。数年前なら考えられなかったことです。
結論から言えば、「自分で考えたものを形にしてみる」こと自体は、心から応援したいと思っています。現役のエンジニアとして見ても、頭の中のアイデアを素早く検証できるのは大きな武器です。
ただ、相談を受けるたびにお伝えしているのは、こういうことです。
「動いて見える」ことと、「本番で安全に使える」ことは、まったく別の話です。
この記事では、その「別の話」の正体、つまり画面の裏側で何が問われているのかを、できるだけ専門用語を避けて整理します。
「作ってみる」は最高のスタート地点
まず誤解のないように。AIで試しに作ってみることを否定する記事ではありません。
新しいサービスやツールを考えるとき、頭の中だけで「これは使えそうか」を判断するのは難しいものです。実際に画面があって、ボタンを押せて、データが動く。そこまで形にして初めて「あ、ここは使いにくいな」「この機能はいらないな」と気づけます。
AIはこの「最初の構成を素早く形にする」フェーズで圧倒的に強い。自分が作りたいものを考え、形にして、確かめる。この使い方は、むしろどんどんやるべきです。
問題は、その次のステップ、「作れたから、公開しよう」と一足飛びに進んでしまうときに起こります。
「試作（プロトタイプ）」と「本番リリース」は、目的も、求められる品質も、まったく違うものです。試作は”確かめる”ためのもの。本番は”他人の大切なデータや時間を預かる”ものです。
「動く」の下に隠れているもの
画面が表示され、ボタンが反応し、データが保存される。利用者から見えるのはここまでです。しかし、本番で安全に動かすためには、その画面の下に、見えない土台が必要です。
graph TB
subgraph SURFACE["ユーザーに見える層 — 動いて見える部分"]
UI["画面・機能（ログイン / 入力 / 保存）"]
end
subgraph FOUNDATION["本番で問われる、見えない土台"]
SEC["セキュリティ（認証・認可）"]
VAL["入力値の検証"]
DB["データベース設計・整合性"]
BAK["バックアップ・障害復旧"]
OPS["エラー監視・運用体制"]
end
UI --> FOUNDATION
SEC --- VAL --- DB --- BAK --- OPS
ユーザーの目に触れるのは上の層だけ。本当に大変なのは、それを下から支える土台の部分です。代表的なものを見ていきましょう。
1. セキュリティ：「誰が、何に、アクセスできるか」
たとえば、ログイン機能があるアプリ。画面上では、自分のIDでログインして、自分のデータが見える。一見、正しく動いています。
しかし、こんな確認はされているでしょうか。
- 他人のIDを推測して、URLを少し書き換えるだけで、他人のデータが見えてしまわないか？（認可の不備）
- パスワードは、そのままの文字列で保存されていないか？（本来は暗号化が必須）
- ログインしていない人が、本来見えてはいけない画面に直接アクセスできないか？
これらは画面をふつうに操作している限り、絶対に気づけません。「自分のアカウントでは正しく動く」からです。攻撃者は、ふつうの操作をしないからこそ攻撃者なのです。
AIは「ログイン機能を作って」と頼めば作ってくれます。しかし「あらゆる不正アクセスを想定して堅牢に作って」と頼んでも、その堅牢さを保証してくれるわけではありません。何を確認すべきかを知らなければ、確認の指示すら出せないのです。
2. 入力値の検証：「ユーザーは正しい使い方をしてくれない」
フォームに名前やメールアドレスを入力する。開発者は「ふつうに名前を入れてくれる」前提でテストします。でも本番では、こんな入力が飛んできます。
- 名前欄に、10万文字のテキスト
- メール欄に、データベースを操作する命令文（SQLインジェクション）
- 数量欄に、マイナスの値や、巨大な数字
こうした「想定外の入力」を弾く処理（バリデーション）がないと、データが壊れたり、最悪の場合データベースの中身が抜き取られたりします。AIが生成したコードでも基本的な検証は入ることがありますが、「すべての入口で、漏れなく」検証されているかは、設計を理解した目で確認しないとわかりません。
3. データベース：「保存できる」と「正しく保存され続ける」は違う
データが保存される。これも画面上は問題なく見えます。しかし、運用が始まると次のような問いが効いてきます。
- 同時に2人が同じデータを更新したら、どちらが残る？データが矛盾しない？
- 関連するデータの片方だけが消えて、つじつまが合わなくなることはないか？（整合性）
- 障害でサーバーが落ちたとき、データは復旧できる？バックアップは取られている？
- データ量が増えても、表示は遅くならない？
特にバックアップは深刻です。「動いていたサービスのデータが、ある日すべて消えた」という事故は、個人開発では決して珍しくありません。
4. 運用：公開した瞬間から、止められなくなる
公開するということは、誰かがそれを使い始めるということです。一度使われ始めたサービスは、簡単には止められません。
- エラーが起きたとき、気づける仕組み（監視）はあるか？
- 個人情報を扱うなら、その取り扱いは法律（個人情報保護法など）に沿っているか？
- 問い合わせや不具合に、誰が、どう対応するのか？
「作って終わり」ではなく、「公開してからが始まり」なのです。
では、どう判断すればいいのか
ここまで読んで「全部ちゃんとやるのは無理だ」と感じたかもしれません。でも、判断はシンプルです。「誰が使うのか」で線を引くこと。
| 使い方 | AIで作ってそのまま | 求められる品質 |
|---|---|---|
| 自分だけで試す | ◯ 問題なし | 動けばOK |
| 社内の数人で使う | △ 要注意 | 最低限のデータ保護 |
| 顧客・不特定多数に公開 | × 確認必須 | セキュリティ・運用の作り込み |
自分や社内で「確かめる」段階なら、AIで作ったものをどんどん試してください。リスクは限定的です。
一方で、お客様のデータを預かる、お金が絡む、個人情報を扱う。こうした「公開」の段階に進むなら、見えない土台の確認は避けて通れません。
おすすめは、「試作はAIで素早く、公開前に品質の専門家の目を一度通す」という二段構えです。アイデアの検証スピードは落とさず、本番のリスクだけを潰せます。
公開前チェックリスト
最後に、本番公開を考えているなら最低限確認したい5点をまとめます。一つでも「わからない」があれば、それは確認が必要なサインです。
- 認証・認可 — 他人のデータが、URLの操作などで見えてしまわないか
- 入力値の検証 — 想定外の入力でデータが壊れたり抜かれたりしないか
- 個人情報・機密データ — 適切に暗号化・管理されているか
- バックアップと整合性 — 障害時にデータを復旧できるか
- エラー監視と運用体制 — 問題が起きたとき気づき、対応できるか
これらは画面を操作するだけでは見えない領域です。だからこそ、設計を理解した第三者のレビューが効きます。
おわりに
AIで「作ってみる」ことのハードルは、劇的に下がりました。これは本当に素晴らしいことで、もっと多くの人が自分のアイデアを形にしてほしいと思っています。
ただ、その先にある「公開する」という一歩は、見た目以上に重い。動いているように見えても、その下の土台が問われている。これだけは、現役のエンジニアとして強くお伝えしておきたいことです。
「作ってみたけど、これ公開して大丈夫だろうか」。もしそう感じているなら、それは正しい感覚です。その直感を、ぜひ一度、専門家と一緒に確かめてみてください。