AIエージェント開発の進め方｜経理の月次チェックを3か月で検証した導入事例

AIエージェント開発の進め方とは、作ってから直すのではなく、1か月ごとに検証の目的を変えて本番化の可否を判断していく段取りのことです。わたしたちはいま、PR・広告事業を手がけるグループ企業の月次決算業務で、経費と原価のチェックをAIエージェントに任せる開発を進めています。このお客様は複数のグループ会社の経理を本社に集約済みで、月次のチェック対象は5,000件超です。設計の軸に置いたのは、全件の合否をAIに決めさせることではなく、人が目で見なければならない件数を減らすことです。この記事は、その考え方と3か月の検証サイクル、並行して実施した「担当者が自分でAI化を判断できるようにする研修」の設計を、実際の数字とともにまとめました。

目次

• 1. 課題：本当の問題は人手不足ではなかった
• 2. 打ち手の全体像：人が見る件数を減らす
• 3. 設計の勘所5点
• 4. 3か月で本番化を判断する検証サイクル
• 5. ユーザー自身がAI化を判断できるようにする
• 6. 現在地と、これから測ること
• 7. うまくいかなかったこと
• 8. まとめ

1. 課題：本当の問題は人手不足ではなかった

このお客様では、月次決算のピークに派遣社員を投入し、経費精算と発注請求のチェックをしていました。症状は3つありました。

• 対象件数が月5,000件を超え、ピーク時に人を足さないと締めが間に合わない
• 派遣社員の判定品質が担当者ごとに違うため、社員のダブルチェックが外せない
• 契約が切れるたびに教育がやり直しになり、同じ種類の差し戻しが毎月繰り返される

さらに、事務系派遣は時給が上昇し、募集しても人が集まらない状況が続いていました。ここまでは「人手不足」の話に見えます。

しかし、本当の問題は人手不足ではなく、判断基準が人にしか残らないことでした。経費チェックの正解は、マニュアルに書かれた条文だけでは決まりません。「グループ会社からの請求だから実印がなくても支払可」「部門間請求だから添付がなくても通す」といった運用上の例外が、現場の頭の中にだけありました。人が入れ替わるたびにこの部分が失われるので、教育コストが下がらず、品質も安定しません。

言い換えると、人を増やしても解決しない構造でした。だから打ち手は「人の代わりを雇う」ではなく、「判断基準をシステムの外に出して、残るようにする」ことになります。そしてゴールは、人を工程から外すことではなく、人が目で見なければならない件数を減らすことに置きました。

2. 打ち手の全体像：人が見る件数を減らす

導入判断で最初に効くのは機能の多さではなく、現場の学習コストと調達の重さです。そのため、現場から見える変化を最小にしました。

• 新しく増えたもの：既存システム側の連携API（1本）、AIエージェント本体、判定レポートを確認する手順
• 増えなかったもの：申請画面、承認フロー、現場の入力操作、追加のSaaSライセンス

申請者は、これまでどおり経費精算システムとSFAに登録するだけです。AIは登録済みのデータと添付書類を読み、結果を次の3つに振り分けます。

1. OK（不備なし）：人は開きません。どの項目をどう突合したかの根拠だけが記録として残ります
2. NG・修正（不備あり）：不備事由つきで人に上げます。人が確認して差し戻します
3. NG・判断不可：添付PDFが読み取れない、押印の有無が画像から確認できないなど、判断材料が足りないケースです。人が目で見て判断します

人の役割は「全件を見ること」から「②と③だけを見ること」に変わります。最終判断は引き続き人が行います。

3. 設計の勘所5点

経営判断で持ち帰れるのは手順ではなく判断基準です。そこで、採用した案と一緒に「やらなかったこと」も書きます。

3-1. 検証はデスクトップ版、本番はAPI構成に分ける

