メールで届く注文書・請求書PDFをPower Automateで自動処理する ── 保存・振り分け・通知・読み取りの設計

「受注メールに添付されたPDFの注文書を、毎朝共有フォルダーに保存して、Excelの受注台帳に転記する」。この作業を毎日30分、担当者が手作業でやっている――そういう会社は珍しくありません。実際、Power Automate の相談の中でも「メールで届く帳票の処理を自動化したい」という話はかなり多い部類です。

一見単純な自動化に見えますが、実際に作ってみると細かい落とし穴が多い領域でもあります。署名の画像まで保存されてフォルダーがゴミだらけになる。対象外のメールでフローが動いて誤保存する。大きい添付のメールだけなぜか処理されない。この記事では、受信トリガーから保存・振り分け・通知までの基本フロー、実務でつまずきやすい落とし穴、AI Builder による読み取り(転記の自動化)まで踏み込むかどうかの判断、そしてメール添付という受け取り方自体の限界まで、順に整理します。

1. まず結論

• Office 365 Outlook コネクタの「新しいメールが届いたとき (V3)」トリガーには、フォルダー・差出人・件名フィルター・「添付ファイル付きのみ」などの絞り込み条件が用意されています。条件は後段の条件分岐アクションではなく、できるだけトリガー側で指定します。¹²
• 受け口は担当者個人の受信トレイではなく、共有メールボックス(例: order@自社ドメイン)にします。専用トリガー「共有メールボックスに新しいメールが届いたとき (V2)」があり、接続アカウントに共有メールボックスへのアクセス許可があれば使えます。³
• 「添付ファイルあり」の判定だけでは、署名やロゴなどのインライン画像も添付として拾ってしまいます。添付ファイルのメタデータにある Is Inline プロパティと拡張子でフィルターするのが基本の対策です。⁴
• 保存先は SharePoint ドキュメントライブラリにして「ファイルの作成」アクションで書き込み、Teams またはメールで保存完了を通知する構成が扱いやすいです。⁵
• 読み取り(転記の自動化)まで踏み込む場合は AI Builder のドキュメント処理を使いますが、消費型のクレジット(容量)が別途必要で、抽出結果には人手確認の設計が必須です。ライセンス体系が2025年以降変わりつつあるため、導入前に最新情報の確認が要ります。⁶⁷
• パスワード付き ZIP(PPAP)で届く添付は、フローで解こうとするのではなく、受け取り方自体を変えるのが本質的な対策です。

2. 対象業務の整理 ── 「メール添付で届く帳票」はどこまで自動化するか

まず、この記事が対象にする業務の形を確認しておきます。

• 取引先から、注文書・請求書・納品書などの PDF がメール添付で届く
• 担当者がそれを開き、共有フォルダーの決まった場所に保存する
• 内容(取引先名、金額、品目など)を Excel や業務システムに転記する
• 担当者や関係者に「注文が来た」ことを知らせる

受発注の受け取り方には、FAX、メール添付、Web フォーム、EDI といった段階があります。メール添付は FAX よりはデータ化しやすい一方、構造化されたデータ連携である EDI やデジタルインボイスには及ばない、中間的な位置にあります。この全体像は別記事「EDIとは？企業間の受発注をどう楽にするのか ── FAX・メール・手入力からデータ連携へ」で整理しています。

その上で、メール添付運用のまま自動化で狙える範囲を分けると、次の3段階になります。

この記事の主戦場は (1) と (2) です。まず (1) だけでも日々の効果は十分にあり、(2) は費用対効果を見て判断する、という進め方をおすすめしています。(3) は第7章で触れます。

3. 基本フロー ── 受信トリガーから保存・通知まで

基本形は「受信トリガー → 絞り込み → 添付ごとのループ → SharePoint へ保存 → 通知」です。

flowchart TD
    Start([共有メールボックスに新しいメールが<br/>届いたとき V2<br/>order@自社ドメイン]) --> Filter[トリガー条件で絞り込み<br/>差出人・件名フィルター・添付ファイル付きのみ]
    Filter --> Each[Apply to each<br/>添付ファイルごとにループ]
    Each --> Check{Is Inline = false<br/>かつ 拡張子 .pdf ?}
    Check -- いいえ --> Skip[処理しない<br/>署名画像などを除外]
    Check -- はい --> Save[SharePoint: ファイルの作成<br/>取引先/年月フォルダーへ<br/>受信日時を含むファイル名で保存]
    Save --> Notify[Teamsチャネルへ投稿 または メール通知<br/>保存先リンク・差出人・件名を記載]
    Notify --> End([完了])
    Save -. 失敗時 .-> Err[エラー通知<br/>管理者へ失敗を知らせる]

