データ転送 - lolly-backup バンドル

Lollyユーザーが蓄積するすべてのデータはそのデバイス上にあります - アカウントもクラウドもありません。データ転送バンドルはその価値を移動させる手段です：あるインストールでエクスポートし、任意の方法（USB、AirDrop、自分宛メール、ネットワーク共有）でファイルを運び、別のインストールでインポートします。ファイルそのものが転送手段です。転送先はオフラインでもオンラインでも構いません。サーバーと一切通信しないため、違いはありません。

signed by Lolly2026-10-21vector SVG9 paths~4.9k nodes11 groups56 KB自分で確認する署名済みファイルを取得 signed by Lolly2026-10-21vector SVG9 paths~4.9k nodes11 groups56 KB自分で確認する署名済みファイルを取得

このページはフォーマット仕様です。エンドユーザー向けの手順は作業を見つけて復元する → 作業を別のデバイスに移すを参照してください。実装はshells/web/src/data-transfer.tsで、tests/data-transfer.test.tsがラウンドトリップの契約を固定しています。

範囲。 バンドルが運ぶのはユーザーデータであり、カタログツールではありません。ツールとカタログアセットは別途同期され、転送先にはすでに存在している(最悪の場合はより新しいバージョンで)ことが前提です。ユーザー自身が作成したツールはprofile.jsonの中を運ばれます。インポートがカタログツールをインストールしたりアップグレードしたりすることは決してありません。

目標

• 1つのフォーマット、すべてのシェルで。 Web PWA、Tauriデスクトップ/モバイルアプリ、そして将来のシェルはすべて、同じエンベロープと対応するパートのスキーマを共有します。任意パートは各シェルのケイパビリティに依存し、対応していないパートは報告されます。各ケイパビリティブリッジが、その背後のストレージアダプターを提供します。
• 転送に耐える。 転送中に破損・切り詰められたバンドルは、インポート時にはっきりと失敗し、決して中途半端に復元しません。
• このバージョンより長持ちする。 古いアプリでも、新しいバンドルの認識可能な部分はインポートできます。本当に互換性を破る変更は、明確に拒否されます。
• 安全にマージできる。 すでに使用中のインストールへのインポートが、バンドルに含まれていなかったものを消すことは決してありません。

エンベロープ

バンドルは通常の .zip です。ダウンロードは所有者にちなんで命名されます - LollyTools-<First>-<Last>-<YYYY-MM-DD>-<n>.zip（例：LollyTools-Ada-Lovelace-2026-06-26-1.zip）- これによりバックアップが溜まったDownloadsフォルダでも判読しやすくなります。名と姓の部分はプロフィールから取得され、未設定の場合は省略されます。プロフィールがない場合は LollyTools-2026-06-26-1.zip に、名だけの場合は LollyTools-Ada-2026-06-26-1.zip になります。各部分はファイル名に安全なトークンにサニタイズされます（Unicodeの文字・数字は保持し、スペース・句読点は除去、最大32文字）。<n> は日単位・デバイス単位の連番なので、同じ日に複数回エクスポートしても衝突せず順序が保たれます。名前の生成はshells/web/src/data-transfer.tsの backupFilename() が行います。zipの中身は名前に関わらず同一です。内訳：

バンドルはあえて通常のzipにしてあります。どんな転送手段でも無傷で残り、どの解凍ツールでも中身を確認できます。

profile.json は最小のパートであり、アプリ内でリーダーが最初に目にするものでもあります。作成者が一度だけ入力する詳細情報と、それをツールが利用できるようにするオプトインです。

signed by Lolly2026-10-21vector SVG15 paths~1.2k nodes30 groups1 image40 KB自分で確認する署名済みファイルを取得

manifest.json

{
  "format": "lolly-backup",
  "formatVersion": 3,
  "minReader": 1,
  "app": "lolly",
  "exportedAt": "2026-06-22T09:30:00.000Z",
  "counts": { "profile": true, "sessions": 2, "userAssets": 4, "prefs": 3, "assetVersions": 1, "fileOperations": 1 },
  "integrity": {
    "profile.json": "sha256-…",
    "sessions.json": "sha256-…",
    "assets.json": "sha256-…",
    "assets/blobs/0.bin": "sha256-…",
    "file-history.json": "sha256-…",
    "file-history/versions/0.bin": "sha256-…",
    "file-history/results/0.bin": "sha256-…",
    "prefs.json": "sha256-…"
  }
}

