Pythonとブラウザ自動操作で月次事務を分担する——分類・修正・起票後の照合

月次の事務は、同じ作業と判断が混ざっている

月末になると資料を集め、項目を確かめ、種類ごとに分類し、誤りを直し、帳票を起こす。毎月繰り返していても、全てが単純な転記とは限りません。資料の説明が足りないとき、同じ記録が二つあるとき、取り消せない操作へ進むときには判断が必要です。月次事務をAIへ任せる設計では、この違いを工程へ分けることが出発点になります。担当者の手を減らすだけでなく、何を確認して正式な処理へ進むかを明確にする必要があります。

医療系の月次事務を扱うヤクモ提供の実装には、分類、修正、起票を行い、取り消せない操作は人が行う分担があります。工程は約十、そのうち人が担当する工程は二つという概数が示され、修正後には事後照合も行います。この分担を参考に、資料の受付から分類候補、修正案、起票案、保存結果の確認へ進む設計を考えます。工程の数は処理範囲を知る手がかりですが、個別の組織で何を人が確認するかは、資料の種類や操作の影響に合わせて定める必要があります。

例えば、対象期間の資料を受け取り、社内の分類表に照らして候補を示す場面を考えます。実際の医療記録や本番帳票を再現する例ではなく、必要な入力と確認事項を決めるための設計です。分類や承認の規則は各組織の一次資料と担当者の判断で確定し、不足や未対応がある資料は人へ返します。

ヤクモ提供の実装の技術構成はPython、pydantic、pytest、ブラウザ自動操作です。処理を実装するPythonに、構造と型を扱うpydantic、検査を実行するpytestを組み合わせています。月次事務の設計では分類候補、修正案、起票案の必要項目を決めてから後段へ渡す方法が考えられます。型検査を通った日付でも対象月が違えば使えないため、形式と業務条件を別に確認します。どの項目を既存実装で検査しているかは、技術名から推測せず実際の契約を調べます。

資料を受け取った段階で、対象をそろえる

月次の処理では、どの期間と対象の資料を扱うかをそろえる必要があります。先月の資料が混ざる、更新前後の資料が両方届く、同じ記録を別の名前で受け取る、といった例があります。分類の前に、対象期間、必要な資料、取得した範囲を一覧にする設計を提案します。資料が一部しかない状態で合計や起票へ進むと、結果が整っていても対象が欠けます。取得件数の多さより、今回の処理に必要な資料がそろうかを確認します。

資料を取得できない場合、登録がないのか、権限や接続の問題で読めないのかを分けます。画面には「資料未着」「参照できず」「重複候補」と次の行動が分かる日本語を示します。確認者がどこへ問い合わせるかが変わるためです。重複候補は類似しているだけで確定しない場合があります。元の対象や期間を比較し、人が判断する範囲を残します。入口で不足を把握できれば、後の分類担当が勝手に推定して埋める状況を減らせます。

元資料は、修正後の照合に使える形で保持します。何でも長期間保管する提案ではなく、必要な確認ができる範囲と保管条件を業務の規則に合わせる考え方です。公開の説明には、個別の記録や識別情報を載せる必要はありません。

月末時点で資料がそろわない場合は、そろった分だけをどこまで処理できるかを決めます。分類候補は準備できても、最終の帳票は確定しない、といった分担が可能です。途中の成果と未着資料を一緒に表示し、揃っていない対象を完成済みの一覧へ混ぜないようにします。

分類では、候補と根拠を一緒に返す

資料の記述から種類を選ぶ仕事は、文脈を読むAIが補助できる部分があります。分類候補を作る設計では、社内の分類表と資料を受け取り、選んだ種類、判断に使った箇所、迷った点を返します。形式が正しい分類名を返しても、その資料へ適用できるかは別の確認です。通常のプログラムは分類名が定義済みかを検査し、曖昧な内容は担当者へ返す方法があります。AIの自信の表現だけを、業務上の根拠として使わないようにします。

