合同会社小村ソフト
相談する
メニュー

FAXで届く注文書をAI Builderで読み取る ── 手入力転記を減らす現実的な設計と限界

· 更新日: · · Power Automate, AI Builder, FAX受注, OCR, SharePoint, 受発注, 業務自動化, 技術相談

更新履歴(3件・最終更新 2026年08月02日)

この記事に加えた変更の記録です。アーカイブした更新前のバージョンは、DOI付きの固定URLから読めます。

記事の冒頭に「この記事の知識マップ」節を追加しました。本文で扱っている概念とその関係を、要約・図・詳細ページへのリンクにまとめたものです。本文の主張は変えていません。
外部レビュー(1283件)への対応として本文を更新しました。個々の変更内容は、この下の履歴を参照してください。
信頼度スコアで仕分ける処理の実装例を、条件式と型の違いまで含めて追加しました。あわせてモデル作成の手順を画面のメニュー名どおりの10ステップに書き起こし、クレジットが尽きたときの対処と消費量の概算表を追加しています。
初版公開
この記事を引用する(DOI: 10.5281/zenodo.21590162)

この記事はZenodoにアーカイブされています。常に最新版へ解決されるDOIと、いま表示している版に固定されたDOIの両方を下に示します。

小村 豪(2026)「FAXで届く注文書をAI Builderで読み取る ── 手入力転記を減らす現実的な設計と限界」合同会社小村ソフト. https://doi.org/10.5281/zenodo.21590162 https://staging.comcomponent.com/blog/fax-order-ai-builder-ocr-automation/

DOI(最新版)
10.5281/zenodo.21590162
DOI(この版)
10.5281/zenodo.21733108

「受注の4割はまだFAXです。複合機から出てきた注文書を見ながら、販売管理システムに1件ずつ打ち込んでいます」。製造業や卸売業の相談で、本当によく聞く話です。続けて出てくるのが「取引先にWeb発注をお願いできる関係ではない」「大手の取引先ほど、先方の発注システムがFAX送信前提になっていて動かせない」という事情です。

FAX受注の改善には、大きく2つの路線があります。ひとつはWeb受注やCSV取込へ移行して「FAXをやめる」路線。もうひとつは、FAXを受けたまま、読み取りと転記を自動化して「やめられないFAXと付き合う」路線です。前者は別記事「FAX受注をWebに移すには ── 二重運用期間の設計と段階移行の実務」で扱いました。この記事は後者、つまりFAXをPDFとしてデータで受け、AI Builderのドキュメント処理で読み取り、人の確認を挟んで受注台帳と基幹システムへつなぐ設計の話です。

先に言っておくと、この仕組みは「全自動」にはなりませんし、するべきでもありません。それでも、毎日1〜2時間の転記作業を「読み取り結果を確認するだけ」の数十分に圧縮できるなら、投資に見合う会社は多いはずです。どこまで自動化できて、どこからが限界なのかを、Microsoft Learnで確認できる仕様に基づいて整理します。

1. まず結論

  • FAX読み取り自動化の前提はFAXを紙ではなくデータ(PDF)で受けることです。複合機のFAX転送機能やクラウドFAXサービスで受信FAXをファイル化し、SharePointに集約するところから始まります。
  • AI Builderのドキュメント処理カスタムモデルは、注文書のような独自レイアウトの帳票から項目・表を抽出できます。学習は「同じレイアウトの帳票=コレクション」単位で、1コレクションあたり最低5件(最大20件)のサンプルが必要です。12
  • 学習タイプ(固定テンプレート文書・一般文書)のどちらも日本語に対応しており、FAQでは手書き文字の抽出にも対応すると明記されています。ただしFAX品質の実帳票でどこまで読めるかは、必ず自社サンプルで検証が必要です。32
  • フローの肝は信頼度スコアによる仕分けです。抽出結果にはフィールドごとに0〜1のスコアが付くため、高信頼は自動で台帳へ、低信頼は人の確認へ回す分岐を組みます。全件を人が見る前提を捨てず、「確認が楽になる」設計にします。4
  • 全取引先の帳票を読もうとしないことです。レイアウトごとにコレクションを分ける仕組み上、件数上位の取引先の定型注文書だけでも効果が出ます。低品質な帳票はサンプルを15〜20件に増やす対処が公式に案内されています。25
  • AI Builderは消費型のクレジットが別途必要です。ドキュメント処理はページ単位で消費し、カスタムモデルは事前構築済みモデルよりレートが高めです。2025年10月発表のAI Builderクレジット段階的終了により、体系はCopilotクレジットへ移行中です。67
  • 読み取りは万能ではありません。件数・取引先数・帳票の定型度によっては、Web受注移行やEDIのほうが本筋になります(第8章の判断表)。

この記事の知識マップ

この記事は、複合機やクラウドFAXサービスでFAX注文書をPDF化してSharePointに集約し、AI Builderのドキュメント処理カスタムモデルで手入力転記を自動化する設計を扱います。モデルはコレクション単位で固定テンプレート文書として学習し、抽出結果には0〜1の信頼度スコアが付くため、高信頼は自動で台帳へ、低信頼は担当者による人の確認へ回す仕分けをフローに組み込みます。基幹システムへ渡すのは確認済みの行だけという関門は維持します。運用にはページ単位で消費するAI Builderクレジットが必要で、2025年10月の段階的終了発表によりCopilotクレジットへの移行が進んでいます。

