FAX注文書・手書き記録のAIデータ化|AI-OCRと生成AIの使い分けと基幹への取り込み方
- 紙・FAXのデータ化は、読む → 確かめる → 入れるの3段に分けて作ります。AIが受け持つのは「読む」です。「確かめる」はマスタとの照合と人、「入れる」は基幹の取り込み口が受け持ちます。
- 様式が決まった書類は従来の帳票定義型のAI-OCR、得意先ごとに書式が違う注文書は画像を読める生成AIが向いています。両方で読ませて、食い違った所だけを人が見る組み合わせもあります。
- 書式がバラバラでも崩れないようにするには、取り出す項目を先に決める、読めない所は推測で埋めずに空欄で返させる、得意先マスタ・品番マスタと突き合わせる、の3つが要です。
- 基幹にAPIが無くても、CSVなどのファイル取込 → RPA → 作った会社に取込口を作ってもらう、の順で入口を探せます。データベースへの直接書き込みはお勧めしません。ここで紹介するのはカトルセが商談で提案している進め方で、導入の実績ではありません。
「FAXで届く注文書を、毎日手で基幹に打ち込んでいる」「工場の記録は手書きなので、まずデータにしないとAIの使い道が出てこない」。2026年11月の第1週だけで、業種の違う3社から紙・FAX・手書きのデータ化について相談を受けました。そのうち2社とは、今週が2回目・3回目の商談でした。
この記事では、紙やFAXの書類をAIで読み取り、基幹システムに入るデータにするまでの設計を、書式がバラバラ・手書き混じり・基幹にAPIが無いという、よくある条件にそってまとめます。貿易書類や請求書など、業界・部門ごとの使い道は運輸・物流業界の生成AI活用事例やバックオフィスの生成AI活用事例に、古いシステムそのものの作り直しはレガシーシステム刷新を生成AIで進める手順にまとめています。この記事では「紙からデータへ」の設計だけを扱います。
1. 商談で聞いた「紙・FAX・手書き」の相談
カトルセが最近お会いした企業から伺った声を、業種と規模だけにして並べます。上の3件が2026年11月の第1週、下の3件がそれより前(9〜10月)です。
| 業種・規模 | 聞いた悩み・やりたいこと |
|---|---|
| 医薬品メーカーの工場(ICT部門) | 現場の記録書は手書きのものが多く、まずデータにすることが課題。データになれば、AIの使い道も出てくると考えている。 |
| 鉄鋼商社(100〜300名規模) | FAXで届く注文書をAI-OCRで読み、CSVにして基幹(FileMakerで作ったシステム)に取り込みたい。書式は得意先ごとに違い、手書きもある。社内の数値コードに置き換える決まりもある。 |
| 検査機関(100〜300名規模) | 英語やローマ字で書かれた輸入書類(パッキングリスト・インボイス・届出書)をAI-OCRで読み、基幹に入れたい。基幹は十数年前に独自に作ったもので、APIが無い。書類は通関業者や荷主が作るため、誤字もある。工場名などのローマ字は1文字違っても報告書に使えないが、読み違いを人が直せるなら許容できる。 |
| 住宅設備メーカー(品質・CS部門) | 販売店・工務店から届くFAXを、人が社内システムに転記している。決まった書式が無く、手書きや崩し字が多い。転記先のシステムが古く、APIでもCSVでも取り込めない。個人情報が多いので、検証用のサンプルを社外に出せない。 |
| ダイレクトマーケティング・物流 | 汎用のAI-OCRをすでに使っていて精度は高いが、件数が多いので目視の確認が残る。入力代行に出す費用と比べて、確認の手間まで含めて採算が合うかが課題。 |
| 製造業(300〜499名規模) | 紙・FAX・口頭・電子で届く注文を、受注管理システムに一本化したい。手書きの読み取り精度と、基幹とのつなぎ方が気になっている。 |
並べてみると、止まっている場所は「AIで読めるかどうか」より手前にあります。①書式がそろわない、②手書きや画質の悪さがある、③読んだ結果を入れる先(基幹)に入口が無い、の3つです。以下、この3つに順に答えていきます。
2. 結論:「読む・確かめる・入れる」を分けて作る
カトルセが商談で提案しているのは、紙からデータまでを3段に分け、段ごとに作って確かめる組み方です。
| 段 | 受け持つもの | やること |
|---|---|---|
| 1. 読む | AI-OCR・生成AI | 画像から、あらかじめ決めた項目だけを取り出す。読めない所は空欄にして理由を付ける。 |
| 2. 確かめる | マスタ照合のプログラム+人 | 得意先・品番・単位をマスタと突き合わせる。合わない所と、自信の低い所だけを人が原本と見比べて直す。 |
| 3. 入れる | 基幹の取り込み口 | CSVなどのファイル取込か、RPA(画面操作の代行)で入れる。同じ注文を2回入れないよう、受付番号を付ける。 |
段を分けるのには理由が2つあります。1つは、まとめて作ると、間違えたときに「読み違い」なのか「マスタに無い品名」なのか「取り込みの失敗」なのかが分からなくなることです。もう1つは、「読む」段のAIはこれからも入れ替わるのに対し、「確かめる」「入れる」段は長く使う仕組みになることです。読む部分だけを差し替えられる形にしておくと、新しいAIが出たときに試しやすくなります。
また、AIに推測で値を埋めさせないことも大切です。かすれた品名から推測した品番がそのまま基幹に入れば、誤発注につながります。推測は「候補」として確認画面に出すまでにとどめ、確定はマスタと人が行います。

