公開スコアより自社データ！マルチモーダルLLM画像認識精度の現場流ベンチマーク検証法

「ChatGPTの画像認識精度がすごいらしい」「Geminiモデルは動画も理解できる」といったニュースをよく目にするようになりました。システム開発エンジニアとして、不動産テック領域で画像認識AI実装や業務自動化ツール構築に携わる藤井麻衣の視点からも、VR内見や間取り図の自動読み取りなど、画像認識技術への期待は日に日に高まっていると感じています。

でも、いざ自社のプロダクトや業務フローに組み込もうとしたとき、こんな壁にぶつかりませんか？

「カタログスペックは高いのに、なぜかうちのデータだと全然使えない……」

実はこれ、AI導入の初期段階で最も陥りやすい罠なんです。MMMU（Massive Multi-discipline Multimodal Understanding）などの公開ベンチマークは、あくまで「一般的な知識」や「綺麗なデータ」に対するテスト結果に過ぎません。現場にある「手ブレした写真」や「独自フォーマットの帳票」を正しく読める保証はどこにもないのです。

本記事では、エンジニアではないDX担当者やプロダクトマネージャーの方でも実践できる、「現場で本当に使えるモデル」を見極めるための定性的な評価ノウハウを解説します。Pythonコードを書く必要はありません。必要なのは、少しの「意地悪な視点」と、現場への深い理解です。

このティップス集について：なぜ「公開ベンチマーク」だけでは不十分なのか

まず最初に、なぜわざわざ手間をかけて独自のテスト（PoC検証）をしなければならないのか、その背景を解説します。

汎用スコアと業務特化精度のギャップ

AIモデルの性能を示すリーダーボード（順位表）を見ると、正答率80%や90%といった高い数字が並んでいます。しかし、この数字は「一般的な画像（猫、風景、有名なランドマークなど）」に対する理解度を含んだ平均点です。

例えば、不動産の実務では「築30年の和室のふすまの汚れ」や「手書きで修正された間取り図の注釈」といった、極めてニッチな情報を読み取る必要があります。汎用的なテストで90点を取る優等生モデルでも、こうした特化タスクでは急に30点しか取れない、なんてことは日常茶飯事です。

「なんとなくすごい」で導入して失敗するパターン

「最新モデルだから大丈夫だろう」と見切り発車で開発を進めると、後で痛い目を見ます。よくある失敗例がこれです。

• 事例: 設備点検の自動化プロジェクト
• 失敗: デモ用の綺麗な写真では完璧に動作したが、現場作業員がスマホで撮った「薄暗くてピンボケした写真」では誤検知を連発。結局、人間が全て再チェックすることになり、工数が逆に増えた。

このような事態を防ぐために必要なのが、自社データを使った小規模テスト（Micro-Benchmarking）です。大規模なシステムを作る前に、まずは手元の数十枚の画像で「本当に使い物になるか」を見極める。そのための具体的なコツを、5つのティップスにまとめました。

ティップス①：評価用データセットは「理想的な画像」と「最悪な画像」を1:1で混ぜる

テスト用の画像を集めるとき、皆さんはどんな画像を選びますか？ 無意識に「見やすい画像」「代表的な画像」を選んでしまっていないでしょうか。

綺麗なサンプル画像だけでテストしてはいけない

モデルの選定時に最も重要なのは、「どれだけ正解できるか」ではなく「どんな条件で失敗するか」を知ることです。照明が完璧で、対象物が中央に写っている画像なら、今の高性能LLMはどれも正解して当たり前です。これではモデル間の差がつかず、評価になりません。

現場のノイズ（照明反射、手ブレ、画角ズレ）を含める重要性

実務でAIを使う場合、入力されるデータは決して綺麗ではありません。実務の現場で間取り図解析のテストをする際は、以下のような「悪条件（ノイズ）」を含んだ画像を意図的にデータセットに混ぜることが推奨されます。

• 照明反射: 光が反射して文字の一部が白飛びしている画像
• 歪み・傾き: スキャナーではなく、スマホで斜めから撮影した書類
• 低解像度: メッセンジャーアプリ等で送受信され、画質が劣化した画像
• 見切れ: 対象物の一部が画面外にはみ出している画像

これらを「理想的な画像」と半々（1:1）の割合で混ぜてください。そして、悪条件の画像に対して「読めません」と正直に言うのか、それとも無理やり間違った答えを出すのかを観察します。この「失敗の仕方」にこそ、そのモデルの実用性が表れるのです。

ティップス②：OCR性能だけでなく「空間認識」と「文脈理解」を分けて評価する

「画像認識」とひとくくりに言いますが、マルチモーダルLLMが画像を見るときの脳みその使い方は、実はタスクによって全く異なります。特に不動産の間取り図や設備図面のような複雑なドキュメントを扱う場合、単一の指標で評価することは避けるべきです。

