ログイン方式の選び方：誰がログインし、何を預かるか

AUM

このサイトには、ログイン機能の作り方の記事がいくつもある。合言葉で守る、Cloudflare Access で守る、Google でログインする、パスキーを使う、ログインキーを配る。この記事では、どれをどう選べばよいのかを解説する。

ここで扱うのは作り方ではなく選び方。コードは AI が書いてくれるが、「どの方式にするか」は頼む側が決めることになる。

本記事の位置付け

Webアプリの2つのタイプは「データをどこに置くか」の地図だった。この記事は「誰を、どうやって見分けるか」の地図。どちらも、選び方を先に知っておくと、頼み方が決まる。

選ぶときに見るのは3つ。

そもそもログイン機能は必要か
誰がログインするのか（特定の少人数か、不特定多数か）
不特定多数なら、方式の違いをどう見るか

そのうえで、開発前に決めておくことを4章にまとめた。

先に、この記事で扱う6つの方式を1つの表にしておく。それぞれの見方は2章と3章で説明する。

方式	対象	本人確認を任せる先	相手に求めるもの	自分が預かるもの	ログインできなくなったら	料金
合言葉（BAU）	特定の少人数	合言葉を知っているか	合言葉	合言葉（Cloudflare に預ける）	合言葉を忘れた → 運営者が教える	無料
Cloudflare Access（CFA）	特定の少人数	本人のメール（届いたコードを入力）	許可されたメールアドレス	入れてよいメールアドレスの一覧	メールを受け取れない → メール事業者	50人まで無料。その先は有料プラン（1人 $7/月）
マジックリンク（MLA）	不特定多数	本人のメール	メールアドレスだけ	メールアドレス	メールを受け取れない → メール事業者	月 $5（Workers Paid）と独自ドメイン
ソーシャルログイン（SOL）	不特定多数	Google などのサービス	Google アカウントなど	見分ける番号だけ	Google などに入れない → Google など	無料
パスキー（PKA）	不特定多数	本人の端末（指紋・顔・PIN）	対応した端末	公開鍵だけ	端末を全部なくした → サイト運営者（戻す仕組みを用意しておく）	無料
ログインキー（ACC）	不特定多数	本人が保管する文字列	文字列の保管	キーのハッシュだけ	キーをなくした、ブラウザが消した → サイト運営者（本人だと確かめて再発行）	無料

料金は、各記事の作り方で動かしたときのもの。Cloudflare Access は、50人を超えても勝手に課金はされず、51人目がログインできずに止められる（→ CFA）。

1. そもそもログイン機能は必要か

多くの公開サイトには、ログインが要らない。 宣伝のためのサイトや、誰でも使ってほしい道具は、誰でも見られるほうがよい。ログインが要るのは、相手を絞りたい部分だけ。

自分だけが使う管理画面
ログインした本人だけが見る画面（自分の記録など）
身内や関係者にだけ見せたいページ

ログイン機能を作らなければ、ログインにまつわる失敗も起きない。

1-1. 管理画面は必須ではない

ここでいう管理画面は、投稿を消したりデータを直したりするために、自分で作るページ（管理者ページ）のこと。4-2 で扱う外部サービスの設定画面（Cloudflare や Google など）とは別のもの。

管理する人が自分ひとりなら、管理画面を作らずに Claude Code に頼む手がある。たとえば掲示板の不適切な投稿は、「◯◯の投稿を削除して」と頼めば、Claude Code が本番のデータベースを直接操作して消す（→ D1W の7-3）。アンケートの集計も同じで、「集計して」と頼めば表にして返ってくる。D1P の診断アンケートは、集計を見る画面を作らずにこの形にしている。

管理画面を作ると、その画面に入るためのログイン機能も作ることになる。ログイン機能を付け忘れる、画面は守ったが裏の API が誰でも呼べるままになっている、といった失敗の元になる（→ CHK の点検項目「ログインなしで管理画面に入れるか」）。管理画面がなければ、このような心配は起こらない。

管理画面が欲しくなるのは、複数人で管理するときや、自分以外の人に運営を任せるとき。そのときは、管理画面の部分だけに Cloudflare Access をかける（→ ADM）。画面とその裏の API の両方を守ることになるので、ほかの記事でログイン機能を作ってみてからでよい。