FAX注文書をAI Builderで読み取る自動化の知識マップAI Builderのドキュメント処理カスタムモデルがコレクション単位の学習と信頼度スコアによる仕分けを通じて手入力転記を自動化し、消費型クレジットとAI BuilderクレジットからCopilotクレジットへの移行がその運用コストを左右する構造を示す図自動化する前提とするに保存される前提とするより先に行うべき実装を担う前提とする利用する利用する両立しない推奨される対応で確認できる利用する前提とする推奨される対応前提とする前提とするの後継に保存されるに保存される原因になり得るで確認できるで構成できる推奨される対応用いるのは非推奨前提とする前提とするで構成できるFAX注文書読み取りの自動化AI Builderのドキュメント処理手入力転記FAXのデータ化SharePointドキュメントライブラリ「ドキュメントを処理する」アクションドキュメント処理カスタムモデルコレクション固定テンプレート文書(文書タイプ)一般文書(文書タイプ)TIFF形式の学習非対応低品質スキャンでのサンプル増量信頼度スコア信頼度スコアによる仕分け人の確認ステップ確認済み状態のみ基幹連携する関門AI BuilderクレジットCopilotクレジットAI Builder容量アドオンPremium付属シードクレジットAI Builderクレジットの段階的終了NoCapacity系エラーPower Platform管理センターでの容量確認事前構築済み請求書処理モデルドキュメントインテリジェンスv4.0

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全28件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. 「やめる」と「読み取る」── 2つの路線を混ぜない

FAX受注の相談を受けるとき、最初に確認するのは「FAXをやめられる相手なのか」です。

Web受注への移行は、取引先に行動を変えてもらう取り組みです。段階移行の記事で書いたとおり、件数が多くシステム対応できる取引先から順に移し、効果の大きいところで手入力を減らしていきます。一方で、どうしても動かせない取引先は残ります。先方の発注業務がFAX前提で回っている、担当者の高齢化でWeb入力を頼めない、そもそも自社が「お願いする側」の力関係にない――こうした相手のFAXは、数年単位で残ると考えるのが現実的です。

そこで出てくるのが「読み取る」路線です。ポイントは、この2路線が排他ではないことです。

路線 相手 自社側の変化 取引先側の変化
やめる(Web受注・CSV取込へ移行) 協力を得られる取引先 受け口の開発・マスタ整備 発注方法が変わる
読み取る(本記事) FAXをやめられない取引先 受信のデータ化と読み取りフロー なし

「読み取る」路線の最大の利点は、取引先に一切の変化を求めないことです。段階移行の二重運用期間中、FAXチャネルの処理コストを下げる手段としても機能します。逆に限界もはっきりしていて、読み取り精度は100%にならないため、確認の工程は残り続けます。取引先ごとにレイアウトが違う帳票を全部読もうとすると、モデルの保守で消耗します。だからこそ、移せる相手は移し、残る相手のFAXを読む、という組み合わせで考えます。

なお、メール添付のPDFで届く注文書の処理は「メールで届く注文書・請求書PDFをPower Automateで自動処理する ── 保存・振り分け・通知・読み取りの設計」で扱いました。FAXをメール転送で受ける場合、受信以降の設計はこの記事とメール記事の合流地点になります。

3. 前提: FAXを「データ」で受ける ── 紙のままでは始まらない

AI Builderに渡せるのはファイルです。複合機が印字した紙をスキャンし直す運用では、手間が転記からスキャンに変わるだけで自動化になりません。最初にやるべきは、受信FAXが人手を介さずファイルとして保存される経路を作ることです。現実的な選択肢は2つあります。

  • 複合機のFAX転送機能。業務用複合機の多くは、受信FAXを印刷せずに指定フォルダーへ保存(スキャンtoフォルダー)したり、メールに添付して転送したりできます。設定は機種のマニュアルと保守業者に確認します。
  • クラウドFAXサービス。FAX番号ごとクラウドサービスに移し、受信FAXをPDFとしてメールやAPIで受け取る形です。複合機の入れ替えなしにデータ化でき、番号ポータビリティの可否や料金体系はサービスごとに確認が必要です。

どちらの経路でも、着地点はSharePointのドキュメントライブラリに揃えることをお勧めします。SharePointコネクタには「ファイルが作成されたとき(プロパティのみ)」トリガーと「ファイル コンテンツの取得」アクションがあり、保存をそのまま後段の読み取りフローの起点にできるためです。8 メール転送で受ける場合は、共有メールボックスで受けて添付PDFをSharePointへ保存するフローを前段に置きます(この設計はメール添付記事の第3〜4章そのままです)。

ファイル形式で1点注意があります。複合機の転送設定によっては、FAXがTIFF形式で保存されることがあります。AI Builderのドキュメント処理は、モデルの学習にはPDF・JPG・PNGしか使えませんが、学習済みモデルをクラウドフローで実行する際にはTIFFも処理できます。3 とはいえ学習サンプルの準備を考えると、転送設定でPDF出力を選んでおくのが素直です。あわせて、処理できるファイルは最大20 MB、画像の場合は50×50〜10,000×10,000ピクセルという制限も押さえておきます。3

