ハンコムのPDFパーサーがGitHubトレンディング1位に上った理由
ハンコムがPDF抽出ツールをApache 2.0のオープンソースとして公開し、GitHubトレンディング1位になりました。ベンチマークスコアと処理速度、収益化構造をまとめました。
AI・テックOswarldです。Google Discoverに表示された私のニュースレターを見つけて訪れてくださったのでしょうか?購読していただければ、面白くて有益なニュースレターをいちばん早くお届けできます。🙇
ハンコムのPDF抽出ツールが開発者たちの注目を集めました
ハンコムは3月23日、PDFデータ抽出ツール「OpenDataLoader PDF v2.0」が3月20日にGitHubの全言語トレンディングで1位になったと発表しました。同社によると、21日の1日でスターが1,800個以上増え、累計7,000個を超えました。私は最初、誰が作ったツールなのか分かりませんでした。利用規約と韓国語ページを見て韓国の開発者によるものかと思ったのですが、ハングルとコンピュータ(ハンコムの正式社名)が参加したプロジェクトだと知って驚きました。

私が関心を持ったのは、順位もさることながら製品を出した方法です。ハンコムオフィスを丸ごと販売するのではなく、文書からデータを取り出すツールを開発者が自ら入手して使えるように公開したからです。
私にとってハンコムは、HWP文書や公共機関の業務環境でよく目にする会社でした。そのため、海外の開発者たちがPDF処理用のオープンソースとしてこの会社に出会うという点が新鮮に感じられました。国内で慣れ親しんだ製品とは別の用途で技術を知らせる機会が生まれたわけです。
GitHubのトレンディングやスターは、関心が集まったという信号です。ただし、技術の正確度や実際の企業導入を証明する指標ではありません。関心を持った開発者たちが自分の文書に適用してみて、その後も使い続けるかどうかが、次に確認すべき点です。
ツールの性能はどのような条件で得られたのか、オープンソースとして公開した方式がハンコムの事業にどうつながり得るのかを見ていきます。
精度と速度は同じ設定で比較すべき
開発チームが公開したベンチマークは、200個のPDFファイルを対象に読み取り順序と表、見出し構造の抽出結果を評価します。4月6日公開のリポジトリの比較表における一部ツールの総合スコアとページ当たりの処理時間は次のとおりです。スコアは0〜1の範囲で高いほど良く、処理時間は短いほど速いです。
| ツールと設定 | 総合スコア | ページ当たり処理時間 |
|---|---|---|
| OpenDataLoader ハイブリッド | 0.907 | 0.463秒 |
| Docling | 0.882 | 0.762秒 |
| Nutrient | 0.880 | 0.230秒 |
| Marker | 0.861 | 53.932秒 |
| Unstructured hi_res | 0.841 | 3.008秒 |
| OpenDataLoader 通常モード | 0.831 | 0.015秒 |
開発チーム自身によるベンチマークだという点も併せて見る必要があります。テスト文書と評価コードが公開されているため同じ手順で確認できますが、すべての種類のPDFで同じ順位が出るという意味ではありません。
ここで区別すべきなのはOpenDataLoaderの2つのモードです。0.907はハイブリッドモードの総合スコアであり、0.015秒は通常モードの処理時間です。通常モードの総合スコアは0.831、ハイブリッドの処理時間は0.463秒です。高い精度と最速の速度を、1つの設定で同時に得たかのように読んではいけません。
実際の処理時間は、文書の構成やハードウェア、OCRの使用有無、並列処理方式によって変わります。この表のページ当たりの時間をそのまま100万ページに乗じて、業務現場での所要時間を確定することはできません。導入する際は、実際によく扱う文書で抽出品質と速度を併せて測定する必要があります。OpenDataLoaderはローカル環境でCPUでも実行できるように設計されており、自分で試してみられるという利点があります。
企業文書から必要な内容を取り出す作業は、思った以上に難しいものです。PDFは画面に文書を一定の見た目で表示するのに適していますが、その中の読み取り順序や表の構造は、抽出しやすい形で保存されていない場合があります。多段組みの文書をどの順序で読むか、表の行と列をどうつなげるか、スキャン画像から文字をどう認識するかが問題になります。RAG1で文書を検索させて回答させるには、こうした前処理の品質を確認する必要があります。
OpenDataLoaderは、規則に従って直接抽出する処理とAIモデルを利用する処理を組み合わせます。一般的なページは高速に処理し、複雑な表やスキャン文書などにはAI機能を活用できます。ハイブリッド機能にはDocling系のツールも使われています。競合ツールをすべて独自技術で置き換えた結果というより、既存技術を組み合わせて文書処理に最適化した設計と見るほうが正確です。
文書処理の経験と外部技術の結合
私は、ハンコムが長く手がけてきた文書処理の経験が、このプロジェクトでどのような役割を果たしたのか気になりました。
PDF処理には、すでにDocling、Marker、Unstructuredといったツールがあります。開発者たちはコストと精度、対応形式に応じてツールを選びます。自社ベンチマークで良いスコアを得ることは、この比較対象に入る契機になり得ます。
私の考えでは、ハンコムの経験が役立つと思われる部分は、文書構造を見分ける作業です。どの文章が見出しなのか、表の行と列はどうつながっているのか、複数段に分かれた本文をどの順序で読むべきなのかを判断する知識2です。ただし、長年の実績そのものが今回のスコアを説明してくれるわけではありません。具体的な実装と、併用したモデルを見る必要があります。
ハンコムの3月の発表によると、2025年7月にPDF技術企業のデュアルラボ(Dual Lab)と業務協約を結び、共同開発に着手しました。同年9月に初期バージョンを公開し、2026年3月12日にv2.0をリリースしました。ハンコムの文書処理の経験と、外部のPDF専門技術がともに参加したプロジェクトです。
こうした協業に意味を見いだせます。自社が得意とする部分を外部の開発者が使える形にし、必要な部分には他の専門企業やオープンソースの技術を組み合わせたわけです。ただし、デュアルラボがどのような理由でハンコムを選んだのかは、公開された協約の事実だけでは断定できません。
ハンコムは他のAI製品と外部技術の連携も進めています。私はこれを、個別製品の販売だけでなく、文書処理技術が他のサービスの中でも使われるように接点を広げようとする試みとして読み取っています。今回のプロジェクトは、その可能性を示す事例だと思います。
オープンソース利用者を商用顧客につなげられるか
ハンコムはこれまでも、ハンコムオフィスNEOなどを通じて海外市場進出を試みてきました。完成したオフィス製品を販売するには、既存の業務方式やファイル互換性、慣れ親しんだ競合製品をともに乗り越える必要があります。PDF抽出ツールは、これとは異なる地点でユーザーに出会います。開発者がすでに作っているサービスに必要な機能を追加できるからです。

