ある定期チェックが、別々の2つの経路から動いていたことがあります。固まった要件をあちこちの文書と実行手順に書き、AI向けの入口まで増やした結果でした。同じ判定が、2か所で別々に走っていたわけです。
で、例外が出るたびに、指示ファイルへ注意事項を書き足すことになります。出力の形式がずれたら、また追記です。経理をAIで自動化したはずなのに、気づけば、AIに読ませる手順書の保守が、新しい定型業務になっていました。同じ判定を何度も確かめる作業も、そこに乗っていました。
いまは、内容が固まった定型処理をAIにPythonでコード化してもらい、スケジューラから毎回同じ処理を動かしています。AIに任せるのは、コード作成から実行の補助、結果の整理、例外の調査まで。要件を決めて、最後に承認するのは人です。
答えが決まる処理はPythonに固定する
指示書に書くのは、対象、正本、コマンド、禁止事項、停止条件まで。日付の整形や金額計算、形式検査、突合のように答えが決まる処理はPythonへ移し、まだルールを決めていない例外だけをAIと人に戻す。
AI向けの指示書に書くこと、書かないこと
AGENTS.mdやCLAUDE.mdのような、AIが作業前に読む指示ファイルは、いまも使っています。ただ、起きたことを何でも書き足しても、結果は安定しませんでした。注意事項をいくら増やしても、同じ結果が返ってくる保証にはなりません。
指示書で伝えるのは、対象業務、参照する正本、実行コマンド、書き込んではいけない範囲、承認が必要な操作、異常時の停止条件です。要するに、どこで動かし、どこから先を人が判断するのかという線引きだけを書きます。
一方で、日付の正規化や金額計算、登録番号の形式検査、CSVの突合、必須項目の欠落判定は、もう答えが決まっています。こうした処理を自然言語の指示から毎回読み取らせると、モデルや会話が変わるたびに、出力を確かめ直すことになります。毎回やっていたのは、まさにこの確認でした。
固定できる処理をコードへ移すと、コード、入力、参照データ、実行環境が同じである限り、同じ判定が返ってきます。要件が変わったときも、Gitの差分を追えば何をどう変えたのか分かります。文章に書いた指示との違いは、ここにあります。
では、そのPythonは誰が書くのか
定型処理をコードへ移すと言うと、経理の側がPythonを覚える話に聞こえるかもしれません。実際には、コードを書くところからAIの担当です。人が用意するのは、業務要件と正常例、異常例、それから期待する出力です。
- 現在の手順と判定基準を文章で整理する
- 正常データと異常データをAIへ渡す
- Pythonの初稿と検証方法を作らせる
- 過去データに対して実行し、期待結果と突合する
- 要件どおりになった処理を次回も再利用する
この流れを一度とおった処理は、翌月も同じコードで動かすだけです。
とはいえ、全部がきれいに自動になったわけではありません。現在の実装には、承認済みの科目対応を処理対象ごとに追加していく仕組みが残っています。設定ファイルへの切り出しも自動テストの整備もこれからで、完全な無人運転ではないのが実際のところです。
もちろん、AIが書いたコードにも誤りは入ります。それでも、入力と出力を保存して同じ条件でやり直せるので、会話の中の解釈だけに頼っていたころより、原因を絞りやすくなりました。
経理のAI自動化を5つの役割に分ける
この分け方は、公開されている設計指針とも合っています。2026年7月17日に確認したOpenAIのエージェント実践ガイドは、あらかじめ決めたルールだけでは扱いきれない業務を、エージェントの候補としています。Anthropicも、明確な手順で処理できる仕事にはワークフローを、手順数を予測しにくい開かれた問題にはエージェントを、というように使い分けています。
経理の話に引き付けると、答えの決まった計算をAIに考えさせ続ける必要はない、ということです。Pythonに正常系を処理させ、まだルールのない例外で止めます。AIの柔軟な調査を使うのは、そこからです。
役割は5つに分かれました。指示書、要件文書、Python、AI、人です。
5つの層に置くもの、置かないもの
それぞれに、置くものと置かないものを決めています。
| 層 | 置くもの | 置かないもの |
|---|---|---|
| 指示書 | 対象、正本、コマンド、禁止事項、完了条件 | 個々の計算や突合のロジック |
| 要件文書 | 業務上の理由、判定基準、例外の定義 | Pythonと同じ実装手順の複製 |
| Python | 取得、整形、計算、照合、分類、ログ | 曖昧な会計判断と承認 |
| AI | コードの生成と改修、実行の補助、結果の要約、例外の調査 | 元に戻せない確定操作 |
| 人 | 要件を決める、例外への対応を選ぶ、最終承認 | 全件の反復作業 |
見てのとおり、AIを処理から外したわけではありません。プログラムを作り、必要に応じて実行し、結果を読んで修正案を出すところまで任せています。任せたうえで、内容が固まったロジックはその場の会話に置かず、あとから同じ条件で動かせるコードとして残しています。
前払費用の月次処理での分け方
実際の経理業務では、前払費用の月次処理をこの形に分けました。Pythonが対象取引を抽出して、証憑を取得します。利用期間が確定した明細は、日割り計算、摘要の正規化、月別集計までそのまま進みます。
- Python：対象抽出、期間計算、更新データ作成、集計、更新後の件数と合計の検証
- AI：文字情報を持たない証憑のOCR、過去仕訳と証憑内容から科目候補を整理
- 人：利用期間や科目候補を確認し、本番反映を承認
効いているのは、検証までPython側に入っている点です。更新時に残すべき項目、更新順によって起きる一時的な超過エラー、書き込み後に確かめる合計——以前ならAI向けの注意書きにしていた内容を、処理と検証そのものに組み込みました。
申請チェックも考え方は同じです。テキストを取得できる証憑は、金額、日付、登録番号、税区分をPythonで判定します。画像やスキャンの証憑だけをAI-OCRに送り、按分や規程上の特例は人が判断します。
新規取引先チェックと経費精算のレシート照合を運用したあとで、何度も繰り返す正常系をコードへ移しました。
ルールのない例外だけをAIに戻す
プログラムは、あらかじめ決めた条件には強い一方で、ルールにない事情まで勝手に決めさせるわけにはいきません。実際、前払費用の処理でも、こういうケースが出てきます。
- 証憑に利用期間が書かれていない
- 複数明細へ按分されている
- 過去データと現行システムで金額がずれる
- 税務上の特例が疑われる
こうしたケースは「要確認」で止めます。止めたあとが、AIの出番です。関連資料と過去の処理を調べてもらい、確認できた事実、差異の原因候補、選択肢、推奨する対応、不足している情報を整理してもらいます。人はその根拠を読んで、どの対応を採るかを決めます。
流れとしては、こうです。
- Pythonが正常系を処理し、例外一覧を出す
- AIが例外の根拠と対応案を調べる
- 人が方針を決める
- 一度きりなら例外記録として残す
- 繰り返すならテストケースに加え、コードへ反映する
例外が出るたびに指示書を長くしていた冒頭のやり方とは、ちょうど逆向きです。繰り返し現れる条件だけをコードへ戻すので、次回から人が確かめる対象が減っていきます。
二重実行のその後
この分業で減ったのは、実行時間だけではありませんでした。同じルールを毎回説明する作業も、全件の出力を読み直す作業も消えています。構造としては、こう変わりました。
- 定型ロジックの変更先を共通のPython処理へ集約できる
- AIと人が見る対象を全件から例外一覧へ絞れる
- 繰り返す例外をテストとコードへ移せる
- モデルや実行環境が変わっても、入口の指示書を大きく直さずに済む
冒頭の二重実行も、この形で解消しています。実際の処理をスクリプトへ集約し、AI向けの入口は「何を読み、何を実行するか」だけに絞りました。正本と起動経路が1つになったので、同じ判定を三重に管理せずに済んでいます。
コードにしたあとの安全網
コードにしたから安心、という話でもないんです。要件そのものが間違っていれば、コードは同じ間違いを高速で繰り返します。正直に書くと、現時点では体系的な自動テストがなく、dry-run、1件だけの実行、実データを再取得して照合する方法に頼っている部分もあります。
- 既定はdry-runにし、書き込みは明示的に指定したときだけ実行する
- 対象を1件に絞って確認してから全件へ広げる
- 更新前データを保存し、更新後に件数、金額、合計を再取得する
- 未定義パターンは処理せず、不一致で止める
足りない部分も、まだ残っています。一部の処理では、異常を検知したときの自動停止も、失敗後の復元も、実装できていません。自動テストと停止処理は、これから増やしていくところです。それでも、同じ条件で誤りを再現して差分を確かめられるようになったこと自体は、前進でした。
最初の1業務を移すときの手順
やったことは次の6つに収まります。
- 業務を定型処理、例外調査、最終判断に分ける
- 頻度が高く、入力と期待出力が明確な処理を1つ選ぶ
- 正常例と異常例をAIへ渡し、Pythonと検証方法を作らせる
- 読み取り専用またはdry-runで過去データと突合する
- 指示書には正本、実行コマンド、禁止事項、承認条件、停止条件だけを置く
- 例外はAIに調査させ、人が決め、繰り返すものはコードへ反映する
同じチェックが2つの経路から動いた原因は、AIが指示を守れなかったことだけではありませんでした。固まった処理の正本と起動経路を、文章の中にいくつも作っていたことにもありました。
例外のたびに指示ファイルへ注意事項を書き足していたあの作業は、いまは、繰り返す例外をテストとコードへ移す作業に置き換わっています。手順書の保守が新しい定型業務になる状態には、戻っていません。
定型処理はAIに毎回考えさせず、AIにコード化してもらう。実行と結果の整理も任せ、コードで扱えない例外だけを調べてもらう。
承認と責任をどこに置くかは、経理AIの内部統制について書いた記事で詳しく紹介しています。
経理AIの内部統制はどう設計する？作業と責任、証跡の分け方経理業務をAIに任せても、承認する人の責任まで移るわけではありません。新規取引先と経費精算の実例から、入…