• 判断：プロンプトの検証はデスクトップ版のチャットで行い、本番の処理はLLMのAPIを直接呼ぶバッチ構成にしました。
• 理由：切り分けの基準は機能の差ではなく、件数と納期です。デスクトップ版には、1回の会話に載せられる情報量と、一定時間あたりに使える量の上限があります。月5,000件超を締めまでの数日で処理しようとすると、この上限に必ず当たります。逆に、数十件のプロンプト検証なら定額のデスクトップ版のほうが速く、追加の費用もかかりません。
• やらなかったこと：本番もデスクトップ版で運用する案は、件数と納期の2点で成立しないため外しました。開発者向けのコーディング用エージェントで組む案も、実行環境とコスト管理が業務運用に向かないため採りませんでした。

3-2. 最上位モデルではなく標準モデルを主力にする

• 判断：候補4モデルを比較し、標準クラスのモデルを主力に選びました。
• 理由：プロンプト検証時の回答と比べたところ、上位2モデルはいずれも100%一致した一方、最軽量モデルは50%しか一致しませんでした。品質が同じなら、より安価なほうを選びます。
• やらなかったこと：「一番賢いモデルを全件に使う」という選び方はしませんでした。月5,000件では、1件あたり数円の差がそのまま月額の差になります。

3-3. 全件の合否をAIに決めさせず、人が見る件数を減らす

• 判断：AIには全件を突合させたうえで、出力を「OK」「NG・修正」「NG・判断不可」の3区分にしました。人が開くのは後ろの2つだけで、承認・差し戻しの実行は人が行います。
• 理由：確率で答えを出す以上、AIは必ず間違えます。ここで狙うべきは判定の完全自動化ではなく、人の目を、本当に人でなければ決められないものへ寄せることです。判断材料が足りないケースをAIに無理やり白黒つけさせると、いちばん危ない誤りがOKの山に紛れます。だから「判断不可」という逃げ道を最初から出力仕様に入れました。
• やらなかったこと：2つあります。1つは自動承認（AIによる直接更新）で、人的チェックが形骸化するリスクのほうが大きいと判断して初期スコープから外しました。もう1つは、AIに必ずOKかNGを返させる設計です。精度の数字は上がりますが、人が見るべき件数が見えなくなります。

3-4. 正解データは「否認リスト」で代替する

• 判断：業務側に正解データの整備を依頼せず、過去の差し戻し理由（否認リスト）を集めて評価基準に使いました。
• 理由：正解データづくりは業務部門の稼働を前提にします。決算期の経理は最も忙しく、ここを前提にすると計画が止まります。
• やらなかったこと：「正解データが揃うまで着手しない」という進め方はしませんでした。

3-5. データはテナント内で完結させる

• 判断：経費データと添付書類の処理を、契約したテナント内で完結する構成にしました。
• 理由：経費には取引先名と金額が含まれます。入力が学習に使われない契約・設定であることを、着手前に情報システム部門と確認しました。
• やらなかったこと：個人アカウントや汎用のファイル共有サービスを経由する検証はしませんでした。

4. 3か月で本番化を判断する検証サイクル

ここがこの案件でいちばん持ち帰ってもらいたい部分です。月次業務は月に1回しか回りません。検証のやり直しは1回につき1か月かかります。だから「1か月＝1回の検証」と割り切り、月ごとに検証の目的を変えました。

4-1. 1か月目：過去データで構築する

前月に計上済みのデータを使い、構築とプロンプト検証をします。狙いは精度を上げることではなく、「そもそもこの業務はAIで解けるのか」を本番前に確かめることです。

この段階で、押印のない手書き領収書がチェックをすり抜ける、請求書の宛名確認の手順が抜けている、といった穴が見つかりました。いずれもプロンプトの追記で直せる種類の穴で、業務そのものが解けないわけではないと判断できました。ここで「解けない」とわかれば、開発に入る前に撤退できます。

4-2. 2か月目：本番データで平行稼働し、全件突合する

当月の本番データで、人とAIを同時に走らせます。平行稼働はデスクトップ版で処理できる件数に絞り、原価399件・経費400件を対象にしました。この範囲で人の判定結果とAIの判定結果を全件突合し、差分を数えます。