主なアクションと設計のポイントは次の通りです。

保存先フォルダーを「取引先/年月」のように動的に決める場合は、保存先フォルダーの存在をフロー側で保証することも忘れないでください。新しい取引先からの1通目や月初の1通目では、保存先のフォルダーがまだ存在しません。SharePoint コネクタには「新しいフォルダーの作成 (Create new folder)」アクションがあり、フォルダーパスをまとめて作成できるため⁵、「ファイルの作成」の前にフォルダーを用意するステップを組み込んでおくと、ここで保存が詰まる事故を防げます。

保存先を昔ながらのファイルサーバーではなく SharePoint にするのは、クラウドフローから直接書き込める、リンクで通知できる、後から AI Builder や検索と組み合わせやすい、という理由です。オンプレミスのファイルサーバーにしか置けない事情がある場合はオンプレミスデータゲートウェイ経由という手もありますが、構成が重くなるため、可能なら保存先ごと SharePoint に寄せることをおすすめしています。

なお、フロー全体のエラー処理(失敗時の通知、実行履歴の確認)の考え方は、別記事「Power Automateで業務を自動化する ── クラウドフロー・デスクトップフローの使い分けとエラー処理設計」で詳しく書いています。

4. 落とし穴と対策

最初の動くフローは半日もあれば作れます。問題はそこからで、実運用に耐えるかどうかは次の落とし穴を潰してあるかで決まります。

4.1 署名・ロゴ画像が「添付ファイル」として保存される

一番よくある相談です。メール本文に埋め込まれた署名画像や会社ロゴは、データ上はインライン添付として扱われるため、「添付ファイルあり」の条件だけで保存すると、本命の PDF と一緒に image001.png のようなファイルが大量に保存されます。

Office 365 Outlook コネクタでは、トリガーやアクションが返す添付ファイルのメタデータに Id・Name・Content Type・Size・Is Inline が含まれ、これらは「添付ファイルを含める」の設定に関係なく常に取得できます。Is Inline が true のものがインライン添付です。⁴

対策は二段構えにします。

1. Apply to each の中で、条件アクションで Is Inline が false のものだけを通す
2. さらにファイル名の末尾が .pdf であることを確認する(取引先が本文中に画像で帳票を貼ってくるケースを除き、これでほぼ確実に絞れます)

なお、サイズの大きい添付や多数の添付を日常的に受ける場合は、トリガーの「添付ファイルを含める」をオフにしておき、メタデータで対象を選別した後、必要な添付だけを「添付ファイルの取得 (V2)」アクションで個別に取得する構成も選べます。¹ 添付のメタデータ(Is Inline や名前)は「添付ファイルを含める」の設定に関係なく取得できるため、選別のロジックはどちらの構成でも同じです。⁴ トリガーが受け渡すデータを小さく保てるので、フローが育って添付の扱いが重くなってきたときはこの形への切り替えを検討してください。

4.2 対象メールの絞り込み ── 専用アドレス+共有メールボックス

個人の受信トレイには、注文書以外のメールも大量に届きます。差出人や件名でどれだけ頑張って絞り込んでも、取引先がメールの書き方を変えれば漏れます。根本対策は、注文受付専用のアドレスを用意して、取引先にはそこへ送ってもらうことです。

このとき受け口は共有メールボックスにします。理由は2つあります。

• 受信の入り口を担当者個人のメールボックスから切り離せる。担当者の異動・退職でメールの受け口ごと消えたり、後任が過去のメールを見られなくなったりする事故を防げる
• 共有メールボックス自体には個別のライセンスが不要で、アクセスするユーザー側にライセンスがあればよい⁹

トリガーは「共有メールボックスに新しいメールが届いたとき (V2)」を使います。前提条件として、フローの接続に使うアカウントがその共有メールボックスへのアクセス許可を持っている必要があります。注意点として、権限を付与してからプラットフォーム側に反映されるまで2時間程度かかることがあるほか、Microsoft 365 グループのアドレスは共有メールボックスとして指定できません。³

ただし、共有メールボックスにすればフローの属人化がなくなるわけではない点に注意してください。フローの接続(Outlook への認証)は接続を作成したユーザーのアカウントに紐づいたままで、共有された接続はそのフローの中でしか使えず、他の所有者が別の所有者の接続の資格情報を変更することもできません。¹⁰ つまり、接続に使ったアカウントが退職で無効化されれば、受け口が共有メールボックスでもフローは動かなくなります。接続はできるだけ退職予定と切り離せる運用用のアカウントで作り、あわせて共同所有者を設定して、いざというとき別の所有者が自分の接続に差し替えてフローを維持できる体制にしておきます。

