経費資料のAI分類を一工程で試す——入力・根拠・確認待ちを分ける設計

「業務を全部AIに」は、最初の単位が大きすぎる

月次の事務を担当する人が、「毎月同じことをしているので全部AIに任せたい」と相談したとします。資料の収集、分類、修正、登録、最終確認が一つの言葉に含まれているため、何を作れば成功かが曖昧です。分類だけなら候補を返す試作ができますが、登録まで含めると権限、重複防止、取り消し、結果の照合が必要です。最初の工程を選ぶときは、業務全体の大きさより、入力と出力を区切れるか、失敗を確かめられるかを見ます。小さな単位でも、その後の判断に役立つことが大切です。

月次の経費資料を整理する場面を考えます。領収書から支出の種類を候補として出し、根拠の箇所を示し、担当者が確認する範囲を最初の試作にします。正式な登録や支払いは対象にしません。分類、修正、起票を一度に任せず、どの段階で人の判断が必要かを分けます。候補を作る工程と、それが資料に合うかを検証する工程、業務担当が受け入れる工程をそれぞれ記録すれば、途中で止まった理由と残る仕事が見えます。

試作でまず知りたいのは、分類候補が担当者の判断を助けるかです。候補があるだけでは効果は分からないため、根拠を確認できた資料、修正が必要だった資料、追加情報を求めた資料を分けます。時間短縮を測る場合も、生成時間だけでなく確認と訂正を含む範囲を先に定めます。

仕事を、入力から結果までの短い工程に分ける

担当者の作業を、資料を集める、項目を読む、支出を分類する、誤りを直す、登録案を作る、正式に登録する、保存結果を確認する、と分けます。各工程に入力、出力、次へ進む条件を書きます。分類なら、領収書と社内の分類表を受け取り、分類候補、根拠、不明な点を返すことが成果です。登録なら、確認済みの項目を受け取り、登録先から結果を取得することが成果です。「AIが回答した」を全工程の完成条件にしないことが、工程分割の第一歩です。

分類の前に必要な項目読取りも、別の工程として扱えます。日付や金額の形式は通常のプログラムで確認できる部分があり、用途の説明から分類する仕事は文脈を読む必要があります。全てをAIに投げるより、固定した規則で処理する部分を分けると、誤りの場所を調べやすくなります。逆に工程を細かくしすぎると受け渡しが増えます。読取りと分類を一つの試作に含める場合も、どちらで誤ったかを確認できる出力を残します。担当の数より、結果を説明できる単位を優先します。

担当者には普段の成功例だけでなく、迷った資料も示してもらいます。そこに人の判断が必要な条件が含まれています。手順書にない作業を自動化の対象から消すのではなく、確認待ちとして設計に残すことが重要です。

工程の聞き取りでは、実際に使う資料を一件ずつ追うと隠れた仕事を見つけられます。画面へ転記する前に別の担当へ確認している、保存後に番号を控えている、といった作業です。手順書の見出しだけで自動化の範囲を決めず、入力から完成までに必要な確認を含めます。

最初に選ぶなら、確認しやすく取り消しやすい工程

候補の工程を比べる観点は、繰り返しの多さ、入力が手に入るか、正解を確かめられるか、誤りの影響、取り消しやすさです。経費の分類候補なら、社内の分類表と担当者の判断に照らせます。正式な支払いは結果の影響が大きく、単なる試作へ含める必要はありません。毎月の負担が大きい工程でも、入力が整理されていなければ先に資料の収集が必要です。「AI向きか」を能力の印象だけで判断せず、試す条件がそろうかを確認します。

分類を選んだ理由を記録すると、後で範囲を広げる判断ができます。例えば人が修正した分類を集められる、元資料へ戻れる、正式登録を変えずに比較できる、という条件です。誤りの影響を限定した比較なら、担当者は既存の仕事を続けながら候補の有用性を見られます。ただし既存の作業と二重に確認する負担もあります。試作の期間と対象を限定し、得たい判断材料を先に決めることで、比較だけが続く状態を避けます。取り消しやすいことは品質が低くてよいという意味ではなく、学習するための影響範囲を限定する条件です。

