AIで作ったアプリに本当にユーザーアカウントは必要か? ログイン機能を追加する前に判断する方法

AIで作ったアプリに、たいていの人がまず追加するのはログイン画面だ。ユーザーアカウントとは、要するにログインのこと──メールアドレス、パスワード、プロフィールがあり、アプリが次の訪問時に同じ人だと認識し、その人のデータを他の人のものと区別して保管できるようにする仕組みだ。これを追加すると、なんだかきちんとした、大人のアプリらしいことをしている気がする。本物のアプリにはアカウントがあるものだから、自分のアプリにもあるべきだ、と。しかし、ユーザーアカウントは早すぎるタイミングで追加してしまいがちなものの代表であり、いったん組み込んでしまうと取り除くのが最も厄介なものの一つでもある。ビルダーにサインアップフォームを頼む前に、そもそも自分のアプリにそれが必要なのかどうか、数分かけて考えてみる価値がある。

これはログインに反対する主張ではない。ログインが本当に必要なアプリはたくさんある。これは、反射的にではなく、意図を持って決めようという話だ。

ユーザーアカウントは実際に何をしているのか?

ログインの仕組みが担う仕事は3つだけだ。訪問のたびに同じ人だと認識すること、各人のデータを他の人のものと分けておくこと、そのデータを非公開に保つこと。それだけだ。メールアドレス、パスワード、「パスワードをお忘れですか」、隅にある小さなアバター──これらは全部、その3つの仕事のための配管にすぎない。

だから本当に問うべきは「ログインを追加すべきか?」ではない。「自分のアプリは、人を認識する必要があるか、データを分ける必要があるか、非公開にする必要があるか?」だ。この3つすべての答えがノーなら、ログインは理由もなく背負っている重荷にすぎない。

自分のアプリにユーザーアカウントが必要かどうか、どう見極めるか?

3つの質問をしてみよう。訪問のたびに相手が誰かを覚えておく必要があるか、各人が自分専用のプライベートなデータを持つか、支払いやメール送信をする必要があるか。このうちどれか一つでもイエスなら、いずれアカウントが必要になるだろう。すべてノーなら、アカウントなしで本来作りたいものをそのまま作れる。

訪問のたびに相手が誰かを覚えておく必要があるか? チップ計算機には必要ない。単位変換ツールにも必要ない。一回きりの「食事プランを作って」というツールも、ユーザーが結果を受け取って満足して帰るだけなら必要ないかもしれない。ページを閉じたらすべてリセットされても誰も困らないなら、アカウントは不要だ。作ったものが消えたらユーザーが困るなら、アカウントが必要な方向に向かっている。

各人が自分専用のプライベートなデータを持つか? 個人用のToDoリスト、保存したレシピ集、アップロードした書類フォルダ──これらは一人の持ち物であり、他の誰にも漏れてはいけない。これがアカウントを持つべき最も強い理由だ。しかし、みんなが同じ店舗一覧を見る公開のレストランディレクトリには「あなただけのもの」自体が存在しない。同じような形のアプリでも、答えはまったく違う。

人に課金したり、メールを送ったりする必要があるか? お金や継続的な連絡が絡んだ瞬間、誰が誰かを確実に把握する手段が必要になる。アイデアを検証している間は後回しにできるが、いずれ必要になる。

ユーザーアカウントを追加すると、実際どんなコストがかかるのか?

ログイン画面は一つの機能ではなく、4つの隠れたコストだ。何気なく訪れる人を追い返すサインアップの壁、終わりのないパスワード対応、守らなければならない個人データ、そして壊れうる部品の増加。「ログインを追加して」という一言のリクエストには、こんなものがついてくる。

アプリの前に立ちはだかる壁。 サインアップフォームは一つひとつが「ちょっと気になる」から「実際に使う」までの間にあるステップであり、ステップがあるたびに離脱する人が出る。アプリが何をするものかを見せる前にメールアドレスとパスワードを求めることは、何気なく試そうとしていた人たちを失うことにつながる──できたばかりのアプリが最も失いたくない相手だ。
終わりのないパスワード対応。 人はパスワードを忘れる。メールアドレスを打ち間違える。二重にサインアップして、自分のデータがどこに行ったのか分からなくなる。アカウントの仕組みを作れば、「ログインできない」というメッセージがじわじわと絶えず届くようになり、あなたがそのヘルプデスク係になる。
守らなければならない個人データの山。 メールアドレスとパスワードを保管し始めた瞬間、それが漏れたら大変なことになる情報を抱えることになる。これはチェックボックス一つで済む話ではなく、責任だ。
壊れうる部品の増加。 ログイン、ログアウト、パスワードリセット、「ログイン状態を保持する」、変なタイミングで切れるセッション──そのどれもが、土曜日にデバッグしたくないタイミングで壊れうるものだ。

