📌結論ファースト
2025年以降でも、同じサーバ内で「SMTP AUTH」と「Microsoft Graph」を併用することは可能です。
どちらもMicrosoft公式がサポートする正規の手段で、機能上の競合はありません。
つまり、いきなり全面切替する必要はなく、並行稼働しながら段階的に移行できるのです。
✅なぜ並行稼働できるのか？
別プロトコルだから衝突しない
SMTP AUTHはメール送信専用のSMTPプロトコル（587/TLS）。
Graph APIはHTTPSベースのREST API。ポートも異なるため干渉しません。公式ドキュメントが並行利用を否定していない
Microsoftは「Graphに移行を推奨」していますが、「SMTP AUTHを使ってはいけない」とは明記していません。
むしろ「OAuth2対応のSMTP AUTHは継続利用可能」とされています。システム上もレート管理が別
SMTPは「1分30通／1日1万宛先」制限。
GraphはHTTP 429で返すスロットリング方式。
管理レイヤーが別なので、同時利用しても干渉しません。
🔧切替を進めるためのステップ
① 認証方式を整える
- SMTP AUTHは**OAuth 2.0（Modern Auth）**必須
- GraphはAzure AD (Entra ID) にアプリを登録し、Mail.Send権限を付与
② 並行稼働の始め方
- まずは社内向けの通知メールをGraphで送信
- 外部顧客向けは従来通りSMTP AUTHで送信
- 問題がなければ徐々にGraphの比率を増やしていく
③ スロットリングとリトライ設計
- SMTP：1分30通制限を超えないように送信キューを設計
- Graph：429/503が返ってきたらRetry-Afterヘッダを尊重し、指数バックオフでリトライ
④ 添付ファイルの扱い
- Graphは3MB超の添付を送る場合**Upload Session（分割アップロード）**必須
- SMTPは添付制限が厳しいため、大容量はGraphに寄せると安定
⚠️2025年以降の注意点
- Basic認証は廃止
→ SMTP AUTHを残す場合も、必ずOAuth対応に切替えること - 権限管理はRBACへ移行
従来の「Application Access Policy」はレガシー化。新規は「RBAC for Applications」で権限を絞るのが推奨。 - 運用監視を徹底
Graphのレスポンスコード／SMTPの送達失敗を必ずログ化して可視化。
📘実例：段階移行のシナリオ
例えば、とある製造業の社内通知システム。
これまで「生産ラインの停止アラート」をSMTP AUTHで送信していたが、添付画像付きの詳細レポートでは容量超過でトラブルが発生。
→ 新規レポート通知だけGraph APIに移行し、アラート通知は従来通りSMTP。
半年後にトラブルがゼロになった段階で、全面的にGraphへ切替。
ポイントは「まず低リスクな社内宛から試す」こと。
社外顧客向けメールをいきなりGraphに変えると、予期せぬ認証エラーで迷惑がかかるリスクがあります。
💡比喩で理解する
イメージとしては、自宅の水道管と新しい給水タンクを併用するようなもの。
古い水道管（SMTP AUTH）はまだ水が流れるけど、そのうち老朽化で廃止予定。
新しいタンク（Graph API）は高機能で水量も調整しやすい。
→ しばらくは両方つないで流し、問題なければ新しいタンクに全面切替すればいい、という考え方です。
🔍運用設計で意識すべき点
- 誰として送るかの制御
Graphのアプリ権限は「誰としてでも送れる」強力な機能。必ずRBACで制御。 - 監査ログを残す
OAuthトークンの利用記録、GraphのAPIレスポンスは監査ログとして必須。 - 障害時のフォールバック
Graphの障害に備えて、SMTPを残しておくのは有効な戦略。
📌要点まとめ
- 2025年以降もSMTP AUTH（OAuth）とGraphは同一サーバで併用可能
- Basic認証は廃止 → OAuth認証へ完全移行必須
- 段階的にGraphへ比率を移し、RBACとスロットリング対策が成功のカギ
👉 この記事はIT管理者やシステム担当者だけでなく、社内システムを運用する中小企業の方にも役立つ内容です。
並行稼働をうまく使えば、「切替リスクゼロ」で移行を進められます。