# オンライン テキスト＆コード差分比較ツール（Diff Checker）：技術アーキテクチャと詳細実践ガイド

ソースコード、構造化スキーマ（JSON / YAML）、設定マニフェスト、データベース定義（DDL）、法務契約書の差分比較（Diffing / テキスト差分比較）は、現代のソフトウェアエンジニアリング、DevOps自動化、セキュリティ監査、コンプライアンス運用において最も基盤となる日常的作業です。GitHubのプルリクエスト（PR）レビューから、マルチステージ環境間における構成ドリフト（Configuration Drift）の検出、秘密鍵や環境変数の安全な監査に至るまで、差分検出にはミリ秒単位の高速処理とコードポイント精度の厳密な数学的正確性が求められます。

ToolsAA オンライン テキスト＆コード差分比較ツール（Online Diff Comparator） は、Webブラウザ上でネイティブに動作する高機能なテキスト差分チェッカー（Text Diff Checker）、左右2画面のコード比較ビューア（Side-by-Side Diff Viewer）、およびGit / POSIX標準準拠のユニファイドパッチ生成エンジンです。本ツールは厳格なゼロナレッジ（Zero-Knowledge / ゼロ知識）設計を採用しており、すべてのデータ処理はクライアントブラウザのローカルメモリ内で100%完結します。外部サーバーへのテキスト送信、クラウドAPI通信、アクセスログ収集、トラッキングは一切発生しません。

本ガイドでは、差分アルゴリズムの標準規格である Eugene Myers の $O(ND)$ アルゴリズムの数学的原理から、ブラウザ内での超高速処理を支えるWeb APIアーキテクチャ、実践的な操作ワークフロー、TypeScript・JavaScript・Python 3.11+ による完全なプロダクション実装コード、開発現場で頻出するエッジケースのトラブルシューティングまでを包括的かつ詳細に解説します。

# 包括的概要と実践的なユースケース

テキストおよびソースコードの差分比較ツールは、比較元のドキュメント（Original）を変更後のドキュメント（Modified）へと変換するために必要な「最小の編集手順（最短編集スクリプト：Shortest Edit Script）」を数学的に特定します。人間が視覚的に斜め読みして変更点を推測するのとは異なり、アルゴリズムによるコンパレータは、行の削除、挿入、置換、そして行内の単語単位・文字単位の微細な調整をコードポイント精度で正確に分離・視覚化します。

[ 元ドキュメント (Original) ]             [ 変更後ドキュメント (Modified) ]
         \                                       /
          v                                     v
+-------------------------------------------------------------+
|        ToolsAA ブラウザ内差分比較エンジン（Diff Engine）      |
|  - ネットワーク送信ゼロ（100% クライアントサイド実行）       |
|  - 正規化処理（CRLF -> LF、Unicode NFC、空白の正規化）       |
|  - O(ND) Eugene Myers 差分グラフ探索アルゴリズム            |
|  - 高精度インライン・トークナイザー（\p{L}\p{N} 正規表現）   |
+-------------------------------------------------------------+
               |                               |
               v                               v
   [ 左右分割表示 (Split View) ]   [ 統合パッチ (POSIX/Git Unified) ]

# エンジニアリングおよびエンタープライズ現場での主要ユースケース

• プルリクエスト（PR）のステージング前ローカル監査: リモートのGitリポジトリ（GitHub / GitLab / Bitbucket）にコミットをプッシュする前に、変更差分をローカルブラウザ上で安全に事前検証します。左右分割表示（Side-by-Side Split View）により、ブランチの切り替えやターミナルでの git diff を繰り返すことなく、変数名のリファクタリング、インポート文の再編成、ロジックの意図しない変更を瞬時に確認できます。
• ゼロトラスト環境におけるIaCマニフェスト・秘密鍵監査: KubernetesのHelmチャート、Terraform設定、Docker Composeマニフェストについて、ステージング環境と本番環境間の構成差異を比較します。インフラ設定ファイルには、内部データベースの接続文字列、プライベートネットワーク構成、APIトークンなどの機密情報が含まれることが多く、外部クラウドサービスへのデータ送信を避けることが必須のセキュリティ要件となります。
• データベースマイグレーションとSQL実行計画の最適化: DDLスクリプト、テーブル定義マイグレーション、および EXPLAIN ANALYZE 実行計画の出力を比較し、インデックス変更やクエリの書き換えによって検索条件やスキャン順序が意図通りに維持されているかを検証します。
• JSON APIレスポンスおよびスキーマドリフトの検知: マイクロサービス間のREST APIやGraphQLレスポンスペイロードを比較し、予期しないプロパティの削除、データ型の変更、ネスト構造の破壊を即座に特定します。
• 法務契約書・NDA・利用規約の改版履歴監査: 機密保持契約（NDA）やサービス利用規約（Terms of Service）の改定案を単語レベルで比較します。賠償責任の上限額の変更、免責事項の修正、契約解除通知期間の短縮など、目視確認では見落としやすい重要な文言変更を漏れなくハイライトします。

