はじめに

こんにちは、研究開発部の石井です。

この記事では、弊社が文書画像からの高精度な情報抽出を目指し、フルスクラッチで開発した視覚言語モデル（Vision Language Model） “Viola” の歩みを共有します。

開発に至った背景から、技術選定の試行錯誤、実用化までに直面した技術・ビジネス両面の課題とそれを乗り越えたプロセス、現在の成果と今後の展望までをお伝えします。

VLM をビジネス課題に適用しようとしている方々にとって、何らかのヒントとなれば幸いです。

Viola プロジェクトの始まり

近年、ChatGPT の登場を皮切りに視覚言語モデル（VLM）の研究が急速に発展し、大きな注目を集めています。特に画像内の文字認識能力が向上し、文字認識の学習に特化したモデルの認識精度に匹敵する事例が報告されるようになりました。

例えば InstructBLIP [Dai et al., 2023] *1 では OCR-VQA データセット [Mishra et al., 2019] *2 において OCR に特化した既存モデルを上回る性能が報告されています。

図 1. InstructBLIP のアプローチ。学習済みの Image Encoder と LLM をアラインする Q-Former を学習する。（*1 Figure 3 より引用）

弊社は、名刺や請求書、契約書等の文書画像から情報を抽出してデータ化するシステムを開発しています。現在もデータ化のためにさまざまな技術を活用していますが、さらなる高精度化を目指し、最新の VLM や LLM の活用を検討しています。

しかし、2023 年 10 月頃にオープンソースの LLM、API として提供されている VLM・LLM を用いてデータ化の精度を評価した結果、精度・コストの観点で十分な投資対効果を得ることはできませんでした。

主な課題は以下の2点でした。

1. データ化のルールを正確に覚えさせることが難しい

LLM は一般常識を考慮してタスクを遂行するような振る舞いを見せますが、一般常識だけではデータ化のルールを完全にカバーすることはできません。

例えば名刺に会社のメールアドレスと個人のメールアドレスが記載されていた場合、どちらをデータ化すべきかは投入するシステムの知識やドメイン固有のルールを知らなければ分かりません。

このような知識を大量にプロンプトに入力すると矛盾が生じやすくなり、回答の正確さが失われる傾向にありました。

2. 文字認識精度が期待値に達していない

比較的大きく記載されている文字は読めるものの、細かい文字の認識精度は不十分であり、利用できる水準には至りませんでした。

フルスクラッチ開発の動機

文字認識精度が低い根本的な理由として、オープンソース VLM の多くは画像エンコーダーとして CLIP の事前学習済モデルを採用していることに着目しました。

OpenAI によって公開されている CLIP の事前学習済みモデルは大きくとも 336x336 ピクセルであり、文書画像中の文字を正確に認識するユースケースにとっては比較的低い解像度であると考えられます。

OCRBench [Liu et al., 2023] *3 では、1344x896 の解像度を処理するアーキテクチャは 224x224 の解像度を処理するアーキテクチャと比べて細かい文字の情報抽出タスクにおいてより優れた性能であり、画像の詳細な情報を捉えるためには高解像度な画像をサポートすることが不可欠である」と報告されています。

高解像度な文書画像をインターネットから大量に収集することは難しい一方で、弊社は学習に利用することができるよう処理された高解像度な文書画像を一定量保有していました。

これらを活用して高解像度な画像をサポートする文書画像エンコーダーを持つ VLM を構築できれば、オープンソースの VLM よりも高精度なデータ化を実現し、価値を創造できるのではないかと考え、フルスクラッチで事前学習を行う決意をしました。

これが “Viola” プロジェクトの始まりです。

リスクとの向き合い

プロジェクトの推進にあたり、下記のスライドで提案されている、事業を「技術リスク」と「市場リスク」の 2 軸で整理するアプローチを参考に戦略を考えました。

speakerdeck.com

スライドによると、技術リスクとは、「作れるかどうか分からない」リスクで、市場リスクとは「売れるかどうか分からない」リスクとされています。

この観点をもとに現状を分析し、下記の状況であると考えました。

1. 技術リスクをどこまで落とせばよいかが分かっていた

