Discourseコミュニティでは、マジックリンクの代わりに短いメールコードを使用してログインできるようになりました。これにより、他の多くのSaaSプラットフォームで馴染みのあるパスワードレスログインフローを提供し、既存の2要素認証設定と併せて動作します。
このトピックでは、主な変更点を確認し、今日からこの機能をどのように使い始めることができるかをお伝えします。
この機能が有効になると、メンバーはよりシンプルなフローを確認できます：
メールアドレスを入力し、続行 をクリックします。
6桁のコードが受信トレイに届きます。コードを貼り付け（または入力）ると、最後の桁が入力されるとフォームが自動送信されます。
2要素認証（TOTP、バックアップコード、セキュリティキー）が有効な場合、次に標準的な2FAステップが表示されます。
知っておくべき詳細：コードは10分間有効で、5回の失敗後に期限切れとなり、1回のみ使用できます。
現時点では、これは実験的な変更とされています！ より広く展開する前に、改善に役立つフィードバックを歓迎します。
これを有効にするには、管理画面（/admin/config/upcoming-changes）の**Upcoming changes **ページに移動し、Enable local logins via code 項目を探します。Enabled for …フィールドを更新して、サイトがこの新しいデザインにオプトインします：
enable_local_loginsとenable_local_logins_via_emailの両方がtrueであることを確認してください。これらが設定されていなければ、この機能をオンにできません。DiscourseConnect （enable_discourse_connect）を使用している場合、この機能を有効にすることはできません。
変更が有効になると、コードによるログインパスが自動的に表示されます。
メールアドレスに認識可能なユーザー名が含まれていない新規メンバーには、user1のような一般的なプレースホルダーの代わりに、「QuietFalcon42」のような親しみやすい生成名が割り当てられます。アカウント準備完了ステップでは、提案がプリフィルされ、新しい名前をロールするためのサイコロボタンが含まれます。
提案の背後にある単語リストは、random_username_adjectivesとrandom_username_nounsサイト設定を通じて設定可能であり、コミュニティはそれらをトーンや言語に合わせて調整できます。
サインアップにメールコードを使用したいが、プリフィルされたユーザー名生成は不要な場合は、このアップcoming changeのShow related settings をクリックし、enable_random_usernamesサイト設定を無効にしてください。
ここからは皆さんに：この新機能についてどう思われるか、ぜひお聞かせください。何が気に入っていて、何が気に入らないか；何がうまく機能していて、何が改善できるか？
「いいね！」 13
さっき自分のサイトで試してみました。他の人たちがどう思っているかはわかりませんが、パスワードマネージャーのユーザーとしては、これはかなり大きな後退に感じられます…
この新しいフローは、私がパスワードマネージャーに押し付けられていた「メールを生成、ユーザー名を入力、パスワードを生成、保存」という戦略を取り除き、最初にメールを入力することを強要します。メールコードの件については問題ありません（むしろ、コードがメールの件名に含まれている場合は、ほぼ好みます）が、他のアカウントデータの入力ボックスを削除することに強く反対します。もし私が技術的な背景を持たないユーザーであれば、このような情報が一切ない入力ボックスに自分のメールを渡すことは避けるでしょう。なぜなら、これは一般的なデザインではないからです。これが恒久的なものになる前に、それが元に戻されることを望みます。
「いいね！」 3
dfabulich
2026 年 7 月 13 日午前 2:12
12
メールコード、通称「マジックリンク」は悪くありませんが、ユーザーをパスキーへ誘導すると、体験が格段に良くなります。
Magic links, those emailed one-time login links, are annoying and inconvenient for folks who use a password manager, but they radically accept some fundamental truths about signing in for everyone else. By layering passkeys on top of magic links,...
メールコードの最大の課題の一つは、Gmailのアプリ内ブラウザを含むアプリ内ブラウザで期待通りに動作しないことです。
マジックリンクで人々が遭遇する最も一般的な問題は、通常のブラウザでサイトにログインしたつもりになっているのに、実際にはアプリ内ブラウザ経由でログインしていることです。例えば、誰かがログインリンクをメールで受信したとします。Gmailアプリを開き、「404 Mediaにサインイン」ボタンをクリックすると、スマートフォンでウェブページが読み込まれます。しかし、これはGmailのウェブブラウザでウェブサイトを読み込んでいるだけで、ネイティブのSafariではありません。
パスキーはこの問題を解決します。
まず、マジックリンクを使用しているウェブサイトは、現在のマジックリンクの動作に不満を訴えた顧客に対して、パスキーをオプションのオプトイン機能として提供できます。問題が発生しないように、いわゆるソフトローンチとして、この機能を100%オプトインに設定できます。
少し後になって、ウェブサイト運営者がパスキーがマジックリンクに関連するユーザー体験の問題に本当に役立つと確信したら、サインイン後、90日ごと、またはパスキーのクロスデバイスサインイン機能を使用してサインインするたびに、ユーザーにパスキーの追加を促すことができます。このようなプロンプトの表現は、Appleデバイスを使用するユーザーに対しては次のようになります。次回メールを確認する必要を避けたいですか？Face IDまたはTouch IDを使用して、迅速かつ安全にサインインするためのパスキーを設定しましょう。
ユーザーをパスキーへ誘導することは、ユーザーをパスワードマネージャーの使用へ誘導することと同じです。なぜなら、パスキーは単にパスワードマネージャーを必要とするパスワードだからです 。
「いいね！」 2
Don
2026 年 7 月 13 日午後 1:19
13
こんにちは
このアプローチは本当に気に入っています！ただし、登録が完了するまで表示名を変更できない点が少し気になります。プロセス中に名前を変更できるオプションを追加できたら素晴らしいと思います。
私のコミュニティでは、「UXでユーザー名を優先する」というサイト設定を無効にしているため、UI全体でフルネーム/表示名が優先されます。そのため、ユーザーがすぐにカスタマイズするオプションがない場合、フロントエンドで「user21」のような自動割り当てされた名前がかなり見苦しくなってしまいます。
ありがとうございます！
「いいね！」 6
pmusaraj
2026 年 7 月 13 日午後 2:48
14
この新しいフローではマジックリンクは送信されません。コードのみを送信します。ユーザーは同じページに留まり、メールからコードをコピーしてサインアップフォームに貼り付けます。したがって、この新しいアプローチはアプリ内ブラウザの問題を解決するのに役立ちます（これは変更の主な利点の一つです）。
dfabulich:
パスキーへの誘導
これは確かに、サインアップのパスワードステップで次に実施したいことです。アプリやウェブサイトはパスキーのサポートを強化しており、多くの場面でパスキーへの誘導表示を目にするようになりました。したがって、Discourseでもこれを追加するのは理にかなっています。（パスワードからパスキーへの移行において、サポートの臨界点に達することは非常に役立ちます。）
「いいね！」 3
DomMcD
2026 年 7 月 18 日午後 9:21
16
この機能に関する唯一の懸念点は、サインアップページから名前とユーザー名のフィールドが削除されることです。これは意図的なものですか？「user63」のようなユーザー名を設定するために、サインアップ直後にユーザーに設定画面を掘り下げてほしくないのです。
「いいね！」 3
kddkd
2026 年 7 月 19 日午後 1:24
17
このメール認証コードによる登録方法は、私がずっと望んでいた変更です！
「いいね！」 1
Moin
2026 年 7 月 20 日午前 7:39
18
この変更がないと、「パスワードを忘れた場合」と「メールを送信する」リンクのサイズが同じになっていました。現在、後者の方が大きくなっています。これは意図的なものでしょうか？
「いいね！」 4
フィードバックありがとうございます。はい、これはアカウント作成をより迅速に行うための機能として意図的に実装されています。
承知しました。はい、この次のステップをより簡素化するか、別の方法で初期ユーザー名を設定する方法を検討しています。
「いいね！」 1
Moin
2026 年 7 月 22 日午前 9:32
21
同意します。そのような汎用的なユーザー名は、ユーザーとのやり取りをより混乱させます。デフォルトではユーザーは3日以内で名前を変更する必要があるので、その期限を過ぎた後に気づくことが多くなるでしょう。そのため、スタッフ側で名前の変更を手配する必要があります。Offering blank username suggestions rather than ‘UserN’ at signup で提案された「サインアップ時に『usern』ではなく空の名前を提案する」機能が、例えばこのメタサイトではその問題を防止してくれました。この修正がマージされる前の1月7日に作成されたのが最後の「userXXX」でした。その後、この機能が有効になるまで新しい「userXXX」は作成されておらず、それ以降は12件新たに作成されています。
「いいね！」 4
この機能は非常に有用です。MFA（多要素認証）による安全なログインを、特定のデバイス（適切な認証アプリがインストールされたもの）を準備しなくても提供できるため、「メールによるワンタイムコード」機能を採用するプラットフォームが増えています。
「いいね！」 5
アカウント作成時にこのステップが表示されていないのはなぜですか？
Moin
2026 年 8 月 19 日午前 11:56
24
これは奇妙な引用です。DomMcDが私を引用したように見えますが、実際にはそうではありません。
私はその手順をテストしていません。Meta上の新規ユーザーについて私が気づいたことをコメントしただけです。サインアップ時にフィールドが見えるかどうかは関係ありません。重要なのは、他のユーザーがそのフィールドをどう扱うかということです。
また、名前がどのように処理されるのかも気になります。すべてのユーザーが生成されたユーザー名を使っているわけではなさそうですが、userXXXという名前を使っているユーザーの方がむしろ多いことに気づきます。
ユーザー名を変更した場合でも、その名前が付けられるようです。これにより、ユーザー名が使用可能になるまで同じ数字が繰り返し使用され、使用不可になると次の数字からやり直されることになります。
例えば、0102100988082 、mohamedasarudeen 、user603 はいずれもuser603という名前を持っています。
彼らが名前を変更できることは承知していますが、それでも、彼らとやり取りする際の私の体験を変えることはできません。
「いいね！」 2
皆が報告してくれたので、ありがとうございます。修正はまもなくマージされます：
main ← keegan/username-step-provider-handoff
merged 03:55PM - 24 Aug 26 UTC
**Previously**, a DiscourseConnect provider handoff redirected away as soon as t… he account existed, so email code signups never saw the username step and kept a generated `userNNN` name.
**In this update**, the handoff waits for the account-ready step to finish, and the generated username is no longer copied into the full name.
| Before | After |
| --- | --- |
|  |  |
「いいね！」 2
アップデート
@keegan の最新の作業 のおかげで、このステップでユーザー名の生成機能が追加され、提案が事前入力されるようになりました：
rishabh:
メールアドレスに識別可能なユーザー名が含まれていない新規メンバーには、user1 のような一般的なプレースホルダーの代わりに、「QuietFalcon42」のような親しみやすい生成名が割り当てられるようになりました。アカウント準備完了ステップでは提案が事前入力され、新しい名前を生成するためのダイスボタンが含まれています。
提案の背後にある単語リストは、random_username_adjectives および random_username_nouns サイト設定で設定可能であり、コミュニティはそれらをトーンや言語に合わせて調整できます。従来の番号付きフォールバックを維持してオプトアウトするには、enable_random_usernames を無効にしてください。
Jagster
2026 年 8 月 28 日午前 10:50
27
もし可能であれば、UXに関する小さな要望があります。これです：
私のデバイスは、ここでパスワードが必要だとかなり確信しているようですが、本来はメールアドレスを尋ねるべきです。そうすれば、私のスマートフォンなどが、他の認証情報ではなくアドレスを提示してくれるようになります。
「いいね！」 2
このサインアップフローは、招待用のランディングページにも実装できますか？このアルファ段階ではスコープ外だと思いますが、機能が安定した後で実装されると非常に役立ちます。私のコミュニティメンバーにとって参入のハードルを大きく下げてくれるので、ありがとうございます！
「いいね！」 4
mcwumbly
2026 年 9 月 5 日午後 9:02
30
「いいね！」 3
ecki
2026 年 9 月 7 日午後 4:49
31
この機能自体は気に入っています（メールとコードだけで完了する最初のサインアップ手順）。ただ、いくつか気になる点があります：
a) ログインとサインアップの設定は別々にすべきです。
「いいね！」 1
変更点
コミュニティでワンタイムログインコードを有効にする
有効化する前に、
新規アカウントへのランダムなユーザー名
皆さんはどう思いますか？
