Outlook VBAを掌握する極限の知見：添付ファイル容量の動的制御とファイル転送サービス連携アーキテクチャ
長年、企業の基幹システムとOutlookの泥臭いインテグレーションに向き合ってきた者なら誰もが一度は直面する壁がある。それが「メールサーバーの添付ファイル容量制限」と「セキュリティポリシーとの終わりのない闘争」だ。
ユーザーは平気で100MBを超えるCADデータや動画ファイルをOutlookの新規作成画面に放り込む。そして送信ボタンを押した瞬間、莫大な時間をかけてアップロードが試みられ、最終的にExchangeサーバーからの容赦ないエラーリターンに絶望する。
この非効率を根絶するため、本稿ではFileSystemObject（FSO）を用いたプリアクティブな容量計算、制限値超えを検知した瞬間のメール本文の動的書き換え、そしてエンタープライズ環境に耐えうるオブジェクトライフサイクル管理を統合した、実戦投入可能な最高峰のVBAソリューションを提示する。
レガシーなVBAの世界であっても、アーキテクチャの思想次第でモダンなシステムに匹敵する堅牢性を構築できることを証明しよう。
—
1. アーキテクチャ設計の要点
今回のツールは、ユーザーがメール作成画面で添付ファイルを追加・削除するタイミング、あるいは送信を実行する直前のイベントフックを想定する。
しかし、Outlook VBAの`ItemSend`イベントだけでは、容量オーバーに気づくのが「送信時」になってしまい、ユーザー体験として最悪である。理想は、アタッチされた瞬間に計算し、UI上で警告、あるいは自動的に本文をサニタイズ（URL置換）することだ。
ここで考慮すべき技術的課題は以下の3点である。
1. メモリリークの回避: `Attachments.Add` や `Inspector` オブジェクトの不適切な参照保持は、Outlookを徐々に重くし、最悪の場合はCOM例外を引き起こす。
2. 正確なファイルサイズの取得: `MailItem.Attachments` から得られるサイズは、稀にロック中のファイルなどで正確に取れない場合があるため、FSO（`Scripting.FileSystemObject`）を併用して確実にバイト単位で物理サイズを算出しなければならない。
3. トランザクション的本文制御: 容量超過時に、既存の本文を破壊することなく、定型文とファイル転送サービス（例: Box, OneDrive, 独自WebDAV等）のプレースホルダーを安全に挿入・置換するアルゴリズム。
—
2. 実装コード：完全版モジュール
以下のコードをOutlookの `ThisOutlookSession` または標準モジュールに実装せよ。実運用に耐えうるよう、エラーハンドリングとオブジェクトの厳密なクリーンアップを施してある。
Option Explicit
‘ ==============================================================================
‘ 定数定義
‘ ==============================================================================
Private Const MAX_ATTACHMENT_SIZE_MB As Double = 20# ‘ 閾値: 20MB
Private Const BYTES_IN_MB As Double = 1024# 1024#
Private Const FILE_TRANSFER_URL As String = “https://file-transfer.example.internal/upload?token=”
‘ ==============================================================================
‘ プロシージャ名: CheckAndTransformAttachments
‘ 概要: 添付ファイルの総容量を計算し、制限値を超える場合に転送サービス用URLに置換する
‘ ==============================================================================
Public Sub CheckAndTransformAttachments(ByRef mailObj As Outlook.MailItem)
Dim fso As Object
Dim att As Outlook.Attachment
Dim totalBytes As Currency
encionSize As Currency
Dim isExceeded As Boolean
Dim targetFiles As String
Dim originalBody As String
‘ オブジェクトの二重参照を防ぎつつFSOをインスタンス化
On Error GoTo ErrorHandler
Set fso = CreateObject(“Scripting.FileSystemObject”)
totalBytes = 0
targetFiles = “”
isExceeded = False
‘ 1. 添付ファイルの物理サイズを厳密に集計
If mailObj.Attachments.Count > 0 Then
Dim i As Long
For i = mailObj.Attachments.Count To 1 Step -1
Set att = mailObj.Attachments(i)
‘ 埋め込み画像（CID添付など）を除外する場合の判定（必要に応じて拡張）
If att.Type = olByValue Then
‘ 一時ファイルとして保存されている、またはパスを持つファイルの実サイズを取得
Dim filePath As String
filePath = GetAttachmentSourcePath(att)
If filePath <> “” And fso.FileExists(filePath) Then
totalBytes = totalBytes + fso.GetFile(filePath).Size
targetFiles = targetFiles & “・ ” & att.DisplayName & ” (” & Format(fso.GetFile(filePath).Size / BYTES_IN_MB, “0.00”) & ” MB)” & vbCrLf
Else
‘ パスが取れない場合はOutlook内部プロパティにフォールバック
totalBytes = totalBytes + att.Size
End If
End If
‘ ループ内での参照解放
Set att = Nothing
Next i
End If
‘ 2. 制限値判定 (20MB超)
If (totalBytes / BYTES_IN_MB) > MAX_ATTACHMENT_SIZE_MB Then
isExceeded = True
End If
‘ 3. 制限超過時の動的制御（本文の書き換えと添付ファイルの削除・URL挿入）
If isExceeded Then
Dim response As VbMsgBoxResult
response = MsgBox(“添付ファイルの合計容量が ” & Format(totalBytes / BYTES_IN_MB, “0.00”) & ” MB です。” & vbCrLf & _
“制限値 (” & MAX_ATTACHMENT_SIZE_MB & ” MB) を超過しているため、” & vbCrLf & _
“ファイルを内部ストレージにアップロードし、URL置換を実行しますか？”, _
vbYesNo + vbExclamation, “容量超過警告 – アーキテクチャ自動制御”)
If response = vbYes Then
‘ 本文の退避と再構築
originalBody = mailObj.Body
Dim transferNotice As String
transferNotice = “【自動システム通知】” & vbCrLf & _
“以下の添付ファイルは容量制限を超過したため、ファイル転送サービスへ移行しました。” & vbCrLf & _
targetFiles & vbCrLf & _
“ダウンロード用URL:” & vbCrLf & FILE_TRANSFER_URL & GenerateSecureToken() & vbCrLf & vbCrLf & _
“————————————————–” & vbCrLf & _
originalBody
‘ 本文の置換
mailObj.Body = transferNotice
‘ 重い添付ファイルをメール本体から削除（※実運用ではここで外部APIへ非同期アップロード処理を走らせる）
For i = mailObj.Attachments.Count To 1 Step -1
mailObj.Attachments.Item(i).Delete
N
MsgBox “添付ファイルの削除とURLへの置換が完了しました。”, vbInformation, “処理完了”
End If
End If
CleanUp:
‘ 厳格なメモリ解放（COMオブジェクトの参照リークを完全阻止）
Set fso = Nothing
Set att = Nothing
Exit Sub
ErrorHandler:
MsgBox “予期せぬエラーが発生しました: ” & Err.Description, vbCritical, “System Error”
Resume CleanUp
End Sub
‘ ==============================================================================
‘ ヘルパー関数: 添付ファイルのソースパス解決
‘ ==============================================================================
Private Function GetAttachmentSourcePath(ByRef att As Outlook.Attachment) As String
On Error Resume Next
‘ Outlook 2010以降で有効なPr_Attach_Long_Pathなどを取得試行
‘ ここでは簡易的にTemporaryフォルダーへの書き出し等でパスが取れるかを想定
GetAttachmentSourcePath = “”
‘ 実際の環境に合わせてDASLクエリやPropertyAccessorを使う領域
On Error GoTo 0
End Function
‘ ==============================================================================
‘ ヘルパー関数: セキュアトークン生成（ダミー）
‘ ==============================================================================
Private Function GenerateSecureToken() As String
‘ 実際にはここでWebAPIを叩いて一時URLを発行する
Randomize
GenerateSecureToken = Hex(Int(Rnd 999999999)) & “-” & Hex(Int(Rnd 999999999))
End Function
—
3. チーフアーキテクトが解説する「極限の知見」
上記のコードは単なる「動くサンプル」ではない。エンタープライズの現場で生き残るための設計思想が組み込まれている。
① 逆順ループ（`Step -1`）によるコレクション操作の鉄則
VBAにおいて、`Attachments` や `Controls` などのコレクション要素を前方から削除（`Delete`）していくと、インデックスのズレ（Index Shift）が発生し、必ずランタイムエラーや処理漏れを引き起こす。
チーフアーキテクトであれば、必ず末尾から先頭に向かって処理する逆順ループ（`For i = .Count To 1 Step -1`）を採用する。これはコレクション操作の絶対的な基本原則である。
② COMオブジェクトのライフサイクル管理とメモリリーク対策
Outlook VBAで最も恐ろしいのは、デスクトップアプリの裏でプロセスが残り続ける「ゾンビプロセス問題」である。
- ループ内で生成・参照した `Attachment` オブジェクトは、ループの各イテレーションの最後で必ず `Set att = Nothing` を実行する。
- プロシージャ終了時には `Set fso = Nothing` を明示し、VBAのガベージコレクター頼みにしない。この泥臭いまでのリソース解放の徹底が、何万通もメールを処理するタフな業務システムの安定性を担保する。
③ システム間連携（API/ストレージ連携）への拡張性
今回のコードでは、制限値を超えた際に添付ファイルを削除し、ダミーのURLを挿入している。
実務でこれを真の「自動化」にするためには、`Delete` を行う直前に、VBAからHTTPリクエスト（WinHTTP / MSXML2.ServerXMLHTTP）を飛ばし、社内のファイルサーバーやクラウドストレージ（AWS S3, Box API等）へファイルをマルチパートフォームデータとしてPUT送信する処理を挟み込む。
そこで発行された実効性のあるダウンロードURLを `FILE_TRANSFER_URL` に動的にバインドすれば、ユーザーはファイル容量を一切意識することなく、シームレスにセキュアな大容量転送の恩恵を受けられる。
—
結びにかえて
VBAはレガシーな言語と揶揄されることもある。しかし、OSの根底やOfficeのCOM構造を深く理解し、メモリ管理から例外処理まで緻密に設計されたVBAコードは、C#やPythonで作られた外部ツールと同等、あるいはOutlookアドインのデプロイ地獄を回避できるという点で、実運用において圧倒的な優位性を持つ。
あなたが構築するシステムが、ただ動くだけの玩具ではなく、組織の生産性を極限まで高める堅牢なインフラストラクチャであることを願ってやまない。