弊社は内製の OCR モデル “NineOCR” を名刺のデータ化に利用しています。Viola が同じ評価データで NineOCR と同等以上の精度に到達すれば、名刺データ化エンジンをリプレースすることで事業貢献できると考えられます。つまり、技術リスクをどこまで落とせばよいか、が比較的明確であると考えました。

2. 市場リスクは比較的小さいと見込めた

弊社は文書画像を高精度にデータ化するために大きなコストをかけています。ドメインによって違いはありますが、画像の文字を今まで以上に高精度にデータ化できれば一定のインパクトがあることが見込めました。

3. 技術リスクが特に高かった

当時 VLM を構築して文字認識を試みた例は社内にほぼなく、どの程度の認識能力を獲得できるか全く未知数でした。特に、先述した通りフルスクラッチでの VLM 構築を検討していたため、性能を事前に予測することが極めて困難でした。

つまり「要求される精度の水準は分かっており、市場もそれなりに大きいが、高い精度を実現できるかが分からない」状態と判断し、まずは高い技術リスクを落とすための技術検証を進めることにしました。

技術検証

CLIP の学習

検証の最初のステップとして、InstructBLIP などのオープンソースの VLM で広く画像エンコーダーとして採用されていた CLIP [Radford et al., 2021] *4 を参考に、画像とテキストの対照学習を試みました。

図 2. CLIP のアプローチ。画像、テキストのペアの組み合わせを正しく予測できるように学習する。（*4 Figure 1. の一部を引用）

しかし、これは以下の理由から期待通りの成果にはつながりませんでした。

高解像度な画像の扱いが難しい

文字を正確に認識するためには高解像度な画像入力が必須と考えていたため、オリジナルの CLIP の 2 倍程度の解像度を採用しました。しかし、画像を高解像度化すると Vision Transformer が出力する画像のパッチ数が増え、処理に必要な GPU メモリが増加するため、バッチサイズを小さくせざるを得ませんでした。CLIP の学習効率はバッチサイズに大きく依存するため、バッチサイズを小さくすると学習が不安定になり、損失の低下速度も非常に遅くなるという問題に直面しました。

画像エンコーダーの評価が難しい

CLIP は画像エンコーダーとテキストエンコーダーからなるアーキテクチャであるため、成果物となるモデルでは文字認識能力を直接評価できません。適切に文字認識能力を評価するためにはテキストデコーダーを新たに学習する必要があり、評価に多大な時間を要しました。

文字認識能力の獲得が難しい

CLIP はバッチ内の画像とその画像に対応するテキストを識別できるように学習を行います。バッチサイズが小さいと全く異なる文書画像だけがバッチ内に含まれる可能性が高くなるため、難易度の低いタスクを解くことになります。

例えば、バッチ内の画像がすべて異なる会社の名刺で、レイアウトが大きく異なる場合、モデルは文字を読まずグローバルなレイアウト特徴だけで損失を小さくできると考えられます。この設計で文字認識能力を獲得できると言い切る自信は私にはありませんでした。

約 1 カ月間検証を行いましたが、上述の理由から文字認識性能の高い画像エンコーダーを効率よく構築することは困難であると判断しました。

GIT へのピボット

改めて、高解像度な画像を入力した場合の悪影響が小さく、文字認識タスクを直接解くことができるアーキテクチャを再調査しました。

例えば SigLIP[Zhai et al., 2023] *5 は対照学習のかわりにペアワイズシグモイド損失を利用して学習する手法を提案しています。論文では、そもそも大きなバッチを用いて損失を計算する必要がなく効率的であるということに加え、過度に大きなバッチサイズは必要なく、合理的なバッチサイズで充分であると報告しています。このアプローチも一つの解決策であると考えましたが、テキストデコーダーを学習しなければならないという課題は残存するため見送りました。

また、CoCa[Yu et al., 2022] *6 は CLIP の対照学習（Contrastive Learning）とキャプション生成（Captioning）を組み合わせて学習する手法を提案しています。これは、画像・テキストそれぞれの中間表現に対照損失を課すことでモーダル間のアラインメントを学習しつつ、画像・テキストのマルチモーダル表現に対してキャプション損失（画像に対するキャプション生成の損失）を課すことで包括的に学習する仕組みです。テキストデコーダーが統合されているため、別途テキストデコーダーを学習することなく性能を評価できる点から解決策として採用できると考えました。