文字が読めることと、意味が分かることは違う

エンジニアの視点から、評価を行う際はモデルの能力を以下の3つに分解してテストすることをお勧めします。

1. OCR能力（文字認識・構造化）:
   画像内のテキストを正確に文字起こしできるか。さらに、最新のトレンドとして重要視されているのがETL（Extract, Transform, Load）能力です。単に文字を羅列するだけでなく、「価格」や「面積」といった項目を正しく認識し、CSVやJSONなどの構造化データとして出力できるかを評価します。

2. 空間認識（Spatial Reasoning）:
   物体の位置関係（右、左、奥、手前）や座標を理解できるか。例えば、間取り図で「キッチンの隣に何があるか」を正しく把握する能力です。

3. 文脈理解（Contextual Understanding）:
   画像全体の状況や、写っているものの意味を説明できるか。「この部屋はファミリー向けか、単身向けか」といった推論が含まれます。

例えば、契約書や帳票の読み取りなら「OCR能力」と「構造化能力」が最優先ですが、内見ロボットや3Dモデリング支援なら「空間認識」が重要になります。これらを混同して「なんとなく賢い」と評価するのは危険です。

位置関係（右隣、下部）の指示に対する正確性をテストする

具体的なテスト方法として、バウンディングボックス（検出枠）の座標指定や、相対位置の質問を投げかけるアプローチが有効です。

• 質問例: 「画像の『右下』にある設備名称は何ですか？」
• 質問例: 「赤いソファの『手前』にあるテーブルの形状は？」

言語モデルベースの画像認識AIは、実はこの「空間的な位置関係」が苦手な傾向にあります。最新のモデルであっても、専用のAI-OCR製品が持つような厳密な座標特定（位置合わせ）機能と比較すると、精度が劣るケースは珍しくありません。

特に、業務特化型のAI-OCRでは、レイアウト定義やマスキング機能などが強化され、座標レベルでの制御が進んでいますが、汎用的なマルチモーダルLLMは「大まかな位置」の把握に留まることが多いのが現状です。自社の業務で「正確な位置情報」が不可欠な場合は、LLM単体で解決しようとせず、位置特定に特化したモデルや専用ツールとの組み合わせも視野に入れて評価を行ってください。

ティップス③：ハルシネーション誘発テストで「知ったかぶり」度合いを測る

生成AI最大のリスク、それが「ハルシネーション（幻覚）」です。もっともらしい顔をして嘘をつく現象ですが、画像認識でもこれは起こります。

存在しない要素について質問してみる

精度の高いモデルを選ぶというよりは、「リスクの低いモデル」を選ぶためのテストです。画像に写っていないものについて質問をする「意地悪テスト」を行うことが、リスク評価として有効です。

• 画像: 何も置かれていない会議室の机
• 質問: 「机の上に置いてあるペットボトルの銘柄を教えてください」

ここで、ダメなモデルは確率的に高い単語を拾って「サントリーの天然水です」などと平気で答えます。逆に優秀なモデルは「画像内にペットボトルは確認できません」と回答します。

「分かりません」と言えるモデルかを確認する

業務利用において最も恐ろしいのは、「分からない」と言わずに適当な情報をでっち上げることです。これを防ぐ能力を「拒否能力（Refusal capability）」と呼びます。

検品業務などで「傷がないのに傷がある」と言われたり、「型番が読めないのに適当な数字を入れる」といった挙動は致命的です。あえて解像度を極端に落とした画像を読ませて、「画像が不鮮明で判断できません」というエラーメッセージを出せるかどうかも、重要な評価ポイントになります。

ティップス④：プロンプトは「役割付与」と「出力形式固定」で標準化する

モデルの性能比較をする際、プロンプト（指示文）が曖昧だと、モデルの実力が正しく測れません。例えば、ChatGPTの最新モデルとGeminiの最新版を比較するなら、条件を厳密に揃える必要があります。

「画像を見て説明して」はNGプロンプト

「この画像について教えて」といったフワッとした指示は避けましょう。モデルによって回答の粒度や視点がバラバラになり、比較不能になります。必ずペルソナ（役割）を設定してください。

• 良い例: 「あなたは熟練の建築資材検品員です。以下の画像を厳密にチェックし、表面のキズや凹みの有無だけを報告してください。」

こうすることで、モデルが注目すべきポイントが絞られ、業務特化の性能を測りやすくなります。特に不動産や建築の現場では、専門的な視点でのチェックが不可欠です。

JSON形式での出力を強制してパースしやすくする

また、評価を効率化するために、出力形式は必ず構造化データ（JSONなど）で指定しましょう。最新のAPIでは「JSONモード」などの機能も充実していますが、プロンプトでも明示的に指定することで、より確実な制御が可能になります。