図にすると、見るべき場所がはっきりします。人がNGと判断した集合と、AIがNGと判断した集合を重ねます。

一致率だけ見れば8割前後で、悪くない数字に見えます。しかし本番化の可否を決めるのは、左だけに残る15件です。右だけに残る100件超は、後述のとおりAIの誤りとは限りません。

4-3. 判定差は3つに仕分ける

差分をすべて「AIの誤り」として扱うと、プロンプトが際限なく膨らみます。次の3つに仕分けました。

1. AIの誤り → プロンプトを改定する。例：添付ファイルは存在したが、請求日が過去である点をAIが見落としていた
2. 人の運用差 → AIではなく基準側を直す。例：社内間の取引は添付なしで通す運用があり、文書化されていなかった。人OK・AI NGの多くはこちらでした
3. データの取得差 → 手順を直す。例：経理が修正した後のデータを取得していたため、修正前を見た人の判定と噛み合わなかった

2番目と3番目は、AIを直しても直りません。AI導入は、それまで暗黙だった業務ルールの棚卸しを強制します。ここを「AIの精度が悪い」と片付けると、本番化はいつまでも近づきません。

仕分けとあわせて、誰が決めるかも先に置きます。正誤の評価と本番移行の可否は業務部門、プロンプトの改定は開発側、スコープと打ち切りはPMが判断します。

4-4. 2か月目と3か月目のあいだに、コスト試算を挟む

見落とされがちですが、本番化を判定する前に、ランニングコストの試算と承認を1工程として入れます。

タイミングが重要です。1件あたりのコストは、プロンプトの長さと添付書類の読み取り量で決まります。設計前に見積もった数字は、まず外れます。平行稼働を終えてプロンプトが固まった時点なら、実測に近い数字が出せます。

出すのは3つです。

• 候補モデルごとの品質（プロンプト検証時の回答と、どれだけ一致するか）
• 1件あたりの単価
• 月間件数を掛けた月額

この3つを並べて、品質が同じなら安いほうを選びます（3-2のとおりです）。検証そのものは定額のデスクトップ版で回し（3-1）、従量課金は試算に必要な分だけ使いました。

4-5. 3か月目：同じ観点で測り直す

改定したプロンプトで、翌月の本番データを同じ方法で測ります。見るのは一致率の上下ではなく、2か月目に見つけた致命的な誤りが消えたかどうかです。消えていれば本番化を判定し、残っていればもう1か月回します。

この案件では、3回目の検証と本番化判定をこれから実施します。

5. ユーザー自身がAI化を判断できるようにする

もう1つの柱が研修です。開発を外部に任せきりにすると、次のテーマを選ぶたびに外部の判断待ちになります。そこで、業務部門が自分で「この業務はAI化できるか」を判断できる状態を先につくりました。

5-1. 研修のゴールを「使えるようになる」に置かない

研修のゴールは、プロンプトの書き方の習得ではなく、自分の担当業務の何をどこまでAI化できるかを、自ら切り分けられることに置きました。そのために、AIの仕組み（確率で予測する／学習範囲の外は知らない／持たせたツールの範囲しか実行できない）から、業務の任せやすさが決まる理由を説明しています。

5-2. 持ち帰りは「適性チェックリスト」1枚

受講者が持ち帰るのは、次の3段階で判定するチェックリストです。結論は3点セットで出します。

記入例：経費チェック＝〈できる〉〈★4〉〈54h/月＝特大〉。

工夫した点が1つあります。チェック項目を「業務のこと」と「環境のこと」に分け、環境のこと（規約・学習設定・コネクタの有無）は空欄のままでよいとしました。受講者に技術調査をさせると、そこで手が止まるためです。空欄は推進担当が埋めます。

5-3. 結果：168業務・月2,091時間の候補が出た