だからといって、やめろという話ではない。アカウントはその置き場所に見合うだけの価値を示すべきだ、ということだ。ビルダーが2分で書いてくれるとしても、決してタダではないのだから。

実際のアプリではどう現れるか

ある友人が、AIビルダーで結婚式の出欠確認ページを作った。最初の発想は、招待客一人ひとりにログインを持たせることだった。しかし実際には何一つ必要なかった。招待状はそれぞれ固有のリンク付きで送られ、リンクを開けばその招待客専用のフォームに直接たどり着く。誰も何かを作成する必要はなかった。パスワードもヘルプデスクも壁もない。「アカウント」の代わりがそのリンクだったのだ。

別の人は、食事プラン生成ツールを作った。バージョン1にはアカウントがなかった。好みを入力すればプランが出てくる、それだけだ。誰でもワンクリックで試せたからこそトラフィックを集められた。「これ保存できますか?」というメッセージが続いた後になってようやく、軽量な「メールアドレスで保存」オプションを追加した。そのころには、ユーザー自身が求めているのだから、そのコストを払う価値があると分かっていた。

対照的な例が、クライアントポータルを作ったフリーランサーだ。各クライアントが非公開のファイルをアップロードし、自分のものだけを見る。このアプリは初日からアカウントが必要だった──「クライアントごとに非公開の書類」というものは、誰がログインしているかを知らずには成り立たないからだ。違いは技術ではない。そのアプリに「あなただけのもの」があり、それを守らなければならないかどうかだ。

フルのユーザーアカウントより軽い代替手段には何があるか?

メールアドレスとパスワードによる本格的なアカウントが必要ないことも多い。たいてい、次の5つの軽い選択肢のどれかで用は足りる。

共有できる秘密のリンク。 先ほどのRSVPページのように、固有のURLがあれば、ログインなしでも自分専用のものにアクセスできる。
マジックリンク。 ユーザーがメールアドレスを入力すると「ここをクリックしてログイン」というリンクが届き、パスワードを扱う必要が一切ない。サポートの手間が減り、ビルダーに設定してもらえる。
「メールアドレスで保存」。 まずは自由にアプリを使ってもらい、何かを保存したくなったときだけメールアドレスを尋ねる。壁は価値を示した後に置く、前ではなく。
一つの共有パスワード。 少人数のチームが使う社内ツールなら、全員が知っている一つのパスワードで実際に十分なこともある。
何もなし。 ユーザーの作業内容を本人のブラウザ自体に保存しておけば、アカウントなしでも次に来たときにちゃんと残っている。個人的で、失っても大したことのないツールならそれで十分だ。

フルのサインアップフローをデフォルトにする前に、これらのどれが自分のアプリに合うか、ビルダーに相談してみよう。

自分に合ったアカウントをビルダーにどう頼めばいいか?

欲しいと思っている機能ではなく、アカウントに担わせたい仕事を説明しよう。「ログインを追加して」ではビルダーにほとんど何も伝わらず、当て推量で作られてしまう。「みんなが自分のリストを保存して、次にスマホから見返せるようにしたい」と言えば、「ユーザーがサインアップできるように」と言うのとはまったく違う、より適切な作りになる。まだアカウントが本題でないなら、そうはっきり伝えよう。「今のところアカウントはなし。リンクを持っている人なら誰でも使える」というふうに。

そして、後から拡張できる継ぎ目を残して設計しておこう。後からアカウントを追加するというのは、既存のデータを真新しいログインに結びつける作業であり、これが意外と面倒だ。将来アカウントを追加するかもしれないとビルダーに伝えておけば、今のうちから各人のデータを何か安定したものに紐づけておいてくれる。そうしておけば、実際に必要になったときのアップグレードが安上がりで済む。

問い続けるべき問い

ユーザーアカウントを追加する前に、こう問いかけよう。これを誰でも見られるようにしたら、何が困るか? 正直な答えが「何も困らない」──公開情報だから、あるいはリセットされるものだから、あるいはリンクがあれば十分だから──なら、壁もヘルプデスクも、守るべきデータの山も、あなたはすでに避けられたことになる。もし答えが「大いに困る」なら、アカウントはそのコストに見合う価値がある。そしてそのとき、あなたは「本物のアプリにはアカウントがあるものだから」ではなく、「自分のアプリに必要だから」という理由でアカウントを追加していることになる。

どちらの結論であっても、あなたは自分で決めたのだ。それこそが大事なことだ。