.exe、.bat、.dll、.docm など、Microsoftが定めた拡張子の一覧を一律にブロックする仕組みで、管理者が個別に追加・変更することはできませんでした。予定どおり提供されれば、組織の業務や受け渡しの実態に合わせて、チャットに送らせないファイル種別を設計しやすくなります。
ただし、拡張子をブロックするだけで、ファイル共有が安全になるわけではありません。制作会社では、クライアントからOfficeファイルを受け取り、外注から圧縮ファイルや素材を受け取ります。「誰が・どの案件で・どの経路から受け取るか」も同時に決める必要があります。
この記事は2026年9月19日時点の情報です。カスタマイズ機能はMicrosoft 365 Roadmapで2026年11月の提供予定とされており、提供時期、対象環境、設定方法は変更または延期されることがあります。導入時には、Roadmap ID 571298と自社テナントの最新情報を確認してください。
TeamsのWeaponizable File Protectionとは？
Weaponizable File Protectionは、マルウェアなどに悪用されやすいファイル形式が添付されたメッセージを、Teamsがチャットとチャンネルでブロックする機能です。管理者が有効にすると、対象拡張子を含む添付ファイルだけでなく、そのファイルを含むメッセージ全体が配信されません。送信者はファイルを外して編集・再送でき、受信者はメッセージ内容の閲覧やファイルのダウンロードができません。 Microsoft Learn：Weaponizable File Protection in Teams 現行のブロック対象には、実行ファイルの.exe、コマンド実行に使われる .bat・.cmd、ライブラリの .dll、マクロ有効文書の .docm、ショートカットの .lnk、ディスクイメージの .iso などが含まれます。Microsoft Learnが公開している一覧は固定で、現時点では管理者が設定できないとされています。 Microsoft Learn：ブロック対象の拡張子一覧
社外組織との会話でも注意が必要です。Microsoftの説明では、会話に参加する組織のいずれかで保護が有効なら、その会話の全員に適用されます。相手が「送れるはず」と考えて送ったファイルでも、自社側の設定によってメッセージが届かないことがあります。
2026年11月に何が変わる？
Roadmap ID 571298で予定されているのは、Weaponizable File Protectionのブロック対象拡張子を管理者がカスタマイズできるようにする変更です。固定リストのオン・オフだけではなく、組織固有の受け渡しルールをTeamsの入口で反映しやすくなります。 Microsoft 365 Roadmap：Roadmap ID 571298 一方で、拡張子のブロックはファイルの安全性を判定する機能ではありません。安全な拡張子に見せかけたファイル、パスワード付きの圧縮ファイル、許可された形式の文書に埋め込まれた内容までを、拡張子だけで評価できるわけではありません。 推奨は、最初から多くの形式を止めるのではなく、実際にチャットで受け取る必要がない形式から始めることです。設定変更前に、制作・開発・情シスの担当者で「止める形式」「例外が必要な用途」「代替の受け渡し先」を確認してください。業務を止めずに安全性を上げられます。制作会社で注意したいファイル共有
クライアントから届くOfficeファイル
見積書、原稿、確認表などはOfficeファイルで届きやすく、.docx や .xlsx まで一律に拒否すると現場が回りません。一方、マクロ付き文書や、予期しないリンク・埋め込みオブジェクトを含むファイルは、通常の原稿や表計算ファイルとは別に扱うべきです。
受け取る前に、送付元、ファイル名、用途をメッセージに書いてもらい、マクロが必要な場合は担当者へ事前連絡するルールにします。必要なら、マクロ付きファイルをチャット添付ではなく、権限を限定したDrive・Box・SharePointの所定フォルダに置いてもらい、担当者だけが確認する運用に分けます。
外注から届く圧縮ファイル
デザイン素材、動画、ソースコードはサイズが大きく、圧縮ファイルで届くことがあります。圧縮形式そのものを一律に危険と決めるのではなく、「誰から受け取るか」「中身を確認できるか」「案件フォルダに直接置く前に検査できるか」を確認します。 特にパスワード付きの圧縮ファイルは、検査をすり抜ける目的で悪用される場合があります。やむを得ず使う場合も、パスワードを同じ会話に書かず、送付元を確認した別経路で受け取り、展開先を案件の共有フォルダとは分ける、といったルールが必要です。実行ファイル・マクロ付きファイル
.exe、.bat、.cmd、.dll のような実行に関係するファイルは、通常の制作レビューやクライアント確認でチャット添付が必要になることは多くありません。マクロ付きのOfficeファイルも、必要な業務と受け取る担当者を明確にできないなら、原則として通常の案件チャンネルへ添付しない設計が安全です。
開発案件で配布物や検証ツールを渡す必要がある場合は、チャットに直接添付するのではなく、リリース管理・ソースコード管理・限定共有のストレージを使います。ファイルのハッシュ、バージョン、作成者、利用目的を記録し、受け取る人を限定できる経路に寄せると、誤送信と改ざん確認の両方に役立ちます。
「チャットに送れる＝安全」ではない
危険な拡張子のブロックは、明らかにリスクの高い形式を入口で減らす有効な対策です。しかし、送信できたことは、安全性の保証ではありません。正規のOfficeファイルやPDFでも、不審な送付元、想定外の依頼、急かす文面、リンク先の変更といった不自然さがあれば、開かずに送付元へ別経路で確認する必要があります。 添付時に次の情報を本文へ残すだけでも、確認の質が変わります。- ファイルの用途と確認してほしい内容
- 作成者または送付元
- 案件名、版数、共有する理由
- 開く・編集する担当者と期限
社外メンバーとのファイル共有ルール
おすすめは、ファイルの形式だけでなく、案件と参加者で共有範囲を区切ることです。
案件の開始時には、クライアント・外注をどのチャンネルへ参加させるか、どのストレージフォルダを使うか、案件終了時に誰がアクセスを外すかを決めます。終了時に、チャットの参加者とストレージの共有権限を同じチェックリストで見直すことも重要です。