# クライアントサイド処理（ローカル実行）がプライバシー保護に不可欠な理由

旧来のオンライン差分ツールの多くは、ユーザーが入力したテキストをHTTP POSTリクエストで外部サーバーへ送信し、バックエンドのLinuxコマンド（GNU diff 等）で処理した結果をブラウザに返送する構成を採用していました。このレガシーなアーキテクチャは、現代の開発環境において深刻なセキュリティリスクを引き起こします。

• 知的財産・ソースコードの外部流出: 自社独自のアルゴリズム、未発表プロダクトのコード、特許関連ロジックが公衆ネットワークを経由して第三者のサーバーに送信されます。
• サーバーログおよび永続ストレージへの意図しない残留: クラウドサーバーのアクセスログ、キャッシュディレクトリ、エラー追跡システム（Sentry等）に送信データが平文で保存され、SOC 2、ISO 27001、GDPR、HIPAAなどのコンプライアンス要件に抵触する恐れがあります。
• 認証情報・クレデンシャルの誤送信: 環境変数ファイル（.env）を比較する際、AWSアクセスキー、SSH秘密鍵、APIトークン、本番DBパスワードなどが誤って第三者インフラにアップロードされてしまう事故が頻発しています。

ToolsAAのテキスト差分比較ツールは、完全なゼロサーバー処理モデル（Zero-Server Processing Model）を採用しています。ToolsAA上でテキストを比較する際、テキストの正規化、トークナイゼーション、Myers行列探索、DOMの差分ハイライト処理はすべて、お使いのブラウザ内部のJavaScriptエンジン（V8やJavaScriptCore）で実行されます。データを含むパケットは端末から1バイトも送信されないため、完全なデータ主権（Data Sovereignty）が保証されます。

# 技術アーキテクチャと内部動作原理

シーケンス比較の数学的本質は、最長共通部分列（LCS: Longest Common Subsequence）問題の解決にあります。これは、変換に必要な編集操作の最小数を求める最短編集スクリプト（SES: Shortest Edit Script）問題と数学的に双対関係にあります。

# 1. Eugene Myers による $O(ND)$ 差分アルゴリズム

GitやGNU diffなどの標準的なバージョン管理ツールは、Eugene W. Myersが1986年に発表した論文（An O(ND) Difference Algorithm and Its Variations）に記載されたアルゴリズムを採用しています。長さ $N$ の元の系列 $A$ と、長さ $M$ の変更後の系列 $B$ が与えられたとき、Myersアルゴリズムは比較問題を $(N+1) \times (M+1)$ のグリッド座標からなる有向編集グラフ（Edit Graph）上の最短経路探索へと写像します。

        (0,0) ---- 水平移動（削除: コスト1） ----> (x+1, y)
          |    \
          |     \
          |      \ 対角移動（スネーク・一致: コスト0）
          |       \
垂直移動（挿入: コスト1） \
          |         v
          v       (x+1, y+1)
       (x, y+1)

編集グラフ上の各エッジの意味とコストは以下の通りです。

• 水平移動 $(x, y) \to (x+1, y)$: 系列 $A$ の要素 $A[x+1]$ の削除。編集コスト = 1。
• 垂直移動 $(x, y) \to (x, y+1)$: 系列 $B$ の要素 $B[y+1]$ の挿入。編集コスト = 1。
• 対角移動 $(x, y) \to (x+1, y+1)$: 要素の一致（$A[x+1] == B[y+1]$）。編集コスト = 0（スネーク / Snake）。

探索の目的は、原点 $(0, 0)$ から終点 $(N, M)$ に至る経路のうち、非対角移動（編集操作）の合計回数である編集距離 $D$ が最小となる経路を特定することです。

# 対角線インデックス $k$ と偶奇性定理

Myersアルゴリズムの核心的な数学的洞察は、編集グラフ上の座標を対角線番号 $k = x - y$ （$k \in [-M, N]$）によってパラメータ化することにあります。