以下のフォーマットのJSON形式のみを出力してください。余計な会話や前置きは不要です。
{
  "has_defect": boolean,
  "defect_type": "scratch" | "dent" | "none",
  "confidence_score": number
}

このように出力を固定することで、Excelやスプレッドシートに結果を貼り付けて集計するのが劇的に楽になりますし、将来的にシステムに組み込む際のAPIレスポンスのテストにもなります。現場での実装を見据えた検証には、こうした「形式の標準化」が欠かせません。

ティップス⑤：コスト対効果（トークン単価）を評価軸に組み込む

最後に、エンジニア視点だけでなくビジネス視点での評価軸です。「性能」と「コスト」は常にトレードオフの関係にあります。

最高精度のモデルが最適解とは限らない

ChatGPTのハイエンドモデルのようなフラッグシップモデルは確かに高性能ですが、API利用料も高額です。一方で、GoogleのGemini Flashや、AnthropicのClaude Haikuシリーズのような軽量モデル（Small Language Models）は、精度は多少劣るものの、コストは数分の一、速度は数倍というメリットがあります。

特に注目すべきは、軽量モデルの進化速度です。例えばAnthropic社のClaudeシリーズでは、旧世代のモデルから、より高性能かつ低コストな次世代の軽量モデルへの移行が進んでいます。最新の軽量モデルは、一世代前のフラッグシップモデルに匹敵する性能を持つことも珍しくありません。

• 難易度高: 手書き文字の解読、複雑な状況判断 → 最新のハイエンドモデル
• 難易度低: 有無のチェック、定型帳票の読み取り → 最新の軽量モデル

このように、タスクの難易度に応じて適切なモデルを使い分ける設計が重要です。また、モデルの廃止（Deprecation）サイクルも早まっているため、特定のバージョンに固定せず、常に最新の推奨モデルに切り替えられるアーキテクチャにしておくことをお勧めします。

画像トークン消費量の見積もりとROI試算

画像入力はテキスト入力に比べてトークン消費量が多くなりがちです。高解像度の画像をそのまま投げると、1枚あたりのコストがビジネスの許容範囲を超えることもあります。月間1万枚処理する場合、そのコスト差は甚大です。

ベンチマークテストの段階で、各モデルの「1処理あたりのコスト」を概算し、「その業務にいくらまで払えるか（ROI）」と照らし合わせることを忘れないでください。場合によっては、99%の精度が出る高額なモデルより、95%の精度でコストが1/10のモデルを選び、残り5%を人間が補完する運用の方が、ビジネス全体としては正解かもしれません。

まとめ：今日から始める「スモールスタート」検証

ここまで、現場目線でのマルチモーダルLLM評価のポイントをお伝えしてきました。

1. データセット: 理想的な画像と悪条件の画像を1:1で混ぜる
2. 評価軸: OCR（文字認識）、空間認識、文脈理解を分けて採点する
3. リスク管理: 存在しない設備について尋ね、ハルシネーション（知ったかぶり）をテストする
4. プロンプト: エンジニアや査定担当者としての役割を与え、JSON形式で出力を固定する
5. コスト: 認識精度とAPI利用単価のバランスを見る

まずは手元の10枚から

いきなり数百枚のデータセットを用意して、大規模な検証環境を構築する必要はありません。まずは手元にある、現場で撮影した「よくある失敗写真（暗い、ブレている、画角が悪い）」を含む10枚程度の画像を選んでみてください。

それを主要なモデル（ChatGPTの最新モデル、Geminiの最新版、Claudeなど）に投げ、スプレッドシートで「◎・○・△・×」をつけることから始めましょう。特にGeminiについては、バージョン更新によって認識精度や安全フィルタの挙動が大きく改善されているケースがあるため、必ず公式ドキュメントで最新のモデルIDを確認して試すことをお勧めします。

たった10枚でも、「このモデルは図面上の文字には強いけど、部屋の奥行き認識が弱い」「このモデルは不明瞭な箇所を正直に『不明』と答えてくれるから信頼できる」といった、スペック表には載っていない「モデルの性格」がはっきりと見えてくるはずです。

検証結果を社内共有する際のフォーマット

評価が終わったら、ぜひその結果をチームで共有してください。単なる正答率（技術的なスコア）だけでなく、「なぜこのモデルを選んだのか」「どの画像で躓いたのか」という判断プロセス自体が、後のシステム導入や運用設計において重要な資産になります。

他社の成功パターンや業界のベストプラクティスを参考にしつつも、最終的には「自社のデータ」で検証した結果こそが、最も信頼できる判断材料です。まずは今日、手元の1枚から検証を始めてみてください。現場の課題を解決する最適なAIモデルが、きっと見つかるはずです。