3. 従来のAI-OCRと、生成AIで読む方法の違い
帳票定義型のAI-OCR:決まった様式を、毎回同じように読む
従来のAI-OCRは、帳票ごとに「どの位置に何が書いてあるか」を定義したり、見本で学習させたりしてから読む仕組みです。たとえばMicrosoftのAzure ドキュメント インテリジェンスには、読み取りモデル(印刷された文字と手書きの文字を取り出す)、レイアウトモデル(文字・表・文書の構造を取り出す)、自社の書類で学習させるカスタムモデルがあります。手書き文字に対応する言語の一覧には日本語も入っています。
カスタムモデルは2種類あります。公式の説明によると、「カスタム テンプレート」は一貫した見た目の様式を前提にしていて、見た目の違いが精度に影響します。「カスタム ニューラル」は、構造化された書類だけでなく、半構造化・非構造化の書類からも項目を取り出せます。Microsoftは、まずニューラルのほうで要件を満たせるか試すよう勧めています。
ノーコードのAI Builder のドキュメント処理でも、同じレイアウトの書類を「コレクション」にまとめ、1つのコレクションにつき5つ以上の見本で学習させます。得意先ごとに書式が違うFAXなら、書式の数だけコレクションと見本が要ることになります。
画像を読める生成AI:書式を定義せず、文脈で項目を探す
もう1つの方法が、画像を読める生成AI(大規模言語モデル)に書類を見せ、「この注文書から得意先・品名・数量を取り出して」と頼むやり方です。AnthropicのClaudeを例にすると、画像はJPEG・PNG・GIF・WebPに対応しています。PDFは各ページを画像に変え、ページから取り出した文字と一緒に読む仕組みです。FAXやスキャンで作ったPDFは、多くの場合ページに文字のデータを持っていないので、実際には画像として読むことになります。
強みは、書式を一つずつ定義しなくても、「注文書なら品名と数量はこのあたり」と文脈で探せることです。欄外の「至急」のような手書きのメモや、英語の書類の「Qty」「Quantity」のような項目名のゆれにも対応しやすくなります。取り出した結果は、構造化出力という機能で、決めたJSONの形にそろえて返させられます。ただし、そろうのは形だけです。値が正しいかどうかは、別に確かめる必要があります。
弱みも公式に書かれています。Anthropicの説明では、画質が悪い画像、傾いた画像、200ピクセル未満の小さな画像では、誤ったり、書かれていない内容を作ったりすることがあります。大きすぎる画像は縮小されるため、文字が読みにくくなる場合もあります。そして、完全な正確さが必要な作業には、人の確認なしで使わないよう求めています。FAXの画質は、まさにこの注意に当てはまります。
違いを並べると
| 観点 | 帳票定義型のAI-OCR | 画像を読める生成AI |
|---|---|---|
| 向く書類 | 様式が決まった社内の記録書、定型の申込書 | 得意先ごとに違う注文書、項目名がゆれる輸入書類 |
| 準備するもの | 様式ごとの定義や学習用の見本 | 取り出す項目の表と指示文(プロンプト)、少しの例 |
| 書式が増えたとき | 定義・見本を足す | 指示はそのままで済むことが多い(検証で確かめる) |
| 自信の目安 | 項目ごとの信頼度(0〜1)を返す製品がある | 製品としての信頼度は無い前提で、照合や読み比べで判断する |
両者の境目は薄れてきています。Microsoftも、構造化された書類から確定的に抜き出すドキュメント インテリジェンスと、LLMで複雑な内容を分析する Content Understanding を並べて案内しています。一方を選ぶより、書類の性質に合わせて組み合わせると考えたほうが実務に合います。

