2026-08-17 公開 ／ Webツール

Webツールを20本以上、原則ブラウザの中だけで動かしている理由と、例外を1つ残した判断

PDFを結合する、画像から色を抜き出す、CSVを整形する、EXIFを見る。こういうツールを20本以上公開していますが、原則としてファイルをサーバーに送っていません。ブラウザの中で処理して終わります。この設計を選んだ理由、そのために諦めたもの、そして例外を1つだけ残している話を書きます。

なぜ送らないことにしたか

1. 扱うファイルの中身が、だいたい他人に見せられないものだから

ツールの性質を並べると分かりやすいです。PDFを結合したい人が持っているのは契約書や請求書です。レシートを集計したい人のデータは家計です。EXIFを確認したい写真には撮影場所が入っています。QRコードにしたいURLには、限定公開のつもりで発行した共有リンクが混ざります。

「便利だけど、これをどこかのサーバーに上げるのはちょっと」という気持ちが、そのまま使われない理由になります。送らない設計だと、その説明そのものが不要になります。プライバシーポリシーで「適切に管理します」と書くより、「送っていません」のほうが短くて強い。

2. 預かると、預かった責任が発生するから

個人で運用していて怖いのは、漏らすことよりも「漏れていないことを証明できない」状態です。サーバーに置いた瞬間、保存期間、削除の確実性、バックアップに残っていないか、ログに残っていないかを全部説明できないといけません。

受け取らなければ、その説明が丸ごと消えます。個人開発で自分の首を絞めない設計としては、これがいちばん効きました。

3. 速いし、登録が要らない

アップロードと結果待ちが無いので、開いてすぐ使えます。ログインも要りません。「1回だけ使いたい」という用途にはこれが合っています。

その代わりに諦めたこと

ここが本題です。この設計はきれいですが、引き換えに失うものがはっきりあります。やってみるまで想像していませんでした。

1. 誰が使ったのか、まったく分からない

アカウントが無く、処理をサーバーで受けていないので、どのツールがどう使われたかの手がかりがほぼ残りません。「PDF結合を使った人が、次にどのツールを見たか」も分かりません。

結果として、次に何を作るべきかの判断材料が手元に無い状態で20本以上作ることになりました。これは効きます。改善のネタが「自分が使って不便だったところ」に限られるので、自分の用途から離れた需要には気づけません。

2. リピーターに連絡する手段がゼロ

メールアドレスもアカウントも持たないので、機能を追加しても、以前使ってくれた人に伝える方法がありません。毎回、はじめて来た人にしか届きません。

ブラウザ完結の設計は「一度きりで使える」ことを最大の長所にしていますが、その長所は「一度きりで終わる」と同じ意味でもありました。

3. 重い処理は端末の性能に引きずられる

サーバーで処理すればどの端末でも同じ速度ですが、ブラウザ内で処理すると使う人の端末の性能がそのまま出ます。動画の分割やPDFの大量結合では、古いスマートフォンだと明確に遅い、あるいはメモリ不足で落ちます。

これは「サーバーに送らない」という約束を守る限り、原理的に解決しません。できるのは、処理の単位を小さく刻む、進捗を出す、無理なサイズを先に知らせる、といったごまかしの工夫までです。

4. ブラウザの実装差がそのまま不具合になる

処理を全部ブラウザに任せているので、ブラウザやOSの差がそのまま動作の差になります。特定の動画形式が分割できない、といった不具合は実際に出ました。サーバー側なら1箇所直せば全員に効きますが、ブラウザ内だと「どの環境で起きるか」を切り分ける工程が毎回入ります。

例外を1つ残している：Officeファイルの変換

ここまで「送っていない」と書いてきましたが、1箇所だけ例外があります。PDF結合ツールで Word・Excel・PowerPoint を投入したときの、PDFへの変換処理です。これはブラウザ内では行わず、ファイルをサーバーへ送って変換し、結果を返しています。

理由は単純で、Officeの文書形式をブラウザだけで正確にPDF化するのが現実的でないからです。レイアウト、フォント、埋め込みオブジェクトを再現しようとすると、ブラウザ内で完結させる方式では実用的な品質になりませんでした。「送らない」を守るならこの機能を作らないという選択になります。

私は機能を作るほうを選びました。そのうえで、投入する前に画面上でそのことを明示するという条件をつけています。PDFと画像は端末内で処理し、Officeファイルだけは変換のためにサーバーを通る、という区別をその場で読めるようにしています。

教訓として残しているのは、「送らない」を売り文句にするなら、例外を1つ作った時点で全部の説明文を数えて直す必要があるということです。プライバシーに関する説明は、他の機能説明と違って間違っていること自体が損害になります。「だいたい送っていません」は説明として成立しません。

それでもこの設計を続けている理由

諦めたものを並べたうえで、まだ続けています。理由は、上の4つが全部あとから足せるのに対して、送らない約束はあとから戻せないからです。

アクセス解析や連絡手段は、必要になった時点で追加できます。処理速度も、端末が新しくなれば勝手に改善します。でも「一度サーバーに送る設計にしたあと、送らない設計に戻す」のは、実質的に作り直しです。そして送っていた期間のデータの説明責任は残ります。

あとから足せるものは後回しにして、あとから戻せないものを先に決める。これがこの件で得た判断の型でした。

持ち帰れること

• 扱うデータの機微さで、まず設計を決める。機能から決めると、途中でサーバー処理に手が伸びます
• 「送らない」を選ぶなら、利用状況が見えないことを最初から前提に置く。あとで「データが無いから判断できない」と気づくと、それまでに作ったものの評価ができません
• あとから戻せない決定を先に、あとから足せる決定を後に。迷ったらこの順に並べ替えると、判断がだいぶ軽くなります
• 例外を作ったら、その原則を書いた文を全部数えて直す。概要文・OGP・構造化データ・本文と、同じ主張が何箇所にも複製されています。1箇所だけ直すと、残りが嘘として生き続けます

ちなみに私は2つめを前提に置いていませんでした。20本以上作ってから「使われ方が分からない」ことに気づいたので、この記事はその反省でもあります。