レスポンス A
レスポンス B

API レスポンス差分: JSON API ペイロードをオンラインで比較

左側に期待していたレスポンス、右側に実際に返ってきたレスポンスを貼り付ければ、変わった全フィールドが一目で分かります。バックエンド・QA・統合テスト向け。データはブラウザの外に出ません。

この API レスポンス差分ツールについて

2 つの HTTP API レスポンスボディを比較するための無料のブラウザ内ツールです。staging から取得した JSON を左側に、production から取得した JSON を右側に貼り付けると、文字単位で差分がハイライトされます。テキストはあなたのマシンを離れません。これは重要なポイントです。実際の API レスポンスには顧客のメールアドレス、セッショントークン、内部ユーザー ID など、サードパーティの差分サイトにアップロードしたくない情報が頻繁に含まれているからです。

CI で不安定な統合テストが落ちた瞬間のためのツールです。手元のラップトップには動作しているレスポンスの Postman スクリーンショット、ビルドランナーには壊れたレスポンスの CI ログがある、という状況。一回限りの調査のために Pact の contract test を立ち上げるのはやり過ぎです。テキストペイン 2 つと差分 1 つで、たいてい 1 分以内に問題のフィールドを特定できます。

内部の差分エンジンは compare-json ツールと同じものです。API テスト向けに枠組みを変えただけです。レスポンスが XML や SOAP エンベロープなら compare-xml ページが対応します。webhook ログや監査証跡のような自由形式テキストの差分なら、compare-text ツールが適切な入口です。

API レスポンス差分が実際に役立つ仕組み

API レスポンス差分は、関連はしているが別物の 2 つのテストの考え方の隙間に位置します。OpenAPI 3.1 のスキーマ差分は、契約上 何が 変わったかを教えてくれます。新しい任意フィールド、リネームされたプロパティ、より厳しい enum など。スナップショットテスト（Jest snapshots、Vitest snapshots、pytest-snapshot）は、コードが 何を生成したか を保存済みのフィクスチャと比較して教えてくれます。このツールはランタイム側にあります。実際の 2 つのレスポンスボディを渡すと、スキーマがその変更を許容しているかや、スナップショットフィクスチャが最新かどうかに関係なく、異なるバイトをすべて表示します。

なぜそれが有用なのか。REST の統合作業で最も痛い不具合は、スキーマ違反ではないからです。微妙なずれです。Jackson のアップグレード後にシリアライザが日付を ISO-8601 から Unix タイムスタンプにこっそり切り替えていた、Marshmallow スキーマが欠落フィールドを省略する代わりに null を出すようになった、ミドルウェアの変更後に DRF ViewSet がペイロードを data エンベロープで包み始めた、など。OpenAPI 仕様は変わっていない。スナップショットは更新されていない。テストは単体では通った。統合は壊れた。レスポンスボディ差分はこれらすべてを捕捉します。契約は気にせず、バイトを見るからです。

揮発性フィールドが主な注意点です。タイムスタンプ、リクエスト ID、トレース ID、サーバー生成 UUID、ページネーションカーソルは、同じエンドポイントの 2 回のキャプチャ間で必ず異なります。意味のある変更が何もない場合でもです。正しい対処は差分を取る前に正規化することです。タイムスタンプをプレースホルダに置換、トレース ID を除去、契約上順序が重要でない配列をソート。Pact のようなツールはマッチャーで対応しますが、このツールではペインを編集して対応します。10 秒で済んで、ノイズフロアが消えます。

API レスポンスの差分を 3 ステップで取る方法