4. AI Builderのドキュメント処理で何ができるか

カスタムモデルの学習の仕組み

AI Builderのドキュメント処理は、サンプル帳票を使って「この帳票のどこに何が書いてあるか」を学習させるカスタムAIモデルです。モデル作成時にはまず文書タイプを選びます。1

文書タイプ 向いている帳票 特徴
固定テンプレート文書 請求書・注文書・納品書など、項目の位置がレイアウトごとに決まっている帳票 学習が速い。精度スコアの評価機能はこのタイプのみ対応5
一般文書 契約書・レターなど、決まった構造のない文書 抽出力は高いが学習に時間がかかる
請求書 事前構築済みの請求書処理モデルに独自フィールドを追加したい場合 既定フィールド+追加学習

取引先の定型注文書なら、基本は固定テンプレート文書です。次に、抽出したい情報を定義します。フィールド(注文番号、注文日、取引先名、納品先など)、表(品目・数量・単価の明細行)、チェックボックスを指定できます。1

学習の単位になるのがコレクションです。コレクションとは「同じレイアウトの帳票のグループ」で、取引先Aの注文書とB社の注文書のようにレイアウトが違う帳票は、別のコレクションに分けます。各コレクションには最低5件のサンプル文書をアップロードし、フィールドや表の位置をタグ付けして学習させます。1コレクションあたりのサンプルは最大20件、1モデルあたり最大200コレクションまで作れます。13 高品質な文書なら5件で十分なことが多い一方、低品質なスキャンでは15〜20件を使うことが公式FAQで推奨されています。2

モデル作成の手順

学習とテストにクレジットは消費されないため9、まず作ってみるのが早道です。画面の道順は次のとおりです(メニュー名はMicrosoft Learnの表記に合わせています)。1

  1. Power Apps(make.powerapps.com)またはPower Automate(make.powerautomate.com)にサインインします。
  2. 左ペインの … More(その他) > AI hub を開きます。よく使うならピン留めしておくと楽です。
  3. Discover an AI capability の中から AI models を選びます。
  4. Extract custom information from documents(文書からカスタム情報を抽出する)を選びます。
  5. Create custom model を選ぶと、ウィザードが始まります。
  6. Choose document type で文書タイプを選びます。取引先の定型注文書なら Fixed template documents(固定テンプレート文書)です。
  7. Choose information to extract で +Add から抽出したい項目を定義します。テキスト・数値・日付・チェックボックス・表を追加でき、数値は小数点記号(.か,)、日付は年月日の並び順、表は列構成をここで指定します。
  8. レイアウトごとにコレクションを作り、それぞれに5件以上のサンプル(JPG・PNG・PDF)をアップロードします。取引先2社で様式が違うなら、コレクションも2つ作ります。
  9. アップロードした各サンプルの上で、手順7で定義した項目に該当する箇所をタグ付けします。
  10. Train で学習させ、Quick test で試します。想定どおり読めたら発行(公開)して、フローから呼べる状態にします。

自社のサンプルがまだ手元にない段階で操作だけ試したい場合は、Microsoftが用意しているサンプルデータでモデルを作ることもできます。1

なお手順6で選んだ文書タイプとは別に、モデルは内部のドキュメントインテリジェンスのバージョン(v4.0 / v3.1)を持ちます。最後に編集したタイミングで決まり、Settings > Published model version で確認できます。表とセルの信頼度スコアが得られるのはv4.0で、古いモデルは編集・再学習・再発行すればv4.0に上がります。1

日本語と手書きの対応

日本語の帳票を扱う上で確認すべき点は、Microsoft Learnで次のとおり確認できます。

  • 固定テンプレート文書・一般文書のどちらの学習タイプでも、日本語がサポート言語に含まれます。3
  • 公式FAQに「ドキュメント処理は印刷テキストと手書きテキストを抽出できる」と明記されています。2

ただし、ここは正直に書いておきます。「対応している」と「自社のFAXが実用精度で読める」の間には距離があります。FAXは解像度が低く、かすれ・つぶれ・斜行が日常的に起きます。手書きの数量訂正や走り書きの備考が読めるかは、帳票の書かれ方次第です。ドキュメント処理のモデル学習とテストは無料でできるので9、導入判断の前に、実際に受信したFAXのPDFそのものをサンプルにして学習・テストし、自社帳票での精度を見ることを必ず挟んでください。きれいな原本PDFで学習してFAXで運用すると、テストと本番で画質が違いすぎて精度が出ない、という失敗になりがちです。

事前構築済みモデルとの違い

AI Builderには学習不要の事前構築済みモデルもあります。代表が請求書処理モデルで、請求書番号・請求日・支払額などの共通フィールドを学習なしで抽出でき、対応言語には日本語が含まれます。10 請求書の処理ならまずこれを試すのが早道です。

一方、注文書向けの事前構築済みモデルはありません。注文書・発注書・納品書のようにレイアウトが会社ごとに違う帳票は、公式FAQでも固定テンプレート文書のカスタムモデルの典型例として挙げられており2、本記事の主題であるFAX注文書はカスタムモデルの領域になります。