WordPress や EmDash のように、最初から管理画面を持つ仕組みを使うなら話は別。管理画面もそのログイン機能も、作り込まれたものを使うことになる。

2. 誰がログインするのか

ログインが要るなら、次に「誰がログインするのか」を考える。頼む側がいちばん最初に答えられる問いでもある。

	誰がログインするか	要るもの
特定の少人数	自分、身内、関係者。顔が分かる相手	入れるかどうかを決めるだけ
不特定多数	誰が来るか分からない	一人ひとりを見分ける仕組み（アカウント）

ここを飛ばして方式を比べ始めると、少人数で足りるのにアカウントの仕組みを作ってしまい、手間のかかる遠回りになる。

2-1. 特定の少人数なら

	合言葉（BAU）	Cloudflare Access（CFA）
入れる人の決め方	合言葉を知っているか	メールアドレスで1人ずつ
誰が入ったか	区別できない	メールアドレスで分かる
1人だけ外す	できない（全員の合言葉を変える）	ポリシーからその人を消す
書くコード	認証の処理（頼めば書いてもらえる）	なし
止まる場所	自分のサイトの中	サイトに届く前（Cloudflare 側）
初回の準備	合言葉を Cloudflare に預ける	Zero Trust の初回設定（カード登録あり）
人数	何人でも（合言葉を配るだけ）	無料で50人まで

少人数で守るなら、Cloudflare Access のほうが守りは強く、使い始めてからの手間も少ない。合言葉方式は自分のサイトの中で照合するが、Access はサイトに届く前に Cloudflare が止めるので、許可していない人のリクエストはサイトまで届かない。すでに Cloudflare を使っていれば、新しいサービスもアカウントも増えない。

ただし、初回だけは手間がかかる。Zero Trust の初回設定でクレジットカードの登録を求められ（$0 の購入として扱われ、請求はされない。あとから消しても Access は使える）、英語の設定画面をいくつか開く。一度きりの用途なら合言葉、続けて使うなら Access、という分け方もできる。

サイト全体ではなく、アプリの一部（管理画面など）だけを守るなら ADM の形になる。

2-2. 不特定多数なら：何を預かるか

不特定多数に使わせるなら、一人ひとりのアカウントが要る。方式は、本人確認を何に任せるかで分かれる。

方式	本人確認を任せる先	自分が預かるもの	記事
メールに届くリンク（マジックリンク）	本人のメール	メールアドレス（ハッシュにして持つこともできる）	MLA
Google などでログイン（ソーシャルログイン）	Google・GitHub などのサービス	本人を見分ける番号だけ（受け取る情報を最小にした場合）	SOL
パスキー	本人の端末（指紋・顔・PIN）	公開鍵だけ	PKA
ログインキー	本人が保管する文字列	キーのハッシュ	ACC

どれも「自分でパスワードを預からない」点が共通している。自分でメールアドレスとパスワードを預かる方式は、この表に入れていない。漏れたときの対応、パスワードを忘れた人への対応まで自分の仕事になり、安全に作り切るのが難しいため。

3. 不特定多数向けの方式を比べる

2-2 の4つの方式を比べるときの見方を2つ挙げる。

3-1. ユーザー側と運営側の負担はトレードオフ

この4つは、上から順に良いという順位表ではない。2つの物差しが逆を向くため。

方式	相手に求めるもの	自分が預かるもの
マジックリンク	メールアドレスだけ（使える人がいちばん広い）	メールアドレス（そのまま持つなら、預かる責任がいちばん大きい）
ソーシャルログイン	Google などのアカウント	見分ける番号だけ
パスキー	対応した端末	公開鍵だけ
ログインキー	文字列を自分で保管すること	キーのハッシュだけ

マジックリンクは、メールさえあれば誰でも使えるかわりに、メールアドレスを預かることになる。ハッシュにして持てば預かるものは減らせるが、そのかわり運営からメールを送れなくなる（→ MLA）。ログインキーは個人情報を預からないかわりに、使う人に文字列の保管を求める。「相手に求めるものが少ない」と「自分が預かるものが少ない」は、同時には選べない。

3-2. ログインできなくなったときの負担

ログインできなくなったときに誰が対応するかは、方式で違う。

	ログインできなくなる場面	対応するのは
