先日、営業部の方々に注文書の処理に時間がかかってしまって大変だから、人を雇おうか考えている。なんとかITで改善できないか？と相談を受けました。
弊社では注文を受けるためのEDIのようなものは導入しておらず、メールの添付ファイルのPDFで注文書が送られてくる、というケースが多く、また稀にFAXで受けるということもあるようです。
過去の記事として、FAXを画像データ化してメールで転送したり、クラウドに保存する方法を紹介したことがありましたので、長村製作所でも複合機のFAX転送機能を使ってすでに画像データにはなっています。
従来のOCRでは、異なるフォーマットの書類を正しく構造化して、臨機応変にデータを抜き取るということが困難でしたが、最近のAI界の目覚ましい進歩を考えればうまくいくのではないかと思いトライしてみた、というのがこの記事の内容です。
解決したい課題の整理
- 送られたきた情報から社内用の品目IDを探して、それをkeyにして価格や在庫を検索するのに手間がかかる
- 最終的にそれらを生産管理システムに手入力するのも時間がかかる
- 工事名が不規則な文字列になっていることが多く、転記に時間がかかる上に転記エラーも起きやすい
- これらに時間を取られて処理が遅れた結果、最短納期での業務遂行に支障をきたしてしまう
これらの問題を解決するために、Claude Codeを使って社内システムを開発しました。
システムの全体像
システムの全体像としては、ローカルからpythonコマンドで実行するアプリケーションで、メールボックスを監視して受注した注文票を自動的に処理しはじめるルートと、手動でPDFをフォルダにいれて処理をはじめるルートを用意してあります。
このPDFを解析して各AIやデータベースを順番に呼び出していくのですが、もっとも重要なのがこのPDFから重要な情報を抽出し、データとして構造化していく工程です。
今回のアプリでは、このOCRを担当するAIとしてGoogle Document AIのCustom Extractorを選択しました。
Google Document AI Custom Extractorについて
Document AIは、Google Cloudが提供するドキュメント処理プラットフォームです。スキャンされた書類やPDFファイルなど、非構造化データから構造化された情報を抽出、分類、分析できます。
簡単に言うと、紙の書類やPDFを「コンピューターが理解できるデータ」に変換してくれるサービスです。
なぜCustom Extractorなのか
Document AIには請求書や領収書など、一般的な書類用の「既製品」モデルがあります。しかし、注文書は会社によってフォーマットがバラバラです。そこで登場するのがCustom Extractorです。
Custom Extractorは、特定のドキュメントタイプや抽出したい項目に合わせて、ユーザーが独自にトレーニングできる Document AI の機能です。事前トレーニング済みモデルでは対応できない、独自の帳票や特定のレイアウトを持つドキュメントからの情報抽出を実現します。
つまり、「うちの会社に届く注文書専用のAI」を作れるということです。
生成AIの力で劇的に簡単に
2024年から、Custom ExtractorにGoogleの生成AI技術が組み込まれました。これにより：
過去では、開発者は各ドキュメントタイプごとに数千のサンプルを使って個別のモデルをトレーニングし、本番環境で使える精度を達成するのに相当な時間を費やしていました。対照的に、生成AIはわずかな量のトレーニングデータで、短時間で幅広い種類のドキュメントからデータ抽出を可能にします。
以前は1000枚以上の注文書を学習させる必要があったのが、今では10〜50枚程度で実用的な精度が出せるようになりました。わかりやすいフォーマットであれば、学習なしでもプロンプトで指示を出すことでそれなりに読み取ってくれます。
実際のスキーマ定義
このような形で、抽出したい情報に対してその値が必ず存在するか、複数回存在するかというような項目を選んだり、生成AIに理解させるための説明文を付加することでその項目を抽出しやすくなるための説明を与えることができます。
例えば、長村製作所に届く注文書では大抵、品目IDという欄に長村製作所で管理している品目IDが入力されているわけではないため、長村製作所のIDを見極めるための指示をここで与えて、さらに実際のドキュメントを20枚程度与えてラベルをつけることで抽出力を強化しています。
スキーマ定義の注意点として、抽出項目を構造化するために項目に親子関係を定義することができるのですが、例えば明細部分を明細というような親として定義するのではなく、直接明細の一列一列を明細行という感じで定義するのが良いようです。レシートとかでも、繰り返される明細行を同じように親として定義すれば良いと思います。
Claude Sonnet 4で柔軟に判断
今回のシステムでは、Document AIがかなりの精度でデータの抽出は行なってくれますが、稀にデータに改行文字が混在していたり、品目IDの見落としなどがあったりということもあったので、データクレンジングをClaudeに任せてしまうと同時に、元のPDFと解析結果のJSONをどちらも渡すことによって見落としをチェックしてもらうという2重のAI体制を用いることにしました。
Claudeはプログラミング用途によく使われるAIですが、文脈理解が得意でこちらが質問などをしたときはきちんとなぜその質問をしたのかの意見をうまく汲み取って答えを提示してくれますし、PDFを渡してしまえばClaudeだけでもそれなりに中身を理解させることもできてしまいます。
Open AIのGPTのほうが少し料金が安く利用できるので今後はそちらに置き換えてみて性能がどうなるかなどのテストもしてみたいと思っています。特にOpen AIはminiなどの簡単な仕事をさせるに適した早くて安いAIが使えるのが魅力ですね。
AIは人間的な、抽象的な判断をさせるのに適しているので、例えば表記の揺れなどで検索が難しいときや、名寄せのような処理を任せてしまうというのはとても良い使い方だと思っています。
今回のシステムでも、DBの最新版の品目IDを探す処理においては、正規表現でも書けそうでしたが楽をするためにAIに判定させてみましたが、今のところよく機能しているようです。
社内アプリのデータ置き場に便利なkintone
十分な精度でデータを抽出することには成功していますが、注文書にそもそも品目IDが含まれていないとか、送料が含まれていないので足さなければならないというような注文書があるので、一度人間の目で確認して不足があれば編集はできるようにしておきたいところです。
こうしたときにkintoneは便利で、ITにあまり詳しくない人でも使いこなせるような、自然にデータを見たり編集したりできるインターフェースを提供してくれます。
ローカルのエクセルに保存するのに比べて、APIで登録しなければならなかったりするため少しハードルがあった印象ですが、これもAIがコーディングは代行してくれるためにデータフィールドの変数名だけ教えてあげればすぐにコードが出来上がるようになったので使い勝手が増しました。
JavaScriptのカスタマイズをすることによって、ここを起点にして見積書を作成するAWSのlambdaへのアクセス等もできるので、今回のように登録されたデータを基にドキュメントを作成したいとか、特定のcsvの形式に加工した形でダウンロードしたい、というようなケースにも便利です。
セキュリティの懸念について
中にはセキュリティの懸念でAIに情報を渡して大丈夫か？という点で心配されている方もいると思うので、私が知っている限りの情報を書いておきます。
API利用でのClaude AIと、Document AIは「お客様データをモデル改善に利用しない」ことを明示しています。
例外的に、通常のチャットモードのClaudeなどでは、利用者のフィードバックを得るとき（どちらの回答が望ましいか聞かれるとき等）に、データが学習に使われる可能性があるということになっています。
ですので、基本的にAPI経由での利用は安全だと思いますが、各社のセキュリティポリシーがあると思いますのでそちらを確認の上、ご利用ください。
SaaS全盛の時代から内製の時代へ
これまで、ITをうまく活用するには、標準化されているSaaSを自社でうまく取り入れて、できれば社内の業務フローをそちらに寄せていくことで業務を効率化すべき、という論調が強かったように思いますし、僕も実際そう考えていましたが、このアプローチは社内の反発を招いたりすることもありますし、なかなかうまくいってる会社も少なかったのではないかと思います。
しかし、コーディングにかける工数が一気に減って、技術的な相談相手にもなってくれて、画像も瞬時にデータ化してくれるようなAIが出てきたことは日本の中小企業にとっては福音であり、むしろ各企業がある程度自分たちの業務にあったアプリを内製してしまったほうが効率的に業務改善ができるようになってきているのではないかと思います。
実際、このアプリも数年前だったら自分1人で作るのはさすがに大変で外部のSaaSみたいなものを使うことを検討したと思いますが、いざClaude Codeで作ってみたら10日程度でできてしまいました。
ぜひみなさんもチャレンジしてみてください！
コメントや問い合わせ等は問い合わせフォームまで。
ブログ村のランキング、ポチッと応援よろしくお願いします。