• 各編集操作（水平方向の $+1$ または垂直方向の $+1$）により、対角線番号 $k$ は必ず $+1$ または $-1$ 変化します。
• したがって、$D$ 回の編集操作を行った時点で到達可能な対角線 $k$ は、$-D \le k \le D$ の範囲に限定され、かつ $k$ と $D$ は同一の偶奇性（$k \equiv D \pmod 2$）を持ちます。
• 対角線 $k$ 上での最遠到達点の $x$ 座標を配列 $V[k]$ に保持するとき、ステップ $D$ における漸化式は以下の通りです。

$$x = \max(V[k-1] + 1, V[k+1])$$

• $x$ が定まった後、後続要素が一致する限り対角線に沿って進む（スネーク移動：$A[x+1] == B[y+1] \implies x \leftarrow x+1, y \leftarrow y+1$）ことで、コスト $D$ を消費せずに到達点を可能な限り前進させます。

Myersアルゴリズムの時間計算量は $O(ND)$、空間計算量は $O(N+M)$ です。変更点 $D$ が全体の行数 $N$ に対して非常に小さい一般的なコード差分（$D \ll N$）では、計算は数ミリ秒以内で瞬時に完了します。

# 2. 計算量爆発を防ぐ3つのアルゴリズム・セーフガード

完全に異なる2つのドキュメントを比較する場合、編集距離 $D$ は $N+M$ に近づき、最悪計算量は $O(N \cdot (N+M)) \approx O(N^2)$ へと悪化します。ブラウザのUIスレッドがフリーズして60 FPSの応答性を損なうのを防ぐため、ToolsAAのエンジンは以下の3段階の最適化セーフガードを実装しています。

1. 線形プレフィックス/サフィックス刈り込み（$O(K)$）: グラフを構築する前に、両ドキュメントの先頭および末尾で完全に一致する行を線形走査で即座に除外し、探索対象の行列サイズを最小化します。
2. 探索深度の動的制限（Bounded Exploration）: 残余行列の積 $N \times M > 300,000$ または $N + M > 1,200$ の場合、最大探索深度を $D_{\max} = 400$ にキャップし、計算が爆発する前に高速アンカーマッチングへフォールバックします。
3. 線形アンカーマッチング（$O(N+M)$）: 系列 $B$ の行に対するハッシュマップを構築し、60行の探索ウィンドウ内で共通のアンカー行を特定します。これにより、2次関数的なバックトラッキングを行わずにブロック単位の一致を線形時間で決定します。

# 3. 多段階トークナイゼーションとネイティブWeb API

• 行レベルの粒度（Line-Level）: 改行文字（\n）で分割します。ソースコード全体の変更箇所の把握やコミットレビューに最適です。
• 単語レベルの粒度（Word-Level）: Unicodeプロパティエスケープ（Unicode Property Escapes）を用いた正規表現 (\s+|[\p{L}\p{N}]+|[^\s\p{L}\p{N}]+) を使用します。日本語の漢字・ひらがな・カタカナ、英数字、記号を正確にトークン化し、行内の微細な修正を視覚的に特定します。
• 文字レベルの粒度（Character-Level）: JavaScriptの標準イテレータ構文（Array.from(str)）を使用して文字列を分解します。これにより、UTF-16サロゲートペア（絵文字、特殊記号、異体字セレクタ）のバイト分断を防ぎ、文字化けを起こさずに1文字単位の差分を正確に比較します。
• ブラウザネイティブWeb APIの最適化: ファイル入力にはローカルファイルをネットワーク送信なしで高速展開する FileReader APIを採用し、グラフ探索時のガベージコレクション（GC）負荷をゼロにするために型付き配列 Int32Array を活用しています。さらに、React 18の useDeferredValue フックによってユーザーのキー入力と重い差分計算を並行処理し、入力ラグを完全に排除しています。

# 4. POSIX標準規格およびGitユニファイドパッチ（Unified Patch）仕様

本ツールが生成するパッチは、POSIX.1-2008およびGitの仕様に完全準拠しています。ハンクヘッダー（Hunk Header）の形式は以下の通りです。

@@ -l,s +l,s @@

• -l,s: 元ファイル（Base）における変更ブロックの開始行番号 $l$ と、対象行数 $s$。
• +l,s: 変更後ファイル（Target）における変更ブロックの開始行番号 $l$ と、対象行数 $s$。
• コンテキスト行（デフォルト: 前後3行）: 変更箇所の前後に元の行を保持することで、適用先端のファイルで行番号が前後していても、git apply や UNIX patch コマンドが変更箇所を正確に特定してパッチを適用できるように設計されています。

