現場のエンジニアへ：送信済みメールの「ログ管理」を甘く見てはいけない
業務効率化の第一歩として「送信メールのExcel記録」を自動化したい――素晴らしい着眼点だ。だが、ネット上に溢れる「とりあえず動くコード」をそのまま業務環境に持ち込むのは危険極まりない。
Outlookのオブジェクトモデルは、単にプロパティを叩くだけで済むような単純な代物ではない。通信ラグ、マルチスレッドの影、そしてExcel側のI/O負荷。これらを無視したコードは、数ヶ月後に「なぜかログが抜ける」「Excelが固まる」という悪夢を招く。
本稿では、プロフェッショナルとして現場で通用する、堅牢かつ保守性の高いログ収集ツールの設計思想を授ける。
—
1. なぜ「イベント駆動」でなければならないのか
初心者がやりがちな「定期的に全メールをスキャンする」手法は、パフォーマンスの観点から論外だ。メールが増えるごとに処理時間は指数関数的に増大する。
我々が採用すべきは、`Items.ItemAdd` イベントだ。Outlookが「アイテムが追加された瞬間」をフックし、その一つだけを処理する。これが最も負荷が低く、かつ即時性の高いアーキテクチャである。
—
2. 実装：プロダクション級のロギングコード
以下のコードを、Outlookの `ThisOutlookSession` に記述する。
Option Explicit
‘ 監視対象のフォルダを保持する変数
Private WithEvents sentItems As Items
Private Sub Application_Startup()
‘ Outlook起動時に送信済みフォルダを監視対象に設定
Dim ns As NameSpace
Set ns = Application.GetNamespace(“MAPI”)
Set sentItems = ns.GetDefaultFolder(olFolderSentMail).Items
End Sub
Private Sub sentItems_ItemAdd(ByVal Item As Object)
‘ オブジェクトの型チェックを必ず行う（防御的プログラミング）
If TypeOf Item Is MailItem Then
Call ExportToExcel(Item)
End If
End Sub
Private Sub ExportToExcel(ByVal mail As MailItem)
Dim xlApp As Object, wb As Object, ws As Object
Dim nextRow As Long
‘ Excelを制御するための定数定義
Const FILE_PATH As String = “C:\Logs\MailLog.xlsx”
On Error GoTo ErrorHandler
‘ Excelインスタンスの取得（起動していれば取得、なければ新規作成）
Set xlApp = CreateObject(“Excel.Application”)
Set wb = xlApp.Workbooks.Open(FILE_PATH)
Set ws = wb.Sheets(1)
‘ 最終行の取得（パフォーマンスのため、UsedRangeよりもCellsを使用）
nextRow = ws.Cells(ws.Rows.Count, 1).End(-4162).Row + 1 ‘ xlUp = -4162
‘ 書き込み
With ws
.Cells(nextRow, 1).Value = mail.ReceivedTime ‘ 送信日時
.Cells(nextRow, 2).Value = mail.To ‘ 宛先
.Cells(nextRow, 3).Value = mail.CC ‘ CC
.Cells(nextRow, 4).Value = mail.BCC ‘ BCC
.Cells(nextRow, 5).Value = mail.Subject ‘ 件名
End With
wb.Close SaveChanges:=True
Exit Sub
ErrorHandler:
Debug.Print “Error: ” & Err.Description
‘ 本番環境ではここにログ出力や通知処理を入れること
End Sub
—
3. 現場で「生き残る」ための3つの重要知見
① Excel I/Oの「重さ」を知る
Excelファイルを開いて書き込んで閉じる、という処理は非常にコストが高い。もしログが頻繁に発生する環境なら、Excelを毎回閉じるのではなく、Excelを非表示で立ち上げっぱなしにしておく「常駐型」への改修を推奨する。
② 送信直後の「プロパティ不在」を避ける
メール送信直後、Outlook内部でメタデータが完全に書き込まれる前に `ItemAdd` が発火するケースが稀にある。もしプロパティが取得できない場合は、`DoEvents` を挟むか、数秒のウェイトを設ける設計に逃げ道を作っておくべきだ。
③ 宛先の「多重データ」の扱い
`mail.To` には複数のアドレスがセミコロン区切りで格納される。Excel上で「宛先ごとに集計したい」という要件が将来的に発生するなら、あらかじめ `Split` 関数で分割してセルに書き込むか、CSV形式で整形して格納することを検討せよ。後からのデータ加工が圧倒的に楽になる。
—
結論：コードは「書く」ものではなく「設計する」もの
このコードはあくまで出発点だ。
実務で重要なのは、「例外が発生したとき、誰がどうやって気づくか？」というエラーハンドリングと、「誰がログファイルをロックしているか？」という競合制御である。
まずはこのコードを動かし、自分の目でログが積み上がるのを確認してほしい。その後、エラー通知機能や、ファイルパスを定数ではなく設定ファイル（INIやJSON）から読み込む構造へと進化させていけば、君のツールは「個人の備忘録」から「組織のインフラ」へと昇華するはずだ。
自動化の旅に終わりはない。君のコードが、誰かの無駄な工数を一つでも減らすことを期待している。
