Power AutomateでOutlookの添付メールを取得できないときの確認順

2026 10/25

2026年10月7日 2026年10月25日

Power AutomateでOutlookの添付メールを取得できないときの確認順

著者: Walkers編集部公開: 2026年10月7日最終更新: 2026年10月25日

Power AutomateでOutlookメールを受信した際に添付一覧が空配列になる現象は、コネクタの未対応形式だけでなくセキュリティ機能による遅延など複数の要因で発生します。添付一覧のメタデータと添付の実体データの取得状態を分離し、内部種別と配信状況を順に切り分ける必要があります。本稿は一次資料に基づく診断ガイドであり、製品実機での検証は未実施です。

添付メタデータと本文データを分離して診断する

Power Automate Outlook添付メール取得トラブルの切り分けフロー

最初 試験メールの実行履歴確認 添付が存在するテストメールを受信させ、実行履歴の未加工出力を確認する。
添付配列が空 [] 配信・環境要因の切り分け Defender動的配信の遅延や、itemAttachment等の未対応形式による除外を調査する。
添付メタデータあり 添付実体と内部型の確認 実体データの有無を確認し、内部種別がfileAttachmentかitemAttachmentかを特定する。
itemAttachmentかつ送信変更可能 ZIP形式送信の運用検討 送信側にZIP圧縮での送付を依頼し、標準コネクタでの受信・保存・展開を検証する。
itemAttachmentかつ送信変更不可 Microsoft Graph APIの検討 Mail.Read権限や認証方式を確認し、Graph経由での生データ取得・保存を設計する。
最終確認 保存ファイルの開封検証 保存先アクションに渡したファイルが破損せず、実務上で正しく開封・閲覧できるか確認する。

内部種別が未加工出力で特定できない場合は「未確認」として扱い、憶測で判断せずGraph API等の詳細ログで検証してください。

Power AutomateのOffice 365 Outlookコネクタにおいて添付ファイルが想定通りに取得できないトラブルを調べる際は、まず通常添付が存在することが確認できている試験メールを用いて、実行履歴の未加工出力を確認します。その上で「添付一覧のメタデータが存在するか」と「添付ファイルの実体データが含まれているか」の2段階を明確に区別して切り分けます。Power AutomateとPower Appsの役割の違いを発注判断の前に確認したい場合は、ノーコード・ローコード・AI駆動開発の用語FAQ20問が手引きになります。

「添付ファイルを含める」設定の正しい動作

該当するメール受信トリガーやアクションのパラメータにある「添付ファイルを含める（Include Attachments）」は、添付ファイルの実体バイナリを取得結果に含めるかを制御する設定です。Office 365 Outlookコネクタの添付ファイル仕様が示す通り、ID、名前（name）、コンテンツタイプ（contentType）、サイズ（size）などのメタデータは、本設定が「いいえ」であっても返されます（※対象の操作バージョンや仕様定義に依存します）。

したがって、実行履歴の出力において添付配列そのものが空（[]）になっている場合、その原因を「添付ファイルを含める」が「いいえ」になっていることだけに求めるのは誤りです。メタデータ一覧すら返らない事象と、メタデータはあるが実体データが含まれない事象を混同せず、使用している具体的な操作名と未加工出力を記録して検証する必要があります。

空配列を引き起こす外部要因

添付ファイル一覧のメタデータが空配列になる要因は、コネクタの設定不備以外にも存在します。Office 365 Outlookトリガーの既知の問題によると、Microsoft Defenderの動的配信（Dynamic Delivery）が有効な環境では、メール本文が先に配信され、セキュリティスキャンが完了するまでの間、初期のトリガー応答で添付ファイル配列が空として返される場合があります。

なお、同資料ではメールを大量に同時受信した場合などに処理がタイムアウトを起こし、正常に取得できなくなる制約も挙げられています。タイムアウト時は空配列ではなく実行エラーとなるケースも含まれるため、配列が空であるという事象（セキュリティ遅延や非対応形式など）と、処理自体が失敗するエラー障害を切り分けて観察する必要があります。