バージョンポリシー（前方互換性）

formatVersion と minReader を分けていることが、古いインストールを取り残すことなくフォーマットを進化させられる理由です。

• リーダーは manifest.minReader ≤ 自身のリーダーバージョンである場合にバンドルをインポートします。拒否される（「needs a newer version of the app」というメッセージとともに）のは、バンドルが明示的により新しいリーダーを要求している場合のみです。
• 加算的な変更 - 新しい任意のパート、または新しい任意のマニフェストフィールド - は formatVersion を繰り上げますが minReader は変更しません。古いアプリでも認識できるパートはすべてインポートされます。認識できないパートはスキップされます（下記参照）が、黙って捨てられることはありません。
• 互換性を破る変更 - あるパートを誤ってインポートするとデータが壊れる場合や、以前は任意だったパートが必須になる場合 - は minReader を引き上げます。古いアプリは、扱えないものをインポートしようとする代わりに、明確に拒否します。
• 将来のバンドルが formatVersion を設定しつつ minReader を省略した場合、リーダーは安全側に倒して formatVersion をゲート条件とします（その変更を互換性を破るものとして扱います）。

作成者向けの経験則： 既存のすべてのリーダーが、あなたの追加を無視しても正しく動作し続けるなら、それは加算的な変更です - formatVersion を繰り上げ、minReader はそのままにします。そうでなければ minReader を引き上げてください。

整合性

manifest.integrity が存在する場合、リーダーは何かを書き込む前に、記載された各パートのSHA-256を検証します。不一致（「failed its integrity check」）や欠落パート（「incomplete」）が見つかると、インポート全体が中止されます - 部分的な復元は行われません。これにより、ファイル転送によって生じうる破損（途切れたAirDrop、添付ファイルを再エンコードするメールゲートウェイ、不良なUSBセクタなど）を検出できます。

整合性チェックは設計上ベストエフォートです。書き込まれるのはWeb Cryptoが利用可能な環境（すべてのセキュアなブラウザコンテキストと最近のNode）のみで、検証されるのはマップとWeb Cryptoの両方が揃っている場合のみです。マップを持たないバンドル - 例えば整合性機能が存在する前に作られたもの - は、そのままインポートされます。「検証できない」ことが「破損している」と扱われることは決してありません。

マニフェストは、自分自身も再生成された lolly.txt READMEも一覧に含めません。ダイジェストが対象とするのは、マニフェストが保証するパートのみです。

インポートのセマンティクス

インポートはマージであり、全置換になることは決してありません:

