← 記事一覧
更新日: May 29, 20267 min read

機密 JSON をオンラインツールに貼ってはいけない理由

JWT トークン、API キー、PII、データベースエクスポートはオンラインフォーマッターに頻繁に貼り付けられる。サーバ側でそのデータに何が起きるか —— そしてブラウザネイティブのツールがなぜ安全か。

ある開発者がパースエラーに当たり、API レスポンスの JSON をコピーして、Google の最初に出てきたオンライン formatter に貼り付けます。その JSON にはユーザー ID、メールアドレス、セッショントークン、あるいは社内設定ファイルが含まれています。これがエンジニアリングチーム全体で毎日何十回も起きています。本記事ではそれが生むリスクと、ブラウザネイティブのツールがなぜそれを取り除けるのかを正確に説明します。

オンライン JSON ツールに最終的に流れ込むデータの種類

実際には、開発者は目下困っているものを何でも貼り付けます。つまり：

  • JWT トークン —— ユーザーの identity claim、ロール、有効期限を含みます。署名が改ざんを防ぎますが、ペイロードは Base64url で符号化された平文：あなたのトークンをログに残した人は誰でも全フィールドを読めます。
  • PII を含む API レスポンス —— 氏名、メール、電話、生年月日、住所。顧客向け API の検索結果の 1 ページに数百件のレコードが入ることもあります。
  • 設定ファイル —— DB 接続文字列、サードパーティ API キー、feature flag 設定、社内サービス URL。
  • データベースエクスポート —— 1 つのテーブル丸ごとの JSON ダンプ。デバッグ用に作って、そのまま貼ることもあります。
  • 社内ビジネスデータ —— 価格ルール、契約条項、未公開の製品データ。公的分類はなくても機微です。

どれもその瞬間は機微には感じません。開発者は構造を理解したいのであって、データを共有したいわけではありません。しかしオンラインツールに貼るという行為は、サードパーティへ送信することと技術的には区別できません。

オンラインツールにデータを送ると何が起きるか

多くのオンライン formatter、validator、diff ツールは、入力をサーバの endpoint に送って処理し、結果を返します。「クライアントサイド」を謳うツールでも、ログ・analytics・エラートラッキング目的でデータを送ることがあります。データがその経路で辿る顛末は以下の通り。

サーバサイドのログ

Web サーバは多くのフレームワークでデフォルトでリクエストボディをログに記録します。あなたの JSON ペイロードの 1 回の POST が以下に残ることがあります：

  • ディスクまたはログサービス（Datadog、Splunk、CloudWatch）に保存されるアプリケーションログ
  • エラートラッキング（Sentry、Bugsnag）—— 特にパース失敗時
  • 「analytics」や「usage」テーブルの 1 行
  • 運営者自身も監視していないかもしれない CDN やロードバランサのアクセスログ

ログ保持ポリシーは大きく異なります。ある工具は 90 日、別の工具は無期限。いずれにせよ運営者 —— と彼らのシステムにアクセスできた者 —— があなたの送信内容を読めます。

サードパーティ analytics

多くのオンラインツールは analytics や広告のためにサードパーティの JavaScript を埋め込みます。これらのスクリプトはネットワークリクエスト、フォーム送信、入力イベントを観察可能。ツールがデータを自前サーバへ送るなら、analytics 層もその HTTP トランザクションを見えます。

キャッシュと CDN ストレージ

入力内容をキーに結果をキャッシュするツールもあります。2 人のユーザが同じ JSON を送ると、2 人目はキャッシュされたレスポンスを取得。入力は数時間〜数日キャッシュに残ることも。極端なケースでは、誤設定されたキャッシュにより予測可能な URL でユーザの送信物が公開状態になった事例もあります。

検索エンジンのインデックス

共有可能な permalink（あなたが整形した JSON を含むか参照する URL）を生成する formatter は、検索エンジンに出力をクロールされたことがあります。社内設定ファイルから特徴的な文字列を検索して、それが JSON formatter のドメイン下に見つかるのは非常に気まずい経験です。

規制上のエクスポージャ

あなたの組織が GDPR、HIPAA、CCPA などの枠組みで個人データを扱っているなら、ユーザのデータをサードパーティのオンラインツールに貼ること自体が無許可のデータ転送に該当することがあります —— 偶発的でも、その工具が評判良くてもです。枠組みは意図的な共有と不注意な工具選択を区別しません。問うのはこれです：個人データが許可された処理境界を超えたか？

HIPAA 対象事業者については、BAA を結んでいないサードパーティサービスに保護対象保健情報を送ることは、データが悪用されたかに関わらず報告義務のある違反となります。

ブラウザネイティブツールが違うのはなぜか

現代のブラウザは複雑なロジック —— パース、検証、diff、整形、エンコード —— をネットワーク要求なしに JavaScript エンジン内で完全に走らせられます。このモデルで作られたツールは、たまたま web で配信されるローカルアプリのように振る舞います。

