はじめに
画像を見て操作対象を説明するAIを作っていたところ、画像にはない「十字マーカー」を根拠にした回答が出てきました。
確認すると、モデルに渡す画像からは十字線を取り除いていたのに、プロンプトには「リング＋十字マーカー」という説明が残っていました。さらに、等倍で切り出した画像を「拡大クロップ画像」と説明していました。
この2箇所を直すと、19ケース中11ケースに出ていた十字への言及は0になりました。しかし、対象認識の判定が改善したケースはなく、1ケースではラベルが欠けました。
今回は、この検証から分かった「説明の整合性」と「対象認識」を分けて評価する必要性をまとめます。
検証の背景
私が個人開発している Local Manual Maker（LMM）は、Windowsの操作を記録し、スクリーンショット付きの手順書へ出力するアプリです。任意のローカルAI処理で、操作対象の説明を補助する機能も開発しています。
今回扱うのは、2026年10月初旬の開発版で行った検証です。現在配布している製品の認識精度を示すベンチマークではありません。
当時の処理では、AIに次の画像を渡していました。
- 操作画面の全体画像
- クリック位置を中心とした480×480ピクセルの切り出し画像
どちらにもクリック位置を示すリングがありました。一方、十字線は画像側の変更で既に廃止していました。
つまり、目印がすべて存在しなかったのではありません。リングはあるが、プロンプトに書かれた十字線はないという不整合です。
1. 画像とプロンプトの前提がずれていた
確認した不整合は2つでした。
| 項目 | 修正前の説明 | 実際の画像に合わせた説明 |
|---|---|---|
| クリック位置の目印 | リング＋十字マーカー | リング |
| 切り出し画像 | 拡大クロップ画像 | 等倍の切り出し画像 |
表は変更した語句の抜粋であり、プロンプト全文ではありません。
今回は、この2箇所を同時に修正しました。画像生成、マーカーの形状、画像の順序、モデル、ランタイム、推論設定、回答形式、UI Automationのヒントは変更しない条件で比較しています。
そのため、結果を「十字という単語を消した効果」だけに分解することはできません。「拡大」から「等倍」への修正も含めた比較です。
2. 既存15ケースと追加4ケースを分けて比較した
比較対象は19ケースです。
- 既存の実画面由来：10ケース
- 既存の合成画面：5ケース
- 追加の実画面由来：4ケース
既存15ケースは、それまでの比較や原因調査にも使っていました。すべてを未見の評価データとして扱うことはできません。
追加4ケースは修正文面を固定した後に用意し、正解を推論前に保存したうえで比較しました。この結果を見て文面をさらに調整することはしていません。
また、比較には画像・プロンプト・設定の一致を確認した過去の回答を一部再利用しています。全ケースを同じタイミングで取り直した実験ではありません。
3. 十字への言及は消えたが、対象認識は改善しなかった
まず、存在しない十字への言及を数えました。
| 評価項目 | 修正前 | 修正後 |
|---|---|---|
| 十字への言及があったケース | 11 / 19 | 0 / 19 |
ここだけを見ると、修正はうまくいったように見えます。
一方、対象認識の判定は次のとおりでした。
| 対象 | 修正前：○ / △ / × | 修正後：○ / △ / × |
|---|---|---|
| 既存の実画面由来10ケース | 7 / 1 / 2 | 7 / 0 / 3 |
| 既存の合成画面5ケース | 3 / 0 / 2 | 3 / 0 / 2 |
| 追加の実画面由来4ケース | 4 / 0 / 0 | 4 / 0 / 0 |
○・△・×は、当時の検証で用いた正解・部分的に正しい・誤りの分類です。△には、ラベルは読めていてもコントロールの種類を誤っていたケースが含まれます。
分類が改善したのは0ケース、悪化したのは1ケース、不変は18ケースでした。
また、○でも、画面上の「X」を読めたことと、その機能を「閉じる」と理解できたことは同じではありません。どこまでを正解とみなすかにも注意が必要です。
4. 架空の根拠が消えても、正しい対象にたどり着くとは限らない
分かりやすかったのは、小さな「●」ボタンを対象にした合成画面です。
修正前には、次の回答がありました。
- 対象ラベル：十字マーカー
- 根拠：リングと内部の十字マークが表示されており
実際には十字線を描いていないのに、プロンプトにある目印を回答へ持ち込んでいました。
修正後、この回答は消えました。ただし、正しい「●」になったわけではなく、対象ラベルは「X」でした。
「●」を「X」と読み違えたのか、別の位置を見ていたのかは、この比較では確定していません。
少なくとも、画像にない十字を根拠にする説明が消えたことだけでは、クリック対象を正しく認識できたとは判断できませんでした。
5. 回答全体ではなく、アプリが使うフィールドを見る
悪化したケースでは、本来のラベルが「行1、列1」でした。
| 回答フィールド | 修正前 | 修正後 |
|---|---|---|
| 対象ラベル | 行1、列1 | 行 |
| コントロールの種類 | button | button |
種類は修正前から誤っていましたが、修正後はラベルの一部まで欠けました。
さらに、修正後の根拠説明には「行1、列1」という文字列が含まれていました。しかし、当時のアプリは手順の説明に対象ラベルのフィールドを使うため、実際に採用される内容は「行」になってしまいます。
回答のどこかに正しい文字列があることと、利用者へ渡る説明が正しいことは別でした。
構造化された回答を使う場合は、回答全体を眺めるだけでなく、アプリがどのフィールドを取り出して、どう表示するかまで確認する必要があります。
6. プロンプトだけでなく、入力画像との整合性を確認する
今回の修正後、画像生成の条件を確認する回帰テストも追加しました。たとえば、切り出しが等倍であることや、中心がクリック位置に対応することを確認するものです。
ここで確認する対象は、AIの回答だけではありません。
- 実際にモデルへ渡す画像
- その画像を説明するプロンプト
- モデルの回答
- アプリが採用・表示するフィールド
画像側の処理を変更しても、プロンプトに古い説明が残ることがあります。逆に、プロンプトを直して回答が自然になっても、最終的な操作説明が改善するとは限りません。
次のように評価を分けておくと、変更の効果を取り違えにくくなります。
- 画像にないものを根拠にしていないか
- 正しい位置の対象を見ているか
- 対象の名前と種類が合っているか
- アプリが使うフィールドに必要な情報が入っているか
この検証の限界
今回の結果は、小規模な開発中の比較です。
- 既存15ケースは、既に調査に使っていたデータです。
- 既存の実画面由来10ケースは2枚のスクリーンショットに由来し、画面の多様性は限られます。
- 追加4ケースだけでは、幅広い画面への適用を判断できません。
- 2つの語句を同時に変更しており、それぞれの効果を分離していません。
- 過去回答を一部再利用しており、全件を新規実行した比較ではありません。
したがって、「この書き方ならハルシネーションを防げる」「認識精度が上がる」と一般化する結果ではありません。
まとめ
画像側で廃止した十字線の説明が、プロンプトに残っていました。実際の画像に合わせて文面を修正すると、19ケース中11ケースにあった十字への言及は0になりました。
一方、対象認識の分類は改善0件、悪化1件でした。
今回の検証で学んだのは、プロンプトを入力画像に合わせることに加えて、根拠説明・対象認識・最終的な表示を別々に確認することです。
AIの説明がもっともらしく整ったときこそ、アプリが利用者へ渡す内容まで見て評価したいと思います。
開発中の検証対象は、Windows操作からWord・Excelの手順書を作る Local Manual Maker（LMM） です。