OpenOCR、Gemini 3.1 Flash-Liteをはじめ全エンジンで空の結果を検知可能に
2026年10月8日。 OpenOCRは、エンジンがページを読み取ったにもかかわらず何も返さなかった場合を検知できるようになりました。一見成功したかのように見える空の結果ではなく、理由を明記した明確なエラーが返されます。試行に対してプロバイダーから請求された以上の金額が請求されることはなく、複数ページのPDFでは正常に読み取れたすべてのページが保持されます。
この挙動はGemini 3.1 Flash-Liteで確認され始めましたが、この保護機能はOpenOCR上のすべてのエンジンに適用されます。
検知された事象
当社のモニタリングにより、OpenOCRで最も利用されているエンジンの一つであるGoogleのGemini 3.1 Flash-Liteにおいて、ある傾向が浮き彫りになりました。実際の文書（明瞭に印刷されたテキストを含む帳票、カード、書簡など）のごく一部において、GoogleのAPIがリクエストの成功を返しているにもかかわらず、テキストがまったく返されない事象が発生していました。過去30日間で、この事象はFlash-Liteで処理されたページの約3%で発生しており、プラットフォーム全体で確認された空の結果のほぼすべて（約97%）を占めていました。
数件程度のリクエストであれば3%は見落とされがちです。しかし大規模な文書処理においては、ワークフローが大量の良好なテキストを受信しつつも、読み取り可能なはずのページを取りこぼしていることを意味します。プロバイダー側が成功シグナルを返していたため、これらの欠落は正常に完了した処理のように見えていました。
リトライを試みても効果はほとんどありませんでした。同一の画像に対して80〜93%の確率で再び空の結果が返ってきたため、リクエストを再試行することはほぼ時間の浪費にしかなりませんでした。
理由が明記された拒否については、別のエンジンに切り替えるのが次のステップとなります。
変更後のレスポンス形式
この変更前は、判読可能なページであっても抽出テキストが存在しないまま成功ジョブとなっていました。関連するフィールドを示す簡略化した例は以下のとおりです。
{
"status": "succeeded",
"extracted_text": ""
}
現在は、プロバイダーによる拒否が明示されるようになりました。以下はGoogleから試行費用が請求された場合の簡略化した例であり、リクエストにはその実費のみが計上されます。
{
"status": "failed_charged",
"error_code": "provider_refused",
"cost_debited": 0.000327,
"provider_error": "Google declined to read this image (reason: SAFETY). Sending it to this engine again will give the same result; try a different engine."
}
ジョブは、利用可能なOCRテキストが配信されたと見なすことはなくなりました。請求は、後述のとおりプロバイダーの実際の請求額に準拠します。
単一エンジンだけでなく、すべてのエンジンに対応する設計
今回の事象はGeminiで検知されましたが、この失敗パターンはGoogle特有のものではありません。どのようなビジョンモデルでも起こり得ることであり、他のいくつかのエンジンでも稀に発生していました。そのため、単一のエンジンのみに対処するのではなく、OpenOCR全体としてあらゆるエンジンからの空の応答の処理方法を変更しました。
白紙の応答ではなく明確な回答を返す。 空の結果は、以下の2つのエラーコードのいずれかを含む失敗として報告されます。
provider_refused: セーフティフィルターなど、プロバイダーが処理を拒否し、その理由を返した場合。エラーには理由が明記され、同一のエンジンに再度ページを送信しても同じ結果になることが通知されます。provider_empty: モデルが理由を示さずに何も返さなかった場合。OpenOCRはエラーを報告する前に、自動的にもう一度ページの読み取りを試行します。
これらのエラーコードにより、アプリケーション側で明示的な拒否と原因不明の空応答を区別できるようになります。後者については、OpenOCRが失敗を返す前に追加の再試行を行います。
公正な請求体系。 プロバイダーから当社へ試行費用が請求された場合、お客様にはマージンを上乗せすることなく、事前見積もりを超えることのない実費のみをご負担いただきます。プロバイダーからの請求がなかった場合は、費用は一切発生しません。これは、プロバイダーを直接呼び出した場合と同じです。
PDFの正常なページを保持。 30ページのPDFのうち1ページが空の結果となった場合でも、残りの29ページはそのまま取得でき、空のページにはページ番号が付与されます。ドキュメント全体が失敗となるのは、すべてのページでテキストが返されなかった場合のみです。
例として、30ページのスキャン文書をFlash-Liteに送信した場合を考えてみます。1〜11ページはテキストが返され、12ページが空、13〜30ページはテキストが返されたとします。OpenOCRは、12ページを指定した警告とともに正常に処理された29ページを返します。この12ページだけを別のエンジンに再送することも、手動で確認することも可能です。請求額が見積もりを超えることはありません。
すべてのエンジンを常時監視。 各エンジンの空結果発生率を継続的に追跡しているため、他のモデルで同様の事象が発生し始めた場合でも、1時間以内に検知できます。
Geminiのエラー理由が可視化
Gemini 3.1 Flash-Liteは現在、GoogleのネイティブAPIで稼働しています。以前使用していたエンドポイントでは、これらの拒否は単に「other」としか報告されませんでした。ネイティブAPIではページが拒否された理由が返されるようになり、その理由がエラー情報として利用者に届くようになりました。
また、応答が滞ったリクエストのタイムアウトを3分から60秒に短縮したため、より迅速にエンジンを切り替えられるようになりました。通常のFlash-Liteのレイテンシは約3.6秒、99パーセンタイルは約12秒です。180秒のタイムアウトは観測された処理時間から見ても長すぎましたが、60秒であれば通常範囲を超えたケースにも十分対応できます。
今後の監視体制
各エンジンの空結果発生率を毎時追跡し、5%に達した時点でチームにアラートを通知します。特定のモデルが白紙の応答を返していても、全体の成功率は正常に見えてしまうことがあります。このエンジンごとの監視シグナルにより、調査すべき箇所を的確に特定できます。
開発者向けの情報
既存のインテグレーションが破損することはありません。単に「空の成功結果」を受信しなくなるだけです。失敗時にリトライを行う設計にしている場合は、エラーコードを確認してください。provider_refusedのページは、再試行するのではなく別のエンジンにルーティングすることをお勧めします。OpenOCRでは単一のAPIキーと共通の残高で多数のエンジンを利用できるため、engineフィールドの文字列を1箇所変更するだけで対応できます。
PDFの場合は、返却されたテキストとともにページの警告情報を保持しておくことで、欠落箇所を特定し、そのページをどのように処理するか判断できます。
よくある質問
既存のインテグレーションは破損しますか？ いいえ。抽出テキストのないページが正常なOCR結果として扱われることがなくなるだけです。コード側ですべての失敗をリトライしている場合は、error_codeを参照して同一エンジンでのprovider_refusedリクエストの再試行を回避してください。
拒否されたページの費用は発生しますか？ プロバイダーからOpenOCRに試行費用が請求された場合のみ発生します。マージンなしの実費のみをお支払いいただき、見積もりを超えることはありません。プロバイダーからの請求がなかった場合は無料です。
なぜ自動でエンジンを切り替えないのですか？ モデルはお客様が意図して選択したものだからです。別のエンジンでは価格や出力形式が異なる場合があります。そのため、発生した事象をお伝えしたうえで、お客様自身に判断を委ねています。
どのエンジンが影響を受けますか？ この挙動は主にGemini 3.1 Flash-Liteで確認されており、過去30日間のプラットフォーム全体の空結果の約97%を占めていました。他のいくつかのエンジンでも稀に発生しています。現在、検知および報告機能はすべてのエンジンをカバーしています。
白紙の区切りページはどう処理すべきですか？ 既知の区切りページは、ドキュメントワークフロー側で処理してください。白紙の用紙やスキャンの裏面などに対しては、そうしたページ専用のOCRエンジンを使用してください。当社では現在、ビジョンモデルが白紙ページに対してテキストを捏造（ハルシネーション）するケースについても検証を行っています。
次の取り組み：テキスト捏造（ハルシネーション）の測定
今回のリリース検証中、完全に白紙のページをGemini 3.1 Flash-Liteに入力してみました。何も返さないどころか、4回すべてでテキストを捏造しました（ビジネスに関する段落、数学の証明、顧客への手紙、そして「THE END OF THE CHAPTER」という文言）。これはGoogleの双方のエンドポイントで発生したため、モデル自体の挙動に起因しています。
テキストを捏造するエンジンは、出力が一見本物に見えるため、何も返さないエンジンよりも検知が困難です。そこで当社は、白紙ページに対してどのOCRモデルがテキストを誤認するかを測定する公開テストHallucinationBenchをOpenOCRベンチマークに追加します。測定結果はゴーストアイコンとともにOpenOCRランキングに掲載され、すべてのエンジンにおけるテキスト捏造率が精度指標と並んで公開される予定です。それまでの間、区切りページやスキャンの裏面などの白紙ページが文書に含まれる場合は、それらのページには専用のOCRエンジンをご利用ください。