4.3 同名ファイルの上書きと重複

「注文書.pdf」という名前の添付は、複数の取引先から何度でも届きます。受信した名前のまま保存すると、同名ファイルの衝突が必ず起きます。保存時のファイル名は受信メールの情報から機械的に組み立てて一意にします。実務では「受信日時(秒まで)+差出人ドメイン+元のファイル名」のような命名にしておくと、衝突をほぼ避けられ、後からメールと突き合わせるのも楽になります。

また、フローの修正後にテストで手動再実行した場合など、同じメールを二重に処理してしまう場面もあります。受信日時ベースの命名なら、このとき書き込み先になるのは同じメール由来の同名ファイルだけなので、別の取引先のファイルを巻き込んで消してしまうことはありません。ただし同名への2回目の書き込み自体は衝突するため(上書きになるか失敗になるかに関わらず、内容は同じものです)、二重処理そのものを検出したい場合は、トリガーの出力に含まれるメッセージIDを保存先リストの列やファイル名に含めておくと、処理済みかどうかを機械的に突き合わせられます。¹

4.4 取りこぼしの検知 ── 「トリガーが動かなかったメール」に気づけるか

見落とされがちですが、受信トリガーは万能ではありません。ドキュメントに明記されている制限として、次のケースがあります。

• 合計サイズが Exchange 管理者の設定した上限または 50 MB のいずれか小さいほうを超えるメールは、トリガーがスキップします。保護されたメール(暗号化メール)や、本文・添付が不正なメールもスキップされることがあります¹
• 同時に大量のメールが届いた場合、システム側の制限によりまれにトリガーがメールを取りこぼすことがあります¹¹

つまり「フローがエラーになった」のではなく「そもそも実行されなかった」メールが起こり得ます。エラー通知だけを監視していても、この取りこぼしには気づけません。対策としては、フローの成功・失敗の通知に加えて、受信トレイを定期的に人が確認する運用を残す(処理済みメールをフローでフォルダー移動させ、受信トレイに残っているものは未処理と分かるようにする)のが現実的です。メール自体のサイズ上限は Exchange Online 側の設定で決まり、既定では受信 36 MB、管理者設定で 1〜150 MB の範囲で変更できます。大容量添付のやり取りがある取引先には、後述するファイル共有リンクなど別の受け渡し方法を検討します。¹²

5. 読み取り(転記の自動化)まで踏み込むか ── AI Builderのドキュメント処理

保存と通知が回り始めると、次に欲しくなるのが「PDF の中身を読んで台帳に書き込むところまで自動化したい」です。ここで使うのが AI Builder のドキュメント処理です。

5.1 事前構築済みモデルとカスタムモデル

AI Builder には、請求書向けの事前構築済みの請求書処理モデルが用意されています。請求書番号・請求日・支払期日・取引先名・合計金額・明細行などの共通フィールドを、モデルの学習なしでそのまま抽出でき、対応言語には日本語も含まれます。入力は JPEG/PNG/PDF で、ファイルサイズは 20 MB までという制限があります。¹³

一方、注文書のように会社ごとにレイアウトが異なる帳票や、請求書でも標準フィールド以外の項目(自社の管理番号など)を取りたい場合は、ドキュメント処理カスタムモデルを作ります。「固定テンプレート文書」「一般文書」「請求書(事前構築済みモデルの拡張)」の3タイプから選び、同じレイアウトの帳票をコレクションとしてまとめ、1コレクションあたり最低5件のサンプル文書をアップロードして、抽出したいフィールドや表をタグ付けして学習させます。¹⁴

フローへの組み込みはどちらも簡単で、請求書処理モデルなら「請求書から情報を抽出する」アクション、カスタムモデルなら「ドキュメントを処理する」アクションに、SharePoint に保存した PDF のファイルコンテンツを渡すだけです。¹⁵⁸

5.2 精度と例外処理 ── 信頼度スコアで人手確認に回す

読み取りの自動化で一番大事なのは、「抽出は間違えることがある」を前提に設計することです。AI Builder の抽出結果には、フィールドごとに 0〜1 の信頼度スコアが付いてきます。実務では、このスコアでフローを分岐させます。¹⁵

• スコアが高い(例: 0.9 以上)→ そのまま台帳へ書き込み、通知は「自動処理済み」
• スコアが低い → 台帳には「要確認」として書き込み、担当者へ「この項目を確認してください」と通知する

