本記事は、AWSのML Developer Relationsである久保さん(@icoxfog417)にお声掛けいただき実施した、AI-BPRのトライアルに関する内容です。AIエージェントによる業務改善が求められる世の中で、AIを使いながら、AIとの役割を明確化し、価値を最大限とする取り組みであるAI-BPRについて紹介します。
本記事で取り上げているAI-BRPのドライランシナリオ作成、ドライラン実行のAgent Skillsは26/7/6時点で未公開です。公開も予定されているとのことです。
AI-BPRとは
AI-BPRとは、「人のリソースを顧客価値につながる強みに集中させるために、ビジネスモデルや業務プロセスをAIエージェントが存在する前提で見直し、人とAIエージェントの役割と責任分担を再設計するアプローチ」です。
従来のBPRの取り組みでは、「問題をどのように改善するか」から始めるDeficit reflexなアプローチ、AIに仕事を奪われるという恐怖感、人対人のコミュニケーションのオーバーヘッドなどが要因で失敗する、または時間がかかってしまうケースが多くありました。AI-BPRではこれらの課題に対して、以下のアプローチで改善を図っています。
- どのように強みを強化するかを考える「強み起点」
- 人をより重要、かつ強みを発揮できる仕事にShiftする「心理的安全なロールシフト」
- AIとのインタラクティブな会話による「即時的フィードバック」
AI-BPRを成功させ、効果を発揮するためには「AIを導入して業務を効率化する」といった単なる置き換えだけでなく、「AIと共存していくために、強みを保ちつつ、業務をどのように変えることができるか？」を考えることが重要です。また組織を横断した提案も必要となります。これらを意識しないと、手作業の一部を自動化するだけで、より高度な仕事へのロールシフトやスケーリングができないためです。
AI-BPRのプロセス
AI-BPRでは4つのプロセスを通して業務プロセスを理解し、どの作業をAIエージェントに任せるか、どのように移行するかを決定します。
Observeは、業務フローを明確にし、分析するプロセスです。今のプロセスで強み💪がどこにあるか、誰に対して価値🎯を提供しているか、課題やリスク📌は何かを抽出します。
| 項目 | 内容 |
|---|---|
| 強み💪 | 個人や組織が持ち、顧客価値の源泉となっているもの |
| 価値🎯 | 社内外の顧客に提供できる成果 |
| 課題やリスク📌 | 現在の業務プロセスが持つ課題 |
Shiftは、Observeで明確になった強み、価値、課題をもとに、ペルソナ（作業者）の役割をどのように変えるかを設計するプロセスです。そのために業務プロセスを分割し、「卓越」「強化」「委譲」それぞれに割り当てます。
| 項目 | 内容 |
|---|---|
| 卓越 | 人が得意で、人にしかできない領域 価値のある領域で注力すべきポイント |
| 強化 | 一部をAIが担うことで、組織にスケールさせるべき領域 |
| 委譲 | 定型業務など、AIが担うべき領域 |
定型的な作業をAIに任せることで、人が介在しないとリスクがある業務や差別化要因となる創造的な業務に人のリソースをシフトすることができます。このあるべき業務フローを計画するのがShiftプロセスです。
Simulateは、Shiftで計画したロールシフト案を実際に実装して、効果があるか、悪影響や副作用が発生しないかを検証します。Shift段階では業務フローをもとにした設計でしかないため、このSimulateプロセスで、設計したTo-Beフローが本当に実現可能かを検証します。Simulateは、単に作ってみるだけではありません。AIエージェントに任せる業務を実際に流し、アウトプットに対して評価観点ごとにフィードバックを行い、改善によってどの程度品質が上がるかを確認するプロセスです。
Simulateでは、複数回サイクルを回し、To-Beフローを検証、改善していきます。サイクルごとに必要なテストケースを作成、追加し、結果を評価し、見つかった課題をもとに改善を繰り返していくことで、最適なTo-Beフローを見つけます。
サイクルを回し、評価結果が十分であると判断した場合、終了を提案します。終了が受け入れられた場合、Forecastへ移行します。
最後のForecastでは、Simulate で検証されたTo-Be設計を、いつ、どのように実装するかを決定し、実行計画へ落とし込みます。短期(1カ月)、中期(3カ月)、長期(6カ月)程度のマイルストンも設け、技術的、組織的にどのような課題と責任があるかも整理していきます。
Forecastで作成された計画は、BPRの終わりではありません。検証済みのTo-Be設計をもとに、実業務への提供と継続的改善を始めるための出発点として捉えることが重要です。
AI-BPRをドライランで体験してみる
今回のワークショップでは、AI-BPRのターゲットとする仮想シナリオを作成して、その仮想シナリオをもとに業務改善を目指すドライランを実施しました。
【事前準備】仮想シナリオの準備
AI-BPRの実施対象となる業務シナリオを作成します。実際は業務担当者がAIとやり取りしながら進めていきますが、今回はAI-BPRを一通り体験することが目的のため、仮想シナリオで対応します。
今回の仮想シナリオは、以下としました。要は社内の問い合わせ対応をAIの力を借りて効率化したい、となります。
関連部門からくるAIツールの問い合わせ対応を効率化したい。
類似した問い合わせが多いが、少しずつポイントが違うので、毎回調査して回答しています。
問い合わせ内容は、AIを活用したツールの使い方やそのガバナンスやセキュリティについてが多いです。
シナリオの具体化は、AIと壁打ちしながら進めていきます。AI-BPR向けのペルソナや業務データ作成もドライランシナリオを作成するAgent Skillsでしっかりと定義されているので、必要な情報を抜け漏れなく簡単に作成できます。
仮想シナリオの準備でのアウトプットファイルは以下となりました。
| ファイル | 内容 |
|---|---|
| persona.md | ペルソナ定義：長島太郎の背景、強み、リスク、業務フロー |
| inquiry_log.csv | 過去3ヶ月の問い合わせ記録（50件）- 傾向分析用 |
| security_faq.md | セキュリティFAQ（10問）- 既存ナレッジ |
| ai_governance_guide.md | AI活用ガバナンスガイドライン - 社内ルール |
| past_inquiries.md | 過去の代表的な問い合わせ5件と回答例 |
| web_search_notes.md | Web調査記録 - セキュリティ、コスト、法律等の参考情報 |
| cost_analysis.xlsx | AI導入による料金試算とROI分析 |
| security_concern_memo.md | セキュリティ懸念事項と対策案 |
AI-BPRの実行
作成した仮想シナリオを用いて、AI-BPRを実施しました。長島さんは仮想シナリオでのペルソナであり、実際の問い合わせ対応を担当する作業者です。
| 項目 | 内容 |
|---|---|
| 名前 | 長島 太郎 |
| 役職 | 製造業・AI推進部門 問い合わせ対応者 |
| 年代 | 40代後半 |
| 経歴 | 製造部門で15年勤務後、2年前にAI推進部門へ配置転換 |
| 性格 | 実務的、慎重、セキュリティ重視 |
Observe
ドライランのObserveプロセスでは、仮想シナリオのペルソナとAIが対話することで、業務プロセスを深掘りし、強みや課題を明確にしていきます。実際に明確化した業務フロー、そこから抽出された強み、価値、課題は下記の通りです。少し長いですが、イメージしやすいように掲載します。
💪 強み（Strength）- ペルソナが持っているもの
| No. | 強み名 | 内容 | 特徴 |
|---|---|---|---|
| 1 | セキュリティ・ガバナンス知識 | OpenAI利用規約、GDPR、日本法など最新情報をキャッチアップして理解している | ✅ 根拠のある回答ができ、信頼を構築できる |
| 2 | ステークホルダー信頼 | 問い合わせ者から「長島さんの回答は詳しくて安心できる」と評価されている | ✅ セキュリティという信頼必須の領域での信頼獲得 |
| 3 | 過去対応の資産 | 過去3ヶ月で50件のQ&A記録が蓄積されている | ✅ AI活用による効率化の素材になる |
🎯 価値（Value）- 組織と顧客が得られるもの
| No. | 価値名 | 内容 | 対象 |
|---|---|---|---|
| 1 | セキュリティと利用促進のバランス | セキュリティリスクを管理しながら、AI利用を推進できる環境の実現 | 全社 / 経営層 |
| 2 | 業務効率化による時間削減 | 月15時間 → 7.5時間に削減（50%削減）する | 長島 / 組織 |
| 3 | 組織的AIガバナンス体制 | 個人の知識ではなく、組織のプロセスとして定着する体制 | 組織全体 |
| 4 | 信頼できるガイダンス体制 | 全社従業員が同じレベルの正確で信頼できる回答を得られる | 全社従業員 |
📌 課題・リスク（Challenge & Risk）- 現在の問題
| No. | 課題名 | 現状 | インパクト | 優先度 |
|---|---|---|---|---|
| 1 | 時間効率性の低さ | 1件30分 × 月30件 = 月15時間の対応時間 | 戦略的業務ができていない、組織的負担が大きい | ⭐⭐⭐ |
| 2 | 業務の属人化と記録散在 | 対応記録がメール散在、他者への引き継ぎが困難 | 長島が不在だと対応困難、セキュリティ・ガバナンス情報が個人依存 | ⭐⭐ |
| 3 | セキュリティ懸念との二項対立 | AI導入で効率化したいが、データ蓄積・料金管理への懸念で推進が慎重 | AI導入の推進が停滞、組織的なAI戦略の実行が遅延 | ⭐⭐⭐ |
Shift
As-Isの業務フローをもとにTo-Beの業務フローを定義します。こちらもペルソナとAIが対話することで、少しずつ深掘りしていきます。
今回の仮想業務フローでは、セキュリティやガバナンス遵守の責任をAIに任せることは、組織としてリスクがあるとし、人が最終判断する方針となっています（卓越）。一方で調査はAIやシステムで実行できると判断し、委譲の判断がなされています。
ポイントはAIに任せるべき業務をAIに任せ、そこから人を解放することで、卓越の作業にリソースを集中できることです。今回の場合は定型的な業務から重要な判断に役割をシフトすることで、判断の品質を高めることができます。
Proposed State (To-Be) - 提案するロールシフト
To-Be のロール分析
| ロール | 実行者 | 内容 | 時間 | 効果 |
|---|---|---|---|---|
| 初期分類 | AI | 質問をカテゴリ判定（ChatGPT系、セキュリティ系等） | 自動 | 🚀 高速・一貫性 |
| 情報検索 | AI | ナレッジベース + Web から関連情報を抽出 | 自動 | 🚀 漏れなし、高速 |
| ドラフト生成 | AI | テンプレートを適用して回答案を生成 | 自動 | 🚀 一貫性、速度 |
| 精査 | 長島 | ✅ チェックリスト確認、誤り検出 | 3～5分 | ⭐ 集中可能 |
| 最終判断 | 長島 | ✅ セキュリティ・ガバナンス承認 | 1～2分 | ⭐ 責任確保 |
なお今回は、AIが出力した「To-Be のロール分析」をそのまま掲載していますが、内容を見ると「初期分類」「情報検索」「ドラフト生成」のように、ロールというよりもタスク単位で分解された結果になっています。
本来のAI-BPRにおけるShiftでは、前述した「AI-BPRのプロセス」の通り、人とAIエージェントの役割と責任分担を再設計することが重要です。そのため、単に業務をタスク単位に分解するのではなく、実在する人の職務や役割に近い単位でまとめると、よりAI-BPRらしい設計になります。
Simulate
実際の問い合わせケースを複数件作成し、Shiftで設計したフローをテストします。サイクル1では3つのテストケースを順に実行し、以下の課題が見つかりました。
| 課題 | 内容 |
|---|---|
| 🔴AI のドラフト誤り率が高い（15%） | Shift で設計した「AI ドラフト自動生成」の過程で、AI が誤った情報を生成するケースが多かった |
| 🟡 複雑なセキュリティ質問での精査時間が長い（5～6分） | セキュリティ・ガバナンス関連の複合質問では、長島の精査時間が目標（3～5分）を超えていた。 |
| 🟡 課題3: ナレッジベースが不完全（新しい質問に対応できない） | Shift で「ナレッジベース検索」を導入しましたが、ナレッジベースに存在しない「新しいタイプの質問」には対応できません。 |
| 🟡 課題4: チェックリスト項目が不足 | 長島が「AI ドラフトは正しいか？」を確認するために使用したチェックリストが、不十分だった。 |
| 🟡 課題5: AI と長島の「期待値ギャップ」 | Shift で設計した「AI ドラフト生成」は、「完璧な回答」を自動生成するものではなく、**「初期案を自動生成する」**ものだが、これが実装段階で明確ではなかった。 |
これらの課題に対する改善案として、以下4つの改善を加えます。
| 改善策 | 改善内容 |
|---|---|
| ✅AIドラフトの正確性向上 | テンプレートの細化とナレッジベース情報の更新 |
| ✅チェックリスト項目の追加と最適化 | 4項目から8項目へ拡張 |
| ✅「新しい質問」への対応ガイドラインの作成 | 「ナレッジベースにない質問」への対応プロセスを明文化 |
| ✅「期待値管理」の強化 | ペルソナ（長島）に対して「AI ドラフトの役割」を明確に共有 |
この4つの改善を加えたのちにサイクル2を回します。サイクル2では、回帰テストとしてサイクル1で実施した3つのテストケースに加えて、改善効果を確認しやすい3つのテストケースを追加して評価しました。サイクル1とサイクル2の比較結果は以下の通りです。
| サイクル | 平均対応時間 | 誤り率 | 修正ループ | 傾向 |
|---|---|---|---|---|
| サイクル1 | 3～6分 | 15% | 平均1.5回 | 基本確認 |
| サイクル2 | 2～5分 | 8% | 平均0.8回 | 改善 |
| 改善量 | 15～30%短縮 | 50%削減 | 47%削減 | ✅ 安定化へ |
サイクル2では、対応時間や誤り率が改善していることがわかります。若干の誤りなどは含んでいますが、本番導入後の継続改善で対応可能と判断し、Simulateプロセスの終了が提案されました。対応時間そのものは大きく削減されており、「人が最終的な判断をする」ことから誤り率も許容範囲として、Simulateプロセスはこれで終了するとします。
Forecast
検証結果をもとに実行計画への落とし込みを実施します。ForecastではTo-Be設計を始めるために必要なもの、本導入に向けたスケジュール、Next Actionが決定します。
今回の仮想シナリオでは、必要なものとして「教育・研修の準備」が上がっていることが印象的でした。業務改善では業務をシステム化して終わりではなく、組織としてそれを受け入れ、理解し、改善していくためには、関係者全員が協力していく文化が必要であることを改めて認識しました。
まとめと所感
生成AIの普及により、人のロールシフトはすでに始まっていると感じています。例えばソフトウェア開発ではコーディングエージェントの爆発的な普及により、コード生成などはAIが担う領域となり、エンジニアのロールはその上位設計やレビュー承認へシフトしています。同様の動きがソフトウェア開発以外の業務にも広がっていく可能性が高いと感じています。
そのときに、個人としても組織としても、業務の一部を単にAIに置き換えるだけでなく、AIとの共存を前提にした業務プロセスそのもののあり方を再検討すべきと感じました。これは単に効率化という観点だけでなく、エンジニアとして、AIに任せる領域と自分たちが価値を発揮すべき領域を再定義するうえでも、必要不可欠だと感じました。
