Skip to Content
Docs12. モダリティ応用画像理解の実務パターン
中級vision-language-modelmultimodalprompt-design更新: 2026-09-10この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

画像理解の実務パターン

この記事の目的

視覚言語モデル(VLM)への画像入力を、ユースケース類型別のプロンプトパターンと限界の知識をもって設計できるようになります。図表読解・UI 解析・検品などの類型ごとの効くプロンプト、構造化出力LLM の出力を JSON Schema などの機械可読なスキーマに従わせる技術。後続の処理がコードである出力(分類・抽出・スコア)に使う。との併用、視覚特有の限界(細かい文字・数え上げ・空間関係の弱さ)と対策、解像度・コストの構造、評価設計を持ち帰れる状態を目指します。画像を「操作」する側は コンピュータ操作エージェントの実装 が正本で、本記事は「読解・理解」までを扱います。

対象読者

  • 画像入力を使う機能(図表読解・検品・UI 解析)を作っていて、精度とコストを両立させたい実装担当
  • VLM の「読めるが細部を外す」挙動に振り回されていて、限界を踏まえた設計をしたいエンジニア

前提知識

本文

概要: 細部の読み取りを対象画像で評価する

**VLM(視覚言語モデル / Vision-Language Model)**は、画像とテキストを一緒に扱えるモデルです。画像説明や読解に利用できますが、細かい文字・数え上げ・精密な位置関係は検証すべき失敗例です。たとえば OpenAI の画像入力ガイド は小さい文字、個数、位置関係などの制約を挙げています。性能はモデル・画像・問いで変わるため、以下をすべての VLM に一律に成立する能力表とは扱いません(マルチモーダルモデルの仕組みの精度の崖)。本記事は、この癖を踏まえてユースケース別にプロンプトを設計し、限界を検証で捕まえる実務を扱います。画面の「操作」は コンピュータ操作エージェントの実装 が正本です。

ユースケース類型

画像理解は、類型で効くプロンプト・注意点が変わります。

類型内容主な注意点
図表・グラフ読解チャート・グラフから数値・傾向を読む細かい数値・軸の読み取りは外しやすい
スクリーンショット・UI 解析画面の要素・状態を読む座標・要素の正確な位置は弱い
写真の検品・分類製品・状態の判定・分類微細な欠陥・境界事例は苦手
手書き手書き文字・記入の読み取り崩れた字・自由記述で精度が落ちる
  • 読解系(図表・UI): 「何が書いてあるか」の大枠は得意です。ただし正確な数値・座標は外しやすく、そこを鵜呑みにしないことが肝心です
  • 判定系(検品・分類): 明確なカテゴリ分けは得意ですが、微細な差・境界事例で崖が来ます。重要な判定は検証・人手と組み合わせます
  • 手書き: 崩れ・自由度が高く、精度が落ちやすい領域です。重要用途では実測して可否を判断します

プロンプトパターン

画像入力でも、プロンプトの書き方で精度が変わります。

  • 観点を指定する: 「この画像を説明して」より「この請求書から金額・日付・宛名を抽出して」と、見るべき観点を明示します。漠然と見せると重要箇所を外します
  • 領域に言及する: 「左上の表」「グラフの凡例」など、注目させたい領域を言葉で指す方法を試します。位置表現自体を取り違える場合があるため、切り出した画像との比較で効果を測ります
  • 複数画像の比較: 「A と B の差分を挙げて」のように複数画像を渡して比較させます。順序・対応を明示し、混同が減るかを評価します
  • 画像付き few-shot: 「こういう画像はこう判定する」の例を数個見せ、判定基準を伝える方法です(プロンプトエンジニアリングの基礎技法の few-shot の画像版)。ただし画像 few-shot はトークンコストが大きい点に注意します

構造化出力との併用

画像理解の結果を後続処理で使うには、構造化します。

  • スキーマで縛る: 「検品結果は {判定: OK/NG, 理由: string, 欠陥箇所: []}」のように型付けします(構造化出力)。自由文で返させるより、後続システムが扱いやすくなります
  • 形式保証と内容保証は別: 対応するモデル・スキーマ・生成設定で形式制約を使えますが、拒否や途中終了も処理する必要があります。形式を満たしても、中身が正しいことは保証しません。「NG と綺麗に構造化されたが、実際は OK」は起こります。内容は次項の限界・評価で担保します

限界と対策

以下は視覚タスクの評価セットに含めたい失敗の候補です。LLM の能力と限界の由来も参照し、採用モデルでの頻度と影響を測ります。

解像度・トークンコストの構造

画像理解の実務判断の多くは、解像度とコストに帰着します(マルチモーダルモデルの仕組みのトークン経済)。

  • 解像度と処理設定を比較する: 細部を保持する解像度は必要ですが、API 側の縮小処理、詳細度設定、タイル・パッチへの分割方式でも品質と費用が変わります。元画像を大きくすれば必ず精度や請求トークンが増えるわけではありません。公式の計算方式と対象画像で確認します
  • 関心領域を切り出す: 全画面を高解像度で渡す前に、必要な領域を切り出す・縮小することでコストを抑えます
  • 画像枚数に注意: 複数画像・動画フレームは枚数分のトークンを食います。必要最小限の枚数にします

視覚タスクの評価設計

画像理解も、評価で品質を確かめます。

  • 正解を用意して測る: 判定・抽出のタスクは、正解データと突き合わせて精度を測ります(Agent 評価の基礎)。「それらしく答える」ことと「正しい」ことは別です
  • 崖のケースを評価に含める: 細かい文字・数え上げ・境界事例・低品質画像など、崖が来るケースを評価セットに入れます。平均だけ見ると崖を見逃します
  • 複数回実行のばらつき: 同じ画像でも実行ごとに答えが揺れることがあります。重要タスクは複数回実行でばらつきを見ます

実務での注意点

アンチパターン

  • 「この画像を説明して」と漠然と渡す → 重要箇所を外し、無駄な説明が返る → 見るべき観点・領域を明示する
  • VLM の数値・座標・個数を鵜呑みにする → 細かい数字・数え上げ・位置で外したまま業務に使う → 重要な読み取りは検証・別手段と併用する
  • 構造化出力の「綺麗な結果」を正しいと思う → 形式は正しいが中身が誤っている → 内容は評価・検証で担保する
  • 低解像度での失敗だけでモデルを評価する → 入力品質とモデル能力の影響を切り分けられない → 解像度・詳細度・関心領域を変えて比較する
  • 平均精度だけで評価する → 崖のケース(細字・数え上げ・境界)を見逃す → 崖のケースを評価セットに含める

チェックリスト

  • ユースケース類型ごとの得意・苦手(数値・座標・数え上げ・手書き)を把握した
  • 観点・領域を明示するプロンプトにした
  • 結果を構造化出力で型付けし、内容は別途検証している
  • 数値・座標・個数など苦手項目を鵜呑みにせず裏取りしている
  • 解像度・関心領域・画像枚数をコストと精度のバランスで設計した
  • 正解データで精度を測り、崖のケースを評価に含めている

関連トピック

参考資料

  • OpenAI, Images and vision  — Limitations と画像入力の解像度・課金処理。個別実装の制約例であり、全 VLM 共通の精度保証ではありません(アクセス日: 2026-09-10)

TODO・未確認事項

なし

ドキュメント AI(帳票・PDF の構造化)マルチモーダル RAG