• 転送先の既存データはそのまま残ります。
• セッションスロットやアップロード画像のidが両方に存在する場合、より新しく保存された方のコピーが残るため、古いバックアップが転送先の新しい作業を上書きすることはありません。時刻が同じか不明な場合は転送先のコピーが残ります。作成履歴を持つWebインストールでは、同じルールによって作品のどちらのコピーを現行として残すかが決まり、もう一方のコピーは保護されたドラフトとして保持されます(下記参照)。
• プロフィールレコードは置き換えられるのではなくマージされます。転送先の各フォルダーはその中身とともに残ります。バンドルにあって転送先にないフォルダーは追加され、両方にあるフォルダーは転送先の名前と親を保ったまま、不足しているバンドル側のメンバーを取り込みます。転送先のフォルダーに入っているセッションは、そのフォルダーに入ったままです。
• お気に入り(ツール、カタログアセット、プロジェクトの項目)は統合されます。テンプレート、プロジェクトのテンプレート、そしてバンドルのユーザー作成ツールは、転送先にそのidのレコードがない場合に追加されます。両方のゴミ箱の項目は保持されるため、どちらのインストールでも復元できた項目は復元できるままです。
• それ以外のすべてのプロフィールフィールド(氏名、連絡先、言語、フィーチャーフラグ、非表示にしたツール、その他の設定)は転送先の値を保持します。転送先で空になっているフィールドは、バンドルの値を採用します。prefs.jsonについても同様です: 環境設定は転送先に存在しない場合にのみ書き込まれます。
• デバイス同期の通常の適用は例外です: デバイス同士をそろえるため、同期されたコピーのプロフィールレコード、環境設定、セッション、画像をそのまま採用します。以前のコピーを復元する場合も同様です。これは意図的に時間を巻き戻す操作だからです。最初の参加であるこの端末に取り込むは、インポートと同じようにマージされます。
• 過去のアセットバージョンと操作IDは不変の例外です: 繰り返しのインポートは冪等であり、すでに異なるバイト列/履歴を指しているIDは、上書きされるのではなく拒否されます。同一の現行アセットを再インポートしてもそのバージョンは保たれます。変更された現行アセットは別のバージョンを持たなければなりません。
• 作成履歴もマージされます。両側にある作品は、より新しく保存された方のコピーを現行とし、もう一方のコピーを保護されたドラフトとして残します。転送先がそのスロットを別の作品に使っている作品は、その隣に追加されます。転送先のゴミ箱にある作品はそのまま残ります。転送先で異なる内容を指しているチェックポイントidは、転送先のものを残します。自身の検査に失敗したアーカイブは、プロフィール・セッション・アセット・環境設定のいずれかが変更される前にインポートを中止します。同一内容の繰り返しインポートはストレージを増やしません。
• バンドルに含まれていなかったものには一切手が加えられません。転送先にはあってもバンドルにはなかったセッションは、インポート後も残ります。

保存済みセッションは画像に自動的に再リンクされます：アセット参照はidで保持され、アップロード画像が復元された後にブリッジがそれらを再解決します（blob: URLはリロードを跨いで残らないため、いずれにせよ必要な処理です）。

インポートのサマリーは { profile, sessions, userAssets, prefs, skipped, failedAssets } を報告します。failedAssets は復元できなかったアップロード済みアセットの数です（例えばデバイスのストレージが満杯の場合など）。これは skipped とは別物で、skipped は前方互換な新しいライターに由来し、このビルドが認識しなかったパートの数を表します。UIは skipped を表示するため（「… · N newer items skipped」）、復元がどこを取りこぼしたかについて正直です。

ファイル履歴が存在する場合、サマリーにはassetVersions、fileOperations、failedHistoryも含まれます。ストレージ枯渇や不変ID同士の衝突は部分的な復元を招くことがあり、UIはユーザーに元のバックアップを保持しておくよう伝えます。クラウド同期は、部分的または非対応の復元の後に適用済みリビジョンを進めることはありません。そのためスナップショットは再試行のために利用可能なまま残ります。復元は、プロフィール・セッション・アセット・履歴の全ストアにまたがる単一のトランザクションではありません。

作成履歴(v3)

履歴機能に対応したWebホストからの手動バックアップには、独自の{ version: 1, documents, revisions, recoveries }スキーマを持つrevision-history.jsonが含まれます。これは、保持されたID、正規化された入力のスナップショット、バージョンのスタンプ、ラスタープレビュー、そして書き手ごとに分かれたドラフトを運びます。履歴アダプターは、現行セッションとそのheadを1回の読み取りトランザクションで取得します。sessions.jsonは、それより古いリーダーのために同じ現行スナップショットを使用します。

復元は、アーカイブを1つのトランザクションとしてコミットする前に、ペイロードのSHA-256とバイト数、一意な識別子、ドキュメントとheadの関係、系譜、タイムスタンプ、プレビューの種類、上限をチェックします。圧縮された親への参照が存在しないこともあります。既存の現行の作業がサイレントに置き換えられることは決してありません: 作品が両側にある場合、現行として残らなかった側は保護されたドラフトになります。アーカイブの384MiBという転送上限は明示的にチェックされ、ストレージの上限は、保持されたチェックポイントを切り詰めることなく適用されます。バックアップ全体は依然としてメモリ内のZIP実装を使用しており、ストリーミング方式のアーカイブではありません。

