Outlookの「アイテム」の添付ファイル（Attachments）のインデックス管理とファイル名取得の罠
Outlook VBAにおける最大の技術的負債の一つが、`Attachments` コレクションの扱いだ。
特に、業務システムとの連携や自動化スクリプトの開発において、「添付ファイル名でファイルを特定し、抽出・保存する」という処理は頻出する。しかし、この一見シンプルに見える操作こそが、数多くのシニアエンジニアを嵌めてきた「インデックスの罠」と「インライン画像の魔物」が潜む領域である。
本稿では、Outlookオブジェクトモデルの深層に踏込み、レガシーな仕様の裏側にある真実と、実務の現場で絶対に破綻しない堅牢な添付ファイル制御の極意を解説する。
—
1. 致命的な仕様：1ベースインデックスと「削除時の詰まり」
VBAの多くのコレクション（例: `Worksheets`, `Collection`）や配列は1ベースであることが多いが、Outlookの `Attachments` コレクションも 1ベース（1から始まる） でインデックス管理されている。
ここで発生する最初の罠が、「ループ内で添付ファイルを削除・変更した際のインデックスのズレ」だ。
例えば、特定の条件に合致する添付ファイルをすべて削除したい場合、以下のようなコードを書くと確実にバグる。
‘ 【アンチパターン】これをしてはいけない
Dim i As Long
For i = 1 To mailItem.Attachments.Count
If mailItem.Attachments(i).DisplayName Like “.tmp” Then
mailItem.Attachments(i).Delete
End If
Next i
なぜ破綻するのか？
`Attachments(1)` を削除した瞬間、元 `Attachments(2)` であったオブジェクトが自動的に `Attachments(1)` にシフトする。結果として、インデックス `2` をスキップすることになり、削除対象が漏れるだけでなく、`Count` を超えたアクセスによる実行時エラー（Runtime Error）を引き起こす。
対策：逆順ループ（Decremental Loop）の徹底
コレクションを操作・削除する場合は、必ず末尾から先頭に向かって処理する逆順ループを構築しなければならない。
Dim i As Long
For i = mailItem.Attachments.Count To 1 Step -1
‘ 末尾から処理するため、削除しても未処理のインデックスに影響を与えない
If mailItem.Attachments(i).DisplayName Like “.tmp” Then
mailItem.Attachments(i).Delete
End If
Next i
—
2. ファイル名取得の罠：`FileName` と `DisplayName` の決定的な違い
Outlookで添付ファイルの名前を取得する際、あなたはどちらのプロパティを参照しているだろうか？
- `Attachment.FileName`
- `Attachment.DisplayName`
この2つの違いを理解していない場合、システム連携において「ファイルが見つからない」「文字化けする」といった深刻な障害の温床となる。
プロパティの仕様差
1. `FileName`:
添付ファイルがディスクから追加された時点の実際のファイル名、またはMIMEパートで定義されたファイル名を返す。システム連携で物理保存する際のキーとしてはこちらが信頼できる。
2. `DisplayName`:
GUI上でユーザーに見えている名称。リッチテキスト（RTF）やHTMLメールの場合、ユーザーが名前を変更できたり、後述のインライン画像のように名前が空（または一意の内部ID）になることがある。
特に、MAPIレベルでのマルチパート構造を持つメールや、他のメール転送（`.msg` の添付）が含まれる場合、`FileName` は空を返し、`DisplayName` のみ値を持つといった変則的な挙動を示す。
—
3. 最大の難敵：インライン画像（CID添付）の混入と識別
HTMLメールの本文中に埋め込まれた画像（署名ロゴやキャプチャ画像など）は、Outlookの内部構造においてすべて `Attachments` コレクションの要素として格納される。
これらを通常の添付ファイルと同じロジックで処理してしまい、業務用のPDFやExcelと一緒に「すべてローカルに保存」してしまうインシデントが後を絶たない。
インライン画像の判定ロジック
インライン画像は、MIMEヘッダの `Content-ID`（CID）を持っているという特徴がある。しかし、Outlook VBAの標準オブジェクトモデルでは、直接 `Content-ID` プロパティを叩けない場合がある（バージョンやMAPIプロパティによる）。
ここで、MAPIプロパティに直接アクセスするための `PropertyAccessor` を使用する。これこそが、シニアエンジニアが知るべき極限の最適解である。
‘ 添付ファイルがインライン画像（CID参照）か判定する関数
Public Function IsInlineAttachment(att As Outlook.Attachment) As Boolean
On Error GoTo ErrorHandler
Dim pa As Outlook.PropertyAccessor
Set pa = att.PropertyAccessor
‘ PR_ATTACH_METHOD (PidTagAttachMethod) が 6 (olEmbeddedItem) かつ
‘ PR_ATTACH_CONTENT_ID が存在するかを確認するなど
‘ 一般的には PR_ATTACH_CONTENT_ID の有無を見る
Const PR_ATTACH_CONTENT_ID = “http://schemas.microsoft.com/mapi/proptag/0x3712001E”
Dim contentId As String
contentId = pa.GetProperty(PR_ATTACH_CONTENT_ID)
If Len(contentId) > 0 Then
IsInlineAttachment = True
Else
IsInlineAttachment = False
End If
Exit Function
ErrorHandler:
‘ プロパティが存在しない場合はエラーになるため、通常添付とみなす
IsInlineAttachment = False
End Function
—
4. 完全版：重複ファイル名対策とメモリ最適化を施したセーフローダー
ここまでの知見（逆順ループ、プロパティの使い分け、インライン除外、そしてCOMオブジェクトの適切な解放）をすべて網羅した、実務投入可能なプロダクションレベルのコードを提示する。
ファイル名が重複している場合（例：同名の `report.pdf` が複数添付されている場合）の連番付与ロジックも実装している。
Sub SaveAttachmentsSafely(mail As Outlook.MailItem, targetFolder As String)
Dim atts As Outlook.Attachments
Dim att As Outlook.Attachment
Dim i As Long
Dim baseName As String
Dim ext As String
Dim savePath As String
Dim fso As Object
Dim counter As Long
Set atts = mail.Attachments
If atts.Count = 0 Then Exit Sub
Set fso = CreateObject(“Scripting.FileSystemObject”)
‘ インデックスのズレを防ぐため、必ず逆順でループを回す
For i = atts.Count To 1 Step -1
Set att = atts(i)
‘ 1. インライン画像（署名や埋め込み画像）はスキップする判定
If Not IsInlineAttachment(att) Then
Dim originalName As String
originalName = att.FileName
If originalName = “” Then originalName = att.DisplayName
‘ 有効なファイル名が存在する場合のみ処理
If originalName <> “” Then
‘ 2. ファイル名と拡張子の分解
ext = fso.GetExtensionName(originalName)
baseName = Left(originalName, Len(originalName) – Len(ext) – 1)
savePath = targetFolder & “\” & originalName
counter = 1
‘ 3. 同名ファイルが存在する場合の衝突回避（上書き防止）
Do While fso.FileExists(savePath)
savePath = targetFolder & “\” & baseName & “_” & counter & “.” & ext
counter = counter + 1
Loop
‘ 4. 保存実行
att.SaveAsFile savePath
End If
End If
‘ オブジェクトの明示的解放（メモリリーク防止）
Set att = Nothing
Next i
‘ クリーンアップ
Set fso = Nothing
Set atts = Nothing
End Sub
‘ 前述のインライン判定関数
Private Function IsInlineAttachment(att As Outlook.Attachment) As Boolean
On Error GoTo NotInline
Dim pa As Outlook.PropertyAccessor
Set pa = att.PropertyAccessor
‘ MAPIプロパティ: PR_ATTACH_CONTENT_ID
Dim cId As String
cId = pa.GetProperty(“http://schemas.microsoft.com/mapi/proptag/0x3712001E”)
If Trim(cId) <> “” Then
IsInlineAttachment = True
Exit Function
End If
NotInline:
IsInlineAttachment = False
End Function
—
5. チーフアーキテクトからの提言：VBAの限界とモダン開発への移行
Outlook VBAは、デスクトップ環境における迅速な自動化において今なお強力なツールである。しかし、Exchange Serverのモダン化、Graph APIへの移行、セキュリティポリシーの強化（マクロの実行ブロックなど）に伴い、ローカルのOutlookクライアントに依存したアーキテクチャはいずれ黄昏を迎える。
もしあなたが現在、何万通ものメール処理や、クラウドストレージ（SharePoint / OneDrive）への直接の添付ファイル連携を構想しているならば、VBAはそのプロトタイプ（概念実証）の域にとどめるべきだ。
真にスケーラブルで堅牢なシステムを目指すのであれば、Microsoft Graph API を用いたクラウドネイティブなメール処理基盤へのリプレースを強く推奨する。
APIの世界では、インデックスのズレやMAPIの呪縛に悩まされることはなく、JSONペイロードとしてクリーンに添付ファイルを制御できる。
技術の本質を見極め、レガシーとモダンの最適な境界線を設計すること――それこそが、我々エンジニアリングの極意である。
