経理システムのマスタ（取引先・科目・部門）の変更を、月次で「誰が・何を・なぜ」の一覧にする
会計システムのマスタ変更ログ（取引先・勘定科目・部門の追加・変更・削除）を月に1回出力し、変更依頼の記録と突き合わせて「依頼のない変更」「振込先の変更」「追加してすぐ削除」「似た名前の取引先の追加」をAIに出させる方法です。整理と抽出はAI、変更が妥当かの確認は担当者と上司、マスタの権限の見直しは責任者。
1. Before ― 手元はどうなっているか
架空のIT企業、サンライズソリューションズ株式会社。会計システムの取引先・勘定科目・部門のマスタは、経理の何人かが変更できます。変更の依頼は、部門からメールやチャットで来ます。気づくと、こうなっていました。
- 取引先マスタに、同じ会社が3件ある。「（株）」「株式会社」「英字」で別々に登録され、支払の集計が割れる。
- 振込先が変わった取引先があるが、誰がいつ変えたか分からない。変更ログはあるが、誰も見ていない（振込先の変更の確認は支払のとき個別に）。
- 使っていない勘定科目や部門が残っている。新しい人が間違えて使う。
- 変更の依頼と、実際の変更が突き合わされていない。依頼なしに変わったものがあっても分からない。
マスタの設計を変える話ではありません。この記事でやるのは、月に1回、変更ログと依頼の記録を突き合わせて、「見るべき変更」だけを一覧にすることです。
2. 問題の分解 ― 何を整えれば進むのか
(a) 会計システムからマスタ変更ログ（日付／マスタの種類／コード／変更の種類：追加・変更・削除／変更した項目／変更者）を月次で出す … 人。
(b) 変更依頼の記録（日付／依頼元／マスタの種類／内容／承認者）を集める … 人。
(c) ログと依頼を突き合わせ、①依頼のない変更、②振込先・支払条件の変更、③追加して同月に削除、④既存と似た名前の取引先の追加、を出す … AI。
(d) 出てきた変更が妥当かを確かめる … 担当者と上司。
(e) 依頼のない変更が続くなら、変更できる人と手順を見直す … 責任者。
変更が妥当だったかを決めること。「依頼のない変更」は、依頼の記録が漏れているだけかもしれないし、緊急で口頭だったかもしれません。妥当かどうかは、変更した人に聞いて、上司が確かめます。それから、振込先の口座番号などの中身はAIに渡しません。渡すのは「振込先の項目が変わった」という事実と日付・変更者の職位だけ。
3. AIに任せること／人が判断すること
- 変更ログと変更依頼の突き合わせ（依頼のない変更・変更のない依頼）
- 振込先・支払条件など「支払に影響する項目」の変更の抽出
- 追加して同月に削除された行、既存と似た名前の取引先の追加の抽出
- 月次の一覧の書式（見るべき変更／確認者／確認結果）
- 変更が妥当だったかの確認（変更者に聞く・依頼元に聞く）
- 似た名前の取引先が同じ会社かどうか
- 使っていない科目・部門を止めるかどうか
- マスタを変更できる人と手順の見直し（責任者）
4. 実行 ― AIとのやりとり
準備 ― ログと依頼の記録
変更ログは、口座番号など中身の値を落として、「どの項目が変わったか」だけ残します。取引先は記号でもよいのですが、似た名前の抽出には名前が要るので、取引先名は残します（社内ルールで確認）。変更者は職位。
往復1回目 ― AIが「不正の可能性」と書いた
③で振込先の変更が4件、うち1件は①にも該当（依頼が見つからない）。その行に「依頼なしの振込先変更は不正リスクが高く、早急な調査を推奨」と付いていた。
依頼なしの振込先変更を出したのは、これが見たかったもの。「不正リスク」「早急な調査」は意図の推測で、依頼の記録が漏れていただけの可能性が高い。禁止事項に書いていてもこうなります。この一言が一覧に残ると、変更者への聞き方が変わってしまいます。
「意図やリスクの記述を削除し、③は事実の表だけにしてください。」
①は7件、②は3件、③は4件、④は追加即削除が2件と似た名前が5組。
③の依頼なし1件を変更者に聞くと、取引先から電話で変更の連絡があり、その場で変えて、依頼の記録を残していなかったとのこと。取引先に折り返して口座を確かめ（支払前の確認の手順どおり）、記録を後から起こします。上司と、「振込先は電話では変えない。書面で受けて記録してから」を手順に足しました。
往復2回目 ― 似た名前の5組
④の似た名前5組に、「重複登録のため、新しい方を削除して既存に統合することを推奨」と付いていた。
5組の抽出はよい。「削除して統合」はマスタの変更の判断で、既存の方が古い住所のまま止まっていて、新しい方が正しいのかもしれません。同じ会社かどうかも確かめていません。
「統合や削除の推奨を削除し、④は表だけにしてください。」
表だけになった。
5組のうち3組は同じ会社の重複。どちらを残すかは、支払実績のある方を残し、もう一方を「使用停止」にします（削除はしない。過去の仕訳が参照しているため）。2組は別会社（支店と本社）。決めたのは担当者と上司。
5. エラーと例外 ― うまくいかないとき
- 会計システムから変更ログが出せない … 出せる範囲（更新日・更新者だけでも）から始めます。ログが出せないこと自体を責任者に伝えます。
- 依頼の記録がメールに散っている … 「マスタ変更依頼」の件名か、依頼の型（1行）を決めて、まず来月から集めます。今月は突き合わせできる分だけ。
- ①が多すぎる … 依頼の記録の方が漏れています。変更者に「変えるときは依頼を先に」を頼み、来月の①が減るかを見ます。
- AIがまた意図や推奨を書く … 削除。毎回。
6. 検証 ― 正しいとどう言えるか
- 今月の変更ログのすべてに、依頼の記録か、確認済みの記録があるか。
- 振込先・支払条件の変更が、すべて上司の確認を通っているか。
- 似た名前の取引先が、「同じ・別」の確認済みになっているか。放置されていないか。
- 一覧に、AIの意図の推測や変更の推奨が混ざっていないか。
7. 注意点
8. After ― 翌月以降、何が変わるか
- マスタの変更が、月に1回、依頼と突き合わされて確認されます。
- 振込先の変更が、支払のときだけでなく、変更の時点でも確認されます。
- 似た名前の取引先が、増えた月のうちに見つかります。
- 「依頼のない変更」の件数が、変更の手順が守られているかの目安になります。
- 会計システムで、取引先マスタを「更新日が今月」で絞る
- 1件ずつ、変更の依頼がどこにあるかを思い出す
- 思い出せない変更が1つでもあれば、それが来月の一覧の最初の行
応用 ― 難易度を上げる場合
支払のときの振込先確認は支払う前に、二重払いと振込先の変更を自分で止める、グループ会社のコードの揃え方はグループ間取引の相手先コードと取引種類を、各社の帳簿で揃える対応表を作るへ。変更できる人の見直しは決裁基準（金額・承認者）と実際の承認記録を突き合わせ、基準と違う承認を出す。