サマリーには、このインポートが追加した分だけを数えるrevisionsとrecoveryDraftsに加えて、各作品がどのようにマージされたかを示すadded、kept、replaced、copies、hiddenが追加されます。この機能を持たないシェルは通常のセッションのみを復元し、履歴パートをスキップ済みとして報告します。ネイティブファイルシステムの履歴は、そのアダプターが永続的な履歴トランザクションを提供するまで未対応のままです。P2Pゲストの状態には永続的な履歴も復旧用アーカイブもありません。

個人のスナップショット同期は、作成履歴を明示的に対象外とします。履歴を持つローカルドキュメントにスナップショットを適用すると、それ以前の作業状態は別の復旧用ドラフトとして保持され、開いているエディタの書き込みトークンはすべて無効化されます。不変のチェックポイントはデバイス上に残ります。これはスナップショットの置き換え中にローカルの履歴を保護するためのものであり、複数デバイスの履歴を統合するものではありません。

過去のアセット参照は保持されますが、レンダリングは引き続き転送先の既存ライブラリを通じてアセットを解決します。このアーカイブは、過去のアセットのバイト列や過去のツールのレンダリング結果を正確に保証するものではまだありません。アセットバージョンとファイル結果のバイト列は、引き続き既存の別のバックアップパートを通じて運ばれます。

保存済みバージョンとファイル結果(v2)

任意の履歴パートには{ version: 2, assetVersions: [...], operations: [...], batches: [...] }が含まれます。リーダーは、batchesを持たない以前のhistory-v1形式も受け付けます。各スナップショットは、安定したアセットIDと正確なバージョン、保存時刻、バイト長、16進SHA-256を識別し、さらに_fileと任意の_credentialFileがバイナリパートを指すアセットレコードを伴います。操作は、元のファイルの事実関係、リクエスト、レポート、タイムスタンプ、任意の結果_fileを運びますが、ストレージバックエンド名、OPFSハンドル、実行リースは運ばれません。history-v1のみに対応する古いリーダーは、バッチのメンバーシップをサイレントに落とすのではなく、インポート前に新しい履歴バージョンを拒否します。

バッチマニフェストは、一度も読み取られなかったファイル、キャンセルされたメンバー、結果の保存領域確保に失敗したもの、中断された作業を含め、処理前に選択されたすべてのソースを記録します。各メンバーは、安定した操作ID、ソースの参照/事実関係、要求された出力名、確定したレポートを持ちます。未読のソースは、でっち上げのダイジェストではなく、宣言された事実関係を持ちます。インポートは、メンバーの識別情報と、運ばれてきた操作レポートとの整合性を検証します。個々の結果が明示的に削除された後もバッチレポートは利用可能なままですが、その受領記録は出力バイト列がまだ保存されていることを意味しません。

