IDとパスワードを同時に表示しないログインフォームのメリットは？

Question

前提

以下WebサイトのようにIDとパスワードを同時に表示しないフォームを見かけることがあります。
気づけば採用事例もいつの時期からか正確には不明ですが、増えてきたように思います。
なんとなく無視していましたが、よくよく考えると不思議に思えてきました。

Apple

https://ddjkaamml8q8x.cloudfront.net/questions/2026-06-07/cb490163-cf0f-4b86-9936-998bd976e173.png

Yahoo

https://ddjkaamml8q8x.cloudfront.net/questions/2026-06-07/18cf7e2d-6b46-4458-8542-17875a48bd4f.png

質問

IDとパスワードを同時に表示しないログインフォームのメリット何ですか？

個人的な感想

• 総当たり攻撃対策
  フォームで対策するのではなくCAPTCHAや多要素認証やレートリミットを実装して対策するべきではないでしょうか。
  また、設計次第ですが、IDの存在有無によってパスワード入力画面に遷移できるかの条件分岐があるなら、IDが存在しているかのチェックができてしまう脆弱な設計だと思います。
  Yahooのようなサービスならスパムメールを送信する前に、宛先が存在するかどうかのチェックに利用されてしまうのではないでしょうか？
  証券会社のシステムならメールアドレス登録有無チェックに利用されて、なりすましなどで「あなたは◯◯◯証券会社を利用してますよね。△△△という話があるのですが・・・」というように悪性されてしまうのではないでしょうか。
  また、応答内容に { "email_exists": true } のような直接的な表現が含まれていないとしても、タイミング攻撃によって存在の有無を推測する事も可能です。
  メリットがあると感じません。

• 開発の手間
  フォームを2つに別けることによる開発の手間も増えます。
  メリットがあると感じません。

• 利用者の手間
  Google Chrome標準のパスワードマネージャーを利用している場合はID選択後に、パスワードをさらに選択する必要があって2度手間になっています。
  IDとパスワードを同時に表示していれば1度の選択でログインできます。
  メリットがあると感じません。

• 巨大プラットフォームでの採用事例
  過去にYahooはIDパスワードどちらも表示していた時期がありました。
  しかし、今は個別に表示されるように変わっています。
  趣味で好きに変化させる事ができる個人開発とは異なり、有名企業が深く調べずに「他社がやってるからマネしてみよう」というような軽い気持ちでログインフォームを変更するとは思えません。
  何らかのメリットが有るから変更したはずです。

Comments

[allen]

個人的には、主なメリットは総当たり攻撃対策そのものではなく、認証フローの柔軟性向上とユーザー体験の最適化にあると思います。

まず、ID（メールアドレス）を先に入力させることで、そのアカウントに応じた認証方式へ分岐できます。

例えば、

* パスワード認証
* パスキー（Passkey）
* SMS認証
* 多要素認証（MFA）
* SSO（Google、Apple、企業アカウント等）

などをアカウントごとに切り替えることができます。

実際にGoogleやMicrosoftなどでも、メールアドレス入力後に認証方法を決定するフローが採用されています。

また、大規模サービスでは「このアカウントはパスワードではなくSSOでログインしてください」「このアカウントはパスキー設定済みです」といった案内を出せるため、1画面で全ての入力欄を表示するよりもUIを簡潔にできます。

セキュリティ面については、ご指摘の通り、CAPTCHA・レートリミット・MFA等の方が本質的な対策であり、ID入力画面とパスワード入力画面を分離したこと自体が強力な防御策になるとは思いません。

一方で、アカウント存在確認（User Enumeration）については、多くの大手サービスは「存在するかどうかを明示しない」「レスポンス時間を均一化する」などの対策を行っています。

そのため、この方式の主目的はセキュリティ強化というより、

* 認証方式の分岐
* パスキー対応
* SSO対応
* UI/UXの最適化
* 将来的な認証基盤の拡張

といった設計上のメリットが大きいのではないかと思います。

Answer 1

生体認証・パスキーなどのパスワードを使わない認証方法が出てきたので、まず ID を入力させて認証方法で出し分けたいんじゃないでしょうか。

Comments

[minato2000]

なるほど、と思い調べてみたのですが、以下2種類どちらも手動でIDを入力する必要はありませんでした。パスキーの選択ダイアログから選択するだけでした。

1. Discoverable Credential （別名：パスキー）
2. Non-Discoverable Credential

また、SBI証券（以下画像）のようにそもそもIDの入力欄を設置していなくても動作します。
https://ddjkaamml8q8x.cloudfront.net/questions/2026-06-08/1d2706a8-1219-424c-a80b-8259fae2736a.png

つまり、パスキー関係でID入力欄はあってもなくても良く、パスワード入力欄はそもそも関係がない話です。
あえてパスワードを非表示にするような画面設計をするメリットは無いと感じました。
開発者の手間やパスワード方式を利用している利用者の手間が増えるだけではないでしょうか。
なぜ、あえてパスワード入力画面を消す必要があったのか不思議です。

[68user]

わたしは SBI証券のようなログイン画面はよくないと思います。なぜならわたしはパスキーで登録したかどうかなんて覚えてないから。よって、まずは ログインID だけ入力させ、パスキー登録状況に応じてその後のフローを変える方がよいと思います。

あと B向けサービスでは 外部 IdP を使った SSO に対応している場合も多いでしょうけど、その場合もまずはログインID だけ入力させて外部 IdP にリダイレクトなのでしょう。

> パスキー関係でID入力欄はあってもなくても良く

なるほど Discoverable Credential や、Non-Discoverable Credential における Conditional UI など選択肢が出てくる場合もあるでしょうけど、新しい端末での初回アクセスなど ID 入力欄が必要な場合もありそうな気がします。詳しくないので間違っていたら失礼。