マジックリンク	メールを受け取れなくなったとき	メール事業者（アドレスを変えたら、運営側での付け替えも要る）
ソーシャルログイン	Google などのアカウントに入れなくなったとき	Google など（アカウントの回復はそちらの仕事）
パスキー	パスキーの入った端末を全部なくしたとき（端末の同期があれば起きにくい）	サイト運営者（本人だと確かめて戻す。その仕組みを用意しなければ戻せない）
ログインキー	キーをなくしたとき、ブラウザがキーを消したとき	サイト運営者（本人だと確かめてキーを再発行する。その仕組みを用意しなければ戻せない）

マジックリンクとソーシャルログインは、ログインできなくなっても、対応するのはメール事業者や Google など、サイトの外になる。問い合わせもそちらにしてもらう。運営側がすることは、マジックリンクでアドレスを変えた人の付け替えくらいで済む。

どの方式でも、最後の手段として、運営者が別の手段で本人だと確かめ、新しいアカウントにデータを移すことはできる。ただし本人の確かめ方とデータを移す作業は、方式とは別に、運営者が用意することになる。

パスキーは、端末の同期（同じ Apple アカウントや Google アカウントの端末どうしでパスキーが共有される仕組み）があるので、端末を替えても同じ人として使える。ただし全部の端末をなくした人を戻す仕組みは、パスキーとは別に用意することになる。運営者が本人だと確かめて戻すほか、使う人が自分で戻れるリカバリコード（使い捨ての回復用コード）を足すこともできる（PKAの7章）。また、パスキーは登録したドメインに縛られるので、あとで独自ドメインに移すと登録し直しになる（PKAの2章）。

ログインキーは、なくす人が実際に出る。なくしたら戻せないままにはしにくいので、運用するとキーの再発行という仕事が運営側に出てくる。

事例を1つ挙げる。連続開催しているイベントで使うアンケートのサービスで、1回目はログインキーで作り、2回目のイベントではソーシャルログインに変えた。理由は安全さではなかった。

端末を替えると別人になった：1回目のイベントでは、事前と事後の2回のアンケートで、事後の22件のうち8件が、事前と別のアカウントになっていた。家のパソコンで事前、会場のスマホで事後、と端末が変わったため
対策を重ねても、なくす人が出た：キーのコピー、メールや LINE への保存、パスワードマネージャーへの対応まで作ったが、ブラウザがキーを消す、キーそのものをなくす、などでうまく機能しなかった

2回目では、「キーをなくした人のための再発行」のタスクがなくなった。受け取る情報を最小にしたので、個人情報も増えていない。そのかわり、ログインキーで作られた1回目の182アカウントは引き継がずに残し、その人たちはログインできなくなった。

4. 開発前に決めておくこと

頼む側が決めておくことを並べる。

決めること	問い
使う人の体験	使う人は何をすることになるか（合言葉を入れる、メールのコードを入れる、「Google でログイン」を押す、文字列を保管する）
なくしたとき	使う人がログインできなくなったら、どうやって戻るか
自分が背負う運用	「入れません」という問い合わせに、誰が答えるか
相手に求めるもの	Google のアカウント、対応した端末、メールアドレス。求めるほど、使える人が減る
あとから変えられるか	方式を替えるとき、いまのユーザーをどうするか
何を預かるか	メールアドレスを持つのか、持たないのか

これが決まっていれば、「ログイン機能を作って」ではなく、条件ごと伝えられる。スキルを入れておくと、ログイン方式を、Claude Code もこの記事と同じ順で考えやすくなる（→ 6章）。たとえば次のように頼む。

この掲示板に、不特定多数の人が使うログイン機能を付けたい。
個人情報は預かりたくないので、Google でログインする方式にして。
受け取る情報は、本人を見分けるのに要る最小限にして。

4-1. メールアドレスを預かると決めたら

メールで本人確認をする方式（マジックリンクや、2-2 の表には入れていないメールとパスワード）を選ぶこと自体は止めない。ただ、選ぶと次のことが自分の仕事になる。

