抽出結果を業務キューへ渡す前に、項目の状態と次の作業を結びつける

Red Hatは2026年10月27日、Atosによる小型モデルの構造化抽出実験を紹介した。本稿はこのベンダー事例を手がかりに、データの受け渡しを考察する。モデルの優劣を判定するものではない。事例の原文

整った表を見ると、受け手はどのセルにも同じ判断が施されたと考えやすい。しかし空欄は、原文に記載がない、システムが読み取っていない、複数の記述が矛盾する、そもそも質問が該当しない、といった異なる状況を表しうる。それぞれ次にすべきことが違う。インターフェースが空白だけを渡せば、受信側は推測するしかない。その推測は既定値、再試行ルール、集計の定義の中に埋もれやすい。

空欄が業務判断に変わるまで

架空のアフターサービス業務を考えよう。Atosの実装を説明する例ではない。顧客が「先週交換品が届いたが、元の問題は残っている」と書いたとする。抽出プログラムは注文日、製品型番、故障の解消状況を埋める必要がある。本文に注文日はない。型番は添付資料にあるかもしれない。「残っている」は該当する問題に結びつける必要がある。三つとも空欄なら、購入証明を求めるべきか、添付資料を読むべきか、元の故障への対応を続けるべきか区別できない。

JSON Schemaの公式文書では、nullとプロパティの不存在が区別されている。この技術上の区別だけで業務状態に名前が付くわけではない。プロパティがないのは旧版のインターフェースが提供していないからか、それとも処理が走っていないからか。明示的なnullは不明なのか、存在しないと確認済みなのか。接続時まで意味を決めなければ、利用側ごとに別の解釈が生まれる。

重要なフィールドについて、値と処理状態を併せて保存する方法が考えられる。状態は「記載なし」「記述が矛盾」「未処理」「根拠のある結果」などに分けられるが、全項目に大きな列挙型を設ける必要はない。区別すべきなのは、次の行動が変わる場合である。低リスクのラベルは単純な空欄でもよいかもしれない。返金、資格、アカウントの扱いを決める項目には、より細かな受け渡しの約束が必要になる。これは設計上の提案であり、普遍的な業界標準ではない。

空欄を説明する材料を残す

状態ラベル自体も誤りうる。重要な項目は、対応する入力の版と原文の位置までたどれることが望ましい。根拠の一節を保存しても判断の正しさは証明されない。ただ、確認者はその一節が別の問いに答えていないか、条件を落としていないかを調べられる。「記載なし」という判断にも処理範囲が必要だ。本文にないことは、未読の添付資料にもないことを意味しない。

先ほどの問い合わせなら、注文日は「本文に記載なし」、型番は「添付資料の処理待ち」とし、故障状態は顧客の記述に結びつけられる。すると業務キューを、資料の追加依頼、未完了の読み取り、対応継続の判断に分けられる。表を完成させるために、モデルが日付を補う必要はない。不明を残すことは、工程全体の失敗を宣言するのではなく、次の作業を適切な場所へ渡すことである。

この約束は正規化にも及ぶ。「先週」を日付範囲に変えるには基準日とタイムゾーンが必要で、ニックネームを顧客名に対応させるには同一人物だと結びつける根拠が要る。正規化後の値だけを残すと、確認者は原文の内容とシステムによる変換を区別しにくい。結果の影響が大きい項目では、標準的に見える文字列だけでなく、元の表現、変換規則の版、結果の関係を残す方が役立つ。

自動化の利益と確認作業を併せて測る

状態の細分化には費用がかかる。保存、画面、研修の負担が増え、人手のキューも膨らみうる。どの不明は行動を止めるべきで、どれは後回しにでき、どれは現在の作業に影響しないかを決める必要がある。型番がなくても苦情の登録はできるが、交換部品の発送はできないかもしれない。同じ項目でも、行動ごとに通過条件は異なりうる。一回の抽出結果を永続的な許可として扱うべきではない。

項目の充足率だけを測ると、不確かな内容まで埋める方向に働く。人手への移管率だけを測れば、妥当な慎重さを罰することになりうる。最終的な処理結果と、その時点で記録された状態を関連づける方が説明力は高い。「根拠あり」のうち後で修正されたもの、「記載なし」のうち実は読み落としだったもの、確認しても新しい利用可能な情報が得られなかったものを分ける。こうした記録は、失敗をすべてモデルの能力に帰すのではなく、具体的な工程の改善につながる。

初期製品では、単純なインターフェースで需要を確かめるべきだという見方も合理的だ。影響が小さく、取り消せて、人が全件を見る作業なら、過剰な初期設計を避けられる。難しいのは、インターフェースの用途が明示されないまま広がることだ。参考用の項目が報告書に使われ、その後自動ルールに取り込まれる。用途変更に意味の再検討が伴わなければ、当初許容できた曖昧さが拡大する。

したがって状態の追加や空欄の意味変更は、型の変更と同様に後続の利用者へ知らせる必要がある。入力例と期待する受け渡し結果を残せば、更新後も受信側が「不明」を「いいえ」と解釈していないか確かめられる。過去のデータにも、説明なく新しい定義を適用すべきではない。欠損率の改善が、業務情報の改善ではなく定義変更だけを表す恐れがあるからだ。

構造化抽出の価値は、文章を協働できる業務へ送り込めることにある。その業務には、行動できる時と、まだ資料が足りない時の両方を知る必要がある。モデルは抽出を担える。項目の意味、許される既定の動作、未解決の問いを誰が引き継ぐかは、利用する組織が明確にしなければならない。