なぜ『5 分で会員登録完成』が罠なのか
まずは他人事のようなニュースを一つ。先月、韓国の個人情報保護委員会が Coupang に 6,246 億ウォンの課徴金を科しました。個人情報の制裁としては過去最大規模です。会員 3,370 万人の氏名とメールが流出しましたが、流出経路はよりによって『自分の情報の編集』ページでした。しかし調査の結論は高度なハッキングではなく、『基本的な安全管理の不足』でした。
なぜここから始めるか。今どきは AI に『メールとパスワードで登録とログインができるように作って』と一行入れれば、5 分で画面が出るからです。サービスを作ったことがある人なら、たいていこう始めたはずです。問題は、画面が出たからといって会員登録が完成したわけではない、という点です。
少し基礎を押さえます。ログインは技術的には二つの仕事です。一つは『あなたは誰か』を確認する認証（authentication）、もう一つは『確認したのでしばらく聞かない』と覚えるセッション（session）です。そしてパスワードはサービスが原本のまま保存してはいけません。復元不能な形に変えて保存し、この変換をハッシュ（hash）と呼びます。きちんと作られたサービスは、運営者でさえ利用者のパスワードを知りません。ハッカーがデータベースを丸ごと盗んでも、元のパスワードは割り出せないのです。
幸い Ruby on Rails のような Web フレームワークは、このハッシュを自動で処理します。『ハッシュを使え』と言わなくても、AI はフレームワークの組み込み機構で暗号化して保存します。つまりここまでは道具が面倒を見てくれる基本です。本当の問題はその次——『何を作ってもらうか』を人が決めねばならない領域から始まります。
欠けているもの（1）（2）——パスワード再設定と会員情報の編集
最初に欠けるのはパスワード再設定です。利用者はパスワードを忘れるでしょうか、忘れないでしょうか。確率ではなく必ず忘れます。ところが一行プロンプトで作った画面には『パスワードをお忘れですか？』がありません。忘れた利用者は再び入れず、結局問い合わせメールを送ります。サービスを開いて最初に受ける問い合わせのかなりの割合がパスワード問題で、これを一人ずつ手作業で変えはじめると、サービスではなくコールセンターになります。
ここに決めるべきことがあります。再設定リンクをメールで送るとして、そのリンクは何分間有効にすべきか。一度使ったら無効にすべきか。リンクがずっと生きていれば、メールボックスが破られた瞬間にアカウントも一緒に破られます。こういうことを定めるのが方針であって、コードではありません。
二つ目は会員情報の編集です。メールを変えたい、パスワードを変えたい——当然の要望なのに、一行の成果物にはその方法がありません。ここにも決めることがあります。パスワードを変える際、今のパスワードをもう一度尋ねるのか。尋ねなければ、カフェでちょっと席を外した隙にアカウントを丸ごと奪われかねません。Coupang の流出がまさにこの『自分の情報の編集』ページで起きたことを思い出せば、この決定の重さが見えます。
欠けているもの（3）——退会、法が懸かった決定
三つ目が最も重要です。退会です。退会機能なしでサービスを開く例は思いのほか多い。ですが退会を望む利用者は必ず現れ、方法がなければその人は怒った状態でメールを送ります。しかもこれは感情の問題では終わりません。個人情報保護法上、利用者は自分の情報を削除する権利を持ちます。退会要求を処理せず粘れば、法の問題になります。
退会で決めるべき決定はこれです。データを本当に消すのか、それとも消したように表示だけするのか。表示だけにする方式をソフトデリート（soft delete）と呼びます。どちらが正しいかはサービスの性質によります。決済履歴のあるサービスなら、税法上、取引記録を一定期間保存する義務があり、全部消すとかえって問題になります。
そこで通常は折衷します。メールのような個人を識別できる情報は匿名化し（誰か分からないように消すか置き換え）、取引記録そのものは残す、という形です。『退会したアカウントではログインできない』ところまで決めねばなりません。この判断はコードではなく方針の領域で、作る前に決めてこそ AI に正確に指示できます。
欠けているもの（4）（5）——保護方針と利用規約、そしてコピペの罠
四つ目と五つ目は機能ではなく文書です。ですがこの二枚が法と契約の問題です。まず個人情報保護方針。あなたがメールを一つ受け取った瞬間から、法のいう『個人情報取扱者』になります。何の情報をなぜ集め、いつまで保管し、どう破棄するかを定めて公開する義務が生じます。これを作らない、あるいは公開しないだけでも、法律上 1,000 万ウォン以下の過料の条項に触れます。
利用規約は性質が違います。これは政府ではなく利用者との問題です。規約は利用者が登録する瞬間にサービスと結ぶ契約です。この契約書がなければ、ある利用者が他人を罵倒したり詐欺をはたらいたりして『アカウントを停止します』と言ったとき、『何を根拠に？』に答える言葉がありません。人が集まるサービスで、規約は運営者を守る文書です。
ここでよくある考え。『その文書、よそからコピーしてくればいいのでは？』実際みなそうします。ですが罠があります。保護方針が実際のサービスと違えば、それ自体が違反です。集めてもいない情報を集めると書いたり、実際に集めていながら書かなかったりすれば、合わない服を着たのと同じです。だからこの文書はコピーではなく『自分のサービスが何のデータを扱うか』から出発せねばなりません。ではそのデータ構造を誰が一番よく知るか。今しがたコードを書いた AI です。
管理者ページと、『ソーシャルログインなら終わり』という錯覚
会員データが生まれた瞬間、もう一つ必要になります。それを覗いて管理する人、すなわち運営者用の管理者ページです。会員一覧を検索し、登録・退会の別を見て、問題を起こした会員を停止させる画面です。ここにも決定が潜みます。管理者は会員情報をどこまで見られるべきか。パスワードはハッシュなので運営者でも見えません。メールは問い合わせ対応のために見る必要があるかもしれない。管理者が見られる範囲を定めることも、『個人データ最小アクセス』という原則が懸かった方針決定です。
そして停止ボタン。管理者が会員を停止できる根拠は、まさに利用規約にあります。規約なしに停止ボタンを作れば運営者の気まぐれで追い出す機能になり、規約があれば契約に基づく正当な措置になります。文書と機能はこうして結びつきます。
最後によくある誤解を一つ。『Kakao や Google のソーシャルログインを付ければ、この宿題は消えるのでは？』パスワードを受け取らなくなるので、パスワード再設定は一つ減るのは確かです。しかし退会、保護方針、利用規約はそのまま全部必要です。むしろ保護方針には『Kakao からどんな情報を受け取るか』という項目が追加で入ります。ソーシャルログインは五つのうち一つを減らすだけで、宿題全体を消してはくれません。
実戦プロンプト——AI に先に問い返させよ
では実際どう指示すべきか。左が誰もが入れる一行、右が本物のサービスに耐える水準のプロンプトです。長さはかなり違いますが、よく見ると難しい技術用語はありません。すべて上で話した方針決定です。再設定リンクは 30 分、退会は表示だけで匿名化、保護方針は実際に集める項目に基づく。コーディング知識ではなく、サービスをどう運営するかの決定です。
肝はプロンプト末尾の一行です。『実装する前に、私が決めていない方針のうち判断が要るものがあれば、先に質問して。』この一行を入れると、AI はすぐコードを書かず問い返します。『メール認証を求めますか、認証なしですぐ登録しますか？』『メールを変えるとき、新しいメールの認証は必要ですか？』こう問われること自体が学びです。自分が思いつかなかった決定を、AI がリストにして差し出してくれるからです。
この一行が AI を単なるコーダーから企画パートナーに変えます。答える過程で方針が積み上がり、AI が何を問うかを見て、自分の知らなかったことを知ります。実戦プロンプトにはこの一文を常に入れることをお勧めします。
メールとパスワードで登録とログインができるように作って。
ログインしたら歓迎メッセージが出るトップ画面も作って。会員登録とログインを実装して。
- メールとパスワード（8 文字以上）で登録。
- パスワード再設定リンクは登録メールへ送り、30 分だけ有効、一度使ったら無効に。
- 会員情報の編集：ログイン中の利用者がメール/パスワードを変えられるように。変更時は現在のパスワードをもう一度入力させて。
- 退会：マイ情報ページからできるように。誤操作防止のためパスワードを入力させてから進める。データは本当には消さず退会表示だけにし、メールなど個人を識別できる情報は匿名化。退会したアカウントではログイン不可。
- 個人情報保護方針と利用規約のページを作り、内容はこのサービスが実際に集める情報に基づいて記述。全ページのフッターにリンクを。
- 登録時に規約/保護方針への同意チェックボックスを置き、同意しないと登録できないように。
実装する前に、私が決めていない方針のうち判断が要るものがあれば、先に質問して。結論——実力は意思決定リストから生まれる
まとめるとこうです。AI で会員登録を作るのは 5 分で済みます。ですがそれが『サービス』になるには、まず意思決定リストが立っていなければなりません——パスワード再設定、会員情報の編集、退会、個人情報保護方針、利用規約、そして管理者ページ。コードは AI が書きますが、決定は人がせねばなりません。
会員登録一つでこれだけ、サービス一つを作れば、こうした意思決定リストが何十も積み上がります。機能が変わるたびデータベース構造も変わり、その変更履歴を安全に管理する仕組みをマイグレーション（migration）と呼びます。変更が順に記録され、問題が起きれば戻せるので、公開後もデータベースを安全に直せます。そして機能がそう変わるたび、保護方針と規約も更新し続けねばならず、ここでもコードを知る AI の助けを借りられます。
だから AI 時代に作る人の実力は、コードではなくこの意思決定リストから生まれます。コードは AI が全部書きます。しかし何を決めるべきかは、サービスを作り、運営して経験した人だけが知っています。あなたのサービスに、この意思決定リストは用意できていますか？