5. フロー全体設計 ── 人の確認を挟む

全体像はこうなります。肝は真ん中の「人の確認」で、ここを省いた全自動構成は後述の理由でお勧めしません。

高信頼低信頼取引先からFAX受信複合機のFAX転送 / クラウドFAXサービスPDFとしてフォルダー・メールへSharePointドキュメントライブラリへ保存受信日時を含む一意なファイル名クラウドフロー起動ファイルが作成されたときAI Builder: ドキュメントを処理する注文番号・取引先・納期・明細を抽出信頼度スコア判定例: 主要フィールドすべて0.9以上?受注台帳リストへ記録状態: 自動読取済み・未確定担当者へ確認依頼Teams通知+元PDFへのリンク原本と突き合わせて修正し確定状態: 確認済み一覧をまとめて確認し確定状態: 確認済み基幹システムへ入力 ── 状態「確認済み」の行のみCSV取込 / Power Automate for desktop

読み取りステップ

フローでは「ドキュメントを処理する(Process documents)」アクションに、学習・公開済みのモデルと、SharePointから取得したファイルコンテンツを渡します(このアクションは2025年5月に「文書から情報を抽出する」から名称変更されました)。出力には、定義した各フィールドの値({フィールド} value)と信頼度スコア({フィールド} confidence score)、表のセルごとの値とスコアが含まれます。複数ページの文書では、処理対象のページ範囲を指定して消費を抑えることもできます。4

実装上の注意として、抽出値はすべて文字列で返ります。数量や金額を台帳の数値列に入れるにはint/float式で変換し、通貨記号や空白はreplace式で除去します。日付もformatDateTime式で揃えます。4 FAX番号や注文番号の全角半角ゆらぎもここで正規化しておくと、後段の突合が楽になります。

確認ステップ ── ここが肝

読み取り結果の確認は、次の2つの形が組みやすいです。

  1. 台帳リストの状態列で確認を回す。受注台帳をSharePointリストで持ち、読み取り結果を「要確認」状態で登録して、担当者がリスト上で元PDF(添付またはリンク)と見比べて修正し、状態を「確認済み」に変える形です。確認済みへの変更をトリガーに後続処理を走らせます。台帳をExcelからSharePointリストへ移す設計は「Excel台帳をSharePointリストへ置き換える」で扱っています。
  2. Teamsの承認で確認を回す。承認(Approvals)コネクタの「開始して承認を待機」アクションをカスタム応答付きで使い、「このまま登録」「修正が必要」のような選択肢で担当者に判断してもらう形です。承認の作り方と応答の扱いは「Power Automateで承認フローを作る ── 紙とメールの稟議・申請を電子化する」で詳しく書きました。11

どちらの場合も、通知はTeamsのチャネルに集約し、元のFAX PDFへのリンクを必ず添えることです。12 確認作業の実体は「読み取り結果と原本の突き合わせ」なので、原本を開くのに手間がかかる設計だと確認が形骸化します。

台帳から基幹システムへ

確認済みのデータを基幹システムへ入れる方法は、基幹側の入口次第です。CSV取込機能があるなら、確認済みデータをCSVに整形して取り込むのが堅実です。取込機能がなく画面入力しかない場合は、Power Automate for desktopによる画面操作の自動転記が選択肢になります。この設計は「Power Automate for desktopで基幹システムへの転記を自動化する」で扱っています。フロー全体のエラー処理(読み取り失敗時の通知、再実行)は「Power Automateのエラー処理とリトライ設計」の考え方がそのまま使えます。

6. 精度と付き合う ── 全部読めなくても効果は出る

信頼度スコアで仕分ける

「読み取りは間違えることがある」を前提にすると、設計の中心は信頼度スコアの使い方になります。スコアは0〜1で、1に近いほど抽出値が正しい確度が高いことを示します。4 実務ではたとえば、こう分けます。

  • 注文番号・取引先・納期・明細の主要フィールドがすべてしきい値(例: 0.9)以上 → 「自動読取済み」で台帳へ。担当者は一覧をまとめて確認し、確定操作だけで済ませる
  • どれか1つでもしきい値未満 → 「要確認」で担当者へ。スコアの低いフィールドを通知に明記し、原本と突き合わせて修正してもらう

実装は「条件」アクション1つで足ります。「ドキュメントを処理する」の後に条件を置き、動的コンテンツの一覧から {フィールド名} confidence score を選んでしきい値と比較します。主要フィールドをまとめて判定するなら、条件を詳細モード(式)に切り替えてandでつなぎます。以下の<...>は、Microsoft Learnの例示にならって「動的コンテンツから挿入する箇所」を表します。4

and(
  greaterOrEquals(<注文番号 confidence score>, 0.9),
  greaterOrEquals(<取引先名 confidence score>, 0.9),
  greaterOrEquals(<納期 confidence score>, 0.9)
)

