仕事で、こんな場面に心当たりがあるはずです。後で見返すためにチャットのやり取りやWebページをスクリーンショットとして残したのに、いざ必要になったとき、その画像内の文字は検索できない。あるいは、署名・捺印済みの重要な契約書を原本として記録に残すためにPDF化したものの、後で内容を確認したり一節を引用したりしようとすると、検索もコピーもできず、ページをめくりながら手で打ち直すしかない。
Gety の内蔵 OCR は、この問題を解決するためのものです。
その効果を確かめるために、私たちは 2 つの公開データセット（MDPBench と OmniDocBench）のドキュメント画像を使い、自分のコンピュータ上で動作する OCR に焦点を当てた独自の評価を構築しました。比較対象には、実際のワークフローでユーザーが出会いやすい主要なローカル OCR の選択肢を選びました。オープンソースで最も強力な候補である PaddleOCR (PP-OCRv6)、ベースラインとして長く使われてきた Tesseract、そして macOS と Windows に標準搭載されている OCR です。Gemini のようなクラウド OCR やクラウドモデルは、あえてこのラインアップに含めていません。それらはアップロード、API 呼び出し、インターネット接続、そして多くの場合は従量課金を必要とします。一方、Gety は完全にオンデバイスで動作します。
結果から、Gety の内蔵 OCR には明確な強みが 2 つあります。
- ローカルで動作するオンデバイス OCR エンジンの中で、Gety は多言語精度で 1 位となり、17 言語全体でも最も高い総合結果を示しました。
- 比較対象のオンデバイスモデルと比べてメモリ使用量は約 5 分の 1 で、バックグラウンドで常時動作する OCR やリアルタイムのインデックス化を現実的にします。
1. 多言語：Gety が最も大きく差をつける領域
多くのエンジンは、英語やフランス語なら十分にこなします。問題が始まるのは文字体系が変わったときです。韓国語、ロシア語、タイ語、ヒンディー語に切り替えると、多くのモデルは 0.9 以上から 0.2 や 0.1 まで落ち込み、実用にはかなり厳しい精度になります。MDPBench のドキュメント画像を使った 17 言語での各モデルの成績は次のとおりです：
| 言語 / 指標 | Gety OCR (built-in) | Apple Vision (built-in) | PP-OCRv6(small) | PP-OCRv6(tiny) | Windows OCR | Tesseract |
|---|---|---|---|---|---|---|
| 総合 (F1) | 0.903 | 0.881 | 0.724 | 0.686 | 0.609 | 0.541 |
| ラテン文字系（平均） | 0.966 | 0.940 | 0.967 | 0.957 | 0.847 | 0.901 |
| 英語 | 0.978 | 0.962 | 0.972 | 0.972 | 0.882 | 0.919 |
| ドイツ語 | 0.959 | 0.967 | 0.992 | 0.991 | 0.923 | 0.962 |
| フランス語 | 0.947 | 0.799 | 0.982 | 0.977 | 0.795 | 0.940 |
| スペイン語 | 0.920 | 0.923 | 0.927 | 0.923 | 0.819 | 0.872 |
| イタリア語 | 0.980 | 0.976 | 0.985 | 0.979 | 0.887 | 0.932 |
| ポルトガル語 | 0.978 | 0.983 | 0.980 | 0.972 | 0.797 | 0.840 |
| オランダ語 | 0.994 | 0.924 | 0.995 | 0.995 | 0.967 | 0.974 |
| インドネシア語 | 0.974 | 0.966 | 0.987 | 0.987 | 0.892 | 0.959 |
| ベトナム語 | 0.967 | 0.958 | 0.884 | 0.814 | 0.661 | 0.716 |
| 非ラテン文字系（平均） | 0.832 | 0.814 | 0.452 | 0.382 | 0.343 | 0.136 |
| 中国語（簡体） | 0.946 | 0.912 | 0.965 | 0.957 | 0.800 | 0.180 |
| 中国語（繁体） | 0.924 | 0.805 | 0.939 | 0.862 | 0.853 | 0.142 |
| 日本語 | 0.916 | 0.804 | 0.924 | 0.525 | 0.454 | 0.173 |
| 韓国語 | 0.970 | 0.961 | 0.276 | 0.248 | 0.211 | 0.190 |
| ロシア語 | 0.954 | 0.960 | 0.155 | 0.106 | 0.096 | 0.102 |
| タイ語 | 0.951 | 0.974 | 0.155 | 0.137 | 0.150 | 0.125 |
| ヒンディー語 | 0.958 | 0.136 | 0.191 | 0.178 | 0.140 | 0.147 |
| アラビア語 | 0.039 | 0.962 | 0.011 | 0.046 | 0.037 | 0.031 |
注目すべきは非ラテン文字系の行です。オープンソースのモデルが崩れ、0.1 〜 0.4 の範囲に沈み込む一方で、Gety は 0.832 を保っています。あなたにとってこれは、中国語、日本語、韓国語、ロシア語のドキュメントを検索できるか、それとも文字体系が変わっただけでその内容が検索からほとんど見えなくなるかの違いです。Gety なら、こうした言語のドキュメントが検索の死角になりにくくなります。
写真はまた別の話です。入力がきれいなデジタルファイルではなく、文書を撮影した写真で、ぶれ、傾き、光の反射がある場合、どのモデルも苦戦します：
| モデル | デジタル生成 (F1) | 撮影 (F1) |
|---|---|---|
| Gety OCR (built-in) | 0.903 | 0.322 |
| Apple Vision (built-in) | 0.881 | 0.421 |
| PP-OCRv6(small) | 0.724 | 0.301 |
| PP-OCRv6(tiny) | 0.686 | 0.289 |
| PP-OCRv5 mobile | 0.707 | 0.278 |
| PaddleOCR (PP-OCRv4) | 0.630 | 0.172 |
| Windows OCR | 0.609 | 0.185 |
| Tesseract | 0.541 | 0.192 |
この条件で本当に強いモデルはまだありません。スコアは軒並み 0.9 台から 0.2 〜 0.4 の帯へと落ち込み、Apple Vision の 0.421 が最高値です。Gety はオープンソースモデルをわずかに上回りますが、日常的な検索では、この列は数字ほど大きな意味を持ちません。実際に検索したいファイルの多くは、傾いた写真ではなく、きれいなスクリーンショットやスキャンです。それが左の列です。
2. 複雑なレイアウト：最良のオープンソースモデルと同じ上位層
言語は 1 つの軸にすぎません。もう 1 つの軸がレイアウトです。段組み、表、繰り返されるヘッダーやフッター。こうしたドキュメントでは、弱いモデルは行を落とし始めたり、順序を入れ替えてしまったりします。OmniDocBench は、まさにそこに負荷をかけるように作られています：
| モデル | レイアウト精度 (F1) |
|---|---|
| Gety OCR (built-in) | 0.963 |
| PP-OCRv6(small) | 0.968 |
| PP-OCRv6(tiny) | 0.963 |
| Apple Vision (built-in) | 0.948 |
| Windows OCR | 0.855 |
| Tesseract | 0.538 |
Gety の 0.963 は、PP-OCRv6 small（0.968）に 0.5 ポイントほど及びませんが、使用中に感じ取れるような差ではありません。両モデルは事実上トップで並んでおり、どちらも標準搭載のシステムエンジンを大きく引き離しています。
3. 同じ精度を、わずかなフットプリントで
うまく読めることと、一日中動かし続けられるほど軽くうまく読めることは、別の話です。同じマシン、同じ入力、同じスレッド予算、CPU 上で計測しました：
| モデル | 多言語精度 (F1) | 1 ページあたりの処理時間（中央値） | 1 ページあたりのピークメモリ |
|---|---|---|---|
| Gety OCR (built-in) | 0.903 | 862 ms | 908 MB |
| PP-OCRv6(tiny) | 0.686 | 607 ms | 4736 MB |
| PP-OCRv6(small) | 0.724 | 2594 ms | 6304 MB |
Gety は 1 ページあたり約 908 MB で済みます。PP-OCRv6 の tiny と small のビルドはそれぞれ 4.7 GB と 6.3 GB を必要とし、5 〜 7 倍も多くなります。これは、常駐させられるモデルと、必要なときに起動する用途に向いたモデルとの違いです。Gety は軽いからこそ OCR を常に動かしておけます。新しいファイルが届くたびにそれを捉え、あなたが指一本動かさなくてもインデックス化します。
（Apple Vision と Windows OCR は、それぞれのプラットフォーム内で異なるハードウェア上で動作するため、メモリや速度の比較は同じ土俵での比較になりません。これらは精度の表にのみ登場します。）
4. テスト対象と比較対象
データセット
私たちは 2 つの公開データセットのドキュメント画像を使い、それらを軸に独自の評価を構築しました。それぞれ別の問いに答えるデータセットなので、あえて分けて報告し、あまり意味のない 1 つの数値にはまとめていません：
| データセット | 答える問い |
|---|---|
| MDPBench | 17 言語にわたって、きれいなページと撮影されたページの両方で精度が保たれるか？ |
| OmniDocBench | レイアウトが複雑になっても精度を保てるか？ |
念のため明確にしておくと、私たちはこれらのデータセットを実際のドキュメントの供給源として使いました。評価方法、指標、そして比較対象のモデルはすべて私たち独自のものであり、データセットの作者が公開している公式評価とは異なります。
採点方法
私たちは OCR の出力を、レイアウトに依存しない文字レベルの F1 で採点します。これは、テキストが正しく認識されたかどうかだけを測るものであり、レイアウト、改行、段落構造、あるいはテキストがページ上のどこに位置するかは測りません。
レイアウトに依存しないようにしているのは、検索、コピー、インデックス化といった重要な用途にとって大切なのは、すべての文字が正しく読み取られたかどうかであって、レイアウトが再現されたかどうかではないからです。すべて正しいけれど順序が違っていたり改行が異なっていたりするテキストが、それだけで減点されるべきではありません。これは OCR のテストであって、レイアウトのテストではありません。
各ページについて、OCR の出力を人手でラベル付けされたテキストと比較し、次を計算します：
採点の前に、正解データと OCR の出力はどちらも同じ正規化処理を通ります。Unicode 正規化、不可視文字の除去、空白の統一、そしてヘッダー、フッター、ページ番号といったページ装飾の除去です。
文字のマッチングには多重集合による計数を用います。複数回出現する文字は、その回数だけ数えます。これにより、読み取り順序、改行、段落分割の違いがスコアに影響することを防ぎ、指標は OCR がページの文字を正しく読み取れたかどうかに集中し続けます。
最終的な数値はページごとの F1 で、言語およびデータグループにわたってマクロ平均を取っています。完全なレポートでは、bootstrap による 95% 信頼区間も示しています。
比較対象
比較にあたっては、実際のワークフローでユーザーが出会いやすい主要な選択肢を使いました：
- PaddleOCR (PP-OCRv6)、オープンソースが提供できる最高峰。tiny、small、medium が用意されていますが、私たちはオンデバイス向けの 2 つのビルド、tiny と small を実行しました。medium はサーバー GPU 向けに設計された 34.5M パラメータのモデルであり、オンデバイスの CPU テストに持ち込むのは筋違いの比較になります。
- Tesseract、昔ながらの働き者で、どこにでも標準で存在し、多くの人が知るベースラインです。
- Apple Vision と Windows OCR、何もインストールしなくてもすでに手元にある OCR です。
5. 精度は土台。使いやすさこそが要点。
数字は、Gety が正確に読むことを物語っています。しかし精度はあくまで前提であり、これらすべてが重要である理由そのものではありません。
普通の OCR ツールをどう使うか考えてみてください。
画像を見つける -> OCR ツールで開く、またはドラッグする -> 手動で認識を開始する -> 結果を待つ -> 使えるテキストを得るまず、抜き出す価値のあるテキストがあると気づく必要があります。それからファイルを見つけ、別のツールに持ち込み、認識を開始し、待って、結果を使う。そのほとんどの場合、この一連の流れはそもそも始まりません。スキャン、スクリーンショット、撮影された契約書は、届いた日からただそこに置かれたまま、検索から見えないままです。
そのギャップこそ、Gety が埋めようとした問題のすべてです。OCR はバックグラウンドで動作するので、ファイルが届いた瞬間に、自動的に読み取られインデックス化されます。変換するものも、クリックするものもありません。検索ボックスに入力すれば、画像の中のテキストがそこにただ存在します。
つまり、精度は何かが見つけられるかどうかを決め、バックグラウンドで静かに動き続けることが、それが実際に見つかるかどうかを決めます。私たちは、もう 1 つの OCR エンジンを世に出そうとしたわけではありません。「この画像の中の言葉は検索できない」ということが、あなたのコンピュータで起こらなくなるようにしようとしたのです。
これらは私たち自身の内部的な結果です。公開データセットである MDPBench と OmniDocBench のドキュメント画像をテスト素材として使用しましたが、評価方法と指標は私たち独自のものであり、データセットの作者が公開している公式の評価とは異なります。各データセットにはそれぞれ独自のライセンスと利用規約があり、一部は研究目的に限られます。ここでは調査結果を報告しているのであって、いかなるサンプルも再配布していません。