「完全ローカル処理」をどうやって確認している？ Browser Kittyの検証方法

Web版を開く通信と、処理対象データの送信は別

GitHub Pagesで公開しているツールは、最初にHTMLを取得するための通信があります。一方、配布用の単一HTMLに必要なランタイムを埋め込み、読み込み後の処理でユーザーファイルをサーバーへ送らない構成にできます。「ページを取得する通信」と「処理対象データを送信する通信」は分けて考えます。

また、「完全ローカル処理」と「どんな環境でも完全オフラインで全機能が使える」も同じではありません。Web Share、Web NFC、画面共有など、一部のWeb APIはHTTPSのSecure Contextやブラウザ・OSの対応を必要とします。HTTPSが必要だからといって、その処理がサーバー側で行われているとは限りません。

1. ファイルを選んだ後の処理経路を追う

最初に見るのは、ユーザーがファイルや文字列を渡したあと、そのデータがどこへ進むかです。ブラウザのFile APIでは、ユーザーが選んだFileをWebアプリ側で読み取れます。ファイル選択そのものはアップロードではなく、サーバーへ送るにはその後にfetch、XMLHttpRequest、フォーム送信など別の処理が必要です。

Browser Kittyでは、入力データがJavaScript、Web Worker、Wasm、Canvas、WebCodecsなど端末内の処理へ渡っているかを確認します。同時に、処理対象のBlobやArrayBuffer、文字列をネットワークAPIへ渡すコードがないかも確認します。「バックエンドがない」だけではなく、入力から出力までの経路を見るのが第一段階です。

2. 実行時の外部依存をなくす

ユーザーファイルをアップロードしなくても、動作中にCDNからJavaScriptを読み込んだり、WasmやAIモデルを外部URLから取得したりすれば、実行時通信は残ります。そのため単一HTML版では、可能な限り必要なJavaScript、Wasm、Worker、モデル、アイコンなどをHTML側へ含めます。

ここで大切なのは、「外部ライブラリを使っている」と「実行時に外部へ通信している」は別だという点です。FFmpegやDuckDB、PPTXレンダラーなどの外部ライブラリでも、ビルド時に取得・固定し、配布HTMLへ埋め込んで実行時に取りに行かなければ、ユーザー操作中のネットワーク依存はなくせます。逆に1ファイルに見えても、起動後にCDNやAPIへアクセスするなら完全な自己完結とは言えません。

3. CSPは「通信しないつもり」をブラウザ側でも制限するために使う

外部接続が不要なBrowser Kittyアプリでは、生成HTMLのCSPにconnect-src 'none'を設定する構成を多く使っています。connect-srcは、fetch、XMLHttpRequest、WebSocket、EventSource、sendBeaconなど、スクリプトから接続する代表的な経路を制限します。コードに意図しない通信処理が紛れた場合でも、ブラウザ側で止められる防波堤になります。

ただし、connect-src 'none'だけを見て「完全ローカル」と判定するわけではありません。CSPにはscript-src、img-src、font-srcなどリソース種別ごとの制御があり、フォーム送信にはform-actionもあります。外部スクリプト・フォント・画像・iframeなど別の経路が残っていないか、実際のCSPとHTMLを合わせて確認します。CSPは検証の代わりではなく、設計を守るための追加の制約です。

4. 実際に操作し、通信が発生しないかを見る

静的にコードを読んだだけでは、遅延読み込み、例外時だけ動く処理、ライブラリ内部の取得処理などを見落とす可能性があります。そのため、代表的なファイルを読み込み、解析・変換・プレビュー・保存まで一通り操作し、ブラウザのネットワーク記録に予期しない外部リクエストが出ていないかを確認します。

実際の確認では、初期読み込みが終わったら開発者ツールのNetwork（ネットワーク）記録をいったんクリアし、ファイル選択から保存まで主要な操作を実行します。その間に新しい外部リクエストが発生しないかを見ることで、「処理対象データを送っていないか」を確認します。

特にWasmやAIモデルは、最初の処理を始めた瞬間にだけ追加ファイルを取得する構成があります。Workerも外部URLから生成する設計なら、その時点で通信が発生します。最初の画面が表示された直後だけでなく、実際に主要機能を動かした状態で確認することが重要です。単一HTML版は、オフラインやfile://でも主要な処理経路を試し、「実行時に外部依存が残っていないか」を別の観点から確認します。

5. 保存・共有・印刷は「隠れたアップロード」と分けて考える

完全ローカル処理のツールでも、ユーザーが結果を外へ出す機能はあります。ファイルとして保存する、クリップボードへコピーする、印刷する、OSの共有シートへ渡す、NFCタグへ書き込む、といった操作です。これらは処理中にアプリが勝手にサーバーへアップロードすることとは意味が違います。

たとえばWeb Share APIは、ユーザー操作をきっかけにデータをOSの共有機構へ渡し、共有先はユーザーが選びます。そこでメールやメッセージアプリを選べば、その先では当然データが外部へ送られる可能性があります。Browser Kittyでは「アプリが処理のために外部送信しない」と「ユーザーが明示的に共有先へ渡す」を区別し、後者がある場合は機能説明や注意点に明記します。

localStorageやBlob URLも同様に、サーバー保存と同じものとして扱いません。localStorageはそのオリジンのブラウザ保存領域で、Blob URLはメモリ上のBlobなどをURLとして参照する仕組みです。ただし保存期間やfile://での挙動にはブラウザ差があるため、長期保存が必要なデータはファイルへ書き出す導線も用意します。

3つの実例：扱うデータが違っても確認するポイントは同じ

Browser Kittyでは、文字列だけを扱う小さなツールから、100万件規模の生成処理、PPTX・音声・動画・Wasmを組み合わせるツールまで、同じ考え方で「どこで処理するか」「実行時に何を取得するか」「どこへ出力するか」を確認しています。

「単一HTML」「バックエンドなし」「CSPあり」だけでは判定しない

検証を続けていると、「これがあれば完全ローカル」と言える単独の条件はないことが分かります。単一HTMLでも外部APIを呼べます。バックエンドを自前で持っていなくても、第三者APIへ送信できます。connect-src 'none'があっても、CSPの他の経路やユーザーが明示的に共有する機能は別に確認する必要があります。

逆に、Web版を最初に取得する通信がある、Secure Contextが必要、外部ライブラリを使っている、といった事実だけでローカル処理を否定するのも正確ではありません。Browser Kittyでは、配布形態のラベルではなく、実行時のデータ経路と実際の挙動を確認した結果として「完全ローカル処理」という表現を使います。

注意点

• 「完全ローカル処理」は「安全性をすべて保証する」という意味ではありません。ブラウザや端末の安全性、OS共有先、保存したファイルの扱いなどは別の問題です。
• サイト本体のアクセス解析と、各アプリがユーザーの処理対象データを送信するかどうかも分けて考えます。Browser Kittyではツール本体のアプリページに解析・広告コードを入れず、処理対象データを送らない構成を基本にしています。
• ローカル処理の説明はツールごとの実装に合わせます。Web ShareやNFC、カメラ・マイクなど例外的なデータの受け渡しがある場合は、まとめて「通信なし」と言い切らず、どこまでローカルかを説明します。