# ステップ・バイ・ステップ実践チュートリアル

# ステップ 1: データの入力と読み込み

• テキストの直接貼り付け: 比較元のテキストを左側のエディタ（Original）、変更後のテキストを右側のエディタ（Modified）にペーストします。
• ローカルファイルのアップロード: パネル上部の ファイルを選択（Upload File）ボタンをクリックし、ローカルのソースコードファイル（.ts, .js, .json, .sql, .py, .txt, .md 等）を直接読み込みます。ファイルはブラウザの FileReader APIを介してメモリ上に即座に展開され、外部サーバーへは一切アップロードされません。
• サンプルプリセットの活用: 上部に用意されたプリセット（TypeScriptコンポーネント、JSON設定ファイル、技術記事テキスト、SQLクエリ）をクリックすることで、典型的な差分パターンの表示例を即座に確認できます。

# ステップ 2: 表示モードの選択

• 左右分割表示（Split View）: 2つのパネルを左右並列で同期スクロール表示します。左パネルに削除行が赤色のハイライト、右パネルに追加行が緑色のハイライトで明瞭に分離表示されます。
• 統合インライン表示（Unified View）: 変更箇所を1つのタイムラインに統合し、変更前後の行を +（追加）および -（削除）の記号とともに時系列で表示します。ターミナルの git diff コマンドの出力形式に慣れている開発者に最適です。

# ステップ 3: 比較粒度と正規化オプションの設定

• 比較粒度（Granularity）:
• 単語単位（Word）: 行内の変更箇所をインラインでハイライト（推奨デフォルト）。
• 行単位（Line）: 関数やブロックの追加・削除など構造的な変更の把握に最適。
• 文字単位（Character）: ハッシュ値、APIトークン、暗号鍵などの微細な1文字の差異を検出。
• 空白の扱い（Whitespace）:
• すべて保持（Preserve All）: インデントの差異も厳密に検知（PythonやYAMLに必須）。
• 行頭・行末を無視（Trim Leading/Trailing）: インデントや末尾スペースの変更を無視。
• 空白を完全に無視（Ignore All）: テキスト本文の内容のみを純粋に比較。
• 大文字・小文字の区別（Case Sensitivity）: SQLキーワードやケースインセンシティブな設定比較では 大文字小文字を無視（Ignore Case） を有効にします。

# ステップ 4: 差分ナビゲーションとパッチのエクスポート

• 差分ナビゲーター: 画面上部の 前の差分（Previous Diff） および 次の差分（Next Diff） ボタンを使用して、変更ブロック間をキーボード感覚で高速ジャンプします。
• ユニファイドパッチのコピー: パッチをコピー（Copy Patch） をクリックすると、Git準拠のユニファイドパッチテキストがクリップボードに格納されます。
• ファイルとしてダウンロード: パッチをダウンロード を選択すると、そのままCI/CDパイプラインや端末で使用できる .diff または .patch ファイルとしてローカルに保存されます。

# プロダクション対応の実装コード

# 1. モダンTypeScript実装（Browser & Node.js両対応）

ブラウザのJavaScriptエンジンおよびNode.js環境で動作する、型安全なEugene Myers $O(ND)$ 差分アルゴリズムとユニファイドパッチ生成エンジンです。Int32Array によるメモリ最適化と正確なバックトラッキングを備えています。

export type DiffOp = "equal" | "delete" | "insert";

export interface DiffItem {
  op: DiffOp;
  val: string;
}

/**
 * Eugene Myers の O(ND) 差分アルゴリズム（TypeScript）
 * @param a 元の系列（行またはトークンの配列）
 * @param b 変更後の系列（行またはトークンの配列）
 * @returns 最小編集操作の配列
 */
