最初に書いておきます。検証対象の MoxiKit は筆者自身が開発しているツール集です。他人のサービスの粗探しではなく、「自分の実装が本当にそうなっているか」を確認する手順としてまとめました。
「サーバーに送らない」は、言葉ではなく検証できる
オンラインツールが「プライバシーに配慮」と書いていても、実際にファイルがどこへ行くかは宣伝文句では分かりません。確認方法は意外と単純です。
- DevTools の Network パネルを開いてファイルを処理する。処理中・処理後に、ファイル本体を含むリクエストが出ていなければ、少なくともその操作では送信されていません。FormData の中身まで見れば判定できます。
- オフラインにして試す。Network パネルで「Offline」にチェックを入れた状態でも処理が完結するなら、その処理は端末側で閉じています。サーバー必須の処理なら、ここで必ず止まります。
自分のサービス MoxiKit（PDF・画像・OCR・開発者向け小物の 46 ツール、https://moxikit.com/ja/?utm_source=qiita&utm_medium=post&utm_campaign=launch2026 ）は、この 2 つの検証を通ることを前提に設計しました。以下は、その実装で実際に踏んだ話のメモです。
実装の要点 3 つ
1. ファイルはメモリにだけ置く
File API で読み込んだ Blob をメモリ上で処理し、結果を Blob URL でダウンロードさせる。ストレージにもネットワークにも出さないのが基本形です。当たり前に見えて、画像プレビューや編集中の一時保存で localStorage / IndexedDB に逃がしたくなる場面が何度もありました。「端末内」と「ブラウザ内」も厳密には違うので、永続化する場合は明示する、が運用ルールです。
2. 重い処理は Web Worker へ、ただし転送コストを見る
PDF 圧縮や音声変換をメインスレッドで回すと UI が固まります。Worker 化自体は定石ですが、盲点はデータ転送です。大きな ArrayBuffer を構造化複製で渡すと、それだけで数百 ms〜数秒溶けます。Transferable（postMessage の第 2 引数で所有権を移す）に変えて初めて実用になりました。
3. AI 推論は ONNX Runtime Web、モデルはキャッシュ戦略が本体
OCR と背景除去は ONNX モデルをブラウザで推論しています。推論そのものより、モデルの配布が問題でした。
- 初回に数 MB〜数十 MB のモデルと言語データを落とす必要がある
- Cache Storage に入れて 2 回目以降を即時起動にする
- モデル更新時はバージョンをキーに含めないと、古いモデルが残り続ける（踏みました）
正直な限界
- 100MB 上限。Web 版の単一ファイル上限です。端末メモリがそのまま上限になるので、これ以上はタブごと落ちます。ネイティブ版は計画中ですが未公開です。
- 端末性能に素直に依存。古いマシンでの大規模 PDF の OCR は普通に遅いです。サーバー処理はこのコストを事業者が持つ方式で、ローカル処理はユーザー側に寄ります。どちらが正解という話ではありません。
- OCR の精度は条件次第。解像度・傾き・レイアウトに弱く、手書きは特に不安定です。
- 付随機能の注意点として、OCR 結果のマスキング（メール・電話番号・証明書番号などをパターンで置換）は漏れ・誤検出があり得るので、共有前の目視確認は必須にしています。
まとめ
「アップロードしない」は、Network パネルとオフライン検証で誰でも確かめられます。ツールを作る側としては、その検証に耐える実装（メモリ内処理、Worker + Transferable、モデルのキャッシュ設計）を揃えるのが本体でした。
他に「これは本当にローカルか？」を確かめる良い方法があれば、ぜひ教えてください。検証手順のコレクションとして育てたいと思っています。