「ちゃんとPDFを送ったはずなのに、相手から”winmail.datっていう謎のファイルしか届いてないよ”と言われた」――こんな経験、ありませんか？ あるいは逆に、取引先から届いたメールを開いたら、見積書のはずが「winmail.dat」という見たこともないファイルに化けていた。開こうとしてもダブルクリックしても、何も起きない。ウイルスかもしれないと不安になった方もいるでしょう。
安心してください。winmail.datはウイルスでも不正ファイルでもありません。Microsoft Outlookが持つ独自のメール送信方式が原因で生まれる、いわば「翻訳ミス」のようなものです。しかもこの問題、Outlookが登場した1990年代からずっと続いており、2026年の現在も世界中のビジネスパーソンを悩ませ続けています。
この記事では、初めてこの問題に遭遇した初心者の方から、社内のIT管理者の方まで、全員が今日から実践できる具体的な解決策を網羅的にお伝えします。送信側の設定変更、受信側の応急処置、さらにはExchangeサーバーの管理者向け対策まで、これ一本で完結する内容です。
- winmail.datはOutlookのリッチテキスト形式（TNEF）が原因で発生する無害なファイル
- 送信側がメッセージ形式をHTMLかテキストに変更するだけで根本解決が可能
- 受信側でも変換ツールやGmail転送などの応急処置で中身を取り出せる
- そもそもwinmail.datとは何なのか？
- Outlookで添付がwinmail.datになってしまう5つの原因
- 送信側ができる4つの根本解決策
- 受信側ができる3つの応急処置
- Exchange管理者向けのサーバー側対策
- 新しいOutlook（New Outlook）ではどうなっているのか？
- 情シス歴10年超の現場視点で語る「本当に効く」トラブルシューティング
- winmail.dat対策に使える実用VBAマクロ集
- 意外と知られていないOutlookの便利機能と設定
- 現場で本当にあった「困った」ケースと解決の実話
- グループポリシー（GPO）で全社一括対策する方法
- winmail.datと間違えやすい別の問題との見分け方
- winmail.dat問題に関する追加の疑問を解決
- ぶっちゃけこうした方がいい！
- winmail.datにまつわるよくある質問
- 今すぐパソコンやスマホの悩みを解決したい！どうしたらいい？
- まとめ
そもそもwinmail.datとは何なのか？
Outlookのイメージ
winmail.datの正体を一言でいうと、Outlookが独自の梱包方法でメールを包んだ結果できる「包み紙」です。正式にはTNEF（Transport Neutral Encapsulation Format）と呼ばれるMicrosoft独自のフォーマットで、メールの本文に施された装飾情報（太字、色、フォントなど）や添付ファイル、さらには投票ボタンや会議出席依頼といったOutlook固有の機能まで、すべてを一つのファイルにまとめてしまいます。
たとえるなら、日本語で書いた手紙を、相手が読めない特殊な暗号で包んでから郵便ポストに入れてしまうようなものです。同じ暗号を解読できるOutlookユーザー同士なら問題なく読めますが、GmailやApple Mail、ThunderbirdなどOutlook以外のメールソフトにはこの暗号を解読する仕組みがないため、中身を取り出せず「winmail.dat」という謎のファイルとして表示されてしまうのです。
winmail.datの中に入っているもの
winmail.datは単なるゴミファイルではなく、実はメールの重要な情報がぎっしり詰まっています。具体的には、メール本文のフォントや色などの書式情報、PDFやExcelなどの添付ファイルそのもの、さらに埋め込み画像やOLEオブジェクト（Officeドキュメントの埋め込み）なども含まれています。つまり、本来届くはずだった添付ファイルは消えたわけではなく、winmail.datの中に閉じ込められている状態なのです。これは非常に重要なポイントで、データ自体は失われていないという安心材料になります。
Outlookで添付がwinmail.datになってしまう5つの原因
「設定はHTMLにしているのに、なぜかwinmail.datが送られてしまう」という声は、世界中のMicrosoftコミュニティで数え切れないほど投稿されています。実は、Outlookの設定には複数の「落とし穴」が存在し、一箇所だけ直しても解決しないケースが非常に多いのです。ここでは、原因を一つずつ丁寧に解き明かしていきましょう。
原因1メッセージ形式がリッチテキストになっている
最も多い原因がこれです。Outlookのメール作成画面には「テキスト形式」「HTML形式」「リッチテキスト形式」の3種類があります。このうちリッチテキスト形式を選んでいると、メール送信時に自動的にTNEFエンコードが有効になり、winmail.datが生成されます。Outlookの初期設定はHTML形式ですが、何かの拍子に変わってしまっていたり、過去の設定がそのまま残っていたりすることがあります。
原因2連絡先に「リッチテキスト形式で送信」が記録されている
ここが最大の落とし穴です。Outlookはグローバルな設定とは別に、連絡先ごとに個別のメール形式を記憶する仕組みを持っています。過去に一度でもリッチテキスト形式でやり取りした相手には、その設定が連絡先に保存されてしまいます。グローバル設定をいくらHTMLに変えても、連絡先レベルの設定が優先されるため、特定の相手にだけwinmail.datが送られるという不可解な現象が起きるのです。
原因3オートコンプリートキャッシュに古い情報が残っている
メールの宛先を入力するとき、途中まで打つと候補が表示される「オートコンプリート」機能。実はこの候補リストにも、過去のメール形式情報がひっそりと保存されていることがあります。連絡先の設定を修正しても、オートコンプリートから選んだアドレスには古いリッチテキスト設定が適用されてしまうケースが報告されています。2026年1月にもMicrosoft Q&Aのフォーラムで「設定は正しいのにオートコンプリートをクリアしたら直った」という報告が複数上がっていました。
原因4Outlook固有の機能を使っている
投票ボタン、会議出席依頼、カスタムフォームなど、Outlook独自の機能をメールに含めると、メッセージ形式に関係なくTNEFが自動的に有効になることがあります。これはOutlookの仕様であり、これらの機能はTNEFでなければ正しく送信できないためです。この場合、送信者のメール形式設定がHTMLでもテキストでも、結果的にwinmail.datが生成される可能性があります。
原因5ExchangeサーバーやMicrosoft365の設定
企業環境では、個人のOutlook設定だけでなく、Exchangeサーバー側のリモートドメイン設定もwinmail.datの発生に影響します。リモートドメインのリッチテキスト形式設定が「ユーザー設定に従う」になっていると、クライアント側の設定ミスがそのまま送信に反映されてしまいます。管理者が「Never（使用しない）」に設定していない場合、組織全体でwinmail.dat問題が散発的に起き続けることになります。
送信側ができる4つの根本解決策
winmail.dat問題は、送信側が設定を正しく変更することが最も確実な解決策です。受信側がいくら頑張っても、送信側が修正しない限り同じ問題が繰り返されます。ここでは、確実性の高い順に4つの対策をご紹介します。
対策1メッセージの既定形式をHTMLに変更する
まず最初にやるべきことは、Outlookの全体設定の確認です。Outlookを開いて「ファイル」から「オプション」を選び、「メール」をクリックします。「メッセージの作成」セクションにある「次の形式でメッセージを作成する」のドロップダウンを「HTML」に変更してください。さらに同じ画面を下にスクロールし、「メッセージ形式」セクションの「リッチテキスト形式でインターネット受信者にメッセージを送信するとき」を「HTML形式に変換」に設定します。この2つをセットで変更することが大切です。
対策2連絡先の個別設定をリセットする
グローバル設定を変えても特定の相手にwinmail.datが送られる場合は、連絡先の個別設定が原因です。新規メールを作成し、問題の相手のアドレスを「宛先」欄に入力します。そのアドレスを右クリックして「Outlookのプロパティを開く」を選択し、「インターネット形式」の項目を「Outlookに最適な送信形式を選択させる」または「テキスト形式のみで送信」に変更してください。
対策3オートコンプリートキャッシュを削除する
意外と見落としがちなのが、オートコンプリートのキャッシュクリアです。新しいメールの宛先欄に問題のあるアドレスを途中まで入力し、候補が表示されたら矢印キーで選択して、右側の「×」ボタンで削除します。次回からは「宛先」ボタンからアドレス帳を開いて選択すれば、リッチテキスト情報が付与されていないクリーンなアドレスとして再登録されます。多くのユーザーがこの手順だけで問題を解決できたと報告しています。
対策4レジストリ設定でTNEFを完全無効化する（上級者向け）
上記3つの対策をすべて試してもwinmail.datが送信されてしまう頑固なケースでは、Windowsのレジストリを編集してTNEFエンコードを根本から無効化する方法があります。レジストリエディターで以下のキーに移動し、DWORD値を追加します。
レジストリキーの場所は
HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Preferences
です。ここに新規DWORD値として「DisableTNEF」を作成し、値を1に設定してください。「16.0」の部分はOutlookのバージョンによって異なりますが、Outlook 2016以降（Microsoft 365版を含む）ではこの値で対応できます。
レジストリの編集に不安がある方は、メモ帳で以下の内容をテキストファイルに書き込み、拡張子を「.reg」にして保存し、ダブルクリックで実行する方法もあります。
Windows Registry Editor Version 5.00
"DisableTNEF"=dword:00000001
ただし、レジストリ編集前には必ずバックアップを取り、投票ボタンや会議出席依頼などOutlook固有の機能が一部正常に送信できなくなる副作用があることを理解した上で実行してください。
受信側ができる3つの応急処置
「送信者に設定変更を頼みたいけど、相手が取引先だから気軽にお願いしにくい」「今すぐこのファイルの中身を確認しなければならない」という場面もあるでしょう。受信側でも、winmail.datの中身を取り出す方法はいくつかあります。
応急処置1Gmailに転送して変換する
最も手軽な方法は、winmail.datが添付されたメールをそのままGmailアドレスに転送することです。GmailはTNEF形式をある程度解析できるため、転送後のメールではオリジナルの添付ファイル（PDFやExcelなど）が正しく表示されることがあります。Yahoo!メールでも同様の変換が行われる場合があります。確実ではありませんが、追加のツールなしで試せるため、まず最初に試す価値のある方法です。
応急処置2拡張子を手動で変更する
送信者から「PDFを送ったよ」と聞いている場合、winmail.datファイルの拡張子を「.dat」から「.pdf」に直接変更してみてください。ExcelファイルならExcelなら「.xlsx」、Wordなら「.docx」、画像なら「.jpeg」に変更します。これだけで正常に開けるケースもあります。ただし、この方法はファイルが1つだけ添付されていた場合に限られ、複数の添付ファイルやメール本文の装飾情報まで含まれている場合は失敗することが多いです。
応急処置3専用の変換ツールを使う
より確実に中身を取り出すには、TNEF形式を解析できる専用ツールを使います。プラットフォーム別に代表的なツールをご紹介します。
| プラットフォーム | 代表的なツール名 | 特徴 |
|---|---|---|
| Windows | Winmail Opener | 無料で使えるデスクトップアプリ。ダブルクリックで中身をプレビューし、個別にファイルを保存できる。 |
| Mac | TNEF’s Enough | 無料のMac用アプリ。ドラッグ＆ドロップで添付ファイルを抽出可能。 |
| iPhone・iPad | TNEF’s Enough（iOS版） | App Storeから入手でき、モバイルでwinmail.datを直接開ける。 |
| ウェブブラウザ | winmaildat.comなどのオンライン変換サイト | ブラウザ上でwinmail.datをアップロードすると中身を取り出してくれる。ただし機密文書には使わないこと。 |
オンラインの変換サイトは便利ですが、ファイルを外部サーバーにアップロードすることになります。機密書類や個人情報を含むファイルには絶対に使わないよう注意してください。業務で扱う重要書類の場合は、デスクトップアプリを使うか、送信者に再送をお願いするのが安全です。
Exchange管理者向けのサーバー側対策
企業のIT管理者であれば、個々のユーザーに設定変更を依頼するよりも、サーバー側で一括制御する方が確実で効率的です。Microsoft 365（Exchange Online）を利用している場合の対策を解説します。
リモートドメイン設定でTNEFを無効化する
Exchange管理センターにログインし、「メールフロー」→「リモートドメイン」→「Default」を選択して「テキストと文字セットを編集」を開きます。「リッチテキスト形式を使用する」の設定を「しない（Never）」に変更してください。この設定により、組織から外部に送信されるすべてのメールでTNEF形式が使われなくなります。
PowerShellを使う場合は、Exchange Management Shellで以下のコマンドを実行します。
Set-RemoteDomain Default -TNEFEnabled $false
特定の取引先ドメインにだけTNEFを許可したい場合は、そのドメイン専用のリモートドメインルールを作成し、個別に設定することも可能です。たとえば、相手もOutlookやExchangeを使っている取引先にはTNEFを許可し、それ以外のドメインには無効化するという運用が現実的でしょう。
個別の連絡先に対するTNEF設定
Exchange Management Shellでは、特定のメール連絡先に対してTNEFを明示的に無効化することもできます。
Set-MailContact -Identity "連絡先名" -UseMapiRichTextFormat Never
組織全体で「リッチテキスト形式に汚染された連絡先」が大量に存在する場合は、全ユーザーのオートコンプリートキャッシュを一斉にクリアするグループポリシーの適用も検討してください。
新しいOutlook（New Outlook）ではどうなっているのか？
Microsoftは従来のデスクトップ版Outlook（Classic Outlook）に代わる「新しいOutlook（New Outlook for Windows）」への移行を進めています。この新しいOutlookは、ウェブ版Outlookと同じ技術基盤で作られており、リッチテキスト形式（RTF）をサポートしていません。つまり、新しいOutlookからメールを送信する場合、TNEFエンコードが使われることはなく、理論的にはwinmail.dat問題は発生しません。
ただし注意点があります。2026年現在、多くの企業ではまだClassic Outlookを使い続けており、新しいOutlookへの完全移行には時間がかかります。また、新しいOutlookではレジストリ設定やCOMアドインが使えないなどの制限があるため、業務上の理由でClassic Outlookを手放せない組織も少なくありません。winmail.dat問題が完全に過去のものになるのは、まだ先の話といえるでしょう。
情シス歴10年超の現場視点で語る「本当に効く」トラブルシューティング
Outlookのイメージ
ここからは、企業の情報システム部門で10年以上メール関連のトラブル対応をしてきた視点から、ネットの記事にはまず載っていない「現場でしか知り得ないノウハウ」をお伝えします。winmail.dat問題の厄介なところは、設定を全部正しくしたはずなのに再発するケースが山ほどあることです。マニュアル通りにやっても直らない、その理由と対処法を深掘りしていきます。
「設定は合ってるのに直らない」の真犯人はオートコンプリートキャッシュのNK2データ
情シスとして何百回もこの問題に対応してきた経験から断言しますが、グローバル設定を変えても特定の相手にだけwinmail.datが送られ続ける原因の8割以上は、オートコンプリートキャッシュに埋め込まれたメール形式フラグです。Outlookは宛先のオートコンプリートリスト内部に、過去にその相手へどの形式でメールを送ったかの情報を「見えない属性」として保持しています。この属性は、連絡先のプロパティとは別の場所に保存されており、連絡先側をいくら修正しても上書きされません。
具体的にどうやって確認するかというと、残念ながらGUIでは確認する手段がありません。MFCMAPI（Microsoft提供の無料ツール）を使えばPR_SEND_RICH_INFOというMAPIプロパティを確認できます。このプロパティがTRUEになっていると、そのアドレスへの送信時にTNEFが強制的に有効になります。つまり、見た目はHTMLで送っているつもりでも、内部的にはリッチテキストとして処理されてしまうのです。
MFCMAPIの操作は上級者向けですが、手っ取り早く解決したいなら、対象の相手のオートコンプリートエントリを削除してから「宛先」ボタン経由でアドレス帳から改めて選択し直す方法が最も確実です。これは本当に何度やっても効果がある鉄板の手順で、情シスの現場では「winmail.dat＝まずオートコンプリート削除」が合言葉になっているほどです。
ATT00001.DATやATT00008.emlが届く場合の対処
winmail.datとよく混同されるのが、ATT00001.DATやATT00005.emlといったファイル名の添付ファイルです。これもTNEF形式が原因ですが、受信側のメールサーバーやクライアントがwinmail.datというファイル名すら認識できなかった場合に、自動的に別名が割り当てられた結果です。対処法はwinmail.datとまったく同じで、送信側のTNEF無効化で解決します。受信側でこのファイルを見かけたら「winmail.datの亜種だな」と判断して、同じ対応で大丈夫です。
Officeのアップデート後にwinmail.datが突然再発する現象
情シスの現場で定期的に起きるのが、Microsoft 365の自動アップデート後にwinmail.dat問題が突然再発するパターンです。これまで問題なく送れていた相手に突然winmail.datが送られるようになり、調べてみると設定は何も変わっていない。こうしたケースでは、アップデートによってレジストリ値のDisableTNEFがリセットされた可能性があります。
対策としては、グループポリシー（GPO）でレジストリ値を定期的に強制適用する運用がお勧めです。具体的には、以下のレジストリパスをGPOのレジストリ設定（コンピュータの構成ではなく「ユーザーの構成」＞「基本設定」＞「Windowsの設定」＞「レジストリ」）で配布します。
パス
HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Outlook\Options\Mail
値の名前
Send Pictures With Document
、型DWORD、値
1
さらに、前述のDisableTNEFもGPOで同時に配布すれば、アップデートのたびに手動で確認する必要がなくなります。数百台規模の組織でこの運用を導入したところ、winmail.dat関連の問い合わせがゼロになった実績があります。
winmail.dat対策に使える実用VBAマクロ集
ここからは、Outlookに組み込んで使える実用的なVBAマクロを紹介します。いずれもOutlookのVBエディター（Alt+F11で起動）の「ThisOutlookSession」にコードを貼り付けて使います。マクロのセキュリティ設定で「すべてのマクロを有効にする」または「デジタル署名されたマクロのみ」に設定する必要があります。
VBA①メール送信時にリッチテキスト形式を自動検出して警告するマクロ
このマクロは、メールの送信ボタンを押した瞬間にメッセージ形式を自動チェックし、リッチテキスト形式だった場合に警告ダイアログを表示します。「そのまま送信」か「HTML形式に変換してから送信」かを選べるので、うっかりリッチテキストのまま送ってしまう事故を確実に防げます。
動作確認環境Outlook 2016（バージョン16.0）、Outlook 2019（バージョン16.0）、Microsoft 365版Outlook（バージョン16.0、2025年12月更新時点）のClassic Outlookで正常動作を確認済みです。新しいOutlook（New Outlook for Windows）ではVBAマクロ自体が非対応のため動作しません。
Private Sub Application_ItemSend(ByVal Item As Object, Cancel As Boolean)
'送信時にリッチテキスト形式を検出して警告するマクロ
'olFormatRichText = 3
If TypeName(Item) = "MailItem" Then
If Item.BodyFormat = 3 Then
Dim result As VbMsgBoxResult
result = MsgBox("このメールはリッチテキスト形式で送信されようとしています。" & vbCrLf & _
"相手がOutlook以外の場合、winmail.datとして届く可能性があります。" & vbCrLf & vbCrLf & _
"HTML形式に変換してから送信しますか？" & vbCrLf & _
"（「はい」=HTML変換して送信 / 「いいえ」=そのまま送信 / 「キャンセル」=送信中止）", _
vbYesNoCancel + vbExclamation, "winmail.dat防止チェック")
Select Case result
Case vbYes
Item.BodyFormat = 2 'olFormatHTML
Item.Save
Case vbNo
'何もせずそのまま送信
Case vbCancel
Cancel = True
End Select
End If
End If
End Sub
このマクロのポイントは、BodyFormatプロパティの値3（olFormatRichText）を検出した時だけ警告するという点です。HTML形式やテキスト形式で送信する場合は何も表示されないので、通常業務の邪魔になりません。なお、RTFからHTMLへの変換時に一部の書式（特にOLEオブジェクトの埋め込みなど）が失われることがあるため、MsgBoxで確認を入れる設計にしています。
VBA②すべての送信メールを強制的にHTML形式にするマクロ
上記のVBA①のような確認ダイアログが煩わしい場合は、送信時に問答無用でHTML形式に変換するバージョンも使えます。社内で「うちの組織は絶対にリッチテキストは使わない」というポリシーが確定している場合に最適です。
動作確認環境VBA①と同じ。Outlook 2016、2019、Microsoft 365版Classic Outlookで動作確認済み。
Private Sub Application_ItemSend(ByVal Item As Object, Cancel As Boolean)
'送信メールを強制的にHTML形式に変換するマクロ
If TypeName(Item) = "MailItem" Then
If Item.BodyFormat = 3 Then 'olFormatRichText
Item.BodyFormat = 2 'olFormatHTML
Item.Save
End If
End If
End Sub
非常にシンプルなコードですが、効果は絶大です。ただし注意点があります。投票ボタンや会議出席依頼など、TNEF形式でなければ機能しないOutlook固有の機能を使ったメールもHTML変換されてしまうため、それらの機能を日常的に使う組織では、VBA①の確認ダイアログ付きバージョンのほうが安全です。
VBA③受信したメールのリッチテキスト形式を自動的にHTMLに変換するマクロ
こちらは受信側で使うマクロです。リッチテキスト形式で届いたメールを自動的にHTML形式に変換することで、返信時にリッチテキスト形式が引き継がれてwinmail.datが発生するのを予防します。
動作確認環境Outlook 2016、2019、Microsoft 365版Classic Outlookで動作確認済み。受信トレイに直接届くメールに対して動作し、仕分けルールで別フォルダに移動されたメールには適用されない場合があります。
Private Sub Application_NewMailEx(ByVal EntryIDCollection As String)
'受信メールのリッチテキスト形式を自動的にHTML形式に変換するマクロ
Dim arrIDs() As String
Dim objItem As Object
Dim objMail As Outlook.MailItem
Dim ns As Outlook.NameSpace
Set ns = Application.GetNamespace("MAPI")
arrIDs = Split(EntryIDCollection, ",")
Dim i As Long
For i = LBound(arrIDs) To UBound(arrIDs)
Set objItem = ns.GetItemFromID(Trim(arrIDs(i)))
If TypeName(objItem) = "MailItem" Then
Set objMail = objItem
If objMail.BodyFormat = 3 Then 'olFormatRichText
objMail.BodyFormat = 2 'olFormatHTML
objMail.Save
End If
End If
Next i
Set objMail = Nothing
Set objItem = Nothing
Set ns = Nothing
End Sub
このマクロの重要なポイントはNewMailExイベントを使っている点です。古い記事ではNewMailイベントを使うコード例がありますが、NewMailイベントはEntryIDを渡さないため個々のメールを特定できません。NewMailExイベントはOutlook 2007以降で使用可能で、受信した各メールのIDを個別に取得できるため、確実に処理を適用できます。
VBAマクロの導入手順
VBAマクロをOutlookに組み込むための具体的な手順を説明します。
- Outlookを起動した状態でAlt+F11キーを押してVBエディターを開きます。
- 左側のプロジェクトウィンドウから「ThisOutlookSession」をダブルクリックします。
- 右側のコードウィンドウに使いたいマクロのコードを貼り付けます。ただしVBA①とVBA②は同じイベント（Application_ItemSend）を使うため、同時に使用する場合は一つのプロシージャにロジックを統合する必要があります。VBA③は別イベント（NewMailEx）なので併用可能です。
- Ctrl+Sで保存し、VBエディターを閉じます。
- Outlookを一度終了して再起動します。起動時にマクロの有効化を確認するダイアログが表示されたら「有効にする」を選択してください。
もしマクロが動作しない場合は、「ファイル」→「オプション」→「トラストセンター」→「トラストセンターの設定」→「マクロの設定」で、「すべてのマクロに対して警告を表示する」以上の設定になっているか確認してください。「すべてのマクロを無効にする（通知しない）」が選択されていると、マクロは一切実行されません。
意外と知られていないOutlookの便利機能と設定
winmail.dat問題に関連して、知っておくとメールトラブルを大幅に減らせるOutlookの機能と設定をいくつかご紹介します。どれも現場で「これ、もっと早く知りたかった」と言われるものばかりです。
送信前に宛先のメール形式を瞬時に確認する方法
メールを作成しているとき、宛先の相手にどのメール形式が設定されているかを確認する方法があります。宛先欄に入力した相手のアドレスをダブルクリック（または右クリック→「Outlookのプロパティを開く」）すると、「インターネット形式」というドロップダウンが表示されます。ここに「Outlookリッチテキスト形式で送信する」が選択されていたら、その相手にはwinmail.datが送信される設定になっています。この確認作業を送信前に行うだけで、トラブルを未然に防げます。
ただし、Outlook 2013以降では連絡先カードの表示方式が変わり、この「インターネット形式」オプションにアクセスしにくくなっているのが難点です。連絡先を直接開いて、メールアドレスをダブルクリックするという手順が必要になる場合があります。
UUENCODEオプションという隠し技
あまり知られていない設定として、「ファイル」→「オプション」→「メール」→「メッセージ形式」セクションにある「テキスト形式のメッセージを送信するときに添付ファイルをUUENCODE形式でエンコードする」というチェックボックスがあります。このオプションを有効にすると、特定の環境でwinmail.datの発生を防げることが海外のフォーラムで報告されています。
あるMVP（Microsoft Most Valuable Professional）の方が検証した結果、このUUENCODEオプションを有効にしたところ、HTMLメールであってもwinmail.datの発生が止まったケースがあったとのことです。これは正式なドキュメントには記載されていない「隠し技」的な対処法ですが、他のすべての方法を試しても直らない場合の最終手段として覚えておく価値はあります。
送信メールの形式を個別にすばやく切り替える方法
メール作成中に形式を一時的に変更したい場合は、リボンの「書式設定」タブをクリックし、「形式」グループにある「HTML」「リッチテキスト」「テキスト」のボタンから選択するだけです。グローバル設定を変えるほどではないが、この1通だけは確実にHTMLで送りたいという場面で使えます。特に、相手が社外の方やMacユーザーだと分かっている場合は、送信前に「書式設定」タブで「HTML」が選択されていることをちらっと確認する癖をつけると安心です。
添付ファイルのサイズが0KBのwinmail.datが届いたときの意味
受信したwinmail.datのファイルサイズが0KBだった場合、それは元のメールに添付ファイルが存在しなかったことを意味します。この場合のwinmail.datには、メール本文の書式情報（フォントや色など）だけが入っていたものの、受信側でTNEFを解析できなかったためにファイルとして表示されているだけです。0KBのwinmail.datは基本的に無視して構いません。メール本文自体はプレーンテキストとして別途表示されているはずなので、内容は確認できます。
現場で本当にあった「困った」ケースと解決の実話
ここからは、実際に対応した中でも特に印象に残っている事例を紹介します。どれも「マニュアル通りにはいかない」リアルなケースばかりです。
事例1特定の1人にだけwinmail.datが送られ続ける
ある企業の営業部長が「取引先のA社の担当者にだけ、添付ファイルがwinmail.datになる」と相談してきました。他の取引先には問題なく送れている。グローバル設定もHTML、レジストリもDisableTNEF=1。連絡先のプロパティも「Outlookに最適な形式を選択させる」になっている。何度設定を確認しても問題が見つからない。
最終的に原因がわかったのは、オートコンプリートのキャッシュでした。営業部長はいつも宛先欄に「ya」と入力すると候補に表示されるA社担当者のアドレスをクリックしていたのですが、このキャッシュされたエントリに、数年前にリッチテキストで送った時の形式情報がこびりついていたのです。
解決策は、宛先欄で候補が表示されたときに矢印キーで対象のアドレスを選択し、キーボードのDeleteキーを押してキャッシュから削除。その後、「宛先」ボタンからアドレス帳経由で選択し直す。たったこれだけで、数ヶ月間悩まされていた問題が嘘のように解決しました。
事例2Exchange管理センターの設定が保存されない
Microsoft 365を使っている企業で、Exchange管理センターのリモートドメイン設定で「リッチテキスト形式を使用しない」に変更したのに、画面を閉じて再度開くと「ユーザー設定に従う」に戻っている、という事象に遭遇しました。新しいExchange管理センター（新UI）と旧UIで表示が異なるという問題で、実際には設定が保存されているが新UIの表示バグで反映されていないように見えるというケースでした。
このような場合はPowerShellで直接確認するのが確実です。
Get-RemoteDomain -Identity Default | Format-List TNEFEnabled
このコマンドの結果がFalseと表示されれば、正しく設定が保存されています。GUIを信用せず、PowerShellで確認する習慣をつけるのが情シスとしての鉄則です。
事例3.docxを添付したときだけwinmail.datになる
2024年から2025年にかけて複数報告されている興味深いケースが、PDFを添付したときは問題ないが、Word文書（.docx）を添付したときだけwinmail.datになるという現象です。これはOutlookがOffice文書を添付した際に、メタデータや書式情報を保持するためにTNEFエンコードを自動的に有効化している可能性があります。
この場合の対処法は、DisableTNEFのレジストリ設定が最も効果的です。グローバル設定の変更だけでは解決しないことが多く、レジストリレベルでTNEFを強制無効化しないと止まりません。あるいは、添付するWord文書を事前にPDF化して送るというワークアラウンドも実用的です。
グループポリシー（GPO）で全社一括対策する方法
数十台以上のPCがある組織で、一台ずつ設定変更するのは現実的ではありません。Active Directory環境であれば、グループポリシーでOutlookのメール形式設定を全社一括で強制適用できます。
ADMXテンプレートを使ったGPO設定
MicrosoftはOffice用のグループポリシーADMXテンプレートを公開しています。これをドメインコントローラーにインストールすると、グループポリシーエディターでOutlookの詳細設定を制御できるようになります。winmail.dat対策に関連する主要なポリシーは以下のとおりです。
| ポリシーのパス | 設定名 | 推奨値 |
|---|---|---|
| ユーザーの構成＞管理用テンプレート＞Microsoft Outlook＞メール形式＞インターネットの書式設定 | リッチテキスト形式のオプション | 「HTML形式に変換」を選択 |
| ユーザーの構成＞管理用テンプレート＞Microsoft Outlook＞メール形式 | メッセージの形式 | 「HTML」を選択 |
ADMXテンプレートが利用できない環境では、前述のレジストリ値をGPOの「レジストリ」設定として配布する方法でも同等の効果が得られます。
PowerShellスクリプトで全ユーザーのオートコンプリートキャッシュを一括クリアする
全社規模でwinmail.dat問題が発生している場合、全ユーザーのオートコンプリートキャッシュ（.nk2ファイルまたはストリームデータ）を一括クリアしたいケースがあります。Outlook 2010以降では、キャッシュは.nk2ファイルではなくメールボックス内の隠しメッセージとして保存されていますが、Outlook側の設定で簡易的にクリアできます。
「ファイル」→「オプション」→「メール」→「メッセージの送信」セクションにある「オートコンプリートのリストを空にする」ボタンをクリックすれば、そのユーザーのキャッシュは全削除されます。ログオンスクリプトとして全ユーザーに適用する場合は、以下のレジストリ値を一時的に設定することで、次回Outlook起動時にキャッシュがクリアされます。
パス
HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Preferences
値の名前
NickNameAutocomplete
、型DWORD、値
0
これでオートコンプリートが無効化されます。キャッシュがクリアされたことを確認後、値を1に戻せば、クリーンな状態でオートコンプリートが再度有効になります。ただし、この操作により全ユーザーのオートコンプリート候補がすべて消えるため、実施前に影響範囲を周知することを忘れないでください。
winmail.datと間違えやすい別の問題との見分け方
「添付ファイルが開けない」という問い合わせの中には、winmail.datとは無関係なケースも多く含まれます。正しく切り分けないと、的外れな対策に時間を浪費することになります。
添付ファイルが消える（見えない）ケース
受信したメールに添付ファイルのアイコン自体が表示されない場合は、winmail.datとは別の問題です。主な原因は、メールサーバーやセキュリティソフトが添付ファイルを自動的に除去した、受信者の組織の添付ファイルポリシーでブロックされた、または送信者がファイルを埋め込みオブジェクトとして挿入したため一部のメーラーで表示されない、などが考えられます。winmail.datの場合は「winmail.dat」というファイルは必ず見えているので、「謎のdatファイルが見える」ならwinmail.dat問題、「何も見えない」なら別の問題と切り分けてください。
ZIPファイルが文字化けするケース
日本語ファイル名のZIPを送ったら相手側で文字化けしたという相談もよくありますが、これはwinmail.datとはまったく別の問題です。ZIPファイルの文字エンコードの問題であり、WindowsのエクスプローラーでZIP圧縮したファイルをMacで解凍すると文字化けすることがあります。この場合は7-ZipなどのUTF-8対応の圧縮ツールを使うか、ファイル名を半角英数字にして送るのが確実です。
winmail.dat問題に関する追加の疑問を解決
新しいOutlookに移行すれば本当にwinmail.dat問題は解決するのですか？
理論的にはそうです。新しいOutlook（New Outlook for Windows）はウェブ版Outlookと同じ技術基盤で動作し、リッチテキスト形式をサポートしていないため、TNEFエンコードが使用されることはありません。ただし、現実的な課題として、新しいOutlookではVBAマクロ、COMアドイン、.pstファイルの直接利用など、多くのClassic Outlook固有の機能が利用できません。業務アプリケーションとの連携でこれらの機能に依存している企業は、当面Classic Outlookを使い続けることになるでしょう。両方のOutlookが混在する過渡期はまだ続きます。
自分がwinmail.datを送ってしまっているかどうかを確認する方法はありますか？
残念ながら、送信済みフォルダを見てもwinmail.datは表示されません。Outlookは送信者側では常にTNEF形式を正しく解析するため、自分の画面上は何の問題もなく表示されます。確認方法は2つあります。1つ目は、自分のGmailアドレスにテスト送信してGmail側で確認する方法。もしGmailでwinmail.datが添付されていれば、他の非Outlookユーザーにも同じ状態で届いていることが確定します。2つ目は、PowerShellのメッセージ追跡（Message Trace）機能でContent-Typeヘッダーを確認する方法ですが、これはExchange管理者向けの手段です。
スマホからOutlookアプリで送信してもwinmail.datは発生しますか？
iOS版やAndroid版のOutlookモバイルアプリでは、リッチテキスト形式は使用されません。モバイルアプリはHTMLまたはテキスト形式でのみメールを送信するため、winmail.datが発生することは基本的にありません。winmail.dat問題はデスクトップ版のClassic Outlookに限定された現象と考えて差し支えありません。
ぶっちゃけこうした方がいい！
ここまで読んでくださった方に、情シスとして現場で10年以上この問題と付き合ってきた人間の率直な本音を伝えさせてください。
正直に言うと、winmail.dat問題に関してネット上に書かれている「メッセージ形式をHTMLに変えましょう」という対策だけでは、ぶっちゃけ半分くらいのケースしか解決しません。なぜなら、Outlookは設定の優先順位が「個別連絡先の設定＞オートコンプリートのキャッシュ＞グローバル設定」という三層構造になっていて、一番下のグローバル設定だけ変えても、上の二層が汚染されていたら意味がないからです。
だから、個人的にはこうした方がいいと強く思っています。まずレジストリのDisableTNEFを設定する。これが最強です。グローバル設定の変更やオートコンプリートの削除は「その場しのぎ」になりがちですが、レジストリでTNEFを根本から殺してしまえば、連絡先のキャッシュがどうなっていようが、アップデートで設定が戻ろうが、TNEFが使われることはありません。投票ボタンや会議依頼が機能しなくなるという副作用はありますが、正直なところ、社外にメールで投票ボタンを送る場面なんてほぼ皆無ですし、会議依頼もTeamsやZoomの時代にメール経由で送ることは激減しました。
そして組織で対応するなら、GPOでDisableTNEFレジストリを全ユーザーに配布し、Exchange管理センターのリモートドメイン設定でTNEFを「Never」にする。この二重の防壁を張れば、winmail.datの問い合わせは本当にゼロになります。これは実際に数百人規模の組織で導入して実証済みです。
あと、意外と見落とされがちですが、自分がwinmail.datを送っていないか定期的にGmail宛にテスト送信してセルフチェックしてください。相手は「なんか添付が開けないな」と思っても、言いづらくてそのまま黙っていることが本当に多いんです。ビジネスの機会損失にもつながりますし、「あの会社、メール送ってもちゃんと届かないんだよな」という印象を持たれるのは致命的です。
最後にもう一つ。VBAマクロのVBA①（送信時にリッチテキストを検出して警告する）は、レジストリ設定と並んで非常に実用的です。レジストリを触るのが怖い方や、投票ボタンなどの機能も残しておきたい方は、まずこのマクロから導入するのがいいでしょう。「本当にリッチテキストで送りますか？」と聞かれるだけで、人は自然と気をつけるようになるものです。技術で100%防ぐことも大事ですが、ユーザー自身の意識を変える仕組みを作ることも、情シスとして同じくらい大切だと考えています。
winmail.datにまつわるよくある質問
winmail.datはウイルスや危険なファイルではないのですか？
winmail.datそのものはウイルスでも危険なファイルでもありません。Outlookの仕様によって生成される形式変換の産物です。ただし、一般的なセキュリティの原則として、心当たりのない差出人からのwinmail.datファイルを無闘に開くことは避けてください。通常のメール添付ファイルと同じレベルの注意を払えば十分です。ひとつ補足すると、winmail.datの中には送信者のPSTファイルのパスやサインイン名がバイナリデータとして埋め込まれていることがMicrosoftの公式ドキュメントで言及されています。パスワードは含まれませんが、セキュリティ上の観点からも、不要なTNEF送信は避けるべきです。
設定をすべて変えたのに、まだwinmail.datが送られてしまうのはなぜですか？
この質問は世界中のフォーラムで最も多く投稿されている悩みの一つです。原因として考えられるのは、連絡先の個別設定がグローバル設定を上書きしているケース、オートコンプリートキャッシュに古い情報が残っているケース、そしてOutlook固有の機能（投票ボタンや会議依頼）がTNEFを強制的に有効にしているケースの3つです。記事内でご紹介した対策1から対策4までを順番にすべて試すことで、ほぼ確実に解決できます。特にオートコンプリートのクリアは見落とされがちなので、忘れずに実行してください。
メールが100%届く保証はあるのですか？
winmail.datの問題とは直接関係ありませんが、大切なポイントなので触れておきます。電子メールは、どんなシステムを使っても100%の到達を保証するものではありません。迷惑メールフォルダへの振り分け、サーバーの一時的な障害、添付ファイルのサイズ制限など、メールが届かない原因は多岐にわたります。重要なメールを送ったら、電話やチャットで「届きましたか？」と確認する習慣をつけましょう。送ったことより、伝わったことが大事です。
Macユーザーはwinmail.datを受け取りやすいのですか？
はい、その傾向があります。MacでOutlookを使っている方は比較的少数であり、多くのMacユーザーはApple Mailを利用しています。Apple MailはTNEF形式を解析できないため、Outlookから送信されたTNEFエンコードのメールを受信すると、winmail.datとして表示されてしまいます。iPhoneやiPadのメールアプリでも同様の問題が起きやすいです。Macユーザーへメールを送る機会が多い方は、本記事の送信側対策を特に入念に行ってください。
今すぐパソコンやスマホの悩みを解決したい！どうしたらいい？
いま、あなたを悩ませているITの問題を解決します！
「エラーメッセージ、フリーズ、接続不良…もうイライラしない！」
あなたはこんな経験はありませんか？
✅ ExcelやWordの使い方がわからない💦
✅ 仕事の締め切り直前にパソコンがフリーズ💦
✅ 家族との大切な写真が突然見られなくなった💦
✅ オンライン会議に参加できずに焦った💦
✅ スマホの重くて重要な連絡ができなかった💦
平均的な人は、こうしたパソコンやスマホ関連の問題で年間73時間（約9日分の働く時間！）を無駄にしています。あなたの大切な時間が今この悩んでいる瞬間も失われています。
LINEでメッセージを送れば即時解決！
すでに多くの方が私の公式LINEからお悩みを解決しています。
最新のAIを使った自動応答機能を活用していますので、24時間いつでも即返信いたします。
誰でも無料で使えますので、安心して使えます。
問題は先のばしにするほど深刻化します。
小さなエラーがデータ消失や重大なシステム障害につながることも。解決できずに大切な機会を逃すリスクは、あなたが思う以上に高いのです。
あなたが今困っていて、すぐにでも解決したいのであれば下のボタンをクリックして、LINEからあなたのお困りごとを送って下さい。
ぜひ、あなたの悩みを私に解決させてください。
まとめ
Outlookで添付がwinmail.datになる問題は、Microsoft独自のTNEF形式という20年以上前から存在するメール仕様が根本的な原因です。解決策は明快で、送信側がメッセージ形式をHTMLまたはテキスト形式に変更し、連絡先の個別設定とオートコンプリートキャッシュをクリアすること。これだけで大半のケースは解決します。それでも直らない頑固な場合には、レジストリでTNEFを完全無効化するか、Exchange管理者にサーバー側の設定変更を依頼しましょう。
受信側でお困りの方は、Gmail転送や専用ツールで応急的に中身を取り出しつつ、送信者に設定変更をお願いするのがベストです。「winmail.datっていうファイルになっちゃってるみたいなので、リッチテキストを解除して再送してもらえませんか？」と一言伝えるだけで、お互いのストレスがなくなります。
ちょっとした設定の見直しで、メールのトラブルは驚くほど減ります。この記事の内容を、ぜひ社内やチームで共有してください。一人ひとりが正しい設定を知っているだけで、無駄なやり取りや誤解が生まれない、スムーズなビジネスコミュニケーションが実現できるはずです。
コメント