KAMIWAZA

アプリ側で検査できる構造を渡す

写真を、項目やレコードを表す仕様に変換します。アプリはその構造を検査し、画面を組み立てます。

変更にも、同じ境界を設ける

生成後のテキスト指示も、SpecDiffという操作の型を通します。項目の追加、名称変更、数値の上限・下限、承認ステップの追加など、対応する操作をモデルが選び、決定論的なリデューサーが既存のspecへ適用します。拒否した変更では元のspecを返します。操作によって画面がどう変わるかは、アプリ側が決めています。

読み取りの不確かさには別の経路があります。ライブ実装は、モデルの申告信頼度が閾値を下回る最初の項目を探し、含めるかどうかを尋ねます。これは人が確認するための接点であり、信頼度の数値を較正できている証拠ではありません。項目と画像上の位置を結ぶsourceBoxもありますが、ライブ写真上の座標精度は定量評価していません。

値が正しくても、書類の情報が揃っているとは限らない

値の一致数と、書類全体の判定を一緒に見ます。読み取った値が正しくても、必要な情報が揃っているとは限りません。

2回の結果を、同じ表で読む

同じ50書類に対する2回の評価記録を比べます。保存された採点結果で、抽出を新たに実行した試験ではありません。

この記録が確かめられる範囲

どちらの回でも、LLM採点器が捏造と記録した値は0件でした。合算の2,225値は、同じ50書類に対する2回の評価です。独立した試験の件数ではなく、検出0件も「値を捏造しない」という一般的な保証ではありません。採点器と人の判定の一致率は測定していません。

評価日は2026年7月6日、モデル提供元への直接経路と記録されています。この表は、残っている判定ファイルを再集計して作りました。元画像は手元になく、採点モデルの識別子も保存されていません。公開した数値から合計は計算し直せますが、原本の再採点や同じセットでの再実行はできません。モデルや接続経路を変えた環境に、この成績をそのまま持ち越すこともできません。

KAMIWAZAは、範囲を定めたプロトタイプです。承認ステップは設計として表示するもので、承認・差戻しは実行しません。生成データも再読込では保持されません。紙からアプリを起こす仕組みの実演と、継続して業務を預かる製品の間には、この実装差があります。