PowerPointの「差分」は、なぜテキストファイルほど簡単ではない？

テキストには「行」という扱いやすい比較単位がある

多くのテキストファイルでは、改行で区切られた「行」を順番のある単位として扱えます。行の移動や大きな書き換えは簡単ではありませんが、「この行が増えた」「この行が消えた」という説明を作りやすいのが大きな特徴です。Gitにも複数のdiffアルゴリズムがありますが、通常のテキスト比較では行ベースの分析が土台になります。

PowerPointでは、レビューしたい単位が最初から1種類ではありません。スライド、テキストボックス、文章、数値、画像、図形、配置、書式、発表者ノートなど、同じ資料の中に異なる種類の変更が混在します。

PPTXは「1つの文書」ではなく、複数パーツがつながったパッケージ

MicrosoftのOpen XML資料では、Open XMLファイルはZIPアーカイブに格納され、複数のドキュメントパーツと、それらを結ぶリレーションシップで構成されます。PresentationMLでは、スライドごとにSlide partがあり、さらにSlide Layout、Slide Master、Theme、Notesなどのパーツが関係します。

そのため、PPTXをZIPとして展開してXMLファイル同士をそのまま比較することはできますが、それだけで「資料として何が変わったか」が分かるとは限りません。人が見たいのは、どのスライドで文章や数値が変わったか、画像が差し替わったか、配置や書式が変わったか、といった意味上の差分だからです。

差分を取る前に「どのスライド同士を比べるか」を決める必要がある

たとえば10枚の資料の2枚目に新しいスライドを1枚追加すると、変更後の3枚目は変更前の2枚目に相当します。スライド番号だけで1対1に比較すると、その後の多くのスライドがすべて「変更あり」に見えてしまいます。削除や並べ替えでも同じ問題が起きます。

PPTX内部のスライドIDも手掛かりになりますが、同じ資料の改訂間で役立つことはあっても、別ファイル間で常に一意な対応キーとして扱えるわけではありません。PPTX Diffでは、スライド番号やIDだけに頼らず、構造や内容などの証拠も組み合わせて変更前後の対応スライドを探し、「変更なし / 変更あり / 追加 / 削除 / 移動 / 要確認」といった状態へ整理します。ここで対応付けを間違えると、その後の文章差分や画像差分が正しくても、比較全体としては役に立ちません。

同じスライドでも、差分は1種類ではない

対応するスライドが決まっても、次は「何が変わったか」を分ける必要があります。文字列の変更と、数値だけの変更はレビュー上の意味が違います。画像の差し替え、オブジェクトの追加、位置やサイズの変更、色やフォントなどの書式変更、発表者ノートの変更も別々に見たいことがあります。

Browser KittyでPPTX Diffを作るときは、こうした変更をSemantic Diffとして分類し、差分一覧では人が確認しやすい単位に寄せました。ここでいうSemantic Diffは文章の「意味」だけを指す言葉ではなく、PPTXの構造から取得できる配置や基本書式の差分も含め、本ツールでレビュー対象を整理するための呼び方です。PPTX内部で何バイト変わったかではなく、「資料として何が変わったか」に近づけるためです。

Semantic Diffだけでも、Visual Compareだけでも足りない

意味上の差分だけを見ると、文章が同じまま位置が少しずれた、文字色が変わった、画像が大きくなった、といった見た目の変化を見落としやすくなります。逆に、スライドを画像化してピクセル差分だけを見ると、「123」が「128」になったような重要な数値変更と、アンチエイリアスやレンダリング差を同じ種類の差として扱いやすくなります。

そのためPPTX Diffでは、差分判定はSemantic Diffを基準にしつつ、高精細プレビューを横並び・重ね合わせ・分割・点滅で確認できるVisual Compareを別に持たせています。構造と意味で「何が変わったか」を探し、見た目で「実際にどう見えるか」を確認する役割分担です。

自動判定できないものを、無理に「変更あり」と断定しない

PowerPointにはグラフ、SmartArt、アニメーション、画面切り替え、複雑なグループや効果などがあります。PPTX Diffでも、すべてを同じ粒度で安全に詳細比較できるわけではありません。たとえばグラフの変更を項目単位で詳細比較できない場合は、無理に正確そうな説明を作らず「要確認」として残し、見た目はVisual Compareで確認する設計にしています。

差分ツールでは「何か答えを返す」ことより、「自動判定できる範囲とできない範囲を分ける」ことの方が重要な場合があります。PowerPointのように構造と見た目の両方を持つ形式では、その境界が特に大きくなります。

PPTX Diffを作って分かったのは、「差分」は1回の比較ではなく段階的な判断だということ

ここまでの内容を実装順に並べると、「PPTXを読む → 対応スライドを探す → Semantic Diffで変更を整理する → Visual Compareで見た目を確認する」という流れになります。後ろの判定ほど前の段階に依存するため、対応付けを誤れば、その後の差分が正しくてもレビュー結果全体は崩れます。

テキストファイルのdiffが簡単という意味ではありません。ただ、PowerPointでは比較対象そのものを人が理解する単位へ組み直す工程が必要です。PPTX Diffを実装して一番大きかった学びは、まさにそこでした。

注意点

• PPTXをZIP展開してGitで管理すること自体はできますが、内部XMLの差分量と、人がレビューしたい変更量は一致しません。用途に応じて、専用の比較表現へ変換してから見る考え方が必要です。
• スライドのスクリーンショット比較だけでも、意味上の差分は十分には分かりません。特に小さな数値変更や発表者ノートは、見た目だけでは見落としやすい変更です。
• Visual Compareの描画は確認用です。PowerPoint本体と完全に同じレンダリングを保証するものではなく、複雑な効果やSmartArtなどでは差が出る場合があります。