展示会で集めた手書きアンケートを読み取って集計表と対応リストにする
展示会やセミナーで回収した紙のアンケートをスキャンし、記入内容をデータにします。読み取るのは、チェックボックスなどの選択式の回答、氏名・会社名・連絡先といった記入欄、そして自由記述欄です。
- 利用ツール
- AWS Textract/Azure AI/ChatGPT/Claude/Gemini/Google Document AI/n8n/Power Automate/Zapier
- 対象業界
- IT・SaaS/不動産/教育/製造
- 対象部門
- マーケティング
- 対象業務
- データ入力・転記/集計・分析
- 主な課題
- 入力作業が多い/営業フォローが追いつかない/確認ミスが多い
- AIで行う処理
- 読み取り(OCR)
- 主な効果
- 入力漏れ削減/対応スピード向上/工数削減/機会損失防止
- 導入難易度
- ★★☆☆☆
- 実装レベル
- 半自動化
- 費用感
- SaaS追加(小)
- 人間の確認
- 必須
01導入前 / 導入後の業務フロー
- 展示会の会場でアンケート用紙を回収し、封筒に入れて持ち帰る
- 帰社後、複合機でスキャンしてPDFにする(保管用)
- マーケティング担当が用紙の束を1枚ずつ見て、Excelに打ち込む
- 会社名の表記ゆれを、既存の顧客リストと突き合わせて直す
- 選択式の回答を集計し、展示会報告のグラフを作る
- 自由記述を読み、営業に渡すべき相手を選ぶ
- 選んだ相手のリストを営業へ渡す
- 用紙を保管箱に入れる
- 会場から持ち帰った用紙を複合機でまとめてスキャンし、指定のフォルダへ保存する
- 自動1つのPDFを1枚ずつのページに分割する
- 自動OCRで選択マーク(チェックボックス)と手書き文字を読み取る
- 自動読み取り結果を、アンケートの設問と回答の形に組み直す
- 自動会社名を既存の顧客リストと照合し、候補を付ける
- 自動自由記述と選択結果から、連絡の優先度を判定する
- 人マーケティング担当が確認画面で用紙の画像と読み取り結果を並べて見て、直す
- 自動承認された内容を集計表と対応リストに書き出し、営業へ通知する
各工程の詳しい説明を読む
- 展示会の会場でアンケート用紙を回収し、封筒に入れて持ち帰る
- 帰社後、複合機でスキャンしてPDFにする(保管用)
- マーケティング担当が用紙の束を1枚ずつ見て、Excelに打ち込む
- 会社名の表記ゆれを、既存の顧客リストと突き合わせて直す
- 選択式の回答を集計し、展示会報告のグラフを作る
- 自由記述を読み、営業に渡すべき相手を選ぶ
- 選んだ相手のリストを営業へ渡す
- 用紙を保管箱に入れる
問題は4つあります。
(a)読めない文字がある。 手書きのメールアドレスは、l と 1、0 と O、— とハイフンの区別がつかないことがあります。読めないまま送ると不達になり、フォローの機会そのものが消えます。
(b)展示会の翌週が入力で埋まる。 300枚を2名で入力すると、6分×300枚=30時間かかります。実質、展示会の翌週は入力作業でふさがります。
(c)営業への引き渡しが遅れる。 入力が終わるまで営業に渡せないため、来場から連絡までに5〜7日かかります。その間に他社が接触しています。
(d)自由記述が読まれないまま埋もれる。 集計に使うのは選択式の回答が中心で、自由記述は担当者が目視で拾える範囲しか活用されていません。
- 会場から持ち帰った用紙を複合機でまとめてスキャンし、指定のフォルダへ保存する
- 【自動】 1つのPDFを1枚ずつのページに分割する
- 【自動】 OCRで選択マーク(チェックボックス)と手書き文字を読み取る
- 【自動】 読み取り結果を、アンケートの設問と回答の形に組み直す
- 【自動】 会社名を既存の顧客リストと照合し、候補を付ける
- 【自動】 自由記述と選択結果から、連絡の優先度を判定する
- 【人】 マーケティング担当が確認画面で用紙の画像と読み取り結果を並べて見て、直す
- 【自動】 承認された内容を集計表と対応リストに書き出し、営業へ通知する
自動化されるのは「読む」「打ち込む」「照合する」「優先度を判断する材料をそろえる」の4つです。残るのは「読み取りが合っているかを確かめる」ことです。
連絡先の確認だけは省けません。 メールアドレスが1文字違えば届きません。この構成で減らしているのは打ち込む時間であって、確認の責任ではありません。
02今回想定するシステム構成
展示会会場でアンケートを回収 │ ▼ 複合機で一括スキャン(300枚を1つのPDFに) SharePoint の「アンケート受領」フォルダ │ ▼【トリガー】ファイルの作成時(プロパティのみ) Power Automate │ ├──▶ PDFを1ページずつに分割 │ ├──▶ OCR(prebuilt-layout) │ ├─ 選択マーク(チェック済み/未チェック) │ ├─ 手書き文字(confidence 付き) │ └─ キーと値の組(features=keyValuePairs) │ ├──▶ 生成AI ── 設問と回答の対応づけ/自由記述の要約/優先度の判定 │ └──▶ 顧客リストとの会社名照合 │ ▼ 確認画面(用紙の画像と読み取り結果を左右に並べる)──【人が承認】 │ ├──▶ 集計表(SharePoint リスト) └──▶ 対応リスト ──▶ 営業へ通知
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| OCR | Azure AI Document Intelligence(prebuilt-layout) | Google Document AI、AWS Textract |
| ワークフロー | Power Automate | n8n、Zapier |
| 生成AI | Claude API | OpenAI API、Gemini API |
| 保管 | SharePoint | Box、Google ドライブ |
| 集計・出力 | SharePoint リスト | Excel、スプレッドシート |
紙をやめられるなら、そちらが先です。 会場でタブレットに入力してもらう、QRコードから自社のフォームに回答してもらう、といった方法が取れるなら、読み取りの精度問題そのものが消えます。この構成が意味を持つのは、来場者に紙で書いてもらうほうが回収率が高いという判断がある場合です。展示会では、立ち止まった数十秒で書いてもらう必要があるため、紙が有利な場面が実際にあります。
03どうやって実装するのか
処理の起点を決める
SharePoint のアンケート受領フォルダにファイルが作成されたことを起点にします。
Power Automate の SharePoint コネクタでは、「フォルダーにファイルが作成されたとき」トリガーは非推奨になっています。代わりに使うのは「ファイルの作成時 (プロパティのみ)」です。特定のフォルダーだけを対象にしたい場合は、「ファイルが作成または変更されたとき (プロパティのみ)」の Folder プロパティに対象フォルダーを指定します。値を指定しないとライブラリ全体が対象になります。
注意すべき挙動が2つあります。
1つは、ファイルの移動ではトリガーが動かないことです。ドキュメントライブラリ間でファイルを移動しても、作成日時などのメタデータが変わらないため、移動先のフローは起動しません。「いったん別のフォルダにスキャンしてから移す」という運用にすると、動かない構成になります。スキャンの保存先を直接、監視対象のフォルダにしてください。
もう1つは、実行のタイミングです。 Power Automate は対象のライブラリを定期的に確認する方式のため、多くの場合は数分以内に起動しますが、変更が続いたときには複数の変更をまとめて拾うことがあります。1枚ごとに即時処理される前提の設計にはしないでください。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| スキャンしたアンケート | 1枚1ページ。300dpi以上のPDFまたは画像 | 複合機 → SharePoint |
| アンケート様式の定義 | 設問文、選択肢、記入欄の名称と並び順 | マーケティングが管理する定義ファイル |
| 顧客リスト | 会社名、正式名称、略称、既存取引の有無、担当営業 | 社内の顧客管理台帳 |
| イベント情報 | 開催日、会場、ブース担当者 | イベント管理表 |
アンケート様式の定義を持つことが重要です。 「設問3は導入時期で、選択肢は4つ」という情報を持っていれば、読み取った選択マークの位置から回答を組み立てられます。定義がないと、チェックが入った位置は分かっても、それが何の回答なのかが分かりません。
データの取得方法を決める
OCR: Azure AI Document Intelligence の prebuilt-layout モデルに画像またはPDFを渡します。Layout モデルは、テキスト、表、文書構造に加えて、ラジオボタンやチェックボックスなどの選択マークを抽出します。アンケート用紙では、この選択マークの抽出が読み取りの中心になります。
手書き文字については、日本語が手書き対応の言語に含まれています(v4.0 の対応は英語・中国語簡体字・フランス語・ドイツ語・イタリア語・タイ語・日本語・韓国語・ポルトガル語・スペイン語・ロシア語・アラビア語)。読み取り結果には、行ごとに手書きかどうかの判定(isHandwritten)と信頼度、単語ごとの confidence が付きます。この信頼度が、後段で人の確認に回すかどうかの判断材料になります。
キーと値の組を取りたい場合は、Layout モデルにクエリ文字列 features=keyValuePairs を指定します。「会社名:」の後ろに書かれた文字列を、キーと値の組として取得できます。
入力の条件は次のとおりです。
| 項目 | 条件 |
|---|---|
| 対応形式 | PDF、JPEG/JPG、PNG、BMP、TIFF、HEIF |
| ファイルサイズ | 有料(S0)で500MB、無料(F0)で4MB |
| ページ数 | PDF・TIFFで最大2,000ページ(無料枠は先頭2ページのみ) |
| 画像サイズ | 縦横それぞれ50ピクセル以上、10,000ピクセル以下 |
| 文字の高さ | 1024×768ピクセルの画像で最低12ピクセル(150dpiで約8ポイントに相当) |
無料枠は先頭2ページしか処理されません。 300枚を1つのPDFにまとめて無料枠で試すと、2枚しか読まれずに「動いた」と誤解します。検証は必ず有料枠で行ってください。
顧客リスト: 社内の台帳から日次でエクスポートしたファイルを参照します。リアルタイム連携は不要です。
AIへ渡す前に整形する
- PDFの分割 … 複合機で300枚をまとめてスキャンすると1つのPDFになります。1枚=1回答なので、ページ単位に分割します。分割しないと、300人分の回答が1件として扱われます
- 向きの補正 … 用紙が上下逆や横向きに入ることがあります。OCR側で角度が返るため、それを見て回転させます
- 白紙・重複の除外 … 記入のない用紙、二重にスキャンされた用紙を取り除きます。全項目が空、または直前のページと内容が一致するものを検出します
- アンケート以外の除外 … 名刺、パンフレット、メモが混ざります。用紙の様式(決まった位置にある見出し)を検出して振り分けます
- 解像度の確認 … 150dpi未満のスキャンは文字の高さが足りず、読み取り精度が落ちます。複合機のスキャン設定を300dpiに固定してください
AIに処理させる
OCRと生成AIで役割を分けます。
OCR にさせること: 選択マークがチェックされているかの判定、手書き文字の読み取り、キーと値の組の抽出。ここは生成AIにさせません。専用モデルのほうが精度が高く、費用も安いためです。
生成AI にさせること:
| 処理 | 内容 |
|---|---|
| 設問と回答の対応づけ | 読み取った選択マークの位置を、様式定義の設問・選択肢に対応づける |
| 会社名の名寄せ | 「(株)◯◯製作所」「株式会社◯◯製作所」「マルマル製作所」を顧客リストの1社に対応づける |
| 自由記述の整理 | 記述内容を「困っていること」「検討中の用途」「その他」に分けて要約する |
| 連絡優先度の判定 | 導入時期・予算の有無・自由記述の具体性から、優先度を3段階で付ける |
| 記入内容の不整合の指摘 | 「導入時期:未定」なのに「今月中に見積が欲しい」と書かれている等を指摘する |
メールアドレスの補正は、生成AIにさせません。 「たぶん gmail.com だろう」という補完は、一見もっともらしく、実際には届かないアドレスを作ります。読み取れなかった文字はそのまま欠けた状態で返させ、人に回します。
指示内容を固定する
あなたは展示会アンケートの入力を担当する事務担当者です。
OCRの読み取り結果と、アンケート様式の定義をもとに、
回答データを組み立ててください。
【厳守事項】
- 読み取れなかった文字を推測で埋めないでください。
該当箇所は null にし、unreadable_fields にその項目名を入れてください。
- メールアドレス・電話番号は、OCRの読み取り結果をそのまま使ってください。
ドメイン名の補完、桁数の補正、ハイフンの追加をしないでください。
- 選択マークの判定は、OCRが「選択済み」と返した項目だけを採用してください。
自由記述の内容から選択肢を推測して埋めないでください。
- 会社名が顧客リストに一致しない場合、新しい会社を作らず
company_id を null にし、reason に理由を書いてください。
- 連絡優先度は、選択式の回答(導入時期・予算)を主に判断してください。
自由記述の熱量だけで「高」を付けないでください。
- 判断に迷った項目は needs_review に列挙してください。
【アンケート様式の定義】
{form_definition}
【OCRの読み取り結果】
{ocr_result}
【顧客リストの候補(社名の近い上位5件)】
{company_candidates}
「自由記述から選択肢を推測しない」の1行が重要です。 自由記述に「来期の予算で検討したい」と書かれていると、選択式の「導入時期」欄が空でも「6か月以内」と埋めたくなります。これをやると、集計値が実際の回答と食い違い、展示会報告の数字が信用できなくなります。
出力形式を固定する
{
"sheet_id": "",
"event_id": "",
"company_name_raw": "",
"company_id": null,
"department": "",
"person_name": "",
"email": "",
"phone": "",
"answers": [
{ "question_id": "q1", "selected": [], "confidence": "high | medium | low" }
],
"free_text": {
"issue": "",
"use_case": "",
"other": ""
},
"priority": "high | medium | low",
"priority_reason": "",
"unreadable_fields": [],
"inconsistencies": [],
"needs_review": [],
"reason": ""
}
answers の selected を配列にしているのは、複数選択の設問があるためです。単一選択の設問で2つ以上入っている場合は、用紙に丸が2つ付いている可能性が高く、人の確認に回します。
構造化出力(JSONスキーマの指定)を使うと、この形から外れた応答が返らなくなります。後段で集計表に流し込む処理を書くうえで、項目が欠けないことは重要です。
システムへ連携する
承認後、2つの出力先に書き込みます。
| 出力先 | 内容 | 用途 |
|---|---|---|
| 集計表(SharePoint リスト) | 全回答の選択式データと自由記述 | 展示会報告、傾向分析 |
| 対応リスト | 優先度「高」「中」の回答+連絡先+自由記述の要約 | 営業のフォロー |
対応リストは、イベント終了の翌営業日に営業へ渡せる状態を目標にします。現在の5〜7日を1日にすることが、この構成のいちばん大きな効果です。
営業支援システムやマーケティング自動化ツールへの取り込みは、製品ごとにCSV形式やAPIが異なります。この部分は利用環境に応じた個別確認が必要です。
人が確認する
連絡先を含む項目は全件、人が確認します。
理由は、メールアドレスと電話番号が1文字違うだけで連絡が届かず、その来場者への接触機会が完全に失われるためです。読み取り精度がどれだけ上がっても、この確認は残します。
一方で、選択式の回答は全件確認しなくても運用できます。 集計は母数が大きいため、1件の誤りが結論を変えることは稀です。OCRの信頼度が低い項目だけを人に回す設計にできます。
確認を速くするための設計が重要です。
- 確認画面で、用紙の画像と読み取り結果を左右に並べて表示する
- 読み取った箇所を、画像上でハイライトする
confidenceが低い項目、unreadable_fieldsに入った項目を色分けする- 連絡先の欄を画面の最上部に固定する(確認の順序を決めてしまう)
- キーボードだけで次の1枚に進めるようにする
確認画面の作りが、この構成の成否を決めます。 用紙を手元に置いて画面と見比べる運用にすると、1枚あたり3分以上かかり、削減効果が出ません。
例外に対処する
| 起きること | 対応 |
|---|---|
| 手書き文字が読めない | 該当項目を null で返し、unreadable_fields に入れる。推測値を入れない |
| メールアドレスの一部が判読できない | 全項目を人に回す。ドメインの補完を自動で行わない |
| 選択肢に丸が2つ付いている | 単一選択の設問なら needs_review に入れて人に回す |
| どこにも丸が付いていない | 未回答として扱う。自由記述から推測しない |
| 会社名が顧客リストにない(新規) | company_id を null にして人に回す。自動で台帳に追加しない |
| 同名の会社が複数ある | 候補を並べて人に選ばせる |
| 用紙が斜めにスキャンされている | 角度の情報をもとに補正する。補正しても読めなければ再スキャンに回す |
| 白紙・二重スキャンが混ざる | 全項目が空、または直前ページと同一の内容を検出して除外する |
| 名刺やパンフレットが混ざる | 様式の見出しを検出して振り分け、別フォルダへ移す |
| 300枚が一度に投入されて処理が滞る | キューに入れて順次実行し、同時実行数の上限を設定する |
| 展示会月だけ処理量が5倍になる | 従量課金の上限額を設定し、想定外の請求を防ぐ |
| 自由記述が用紙の裏面に続いている | 両面スキャンを前提にし、表裏を1件として結合する |
記録を残す
- スキャンした用紙の画像(原本)
- OCRの読み取り結果(生の状態、
confidenceを含む) - 生成AIが組み立てた回答データ
- 人が修正した項目と、修正前後の値
- 確認者、確認日時
- 営業へ引き渡した日時と、その後の接触結果
最後から2番目の項目が、精度の実測値になります。「選択式はほぼそのまま通るが、メールアドレスは2割修正されている」と分かれば、どこに手を入れるべきかが決まります。
原本の保管期間は、個人情報の保管方針に合わせて決めてください。「念のため残す」で無期限に保管すると、漏えい時の影響範囲が広がります。
04実装レベルの3段階
半自動化の時点で、6分が2分程度になります。 打ち込みが消えるためです。本格構成にすると1.8分程度になりますが、外部システムとの連携を作り込む必要があります。 多くの企業では、半自動化で止めるのが妥当です。 営業支援システムへの自動登録は、連携先の仕様に依存する部分が大きく、費用対効果が読みにくくなります。CSVで書き出して取り込む運用でも、5〜7日が1日になるという効果は変わりません。
05工数削減シミュレーション
導入後 500件 × 1.8分 ÷ 60 = 15 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 展示会・セミナー・内覧会などで紙のアンケートを月200枚以上回収している企業。回収から営業への引き渡しまでに数日以上かかっていて、その間に問い合わせ対応が遅れている状態。アンケート用紙の様式が自社で決められること。
- 月に数十枚しか回収しない場合(手入力のほうが速い)。すでにタブレットやQRコードでの電子回答に切り替えられる場合は、そちらのほうが確実で費用も安い。氏名・連絡先を含む用紙を外部サービスに送ることが規程上できない場合。
07最小構成で試す方法
- 直近の展示会のアンケート用紙を30枚用意する(字の綺麗さがばらつくように選ぶ)
- 300dpiでスキャンし、1枚ずつのファイルにする
- Document Intelligence Studio(画面上でファイルをアップロードして結果を見られる)の Layout モデルに投入する
- 選択マークが正しく「選択済み」と判定されているかを見る
- 会社名・氏名・メールアドレスが正しく読めた枚数を数える
手順4を先に見てください。 選択マークが読めなければ、この構成は成立しません。文字の読み取り精度より先に確認すべき点です。
判断の目安は次のとおりです。
| 状態 | 判断 |
|---|---|
| 選択マークが9割以上正しい | 集計の自動化は成立する |
| 選択マークが7〜9割 | チェック欄の枠を大きくする、記入例を用紙に載せるなど、様式側の改善で上がる |
| 選択マークが7割未満 | 用紙の様式を見直す。チェック欄が小さすぎるか、丸で囲む形式になっている可能性がある |
| メールアドレスが8割以上正しい | 確認工程を付ければ実用になる |
| メールアドレスが5割未満 | 記入欄をマス目(1文字1マス)にする。手書きのアドレス欄は、様式の改善効果がもっとも大きい部分です |
この検証だけは必ずやってください。 手書きの読み取り精度は、書き手の字と用紙の様式に強く依存します。他社の事例や製品の紹介値ではなく、自社の用紙で測らないと導入後の工数が読めません。
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| 300枚を1つのPDFのまま処理して1件になる | 前処理でページ単位に分割する。最初に必ず確認する点 |
| 無料枠で試して先頭2ページしか読まれない | 検証は有料枠で行う。無料(F0)はPDFの先頭2ページのみ処理される |
| スキャンの解像度が低くて読めない | 複合機の設定を300dpiに固定する。1024×768で文字の高さ12ピクセルが下限の目安 |
| ファイル移動でフローが起動しない | スキャンの保存先を監視対象フォルダに直接指定する。移動ではメタデータが変わらずトリガーされない |
| 非推奨のトリガーを選んでしまう | 「フォルダーにファイルが作成されたとき」は非推奨。「ファイルの作成時 (プロパティのみ)」を使う |
| チェック欄が読めない | 用紙の様式を見直す。丸で囲む形式より、四角のチェックボックスのほうが判定しやすい |
| 手書きメールアドレスの精度が上がらない | 記入欄をマス目(1文字1マス)にする。用紙側の改善が最も効く |
| 読めなかった箇所が推測で埋まる | プロンプトで補完を明示的に禁じ、unreadable_fields に返させる |
| 自由記述から選択肢が推測されて集計が狂う | 選択マークの読み取り結果だけを採用させる |
| 会社名の表記ゆれで照合できない | 略称・旧社名を含む名寄せ辞書を作る。顧客台帳の検索用カナを使う |
| 展示会月に処理が集中してAPIの制限に当たる | キューに入れて同時実行数を制限する。従量課金の上限額も設定する |
| 確認画面が使いにくく確認に時間がかかる | 用紙の画像と結果を左右に並べる。連絡先を最上部に固定する。ここを省くと削減効果が出ない |
| 両面記入の裏面が別件として登録される | 両面スキャンを前提にし、表裏を1件として結合する処理を入れる |
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 来場者の氏名、会社名、部署、メールアドレス、電話番号、検討中の課題。個人情報にあたります。
- 取得時の利用目的の明示 … アンケート用紙に、取得した情報の利用目的を記載してください。「営業担当からご連絡する場合があります」といった記載が用紙にないまま連絡すると、問題になります
- 外部サービスへの送信可否 … 氏名と連絡先を含む画像を外部のOCRサービスに送ることになります。自社のプライバシーポリシーと個人情報の取扱規程で、外部委託が想定されているかを確認してください
- 保管場所とリージョン … OCRサービスを利用する地域(リージョン)を確認します。国外のリージョンを使う場合、外国にある第三者への提供にあたるかどうかの検討が必要です
- 学習利用 … 入力を学習に使わないことが契約で保証されるサービスを選びます
- アクセス権限 … スキャン画像の保管場所を、マーケティングと担当営業に限定します。全社共有のフォルダに置かないでください
- 原本の保管期間 … 紙とスキャン画像の保管期間を決め、期限が来たら削除します。「念のため残す」を続けると、漏えい時の影響が広がります
- 自動実行してよい範囲 … 連絡先の確認は必ず人が行います。運用が安定しても変えません。特に、確認を経ずにメールを自動送信する構成にしないでください。誤ったアドレスへの送信は、無関係な第三者への情報流出になります
誤りが起きた場合のリスクは、来場者への連絡の不達(機会の損失)と、誤ったアドレスへの送信(情報の流出)です。後者のほうが重大です。
10まず何から始めるか
1週目:30枚で読み取り精度を測る
直近の展示会のアンケート30枚を300dpiでスキャンし、OCRサービスの画面から読み取り精度を測ります。選択マークの判定を先に見てください。ここが読めないなら、この構成は成立しません。
2週目:用紙の様式を見直す
読み取り結果を見ながら、用紙の様式を直します。メールアドレス欄をマス目にする、チェック欄を大きくする、この2つで精度が大きく変わります。次の展示会から新しい様式を使います。システムを組むより先に、ここに手を入れるほうが効果が大きい場合があります。
3〜4週目:半自動化を作る
フォルダ監視 → 分割 → OCR → リストへの出力までを作り、次のセミナー(100枚程度)で試します。1枚あたりの時間を実測します。営業支援システムへの連携はまだ作りません。
2か月目以降: 削減効果が確認できたら、確認画面を作り込みます。並行して、イベント終了から営業への引き渡しまでの日数を記録してください。この日数の短縮が、工数削減より大きな効果を生む可能性があります。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
Document Intelligence の Layout モデルが、テキスト・表・文書構造に加えてラジオボタンやチェックボックスなどの選択マークを抽出すること。features=keyValuePairs の指定でキーと値の組を取得できること | Microsoft Learn: Language support(OCR) | 2026-09-10 |
| v4.0 の手書き対応言語に日本語が含まれること(英語・中国語簡体字・フランス語・ドイツ語・イタリア語・タイ語・日本語・韓国語・ポルトガル語・スペイン語・ロシア語・アラビア語) | Microsoft Learn: Language support(OCR) | 2026-09-10 |
Read/Layout が単語ごとの confidence と、行ごとの手書き判定(isHandwritten)と信頼度を返すこと。対応形式・ファイルサイズ(S0で500MB/F0で4MB)・ページ数(PDFとTIFFで最大2,000ページ、無料枠は先頭2ページのみ)・画像サイズ(50〜10,000ピクセル)・文字の高さ(1024×768で12ピクセル、150dpiで約8ポイント相当)の条件 | Microsoft Learn: Read model | 2026-09-10 |
| Power Automate の SharePoint コネクタで「フォルダーにファイルが作成されたとき」が非推奨であり、代替が「ファイルの作成時 (プロパティのみ)」であること。ファイルの移動ではメタデータが変わらずフローがトリガーされないこと。変更の確認が定期実行のため複数の変更をまとめて拾う場合があること | Microsoft Learn: SharePoint コネクタ | 2026-09-10 |
| 生成AIの構造化出力により、指定したJSONスキーマから外れない応答を得られること | Anthropic: Structured outputs | 2026-09-10 |
営業支援システムやマーケティング自動化ツールへの取り込み方式(API/CSV)は製品によって異なります。この部分は利用環境に応じた個別確認が必要です。 個人情報の取扱いについては、自社のプライバシーポリシーと規程に照らして確認してください。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-0028)についてのご相談はこちらから。