テキストペイン 2 つ、差分 1 つ。ログイン不要、アップロード不要、プロキシ配線も不要。

  1. 1

    1 つ目のレスポンスをキャプチャ

    curl、httpie、Postman、Insomnia など、チームで使っているもので endpoint を叩きます。curl -s https://api.example.com/v1/users/123 | jq が良い基本形です。jq が JSON を整形してくれるので、差分が格段に読みやすくなります。本文（JSON だけ、ヘッダは不要）をコピーして左側のペインに貼り付けます。CI ログから持ってくる場合は、多くのロガーが付けるタイムスタンプの接頭辞を取り除き、差分が実際のペイロードに当たるようにします。

  2. 2

    2 つ目のレスポンスをキャプチャ

    比較対象を叩きます。別の環境、別の API バージョン、別のベンダー。同じ形式のキャプチャ、同じ pretty-print の手順。右側のペインに貼り付けます。一方が録画フィクスチャ（vcrpy、pollyjs、MSW、nock）でもう一方がライブの場合、まず明らかな揮発性フィールドを正規化します。request_id をスクラブし、タイムスタンプを定数に置き換え、本文に紛れ込んだトレースヘッダを除去します。残った差分が本物のシグナルです。

  3. 3

    ハイライトされた差分を読む

    削除は左側に赤い取り消し線で、追加は右側に緑で表示されます。各ヘッダの変更カウンターは差分が見つけた個別の編集件数を示します。最初に注目すべきは 3 点です。status 文字列の変更、欠落・追加されたキー、値の型変更（string が number に、object が null に）。この 3 カテゴリでほぼすべての本物の API リグレッションをカバーします。フォーマットや並び順の変更は、コンシューマがそれに依存していなければ通常はノイズです。

API レスポンス差分が正解になる場面

不安定な統合テストの再現

ローカルでは通って CI で落ちるテスト。手元の Postman でキャプチャしたレスポンスと、CI ビルドエージェントでキャプチャしたレスポンスがあります（多くの CI システムは verbose フラグでリクエスト・レスポンスをダンプできます）。両方を差分ツールに貼り付けます。10 回中 9 回は環境要因です。違う feature flag、古いフィクスチャ、ビルドランナーのタイムゾーンずれ。残りの 1 回は本物のバグで、特定のフィールドにまで絞り込めています。

新鮮なレスポンスに対するフィクスチャの検証

リポジトリにはテスト用にサードパーティ API をモックする、コミット済みのフィクスチャファイルがあります。上流のプロバイダがマイナーバージョンを公開したばかり。curl でライブの endpoint を叩き、そのレスポンスをフィクスチャの隣に貼り付ければ、ドリフトしたフィールドが正確に分かります。VCR スタイルの再生ツールが自動化していることの手動版です。テストスイート全体を再録せずに 1 つのフィクスチャを更新したいときに便利です。

API バージョンの後方互換性の確認

社内 API の v2 をリリース直前。本番には v1 クライアントがまだ存在しています。/v1/orders/42 と /v2/orders/42 の両方を叩いてレスポンスの差分を取ります。削除されたフィールド、リネームされたキー、値の型変更はどれも v1 クライアントにとっての破壊的変更です。新しいフィールドはどれも追加であり安全です。これは consumer-driven contract test の貧者版です。何十もの endpoint にスケールしませんが、1〜2 個の素早いサニティチェックには使えます。

シリアライザのリグレッション発見

Jackson、Marshmallow、DRF、または類似のシリアライズ層をアップグレードしたチーム。テストは通る。その後、下流のコンシューマからパーサが詰まると報告。同じ endpoint のレスポンスを古いブランチと新しいブランチでキャプチャして差分を取ります。よくある発見は、日付フォーマットが 2026-05-09T10:00:00Z から Unix タイムスタンプに切り替わっていた、小数の末尾ゼロが落ちていた、enum が文字列でなく整数でシリアライズされ始めていた、または以前は省略されていた null フィールドがペイロードに現れ始めた、など。

2 つのプロバイダまたはバージョン間の webhook ペイロード比較

同じイベントタイプの Stripe webhook V1 と V2 はほぼ同じに見えてまったく同じではありません。GitHub の webhook イベントペイロードも API バージョン間で同様、Slack のイベント購読もスコープ間で同様です。サンプルペイロードをそれぞれ差分ツールに貼り付ければ、リネームされたフィールド、移動された入れ子オブジェクト、新しいメタデータブロックが見えます。プロバイダのドキュメントページを 2 つ並べて読むより速く、特に実際にどのフィールドが現れるかをドキュメントが曖昧にしている場合に有効です。

「staging では動くのに prod で壊れる」のデバッグ

