業種ごとに分かれたドメインでも、それぞれのパスキーでログイン

この会社は、医院や店舗の予約受付とスタッフのシフト管理を一つにまとめた SaaS を提供しています。利用者は歯科医院、車の整備工場やタイヤ店、クリニックと幅広く、同社は業種ごとにドメインを分けて、それぞれの業種に合わせた画面と言葉でサービスを届けています。

医院や店舗の担当者は、予約の確認やシフトの調整のために、毎日のように管理画面へログインします。患者や来店客の情報を扱う画面であるため、ログインの安全性を高めることは以前から重要な課題でした。同社は、業種ごとに分かれたドメインの構成を保ったまま、パスキーによるログインを導入しました。その検討と導入の過程を順に紹介します。

業種ごとにドメインを分けて提供してきた理由

同社のサービスは、予約の受付、予約の一覧、スタッフのシフトといった基本の仕組みを全業種で共通にしながら、画面に表示する言葉や項目の名前を業種ごとに切り替えています。歯科医院では診療や診察室、整備工場ではピットや作業メニューといったように、利用者が日頃使っている言葉で操作できることを重視してきました。

こうした業種ごとの違いをわかりやすく届けるため、同社は歯科・車と整備・クリニックのそれぞれにドメインを用意しています。利用者は自分の業種のドメインにアクセスし、その業種向けの案内や画面を使います。案内の資料や問い合わせの窓口も業種ごとに整理されており、ドメインはサービスの入り口そのものとして定着していました。

一方で、仕組みの中身は一つです。業種ごとに別のシステムを作るのではなく、違いを業種ごとの設定に集めることで、機能の追加や不具合の修正を全業種に同時に反映できるようにしています。ログインの仕組みについても、業種ごとに別々に作り込むのではなく、共通の方法で扱えることが望ましいと考えていました。

医院や店舗では、受付の端末を複数のスタッフで使うことも多く、パスワードの使い回しや書き留めといった運用上の不安も残っていました。予約や患者の情報を扱う立場として、ログインをより確かなものにすることは、利用者に安心してサービスを使っていただくための前提だと同社は考えていました。

ドメインに結び付くパスキーと、独自開発を避けた判断

パスキーは、パスワードの代わりに端末の生体認証や画面ロックを使ってログインする仕組みです。利用者は文字列を覚える必要がなく、偽のサイトに入力させられる心配も小さくなります。同社にとって、医院や店舗の担当者に負担をかけずにログインを強化できる方法として、パスキーは有力な選択肢でした。

ただし、パスキーは登録したドメインに結び付いて動作します。歯科のドメインで登録したパスキーは、車と整備やクリニックのドメインでは使えません。業種ごとにドメインを分けている同社にとって、この性質はパスキーを導入するうえで最初に整理すべき点でした。

検討の過程では、ログインだけを共通のドメインに集める案も挙がりました。しかし、この方法では、ログインのたびに利用者が業種の入り口から別のドメインへ移ることになり、業種ごとに整えてきた画面の流れが途切れます。案内の資料や問い合わせの窓口を業種ごとに分けてきた考え方とも合いません。

そこで同社は、業種ごとのドメインをそのまま生かし、それぞれのドメインでパスキーを登録・利用する構成を前提に検討を進めました。パスキーの仕組みを社内で独自に開発することも検討しました。しかし、パスキーの登録とログインには、ブラウザと認証器のやりとり、サーバーでの検証、登録済みのパスキーの管理など、正しく実装すべき要素が多くあります。これを業種ごとのドメインに対応させ、継続して保守していくことは、予約とシフトの機能を磨くべき開発の力を大きく割くことになります。

同社が SealGate を評価したのは、アプリごとにドメインを設定でき、同じ組み込み方で複数のアプリにパスキーを追加できる点でした。業種ごとに SealGate のアプリを作成し、それぞれに対応するドメインを設定すれば、パスキーはそのドメインで登録・利用されます。組み込みの手順はどの業種でも共通で、ブラウザ SDK とサーバー側の中継を一度整えれば、同じ方法で三つのドメインに展開できます。

既存のログイン画面を残したままパスキーを追加できる点も判断の材料になりました。全面的に作り替える必要がなく、パスワードとパスキーを併用する期間を設けられるため、利用者に急な切り替えを求めずに済みます。

業種ごとに一つのアプリを置く構成

導入にあたって、同社は業種ごとに SealGate のアプリを一つずつ作成しました。歯科・車と整備・クリニックの三つのアプリに、それぞれの業種のドメインを設定し、パスキーの登録とログインはそのドメインの中で完結する構成です。

組み込みの手順は全業種で共通にしました。管理画面にはブラウザ SDK を組み込み、サーバー側では SealGate との中継を行います。業種ごとに異なるのは、どのアプリにつなぐかという設定だけです。同社が以前から進めてきた、業種の違いを設定に集める考え方を、ログインの仕組みでもそのまま当てはめた形になりました。サーバー側の中継では、SealGate で確かめたログインの結果を受けて、これまでと同じ方法で同サービスのセッションを始めます。ログインした後の画面や権限の扱いは従来の仕組みのままで、変更はログインの入り口に限られました。

