LINE セルフ登録フロー設計

背景・課題

現状 (Plan 1.5 で確立した claim 動線)

受付スタッフが事前に紙カルテからシステムへ User を登録 (provider: manual)
患者が LINE/Google でログイン → PendingClaimToken 発行
/onboarding/claim で 3 要素 (電話・フリガナ・生年月日) を入力
一致したカルテに OAuth 紐付け、不一致なら 401

取りこぼし問題

アナログ管理から移行する際に受付負荷が極めて高い

既存予約者情報は「フリガナ + 電話番号」しか持たないケースが多い
電話予約で取ったフリガナは聞き間違いが起きうる
生年月日まで聞いていないことが多い

来院前にシステムに無い患者は予約できない (新規取りこぼし)
既存患者でも受付登録の精度次第で紐付け失敗、来院時にスタッフが手作業で修正する運用負荷

運用上の前提

アナログカルテはそもそも電子カルテと紐付いていない (独立した紙運用)。
新システム導入の際、患者に「導入後から予約履歴を蓄積する」と周知すれば、過去予約の移行は不要。
LINE 公式アカウントから予約導線を流すケースが大半 → LINE 一本化が業務に適合。

設計方針

振る舞い (大幅シンプル化)

LINE ログイン → /onboarding でプロフィール入力 → 常に新規 User 作成 → Home

突合ロジック完全撤廃。受付運用とシステムを独立させる。

項目	現状	新仕様
ログイン手段	LINE / Google	LINE のみ
既存カルテとの突合	3 要素一致 (phone / kana / dob)	しない (常に新規 User 作成)
`claim_failed` 401	あり	廃止
`possibly_existing_user` 等の親切エラー	(検討対象)	不要
受付の事前登録要件	必須	不要 (任意・staff-web で続行可)

割り切り事項

項目	影響
既存 `provider: manual` User	データ残置。誰とも紐付かない「孤立カルテ」扱い。staff-web からは見える
「前回施術」カード	LINE 連携後の初回予約後から表示 (2 回目以降)
患者から見える予約履歴	LINE 連携後のみ
アナログ時代の予約参照	紙カルテで対応、staff-web 上は別 User として表示

将来必要になれば 「LINE 連携 User と旧 manual User をマージする管理画面」 を Plan 4-D-2 として別途実装する。本仕様の MVP には含めない。

API 仕様

新規エンドポイント: `POST /api/v1/auth/oauth/register`

現 oauth/claim を リネーム + 動作変更。Controller も OauthRegistrationController へ。

Request

POST /api/v1/auth/oauth/register
Content-Type: application/json

{
  "pending_claim_token": "<10分有効、LINE callback で発行>",
  "full_name": "山田太郎",
  "kana": "ヤマダタロウ",
  "phone": "09011112222",
  "date_of_birth": "1990-01-01"
}

Response

Status	body	説明
200	`{ user: { id, full_name, role: "user" } }`	新規 User 作成成功 + JWT cookie 発行
401	`{ error: "claim_token_expired", message: "LINE ログインからやり直してください" }`	トークン期限切れ
422	`{ error: "validation_failed", details: { phone: ["..."], kana: ["..."] } }`	入力 validation 失敗
429	`{ error: "rate_limited", message: "しばらく待ってから..." }`	レート制限

廃止される評価分岐

:phone_not_found
:kana_mismatch
:dob_required
:dob_mismatch
:already_linked
:locked (oauth_link_locked? は廃止)

評価ロジック (擬似コード)

def create
  # Step 1: レート制限 (phone × ip_address)
  return rate_limited if OauthClaimRateLimiter.over_limit?(...)

  # Step 2: token decode
  payload = decode_claim_token  # → expired / invalid → 401

  # Step 3: validation (Zod / strong params で必須項目検証)
  attrs = registration_params  # → 不足/不正 → 422

  # Step 4: 新規 User 作成 + 紐付け
  user = User.create!(
    full_name: attrs[:full_name],
    full_name_kana: attrs[:kana],
    phone: attrs[:phone],
    date_of_birth: Date.parse(attrs[:date_of_birth]),
    provider: payload[:provider],  # "line"
    uid: payload[:uid],
    role: :user,
    onboarded: true
  )

  # Step 5: ログ + JWT 発行
  OauthLinkAttemptLogger.log!(result: "success_new", ...)
  set_jwt_cookie(encode_jwt(user))
  render json: { user: user_payload(user) }, status: :ok
end

データモデル

新規 User の固定値

