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