ネットワークの「揺らぎ」に屈しない。添付ファイル保存における堅牢なリトライ設計論
業務自動化の現場で、ツールが「動かない」という報告を受けるとき、その原因の多くはロジックの誤りではない。「環境の非決定性」への考慮不足だ。
特に、Outlook VBAを用いて添付ファイルをネットワークドライブ（NAS）や共有フォルダへ保存する処理を実装する場合、ローカル環境では完璧に動作したコードが、本番環境のネットワーク越しでは、まるで呪われたかのように「アクセス権限エラー」や「書き込み禁止」で停止する。
もし君が、`On Error Resume Next` を使ってエラーを握りつぶし、あるいは単純な `SaveAsFile` を一発叩くだけのコードを書いているなら、今すぐその設計を捨ててほしい。それは「ツール」ではなく、いつ爆発するか分からない「時限爆弾」だ。
本稿では、プロフェッショナルが実践する、ファイルロックとネットワーク遅延を制するための「再試行（Retry）ロジック」の極意を伝授する。
なぜ、あなたのコードはネットワーク上で死ぬのか
なぜ、ファイルが存在し、権限もあるはずなのにエラーが出るのか。その正体は、主に以下の3つの「レイテンシ（遅延）」にある。
1. OSおよびファイルシステムのロック:
添付ファイルが作成された瞬間、アンチウイルスソフトがスキャンを開始したり、Windows Indexing Serviceがファイルを掴んだりする。この「一瞬の占有」が、VBAの書き込み処理と衝突する。
2. ネットワーク・ハンドシェイクの遅延:
NASへの書き込みは、ローカルSSDとは比較にならないほど不安定だ。セッションの確立や、ファイルヘッダーの書き込み完了までに、マイクロ秒単位の「隙」が生じる。
3. 非同期的な状態遷移:
VBAが「書き込み命令」を出した直後、OS側でファイルが「利用可能」な状態に遷移するまでには、わずかなタイムラグがある。
これらを「エラー」として処理せず、「一時的な状態」として捉え、戦略的に待機・再試行する設計こそが、堅牢なシステムへの分水嶺となる。
堅牢な設計指針：Retry Pattern の実装
単にループを回せばいいわけではない。無闇なループはCPUリソースを浪費し、最悪の場合、Outlookをフリーズさせる。以下の3原則をコードに組み込む。
1. Retry Limit（最大試行回数）: 無限ループを避け、システムが完全に死んでいるのか、一時的なものかを切り分ける。
2. Wait Interval（待機時間）: `DoEvents` でOSに制御を戻し、`Sleep` API で物理的な待機時間を確保する。
3. Error Discrimination（エラーの選別）: 「パスが見つからない」といった致命的なエラーと、「ファイルがロックされている」といった一時的なエラーを区別する。
プロダクション・コード：AttachmentSaver モジュール
以下に、実務でそのまま利用可能なレベルの、再試行ロジックを組み込んだ関数を示す。
Option Explicit
' Windows APIの宣言: 待機時間をミリ秒単位で制御するために使用
If VBA7 Then
Declare PtrSafe Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As LongPtr)
Else
Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)
End If
''' <summary>
''' 添付ファイルを指定パスに保存する。
''' ネットワーク遅延やファイルロックを考慮し、リトライロジックを内包する。
''' </summary>
''' <param name="oAttachment">対象のOutlook.Attachmentオブジェクト</param>
''' <param name="strSavePath">保存先のフルパス</param>
''' <returns>成功すればTrue、失敗すればFalse</returns>
Public Function SafeSaveAttachment(ByRef oAttachment As Outlook.Attachment, _
ByVal strSavePath As String, _
Optional ByVal maxRetries As Integer = 5, _
Optional ByVal sleepMs As Long = 1000) As Boolean
Dim i As Integer
Dim success As Boolean
Dim errNum As Long
success = False
' 試行ループ
For i = 1 To maxRetries
On Error Resume Next
' 1. 添付ファイルの保存実行
oAttachment.SaveAsFile strSavePath
errNum = Err.Number
On Error GoTo 0
If errNum = 0 Then
' 成功時
success = True
Exit For
Else
' エラー発生時のログ出力（実務ではログファイルやDBへ記録することを推奨）
Debug.Print "[Attempt " & i & "] Error saving file: " & errNum & " - " & Err.Description
' 致命的なエラー（パスが存在しない等）はリトライしても無意味なので即座に抜ける
' 70: Permission Denied (ロック等の可能性あり)
' 75: Path/File access error
' 76: Path not found
If errNum = 76 Then
Debug.Print "Critical Error: Path not found. Aborting."
Exit For
End If
' 2. 待機処理
' DoEventsでOSに制御を戻し、他のプロセス（アンチウイルス等）に隙を与える
DoEvents
' Sleepで物理的なインターバルを確保
Sleep sleepMs
End If
Next i
If Not success Then
Debug.Print "Failed to save attachment after " & maxRetries & " attempts."
End If
SafeSaveAttachment = success
End Function
''' <summary>
''' メインルーチン（テスト用）
''' </summary>
Public Sub ProcessIncomingEmails()
Dim outlookApp As Outlook.Application
Dim ns As Outlook.NameSpace
Dim inbox As Outlook.Folder
Dim mail As Outlook.MailItem
Dim att As Outlook.Attachment
Dim saveDir As String
Dim targetPath As String
Set outlookApp = New Outlook.Application
Set ns = outlookApp.GetNamespace("MAPI")
Set inbox = ns.GetDefaultFolder(olFolderInbox)
' 保存先（ネットワークドライブを想定）
saveDir = "\\YourServer\SharedFolder\Attachments\"
' フォルダ存在チェック（これを行わないのは設計ミスである）
If Dir(saveDir, vbDirectory) = "" Then
MsgBox "保存先ディレクトリが見つかりません: " & saveDir, vbCritical
Exit Sub
End If
' 受信メールを走査（例として直近のメール）
For Each mail In inbox.Items
If TypeOf mail Is MailItem Then
If mail.Attachments.Count > 0 Then
For Each att In mail.Attachments
' ファイル名から不正文字を除去する処理は別途必要
targetPath = saveDir & att.FileName
' 【極限の知見】ここで堅牢な保存関数を呼び出す
If SafeSaveAttachment(att, targetPath) Then
Debug.Print "Success: " & att.FileName
Else
' 失敗した場合は、業務フローに応じて通知やログ記録を行う
Debug.Print "Failure: " & att.FileName
End If
Next att
End If
End If
Next mail
End Subアーキテクトの視点：さらなる高みへ
上記のコードは、単なる「エラー回避」を超え、「システムの予測可能性を高める」ための設計だ。だが、これだけで満足してはいけない。実務レベルでは以下の観点も考慮せよ。
1. ファイル名のサニタイジング（無害化）
`att.FileName` をそのまま使うのは素人だ。ファイル名に `\ / : * ? ” < > |` などの禁止文字が含まれていたり、OSの予約語（`CON`, `PRN`など）であったりする場合、リトライ以前の問題で確実に失敗する。保存前に必ず正規表現等でクレンジングせよ。
2. 指数バックオフ（Exponential Backoff）の検討
上記の例では固定の `sleepMs` を用いているが、より高度な設計では、リトライ回数が増えるごとに待機時間を倍増させる「指数バックオフ」を導入する。
`Sleep (sleepMs * (2 ^ (i – 1)))`
これにより、一時的なネットワークの瞬断には素早く反応し、深刻な負荷状況には静かに身を引く、エレガントな挙動を実現できる。
3. ログの外部化
`Debug.Print` は開発者のためのものだ。プロダクション環境では、エラー内容、試行回数、発生時刻を、テキストファイル、あるいは共有のSQLデータベースへ書き出す設計にせよ。エラーが起きた際、「いつ、どのファイルで、なぜ失敗したのか」を即座に特定できることが、保守コストを劇的に下げる。
結論
「動けばいい」コードは、ユーザーの信頼を失う。
「失敗する可能性がある」ことを前提に、その失敗をいかにエレガントに制御するか。それこそが、我々エンジニアに求められる真の設計力である。
ネットワークの揺らぎを恐れるな。それをコントロールするロジックを組み込め。
