JSON Merge Patch (RFC 7396) 評価ツール｜パッチ適用結果と操作履歴を可視化

ターゲット JSON とパッチ JSON を貼り付けると、RFC 7396 のマージ規則に従って適用結果を整形 JSON で表示し、どのパスにどの操作 (設定・削除・ルート置換) が起きたかを順序付きトレースで開示するツール。

💡 このツールについて

HTTP PATCH リクエストを設計するとき、「このパッチを送ったら相手側 JSON がどう変わるか」を実際の API を叩く前に手元で確かめたい場面は多い。RFC 7396 (JSON Merge Patch) は「パッチ JSON のメンバを再帰的に当て込む」という単純な規則ですが、null で消える挙動や、オブジェクトだけ再帰してスカラ・配列は丸ごと置換される挙動を頭の中で追うのは意外と間違えやすい。

このツールは、ターゲットとパッチの 2 つを貼り付けるだけで、マージ後の最終 JSON に加えて、適用された操作を 1 件ずつ表に出します。「/author/email を削除」「/title を Hello World に設定」のようにパスと操作種別が並ぶので、想定した差分が本当に起きるか・余計な置換が混じっていないかを目で確かめられます。OpenAPI の PATCH エンドポイント仕様レビューや、素の merge patch を受け取るバックエンドの挙動再現など、仕様どおりの結果を再現したいときに使えます。

🧐 よくある質問

Q. JSON Patch (RFC 6902) との違いは？ RFC 6902 は add / remove / replace / move / copy / test を並べた操作配列で、配列要素の挿入や特定インデックスの書き換えまで表現できます。RFC 7396 は「変更後の部分オブジェクトを送る」declarative な形式で、簡潔な反面、配列の部分更新や「値を null に設定する」ことは表現できません。このツールは RFC 7396 専用です。

Q. パッチで配列を一部だけ書き換えられますか？ できません。RFC 7396 では配列は不透明 (opaque) な値として扱われ、パッチに配列を書くとターゲットの配列は丸ごと置き換わります。要素単位の差分が必要なら RFC 6902 を選ぶ設計判断になります。

Q. ターゲットに無いキーを null で消そうとするとどうなりますか？ ターゲットにそのキーが存在しない場合、null 指定は何もせず、削除操作も発生しません。トレースにも記録されません。

Q. パッチがオブジェクトでなくスカラや配列だった場合は？ パッチ全体がターゲットを置換します (RFC 7396 §2)。トレースには「ルート置換」として出ます。空文字列の入力欄は null として扱われます。

Q. 元の JSON のキー順は保たれますか？ 出力は整形表示なので、新規追加されたキーは末尾寄りに並ぶことがあります。RFC 7396 自体がキー順を規定しないため、意味的な等価性で判断してください。

📚 JSON Merge Patch をめぐる豆知識

RFC 7396 は 2014 年に標準化された比較的新しい仕様で、同年に先行公開された RFC 7386 を修正・置き換える形で出ています。「メンバ値を null にすると消える」という規則の副作用として、「フィールドの値を意図的に null として保存したい」ケースが表現できないという制約が生まれ、これが merge patch を採用するか RFC 6902 を採用するかの分かれ目としてよく議論されます。media type は application/merge-patch+json で、HTTP の Content-Type ヘッダにこれを付けることで、サーバ側が「素のリプレースではなく merge patch として解釈すべき」と判別できる設計になっています。