デプロイの古典的な頭痛。同じクライアントリクエストが staging と production から微妙に異なる JSON を返す。両方をキャプチャして両方を貼り付ければ、違いはたいてい設定フラグ、欠けている feature gate、または古いキャッシュレスポンスです。マルチリージョンのデバッグ（us-east-1 と eu-west-1 が異なるデータを返す）、CDN キャッシュの問題（Cloudflare が古い本文をキャッシュ）、リードレプリカの遅延（書き込みが伝播しきっていない）にも同様に当てはまります。

知っておくと役立つ API レスポンス差分のエッジケース

レスポンスボディ差分が、テストフレームワーク・OpenAPI ツール・あなたの目の判断と食い違う場面。差分が本物のバグを見つけたと結論する前に、ざっと目を通しておく価値があります。

TopicWhat this tool does
揮発性フィールド（タイムスタンプ、ID）created_at、updated_at、request_id、trace_id、サーバー生成 UUID、ページネーションカーソルは 2 つのキャプチャ間で常に異なります。jq 'del(...)' で正規化、定数に置換、または差分を取る前に編集して取り除きます。本当に気にすべきシグナルは別の場所にあります。
null vs キーの欠落{"foo": null} と {} は JSON では別物で、多くのシリアライザ（Marshmallow、Jackson、System.Text.Json）にはこの 2 つを切り替える設定があります。差分はこれを表面化します。一部のクライアントは同等扱いし、一部はしません。正解はあなたのコンシューマ次第で、これがシリアライザのアップグレード後に頻発するリグレッションの原因になります。
キーの順序RFC 8259 は JSON オブジェクトを順序なしと定義しています。意味的に同一でキーの順序が違う 2 つのレスポンスはここで差分として表示されます。テキスト比較は順序に敏感だからです。順序非依存の差分が欲しい場合は、両側を jq --sort-keys で事前にソートします。順序に依存する稀なコンシューマ（一部の署名フロー、一部のレガシーパーサ）には注意が必要です。
配列の順序JSON の配列は順序付きですが、多くの API は実際には契約上順序のない配列を返します。権限のリスト、feature flag のリスト、webhook 購読のリスト。差分は並び替わった配列を変更として報告しますが、コンシューマがそれを気にしないことも多々あります。並び替えがドメインで無害なら、差分を取る前に両側を安定したキーでソートします。
JSON.parse の厳格さ差分は入力を不透明なテキストとして扱います。一方のキャプチャに末尾カンマ、クォートされていないキー、コメント（厳密 JSON ではすべて違反）があっても差分は動きますが、必要以上にノイジーになります。両方のキャプチャをまず jq . に通して再整形し、不正な入力を弾きます。jq は厳密な RFC 8259 パーサを使います。
レスポンスのラッピング（data エンベロープ vs フラット）多くの API はペイロードを {"data": ...} エンベロープに包み、横に meta、links、included を付けることもあります（JSON:API など）。フラットからラップへの移行（またはその逆）は破壊的変更で、差分にはすぐ現れますが、内側のレコードは同じに見えるためスキーマレビューでは見落としやすい変更です。
ページネーションカーソルの変更カーソルベースのページネーションは不透明トークン（next_cursor、after、page_token）を使い、毎回変わるよう設計されています。常に差分として表示されます。比較前に取り除くか、data 配列の中身だけを比較してページネーションブロック全体を無視します。
エラーレスポンスの形式エラーボディは無法地帯です。フラットな {"error": "..."} を返す API もあれば、type、title、status、detail、instance を持つ RFC 7807 Problem Details を返すものも、ベンダー固有の形を返すものもあります。独自形式から RFC 7807 への移行は大きな差分を生みますが、ほとんどは改善です。逆方向の移行は早期に捕まえる価値のあるリグレッションです。

API レスポンス差分: よくある質問

Postman の組み込み差分機能と何が違いますか？

Postman には Collection Runner 内のレスポンス比較ビューと、個別レスポンス向けの Visualize 機能があります。どちらも、Postman の中で生活していて、レスポンスがすでに Postman 履歴アイテムとして保存されているなら良いものです。このツールはプロバイダ非依存です。Postman、Insomnia、curl、httpie、CI ログ、Stack Overflow のスニペット、同僚の Slack メッセージから貼り付けられます。アカウントもワークスペースも同期もありません。ツールをまたいだ単発の比較ならその方が速いです。単一プラットフォーム内でチーム共有の API テストをするなら、Postman 自身の機能で十分です。

