ゲストモード（匿名ユーザー）の実装方法と Logto ユーザーへの変換方法

Posted at 2026-01-21

本記事は元々 blog.logto.io に掲載されたものです。

多くのアプリは、ユーザーがサインアップする前に機能を試せるようになっています。ショッピングカート、ドキュメントの下書き、保存済みの設定などがその例です。ユーザーは、この「ゲストモード」が当然のように使えることを期待しています。

しかし Logto（または他の OIDC プロバイダー）で認証している場合、こうした匿名ユーザーをどう扱えばよいのでしょうか？

簡単に言えば：Logto は認証を担当し、あなたのアプリはゲストセッションを管理します。この2つは別々の役割です。

この記事では、Logto でゲストモードを実装するシンプルな3段階パターンを紹介します。以下を学べます：

Logto に「匿名ログイン」機能がない理由

Logto に「匿名ログイン」機能があることを期待しているかもしれません。たとえば API を呼び出してトークンを取得し、ユーザーの操作を必要としないようなものです。

しかし、OIDC はそういう仕組みではありません。その理由は：

OIDC はユーザーの同意を前提としています。 仕組みの本質は、「この人が誰か？」を明確に認証することです。匿名トークンは「誰かは来たけど、その人が誰か分からない」という意味になり、本来の目的を果たせません。

こう考えてみてください：

ゲストモードはセッション管理の話であり、認証とは異なります。だから認証システムには含めません。

これは実は良いことです。 明確な分担ができるからです：

それぞれの仕組みに専念させましょう。

基本パターン：Guest → Auth → Merge（ゲスト → 認証 → マージ）

バックエンドがゲストセッションを生成・管理します。この段階では Logto は関与しません。

ユーザーが意味のある操作をしたとき（例：カートに追加）、バックエンドは：

シンプルで構いません。guest_sessionsテーブルにguest_id、data、created_at カラムがあれば十分です。

ユーザーが「サインアップ」や「サインイン」をクリックしたら、通常の Logto OIDC フローを開始します。

ゲスト ID はクッキーやストレージに残したままです。認証が完了すると、フロントエンドが持つのは：

ここで両者をつなぎます。API で両方を送信します：

POST /api/merge-guest
Authorization: Bearer <access_token>
Body: { "guestId": "guest_abc123" }

バックエンド側では、両方のトークンを検証してください：

アクセストークンを検証 → ユーザー ID を抽出。アクセストークンの検証方法はこちら。
ゲスト ID を検証 → 本当にあなたのバックエンドが発行したゲストセッションか確認します。これが肝心で、クライアントの guestId を信用しすぎないように。

2つとも有効であれば：

統合の具体的なロジックはビジネス用途により異なります。ショッピングカートなら商品の合体、ドキュメント下書きなら所有権の移管、などです。

マージ関連のエンドポイントは特に慎重に設計しましょう：

必ずアクセストークンを検証する。リクエストボディの userId を使うだけでなく、JWT を必ずデコード・検証しましょう。Logto の方法はこちら。
必ずゲスト ID を検証する。DB に存在し有効期限が切れていないか確認。JWT 方式なら署名検証も。
認証必須にする。アクセストークンのないリクエストは拒否します。
ゲストセッションの TTL（有効期限）を設定する。未使用セッションは30日などで自動削除しましょう。

Logto のゲストモード運用はシンプルな方式です：

このパターンは Logto 以外の OIDC プロバイダーでも活用できます。ポイントは「認証」と「セッション管理」は別物、両者それぞれ専念させることです。