業務の自動化や各種クラウドツールの運用設計でお困りの際は、AI業務診断をご活用いただけます。

itemAttachmentの仕様制約と拡張子の違い

メタデータ取得の成否を確認した次の段階として、添付されているアイテムの内部種別を調査します。特に「通常のPDFは取得できるのに、転送メールやメッセージの添付だけが処理できない」という事象では、内部オブジェクトの型の違いが関係しています。

Office 365 Outlookコネクタにおける非対応種別

Office 365 Outlookコネクタの既知の問題と制限事項において、Office 365 Outlookコネクタは電子メール、予定表アイテム、配信不能レポート（NDR）などの「アイテム添付（item attachment）」に対応していないことが公式に規定されています。

一方で、PDFや画像などの通常のバイナリデータは「ファイル添付（fileAttachment）」として扱われます。Outlookクライアント上でメッセージ項目を添付する操作を行った場合、内部的にitemAttachmentとして構成されることがあり、この形式をコネクタのアクションが解釈できない場合に出力が得られなくなります。

EML・MSGの拡張子と内部種別の関係

添付ファイル名が.emlや.msgといったメール形式の拡張子であっても、その内部データ構造が一律に決まるわけではありません。メールボックス内のメッセージを直接添付したのか、ローカルファイルをドラッグ＆ドロップしたのかといった送信操作の記録と、実際の応答から得られる内部種別の確認は分離して管理する必要があります。

外見上の拡張子や送信操作から内部種別を補完・断定することはできません。コネクタの出力やAPIの応答で型が取得できない場合は「未確認」とし、実際の応答に含まれる内部型を個別に観察して判定することが求められます。

状況	該当する条件	推奨される次の確認手順
配信・環境要因の調査	PDF等も含めすべての添付で一覧メタデータが空配列になる	Defender動的配信の有無や未対応形式の除外、実行履歴の受信状態を確認
エラー・取得失敗の調査	空配列ではなくフローの実行履歴でタイムアウトやエラーが発生する	大量受信時のタイムアウト制約の有無やコネクタのエラーログを確認
送信運用の変更検討	通常ファイルは取得可能でメール添付のみ失敗し、送信側の変更が可能	送信元にZIPファイル形式での送付へ変更可能か確認
Graph APIの検討	送信側の運用を変更できず、メール項目添付の自動取得が業務上必須	Microsoft Graph APIの最小権限、ライセンス、データ形式の対応を調査

送信側のZIP化運用とMicrosoft Graph APIの比較

メール添付の自動取得がコネクタの制限に直面した場合、対処方針は大きく「送信側での送信方式の変更」と「Microsoft Graph APIの利用」の2つに分かれます。それぞれの前提条件と技術的制約を比較検討します。コネクタの頭打ちにより外部API活用が避けられないときは、Power Apps・AppSheetで内製するか、AI駆動開発で外注するかを踏まえ社内開発を続けるか判断します。

送信元でのZIP圧縮と保存後の開封確認

Office 365 Outlookコネクタの制限事項では、EML、MSG、ICSなどのアイテムをトリガー応答で取得するための回避策として、それらをZIPファイルに含めて送信する方法が言及されています。

送信元が社内組織などで運用変更を依頼できる相手であれば、ZIP圧縮での送信はトリガー応答で添付を取得するための有力な回避策です。ただし、ZIP形式の採用には送信側の合意が必要なほか、受信側でのZIP展開や保存後のメールファイルが破損せず実務上で正しく閲覧・開封できるかまで、後続アクションを含めた個別検証が必要です。

Microsoft Graph APIを利用する際の権限とデータ構造

送信側の運用変更が不可能な場合、Microsoft Graph APIを経由して添付オブジェクトを取得する構成が検討されます。Graphの添付ファイル取得API仕様では、添付の種別としてfileAttachment、itemAttachment、referenceAttachmentが明確に定義されています。