図 3. CoCa のアプローチ。Contrastive Loss と Captioning Loss で画像・テキスト基盤モデルを事前学習する。（*6 Figure 1 より引用）

調査と簡易実験を繰り返す過程で GIT（Generative Image-to-text Transformer）[Wang et al., 2022] *7 が代替のアーキテクチャとして最も適すると判断し、採用しました。

GIT は画像エンコーダーとテキストデコーダーを組み合わせたアーキテクチャで、キャプション損失を最小化します。CoCa と同様に、文書画像に記載された文字列をキャプションと捉えて学習を行うことにより、文字認識能力を損失値から評価できるというメリットを持っており、よりシンプルな構成でした。

図 4. GIT のアプローチ。Captioning を事前学習し VQA を Fine-Tuning する。（*7 Figure 2 より引用）

GIT の論文を見る限り CoCa と比べて飛躍的に性能が向上しているとは言い難く、どちらを採用するかは迷いました。しかし、単純な構成・少ないパラメータ数でベンチマーク精度が同等以上であること、当時時点で transformers にモデルの実装があり、検証を素早く開始できる見込みがあったことから GIT をベースアーキテクチャとして採用することを決めました。

まず、文書中に記載されている主要な文字を正解データとしてキャプション生成タスクを解く事前学習を通して文字認識能力の獲得を目指しました。loss が低下するにつれて文字を正確に読むことができるようになっていく様子を確認することができたため、少なくとも心理的には良い判断だったと感じています。また、CLIP は学習初期の段階では loss が安定せず学習率のスケジューリングを慎重に設計する必要がありましたが GIT は固定の学習率でも問題なく学習が進みました。地味ではありますが懸念を一つ減らすことができた点も良かったです。

文字認識能力をそれなりに獲得した段階で、VQA(Visual Question Answering) データセットでの Fine-Tuning に切り替えました。Fine-Tuning では、文書中の文字を全て出力するのではなく、事前に「"質問: 氏名は？回答:"」といったプレフィックスとなるテキストを入力したうえで、続きの文字（"石井良"）を予測させます。これにより文書からの情報抽出タスクとしてのインターフェースを完成させました。これが Viola のアーキテクチャ原型となりました。

Viola のアーキテクチャ・技術については下記のスライドで紹介しています。興味があればぜひご覧ください。

speakerdeck.com

この枠組みで 2 カ月程度の技術検証を行った結果、一部の名刺データセットに対しては NineOCR（既存の内製 OCR）と同程度の精度に達し、当初目標としていた水準まで技術的不確実性を軽減することができました。

検証を支えた学習環境

Viola の学習には AWS SageMaker Training Job を活用しました。

SageMaker Training Job の詳細な説明は省略しますが、学習を従量課金で実行できるようになる点が特に今回のプロジェクトと相性が良かったです。

検証を始めて間もない時期は、少量のデータを学習して正常に損失が低下していることや過学習していることを確認できれば良く、学習よりも実装の時間が長かったです。ある程度実装が固まり、データを増やして高い精度を追求する時期になると高いスペックの GPU を搭載したマシンを利用したくなっていきました。実装に誤りがあってうまく学習できない時期が続いたり、問題設計が適切でなくそもそも正常に損失が低下せず、スペックを上げる必要がないタイミングもありました。

上述の通り、機械学習プロジェクトは特定のタイミングで高いスペックの GPU を利用したくなるものの、常に必要ではない、という状況が多いです。

しかし、GPU マシンは比較的高価であるため、プロジェクト開始とともに大規模なマシンを購入・レンタルしたものの、検証がうまくいかずに使う必要がなくなった、といった場合に金額的な損失が大きくなりやすいです。このリスクをヘッジする手段として、必要なときに必要なだけのリソースを利用できる AWS SageMaker Training Job が役立ちました。

