OCR・Document AIで文字が読めても、請求書を会計システムへ安全に登録できるとは限りません。取引先、請求番号、支払期日、税額、明細行を正しい項目へ対応させ、重複や金額矛盾を止め、人が原本へ戻れることまでが実装です。本稿では月1万件の請求書を扱う架空の想定条件を使い、PDF・画像の受付から登録前確認までを設計します。読後の行動は、対象帳票を一種類に絞った並行運用へ進めるかを判断することです。
OCR・Document AIの対象帳票を一種類の請求書に固定する
最初の対象は、国内の継続取引先から届く標準請求書だけにします。月1万件、平均5ページ、12種類の主要レイアウトがあるという想定です。手書き伝票、海外税制、契約書、納品書、領収書、本人確認書類は同じ処理へ混ぜません。
OCRは文字と位置を取り出す層、Document AIの抽出器は文字を請求番号や合計金額へ対応させる層、生成AIは摘要の候補整理など限定した補助層と定義します。生成AIに数値の穴埋めをさせず、原本にない値は欠損として扱います。
完成状態は「自動登録」ではなく、「根拠を確認できる登録待ちデータ」です。原本ファイル、ファイルハッシュ、抽出前の文字列、正規化後の値、ページ座標、モデル版、業務ルールの結果、修正者、承認時刻を一つの処理IDへ結び付けます。会計システムへ送る直前に、支払先コードと合計金額を再照合し、登録後には会計側の伝票番号を受け取ります。
応答がない場合は成功と見なさず、再送による二重計上を防ぐ保留状態へ移します。
| 処理層 | 入力 | 出力 | 判断してはいけないこと |
|---|---|---|---|
| 受付 | メール添付、アップロード、連携ストレージ | 処理ID、原本、MIME型、ハッシュ | 拡張子だけでファイル種別を確定しない |
| OCR | PDFまたは画像 | 文字、座標、ページ、信頼度 | 請求書の意味や仕訳先を推測しない |
| 項目抽出 | OCR結果とレイアウト | 請求番号、日付、金額、明細候補 | 欠けた重要値をもっともらしく補完しない |
| 業務検証 | 抽出値、取引先マスター、計算規則 | 合格、要確認、受付拒否 | ルール矛盾を平均信頼度で相殺しない |
| 登録 | 承認済みデータと一意キー | 伝票番号または明示的な失敗 | 結果不明の要求を無条件に再送しない |
OCRの正答は文字列の一致です。業務の正答は、正しい取引先へ正しい金額を一度だけ登録し、原本と承認者を後から示せることです。
PDF・TIFF・PNG・JPEGの入力形式と受付拒否条件を決める
Google Cloud Document AI「Supported Files」は、PDF、GIF、TIFF、JPEG、PNG、BMP、WebPなどの対応画像形式を示し、HTMLや一部のOffice形式は利用できる処理器が限られると説明しています。また、読み取り精度を得る目安として最低200dpi、一般には300dpi以上を推奨しています[1]。本稿の実装では選択肢を狭め、PDF、TIFF、PNG、JPEGだけを受け付けます。可逆圧縮のPNGまたはTIFFを優先し、JPEGは再圧縮を重ねた画像を受付段階で警告します。
Google Cloud Document AI「Limits」は、オンライン処理を1ファイル40MB、バッチ処理を1GB、画像を1ページ40メガピクセルとし、Enterprise Document OCRのページ数を通常のオンライン処理15ページ、バッチ処理500ページと掲載しています[2]。これはサービス上限であり、業務上の受付基準ではありません。
想定システムではオンラインを10ページ・20MBまでに抑え、それを超える請求書は夜間バッチへ分けます。暗号化PDF、壊れたページ、天地が混在する画像は自動変換せず、依頼者へ理由付きで返します。
| 検査項目 | 本記事の受付条件 | 条件外の処理 |
|---|---|---|
| 実体形式 | MIME型とファイル署名がPDF、TIFF、PNG、JPEGのいずれか | 拡張子を書き換えず、送信者へ再提出を依頼 |
| ページ・容量 | オンラインは10ページかつ20MB以下 | 上限内ならバッチへ移し、超過時は分割を依頼 |
| 画質 | 300dpiを標準とし、最小文字が目視できる | ぼけ、影、欠け、強い圧縮を撮り直しキューへ送る |
| 保護設定 | 処理用コピーを正規手続で復号できる | パスワードをチャットへ書かせず、安全な経路で確認 |
| 帳票種類 | 請求書であり、対象12レイアウトのいずれか | 未分類フォルダーへ隔離し、別文書として受付 |
| 原本性 | 受付時のSHA-256と受信元を保存済み | 同一ハッシュがあれば重複候補として登録を保留 |
スマートフォン撮影を許可する場合は、四隅の欠け、台形歪み、反射、指の写り込みを品質判定へ追加します。画像の自動補正前後を別ファイルとして残し、補正済み画像だけを原本と呼びません。ページを分割したときも、元ファイルの処理IDとページ番号を継承させます。これにより、レビュー画面から受領時の状態まで戻れます。
登録項目の定義と正解データを取引先別に作る
抽出対象は、取引先名、取引先コード、請求番号、請求日、支払期日、通貨、税抜額、税額、税込額、振込先、明細行に限定します。「日付」「金額」のような名前だけでは不十分です。
日付は西暦のYYYY-MM-DDへ正規化する、金額は通貨記号と桁区切りを除いて整数または小数へ変換する、請求番号は先頭ゼロを保持する、といった比較規則を項目辞書に記載します。空欄をゼロへ置き換える処理は、税額や数量を誤登録するため採用しません。
想定する正解データは、12取引先から各20件、合計240件です。160件を設定調整、80件を固定評価に分け、同じ請求書の複製や連番ページを両方へ入れません。経理担当とデータ担当が独立してラベルを付け、不一致は支払承認者が原本を見て裁定します。
レイアウトが少ない取引先、訂正版、複数税率、マイナス明細、ページをまたぐ表を意図的に含めます。件数は想定例であり、実装先では項目別の出現数と誤りの重大度から増やします。
| 項目 | 一致の定義 | 不一致時の扱い |
|---|---|---|
| 請求番号 | 大文字小文字、記号、先頭ゼロを含む完全一致 | 重複判定に使うため必ず人が原本確認 |
| 取引先コード | 名称候補ではなく有効期間内のマスターIDと一致 | 同名企業を自動選択せずマスター担当へ照会 |
| 請求日 | 原表記を保持し、正規化値が暦上有効 | 和暦変換や月日逆転の疑いを確認キューへ送る |
| 税込額 | 通貨と小数桁を含めて正解値と一致 | 信頼度に関係なく登録を停止 |
| 明細 | 行順、品目、数量、単価、金額の組が全行一致 | 一行でも欠ければ請求書全体を部分合格にしない |
| 振込先 | 既登録口座または承認済み変更申請と一致 | 新規・変更口座は支払先確認手続へ分岐 |
{ "schema_version": "invoice-ja-2026-07-01", "document_id": "INV-20260730-00421", "source_hash": "sha256:...", "fields": { "invoice_number": {"raw": "A-00128", "normalized": "A-00128"}, "invoice_total_jpy": {"raw": "￥110,000", "normalized": 110000} }, "decision": "review_required", "reasons": ["bank_account_changed"]}
項目辞書、正解データ、業務ルールは別々に版管理します。モデル版だけを記録しても、正規化式や取引先マスターが変われば結果は再現できません。評価時には三つの版番号を同じ実行記録へ書き、変更前の80件を回帰試験として残します。
受付から会計システムの登録待ちまでを八段階で実装する
処理は一つの長いプロンプトにせず、失敗位置を特定できる段階へ分けます。各段階は「成功」「人の確認待ち」「受付拒否」「システム失敗」のいずれかを返します。タイムアウトや空レスポンスを成功扱いにしません。再実行には同じ処理IDと試行番号を使い、原本ハッシュ、モデル版、出力ハッシュを比較します。
外部サービスへ送る前に、契約したリージョン、暗号化、ログの保存先、再学習への利用条件をシステム設定から検証します。
- 受領を確定する：送信元、受信時刻、MIME型、SHA-256、ページ数を記録し、重複候補を検索する。
- 入力品質を検査する：解像度、回転、欠け、暗号化、画像圧縮、対象帳票かを判定し、原本を変更せず作業コピーを作る。
- OCRを実行する：文字、段落、ページ座標、信頼度を取得し、API応答と処理器の版を保存する。
- 項目を抽出する：項目辞書へ対応させ、原文と正規化値を分ける。生成AIを使う摘要整理でも数値の生成は禁止する。
- 決定的ルールを適用する：税抜額と税額の合計、取引先マスター、重複、支払口座、必須項目をコードで照合する。
- 確認先を決める：項目別信頼度とルール結果から、自動通過、経理確認、取引先照会、情報管理確認へ分岐する。
- 人の修正を保存する：原本上の位置を見ながら値を直し、修正理由と修正前後を監査ログへ追記する。
- 登録待ちへ移す：承認済みデータを一意キー付きでステージングし、会計側の応答を受けてから完了にする。
if input_rejected: return "request_resubmission"if ocr_failed or response_missing: return "system_retry_queue"if critical_field_missing: return "accounting_review"if bank_account_changed: return "supplier_verification"if personal_data_route_unknown: return "privacy_owner_review"if duplicate_key_exists: return "duplicate_hold"return "staging_ready"
失敗時の再試行は最大二回とし、待機時間を30秒、120秒のように広げます。同じファイルを何度も新規受付すると、課金と二重登録の両方が増えます。二回失敗した処理は担当者へ渡し、API障害、ファイル破損、権限不足、サービス上限のどれかを選択して記録します。会計連携では送信前の一意キーを固定し、登録後に返る伝票番号との対応を保存します。
NISTのAI Risk Management Framework 1.0は、AIシステムを配備前に試験し、運用中も定期的に測定する考え方を示しています。この枠組みは任意で業種横断の資料であり、会計処理の法的要件そのものではありません[8]。本実装では、入力条件、測定結果、停止判断、復旧を版ごとに残すための設計根拠として利用します。
全文の正解率ではなく項目別の適合率・再現率・完全一致を測る
「OCR精度99％」という一つの数字では、支払事故を予測できません。社名の一文字と税込額の一桁では影響が異なり、明細が100行ある請求書では多数の正しい文字が重大な誤りを隠します。
Google CloudのDocument AI評価資料は、項目抽出を適合率、再現率、F1で評価し、一般的なAccuracyを提供しない理由も説明しています。信頼度のしきい値を上げると、通常は適合率が上がる一方で再現率が下がります[3]。したがって、項目ごとに誤検出と見逃しの費用を決めます。
適合率 = 正しく抽出した件数 ÷ 抽出した全件数再現率 = 正しく抽出した件数 ÷ 正解データに存在する全件数F1 = 2 × 適合率 × 再現率 ÷ (適合率 + 再現率)項目完全一致率 = 正解と完全一致した文書数 ÷ 評価文書数無人通過率 = 人が直さず登録待ちへ進んだ文書数 ÷ 全処理文書数
固定評価80件に重要項目が640個あり、正しく抽出した項目600、誤って抽出した項目12、見逃した項目40という想定例です。この場合、適合率は600÷612＝98.0％、再現率は600÷640＝93.8％、F1は約95.8％です。平均だけを見ると高く見えますが、40件の見逃しに税込額や振込先が含まれるなら自動登録には進めません。誤りを項目名、取引先、画質、ページ位置、モデル版で分解し、どの条件を人へ戻すかを決めます。
| 対象 | 測定方法 | 限定運用の基準 | 基準外の処理 |
|---|---|---|---|
| 税込額・通貨 | 80件すべてを完全一致で照合 | 誤り0件かつ計算ルール合格 | 一件でも誤れば全件を人が確認 |
| 請求番号 | 記号と先頭ゼロを含む完全一致率 | 99.5％以上を目標にし、重複確認を併用 | 不一致は原本照合キューへ送る |
| 取引先コード | マスターID単位の適合率と再現率 | 両方99.0％以上かつ同名誤選択0件 | 候補を表示し、担当者が一社を確定 |
| 明細行 | 全行一致率と欠落行数を併記 | 全行一致95％以上、金額差0円 | 行欠落があれば請求書全体を確認 |
| 無人通過 | 修正なしの登録待ち件数を集計 | 品質基準を満たした後に30％以上 | 低くても精度条件を緩めず原因を分類 |
99.5％という基準は編集部が示す設計例で、少数の評価データだけでは安定性を証明できません。取引先ごとの出現数、信頼区間、繁忙期の画質を加え、支払事故の許容度に合わせて承認者が決めます。信頼度が高くても、税額計算、口座変更、重複検知のどれかが失敗すれば確認対象です。
反対に信頼度だけが低く、原本との完全一致を決定的ルールで証明できる項目は、検証記録を残したうえで扱いを見直せます。
確認画面で原本・抽出値・信頼度・業務ルールを同時に照合する
確認画面は、左側に原本ページ、右側に項目一覧、下部に処理履歴を配置します。項目を選ぶと原本の該当座標を枠で示し、抽出した文字列、正規化値、信頼度、採用した取引先マスター、業務ルールの結果を同じ行へ表示します。担当者はPDFを別窓で探さずに済み、数字を直した理由を原本の位置と一緒に残せます。
OCR文字列と正規化値を一つの入力欄で上書きすると原因分析ができないため、別フィールドにします。
Google Cloudの現行廃止一覧では、Document AI Human in the Loopの廃止日が2024年1月16日と示されています[5]。過去の画面を前提に新規システムを設計せず、自社の確認画面、ワークフロー製品、または要件を満たす外部サービスを選びます。
製品選定時には、原本座標の表示、項目別の差し戻し、監査ログ、アクセス権、キーボード操作、版管理を実機で確認します。
| 領域 | 表示内容 | 担当者の操作 | 保存する証跡 |
|---|---|---|---|
| 原本ビュー | ページ、拡大率、抽出座標、画質警告 | 該当箇所へ移動し、補正前画像も開く | 参照ページと座標 |
| 項目パネル | 原文、正規化値、信頼度、必須状態 | 修正、欠損指定、別候補の選択 | 修正前後と理由コード |
| 検証パネル | 税計算、マスター、重複、口座変更 | 解消、取引先照会、上長差し戻し | 確認資料と承認番号 |
| 確定操作 | 登録対象の版と重要項目の要約 | 承認、保留、受付拒否のいずれか | 担当者、時刻、データハッシュ |
| 履歴 | OCR、抽出、修正、連携の時系列 | 前版比較と再処理理由の確認 | モデル版、ルール版、試行番号 |
確認の速度だけを上げると、担当者が候補をそのまま承認する偏りが生まれます。金額、口座、取引先コードは確認前に値を隠し、原本を読んでから候補を表示するサンプル監査も有効です。週に20件を別の経理担当が再確認し、修正見逃しと過剰修正を測ります。担当者ごとの承認数を競わせず、重大誤りを止めた判断を品質記録に含めます。
権利・個人情報・保存期限をデータの通り道ごとに確認する
請求書には、担当者名、メールアドレス、住所、銀行口座、印影、購入内容が含まれます。受付用メール、作業ストレージ、OCRサービス、生成AIサービス、確認画面、監査ログ、会計システムのどこへ複製されるかを図にし、それぞれの利用目的、閲覧者、保存場所、削除時期を決めます。
個人情報保護委員会の生成AIサービスに関する注意喚起は、個人情報を含む入力を扱う際に、利用目的やサービス提供者による機械学習利用などを確認する必要性を示しています[6]。本稿は個別案件の法的判断を代替しません。
生成AIを摘要整理へ使う場合も、請求書全文をそのまま送る設計にはしません。取引先名や口座を仮IDへ置換し、必要な明細説明だけを渡します。契約上の学習利用、再委託、国外処理、ログ保持、削除要求、障害時の通知を情報管理担当と確認します。原本は会計上必要な保管方針へ従い、モデル検証用コピーは目的を終えたら別期限で削除します。
匿名化したつもりでも、取引内容と日付の組合せで再識別できる場合があるため、変換表へのアクセスを分離します。
見積書、図面、カタログ、契約条件が請求書へ添付されると、個人情報だけでなく著作物や営業秘密も入ります。文化庁「AIと著作権に関する考え方について」は、AI利用と著作権の論点を整理していますが、資料自体は個別案件の結論を自動的に与えるものではありません[7]。
OCRのために複製する権限、外部サービスへ送る契約上の権限、学習や評価へ二次利用する範囲を別々に確認します。
| 確認対象 | 記録する内容 | 未確認時の処置 |
|---|---|---|
| 個人情報の利用目的 | 請求処理、監査、モデル評価のどこまで含むか | 評価データへ転用せず情報管理担当へ照会 |
| 外部処理条件 | 保存地域、学習利用、再委託、削除、事故通知 | 当該サービスへの送信を無効化 |
| 著作物・営業秘密 | 複製、解析、社外送信を許す契約または社内根拠 | 添付物を分離し、権利担当へ渡す |
| 閲覧権限 | 受付、修正、承認、監査の役割別権限 | 最小権限を設定するまで本番データを置かない |
| 保存と削除 | 原本、作業画像、JSON、ログ、正解データの期限 | 期限のない複製を作らず、保管責任者を決める |
API待ち・人の確認・再処理を分けて処理時間と費用を試算する
処理時間は「受付から登録待ちまで」で測り、OCR APIだけの応答時間にしません。想定するオンライン処理では、受付検査2秒、OCRと項目抽出4秒、業務ルール1秒で、無人通過は合計7秒です。確認対象はキュー待ち30秒、担当者操作45秒、再検証3秒を加え、中央値85秒になります。
これは計画値であり、実測時には受付時刻、API送信、応答、確認開始、承認、会計応答を別々に記録します。p95が目標を外れた場合、API、画面、担当者配置のどこが詰まったかを分解します。
Google Cloud Document AI「Pricing」は、2026年7月30日の参照時点で、Enterprise Document OCRを月初の無料枠後、500万ページまで1,000ページ当たり1.50米ドル、Custom ExtractorとForm Parserを100万ページまで1,000ページ当たり30米ドルと掲載しています[4]。次の計算は、5万ページ、Custom Extractor、1米ドル150円を置いた想定例です。税、保存、通信、監視、契約割引、別製品の料金は含めず、導入先の請求SKUで置き換えます。
OCR費:(50,000ページ - 無料1,000ページ) ÷ 1,000 × 1.50米ドル= 73.50米ドル抽出費:50,000ページ ÷ 1,000 × 30.00米ドル= 1,500.00米ドルAPI想定合計:(73.50 + 1,500.00) × 150円= 236,025円人の確認:10,000件 × 確認対象20% × 1.5分 ÷ 60 × 4,000円/時= 200,000円監視・保守・保存の想定 = 180,000円月額想定 = 616,025円
現行手作業を1万件×5分×4,000円÷60＝3,333,333円と置くと、月差額は約2,717,308円です。初期費用を、連携開発350万円、確認画面180万円、データ整備70万円の合計600万円とすれば、単純回収期間は600万円÷約271.7万円＝約2.2か月です。ただし、この値は人員を直ちに削減できる意味ではありません。照会、例外、監査、月末集中、システム停止時の代替作業を含めて実測し、重大な誤登録の損失も別枠で評価します。
| 区分 | 計算単位 | 実測元 | 上限超過時の対応 |
|---|---|---|---|
| OCR・抽出 | 処理ページ数と処理器別単価 | クラウド請求明細 | 不要ページ除外とバッチ範囲を見直す |
| 確認作業 | 確認件数×一件当たり時間 | 確認画面の操作ログ | 精度を緩めず誤り上位の入力を改善 |
| 例外照会 | 取引先・法務・情報管理への照会時間 | チケットの開始・完了時刻 | 回答期限と代替担当を設定 |
| 停止対応 | 復旧時間と滞留件数 | 障害記録と手作業件数 | 日次上限で手作業へ切り替える |
| 品質損失 | 誤支払、再処理、監査指摘の影響額 | インシデント台帳 | 重要項目を常時確認へ戻す |
四週間の並行運用で精度・時間・復旧を動作確認する
一週目は対象12レイアウトと240件の正解データを確定し、個人情報、権利、保存期限を承認します。二週目は受付、OCR、項目抽出、業務ルール、確認画面をテスト環境で接続します。三週目は会計へ登録せず、現行処理の結果とAI側の登録待ちデータを比較する影運用を行います。
四週目は経理担当が両方を確認し、承認済みデータだけを検証用の会計環境へ送ります。本番の支払実行はPoCから外します。
| 観点 | 合格条件 | 確認方法 | 不合格時の戻り先 |
|---|---|---|---|
| 重要項目 | 税込額、通貨、振込先の残存誤り0件 | 固定80件と当週全件を原本照合 | 項目辞書・ルール設計 |
| 重複防止 | 再送試験で会計伝票が二重に作られない | 応答欠落とタイムアウトを意図的に発生 | 一意キー・連携制御 |
| 確認時間 | 確認対象の中央値90秒以内、p95が5分以内 | 確認画面ログを件数別に集計 | 画面設計・担当配置 |
| 権限 | 役割外ユーザーが原本と口座を閲覧できない | 権限別アカウントで拒否を確認 | IAM・情報管理 |
| 復旧 | サービス停止後4時間以内に手作業へ移行 | 連絡、出力、再開、照合を訓練 | 業務継続計画 |
合格後もモデル版、項目辞書、取引先マスター、税制、入力経路が変われば固定80件を再実行します。無人通過率が上がっても、取引先別の再現率が二週続けて基準を外れたら対象を縮小します。月末だけ処理量が増える場合は月中の平均で判断せず、最大日量の1.5倍を流す負荷試験を行います。確認キューを翌営業日へ残さないことも業務側の受入条件です。
低信頼度・金額矛盾・権利不明を自動処理から人へ戻す
人へ戻す条件は「AIが迷ったとき」のような抽象表現にしません。入力拒否、経理確認、取引先照会、情報管理確認、法務確認、システム運用の六つへ分けます。差し戻しには処理ID、原本、該当ページ、抽出値、ルール結果、期限、次の担当を必須にします。担当者が回答できない場合の代替承認者も設定し、確認待ちを自動通過させません。
| 検知した条件 | 停止する範囲 | 戻す担当 | 再開条件 |
|---|---|---|---|
| 形式不一致、暗号化、ページ欠け | 当該ファイルの受付 | 請求書の送信者または受付担当 | 条件を満たす原本を再受領 |
| 税込額、通貨、請求番号が欠損 | 請求書全体の登録 | 経理担当 | 原本確認と修正理由の保存 |
| 合計式が1円でも一致しない | 関連する全明細 | 経理担当と取引先窓口 | 訂正版または差異承認を取得 |
| 振込先が登録済み口座と異なる | 支払先の確定 | 取引先確認の責任者 | 既定の口座変更手続を完了 |
| 個人情報の利用経路が未承認 | 外部AIサービスへの送信 | 情報管理責任者 | 利用目的・契約・保存先を承認 |
| 添付図面などの利用権限が不明 | 添付物の解析と評価利用 | 法務・契約担当 | 権利根拠または除外方法を確定 |
| API失敗が二回続く | 同じ処理IDの自動再試行 | システム運用担当 | 原因を分類し一回だけ手動再開 |
| 確認キューが日次処理能力を超える | 新規の無人通過拡大 | 経理責任者 | 手作業移行と滞留解消を確認 |
この実装が向かない条件
原本を保存できない、重要項目の正解を経理担当も決められない、口座変更の本人確認手続がない、停止中の手作業へ戻せない場合は導入を見送ります。OCRの候補が表示できても、支払判断の責任と復旧経路がない状態では本番登録へ進めません。
終了条件も明記します。重大な金額誤りが一件発生した場合は対象レイアウトの無人通過を停止し、固定評価と直近30日分を再確認します。個人情報の誤送信が疑われる場合は外部送信を止め、情報管理部門の事故対応へ移します。
請求書処理を廃止するときは、定期ジョブ、サービスアカウント、作業コピー、正解データ、監視通知を一覧で無効化し、会計側に未完了データが残っていないことを確認します。
次に取る行動は一種類の請求書を20件集めること
継続取引先を一社選び、通常、複数税率、訂正版、複数ページ、低画質を含む20件を集めます。利用権限を確認したうえで、請求番号、日付、取引先コード、税込額、振込先、明細を人が確定し、入力検査から確認画面まで通してください。金額と口座の残存誤りが0件で、修正理由と処理時間を追跡できたときだけ、次の取引先へ広げます。
20件の実施表には、原本ハッシュ、ページ数、解像度、帳票レイアウト、正解値、抽出値、項目別信頼度、業務ルール結果、確認開始・終了時刻、修正理由、最終判断を一行ずつ残します。API応答だけを成功記録にせず、確認後の値が検証用会計環境へ一度だけ登録され、返された伝票番号を処理IDへ結び付けられるところまで確認します。
受付拒否や人への差し戻しも失敗として消さず、想定した停止条件が働いた証拠として集計します。
参考文献・出典
- Google Cloud公式ドキュメント「Supported Files」（対応形式・推奨解像度、最終更新2026年7月17日、参照日2026年7月30日）
- Google Cloud公式ドキュメント「Limits」（ファイル・ページ上限、最終更新2026年7月17日、参照日2026年7月30日）
- Google Cloud公式ドキュメント「Evaluate performance」（適合率・再現率・F1・信頼度、最終更新2026年7月17日、参照日2026年7月30日）
- Google Cloud公式料金表「Document AI pricing」（米ドル建て料金、参照日2026年7月30日）
- Google Cloud公式ドキュメント「Document AI deprecations」（Human in the Loopの廃止一覧、最終更新2026年7月17日、参照日2026年7月30日）
- 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」（2023年6月2日、参照日2026年7月30日）
- 文化庁「AIと著作権について」（「AIと著作権に関する考え方について」2024年3月15日を含む、参照日2026年7月30日）
- NIST「Artificial Intelligence Risk Management Framework (AI RMF 1.0)」（NIST AI 100-1、2023年1月26日、参照日2026年7月30日）