v2.0では、従来のMPL 2.0の代わりにApache 2.0ライセンス3を適用しました。商業利用と修正・配布を許可し、修正したコードの公開を一般的には強制しないライセンスです。ただし、再配布する際にライセンスや著作権表示などを維持しなければならない条件はあります。何の条件もなしに使えるという意味ではありません。
GTMの観点から見れば、開発者にまず機能を試させ、導入させる方式です。有用だと判断すればより大きな業務につなげることができ、その過程で有料機能やサポートが必要になる場合があります。無料利用がそのまま売上になるわけではないため、どの機能に顧客がお金を払うのかは別途確認する必要があります。
ハンコムは、データ抽出と検索サービスのハンコムピディア、業務を助けるハンコムアシスタントなどをつなぐ製品構成を示してきました。OpenDataLoaderのv2.0の文書にも無料機能と企業向け追加機能が区分されており、ハンコムの商用データ分析機能との連携が計画として記されています。MCP4などAIツール連携も準備中だと発表しています。オープンソースを使ってみた企業が商用製品を検討するようにつなげる方式と見ることができます。
GitHubで受けた関心が実際の導入につながったかどうかは、まだ見ていく必要があります。既存ツールを切り替えるだけの品質と運用上の利点があるか、問題が起きた際に保守やサポートを受けられるかが、企業の選択に影響を与えるでしょう。
Oswarldの視点
GTM戦略を見てきた中で、韓国で販売していた完成品を英語に翻訳して海外に出す試みをよく目にしました。翻訳は必要ですが、それだけで新しい顧客がその製品を選ぶ理由が生まれるわけではないんですよね。
今回私が注目したのは、海外開発者の具体的な問題から出発したという点です。PDFを正確に読み取ってAIに渡さなければならない開発者に、文書抽出ツールを提供したわけです。慣れ親しんだハンコムオフィスを説明するよりも、どんな用途に使えるのかをすぐに示すことができます。
AIが外部文書を検索し、ツールを呼び出すサービスが増えるにつれ、文書抽出機能を直接比較しようとする開発者も出てきます。ライセンスを変更し、コードとベンチマークを公開したのは、こうした人たちが試しやすくするための選択だと見ています。広く使われるツールになる機会はありますが、市場の標準になったと言うには早い段階です。
他の韓国企業もこうしたアプローチを検討できるでしょう。検索やメッセージング、金融サービスの利用経験、物流運用の中で積み上げてきた技術のうち、外部顧客の問題を解決できる部分があるかを見るのです。ただし、すべての技術を切り離して販売できるわけではありません。外部でも使えるのか、運用とサポートにかかるコストを負担できるのかを確認する必要があります。
個人にとっても考えてみるべき点があります。ある分野を長く手がけると、一般的な説明だけでは分かりにくい判断基準が生まれるものです。どんなエラーが頻発するか、どんな条件では別の方法を使うべきかといった知識です。私は、こうした経験を他の人が活用できるように整理することが、重要になってきていると思います。
経験が長いという事実だけで価値を認めてもらうのは難しいです。事例と基準を説明したり、実際に動作するツールに仕立てたりしなければ、他の人がそれが有用かどうかを判断できないからです。
おわりに
ハンコムの今回の試みで私が参考にしたいのは、慣れ親しんだ製品を別の顧客の問題に合わせて切り分けて提供した方法です。開発者たちが自分で試して比較できるように公開した点もです。
長く手がけてきた仕事の中で、他の人の試行錯誤を減らせる部分は何か、考えてみる価値があります。その基準を説明やツールに仕立てて誰かに試してもらえば、どれほど有用かをより具体的に知ることができるでしょう。今回のハンコムの試みが、今後どれだけ持続的な利用と事業成果につながるかも見守っていきたいと思います。
参考資料と関連リンク
主要出典
- OpenDataLoaderベンチマーク、2026.04.06保存版。本文中のモード別スコアと処理時間を照合した資料です。現在のベンチマークリポジトリでは、テストデータと評価コードを確認できます。
- ハンコム、OpenDataLoader PDF v2.0トレンディング1位発表、2026.03.23。当時の順位とスター数、共同開発および発売スケジュールに関する会社発表です。
- OpenDataLoader v2.0.0 README。通常・ハイブリッドモード、無料・企業向け機能と当時の計画を確認できます。
- Apache License 2.0。利用・修正・再配布の許可範囲と表示条件があります。
背景知識
- “Best PDF Parsers for AI and RAG Workflows in 2026”、Firecrawl Blog。:Docling、Marker、Unstructuredなど競合ツールの強みと限界を比較した記事です。OpenDataLoaderが市場のどの位置にあるかを推し量るのに適しています。
- Auer et al.、“Docling Technical Report”、arXiv:2408.09869、2024。:Doclingの設計思想を公式文書で確認できます。OpenDataLoaderと比較すると、両ツールのアプローチの違いが見えてきます。
- ハンコムのOpenDataLoader GitHubリポジトリ。:自分で入手して試せる公式リポジトリです。READMEのベンチマークセクションで、他のツールとの比較数値も確認できます。