開発の段階では、まずテスト環境で登録からログインまでの流れを確かめました。一つの業種のドメインで手順を固めたうえで、残りの業種にも同じ手順を当てはめていきました。業種ごとに作業を繰り返す必要はほとんどなく、設定の違いを確かめるだけで展開を進められました。

業種ごとにアプリが分かれているため、利用者の管理やログインの記録も業種単位でまとまります。どの業種でどれだけパスキーが使われているかを個別に把握できることは、構成を決めるうえで同社が重視した点の一つでした。

スタッフの入れ替わりと端末の共有を見据えた運用

医院や店舗では、スタッフの採用や退職、勤務する拠点の異動が日常的に起こります。新しく加わったスタッフにはすぐに管理画面を使ってもらう必要があり、退職したスタッフのログインは速やかに止めなければなりません。同社は、パスキーの導入にあたって、こうした入れ替わりへの対応を運用の前提として整理しました。

SealGate では、アプリごとに利用者と登録済みのパスキーを管理できます。業種ごとにアプリが分かれているため、どの業種の利用者がどのパスキーを登録しているかを、業種の単位で確認できます。スタッフが退職した場合や端末を紛失した場合には、該当するパスキーを無効にし、ログインできない状態にする運用としました。

受付の端末を複数のスタッフで使う場面についても検討しました。同社は、スタッフ一人ひとりが自分のパスキーを登録し、誰がいつログインしたかを後から確かめられる形を基本としています。ログインの記録が利用者ごとに残ることで、医院や店舗から操作の経緯について問い合わせを受けた場合にも、記録をもとに確認できるようになりました。

既存のログインと併用しながらの切り替え

利用者への切り替えは、既存のパスワードによるログインを残したまま進めました。医院や店舗の担当者は、これまでどおりのログイン画面からサービスを使い続けながら、都合のよい時にパスキーを登録できます。パスキーを登録した担当者は、次回から端末の生体認証や画面ロックでログインします。

医院や店舗の業務は、診療や作業の合間に予約やシフトを確認する場面が中心です。ログインの方法を一斉に切り替えると、受付の現場で戸惑いが生じかねません。同社は、パスワードとパスキーを併用する期間を設けることで、各医院や店舗が自分の都合に合わせて移行できるよう配慮しました。

利用者への周知は、業種ごとの案内に合わせて行いました。パスキーの登録の方法と、登録後のログインの流れを業種ごとの言葉で説明し、問い合わせの窓口もこれまでどおり業種ごとに対応しています。複数のスタッフで端末を共有する医院や店舗に向けては、スタッフそれぞれがパスキーを登録する運用もあわせて案内しました。

業種ごとに把握できるようになったログインの状況

導入後、医院や店舗の担当者は、自分が利用している業種のドメインで、パスキーを使ってログインできるようになりました。パスワードを入力する手間がなくなり、端末の生体認証や画面ロックで速やかに管理画面を開けます。業種の入り口から離れることなくログインが完結するため、これまでの画面の流れも保たれています。

業種ごとに SealGate のアプリが分かれていることで、利用状況やログインの記録も業種単位で確認できます。パスキーの登録が進んでいる業種と、これから案内を強めるべき業種を見分けやすくなり、周知の進め方を業種ごとに考えられるようになりました。

開発の面では、パスキーの仕組みを社内で保守する必要がなくなり、組み込みの手順も全業種で共通になりました。ログインに関わる変更を加える場合も、一つの手順を見直せば三つのドメインに反映できます。同社は、こうした構成によって、予約とシフトの機能の開発に力を集中できるようになったと捉えています。

利用者からの問い合わせへの対応も変わりました。ログインできないという相談を受けた場合も、業種ごとのログインの記録をもとに、パスキーの登録の有無やログインの状況を確かめたうえで案内できます。パスワードの再設定の依頼に頼っていた対応が減り、窓口の担当者が状況を把握しやすくなりました。

新しい業種を迎える際も同じ構成で

同社は今後、対応する業種を増やしていくことも視野に入れています。新しい業種のドメインを用意する場合も、SealGate のアプリを一つ追加してドメインを設定すれば、既存の業種と同じ組み込み方でパスキーを提供できます。業種が増えてもログインの仕組みを作り直す必要はありません。

当面は、パスワードとパスキーを併用しながら、各業種でパスキーの登録を広げていく方針です。業種ごとのログインの記録を見ながら、案内の内容や時期を調整し、医院や店舗の担当者が無理なく移行できるよう支えていきます。また、パスキーの登録が十分に広がった段階で、パスワードによるログインの扱いをどうするかも、業種ごとの状況を見ながら判断していく予定です。業種ごとにアプリが分かれているため、移行の進み具合に応じて業種単位で方針を決められることも、この構成の利点だと同社は考えています。業種ごとの使いやすさとログインの安全性を両立させながら、サービスの基盤を整えていく考えです。