どうもこんにちは。
先日、とあるAI BPR（AI-driven Business Process Re-engineering） の勉強会に参加してきました。
正直なところ、最初は「AI BPRとAI-DLCは何が違うんだっ！」っていう風に思っていました。しかし、お話を聞いていくうちに「これは効率化の話でじゃなくて、業務そのものを組み替える話だ」と理解がガラッと変わりました。エンジニアとして刺さるポイントも多かったので、忘れないうちに整理したいなと思い、記事にしました。
この記事では、
- AI BPRとは何ぞ
- 従来の BPRとどう違うの？
- 進め方
- AI-DLCとの比較
- 参加してみての所感
を書いていきます。同じく「生成AIをどう業務に組み込むか」で悩んでいる方の参考になれば幸いです。
AI BPRとは何ぞ
一言でいうと、AI BPRは
業務プロセスそのものを「AIエージェント前提」に組み替える業務変革プログラム
であると、私は理解しました。
ポイントは、生成AIを「個人の効率化ツール」として使うのではなく、業務プロセス・役割分担・意思決定・成果物の流れ自体を再設計するところにあります。
そして狙いは効率化ではなく、計測可能なビジネスアウトカム（利益）の向上ということです。
「作業が速くなっても、人間の仕事が変わっていなければ、それはAI BPRとは言えない」という言い切りが印象的でした。
なぜ今なのか
背景として挙げられていたのは、大きく3つです。
1. 人材が構造的に足りない
生産年齢人口が減少し、DXを牽引できる人材は海外比で 2〜3倍不足。「AIを使える人材の育成」だけでは間に合わず、業務プロセス自体を変える必要がある。
2. AI が「任せられる」段階に来た
生成AI は「支援」から「委譲」へ進化し、計画を立てて作業し仕事を完了できる、新たな "知的労働資源" になった。
3. 既存のやり方では、業務にうまく組み込めない
生成AIの個人利用は6割を超えているのに、業務プロセスに組み込めている企業は13%程度しかありません（米国・ドイツは37%）。「個人では使えているのに、業務は変わらない」という大きなギャップがあるわけです。
では、なぜ業務への組み込みはこんなに進まないのか。それは、従来のBPRやAI導入のやり方そのものに失敗要因があるから、と整理されていました。
(1) 欠損反射（Deficit Reflex）── 問題起点で始めてしまう
「何が壊れているか」を起点に、反射的に修正しようとするアプローチ。これが現場の防衛反応を誘発してしまい、組織変革が失敗する要因の7割超を説明するとも言われています。
(2) 適応課題を扱えていない ── 「技術的に可能か」だけ見てしまう
「その業務は技術的に置き換えが可能か」ばかりを議論しがちです。でも現場にとっては、精度への不安の次に大きいのが「自分の仕事がなくなるのでは」という職の代替への恐怖です。ここに向き合わず、「効率化で浮いた分を何に充てるのか」まで踏み込まないと、現場の協力は得られず、心理的安全性も保てません。
(3) スピードが遅い ── 提案が出る頃には陳腐化している
ヒアリング → 書き起こし → 分析で数週間〜数ヶ月。その間に事業環境が変わってしまい、せっかくの提案が陳腐化してしまいます。
従来のBPRとどう違うのか
AI BPRは、従来の 問題解決（Problem-Solving） ではなく、可能性増幅（Possibility Amplification） というパラダイムを取ります。
| 観点 | 従来の BPR | AI BPR |
|---|---|---|
| 出発点の問い | 「効率が悪いプロセスは?」 | 「何が強みか?DoをAIに任せられるとしたら?」 |
| 人間の役割 | 現状を分析し問題を修正する | 強みをPlan/Seeに分解し、DoをAIに委ねる |
| AIの位置づけ | 改善案を実行するツール | Doを担う前衛。人間はPlanとSeeに集中 |
| 参加者の心理 | 防衛（仕事を否定される） | 再発見（自分の強みの上位の役割が見える） |
| 意思決定まで | 数週間〜数ヶ月 | 数時間〜数日 |
| アウトプット | 議事録・変革案 | 動くAIエージェントによる実験に基づく計画 |
3つの設計原則
1. 強み起点
「何が問題か」ではなく、提供できている顧客価値・強みから考え始める。
2. 心理的安全なロールシフト
今"Do"で発揮している強みを"Plan"/"See"へ移し、DoをAIに委譲する。人間は上位の役割へShiftする。
3. 即時的フィードバック
AIとの対話で成果物を「持ち帰り時間ゼロ」でその場作成する。
「DoをAIに任せられるとしたら、あなたの強みをPlanとSeeにどう活かしますか?」
この「としたら」という仮定法がミソで、「あなたの仕事を奪う」という損失回避のスイッチを踏まずに、参加者が自ら上位の役割を発見できるように設計されているようです。
これは組織開発の理論（Appreciative Inquiry や適応課題論）がベースにあるそうで、「40年広まらなかった理論を、AIのファシリテーション標準化で実装可能にした」という説明に「なるほどぉ...」と感じたところではありました。
進め方（4ステップ）
AI BPRは、実データを持ち込み、以下のステップで進めます。
| ステップ | 目的 | AI の役割 |
|---|---|---|
| Observe | 業務の流れ・強み・リスクを把握しマッピング | 鏡: 聞いて描く |
| Shift | 役割分担を設計（卓越・委譲の切り分け） | 触媒: 提案し問う |
| Simulate | エージェントで検証し改善 Velocity を計測 | 構築し計測する |
| Forecast | 実測値をもとに移行計画を立案 | 計画を共同執筆 |
とくにSimulateはPoCではないという点が刺さりました。実データで「その場で実務に役立つもの」を作り、動くエージェントで一気通貫に業務を流してみる。しかも、価値は"完成度"ではなく「新しい業務イメージと、そこに到達するまでのプロセス・時間の実感」を得ることにある。だから「これは使えない」「ここは人間がやるべきだ」という発見も、等しく価値ある発見として扱う。ということでした。
これを聴いていて、Claude CodeやCodex, Kiroを使っている人たちは無意識にこれを自分の手元でやってるんだよなぁ...と思いました。今まで自分が手作業でやっていたタスクに対して、「とりあえずやらせてみよう！」でやらせてみて、「自分でやった方が良さそうだな」という部分と「これは情報与えればできるようになりそう」という部分を分けて考えたりしているんですよね。その点で見れば、自分の手元でやるか、組織的にやるかの違いなのかなと思ったり...（組織的にやるのが難しいんですよね。わかっているつもりなんです。）
AI-DLCとの比較
ここが個人的に一番整理したかったところです。AWS には開発向けの AI-DLC（AI-Driven Development Lifecycle） という方法論もあって、名前も似ているので混同しがちです。ここをしっかりと整理がつきました。
そもそも AI-DLCとは
- 開発ライフサイクル（SDLC）を AI 中心に再構想する開発方法論。提唱者はAWSのRaja SPさん。
- 中核のメンタルモデルは「AI が計画を立てる → 文脈を得る質問をする → 人間の承認後にのみ実装する」ループを全工程で高速反復すること。
- Sprint を Bolt、Epic を Unit of Work と呼ぶなど、アジャイル用語を再定義しているのも特徴。
共通点（同じDNA）
| 共通する思想 | AI-DLC での現れ方 | AI BPR での現れ方 |
|---|---|---|
| エージェント主導・人間が意思決定 | AIが計画/実装、人間が検証・承認 | AIが成果物作成、人間がレビュー・意思決定 |
| 対話方向の逆転（AI が問いを主導） | AIが明確化の質問を投げる | AIが質問を生成し参加者が回答する |
| 改造でなく再構想（第一原理） | 既存SDLCにAIを後付けしない | 問題起点を捨て、強み起点へ転換 |
| 時間の劇的圧縮 | 週単位 → 時間〜日単位（Bolt） | 数週間〜数ヶ月 → 4〜5時間 |
| 共通ツール基盤 | Claude Code / Kiro | Kiro / Claude Cowork / Amazon Quick |
相違点（対象と課題が違う）
| 観点 | AI-DLC | AI BPR |
|---|---|---|
| 対象領域 | ソフトウェア開発（SDLC） | ビジネスモデル・業務プロセス |
| 主目的 | 開発速度・Time to Market 短縮 | 業務変革によるビジネスアウトカム向上 |
| 課題の性質 | 技術的課題「どう変えるか」 | 適応課題「なぜ変われないのか」 |
| 主な対象者 | 開発チーム（PO・開発者） | 業務担当者・組織横断 |
| フェーズ | Inception → Construction → Operations | Observe → Shift → Simulate → Forecast |
| 心理面の扱い | 開発者体験の向上が主眼 | 職の代替不安・防衛反応の克服が中核 |
ざっくり言うと、AI-DLC は「技術的課題（どう作るか）」を、AI BPRは「適応課題（なぜ人と組織が変われないか）」を扱う。ここが最大の違いだと理解しました。
競合ではなく連携する
そして両者は競合ではなく、バリューチェーン上で連続します。
AI BPR の Simulate で作るのはあくまで簡易プロトタイプ。それを実業務に耐える形で作り込む段階を AI-DLC が引き継ぐ、という補完関係になってい流のではないかと考えています。
共通点は「エージェントが主導して成果物を作成し、人間が意思決定する」こと。この1点で、両者は同じ設計思想を共有していると考えました。
社内で進めるとしたら
まずは、AI BPRのワークショップを社内で実施すべき。その後、ワークショップで終わらせず、組織横断（1 to 100）につなげるのが肝、という話でした。自分なりにステップとして整理してみました。
1. 準備
一番大事なのは、役職者をスポンサーに巻き込むことです。AI BPRは単なる効率化ではなく、部門をまたいだ役割・人員配置の変更を伴う「組織変革」なので、現場だけで進めても意思決定できずに頓挫します。とくにIT部門は他部門のリソースを動かす権限を持たないことが多いので、対象業務を持つ部署の役職者も押さえておきたいところです。
対象業務は、組織の役割を代表するものを1つ選びます。小さすぎると組織変革の議論にならず、広すぎると具体化できないので、その塩梅が大事です。
環境面では、AIエージェント（Kiro / Cowork / Amazon Quick など）が動く状態を事前に用意しておきます。ここで意外と重要なのが、社内のAI利用規定・データ投入の可否の確認です。進めようとした矢先に「AIエージェントツールをインストールできない」「このデータを本当に入れていいか分からない」というのはあるあるらしいので、ここは確実に潰しておきましょう。
2. 実施
前述したように「効率化」をテーマにすると失敗するので、"何を伸ばしたいか" から逆算してテーマを決めましょう。実際の業務データを持ち込み、手元のAIエージェント環境で Observe → Shift → Simulate → Forecast のフローを回していきます。
- Observe：スコープを狭めすぎない（視点を広げる）
- Shift：AIに「より良い提案」を求める（自分で答えを決めきらない）
- Simulate：AIの成果物を見てフィードバックする（結果責任を"AI"ではなく"自分の指示"に持つ）
- Forecast：業務を変えることへの抵抗（防衛反応）の強さを確かめる
逆に、「結局ChatGPTで良かったね」で終わったら黄色信号です。それはAIを効率化ツールとして使う視点に留まっていて、「業務そのものを変える」視点に切り替わっていないサインだからです。
3. フォロー
ワークショップの成果を定着させ、実際に人の役割が"上位業務"へシフトしたかを確認しましょう。ここでの成功は「作業が速くなった」ではありません。AIに任せて浮いた時間で、付加価値の高い新しい仕事が生まれているか、最終的には**計測可能なビジネスアウトカム（利益）**につながっているか、が判断基準です。作業だけ効率化されて人間の仕事が変わっていなければ、AI BPRができているとは言えない、という話でした。
4. 横展開
フォローで手応えが出たら、1 to 1で終わらせず 1 to 100で組織横断へ広げます。なぜ横断かというと、対象業務だけ改善しても、その "外側" のプロセスがボトルネックのままだと計測可能な価値が出にくいからです。だからこそ、横串の意思決定者（提案すべきターゲット）を特定することが重要になります。
5. 基盤化
横展開と並行して、成果物やエージェントを組織資産として運用する基盤を漸進的に整えていきます。ざっくり3層のイメージです。
- 業務設計の層：To-Be をデザインし、OKRと対象業務の優先度を決める（AI BPR Orchestration）
- エージェント稼働の層：Amazon Quick / Bedrock AgentCore で動かし、MCPでツール・データに接続し、ガードレールで安全化する
- データの層：エージェントが正しく動くためのデータカタログ・ナレッジ基盤
ワークショップで作った成果物は "やって終わり" にせず知識として再利用し、エージェントも運用しながら賢くしていくイメージです。
勘所は「小さく始めて → 定着 → 横串で広げ → 基盤に載せる」。最初から全社基盤を作ろうとしない、ということですね。
まとめと所感
参加してみて一番の学びは、AI BPRは技術論ではなく「組織の適応課題」への働きかけだという点でした。「結局 ChatGPT でよかったよね」で終わってしまうのは失敗のサインで、それは AIを効率化ツールとして使う視点に留まり、業務そのものを変える視点に切り替わっていない、という指摘はハッとさせられました。
そして、アプリの性能改善と業務のボトルネック解消は本質的に同じという話には、「たしかに...！」と感じた部分でした。
| アプリケーション改善 | AI BPR における業務改善 |
|---|---|
| リクエストの流れを理解する | 業務の流れを理解する |
| メトリクス/ログ/トレースで横断監視する | プロセス・担当者・成果物・待ち時間を横断観察する |
| ボトルネックを特定する | 人手/承認/転記/確認/例外対応のボトルネックを特定する |
| キャッシュ/非同期化/並列化で改善を設計する | AI委譲/役割変更/パイプライン化を設計する |
| SLO/コストで効果を測る | 利益/リードタイム/品質で効果を測る |
「流れを理解し、横断的に監視し、ボトルネックを特定して改善を設計する」という、普段アプリに対してやっていることを、そのまま業務オペレーションに向ければいい。AI BPRは、エンジニアリングの対象をアプリケーションから業務へ広げる取り組みだと捉えると、解像度高く理解することができました。
以上