Airparserの代替：新しい文書タイプごとの設定をやめよう

各受信トレイにフィールドを定義します。 AirparserのパーサーはLLM駆動かつスキーマベースです。「請求書番号：上部にある一意の識別子」のようにフィールドを定義すると、モデルが値を特定します。描画するゾーンがないのは旧ツールに比べて大きな改善ですが、受信トレイごとに独自のフィールド定義を持つため、文書タイプが異なれば別のスキーマが必要になります。

値が欠落している場合、特に財務データではハルシネーションのリスクが顕在化します。 Airparserの公式ドキュメントでも、処理時間が長くなるとハルシネーションのリスクが高まる可能性があると指摘されています。ハルシネーションとは、AIがデータを捏造または誤解釈するケースです。請求書にフィールドが存在しない場合、テキストモデルがもっともらしい数値で空白を埋める可能性があります。請求書の合計額、税額、勘定科目コードにおいては、捏造された値は空のセルよりも有害です。人間によるレビュー（Human-in-the-loop）でこれらを検出できますが、自動化の約束に手作業のステップが加わります。

複雑なテーブルが難所であり、Airparserの公式ドキュメントもそれを認めています。 LLMエンジンは、メール、履歴書、契約書など散文中心の文書では良好に機能します。Airparserのトラブルシューティングガイドでは、「文書構造がLLMエンジンにとって複雑すぎる一部のケースでは、抽出データが不完全または不正確になる可能性がある」と認めており、テキストエンジンとビジョンエンジンの切り替えを推奨しています。請求書の明細行や銀行明細の行については、数値を信頼できるようになるまでにさらなるスポットチェックが必要です。

スキーマ不要：列名を入力するだけで結果が得られます。 フィールドの説明も、ドキュメントタイプごとの設定も不要です。「請求書番号」「取引先名」「合計」と入力するだけで、ビジョンAIがドキュメントを画像として認識し、ページ上のラベルを見つけて、その隣の値を抽出します。テキストパターンから推測するのではなく、人間と同じように視覚的にラベルを見つけて読み取ります。初回アップロードから、あらゆるレイアウトで、設定ゼロで動作します。

ページ画像に基づいた読み取り。 モデルは「合計」ラベルとその隣の数字を視覚オブジェクトとして特定するため、スキーマが要求するフィールドを埋めるために値を生成しているわけではありません。これにより、存在しない数値を invent するという特定の失敗モードは軽減されますが、保証はありません。どのモデルでもページを誤読する可能性があります。そのため、レビューモードでは各セルのソース領域がハイライト表示され、ドキュメントを打ち直す代わりに、数秒で値を確認できます。

抽出中にAIが計算・推論します。 ページから値を読み取るだけでなく、ImageToTable.aiは抽出中に計算（「明細合計（数量×単価）」などの計算列）を行い、ドキュメントにない情報を推論します（「カテゴリ（選択肢：食事/交通/オフィス）」などの推論列）。Airparserはスキーマフィールドを埋めてPythonによる後処理を提供しますが、ImageToTable.aiは同じパスで導出出力を生成するため、抽出後のスプレッドシート作業が不要になります。