ブラウザネイティブツールに JSON を貼ったとき：

  • テキストはブラウザのメモリ内の JavaScript 変数に入ります。
  • パーサ（これも JavaScript）が同じタブ内で処理します。
  • 出力は DOM にレンダリングされます。
  • あなたのデータをペイロードに乗せた HTTP リクエストはどのサーバにも飛びません。

データはマシンから一切出ません。送信されていない以上、ログ・キャッシュ・インデックスのしようがありません。

工具が本当にローカルかを確かめる方法

「データは決して保存しません」という主張はよくありますが、外からは検証不能。唯一信頼できるチェックはブラウザの Network パネル：

  1. DevTools を開く（F12 または Cmd+Option+I）。
  2. Network タブに切り替え、Preserve log にチェック。
  3. JSON を貼って操作を起動（整形、検証など）。
  4. XHR/Fetch でリクエストをフィルタ。あなたの入力をペイロードに乗せた送信リクエストがあれば、それはクライアントサイドではありません。

真にローカルなツールでは、あなたのデータを乗せた送信 POST や fetch は現れません。静的アセット（CSS、JS）や analytics ping は見えるかもしれませんが、どれもあなたの JSON ペイロードは含みません。

// ローカルツールの動き —— ネットワーク呼び出しなし：
const result = JSON.parse(userInput);   // ブラウザ内で実行
render(result);                         // DOM を更新

// サーバサイドツールの動き：
const res = await fetch('/api/format', {
  method: 'POST',
  body: JSON.stringify({ input: userInput }),  // データがマシンを出ていく
});

実用パターン：BAA、WebCrypto、レダクションヘルパ

残りリスクのほとんどを抑える 3 つのパターン：

  • HIPAA 周辺業務のための BAA（Business Associate Agreement） —— チームが PHI を扱うなら、それに触れる任意のサードパーティサービスは事前に署名済み BAA が必要。だからこそ「ローカル動作」と称する formatter に PHI を貼るのは技術問題であると同時にドキュメント問題。
  • クライアントサイド WebCrypto —— ブラウザでハッシュ・署名・暗号化・鍵生成が必要な時、標準の crypto.subtle API がサーバ往復なしでこなします。「この payload を復号して見たい」を暗号文を外へ送らずに行う正しいプリミティブ。
  • レダクションヘルパ —— デバッグ時は既知の機微 key（password、 token、email、ssn）の値をマスクする小さなレダクタを通してから貼る。20 行の関数の方が analytics の請求ログでトークンを発見するより遥かにマシ。

チーム単位で持つ価値のあるポリシー

個人の意識だけでは限界があります。軽量なポリシーが穴を埋めます：

  • 貼る前に分類する。 JSON に氏名、メール、ID、トークン、鍵があるなら、それは機微。ローカルツールか承認された社内ツールを使う。
  • 承認ツールリストを維持する。 検証済みローカル優先ツールの短いリストの方が、漠然とした「気をつけて」より守りやすい。
  • デバッグセッションで本番資格情報を絶対に共有しない。 オンラインツールに貼ったトークンや鍵は、見た目が安全でも全てローテーション。
  • デバッグにはスクラブ済みサンプルを使う。 貼る前に実ユーザ値を合成データに置換。"email": "test@example.com" を含む構造でも、パースエラーのデバッグには実アドレスと同じくらい役立ちます。

よくある質問

機微 JSON をオンラインツールに貼っても安全ですか？

ツールが全てをブラウザ内で処理する場合のみ。サーバサイド formatter は入力をログ・キャッシュ・インデックスし得るし、PII をサードパーティへ貼ること自体が意図に関わらず GDPR や HIPAA 違反になり得ます。

JSON ツールがローカルかをどう確認しますか？

DevTools → Network を開き、「Preserve log」をチェックし、操作を実行。あなたの入力をペイロードに乗せた送信リクエストが無ければクライアントサイド。静的アセットや analytics リクエストは OK、JSON の POST は NG。

オンラインツールにトークンをもう貼ってしまったらどうする？

ローテートしてください。サードパーティツールに触れた資格情報や鍵は、ツールが立派に見えても侵害扱い。Base64 で符号化されたトークンは依然として平文 であることを忘れずに。

チームでこれを完全に避けるには？

ブラウザネイティブのツールを使う、承認ツールリストを保つ、そしてデバッグは実レコードではなくスクラブ済みサンプル（"email": "test@example.com"）で行う。

fixjson.org が行っていること

fixjson.org の全ツール —— JSON 修復、JSON diff、YAML formatter、JSON Stringify、Base64 エンコード/デコード、URL デコード —— は完全にブラウザ内で動きます。パーサ、diff エンジン、formatter はすべてローカル実行の JavaScript。Network タブで検証できます：あなたの入力を運ぶ POST は出ません。

サイトは CDN から静的アセット（HTML、CSS、JS）を一度ロードします。その後はオフラインで動きます。入力はどのサーバにも送られません。どのデータもログ・保存・共有されません。