オンラインツールを使うとき、あなたのファイルは実際どこへ行くのか
公開日 2026-07-20
どの「無料オンラインツール」のページも見た目は同じです。親しみやすいドロップゾーン、ボタン、ダウンロード。しかしその間で実際に何が起きているかによって、このカテゴリ全体は二つに分かれます。あるツールはファイルをサーバーにアップロードしてそこで処理します。別のツールはすべての処理をブラウザタブ内で行い、ファイルは端末から一切出ていきません。ページの見た目はどちらも同じなので、ここではその見分け方と、それぞれの方式が実際に正当と言えるのはどんな場合かを説明します。
2つのアーキテクチャ
アップロード型のツールは、あなたのファイルをネットワーク経由で企業のサーバーへ送り、そこで処理を行い、結果を送り返します。一方クライアントサイドのツールはコードをダウンロードします。JavaScriptと、そして年々増えているのが、本物のライブラリ（PDFエンジン、画像コーデック、さらにはffmpegまで）をWebAssemblyでビルドしたもので、それがタブ内で動作します。「ダウンロード」を押したとき、ブラウザはすでにメモリ上に構築済みのファイルを保存しているだけです。どちらのモデルも古くからありますが、この10年で変わったのは、WebAssemblyによってクライアントサイド側が本格的な処理をこなせるようになったことです。
「アップロードされた」が実際に意味すること
いったんファイルがアップロードされると、それはあなたが制御できないインフラ上に存在することになります。そのサービスは1時間後に削除すると約束するかもしれませんし、評判の良いサービスの多くは実際にそれを守りますが、その約束は外部から検証することができません。ストレージ、バックアップ、ログ、あるいはサーバーが置かれている法域を監査することはできないのです。アップロードされたすべてのファイルは、侵害の対象にもなります。そのサービス自体が侵害されれば、その時点でそこにあるものはすべて侵害されるからです。だからといってアップロード型サービスが悪意あるものだというわけではありません。それを使うという行為自体が一種の信頼の行使であり、賢明な問いは、そのファイルがその信頼に値するかどうかです。ミーム画像なら、もちろん問題ありません。しかし、署名済みの契約書、医療記録、パスポートのスキャンとなると、話は別です。
鍵マークが表すのは通信経路であって、行き先ではない
よくある誤解はHTTPSの鍵マークです。TLSはブラウザとサーバーの間の接続を暗号化するため、転送中に途中の誰かがファイルを読み取ることはできません。しかし、到着後に何が起きるかについては何も語っていません。HTTPS経由のアップロードも、やはりアップロードです。サーバーはあなたのファイルを復号して処理します。あたかも直接手渡したかのように。その先を左右するのは鍵マークではなく保持ポリシーであり、そもそも鍵マークはまともなアップロード型サイトならどこにでも表示されます。「安全な接続」と「ファイルが端末に留まる」は、まったく無関係な主張です。
2分で自分で確認する
どのサイトの言葉も鵜呑みにする必要はありません。このサイトも例外ではありません。ブラウザのDevTools（F12）を開き、Networkタブに切り替え、内容をクリアしてから、そのツールでファイルを処理してみてください。ペイロードサイズがおおよそあなたのファイルと一致するPOSTやPUTリクエストがないか確認します。20MBのPDFが20MBのリクエストを発生させたなら、マーケティング文句が何と言おうと、それはアップロードされたということです。本物のクライアントサイドツールはそのようなリクエストを一切見せません。通常見えるのは、バイト単位で測られる程度の小さなアナリティクスの通信だけです。
2つ目のテストはさらに簡単です。ツールのページを読み込み、インターネットを切断し（機内モードでも構いません）、それからファイルを処理してみてください。クライアントサイドのツールは動き続けます。必要なものはすべてページと一緒にすでに届いているからです。アップロード型のツールは即座に失敗します。noritoのすべてのツールはこの両方のテストに合格しており、仕組みのページにそのアーキテクチャが記載されています。気になる方は、今すぐPDFを結合に対してこのNetworkタブのチェックを試してみてください。
このチェックをより確実にする2つの工夫があります。まず、実際に使う一連の流れを最初から最後まで実行してみてください。あるツールがローカルで処理していても、共有ボタンやクラウド保存ボタンを押した瞬間にアップロードすることがあるためです。次に、初回アクセス時にクライアントサイドのツールが数メガバイト程度のJavaScriptやWebAssemblyを正当にダウンロードすることがあります。処理エンジンがあなたの端末に届いているのです。その通信はあなたに向かって流れているのであって、あなたから流れ出ているのではなく、その方向はリクエスト一覧を見れば一目瞭然です。
アップロードなしでも漏れる可能性があるもの
クライアントサイド処理はプライバシーのフォースフィールドではなく、その隙間について正確に理解しておく価値があります。ファイルの中身がローカルに留まっていても、アナリティクススクリプトがメタデータを送信することはあります。ファイル名、サイズ、使用した機能などです。出力ファイルには、入力から引き継がれた機密性の高いメタデータが含まれることもあります。典型例は写真で、GPS座標を含むEXIFデータはほとんどの編集操作を経ても残るため、専用のメタデータ削除ツールが存在するのです。あなたがインストールしたブラウザ拡張機能は、そのページがどう作られていようと、どのページ上のどんな内容でも読み取ることができます。そして「クライアントサイド」という言葉は、そのサイトのコードが正直であるかどうかについては何も語りません。悪意あるページがローカルで処理しつつ、こっそりデータを外部に送信することも可能です。ここでのクライアントサイド処理は、プライバシーにとって必要条件ではあっても十分条件ではありません。検証可能性と評判の組み合わせこそが、本当の基準です。
サーバーが本当に必要な場合
タブ内で合理的に実行できないタスクも数多くあり、その点は公平に述べておくべきです。乱雑なスキャン画像に対する高精度OCRは、依然としてサーバーサイドのエンジンに分があります。TesseractはWebAssemblyにコンパイルされ動作はしますが、最も強力なモデルはブラウザ内では大きすぎて遅くなります。最新の背景除去や画像のアップスケーリングは、数百メガバイトに及ぶMLモデルに依存しています。長時間の動画トランスコードは、タブが許容できる時間内でこなせる範囲を超えますし、ブラウザタブの実用的なメモリ上限（一般的に2〜4GB）は、非常に大きなファイルをそもそも扱えなくします。共同作業を伴うものは、定義上サーバーを必要とします。つまり「アップロード＝悪」というのは単純化しすぎです。正しい問いは、そのタスクが本当にサーバーを必要とするかどうかです。日常的なケース——PDFの結合、画像の変換やリサイズ、パスワードやQRコードの生成——では、必要ありません。
妥当なデフォルトの姿勢
見知らぬ人にメールで送ることをためらうようなものについては、自分で実際にローカル処理であると確認済みのツールを選びましょう。あるタスクが本当にサーバーを必要とする場合は、明文化された保持ポリシーを持つプロバイダーを選び、アップロード前にファイルからメタデータを削除してください。そして2分間のDevToolsチェックを習慣にしてください。これは、ユーザー自身が直接検証できる数少ないプライバシー上の主張の一つであり、自分たちのアーキテクチャについて正直なサイトであれば、このチェックにも耐えられるはずです。