Power Automateの生成AI活用方法|事務書類はAIで読み、判定はルール表に任せる
毎月届く請求書のPDFを開き、金額と支払期日を一覧に打ち込み、発注の記録と合っているかを確かめる。部長から「Power AutomateとAIで自動にできないか」と言われ、試しにフローを作った。請求書の金額は読み取れたものの、発注と違う金額の請求書も、そのまま一覧に登録されていきます。
Power Automateで生成AIを使うためのライセンスも、この1年で変わっています。
Microsoftは2025年10月にAI Builderクレジットの段階的な終了を発表し、AI Builderの実行に使う容量はCopilotクレジットへ移りつつある。以前の解説記事のライセンスの説明が、2026年10月時点では当てはまらない場合があります。
この記事を読み終えると、自部署の請求書や申請書の処理を、AIに読ませる項目、ルール表で判定する条件、人が確認する例外に分けたフローとして設計できます。必要なライセンスとクレジットの見積もり方も分かる。
Power AutomateのAIでできること、ライセンス、フローが使われなくなる原因、フローの作り方、ルール表、テストと例外の順に説明します。記事の後半には、いま使っているチェックリストを貼ると、読み取る項目・判定ルール表の下書き・例外の送り先・テストに使う書類の一覧が出る指示文を載せました。
なお、社員からの質問に規程をもとに答える窓口を作りたい場合は、Power AutomateよりCopilot Studioのエージェントが向いています。作る手順はMicrosoft AIエージェントとはで扱っています。
Power Automateと生成AIでできること
Power Automateのフローは、トリガーとアクションでできています。Microsoftの説明では、トリガーはフローを開始するイベント、アクションはトリガーの後にフローで実行するイベントです(Copilot で最初のクラウド フローを作成する)。
生成AIは、このうち一部のアクションと、フローを作る作業に関わる。
| 機能 | できること | 事務での使いどころ | 確認しておく条件 |
|---|---|---|---|
| クラウド フローのCopilot | やりたいことを文章で伝えると、トリガーとアクションを提案してフローの構造を作る。既存のフローの編集と説明もする | フローの下書き | 英語に最適化され、他の言語のサポートは限られる。変更はデザイナーで確認する |
| AI Builderの請求書処理 | 請求書番号・請求日・合計金額・仕入先名などを取り出し、項目ごとに0から1の信頼度を返す | 請求書の読み取り | 日本語に対応。AI Builderのアクションはプレミアム扱い |
| AI Builderのドキュメント処理 | 自社の書式の書類で学習させ、指定した項目を取り出す | 申請書や届出書の読み取り | 学習用に自社の書類が必要。プレミアム扱い |
| プロンプト(プロンプトを実行する) | 指示文と入力を渡し、文章を生成させる | 摘要の分類・差し戻し理由の下書き | 一部の地域に限られる。プレミアム扱い |
| 承認(開始して承認を待機) | 担当者に確認を依頼し、応答を待つ | 例外の確認 | 標準コネクタ |
出典は請求書処理事前構築済み AI モデル・Power Automate でプロンプトを使用する・Power Automate の承認を始めましょうなどのMicrosoftの公式ページです。
表のうち、事務の処理で生成AIが担うのは、書類を読むことと文章を下書きすることの2つです。請求書の金額が発注と合っているか、支払ってよいかを決める機能は、この表のどこにもありません。判定を誰が持つかは、フローを作る側が決めることになる。
Power Automateで生成AIを使うためのライセンスとクレジット
使える機能が分かったところで、費用の前提を確かめます。AI Builderのライセンスは2025年から2026年にかけて変わっており、確認した時点の公式ページで判断する必要があるためです。2026年10月時点のMicrosoftの説明は次のとおりです。
| 使うもの | 必要なもの |
|---|---|
| 標準コネクタだけのフロー(SharePoint・Excel Online (Business)・Office 365 Outlook・承認など) | Office 365のライセンスなど、標準コネクタを使う権限を含むライセンス |
| AI Builderのアクション(請求書処理・ドキュメント処理・プロンプトなど) | プレミアム コネクタ扱いで、使うフローにはPower Automate Premiumライセンスが必要 |
| AI Builderを実行するたびに消費する容量 | AI BuilderクレジットかCopilotクレジット。AI Builderクレジットは段階的に終了する |
| 実行する場所 | Dataverseを使うPower Platformの環境 |
AI Builderの容量アドオンは2025年11月1日に新規の販売を終え、新しい顧客はCopilotクレジットを購入する必要がある。AI Builderの試用版も廃止されました(AI Builder のライセンスの概要)。
2026年11月1日以降に購入や更新をしたPower PlatformやDynamics 365のライセンスには、AI Builderクレジットが付かなくなります(AI Builder クレジットの期間終了)。
クレジットの量は、読み取るページ数から見積もれます。2026年10月時点のMicrosoftの料金表では、請求書の読み取りは1ページあたり8 Copilotクレジットで、従量課金制では1 Copilotクレジットが0.01ドルです。
仮に月300ページの請求書を読み取るとすると、8×300で月2,400クレジット、従量課金制の換算で24ドルになります。この金額に、フローを動かすPower Automate Premiumのライセンス費用は含まれません。
モデルの作成とテストではクレジットを消費せず、フローで実行したときに消費する。クレジットは毎月リセットされ、翌月に繰り越せません。
日本円での価格や契約の形は会社ごとに変わるため、購入前に最新の料金表で確かめます。Copilotクレジットを環境に割り当てる操作はPower Platform管理センターで行うため、情シスのAI活用を参考に、情報システム部門と分担を決めておく。
ライセンス以外にかかる費用も含めた見方は、生成AI導入の費用相場で整理しています。
Power Automateに生成AIを入れたフローが使われなくなる3つの原因
ライセンスを用意してフローを作っても、試作のまま本番で使われないことがあります。原因は大きく3つあり、いずれもAIの読み取りの精度ではなく、フローの組み方にある。
原因1 読み取りと判定を1つのプロンプトに任せて誤りの原因を分けられない
たとえば、プロンプトに請求書の文字を渡し「発注と合っていれば承認と答えて」と頼むフローです。誤って承認と出たとき、金額を読み違えたのか、照合の条件を取り違えたのかが分からない。直す場所が決まらないまま、担当者はAIの結果を信用しなくなります。
原因2 判定の基準がフローの条件分岐の中にあり担当者が直せない
差額が1,000円以上なら差し戻す、という基準をフローの「条件」に直接書いた場合です。基準を変えるたびにフローを編集する必要があり、Power Automateを触れる人しか直せません。作った人が異動すると、どの基準で判定しているのかを誰も説明できなくなる。
原因3 例外の送り先が決まっておらず全件を人が見直す
読み取りの信頼度が低い請求書や、どのルールにも当てはまらない請求書の扱いを決めていない場合です。不安になった担当者は、フローが処理した全件を見直し始める。これでは、確認の作業が手作業のときより1つ増えるだけになる。
3つの原因に対応する対策は、次のとおりです。
| 原因 | 対策 | 扱う節 |
|---|---|---|
| 原因1 読み取りと判定が混ざる | フローを読み取り・判定・人の確認の3段に分ける | フローの作り方 |
| 原因2 基準がフローの中にある | 判定の条件をフローの外のルール表に出す | ルール表の作り方 |
| 原因3 例外の送り先がない | 例外ごとの送り先を決め、テストで確かめる | テストと例外 |
3つの原因に共通するのは、AIを入れた作業の前後に、AIの結果を確かめる新しい仕事が生まれている点です。着手する前に押さえるべき、手戻りを生まない業務の切り分け方を整理したのが、資料『AIによる業務効率化が進まない理由 ~業務設計編~』です。
なお、自部署のどの書類処理をPower Automateに移すかの仕分けは、リデザインワークのAX支援でも無料でご相談を承っています。
書類の読み取りと判定ルールを分けるPower Automateのフローの作り方
原因1への対策として、フローを読み取り・判定・人の確認の3段に分けます。請求書を例に、段ごとに使うものを並べると次の6つになる。
| 段 | やること | 使うもの |
|---|---|---|
| 1 受け取り | 請求書のPDFがSharePointのフォルダーに追加されたらフローを開始する | SharePoint |
| 2 読み取り | 請求書番号・請求日・合計金額・仕入先名と、それぞれの信頼度を取り出す | AI Builderの「請求書から情報を抽出する」 |
| 3 読み取りの確認 | 合計金額などの信頼度が基準値より低ければ、判定に進めず人の確認へ回す | 条件 |
| 4 判定 | ルール表を読み込み、発注の記録との差額・支払期日・取引先の登録の有無を照合する | Excel Online (Business)、またはSharePointのリスト |
| 5 振り分け | 合格した請求書は登録用の一覧へ、不合格とルールに当てはまらない請求書は理由を付けて担当者へ送る | 承認の「開始して承認を待機」 |
| 6 記録 | 判定結果・当てはまったルールの番号・信頼度をログの表に残す | Excel Online (Business) |
AIのアクションは2段目だけで、判定の4段目にはAIを使いません。読み取りを誤ったのか判定を誤ったのかを、段ごとの記録から切り分けられます。
3段目の基準値は、Microsoftの解説にある例が参考になります。請求書の合計の信頼度が0.65未満かどうかを確かめ、未満なら別の処理に回すフローです。最初は基準値を高めに置き、テストの結果を見て下げていくと、誤った金額が判定に進むのを防げる。
申請書や届出書のように自社独自の書式の書類は、AI Builderのドキュメント処理のモデルを自社の書類で学習させて読み取ります。読み取った後の判定と振り分けは、請求書と同じ3段で組めます。
フローの骨組みは、クラウド フローのCopilotに作らせても構いません。Microsoftは「X が発生した場合、Y をする」の形で、使うコネクタを指定して書くよう勧めています。ただしCopilotは英語に最適化されています(Copilot で最初のクラウド フローを作成する)。
また、Copilotが対応するコネクタは、Power Platformで使えるものの一部に限られる。提案に入らなかったアクションはデザイナーで追加し、Copilotが加えた変更はデザイナーで確かめます(クラウド フローの Copilot に関するよくあるご質問)。
判定をルール表に持たせる理由と表の作り方
フローの段が決まったら、原因2への対策として、4段目の判定の条件をフローの外の表に書き出します。判定をAIにもフローの条件分岐にも持たせない理由は3つあります。
1つ目は、判定の理由を説明できることです。差し戻した請求書ごとに、当てはまったルールの番号が記録に残る。生成AIに判定させた場合は、なぜその判定になったのかを条件として示せません。
2つ目は、基準が変わったときに担当者が直せることです。差し戻す金額や取引先が変わっても、表の行を直すだけで済み、フローには手を入れない。Power Automateを触れない担当者でも基準を管理できます。
3つ目は、テストができることです。ルール表は同じ入力に同じ結果を返すので、読み取りの誤りと判定の誤りを別々に数えられる。
表には、確認項目ごとに、照合する2つのデータと差し戻す条件を書きます。請求書の例は次のとおりです。
| ルール番号 | 確認項目 | 照合する2つのデータ | 差し戻す条件 | 差し戻し先 |
|---|---|---|---|---|
| R01 | 合計金額 | 請求書の合計と発注の記録の金額 | 差額が1,000円以上 | 経理担当 |
| R02 | 取引先 | 請求書の仕入先名と取引先マスタ | マスタに登録がない | 経理担当 |
| R03 | 支払期日 | 請求書の期限と社内の支払日 | 次の支払日に間に合わない | 経理課長 |
| R04 | 二重の請求 | 請求書番号と登録済みの一覧 | 同じ番号がすでにある | 経理担当 |
| R05 | 読み取りの確かさ | 合計金額の信頼度 | 基準値より低い | 経理担当 |
表の右に、根拠の規程・変更した日・変更した人の列を足しておくと、基準を変えた経緯も残る。仕入先名の照合は、「株式会社」と「㈱」のような法人格の書き方を統一してから比べないと、登録済みの取引先まで差し戻されます。
リデザインワークのAX支援でも、Power Automateを含むMicrosoftの環境で、読み取りはAI、判定はルール表という分け方でフローを組んでいます。確認項目を判定ルール表に書き出して確認の工数を減らした事例は、ダブルチェックは無駄かで紹介しています。
フローの作成を外部に頼む場合も、ルール表は自社で更新できる形で納めてもらいます。その条件の決め方は、ベンダーロックインを避けるAI導入で扱っている。
Power Automateのフローのテストと例外の扱い
ルール表ができたら、原因3への対策として、例外の送り先を決めてから本番の前にテストします。例外は次の4つに分けておく。
| 例外 | 起きる場面 | 送り先 |
|---|---|---|
| 読み取りの信頼度が低い | 手書き・不鮮明なスキャン・見慣れない書式 | 承認で担当者へ送り、正しい値を入力してもらう |
| どのルールにも当てはまらない | 新しい取引先・新しい費目 | 担当者へ送り、ルール表に足す行の候補として記録する |
| 1つのPDFに複数の請求書がある | まとめてスキャンした | ページの範囲を指定して1通ずつ読み取るか、担当者へ送る |
| AIのアクションが失敗する | クレジットの不足・呼び出し回数の制限 | 担当者に通知し、手作業の手順に切り替える |
4つ目は見落とされがちです。AI BuilderクレジットとCopilotクレジットがどちらも尽きると、AI Builderの機能は失敗する。請求書処理には、環境ごとに60秒あたり360回という呼び出しの上限もあります。
テストは、次の順で進めます。
- 過去の書類を30件選ぶ。金額が合っているもの、差額があるもの、新しい取引先、手書きを含むもの、複数ページのものを混ぜる
- 手作業の判定結果を先に記録する。この記録を正解として使う
- フローで処理し、読み取った値と判定を正解と比べる。読み取りの誤りと判定の誤りを分けて数える
- 誤りの種類ごとに直す場所を決める。読み取りの誤りは信頼度の基準値かモデルを見直し、判定の誤りはルール表の行を直す
- 本番の最初の1か月は手作業と並べて動かす。結果に差が出た件だけを確認し、期間が終わったら手作業をやめる
5番目の期間を先に決めておかないと、並行して確認する運用がそのまま続きます。プロンプトで文章を作らせる場合は、Microsoftも生成した結果を人がレビューする手順を入れるよう勧めており、承認のアクションをプロンプトの後に置く例を示しています。
判定ルール表とフローの設計を下書きするAIへの指示文
ここまでの3段の分け方、ルール表、例外の送り先は、いま使っているチェックリストがあればAIに下書きさせられます。社内で利用が認められた生成AIに、次の指示文を貼って使ってください。
あなたは管理部門の業務改善を支援する担当者です。
次の書類処理を、Power Automateのフローにするための設計を下書きしてください。
【対象の書類と処理】
(例)取引先から届く請求書。月に約300通。PDFでメールに添付されて届く
【いま確認している項目】
(チェックリストや手順書を貼る。無ければ思いつく順に箇条書きで)
【出力】
1. AIに読み取らせる項目の一覧(項目名と、請求書のどこに書かれているか)
2. 判定ルール表の下書き
列:ルール番号・確認項目・照合する2つのデータ・差し戻す条件・差し戻し先
3. 例外の一覧と送り先
(読み取りの信頼度が低い・どのルールにも当てはまらない・
1つのPDFに複数の書類がある・AIの処理が失敗する、の4つを必ず含める)
4. テストに使う書類の条件を10個(正常なもの・差額があるもの・手書き など)
【条件】
・判定はAIに任せず、すべて判定ルール表の条件で決める前提で書く
・差し戻す金額や日数が情報から読み取れない場合は、数値を推測で埋めず
「担当者に確認する質問」として別の表にまとめる
2番目の判定ルール表は、そのままExcelの表に貼ってたたき台にできます。条件の【担当者に確認する質問】は、ベテランの担当者に聞くヒアリング項目として使える。
フローの骨組みをクラウド フローのCopilotに作らせる場合は、Microsoftの勧める「X が発生した場合、Y をする」の形で、コネクタの名前を入れて書きます。AI Builderのアクションが提案に入らなければ、デザイナーで2段目に追加します。
SharePoint の「請求書受付」フォルダーにファイルが作成されたら、
Excel Online (Business) の「請求書ログ」の表に、ファイル名と作成日時の行を追加し、
Microsoft Teams の「経理」チャネルにファイル名を投稿する。
Power Automateの生成AIは読み取りに使い判定はルール表に残す
ここまで見てきたとおり、Power AutomateでAIに任せるのは書類を読む段で、支払ってよいかを決める段ではありません。判定をルール表に残しておけば、AIの読み取りを誤ったときも、基準が変わったときも、直す場所が1か所に決まる。
まずは毎月処理している書類を1つ選び、いま確認している項目を、照合する2つのデータと差し戻す条件の形で書き出してください。経理の工程ごとに、どこからAIに任せるかは経理業務のAI活用で扱っています。






