【テクニカル・上級編】【実務中級者向け】保存時の「INCREMENTALSAVEPERCENT」最適化：フルセーブを強制してファイル破損リスクを低減する – AutoCAD VBA解析バイブル

AutoCAD VBA

2026.11.12

「増分保存」という甘い罠を断つ：`INCREMENTALSAVEPERCENT`の極限制御によるDWG整合性の担保

「増分保存」という甘い罠を断つ：`INCREMENTALSAVEPERCENT`の極限制御によるDWG整合性の担保

業務自動化の最前線に立つエンジニアにとって、最大の敵は「処理速度」ではない。真の敵は、静かに、しかし確実に進行する「データの腐敗（Data Corruption）」だ。

AutoCADを用いた大規模な設計プロセスにおいて、多くの開発者が「保存時間の短縮」という目先の果実に目を奪われ、ファイル構造の健全性を犠牲にしている。その元凶こそが、システム変数 `INCREMENTALSAVEPERCENT` に潜む、増分保存（Incremental Save）のメカニズムである。

本稿では、シニアエンジニアおよびシステム管理者が、設計データの完全性を維持するために、どのようにVBAを用いてこの制御を掌握すべきか、その極限の知見を提示する。

1. 増分保存のメカニズムと「構造的断片化」の正体

AutoCADの `INCREMENTALSAVEPERCENT` は、図面の変更量がファイル全体の一定割合（デフォルトでは25%）未満である場合、ファイル全体を書き直すのではなく、変更された差分データのみをファイルの末尾に追記する仕組みである。

一見、I/O負荷を軽減する合理的な設計に見える。しかし、バイナリレベルで見た時、この挙動は「図面構造の断片化」を引き起こす。

なぜファイルが壊れるのか？

増分保存が繰り返されると、DWGファイル内には「古いデータ」と「新しいデータ」が混在し、ポインタの参照関係が複雑化していく。

ブロック定義の不整合: 複雑なネスト構造を持つブロックにおいて、増分更新がポインタの不整合を誘発する。
XREF（外部参照）との同期不全: 差分データが蓄積されることで、外部参照の読み込み時にメモリ上のオブジェクトツリーとの不一致が生じるリスクが高まる。
監査（AUDIT）の限界: `AUDIT` コマンドは論理的なエラーを検出できるが、物理的なファイル構造の断片化に起因する潜在的なリスクを完全に排除することはできない。

結論から言えば、「真に堅牢なシステム」においては、増分保存を無効化し、常にフルセーブを強制すべきである。

2. 極限の制御：VBAによるシステム変数の強制操作

実務における自動化スクリプトでは、単に `Save` を呼び出すだけでは不十分だ。保存の直前にシステム変数を書き換え、保存後に元の環境へ復元するという「状態管理」が必要となる。

以下に、堅牢性を追求した実装例を示す。ここでは、単なる変数の書き換えに留まらず、オブジェクトのライフサイクルとエラーハンドリングにまで踏み込んでいる。

Option Explicit

' Windows API: ファイルの属性を確認するための宣言
' ファイルが読み取り専用でないか、あるいはロックされていないかを事前に検証するために使用する
Private Declare PtrSafe Function GetFileAttributes Lib "kernel32" Alias "GetFileAttributesA" (ByVal lpFileName As String) As Long
Private Const FILE_ATTRIBUTE_READONLY As Long = &H1

