Transformers.js で提案されたクロスオリジンストレージ API の実験

[記事一覧に戻る](https://huggingface.co/blog) (これは、Google の Chrome チームに所属する開発者リレーションズエンジニア [Thomas Steiner](https://blog.tomayac.com/) 氏によるゲスト投稿です。) Transformers.js は、Web 開発者がタスク固有のパイプラインを通じて、Transformer の力を Web アプリで簡単に活用できる手段を提供します。ブラウザ内で推論を実行するには、開発者は [pipeline()](https://huggingface.co/docs/transformers.js/en/api/pipelines) のインスタンスを作成し、そのパイプラインを使用したいタスクを指定します。具体的な例として、以下のスニペットは自動音声認識 (ASR: Automatic Speech Recognition) パイプラインを設定する方法を示しています。 import { pipeline } from 'https://cdn.jsdelivr.net/npm/@huggingface/transformers@4.2.0'; const asr = await pipeline( 'automatic-speech-recognition', 'Xenova/whisper-tiny.en', { device: 'webgpu' }, ); const result = await asr('jfk.wav'); console.log(result); ## キャッシュの課題 ソースコードを確認すると、モデルとして [Xenova/whisper-tiny.en](https://huggingface.co/Xenova/whisper-tiny.en) を指定していることがわかりますが、これは一般的な英語音声認識タスクにとって非常に優れた選択です。実際、リンクされた抜粋[1]（https://github.com/huggingface/transformers.js/blob/bc9cf7400f4f2c8695016699f879e31026ff0313/packages/transformers/src/pipelines/index.js#L151-L158）によると、Transformers.js の[デフォルトモデル解決](https://github.com/huggingface/transformers.js/blob/main/packages/transformers/src/pipelines/index.js)において、これはまさにデフォルトのモデルとなっています。 ## モデルリソース ブラウザでこの例 [2]（https://googlechrome.github.io/samples/transformersjs-automatic-speech-recognition/index.html）を実行すると、Transformers.js が自動的に関連するモデルリソースと Wasm ファイルのダウンロードおよびキャッシュ処理を行います。以下のスクリーンショットは、アプリにアクセスした後の Chrome DevTools の [Cache storage](https://developer.chrome.com/docs/devtools/storage/cache) セクションを示しています。ページを再読み込みすると、リソースは [Cache API](https://developer.mozilla.org/en-US/docs/Web/API/Cache) から提供され、モデルからの結果返却もほぼ瞬時に行われます。 [1]: https://github.com/huggingface/transformers.js/blob/bc9cf7400f4f2c8695016699f879e31026ff0313/packages/transformers/src/pipelines/index.js#L151-L158 [2]: https://googlechrome.github.io/samples/transformersjs-automatic-speech-recognition/index.html しかし、Xenova/whisper-tiny.en は人気のあるモデルであり（前述の通り、Transformers.js における ASR デフォルトモデルとしても知られています）、あなたが訪れるアプリがこれを利用するのは一つだけではないことは容易に想像がつくでしょう。この状況をシミュレートするために、前回の例と同じアプリを [異なるオリジン](https://rawcdn.rawgit.net/GoogleChrome/samples/c4192bd7a3c66fc288a7b22b77acb935df00b8a1/transformersjs-automatic-speech-recognition/index.html) から提供したものを示します。この異なるオリジンのアプリを訪れると、ブラウザはほぼ即座に利用可能になるのではなく、前回のものと同じバイト単位で同一のモデルリソースであっても、再度ダウンロードしてキャッシュする必要があります。この toy example（玩具的な例）ですら、Chrome DevTools の [Application パネル](https://developer.chrome.com/docs/devtools/application#open_the_application_panel) 内の **Storage** セクションで確認できるように、重複したダウンロードと保存で合計 177 MB に達します。これがすぐに膨れ上がっていくことは容易に想像がつくでしょう。 ## Wasm ランタイムリソース しかし、状況はさらに悪化します。トイ・サンプルにセカンドのパイプラインとして感情分析を追加してみましょう。デフォルトでは [Xenova/distilbert-base-uncased-finetuned-sst-2-english](https://huggingface.co/Xenova/distilbert-base-uncased-finetuned-sst-2-english) モデルが使用されます (モデルを指定しない場合、Transformers.js のデフォルトのモデル解決機構が自動的にこれを選択します)。 const classifier = await pipeline('sentiment-analysis'); const sentiment = await classifier(result.text); pre.append('\n\n' + JSON.stringify(sentiment, null, 2)); これらは全く異なる 2 つの AI モデルですが、Transformers.js の基盤となっている ONNX ランタイムライブラリ [from the underlying ONNX Runtime library](https://onnxruntime.ai/docs/api/js/interfaces/Env.WasmFilePaths.html#wasm) から提供される、同じ 4,733 kB の ort-wasm-simd-threaded.asyncify.wasm WebAssembly (Wasm) ランタイムファイルに依存しています。[異なるオリジンの拡張デモ](https://rawcdn.rawgit.net/GoogleChrome/samples/d47114a15637383015c274e7bdcd81e1a17b0ccf/transformersjs-automatic-speech-recognition/index2.html) を開くと、[Network タブ](https://developer.chrome.com/docs/devtools/network#load) で Wasm ランタイムも再度ダウンロードされキャッシュされていることが確認できます。 したがって、同じ AI モデルを共有していないアプリを実行していても、ブラウザはすでに存在する共有 Wasm リソースに対して冗長なリクエストを行い、さらにそれを再度キャッシュすることで、ハードディスクの容量を消費してしまいます。 ## キャッシュ分離 ## AI モデルリソースの提供 デフォルトでは、**AI モデルリソース**は [Hugging Face Hub](https://huggingface.co/docs/hub/en/models-the-hub) から、最終的には Hugging Face CDN から提供されます。ブラウザは [https://huggingface.co/Xenova/distilbert-base-uncased-finetuned-sst-2-english/resolve/main/config.json](https://huggingface.co/Xenova/distilbert-base-uncased-finetuned-sst-2-english/resolve/main/config.json) のようなリソースに対してリクエストを送信しますが、これは最終的に CDN URL である [https://huggingface.co/api/resolve-cache/models/Xenova/distilbert-base-uncased-finetuned-sst-2-english/0b6928efcb76139cae2c6881d49cda67fe119f42/config.json?%2FXenova%2Fdistilbert-base-uncased-finetuned-sst-2-english%2Fresolve%2Fmain%2Fconfig.json=&etag=%223c36342ef1f74de2797d667c68c6b7b988d0b87c%22](https://huggingface.co/api/resolve-cache/models/Xenova/distilbert-base-uncased-finetuned-sst-2-english/0b6928efcb76139cae2c6881d49cda67fe119f42/config.json?%2FXenova%2Fdistilbert-base-uncased-finetuned-sst-2-english%2Fresolve%2Fmain%2Fconfig.json=&etag=%223c36342ef1f74de2797d667c68c6b7b988d0b87c%22) へリダイレクトされます（本ケースの場合）。 ## Wasm ランタイムリソースの提供 **Wasm ランタイムリソース**は、デフォルトでは [jsDelivr CDN](https://www.jsdelivr.com/) から提供されます。例えば、執筆時点では `ort-wasm-simd-threaded.asyncify.wasm` は [https://cdn.jsdelivr.net/npm/onnxruntime-web@1.26.0-dev.20260416-b7804b056c/dist/ort-wasm-simd-threaded.asyncify.wasm](https://cdn.jsdelivr.net/npm/onnxruntime-web@1.26.0-dev.20260416-b7804b056c/dist/ort-wasm-simd-threaded.asyncify.wasm) から取得されます。 ここで、異なるオリジンで実行されているアプリであっても、最終的に同じ CDN URL からリソースを提供しているなら、キャッシュは問題ないはずだと考えるかもしれません。しかし残念ながら、これはブラウザにおけるキャッシュの仕組みが長年採用されてきた方法ではありません。[Gaining security and privacy by partitioning the cache](https://developer.chrome.com/blog/http-cache-partitioning) という記事で詳細が説明されていますが、本質的には**キャッシュはオリジンごとに分離**されており、タイミング攻撃（timing attacks）を防ぐためです：Web サイトが HTTP リクエストに応答するまでの時間が、ブラウザが過去に同じリソースにアクセスしたことがあるかどうかを露呈し、それがセキュリティやプライバシーの漏洩につながる脆弱性となるからです。 ## Chrome の実装 具体的な実装はブラウザによって異なりますが、Chrome ではキャッシュされたリソースは**リソース URL**に加えて、ネットワーク分離キーを使用してキー付けされます。ネットワーク分離キーは**トップレベルサイト**と**現在のフレームサイト**で構成されます。https://googlechrome.github.io および https://rawcdn.rawgit.net にホストされていた先ほどの玩具例を考えてみましょう。これらがどちらも https://cdn.jsdelivr.net/npm/onnxruntime-web@1.26.0-dev.20260416-b7804b056c/dist/ort-wasm-simd-threaded.asyncify.wasm から Wasm ランタイムを使用している場合、そのキャッシュキーは以下の表のようになります。 Network Isolation Key **Resource URL** **Top-level site** **Current-frame site** https://googlechrome.github.io https://googlechrome.github.io https://cdn.jsdelivr.net/npm/onnxruntime-web@1.26.0-dev.20260416-b7804b056c/dist/ort-wasm-simd-threaded.asyncify.wasm https://rawcdn.rawgit.net https://rawcdn.rawgit.net https://cdn.jsdelivr.net/npm/onnxruntime-web@1.26.0-dev.20260416-b7804b056c/dist/ort-wasm-simd-threaded.asyncify.wasm したがって、リソース URL が完全に一致していても、ネットワーク分離キーが一致しないためキャッシュヒットせず、結果として重複ダウンロードと重複ストレージが発生します。これがクロスオリジンストレージ提案が目指す課題です。 ## クロスオリジンストレージ API の登場 **💡 注意:** Cross-Origin Storage API はまだ初期段階の提案であり、確定した仕様ではありません。提案された API はいまだどのブラウザでもネイティブ実装されていませんが、それを待たずに実験を開始することも可能です。[Cross-Origin Storage 拡張機能](https://chromewebstore.google.com/detail/cross-origin-storage/denpnpcgjgikjpoglpjefakmdcbmlgih) をインストールして、すべてのページに `navigator.crossOriginStorage` のポリフィルを注入し、完全なフローをテストしてください。 提案されている **[Cross-Origin Storage](https://github.com/WICG/cross-origin-storage) (COS) API** は、Web アプリが URL ではなく暗号化ハッシュによって識別される大規模ファイルを、オリジン境界を超えて保存および取得できる専用の `navigator.crossOriginStorage` インターフェイスを導入します。 ![image](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/cross-origin-storage/klwb5fryaa.png) この最後の点である「暗号化ハッシュ」が鍵となります。COS はファイルを URL やオリジンではなく、その**ハッシュ値**によって識別するため、`https://googlechrome.github.io` を訪問中にダウンロードした `ort-wasm-simd-threaded.asyncify.wasm` Wasm ランタイムは、`https://rawcdn.rawgit.net` がこれから要求しようとしているものとも同一と認識されます。どちらのオリジンから取得されたかに関わらずです。以下のコードスニペットは基本的なフローを示しています。 ```const hash = { algorithm: 'SHA-256', value: '8f434346648f6b96df89dda901c5176b10a6d83961dd3c1ac88b59b2dc327aa4', };``` try { const handle = await navigator.crossOriginStorage.requestFileHandle(hash); // Cache hit! Get the file as a Blob and use it directly. const fileBlob = await handle.getFile(); } catch (err) { // Cache miss. Download from network, then store for next time. const fileBlob = await fetch('https://cdn.jsdelivr.net/.../ort-wasm-simd-threaded.asyncify.wasm') .then(r => r.blob()); const handle = await navigator.crossOriginStorage.requestFileHandle( hash, { create: true, origins: '*' }, ); const writableStream = await handle.createWritable(); await writableStream.write(fileBlob); await writableStream.close(); } リソースがクロスオリジンストレージ (COS) に存在する場合は、[FileSystemFileHandle](https://developer.mozilla.org/en-US/docs/Web/API/FileSystemFileHandle) が返され、そこから [getFile()](https://developer.mozilla.org/en-US/docs/Web/API/FileSystemFileHandle/getFile) を介して直接 Blob として読み込むことができます（結果得られる [File](https://developer.mozilla.org/en-US/docs/Web/API/File) は [Blob](https://developer.mozilla.org/en-US/docs/Web/API/Blob) から継承されます）。リソースが COS に存在しない場合は、ネットワークからフォールバックし、そのリソースを COS へ書き込みます。これにより、次回の必要時に（あなたのアプリである場合もあれば、全く異なるオリジン上の別の無関係なアプリである場合も含め）再利用可能になります。 この API は、おそらく [Origin Private File System](https://developer.mozilla.org/en-US/docs/Web/API/File_System_API/Origin_private_file_system) (OPFS) API からご存知の [FileSystemDirectoryHandle.getFileHandle()](https://developer.mozilla.org/en-US/docs/Web/API/FileSystemDirectoryHandle/getFileHandle) 関数（[File System Standard](https://fs.spec.whatwg.org/) に基づく）を意識して設計されています。ハッシュパラメータは、OPFS における名前のパラメータと同じ役割を果たし、リソースを一意に識別します。options.create フラグも同様に機能し、読み取り専用アクセスの場合は省略または false、書き込みを行う場合は true と設定されます。 ## 誰が何を閲覧できるかを制御する すべてのリソースをグローバルに共有する必要はありません。COS では、ファイルを保存する際に origins オプションを通じて、開発者が可視性を精密に制御できます。 - origins: '*' を設定すると、ファイルはグローバルに利用可能になります。任意のオリジンがハッシュによってそのファイルを検出できます。これは、Web 上のすべてのアプリが単一のキャッシュコピーから恩恵を受けることを目的とした AI モデルリソースや、Transformers.js の例における Wasm ランタイムにとって適切な選択肢です。 - origins: ['https://write.example.com', 'https://calculate.example.com'] のように特定のオリジンのリストを渡すことで、アクセスを指定されたサイトのみへ制限できます。これは、他者には発見されないことが望ましい、自社ドメイン間で共有される独自リソース（例えば、商用オフィススイートで使用される独自の校正 AI モデルなど）に対して効果的に機能します。 - オリジンを完全に省略すると、ファイルは同じサイトのオリジンのみが利用可能になります。これは組織内のすべてのサブドメイン間で共有されるリソースに対する合理的なデフォルトですが、組織の境界を越えて利用することを意図したものではありません。 重要なルールとして、可視性はアップグレードすることはできますが、ダウングレードすることはできません。ファイルがすでにグローバルに公開されている場合、後から制限されたオリジンリストで保存しようとする試みは静かに無視されます。これにより、悪意のあるアクターがパブリックリソースを再保存してその利用範囲を狭めることが防止されます。逆のケースも可能です：最初に制限されたオリジンリストで保存されたファイルは、後からより寛容な設定にアップグレードできます。元の保存者だけでなく、任意のサイトが同じハッシュ（ハッシュは秘密ではありません）に対して `create: true` とより広いオリジン値を指定して `requestFileHandle()` を呼び出すことができ、ブラウザがハッシュが一致することを確認すれば、その時点からリソースはより広い聴衆に利用可能になります。ただし、アップグレードを行うサイトは**必ず**返されたハンドルを通じてファイル全体を書き込む必要があります。この要件は、サイトがアップグレード経路を悪用して特定のファイルが既に COS に保存されているかどうかを検出するサイドチャネルとして利用することを防ぐために存在します。 ## デザインによる整合性保証 COS の微妙だが重要な性質の一つは、ブラウザがファイルの書き込み時に**ハッシュを検証する**ことです。書き込むデータが宣言されたハッシュと一致しない場合、書き込みはエラーで失敗します。これにより整合性チェックが自動的に行われ、COS からファイルを読み取るアプリケーションは、期待したバイト列を正確に取得できていることを確信できます。これは、ネットワークダウンロード後に自分でハッシュを計算した場合と同じ保証を得られることになります。 この仕組みは Transformers.js のシナリオにおいて二重に有用であることがわかりました。現在、モデルの重みをダウンロードした後、ほとんどのアプリケーションには、CDN が正しいバイト列を提供したことを実用的に検証する方法がありません。COS を使用すれば、ストア内のすべてのファイルは書き込み時に暗黙的に検証され、その出所が公式の Hugging Face CDN であってもランダムなサイトのセルフホストミラーであっても関係ありません。 ## プライバシーを犠牲にせずユーティリティを維持する もちろん、クロスオリジンの共有キャッシュは、パーティション化された HTTP キャッシュとは逆の同じ疑問を提起します：どのサイトでもハッシュによってファイルの存在を検索できるなら、攻撃者がゲームエンジン Wasm モジュールがキャッシュされているかどうかを確認することで、ユーザーの閲覧履歴について何かを学習できてしまうのではないか？ COS はこの問題に対し、2 つの補完的なメカニズムで対応しています。 - 第一に、origins フィールドです：グローバルに検索可能にしてはならない独自リソースは、origin: '*' で保存すべきではありません。これは開発者教育を通じて、適切な場合に常に検討するよう開発者に促されています。 - 第二に、可用性ゲート機能です。グローバルに宣言されたファイルであっても、ブラウザは十分な数の異なるオリジンでそのファイルが検出されていない場合、ファイルの存在を確認するのを抑制することがあります。1 つまたは 2 サイトでのみ出現するファイルはクロスサイト識別子として機能し得るため、物理的にディスク上に何があるかに関わらず、ブラウザはそのファイルを存在しないものとして扱うエラーを返す可能性があります。Chrome チームでは、稀なリソースが引き起こす可能性のあるプライバシー漏洩を意識しており、キャッシュできる正確なリソースを制限することでこれを緩和する計画を立てています。具体的な緩和策はまだ詳細化されている段階です。 重要なのは、これはエラーが決定論的な答えではないということです。「保存されていない」ことを意味する場合もあれば、「保存されているがブラウザはそれを教えてくれない」ことを意味する場合もあります。アプリケーションは常に同じ方法で対処すべきであり、ネットワークへのフォールバックを行う必要があります。 ## Transformers.js の例におけるこの意味 以前のおもちゃの例に戻りましょう：ort-wasm-simd-threaded.asyncify.wasm ランタイムは 4,733 kB のサイズで、使用する AI モデルに関わらず、Transformers.js を搭載したすべてのアプリによって共有されます。COS（Cross-Origin Storage）を使用すると、最初にロードするアプリが一度だけダウンロードし、SHA-256 ハッシュ値をキーとして「origin: '*'」の条件で保存します。その後、https://googlechrome.github.io 上にあるか、https://rawcdn.rawgit.net 上にあるか、あるいは他のオリジンにあるかに関わらず、すべてのアプリが COS から即座にそのリソースを検出できます。重複する Whisper モデルの重みデータ 177 MB も同じ仕組みです：Xenova/whisper-tiny.en は一度だけダウンロードされ、2 回目のアクセス時にハッシュで認識され、COS からミリ秒単位で提供されます。もちろん、Xenova/distilbert-base-uncased-finetuned-sst-2-english についても同様のことが起こります。 Transformers.js 自体もすでにライブラリレベルで COS API のパイロット運用を行っています。[Pull request #1549](https://github.com/huggingface/transformers.js/pull/1549) は、オプトインフラグの背後に実験的な COS キャッシュバックエンドを導入しました。これを有効にするには、パイプラインを設定する前に単一の行を追加するだけです。 import { env, pipeline } from "https://cdn.jsdelivr.net/npm/@huggingface/transformers@4.2.0"; // 👇 実験的な Cross-Origin Storage キャッシュバックエンドをオプトインします。 env.experimental_useCrossOriginStorage = true; const asr = await pipeline('automatic-speech-recognition', 'Xenova/whisper-tiny.en', { device: 'webgpu' }); const result = await asr('jfk.wav'); console.log(result); このフラグを設定すると、Transformers.js は各 [Xet-tracked](https://huggingface.co/docs/hub/en/xet/index) モデルファイル（大規模な ONNX 重みファイル）の SHA-256 ハッシュを解決するために、生の Xet ポインタ（[例：生ポインタファイル](https://huggingface.co/Xenova/whisper-tiny.en/raw/main/onnx/decoder_model.onnx)）を取得し、その oid sha256: フィールドから抽出します。その後、このハッシュを navigator.crossOriginStorage のキーとして使用します。モデルがすでに COS（Cross-Origin Storage）に存在する場合（別のサイトが先にそこに保存した場合）、ネットワーク往復なしですぐに提供されます。もし存在しない場合は、通常のダウンロードにフォールバックし、その結果を次の呼び出しのために COS に保存します。この玩具例では、実用上の利点は、Xenova/whisper-tiny.en および Xenova/distilbert-base-uncased-finetuned-sst-2-english（もちろん ort-wasm-simd-threaded.asyncify.wasm も）が、異なるオリジンからどれだけ要求されても、一度だけ通信経路を跨げば済む点にあります。 フラグの接頭辞に experimental_ が付いている点にご注意ください。これは意図的なもので、基盤となるブラウザ API がまだ標準化されていないこと、およびメジャーバージョンアップなしに変更される可能性があることを示しています。 ## 今日から試す COS API はまだどのブラウザでもネイティブ実装されていませんが、それを待たずに実験することは可能です。[Cross-Origin Storage 拡張機能](https://chromewebstore.google.com/detail/cross-origin-storage/denpnpcgjgikjpoglpjefakmdcbmlgih) をインストールして、すべてのページに `navigator.crossOriginStorage` のポリフィル（互換性実装）を注入し、完全なフローをテストしてください。[拡張機能のソースコード](https://github.com/web-ai-community/cross-origin-storage-extension) を閲覧したり、[利用手順](https://github.com/web-ai-community/cross-origin-storage-extension?tab=readme-ov-file#usage) に従ったりして、すぐに始められます。 拡張機能をインストールしたら、すぐに完全なエンドツーエンドの体験を試すことができます。まず、COS 有効化された最初の [トイ例 (toy example)](https://googlechrome.github.io/samples/transformersjs-automatic-speech-recognition/index3.html) を開き、Xenova/whisper-tiny.en の読み込みを待ちます。次に、2 つ目のオリジンからの COS 有効化された [トイ例](https://rawcdn.rawgit.net/GoogleChrome/samples/1e4f2b8c10adc394352c6ec8327bb503bac7aba1/transformersjs-automatic-speech-recognition/index3.html) を開きます。以前見た 177 MB の再ダウンロードの代わりに、モデルは COS (Cross-Origin Storage API) からミリ秒単位で提供されます。拡張機能のポップアップウィンドウを開くと、COS が動作している様子を確認できます。**リソース別表示**を選択すると、SHA-256 ハッシュが 950978b1dbcbf250335358c1236053ba19a7f7849b33dc777f4421b72b7626fa のリソースが、https://googlechrome.github.io と https://rawcdn.rawgit.net の両方で共有されているのがわかります。これは直感的にはわかりにくいかもしれませんが、Hugging Face 上の SHA-256 ハッシュと比較して確認できる通り、[https://huggingface.co/Xenova/whisper-tiny.en/blob/main/onnx/decoder_model_merged.onnx](https://huggingface.co/Xenova/whisper-tiny.en/blob/main/onnx/decoder_model_merged.onnx) を見ていることになります。現時点では、この拡張機能はあなたのようなパワーユーザー向けに主に設計されています。ブラウザに実装されれば、ブラウザの**設定**ページでより親しみやすい統合が行われるようになります。以下のスクリーンショットは、**リソース別表示**タブがアクティブな状態の拡張機能ポップアップウィンドウを示しており、共有されているリソースとそのハッシュ値、さらにそのリソースを COS キャッシュに保持している 2 つのオリジンを確認できます。 ## 呼びかけ Transformers.js アプリを自作されている場合は、呼びかけはシンプルです。最初の pipeline() 呼び出しの前に env.experimental_useCrossOriginStorage = true を設定し、拡張機能をインストールして、ネットワークタブから重複するダウンロードが消える様子をご覧ください。各サイトが参加することで、他のすべてのサイトのユーザーにとって体験がより高速かつ低コストになります。参加は完全にリスクフリーです：COS API がユーザーに COS 拡張機能がインストールされていないためにサポートされない場合、コードはデフォルトのパス（[Web Cache](https://developer.mozilla.org/en-US/docs/Web/API/Cache) API）に自動的にフォールバックします。 Transformers.js は COS の実験を独りで行っているわけではありません。[WebLLM](https://webllm.mlc.ai/)（オプトイン方式、詳細は [ドキュメント](https://webllm.mlc.ai/docs/user/advanced_usage.html#using-cross-origin-storage-cache) を参照）や [wllama](https://github.com/ngxson/wllama)（自動実行、詳細は [PR](https://github.com/ngxson/wllama/pull/248) を参照）も、この提案された API に大きな期待を寄せています。 Chrome チームでは、[COS API のネイティブ実装を検討しています](https://chromestatus.com/feature/5163371507875840)。これはまだ初期段階の提案ですので、API 自体やその提案の形状についてのご意見をお待ちしています。不具合報告は [Cross-Origin Storage リポジトリ](https://github.com/WICG/cross-origin-storage) で行い、[サポート表明](https://github.com/WICG/cross-origin-storage/labels/expression%20of%20support) を行うか、PR を作成することも可能です。

Transformers.js で提案されたクロスオリジンストレージ API の実験

背景や根拠まで確認しますか？

このニュースを、実務の判断につなげる

調べる

選ぶ

サイト