WordでPDF保存すると感度ラベル強制が出ない原因とMicrosoft Purviewで塞ぐ対策（DLP/自動ラベル）

Wordの「名前を付けて保存→PDF」や「エクスポート→PDF」で、組織で感度ラベル（Sensitivity label）の必須設定をしていても、ラベル選択の強制／プロンプトが出ず未ラベルのPDFが作成できるケースがあります。原因と、Microsoft Purview（自動ラベル・DLP・Endpoint DLP）で実務的に塞ぐ方法を解説します。

WordでPDF保存すると感度ラベル強制が出ない現象とは

Word（Excel / PowerPointも同様）で機密情報を含む資料を作成したあと、そのまま「名前を付けて保存 → PDF」を実行すると、本来は「ラベルを付けてから保存してください」と促されるはずなのに、ラベルを選ばないままPDFを保存できてしまうことがあります。

環境によっては、リボンやタイトルバーに感度ラベルの選択UI（ドロップダウン）が表示されているのに、PDF保存のタイミングでは選択必須としてブロックされない、という形で現れることもあります。結果として、未ラベル（＝組織の想定より保護が弱い、もしくは保護なし）のPDFが作られ、共有・送信の経路によっては漏えいリスクにつながります。

結論：原因は「設定ミス」ではなく、PDF保存がラベリング強制をすり抜ける既知の制限

Microsoft側の説明として、OfficeデスクトップアプリにおけるMIP（Microsoft Information Protection）のラベル必須（Mandatory labeling）の強制は、基本的に保存／名前を付けて保存（.docx / .xlsx / .pptx などのネイティブ形式）で発火します。

一方で「Save As PDF（PDFとして保存）」は、操作としては“変換・出力”に近く、ラベリングエンジンを通らずにPDFを作成してしまうため、ラベル強制が発火しない（＝プロンプトが出ない、保存が止まらない）という既知の制限として案内されています。

重要なのは、これが「元のWordファイルを先に保存していないから」だけで説明できる問題ではなく、PDF保存という経路が、ラベル強制の仕組みを迂回し得るという点です。対策は、保存操作そのものを“直す”のではなく、迂回しても漏えいしない設計に寄せるのが現実解になります。

まず押さえる：感度ラベルの「必須ラベル付け」は何を守る仕組みか

感度ラベルは、ドキュメントやメールなどのデータに「公開」「社内限定」「社外秘」「極秘」などの分類を付け、その分類に応じて暗号化やアクセス制御、ヘッダー／フッター／透かしといったマーキングを適用できる仕組みです。

そしてラベルポリシーでは、次のような運用を組織として強制できます。

既定（デフォルト）ラベル：ラベル未設定のドキュメントやメールに、あらかじめ決めたラベルを付けて開始する
必須ラベル付け（Mandatory labeling）：保存・送信などの前に、ラベル適用を要求する
ダウングレード／削除の正当化：より低いラベルに変更したり削除したりする際に理由を求める

ただし、必須ラベル付けは万能ではなく、アプリや操作の種類によって適用範囲・挙動が異なります。今回の「PDF保存で強制が出ない」も、そのギャップが表面化した代表例です。

操作別に整理：どこでラベル強制が効き、どこで抜けやすいのか

現場で混乱しやすいのは、「Word上で感度ラベルが見えている＝どの出力でも強制されるはず」と思い込みやすい点です。実際には、“保存（ネイティブ）”と“変換・出力（PDFなど）”で挙動がズレることがあります。

操作	代表的なメニュー	必須ラベル付け（強制）の効き方	実務上のポイント
ネイティブ保存	保存 / 名前を付けて保存（.docx等）	ラベル必須が発火しやすい	「まずネイティブで保存」を標準手順にする
PDFへ変換	名前を付けて保存→PDF / エクスポート→PDF	ラベル強制が発火しない（抜け道になり得る）	“未ラベルPDFが外に出ない”対策が重要
ラベル付きPDFの生成	（事前にラベルを付けたファイルを）PDF化	PDFがラベルを継承するケースがある	「先にラベル適用→PDF化」を徹底
印刷→PDF	印刷→Microsoft Print to PDF 等	アプリにより制限・ブロックの考え方が異なる	Endpoint DLP等で印刷経路も含めて制御