プロジェクト開始当初は g4dn.xlarge のような比較的安価なインスタンスを用いて小規模に検証を進め、ある程度成果が見込めるようになった段階で g4dn.12xlarge 、p4d.24xlarge 等の高いスペックの GPU を搭載したインスタンスを用いて学習する、といった柔軟な切り替えを実現してくれました。また、一時的に複数のパラメータで並列に実験をしたい、といったケースでも柔軟にスケールして実験を加速することができました。

コストの観点では、スポットインスタンスを利用することにより最大 70% の割引を受けることができる点もありがたかったです。学習プロセスはミッションクリティカルなジョブではないこと、大抵のフレームワークがチェックポイントのアウトプットをサポートしており、不意のジョブ停止に強いことからスポットインスタンスとの相性が良いため、積極的に利用しました。

SageMaker Training Job の利用に関しては過去に記事を執筆しています。興味があればぜひご覧ください。

findy-tools.io

buildersbox.corp-sansan.com

実用化までの壁

技術的不確実性が下がったため、次は Viola を導入する事業領域の探索に移りました。先述した通り、私は当初「十分な精度があればデータ化エンジンとしての使い道は自然と見つかるだろう」と安易に考えていましたが、そう単純ではなく、いくつかの困難がありました。

主な課題は以下の 3 点でした。

投資対効果の見極めには時間がかかる

Viola は比較的大規模で推論時にも GPU を利用する想定だったため、ルールベースや CPU で動作する機械学習モデルと比べて運用コストが高くなります。従って、運用コストを充分に上回る価値を提供できる領域に導入する必要があります。しかし、大きく効果が出そうな課題が放置されているという状態は基本的にはありません。大きな課題があれば弊社のメンバーによって何らかの手段で課題解決が進められています。現在の手段でデータ化できていない文書を Viola がデータ化できるかは実際に検証しなければ分かりません。導入できそうな領域はあっても「本当に投資対効果があるのか」を見極めることには時間がかかりました。

リプレースにはコストがかかる

既存システムと同程度の性能を達成したのでリプレースできるという私の考えは安易でした。リプレースに伴う工数やリスクを考慮すると、同程度の性能というだけではリプレースの判断には至らないことがほとんどでした。

技術的不確実性は落ちていなかった

私は名刺ドメインで NineOCR と同程度の精度に到達したため、技術的不確実性が下がったと判断しました。私はこの結果から他の領域でも価値を提供できると安易に類推しましたが、本来はあくまで名刺のデータ化に限り高い精度だったという話に過ぎません。本当に他のドメインでも同様に高い精度で、ビジネス価値に結びつくことを保証するものではありませんでした。

「名刺では NineOCR 程度の精度に達したがリプレースするほどでなく、他のドメインで投資対効果を見極めるためには地道な検証が必要である。」という状態でした。

解決のアプローチ

Viola の導入によって投資対効果を見込めるタスクを探すために、まずは導入可能性のある領域を担当するメンバーへのヒアリングを実施しました。

ヒアリング当初は簡単に技術を紹介し、「Viola が使えそうなタスクはありませんか？」と受動的に可能性を探っていましたが、提案してもらったタスクと Viola が得意とするタスクがややミスマッチであることが多く、具体的な導入にはつながりませんでした。

ミスマッチが起きていたのは、“検証を始める前の自分がそうだったように”「多くのメンバーは Viola がどの程度の性能なのかを正確には知らない」ことが理由であると考えました。

そこで、コミュニケーション戦略を転換し、受動的にアイディアをもらうのではなく能動的に働きかけるようにしました。

具体的には、導入可能性のある領域の担当者から学習や評価に使えるクエリを連携してもらい、私が Viola の学習と評価を実施しました。結果を定性・定量の両面から評価したレポートを作成し、共有することで具体例をベースに議論できるようにしました。

このコミュニケーションスタイルの転換によって、私自身と別ドメインの担当メンバーのそれぞれが、現状の性能と導入に向けての具体的な課題をシャープに見通せるようになったと思っています。結果、Viola の検証にリソースを割いてもらう体制を徐々に構築できるようになりました。

この取り組みを名刺・請求書・契約書それぞれのドメインで大小合わせて 10 件程度実施しました。いくつかの取り組みは実を結び、プロジェクト開始から約 10 カ月が経過したところでようやく名刺・請求書のドメインで Viola がリリースされ、システムへの導入が実現しました。