式を書くときのポイントは2つです。

  • 値とスコアで型が違います。 {フィールド} value は文字列ですが、{フィールド} confidence score は0〜1のfloatで返るため、スコアはそのまま数値比較できます。金額や数量そのものを条件に使う場合だけfloat()やint()で変換します。4
  • 明細表のセルにもスコアが付きます({表名}{列名} confidence score)。ただし表の列を参照した時点で、そのアクションは自動的に「Apply to each」の中に入ります。明細全体をまとめて判定したいなら、変数(例: minScoreを1.0で初期化)を用意し、ループ内で各行のスコアと比較して最小値を残し、ループの後で1回だけしきい値と比べる形が扱いやすくなります。4 なお、表とセルの信頼度スコアが得られるのはドキュメントインテリジェンスv4.0のモデルです。1

条件の「はい」側で受注台帳へ「自動読取済み」として登録し、「いいえ」側でTeams通知と要確認登録に分岐させれば、この章の仕分けはそのままフローになります。

高信頼の側も、確認そのものを省くわけではない点に注意してください。スコアは「正しい確度が高い」ことを示すだけで、正しさの保証ではありません。高信頼でも読み違いは起きるため、基幹システムへ渡すのは人が確定操作をした「確認済み」の行だけという関門は、スコアに関係なく維持します。スコアで変えてよいのは確認の重さ(まとめて確定か、1件ずつ修正か)であって、確認の有無ではありません。

しきい値は最初から決め打ちにせず、運用開始後の「自動扱いにしたのに実は間違っていた件数」を見ながら調整します。重要なのは、間違いのコストが非対称なことです。要確認に倒しすぎても確認の手間が少し増えるだけですが、誤読を自動で通すと誤出荷につながります。迷ったらしきい値は高めに置きます。

FAX画質という宿命

ドキュメント処理の要件には「紙からのスキャンは高品質な画像であること」「文字が埋め込まれたPDF(テキストPDF)のほうが文字化けや位置ズレがなく望ましい」とあります。35 FAXはこの理想の対極にあります。それでも打てる手はあります。

  • 学習サンプルを実際のFAXにする。前述のとおり、運用時と同じ画質で学習させるのが第一です。低品質な画像では、サンプルを10〜15件以上に増やすことが公式に案内されています。5
  • 送信側の品質に働きかける。上位取引先には「高画質(ファイン)モードで送ってほしい」と頼めることがあります。取引先に変化を求めない路線とはいえ、送信ボタンの隣の設定1つなら頼みやすい部類です。
  • 読めない帳票を無理に読まない。かすれがひどい、手書きが大半、といった帳票は要確認行きが常態化します。その取引先は読み取り対象から外し、従来どおり手入力する判断も必要です。

レイアウトが取引先ごとに違う問題

注文書のレイアウトは取引先の数だけあります。ドキュメント処理はこれをコレクションで吸収する設計になっており、レイアウトごとにコレクションを分けて1つのモデルにまとめられます(最大200)。3 ただし、コレクションを増やすほどサンプル収集とタグ付け、精度検証、レイアウト変更への追従という保守が増えます。取引先が注文書の様式を変えれば、そのコレクションは学習し直しです。

だからこそ、始め方は「全部読む」ではなく「件数上位の取引先の定型注文書だけ読む」です。FAX受注が月600件で、上位3社が350件を占めるなら、3コレクション(サンプル各5〜20件)のモデルで転記の6割弱が対象になります。残りは今までどおり手入力でよいのです。これは段階移行の記事で書いた「効果の大きいところから順に動かす」原則の読み取り版で、Web移行の取引先分類(A/B/C)がそのまま流用できます。パイロットで型を作り、効果を測ってからコレクションを足していく進め方が、モデル保守の消耗を防ぎます。

細かい制約も確認しておきます。ページをまたぐフィールドや、ページをまたいで折り返す明細行は現状サポートされていません。3 複数ページの注文書が多い取引先では、明細の設計に注意が必要です。

7. ライセンスと費用感 ── クレジットという消費モデル

AI Builderのアクションは、Power Automateのライセンスとは別に、実行のたびに消費型の容量を使います。ここを知らずに作り始めると、本番でNoCapacity系のエラーに突き当たります。9

仕組みはこうです。ドキュメント処理は処理したページ数に応じてクレジットを消費します(抽出対象のデータがないページでも消費します)。2 消費レートは機能ごとに異なり、公式のレート表では、カスタムモデルのドキュメント処理は1ページあたり100 AI Builderクレジット、事前構築済みの請求書処理などは1ページあたり32クレジット、Copilotクレジット体系ではコンテンツ処理として1ページあたり8 Copilotクレジットと定義されています。6

クレジットの入手経路は、従来は次の2つでした。9

  • AI Builder容量アドオン: 1アドオンあたり100万クレジット
  • Premiumライセンス付属のシードクレジット: Power Automate Premiumライセンス1本あたり5,000クレジット

クレジットはテナント単位でまとまり、管理者が環境に割り当てて使います。試算すると、Premium付属の5,000クレジットはカスタムモデルのドキュメント処理50ページ分です。1枚ものの注文書が月50件までなら付属分で収まり、月600件ならアドオンやCopilotクレジットの購入が必要、という規模感になります。

消費量の概算