export function myersDiff(a: string[], b: string[]): DiffItem[] {
  const n = a.length;
  const m = b.length;
  const max = n + m;
  
  // 対角線 k = x - y を追跡するための型付き配列（GC負荷を極小化）
  const v = new Int32Array(2 * max + 1);
  const trace: Int32Array[] = [];

  // 最短編集距離 D を 0 から max まで探索
  for (let d = 0; d <= max; d++) {
    trace.push(new Int32Array(v));
    for (let k = -d; k <= d; k += 2) {
      // 垂直移動（挿入）または水平移動（削除）を選択
      let x = (k === -d || (k !== d && v[k - 1 + max] < v[k + 1 + max]))
        ? v[k + 1 + max]
        : v[k - 1 + max] + 1;
      let y = x - k;

      // スネーク（一致する要素に沿ってコスト0で対角線を進む）
      while (x < n && y < m && a[x] === b[y]) {
        x++;
        y++;
      }
      v[k + max] = x;

      // 終点 (n, m) に到達した時点で探索完了
      if (x >= n && y >= m) {
        d = max + 1;
        break;
      }
    }
  }

  // バックトラッキングによる編集パスの復元
  let x = n;
  let y = m;
  const diff: DiffItem[] = [];

  for (let d = trace.length - 1; d >= 0; d--) {
    const vPrev = trace[d];
    const k = x - y;
    const prevK = (k === -d || (k !== d && vPrev[k - 1 + max] < vPrev[k + 1 + max]))
      ? k + 1
      : k - 1;
    const px = vPrev[prevK + max];
    const py = px - prevK;

    // スネーク区間の復元（一致）
    while (x > px && y > py) {
      x--;
      y--;
      diff.push({ op: "equal", val: a[x] });
    }

    if (d > 0) {
      if (x === px) {
        // 垂直移動（挿入）
        y--;
        diff.push({ op: "insert", val: b[y] });
      } else {
        // 水平移動（削除）
        x--;
        diff.push({ op: "delete", val: a[x] });
      }
    }
    x = px;
    y = py;
  }

  // 逆順で構築された履歴を正規順に並び替え
  return diff.reverse();
}

/**
 * POSIX / Git 準拠のユニファイドパッチ（Unified Diff）文字列を生成
 */
export function toUnifiedPatch(diff: DiffItem[], fileNameA = "a.txt", fileNameB = "b.txt"): string {
  let patch = `--- ${fileNameA}\n+++ ${fileNameB}\n@@ -1,${diff.length} +1,${diff.length} @@\n`;
  for (const item of diff) {
    const prefix = item.op === "equal" ? " " : item.op === "delete" ? "-" : "+";
    patch += `${prefix}${item.val}\n`;
  }
  return patch;
}

# 2. モダンJavaScript（ES2022 / Web Worker）バックグラウンド処理実装

巨大なドキュメントを比較する際、ブラウザのUIスレッドを一切ブロックさせないためのWeb Worker実装です。バックグラウンドスレッドで差分計算を実行し、UIの60 FPSのスムーズな描画を維持します。

// diff-worker.js: ブラウザのバックグラウンドスレッドで動作する差分計算ワーカー
self.onmessage = function (e) {
  const { textA, textB, granularity = "word" } = e.data;

  // 1. 改行コードの標準化（CRLF / CR -> LF）
  const normalize = (str) => str.replace(/\r\n/g, "\n").replace(/\r/g, "\n");
  const cleanA = normalize(textA);
  const cleanB = normalize(textB);

  // 2. 粒度に応じた高速トークナイゼーション
  let tokensA, tokensB;
  if (granularity === "line") {
    tokensA = cleanA.split("\n");
    tokensB = cleanB.split("\n");
  } else if (granularity === "character") {
    tokensA = Array.from(cleanA);
    tokensB = Array.from(cleanB);
  } else {
    // 単語レベル: Unicodeプロパティ正規表現による分割
    const wordPattern = /(\s+|[\p{L}\p{N}_]+|[^\s\p{L}\p{N}_]+)/gu;
    tokensA = cleanA.match(wordPattern) || [];
    tokensB = cleanB.match(wordPattern) || [];
  }

  // 3. Myersアルゴリズムの実行
  const startTime = performance.now();
  const diffResult = executeWorkerDiff(tokensA, tokensB);
  const durationMs = performance.now() - startTime;

  // 4. メインスレッドへの完了通知
  self.postMessage({
    status: "success",
    diff: diffResult,
    durationMs: durationMs,
    totalTokens: tokensA.length + tokensB.length
  });
};

