【実務中級】`Slide.Shapes.Count`が膨大なスライドの高速処理：Dictionaryオブジェクトを併用し、特定のオブジェクト名（例：「図 1」）をミリ秒単位でシーク・操作する高速化アプローチ
PowerPoint VBAの現場において、真のパフォーマンス劣化を引き起こす元凶は何か。それは巨大な画像ファイルそのものではない。DOM（Document Object Model）の探索コスト、すなわち「シェイプの線形探索（O(N)の罠）」である。
1スライドあたり数百個、いや、自動生成された複雑なレポートであれば1,000を超えるシェイプがひしめくプレゼンテーション。その中から「図 1」という特定の名前を持つオブジェクトをピンポイントで捕捉し、データを流し込む処理を書いたとする。
素朴な開発者が最初に書くコードは、決まってこうだ。
‘ 【アンチパターン】絶対にやってはいけない線形探索
Dim shp As Shape
For Each shp In slide.Shapes
If shp.Name = “図 1” Then
shp.TextFrame.TextRange.Text = “更新データ”
Exit For
End If
Next shp
このコードの何が問題か。`For Each`によるCOMオブジェクトの列挙は、背後で重厚長大なお見合い（COM Interop）を繰り返している。スライド内のシェイプ数が500個であれば、ワーストケースで500回のCOM境界跨ぎが発生する。これを数十〜数百スライドのループ内で回した瞬間、CPUは悲鳴を上げ、処理は数分から数十分の泥沼へと沈んでいく。
今回は、VBAの裏側にあるCOMの呪縛を断ち切り、`Scripting.Dictionary`を用いた「O(1) インデックス・キャッシュ」によって、ミリ秒単位でターゲットシェイプをシーク・操作する極限の高速化アプローチを解説する。
—
1. なぜ「`Slide.Shapes.Item()`」や「`For Each`」は遅いのか
PowerPointの`Shapes`コレクションは、配列のようなメモリ上の連続領域ではなく、内部的にはCOMコンポーネントとしてのリンク構造を持っている。
VBAから `Slide.Shapes(i)` や `For Each` を実行するたびに、以下のコストが漏れなく発生する。
1. COM境界の横断: VBAランタイムからネイティブ（C++製）のPowerPointエンジンへのコンテキストスイッチ。
2. オブジェクトラッパーの生成: 取得したポインターに対するVBA側の `Shape` オブジェクトの動的生成とライフサイクル管理。
特に特定の名前（例: `”図 1″`）を文字列比較で探す場合、コレクションの先頭から順番にオブジェクトをインスタンス化しては破棄する、という不条理なオーバーヘッドが毎回発生する。これが「重いスライド」の正体である。
—
2. アーキテクチャの核心：Dictionaryによる一括インデキシング
解決策はシンプルだ。「最初に一度だけ全シェイプを走査し、メモリ上のDictionaryに [シェイプ名 -> Shapeオブジェクトの参照] のマップを構築する」。
これがいわゆるインデキシング（索引化）である。一度Dictionaryに格納してしまえば、以降の検索コストは O(1)、すなわち一瞬である。何度「図 1」を呼び出そうとも、COM境界を無駄に跨ぐことはない。
究極の高速化実装コード
以下のコードは、実務の現場で即座に使える、堅牢性と極限のパフォーマンスを両立させたモジュールである。
Option Explicit
Sub ProcessHeavyPresentation()
Dim startTime As Double
startTime = Timer
Dim targetSlide As Slide
Set targetSlide = ActivePresentation.Slides(1) ‘ 例として第1スライドを対象
‘ 1. シェイプ・インデックス（Dictionary）の構築
Dim shapeDict As Object
Set shapeDict = CreateShapeIndex(targetSlide)
If shapeDict Is Nothing Then Exit Sub
‘ 2. O(1) による超高速シーク＆操作
Dim targetName As String
targetName = “図 1”
If shapeDict.exists(targetName) Then
Dim targetShape As Shape
‘ Setで参照を取得（余計なCOMラッパーを生成しない）
Set targetShape = shapeDict(targetName)
‘ ターゲットに対する操作
targetShape.Fill.ForeColor.RGB = RGB(255, 0, 0)
Debug.Print “「” & targetName & “」の色彩を変更しました。”
Else
Debug.Print “指定されたシェイプが見つかりませんでした: ” & targetName
End If
‘ 3. メモリの明示的解放（重要）
Set shapeDict = Nothing
Set targetShape = Nothing
Debug.Print “処理完了時間: ” & Format(Timer – startTime, “0.000”) & ” 秒”
End Sub
/
- スライド内の全シェイプをスキャンし、名前をキーにしたDictionaryを返す
- @param {Slide} sld 対象のスライド
- @return {Object} Scripting.Dictionary
/
Private Function CreateShapeIndex(ByVal sld As Slide) As Object
Dim dict As Object
Set dict = CreateObject(“Scripting.Dictionary”)
Dim shp As Shape
Dim shpCount As Long
shpCount = sld.Shapes.Count
‘ 1度だけの線形走査でメモリにキャッシュする
Dim i As Long
For i = 1 To shpCount
Set shp = sld.Shapes(i)
‘ 同名シェイプが存在する場合のキー重複エラーを防ぐ防衛策
If Not dict.exists(shp.Name) Then
dict.Add shp.Name, shp
End If
Next i
Set CreateShapeIndex = dict
End Function
—
3. チーフアーキテクトが教える：メモリ管理と罠の回避
VBAにおけるパフォーマンスチューニングは、単にコードを速く書くだけではなく、「メモリリークの根絶」と表裏一体である。
① `Scripting.Dictionary` の参照解放
VBAのDictionaryにCOMオブジェクトの参照（`Shape`など）を格納すると、VBAランタイムとCOMの参照カウンタが複雑に絡み合う。処理の終了時には必ず `Set shapeDict = Nothing` を実行し、Dictionary自体が保持しているオブジェクトへの参照を一網打尽に解放しなければならない。これを怠ると、PowerPointのプロセス内にゾンビオブジェクトが残り、メモリリークや予期せぬクラッシュの温床となる。
② 同名シェイプ（Duplicated Names）への耐性
PowerPointで図形をコピー＆ペーストすると、意図せず全く同じ `Name`（例：「図 1」）を持つシェイプが複数誕生することがある。
上記の `CreateShapeIndex` 関数では、`If Not dict.exists(shp.Name) Then` という防衛的コードを挟むことで、万が一のキー重複によるランタイムエラー（エラー457: すでにキーがコレクションに存在しています）を完全にブロックしている。
—
4. 大規模バッチ処理への拡張
このアプローチの真価は、複数スライド、さらには数百個のファイル（Presentation）を一括処理するバッチシステムにおいて発揮される。
スライドを切り替えるたびにインデックスを作り直す（あるいはプレゼンテーション全体を走査して `Slide ID` をキーにした多次元Dictionaryを構築する）ことで、レガシーなレポート自動生成システムであっても、処理時間を従来の「数十分単位」から「数秒単位」へと劇的に短縮することが可能になる。
「シェイプの数が多いからVBAでは処理しきれない」というエンジニアの言い訳は、これで終わりだ。オブジェクトモデルのライフサイクルを支配し、メモリ上の参照をコントロールする者だけが、VBAの限界突破という果実を手にすることができる。
