Inferioなぜ AI の精度は自社データ次第なのか(そしてなぜ OCR が最初の一歩なのか)?
2026年7月8日 · 6分で読める
AI モデルが自社について正確に答えられるのは、自社のデータが見えているときだけです。汎用モデルは、あなたの取引先も、契約も、先月の支出も知りません — その知識は請求書、領収書、契約書の中にあり、その大半は紙と PDF に閉じ込められています。AI を役立たせるためのデータ基盤づくりは、地味な一歩から始まります。文書から構造化データを抽出すること — つまり OCR です。
なぜ AI は自社のことになると間違えるのか?
large language model(LLM)— 現代のあらゆる AI アシスタントの中核 — が扱える情報源は 2 つしかありません。学習データに含まれていたものと、コンテキストとして与えられたものです。自社の内部記録はどちらにも入っていません。「先月、取引先 X にいくら支払った?」と尋ねられたアシスタントの選択肢は 2 つだけです。知らないと認めるか、数字をでっち上げるか。どちらも「AI が不正確」に見えますが、モデルが壊れているのではありません — データを一度も渡されていないだけです。
データ工学の古い格言「garbage in, garbage out」には、より厳しい現代版があります。データが入らなければ、答えは出ない。先月の請求書が書庫の紙の束や共有フォルダのスキャン PDF としてしか存在しないなら、どれほど優れたモデルでも答えは直せません。ビジネスにおける AI 精度のボトルネックは、ほとんどの場合モデルではなく、自社の事実が機械の読める場所に存在するかどうかなのです。
「ビジネスのデータ基盤」とは実際に何を指すのか?
数年がかりのデータレイク構築プロジェクトのことではありません。ほとんどの企業にとって、機能するデータ基盤の出発点はずっと小さなもの — 構造化データ(structured data)、つまり名前と型を持つフィールドに分解され、ソフトウェアがクエリできる情報です。写真のままの請求書は死んだ資料ですが、同じ請求書が取引先、発行日、明細行、税率、合計を持つデータベースの 1 行になれば、システムが使える事実になります。
文書データが構造化されて初めて、下流のすべてが可能になります。アナリティクスは取引先別・四半期別に支出を集計でき、消込は請求書と支払いを突合でき、AI アシスタントは質問に正しく答えるために必要な行をそのまま取得できます。画像ファイルの入ったフォルダでは、これらのどれも動きません。構造化データこそが、「書類はどこかにある」と「自社について質問に答えられる」の分かれ目です。
なぜ OCR があらゆる AI 戦略の第一歩なのか?
企業の業務知識の大半はデータベースの中にはなく、文書として届きます。紙の請求書、スキャン PDF、スマホで撮った領収書、押印済みの契約書。AI システムは書庫を読めません。アナリティクス層も、検索システムも、アシスタントも、その知識を使う前に、誰か(あるいは何か)が文書をデータに変換しなければなりません。その変換ステップが OCR であり、現代のパイプラインでは AI OCR — vision-language モデルが文書を文脈ごと読み取り、生テキストの壁ではなく名前付きフィールドを返すもの — がその役を担います。
OCR が付随機能ではなくスタックの土台に位置するのはこのためです。OCR はインジェスチョン(取り込み)層なのです。これを飛ばせば、その上のあらゆる AI 層はデータ不足に陥ります — アシスタントには取得すべき事実がなく、ダッシュボードには描くべき数字がなく、消込ジョブには突合すべき対象がありません。文書抽出を AI 戦略の第一歩と位置づける企業には積み上がる資産が残り、いきなり「AI チャットボットを付ける」企業に残るのは、空っぽの部屋に向かって流暢に話すインターフェースです。
データ → AI のループは実務でどう回るのか?
実務のループは 4 段階です。第一に、文書が入ってきます — JPG・PNG・WebP の画像、複数ページの PDF や TIFF。第二に、抽出エンジンが各文書を構造化フィールドに変換し、フィールドごとに confidence score を付けます。レビュー閾値(Inferio のデフォルトは 0.75)を下回った値は修正 UI で人のレビューに回り、確信度の低い値が静かに帳簿へ紛れ込むのを防ぎます。第三に、クリーンな結果がデータストアに届きます — REST API と署名付き webhook 経由、あるいは freee や MoneyForward といった会計ツールへの直接同期で。第四に、そのストアが利用側を支えます。レポート、消込、そして自社の数字で自社の質問に答えられる AI アシスタントです。
このループは複利で効きます。構造化された請求書が 3 か月分あれば「先月いくら使った?」に答えられます。2 年分あれば「インフレ率を超えて値上げした取引先はどこか?」「第 4 四半期の支出増は年をまたいでどう推移しているか?」にも答えられます。処理した文書の一枚一枚が、次の質問を答えられるものに変えていく — これがデータ基盤の実務的な意味です。一発勝負のプロジェクトではなく、文書 1 枚ずつ育つ資産なのです。
よくある質問
- 始める前に本格的なデータウェアハウスが必要か?
- いいえ。有効な出発点は、毎日すでに扱っている文書 — 請求書、領収書、契約書 — から得た構造化データを、いま使っているデータベースや会計システムに流し込むことです。ウェアハウスは量が増えてから加える最適化であって、価値を得るための前提条件ではありません。
- RAG とは何か、OCR とどう関係するのか?
- RAG(retrieval-augmented generation)は、AI アシスタントに自社データから回答させる標準的な手法です。応答の前に、システムが自社のストアから関連レコードを検索し、コンテキストとしてモデルに渡します。検索が機能するのは機械可読なデータに対してだけ — つまり文書が先に OCR と抽出を通過している必要があります。抽出がなければ検索対象がなく、検索対象がなければ RAG は当て推量に退化します。
- 抽出したデータはどうやって社内システムに入るのか?
- REST API と署名付き webhook 経由です。社内システムは文書ごとに構造化フィールドを受け取り、各配信の署名を検証できます。会計領域では、Inferio は OAuth 経由で freee と MoneyForward に直接同期します。日本向けには、国税庁(NTA)の公開 API による T 番号の検証、8%/10% の税率区分、電子帳簿保存法が求める 7 年間の保存にも対応しています。
- どの文書タイプから始めるべきか?
- 最も量の多いものからです — 多くの企業では請求書か領収書です。量が多いほど抽出の投資回収が早く、できあがるデータセットも早く役立ちます。契約書などの少量の文書は、コアのループが回り始めてからパイプラインに加えれば十分です。