Portable Capsule
このページは Portable Application の wire v3 / v4 と、2026年10月29日に確認した実装を説明します。利用可否は配備バージョンとアカウントの権限によって異なります。記載したすべての経路について本番での利用可否を確認したものではありません。
Capsule とは
Capsule は、計算を続けられる seal 済み・不変・アドレス可能な地点です。Run はその地点から進む実行です。ファイル、コンテナ、スナップショットは Capsule の転送や実現に使われますが、その同一性ではありません。
Portable Application の K は、Run に求める観測可能な条件を定めた Bound Contract です。D は、その Contract を実現するために宣言された Bound Derivation です。バンドルは複数の D を持て、受取側が一つ選択します。同じ K が意味するのは宣言された条件が同じことであり、すべての動作や環境が等価になる保証ではありません。
ContractRef は正規化された K、DerivationRef は正規化された D を識別します。.capsule ファイル全体の SHA-256 は転送バイトの識別子です。依存物を再パッケージすると、K と D を維持してファイルの digest が変わることがあります。実行には対象ホストの runtime、資源、権限、依存物が別途必要です。
Portable Capsule v3 / v4
| wire 形式 | profile | 内容と同一性 |
|---|---|---|
| v3 | ato.portable-application/1 | Contract 起点。宣言されたオブジェクト closure を内包し、Instance snapshot と v4 portability manifest は含みません。 |
| v4 | ato.portable-application/2 | Contract 起点。portability manifest と任意の Instance snapshot を持ち、依存 blob の外部取得先または内包を指定できます。 |
両者の Capsule identity は ContractRef です。2026年10月29日に確認した API stg の curation publisher は Discover 公開に v3 を受け付けます。v4 の import や export ができることだけでは、v4 の Discover 公開は成立しません。Computation 起点の wire v2 は ComputationRef を使う別 profile であり、その root を ContractRef と読み替えません。
validator は正規化、参照と digest、宣言された schema、順序、到達可能な object closure を確認します。構造化オブジェクトは内包され、v4 の外部 blob は取得時に digest と照合します。必要な object の欠落、到達不能な余分の object、未対応 profile、未知フィールドは拒否されます。バンドルが有効でも、選択した D が特定のホストで実行できるとは限りません。
アプリのみと保存データ付き
App only は現在の Instance の保存データを新たに取得せず、K を維持します。確認した実装では、元バンドルに snapshot が既に含まれている場合はそれが保持されます。以前にバンドルされたデータが含まれない保証ではないため、共有前に元データと出力を確認してください。App + this app's saved data は対応する保存リソースと asset の v4 snapshot を作成します。snapshot の条件が新しい Contract K′ に結び付くため、含まれる snapshot が変わると K′ も変わります。宣言済み DerivationRef は保持されます。受取側には新しい Instance とリソースの ID が作られます。任意のファイル、プロセスメモリ、ブラウザーの cookie、外部サービスすべてを取得するものではありません。
v4 の依存物の選択肢は Thin、Standard（cached）、Offline です。Thin はネットワークを必要とする場合があり、Standard は一部を内包し残りを取得できます。Offline はポータブルな依存 closure の内包を要求します。OS、ドライバー、Docker engine 等のホスト能力まで含むわけではありません。取得元 URL は digest 検証の代わりにはなりません。
エクスポートとインポート
- サインインし、Discover で対応する Portable アプリを開きます。タイトル横にある、しおり型の Libraryに保存 を選び、案内が出た場合は従ってください。インポートと検証の完了を待ちます。
- ライブラリ でアプリのタイルを右クリックします。タッチ端末では長押しして指を離します。アプリ情報 を選んで アプリ タブを開き、表示される場合は Ato アプリをエクスポート… を選びます。アプリのみ または アプリ＋このアプリのセーブデータ と依存物を選び、ダウンロードを待ちます。
- 受取側アカウントでサインインし、ライブラリの アプリを追加 で ファイルを選択してください を選び、
.capsuleを指定します。配置先と Binding の案内に従い、インポートと検証の完了後、アプリを実行して結果を確認します。
Export には、検証済み portable import 由来で、有効な所有 Instance と ready の元バンドルが必要です。Classic Discover の保存、ゲスト試用、新規 Formation したアプリだけでは自動的に条件を満たしません。サービスが対象と判断したときだけ Export が表示されます。配備環境や経路によって利用できない場合があります。保存データ付きでは実行中の状態を flush し、該当する volume は停止状態の checkpoint が必要な場合があります。失敗時はエラーを解消して再試行してください。操作の開始やファイル選択だけでは完了ではありません。
権限を持つ MCP クライアントは check_library_exportability、export_app、get_export を利用できます。App only の export には apps:write が必要です。保存データ付きはブラウザー状態の fence を取得するため PWA から開始してください。Import は prepare_import、必要に応じた complete_import_upload、get_import_validation、import_app、get_import を使います。直接 upload ではファイルの digest・バイト数・v3/v4 の version と profile を prepare_import に渡し、返された URL と headers で upload してから complete_import_upload を呼び、validation を確認します。宣言済み D を選びます。同じ idempotency key は同一要求の再試行だけに使います。ローカル・セルフホストの補足は CLI クイックスタートを参照してください。
互換性と制限
制限を確認するときは、次の区分を分けて考えてください。
- FORMAT: root や object の参照など、wire profile の規則。
- IMPLEMENTATION: 特定の codec、API、Worker の上限や対応操作。
- PLATFORM: ホスト、Runner、runtime、デバイス、ネットワーク、依存サービスの条件。
- POLICY: 所有権、権限、provenance、ライセンス、公開の条件。
- UNVERIFIED: 実行証拠が不足している経路や環境。
以下は2026年10月29日に確認した実装です。すべての経路が本番で有効であるという意味ではありません。
| Runtime | 証拠 |
|---|---|
| Static | staging の一部事例を検証 |
| Process | Python の一事例を検証 |
| OCI | staging の一事例を検証 |
| WASM | 一般的な対応は未検証 |
| Desktop | 一般的な対応は未検証 |
| GPU | 一般的な対応は未検証 |
- Static web: IMPLEMENTATION, UNVERIFIED. 実装済み。一部の staging 事例で検証、Run 検証、別アカウントでの試験に成功しています。全アプリの保証ではありません。
- Process / Python: IMPLEMENTATION, PLATFORM, UNVERIFIED. Python process の一例は staging managed Runner で成功しました。実行可否は固定された runtime、OS、architecture、依存物、ネットワーク、policy に依存し、別の process の実行を保証しません。
- OCI: IMPLEMENTATION, PLATFORM, UNVERIFIED. 対応する container と service group の経路があります。Databag の app-only export/import の一例は linux/amd64 の staging 別アカウント間で HTTP 観測と receipt を確認しました。D の上限は CPU 1、memory 512 MiB です。その試験では保存 volume の移送、通話、他の platform は未検証です。他の image や service はそれぞれ admission と検証が必要です。
- WASM、Desktop、GPU: PLATFORM, UNVERIFIED. 対応する Adapter、Runner、環境によって異なり、一般的な Portable 対応は未検証です。
- 保存状態: IMPLEMENTATION, UNVERIFIED. 対応する browser state、JSON リソース、参照 asset を取得できます。filesystem volume checkpoint の経路は実装されていますが、確認した時点で別アカウント間の volume 往復は未検証です。その他のローカル状態や外部状態は自動的には含まれません。
- Secrets と権限: IMPLEMENTATION, POLICY. token、credential、grant、lease、外部アカウントへのアクセスは Binding として移送されません。受取側で再設定してください。アプリの保存データ自体に機密情報が含まれることはあるため共有前に確認してください。アプリと依存物を再配布する権限とライセンスも必要です。
- サイズ: IMPLEMENTATION, UNVERIFIED. 確認した hosted API のバンドル上限は 256 MiB で、利用可能な場合は 32 MiB 超に直接 upload を使います。validator の workspace artifact 転送と報告される workspace 総量にはそれぞれ別途 64 MiB 上限があります。確認した PWA はファイル先頭 8 MiB の中で完全な bundle index を読み取る必要があります。確認した Rust codec は別途、エンコードされた bundle 768 MiB、1 object 64 MiB、宣言された decoded object の合計 256 MiB、object 数 10,000 件に制限し、OCI archive には追加の上限があります。これらは実装上の上限であり、v3/v4 形式の普遍的な制限ではありません。staging では 40.3 MB の bundle が直接 upload と validation に成功しました。96,660,033 バイトの v3 bundle は upload されましたが workspace 転送は拒否されました。download の成功上限は実測していません。
- User-managed Runner: PLATFORM, IMPLEMENTATION, UNVERIFIED. admission が許す場合は配置先として選択できます。Runner に置かれた volume はその Runner に固定され、別の Runner の選択は拒否されます。特定の Runner と状態での export や別アカウントでの再現は一般には未検証です。
バンドルが検証済みでも、依存物、runtime、権限、上限により実行は失敗し得ます。エラーが許す場合に同一操作を再試行し、要求を変更する場合は新しい idempotency key を使ってください。バンドルの検証、Discover 公開、別アカウントでの実行は別々の結果です。
検証と Receipt
バンドルの validation は将来の Run を証明しません。Run receipt は ContractRef、選択した DerivationRef、対象環境、観測結果、利用可能な場合は bundle digest と実行証拠を記録します。fully_satisfied=true は、その検証で receipt のすべての条件が満たされたという意味です。Deferred や Failed は該当しません。観測していない動作、安全性、ライセンス適合性、別マシンでの成功は証明しません。インポート後や環境変更後は再検証してください。
不足する能力には、新しい D、Adapter や Runner、API/MCP 入口、運用・権限・ライセンス上の対応で解決できる場合があります。形式変更は、具体的な要件を v3/v4 で表現できない場合に別途検討します。ここに挙げた制限だけを理由に v5 が必要とは言えません。