PowerPointの深淵へ：VBAによる「改ざん検知・整合性検証」アーキテクチャの構築
PowerPointのファイル形式（.pptx）は、その実態がOpen XMLパッケージであることは周知の事実だ。しかし、オブジェクトレベルでの「改ざん」や「意図せぬ挿入」を検知するとなると、話は急激に複雑化する。
防衛や金融といった極限の現場では、GUI上の「保存」ボタンは単なるトリガーに過ぎない。我々アーキテクチャ設計者は、その背後で「ファイルの状態が定義された正当性（Integrity）を維持しているか」を数学的に検証するゲートキーパーを実装しなければならない。
本稿では、PowerPointの `Application.PresentationBeforeSave` イベントをフックし、全シェイプのGUIDをスキャン、前回保存時との差分を検証する「セキュリティゲート」の設計思想と実装を解説する。
—
1. 識別子の「真実」：Shape.IdとGUIDの危うさ
まず、開発者が陥る最初の罠が `Shape.Id` だ。これはスライド内のインデックスに過ぎず、オブジェクトの移動や複製、あるいは悪意ある挿入によって容易に衝突する。
真の検証を行うには、`CustomXMLPart` を活用し、各シェイプに永続的な識別子を埋め込む必要がある。スライドのシェイプ一つひとつに属性として「署名」を持たせ、保存時にその整合性を照合する。これが防衛レベルの最低防衛ラインだ。
—
2. セキュリティゲート実装：検証ロジックの骨子
以下のコードは、保存直前に全シェイプのハッシュを計算し、あらかじめ埋め込まれたメタデータと比較するモジュールのコアロジックである。
セキュリティ監視モジュール (VBA)
‘ 必須参照設定: Microsoft XML, v6.0
Option Explicit
Private Sub App_PresentationBeforeSave(ByVal Pres As Presentation, ByVal SaveAsUI As Boolean, Cancel As Boolean)
‘ 1. メモリ最適化: オブジェクトの明示的解放準備
Dim oSlide As Slide
Dim oShape As Shape
Dim isTampered As Boolean
‘ 2. 整合性検証ロジック
‘ 実運用では、ここを外部DLL（C++等）の呼び出しに置き換えるのが定石
For Each oSlide In Pres.Slides
For Each oShape In oSlide.Shapes
If Not VerifyShapeIntegrity(oShape) Then
MsgBox “警報: 不正なオブジェクトを検出しました。” & vbCrLf & _
“スライド: ” & oSlide.SlideIndex & ” シェイプ: ” & oShape.Name, vbCritical
Cancel = True
Exit Sub
End If
Next
Next
‘ 3. オブジェクトの明示的解放（VBAのガーベジコレクションを待たない）
Set oShape = Nothing
Set oSlide = Nothing
End Sub
Private Function VerifyShapeIntegrity(shp As Shape) As Boolean
‘ ここでCustomXMLPartから取得したハッシュ値と、
‘ 現在のシェイプのプロパティから算出したハッシュを比較する
‘ 不正な挿入（GUIDが存在しない）は即座に弾く
Dim guid As String
guid = shp.Tags(“Security_GUID”)
If guid = “” Then
VerifyShapeIntegrity = False ‘ 未登録のシェイプは不正とみなす
Else
‘ 本来はここでSHA-256等による検証を行う
VerifyShapeIntegrity = True
End If
End Function
—
3. シニアエンジニアが意識すべき「戦術的注意点」
A. Windows APIによるメモリ管理の徹底
VBAのランタイムは巨大なメモリリークを引き起こしやすい。特に `PresentationBeforeSave` のようなイベントドリブンな環境では、`Set = Nothing` を徹底するだけでなく、Windows API (`GlobalAlloc`, `CopyMemory`) を活用して、検証用のメタデータをプロセス外メモリに退避させる手法が有効だ。これにより、メモリダンプによる改ざん検知の回避を防ぐ。
B. レガシー環境と互換性のトレードオフ
`.pptm` ファイルを扱う際、マクロが無効化された環境での動作を考慮しなければならない。セキュリティを高めるのであれば、「マクロが有効でない限り、コンテンツを開けない」ように `CustomXMLPart` を暗号化・ロックするアーキテクチャが求められる。
C. パフォーマンスの壁（O(n)の呪縛）
数千のシェイプを持つプレゼンテーションにおいて、全シェイプのハッシュ再計算は保存時間を著しく増大させる。
- 差分更新アルゴリズム: 直前の保存から変更があったスライドのみをスキャン対象とする「変更フラグ」の管理を導入すること。
- 非同期処理: 重い計算は、別スレッドで動作する COM アドイン（C#/.NET）側に切り出し、VBAからは呼び出しのみを行う構成が理想だ。
—
4. 結び：アーキテクトとしての矜持
VBAは、その自由度の高さゆえに「魔窟」になりやすい。しかし、その内部構造を掌握し、メモリ管理とデータ整合性の論理を極めれば、VBAは堅牢なエンタープライズ監視システムの一翼を担える。
「動けばいい」というコードを書く時代は終わった。シェイプの一つひとつ、メモリのビットの一つひとつを支配し、企業の知的財産を守り抜くこと。それが、我々が目指すべきプロフェッショナルの到達点だ。
次に実装すべきは、この検証結果をブロックチェーン上のタイムスタンプサーバーと同期させる機能だろう。その知見が必要になれば、またいつでも門を叩いてほしい。
