原文・抽出値・業務判定を三層で保存する——条件付き数値の根拠と訂正を追う

同じ八十度でも意味が違う

工場の点検報告に「温度八十度」と書かれていたとします。集計表には数値の八十だけが残り、異常の欄が赤くなります。しかし原文は「停止直後に八十度、冷却後は規定内」だったかもしれません。別の報告は「計器の誤差が疑われるため参考値」です。数値の形式が正しいことと、同じ意味で比較できることは異なります。点検担当が数字だけを見て再点検の順番を決めるなら、注記の欠落が判断へ直接影響します。

設備報告から値を取り出す設計で大切なのは、報告のどこから数値が得られ、どんな条件が付いていたかを残すことです。利用者向けには見やすい数値を示し、詳細で原文へ戻れるようにします。全報告を一覧へ載せる方法もありますが、件数が多いと必要な一文を探せません。要約と原文のどちらかを選ぶより、両者をつなぐことを考えます。

数値の保存は検索や計算に向き、原文の保存は文脈の確認に向きます。この役割の違いを理解すれば、二重保存を無駄とは考えずに済みます。数字だけでは理由を説明できず、原文だけでは全件を比較しにくいからです。最初に「何を計算するか」「何を問い合わせられるか」の二つを整理すると、残す情報の範囲が決まります。個人情報や機密を含む場合は、必要な原文へアクセスできる担当者も別途決めます。

原文と抽出値を同じものにしない

入力には報告の本文、作成日時、対象設備、記録者、資料の版を用意します。処理では温度、単位、測定時点、測定条件を取り出します。ここで取り出した値は原文の写しではなく、原文の一部を解釈した結果です。だから原文を書き換えて抽出値に置き換えるのではなく、元の文と別に保存します。単位を換算した場合も、元の値と単位、換算後の値を分ければ計算の過程を確認できます。

原文の「八十前後」を数値の八十へ変換する場合は、おおよその値であることを残します。「八十未満」なら上限の意味も必要です。数字が含まれているだけで全てを同じ温度欄へ入れると、概算、範囲、上限、実測が混ざります。抽出できなかった箇所をゼロにする方法も避けます。読めなかった、記載がなかった、該当しなかったを分けることで、追加の確認が必要な報告を絞れます。

抽出時の判断には、原文の該当文を結び付けます。報告全体への参照だけだと、数ページの文書から同じ箇所を毎回探すことになります。例えば「停止直後」の文と温度の値を一緒に確認できれば、数値の採用が妥当かを判断しやすくなります。ただし該当文だけで十分とは限りません。近くの段落に測定器の不具合が書かれているなら、その周辺へ広げて読める経路も必要になります。

三つの層で訂正を受け止める

保存する情報を、受け取った資料、取り出した値、業務上の判定という三つの層へ分けます。報告の温度が訂正された場合は資料の新版を追加し、影響する抽出値と判定を再確認します。一方、警告の基準だけが変わった場合は原文も抽出値も同じで、判定だけを更新できます。全てを一つの表へ上書きすると、数字が変わったのか基準が変わったのかが分からなくなります。訂正の原因に応じて更新範囲を分けます。

過去の報告書を再現したいなら、当時使った資料と判定基準の組を残します。今の基準で過去の全件を再評価する分析と、当時の判断を説明する記録は用途が違います。どちらか一方へ揃えるのではなく、画面が現在の再評価か、当時の結果かを示します。設備の交換で測定位置が変わった場合も、同じ設備名だから継続した数値と見なしてよいかを確認する必要があります。

資料の版を増やすときは、以前の版が誤りだったことを示す情報も必要です。古い版を削除すれば、当時の報告がなぜその数字だったか説明できません。反対に古い版を現行の資料として使い続けるのも問題です。保持と採用を分け、履歴には残すが新しい判断には使わない、といった扱いを明示します。原文を保存する設計には、どの版を参照してよいかを決める責任も伴います。

読み手に合わせて入口を変える

点検の担当者には、設備名、測定値、条件、要確認事項を一覧にします。管理者には、未確認の報告数と重要な変化を見せます。どちらからも原文へ戻れるようにしますが、原文を初期画面で全部読む必要はありません。異常な値だけを強調すると、参考値や未測定が見落とされる場合があります。数値の大きさと、確認できているかを別のラベルで表し、確認の必要性が伝わるようにします。

詳細画面では抽出した値と原文の該当箇所を並べます。担当者が原文を修正すべきか、抽出結果を修正すべきかを選べると、誤りの原因を残せます。ただし誰でも原文を直せるようにはしません。原資料の訂正は元の作成者や承認した担当者が行い、抽出の修正とは分けます。画面上で読みやすく加工した文章も、引用した原文そのものと誤解させない表記が必要です。

検索では、原文の表記と揃えた語の両方を使えると便利です。現場で「熱い」と書かれた報告を温度の注意として拾うことは候補作りには使えますが、温度を測ったことにはなりません。明示された値と、文章から推測した状態を分けます。推測を使う場合には何を根拠にしたかを示し、人が確認できる経路を残します。検索の便利さを、存在しない測定結果の生成へ広げないことが重要です。

検査は意味の取りこぼしを狙う

検証用の報告には、単純な数値だけでなく、条件付きの値、範囲、単位の違い、訂正文、否定文を含めます。「八十度ではない」という一文から八十を採用してしまうような失敗は、通常の数字だけの資料では見つかりません。処理が動くかより、どんな文で誤るかを確かめます。抽出できなかった報告を適切に止めることも成功条件に含め、全件に何らかの数値を出すことを目標にしません。

