帳票の入力を、
AIとの二人三脚へ。

企画のとき、まず市場を調べました。近ごろの潮流は、生成AIに画像を直接読ませて項目まで一気に取る方式です。新しいのだから、その一段方式が素直に見えました。けれど調べていくと、このシステムの生命線と正面からぶつかる事実に行き当たりました。

このシステムの核心は「AIが自信を持てない項目だけを人に見せて、確認を必要な箇所に絞る」こと。それを成り立たせるには、項目ごとの自信度と、原本のどこを読んだかの位置情報が、機械的に確実に取れなければなりません。ところが生成AI単独では、この自信度が本当の意味では確実に取れず、位置情報の精度・一貫性も保証しにくい。一方、クラウドOCRは、項目・語・行ごとの自信度と位置情報を確実に返してくれます。

だから、あえて二段に分けました。「自信度と位置情報を確実に返すクラウドOCRで文字起こしし、生成AIで項目を構造化して抜き出す」。一段方式のほうがシンプルで速く、費用も抑えられます。それでも、人の確認を助けるUIの土台（自信の低いものだけを回す・原本ハイライトで照らし合わせる）を成り立たせるために、ここは思想として譲りませんでした。一段方式も捨てず、差し替え口の別アダプタとして「安心度の高い文書を速く流すレーン」に将来使える余地を残しています。

文字起こし層にどのクラウドOCRを選ぶかは、費用では差がつきませんでした。決め手は、日本語手書きの実力、自信度と位置情報が確実に取れること、そして社内の技術基盤（.NET・Microsoft認証）との相性です。公式SDKが成熟し、鍵を持たずに安全に認証できる Azure AI Document Intelligence を第一に選びました。言語カバレッジの広い Google Document AI も魅力でしたが、こちらは将来の増設先として位置づけています。

出発点は、社内に実在した困りごとでした。取引先ごとに様式のちがう依頼書を月数百件手入力する、紙・PDF・データ混在の請求書を会計へ転記して突合まで手作業でやる――。ここで本当に求められていたのは「文字を読む」ことではなく、読んだ後の確認・修正・突合・連携という運用全体を軽くすることでした。だから真ん中の価値を「読み取り」ではなく「読むだけで終わらせない一気通貫」に置きました。

そして、AIに全部任せて自動確定する設計は採りませんでした。帳票は、金額も日付も間違えられません。AIは下書きをつくり、最後は必ず人が確定する。 ただ、全項目を人が見直すのでは省力になりません。そこで、自信の低い項目や自動チェックに引っかかった項目だけを色分けして提示し、原本と抽出値を左右に並べて該当箇所を双方向に照らし合わせる。「どこを見ればいいか」を機械が示すから、確認は必要な箇所に絞れます。誤読を確実に捕まえる仕組みこそが、実務での安心につながる――そう考えて、自分たちの帳票に合わせて作り込みました。

一気通貫を作り終えて、実際に人に触ってもらいました。返ってきた最初の声は、機能への賞賛ではなく、その手前でのつまずきでした。

「ログインはできた。でも、様式（項目定義）の設定が難しい。何もない空の状態から、項目キー・表示名・データ型・明細列……を手で組み立てるのが大変だ。」

このシステムの価値は確認・修正・連携の運用にあるのに、その手前の様式定義という最初の壁で、試す人が価値にたどり着く前に手が止まってしまう。ご要望は明快でした――「サンプルの帳票を一枚読ませて、様式を自動でたたき台まで作ってほしい。100点じゃなくていい。後から直せれば十分」。

ここで、既存の資産を"逆向き"に使う発想が効きました。ふだんは「様式で定義済みの項目に、Claudeが値を埋める」。これを裏返し、項目の決まっていないサンプルを読ませて、Claudeに項目そのものを提案させる。サンプルをAzure DIで文字起こしし、Claudeが見出し項目＋明細列の候補を提案して、既存の様式エディタに下書きとして並べる。ユーザーは、ゼロから作る代わりに、たたき台を直すだけでよくなりました。

このとき、設計思想として「100点を狙わない」を明文にしました。提案の不完全さは人の編集で仕上げる前提とし、AIには「実在しそうな項目の当たり付け」までを期待する。過剰に精度を作り込まない。この割り切りは、実は業界の主流とも重なっていました。編集を前提にする考え方は、各社の設計とも同じ方向です。

そして、ここに私たちなりの差別化があります。競合各社も生成AIを使いますが、多くは「抽出」の自動化に使います。本システムは「様式を作る作業そのもの（最初の壁）を、生成AIで軽くする」ことに寄せ、人が編集する様式定義エディタへの下書き投入を、一次の使い勝手にしました。 私たちが調べた範囲では、この編集起点の使い方は国内で目立ちませんでした。しかも土台のAzure DIは和文手書きに強く、和文業務帳票の様式提案に踏み込めます。この新機能は、実際のご担当者が実帳票で動作確認まで行っています。

社内ニーズを調べる中で、費用やスペックだけでは割り切れない要求が実在しました。「情報の漏えいを防ぐためオンプレミスで導入したい」「クラウド型なら多要素認証が必須」――。つまり、どんなに安く高精度でも、機微な文書を外部に出すこと自体が前提に合わないケースがあるということです。

だから最初から、読み取りの中核を一つの境界（差し替え口）として抽象化しました。呼び出す側は「クラウドか自前か」を知りません。一般文書は速くクラウドで、機密案件は社内で完結するローカル処理で――この二段構えを、システム本体やデータの形を一切変えずに、差し替えだけで実現できます。文字起こしと項目抽出も分けてあるので、将来ほかのクラウドOCRを足す（たとえば Google Document Intelligence）のも、国内厳守の要件が出たら抽出役を東京リージョン経由に替えるのも、境界を保ったまま受け止められます。項目を汲む抽出の側も同じ思想で差し替え可能にしてあり、いまはClaudeで動かしながら、将来ほかのAIプロバイダを加えていく余地を残しています。

新機能でも、この思想を貫きました。提案生成の口を既存の境界と対称な新しい差し替え口として足し、サンプルはメモリ・一時ファイルのみで扱って提案後に破棄し、Azureの解析結果も即時削除の対象にし、送信前に「外部AIへ送られる・機微文書は送らない」旨を画面で明示する。外部送信への配慮を、機能を足すたびに設計として作り込む――そういう進め方をしています。