function executeWorkerDiff(a, b) {
  const n = a.length, m = b.length, max = n + m;
  const v = new Int32Array(2 * max + 1);
  const trace = [];

  for (let d = 0; d <= max; d++) {
    trace.push(new Int32Array(v));
    for (let k = -d; k <= d; k += 2) {
      let x = (k === -d || (k !== d && v[k - 1 + max] < v[k + 1 + max]))
        ? v[k + 1 + max]
        : v[k - 1 + max] + 1;
      let y = x - k;
      while (x < n && y < m && a[x] === b[y]) { x++; y++; }
      v[k + max] = x;
      if (x >= n && y >= m) { d = max + 1; break; }
    }
  }

  let x = n, y = m;
  const result = [];
  for (let d = trace.length - 1; d >= 0; d--) {
    const vPrev = trace[d];
    const k = x - y;
    const prevK = (k === -d || (k !== d && vPrev[k - 1 + max] < vPrev[k + 1 + max])) ? k + 1 : k - 1;
    const px = vPrev[prevK + max];
    const py = px - prevK;
    while (x > px && y > py) { x--; y--; result.push({ op: "equal", val: a[x] }); }
    if (d > 0) {
      if (x === px) { y--; result.push({ op: "insert", val: b[y] }); }
      else { x--; result.push({ op: "delete", val: a[x] }); }
    }
    x = px; y = py;
  }
  return result.reverse();
}

# 3. モダンPython 3.11+ 実装

Pythonの最新の型アノテーションを活用した、堅牢でクリーンなMyers差分アルゴリズムおよびユニファイドパッチフォーマッターの実装です。

from typing import List, Tuple

def myers_diff(a: List[str], b: List[str]) -> List[Tuple[str, str]]:
    """
    Eugene Myers の O(ND) アルゴリズムを用いた差分計算。
    
    Args:
        a: 比較元の行リスト
        b: 変更後の行リスト
        
    Returns:
        タプルのリスト [('equal'|'delete'|'insert', 内容)]
    """
    n, m = len(a), len(b)
    max_d = n + m
    v = {1: 0}
    trace = []

    for d in range(max_d + 1):
        trace.append(v.copy())
        for k in range(-d, d + 1, 2):
            # 前のステップの最大x座標から最適な移動を選択
            if k == -d or (k != d and v.get(k - 1, 0) < v.get(k + 1, 0)):
                x = v.get(k + 1, 0)
            else:
                x = v.get(k - 1, 0) + 1
            y = x - k

            # 一致する要素がある限り対角線を進む（スネーク）
            while x < n and y < m and a[x] == b[y]:
                x += 1
                y += 1
            v[k] = x

            # 終点到達の判定
            if x >= n and y >= m:
                break
        if v.get(n - m, 0) >= n:
            break

    # バックトラッキングによる最短編集スクリプトの復元
    x, y = n, m
    diff: List[Tuple[str, str]] = []

    for d in range(len(trace) - 1, -1, -1):
        v_prev = trace[d]
        k = x - y
        if k == -d or (k != d and v_prev.get(k - 1, 0) < v_prev.get(k + 1, 0)):
            prev_k = k + 1
        else:
            prev_k = k - 1

        px = v_prev.get(prev_k, 0)
        py = px - prev_k

        # スネーク部分（一致）の回収
        while x > px and y > py:
            x -= 1
            y -= 1
            diff.append(("equal", a[x]))

        if d > 0:
            if x == px:
                y -= 1
                diff.append(("insert", b[y]))
            else:
                x -= 1
                diff.append(("delete", a[x]))
        x, y = px, py

    return list(reversed(diff))

def format_unified_patch(
    diff: List[Tuple[str, str]], 
    file_a: str = "original.txt", 
    file_b: str = "modified.txt"
) -> str:
    """Git apply および patch コマンド互換のパッチ文字列を出力"""
    lines = [
        f"--- {file_a}",
        f"+++ {file_b}",
        f"@@ -1,{len(diff)} +1,{len(diff)} @@"
    ]
    for op, val in diff:
        prefix = " " if op == "equal" else ("-" if op == "delete" else "+")
        lines.append(f"{prefix}{val}")
    return "\n".join(lines) + "\n"

# 開発者が直面する落とし穴とエッジケースのトラブルシューティング

# 1. CRLF（Windows）とLF（Unix/macOS）の改行コード不一致

• 現象: Windows環境とLinux環境で作成されたファイルを比較すると、視覚的には全く同一のコードであるにもかかわらず、ファイル内の全行が変更行としてハイライトされる。
• 原因: Windowsは行末にCRLF（\r\n）、Unix系OSはLF（\n）を使用します。バイナリレベルでは各行末にキャリッジリターン（\r）が存在するため、文字列一致判定がすべて不一致となります。
• 解決策: ToolsAAのエンジンは、差分行列を生成する前処理として .replace(/\r\n/g, "\n").replace(/\r/g, "\n") を自動実行し、改行コードをLFへ一貫して正規化します。

# 2. Unicode正規化形式の相違（NFC vs. NFD）

