「ログインのときに、特定の条件の利用者にだけ追加の本人確認を挟みたい」。この一文から始まる要望が、3 か月かかることがあります。
iOS のアプリを直し、Android を直し、Web を直す。それぞれテストして、アプリは審査に出す。公開されても、利用者が更新するとは限らないので、古い手順のまま動き続けるアプリを数か月抱えることになります。その間、サーバー側は新旧どちらの手順にも応答できる状態を維持しなければなりません。
Airbnb が 2026年8月に公開した認証基盤の作り直しは、この構造そのものを移した事例です。結果として認証関連のコードは 60% 減り、Web クライアントの配信サイズは 100KB 減りました。ただし読みどころは削減幅ではなく、何をどこに置き直したかのほうにあります。
画面の順序を、クライアントから取り上げる
従来の作りでは、「メールアドレスを入れたら次はパスワード」「特定の条件ならワンタイムパスワードを挟む」という手順の組み立てが、アプリと Web のそれぞれに書かれていました。同じ判断が 3 か所に複製されている状態です。
作り直した後は、次に何の画面を出すかをサーバーが決めます。クライアントは「サーバーから渡された画面を描く」役に徹し、条件分岐を持ちません。どの本人確認方法を要求するかは、利用者とセッションの状況をもとにサーバー側のポリシーエンジンが選びます。
この移動によって、何が変わったのかを整理するとこうなります。
| 変更したいこと | 従来 | サーバー主導にした後 |
|---|---|---|
| 本人確認の手順を足す | 3 つのクライアントを改修し、審査を待つ | サーバー側の設定変更で完結する |
| 条件によって手順を変える | 各クライアントに条件分岐を実装する | ポリシー側に条件を足す |
| 古いバージョンの利用者 | 旧手順を維持し続ける | 同じサーバー応答を受け取る |
公表されている効果としては、認証の成功率が 2.6% 改善し、重複したアカウント作成が 27% 減り、ワンタイムパスワードの送信コストが 11% 下がったとされています。成功率と重複アカウントの改善は、コード量の削減ではなく「判断を一箇所に集めた」ことの結果です。3 か所に分かれた実装は、必ずどこかで挙動がずれます。
中小規模のシステムに、そのまま持ち込めるか
Airbnb の規模でしか成立しない部分と、規模に関係なく効く部分があります。
持ち込みにくいのは、ポリシーエンジンそのものです。 利用者の状況に応じて最適な本人確認を動的に選ぶ仕組みは、それ自体が開発対象になります。ログイン頻度が高くない社内システムで、この投資は回収しにくいものです。
規模に関係なく効くのは、画面の順序をサーバーが返す形にすることです。 「次に出す画面の名前」と「そこで必要な入力項目」をサーバーの応答に含めるだけで、手順の変更がクライアントの改修から切り離せます。ポリシーエンジンが無くても、条件分岐をサーバー側の 1 ファイルに集めるだけで、3 か所の複製は消えます。
判断の目安としては、次のように切り分けられます。
- モバイルアプリを配布していて、審査待ちが変更速度の足かせになっている → 効果が出やすい
- Web だけで完結していて、認証の手順が当面変わる予定が無い → 急ぐ理由は薄い
- 認証方式の追加が具体的に見えている（多要素の導入、パスキー対応など） → その作業と同時にやる価値がある
3 番目に該当する会社が多いはずです。パスキーへの移行や乗っ取り対策としての多要素化を検討している段階であれば、方式を足すたびにクライアントを直す構造のまま進めるか、先に手順の置き場所を移すかを決めておくと、後の改修量が変わります。
作り直しの範囲をどこで切るか
認証基盤全体を一度に作り直す判断は、リスクの割に見返りが読みにくくなります。段階を切るなら、次の順序が現実的です。
最初に、いま認証の手順がどこに何通り書かれているかを数えるところから始めます。iOS・Android・Web に加えて、管理画面や外部連携用の入口が別実装になっていることがあります。数えた結果が 2 か所以下なら、作り直しの優先度は下がります。
次に、新規に追加する方式だけをサーバー主導の形で作ります。既存の手順はそのまま残し、新しい方式を通る利用者だけが新しい経路を通る形です。既存経路を壊さずに新旧を並走させられるのが、この設計の利点でもあります。
既存経路の移行は、新方式が安定してから着手すれば足ります。ここを先にやると、ログインできない利用者が出たときの原因切り分けが難しくなります。
次にやること
自社のシステムで、ログインの画面遷移を決めている箇所を書き出してください。ファイル名でも構いません。
その数が 3 つ以上あり、かつ今後 1 年以内に認証方式を追加する予定があるなら、追加作業と同時に順序の判断をサーバー側へ寄せる価値があります。予定が無いなら、今回の事例は「そういう作り方がある」という知識として置いておく形で十分です。
認証まわりの構成の見直し、既存システムを止めずに移行する進め方については、グリームハブの開発・AI・自動化のご相談で承っています。現在の構成と利用者の規模によって適切な範囲が変わるため、お問い合わせからご相談ください。