Microsoft のドキュメント自体が、事前構築済みモデルとカスタムモデルを組み合わせ、信頼度スコアが低い場合にもう一方のモデルへフォールバックさせる構成例を紹介しています。¹³「全部自動で読めたら儲けもの、読めなかった分だけ人が見る」という設計にすると、精度100%を追わずに済み、導入のハードルが大きく下がります。

5.3 ライセンスとクレジット ── ここは事前確認が必須

AI Builder のアクションは実行のたびに消費型の容量を使います。従来この容量は AI Builder クレジットと呼ばれ、AI Builder 容量アドオン(1アドオンあたり月100万クレジット)のほか、Power Automate Premium などの Premium ライセンスにも少量(Power Automate Premium で5,000クレジット)が付属してきました。クレジットはテナント単位でプールされ、環境に割り当てて使います。環境に容量がないと、フローは NoCapacity などのエラーで止まります。⁶

ただし、この体系は現在移行期にあります。2025年10月に AI Builder クレジットの段階的終了が発表され、Premium ライセンス付属のシードクレジットは2026年11月1日に終了、新規顧客は AI Builder 容量アドオンを購入できず Copilot クレジットを購入する形に変わっています。AI Builder の機能自体は Copilot クレジットで引き続き使えますが、クラウドフローでは AI Builder クレジットを先に消費し、無くなると Copilot クレジットを消費する、という優先順位になっています。⁷¹⁶

要するに、「読み取りまでやるなら追加コストがかかる。その体系は今まさに変わりつつある」ということです。導入判断の目安を表にしておきます。

6. パスワード付きZIP(PPAP)が来る場合 ── フローで解く話ではない

「添付がパスワード付き ZIP で届くのですが、フローで解凍できますか」という質問も定番です。結論から言うと、フローの中で解こうとしないでください。

パスワード付き ZIP の運用は、パスワードが別メールで届き、人間がそれを読んで手で入力して開く、という前提で成り立っています。パスワードの通知タイミングも書式も相手任せで、機械処理を想定した仕組みではありません。ここを無理に自動化しようとすると、パスワードメールの解析やパスワードの保管といった、本来やらなくてよい危うい仕組みを抱え込むことになります。

そもそも PPAP は、同じ経路で鍵と荷物を送っている時点でセキュリティ対策としての意味も乏しく、受信側のウイルス検査を素通りさせる害のほうが大きい運用です。この問題点と代替手段(ファイル共有リンクなど)は別記事「なぜメールセキュリティにおいて PPAP はダメなのか。正しいやり方は？」で詳しく書いています。自動化の文脈で言えば、PPAP で届く帳票は「受け取り方を変える交渉をすべき対象リスト」の筆頭です。取引先に対しても「自動処理の都合で、パスワード付き ZIP ではなく平文の PDF 添付またはファイル共有リンクでお願いしたい」という依頼は、PPAP 廃止の流れもあり、以前より通りやすくなっています。

7. その先へ ── メール添付運用の限界と段階移行

保存も通知も読み取りも整えた後に残るのは、「そもそもメール添付で帳票をやり取りしている」こと自体の限界です。

• 帳票のレイアウトは取引先の数だけあり、読み取りモデルの保守は取引先が増えるほど重くなる
• 読み取り精度は100%にならないため、人手確認の工程は永遠に残る
• メールは届かないことがあり(サイズ超過、迷惑メール判定)、取りこぼし監視も残り続ける

これらは Power Automate の設計をどれだけ磨いても消えません。工程の起点が「非構造化データ(PDF)を人間宛てに送る」ことにある限り、読み取りと確認は必要経費として残ります。だからこそ、中期的には最初から構造化データで受け取る方向、つまり Web 受注フォーム、EDI、請求書ならデジタルインボイス(Peppol / JP PINT)への段階移行を視野に入れる価値があります。

移行は一斉切り替えである必要はありません。応じてくれる取引先から順に新しい受け取り方へ移し、残りはメール添付+自動処理で受ける、という二重運用が現実的です。この段階移行の設計は「FAX受注をWebに移すには ── 二重運用期間の設計と段階移行の実務」で、デジタルインボイスの仕組みは「デジタルインボイスとは？ ── 「請求書のPDFをメールで送る」と何が違うのか」で整理しています。本記事のフローは、その移行期間中の「メール添付で受け続ける分」を支える仕組みとして位置づけるのがよいと考えています。

8. まとめ

メールで届く注文書・請求書 PDF の処理は、Power Automate の自動化テーマとしては入門的な部類ですが、実運用に耐えるものにするには押さえるべき点がはっきりしています。