分類表へ当てはまらない資料は、近い種類へ無理に入れず対象外や確認待ちにします。同じ記述でも期間や業務の条件で扱いが変わる場合には、その条件を入力へ含めます。確認画面を設計するなら、候補の横に根拠を開く入口を置き、担当者が正しいかを判断できるようにします。候補を一括して合格へする方法と、迷ったものだけを確認へ返す方法は、誤分類の影響と担当者の負担を比較して選びます。人の確認を減らすことだけでなく、誤りを見つけられるかを評価します。

分類を訂正した場合は、正しい種類だけでなく理由を残します。資料の読取りが誤ったのか、規則の解釈が違ったのかが分かれば、修正する工程を選べます。全ての訂正をAIの能力不足へまとめないことが、運用改善につながります。

修正は、元の値と変更理由を残す

誤りを直す工程では、どの項目を何から何へ変えたかを示します。書式を整えるだけの修正と、値の意味を変える修正は影響が違います。例えば日付の表記をそろえる処理と、希望日を別の日へ変える処理を同じものにしません。修正の根拠が資料にあるか、担当者の確認が必要かを分類します。元資料にない値をもっともらしく追加すると、変更履歴があっても正しさは確定しません。根拠に基づく修正と推定を分けることが大切です。

修正案には、対象項目、変更前、変更後、根拠、確認が必要かを含める設計が考えられます。担当者は差分から確認を始め、必要に応じて元資料へ戻れます。全ての変更を文章で報告するより、項目ごとの差を示す方が見落としを探しやすくなります。ただし差分だけでは文脈を誤解する場合もあるため、関連情報を開けるようにします。修正後の照合では、確認された値と保存先から再取得した値を比較します。確認画面の内容が合っていることと、変更が実際に反映されたことを別に確かめます。

修正が必要な理由が分からない場合は、修正しない選択も必要です。対象の不一致や資料不足を、形式の修正で隠さないようにします。変更できることと、変更してよい条件があることは別の判断です。

起票の候補と、正式な操作を分ける

分類と修正が終わったら、帳票や登録項目を作る工程へ進めます。候補を作成した段階では、正式な処理が成立したとは表示しません。起票する対象、期間、内容、根拠がそろっているかを検査し、確認された候補だけを次へ渡します。人が確認した後に元資料や分類が変わった場合は、古い候補を使わない条件が必要です。入口の資料、修正結果、起票候補を結び付けておくと、どこを作り直すかを説明できます。

取り消せない操作を人が行う分担は、AIの処理を途中で放棄することではありません。その時点で必要な判断材料をそろえて渡す設計です。対象、変更内容、確認済み、未確認をまとめ、担当者が正式な操作を行える状態にします。開発パートナー（ヤクモ）提供の約十工程と人担当二工程という概数は、こうした分担があることを示します。ただし、その割合を他の組織の全業務へ当てはめて自動化率を計算することはできません。実際の担当範囲は、操作の影響と既存の権限に合わせて決めます。

人が操作を終えた後も、保存結果の確認は残ります。ボタンを押したことと、帳票や登録値が正しく保存されたことを分けます。正式な操作の担当が人でも、結果を取得して照合する工程を設けられます。

人へ残す工程を決めるときは、分類を確定する判断と、正式な操作を行う判断を分けます。分類表への適用が曖昧なら前者が必要で、取り消せない起票なら後者が必要です。既存例の人担当二工程という概数だけから、その内容を自分の業務へ割り当てることはできません。対象と影響を列挙し、操作前に必要な根拠、操作後に照合する項目、担当者が不在の場合の引継ぎを決めます。

登録後の照合で、業務の完成を確かめる

修正した値や起票した内容が、保存先へ正しく反映されたかを確かめます。元の対象、確認した修正内容、保存先から取得した結果を比較する方法を提案します。登録要求への成功の応答だけでは、対象や値が正しかったかを見られません。修正前後の資料が変わっていないかも確認します。保存先から取得できない場合は、内容が間違っていると断定せず結果不明として返します。照合の結果を業務の完成条件へ含めることで、作業の実施と受入を分けられます。

