この記事の要点
- 自動化の単位を、画面操作ではなく業務の完了に置く
- AI・ルール処理・人の判断を組み合わせる
- 例外対応を含む総工数で導入効果を見る
- 依頼を受け付ける
- 必要情報を照合する
- 処理・承認を進める
- 完了を確認する
AI-BPOは「全部をAIに丸投げすること」ではない
本記事ではAI-BPO型の仕組みを、AIと既存システムを組み合わせ、継続的な業務処理を担う設計として扱います。統一された製品分類や契約形態を意味する言葉ではありません。従来の業務委託を置き換える場合もあれば、社内業務の一部をシステム化する場合もあります。
たとえば問い合わせの要約ができても、担当者が案件を振り分け、返信を書き、対応履歴を登録しているなら、仕事の大部分は残っています。受付、担当の決定、回答準備、承認、送信、完了確認を一つの単位にすると、本当に減らせる負担が見えます。
一方、金額の例外承認や顧客との重要な合意まで自動化することが目的ではありません。処理の連続性を高めながら、責任を持つ人が必要な時点で判断できる形を目指します。
「何をもって完了か」を先に決める
着手時は、担当者へ「毎日どんな操作をしますか」だけでなく、「何が起きたら仕事が始まり、何が揃えば終わりますか」と聞きます。受注処理なら、注文メールを読んだ時点ではなく、正しい内容で受注登録され、顧客へ確認が返り、例外が担当者へ渡った時点が完了候補です。
| 項目 | 確認する内容 | 曖昧なままにした場合 |
|---|---|---|
| 開始条件 | メール受信、締め日、未対応案件の発生 | 同じ依頼を複数回処理する |
| 完了条件 | 登録結果、通知結果、証跡の保存 | 下書きを作っただけで完了扱いになる |
| 中断条件 | 情報不足、金額差異、権限不足 | 判断できない案件が滞留する |
| 引き継ぎ先 | 担当部署、責任者、対応期限 | AIが止まった後の担当が決まらない |
工程ごとに担当部署が異なる場合は、前工程の完了と次工程の受付を別々に記録します。「送ったはず」と「受け取っていない」の間を可視化することも、業務改善の重要な対象です。
AI・ルール処理・人を役割で分ける
当社の設計案では、文章からの意図の読み取りや回答案の作成をAI、金額計算や登録条件のチェックを通常のプログラム、人間関係や責任を伴う例外判断を人に分けます。同じ業務の中で使い分けるため、AIの利用割合そのものは成果指標にしません。
Anthropicの技術資料は、固定された経路を進むワークフローと、モデルが処理を選ぶエージェントを区別しています。この区別を参考に、順序が決まる業務は工程を固定し、必要な部分だけ柔軟な判断を使う案が考えられます。
| 工程 | AI・システム側 | 人が担うこと |
|---|---|---|
| 受付 | 注文の内容を整理し、既存案件と照合 | 注文者や取引条件の例外確認 |
| 準備 | 不足情報の検出、確認文の作成 | 未確定条件の合意 |
| 実行 | 承認済みの内容で登録・通知 | 価格・納期の特例承認 |
| 追跡 | 結果確認、未完了の再通知 | 解決できない案件の調整 |
この表は構築イメージであり、導入済みの顧客実績ではありません。利用できる連携機能、社内規程、相手先の運用により実現範囲は変わります。
通常処理より先に、止め方を話し合う
設計会議では、きれいな成功例だけでなく、取引先不明、添付不足、重複依頼、処理途中の通信切断を並べます。それぞれについて「自動で再試行」「情報を待つ」「担当者へ渡す」「処理を止める」を決め、理由と現在地を画面に残します。
承認は文章に「承認済み」と書かれているだけでは成立しません。権限を持つ利用者が対象の内容を確認した記録と、実行対象の版を結び付けます。承認後に価格や宛先が変わったら、以前の承認をそのまま使わないルールが必要です。
業務の委託先も関わる場合、連絡・再処理・データ訂正の責任分担を明確にします。システム化によって境界が消えるわけではなく、むしろ境界を機械が扱える状態にする作業が求められます。
ワークシート:受注1件を最後まで追ってみる
検討会では、過去の受注1件を題材に、メールの受信から顧客への確認までを順番に再現する方法があります。各工程で、開いた画面、転記した項目、待った相手、迷った判断を記入します。件数の平均から始めるより、実際の仕事のつながりを具体化できます。
次に同じ注文がもう一度届いた場合、商品が欠品していた場合、承認者が休暇だった場合を加えます。これは架空の検証条件であり、成果の実績ではありません。どの時点で通常フローから外れ、何があれば再開できるかを担当者と確認します。
改善案を作ったら、自動化で消える作業、残る確認、新しく増える監視を色分けします。AIの前処理を担当者が毎回行う必要があるなら、その負担も含めます。受注登録は速くなっても、承認待ちが変わらなければ、顧客への回答速度は変わらないかもしれません。
このワークシートの成果物は、ツールの一覧ではなく、開始と完了が分かるフロー、例外一覧、担当分担、検証したい仮説です。開発会社が業務をどう理解したかを、発注前に同じ図で確認できます。
「自動化率」だけで成功を判断しない
自動で終えた割合が高くても、残った例外の調査に時間がかかれば負担は減りません。対象件数、完了件数、手戻り件数、例外の滞留時間、人の確認時間を同じ期間で測ります。対象外にした難しい案件も記録し、都合のよい母数に変えないことが大切です。
まず一つの部署・一つの入口に絞り、現行業務と並べて結果を比較する案を推奨します。最初から自動送信や正式登録を有効にせず、確認可能な下書きで処理を通してみると、業務ルールの抜けを発見しやすくなります。
相談前には、実際の帳票の匿名化サンプル、通常時と繁忙時の件数、例外の種類、完了までの担当部署を揃えてください。個別のツール選びはAIエージェントとRPAの比較、投資判断はROIの考え方で補えます。
参考にした一次情報
- Anthropic「Building effective agents」
あらかじめ決めた処理経路を使うワークフローと、モデルが処理を選ぶエージェントの区別を参照。
参照日: 2026年10月1日。リンク先の説明は機能・設計原則の確認に用いています。本記事の業務例や推奨する進め方は当社の提案であり、引用元が当社サービスや効果を保証するものではありません。
どの工程をAIに任せるか、業務全体から整理します。
現在の業務フロー、利用データ、例外対応をもとに、AIに任せる範囲と人が判断する箇所を整理します。仕様が固まる前のご相談も承ります。
開発を相談する