Outlook アドインを開発・管理している組織にとって、Mailbox requirement set 1.16 は「すぐ全員が設定変更しなければならない更新」ではありません。重要なのは、Outlook add-ins で暗号化メールの復号、EWS トークンの対応判定、添付ファイルや宛先情報の処理をより実務向けに扱えるようになった点です。
Microsoft は 2026年6月30日、Outlook add-ins 向けの Mailbox requirement set 1.16 が一般提供されたと発表しました。今回の更新は、従来の COM/VSTO アドインと Web アドインの機能差を縮める流れの一部であり、特にメッセージ保護、情報漏えい対策、メール処理の自動化に関係する開発者・管理者は確認しておく価値があります。(Microsoft for Developers)
Outlook の「Mailbox requirement set 1.16」とは何か
Mailbox requirement set 1.16 は、Outlook アドインで利用できる Office JavaScript API の機能セットです。Outlook アドインは、マニフェストで「このアドインが最低限必要とする Mailbox API のバージョン」を指定します。
たとえば、アドインが Mailbox 1.16 の機能を前提にしている場合、Outlook クライアントや Exchange 環境がその要件を満たしていなければ、アドインが読み込まれない、または該当機能を使えない可能性があります。Microsoft Learn でも、マニフェストに指定した最小要件セットが、アドインを読み込める Outlook クライアントを左右すると説明されています。(Microsoft Learn)
今回の Mailbox requirement set 1.16 は、主に次の用途を強化します。
| 更新内容 | できるようになること | 影響を受けやすい利用シーン |
|---|---|---|
OnMessageDecrypt イベント | 保護されたメッセージと添付ファイルの復号処理をイベントベースで実行 | 独自暗号化、機密メール、セキュアメール運用 |
| EWS トークン対応状況の確認 API | 組織で EWS callback tokens が使えるか判定 | 旧来の EWS 依存アドイン、オンプレミス Exchange 対応 |
contentId プロパティの拡張 | インライン添付ファイルを識別しやすくする | HTML メール解析、DLP、本文内画像処理 |
| Recipients API の上限拡大 | 宛先フィールドから最大 1,000 件の宛先を取得 | 大量配信、承認フロー、DLP チェック |
SessionData 上限拡大 | セッション内で保持できるデータ量が増える | 一時状態管理、複数ステップのアドイン処理 |
今回の更新で押さえるべき最大のポイント
今回の更新を一言でまとめると、Outlook Web アドインで、セキュリティ関連のメール処理をより実装しやすくする更新です。
特に注目すべきなのは、保護されたメールを開いたタイミングで復号処理を行う OnMessageDecrypt イベントです。Microsoft の説明では、このイベントにより、Outlook アドインが暗号化されたメッセージを識別し、復号し、復号済みの本文を表示し、必要に応じてエラー通知を出せるようになります。(Microsoft for Developers)
ただし、ここで誤解しやすい点があります。Mailbox 1.16 が追加されたからといって、Microsoft がすべての暗号化方式を自動的に提供するわけではありません。暗号化・復号のプロトコル自体は、アドイン側で実装する必要があります。Microsoft Learn でも、独自の暗号化および復号プロトコルを実装する必要があると説明されています。(Microsoft Learn)
つまり、管理者や開発者が見るべきポイントは「Outlook に暗号化機能が追加されたか」ではなく、既存の暗号化メール運用や COM/VSTO アドインを、Outlook Web アドインへ移行しやすくなるかです。
Mailbox requirement set 1.16 の主な新機能
保護されたメッセージの復号をイベントベースで処理できる
Mailbox 1.16 の中心的な更新が、OnMessageDecrypt イベントです。これは、ユーザーが暗号化されたメッセージを開いたときに、アドイン側の復号処理を起動するための仕組みです。
実務上は、次のような流れで使います。
| 処理の流れ | 実装・確認する内容 |
|---|---|
| 送信者がアドインでメールを暗号化 | アドイン側で暗号化プロトコルを実装する |
| 暗号化済みメールに識別用ヘッダーを付与 | internetHeaders API などでヘッダーを設定する |
| 受信者がメールを開く | OnMessageDecrypt イベントが条件に応じて起動する |
| アドインが復号処理を実行 | 復号後の本文・添付ファイルを event.completed で返す |
| Outlook が復号済み内容を表示 | 成功・失敗・処理中などの通知が表示される |
この仕組みは、金融、医療、法務、グローバル企業の機密情報共有など、メール本文や添付ファイルの保護が重要な業務で特に有効です。
一方で、運用設計なしに導入すると失敗しやすい領域でもあります。たとえば、受信者側に同じアドインがインストールされていなければ復号できません。Microsoft Learn でも、各アドインが独自の暗号化プロトコルを使うため、メッセージは暗号化した同じアドインでのみ復号できると説明されています。(Microsoft Learn)
EWS トークンの対応状況をアドイン側で判定できる
Mailbox 1.16 では、Office.context.mailbox.diagnostics.ews.getTokenStatusAsync API により、組織で EWS callback tokens がサポートされているかを確認できるようになりました。
これは、Exchange Online と Exchange on-premises の両方を意識する組織にとって重要です。Microsoft の公式ブログでは、Exchange Online では EWS tokens が無効化されている一方、一部の組織ではオンプレミス環境が残っているため、この API により推奨される認証方式を使いつつ、必要に応じて後方互換性を維持できると説明されています。(Microsoft for Developers)
管理者目線では、ここが移行判断のポイントです。
| 環境 | 確認すべきこと | 推奨される対応 |
|---|---|---|
| Exchange Online のみ | 旧 EWS トークン依存が残っていないか | MSAL や Nested App Authentication など現行方式への見直し |
| Exchange on-premises 併用 | オンプレミス向け互換処理が必要か | API で状態判定し、分岐処理を実装 |
| グローバル混在環境 | テナント、地域、クライアントごとの差分 | 一律実装ではなく環境別にテスト |
| 旧 COM/VSTO 連携あり | 認証・メールアクセス方式が古くないか | Web アドイン移行時に認証設計を再確認 |
特に、以前から EWS や Exchange callback token に依存している Outlook アドインは、Mailbox 1.16 を「新機能」として見るだけでなく、認証方式の棚卸しのきっかけとして扱うべきです。
インライン添付ファイルを contentId で識別しやすくなる
HTML メールでは、本文中に表示される画像が添付ファイルとして扱われることがあります。従来、この種のインライン添付を本文内の画像と正確に対応付ける処理は面倒になりがちでした。
Mailbox 1.16 では、Attachment API の contentId プロパティのサポートが拡張され、インライン添付ファイルを識別しやすくなっています。Microsoft Learn の 1.16 API 一覧でも、AttachmentDetails と AttachmentDetailsCompose において、インライン添付ファイルの content identifier を取得できることが示されています。(Microsoft Learn)
これは、次のような処理で役立ちます。
| 活用シーン | 具体例 |
|---|---|
| DLP チェック | 本文内画像に機密情報が含まれていないか検査する |
| メールレンダリング | HTML 本文内の cid: 参照と添付ファイルを対応付ける |
| 暗号化・復号処理 | 復号後の本文とインライン画像を正しく再構成する |
| アーカイブ処理 | メール本文と画像添付を分離せず保存する |
見落としやすいのは、通常の添付ファイルと本文内画像を同じロジックで扱うと、メール表示や監査ログにズレが出る可能性がある点です。DLP や監査系アドインを運用している場合は、インライン添付を「添付ファイル一覧に出るもの」だけで判断しない設計が必要です。
Recipients API で最大 1,000 件の宛先を取得できる
Mailbox 1.16 では、Recipients API の getAsync メソッドで、メールアイテムの各宛先フィールドから最大 1,000 件の宛先を取得できるようになりました。Microsoft の公式ブログでは、この上限拡大により、DLP ソリューションが大規模な宛先リストを一度の操作で評価しやすくなると説明されています。(Microsoft for Developers)
これは、特に次のような組織で影響があります。
- 大人数向けの社内通知メールを扱う
- 外部ドメイン宛ての送信チェックを行う
- Bcc や配布リストを含む宛先監査を行う
- 承認フローや送信前警告を Outlook アドインで実装している
- 宛先数に応じて暗号化やラベル付けを切り替える
ただし、取得できる件数が増えたからといって、すべての処理をクライアント側だけで行うのが最適とは限りません。1,000 件の宛先を対象に外部ドメイン判定、部署判定、例外ルール判定を行う場合、パフォーマンスやタイムアウトにも注意が必要です。
実務では、次のような設計が安全です。
| 判断項目 | 推奨設計 |
|---|---|
| 宛先数が少ない | クライアント側で即時チェック |
| 宛先数が多い | サーバー側 API と組み合わせて判定 |
| 外部ドメイン混在 | ドメイン分類ルールをキャッシュする |
| 配布リスト利用 | 展開済み宛先と表示上の宛先の違いを確認 |
| 送信ブロックあり | ユーザーに理由と解除手順を明示する |
SessionData の上限が 2,621,440 文字に拡大
Mailbox 1.16 では、SessionData オブジェクトでアドインごとに最大 2,621,440 文字を扱えるようになりました。これは、単一セッション内で一時的な状態や処理データを保持したいアドインにとって便利な更新です。(Microsoft Learn)
たとえば、次のような用途が考えられます。
| 用途 | 保存するデータの例 |
|---|---|
| 複数ステップのチェック | 宛先判定結果、途中の検査状態 |
| 暗号化・復号フロー | 復号処理に必要な一時的な文脈情報 |
| UI 状態の保持 | ユーザーが選択した分類、警告確認状態 |
| DLP 処理 | 一時的な検査結果、例外判定フラグ |
ただし、SessionData は永続的なデータベースではありません。監査ログ、承認履歴、証跡として残すべき情報は、適切なサーバー側ストレージや Microsoft 365 側の監査機能と組み合わせるべきです。
影響範囲：誰が確認すべきか
Mailbox requirement set 1.16 の影響は、Outlook を使うすべての一般ユーザーに一律で及ぶものではありません。主な対象は、Outlook アドインを開発・配布・管理している組織です。
| 対象者 | 確認すべきポイント |
|---|---|
| Microsoft 365 管理者 | 組織内で利用中の Outlook アドインが Mailbox 1.16 に対応するか |
| Outlook アドイン開発者 | マニフェスト、API 判定、フォールバック処理を見直す |
| セキュリティ担当者 | 暗号化、DLP、外部送信チェックへの活用可否を確認する |
| Exchange 管理者 | Exchange Online とオンプレミス環境の差分を把握する |
| 情シス・ヘルプデスク | アドインが表示されない、復号できない場合の切り分け手順を用意する |
| COM/VSTO 利用組織 | Web アドイン移行の候補機能として評価する |
特に、次の条件に当てはまる組織は優先度が高いです。
- Outlook の COM/VSTO アドインを長年使っている
- メール暗号化やセキュアメール製品を独自運用している
- DLP や送信前チェックを Outlook アドインで実装している
- Exchange Online と Exchange Server を併用している
- グローバル拠点で Outlook のクライアント種類が統一されていない
- 新しい Outlook for Windows への移行を進めている
対応クライアントと注意すべき互換性
Mailbox 1.16 は一般提供されましたが、すべての Outlook クライアントで同じように使えるわけではありません。Microsoft Learn のサポート表では、Exchange Online は Mailbox 1.16 をサポートし、Outlook on the web、新しい Outlook for Windows、Microsoft 365 サブスクリプション版のクラシック Outlook for Windows などで 1.16 がサポート対象に含まれています。一方、Exchange on-premises は 1.5 までのサポートとして示されています。(Microsoft Learn)
特に重要なのは、クライアントとサーバーの両方を見ることです。Outlook クライアントが新しくても、接続先の Exchange 環境が対応していなければ、利用できる requirement set は制限される可能性があります。
| 環境 | Mailbox 1.16 利用時の見方 |
|---|---|
| Outlook on the web + Exchange Online | 対応候補として優先的に検証しやすい |
| 新しい Outlook for Windows + Exchange Online | Web アドイン移行の中心候補 |
| クラシック Outlook for Windows | バージョンとビルド確認が必要 |
| Mac 版 Outlook | 機能ごとの対応状況を個別確認 |
| Outlook for iOS / Android | Mobile は要件セット上の制約があるため別途確認 |
| Exchange on-premises | Mailbox 1.16 前提の設計は慎重に判断 |
クラシック Outlook for Windows では、Mailbox 1.16 のサポートは Version 2602、Build 19725.20126 以降として示されています。更新チャネルによって配信タイミングが異なるため、管理者は Microsoft 365 Apps の更新チャネルと実際のビルドを確認する必要があります。(Microsoft Learn)
設定変更や移行期限はあるのか
今回の Mailbox requirement set 1.16 の公開自体について、Microsoft の公式ブログでは、管理者が特定日までに設定変更を行う必要がある、または既存アドインが強制的に移行される、という内容は示されていません。(Microsoft for Developers)
そのため、現時点での実務的な整理は次のとおりです。
| 項目 | 判断 |
|---|---|
| Mailbox 1.16 対応の強制 | 公式発表上、強制移行としては示されていない |
| 管理センターでの即時設定変更 | 通常は不要 |
| 既存アドインの即時修正 | 1.16 の API を使わない限り必須ではない |
| COM/VSTO からの移行期限 | 今回の発表単体では期限告知ではない |
| EWS トークン依存 | Exchange Online では既に注意が必要 |
| 推奨アクション | 利用中アドインの API 依存と対応環境を棚卸しする |
ただし、「設定変更が不要」という意味を「何もしなくてよい」と捉えるのは危険です。特に EWS トークン、COM/VSTO アドイン、暗号化メール、DLP アドインに関係する組織では、今回の更新をきっかけに設計を見直すべきです。
管理者が確認すべきチェックリスト
Mailbox requirement set 1.16 への対応では、いきなり本番アドインを更新するよりも、利用状況と依存 API の棚卸しから始めるのが安全です。
| 確認項目 | 具体的な作業 | 優先度 |
|---|---|---|
| 利用中の Outlook アドイン一覧 | Microsoft 365 管理センター、Exchange 管理、配布ポリシーを確認 | 高 |
| アドインの種類 | COM/VSTO、Office.js、ストアアドイン、社内開発アドインを分類 | 高 |
| Mailbox requirement set | マニフェストの MinVersion を確認 | 高 |
| EWS 依存 | EWS callback token、Exchange user identity token の利用有無を確認 | 高 |
| クライアント環境 | Outlook on the web、新 Outlook、クラシック Outlook、Mac、Mobile を分類 | 高 |
| Exchange 環境 | Exchange Online のみか、オンプレミス併用か確認 | 高 |
| セキュリティ機能 | 暗号化、DLP、送信前警告、外部宛先チェックを棚卸し | 中 |
| フォールバック処理 | Mailbox 1.16 非対応環境での代替動作を確認 | 中 |
| ヘルプデスク準備 | 「アドインが出ない」「復号できない」場合のFAQを作成 | 中 |
マニフェストの最小要件を上げすぎない
Mailbox 1.16 の機能を使いたい場合でも、マニフェストの最小要件を安易に 1.16 に上げるのは避けた方がよい場合があります。Microsoft Learn では、開発者はシナリオに不可欠な API を含む最も早い requirement set を使うべきだと説明されています。(Microsoft Learn)
たとえば、アドイン全体の基本機能は Mailbox 1.8 で動き、暗号化メールの復号機能だけが Mailbox 1.16 を必要とする場合、次のような設計が現実的です。
if (Office.context.requirements.isSetSupported("Mailbox", "1.16")) {
// Mailbox 1.16 の機能を使う処理
} else {
// 代替処理、またはユーザーへの案内
}このように実行時判定を入れておけば、古いクライアントでは基本機能だけを提供し、新しいクライアントでは 1.16 の機能を有効化できます。
Outlook クライアントの種類を分けてテストする
Outlook アドインは、同じ Microsoft 365 テナントでもクライアントによって挙動が変わることがあります。少なくとも次の組み合わせは分けて検証するべきです。
| テスト対象 | 確認する内容 |
|---|---|
| Outlook on the web | Mailbox 1.16 API の動作、イベント発火、UI 通知 |
| 新しい Outlook for Windows | Web 版と同等に動くか、ポリシー影響はないか |
| クラシック Outlook for Windows | バージョン 2602 / Build 19725.20126 以降か |
| Mac 版 Outlook | 対象機能がサポートされるか |
| iOS / Android | そもそも対象シナリオに含めるべきか |
| Exchange on-premises | Mailbox 1.16 前提の処理が動かない場合の代替策 |
特にグローバル企業では、国や拠点ごとに Outlook の更新チャネルが異なることがあります。日本本社では動作しても、海外拠点の半期エンタープライズチャネルでは未対応、というケースもあり得ます。
開発者が実装時に注意すべきポイント
OnMessageDecrypt はセキュリティ設計とセットで考える
OnMessageDecrypt は便利なイベントですが、単に「メールを開いたら復号する」だけの実装では不十分です。
確認すべき観点は次のとおりです。
| 観点 | 確認内容 |
|---|---|
| 認証 | 復号を許可するユーザーをどう判定するか |
| 鍵管理 | 復号キーをどこで管理し、どう取得するか |
| 監査 | 誰がいつ復号したかを記録するか |
| エラー時の案内 | 復号できない場合にユーザーへ何を表示するか |
| オフライン時 | アドインが読み込めない場合の挙動をどうするか |
| 返信・転送 | 復号後の返信や転送時に再暗号化するか |
Microsoft Learn では、復号されたコンテンツは Outlook クライアントに保存されず、ユーザーがメッセージを開くたびに復号されると説明されています。また、暗号化されたメッセージは復号されるまで返信や転送ができない点も示されています。(Microsoft Learn)
この仕様はセキュリティ上は有利ですが、ユーザー体験には影響します。復号に時間がかかる、アドインが読み込めない、ネットワークが不安定といった場面では、問い合わせが増える可能性があります。
EWS トークン依存を段階的に減らす
Mailbox 1.16 の EWS トークン状態確認 API は、旧方式を延命するためだけの機能ではありません。むしろ、環境に応じて現在の認証方式を判定し、より推奨される認証方式へ移るための補助線として使うべきです。
Microsoft Learn では、Exchange Online の従来の user identity tokens や callback tokens はサポートされなくなっており、 delegated user access や user identity が必要な Outlook アドインでは MSAL と Nested App Authentication の利用が推奨されています。(Microsoft Learn)
実務では、次の順番で進めると安全です。
| 手順 | 作業内容 |
|---|---|
| 現状把握 | アドイン内で EWS callback token を使っている箇所を洗い出す |
| 影響分類 | Exchange Online ユーザーとオンプレミスユーザーを分ける |
| 判定実装 | getTokenStatusAsync で利用可否を確認する |
| 代替設計 | MSAL / NAA など現行方式への移行を検討する |
| 段階移行 | 拠点・部門単位でテストし、例外を減らす |
よくある誤解と失敗しやすいポイント
Mailbox 1.16 にすればすべての Outlook で動くわけではない
Mailbox 1.16 は一般提供されていますが、対応可否は Outlook クライアント、Exchange 環境、更新チャネル、アドインの実装に左右されます。
特に、Exchange on-premises 環境を含む場合は要注意です。Microsoft Learn のサポート表では、Exchange on-premises Subscription Edition、Exchange 2019、Exchange 2016 のサポート範囲は Mailbox 1.5 までとして示されています。(Microsoft Learn)
COM/VSTO アドインが自動で置き換わるわけではない
今回の更新は、COM/VSTO と Web アドインの機能差を縮める方向のものですが、既存の COM/VSTO アドインが自動的に Web アドインへ変換されるわけではありません。
移行する場合は、次のような再設計が必要です。
| COM/VSTO 側の考え方 | Web アドインでの見直し |
|---|---|
| Windows クライアント前提 | Outlook on the web / 新 Outlook / Mac も含めて設計 |
| ローカル環境への依存 | Web ランタイムとクラウド API 中心に再構成 |
| 独自認証処理 | Microsoft identity platform に合わせて見直し |
| クライアント側処理中心 | サーバー側 API との役割分担を再設計 |
| Outlook バージョン依存 | requirement set による機能判定を実装 |
宛先 1,000 件取得を前提に重い処理を入れすぎない
Recipients API の上限拡大は便利ですが、送信前チェックで大量の宛先を同期的に処理すると、ユーザー体験が悪化します。
たとえば、送信ボタンを押した後に 1,000 件の宛先すべてを外部 API で逐次照会すると、処理が遅くなり、送信ブロックやタイムアウトの原因になります。
現実的には、次のような工夫が必要です。
- ドメイン分類や部門情報はキャッシュする
- 明らかに安全な宛先は早期に除外する
- 高リスク条件だけサーバー側で詳細判定する
- ユーザーに「何を確認しているのか」を表示する
- 失敗時の既定動作を事前に決める
復号できない場合のユーザー案内を設計していない
暗号化メールは、復号できないと業務停止につながりやすい領域です。アドインが入っていない、古い Outlook を使っている、オフラインである、権限がない、といった理由で復号できない場合に、ユーザーが次に何をすべきか分からない状態は避けるべきです。
最低限、次の案内を用意しておくとヘルプデスク負荷を減らせます。
| 状況 | ユーザー向け案内の例 |
|---|---|
| アドイン未インストール | 指定の Outlook アドインを追加する手順 |
| 非対応クライアント | Outlook on the web または新しい Outlook で開く案内 |
| 権限不足 | 送信者または管理者への問い合わせ先 |
| 一時エラー | 別のメールを開いてから再度開く、Outlook を再起動する |
| 処理時間超過 | 添付ファイルサイズやネットワーク状態の確認 |
実務でのおすすめ対応手順
Mailbox requirement set 1.16 は、急いで本番展開するより、対象アドインと業務シナリオを絞って検証するのが適しています。
| ステップ | 作業 | 成果物 |
|---|---|---|
| 1 | Outlook アドインの棚卸し | アドイン一覧、所有部門、用途 |
| 2 | API 依存の確認 | Mailbox requirement set、EWS 依存、認証方式 |
| 3 | 対象シナリオの選定 | 暗号化、DLP、宛先チェックなど |
| 4 | 対応環境の確認 | Outlook クライアント、Exchange 環境、更新チャネル |
| 5 | PoC 実装 | 1.16 API の動作確認 |
| 6 | フォールバック設計 | 非対応環境での代替処理 |
| 7 | 管理者展開 | 配布ポリシー、利用者案内、ヘルプデスク手順 |
| 8 | 本番監視 | エラー、復号失敗、処理時間、問い合わせ傾向 |
優先順位としては、まず EWS トークン依存の有無を確認し、次に暗号化・DLP・大量宛先処理のような業務影響の大きいアドインから検証するのが現実的です。
Outlook 管理者・開発者が今やるべきこと
Mailbox requirement set 1.16 は、Outlook アドインをよりセキュアで実務的に使うための重要な更新です。特に、保護メールの復号、EWS トークン判定、インライン添付の識別、最大 1,000 件の宛先取得、SessionData 上限拡大は、セキュリティ系アドインや業務アドインに直接関係します。
一方で、今回の発表は「全組織に即時移行を求めるもの」ではありません。重要なのは、既存アドインがどの API に依存しているか、どの Outlook クライアントで動かす必要があるか、Exchange Online とオンプレミスのどちらを対象にするかを整理することです。
まずは、組織内の Outlook アドインを棚卸しし、EWS 依存、COM/VSTO 依存、暗号化・DLP 関連のアドインを優先的に確認してください。そのうえで、Mailbox 1.16 の機能を使うべき箇所だけを段階的に検証すれば、既存環境を壊さずに Outlook Web アドインへの移行準備を進められます。
コメント