宿題として全員に自分の業務を診断してもらったところ、全168業務・合計で月2,091時間の改善見込みが挙がりました（見込み値であり、必達値ではありません）。

6. 現在地と、これから測ること

この記事は進め方を扱っています。導入の成果は、本番化してからでないと測れません。2026年9月時点の現在地と、これから測る項目を書いておきます。

現在地：2か月目の平行稼働まで終わり、致命的な誤り（人NG・AI OK）を原価3件・経費12件まで特定しました。プロンプトを改定し、3か月目の再検証と本番化判定をこれから実施します。

これから測る項目は3つです。

• 人が目で見る件数を、どれだけ減らせたか（OK判定分を人が開かなくなる効果）
• 月次チェックにかかっていた工数が、どれだけ減ったか
• 本番運用に移した後、致命的な誤りが何件残っているか

いずれも実測が出た時点で、別の記事として報告します。推定値や概算では書きません。事例記事の数値は営業資料に転記されるため、後から出典を辿れないものを載せないと決めています。

7. うまくいかなかったこと

お客様の落ち度ではなく、わたしたちの設計判断の誤りとして3つ挙げます。

7-1. 最初に見る指標を間違えた

1か月目の報告で、わたしたちは判定の一致率を主指標として提示しました。数字としては見栄えがしますが、本番化の可否を決める材料にはなりません。2か月目に「人NG・AI OK」の件数へ指標を切り替えましたが、この切り替えは最初からできたはずでした。

7-2. 人の判定を正解として扱ってしまった

平行稼働の突合では、人の判定を正解、AIの判定を採点対象という前提で始めました。実際には、人OK・AI NGとされた100件超の多くが、文書化されていない運用ルール（社内間取引は添付なしで可、など）に由来していました。AIの誤りとして数えたまま進めていたら、必要のないプロンプト改定を重ねることになっていました。

7-3. 比較するデータの取得時点を決めていなかった

経理が不備を直接修正した後のデータを取得していたケースがあり、人の判定とAIの判定が別の状態を見ていました。突合の前提として「いつ時点のデータを使うか」を決めておくべきでした。現在は取得タイミングを固定して再測定しています。

8. まとめ

• 全件の合否をAIに決めさせない。出力を「OK」「NG・修正」「NG・判断不可」に分け、人が目で見る件数を減らすことをゴールに置く。判断材料が足りないものは、AIに白黒をつけさせずに人へ回す
• 月次業務のAIエージェント化は「1か月＝1回の検証」で設計する。1か月目は過去データで解けるかを確認し、2か月目は本番データで致命的な誤りを検出し、3か月目にそれが消えたかを測る
• 精度の指標は一致率ではなく、人がNGと判断したものをAIがOKと判定した件数に置く
• 本番化を判定する前に、ランニングコストの試算と承認を1工程として挟む。プロンプトが固まってからでないと1件あたりの単価は読めないので、平行稼働の後に置く
• 人とAIの判定差は「AIの誤り」「人の運用差」「データの取得差」の3つに仕分ける。AIを直しても直らない差が必ず混ざっている
• デスクトップ版とAPI構成の切り分けは、件数だけでなく納期とセットで決める。短納期で大量に処理しようとすると、デスクトップ版は利用量の上限に当たる。逆に納期に余裕があれば開発は要らない
• 現場から見える変化は最小にする。申請画面・承認フローを変えずに済む構成なら、導入の合意形成が速い
• 開発と同時に、業務部門が自分でAI化の可否を判定できる状態をつくる。ただし候補が出た後の仕分け（エンジニアが作る／本人が作る）は先に決めておく

ご相談ください

次のような課題をお持ちでしたら、FROM CENTERにご相談ください。

• 月次決算のピークを人員の追加投入でしのいでおり、来期の体制が見通せない
• AI導入のPoCは実施したが、本番化の判断基準が決められないまま止まっている
• 社内でAI活用のテーマは挙がるものの、誰が作るのかが決まらず着手できない

お問い合わせはこちら