「PDFとして保存」と「印刷してPDF」は別物

“PDFを作る”という点では同じでも、内部的にはまったく別の経路です。

PDFとして保存（Export/Save As PDF）：Officeがファイル変換としてPDFを生成する経路
印刷してPDF（Print to PDF）：プリンタードライバ経由の出力（PDFプリンター）

たとえばOutlookでは、必須ラベル付けが有効な場合、印刷してPDFがブロックされる事象が案内されています。理由として「印刷コマンドで作成されるファイルは感度ラベルやメタデータを失う可能性がある」という旨のメッセージが示され、PDF化が制限されるケースがあります。

一方、Word/Excel/PowerPointは“印刷”ではなく“エクスポート”でPDF化することが多く、ここで今回のようなラベル強制の抜けが目立ちます。つまり「PDF作成の入口が複数ある」こと自体が、対策を難しくしています。

漏えいリスクが上がる典型パターン

「PDF保存で強制が出ない」ことが、実際に事故につながりやすいのは次のような状況です。

新規作成→機密情報を貼り付け→そのままPDF保存（元ファイルを保存しない）
未ラベルPDFをローカルに作成→メール添付で送信（送信時DLPが弱い/未設定）
未ラベルPDFをチャットや外部ストレージへアップロード（持ち出し経路の監視がない）
「PDFは最終成果物だから」とレビューを飛ばして共有（運用がPDF前提）

つまり、真に怖いのは「PDFが作れること」ではなく、未ラベル（＝組織の保護前提が崩れた状態）のまま外部に出ることです。ここを止める設計が必要です。

対策の基本方針：保存時の強制に頼り切らず“持ち出し経路”で塞ぐ

「PDF保存の瞬間に必ずラベル強制を出す」だけで解決しようとすると、仕様・実装・端末差・アプリ差に振り回されがちです。実務的には、次の3層で考えると破綻しにくくなります。

防御層	狙い	代表的な手段
作成時（Word/Excel/PowerPoint）	できるだけ早くラベルを付ける	ネイティブ保存を先に行う、既定ラベル、（可能なら）アプリ自動ラベル
保管時（SharePoint/OneDrive）	置き場で是正・自動化する	自動ラベル（Auto-labeling）、ライブラリ既定ラベル
持ち出し時（共有・送信・印刷・アップロード）	未ラベル／不適切ラベルの外部流出を止める	DLP（クラウド）、Endpoint DLP（端末）、監査・アラート

すぐ効く運用：先にネイティブ形式で保存してラベル強制を“確実に踏む”

最も即効性が高いのは、手順を変えることです。

Wordで文書を作成したら、まず「名前を付けて保存（.docx）」を行う
保存時にラベルが必須なら、ここで必ずラベルを選択・適用する
その後に「PDFとして保存／エクスポート」でPDF化する

これだけでも「未ラベルのままPDF化」が大きく減ります。さらに、後述する既定ラベルを併用すると、ユーザー負担を抑えつつ“すり抜け”を狭められます。

抜け道を狭める設定：既定ラベルで「新規作成＝最初からラベル付き」にする

今回の穴は「ラベルが付いていない状態のままPDFにできる」ことが核心なので、逆に最初からラベルが付いた状態で作業を始めさせるのが効果的です。それが既定（デフォルト）ラベルです。

ラベルポリシー側で、ラベル未設定のドキュメントに既定ラベルを適用できます。また、必須ラベル付けだけを強くすると、ダイアログが頻繁に出てユーザー体験が悪化しやすいため、Microsoft側でも既定ラベルと必須ラベル付けを組み合わせる考え方が示されています。

既定ラベル：最低限の分類（例：General / 社内向け）を自動適用して“無ラベル”を消す
必須ラベル付け：より厳しい分類が必要な場合に、適切なラベルへ引き上げさせる