金額は時点と契約で変わるためこの記事では扱いませんが、消費するクレジット量は公開レートから自分で計算できます。カスタムモデルのドキュメント処理は1ページ100 AI Builderクレジット、Copilotクレジット体系ではコンテンツ処理として1ページ8 Copilotクレジットです。6 月あたりの読み取りページ数を掛けるだけです。

月間の読み取りページ数 AI Builderクレジット Copilotクレジット 目安
50ページ 5,000 400 Power Automate Premium 1本の付属シードクレジット(5,000)でちょうど収まる
600ページ 60,000 4,800 付属分では足りない。容量アドオン(100万クレジット)の6%程度を消費
3,000ページ 300,000 24,000 容量アドオン1本の3割

計算の考え方はMicrosoftのFAQの例(領収書処理32,000件×32クレジット=1,024,000クレジット→アドオン1本+Premium 5本で充当)と同じです。9 実際の支払額は、この消費量に自社の契約単価(アドオンやCopilotクレジットの価格、為替や割引の適用状況)を掛けて出します。Power Platformライセンスガイド(PDF)にレートカードがあるので、見積もりはそこと最新の価格情報で確認してください。9

注意点として、消費量は月単位でリセットされ、使い残しは翌月に繰り越されません。9 繁忙期の山に合わせて多めに確保すると、閑散期の分は無駄になります。ページ範囲の指定で無駄な読み取りを減らす、読み取り対象を件数上位の取引先に絞るといった設計上の節約が、そのまま費用に効きます。

クレジットが尽きたときの対処

NoCapacity、EntitlementNotAvailable、QuotaExceeded、No capacity was found、Credit usage exceeds allocation といったエラーでフローが失敗したら、環境へのクレジット割り当てを確認します。フローデザイナーでは「All AI Builder credits in this environment have been consumed(この環境のAI Builderクレジットをすべて消費しました)」という修復パネルが出ます。9

確認と対処の道順は次のとおりです。9

  1. Power Platform管理センターで Licensing(ライセンス) > Capacity add-ons(容量アドオン) > Summary タブを開き、購入済み・割り当て済み・消費済みのクレジット数を確認します。
  2. 環境ごとの消費量はAI Builder消費レポートで確認します。当月分を合計すると、その環境の月間消費量になります。
  3. 不足していれば、同じ画面の Add-ons タブから Assign to an environment で環境に割り当て直します(テナント全体または他の環境の余剰を回します)。
  4. それでも足りなければ、容量アドオンの追加購入(既存顧客のみ、2026年11月1日まで)またはCopilotクレジットの購入・従量課金の許可を検討します。

ここで押さえておきたい仕様が1つあります。環境にクレジットを割り当てると、その環境はテナントの未割り当てクレジットを自動では使いません。9 「テナント全体にはまだ残っているのに、この環境だけ止まった」という事故は、この仕様を知らないと原因にたどり着けません。逆に、割り当てを行っていない環境はテナントの未割り当て分を使います。運用開始前に、読み取りフローを置く環境がどちらの状態なのかを管理者と確認しておいてください。

ただし、この体系は今まさに移行期です。2025年10月にMicrosoftはAI Builderクレジットの段階的終了を発表しました。2025年11月1日以降、新規顧客はAI Builder容量アドオンを購入できず、2026年11月1日にはアドオンの更新終了とPremiumライセンス付属シードクレジットの廃止が予定されています。AI Builderの機能自体はなくならず、Copilotクレジットで引き続き利用できます。移行期間中は、AI Builderクレジットを先に消費し、尽きるとCopilotクレジットを消費、両方なければ実行がブロックされる、という優先順位です。7

要するに「読み取りには実行量に応じた追加コストがかかる。その通貨が切り替わりつつある」ということです。この記事では具体的な金額は挙げませんが、月間のFAX件数×ページ数からレート表で消費量を見積もり、最新の価格情報とあわせて確認してください。Power Automate側のライセンス(標準/プレミアムコネクタの境界)については「Power Automateのライセンスと標準/プレミアムコネクタの境界」で整理しています。

8. どの道を選ぶか ── 判断表

FAX注文書への対処は、AI Builder読み取りだけが答えではありません。件数・取引先数・帳票の定型度で線を引くと、だいたい次のようになります。

状況 現実的な選択
FAX受注が月数十件、取引先も少ない 手入力継続。読み取りの構築・保守コストが効果を上回りにくい。まずは受信のPDF化と保存の自動化だけでも価値がある
件数は多いが、少数の取引先の定型注文書に集中している AI Builder読み取りの好適地。上位取引先のコレクションから始めて、確認フローとセットで運用する
件数が多く、取引先が協力的(データで注文を作れる) Web受注・CSV取込への移行が本筋。読み取りという工程自体をなくせる。移行期間中の残FAXに読み取りを併用
手書き中心・レイアウトが毎回違う・画質が悪い 読み取りの精度が安定しない。手入力を残しつつ、その取引先こそWeb・電話など受け方自体の変更を交渉する対象
特定業界で取引量が大きく、標準フォーマットが存在する EDIを検討。業界標準があるなら独自の読み取りより長期的に安い(「EDIとは？企業間の受発注をどう楽にするのか」参照)
移行もEDIも進めたいが投資余力が課題 省力化投資の補助制度が使える場合がある(「省力化投資補助金でFAX受注のWeb化はできるか」参照)