現在の成果

最初のリリースまでに長い時間を要しましたが、その期間に複数の案件の種を蒔くことができていたため、一度軌道に乗るとその後は順調に成長しています。現在では四半期ごとに 2〜3 の領域で事業貢献を伴うリリースを出しており、既に名刺・請求書・契約書それぞれのデータ化に活用されています。今四半期も 4 件程度のリリースを見込んでいます。

また、プロジェクト開始時点から半年は 1 名で検証を実施していましたが、現在は 4 名程度の研究員が Viola に技術的な改善を加えつつビジネス適用に向き合ってくれています。

技術的にもいくつかのアップデートがありました。以下に代表的な例を紹介します。（必ずしも全てのドメインでこれらの変更が採用されているわけではありません。）

当初画像のエンコーダーは GIT のアーキテクチャを流用して Vision Transformer を採用していましたが、Swin Transformer [Liu et al., 2021] *8 に差し替えることで細かい文字列の認識精度を向上させました。
細かい文字列に対して認識精度が劣化する問題は引き続き残っていたため、入力解像度を当初よりもさらに大きくすることで文字認識能力を向上させました。
Scaled Dot-Product Attention の導入・デコード時の KV キャッシュ活用によって、推論にかかるレイテンシを大きく改善しました。
データ化したい項目同士の依存関係を考慮するために、1 つの質問で複数の回答を出力する（"質問: 金額項目は？回答:" という文字列に続いて "合計11000円\t課税対象額10000円\t税額1000円" と出力する）ようなインターフェースを構築しました。
- この成果は弊社の Loem ・保坂が言語処理学会第 31 回年次大会に「視覚質問応答による文書情報抽出における同時多項目推論」として論文を投稿しています。ご興味があればぜひご覧ください。
請求書・契約書のように複数ページから成る文書のコンテキストを考慮するために、動画 VQA の枠組みを流用して複数ページ文書に対する VQA のインターフェースを構築しました。
- この成果は弊社の山内が人工知能学会全国大会第 39 回にて発表を予定しています。こちらもご興味があればぜひご覧ください。

技術的な改善は領域横断で適用できるものが多く、レバレッジの効く成果です。推論時のレイテンシ改善は、リリースするすべての API の運用にかかるコストを大きく下げるため、投資対効果に直結します。複数ページ文書に対するインターフェース拡張は、今まで 1 枚の文書画像しかデータ化できなかったところ、複数枚の文書画像もデータ化できるようになるため、提供できる価値の総量が増えます。

ベースとなるモデルが同じであり、各メンバーが実施した技術的な改善を素早く横展開できるため、より早く実用化に至るまでの壁を突破できるようになってきています。

今後の展望

適用領域をさらに拡大するとともに、継続的なモデルの精度・速度向上に取り組みます。特に技術的には以下の点に注力する予定です。

画像エンコーダーの最適化

複数ページの文書を Swin Transformer で 1 枚ずつエンコードし、テキストデコーダーに入力する現在のアーキテクチャはやや冗長だと考えます。データ化というタスクの特性上、画像の一部の領域を見れば良い場合が多いため、デコーダーに入力する画像トークンを削減する余地があると考えられます。また、現状は文字が全く書かれていない余白の領域と文字が密に書かれている領域を同じ特徴量として扱いますが、密な領域により多くのパラメータを割り当てることができればより効率的です。例えば Qwen2.5-VL のテクニカルレポート[Alibaba Group, 2025] *9では、画像のピクセルサイズに合わせてトークン数を変更する手法が提案されています。このようなアプローチを検証し、より高速に、多くのページを読み込むことができるアーキテクチャに進化させたいと考えています。

グラウンディングとの統合

Viola は文書画像そのものを入力として受け取るインターフェースであるため、細かい文字列の認識精度が劣化する課題はしばらく残存すると考えます。この課題の解決策としてグラウンディング（Visual Grounding）が機能する可能性があります。正確に文字が読めなくとも文字領域の座標が分かれば、領域を切り出して文字認識モデルに読み取らせることでより正確に文字が認識できるためです。このアプローチによる精度の向上幅を検証し、実現可能性を見極めていきたいと考えています。