• 既知のすべての履歴レコード、レポート、参照先ファイルは、プロフィールやアセットのインポートによる書き込みが行われる前に検証されます。エンベロープに整合性マップがない場合でも、不足しているバイト列やSHA-256の不一致は失敗として扱われます。抽出された認証情報は、それらを数値キーのオブジェクトとしてJSONシリアライズしていた古いライターからのインポートも含め、バイト配列のまま保たれます。
• 実行中の操作は、バックアップの中では説明的な失敗レポートを伴い、結果を持たない中断済みレコードになります。復元がバックグラウンドの作業を再開したり、有効な実行リースをインポートしたりすることは決してありません。再試行には元のファイルを選び直す必要があり、記録されたSHA-256が利用可能であればそれと照合されます。
• 復元された結果は、そのバイト列とメタデータをまとめてIndexedDBにコミットします。通常の新しい結果は、利用可能な場合はOPFSを使用し、IndexedDBへのフォールバックを備えます。既存の実行中の操作がインポートによって置き換えられることは決してありません。
• 履歴のZIP組み立ては依然としてメモリ上で行われます: 現在の上限は履歴ペイロード256MiB、履歴メタデータ4MiB、最大で操作100件、バッチ100件、スナップショット2,000件です。エクスポートは、サイズ超過や不完全な履歴を明示的に拒否し、サイレントに省略することは決してありません。古いローカルコピーを削除する前に、重要なバージョン/結果は個別にダウンロードしてください。これらの上限は、スマートフォンにおけるピークメモリ使用量を測定して保証するものではありません。
• ローカルの結果履歴には512MiBの予算と100件のレコード上限があります。アセットのスナップショットには別途512MiBの予算があり、アセットごとに最大20件の過去バージョンまでです。抽出された認証情報のバイト列は、そのスナップショット予算にカウントされます。復元はこれらの上限を尊重し、既存のユーザーデータをサイレントに追い出すことは決してありません。
• ローカルのバッチメタデータには別途4MiBの予算があり、最大100件のマニフェストとバッチあたり20件のメンバーまでです。保留中のメンバーはメタデータ容量を予約し、メンバーごとのレポートには32KiBの上限があります。これは論理的な予算であり、ブラウザのディスク容量の保証ではありません。実際にクォータの失敗が起きた場合はそれが表面化し、メモリ上のレポートはダウンロード可能なままです。バッチメンバーを再試行すると、古いレポートを上書きすることなく新しいバッチが作られます。バッチレコードを削除しても、個々の結果のバイト列やライブラリのアセットは削除されません。
• 変換された結果は、正規化や再エンコードを行うことなく、明示的にライブラリへ追加できます。ソース/出力のハッシュと操作の関連付けがそのアセットに付随します。繰り返し追加しても変更のないコピーは再利用され、編集済みのコピーが上書きされることは決してありません。ラスター画像は新しいDesignドキュメントを開始できます。そのドキュメントは現行のライブラリアセットIDを使用します: Designのランタイムとurlパス全体にわたって正確なバージョン固定を強制することは、依然として別途の作業です。SVG/HTML/PDF/ZIPの結果は、この受け渡しによって不透明なファイルアセットとして保持され、信頼されたインタラクティブ/ベクターコンテンツへは昇格しません。
• Convert → Recent file operationsでは、履歴の利用状況、レポート、ダウンロード、バージョンマネージャーを確認できます。このマネージャーは、削除済みのライブラリアセットの過去バージョンも見つけ出します。スナップショットを復元すると、選択したスナップショット自体はそのまま保たれつつ、新しい現行バージョンが作られます。設定 → ストレージは、使い捨てのキャッシュとは別に、結果とバージョンを計上します。
• 明示的な一時ファイルのクリーンアップは、操作が所有し、どこからも参照されていないバイト列のみを削除します。現行のレコードはそのファイルを保護し、最近のOPFSファイルには1時間の猶予期間があります。保存済みの結果とアセットのスナップショットは自動的には消去されません。

古いリーダーも引き続きv2のエンベロープ(minReader: 1)を受け入れ、見慣れたパートを復元し、対応していない履歴パートはスキップ済みとして数えます。完全な履歴復元にはfileHistoryアダプターを持つシェルが必要です。これはシェル内部の接点であり、ツール向けの新しいHostV1ケイパビリティではありません。実際の2台間の復元は、ローカルのChromiumゲートで検証されます。インストールされたTauri/iOS/Androidでの復元の受け入れ検証は、別途行われます。

転送されないもの

• カタログキャッシュ(ダウンロード済みのアセットメタデータとblob、ツールインデックス) - 転送先で無償で再同期される。
• カタログツールとカタログアセット - 対象外であり、転送先にはすでに存在していることが前提。ユーザーが追加したブランドトークン、フォント、ロゴはユーザーアセットであるため、これらは転送される。
• blob: / オブジェクトURL - 読み込み時にブリッジが再生成する。
• 変換の元ファイル、実行中の実行リース、そしてマシンローカルなアクセス/署名用の秘密情報 - 移植可能な履歴ペイロードではない。保存された結果はコピーであり、元のソースがバックアップされていたことを意味するものではない。
• エクスポート連番カウンター - 日単位のダウンロード命名カウンター(localStorageのlolly-export-seqキー)は、ローカルな命名上の便宜にすぎない。PREF_KEYSから除外されているため、バンドルに含まれることは決してない。

ストレージメーターも同じ区分けを項目別に示します。保存済みセッション、自分の画像、そしてファイルの結果とバージョンはバンドルに含まれます。その下にあるアセットキャッシュ、ツールプレビュー、オフラインピンはすべて再導出可能なため、残されます。

