生成AIや開発支援ツールのおかげで、思いついたアプリが数時間で形になる時代になりました。以前なら何日もかかった機能が、対話しながらあっという間に動く。個人開発のハードルは、確かに下がっています。
ただ、そこで一度立ち止まりたいのが「動いたからヨシ」で公開してしまう瞬間です。画面が表示されて、ボタンを押せば反応する。それは大事な第一歩ですが、動くことと安全に運用できることは別の話です。この記事では、個人開発でも見落としがちなセキュリティの穴と、動く以外に考えるべき非機能要件を、初心者にも分かる言葉で整理します。
結論：AI時代は「全体を見る視点」が差になる
先に結論をお伝えします。AIによって実装そのものが軽くなった分、これからは全体を見る視点、つまりセキュリティと非機能要件をどこまで考えられるかが、作り手の差になっていきます。
コードを書く速さは、ツールがどんどん肩代わりしてくれます。だからこそ、動いた後に「このまま公開して大丈夫か」「こういう場合はどうなるか」を問える人が価値を持ちます。動けばいいで終わらせず、その一歩先を見る。それが今の個人開発者に効いてくる姿勢です。
見落としがちなセキュリティの穴
まずセキュリティです。専門用語が並びますが、どれも「悪意のある人に狙われる隙間」だと考えると分かりやすくなります。代表的な穴を噛み砕いてみます。
- SQLインジェクション：入力欄に打ち込んだ文字が、そのままデータベースへの命令として解釈されてしまう隙です。たとえば検索欄に細工した文字を入れると、本来見えないはずのデータを引き出されたり、消されたりします。ユーザーが入力した値をそのまま命令に混ぜないことが基本です。
- XSS(クロスサイトスクリプティング)：投稿欄などに仕込まれた悪意のあるプログラムが、それを見た別のユーザーの画面で動いてしまう隙です。読んだ人の情報が抜かれることもあります。入力された内容をそのまま画面に出さず、無害な文字として表示する処理が要ります。
- 認可がない：ログイン(本人確認)は通るのに、誰が何を触れるかの制限がない状態です。Aさんが他人のURLを少し書き換えるだけでBさんのデータを見られてしまう、といったことが起きます。認証と認可の違いは、AIで作ったアプリのサーバは安全か(認証と認可)で詳しく整理しています。
- 管理画面が誰でも見られる：運営者しか使わないはずの管理ページに、URLを知っていれば誰でも入れてしまう状態です。
- クラウドストレージの公開設定：S3のようなファイル置き場を、うっかり全世界に公開する設定のまま使ってしまう例です。アップロードした画像や書類が、そのまま外から見えてしまいます。
- ログがない：誰がいつ何をしたかの記録がない状態です。問題が起きても、何が起きたのか後から追えません。
非機能要件とは：「動く」以外に考えること
次に非機能要件です。少し難しい言葉ですが、機能そのもの(何ができるか)ではなく、それを安定して使い続けるための条件、と考えてください。動くかどうかではなく、動き続けられるかどうかの話です。個人開発で見落としやすいのは、次のあたりです。
- バックアップがない：データを保存する仕組みはあっても、控えを取っていない状態です。何かの拍子にデータが飛んだとき、取り戻せません。
- レートリミットがない：レートリミットとは、同じ相手からの過剰なアクセスを制限する仕組みのことです。これがないと、短時間に大量のリクエストを送りつけられて、サービスが重くなったり止まったりします。
- 高負荷への備えがない：使う人が1人のときは快適でも、100人、1000人と増えたときに耐えられるか。想定しておかないと、人気が出た途端に動かなくなることがあります。
突き詰めるべき問い
ここまでの話を全部覚える必要はありません。代わりに、作ったものに対して次の問いを自分に投げてみてください。それだけで、見えてくる景色が変わります。
- そのシステムは、誰が使うのか。
- 個人情報を扱うのか。扱うなら、漏れたら何が起きるのか。
- ユーザーが増えたら、どうなるのか。
- 不正アクセスされたら、どうなるのか。
- サーバが落ちたら、どうなるのか。
- データを誤って削除してしまったら、どうなるのか。
どれも「こういう場合はどうする」という問いです。答えを持っていれば、必要な備えが自然と見えてきます。逆に問いを立てないまま公開すると、想定していなかった場面に足をすくわれます。
全部を完璧にやる必要はない
ここで大事なのは、これら全部を最初から完璧に備える必要はない、ということです。友人数人と使う小さなツールと、不特定多数がお金を払って使うサービスとでは、必要な守りの深さがまるで違います。
だから、運用の目的から逆算して「この規模なら、ここまでは考えておく」と自分で線を引く。その姿勢こそが差になります。そして皮肉なことに、実装をAIに任せるほど、この全体を見る視点の価値は上がっていきます。コードは任せられても、何を守るべきかの判断は、作り手にしか決められないからです。AI時代に本当に問われる力については、AI時代のエンジニアに本当に必要な力でも掘り下げています。
次の一歩
まずは自分の作ったものに、上の問いを1つずつ投げてみることから始めてみてください。「これは個人情報を扱うか」「落ちたらどうなるか」。それだけで、次に手を打つべき場所が見えてきます。
具体的な穴の対策としては、認可の話をまとめたAIで作ったアプリのサーバは安全か(認証と認可)や、備えを怠ったときに費用の面で跳ね返ってくる例を扱ったサーバレス開発に潜む従量課金の罠が、この記事と地続きです。
まとめ
- AIで実装が軽くなった分、全体を見る視点(セキュリティと非機能要件)が作り手の差になる。
- セキュリティの穴：SQLインジェクション、XSS、認可のなさ、管理画面の開放、ストレージの公開設定、ログのなさ。
- 非機能要件：バックアップ、レートリミット、負荷への備え。「動く」以外に考えること。
- 全部を完璧にする必要はない。運用の目的から「誰が使い、どうなったら困るか」を突き詰める姿勢が差になる。
独学でつまずきやすいのは、知識そのものよりも「何をどの順番で学ぶか」です。セキュリティや非機能要件も、いきなり全部を追うと迷子になりますが、あなたの作りたいものから逆算すれば、いま必要な範囲は意外とはっきりします。その線引きを、1対1で一緒に整理することもできます。