判断の感覚としては、「同じレイアウトの帳票が月に何枚届くか」を数えるのが早いです。この数が大きい取引先が数社あるなら読み取りが効きます。レイアウトあたりの枚数が少ないまま取引先だけ多いなら、読み取りモデルの保守が割に合わず、Web移行かEDI、あるいは手入力継続のほうが合理的です。

もうひとつ、忘れてはいけないのが確認工程の位置づけです。読み取り自動化の効果は「転記がゼロになる」ことではなく、「転記が確認に変わる」ことです。効果測定では、導入前の入力時間と、導入後の確認・修正時間を同じ物差しで測ってください。要確認率(しきい値未満で人に回った割合)と、自動扱いの誤読件数をあわせて追うと、しきい値調整とコレクション追加の判断材料になります。

9. まとめ

FAXで届く注文書の自動化は、「FAXをやめる」話とは別の路線として設計できます。整理すると、こうなります。

まず、受信FAXを複合機の転送機能やクラウドFAXサービスでPDF化し、SharePointに集約する。紙のままでは何も始まりません。次に、AI Builderのドキュメント処理カスタムモデルを、件数上位の取引先の定型注文書に絞って学習させる。コレクションあたり最低5件、FAX品質ならサンプル多め、学習には実際に受信したFAXを使う。そして、信頼度スコアで自動と要確認を仕分け、人の確認を挟んでから台帳と基幹システムへ流す。全自動を狙わないことが、かえって導入を早く、運用を安定させます。

費用面では、消費型クレジットの見積もりと、AI BuilderクレジットからCopilotクレジットへの移行スケジュールの確認が必須です。そして、読み取りはあくまで「やめられないFAXと付き合う」ための手段です。協力を得られる取引先はWeb受注やCSV取込へ移し、残るFAXを読み取りで軽くする。2つの路線を組み合わせたとき、手入力の総量が一番小さくなります。

FAX受注のPDF化から読み取りフローの設計、確認ステップと基幹連携の作り込み、Web移行との組み合わせ方まで、自社の帳票でどこまでいけるか検証しながら進めたい場合は、下記の相談領域からお声がけください。

関連記事

関連する相談領域

合同会社小村ソフトでは、FAX・メールで届く帳票の読み取り自動化の設計から、確認フローの作り込み、既存の販売管理システム・基幹システムとの連携までご相談いただけます。

参考リンク

  1. Microsoft Learn, Create a document processing custom model. モデル作成ウィザードの道順(AI hub > AI models > Extract custom information from documents > Create custom model > 文書タイプ選択 > Choose information to extract > コレクションとサンプルのアップロード > Train > Quick test)、文書タイプ3種(固定テンプレート文書/一般文書/請求書)、フィールド・表・チェックボックスの定義と数値の小数点記号・日付の並び順指定、サンプルデータでモデルを作れること、コレクションが「同じレイアウトの帳票のグループ」であること、コレクションごとに最低5件のサンプル(JPG/PNG/PDF)が必要で最大200コレクション作れること、ドキュメントインテリジェンスv4.0とv3.1の違い(v4.0は表・セルの信頼度スコアや署名検出に対応)とSettings > Published model versionでの確認方法について。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  2. Microsoft Learn, FAQ for document processing. 固定テンプレート文書が請求書・注文書・納品書に適していること、印刷テキストと手書きテキストの両方を抽出できること、高品質文書なら5件で足り低品質スキャンでは15〜20件が推奨されること、コレクションあたり最低5件・最大20件のベストプラクティス、抽出対象がないページでもページ単位でクレジットを消費することについて。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  3. Microsoft Learn, Requirements and limitations for a document processing model. 固定テンプレート文書・一般文書の両タイプで日本語がサポートされること、対応形式(PDF/JPG/PNG、テキストPDF推奨)、TIFFは学習に使えないが学習済みモデルのクラウドフロー実行では処理できること、最大20 MB・画像50×50〜10,000×10,000ピクセルの制限、紙からのスキャンは高品質画像であるべきこと、1モデル最大200コレクション、ページをまたぐフィールド・明細行が非サポートであることについて。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  4. Microsoft Learn, Use a document processing model in Power Automate. 「ドキュメントを処理する(Process documents)」アクション(2025年5月に「文書から情報を抽出する」から改称)、フィールド・表セルごとの値と0〜1の信頼度スコアが出力されること、ページ範囲指定で消費を抑えられること、抽出値がすべて文字列で返りint/float/replace/formatDateTime式で変換すること、Is Inline条件による署名画像の除外について。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  5. Microsoft Learn, Improve the performance of your document processing model. 低品質画像では10〜15件などより多くのサンプルを使うべきこと、テキストPDFが画像ベース文書より望ましくスキャンPDFは画像として扱われること、精度スコアが固定テンプレート文書タイプのモデルのみで得られること、レイアウトの異なる文書は別コレクションに分けるべきことについて。 ↩ ↩2 ↩3 ↩4

  6. Microsoft Learn, Overview of licensing (AI Builder capability rate table). カスタムドキュメント処理が1ページ100 AI Builderクレジット、請求書・領収書等の分析が1ページ32クレジット、Copilotクレジット体系ではコンテンツ処理として1ページ8 Copilotクレジットという機能別消費レートについて。 ↩ ↩2 ↩3

  7. Microsoft Learn, End of AI Builder credits. 2025年10月に発表されたAI Builderクレジットの段階的終了、2025年11月1日の新規向けアドオン販売終了、2026年11月1日のアドオン更新終了とシードクレジット廃止、AI Builder機能自体はCopilotクレジットで継続利用できること、AI Builderクレジット→Copilotクレジットの消費優先順位と両方ない場合のブロックについて。 ↩ ↩2

  8. Microsoft Learn, Microsoft SharePoint Connector in Power Automate. 「ファイルが作成されたとき(プロパティのみ)」トリガー、「ファイル コンテンツの取得」「ファイルの作成」アクションなど、ドキュメントライブラリへの保存を起点にフローを組めることについて。 ↩

  9. Microsoft Learn, Licensing and AI Builder credits. AI Builder容量アドオンが100万クレジット、Power Automate Premiumライセンスに5,000クレジットが付属すること、クレジットがテナント単位でまとまり環境に割り当てて使うこと、容量不足時にNoCapacity/EntitlementNotAvailable/QuotaExceeded等のエラーでブロックされフローデザイナーに修復パネルが出ること、Power Platform管理センターのLicensing > Capacity add-ons(Summaryタブでの消費確認、Add-onsタブのAssign to an environmentでの環境割り当て)、消費レポートによる環境別消費の確認、環境に割り当てた場合はテナントの未割り当て分へ自動的に切り替わらないこと、消費が毎月1日にリセットされ使い残しが繰り越されないこと、モデルの学習とテストが無料であること、シードクレジットが2026年11月1日に削除されること、見積もりの考え方(領収書32,000件×32クレジットの例)とライセンスガイドPDFのレートカードについて。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10

  10. Microsoft Learn, Invoice processing prebuilt AI model. 事前構築済み請求書処理モデルが請求書番号・請求日・支払額などの共通項目を学習なしで抽出できること、対応言語に日本語(日本)が含まれること、入力形式(JPEG/PNG/PDF、20 MB以下)について。 ↩

  11. Microsoft Learn, Get started with approvals. 「開始して承認を待機」アクションと、応答の選択肢を自分で定義できるカスタム応答を含む承認の種類について。 ↩

  12. Microsoft Learn, Send a message in Teams using Power Automate. SharePointの「ファイルが作成されたとき(プロパティのみ)」トリガーとTeamsの「チャットまたはチャネルでメッセージを投稿する」アクションを組み合わせた通知フローについて。 ↩

