AIエージェントを業務に組み込む設計:人とAIの役割分担
この記事のテーマで進めたい事業がある方へ:お問い合わせ →
AIを業務の流れに組み込むときは、「AIが行うこと」「人が確認すること」「人だけが判断すること」を、作業ごとに先に分けて設計します。AIエージェント(目標に向けて、複数の手順を自律的に進めるAIの仕組み)は便利ですが、誤りが連鎖したり、意図しない操作が行われたりするリスクがあります。そのため、任せる範囲と権限を小さく始め、実績を見て広げるのが基本です。
この記事では、業務の流れの中でのAIと人の役割分担の決め方と、確認点・権限・記録の設計を説明します。検証の進め方は既存業務でのAI PoCの設計:成功基準と進め方を参照してください。
役割分担は3段階で考える
| 段階 | AIの役割 | 人の役割 | 向く場面 |
|---|---|---|---|
| 支援 | 情報の検索、要約、下書きの提示 | 内容を確認し、使うかを判断・実行 | 最初の導入、誤りの影響が大きい業務 |
| 協働 | 手順の一部を実行し、結果を提示 | 要所で承認し、例外に対応 | 定型的で、確認点を置ける業務 |
| 自動実行 | 手順を自律的に実行 | 結果の監視と例外対応 | 誤りの影響が小さく、検証済みの業務 |
最初は「支援」から始め、精度と運用の実績に応じて「協働」へ進めます。「自動実行」は、誤りの影響が小さく、失敗しても元に戻せる業務に限定します。
設計の進め方
1. 業務の流れを書き出す
対象の業務を、開始から終了までの手順で書きます。各手順について、「入力は何か」「出力は何か」「誰が責任を持つか」を明確にします。(棚卸しの方法は業務の棚卸しとAI適用候補の見つけ方)
2. 手順ごとに担当を割り当てる
次の問いで判断します。
- 誤った場合の影響は大きいか(金銭、安全、信用、法令)
- 元に戻せるか(取り消し、修正ができるか)
- 判断に経験や文脈が必要か
- 顧客や取引先に直接影響するか
- 説明責任が求められるか
影響が大きい、元に戻せない、責任の説明が必要な手順は、人が判断・承認する手順にします。
3. 確認点(チェックポイント)を置く
人の確認点は、多すぎても少なすぎても機能しません。
- AIの出力が外部に出る前(顧客への送信、システムへの登録、支払いなど)に置く
- 確認する人に、判断のための材料(根拠となった情報、AIの確信度や不確実な点)を示す
- 確認する時間を業務量に含める。確認が忙しさで形だけにならないようにする
AI事業者ガイドラインは、AIの出力を特定の個人または集団の評価の参考にする場合には、AIを利用している旨を対象者に通知し、自動化バイアス(AIの出力を過度に信頼してしまうこと)も踏まえて人間による合理的な判断のもとで説明責任を果たすことを求めています。人が確認する設計は、この点でも重要です。
4. 権限を最小にする
AIが社内のシステムやデータに接続する場合は、必要最小限の権限だけを与えます。
- 読み取りのみか、書き込みも必要か
- アクセスできるデータの範囲
- 実行できる操作の種類(送信、削除、支払いなどは特に慎重に)
- 利用者ごとの権限(AIが利用者の権限を超えて情報を取得しないように)
5. 記録を残す
AIがどの情報をもとに何を出力し、誰が確認して何を決めたかを、記録に残します。問題が起きたときの原因の調査と、説明に必要です。ガイドラインも、事後検証のための作業記録の保存を、開発者側の事項として挙げています。
6. 停止と例外の手順を決める
- AIが不確かな場合、人に引き継ぐ条件(信頼度が低い、想定外の入力など)
- 異常を検知した場合の停止手順と、連絡先
- 利用を止めても業務が続けられる代替の手順
業種別の例(仮の例)
- 小売業の場合:問い合わせへの回答で、AIが過去の対応記録を検索して回答案を作る(支援)。担当者が確認して送信する。返品や返金の判断は人が行う。
- 製造業の場合:不具合の報告が入ると、AIが類似の過去事例を集めて一覧にする(協働)。是正措置の決定は担当者と責任者が行う。
- 金融業の場合:書類の記載漏れの候補をAIが指摘する(支援)。審査の判断は担当者が行い、判断の根拠は記録する。
- 建設業の場合:日報や写真からAIが報告書の下書きを作る(支援)。現場責任者が確認して提出する。
- サービス業の場合:予約の変更依頼のうち、定型的なものをAIが処理し(協働)、例外は担当者に回す。
注意点
- 責任の所在は人にある:AIが出力した内容でも、業務の結果の責任は組織にあります。AIの責任にはできません。
- 利用するサービスの条件を守る:提供者が定める利用上の留意点や、想定している範囲を超えない使い方にします。
- 性能は変わる:AIのバージョンや入力によって出力の質が変わることがあります。定期的に評価し直す仕組みが必要です。
- 人の役割を再設計する:AIが下書きを作るようになると、人の仕事は「作る」から「確認し、判断する」に変わります。必要な能力や研修はAI転換で人を置き去りにしない:リスキリングと現場定着で扱います。
- 要件の整理:業務システムとして組み込む場合は、要件定義の進め方も参考になります。
まとめ
AIの業務への組み込みは、作業ごとに、AIが行うこと、人が確認すること、人だけが判断することを分けて設計します。最初は支援の役割から始め、確認点、最小の権限、記録、停止の手順を整えたうえで、実績に応じて範囲を広げます。
参考資料
同じ工程の記事
業務のAI化で人とAIの役割分担を決める:確認・例外・記録の設計
業務をAI前提に組み替えるときは、人とAIの役割分担をどう決めるかが成否を分けます。作業の分け方、人が確認する地点の置き方、例外の扱い、記録の残し方を、業務のAI化を任された担当者向けに整理します。
生成AIのPoCが本番化しない理由:成功基準・評価データ・運用コストの決め方
生成AIのPoCが失敗して本番化に進まない主な原因は、成功基準・評価データ・運用コストを最初に決めていないことです。確認・修正の時間まで含めて測り、本番化・修正・中止を判断できるようにするための決め方と進め方、失敗しやすい点を整理します。本番化の判断材料の作り方も扱います。
PoC・MVP開発の費用の内訳と見積もりの読み方:何で金額が決まるか
PoC・MVP開発の費用は、範囲・体制・期間で決まります。見積もりの内訳の項目、金額が変わる要因、複数社の見積もりをそろえて比べる方法、追加費用が出やすい点を、相場の数字に頼らず整理します。
PoCとMVPの違い:どちらから始めるかを決める判断の目安
PoCとMVPの違いは、確かめたい問いにあります。PoCは「できるか」、MVPは「使われ、お金を払われるか」。どちらから始めるかを決める4つの質問、期間と体制の違い、外部に頼むときの注意点を整理します。
