AIコーディングツールを使うと、小さなWebアプリや業務改善ツールを驚くほど早く作れるようになりました。Codex、Claude Code、GitHub Copilot、Cursorなどに「こんな画面がほしい」「このCSVを整理したい」「WordPress運用の確認ツールを作りたい」と頼むと、以前なら休日を使って組んでいたものが、数時間で形になることもあります。
ただ、ここで一度立ち止まりたいです。ローカルで動いたアプリと、インターネット上に公開してよいアプリは別物です。AIが作ったコードが悪いという話ではありません。むしろ、AIのおかげで試作の速度が上がったからこそ、「公開前に何を見るか」を決めておかないと、便利な個人ツールがそのまま情報漏えいや不正アクセスの入口になってしまいます。
この記事では、AIで作った個人アプリを公開する前に、SE目線で最低限確認したいポイントを整理します。セキュリティ専門家向けの厳密な監査手順ではなく、個人開発者やフリーランスSEが「公開してよいか迷ったとき」に使える現実的なチェックリストです。
結論：まず「誰のデータを、どこに置き、誰が触れるか」を見る
公開前に最初に見るべきなのは、フレームワークやライブラリの名前ではありません。まず確認したいのは、次の3つです。
- このアプリは、誰のデータを扱うのか
- そのデータは、どこに保存されるのか
- 保存されたデータや管理画面に、誰がアクセスできるのか
自分だけが見るメモ、ダミーデータだけの試作、公開しても困らない静的ページであれば、リスクは比較的小さくできます。一方で、メールアドレス、顧客情報、売上、健康情報、金融情報、ログイン情報、社内資料、APIキーのようなデータが入るなら話は変わります。AIで短時間に作れたとしても、公開の基準は一段上げる必要があります。
The Vergeは、AIで作った個人アプリが公開後にSQLインジェクションや認証不備、データ露出の問題を抱えていた事例を紹介しています。記事の中では、AIによる「バイブコーディング」は試作を簡単にする一方で、ローカルの個人ツールが公開アプリや業務ツールに変わった瞬間に責任が変わる、という点が強調されています。これは、個人ブログ運用や副業ツールにもそのまま当てはまります。
AIで作ったアプリが危ないのではなく、公開判断が危ない
AIが生成したコードには間違いが混ざることがあります。これは事実です。ただし、人間が書いたコードなら安全で、AIが書いたコードなら危険、という単純な話ではありません。人間が急いで作った個人アプリにも、認証漏れ、環境変数の直書き、過剰なログ出力、古いライブラリ、管理画面の露出は普通に起きます。
AI時代に変わったのは、アプリを作るまでの心理的な距離です。以前なら「公開するならちゃんと作らないと」と考えていたものが、AIを使うと「もう動いたから公開してみよう」となりやすい。ここが一番の落とし穴です。
CodexやClaude Codeのようなエージェント型ツールは、コードベースを読み、ファイルを編集し、コマンドを実行し、テストや修正まで進められます。GitHub Copilot cloud agentも、リポジトリ調査、実装計画、ブランチ上の変更、PR作成前の反復などを支援できます。便利な一方で、任せられる範囲が広いほど「何を許可し、何を止めるか」を人間側で決めておく必要があります。
チェック1：公開URLとアクセス範囲を確認する
まず確認したいのは、誰がその画面にアクセスできるかです。個人開発では、ここが曖昧になりがちです。
- URLを知っている人なら誰でも見られるのか
- 検索エンジンに拾われる可能性があるのか
- 管理画面やAPIエンドポイントも外から見えるのか
- テスト用ページ、デバッグ用ページ、ログ表示ページが残っていないか
- Basic認証やログイン機能を入れたつもりでも、保護されていないURLがないか
「URLを誰にも教えていないから大丈夫」は、安全策として弱いです。公開サーバーに置いた時点で、予期しないアクセスは起こり得ます。特に、管理画面やAPIが推測しやすいパスにある場合、あとから気づくのはつらいです。
AIにレビューを頼むなら、単に「セキュリティを見て」ではなく、こう聞くと確認しやすくなります。
このアプリをインターネットに公開する前提で確認してください。
- 認証なしで見える画面
- 認証なしで呼べるAPI
- 管理画面やデバッグ画面
- URLを推測されると困るページ
- 公開しないほうがよいファイル
を一覧にしてください。
修正案は出してよいですが、まずリスク一覧を優先してください。ポイントは、いきなり修正させるのではなく、まず一覧化させることです。AIに任せる範囲を「調査」と「修正」に分けるだけで、人間が判断しやすくなります。
チェック2：ログインと権限を「あるつもり」で済ませない
次に見るのは認証と権限です。ログイン画面があることと、守るべき操作が正しく保護されていることは別です。
- ログイン前に、データ一覧や詳細APIが呼べないか
- 他人のIDをURLに入れると、別ユーザーのデータが見えないか
- 管理者だけの操作を一般ユーザーが実行できないか
- パスワード再設定や招待機能が雑に作られていないか
- ログアウト後にブラウザバックで管理画面が見えないか
個人アプリでは、最初から複雑な権限管理を作る必要がない場合もあります。その場合は、無理にユーザー登録機能を作らず、自分だけが使う前提にする、公開しない、静的な出力だけにする、といった選択もあります。
OWASP Application Security Verification Standard（ASVS）は、Webアプリの技術的なセキュリティ管理をテストする基準として使える資料です。個人開発で全項目を厳密に満たすのは現実的でないとしても、「認証」「アクセス制御」「入力検証」「ログ」「設定」など、見るべき分類を知るだけでも役に立ちます。
チェック3：APIキーと秘密情報をコードに書いていないか
AIで作ったコードを確認するとき、特に気をつけたいのが秘密情報です。APIキー、WordPressのApplication Password、データベース接続文字列、OAuthトークン、メール送信用パスワードなどは、コードやHTML、公開リポジトリに置いてはいけません。
これは半農エンジニアラボの運用でも強く意識しています。WordPressの認証情報は `.env` や環境変数で扱い、記事本文やドキュメントに直書きしない。Codexに作業させるときも、公開・予約投稿・X投稿に勝手に進まないよう、AGENTS.mdやruntime-rulesで止める。こうしたルールは、ブログ運用だけでなく個人アプリ開発にもそのまま使えます。
公開前には、少なくとも次を確認します。
- ソースコードにAPIキーが直書きされていないか
- フロントエンドに秘密情報を埋め込んでいないか
- エラーメッセージに接続文字列や内部パスが出ないか
- ログにトークンや個人情報が残らないか
- `.env` や設定ファイルが公開ディレクトリに置かれていないか
AIに頼む場合は、次のように範囲を絞るとよいです。
このリポジトリ内で、公開してはいけない秘密情報が混ざっていないか確認してください。
対象はAPIキー、トークン、パスワード、接続文字列、秘密鍵、メール認証情報です。
見つけた場合は値を表示せず、ファイル名と理由だけを報告してください。
修正する前に、人間の確認を待ってください。大事なのは「値を表示しない」と明示することです。レビューのつもりで秘密情報をチャットに貼り出してしまうと、それ自体がリスクになります。
チェック4：入力欄とファイルアップロードを軽く見ない
問い合わせフォーム、検索欄、メモ欄、CSVアップロード、画像アップロードなど、ユーザーが何かを入力できる場所は注意が必要です。小さな個人アプリでも、入力欄がある時点で、想定外の文字列や巨大なファイル、悪意ある内容が入る可能性があります。
公開前に見る観点は、次のようなものです。
- 入力値をそのままSQLやコマンドに渡していないか
- HTMLとして表示するときに、適切にエスケープしているか
- ファイル種別、サイズ、保存先を制限しているか
- アップロードしたファイルをそのまま実行できる場所に置いていないか
- エラー時に内部情報を出しすぎていないか
ここで攻撃手順を細かく覚える必要はありません。個人開発者としては、「ユーザー入力を信用しない」「保存する前に制限する」「表示する前に無害化する」という原則だけでも、AIへの依頼内容が変わります。
チェック5：データを持たない設計にできないか考える
セキュリティ対策というと、強い認証や高度な監視を足す方向に考えがちです。しかし個人開発では、そもそもデータを持たない設計にするほうが安全な場合があります。
たとえば、ブログ運用のチェックリストなら、毎回ブラウザ内だけで動く静的ページにする。CSV整形ツールなら、サーバーにアップロードせずブラウザ内で処理する。作業メモなら、公開サーバーに保存せずローカルファイルに出す。すべてのツールをログイン付きWebアプリにする必要はありません。
特に、顧客データ、医療情報、金融情報、契約情報、個人の健康記録のようなものは、軽い気持ちでクラウドに置かないほうがよいです。扱う必要がある場合は、技術的な安全性だけでなく、契約、規約、法務、専門家確認が関わります。個人ブログの記事としては、ここを断定せず、「迷うなら保存しない、公開しない、専門家に確認する」と書くのが誠実です。
チェック6：AIのセキュリティレビューを過信しない
CodexやClaude Codeには、セキュリティレビューに使える機能やワークフローがあります。OpenAIのCodexドキュメントにも、Cyber SafetyやCodex Securityへの導線があります。Claude Codeの公式ドキュメントでも、コードベースの読解、ファイル編集、コマンド実行、CI/CD、MCP連携など、開発作業を広く支援することが説明されています。
ただし、AIレビューは万能ではありません。AIは、与えられた前提の中で問題を探します。そもそも「このアプリは誰のデータを扱うのか」「どこまで公開するのか」「業務データなのか個人メモなのか」を伝えていなければ、文脈に合ったリスク判断は難しくなります。
そのため、AIにセキュリティレビューを頼むときは、最低限の前提を渡します。
前提：
- このアプリはインターネット上に公開予定です。
- ユーザー登録はありません。
- 管理者だけがデータを登録します。
- 保存するデータはブログ運用メモで、顧客情報や医療情報は扱いません。
依頼：
公開前のセキュリティリスクを確認してください。
特に、認証、アクセス制御、入力検証、秘密情報、ログ、エラー表示、依存ライブラリを見てください。
危険度を高・中・低で分け、修正前に確認すべき点を一覧にしてください。このように前提を明示すると、AIの回答も実務に寄りやすくなります。逆に、前提が曖昧なまま「安全にして」と頼むと、一般論の修正だけで終わる可能性があります。
チェック7：依存ライブラリと更新方法を見る
AIが生成したコードは、便利なライブラリを使うことがあります。問題は、使っているライブラリが古い、メンテナンスされていない、似た名前の怪しいパッケージである、というケースです。
公開前には、次の点を見ます。
- 使っているパッケージ名が公式のものか
- 不要な依存関係が大量に入っていないか
- 古いバージョンのまま固定されていないか
- 更新手順を自分で説明できるか
- AIが提案したインストールコマンドを意味も分からず実行していないか
個人開発では、依存ライブラリを増やしすぎないことも安全策です。小さなフォーム、静的な一覧、簡単なCSV整形であれば、重いフレームワークや多数のプラグインを入れなくても済むことがあります。AIには「依存ライブラリを増やさずに実装して」「追加する場合は理由を説明して」と依頼するとよいです。
チェック8：公開後に止める手段を決めておく
公開前チェックで意外と忘れがちなのが、問題が起きたときの止め方です。アプリを公開するなら、公開後に不具合やリスクに気づいたとき、すぐ止められるようにしておきたいです。
- 公開URLを一時的に閉じる方法
- 管理画面へのアクセスを止める方法
- APIキーをローテーションする方法
- ログを確認する方法
- データをバックアップ・削除する方法
- どの時点で公開をやめるかの判断基準
半農エンジニアラボのWordPress運用では、Codexが勝手に公開しない、下書き保存までに止める、Xへ自動投稿しない、Threads投稿は明示依頼とドライラン後にする、というルールを置いています。個人アプリでも同じで、「作る」だけでなく「止める」手順を先に決めておくと、安心して試せます。
公開前チェックリスト
最後に、実際に使える形でチェックリストをまとめます。
- このアプリが扱うデータを説明できる
- 顧客情報、医療情報、金融情報、契約情報を扱わない、または専門家確認が済んでいる
- 公開URLから見える画面を把握している
- 管理画面、API、ログ表示が認証なしで見えない
- ユーザーごとの権限が必要な場合、他人のデータを見られない
- APIキーやパスワードをコードに直書きしていない
- エラー表示やログに秘密情報が出ない
- 入力欄、検索欄、アップロード機能の扱いを確認した
- 依存ライブラリの名前と用途を説明できる
- 公開後に一時停止する方法を決めている
- AIレビューだけでなく、人間が重要箇所を読んだ
すべてを完璧にできなくても、このリストを見ながら「今回は公開しない」「静的ページにする」「ダミーデータだけにする」「専門家に見てもらう」と判断できれば、それだけで大きな前進です。
まとめ
AIコーディングツールは、個人開発や副業の入口を広げてくれます。これまで作れなかったものを試せるようになり、ブログ運用や日々の作業改善にも使いやすくなりました。
一方で、作れることと公開してよいことは別です。公開前には、誰のデータを扱うのか、どこに保存するのか、誰が触れるのか、秘密情報が混ざっていないか、止める手段があるかを確認する必要があります。
AIに任せるほど、人間の役割は「コードを全部書くこと」から「公開してよい状態か判断すること」へ移っていきます。半農エンジニアラボでは、WordPress運用でも公開やSNS投稿を人間確認に残しています。個人アプリでも同じように、便利さと安全性の境目を自分で決めることが、AI時代のSE仕事術になると思います。