関連する記事

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

関連トピック

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

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

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

よくある質問

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

AI Builderは日本語のFAX注文書を読み取れますか？
読み取れる可能性は十分あります。AI Builderのドキュメント処理カスタムモデルは、固定テンプレート文書・一般文書のどちらの学習タイプでも日本語をサポートしており、手書き文字の抽出にも対応するとFAQに明記されています。ただしFAXは解像度が低く、かすれや斜行も起きやすいため、実際にどこまで読めるかは帳票と回線品質次第です。導入判断の前に、実際に受信したFAXのPDFをサンプルにしてモデルを学習させ、自社の帳票での精度を確認することを強くお勧めします。
モデルの学習にはサンプル帳票が何枚必要ですか？
同じレイアウトの帳票をまとめた「コレクション」ごとに最低5件のサンプル文書が必要です。1コレクションに登録できるのは最大20件で、高品質な文書なら5件で足りることが多い一方、FAXのような低品質のスキャンでは15〜20件を使うことが推奨されています。取引先ごとに注文書のレイアウトが違う場合は、レイアウトごとに別のコレクションを作り(1モデルあたり最大200コレクション)、まずは件数の多い取引先の定型注文書だけから始めるのが現実的です。
読み取った結果をそのまま基幹システムに登録してよいですか？
無人でそのまま流すことはお勧めしません。AI Builderの抽出結果には各フィールドに0〜1の信頼度スコアが付くので、スコアが高いものは自動で受注台帳へ記録し、低いものは担当者へ通知して元のFAX画像と突き合わせて確認・修正してもらう分岐を必ず挟みます。確認済みのデータだけを基幹システムへの入力(CSV取込やPower Automate for desktopによる転記)に回す構成にすると、読み取りミスがそのまま出荷ミスになる事故を防げます。
AI Builderの利用にはどんな費用がかかりますか？
AI Builderのアクションは実行のたびに消費型のクレジットを使います。ドキュメント処理は読み取ったページ数に応じて消費し、カスタムモデルは事前構築済みモデルより消費レートが高く設定されています。従来はAI Builderクレジット(容量アドオンやPower Automate Premium付属の5,000クレジット)で賄う体系でしたが、2025年10月にAI Builderクレジットの段階的終了が発表され、Copilotクレジットへの移行が進んでいます。Premium付属のシードクレジットは2026年11月1日に終了するため、新規導入時は必ず最新のライセンス体系を確認してください。

著者プロフィール

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

小村 豪

合同会社小村ソフト 代表

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

お問い合わせ
ブログ一覧に戻る