組み合わせ方の3つの型
- 書類の種類で振り分ける:社内で様式を決めている記録書は帳票定義型で、得意先ごとに違う注文書は生成AIで読みます。振り分けの前に「どの書類か」を見分ける段を置きます(ドキュメント インテリジェンスには、書類の種類を見分けるカスタム分類子があります)。
- OCRで文字にしてから、生成AIで項目に当てはめる:OCRが返す文字・位置・信頼度は残したまま、「どの文字がどの項目か」の当てはめと表記ゆれの整理を生成AIに任せます。
- 2つの方法で読んで突き合わせる:帳票定義型と生成AIの両方で読み、一致した項目はそのまま通し、食い違った項目だけを人が見ます。読む費用は2倍かかりますが、人が見る範囲を絞れます。
どの型が合うかは、6章のサンプルでの読み比べで決めます。
4. 書式がバラバラ・手書き混じりでも崩れない設計
取り出す項目を先に決める
最初に作るのは、AIへの指示文ではなく項目の表です。基幹に取り込むCSVの列から逆算して、「何を、どの形で、どう確かめるか」を決めます。FAX注文書なら、たとえば次のようになります。
| 項目 | 書類での書かれ方の例 | 確かめ方 |
|---|---|---|
| 得意先 | 社名、送信元のFAX番号 | 得意先マスタ(FAX番号・社名の別の書き方)と照合する |
| 注文日・納期 | 日付、「至急」「◯日着」 | 日付の形に直し、過去の日付や休日を警告する |
| 品名・規格・寸法 | 得意先ごとの呼び方、手書きの寸法 | 品番マスタと、得意先ごとの呼び方の読み替え表で照合する |
| 数量・単位 | 本・枚・kg など | 単位の一覧に無いものは人に回す。いつもの注文より桁が大きすぎる・小さすぎるものを警告する |
| 納品先 | 現場名・住所 | 得意先ごとの納品先一覧と照合する |
| 備考 | 手書きのメモ | 原文のまま残し、「要確認」の印を付ける |
注文書は1枚に明細が何行もあるのが普通なので、項目の表は「見出し(得意先・日付)」と「明細(品名・数量)」に分けて作ります。
読めない所は空欄と理由で返させる
生成AIへの指示には、「読めない・判断できない値は推測で埋めず、空欄にして理由を書く」を必ず入れます。指示が無いと、AIはもっともらしい値で欄を埋めてしまうことがあります。返してもらう形は、たとえば次のようにします。
{
"得意先": "(FAX番号で照合)",
"納期": "2026-11-20",
"明細": [
{"品名": "(読み取った文字のまま)", "数量": 12, "単位": "本", "要確認": false},
{"品名": null, "数量": null, "単位": null, "要確認": true, "理由": "手書きがかすれて読めない"}
]
}
「自信の低さ」を何で決めるか
帳票定義型の製品には、項目ごとに信頼度を返すものがあります。Microsoftの説明では、信頼度は予測が正しい見込みを0から1で表したもので、0.95なら20回に19回は正しい見込み、という意味です。正確さが重要な場面では、この値を使って「自動で受け入れるか、人のレビューに回すか」を決められるとしています。AI Builderでも、Power Automateのフローで項目ごとの信頼度スコアを受け取れます。
生成AIで読む場合は、AIに自分で付けさせた「自信の点数」をそのまま確率として扱わないほうが安全です。カトルセが提案しているのは、次の3つで「要確認」を決める方法です。
- マスタと一致したか:得意先・品番・単位が、マスタや読み替え表に見つかったか。
- 2つの読み方が一致したか:OCRの結果と生成AIの結果、または同じAIに2回読ませた結果が同じか。
- 書類の中で計算が合うか:数量×単価=金額、明細の合計=総額、のような関係が成り立つか。
マスタとの突き合わせは、AIではなくプログラムで
鉄鋼商社の相談にあった「社内の数値コードに置き換える決まり」のように、読み取った後の変換は会社ごとに必ずあります。この照合と変換は、同じ入力に必ず同じ結果を返すプログラムで行います。生成AIの役目は、マスタに見つからなかったときに「近い品番の候補」を出すところまでです。人がその候補から選んだ結果は「得意先ごとの読み替え表」に記録し、次からはプログラムが自動で引けるようにします。使うほど確認が減るのは、AIが賢くなるからではなく、この表が育つからです。
人の確認画面は「原本の横に、怪しい所だけ色」
確認画面では、原本の画像と読み取った値を横に並べ、要確認の項目だけに色を付けます。直した値は「どこを、何から、何に直したか」を記録しておきます。この記録が、後で精度を測るときの正解データになり、読み替え表を育てる材料にもなります。
工場の手書き記録は、まず「様式」を見直す
医薬品メーカーの工場の相談のように、書き手が社内の人で、様式を自社で決められる記録は、FAX注文書とは事情が違います。書き手が社外なら読む側で吸収するしかありませんが、書き手が社内なら書く側を変えられます。記入欄に枠を付ける、選択式のチェック欄を増やす、数字を書く欄を1文字ずつ区切る、といった見直しをすると、帳票定義型のAI-OCRで読みやすくなります。そもそもタブレットなどで直接入力に切り替える選択肢もあります。
また、医薬品の製造記録のように、品質の手順で記録の扱いが決まっている現場では、データ化の前に品質保証の部門と「原本は紙かデータか」「直した記録をどう残すか」を決めておきます。点検や整備のメモを記録様式の下書きにする使い方は、保守・運用の現場でも相談が多い題材です。
お手元の帳票で、どこまで読めるかを確かめる
FAXの注文書や手書きの記録を数枚お預かりし、取り出す項目を決めてから読み取りを試す進め方をご相談いただけます。個人情報を含む書類は、秘密保持契約を結んだうえで、または個人情報を伏せた状態で拝見します。
5. 基幹にAPIが無いときの取り込み方
読み取ったデータは、基幹に入ってはじめて役に立ちます。今週3回目の商談をした検査機関も、9月に伺った住宅設備メーカーも、基幹にAPIが無いことが課題に挙がっていました。APIが無くても、入口は次の順に探せます。
| 方法 | 中身 | 向く場合 | 気をつけること |
|---|---|---|---|
| 1. ファイル取込(CSVなど) | 基幹の画面や夜間の処理にある「ファイルから取り込む」機能を使う | 取込機能があり、列の並びが決まっている | 文字コード・列の順・日付の書き方を合わせる。同じ注文を2回入れないよう受付番号を持たせる |
| 2. RPA(画面操作の代行) | 人が打ち込んでいる画面に、ソフトウェアのロボットが同じ手順で入力する | 取込機能が無く、画面からの入力しか手段が無い | 画面が変わると止まる。入力後の画面で結果を確かめる手順を入れる |
| 3. 作った会社に取込口を作ってもらう | ファイル取込やAPIを基幹に追加してもらう | 保守の契約があり、件数が多く長く使う | 費用と期間がかかる。基幹の作り直しが決まっているなら、その要件に入れる |
| 4. データベースへの直接書き込み | 基幹のデータベースに直接行を足す | 原則として勧めない | 画面から入力したときに動くチェックや連動処理を飛ばしてしまうおそれがある。保守の対象外になる、基幹の更新で壊れる、といったことも起きうる |
どの方法を使う場合も、AIが読んだ結果をすぐ基幹に流さず、一度「取込待ちの表」に貯めて、人が承認したものだけを流す形にします。誰がいつ承認したかが残り、取り込みに失敗したときのやり直しも簡単になります。
RPAでは、たとえばMicrosoftのPower Automate のデスクトップ フローが、ExcelやWebだけでなく、ターミナル エミュレーターのような古いアプリケーションも、画面の部品・画像・座標を手がかりに操作できると説明しています。RPAとAIの役割の分け方は、RPAとAIエージェントの違いと使い分けで詳しく扱っています。
鉄鋼商社の例のように、基幹がFileMakerで作られている場合も、最初に確かめることは同じです。「いまのシステムにCSVなどのファイルを取り込む画面や手順があるか」「取り込みを決まった時刻に自動で動かせるか」を、作った会社か社内の担当に確認します。FileMaker自体の取り込み機能の仕様は、お使いの版に合わせてClarisの公式ヘルプでご確認ください(本記事の執筆時点では公式ヘルプを確認できなかったため、機能の詳しい内容は書いていません)。
基幹を数年のうちに作り直す予定があるなら、いまは取込待ちの表とRPAで小さく回し、新しい基幹の要件に「ファイル取込かAPI」を入れておくのが手戻りの少ない順番です。