筆者アン・グァンソプ(安光涉)は世宗大学校経営学科教授であり、INLEVEL9のリードコンサルタントである。大学では経営データ管理、ビジネスアナリティクスなど統計およびデータ分析を教える一方、現場ではGTM戦略とAI戦略コンサルティングを主導し、技術とビジネスの接点を設計している。AI対話システムの記憶アーキテクチャ(HEMA)研究で学術論文を発表し、毎日グローバルなAI論文をキュレーションするDaily Arxivプロジェクトを運営している。高麗大学校技術経営専門大学院修士課程とKMBAを卒業した。著書に『考えを委ねる人々:ホモ・ブレインレス』がある。
각주
-
RAG(Retrieval-Augmented Generation、検索拡張生成):質問に関連する外部資料を検索し、AIが回答する際に参照させる方式です。抽出品質だけでなく、検索や文書分割、回答生成など複数の段階が結果に影響を与えます。 ↩
-
文書構造の知識:見出し・本文・表など文書の構成要素同士の関係や読み取り順序を見分けるために使われる知識です。 ↩
-
Apache 2.0(Apache License 2.0):商業利用と修正・再配布を許可するオープンソースライセンスです。ライセンス・著作権表示の維持や変更箇所の明示など、定められた条件に従う必要があります。 ↩
-
MCP(Model Context Protocol):AIアプリケーションが外部ツールやデータに接続する際に使用される公開プロトコルです。 ↩

あなたの視点が次の号をつくります
この号で最も共感した点、あるいは違う経験をした点はどこですか。