Rustベースのコンテンツ認識diffツールOmniDiffの性能と活用方法

関数の位置を移動しただけなのに、レビュー画面では削除と追加が長く並び、画像変更は「ファイルが変更されました」という1行で終わってしまうことがあります。このような場合、変更行数よりも、何が変わったのかを素早く把握する方が重要です。

Rustで開発されたOmniDiffは、コードの構文構造を比較し、画像・フォント・PDFにはそれぞれの形式に合わせた比較手法を適用します。公式ドキュメントと公開デモを基に、既存のGitワークフローでどのように活用できるかを見ていきます。 ¹

OmniDiffの中核技術：Rustベースの構造認識と非テキストファイルサポート

コード比較における構造的認識 OmniDiffは、C、C++、Go、Python、Rust、TypeScriptなど合計25言語のソースコードをTree-sitterパーサーを通じて構文ツリーとしてパースします ², ¹。ここでの中核となる技術は、APTED（Advanced Post-order Traversal Edit Distance）ツリーdiffアルゴリズムの効率的な実装です ³。従来のテキストベースのdiffでは移動したコードを「削除後の挿入」と認識する一方、OmniDiffは構文ツリーの構造変化を解析することで、コードが実際に移動（Moved）されたことを識別できます ³。

ソースコードの言語は拡張子によって検出されます。一方、非テキストファイルはファイル名ではなく実際のバイトデータによって形式を識別します。この2つの経路を区別することが、サポート範囲を正確に理解するために重要です。 ¹

非テキストファイルの内容単位での解析 テキストコードを除くバイナリファイルについては、コンテンツの特性に応じて以下のように比較を行います ², ¹, ⁴。

• 画像: PNG、JPEG、GIFなどの画像をピクセル単位で比較します。特にアニメーションGIFの場合は、フレーム数の増加（例：5個から7個へ増加）やフレーム別の変更点を具体的に報告します ², ⁴。
• フォント: TrueType、OpenType、WOFF2などのフォントファイルからグリフをレンダリングし、特定のアイコン（例：U+0021）のピクセル変更率やメトリクスの変化を追跡します ¹, ⁴。
• アーカイブ: ZIP、JAR、EPUB、Office文書（ODT）などのコンテナ形式のファイル内部構造を開き、変更されたコンポーネントのみを抽出して解析します。ネストされた圧縮ファイルもコンポーネントごとに比較します ², ⁴。
• PDF: ページをレンダリングして視覚的な変更点を識別し、メタデータの変更とページレンダリングの差分を区別して記録します ², ⁴。

実測パフォーマンスベンチマーク：処理速度と精度

以下の数値は、プロジェクト開発者が公開した測定結果です。本記事で独自に再測定を行ったものではありません。比較対象やデータセットが異なれば結果も変わります。

Hacker Newsの議論で、開発者はDifftasticと共通してサポートしているコード事例の比較数値を共有しました。このデータによると、OmniDiffの中央値（p50）処理速度は4msで、Difftasticの35msより約8倍以上速いことが示されています ³。

Difftasticとサポート範囲が重複するコード変更に限って比較した場合、OmniDiffは人間による判断基準と「完全に一致（perfect）」する割合が90%で、Difftasticの64%よりも高い精度を示しています ³。

上記の90%は、Difftasticとサポート範囲が重複する比較に限定された数値です。GeekNewsにまとめられた別の全コード精度評価では、--minimal 基準の完全一致率は69.6%と示されています。これらの2つの数値を同じ評価結果として読み取るべきではありません。 ²

現在の誤差は、マッチングアルゴリズム自体よりも、画面に変更点をどのようにハイライト表示するかというレンダリングルールに主に起因しています ²。

開発者ワークフロー統合：TUI、CLIおよびエディター連携

OmniDiffは対話型ターミナルUI（TUI）とスクリプト用平文出力の両方をサポートしており、さまざまな開発環境に柔軟に適用できます。

バージョン管理システム（Git、Jujutsu）連携 対話型Gitビューアは omnidiff git configure で設定した後に git difftool で開きます。GIT_EXTERNAL_DIFF=omnidiff git diff は平文出力用連携です ², ¹。単に git diff と入力した場合は、ページャー環境では対話型TUIが起動せず、平文モード（headless mode）で結果が出力されます ², ¹。Jujutsu（jj）の場合は、専用設定ウィザードを通じてファイル別呼び出し（file-by-file）モードで構成することで、言語検出機能を完全に利用できます ², ¹。

インストール後、2つのファイルを直接比較したり、Git設定ウィザードを実行したりできます。ウィザードでは、現在のリポジトリかグローバル適用範囲かを選択します。 ¹

omnidiff BEFORE AFTER
omnidiff git configure
git difftool

出力形式およびレビューツール

• ターミナルビューア（TUI）：ライトテーマとダークテーマをサポートしており、24ビットカラーやターミナルグラフィックプロトコル（kitty、sixelなど）を通じて画像を実画像として画面に表示します ², ¹。
• 自動化／スクリプト：--headless は平文を出力し、標準出力がターミナルでない場合にもこのモードに切り替わります。JSON出力は別途 omnidiff --mode json BEFORE AFTER を使用します ², ¹。
• ブラウザレビュー：まだ v0.0.0 段階の初期版である codereview プロジェクトを通じて、Webブラウザ環境でのレビューも可能です ², ¹。

エディタープラグイン VS CodeおよびNeovim用プラグイン（omnidiff-vscode、omnidiff.nvim）が提供されており、Open VSXを通じてCursorやVSCodiumなどでもインストール・利用が可能です ², ¹。

OmniDiffの技術的制限とプロジェクト現状

コンテンツを比較するビューアと、マージ競合を解決するツールは区別する必要があります。 最も代表的な課題は、3方向マージ（3-way merge）をサポートしていない点です。APTEDアルゴリズムは基本的に2方向比較に最適化されているため、マージ競合（conflict）解消用の3方向diff機能は、開発者が今後解決したいと表明している課題です ³。 READMEでは、開発速度を維持するために現在外部コントリビューションを受け付けていないと説明されています ², ¹。開発過程ではAIエージェント（Claude Code）を活用しており、AGPL-3.0-onlyライセンスを採用しています ², ¹。まず公開デモで自分がよく見る変更タイプを確認し、慣れ親しんだ2つのファイルで結果を比較してみるのがよいでしょう。コード移動や画像・フォント変更が頻繁なリポジトリなら、一般的な行単位の比較とどのような違いがあるのかを確認しやすくなります。