同じ領収書が二度使われ、ファイル名だけが違った
一言でいうと
請求の証憑点検は、ファイルがすべて届いたかを数えることではなく、そのファイルが本当にその書類なのかを、名前ではなく中身で判定することです。形式はマジックバイトで、同一性は内容ハッシュで、記録と実物のずれは双方向の突き合わせで見ます。
なぜ必要なのか
保険請求で書類は、支払判断の根拠です。ところが受付窓口が複数あり、チャネルが複数あると、同じシステムに入ってくるファイルの状態がばらばらになります。スキャナーが作ったPNGに、担当者が.pdfを付けてアップロードし、ファイル名に被保険者の名前を入れて送り、同じ領収書を名前だけ変えて2つの請求に出します。審査者は画面で開くものだけを見るので、この3つとも、目ではなかなか捕まりません。
点検を人の目に任せると、3つが同時に崩れます。書類が足りないのに届いたとして処理され(支払いの根拠が空になり)、同じ書類が2回支払いの根拠に使われ(重複支払い)、ファイル名に載った個人情報が、一覧・バックアップ・ログに広がります。3つとも、あとで見つかると、元に戻すコストが非常に高くなります。反対に、受付時点の自動点検は安価です。必要なのは、ルール表1つとファイルの先頭の数バイト、そしてハッシュだけです。
どう動くのか
チェックリストは、コードではなくデータとして置きます。請求の種類ごとに必要な書類が違い、その一覧は商品と規定が変わるたびに動きます。種類と書類の種別を2つのカラムにした表に入れておけば、点検器は表を読むだけで済み、規定が変わってもコードを直しません。SQLiteのようにカラムの型が緩いストレージでは、値の保存クラスが何なのかも一緒に知っておくとよいです(SQLiteのデータ型)。
形式は、先頭のバイトで見分けます。拡張子は人が付けたラベルなので、何の保証もありません。PDFの先頭が%PDF-であることは、RFC 8118のメディアタイプ登録項目が定めていて、PNGは最初の8バイトが10進数で137 80 78 71 13 10 26 10であると、RFC 2083の3.1節が定義しています。JPEGはFF D8 FFで始まり、ZIPはPKのあとに03 04が来ます。Linuxのfileコマンドがしていることも、結局この表を見ることです。
ここで必ず守ることが1つあります。これらのファイルにはNULバイトが混ざっているので、grepを使ってはいけません。GNU grepは、NULが混ざった入力をバイナリファイルとみなして、「Binary file matches」とだけ出すか、黙って何も見つけられません。先頭がNULで始まる形式ほど、本物のファイルから確実に外れます。od -cで見るか、Pythonでopen(path, "rb").read(16)で読んで比べます。
同一性は、内容ハッシュで見ます。同じ書類かどうかを、ファイル名で言うことは絶対にできません。hashlibでファイルの内容のsha256を求めて、同じ値同士をまとめれば、名前を変えて出し直した書類が1つの塊として現れます。ハッシュを人が読む一覧に載せるときは、16進数で書くのが普通で、バイトをそのままテキストに入れなければならないときのbase16・base32・base64の位置づけを整理した文書がRFC 4648です。パスを扱うコードは、文字列操作の代わりにpathlibを使うと、拡張子と名前を分けるミスが減ります。
記録と実物は、双方向で突き合わせます。受付記録にあるのにファイルがないことと、ファイルはあるのに記録がないことは、別の事故です。前者は支払いの根拠が空になっていることで、後者は誰のものかわからない個人情報が残っていることです。片方向しか見ない点検器は、いつも半分を見逃します。
doc_rule(규칙표) ─┐
├─▶ 빠진 서류 ─┐
submission(기록) ─┤ ├─▶ 청구별 보완 요청 목록
├─▶ 고아 / 없는 파일 ┤
inbox(실물) ──────┴─▶ 형식 · 해시 · 이름 ┘
現場での姿
期限計算の起算日を誤ることが、非常によくあります。受付日を基準に数えると、遅く受け付けた案件ほど期限が延びます。起算日は事故日でなければならず、そのルールは1行の文書にして、点検器と一緒に置きます。このラボでは事故日から30日を期限としますが、これは実際の法定期限ではなく、このラボの仮定です。商品や会社ごとに異なるので、現場では必ずその会社の規定を確認しなければなりません。
ファイル名の個人情報も、よくそのまま残ります。内容は非識別化処理を行うのに、名前には手を付けないことが多く、一覧画面、バックアップの索引、エラーログ、さらには報告書のファイル名まで、その名前をそのまま運びます。点検報告書自体が、同じ値をもう一度広げることのないよう、報告書には件数とルールだけを書き、値は載せません。
実務で本当に大切なこと
- 形式の判定は名前ではなく中身で行います。そして判定結果を表として残し、あとで数え直せるようにします。
- 同じ書類の再利用は、ハッシュでしか捕まりません。人が見る一覧には、根拠(どの請求とまとまったか)も一緒に出します。
- 欠けた書類と遅れた書類は、処理が違います。補完依頼の一覧は、理由別に分けて書きます。
- 点検器は、受付箱を書き換えません。ファイルを移動したり名前を変えたりすることには、合意された手順が別にあります。
次のラボですること
ダオン損害保険(仮想)の請求60件と受付箱のファイル189個を自分で作り、ルール表で欠けた書類を探します。拡張子を信用しない形式判定器を作って受付箱全体の判定表を出し、内容ハッシュで使い回された書類をまとめ、ファイル名に載ってきた個人情報を数えます。期限を事故日から計算し、記録と実物を双方向で突き合わせたあと、請求ごとの補完依頼の一覧と報告書で締めくくります。