まず、受け口を共有メールボックスの専用アドレスにし、絞り込み条件はトリガー側に寄せる。添付の選別は Is Inline と拡張子の二段構えにして署名画像を除外する。ファイル名は受信日時ベースで一意にし、トリガーがスキップするケース(50 MB 超、暗号化メール、同時大量受信)があることを前提に、取りこぼしに気づける運用を残す。ここまでが第一段階です。

読み取りまで踏み込むなら、AI Builder の事前構築済みモデルかカスタムモデルを信頼度スコアの分岐とセットで使い、消費型クレジットのコストと移行中のライセンス体系を事前に確認する。そして、パスワード付き ZIP はフローで解かず、受け取り方を変える交渉の対象にする。メール添付という形式自体の限界が見えてきたら、Web フォーム・EDI・デジタルインボイスへの段階移行を検討する――この順番で進めれば、大きな手戻りなく育てていける領域です。

関連記事

• Power Automateで業務を自動化する ── クラウドフロー・デスクトップフローの使い分けとエラー処理設計
• なぜメールセキュリティにおいて PPAP はダメなのか。正しいやり方は？
• EDIとは？企業間の受発注をどう楽にするのか ── FAX・メール・手入力からデータ連携へ
• FAX受注をWebに移すには ── 二重運用期間の設計と段階移行の実務
• デジタルインボイスとは？ ── 「請求書のPDFをメールで送る」と何が違うのか

関連する相談領域

合同会社小村ソフトでは、Power Automate を使ったメール・帳票処理の自動化設計や、受発注業務のデジタル化に向けた段階移行の相談を扱っています。

• 技術相談・設計レビュー
• Windowsアプリ開発
• お問い合わせ

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

共有メールボックスに届いたメールでもPower Automateのフローを起動できますか？

できます。Office 365 Outlookコネクタには「共有メールボックスに新しいメールが届いたとき(V2)」という専用トリガーがあり、注文受付用の共有アドレスに届いたメールを起点にフローを動かせます。前提として、接続に使うアカウントがその共有メールボックスへのアクセス許可を持っている必要があります。権限を付与した直後は反映まで2時間ほどかかることがある点と、Microsoft 365グループのアドレスは共有メールボックスとして指定できない点に注意してください。担当者個人の受信トレイではなく共有メールボックスで受けるほうが受け口を引き継ぎやすくなりますが、フローの接続自体は作成したユーザーのアカウントに紐づくため、接続に使うアカウントの扱いと共同所有者の設定もあわせて決めておく必要があります。

メール署名の画像が添付ファイルとして保存されてしまうのはなぜですか？

メール本文に埋め込まれた署名画像やロゴは、データとしては添付ファイルの一種(インライン添付)として扱われるためです。「添付ファイルあり」の条件だけで処理すると、本命のPDFと一緒に署名のPNGやGIFまで保存されてしまいます。対策として、Office 365 Outlookコネクタが添付ファイルごとに返すIs Inlineというメタデータを条件分岐に使い、Is Inlineがfalseのものだけを処理します。さらにファイル名の拡張子が.pdfかどうかの判定を重ねると、対象をより確実に絞り込めます。

AI BuilderでPDFの読み取りまで自動化するには何が必要ですか？

AI Builderには請求書から請求書番号・日付・合計金額などを抽出する事前構築済みの請求書処理モデルがあり、日本語の請求書にも対応しています。注文書など独自レイアウトの帳票は、サンプル文書(1レイアウトあたり最低5件)を使って学習させるドキュメント処理カスタムモデルで対応します。実行にはAI Builderクレジットなどの消費型の容量が必要で、環境に容量が割り当てられていないとフローがエラーで止まります。また2025年10月にAI Builderクレジットの段階的終了が発表されており、今後はCopilotクレジットへ移行していくため、新規導入時は最新のライセンス体系を確認してください。

パスワード付きZIP(PPAP)で届く添付ファイルもフローで処理できますか？

パスワード付きZIPは自動処理と根本的に相性が悪く、フローの中で展開する前提で設計すべきではありません。パスワードが別メールで届き人間が読んで初めて開ける、という運用自体が機械処理を想定していないためです。ZIPのまま保存して人が開ける場所に置くことは可能ですが、それでは転記や読み取りの自動化にはつながりません。現実的には、取引先にPPAPをやめてもらう交渉、つまりファイルの受け取り方自体を変えることが本質的な対策になります。セキュリティ面でもPPAPには問題が多いため、交渉の材料としてPPAPの問題点を整理した記事も参考にしてください。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。