''' <summary>
''' 図面の整合性を担保するためのフルセーブ・プロシージャ
''' </summary>
Public Sub SecureFullSave()
    Dim acadApp As Object
    Dim targetDoc As Object
    Dim originalPercent As Double
    Dim targetPath As String
    
    On Error GoTo ErrorHandler

    Set acadApp = ThisDrawing.Application
    Set targetDoc = ThisDrawing
    targetPath = targetDoc.FullName

    ' 1. ファイルの物理状態の事前検証 (Windows API活用)
    ' 保存前にファイルが読み取り専用でないことを確認するのは、アーキテクトの嗜みである
    If (GetFileAttributes(targetPath) And FILE_ATTRIBUTE_READONLY) <> 0 Then
        Err.Raise vbObjectError + 513, "SecureFullSave", "Error: Target file is Read-Only."
    End If

    ' 2. 現在の INCREMENTALSAVEPERCENT を退避
    ' ユーザー環境のプリファレンスを破壊しないためのエチケット
    originalPercent = targetDoc.GetVariable("INCREMENTALSAVEPERCENT")

    ' 3. 増分保存を完全に無効化 (0%に設定することで常にフルセーブを強制)
    ' これにより、DWG構造がクリーンな状態で再構築される
    targetDoc.SetVariable "INCREMENTALSAVEPERCENT", 0

    ' 4. 図面内の潜在的なエラーをクリーンアップ
    ' 保存前にAUDITを実行することで、メモリ上の不整合を解消する
    targetDoc.Audit True

    ' 5. フルセーブの実行
    targetDoc.Save

    ' 6. システム変数の復元
    targetDoc.SetVariable "INCREMENTALSAVEPERCENT", originalPercent

    Debug.Print "Successfully performed a clean full save: " & targetPath

CleanUp:
    ' 7. メモリ管理の徹底
    ' VBAのCOMオブジェクトは、明示的にNothingを代入して参照カウントを減らす
    ' これを行わないと、AutoCADプロセスがゾンビ化する原因となる
    Set targetDoc = Nothing
    Set acadApp = Nothing
    Exit Sub

ErrorHandler:
    MsgBox "Critical Error during Secure Save: " & Err.Description, vbCritical, "System Integrity Violation"
    ' エラー発生時でも、可能な限りシステム変数を元の状態に戻す試みを行う
    If Not targetDoc Is Nothing Then
        On Error Resume Next
        targetDoc.SetVariable "INCREMENTALSAVEPERCENT", originalPercent
    End If
    Resume CleanUp
End Sub

3. アーキテクトの視点：メモリ最適化とオブジェクトのライフサイクル

上記のコードで `Set targetDoc = Nothing` を強調したのは、AutoCAD VBAにおける「メモリリーク」と「プロセス残留」が、大規模なバッチ処理において致命的なボトルネックになるからだ。

オブジェクトの明示的解放（Explicit Release）

VBAのガベージコレクションは、COMオブジェクトに対して必ずしも即時的かつ予測可能な挙動を示すわけではない。特に、`ThisDrawing` や `Application` といったトップレベルのオブジェクトを介して、複雑なエンティティ（BlockDefinition, Layer, Xref）を操作する場合、参照が循環するとAutoCADはメモリを解放できなくなる。

シニアエンジニアが書くコードは、「使い終わったものは、即座に、確実に、ゴミを残さず片付ける」。これは、自動化システムをサーバー上で長時間稼働させる（Headlessモード等）際の鉄則である。

パフォーマンスのトレードオフ

`INCREMENTALSAVEPERCENT = 0` に設定すると、保存時間は確実に増加する。しかし、我々が設計すべきは「保存が速いシステム」ではなく、「データが失われないシステム」である。

開発環境: 速度優先で `25` 程度に設定。
本番・リリース環境: 整合性優先で `0` を強制。

この使い分けを、システム全体のアーキテクチャ設計（Configファイル等による制御）に組み込むことが、真のプロフェッショナルの仕事である。

結論

`INCREMENTALSAVEPERCENT` の制御は、単なる設定変更ではない。それは、図面データの物理的構造に対する深い理解に基づいた、「データの完全性を守るための防衛策」である。

増分保存という名の「効率化」が、将来的なファイル破損という「コスト」を招いていないか。常にその視点を持ち、コードの一行一行に、データの整合性への責任を込めてほしい。

技術の深淵は、常に、細部に宿る。