差分アルゴリズムのしくみ
このページのすべての差分ビューは Myers アルゴリズムによって生成されます — Eugene W. Myers が 1986 年に考案した、D を編集距離とした O((N+M)D) 時間で 2 つのトークン列の間の最短編集スクリプトを求める技術です。このアルゴリズムは最長共通部分列問題を基盤としており、エンジンはオープンソースの jsdiff ライブラリを使用してすべてブラウザ内で実行されます。
- 入力をトークン化 — 比較前に、アルゴリズムが各入力をトークンの列に分割します。行粒度では改行で分割し、単語粒度では空白と句読点の境界で分割し、文字粒度ではすべての Unicode コードポイントを個別のトークンとして扱います。
- 編集グラフの構築 — Myers アルゴリズムは比較を 2D グリッド上のパスとしてモデル化します。右に移動することは「元のテキストから削除」、下に移動することは「変更後から挿入」、斜め右下に移動することは「両方でトークンが一致」を意味します。アルゴリズムは最も対角線が多い最短パスを求めます。
- LCS の抽出 — 最短パスの対角移動が最長共通部分列 — 同じ相対順序で両方の入力に現れるトークン — をトレースします。LCS 内のすべてのトークンが「変更なし」であり、それ以外はすべて追加または削除です。
- 前処理オプションの適用 — 「大文字小文字を無視」を有効にすると、LCS パスの前に両方の入力が小文字化されるため「HELLO」と「hello」が同一とみなされます。「空白を無視」は複数のスペースを 1 つに折りたたみます。「各行をトリム」は比較前に各行の先頭と末尾の空白を削除します。
- 選択したビューのレンダリング — 出力は同じ LCS 結果を 3 つの方法で表示します。並排表示は赤と緑の行ハイライトで左に元のテキスト、右に変更後を 2 列グリッドで表示します。統合表示は
git diffの出力のように − と + のプレフィックス行で 1 列表示します。インライン表示は削除を赤の取り消し線、追加を緑の下線として同じテキストフロー内に表示します。 - サマリーストリップの計算 — レンダリング後、ツールは追加、削除、変更なしのトークン数を数え、類似度を変更なしトークンと 2 つの入力長の大きい方の比率として計算します。類似度 100% は前処理後に 2 つの入力が同一であることを意味します。
差分チェッカーを使う理由
- Git クライアントなしのコードレビュー — 設定ファイル、SQL マイグレーション、シェルスクリプトの 2 つのバージョンを貼り付け、リポジトリをクローン、ブランチの切り替え、CI パイプラインの待機なしに何が変わったかを確認できます。ペアプログラミング中のクイックレビュー、Git 履歴を共有していない委託業者のハンドオフ、バージョン管理以前のレガシーコードベースに便利です。統合表示はチャットスレッドやチケットにそのままコピーできる出力を生成します。
- 契約書や文書のレッドライン — 単語レベルの差分は Word の変更の追跡パネルより速く契約書のドラフト間でどの語句が変わったかを表示します。最初のドラフトの条項 A と締結済みコピーの条項 B を貼り付けると、移動した正確なフレーズが赤と緑でハイライトされます。法務担当者や調達チームは、契約が署名される前に土壇場のレッドラインがレビューをすり抜けていないか確認するためにこれを使います。
- 文章と原稿の改訂 — 初稿と編集済みバージョンを比較するライターは、単語粒度に切り替えることで両方を読み直すことなくすべての置換、挿入、削除を確認できます。翻訳者がソーステキストに対する変更を確認する場合、編集者がコピー編集が著者の声を保持しているか確認する場合、ジャーナリストが公開記事とファイルされた原稿を照合する場合も同様のワークフローが使えます。
- ログと設定の比較 — 2 つのサーバー設定スナップショット、2 つの cron スケジュール、または 2 つの
ps aux出力を比較するシステム管理者は、行粒度を使用して 200 行のファイルの中の 1 つ変更されたパラメーターを数秒で見つけられます。「空白を無視」オプションと組み合わせると、ノイズの多いアライメントのみの差分が実際に重要なパラメーター変更だけに絞り込まれます。
主な活用シーン
テキスト差分は、ライティング、開発、運用のすべての編集サイクルの末尾に登場します。
- プルリクエストレビュー：ブランチをチェックアウトするオーバーヘッドなしに、承認前にロジックの変更を理解するために 2 つの関数実装を並べて貼り付けます。
- 国際化 QA：英語のソース文字列とその翻訳を単語レベルで比較し、翻訳者が導入した挿入、省略、用語の入れ替えを検出します。
- インシデント分析：2 つの Kubernetes マニフェストのスナップショットまたは 2 つの「docker inspect」出力を行レベルで比較し、障害の前に起きた設定変更を特定します。
実際の例
5 行のサーバー設定を例にとります。変更前：host=localhost、port=5432、dbname=app_db、user=app、password=secret。変更後：host=db.prod.example.com、port=5432、dbname=app_db、user=app_prod、password=secret。行粒度と並排表示で、1 行目は左に赤（host=localhost）、右に緑（host=db.prod.example.com）、4 行目は左に赤（user=app）、右に緑（user=app_prod）、2・3・5 行目は両側で変更なしのまま表示されます。サマリーストリップは追加 2、削除 2、変更なし 3、類似度 60% — 5 行中 3 行を維持 — と報告します。単語粒度に切り替えると差分がさらに絞り込まれます：1 行目と 4 行目の = の右側の値だけがハイライトされ、キーは変更なしのままで、LCS が host、user、周囲の句読点を維持とカウントするため類似度は約 85% に上がります。
これはブラウザ内で実行されますか？
はい。差分計算全体がページとともに読み込まれるオープンソースの jsdiff ライブラリを使用してクライアントサイドで実行されます。入力、貼り付け、比較したものは一切サーバーに送信されません。自分で確認できます：ブラウザの DevTools を開き、ネットワークタブに切り替えてログをクリアし、「比較」をクリックして、比較ステップでのネットワークリクエストがゼロであることを確認してください。
類似度のパーセンテージは何を意味しますか？
類似度は 変更なしトークン / max（元のテキストの総トークン数、変更後の総トークン数） として計算されます。100% は前処理オプション（大文字小文字の折りたたみ、空白の折りたたみ、行トリム）適用後に 2 つの入力が同一であることを意味します。0% は入力間で共有されるトークンがないことを意味します。この指標は編集距離の大まかな近似です — 有用なクイックゲージですが、剽窃や独自性のスコアではありません。
JSON / YAML / XML を意味的に差分できますか？
このツールではできません。これはテキストレベルの差分であるため、データが論理的に同一であってもスペースのみの JSON や XML の整形でも多くの変更が表示されます。JSON のオブジェクトキーの並び替えも、ほとんどのパーサーがキーの順序を無意味とみなしているにもかかわらず変更として表示されます。解析されたオブジェクトツリーを比較してキーの順序と整形を無視する真の意味的な差分については、専用の JSON 差分ツールを計画しています。今のところは、ここに貼り付ける前に両方の入力を同じインデントとキーの順序に正規化してください。
統合表示と並排表示の違いは何ですか？
並排表示は 2 列でレンダリングします：左に元のテキスト、右に変更後、削除された行は左に赤でハイライト、追加された行は右に緑でハイライトされます。変更なしの行は両列の同じ行に揃えて表示されます。統合表示は 1 列でレンダリングし、削除された行に − プレフィックスと赤い背景、追加された行に + プレフィックスと緑の背景を付けます — ターミナルに git diff が出力するのと同じレイアウトです。結果をパッチファイルとしてコピーしたり、コードレビュースレッドに貼り付けたりする場合は統合表示を使います。何が何に置き換えられたかの視覚的なアライメントが生のパッチテキストより重要な場合は並排表示を使います。
左に変更前、右に変更後を貼り付け、ビューと粒度を選ぶと比較がミリ秒で表示されます。ライブモードをオンにすると、どちら側を編集しても差分がキーストロークごとに再実行されます。結果を git apply が直接使用できる標準の統合 .patch ファイルとしてダウンロードできます。アップロードなし、アカウントなし、ベンダーの API キーなし、クォータなし。