ゲスト、サインイン、アカウント切り替えで、プロジェクトデータはそれぞれどこに置かれるか
SlateX はゲスト状態とサインイン状態のデータを2つの分けた物理データベースへ置いていて、同じ1組のデータモデルを使い、同じ1つのファイルではありません。ゲストライブラリが担うのは未サインイン状態の記録だけです。アカウントライブラリはサインイン後の記録を担い、クラウドのプライベートデータベースを設定されているのもアカウントライブラリだけです。アカウントを切り替えるときの帰属も、「現在誰がサインインしているかで全件の記録の帰属を決める」やり方ではなく、1件ごとに Apple の身元の条件で判断しています。
分けたライブラリが解決するのは「データがどちら側に落ちるか」の問題で、いずれかの安全、プライバシー、デバイスをまたぐ結果に代わって保証しているのではありません。
ゲストライブラリとアカウントライブラリは2つのファイル
ゲストライブラリもアカウントライブラリも、アプリケーションサポートの中の専用サブディレクトリに置かれています。この位置はユーザーが「ファイル」App で直接見る Documents の位置ではないため、「データベースのファイルを見つけた」を「すべてのメディアを手にした」と理解してはならず、データベースのファイル単体のバックアップを完全なバックアップ方案として書くこともできません。
2つのライブラリは同じ1つのデータモデルのインスタンスを共用しているので、プロジェクト、シーン、テイク記録、コンティニュイティの素材などの対象は同じ1組の構造で表現されます。違いは保存の落点です。ゲストのデータはゲストライブラリへ入り、サインイン後のアカウントのデータはアカウントライブラリへ入ります。コードがクラウドのプライベートデータベースを設定しているのはアカウントライブラリだけで、ゲストライブラリはライフサイクル全体を通じてクラウドへのアップロードの設定がまったくありません。ここで言っているのはコードの設定の事実で、「このデバイスではアップロードしないと検証済み」というテストの結論ではありません。
写真と動画はライブラリの中で同じものではない
写真のデータ本体は、データベースの中のバイナリデータとして保存されるため、データベースの記録と一緒に移動します。動画は違います。データベースの中に保存されているのは、ローカルのファイルへ向かう1本のパスで、動画ファイルそのものを同じデータベースのフィールドへ入れているのではありません。
この違いは、写真の記録と動画のパスをデバイスをまたぐときに同じ1種類の機構として扱えないことを意味します。コードが説明できるのは、データベースのそれぞれに何が保存されているかまでで、「別のデバイスへ移れば必ず取得できる」も「必ず取得できない」も約束できません。受け取り側はこれを別々の2種類の保存形態として見る必要があり、データベースの同期をメディアのファイルが到着済みだと等しく扱ってはなりません。
データベースに1件のメディアの記録があっても、対応するローカルのファイルが必ず別のデバイス上に現れているという意味ではありません。
サインイン後、帰属はライブラリ丸ごと主人が変わるのではない
アカウント側のデータの帰属は、1件ごとに Apple の身元の条件で判断されます。プロジェクトとその到達できる記録は、現在の身元に対応する帰属の経路へ落ちる必要があり、あるアカウントが今サインインしているからと、ライブラリの中身を一概にそのアカウントの所有と見なしてはいけません。
この判定は、アカウントを切り替えたときに1件の記録を引き続き読み込めるか、移行できるか、削除できるかへも影響します。言い換えると、サインイン状態はどのデータ環境へ入るかの条件の1つにすぎず、具体的な記録が誰に属するかは、その記録自身がどの関係の経路をたどって対応する身元へ戻れるかにもかかっています。
ゲストのデータは能動的なサインインのときだけ移行する
ゲストの記録をアカウントライブラリへ移すのは、自動的にサインインを復元したときに自然に起きることではありません。ユーザーが自分でサインインを押した1本の経路だけがゲストの移行を開始でき、アプリが既存の認証情報からサインインを復元するとき、ゲストライブラリを自動で運ぶことはありません。
移行自体は段階に分けて実行します。まずゲストライブラリからスナップショットを作り、そのあと移行できる対象をアカウントライブラリへ書き込み、続いて新しいコンテキストを使って属性ごと、関係ごと、帰属ごとに検証します。検証を通って初めて、来源側のゲストの記録が片付けられます。いずれかの段階が失敗すれば、来源側は片付けの手順に入りません。
検証が通らなければ元のまま残します。動かさないで済むなら、半分だけ動かすことはしません。 この一文は現在の移行の順序を記述していて、ネットワーク、クラウド、その他のデバイスが追加の検証を完了済みだとは表していません。
このページが答えられる範囲
この仕組みが答えられるのは、ゲストとアカウントの記録がどちらのライブラリに落ちるか、どのライブラリがクラウドのプライベートデータベースを設定されているか、メディアはデータベースの中でどの形態で現れるか、能動的なサインインのときにゲストのデータがどのように照合を経て移行するかまでです。特定の暗号化のモデルや全範囲のプライバシーの保証を証明することはできず、誰でも読み取れないことも証明できません。コードの設定を、すでに完了したデバイス側の安全監査として書くことは、なおさらできません。
質問が「別のデバイスが同じ瞬間に同じメディアを表示するか」「App を削除したあと復元できるか」「ある法規がこれで満たされるか」へ変わった場合、本稿は手元のデバイスのプロジェクトディレクトリの実際の組織の仕方を記述するだけで、これらの状況へ外挿はしません。
FAQ
ゲスト状態とサインイン状態は同じデータベースを使いますか?
使いません。2つの状態は分けた物理データベースのファイルを使い、同じ1つのデータモデルのインスタンスを共用しています。ゲストの記録はゲストライブラリへ入り、サインイン後の記録はアカウントライブラリへ入ります。
ゲストライブラリもクラウドのプライベートデータベースへ入りますか?
現在のコードはゲストライブラリにクラウドへのアップロードを設定しておらず、クラウドのプライベートデータベースを設定されているのはアカウントライブラリだけです。この表現はコードの設定を記述していて、すべてのネットワーク動作をデバイス側のテストで証明済みだと意味しません。
なぜ写真と動画を同じデバイスをまたぐ予想で理解できないのですか?
写真のデータ本体はデータベースのフィールドの中に保存されますが、動画はデータベースの中にローカルのパスを保存しているためです。2つの保存形態は違い、データベースの記録が存在することだけから、別のデバイスが対応するファイルをすでに取得したと推断することはできません。
ゲストのデータはいつサインイン中のアカウントへ移りますか?
ユーザーが自分でサインインを開始したときだけ、ゲストの移行を開始できます。システムが既存のサインイン状態を復元するときは自動で移行しません。移行は書き込みと検証を通り、検証が通らなければ来源の記録は保持されます。
Axiom One LLC — SlateX。上の数字は 2026-09-24 時点のものです。