カラム	値
`role`	`:user`
`onboarded`	`true`
`provider`	`:line`
`uid`	LINE userId
`email`	`nil` (LINE は email 取得しない)
`patient_number`	`nil` (来院時に受付が付与)
`full_name` / `full_name_kana` / `phone` / `date_of_birth`	患者入力

enum 変更

enum :provider, { line: 0, google: 1, email: 2, manual: 3 }

残置 google: 1 は将来再導入余地、migration 不要

UI フロー

Before / After

Before: 本人確認 (claim)

← クリニック予約👤

本人確認

受付で登録された情報と一致するか確認します。

電話番号

09012345678

フリガナ (姓名)

ヤマダタロウ

生年月日

1990 / 01 / 01

既存患者前提・氏名なし・
不一致なら 401

After: ご利用登録

← クリニック予約👤

ご利用登録

ご予約のためにお名前と連絡先をご登録ください。

お名前

山田太郎

フリガナ (姓名)

ヤマダタロウ

電話番号

09012345678

生年月日

1990 / 01 / 01

セルフ登録・氏名追加・
常に新規作成成功

エラーバナー

ケース	メッセージ
validation_failed	「入力内容に誤りがあります。ご確認ください」+ フィールド単位エラー
claim_token_expired	「セッションが切れました [ログインへ]」
rate_limited	「しばらく待ってから再度お試しください」
unknown	「通信エラーが発生しました。再度お試しください」

ログイン画面 (`/login`) の文言変更

- 受付の方が登録した後、ご自身の LINE / Google で
-   ログインしてください。
+ LINE アカウントでログインしてください。
+   初めての方はそのままご登録いただけます。

LINE 一本化 (Google 動線撤去)

削除対象

ファイル	内容
`apps/user-web/src/components/auth/OAuthButtons.tsx`	Google ボタン
`apps/api/config/routes.rb`	`google/callback` ルート
`apps/api/app/controllers/api/v1/auth/omniauth_callbacks_controller.rb`	`def google_oauth2` メソッド
`apps/api/config/initializers/omniauth.rb`	`provider :google_oauth2, ...`

残置

User model の enum :provider の google: 1 (DB 値、将来再導入用)
omniauth-google-oauth2 gem (Gemfile から削除するかは別判断、本仕様では削除しない)

セキュリティ・運用

レート制限

既存 OauthClaimRateLimiter を 再利用: phone × ip_address ベース、24h で 5 回。新規登録もブルートフォース対象になり得るので維持。

監査ログ

既存 OauthLinkAttemptLogger を 再利用。新 result 種別 success_new を追加。受付スタッフが「LINE セルフ登録された患者」を staff-web 上でフィルタできる (Plan 4-D-2 で UI 化)。

なりすまし耐性

突合ロジック撤廃により 「他人の情報で誰かのカルテを覗く」経路は存在しない。LINE 連携 = 個人 1 アカウント、phone は自己申告。

テスト方針

API

既存 spec/requests/api/v1/auth/oauth_claim_spec.rb を 書き換え
突合系テスト (kana_mismatch / dob_mismatch / phone_not_found / already_linked) を削除
新規ケース: 正常登録、token expired、validation error、rate limit

Web

apps/user-web/src/routes/onboarding-claim.test.tsx を register 対応に 書き換え
新規ケース: 正常登録、validation error 表示、token expired 遷移

E2E

「LINE 連携 → 登録 → 初回予約 → 確定」のフルパス (mock または dev seed)

スコープ外 (別 plan)

staff-web の 「LINE 連携 User と旧 manual User をマージ」管理画面 (Plan 4-D-2)
既存 provider: :manual User の cleanup / アーカイブ
アナログ予約データの一括インポート
Google ログインの完全撤廃 (enum 削除 + omniauth-google-oauth2 gem 削除)

背景・課題

現状 (Plan 1.5 で確立した claim 動線)

取りこぼし問題

運用上の前提

設計方針

振る舞い (大幅シンプル化)

割り切り事項

API 仕様

新規エンドポイント: POST /api/v1/auth/oauth/register

Request

Response

廃止される評価分岐

評価ロジック (擬似コード)

データモデル

新規 User の固定値

enum 変更

UI フロー

Before / After

Before: 本人確認 (claim)

本人確認

After: ご利用登録

ご利用登録

エラーバナー

ログイン画面 (/login) の文言変更

LINE 一本化 (Google 動線撤去)

削除対象

残置

セキュリティ・運用

レート制限

監査ログ

なりすまし耐性

テスト方針

API

Web

E2E

スコープ外 (別 plan)

関連参照

新規エンドポイント: `POST /api/v1/auth/oauth/register`

ログイン画面 (`/login`) の文言変更