前の第4章「AIと作る」で、動くものができました。ここからがフェーズ4「出す」――テストで壊れないか確かめ、セキュリティの穴をふさぎ、そして世に公開する段階です。「動いた」で満足せず、他人に安心して触ってもらえる状態まで持っていきましょう。難しく聞こえますが、ここでもAIが相棒になります。
「未完成でもいい。まず1人に、安全に届ける」
「作った」と「出せる」は違う
自分のパソコンで動くものと、他人が触っても大丈夫なものは、別物です。あなたは「正しい使い方」を知っているので、想定どおりに動かします。でも公開すれば、あなたが想定しない入力・操作・悪意が飛んできます。空欄で送信する人、記号を大量に貼り付ける人、他人のデータを覗こうとする人――。
だからといって身構える必要はありません。個人開発で最初にやるべきことは、ごく基本的な3点だけです。「壊れないか」「秘密が漏れないか」「他人のデータが守られるか」。この章は、その最低限をAIと一緒にクリアして、堂々と公開するための章です。
正しい手順でしか触らない。エラーが出ても自分で直せる。秘密情報が画面に出ても気にしない。
想定外の入力が来る。エラー画面から内部情報が漏れる。うっかり公開した鍵で高額請求や情報流出も。
テストとレビューをAIに任せる
「一人開発だと、コードをレビューしてくれる先輩がいない」――その役目こそ、AIに任せましょう。あなたが書いた（あるいはAIに書かせた）コードを、別の視点でもう一度AIに点検させるのです。書いた本人（人間もAIも）は自分のミスに気づきにくい。だから「監査役」を立てるのが効きます。
やり方はシンプル。コードを貼り付けて、こう頼むだけです。「このコードのバグ・危険な入力・抜けているテストを挙げて」。すると、自分では気づかなかった穴がリストで返ってきます。あとは1つずつ、優先度の高いものから直す。全部を一度に直そうとせず、指摘を1件直して動作確認、また1件、と進めるのがコツです。
AIに監査を頼むときは、次のような観点を明示すると精度が上がります。
「どんな時に落ちる？」「空欄やゼロを渡したら？」壊れる条件をAIに探させる。
悪意ある文字列・巨大なデータ・不正なファイル。「攻撃者ならどう突く？」と聞く。
「確かめるべきなのに確認していないケースは？」境界値や例外を洗い出させる。
「APIキーやパスワードがコードに直書きされていないか？」漏洩の芽を先に摘む。
💡 テストは「自動で確かめる仕組み」。 実践ルートなら、AIにテストコードまで書かせましょう。「この関数のテストを書いて。正常系と、空欄・異常値のケースも」と頼めば、次に直したとき壊れていないかをボタン1つで再確認できます。入門ルートなら、手で「わざと変な操作をしてみる」だけでも十分な一歩です。
セキュリティの最低限3つ
セキュリティは奥が深い分野ですが、個人開発の公開時にまず必ず押さえる3点だけを覚えてください。この3つを外すと、お金・信用・他人の情報を一気に失いかねません。逆に、ここさえ守れば最初の公開としては十分です。
APIキー・パスワード・トークンをコードに直接書かない。.envのような環境変数ファイルに逃がし、そのファイルは公開対象から除外（.gitignoreに追加）する。
ログイン機能があるなら、Aさんが自分以外のデータを見られないようにする。「このデータは本当にこの人のもの？」という所有者チェックを、AIに確認させて必ず入れる。
外部サービスの鍵やDBの権限は必要な分だけ。「全部できる」鍵を配らない。使い捨ての鍵、読み取り専用の鍵など、用途を絞って発行する。
🚨 秘密鍵を絶対に公開しない。 これは個人開発で最も多い、そして最も高くつく事故です。APIキーをコードに直書きしたままGitHubなどに公開すると、数分〜数時間で自動的に見つけ出され、悪用されます。有料APIなら気づいた時には数十万円の請求、ということも実際に起きています。公開前に必ず「鍵がコードに残っていないか」をAIに点検させてください。もし一度でも公開してしまった鍵は、削除では不十分。必ず無効化して新しい鍵に発行し直すこと。
「難しそう」と感じたら、AIにこう聞けば大丈夫です。「このコードを公開する前に、セキュリティ上やっておくべきことを初心者向けに教えて」。あなたのコードに即した具体的なチェックリストが返ってきます。
自動化を安全に走らせる（実践向け）
ここは主に🔧実践ルート向けの話です。Claude CodeのようなAIエージェントに、ファイル操作やコマンド実行を自動で任せると開発は一気に速くなります。一方で、「勝手に大事なファイルを消す」「意図しないコマンドを走らせる」といった暴走のリスクもゼロではありません。
そこで大切なのが「隔離（サンドボックス）」の考え方です。AIに強い権限を渡すときは、被害が及んでも問題ない箱の中で走らせる。具体的には、専用の作業フォルダやコンテナに閉じ込め、本番データや秘密情報には触れられないようにしておく。こうすれば、安心してAIに自動化を任せられます。
📦 「試すのは箱の中、本番はゆっくり」 が原則です。AIの自動実行を、いきなり本番環境や大事なデータの上で走らせない。隔離の具体的なやり方はClaude Codeのサンドボックス設定ガイドで詳しく解説しています。入門ルートの人は、この節は「そういう安全策があるんだ」と知るだけで十分です。
公開する ― コードからネット公開まで
いよいよ公開です。「公開」とは、あなたのパソコンの中にあるものをネット上に置いて、誰でもURLで開ける状態にすること。これをデプロイと呼びます。難しそうな響きですが、今どきは無料のサービスに数クリックで載せられます。
大まかな流れは次の3ステップです。個人開発の最初の公開は、すべて無料枠で十分まかなえます。お金をかけるのは、使ってくれる人が増えてからで構いません。
GitHubなどにコードを保存する。秘密ファイル（.env）は除外するのを忘れずに。これが公開の土台になる。
Vercelなどの無料ホスティングにGitHubを連携。秘密情報は管理画面から環境変数として登録する。
自動でネット上にビルドされ、公開URLが発行される。あとはそのURLを1人に渡すだけ。
✅ 未完成でも、公開して1人に見せる。 「まだ機能が足りない」「デザインが微妙」――その気持ちで公開を先延ばしにするのが、個人開発が消える一番の原因です。60点でいい。公開URLを身近な1人に送るところまでやりきりましょう。その人の「ここ使いにくい」の一言が、100時間の悩みより価値があります。
具体的な手順は――GitHubへの保存からVercelでの公開、環境変数の設定まで――Claude Code / Cursorで作ってVercelに公開する手順で画面つきで解説しています。詰まったら、そのままAIに「この画面でエラーが出た、どうすれば？」と聞けば、たいてい抜け出せます。
- 一人でもレビュー役はAIに。「バグ・危険な入力・抜けたテストを挙げて」で監査させ、1つずつ直す。
- セキュリティは最低限3つ：秘密は環境変数へ／他人のデータを守る／権限は最小限。
- 秘密鍵は絶対に公開しない。漏れたら削除でなく無効化＆再発行。公開前にAIで点検。
- 公開（デプロイ）は無料枠でOK。未完成でもURLを1人に渡すところまでやりきる。
これで「作って、安全に出す」までたどり着きました。でも本当の勝負はここから。使ってもらい、改善し、続けられる形にするのが最終フェーズです。次の第6章「育てる ― 集客と収益化」へ進みましょう。