注意点として、既定ラベルにいきなり強い暗号化を持つラベルを置くと、外部共有や業務フローが詰まりやすいので、まずはベースラインとしての分類を置き、必要に応じて上げる運用の方が安全です。

Microsoft Purviewの自動ラベルを併用する（クラウド保管を前提に効く）

保存時の強制を“完全に”直せない以上、クラウドに置かれた後に自動で是正する仕組みを持っておくと、事故確率が下がります。Microsoft Purviewでは、条件（機密情報タイプ等）に応じて自動でラベルを適用する方法が用意されています。

自動ラベルには大きく2系統ある

Officeアプリ側（クライアント側）での自動／推奨ラベル：Word等で編集している最中に、条件に応じてラベル適用や推奨を行う
SharePoint/OneDrive/Exchange（サービス側）での自動ラベル：クラウド上のファイルをスキャンして条件に一致したらラベル適用

ただし、構成によっては必須ラベル付けと自動ラベルが同時にあるとタイミング問題が起きる旨の注意もあり、設計時には検証が重要です（“必須ラベル付けがあるから自動ラベルはいらない”ではなく、“必須ラベル付けの穴を自動ラベルで埋める”発想で組み合わせを調整します）。

SharePoint / OneDrive向け自動ラベルの進め方（例）

Microsoft Purviewポータルで自動ラベル（Auto-labeling）を作成
対象の場所（SharePointサイト、OneDriveアカウント等）を指定
条件（例：クレジットカード番号、個人番号、顧客情報などの機密情報タイプ）を指定
適用する感度ラベルを指定
可能ならシミュレーションで誤検知を確認してから本番適用

手段	得意なこと	弱いところ	おすすめ用途
既定ラベル	無ラベルをほぼ消せる	内容に応じた精密分類はできない	ベースラインの分類（社内向け等）
Office自動／推奨ラベル	作成中に気付かせられる	端末・アプリ条件、タイミングの影響がある	“その場で教育”したい部門
SharePoint/OneDrive自動ラベル	置き場で是正しやすい	クラウドに置く前の流出は止められない	保管・共有の標準がクラウドの組織

DLPで「未ラベルPDFが外へ出ない」状態を作る

抜け道対策の本命は、外に出る瞬間（共有・送信・アップロード・印刷・コピー）で止めることです。PurviewのDLPは、ラベル有無や内容検出に基づいてブロック／監査できます。

クラウドDLPで塞ぐ（SharePoint/OneDrive/Exchange）

SharePoint/OneDrive：外部共有、特定ドメイン共有、ゲスト共有などで未ラベル／不適切ラベルをブロック・監査
Exchange（メール）：添付ファイルが未ラベル、または機密情報検出でラベル不足の場合に送信ブロック／警告

ここを強くすると「作れてしまった未ラベルPDF」が組織外へ出にくくなります。

Endpoint DLPで塞ぐ（端末上の“作成・持ち出し”を直接制御）

Endpoint DLPを使うと、端末でのユーザー行為（アプリごとの操作）に対して、より直接的に制御をかけられます。特に今回のように「ローカルでPDFを作ってしまう」リスクがある場合、端末側の制御が効きます。

印刷（PDF出力を含む）をブロック／監査
ブラウザへのアップロード、クラウドへの持ち出しを制御
USBコピー、ネットワーク共有へのコピーを制御
Office/PDF/CSVなどのファイル操作を監査対象にする

ポータル上のEndpoint DLP設定では、印刷や各種制限アクション、Office/PDFファイルの監査など、DLP全体の動作を統一的に管理できる旨が示されています。組織として「未ラベルのファイルは印刷（PDF化含む）不可」「外部アップロード不可」のように、出口側のルールを設けやすくなります。

PDF側の現実解：AcrobatのMPIP連携でPDFにも“必須ラベル”を適用する

「PDFに対しても、保存時にラベル必須を出したい」という要求が強い場合、Officeだけで完結させるのではなく、PDFを扱うアプリ側で強制する発想もあります。

