Microsoft 365 基本認証停止 — 2026年4月以降のKintoneメール送信
2026年4月1日、Microsoft 365がExchange OnlineのSMTP基本認証を完全停止します。これは、多くのKintoneメール送信プラグインが依存していた認証方式です。この記事では、実際に影響を受けるプラグイン・現場の症状・対応オプションを、Kintoneコンサルタントとして2019年から現場に立ってきた視点で整理します。
この記事の要点
Microsoft 365の基本認証停止は2026年4月1日が期限。SMTP経由でメールを送っているKintoneプラグインは、この日を境に送信不可になります。対応策はOAuth 2.0対応のメール送信プラグインへの切り替えです。Kinplug Mailは元々OAuth基盤で設計されており、既存プラグインからの移行を無料で支援しています。
何が起きるのか
Microsoftは、Exchange Onlineのセキュリティ強化の一環として、長年使われてきた「基本認証（Basic Authentication）」を完全廃止します。具体的には、以下の認証方式が使えなくなります。
- SMTP AUTH（SMTP基本認証による送信）
- IMAP/POP3 基本認証（メール受信）
- Exchange ActiveSync 基本認証
- EWS 基本認証
- PowerShell 基本認証
これらはすべて、ユーザー名とパスワードをBase64でエンコードしてサーバーに送るという、シンプルだが脆弱な認証方式です。Microsoftは2022年10月から段階的に停止を開始し、2026年4月で最終期限を迎えます。SMTP AUTHについては、管理者がテナント全体でオプトアウトを選んでいる場合、それ以前から使えなくなっている可能性もあります。
Googleはすでに2024年9月にGmailの同等機能を停止しており、この流れはメール業界全体の方向です。
Kintoneメール送信に与える影響
Kintoneからメールを送信する仕組みは、大きく以下の4パターンに分かれます。それぞれ影響の有無を確認します。
| 送信方式 | 2026年4月以降 | 影響内容 |
|---|---|---|
| SMTP基本認証プラグイン | 送信不可 | パスワード認証が拒否される |
| OAuth 2.0対応プラグイン | 影響なし | Microsoft Graph API経由で正常動作 |
| Kintone標準通知（受信側） | 影響なし | 受信専用のため認証不要 |
| 自社実装のJavaScript + SMTP | 要書き換え | OAuth実装に変更必要 |
現場で圧倒的に多いのは、1番目のSMTP基本認証プラグインと、4番目の自社実装です。両者とも、4月1日を過ぎた時点で突然メールが送れなくなります。
既に起きている現場の症状
2026年4月の数ヶ月前から、Microsoftは対象テナントに対してSMTP AUTHを段階的に無効化し始めています。症状の典型例：
- 特定のユーザーでだけメール送信が失敗する（テナント管理者がオプトアウトを進めている場合）
- エラーログに
5.7.30 ClientSubmitTime is requiredまたはSmtpClientAuthentication is disabled for the Tenantが頻発する - Kintoneのプロセス管理アクションでメールだけが止まり、他のアクションは正常
- 送信のタイムアウトが増え、一定の割合で失敗するが、原因が不安定に見える
これらの症状が出ている場合、すでにMicrosoftから実質的な基本認証の停止が始まっていると考えてよいです。
対応オプション
オプション1. 基本認証の再有効化（暫定、推奨しない）
Microsoft 365管理センターで、ユーザー単位でSMTP AUTHを再有効化することは技術的に可能です。ただし、これは完全な解決ではなく、時間稼ぎです。2026年4月1日には、このオプション自体が無くなります。それまでの数週間・数ヶ月を急場しのぎする目的以外で選択する理由は、基本的にありません。
加えて、基本認証はフィッシングによるパスワード漏洩時の横展開リスクが高く、セキュリティ監査で指摘される可能性もあります。金融・医療・公共機関向けのKintone環境では、そもそも管理者が再有効化を許可しない場合もあります。
オプション2. OAuth 2.0対応プラグインへの切り替え（推奨）
最も確実で、最も早期に決着させられる方法です。OAuth 2.0対応のメール送信プラグインは、Microsoft Graph APIを経由してメールを送信します。基本認証は使わず、ユーザーが一度Microsoft画面で認証すれば、それ以降はトークンベースで送信できます。
具体的な利点：
- 基本認証停止の影響を完全に受けない
- Send As（委任送信）対応で、共有メールボックスからの送信も可能
- 送信元ドメインのSPF/DKIM/DMARCが正しく設定される
- 監査ログが充実し、誰が送信したかが明確になる
- APIレート制限の管理がMicrosoft側で行われる
オプション3. Kintone標準機能のみで運用
Kintoneには受信側のメール通知機能がありますが、能動的にメールを送信する機能は限定的です。プロセス管理のステータス変更通知・アプリ権限変更通知など、「Kintoneから自動的に出ていく」メールはKintone標準機能でも送信できますが、これは送信元がCybozuのメールサーバーから出るため、基本認証停止の影響を受けません。
ただし、顧客宛のカスタムメール（見積書送付・進捗連絡・お礼メール等）を自動化したい場合、Kintone標準機能だけでは不十分です。
移行の実際の流れ
既存のSMTP基本認証プラグインから、OAuth対応プラグインへの移行手順は、シンプルにまとめるとこうなります。
- OAuth対応プラグインをインストール（既存プラグインはまだ削除しない）
- 送信元アカウントをOAuth認証（Google または Microsoftの画面で一度だけ）
- 送信テンプレート・宛先ロジック・プロセス管理アクションを移植
- テスト送信で正しく動くか確認
- 既存プラグインを無効化して、新プラグインに切り替え
- 2週間ほど並行運用して、問題がないことを確認
- 既存プラグインを削除
実際の移行作業時間は、テンプレート数と送信ロジックの複雑さに応じますが、私たちの経験では3～8時間が典型的です。プロセス管理連動が複雑な環境では1～2日かかります。
よくある移行時の注意点
Send Asが必要な場合、Exchange側での委任設定が必須
共有メールボックス（例：info@your-company.com）から、個別の社員アカウントを使って送信する場合、Microsoft 365の管理者がExchange Admin Centerで「Send As」権限を明示的に委任する必要があります。これはプラグイン側では制御できない範囲で、必ず管理者に依頼が必要です。
Gmail側の「アプリパスワード」は使えない
Google Workspaceで以前使われていた「アプリパスワード」は、2024年9月以降はOAuth 2.0に統一されました。既存のアプリパスワード経由で送信していた場合も、同様にOAuth対応プラグインへの移行が必要です。
複数サブドメイン環境での注意
Kintoneを複数サブドメインで運用している場合（例：sales.kintone.comとops.kintone.com）、OAuth接続はサブドメイン単位でスコープされるべきです。サブドメイン間で接続情報が共有されると、誤送信のリスクが出ます。Kinplug Mailでは、接続情報を保存するKintoneアプリ側でサブドメインを記録し、実行時にスコープを確認します。
Kinplug Mailの位置づけ
Kinplug Mailは、OAuth 2.0を前提に設計されたKintoneメール送信プラグインです。SMTP基本認証はそもそもサポート対象外として開発しており、Google・MicrosoftのAPI仕様変更の影響を受けないアーキテクチャです。
- Gmail および Microsoft 365対応
- 共有メールボックスのSend As送信対応
- サブドメイン単位でのOAuth接続スコープ
- 既存プラグインからの無料移行支援
- 14日間のトライアルで実環境検証が可能
- 設定はKintone内で完結。外部ポータルへのログイン不要
2026年4月が近づくにつれて、この種のプラグインへの需要は急増しています。移行をお考えの場合、時間に余裕を持って取りかかることをお勧めします。
参考リンク
OAuth移行についてのご相談は support@kinplug.com までお気軽にご連絡ください。緊急対応の場合はその旨ご明記いただければ、当日対応します。