メールアドレスを読める形で持つと、漏れたときに個人情報の漏洩になる。マジックリンクは、ログインのたびに本人がアドレスを入れるので、ハッシュにして持つ作りもできる（→ MLA）。ただしハッシュだけでは、運営からお知らせのメールを送れない
メールが届かないと、その人はログインできない。「届かない」という問い合わせが自分に来る
メールを送る仕組みを用意することになる。ログインの仕組みを提供するサービスに付いてくるメールは、送れる数が本番では足りないほど絞られていることが多い。外のサービスを使えば、その無料枠と障害に自分のサイトが左右される。Cloudflare の中で送る Cloudflare Email Service もあるが、有料プラン（Workers Paid）と独自ドメインが要る
「退会したいので消してほしい」に応える

これを読んだうえで「それでもメールがよい」と言えるなら、それは選んだうえでの判断。

個人情報を集めたいだけなら、自分のサイトで預からず、Google フォームのような外のサービスに任せるほうがよい。

4-2. 外部サービスの設定画面を開くか

頼む側の手間の感じ方に近い物差しを、もう1つ。

	Claude Code に頼めば進む	自分も外部サービスの設定画面を開く
特定の少人数	合言葉（BAU）	Cloudflare Access（CFA）
不特定多数	パスキー（PKA）、ログインキー（ACC）	マジックリンク（MLA）、ソーシャルログイン（SOL）

外部サービスの設定画面とは、Cloudflare の Zero Trust、Google Cloud Console、メールを送るサービスの設定画面など。コードの量とは別の物差しで、たとえば Cloudflare Access はコードがゼロでも、初回は自分で設定画面を開く。ログインキーはコードが多くても、外の設定が無いので頼めば進む。

5. 補足：仕組みを少しだけ

選び方に関わる範囲で、仕組みに触れておく。読まなくても選べる。

パスキーが「漏れても困らないもの」しか預からない理由。 パスキーは、鍵を2つ1組で作る。1つ（秘密鍵）は本人の端末から外に出ず、もう1つ（公開鍵）だけをサイトに預ける。公開鍵は、秘密鍵で作った署名が本物かを確かめるためのもので、公開鍵からは秘密鍵を作れない。だから、サイトから公開鍵が漏れても、なりすましには使えない。

Google でログインするとき、パスワードがサイトを通らない理由。 会社の SSO（1回ログインすれば社内の別のシステムにも入れる仕組み）を、個人の Google アカウントで行うものと考えると近い（→ SOL の1章）。ログインの画面は Google のもので、パスワードは Google にだけ送られる。ログインが済むと、Google が署名した「この人は確かに本人」という引換券がサイトに届く。サイトは、Google が公開している鍵で署名を確かめるだけ。だからサイトは、パスワードを一度も受け取らない。

6. 補足：Claude Code に入れておけるスキル

この記事の考え方の一部は、Claude Code の「スキル」として入れておける。スキルは、関係する場面で Claude Code が自分で読み込む手順書のようなもの。このサイトでは2つ配っている。

スキル	使われる場面	中身
kukude-webapp-safety	公開・デプロイ・push の前、ログイン機能を作るとき	公開の前に、ログインなしで開けるページ・呼べる API・読めるデータを一覧にして見せる。ログイン機能を足すときは、この記事と同じ順（そもそも要るか、少人数なら合言葉、不特定多数ならソーシャルログイン・パスキー・ログインキー）で考える
uuid-key-auth	ログインキーの方式でアカウントを作るとき	ACC で扱った作り方の要点。キーはハッシュで保存する、ヘッダで送る、別の端末に渡すリンクは `#key=` にする、など

入れ方は IRN の2-2と同じで、マーケットプレイス yto/yto-skills を追加し、プラグインの一覧から Kukude webapp safety と Uuid key auth を選んで入れる。ターミナル（Claude Code の CLI）ならこの3行。

/plugin marketplace add yto/yto-skills
/plugin install kukude-webapp-safety@yto-skills
/plugin install uuid-key-auth@yto-skills

スキルは考え方を思い出させる手順書で、入れれば安全になるというものではない。

備忘録

方式ごとの作り方は各記事にある。合言葉は BAU、Cloudflare Access は CFA（サイト全体）と ADM（一部だけ）、ソーシャルログインは SOL、パスキーは PKA、ログインキーは ACC
ログインキーが消える仕組み（ブラウザの保存領域が消されること）は STO にある
Cloudflare Access の無料プランの上限は50人（51人目はログインできずに止められ、勝手に課金はされない）

2026-10-27 (last updated: 2026-11-03) タツヲ (yto)

☕️ Vibecoding Notes を応援