Graph APIの標準的なGETリクエストでは添付オブジェクトのプロパティが返されます。URLの末尾に/$valueを付与すると生データ（raw content）を取得できますが、この挙動は添付種別によって異なります。メールのitemAttachmentに対して/$valueを呼び出すとMIME形式の生データが返されますが、クラウド上の共有ファイルを指すreferenceAttachmentに対して/$valueを実行するとHTTP 405（Method Not Allowed）エラーとなります。

データ形式の面では、fileAttachmentのリソース仕様におけるcontentBytesがBase64（バイナリを文字列へ変換した形式）で返されます。一方、/$valueで取得される生データ（raw content）はHTTP応答としてバイナリまたはMIME（メール構造テキスト）形式で返されます。Power Automateの保存先アクションが要求する入力仕様やコンテンツタイプ（Content-Type）を確認し、無条件の二重デコードや文字列変換によるファイル破損を避ける設計が必要です。

Power AutomateからGraph APIを直接呼び出す場合、HTTP with Microsoft Entra IDコネクタなどのPremiumコネクタを利用することが一般的です。事前承認型（preauthorized）コネクタとは異なり、利用するスコープに応じた管理者同意や構成が必要となります。

Graph APIでメール添付を取得する最小特権スコープとしてはMail.Readなどが定義されています。Microsoft Graphの仕様上はサインインユーザーとして実行する「委任アクセス」とアプリ単体で動作する「アプリケーションアクセス」が存在し、対象メールボックスの指定方法（/meまたは/users/{id}）が異なります。ただし、直前に挙げたコネクタ側でサポートされている具体的な認証方式はコネクタ定義側の仕様に依存するため要確認であり、Power Automate上で両方式を無条件に選択できるわけではありません。本稿では本人のメールボックスを委任アクセスで参照する構成を前提としており、アプリケーションアクセスや共有メールボックスの取得可否は別途検証が必要です。また、接続作成に成功しても、管理者同意の不足や組織のアクセス許可ポリシーによりHTTP 403（Forbidden）が返されることがあります。

接続確認とファイル保存・開封の分離確認

フローの構築においては、APIやコネクタが成功ステータス（HTTP 200等）を返したことと、目的のファイルが実務上利用可能な状態で保存されたことを別個に評価しなければなりません。以下は、自社環境で検証を行うための確認票テンプレートです。実機試験は未実施のため、結果セルは空欄としています。

ケース	送信条件	送信側変更可否	取得経路	観測結果（内部種別／配列／形式）
1	PDF添付	可 / 否	コネクタ（トリガー）	未確認
2	メッセージ直接添付	可 / 否	コネクタ（アクション）	未確認
3	ローカルEML/MSG添付	可 / 否	Graph API（通常GET）	未確認
4	メッセージ直接添付	可 / 否	Graph API（/$value）	未確認
5	EML/MSGをZIP化添付	可 / 否	コネクタ（トリガー）	未確認

ケース	保存先アクション	確認項目	実測開封結果
1	未確認	PDF閲覧可否	未確認
2	未確認	メール閲覧可否	未確認
3	未確認	メール閲覧可否	未確認
4	未確認	MIME解読・閲覧可否	未確認
5	未確認	展開後メール閲覧可否	未確認

送信条件と取得経路（コネクタのトリガー／アクション、Graphの通常GET／/$value）を区別して試験します。内部種別、添付配列の有無、応答形式、保存先アクションへの受け渡し可否、および保存後の開封結果はすべて空欄または未確認として扱い、実際の検証ログから記録してください。

社内システムやクラウド自動化の進め方に課題を感じている場合は、現状の課題を整理するAI業務診断をご検討ください。

よくある質問

「添付を含める」を有効にすれば空配列は直りますか？

メタデータは本設定が「いいえ」でも返される仕様ですが、具体的な挙動は対象の操作バージョンや仕様定義に依存します。まず利用中のトリガーやアクションの仕様定義を確認した上で、それでも一覧が空配列になる場合は、非対応のアイテム添付やDefender動的配信による遅延の有無を切り分けてください（大量受信時のタイムアウト等は空配列ではなくエラー終了となる場合があります）。