最初の対象を「領収書全種類」にせず、定型の支出一種類へ絞る案もあります。対象を狭めたことを隠さず、対象外が来たときの表示を決めます。試作で扱った範囲を明確にしておけば、次に広げる種類を選べます。

試作の対象を選んだ理由を業務担当と共有すれば、対象外の資料が来たときも処理範囲を説明できます。狭い対象の成功を全業務へ広げず、追加する資料の種類と検査を次の判断へ残します。

人に残すのは、最後のボタンだけではない

人の確認を正式登録の直前に置いても、根拠が見えなければ確認者は最初から調べ直します。分類候補の横に、原資料の該当箇所、適用した分類の説明、不明な点を表示する方法を提案します。人が行う仕事は、候補の意味を判断し、必要な修正を行い、正式登録へ進めるかを決めることです。確認者が何を見るかを設計せず「人が確認する」とだけ書いても、責任の所在は明らかになりません。必要な判断と情報を一組にします。

曖昧な資料は、全件を一つの確認一覧へ混ぜず、理由ごとに返すと扱いやすくなります。金額が読めない、分類が複数に当たる、資料が重複している、という違いで次の作業が変わります。分類の迷いなら担当者の判断、金額の欠落なら資料の追加、重複なら対象の照合が必要です。人へ返す件数だけを減らす目標では、無理な推定が増える可能性があります。確認待ちの妥当性、担当者が解消できたか、誤って通した資料がないかを合わせて見ます。

正式登録を人が行う場合でも、候補を作るAIが勝手に登録できない権限にする方法があります。指示と接続範囲をそろえ、候補作成の成功を登録完了と表示しないようにします。業務の段階を利用者に分かる言葉で示します。

確認者が多い業務では、誰がどの項目を確定するかも決めます。金額の確認担当と用途の分類担当が違う場合、全部を一人へ返しても判断できません。確認画面の論点を担当別に分け、既に確定した項目を保持したまま必要な判断だけを依頼する経路を考えます。

完成条件を、件数より結果の意味で定める

試作の完成条件を「百件処理した」にすると、誤分類や根拠のない候補も数に含まれます。分類試作の設計では、対象を選べたこと、必要な項目を返したこと、根拠へ戻れたこと、対象外や不足を確認へ返せたことを条件にします。分類結果が正しいかは担当者が基準に照らして確認します。件数は対象の規模を示せますが、品質や業務完了の代わりにはなりません。完成した成果と検査した範囲を一緒に残します。

候補の提出、成果物の検証、別担当のレビュー、受入を別の段階として管理する設計が考えられます。長い仕事の途中状態を保存できても、分類の妥当性まで自動で判断できるとは限りません。候補が存在することや必要項目がそろうことは機械で確認し、分類表をその資料へ適用できるかは担当者が確かめます。保存できたこと、検査を通ったこと、業務で受け入れたことを区別すれば、停止した場所に応じて次の担当を選べます。

結果の不一致が見つかったら、元資料の読取り、分類の規則、確認画面のどこを直すかを分けます。全てを「AIの精度」の問題へまとめない方が、改善の費用と効果を判断しやすくなります。

工程の分岐や差戻しをLangGraph、途中状態の保存をSQLiteへ分担する構成が考えられます。AIが分類する部分と、成果物を機械で検査して別担当が受け入れる部分を分ける方法です。経費分類では、候補が保存された段階と担当者が分類を確定した段階を別々に扱います。再開時には今回の資料と分類表の版を照合し、古い候補を現在の確認結果へ混ぜない条件も必要です。状態を保存できるだけで、経費の正式登録や支払いを実行したことにはなりません。

正常、情報不足、重複の三種類から試す