• 現象: 日本語の濁点・半濁点付き文字（例: 「が」「パ」）や、欧州言語のアクサン記号（例: é）を含む行で、見た目が同じなのに差分として検出される。
• 原因: macOSのファイルシステム（HFS+やAPFS）や一部の入力システムはUnicode NFD（結合分解形式: 「カ」＋「゛」）を採用する一方、LinuxやWindows、標準的なWeb環境はNFC（結合合成形式: 「ガ」）を採用します。コードポイントが異なるため、単純比較では不一致となります。
• 解決策: 入力文字列に対して比較前に String.prototype.normalize('NFC') を適用し、コードポイントを標準合成形式へ統一します。

# 3. 不可視文字（ゼロ幅スペース・BOM）およびBiDi（双方向）攻撃

• 現象: コピペしたコードで見た目は一文字も変わっていないのに、特定の行だけが差分判定される。またはコンパイラが構文エラーを吐く。
• 原因: Webページやチャットツールからコピーした際に、ゼロ幅スペース（Zero-Width Space: U+200B）やBOM（Byte Order Mark: U+FEFF）が混入しています。さらに悪質なケースでは、Right-to-Left Override（U+202E）を利用したトロイの木馬ソースコード（Trojan Source）が隠蔽されている場合があります。
• 解決策: ToolsAAのレンダラーは、不可視文字や制御コードを検知した際、[ZWSP]、[BOM]、[RLO] などの視覚的バッジとして画面上に明示的に描画し、開発者へ警告します。

# 4. キー順序が未ソートのJSONオブジェクト比較

• 現象: 2つのJSON APIレスポンスで保持しているデータ値は完全に同等であるにもかかわらず、巨大な差分がレポートされる。
• 原因: 行ベースの比較器はテキストの行順序を厳密に比較しますが、JSONの仕様上、オブジェクト内のキー順序は無意味です。キーの出現順序が異なると、論理的に等価であってもテキスト差分として判定されます。
• 解決策: 比較前にJSONをパースし、キーを再帰的にアルファベット順でソート（Object.keys().sort()）した上で整形再シリアライズ（Pretty-Print）してから比較を行います。

# 5. 巨大な単一行（圧縮・Minifyされたファイル）によるメモリ圧迫

• 現象: 圧縮されたJavaScriptバンドルや巨大な1行のJSONを比較すると、ブラウザのCPU使用率が跳ね上がり、動作が極度に重くなる。
• 原因: 1行が数万文字に及ぶ場合、単語レベルのトークナイザーが生成するトークン配列が巨大化し、ブラウザのメインスレッドを占有します。
• 解決策: ToolsAAでは、1行あたりのインライン・トークナイゼーションの上限を5,000文字に制限し、これを超える場合は安全に行単位比較へ切り替えるフェイルセーフを設けています。さらにReact 18の useDeferredValue により、レンダリング負荷をバックグラウンドへ逃がしています。

# FAQ：開発者からよくある質問

# Q1: ToolsAAはなぜコードや機密情報が外部サーバーへ送信されないと言い切れるのですか？

回答: ToolsAAは、Next.jsのクライアントコンポーネント（"use client"）として完全にブラウザ内部で動作するように実装されています。テキストの正規化、トークン化、Myersアルゴリズムによる差分行列計算、DOMの描画処理に至るまで、すべての演算はお使いの端末のJavaScriptエンジン（V8やJavaScriptCore）のローカルメモリ上で完結します。バックエンドへの通信エンドポイントは存在せず、アクセス解析ツールによる入力値の収集も一切行っていません。ネットワークを切断した完全なオフライン状態でも全く問題なく動作することをご自身で検証いただけます。

# Q2: Myersアルゴリズムは従来の動的計画法によるLCS（最長共通部分列）アルゴリズムと何が違いますか？

回答: 標準的な動的計画法（DP）によるLCSアルゴリズムは、常に $N \times M$ の全テーブルを構築するため、テキストの類似度に関わらず常に $O(N \cdot M)$ の時間計算量と空間計算量を消費します。一方、Eugene Myersのアルゴリズムは問題を編集グラフの対角線探索（$k = x - y$）へと帰着させ、一致箇所（コスト0）を貪欲に飛び越える「スネーク」移動を優先します。そのため、変更点 $D$ に比例する $O(ND)$ の時間計算量で動作します。大半の行が一致している一般的なコードやドキュメントの比較では $D \ll N$ となるため、従来の動的計画法と比べて桁違いの高速性と省メモリ性能を発揮します。

# Q3: 見た目は全く同じテキストなのに、すべての行が変更扱いになってしまうのはなぜですか？