タイムスタンプやリクエスト ID のような揮発性フィールドはどう扱えばいいですか？

実用的なやり方は差分を取る前に正規化することです。両方の貼り付け内容をペインに開いた後、揮発性フィールドを直接編集します。タイムスタンプを定数文字列に置換、request_id と trace_id の値を除去、毎回変わるページネーションカーソルを削除。差分は残った差異だけをハイライトし、それが本当に重要な箇所です。同じ endpoint の繰り返し比較なら、貼り付ける前に jq の delete フィルタ（jq 'del(.meta.request_id)'）を通すのも手です。

OpenAPI スキーマ差分と何が違いますか？

スキーマ差分は契約を比較します。POST /orders に任意フィールド discount_code が追加された、status enum に新しい値が増えた、といったことを教えます。oasdiff や Spectral のような OpenAPI 対応ツールはこれをうまくこなします。このツールは実際のレスポンスボディを比較します。両者は補完的です。スキーマ差分は契約の変更を捉え、レスポンス差分は契約と現実のずれを捉えます。シリアライズの不具合、環境のミスマッチ、古いフィクスチャはそこに潜みます。

大きなレスポンスは扱えますか？

実用上は扱えます。整形された JSON で各側数千行程度までです。それを超えると、文字単位の差分とセマンティッククリーンアップは遅くなります。サーバーではなくブラウザで動いているからです。非常に大きなペイロード（10,000 件のページネーションダンプなど）の場合、レスポンスをレコード単位やトップレベルキー単位で小さな塊に切り分け、それぞれ別々に差分を取るのが正しい方法です。あるいは速度重視なら jd や diff <(jq . a.json) <(jq . b.json) でコマンドライン上の構造的差分を実行します。

XML や SOAP のレスポンスでも動きますか？

直接は動きません。このページは JSON 向けに調整されています。最近の REST と webhook ペイロードのほとんどは JSON です。XML、SOAP エンベロープ、RSS、POM スタイルの設定の差分が必要なら、compare-xml ツールが適切な入口です。インデントと namespace の整形を正しく扱います。ヘッダと本文が混在した生のレスポンスボディや、プレーンテキスト API（一部のレガシーシステムは今でも text/plain を返します）には、構造を強制しようとしない compare-text が仕事をします。

キーの順序を保持しますか、それともソートしますか？

貼り付けたキーの順序を保持します。JSON オブジェクトは RFC 8259 で公式に順序なしと定義されているため、意味的に同一でキーの順序が違う 2 つのレスポンスは、このツールでは差分として表示されます。順序を無視したい場合、まず両側を jq --sort-keys または同等のものに通して正規化します。ほとんどのクライアントはキーの順序に依存しないので、ソート済みキーへの正規化はレスポンス比較の安全なデフォルトです。ただし一部のレガシーコンシューマ（古い XML から JSON へのブリッジ、特定の電子署名フロー）は順序に依存することに注意してください。

プライバシーと、API レスポンスでそれが重要な理由

API レスポンスのペイロードには、漏らしたくないものが頻繁に含まれます。顧客のメールアドレス。内部ユーザー ID。セッショントークン。誤って本文フィールドに入った Auth bearer トークン。Stripe の顧客 ID。webhook シークレット。氏名・住所・電話番号などの PII フィールド。これをクラウドホストの差分サービスに貼り付けること自体がデータ取扱いイベントであり、業界によっては SOC 2 統制、GDPR データ処理契約、HIPAA Business Associate Agreements に違反する可能性があります。このツールは完全にあなたのブラウザ内で動きます。何もアップロードされず、ログにも残らず、サードパーティのサービスにも送られません。差分・ハイライト・レンダリングはすべてあなたのマシンで実行されます。検証も簡単です。ブラウザの DevTools を開き、Network タブに切り替え、両方のレスポンスを貼り付けて観察してください。比較時に外向きのリクエストはありません。より広範な API 設計とセキュリティのガイダンスとして、Microsoft の API design best practices は確かなリファレンスです。