試験用には、分類が明確な領収書、用途が書かれていない領収書、同じ資料が二度届く例を用意します。明確な例は候補を返し、情報不足は確認待ち、重複は追加の登録候補を作らない、と期待結果を先に決めます。分類表へ当てはまらない例も用意し、勝手に近い分類へ押し込まないことを確かめます。正常な資料が全て止まっていないかも見ます。検査で使った種類と本番で来る種類の違いを残し、試作の成功を月次業務全体の成功へ広げないようにします。

担当者が訂正した資料では、どの項目がなぜ変わったかを記録します。分類名だけが変わったなら規則の説明を見直し、元金額が変わったなら読取りの検査へ戻します。画面が見にくくて訂正された場合は、AIの処理より表示の改善が必要です。試作の評価に人の確認時間を含めるなら、開始と終了の定義を決めます。候補生成の時間だけを測って業務の短縮と呼ぶことはできません。導入を続ける判断に必要な記録を、試す前から用意します。

試験には実データを使える権限や管理条件も必要です。説明用に作った資料で接続や画面を確かめる段階と、許可された業務資料で品質を評価する段階を分けます。前者の成功を後者の結果へ置き換えません。

次の工程へ広げると、必要な条件も増える

分類が役立つと分かってから、修正や起票へ広げる場合があります。修正は元の値を変更するため、変更前後と理由を残します。起票（登録の申請を作ること）は登録先に影響するため、対象の照合、同じ処理を繰り返さない条件、結果の取得が必要です。登録の応答が途切れたときは、成立している可能性を考えて先に保存先を確認します。前の工程の成功を、そのまま後の工程の安全へ引き継ぎません。追加する操作ごとに、権限と検査の契約を見直します。

工程をつなぐ際は、確認された入力が後段でも同じかを見ます。担当者が分類を直した後、古い候補を起票に使うと、確認の意味が失われます。今回の資料と確認済みの値を結び付け、変更後には影響する成果を再作成する条件を設けます。修正後には起票案だけでなく保存先の値も照合します。必要な確認を先に列挙し、形式検査、分類の判断、登録後の確認を誰が行うかを決めます。他の業務の工程数を当てはめず、自分の対象で人が残る範囲を検証します。

人の工程を減らすことが常に目標ではありません。取り消せない操作で判断を維持することは、業務の完成条件を守るための選択です。AIの担当範囲を広げる価値と、確認の負担や影響の大きさを比較します。

最初の選択を、次の判断材料へつなぐ

最初の工程を選ぶ際は、なぜその範囲にしたか、何が分かれば続けるか、何が起きれば中止するかを記します。分類試作なら、担当者が根拠を確認できる、誤りを訂正できる、対象外を適切に返せることが続行の材料になります。訂正が多くても、原因が台帳の未整備ならデータ整理へ切り替える選択があります。失敗を全部成功へ寄せず、開発の範囲を変える材料として使います。動く試作と、使える業務工程の差を確認することが目的です。

残る制約は、月ごとの入力や規則の変化です。ある月の資料だけで成功しても、別の支出種類や更新された分類表へ対応できる保証にはなりません。新しい対象を追加するたび、同じ基準で検査し、確認画面と再開手順を更新します。工程を選ぶ基準を持っていれば、AIの能力が変わっても業務の目的から判断できます。最初に任せる仕事は、最も派手な自動化より、入力と結果を確認でき、失敗から次の判断を学べる工程が有力です。

相談の段階で全工程を決め切る必要はありません。現在の資料、担当者の判断、変更の影響を整理し、一工程の試作と評価へつなげます。どこまでを確認したかを明示しながら進めることで、期待だけで範囲を広げることを避けられます。

試作を続けない判断をした場合も、何が分かったかを残します。入力の対象を絞れない、根拠の分類表がない、担当者が結果を確認できない、といった障害は、データ整備や業務の整理へつなげられます。AIの追加開発を止めることと、課題の解決を諦めることは別です。