【ITニュース解説】Why JSON Array Diffing Is Harder Than It Looks

JSON（JavaScript Object Notation）は、Webアプリケーションやシステム間で情報をやり取りする際に広く使われるデータ形式だ。これは、人間にとっても機械にとっても読み書きしやすい構造をしており、特にデータのかたまりやリスト（配列）を表現するのに適している。システム開発では、時間の経過とともにデータがどのように変化したかを把握する必要があることが多く、この変化を特定する作業を「差分比較（diff）」と呼ぶ。

一般的な差分比較ツールは、テキストファイルを比較するように、データの「位置」に基づいて変化を見つけるのが基本だ。JSONデータの中にリスト（配列）がある場合、リストの最初の要素と最初の要素、二番目の要素と二番目の要素、というように順番に比較していく。これは、リストの順番そのものに意味があるデータ（例えば、手順のリストなど）の場合には非常に正確な比較方法となる。

しかし、配列がユーザーのリストや商品の在庫情報のように、個々の「レコードの集まり」を表している場合、この位置に基づく比較は思わぬ問題を引き起こすことがある。例えば、あるユーザーのデータがリストの中で数カ所移動しただけで、中身は何も変わっていないのに、差分ツールは「その位置のデータが丸ごと別のものに変わった」と報告してしまう可能性がある。記事の例で示すように、ユーザーリストで「Carol」のデータが先頭に移動し、「Bob」のステータスが変更され、「David」が新たに追加された場合、通常の差分ツールはCarolの移動によって、移動後の位置にあるAliceやBobのデータも「変更された」と誤って報告してしまう。これでは、本当に何が変わったのかを見つけるのが難しくなり、大量の「ノイズ（無関係な差分情報）」に埋もれてしまうことになる。

人間がこのデータを見れば、「Bobのステータスが変わった」と「Davidが追加された」という二つの本質的な変更点だけを指摘するだろう。これは、人間がそれぞれのユーザーを「同じ人物」として認識できるため、たとえリストの中での位置が変わっても、その人物のデータ自体が変わったとは判断しないからだ。つまり、データの本質的な「同一性」を理解した上で比較することが重要になる。

この問題を解決するために開発されたのが「JSON Semantic Diff」というアプローチである。これは、単に位置で比較するのではなく、まず配列の中のどのデータが互いに「同じもの」であるかを賢く特定しようと試みる。この「対応関係（Correspondence）」を正しく見つけることが、データの本質的な変化だけを抽出する、セマンティックな差分比較の最も重要な部分となる。

対応関係を見つけるのは一見簡単そうに見えるかもしれない。「id」や「userId」のような識別子を探せば良いと考えるかもしれないが、実際のデータはそう単純ではない。識別子となる項目の名前は「orderNumber」「sku」「email」など、データの内容によって多岐にわたる。さらに、識別子と思える項目がデータ中に存在しなかったり、複数の同じ値が存在したり、あるいは一時的にしか一意でない場合もある。逆に、一見すると識別子とは無関係そうな項目が、実は最も信頼できる識別子であることもあるのだ。

JSON Semantic Diffは、単に項目名に依存するのではなく、データそのものから識別子を「推論」する。これは、配列内の各データのかたまりについて、個々の項目やいくつかの項目の組み合わせを「識別子の候補」として評価していく方法である。その評価には、以下のようないくつかの「シグナル」と呼ばれる情報が使われる。

まず、候補となる項目や組み合わせが、データ内で重複なく存在しているかという「一意性」をチェックする。次に、その候補を使って、比較対象のデータ間でどれだけのデータが対応付けられるかという「マッチカバレッジ」を見る。対応付けられたデータの数が、元の両方の配列に対して十分に多いかという「人口の重なり」も重要だ。また、候補となる項目が、比較対象のすべてのデータに存在しているかという「完全性」、その値のデータ型（数字、文字列など）が、一貫しているかという「型の一貫性」も評価する。そして、項目名が「id」や「userId」など、識別子を示唆するような名前であるかという「名前のヒント」も参考にされるが、これはあくまでヒントであり、絶対的なルールではない。