回答: 最も一般的な原因は、OS間における改行コードの差異（WindowsのCRLF \r\n と、Linux/macOSのLF \n）です。目に見えない末尾の復帰改行文字（\r）が存在するため、プログラム判定ではすべての行が不一致と見なされます。この問題を解消するには、ToolsAAのオプションで 空白の扱い: トリム（Trim Leading/Trailing） を選択するか、自動正規化機能を有効にして入力データをLFに統一してください。

# Q4: 1行に圧縮（minify）されたJavaScriptファイルや巨大なJSONワンライナーも比較できますか？

回答: はい、比較可能です。一般的な行ベースの差分ツールでは、1行のファイルに変更が1箇所でもあるとファイル全体が1つの巨大な変更ブロックとして扱われてしまいます。ToolsAAでは、設定パネルの 比較粒度（Granularity） を「行（Line）」から「単語（Word）」または「文字（Character）」に切り替えることで、改行が存在しないファイルであっても単語単位や識別子単位で細かく分割し、変更された正確な位置をインラインで特定できます。

# Q5: ユニファイドパッチヘッダーの @@ -oldstart,oldlength +newstart,newlength @@ はどのように読み解きますか？

回答: マイナス記号（-）は変更前の元ファイルを指し、oldstart はハンクの開始行番号、oldlength はハンクに含まれる総行数（変更のないコンテキスト行を含む）を表します。プラス記号（+）は変更後のファイルを指し、newstart は変更後の開始行番号、newlength は変更後の総行数を表します。git apply や patch コマンドは、これらの行番号座標と前後のコンテキスト行を照合することで、適用先端のファイルで周辺コードの行位置が多少ずれていても、目的の箇所へ正確に変更をマージできます。

# Q6: ソースコードのレビューと自然言語の文章比較で、推奨される設定はどう異なりますか？

回答: ソースコードの場合は、インデントの変更を検知できるように 粒度: 単語（Word） ＋ 空白: すべて保持（Preserve All） が最適です。一方、Markdown文書、仕様書、法務契約書などの文章比較では、行末の余分なスペースやインデントのゆらぎを無視して純粋な文章内容の変化に集中するため、粒度: 単語（Word） ＋ 空白: トリム（Trim Leading/Trailing） の組み合わせを推奨します。暗号鍵やトークンの比較には 粒度: 文字（Character） を使用してください。

# Q7: 数万行の巨大なファイルをブラウザで比較してもタブがクラッシュしないのはなぜですか？

回答: ToolsAAはブラウザクラッシュを防ぐために多層防御アーキテクチャを採用しています。①最初と最後の完全一致行を線形時間で即座に除外するプレフィックス/サフィックス刈り込み、②差分が大きい場合に計算爆発を防ぐ探索深度制限（$D_{\max} = 400$）とアンカーマッチングへのフォールバック、③オブジェクト生成によるメモリ割り当てとGCを最小限に抑える型付き配列（Int32Array）の利用、④UIの描画優先度を制御するReact 18の useDeferredValue の採用により、タブの応答性を常に維持します。

# Q8: ToolsAAで生成・ダウンロードした .patch ファイルをローカルのGitリポジトリに適用するにはどうすればよいですか？

回答: パッチファイルをダウンロードするか内容をクリップボードにコピーして保存した後、ターミナルで対象のリポジトリのルートディレクトリに移動し、以下の標準コマンドを実行して適用します。

# Git を使用してパッチを適用する場合（推奨）
git apply --ignore-whitespace changes.patch

# UNIX 標準の patch ユーティリティを使用する場合
patch -p1 < changes.patch

# 技術比較マトリクス：モード・粒度・ユースケース

# まとめ

ToolsAA オンライン テキスト＆コード差分比較ツール は、厳密なアルゴリズム工学と徹底したプライバシー保護原則を融合させた、プロフェッショナルエンジニアのための次世代差分プラットフォームです。

Eugene Myers の $O(ND)$ アルゴリズムをブラウザのサンドボックス環境内で極限まで最適化して実行することにより、機密性の高いソースコード、企業インフラの構成定義、社外秘の契約書を一切第三者サーバーに晒すことなく、デスクトップネイティブツールに匹敵する速度と精度で安全に差分を抽出します。

Gitプルリクエストのローカル検証、IaCマニフェストの監査、APIレスポンスのデバッグなど、日々のエンジニアリング業務において、完全なプライバシーと妥協のない計算精度を両立させた安全な差分比較をぜひご活用ください。