鉄の掟：Outlookの「送信予約」をExcelから掌握する極限の自動化術
Outlookの `DeferredDeliveryTime` は、単なるプロパティではない。これは、MAPIサブシステムに対する「未来への予約」である。
多くのエンジニアが犯す過ちは、`MailItem` をループの中で安易に生成し、メモリ上に残骸を撒き散らすことだ。数千件のメールを一括で下書きに放り込む際、VBAのガベージコレクション（GC）を信用してはならない。本稿では、レガシーな環境下でも死なない、堅牢かつ高速な一括送信予約ロジックを伝授する。
—
1. メモリ管理の真髄：オブジェクトの「死」を制御せよ
VBAにおけるメモリリークの温床は、暗黙的なオブジェクトの参照保持にある。ループ内で `Set objMail = Nothing` を呼ぶのは当然だが、さらに一歩進んで、「プロセス外サーバーとしてのOutlookの負荷」を意識せよ。
大量処理を行う際は、`.Display` メソッドを絶対に叩いてはいけない。あれはGUIスレッドを消費し、レンダリングコストを強制する「毒」だ。バックグラウンドの `Save` 処理に徹することで、数倍の処理速度を叩き出せる。
2. 実装：Excelからの一括予約バッチ処理
以下のコードは、Excelのシートから指定されたカラム（宛先、件名、本文、送信日時）を読み込み、Outlookの `Drafts` フォルダへ静かに格納する。
‘ 必要な参照設定: Microsoft Outlook XX.X Object Library
Option Explicit
Sub BatchScheduleEmails()
Dim olApp As Object ‘ Late Binding推奨（環境差異への耐性）
Dim olNs As Object
Dim olDrafts As Object
Dim olMail As Object
Dim ws As Worksheet
Dim lastRow As Long, i As Long
‘ インスタンス取得の最適化
On Error Resume Next
Set olApp = GetObject(, “Outlook.Application”)
If olApp Is Nothing Then Set olApp = CreateObject(“Outlook.Application”)
On Error GoTo 0
Set olNs = olApp.GetNamespace(“MAPI”)
Set olDrafts = olNs.GetDefaultFolder(16) ‘ 16 = olFolderDrafts
Set ws = ThisWorkbook.Sheets(“Schedule”)
lastRow = ws.Cells(ws.Rows.Count, 1).End(-3).Row ‘ xlUp
‘ 処理の高速化: 画面更新停止等のExcel側チューニングも忘れずに
Application.ScreenUpdating = False
For i = 2 To lastRow
‘ 明示的なオブジェクト生成
Set olMail = olDrafts.Items.Add(0) ‘ 0 = olMailItem
With olMail
.To = ws.Cells(i, 1).Value
.Subject = ws.Cells(i, 2).Value
.Body = ws.Cells(i, 3).Value
‘ 【極限の知見】送信予約の設定
‘ 日時は必ずDate型として渡す。文字列の暗黙変換はMAPIの解釈揺れを招く
.DeferredDeliveryTime = CDate(ws.Cells(i, 4).Value)
‘ 保存のみで送信はしない（予約時刻までサーバー側で保持される）
.Save
End With
‘ 参照の即時破棄（ループ内のメモリ解放）
Set olMail = Nothing
Next i
‘ 後処理
Set olDrafts = Nothing
Set olNs = Nothing
Set olApp = Nothing
Application.ScreenUpdating = True
MsgBox “全件の予約送信処理が完了しました。”, vbInformation
End Sub
3. シニアエンジニアが押さえるべき「罠」
A. `DeferredDeliveryTime` の解釈
このプロパティは「送信ボタンを押した時」ではなく、「送信キューに乗った際」の基準になる。クライアント側のOutlookが起動していないと送信されないという罠がある。もし常時稼働を保証できないなら、Exchange Server側のトランスポートルールや、Power Automateへの移行を検討するのが、アーキテクトとしての誠実な回答だ。
B. レイトバインディング（Late Binding）の採用理由
`Dim olApp As Outlook.Application` と宣言したくなる気持ちはわかる。しかし、ユーザー環境のOutlookのバージョンが混在する社内環境では、参照設定のズレが「コンパイルエラー」を引き起こす。`CreateObject` を用いたレイトバインディングこそが、保守性の高いソリューションの第一歩である。
C. Windows APIの介入タイミング
もしメールの送信速度を物理的な限界まで高めたいなら、`SendMessage` 等でOutlookのメインウィンドウに対してコマンドを投げる手法があるが、現代のOutlookでは推奨されない。COMインターフェースを正しく叩くことが、最も低レイヤーで安全な操作であると心せよ。
結び：エンジニアの美学
自動化とは、単にコードを書くことではない。「システムが最も効率的に呼吸できる状態」を設計することだ。
大量の予約メールを放り込む際、あなたのコードがOutlookのCPU使用率を急騰させていないか？ `DoEvents` を適度に挟み、OSのイベントループを阻害しない配慮こそが、伝説的なエンジニアと初心者を分かつ境界線である。
さあ、あなたのExcel表に眠るタスクたちを、正確な未来へと送り出してやりたまえ。
