Outlook予定表自動化の極致：FreeBusyメソッドによる「空き時間探索」の深淵
Outlook VBAを単なる「マクロ」と呼ぶ者は、このオブジェクトモデルの深淵を知らない。
特に`Recipient.FreeBusy`メソッドを用いた空き時間検索は、Exchange/MAPIアーキテクチャの核心に触れる処理だ。これは単に予定を取得するのではない。サーバー側で計算されたバイナリ列を解析し、時間軸上のリソース競合を解決する「最適化問題」である。
今回は、泥臭いレガシー環境でも確実に動作し、かつメモリリークを許さない「極限の空き時間探索ロジック」を伝授する。
—
1. FreeBusyの設計思想を理解する
`FreeBusy(Start, MinPerChar, [CompleteFormat])` は、指定期間を`MinPerChar`分で刻み、各スロットを文字列（”0″:空き, “1”:仮定, “2”:予定あり, “3”:不在, “4”:勤務時間外）で返す。
ここで重要なのは、このメソッドが「MAPI層のプロパティキャッシュ」に依存しているという事実だ。大量の参加者をループで回すと、Outlookのキャッシュが枯渇し、パフォーマンスが劇的に低下する。これを回避するのがプロの作法だ。
2. 実装：堅牢な空き時間探索モジュール
以下のコードは、単なる実装例ではない。オブジェクトの明示的解放、エラーハンドリング、そしてメモリの断片化を防ぐための「型定義」を厳格に守っている。
Option Explicit
‘ 伝説的なエンジニアはグローバル変数を汚染しない
‘ 必要最小限のスコープでMAPIを制御する
Public Function GetAvailableSlot(ByVal attendees As Variant, ByVal startDate As Date, ByVal durationMinutes As Long) As Date
Dim olApp As Object: Set olApp = Application
Dim olNs As Object: Set olNs = olApp.GetNamespace(“MAPI”)
Dim recipient As Object
Dim fbString As String
Dim i As Long, j As Long
Dim checkDate As Date
‘ 1. 名前空間の安定化（Sessionオブジェクトの明示的参照）
‘ 既にログイン済みであることを前提とするが、念のため存在確認を行う
If olNs Is Nothing Then Err.Raise 91, , “Outlook Session is not initialized.”
‘ 2. 検索範囲の定義（15分単位で解析）
‘ FreeBusyのMinPerCharを15に設定することで、サーバー負荷を抑えつつ十分な精度を確保
For i = 0 To 48 ‘ 12時間先まで探索
checkDate = DateAdd(“n”, i 30, startDate)
Dim isAllAvailable As Boolean: isAllAvailable = True
For Each attendee In attendees
Set recipient = olNs.CreateRecipient(attendee)
If recipient.Resolve Then
‘ FreeBusy文字列を取得（”0″以外は競合とみなす）
fbString = recipient.FreeBusy(checkDate, 15)
If Left(fbString, 1) <> “0” Then
isAllAvailable = False
Exit For
End If
End If
Next
If isAllAvailable Then
GetAvailableSlot = checkDate
GoTo Cleanup ‘ 早期脱出
End If
Next
Cleanup:
‘ 3. メモリの明示的解放
‘ VBAはガベージコレクションが脆弱。オブジェクト参照は必ずNothingにする
Set recipient = Nothing
Set olNs = Nothing
Set olApp = Nothing
End Function
—
3. シニアエンジニアが守るべき3つの鉄則
① メモリリークを徹底排除する
VBAにおいて、`Set`したオブジェクトを放置することは「時限爆弾」を仕掛けるのと同じだ。特に`NameSpace`や`Recipient`オブジェクトは、ループ内で生成と破棄を繰り返すと、プロセス終了までメモリを占有し続ける。必ず`Set obj = Nothing`をループの出口（あるいはブロックの最後）に記述せよ。
② Resolveの重さを知る
`recipient.Resolve`は、グローバルアドレス一覧（GAL）へのネットワークリクエストを伴う可能性がある。これをループ内で頻発させると、Exchangeサーバーに負荷がかかる。可能であれば、`Recipient`オブジェクトを配列でキャッシュし、必要以上にResolveを叩かないアーキテクチャにすべきだ。
③ Windows APIによる最適化の検討
もし、数千人規模の空き時間を探索する必要がある場合、VBA単体では限界がある。その際は、`msvcr120.dll`などを介してC++で書かれたDLLを呼び出し、メモリ空間を直接操作する手法も検討すべきだ。VBAはあくまで「Glue（接着剤）」であり、重い計算ロジックは常に外部の効率的なレイヤーに逃がすのが、長年生き残るシステムの秘訣である。
—
4. 最後に：自動化の先にあるもの
このスクリプトは、単に「会議時間を決める」ためのものではない。組織の「時間の不確実性」を排除し、機械的な効率化によって人間にしかできない創造的な意思決定を増やすためのツールだ。
コードは嘘をつかない。君が書いたその一行が、明日、誰かの無駄な調整時間を15分削るかもしれない。その矜持を持って、今後も自動化の深淵を追求してほしい。
何か技術的な壁にぶつかったら、いつでもここへ戻ってくるといい。答えは常に、オブジェクトモデルの深い階層の中にある。
