保存されない情報：UID・メール・トークンをゲームに渡さない理由
遊びを見つける執筆にClaudeを使用しています。
ログインしてゲームを遊ぶと、クラウドセーブやプレイ履歴が残ります。このとき、遊んでいるゲームの側は「誰が遊んでいるのか」をどこまで知っているのでしょうか。メールアドレスや認証の情報までゲームに届いているなら、作者のコードがそれを保存したり、別の場所に書き出したりする余地が生まれます。 アソバースの確認済みの仕様では、ゲームにはFirebaseのUID（利用者を識別する内部ID）、認証トークン（ログイン状態を証明する情報）、メールアドレスを渡さないことになっています。この記事は、その線引きが何を守っているのか、どこまでが仕様として確かめられているのかを整理します。あわせて、作る人が自作ゲームのセーブ内容を棚卸しする手順を示します。 題名の「保存されない」は、ゲームが受け取るデータやセーブの中身にこれらの情報が入らない、という意味で使います。アソバース全体のどこにも保存されない、という意味ではありません。ログインの仕組みそのものはサイト側が持っています。
この記事の目次
ゲームに渡るものと、渡らないもの
まず確認済みの事実を並べます。
- FirebaseのUID、ゲームへの扱い：渡さない
- 認証トークン、ゲームへの扱い：渡さない
- メールアドレス、ゲームへの扱い：渡さない
- 作品専用のプレイヤーID、ゲームへの扱い：使える（SDK経由）
- クラウドセーブ、ゲームへの扱い：使える（作品ごとにJSONで128KiBまで）
ゲームが使えるのは「作品専用のプレイヤーID」です。名前のとおり、作品ごとに用意されるIDです。この名前から読み取れるのは、同じ人が別の作品を遊んでも、作品ごとに別のIDで扱われる設計だということです。実際にどんな値になるかは、現在の案内で確認してください。
もう一つの前提があります。アップロードしたゲームにはSDK（ゲームから使う小さな部品群）が自動で追加されます。URLで投稿したゲームは、作者がSDKを読み込んだときに、作品専用のプレイヤーIDとクラウドセーブが使えます。つまり作者が何もしなければ、これらの機能は有効になりません。
なぜ「渡さない」が設計として意味を持つのか
ここからは、仕様から読み取れることとして考えます。開発の経緯や意図について、公式の発言があるわけではありません。
UID：サービス内部の識別子を外に出さない
UIDは、認証の仕組みの側で利用者を識別するための値です。これをゲームに渡すと、ゲームが別の場所でもその値を使って同じ人を特定できてしまいます。作品専用のプレイヤーIDを別に用意し、ゲームにはそちらだけを見せる設計であれば、ゲームの内側の都合（誰のセーブか）と、サービスの内側の都合（誰のアカウントか）を切り離せます。
認証トークン：持っているだけで本人として振る舞えるもの
認証トークンは、ログイン状態を証明するために使われる情報です。一般に、この種の情報は持っている側が本人として操作できる性質があります。ゲームは作者が書いたコードで動くため、トークンを渡すと、そのコードに本人としての操作を許すことになります。渡さない設計は、ゲームのコードを信頼しきらない前提に立っていると読み取れます。
メールアドレス：公開しない前提と同じ向き
アソバースでは、公開プロフィール（名前・紹介・SNSや問い合わせページのHTTPS URL）は本人が明示的に公開を選んだときだけ表示されます。ログイン用メールは公開しません。ゲームにメールを渡さないことは、この方針と同じ向きです。ログインに使うメールと、人に見せる情報が、別のものとして扱われています。
ゲームの周りを囲む仕組み
情報を渡さないだけでなく、ゲームが動く場所そのものにも仕切りがあります。確認済みの点は次のとおりです。
- ゲームはsandbox付きiframeで実行されます。sandboxは、埋め込んだページに権限の制限をかける仕組みです。
- アップロードしたコードは、メインサイトとは別のオリジンから配信されます。オリジンとは、ブラウザが「同じ場所」かどうかを判断する単位です。
- アップロード作品内のlocalStorage／sessionStorageは、一時メモリーの互換処理です。
この三つが重なることで、ゲームのコードがメインサイト側の画面やデータに直接触れにくくなります。ただし、sandboxの許可項目の細部や、ブラウザごとの挙動までは確認済み事項にありません。そこは現在の案内で確認してください。
ここで注意したいのは、localStorageの扱いです。アップロード作品では一時メモリーの互換処理なので、「ブラウザに残るから進行が消えない」とは考えないほうが安全です。残したい進行は、クラウドセーブ（ログイン中）を使う設計にします。
作る人の側の線引き：セーブJSONに何を入れるか
サイト側が渡さなくても、ゲームの作者が自分でメールや名前を集めて、セーブに入れてしまうことは起こりえます。クラウドセーブは作品ごとにJSONで128KiBまで使えるので、入れられる余地は十分にあります。そこで、作る人が自分で行える棚卸しの手順を示します。
セーブの中身を棚卸しする手順
- セーブに書き込んでいる箇所を、コードの中ですべて探します。
- 書き込む内容を、一つずつ書き出します。たとえば「ステージの到達番号」「最高記録」「設定（音量・言語）」のように分けます。
- 項目ごとに、「ゲームの進行に必要か」を確認します。必要でないものは外します。
- 実際にセーブされたJSONを一度表示し、想定していない文字列が入っていないかを目で見ます。
- 作品の更新のたびに、手順1〜4を繰り返します。
起こりやすい誤りは、デバッグ用に入れた情報がそのまま残ることです。テスト中に自分のメールアドレスや名前を試しに保存し、削除し忘れる場面を考えてみます。公開前に4の確認をしておけば、気づけます。
プレイヤー名を扱いたいとき
ゲーム内で名前を入力させたい場合は、アカウントの情報を使うのではなく、ゲーム内で入力してもらう形になります。このとき、入力欄に本名やメールを書かないよう、画面上で一言添えるのが親切です。ゲーム内ランキングを作る場合も同様です。アソバースには、ゲーム内スコアの共通ランキングはまだ提供されていません。ランキングをどう作るかは作者の設計ですが、他人に見える文字列を集めるときは、何が表示されるかを事前に確認してください。
遊ぶ人・保護者が確かめられること
遊ぶ側にも、確認できる点があります。
- ログインしなくても遊べます。ログインなしで遊ぶと、履歴や進行は端末内に保存されます。
- ゲストの履歴や進行は、ログイン後のアカウントへ自動では混ざりません。端末で遊んだ記録が、あとからアカウントに紐づくわけではない、ということです。
- ログイン中はクラウドセーブ、作品ごとのプレイ履歴、あとで遊ぶ、好きな作品、作者のフォローが使えます。
- 退会すると、アップロードファイル、履歴・セーブを含む個人データ、認証アカウントが削除されます。
お子さんが遊ぶ場面では、「ゲームの画面で自分が打ち込んだ文字」は、サイトの仕組みとは別の話だと整理できます。ゲームがUIDやメールを受け取らない仕様でも、画面に入力した本名や連絡先は、ゲームが受け取れてしまいます。入力欄のあるゲームでは、何を入力してよいかを一度一緒に確認すると安心です。
なお、公式作品13本のうち、保存があるのは「余白の庭」「WAVE / WAVE」「かたちのあいだ」の3作品です。他の10作品の記録や録音は、画面を開いている間だけ残ります。保存される内容の細部は、作品を開いて確かめてください。
未同期のセーブがあるとき
クラウドセーブでは、もう一つ知っておきたい点があります。未同期の端末セーブは、クラウドの古いデータより優先して再送されます。端末でしばらく遊んだあとにログイン状態が戻ると、端末側の新しい進行がクラウドの古い内容を上書きする向きで扱われる、ということです。
ここから読み取れるのは、進行を失わないことを優先した設計だということです。逆に、複数の端末で同じ作品を遊ぶときは、どの端末の進行が最新かを意識しておくと混乱を避けられます。動きの細かい条件（どの時点で再送されるかなど）は、現在の案内で確認してください。
次の行動
作る人は、自作ゲームのセーブ内容を上の手順で書き出し、メールや名前などの個人情報が混ざっていないかを公開前に確認してみてください。遊ぶ人や保護者は、ゲームの入力欄に何を書くかを意識し、ログイン後のアカウントとゲストの記録が別になる点を覚えておくと安心です。
参考資料
- アソバース 現在の案内（投稿・SDK・クラウドセーブ・プライバシーに関する項目）
