出発点は「AI-OCR を入れたのに工数が減らない」
DropOCR の設計は、1 つの観察から始まっています。AI-OCR を導入した現場で、入力の時間は減ったのに、全体の工数がほとんど変わっていないという状態が繰り返し見られました。
理由を辿ると、共通していたのは次の 2 つでした。
- 出てきた結果を信用しきれず、結局すべて目視で検算している
- 出力された形が自社の集計表と違うため、貼る前の整形作業が新たに発生している
どちらも読み取りエンジンの性能では解決しません。ここから、プロダクトとして解くべき問題は「もっと正確に読む」ではなく、「どこを確認すればよいかを示す」ことと「そのまま貼れる形で出す」ことだと定めました。
判断 1: 帳票の事前定義を持たない
多くの AI-OCR は、帳票の様式ごとに読み取り位置を定義します。この方式は精度が安定する反面、取引先が増えるほど設定作業が積み上がります。30 社あれば 30 通り、先方が様式を変えれば作り直しです。
私たちは、この設定作業そのものを無くす方を選びました。位置ではなく、書かれている内容の意味から項目を判定します。「請求金額」「ご請求額」「合計（税込）」が同じものを指していると解釈できれば、様式ごとの定義は要りません。
代償もあります。 位置で決め打つ方式に比べ、判定を誤る可能性は残ります。だからこそ次の判断が必要になりました。
判断 2: 確からしさを、セル単位で持つ
抽出結果は、値だけでなくセルごとの信頼度を一緒に持ちます。これがこのプロダクトの中心にある設計です。
信頼度があると何ができるか。人が確認する対象を、全件から一部へ絞れます。100 枚 × 40 項目で 4,000 セルあっても、確認すべきセルが 200 個と示されれば、確認の作業は別物になります。
見送った案: 信頼度を内部だけで使い、閾値を下回った値を空欄にして出す、という案がありました。見た目はきれいになりますが、読めなかったことが利用者に見えなくなります。空欄が「そこには何も書かれていなかった」なのか「読めなかった」なのか区別できない状態は、静かな欠落を生みます。採用しませんでした。
判断 3: 色だけで示さない
低信頼のセルは、黄色のハイライトに加えて ⚠ の記号と、なぜ低いかを示すツールチップの 3 つで示しています。
色だけで示す方が画面は美しくなります。しかし帳票の確認作業は、白黒で印刷したり、色覚特性のある方が担当したりする現場で行われます。情報を色だけに載せると、その環境では情報が消えます。記号と文言を併記するのは、そのための冗長性です。
判断 4: 明細以外の行を、黙って捨てない
帳票には明細のほかに、小計行・合計行・見出し行・注記行が混ざります。ここには 2 つの失敗があります。
- 黙って捨てる → 合計が合わなくなる
- そのまま明細として扱う → 集計が二重になる
どちらも「気づいたときには遅い」型の失敗です。私たちは、行の種別を判定したうえで既定では警告付きで残し、除外したい場合は明示的に選ぶ形にしました。判定を人が直すこともでき、直した内容は判断の根拠として保存されます。
自動で正しく処理することより、間違えたときに気づける状態を優先した判断です。
判断 5: 曖昧な一致を自動確定させない
商品名から自社の商品コードへの変換では、表記を正規化したうえで完全に一致した場合だけ自動で当てます。似ている候補は提示するだけで、確定は人が行います。
「似ているから、たぶんこれ」で自動確定させると、在庫と売上の両方が同時に狂います。しかも当たっているように見えるため発見が遅れます。ここは利便性より安全側に倒しました。人が選んだ対応は辞書として残り、次回からは自動で通ります。1 回だけ人が判断すれば、以後は自動になるという形です。
判断 6: 変換できない値は、出力を止める
日付の書式変換に失敗した場合、間違った値を出さずに出力自体を保留してエラーで知らせます。
出力を止めると、その瞬間は不便です。しかし誤った日付が静かに集計へ混ざる方が、はるかに高くつきます。止まれば気づけます。混ざれば気づけません。この非対称性が、判断の根拠です。
判断 7: できないことを、できると書かない
月締め請求のような n 対 1 の照合には、現時点で対応していません。機能一覧にも、その旨をそのまま書いています。
導入検討の段階で誤解が生まれると、運用開始後に破綻します。カタログ上の見栄えより、導入後に裏切らないことを優先するという方針で、対応範囲を明示しています。
判断 8: データの分離を、述語ではなく構造で守る
複数の会社が同じシステムを使う以上、他社のデータが見えないことは前提です。ここで「検索条件に会社 ID を付ける」という実装だけに頼ると、条件を書き忘れた 1 箇所が事故になります。書き忘れは必ず起きるという前提で設計する必要があります。
そのため、データベースの層で、その会社のデータしか見えない状態を作っています。アプリケーション側の条件はその上に重ねる 2 層目という位置づけです。1 層目が守っている限り、2 層目の書き漏れがそのまま漏洩にはなりません。
役割による権限も同様です。「画面にボタンを出さない」だけでは、API を直接叩けば通ってしまいます。表示の制御と、実際に通す/通さないの判定は別の層で行う必要があります。
判断 9: 一覧で「何をすればよいか」を示す
ダッシュボードの数字は、それ自体では行動につながりません。「要確認 12 件」と表示されているだけなら、その 12 件を探すところから始まります。
そこで、数字そのものを入口にしています。「要確認 12 件」をクリックすれば要確認だけに絞られた一覧が開き、「エラー 2 件」からは失敗した帳票へ直接移動します。表示と操作を分けないことで、放置されるものが減ります。
同じ考えで、合計金額には未確認の帳票を含んだ暫定値か確定値かの内訳を付けています。見た目を整えるために不確かな数字を確定値のように見せない、という判断です。報告にそのまま使ってよい数字かどうかを、利用者が判断できる必要があります。
開発の進め方についても、同じ原則を置いている
このプロダクトは、実装の前に「この変更で何が壊れうるか」を検出できる形にしてから進める方針をとっています。テストは正常系を通すためではなく、壊れたときに気づくために書きます。
たとえば、機能ページの本文が規定の分量を満たしているか、キャプチャ画像が実在するか、記事中の内部リンクが実在するページを指しているかは、いずれも自動で検査しています。人の注意力に依存する確認は、いつか必ず抜けるためです。
この記事で挙げた設計判断も、同じ原則の別の表れです。間違いが起きない仕組みではなく、間違いが起きたときに静かに通り抜けない仕組みを作る、という一貫した方針があります。
結果として何が変わるか
これらの判断を積み上げた結果、担当者の仕事は次のように変わります。
- 全件を検算する → 印のついたセルを確認する
- 列を並べ替えて貼る → 自社の形で出てきたものを貼る
- 読み替えを記憶する → 1 回選べば辞書が覚える
- 問題に締めの後で気づく → 処理の時点で警告が出る
いずれも「作業が速くなる」ではなく、作業の性質が変わる方向の変化です。入力から確認へ、記憶から仕組みへ。ここが狙いです。
まとめ
DropOCR の設計を貫いているのは、間違えないことより、間違えたときに気づけることという優先順位です。AI を使う以上、判定を誤る可能性はゼロになりません。ゼロにならない前提で、誤りが静かに通り抜けない構造をどう作るか、という問題として扱っています。
実際の画面は確認グリッドのページで確認できます。お手元の帳票で試したい場合は、そのまま投入して結果をご覧ください。