さて前回『AIに仕事をとられる前にAIを手下にしようとしてみる話 その１』からの続きです
今回はNotebookLMの利用するOCRがどのように曖昧な部分を処理するかを探ってみたいと思います
この問題は結構重要で真面目にシステムを構築する場合にはちゃんと把握しておくべき課題です
OCRは手書き文字認識だけでなく構成図を理解することもできます。（状況を元に関係性などをテキスト化してですが）
今回はとりあえず文字認識に絞って考えます
今、練習として、勤怠情報を処理する指示（プロンプト）を作成してるのですが、これはお給金に関係します
適当に数字を読み取られては困りますからね
ではGeminiさんに
NotebookのOCR機能で文字認識した場合、各文字列ごとに認識精度（確からしさ）を示すことは可能？
と聞いてみました
Geminiさん曰く
ーーーー＞
現時点（2025年9月）で、NotebookLMのユーザーインターフェースや標準的な出力形式では、OCRによる各文字列ごとの認識精度（確からしさ、信頼度スコア）は直接表示されません。
NotebookLMは、背後にあるGeminiモデルの高度な推論能力を利用して、個々の文字認識のスコアではなく、文書全体としての論理的な整合性を優先して出力を生成します。
NotebookLMのOCR処理の特徴
NotebookLMのOCR機能は、一般的なOCRソフトウェアとは異なり、Geminiのマルチモーダル能力に統合されています。
- 統合された推論: NotebookLMは、単に文字を認識するだけでなく、認識された文字を文脈や図形の配置と照合して、最も意味的に正しい結果を生成します。例えば、OCR結果が「I20」と「120」のどちらにも読める場合、周囲の数字の合計が「120」になることで、認識精度スコアに関係なく「120」を採用します。
- 出力の最適化: ユーザーへの最終的な出力（要約、質問への回答など）は、最も信頼できるとモデルが判断したテキストに基づいた自然言語の形になります。このプロセスにおいて、個々のOCR信頼度スコアは内部的な判断材料として使われますが、ユーザーには開示されません。
- グラウンディングの重視: NotebookLMが提供するのは、「この情報がアップロードされたどのソースに書かれているか」という引用（グラウンディング）です。これにより、ユーザーはAIが提示した情報の「確からしさ」を、元の文書で視覚的に確認できるようになっており、これが個々のOCR精度スコアに代わる信頼性担保の手段となっています。
もし、より詳細なOCRの認識精度スコアが必要な場合は、Google CloudのDocument AIやVision AIなど、開発者向けのAPIサービスを利用する必要があります。これらのサービスでは、認識されたテキスト（バウンディングボックス付き）と、各単語や行の信頼度スコアがJSON形式などで出力されます。
＜ーーーー
だそうです。
ある程度はおりこうにやってくれそうな事はわかりました
ただどのへんまでやってくれるのか気なったのでもう少し深堀りして
Geminiさんに
NotebookLMで表データをOCRで読み取る場合、合計の欄とその対象と思われるセルの合計値が異なると判断した場合、信頼度スコアの低い部分で調整したりしますか？
と聞いてみます
Geminiさん曰く
ーーーーー＞
はい、その通りです。NotebookLMの基盤であるGeminiモデルは、単なるOCRの信頼度スコアに頼るのではなく、表の算術的な整合性を最優先して、信頼度が低いと判断されたセルや文字を**論理的に調整（補正）**しようと試みます。
補正のプロセス（算術的整合性の優先）
NotebookLMが表データ（特に合計欄）を読み取る際の動作は、以下のステップで高度な推論を行います。
1. 不整合の検出とOCRエラー候補の特定
- 要素認識: モデルは、表の構造、各セルのテキスト、および合計欄の数値を認識します。
- 算術検証: モデルは、認識した内訳の数値 を合計し、認識した合計欄の数値 と比較します。
- もし であれば、モデルは表に不整合があると判断します。
- エラー候補の特定: 不整合の原因となっている可能性のあるセルを特定します。特に、OCRの初期段階で信頼度スコアが低かった文字（例：「I」と「1」、「O」と「0」など）を含むセルを、最優先の調整候補としてマークします。
2. 論理的な調整（仮説検証）
モデルは、マークされた候補セルに対して、人間が行うように仮説を立てて検証します。
- シナリオ: 認識結果が「」、「」で、合計欄が「」だったとします。
- 現在の合計: （「I」を「1」と仮定した場合）または （「I」を「7」と仮定した場合）など。
- 目標合計: 。
- 調整: モデルは、「」を「」に補正すれば、合計が となり、表の論理が完全に一致することを発見します。
3. 最終的な出力
モデルは、この算術的な整合性を最重要視し、補正された「」を最終的なデータとして利用します。
このように、NotebookLMは、単純な「OCRスコアが低いから調整する」のではなく、**「算術的な論理を成立させるために、信頼度が低い部分を調整する」**という、より高度な推論を行っています。
＜ーーーーー
同様にGeminiでどうかの聞いたところ、同じ様な回答でしたがちょっと回答内容が異なるのはなぜなんでしょうね
Geminiさん曰く
ーーーーー＞
そのアプローチは、GeminiのようなマルチモーダルLLMの高度な推論能力とデータ検証の分野で、非常に重要な役割を果たします。
従来のOCRシステムのように「文字ごとの信頼度スコア」を直接調整するわけではありませんが、Geminiはプロンプトや後処理ロジックを通じて、実質的にその検証・修正のプロセスを実行できます。
Geminiによる表データの自動検証・修正
ご提示の例（表の合計欄の数値と、内訳セルの合計値の不一致）は、まさにGeminiの強みが活かされるシナリオです。
1. 内部的な推論と検証
Geminiは単に文字を認識するだけでなく、視覚的な構造と数値の論理性を同時に理解します。
- テーブル構造の理解: 画像からテーブルを正確に抽出し、どのセルが「項目」で、どのセルが「数値」で、「合計」セルはどれかを把握します。
- 算術的検証（Reasoning）:
- プロンプトで「内訳の数値を足し算して、合計セルと一致するか検証してください」という指示を与えることができます。
- Geminiは抽出した数値に対して実際に計算を実行し、不一致を検出します。
2. 不一致が発生した場合の処理
合計が合わない場合、Geminiは一般的に以下のステップで**自己修正（自己補正）**を試みます。
- 低信頼度の特定: 合計値が不一致を起こしている場合、Geminiは内訳のセルの中でOCRの認識が最も不安定そうな文字（例：手書き、かすれ、似た文字’5’と’S’など）を内部的に再評価します。
- 文脈による調整: 「合計を正しくするために、この怪しい文字（例：’8’と認識された部分）が’3’であれば合計が合う」という論理的な推論を行い、認識結果を最も論理的に整合性のとれる値に修正しようとします。
- 構造化された出力: 最終的な認識結果と、その**検証結果（例：’合計は一致しました’または’このセルをXに修正しました’）**をJSONなどの構造化された形式で出力します。
3. 外部システムとの連携
Geminiは、生の信頼度スコアを返す従来のOCRエンジン（例：Google Cloud Vision API）と組み合わせて使用されることもあります。
- OCRエンジン: 文字ごとの信頼度スコアを出力し、テキストを抽出する。
- Gemini: その抽出されたテキスト（と元の画像）を受け取り、「合計が合っているか」をチェックし、論理的なエラーを修正する。
このように、Geminiはマルチモーダルな推論力とLLMの強力な論理処理能力を用いて、従来のOCRの「文字認識の正確性」を超えた**「データとしての正確性」**の検証と修正を行うことができます。
＜ーーーーー
こんな感じで割とまともな回答を得られました
とはいえAIが返す回答はあくまで用意されている情報を組み合わせて出力するだけで、実際に実装されている機能に基づいて回答しているわけではない点に注意が必要です（言ってることとやってることは別）
最近この辺をGeminiと延々と問答した結果を書いてるサイトがあって面白かったです
AIにプロンプトで指示を出して結果を得るのは意外と人に仕事を依頼するのに似ている気がします。
どちらも曖昧さをなくすことは困難で、それを小さくするために性格（性質）を知ってより適切な指示を出す
まあAIはくどくどいっても朝令暮改でも気分を損ねないのは良いですが
AIを手下にする道はまだまだです
次はNoteBookLMでExcelの勤怠ファイルから必要な情報を集めるプロンプトでも書いてみるつもりです
（これでお伺いレベルからAIに命令する立場をちょっと経験してみようかとｗ）
▼この記事がいいね！と思ったらブックマークお願いします