これらのシグナルはそれぞれ異なる観点から候補を評価する。例えば、ある項目が一意であっても、比較対象のデータにその値が一つも存在しなければ無意味だ。あるいは、マッチする値は多いが、配列全体のほんの一部しかカバーできない場合もある。これらのシグナルを総合的に組み合わせることで、各候補の「スコア」を計算する。また、複数の項目を組み合わせた「複合識別子」の場合には、少し複雑さに対するペナルティも与えられ、可能な限り単一の信頼できる項目を優先するようになっている。

記事の例では、最も適切な識別子が94%という高いスコアを獲得し、次点の候補を大きく上回ったとされている。しかし、単にスコアが高いだけでなく、いくつかの「安全基準」も設けられている。例えば、識別子の一意性が十分に確保されているか、両方のデータで十分な数のレコードが対応付けられるか、そして一番良い候補と二番目に良い候補のスコアに十分な差（マージン）があるか、といった点だ。もし二つの候補がほぼ同じスコアだった場合、どちらを選んでも任意性が高く、誤った対応付けをしてしまうリスクがある。誤った対応付けに基づく「きれいな差分」は、かえって誤解を招く危険性があるため、曖昧な場合は無理に推論せず、あえて位置による比較にフォールバックすることもある。

時には、単一の項目だけでは識別子として機能しない場合もある。例えば在庫データの場合、「店舗（store）」だけでは複数の商品があるため一意でなく、「商品コード（sku）」だけでは同じ商品が複数の店舗にあるため一意ではない。しかし、「店舗」と「商品コード」を組み合わせることで、特定の店舗の特定の商品という形で、在庫レコードを一意に識別できるようになる。このような「複合識別子」の推論も、JSON Semantic Diffは行う。これにより、「数量が変わった既存の商品」「価格が変わった既存の商品」「新規追加された店舗と商品の組み合わせ」などを正確に区別できるようになる。

しかし、すべての配列に信頼できる識別子が存在するとは限らない。値が重複していたり、対応するデータが少なすぎたり、重要な項目が一部のデータに欠けていたりすることもある。また、配列の順序そのものに意味がある場合もある。このような、自動での推論が難しい、あるいは曖昧なケースでは、JSON Semantic Diffは無理に推論せず、最初の説明で述べたような「位置による比較」に戻る。その場合でも、利用者が手動で「この項目とこの項目を組み合わせたものが識別子だ」と指定することで、ツールを補助できる仕組みも提供されている。これは、データに関する専門的な知識がある場合に特に役立つ。

このJSON Semantic Diffは、人工知能（AI）や曖昧な意味解釈（ファジーセマンティックマッチング）に頼っているわけではない。同じ入力と設定であれば、必ず同じ結果を出す「決定論的」な設計になっている。また、なぜその識別子を選んだのか、そのスコアや内訳、次点の候補、そしてそれらの差といった情報も提示されるため、「なぜこの結果になったのか」を理解し、説明することができる。さらに、この比較処理はユーザーのブラウザ上でローカルに実行されるため、機密性の高いJSONデータをサーバーにアップロードする必要がなく、安心して利用できる点も特徴だ。

セマンティックな差分比較の真の目的は、単に見た目の良い差分を表示することではない。「これらの二つのデータは、たとえ位置が異なっても、同じ実体を表している」という強力な主張を、確かな根拠に基づいて行うことにある。これにより、不要なノイズを大幅に削減できるが、それはその主張が十分に裏付けられている場合に限られる。可能な限り識別子を推論しようとするのではなく、信頼できる十分な根拠があるときにのみ推論を行い、不確かな場合はその不確かさを明確にすることが、このアプローチの目標である。この技術はまだ開発途上であり、実際の多様なデータに触れることで、さらなる改善が期待されている。