ログインの裏で何が起きているか：トークンがゲームに渡らない理由
遊びを見つける執筆にClaudeを使用しています。
アソバースにログインした状態でブラウザゲームを開く場面を考えてみます。ゲームの中でハイスコア相当の記録が残り、別の端末で開いても続きから遊べたとします。このとき、ゲームは「あなたが誰か」をどこまで知っているのでしょうか。メールアドレスや本名まで届いているのでしょうか。 結論から言うと、確認済みの仕様では、ゲームにFirebaseのUID、認証トークン、メールアドレスは渡されません。ゲームが受け取れるのは「作品専用のプレイヤーID」と、作品ごとに最大128KiBのクラウドセーブです。この記事では、ログインの仕組みの中で何がサイト側に残り、何がゲーム側に届くのかを、公開されている範囲の仕様から整理します。 「トークン」は、一般にログイン済みであることを示す通行証のようなものです。これを持っている相手は、持ち主として扱われる可能性があります。そのため、通行証を誰の手元に置くかは、ログインを伴うサービスの設計で重要な論点になります。以下では、この分け方から読み取れることを説明します。
登場するのは三者です：ログイン、サイト本体、ゲーム
仕組みを考えるために、登場するものを三つに分けます。
- ログイン（アカウント）：GoogleまたはメールアドレスでのアカウントでメールはGoogleアカウントの場合も確認が必要な操作があります。メールアドレスで作る場合は確認メールが届きます。ログインは必須ではなく、ログインなしでも遊べます。
- サイト本体：ログイン状態を扱い、クラウドセーブ、プレイ履歴、あとで遊ぶ、好きな作品、作者のフォロー、レビュー、いいねなどを管理します。
- ゲーム：作者が作ったHTMLなどのコードです。sandbox付きのiframeの中で実行されます。アップロードされたコードは、メインサイトとは別のオリジンから配信されます。
「オリジン」は、ブラウザが「同じサイトかどうか」を判断する単位で、おおまかにはアドレスのドメインなどの組み合わせです。別オリジンのコードは、ブラウザの標準的な仕組みにより、サイト本体のデータや画面に自由には触れません。iframeは、ページの中に別のページを埋め込む仕組みです。sandboxは、そのiframeの中のコードにできることを制限する指定です。
この三者のうち、ログインに関わる情報を直接持つのはサイト本体側で、ゲームは壁の向こう側にいます。ゲームが何を受け取れるかは、この壁の間を何が通るかで決まります。
ゲームに渡るもの、渡らないもの
確認済みの事項を表にします。
- FirebaseのUID、ゲームに渡るか：渡さない
- 認証トークン、ゲームに渡るか：渡さない
- メールアドレス、ゲームに渡るか：渡さない
- 作品専用のプレイヤーID、ゲームに渡るか：使える（SDK経由）
- クラウドセーブ（作品ごとにJSONで128KiBまで）、ゲームに渡るか：使える（SDK経由）
SDKは、ゲーム側からサイトの機能を呼び出すための部品です。アップロードしたゲームにはSDKが自動で追加されます。URLで投稿したゲームでは、作者がSDKを読み込むと同じ機能が使えます。
ここから読み取れるのは、ゲームに必要なのは「この作品の中で、同じプレイヤーを区別できること」と「その人の続きを保存すること」の二つだけだ、という切り分けです。「作品専用」のIDなので、作品をまたいで同じ人を名指しする用途は想定されていないと読み取れます。メールアドレスやアカウント本体の識別子が要らない理由は、ここにあります。
なぜトークンを渡さない設計になるのか
トークンがゲームに渡らない理由を、仕様の記述から読み取れる範囲で整理します。公式の説明文ではなく、設計から読み取れることとして読んでください。
ゲームのコードは誰でも書けるものです
アソバースには、誰でも作品を投稿できます。ゲームはあくまで作者のコードです。そのコードが、プレイしている人の通行証を手にできる設計だと、悪意のある作品が通行証を外へ送ってしまう可能性が考えられます。通行証を渡さなければ、その経路は最初からなくなります。
sandboxと別オリジンは、同じ方向の対策です
sandbox付きiframe、別オリジン配信、トークン非公開は、いずれも「ゲームのコードを信用しすぎない」という方向でそろっています。壁を一つ作るだけでなく、壁を越えて渡す情報そのものを絞っています。サーバー用コードやサービスワーカー、SharedArrayBufferを使うマルチスレッドが投稿の対象外とされているのも、ゲームの実行環境をできるだけ単純に保つ方向の制限と読めます。
ゲームに必要な情報は、SDKの二つで足ります
プレイヤーIDとクラウドセーブがあれば、続きから遊ぶ機能は作れます。ログインの本人確認はサイト本体が担い、ゲームは「保存と読み込み」だけを頼む形です。ゲームの側が本人確認の責任を負わなくてよいことは、作る人にとっても利点です。
クラウドセーブとゲストの境目
次に、ゲームに届く「保存」の範囲を整理します。
- クラウドセーブは作品ごとにJSONで128KiBまでです。写真や長い録音のような大きなデータを入れる前提ではなく、進行状況、設定、記録の数値などを入れる大きさです。
- 未同期の端末セーブは、クラウドの古いデータより優先して再送されます。オフラインや通信の不調で同期できなかった進行が、古いクラウドの内容で上書きされないための扱いです。
- ゲストの履歴と進行は端末内に保存され、ログイン後のアカウントへ自動では混ざりません。ログインなしで遊んだ分と、アカウントの分は、別のものとして扱われます。
- 退会すると、アップロードファイル、履歴・セーブを含む個人データ、認証アカウントが削除されます。
アップロード作品の中では、localStorageやsessionStorageは「一時メモリーの互換処理」とされています。つまり、ブラウザ標準の保存の仕組みを使うコードでも動きますが、それは永続的な保存を約束するものではありません。続きから遊べる保存をしたいときは、SDKのクラウドセーブを使うのが前提になります。
公式作品13本のうち、保存があるのは余白の庭、WAVE / WAVE、かたちのあいだの3作品で、他の10作品の記録や録音は画面を開いている間だけです。保存の仕組みの細部は確認済み事項にないので、各作品を開いて確かめてください。
自分で確かめる手順
ここまでの内容は、読者が自分で確認できます。結果は環境や状態によって変わるため、ここでは確かめ方だけを示します。
遊ぶ人・保護者向け：ゲストとアカウントの境目
- ログアウトした状態で、保存のある作品（たとえば余白の庭）を開き、少し進めます。
- ログインして、同じ作品を開きます。
- ゲストのときの進行が見えるか、見えないかをメモします。
- 「あとで遊ぶ」や「好きな作品」、プレイ履歴の画面が、ログイン前後でどう違うかも見比べます。
仕様では、ゲストの履歴・進行はログイン後に自動では混ざらないとされています。手順1〜3の見え方が仕様と合っているかを、自分の画面で確認する形です。
学習者向け：画面を開いている間だけの記録
- 記録が画面を開いている間だけ残る作品（たとえば潮目のオセロの対局や、雨音のピアノの録音）を使います。
- 記録を作った状態でページを再読み込みし、残るかどうかを確かめます。
- 保存のある作品でも同じ操作をして、違いを比べます。
「保存の有無」と「ログインの有無」は別の話だと体感できます。
作る人向け：渡されない前提で作れているか
- 作品のコードの中で、ユーザーのメールアドレスやアカウント識別子を使う処理がないかを探します。ゲームに渡らない情報なので、使う設計にしないほうが安全です。
- 進行の保存を、localStorageだけに頼っていないか確認します。アップロード作品では一時メモリーの互換処理なので、続きから遊ばせたいデータはSDKのクラウドセーブに入れます。
- クラウドセーブに入れるJSONが128KiBに収まるかを、書き出した文字列の長さで見積もります。上限を超えそうなデータは、記録する項目を絞ります。
- ログインなしの状態でも、ゲームが遊べるかを確認します。サイトはログインなしでも遊べる前提です。
プレイヤー名や紹介文のような情報を、ゲームの画面でプレイヤーに入力させる場合は、それが公開される可能性があるかどうかを作者の側で判断してください。個人情報の扱いや規約の細部は、公式の案内で確認してください。
次の行動
ログイン前後で、同じ作品の進行の見え方がどう変わるかを、自分の端末で一度確かめてみてください。作る人は、作品のコードから「ゲームに渡らない情報」を使う処理を洗い出し、保存はSDKのクラウドセーブに寄せられるかを点検してみてください。SDKの最新の呼び出し方や上限は、現在の案内で確認してください。
