アップロード型サービスに残る、構造的なリスク
「アップロード後すぐに削除します」と書かれていても、ネットワーク経由でデータが運営者の管理下に渡る時点で、ユーザー側からは検証できないリスクが残ります。NoSend Tools がそもそも送信しない設計を選んだ理由を、構造の側から説明します。
「すぐに削除します」と「送られなかった」は別の話
オンラインで画像から EXIF を消す、PDF を結合する、テキストを Base64 にする — こうした作業の多くは、いまも「ファイルを一度サーバーに送って処理し、結果を返す」型のサイトで行われています。多くのサービスは利用規約に「アップロードされたファイルは一定時間後に自動削除します」と明記しており、それは本当に運用されているケースもあるでしょう。
ただ、利用者側から見ると、「削除された」ことを後から検証する手段はありません。経路上には CDN や WAF のキャッシュ、デバッグ用に保存されたエラーログ、リバースプロキシの一時バッファ、運営者のアクセスログがあり、送信した時点でデータはあなたの手から複数の場所に枝分かれします。事業者が善意で運用していても、データを構造として手放してしまった以上、ユーザー側に検証手段がないことが本質的な非対称性です。
利用規約の本文に「学習・改善のため利用することがあります」
もう 1 段見落としやすいのが、無料サービスの利用規約に含まれる「品質向上のため、アップロードされたデータを匿名化したうえで内部で利用することがあります」といった条項です。同意した時点で、ユーザーは運営者に「データを処理目的以外で使う権利」を渡しています。
社外秘の契約書、未発表の音声原稿、撮影位置付きの写真、本番環境の JWT — これらが学習データやテスト用サンプルとして二次利用されると困るデータは、規約の条項ひとつで「ユーザーの意図しない用途」に流れる可能性があります。
「送信されなかった」を後から確かめられる設計
NoSend Tools は、入力データを送信する経路を構造として持っていません。WebAssembly に取り込んだ ffmpeg や pdf-lib、ブラウザ標準の Web Crypto / Web Audio API などをページ側のコードから直接呼び出して、ブラウザのメモリ内で処理を完結させます。
「送らない」と書かれているだけの状態と、「送る経路自体がコードに存在しない」状態は、利用者にとって意味が違います。気になるツールのページで DevTools を開き、Network タブを記録状態にしたまま入力 → 実行 → 結果取得を行い、リクエストが 0 件のままであることを目視できます。さらにサイト全体のソースコードは GitHub に公開しているので、実装側からも監査できます。