導入・システム連携ガイド

01 / SYSTEM OVERVIEW

認証の入口を変えて、
会員資産を活かす。

Connect / Guardの連携イメージです。
図は責任分界を整理する参考設計で、実装済みAPIの仕様書ではありません。

登録した携帯から携帯通信網を通じてATIRO CODEへSMSを送り、企業側の会員照合APIと連携する概念図。会員DBは企業側に残す構成。 — Login Connect / Guard の連携イメージ既存会員DBを活用

MembersはATIRO側で会員基盤とマイページを提供する構成です。既存のPOS・予約システム等との連携要否や、保管する会員情報の範囲を別途整理します。

02 / CONNECTION SEQUENCE

誰が、何を確認するか。
データの流れで理解する。

システム間・SMSのやり取り利用者のWeb画面操作

利用者 / ブラウザATIRO CODE企業側サーバー / 会員DB

1ログイン画面を開く・認証用の状態を作成

2登録携帯から「ログイン」とSMSを送信

3送信元番号に対応する会員を照合

4対象会員の照合結果を返す

5登録会員に8桁コードをSMSで返信

6届いたコードをWeb画面に入力

7企業側サーバーから認証結果を検証

8検証結果と対象会員を企業側へ返す

企業側で状態を消費・セッションを発行

9マイページへ遷移（通知SMSは設定に応じて）

参考設計：実際のAPIの呼び出し順、照合のタイミング、非同期通知／状態照会の方式は正式仕様に合わせて確定します。ここで示す番号は手順番号です。

認証の成否を、ブラウザ上の値やURLパラメータだけで判断しないでください。結果の真正性・有効期限・対象会員・セッション／操作との対応を、企業側サーバーで確認する必要があります。

03 / IMPLEMENTATION

導入は、4つのステップで。

期間は既存システムと要件によって変わります。
まずは範囲を絞ったPoCで、利用体験と運用の成立を確認します。

要件を整理し、会員データの照合を準備し、Web画面とSMSをつなぎ、検証して公開する4段階の導入イメージ — **01　要件整理**対象・リスク・利用者
**02　照合設計**会員DB・番号・責任分界
**03　画面・認証連携**SMS導線・サーバー検証
**04　検証・段階公開**PoC・監視・復旧

STEP 01 / PLAN

対象業務とリスクを定義

ログインだけか、重要操作も対象か。端末、利用回線、代替手段、対象会員、サービスの選択と検証指標を決めます。

STEP 02 / DATA

照合と責任分界を設計

登録番号の正規化・重複・変更の扱いを整理。会員IDとの対応、照合API、照合用データの生成方法、保管範囲を確認します。

STEP 03 / BUILD

導線と検証処理を実装

SMSの宛先・本文を用意する導線とコード入力画面を設置。認証結果のサーバー検証、セッション発行、通知を連携します。

STEP 04 / LAUNCH

PoCから段階的に公開

成功だけでなく、期限切れ・誤入力・再利用・通信遅延をテスト。運用監視、紛失や番号変更の復旧、切り戻し手順を確認します。

04 / RESPONSIBILITY

どこまでを、
誰が担当するか。

項目	ATIRO側と確認する範囲	企業側で設計・対応する範囲
SMSの入口	利用番号、受信・返信、対象回線、送受信条件	画面の案内、サービス名・操作内容、PC利用者の導線
会員照合	照合仕様、照合キー、テナントの分離、未登録時の応答	既存会員ID・登録番号の品質、照合API、重複と変更ルール
認証・承認	コード／承認の状態、有効期限、検証インターフェース	セッション／操作との紐付け、サーバー側検証、権限判断
運用・監視	送受信の障害・遅延、利用量、ログの提供範囲	不正検知、本人への案内、復旧・番号変更、問い合わせ対応
個人情報	処理・保存対象、保存期間、委託範囲、データ出力・削除	利用目的の通知、権限管理、運用担当者の管理、必要な同意

本表は責任分界の協議項目です。サービスの標準機能・SLA・サポート範囲を保証する一覧ではありません。

05 / ENGINEERING NOTES

コードを受け取る、その先の実装。

以下は設計チェック用の擬似コードです。
ATIROの公開API、SDK、URL、署名方式を示すものではありません。

// Reference only. Replace each adapter with the confirmed API contract.
pending = loadPendingAuthentication(serverSession)
result  = verifyWithConfirmedAtiroInterface(submittedCode)

requireVerifiedServerResponse(result)
requireNotExpired(result, pending)
requireExpectedTenantAndPurpose(result, pending)
requireAccountAndSessionBinding(result, pending)

// Reject replay and race conditions on the server.
consumeAuthenticationOnceAtomically(result)
rotateSessionAndSignIn(result.accountId)

// Never trust a browser flag such as "?authenticated=true".

Webhookを採用する場合は、正式仕様に応じた署名検証・時刻検証・重複排除を行います。照会API方式の場合もサーバー間認証と結果の検証が必要です。鍵をブラウザに埋め込まない設計にします。

比較・セキュリティ説明の参考資料

OWASP — Authentication Cheat Sheet ↗OWASP — Transaction Authorization Cheat Sheet ↗

06 / LAUNCH CHECKLIST

公開前の確認を、
抜け漏れなく。

チェックはこの画面内だけの確認用です。
外部への送信や、ブラウザへの永続保存は行いません。

対象会員と携帯番号の対応・重複・番号変更ルールを決めた利用回線・SMS送信料・PCからの利用方法を確認した認証用セッションと対象会員／対象操作をサーバーで紐付けたコードの期限切れ・誤入力・再利用・同時実行を検証した未登録番号・大量送信・返信費用の上限と監視を設計した紛失・番号変更・通信障害時の代替手段と復旧を決めたSMS本文・番号・ログの保存期間とアクセス権を確認した旧ログイン・再設定経路の保護と切り戻し手順を確認した

0 / 8 項目を確認済み

既存の仕組みと、
どうつなぐかが見える。

認証の入口を変えて、
会員資産を活かす。

誰が、何を確認するか。
データの流れで理解する。

導入は、4つのステップで。

対象業務とリスクを定義

照合と責任分界を設計

導線と検証処理を実装

PoCから段階的に公開

どこまでを、
誰が担当するか。

コードを受け取る、その先の実装。

比較・セキュリティ説明の参考資料

公開前の確認を、
抜け漏れなく。

あなたのサービスに、
新しい認証の入口を。

既存の仕組みと、どうつなぐかが見える。

認証の入口を変えて、会員資産を活かす。

誰が、何を確認するか。データの流れで理解する。

導入は、4つのステップで。

対象業務とリスクを定義

照合と責任分界を設計

導線と検証処理を実装

PoCから段階的に公開

どこまでを、誰が担当するか。

コードを受け取る、その先の実装。

比較・セキュリティ説明の参考資料

公開前の確認を、抜け漏れなく。

あなたのサービスに、新しい認証の入口を。

既存の仕組みと、
どうつなぐかが見える。

認証の入口を変えて、
会員資産を活かす。

誰が、何を確認するか。
データの流れで理解する。

どこまでを、
誰が担当するか。

公開前の確認を、
抜け漏れなく。

あなたのサービスに、
新しい認証の入口を。