課題
人事の発令（異動・任免・出向・契約更改など）が出るたびに、担当者が発令文書を読み、基幹の人事システムに取り込むための数百列のExcelフォーマットへ手で転記していました。発令文書は形式がバラバラで、スキャン画像も混ざります。年間の発令はおよそ300〜450件（数値はいずれも概数です）。
より根の深い問題は、転記のときに参照するマスタ（所属コードなど約20種）の状態でした。かつてのデータベースからExcelに移されて以来、長年の手作業で継ぎ足され、どの値が正しいのかが人の記憶に依存する状態になっていました。マスタが整っていないため、転記の自動化を試みても「新しいコードが読めない・区分が食い違う」で手戻りが出る——道具の問題ではなく、参照する台帳の問題です。
やったこと
1. 約20種のExcelマスタと現状人員データを、データベースへ移管する
自動化の前に、参照される側の台帳を先に整備しました。約20種・約950行のマスタと、約580行の現状人員データをExcelからNotionのデータベースへ移管。移行時には、コード類を文字列として保持して先頭ゼロの桁落ちを防ぐ、行数と抜き取りで原本との一致を照合する、といった検証を挟んでいます。
2. 変換ルールを「指示書」として言語化する
AIに任せる変換のルール——どのマスタを参照するか、日付はどの欄を採るか、そして推測で埋めることの禁止（確定できない項目は「要確認」として列挙する）——を指示書のページに書き切り、これを変換ルールの唯一の参照元にしました。ルールが文書として存在するため、担当者が変わっても運用が引き継げます。
3. AIの読み取りと、決定的な処理を分ける
構成は2層に分けました。形式がバラバラな発令文書（スキャン画像を含む）を読み取って構造化する部分だけをAIが担い、マスタとの突合・コードの引き当て・整合チェックは決定的な処理が担います。確率的な処理を1箇所に閉じ込めることで、「どこで間違いうるか」を管理できる形にしています。
難しかったこと
「この文書は機械では読めない」と、いったん結論しかけた。 初期の検証でスキャン文書から文字が1つも取り出せず、別の読み取り工程を足す前提で設計を進めかけました。実際には、試した道具がテキスト専用だっただけです。本番で使う基盤は同じ文書を読めました。道具の限界を、仕様と取り違えていたことになります。
箱を増やすほど、使われる形から遠のいた。 当初は、受付から取り込みまでの状態を持つデータベースを運用の中心に置きました。ただ、日々使う人から見ると手数が多く、ややこしいものでした。運用は、指示書のページを呼び出して発令文書を添付する2手順に絞り、状態を持つデータベースは将来の枠として休止させています。
素直に読むと、日付を取り違える。 発令文書の冒頭には決裁の日付が載っており、そのまま拾うと異動の日付とずれます。見出しを飛ばして日付の入る行を選ぶ形に変えました。文書によって見出しが「異動日」だったり「発令日」だったりするため、どちらでも同じ欄を採れるようにしています。
検証
実際の発令文書（デジタル・スキャン混在）で検証し、変換結果のコードを原本と機械照合して全項目一致を確認しました。判断できない項目が推測で埋まらず「要確認」として出てくることも、実データで確認しています。全自動を狙わず、最後は人が確認する前提の設計です。
その後
構築と動作検証を終え、実運用に向けた検証の段階です。Excel台帳の限界と移行の考え方はExcel台帳のデータベース化に、一般化して整理しています。
同じ型が効く業務
決まった形のない文書を読み、決まった様式のデータに直す——この作業は人事に限りません。契約書や申込書の受付、届出・申請の処理、請求書の受け取りも同じ形です。文書の種類が多く、紙とスキャンが混ざっているほど、人の手が空かない領域になります。
当社の経験では、順序を変えるところが要でした。変換の自動化より先に、参照される側の台帳を正しくする。そのうえで、確率的に振る舞う部分を読み取りだけに閉じ込め、確定できないものは「要確認」として人に返す。全部を機械に任せない前提のほうが、運用に載りました。