作品ごとのプレイヤーID：同じ人が作品ごとに違うIDを持つ理由
遊びを見つける執筆にClaudeを使用しています。
同じ人が、ふたりの作者の別々のゲームを遊ぶ場面を考えてみます。それぞれのゲームには、遊んだ人を区別する印としてプレイヤーIDがあります。このとき二つのゲームのIDが同じ文字列なら、作者同士が見比べるだけで「あの作品を遊んだ人は、こちらの作品も遊んでいる」と分かってしまいます。別のIDなら、その結びつけは手元のデータだけではできません。 アソバースのプレイヤーIDは、この二つ目の形を取っています。確認済みの案内では「作品専用のプレイヤーID」と呼ばれています。この記事では、作品ごとにIDを分ける設計が何を守り、何を手放しているのかを、確認済みの事実だけを根拠に整理します。IDの具体的な作り方や内部の経緯は確認済み事項にないため、そこは推測で埋めません。最後に、自分で作った二つの作品でIDが本当に別になっているかを確かめる手順も示します。
確認できていることと、まだ分からないこと
まず、根拠にできる事実を分けて並べます。
- アップロードしたゲームにはSDKが自動で追加される、状況：確認済み
- URL投稿のゲームは、作者がSDKを読み込むと作品専用のプレイヤーIDとクラウドセーブが使える、状況：確認済み
- クラウドセーブは作品ごとにJSONで128KiBまで、状況：確認済み
- ゲームにはFirebaseのUID・認証トークン・メールアドレスを渡さない、状況：確認済み
- ゲームはsandbox付きiframeで実行され、アップロードしたコードはメインサイトと別のオリジンから配信される、状況：確認済み
- IDの文字列の長さや形式、生成方法、状況：確認済み事項にはない
- ログインしていないゲストにIDが付くかどうか、その扱い、状況：確認済み事項にはない
分かっているのは「IDは作品専用で、ログイン用の識別情報はゲームに渡さない」という骨格です。IDの形式やゲスト時の扱いは、現在の案内とSDKの説明で確認する必要があります。
設計から読み取れること：三つの境界
確認済みの事実を並べると、アカウントとゲームのあいだに三つの境界が引かれているように読めます。ここからは設計から読み取れる範囲の話です。
一つ目：アカウントの識別情報を渡さない境界
ログインの仕組みが持つユーザー識別子（FirebaseのUID）、認証トークン、メールアドレスは、ゲームに渡さない対象として挙げられています。これらをゲームに渡してしまうと、ゲームの作者は「この人のアカウントそのもの」を握ることになります。
そこでゲームには、アカウントの識別情報とは別の、作品専用の印だけを渡す形になっています。ゲームが必要とするのは「この作品を前回遊んだ人と同じか」という情報であり、「その人が誰か」ではないからです。
二つ目：作品どうしを隔てる境界
IDが作品専用であるため、ある作品が持つIDは、別の作品が持つIDと値の上で結びつきません。すると作者Aが保存しているIDの一覧と作者Bが保存しているIDの一覧を持ち寄っても、IDの一致から同一人物を見つけることはできない設計だと読めます。
ここで「できない」と言い切らないのは、遊んだ時間帯やセーブの内容、作者が別に集めた情報など、IDの外にある手がかりまでは、IDの設計で防げないからです。IDを分けることは、結びつきの手がかりを一つ減らす設計であり、あらゆる名寄せを不可能にするものではありません。
三つ目：コードの実行環境の境界
ゲームはsandbox付きのiframeで動き、アップロードされたコードはメインサイトとは別のオリジンから配信されます。オリジンとは、ブラウザが「ここまでが同じ出どころ」と見なす範囲のことです。別のオリジンにあることで、ゲームのコードはアソバース本体のページの内容や保存領域に直接触れにくくなります。
IDを分ける設計は、この実行環境の隔離と同じ向きの考え方です。データの面でも実行の面でも、ゲームから見える範囲を作品の内側にとどめています。
保護者の立場で言えば、子どもがゲームを遊んでも、ゲームの作者側にメールアドレスが渡るわけではない、という点が要点です。公開プロフィール（名前・紹介・SNSや問い合わせページのHTTPS URL）も、本人が明示的に公開を選んだときだけ表示されます。
分けることで手放しているもの
境界を引けば、何かを手放すことにもなります。作品ごとにIDを分けた場合、次のような機能は構造的に作りにくくなります。
- 作品をまたいだ実績や称号：IDが結びつかないので、ある作品の達成を別の作品が参照する仕組みは、ゲーム側だけでは作れません。
- 作品を超えた共通ランキング：ゲーム内スコアの共通ランキングは、現在アソバースでは未提供です。これがIDの設計と直接つながっているかどうかは、確認済み事項からは言えません。ただ、設計の方向としては整合しています。
- フレンドやチャット：これらも未提供です。人と人を結ぶ機能は、アカウントの識別が前提になるため、IDを分ける設計とは別に慎重な検討が要る領域だと考えられます。
なお、アソバースにあるランキングは、プレイ回数・いいね数・レビュー平均で並べる作品のランキングです。人のランキングではありません。プレイ回数も作品を起動した実測回数で、人数ではないと説明されています。ここにも「作品は数えるが、人を横断して追跡しない」という一貫した姿勢が読み取れます。
一方で、同じ作品の中での連続性は保たれます。ログイン中はクラウドセーブが使え、作品ごとにJSONで128KiBまで保存できます。IDが作品専用であることは、「この作品のセーブは、この作品とこのアカウントの組み合わせに属する」という形で働いていると読めますが、セーブの内部の鍵の作り方は確認済み事項にないため、これは推測です。
自分で確かめる：二作品のIDを比べる手順
「同じアカウントなのに作品ごとにIDが違う」という点は、自分の作品が二つあれば確かめられます。以下は実験の設計書です。結果はここには書きません。
準備するもの
- アソバースのアカウント（ログイン済み）
- 自作のゲーム二つ。アップロード投稿ならSDKは自動で追加されます。URL投稿なら、作者がSDKを読み込んでおきます。
- ブラウザの開発者ツール。ゲームはiframeの中で動くため、コンソールの実行対象を、ゲームのiframeに切り替える必要があります。
- メモ用の表（作品名、日時、端末、ログインの有無、IDの全文）
IDの取得方法は、SDKの案内で確認してください。この記事では名称や呼び出し方を示しません。
手順
- 同じ端末・同じブラウザ・ログイン中の状態で、作品Aを開き、プレイヤーIDを取得して記録します。
- 作品Aをいったん閉じ、開き直して、もう一度取得します。これを3回繰り返します。
- 作品Bでも同じ操作を3回行います。
- 記録した6件の文字列を、先頭だけでなく全体で比べます。
結果の読み方
- 作品Aの3回が互いに一致し、作品Bの3回も互いに一致し、AとBの値が異なる：作品専用という説明どおりの挙動と読めます。
- 同じ作品のなかで毎回値が変わる：取得の条件（ログインの状態やSDKの読み込み）を見直し、SDKの案内に当たってください。
- AとBが一致する：読み込んでいるSDKの種類や、取得している値が違う可能性があります。案内を確認し、必要なら問い合わせてください。
起こりやすい誤り
- ゲストとログイン中を混ぜて比べる：ゲストにIDが付くか、付くとしてどう扱われるかは、確認済み事項にありません。ゲストの履歴や進行は端末内に保存され、ログイン後のアカウントへ自動では混ざらないことだけが分かっています。比べるときは条件をそろえてください。
- localStorageの値をIDと取り違える：アップロード作品内のlocalStorageやsessionStorageは、一時メモリーの互換処理です。恒久的な保存の根拠にはなりません。
- 別の端末の結果を混ぜる：端末が違うと、未同期のセーブの状態などが変わる場合があります。まず一台の端末で完結させてください。
- IDを外に貼る：記録したIDは、公開の場所に貼らないでください。作品専用の印とはいえ、その作品の中では本人を指す値です。
次の行動
自作のゲームが二つあれば、上の手順でIDを6件記録し、作品ごとの一致と不一致を表に書き出してみてください。作る前の段階なら、ゲームのセーブに何を入れるかを決めるとき、メールアドレスなどの個人情報を入れない設計にして、128KiBの範囲に収まるJSONを組んでみるのが最初の一歩です。IDの形式やゲストの扱いなど、この記事で「確認する」とした点は、公開されている現在の案内で確かめてください。
