すべての開発者は、オンラインフォーマッターにシークレットを貼り付けたことがある。APIキーを含む設定ファイル。チェックしたかったJWT。本番データに対してテストしたかった正規表現。オンラインツールはフォーマットし、結果を出力し、誰もがそのまま進んだ。問題は、そのシークレットが今や他の誰かのデータベースにあるということだ。
モダンブラウザランタイムは、開発ツールにおいてサーバーができることほぼすべてを実行できる。JavaScriptは高速だ。Web Crypto APIは堅牢だ。WASMにより、重いパース（YAML、JSON Schema、正規表現）もローカルで実行される。その結果、すべてをクライアントサイドで処理し、データをアップロードすることも、バックエンドを必要とすることもない、新しい世代の開発ツールが生まれた。
この投稿は、なぜそれが重要なのか、うまくいかないケース、そして違いを見分ける方法についてだ。
「クライアントサイド」とは何か
クライアントサイドツールとは、処理がサーバーではなくブラウザ内で実行されるツールのことだ。HTML、CSS、JavaScriptは一度だけダウンロードされる。それ以降のすべての操作はローカルで行われる。サーバーはもう関与しない。
JSONフォーマッターの場合：
<textarea>にJSONを貼り付ける。- ブラウザがパースし、フォーマットし、結果を表示する。
fetch呼び出しは行われない。APIエンドポイントはない。ログサービスはない。
JWTデコーダーの場合は：
- 3つのbase64セグメントがブラウザでデコードされる。
- 署名はローカルで実行されるコードで検証される（またはされない）。
- シークレットはマシンから出ない。
これはすべてのブラウザで自分で確認できる。DevTools → Networkを開き、操作を実行し、リクエストログを監視すればよい。真にクライアントサイドのツールは、入力データを含むリクエストがゼロであるはずだ。
開発ツールにとってなぜこれが優れているのか
プライバシー。 最も明白な利点。ツール提供者は、受け取っていないものを漏洩できない。存在しないログを召喚されることもない。データを持っていないので、データを売ることもない。
レイテンシー。 ネットワーク往復がない。100KBのJSONファイルをフォーマットするのは数ミリ秒だ。同じファイルをサーバーにアップロードし、フォーマットし、ダウンロードすると、調子が良い日でも200msかかることがある。一日に何十回も使うツールでは、その差は積み重なる。
コスト。 ツール提供者は計算やストレージに費用を払わない。クライアントサイドツールはユーザーあたりの限界コストが事実上ゼロだ。だから無料が多い。
オフライン。 ページが読み込まれれば、インターネット接続なしでもツールは動作する。機内、不安定なWi-Fiのカフェ、気密環境で役立つ。
レジリエンス。 ツール提供者が資金を使い切ったり、クリプトに方向転換したりしてもツールはダウンしない。URLにアクセスできさえすれば、動作する。
トレードオフ
クライアントサイドは無料ではない。一部のツールがこのアプローチを取れない本当の理由がある。
ファイルサイズ制限。 ブラウザタブは単一プロセスだ。非常に大きいファイル（数100MB）はタブをクラッシュさせる可能性がある。サーバーコードツールはストリーミングし、任意のサイズを処理できる。JSONフォーマッターの場合、約50MBを超えるとブラウザで動作が遅くなり始める。DevSpeedToolsのJSONフォーマッターはこの点をうまく処理する；本当に大きなファイルには、ストリーミングCLIツールが正しい答えだ。
コラボレーションがない。 ツールがユーザー間で状態を共有する必要がある場合（Figma、Google Docs、マルチプレイヤーなど）はサーバーが必要だ。しかし、ほとんどの開発ツールがそうするわけではない。フォーマッター、バリデーター、デコーダー、ジェネレーター — これらはすべて単一ユーザー操作だ。
ユーザーデータの分析がない。 提供者はユーザーがツールで何をしているかを確認できない。それがポイントだ。しかし、ツール作成者がユーザー報告の問題をデバッグしにくくなるという意味でもある。優れたクライアントサイドツールは、明確なエラーメッセージと、実際のデータを共有せずに再現可能な例を共有する方法を提供する。
クロスオリジンアセットの制限。 ツールがサードパーティAPIから取得する必要がある場合（例：IDプロバイダーからJWKSを取得する必要があるJWT検証ツール）、CORS設定が正しくなければならない。純粋にローカルなツールでは、これは問題にならない。
初期ダウンロード。 WASMモジュールは数MBになることがある。大きなWASMベースのYAMLパーサーや正規表現エンジンは、初回アクセス時に読み込みに時間がかかることがある。2回目以降はキャッシュされる。ストリーミングコンパイル（2024年以降、ChromeとFirefoxで標準）により、完全にダウンロードされる前に最初のパースが行われるため、本質的な懸念から軽微な問題に縮小した。WebGPUが利用可能な場合、計算集約型の開発ツール（画像処理、暗号、正規表現エンジン）をGPUで実行でき、適切なワークロードではJavaScriptより数桁高速だ。
ツールが実際にクライアントサイドであるかの確認方法
ほとんどの開発ツールのマーケティング文面は「クライアントサイド」「ブラウザ内」「アップロードなし」と言っている。そのほとんどは本当だ。そうでないものもある。確認方法を紹介しよう。
- DevTools → Networkを開く。 ツールを使い、リクエストを監視する。ツールがデータを含むAPIに
POSTしているなら、クライアントサイドではない。HTML、CSS、JSバンドルのリクエストだけなら問題ない。 - ソースを確認する。 右クリック → ページソースを表示 → JavaScriptを探す。重い処理が
scriptタグにあり、ローカルで実行されるなら、ツールはクライアントサイドだ。サーバーAPIを薄く包んでいるだけなら、そうではない。 - ネットワークをブロックする。 DevTools → Network → 「オフライン」。ツールを再読み込み（ページがキャッシュされている必要がある）。ツールを使う。まだ動作するなら、真にクライアントサイドだ。
- プライバシーポリシーを読む。 「収集しない」「ログを記録しない」「すべての処理はブラウザ内で行われる」という文面を探す。「プライバシーを大切にしています」のような曖昧な文面は黄色旗だ。
優れたクライアントサイド開発ツールの特徴
最高のクライアントサイドツールはいくつかの共通点がある：
- クライアントサイドであることを明示する。 しばしば入力近くに小さなバッジがある（「ローカルで処理済み」やロックアイコン）。
- オフラインで動作する。 読み込まれれば、ネットワークなしでもページは動作し続ける。
- 大きなデータの貼り付けを適切に処理する。 10MBの貼り付けでブラウザがロックしてはならない。
- URLフラグメントで状態を共有する方法を提供する。 例：入力を
#data=...URLフラグメントにエンコードするツールは、データをサーバーに送信せずに例を共有できる。DevSpeedToolsの共有ヘルパーはまさにこれを行う。 - プライバシーに関する説明がある。 ツールが入力に対して何をするかを説明する短い文面 — 通常は「何もしない」。
サーバーコードがまだ正しい答えの場合
すべてがクライアントサイドでできるわけでも、すべきわけでもない：
- データベースが必要なツール。 「自分のIPは？」ツールは実際にIPを見る必要がある。
- 有料APIを呼び出す必要があるツール。 「この記事を要約する」ツールはOpenAIを呼び出す。OpenAIキーはブラウザに含められない。
- 外部システムへの書き込みアクセスが必要なツール。 Slackに投稿したり、GitHub PRを作成したりするものすべて。
- ユーザー間で集計が必要なツール。 「このドメインはブロックリストにあるか」ツールは共有ブロックリストが必要だ。
境界線：操作がユーザーの入力のみの関数であるなら、クライアントサイドであるべきだ。操作に共有状態が必要なら、サーバーは避けられない。
開発ツール分野におけるここ5年の変化は劇的だ。かつてバックエンドを必要としていたツール（フォーマッター、バリデーター、デコーダー、ジェネレーター）は、今や完全にブラウザで実行される。パターンはシンプルだ：一度ダウンロードし、永遠に実行し、何も送信しない。機密性の高い設定や本番トークンを使う開発者にとって、この変化は安全性の有意义な向上だ。