6. 精度の測り方と、サンプルでの検証の進め方
精度は「項目ごと」と「確認の手間」で測る
「文字の認識率99%」のような数字は、注文書のデータ化ではあまり当てになりません。1枚の注文書で数量が1桁違えば、ほかの文字が全部合っていても誤発注になるからです。測るのは次の4つです。
- 項目ごとの正解率:得意先・品名・数量・納期など、項目ごとに分けて数えます。
- 1枚まるごと直さずに通った割合:人が1か所も直さなかった書類の割合です。
- 自動で通したものの中の誤り:いちばん怖い数字です。「要確認」にならずにすり抜けた誤りを数えます。
- 人の確認にかかった時間:確認画面で直す時間を、いまの手入力の時間と比べます。
ダイレクトマーケティング・物流の会社の相談にあったように、精度が高くても件数が多ければ目視の確認は残ります。採算は「読み取りの費用」だけでなく、確認の手間まで含めて比べます。
項目ごとに、求める水準を変える
検査機関の相談では、工場名などのローマ字は1文字違っても報告書に使えない一方で、ほかの項目は読み違いを人が直せるなら許容できる、という話でした。このように、項目ごとに「必ず人が原本と見比べる」「マスタと一致すれば通す」を分けて決めると、確認の手間を必要な所に集められます。1文字の誤りが許されない項目は、過去に登録した名前の一覧と照合する方法も使えます。
検証の進め方
- 項目の表と「正解」をそろえる:過去のFAXと、それを人が基幹に入力した結果が残っていれば、それがそのまま正解データになります。
- サンプルを選ぶ:件数の多い得意先から書式ごとに数枚ずつ選び、手書き・かすれ・傾き・2枚にまたがる明細など、読みにくいものも必ず混ぜます。読みやすいものだけで測ると、本番で精度が下がります。
- 2〜3の方法で読む:帳票定義型、生成AI、その組み合わせで同じサンプルを読みます。
- 項目ごとに集計し、外れた理由で分ける:画質・書式・マスタに無い品名など、理由によって打つ手が変わります。
- 進むか止めるかを決める:カトルセの生成AI開発では、検証の段で成り立たないと判断したら、そこで止めて構わない進め方にしています。
FAXを画像やPDFにするときの解像度や圧縮も、読みやすさを左右します。Anthropicも、JPEGを強く圧縮すると文字が読みにくくなることがあるため、実際に送っている画像を確かめるよう注意しています。検証では、本番と同じ受信・保存の設定で作った画像を使います。
7. 情報の扱い:FAXは個人情報のかたまり
FAXの注文書には、得意先の担当者名・電話番号・納品先の住所が入っています。輸入書類には取引先と金額、工場の記録には製造の情報が載っています。AIに読ませる前に、次の3つを決めます。
- 学習に使われない契約のサービスを使う:Anthropicの商用利用規約には、サービスを通じた顧客のコンテンツでモデルを学習させない旨が書かれています。Microsoftも、Foundry で Azure が販売するモデルについて、プロンプトや入力を、許可や指示なしに生成AIの基盤モデルの学習に使わないと説明しています。一方、無償版や個人契約は条件が違うことがあるので、会社として契約したサービスに限ると社内の決まりに書いておきます(決まりの作り方は研修と並行して作るAI利用規程)。
- どこに、何日置くか:原本の画像と読み取った結果をどこに保存し、いつ消すか。確認画面を誰が見られるか。記録(ログ)に本文を残すか。契約だけでは決まらないので、仕組みの設計に入れます。
- 検証用のサンプルをどう扱うか:住宅設備メーカーやダイレクトマーケティングの会社のように、契約前はサンプルを社外に出せない会社は珍しくありません。秘密保持契約を先に結ぶ、個人名や電話番号を伏せたコピーで試す、社内の環境で読む構成にする、のいずれかで進めます。社外に出さない構成の考え方はローカルLLMのオンプレ構成と費用にまとめています。
8. 小さく始める順番
カトルセが商談で提案している始め方は次のとおりです。最初から全部の書類を自動にしようとせず、確認画面を中心に回しながら、確認を省ける範囲を少しずつ広げます。
- 1つの書類・1つの流れに絞り、件数の多い得意先の書式から始める:たとえば「FAX注文書の受注入力」だけにします。
- 最初は半自動にする:AIが下書きを作り、人が確認して、ファイル取込かRPAで基幹に入れます。
- 直した記録を貯め、確認を省く範囲を広げる:誤りが出ていない項目・得意先から、人の確認を減らします。
仕組みを作る前に、いま使えるAIで感触をつかむこともできます。個人情報を伏せたFAXを1枚、会社として契約した画像を読めるAIのチャットに入れて、次のように頼みます。
この注文書の画像から、得意先・注文日・納期・品名・規格・数量・単位・納品先・備考を、明細ごとに1行の表にしてください。
読めない文字や判断できない値は推測で埋めず、空欄にして「理由」の列に理由を書いてください。
手書きの部分は、読み取った文字をそのまま書いてください。
1枚では精度は分かりませんが、項目の表の作り方と、どこで外れやすいかの感触はつかめます。
紙・PDFの書類をデータにする仕組みの例を見る
PDFの見積書をAI-OCRで読み取ってExcel形式のデータに変える仕組みなど、業務に合わせて作ったAIの開発事例を、課題と仕組みの説明つきで公開しています。
9. カトルセが手伝える範囲
カトルセがお手伝いできるのは、次の3つです。
- 仕組みづくり:PDFの見積書をAI-OCRで読み取ってExcel形式に変える仕組み(PDF見積のExcel化)や、図面から記号を見つけて数量を集計する仕組み(建具数量の拾い出し)を開発しています。生成AI開発として、要件の整理と検証だけを切り出してご依頼いただくこともできます。
- 研修:経理・財務向けの生成AI×経理財務実務研修では請求書のデータ抽出と突合の下ごしらえを、保守・運用向けの生成AI×保守運用実務研修では点検メモ・音声・写真から記録様式の下書きを作る使い方を扱います(基幹への取り込みの仕組みを作る研修ではありません)。職種別AI研修シリーズ(全10講座・各11時間)。受講料は全講座共通で1名あたり36万円(税抜)。ライブ形式(対面/オンライン同時双方向)のため人材開発支援助成金の活用をご検討いただけます。支給の可否は都道府県労働局の審査で決まります。申請手続きは社会保険労務士の独占業務のため、必要な場合は提携社労士をご紹介します。
- 進め方の伴走:対象の書類の絞り方、正解データのそろえ方、基幹の取り込み口の探し方を、AI顧問として一緒に進めます。
よくある質問
FAXの注文書は、AIのチャットに画像を入れるだけでデータ化できますか?
1枚ずつ項目を書き出させる下書きには使えます。ただ、毎日の業務で使うには、取り出す項目の表、読めない所を空欄で返させる指示、得意先・品番マスタとの照合、人の確認画面、基幹への取り込み口が必要です。AIに画像を入れるのは「読む」段だけで、「確かめる」「入れる」段は別に作ります。
手書きの文字も読めますか?
読めます。日本語の手書きに対応したAI-OCRがあり、画像を読める生成AIも手書きを読めます。ただ、崩し字・かすれ・FAXの画質の悪さで外れやすくなるため、自社の書類のサンプルで項目ごとの正解率を測り、自信の低い所を人が確かめる前提にします。
AI-OCRと生成AIは、どちらを選べばよいですか?
様式が決まっている書類は帳票定義型のAI-OCR、得意先ごとに書式が違う書類は生成AIが向いています。迷う場合は、同じサンプルを両方で読み、項目ごとの正解率と人の確認時間で比べます。両方で読んで、食い違った所だけを人が見る組み合わせもあります。
基幹システムにAPIがありません。それでも自動で取り込めますか?
多くの場合は取り込めます。まず基幹にCSVなどのファイルを取り込む機能があるかを確かめ、無ければ人の画面入力を代わりに行うRPAを使います。どちらの場合も、AIが読んだ結果を一度取込待ちの表に貯め、人が承認したものだけを流します。データベースへの直接書き込みは、作った会社の合意が無い限りお勧めしません。
検証のためにFAXのサンプルを社外に出せません。どう進めればよいですか?
秘密保持契約を先に結ぶ、個人名や電話番号を伏せたコピーで試す、社内の環境で読む構成にする、のいずれかで進めます。過去のFAXと、それを人が基幹に入力した結果が残っていれば、それが正解データになります。
まとめ ── 読むのはAI、確かめるのはマスタと人、入れるのは取り込み口
- 「読む・確かめる・入れる」の3段に分けます。AIは読む段だけを受け持ち、推測した値は候補にとどめます。
- 様式が決まった書類は帳票定義型、バラバラな書類は生成AI。迷ったら両方で読み比べ、食い違いだけを人が見ます。
- 項目の表を先に決め、読めない所は空欄で返させます。照合と変換はプログラムで行い、直した記録で読み替え表を育てます。
- APIが無ければ、ファイル取込 → RPA → 取込口の追加の順に探します。取込待ちの表を挟み、データベースへの直接書き込みは避けます。
- 精度は項目ごとと確認の手間で測ります。サンプルには読みにくいものを混ぜ、過去の入力結果を正解データに使います。
自社のどの書類から始めればよいか、いまのAI活用の段階を知りたい方は、まず生成AI活用レベル診断(無料)をお試しください。具体的なご相談はお問い合わせからどうぞ。
参考
- Microsoft「Azure ドキュメント インテリジェンスとは」(Microsoft Learn)
- Microsoft「ドキュメント インテリジェンスの言語サポート(OCR・手書き)」(Microsoft Learn)
- Microsoft「カスタム モデル」(Microsoft Learn)
- Microsoft「正確性スコアと信頼度スコアの解釈と改善」(Microsoft Learn)
- Microsoft「ドキュメント処理モデルを作成する」(AI Builder)
- Microsoft「Power Automate でドキュメント処理モデルを使用する」(AI Builder)
- Microsoft「デスクトップ フローの概要」(Power Automate)
- Microsoft「Foundry モデルのデータ、プライバシー、セキュリティ」(Microsoft Learn)
- Anthropic「Vision」(Claude Platform Docs)
- Anthropic「PDF support」(Claude Platform Docs)
- Anthropic「Structured outputs」(Claude Platform Docs)
- Anthropic「Commercial Terms of Service」(2025年6月17日発効)
※ 本記事は2026年11月7日時点の情報にもとづいています。Microsoftの製品の説明は上の「参考」のMicrosoft Learnの各ページ(2025年5月〜2026年9月更新の版)で、Claudeの画像・PDF・構造化出力・利用規約の説明はAnthropicの公式ドキュメントと規約で、いずれも2026年11月7日に確認しました。Google Cloud の Document AI と Claris FileMaker の公式ヘルプは、執筆環境から開けなかったため、機能・価格を記載していません。特定のAI-OCR製品の比較・価格と、開発の費用は記載していません。商談で伺った声は、企業が特定されないよう業種と規模だけにしています。紹介した進め方はカトルセが商談で提案している内容で、導入の実績や効果を示すものではありません。本記事に登場する製品名・サービス名は、それぞれの提供元の商標または登録商標です。
