Outlook VBAを掌握する：送信メールのSQL Server自動記録による「可視化」の極意
業務自動化の世界において、多くのエンジニアが「メール送信の自動記録」で躓く。
理由は単純だ。Outlookのイベントモデルを深く理解せず、場当たり的なコードを書くからだ。
「とりあえず動く」ものと「止まらないシステム」の間には、深淵のような溝がある。今日は、その溝を飛び越え、堅牢かつ保守性の高い「送信済みアイテム監視・DB連携」のアーキテクチャを君たちに授ける。
なぜ、多くのVBAコードは「死ぬ」のか
多くの初心者は、`ItemSend` イベントの中で直接DB接続を行い、重いクエリを投げる。これは自殺行為だ。
Outlookはシングルスレッドで動作するアプリケーションであり、イベントハンドラ内で長時間を要する処理（特にネットワークを跨ぐSQL接続）を行うと、UIのフリーズや、最悪の場合、メール送信そのものの失敗を招く。
我々が目指すべきは「イベントの即時解放」と「堅牢なADO接続」の両立だ。
—
プロダクション・コード：堅牢な監視モジュール
まずは、`ThisOutlookSession` に記述するイベントフックだ。ここでは処理を極力簡素化し、ロジックを別モジュールへ分離する。これが保守性の第一歩である。
1. ThisOutlookSession（イベントの入り口）
‘ 送信イベントを監視するクラスモジュール的役割
Private Sub Application_ItemSend(ByVal Item As Object, Cancel As Boolean)
On Error GoTo ErrorHandler
‘ メールアイテムか判定（会議出席依頼などもItemSendをトリガーするため）
If TypeOf Item Is Outlook.MailItem Then
‘ 送信処理を非同期的に扱いたいが、VBAでは同期処理が基本。
‘ そのため、DB書き込みは最小限の構成で実装する。
Call LogService.RecordSentMail(Item)
End If
Exit Sub
ErrorHandler:
‘ 致命的なエラーでもメール送信そのものを止めない配慮が必要
Debug.Print “Error: ” & Err.Description
End Sub
2. LogService（ビジネスロジックとDB連携）
次に、SQL Serverへの接続を司るロジックだ。ここで重要なのは、「Connectionオブジェクトの使い回しをしない」「明示的なCloseとNothingの代入」である。
‘ 標準モジュール: LogService
Option Explicit
Public Sub RecordSentMail(ByVal mail As Outlook.MailItem)
Dim conn As Object ‘ ADODB.Connection
Dim cmd As Object ‘ ADODB.Command
Dim connStr As String
‘ 接続文字列（環境に合わせて変更せよ）
connStr = “Provider=SQLOLEDB;Data Source=YOUR_SERVER;Initial Catalog=YOUR_DB;Integrated Security=SSPI;”
On Error GoTo ErrHandler
Set conn = CreateObject(“ADODB.Connection”)
conn.Open connStr
Set cmd = CreateObject(“ADODB.Command”)
With cmd
.ActiveConnection = conn
.CommandText = “INSERT INTO SentMailLog (Recipient, Subject, SentTime) VALUES (?, ?, ?)”
.Parameters.Append .CreateParameter(“@r”, 200, 1, 255, mail.To)
.Parameters.Append .CreateParameter(“@s”, 200, 1, 255, mail.Subject)
.Parameters.Append .CreateParameter(“@t”, 7, 1, , mail.SentOn)
.Execute
End With
Cleanup:
If Not conn Is Nothing Then
If conn.State = 1 Then conn.Close
Set conn = Nothing
End If
Exit Sub
ErrHandler:
Debug.Print “DB Error: ” & Err.Description
Resume Cleanup
End Sub
—
現場で差がつく3つの鉄則
1. 接続文字列は「認証」をハードコードしない
Windows認証（Integrated Security=SSPI）を利用することを強く推奨する。コード内にパスワードを埋め込むことは、セキュリティ上の脆弱性そのものだ。
2. パラメータ化クエリ（Prepared Statements）の徹底
`”INSERT … VALUES (‘” & mail.Subject & “‘)”` のような連結文字列は絶対に行うな。件名に `’` が含まれていた瞬間にクエリは破綻する（SQLインジェクションのリスクも考慮せよ）。上記のコードのように `ADODB.Command` と `Parameters` を使うのがプロの流儀だ。
3. オブジェクトの「寿命」を管理する
`Set conn = Nothing` を忘れるな。Outlookは常駐アプリだ。メモリリークは数日でユーザーのPCを重くし、君への評価を地に落とす。`Cleanup` ラベルを使った後始末の徹底は、エンジニアの品格である。
—
次のステップへ
このシステムは「送信」をトリガーにしているが、本番環境では「送信済みアイテムフォルダのアイテム追加監視（`Items.ItemAdd`）」を組み合わせることで、オフライン時の送信など、より広範囲な履歴管理が可能になる。
ただし、まずはこの「確実な一歩」を実装し、安定稼働させてほしい。
システムは作って終わりではない。運用に耐えうるコードだけが、長く愛されるツールとなるのだ。
健闘を祈る。君の書くコードが、組織の業務を支える強固なインフラとなることを期待している。