ところで「普通はログインID・パスワードが同一フォームにあるべきで、ログインIDしかないのはおかしい」という思想を感じるのですが、PC だとそうかもなぁと思うのですが、スマホ前提で考えると複数項目があるフォームって使いづらくないですか?

[minato2000]

> SBI証券のようなログイン画面はよくない
> パスキーで登録したかどうかなんて覚えてないから
確かに幅広い層からのアクセスが想定されるWebサイトではおっしゃるとおりですね。無駄な問い合わせが増える原因にもなってしまいます。できる限り利用者に判断させる余地を捨ててシンプルにするべきですね。

> スマホ前提で考えると複数項目があるフォームって使いづらくないですか?
主観的な話になってしまいますが個人的には複数項目（ID, パスワードとsubmitボタンの3つ）が表示される程度であれば気にならないです。
むしろパスワードマネージャーで一発で入力できないほうが辛く感じます。
すべてのWebサイトのパスワードは制限がなければ英数字大文字小文字記号混じりで32文字以上を指定しているので覚えられないです。

ただし、複数項目がSBI証券のような画面を意味するのであれば、使いづらいと感じます。
スマホで出ると、PCに比べて画面が狭いスマホでは画面外にボタンが移動することになり、利用者が画面を縦横スクロールしない事によって「パスキーのフォーム」または「IDパスワードのフォーム」どちらかに気付けない事も考えられます。

[minato2000]

また、今気づいたのですがYahooとAppleどちらも電話番号ログインに対応していて、Yahooの画面は認証コード入力画面に移るので妥当なUIだと感じました。
電話番号ログインの場合はパスワードは存在しないのでパスワード欄が最初から表示されている方が違和感を覚えます。

ただし、Appleは電話番号ログインでもパスワードが存在するようなので理解できません。

参考画像
https://ddjkaamml8q8x.cloudfront.net/questions/2026-06-10/8f139f8e-3608-4831-8ef3-67d209ecf653.png

Yahooはパスワード欄を表示しない妥当な理由が存在するが、Appleは妥当ではない気がしてきました。

今回の質問である「IDとパスワードを同時に表示しないログインフォームのメリット何ですか？」に対する妥当な回答も「メリットという表現は正しくなく、パスワードが存在しない電話番号ログインが存在するからパスワード欄が表示できない。」が妥当な気がしてきました。

Appleの件は理解できませんが・・・。

Answer 2

ユーザーIDとパスワードをわけることでむしろパスワードマネージャーによる脆弱設定を回避できるのでは？
手段は無数にあるわけでどれを選択するかはサービス提供側の裁量でしょう

Comments

[minato2000]

理解できず申し訳有りません。
パスワードマネージャーによる脆弱設定とは具体的にどのようなものでしょうか？

[yambejp]

パスワードマネージャーがユーザーIDとパスワードを保管するから便利ということは、すなわちセキュリティが低下しているということです。IDとパスワードが別画面なら、IDの保管が防げたりIDとパスワードの紐づけが防げる＝セキュリティは相対的に高くなりますね。
もちろんそれを目的にするなら別に効率が高い方法もありますが、それをもってこの方法にメリットがないというのは早計だという指摘です

[minato2000]

手元にあるGoogle Chrome標準のパスワードマネージャで確認してみましたが、別画面かどうかは関係なくIDとパスワードがセットで保存できるので、結果的に別画面にしている意味が無いと判断しました。
私が個人的な感想として挙げているデメリットが上回ると考えています。

しかし、おっしゃるとおりサービス提供者側が無意味なことに意味を感じているのであればサービス提供側の裁量なので個人が考えること自体が無意味ですね。
複数社での採用事例があるのが気になる所ではありますが、過去にもメールにおいてPPAPがなぜか複数企業で採用されていましたね。
現代ではPPAPが非推奨な事は当たり前になっています。
私は同様の現象が起きているのではないかと感じています。

[yambejp]

>別画面かどうかは関係なくIDとパスワードがセットで保存できるので、結果的に別画面にしている意味が無い

IDとパスワードが別画面であれば「セットにしない」ことができますよね？クロムのように端末をまたいでIDとパスワードの組み合わせが共有されてしまうような環境はセットにしないメリットは大きくないですか？

[minato2000]

私の質問の仕方がどのようなメリットがあるかという聞き方だったので、単純にメリットがあるかないかや、「ユーザーにIDとパスワードをセットで保存しない選択肢を与える」というメリット、「IDパスワードをセットで保存していないので、端末侵害によるリスクを低下できる」というメリット、などの話しになると「おっしゃるとおりのメリットがある」が答えになります。

しかし、サービス提供者側がパスワード欄を非表示にする理由としては妥当ではない気がしています。
私たちは今、かなり特殊なケースについて議論している気がします。

Answer 3

完全に妄想ですが、先に登録画面を作ってその時に「そのアカウントは既に存在します」のバリデーションを作ったんで、逆にログインの時に「そのアカウントは既に存在しません」を流用したかったんでしょう。

まあほとんどの場合、そのシステム自体は流用しているでしょうがユーザー数の多いシステムでは、ユーザーの存在を確認するアルゴリズムをそれなりに作りこんでいる可能性があります。

Comments

[minato2000]

申し訳有りません、
あなたが何について回答を書いていただけたかさっぱり理解できませんでした。
私の質問内容は「IDとパスワードを同時に表示しないログインフォームのメリット何ですか？」です。

[u2025]

私の回答内容は「IDとパスワードを同時に表示しないログインフォームのメリット何ですか？」に対するものです。