抽出値の検査と、業務判定の検査は分けます。温度を正しく取り出しても、停止直後の値へ運転中の基準を適用すれば判定が違います。測定条件に応じた基準を選べるかを別に確認します。担当者のレビューでは、数値が一致することだけでなく、判定に使った前提が原文に存在するかを見ます。前提が不明なら判定を保留するなど、分からないことを出力する方法も設けます。

抜け落ちた注記を検出するには、対象資料の代表的な種類を事前に選びます。読みやすい報告ばかりでは、手書きの転記や表の注記の問題が見えません。試験に含めた形式と含めていない形式を示し、未対応の資料は別に扱います。精度の数値を出すなら、数値の一致、条件の抽出、判定の一致を分けて測る必要があります。設計段階では精度の実測値がないため、検証に必要な資料と基準をそろえることから始めます。

値の出所と確認結果を結び付ける

数値を扱う基盤では、使いやすく整えた値とは別に原資料を残す方法があります。金融データ基盤のヤクモ提供の実装には、開示原本をテキスト化して保持し、取得値の出所と網羅率を記録する構成があります。設備報告では、この保存に加えて原文の該当箇所へ戻れる関係を設計します。資料全体の保存と、個々の値がどの文に由来するかの対応は別の仕事です。八十度という値から測定条件へ戻れるか、資料の訂正が抽出値へ伝わるかを確認します。

文章を使う工程にも、生成、来歴確認、監査、レビュー、人の承認を分ける方法があります。記事制作の実装・テスト記録はこの分担の参考になりますが、本番で自動公開した記録とは別です。設備報告では、値を抽出したこと、原文と一致すること、業務の判定へ使ってよいことを異なる条件にします。原文の温度が正しくても、測定時点が不明なら判定は保留できます。承認が必要な項目では、確認者へ元の文と抽出結果を渡し、意図した条件が残っているかを確かめます。

成果物を単独の文章や数字として扱わず、出所と検査を伴うものとして扱います。必要な根拠の粒度は業務によって違います。監査に使う資料なら原文の版や確認者が重要になり、日常の候補探しならまず該当箇所へ戻れることが役立つかもしれません。設備報告では、警告から抽出値、抽出値から原文へ段階的に戻れる経路を設ける案があります。閲覧者が何を確認するかを先に決め、そのために必要な情報を保存します。別用途の処理記録を設備判定の検査済み証拠にはしません。

構造化した値をPostgreSQLやSupabaseで保存し、原資料をオブジェクトストレージへ残し、Pythonで抽出や検査を組み立てる構成が考えられます。文章の根拠や承認を扱う処理と数値の保存は別の役割です。設備報告では原資料の版、抽出箇所、判定基準の版を対応付けます。三つがそろっているかだけでなく、訂正後にどの層を再作成するかも検査します。元資料を直した場合と基準だけを直した場合を分け、変更していない層まで無条件に上書きしないことを確かめます。

保持するほど閲覧の責任が増える

原文には数値以外の情報も含まれます。担当者名、顧客名、事故の説明など、一覧の利用者に不要な情報があるかもしれません。原文を全て保持することと、全て公開することは別です。抽出値の閲覧権限と、原文の詳細へ進む権限を分けます。参照先を表示する際も、権限のない利用者へ資料の内容を返さないことを確認します。根拠へ戻れる設計は、必要な範囲で戻れる設計であるべきです。

保持期間も決めます。業務の記録として必要な期間、訂正を受ける期間、個人情報を残してよい期間は一致しない場合があります。原資料を削除する場合は、残った抽出値の根拠が失われることをどう表示するかも考えます。削除後に根拠へ戻れるように見せたままにしてはいけません。数値だけを匿名で残す方法が適切かも含め、業務上の必要性と取り扱いの条件を確認します。

保存領域を節約するため、要約だけ残す方法もありますが、その場合は元の意味を確認できない限界が生まれます。原文、該当箇所、要約のどこまで残すかを一律に決めるより、用途ごとに選ぶ方が合理的です。大切なのは、戻れる範囲を過大に表示しないことです。数字の裏付けが失われたときは、その状態が画面と記録に現れるようにすれば、利用者が確認済みの情報として誤用することを防げます。

まず一種類の報告で往復する

導入の最初には、一種類の報告から値を取り出し、一覧の一つの数字から原文へ戻り、訂正後に差分を確認するところまで試します。大量の資料を一度に処理する前に、この往復が成立するかを確かめます。数値が計算できた、原文を保存できたという別々の成功だけでは、問い合わせに答えられるとは限りません。利用者がどの数字を疑っても、採用理由と条件へ戻れることを完了条件にします。

応用先には契約書の金額抽出、問い合わせ分類、社内報告の要点整理があります。ただし文章から取った情報を全て確定事実へ変えることはできません。原文自体に誤りがあれば、丁寧な保存もその誤りを保持するだけです。原文と一致すること、業務で正しいこと、操作に使ってよいことを分けて確認します。根拠を残す設計は真偽を自動で保証する仕組みではなく、疑問へ戻り、訂正を説明するための仕組みです。

長期運用では、確認の問い合わせを次の改善へ使えます。条件の取りこぼしが多い報告形式は、入力側の様式を変える候補になります。処理の工夫だけで複雑さを吸収するより、測定条件を独立した欄へ置く方が有効な場合もあります。数字と原文を残すことで、どこに曖昧さが生まれたかを具体的に調べられます。説明可能性を、後から言い訳を書く作業ではなく、日々の入力と保存の設計へ組み込みます。