- 公開日
画像や音声から外部システムを操作する場合は、「何を読み取れたか」「業務で使う値へ変換できたか」「その値を使って実行してよいか」を別々に判断します。読めない金額は未確認のまま残し、登録候補ができても登録済みとは扱いません。工程を分ければ、足りない情報を補う場所と、止める操作を具体的に決められます。
マルチモーダルとは、文字に加えて画像や音声など複数の形式を扱うことです。外部ツールは、資料の取得、計算、業務システムへの登録など、モデルの回答の外にある機能を呼び出す仕組みです。入力形式が増えることと、実行権限が増えることは別なので、画像対応のモデルへ接続しただけで登録まで許可されたとは考えません。
認識結果そのものを原資料で確かめる方法は「画像・音声の認識結果は、原資料へ戻って確かめる」で扱います。この記事では、認識した値を登録候補に変換し、外部のシステムへ登録・実行する工程の分け方に絞ります。
一枚の納品書でも三つの判断がある
ここでは、架空の納品書画像から仕入記録の登録候補を作る設計を考えます。利用者の依頼は「この納品書の日付、取引先名、合計金額を確認用にまとめて」です。登録や支払いは依頼されておらず、使えるのは承認済みの画像解析環境と、利用者にだけ候補を返す機能とします。これは説明用の例で、画像解析や仕入登録を実行した記録ではありません。
納品書の見える部分には「2026年10月8日」「青葉文具」「合計 ¥1?80」があり、金額の百円の桁が折り目で隠れていると仮定します。通貨は別の欄に「日本円」と明記されています。画像は一枚ですが、下端が切れており、伝票番号は取得できません。「?」は実際に印字された文字ではなく、ここでは読めない桁を示す記号です。
| 工程 | この例で行うこと | 次へ渡す条件 |
|---|---|---|
| 認識 | 画像の文字や位置を読み取り、判読できない部分を残す | 読み取った箇所を元画像へ戻って確認できる |
| 変換 | 日付・取引先名・通貨・合計金額を所定の項目へ整理する | 元の表記と対応し、必須項目の未確認を区別できる |
| 実行 | 承認された候補を特定の仕入システムへ登録する | 対象・内容・権限・承認が揃い、結果を照合できる |
画像から文字を取り出す処理はOCRと呼ばれます。画像対応モデルが直接読み取る方式でも、読み取り結果と登録値を分ける考え方は同じです。日付を「2026-10-08」へ揃えるのは形式の変換ですが、「¥1?80」を「1,980円」と決めるのは、隠れた情報の補完になってしまいます。
取得できた範囲を先に示す
まず、「納品書画像一枚の見えている範囲を対象にした。下端の伝票番号と合計の一桁は未確認」と範囲を示します。ファイルを受け取ったこと、解析処理が終了したこと、必要な値を確認できたことを区別するためです。画像の裏面や切れた部分を取得したことにはできません。
OpenAIのImages and visionは、小さい文字や回転した画像の誤読、解析前のリサイズなどの限界を説明しています。これは同APIの文書に記された注意であり、すべてのモデルの精度を表すものではありません。元画像が鮮明でも、実際に処理された画像や表示範囲が異なれば、確認できる内容も変わり得ます。
納品書の例なら、全体像と金額部分を確認し、必要に応じて折り目を伸ばして撮り直してもらいます。拡大するだけで隠れた桁が復元するとは扱いません。複数の読取り結果が同じ値になっても、同じ欠けた画像に依存していれば、欠落を解消する根拠にはなりません。
音声を扱う場合も、対象にした録音区間と言語、聞き取れなかった箇所を残します。例えば一部の音声だけを文字起こししたとき、録音外で訂正や取消がなかったとは言えません。文字起こしの文章が流暢でも、話者の権限や、その発言が今回の操作を許可するかは別に判断します。音声の内容を自動で実行命令へ昇格させないことが境界になります。
不明な値を保ったまま候補を作る
この画像から返す候補は、日付「2026-10-08」、取引先名「青葉文具」、通貨「JPY」、合計金額「未確認」です。合計の読取り表記「¥1?80」と、その理由「折り目で一桁が判読できない」を添えます。登録用データでは、未確認を表せる形式を採用し、ゼロ円や空文字へ置き換えて正常な値として扱わない設計にします。
項目の形式だけでなく意味も確認します。「合計」の近くにある数字か、預り金やお釣りを誤って選んでいないか、通貨は画像に根拠があるかを照合します。取引先名の文字列が読めても、それだけで社内の取引先IDを一意に決められなければ、取引先の紐付けは別の未確認項目として残します。
欠けた金額を埋めるために、同じ取引先の過去の納品額や他部署の仕入記録を検索する処理へ進めるべきではありません。今回必要なのは、この納品書の合計を裏付ける資料です。原画像の再取得や、利用者が確認した値とその根拠を待ちます。補足を受けたときは、どの項目をどの資料で更新したかを残し、以前の認識結果と混ぜません。
候補だけを返す段階では、登録に使う必須項目が欠けていても、読めた日付と取引先名の整理は続けられます。出力は「合計が未確認のため登録可能な状態ではない」と明示します。全作業を止めるか、すべてを埋めて進むかという二択にせず、根拠のある部分と保留部分を分けます。
登録を追加すると確認の範囲が変わる
次に同じ納品書について、利用者が登録も依頼した場合を考えます。撮り直した画像では合計「¥1,980」が明瞭で、元の納品書と同一であること、日付・取引先名・合計を利用者が確認したと仮定します。登録先は社内の仕入記録一覧で、支払いや検収の最終承認は含めません。ここで初めて登録の準備へ進みます。
登録前に見せる内容は、登録先、対象の納品書、日付、取引先名、通貨、金額1,980円、重複候補の有無、今回行う操作です。本例では重複確認も登録条件とし、照合できなければ登録を保留します。「重複なし」と表示して進めることはしません。承認した内容と実行へ渡す内容を結び付け、後から金額や登録先が変われば再確認します。
OpenAIのFunction callingが説明するfunction toolの流れでは、モデルによる呼出し要求と、アプリ側の実行・結果返却は別の段階です。これは同方式の説明であり、提供者側で動く組込みツールを含む全方式の実装を一律に決めるものではありません。業務上は、誰が実行する構成でも、呼出し案が出たことだけを登録成功の根拠にしないことが要点です。
実行器では権限と承認の有効性を確認し、登録後には返却された登録IDを使って内容を照合します。権限不足なら登録を止め、候補を利用者へ返します。応答が途切れた場合は結果不明として、元の要求と登録一覧を確認します。AWSの再試行設計が示すように、応答不着は未実行を意味しません。重複適用を防ぐ契約を確認できないまま、新しい要求として登録し直さないようにします。
画像と認識結果の行き先も分けて確認する
画像を読める環境でも、その画像を外部へ送ってよいとは限りません。納品書には担当者名や顧客番号など、登録候補に不要な情報が含まれることもあります。読取りを行うサービス、変換結果の保存先、登録ツール、ログのそれぞれについて、必要な情報と利用条件を確認します。マスキングするなら、解析先へ送る前に行い、金額や日付など必要な根拠まで消していないかも確かめます。
OWASPのExcessive Agencyが勧める必要最小限の機能・権限という考え方からも、候補作成だけの構成に登録や支払いの機能を付ける必要はありません。登録する構成でも、必要な一覧への書込みに限定する設計を検討します。画像中に別の送信先や操作指示が書かれていても、それは読取り対象のデータであり、利用者の承認を置き換えません。
候補だけなら外部登録の承認や登録後照合は工程に入りませんが、入力の利用許可、取得範囲、不明値の保持は残ります。登録を追加すると、実行権限、内容の確定、重複確認、結果不明への対応が増えます。工程を分けて保存する負担もあるため、原画像との対応を失わない範囲で必要な記録に絞り、保持期間と閲覧できる人を決めます。
この納品書なら、読めない一桁を残して候補を返せるか、撮り直した根拠と登録値を結び付けられるか、登録できなかった場合に候補と実行状態を別々に伝えられるかを確かめます。認識の評価、ツールの選択、権限の強制はそれぞれ必要な仕組みですが、まず各工程の入力と出力を区別すると、どこを詳しく点検すべきかが見えてきます。
音声入力で会話と操作指示を分ける信頼境界は「音声入力の会話と操作指示を分けるための信頼境界」で解説しています。
