文書AIを語るとき、真っ先に思い浮かぶ技術は、いまなおOCRだ。
契約書、申請書、証憑書類、領収書、図面、公文書、報告書のように、企業や機関の業務では、いまも数多くの文書がやり取りされている。多くの人はOCRを「画像の中の文字をテキストに変える技術」程度に理解している。
しかし、実際の業務現場の文書は、そう単純ではない。
一枚の文書の中には、見出し、本文、表、注釈、署名欄、印鑑、チェックボックス、添付画像、数字、単位、そして項目どうしの関係が、複雑に絡み合っている。文字を正確に読むだけでは足りない。どの値がどの項目につながるのか、表の行と列がどんな意味を持つのか、文書全体の流れの中で、その情報がどんな文脈に置かれているのかを、あわせて理解しなければならない。
韓国ディープラーニングのAIエンジニアIanは、この問題に長く向き合ってきた人物だ。
2026年3月、Ianが開発に携わった韓国ディープラーニングの文書AIモデルKDL Frontierは、グローバルなOCRベンチマークOCRBench v2の英語部門で総合1位を記録した。Gemini、GPT、NVIDIAといったグローバルビッグテックのモデルを上回る順位だった。
今回の成果は、単にOCRのスコアが一つ高く出た、という結果ではない。文書認識、情報抽出、パーシング、計算、文脈理解、推論までを含む高難度の評価で、韓国ディープラーニングの文書AI技術が、グローバルの主要モデルと競い合えることを示した事例だ。
何より重要なのは、この成果が、韓国ディープラーニングが長く力を注いできた方向と、しっかり結びついている点だ。
文書AIは、汎用AIだけでは解決しにくい。産業や業務ごとに文書の見方が異なり、同じ数字でも、どの文書に置かれているかによって意味が変わる。結局、文書をきちんと理解するには、技術だけでなく、文書というドメインへの経験と解釈力が必要になる。
Ianに、今回の成果の意味と、KDL Frontierが文書を理解する方式、そして韓国ディープラーニングの開発チームが文書AIに向き合う姿勢について聞いた。
「1位よりも大切だったのは、実際の文書でも通用するモデルを作ることでした。」
Q. まず、OCRBench v2での1位達成の、率直な感想を聞かせてください。
正直に言うと、うれしかったです。開発者として、グローバルなリーダーボードで1位を取ったことは、間違いなく意味のあることですから。
ただ、私たちは最初から「リーダーボード1位」だけを目指して走ってきたわけではありません。より重視したのは、実際の顧客の文書で、モデルがどれだけ安定して動くか、でした。
業務の現場でOCRが間違えると、それは単に文字一つが誤って読まれる、という問題ではありません。数字一つが誤って抽出されれば、確認者が再びチェックしなければならず、項目が誤ってつながれば、後続の業務全体が揺らぎかねません。
だから私たちは、スコアを上げることよりも、「実際の文書で、意味のあるエラーをどれだけ減らせるか」をより重視しました。今回の結果は、その方向が間違っていなかった、という確認に近いものでした。
OCRBench v2は、なぜ難しいベンチマークなのか
Q. OCRBench v2は、一般的なOCR評価とどんな点が違うのでしょうか。
従来のOCR評価は、たいてい「文字をどれだけ正確に読んだか」に焦点が当てられています。もちろん、それも重要です。しかし文書AIで本当に難しい問題は、その次にあります。
たとえば契約書から日付を読み取ったとしても、その日付が契約締結日なのか、効力発生日なのか、支払期限なのかを区別できなければ、そのまま業務に使うのは難しいです。表の中の金額を読んでも、その金額が税抜金額なのか、消費税なのか、合計金額なのかをつなげられなければ、結局は人が見直さなければなりません。
OCRBench v2は、こうした部分をより深く見ます。単なる認識だけでなく、文書内のテキストの位置、レイアウト、関係、抽出、パーシング、計算、文脈理解、推論の能力を、あわせて評価します。
分かりやすく言えば、「文字を読めるか」ではなく、「文書を見て、業務的に意味のある情報を理解できるか」を問う評価に近いのです。
「OCRで最も危険なエラーは、読めないエラーではなく、誤ってつなげてしまうエラーです」
Q. KDL Frontierが良い成績を出せた核心は、何でしたか。
私たちは文書を、一つの画像やテキストの塊としては見ません。文書の中には構造があり、関係があり、流れがあります。KDL Frontierは、この全体の構造と文脈を、あわせて考慮するよう設計されています。
OCRでよく思い浮かべるエラーは、文字を誤って読むことです。ところが実際の業務では、文字は正しく読めたのに、見当違いの項目につながってしまうエラーのほうが、より致命的になる場合が多いのです。
たとえば文書に「2026年3月1日」という日付があり、モデルがこの日付を正確に読んだとしても、それが契約日なのか、提出日なのか、満了日なのかを誤って判断すれば、結果的には誤った情報になってしまいます。
だから私たちは、テキストをうまく読むことと同じくらい、文書内の要素どうしのつながりを保つことに集中しました。レイアウト、位置、周囲のテキスト、項目どうしの関係を同時に見ながら、情報が実際の意味の単位で抽出されるようにしたことが、性能に影響したと考えています。
「文書AIには、文書を知っているAIが必要です」
Q. 最近は、汎用のマルチモーダルモデルも文書をかなりうまく読みます。それでも文書特化モデルが必要な理由は、何でしょうか。
汎用モデルは、本当に速いスピードで進化しています。画像も見て、テキストも理解し、質問にも答えられます。私たちも、その進化の速さをずっと見ています。
ただ、企業や機関の文書業務は、汎用モデルが得意とする一般的な理解能力だけでは足りない場合が多いのです。実際の文書処理では、一貫性、再現性、セキュリティ、項目ごとの精度、構造の維持、後処理のしやすさが重要になります。
顧客企業はふつう、「この文書がだいたいどんな内容か教えて」を求めているのではありません。「この項目を正確に抽出して、うちのシステムの特定のフィールドに入れて」を求めています。このとき大切なのは、回答が自然であることよりも、文書にある情報だけを根拠に、正確に抽出されることのほうが、はるかに重要です。
そして、これは単にモデルが賢いだけでは解決できる問題ではありません。文書がどの業務で使われるのか、どの項目が重要なのか、どんなエラーが実際の運用で致命的なのかを、知っていなければなりません。
たとえば、公共文書、金融書類、製造現場の文書、教育行政の文書は、どれも構造と目的が異なります。同じ「金額」という言葉でも、ある文書では契約金であり、ある文書では税抜金額であり、ある文書では予算執行額であることがあります。AIがこの違いを理解できなければ、自動化はかえって確認の負担を増やしかねません。
文書AIにドメイン知識が必要な理由が、ここにあります。
韓国ディープラーニングは、文書を単なるOCR処理の対象としては見ません。文書がどの業務で発生し、どんな基準で確認され、どんな形でシステムに入るべきかまで、あわせて見ます。その経験が、モデル設計やデータ構成、エラー分析の過程に、継続的に反映されています。
KDL Frontierは、文書をどう理解するのか
Q. もう少し技術的に説明すると、どんなアプローチを取りましたか。
文書には、視覚情報と言語情報が同時に存在します。どのテキストがどこに置かれているのか、どの項目と近いのか、表の中で何行目、何列目にあるのか、周囲の文とどんな関係を持つのか、そのすべてが重要です。
KDL Frontierは、こうした情報を切り離して見るのではなく、あわせて反映する方向で設計されています。文書のレイアウト、関係、位置の情報を一緒に見て、文書の中の要素がどんな文脈でつながっているのかを、保とうとしました。
特に文書パーシングでは、単に「テキストを抜き出すこと」ではなく、文書が持つ構造をできるだけ保つことが重要です。見出しは見出しとして、表は表として、項目と値は互いにつながった形で保たれてこそ、その後の自動化業務に活用できます。
結局、文書AIの目標は、人が見ていた文書を機械にそのまま読ませることではありません。人が業務の中で判断していた構造と意味を、AIが理解できるようにすることです。
「文書にない答えを作らないことも、技術です」
Q. 文書AIでハルシネーションを減らすことも重要だ、とおっしゃいました。
文書AIでは、ハルシネーションを減らすことが非常に重要です。文書にない内容を、もっともらしく生成してはいけません。顧客の業務に入る技術であれば、分からないことは分からないと処理し、文書にある情報だけをもとに結果を出さなければなりません。
特に文書自動化は、結果がシステムに直接つながる場合が多いです。誤って生成された値が内部システムに入ると、人が後からエラーを見つけるのは難しくなります。だから文書AIでは、「どれだけ自然に答えるか」よりも、「根拠のない答えを作らないか」のほうが重要です。
私たちが文書構造の理解とNear-Zero Hallucinationを重視する理由も、ここにあります。文書にある情報だけをもとに抽出し、項目どうしの関係を保ち、確信が持ちにくい場合には無理に答えを生成しない、という方向が、実際の業務ではより安全です。
「手書き文字、かすれたスキャン、複雑な表……実際の文書は、いつもモデルを苦しめます」
Q. 開発の過程で、最も難しかった部分は何でしたか。
実際の文書は、きれいではありません。リーダーボードやサンプル画像のように整った文書ばかりではなく、スキャンがかすれていたり傾いていたり、印鑑が重なっていたり、手書きが混ざっていたり、表が崩れていたりする場合も多いのです。
特に、手書き文字やノイズの多い文書は、モデルにとって非常にやっかいです。文字そのものの崩れも大きく、周囲のレイアウトとあわせて見なければ意味がつかめない場合が多いのです。
だから私たちは、特定のタイプの文書にだけ合わせたモデルではなく、さまざまな文書タイプに対応できる汎化性能を重視しました。公共、金融、製造、教育などドメインごとに文書の形が異なるため、どれか一方にだけよく合う方式では、実際の顧客環境で長く使われるのは難しいのです。
重要なのは、初めて見る文書でも、どれだけ崩れないかです。文書のタイプが少し変わったり、書式が違ったりしても安定して処理できてこそ、PoCで終わる技術ではなく、実際の運用に入れる技術になります。
OCRBench v2のPrivate dataリーダーボードで確認した性能
Q. 今回の評価がPrivate data基準である点も、意味があるのでしょうか。
はい。公開されたサンプルにだけよく合うモデルは、実際の環境では限界があります。リーダーボードのスコアは高くても、顧客の文書に適用したときに性能が落ちるなら、良い技術とは言いにくいのです。
今回のOCRBench v2、2026年3月の英語部門の評価は、Private dataリーダーボードを基準に公開されました。特定の公開サンプルにだけ最適化された結果ではなく、別途構成された評価データで文書理解の能力を確認した、という点で意味があります。
私たちが顧客企業の文書を扱うときも、同じ観点でアプローチします。文書のタイプが変わったり、書式が少し違ったりしても、安定して処理できなければなりません。そうしてこそ、実際の運用環境で、人が再確認しなければならない時間を減らせます。
「良いモデルは、開発者ひとりで作るものではなく、失敗を最後まで追いかけるチームが作ります」
Q. 今回の成果を生んだ、韓国ディープラーニングの開発文化についても聞かせてください。
私たちのチームは、結果と同じくらい、失敗を重視します。モデルが間違えたときに「なぜ間違えたのか」を最後まで見てこそ、次の改善が可能になります。
文書AIは、単に精度の数字だけを見て改善するのは難しいものです。あるエラーは認識の問題であり、あるエラーはレイアウトの問題であり、あるエラーは関係理解の問題です。表面上は同じ誤答のように見えても、原因は異なることがあります。
だから私たちは、失敗のケースをたくさん見ます。モデルがどんな文書で揺らぐのか、どの項目を誤ってつなげるのか、どんなレイアウトで情報が崩れるのかを、継続的に確認します。そしてそれを、開発者個人の勘で片づけるのではなく、チーム全体で共有します。
特に文書というドメインでは、小さなエラーも見過ごすわけにはいきません。顧客が実際にどんな文書を処理するのか、どんな例外がよく起こるのか、どの項目で確認に時間がかかるのかを、ずっと見続けなければなりません。モデルを作ることと、現場を理解することは、切り離されていません。
良いモデルは、一度では生まれません。失敗した実験を記録し、原因を分け合い、また設計し直す、その過程に耐えるチームから生まれるのだと思います。
「技術的にかっこいいモデルよりも、顧客の業務で使えるモデルを作りたいのです」
Q. 顧客企業の立場からは、今回の成果をどう受け止めればよいでしょうか。
ベンチマークでの1位は、技術力を示す一つの指標です。しかし顧客企業の立場から見て、より重要なのは、「では、自社の業務で使えるのか」だと考えます。
文書AIを導入しようとする顧客企業は、すでに課題を抱えている場合が多いです。人が文書を一つずつ確認するのに時間がかかったり、入力ミスが繰り返されたり、文書のタイプが多様で、従来のOCRでは自動化がうまくいかなかったりするケースです。
KDL Frontierの強みは、文書を単なるテキストに変えるだけで終わらない点です。文書の構造と文脈をあわせて理解し、必要な情報を意味の単位で抽出できるよう設計されています。
契約書、申請書、証憑書類、報告書、公文書のように複雑な文書を扱う組織であれば、単純なOCRより一段高いレベルの文書理解が必要です。そして、その文書理解は技術だけでは完成しません。その文書がどの業務で使われ、どの情報が実際の意思決定に必要なのかを、知っていなければなりません。
韓国ディープラーニングが自信を持って言える部分も、ここにあります。私たちは文書AIの領域を長く扱ってきて、さまざまな産業の文書を実際に処理しながら積み上げた経験があります。その経験が、モデルの構造や製品の使いやすさ、顧客企業への適用の仕方に溶け込んでいます。
Ianが考える「良いAIエンジニア」
Q. AIエンジニアとして、最も大切にしている姿勢は何ですか。
謙虚さだと思います。モデルが良くなるほど、開発者はモデルを信じたくなります。ところが実際の文書を見ると、いつも例外があります。初めて見る書式、予想もしなかったノイズ、人が見ても曖昧な文書が、次々と出てきます。
だから、モデルを過信しない姿勢が重要です。性能がよく出たときにも、「どこで間違えうるか」を見続けなければなりません。特に文書AIは、顧客の業務と直接つながっているので、より慎重でなければなりません。
もう一つは、問題を正確に定義する力です。AIの開発は、モデルを回すことだけではありません。顧客の業務でどんなエラーが本当に致命的なのか、どの情報が必ず保たれなければならないのか、どんな状況では答えを出さないほうが安全なのかを、あわせて判断しなければなりません。
私は、良いAIエンジニアとは、技術をよく知る人であると同時に、その技術が使われる業務を理解しようと努める人だと思います。
「文書AIの次の課題は、より正確に、より軽く、より簡単に使えるようにすることです」
Q. これからIanさんと韓国ディープラーニングの開発チームが集中したい方向は、何でしょうか。
精度を高め続けることは、基本です。しかし実際の導入を考えると、精度と同じくらい重要なことがあります。より速く処理でき、より多様な環境で動き、顧客企業がより簡単に適用できなければなりません。
特に企業や機関は、セキュリティ要件が高いものです。クラウドだけでなく、オンプレミスや閉域網の環境でも安定して動作しなければならない場合が多いです。だから、モデルをより効率的にし、さまざまな展開環境に合わせられるようにすることも重要です。
もう一つは、文書のドメインごとの最適化です。すべての文書を一つの方式で処理するよりも、顧客の業務や文書のタイプに合わせて、より精緻に理解する方向へと進化すべきだと考えています。
文書AIには、まだ解くべき問題がたくさんあります。だから面白いのです。技術的にも難しく、顧客の業務とも深くつながっていて、きちんと作ったときには、実際の効率改善がはっきりと現れる領域ですから。
文書を読むAIから、業務を理解するAIへ
OCRBench v2の1位は、韓国ディープラーニングにとって重要な成果だ。しかしIanは、インタビューを通じて「1位」よりも、「実際の文書」や「業務で使えるAI」について、より多く語った。
文字を読む技術は、増えている。しかし企業が求めているのは、単なるテキスト変換ではない。文書の中の情報を正確に理解し、業務に必要な形へと構造化し、システムにつなげられる技術だ。
そして、その技術はモデルの性能だけでは完成しない。文書が生まれる業務、人が確認する基準、自動化のあとにデータが流れていくシステムまで、知っていなければならない。これを知ってこそ、AIは意味を持つ。
韓国ディープラーニングが集中する文書AIの方向も、ここにある。
文書を画像として見るのではなく、データへと変えること。テキストを抽出するだけで終わらず、関係と文脈を理解すること。顧客の実際の業務で、人が再確認しなければならない時間を減らすこと。
Ianは最後に、こう語った。
「文書AIは、結局のところ顧客の時間を減らさなければなりません。モデルが賢く見えることよりも、人が再確認しなくて済むほど、正確で安定した結果を出すことのほうが重要です。私たちが作りたいのは、そういう技術です。」
OCRBench v2でのグローバル1位は、その過程から生まれた一つの結果だ。
そしてその結果は、韓国ディープラーニングがこれからどんな文書AIを作っていくのかを示す、出発点でもある。