Adobe Acrobatは、Microsoft Purview Information Protection（MPIP）と連携し、PDFに対してラベルの表示・適用・編集、さらには既定／必須ラベル付けをサポートする旨が案内されています。具体的には、必須ラベル付けが有効な環境で、ラベルなしで保存しようとするとラベル選択を求め、キャンセルすれば保存できない、といった動作が説明されています。

このアプローチは「Wordから出るPDFを完全に止める」ものではありませんが、PDFを正しいラベル状態に戻す（あるいはラベルなしPDFの取り回しを難しくする）施策として有効です。

トラブルシュート：PDFにラベルが付かない／期待通りに継承されないときの確認ポイント

Officeのエディションとファイル形式を確認する

感度ラベルは、サブスクリプション版のOfficeでのサポートが前提になりやすく、またOfficeアプリの組み込みラベリングは、主にOpen XML形式（.docx等）をサポートし、古い形式（.doc等）や他形式は制約が出ることがあります。まずはファイル形式が対象か確認します。

「PDF化の方式」と「事前にラベルが付いているか」を確認する

Word/Excel/PowerPointにはPDF変換の複数の入口（保存/エクスポート/共有）があり、PDFが作成される際にラベルが継承されるケースがある一方、未ラベル状態からのPDF保存では強制が効かないケースが報告されています。運用上は、先にラベルを付けてからPDF化する手順が前提になります。

ラベルポリシーの反映遅延・ポリシー順序を疑う

ラベルポリシーはユーザー/グループ単位で公開され、反映に時間がかかることがあります。また複数ポリシーを割り当てている場合は、ポリシーの順序（優先度）で設定が上書きされることがあります。「設定したはずの既定ラベルが付かない」「必須が効かない」場合、順序と反映状況を点検します。

自動ラベルと必須ラベルの“タイミング”問題を想定する

自動ラベル（Officeアプリ側）を併用している場合、必須ラベル付けと同時利用で期待通りに動かない可能性が示されています。設計時は、必須の強制を上げる前に、シナリオ（新規作成、貼り付け、PDF化、共有）をテストし、どの時点で何が効くかを可視化すると事故を減らせます。

おすすめ構成：現場で破綻しにくい“落としどころ”

「PDF保存の瞬間に必ずプロンプト」を100%実現するよりも、無ラベルで外に出ないことをKPIにした方が運用は安定します。多くの組織で採りやすい構成例をまとめます。

レベル	狙い	推奨セット	向いている組織
最小構成	とにかく穴を小さくする	先にネイティブ保存→ラベル→PDF化（運用徹底）	短期で改善したい、まず現場に浸透させたい
標準構成	無ラベルを減らし、共有で止める	既定ラベル＋必須ラベル付け＋クラウドDLP（共有/送信）	Microsoft 365上での共有が中心
強固構成	端末からの持ち出しを抑止	標準構成＋Endpoint DLP（印刷/アップロード/コピー制御）＋監査/アラート	個人情報・設計図・法務資料など高リスク部門を抱える
PDF運用重視	PDFにもラベル必須を寄せる	強固構成＋Acrobat MPIP連携（PDF保存時の必須ラベル）	成果物がPDF中心、外部提出が多い

まとめ

Wordで「PDFとして保存」したときに感度ラベルの強制／プロンプトが出ない問題は、単なる手順ミスではなく、PDF保存がラベル強制の仕組みを迂回し得る既知の制限として整理できます。

だからこそ、対策は「PDF保存時に必ずプロンプト」を追いかけるより、次の組み合わせが現実的です。

まずネイティブ保存でラベル適用（手順の標準化）
既定ラベルで無ラベルを消し、必須ラベル付けのストレスを減らす
Purviewの自動ラベルでクラウド保管後に是正する
DLP/Endpoint DLPで未ラベルのまま外へ出ないよう出口を塞ぐ

この“多層”で設計すると、PDF保存が一部すり抜けても、漏えいに直結しない状態を作れます。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。