signed by Lolly2026-10-21vector SVG37 paths~4.9k nodes85 groups65 KB自分で確認する署名済みファイルを取得 signed by Lolly2026-10-21vector SVG37 paths~4.9k nodes85 groups65 KB自分で確認する署名済みファイルを取得

クロスシェルの保証

data-transfer.tsは、ケイパビリティブリッジ(host.profile、host.state、host.assets)と共有のlocalStorageのprefsだけを通じて読み書きします。同じモジュールが、IndexedDBまたはファイルシステムのストレージを介して、Webでもtauriでも共通のエンベロープを読み書きします。任意の履歴パートは、対応するアダプターが利用可能な場合にのみ現れ、対応していないパートはインポート時にスキップ済みとして報告されます。ヘッドレステストスイートはインメモリのブリッジに対して共通パートを検証し、履歴のトランザクションについては実ブラウザでのテストも別途あります。

この保証の外にあるシェルが2つあり、それぞれ理由が異なります。

• ワンショットのCLIは保持するものがありません - その状態は呼び出しごとにインメモリで一時的なものです。
• TUIは状態を永続化しており(~/.lolly: セッション、フォルダ、プロフィール)、そのProfileビューはバックアップも取れますが、書き出すのは独自のよりシンプルなアーカイブです: セッションごとのsaved-state/<slot>.jsonに加えてprofile.jsonとfolders.jsonがあるだけで、マニフェストもformatVersion/minReaderも整合性マップもありません。この形式ではインポートできず - リーダーは「Lollyのバックアップではありません」として拒否します - しかも紛らわしいことに似た名前(lolly-backup-<stamp>.zip)を使っています。両者の統一は既知のギャップです。

予約された拡張ポイント

エンベロープはマニフェストと名前付きパーツの集合として設計されているため、新しい種類の移植可能なデータを破壊的変更なしに後から乗せられます。それらは追加的なパーツとして組み込まれ(新しいformatVersion、同じminReader)、現在のリーダーは認識しないものをスキップします。これらはまだ実装されていません。将来これらが導入されたときにフォーマットの一貫性を保つため、名前だけをここで予約しています。

• tokens.json - デザイントークン。 W3C DTCGのデザイントークンドキュメント(Penpotがインポート/エクスポートする形式 - $value/$type/$descriptionを持つトークンをグループ、セット、テーマに整理したもの)。バンドル内のトークンセットにより、ユーザーはセッションと一緒にブランドのプリミティブをインストール間で移動できます。(ユーザー自身のブランドトークンは、すでに今日でもassets.json内のuser/tokens/brandアセットとして移動しています。このパートは、セットとテーマを含む完全なDTCGドキュメントを丸ごと運ぶことになります。) 長期的には、取り込まれたトークンセットはツールやパレットアセットが参照する第一級のソースになります。
• penpot/ - 取り込まれたPenpotファイル。 インポートされツールとして表示されるPenpotファイル(またはその抽出されたLolly関連サブセット)のための予約ディレクトリです。バンドルは取り込まれた定義を保持するため、ユーザーの他のデータと一緒に移動します。

これらの予約名と上記のパーツ以外のものは、リーダーから見ると未知のパーツです。手を加えられずに残り、skipped にカウントされます。

リファレンス

• モジュール: shells/web/src/data-transfer.ts(exportBackup、importBackup、BACKUP_FORMAT、BACKUP_FORMAT_VERSION、BACKUP_READER_VERSION - backupFilename()の命名関数は内部用です)。
• コントラクトテスト: tests/data-transfer.test.ts - ラウンドトリップ、マージ、整合性、前方互換性、リーダーゲートの各ケース。
• 履歴のコントラクトテスト: tests/file-history-backup.test.ts、tests/file-batch-history.test.ts、tests/file-result-library.test.ts。ブラウザでの受け入れテスト: tests/file-history.browser.test.ts、tests/file-batch-history.browser.test.ts、tests/file-result-reuse.browser.test.ts。
• 使用するブリッジ面: host.profile、host.state、host.assets - Host APIを参照。