WHY NO-SEND
なぜ「送らない」設計を選んだのか
オンラインツール市場の主流はアップロード型ですが、本サイトはあえてその逆を取りました。設計の根拠と、そこから派生する利点・制約を整理します。
アップロード型に残る、検証不可能な信頼問題
オンラインの変換・編集サービスの大半は、ファイルやテキストを一度サーバーに送って処理する設計です。多くの利用規約には「アップロード後すぐに削除します」と書かれており、運営者が誠実にそれを履行しているケースもあるでしょう。ただ、利用者側から「本当に削除された」「ログに残らなかった」「学習データに使われていない」を後から検証する手段はありません。
つまりアップロード型は、運営者の善意を「信用するしかない」という構造を内包しています。社外秘の契約書、未発表の音声原稿、撮影位置入りの写真、本番環境の JWT — これらが学習データやテスト用サンプルとして二次利用されると困るデータを扱うとき、検証不可能な信頼は使いどころが難しい資源です。
送らない設計が成立する技術的タイミング
10 年前まで、動画変換・PDF 編集・大きな画像から EXIF を読む、といった操作はサーバーに重い処理を任せるのが当然でした。WebAssembly (2017 年に主要ブラウザで安定) と、ffmpeg.wasm・libheif-js・pdf-lib・PDF.js・kuromoji.js・transformers.js といった対応ライブラリの整備により、2020 年代に入ってから「これらをすべてブラウザで動かす」が現実的なコストで可能になりました。
「ブラウザ内で完結 = 遅い・機能制限が多い」という従来の前提は、もはや成立しません。WebAssembly のおかげで、デスクトップアプリと同等の機能を、インストール不要のオンラインツールとして配信できます。NoSend Tools はこの技術タイミングの上に立っています。
ユーザー体験としての副次効果
「送らない」を構造として徹底すると、副次的な利点が複数立ち上がります。アカウント登録が要らない (送信先がないので識別の必要がない)、ファイルサイズに「サーバー上限」が無い (端末メモリだけが制約)、オフラインでも動くツールが多い (初回キャッシュ後は再ダウンロード不要)、機密データを扱う組織の社内ポリシーに抵触しない (外部送信が無い)、といった点です。
結果として、業務・私生活の両方で「アップロードを避けたい場面」のデフォルト動線になることを狙っています。送信を構造的に排除した側に、自然と用途が集まる設計です。
制約も明示しておく
送らない設計には制約もあります。OCR / 文字起こし / 背景除去のような ML モデルを使うツールは、モデル本体 (数十〜数百 MB) を一度ダウンロードする必要があり、初回起動が遅くなります。動画変換は端末の CPU で行うため、サーバー側で行うサービスより処理時間がかかります。協調編集 (同じ PDF を複数人で編集する) のような機能は提供できません。
これらの制約と引き換えに、入力データの送信を構造的に排除できます。「送信を許容する代わりに速度を取る」か「速度を犠牲にしてでも送信を排除する」かの選択を、サイトとして後者に倒している、というのが NoSend Tools の立ち位置です。