不一致があった場合、直ちに再度変更する前に原因を調べます。入力を取り違えた、保存が遅れている、人が別の修正を行った、といった違いがあります。無条件の再修正は、正しい手動変更を上書きする可能性があります。対象と時点をそろえ、どの結果を照合したかを残します。同じ資料が再送された場合には、以前の登録と結果へ戻れる条件も必要です。通信の失敗を理由に二重の起票をしないよう、保存先の照会を先に行います。連携方法ごとに実際の挙動を確認します。

照合が済んだ範囲を一覧にすると、月次のどの対象が残っているかを探せます。全件の処理表示が同じ「完了」だと、候補作成だけの対象と正式処理まで終えた対象が混ざります。利用者に意味が分かる段階を示します。

検査では、月次の境界と例外を入れる

正常な資料に加え、別月の資料、欠落、重複、分類が曖昧な記述、確認後の更新、保存後の応答喪失を用意します。期待結果は先に定めます。別月なら今回の集計へ含めず、欠落は追加の確認へ、重複は以前の結果を照会し、変更後は関係する候補を再作成する、と対応させます。正常例が処理できたことだけで月次業務全体を受け入れないようにします。対象の種類と期間、検査した工程、未確認を記録します。

担当者の確認作業も検査します。根拠が開けるか、修正理由が分かるか、未解決の項目だけを見つけられるかを確認します。AIの出力が合っていても、担当者が全資料を一から読み直すなら、表示に改善の余地があります。確認時間を測る場合はどこからどこまでを含むかを定義します。生成だけの時間と、分類の修正や登録後の照合を含む時間を分け、実際に測定した範囲だけを比較します。継続運用の評価には複数月の対象も必要で、一度の機能確認から削減率や連続正常稼働を断定しません。

業務の規則が更新された場合は、古い分類や検査結果をそのまま使わないようにします。変更が既存の月次資料へ影響するかを確認し、必要な再検査の範囲を定めます。月が変わるだけで同じ条件とは限らない点に注意します。

検査で使う月次資料は、今回の分類規則へ対応するものを選びます。過去の資料に現在の規則を当てる場合は、その差を確認します。複数月を比較したいときも、期間ごとの対象と完成条件をそろえないと、処理の違いが資料の違いによるものか判断できません。

人の確認を、説明できる工程として残す

導入する際は、資料の受付、分類、修正、起票候補、人の操作、照合を工程図にし、誰が何を受け取るかを示します。人の工程を単に丸で囲むより、判断する対象と根拠を説明すると、担当者も運用の不足を指摘できます。AIと通常のプログラムが同じ工程にいても、解釈と形式検査の役割を分けて示します。内部の操作名や状態の番号より、月次の仕事と結果を日本語で表示する方が、利用者が進捗と残る判断を理解しやすくなります。

残る制約は、資料の品質と組織ごとの業務規則です。同じ分担が全ての医療機関や事務に適合するとは限りません。対象の業務を選び、入力、出力、権限、照合方法を確認して試作します。取り消せない操作を人が行うことは、自動化の弱点として消すより、完成条件を守る役割として説明できます。月次事務の設計で重要なのは、機械に任せる割合の大きさより、分類から修正、起票、確認までの結果を根拠とともに追えることです。

続行の判断には、担当者が迷った資料と訂正した理由を使います。規則の整理が必要なのか、読取りの改善なのか、画面の修正なのかを分けて次の開発範囲を決めます。AIへまとめて任せるより、結果を確かめられる工程から広げる進め方が、業務の実態へ合わせやすくなります。

導入後の更新には、業務担当の引継ぎも含まれます。以前の担当者だけが知っていた例外があれば、確認の理由と根拠へ残します。新しい担当者が同じ判断材料を使えるかを確かめることで、人の工程が属人的な最後の補完になることを避けやすくなります。