Amazon Web Services ブログ
AI 駆動の業務変革手法 :「課題は何ですか?」と聞くのをやめた日
業務の「ボトルネック」を見つけて AI エージェントに置き換える。成果を KPI で測り報告する。この至極正当なアプローチが「失敗の温床」であることに気づくのに時間がかかりました。
本ブログでは、AWS が提供している AI 駆動の業務変革手法である AI BPR (AI-driven Business Process Re-Engineering) というプログラムの 3 ヶ月の歩みの中で得られた知見を共有します。AI BPR は、ビジネスモデル/業務プロセスを AI エージェント前提に組み替えるための 4~5 時間のプログラムです。ファシリテート、技術検証、成果物作成といったプロセス全体を AI エージェント駆動で実施し迅速かつ効果的な業務変革を実現します。
なぜ「正しいアプローチ」で組織は変わらないのか
AI BPR は、ソフトウェア開発サイクル全体の最適化手法 (AI DLC)をビジネスに適用できないかという素朴なアイデアから生まれました。到達目標の設計、業務フローの分析、ボトルネックの特定、AI エージェントによる解決策の実装、計測、解決案のまとめ。これら業務プロセス最適化のステップを、AI 駆動で高速化するフレームワークとして当初開始しました。
| Step | 内容 | 所要時間 |
|---|---|---|
| Step 1: Goal | ステークホルダー特定、採用決定基準の文書化 | 30分 |
| Step 2: Focus | 注力業務範囲の可視化とボトルネック特定、制約条件設定 | 30分 |
| Step 3: Solution | 複数案生成・評価、FAQ 作成 | 30分 |
| Step 4: Simulation | シナリオ作成、Kiro Power による AI エージェント効果検証 | 30分 |
| Step 5: Challenge | 摩擦の予測と解決のスケジュール検討 | 30分 |
提案を始めると、生成 AI による成果物作成の高速化と意思決定への集中に期待の声をいただき、一定の効果も実感いただけました。その一方で、見逃せない反応もいくつかありました。
- AI エージェントに業務を任せるのは、BCP の観点で危険である。我々のビジネスは止まることが許されない
- AI BPR を実施してみたが、予想した解決策の枠内にとどまった。これまでの検討に比べて大きな進歩を感じない
いずれも正当な主張に思えます。しかし、事業継続性については人間にプロセスを残しても体調不良や欠勤によるリスクがあります。止まることが許されないならば本来 AI エージェントの活用は合理的なはずです。後者は、課題と解決策について常日頃考えている担当者であれば妥当な評価です。一方、生成 AI の提案を批評家目線でとらえて共創相手として扱っていない点が気がかりでした。
表面的なフィードバックは多様ですが、深層に共通する構造があることに気づきました。
1つは、担当している仕事に対する知見と経験から来る素朴な反発です。長年磨いてきた専門性が AI で代替されるかもしれないという示唆は、能力への脅威ではなくアイデンティティへの脅威として受け取られます。この傾向は Stanford の研究でも示唆されています。生成 AI を職場で活用する上で 45% が AI の精度・信頼性への懸念を、23% は職の代替への恐怖を挙げています。実際、様々な企業で効率化に取り組む部署の方とお話しすると、業種に限らずこの不安に直面していると言われます。
もう1つは、「人間」に信頼を置くことで組織内の人間関係や責任の所在を安定させたいという心理です。「この業務は○○さんが詳しい」という構造は、組織内の責任分担の現れであり、AI エージェントへの委譲は単に業務の代替だけでなく「責任の委譲」も伴います。つまり、業務停止時の責任が AI エージェントを管轄する IT にもこれまで以上に波及するということです。
この2つが合わさると、「やっぱり人間でないと難しい」「危機対応時を考えると人間が担うべき」といった言葉が経験者を尊重すると共に責任移動を回避する都合のよい「落としどころ」として機能します。人間でないと困難な業務は本当に多くありますが、その「困難」への挑戦よりこの一見合理的な落としどころが選択されやすくなります。
これらの反応を通じて認識したのは、現状の AI BPR では真の問題を解決できないということでした。問題解決プロセスが AI で速くなっただけで、そのアウトカムは結局「落としどころ」に留まり大きな変化が見られない。もちろん速くなることに価値はありますが、誤った診断のまま処置のスピードだけ速くなっても根治することはありません。
壊す、調べる、組み直す
まず決めたのが、AI BPR の構成を壊すということでした。通常の問題解決や効率化のフレームワークを疑い、根本原因の解明と解決に向けたチャレンジを続ける選択をしました。
不安がなかったのは、この「正しいアプローチが機能しない違和感」が過去に一度も検討されたことがないはずはない、という予想があったからです。業務変革の失敗は 1993 年に BPR が提唱されて以来、繰り返し議論されてきた構造的な課題です。IBM が 1,532 名の変革実務者を対象に行った調査では、担当プロジェクトのうち目標を完全に達成したのは 41% (IBM, 2008) に留まっています。McKinsey が 1,034 名を対象に 2021 年に実施した調査でも変革の成功率は 30% 前後です (McKinsey & Company, 2021)。数十年を経て成功率は 30~40% に留まっているといえ、この間に膨大な原因の分析と対策の提案が蓄積されているはずです。
AI BPR を提供するたびに、参加者の反応を 4 層で分解しました。Surface (発せられた言葉)、Experience (AI BPR 体験中の出来事)、Psychology (事前の期待・バイアス)、Habit (個人の経験や気質) に分解し、フィードバックがどの階層に由来するか分析し、先行事例と研究による裏付けを行いました。生成 AI による分析と具体的改善点を特定するレポートは、時に数万文字に及んでいます。
その結果、第一章で観測した反応は理論的に予測可能な現象であることがわかりました。以下では、調べ組み直す過程を記載します。
観察の理論的裏付け
このセクションは論文の引用もあり少し専門的です。「具体的にどう変えたか」に関心がある方は読み飛ばして頂いて構いません
第一章で観察した「やっぱり人間でないと難しい」という「落としどころ」には Argyris (1990, 1991) が論じた防衛的ルーティン(organizational defensive routines) という名前がついています。防衛的ルーティンは困惑や脅威を感じうる状況、この場合生成 AI による職の代替や AI エージェントの導入による責任範囲の拡大、が発生した際に無意識のうちに取られる行動・方針・慣行です。Argyris はさらに、この回避が磨き上げられた技術として機能する点を指摘し、これを 熟達した無能力 (skilled incompetence) と呼んでいます。熟達しているがゆえに、問題を避けていること自体に気づかなくなる点に課題があります。変化したい、一方で現在の安定状況を守りたい、という表裏の動機が相殺し結果として動かない、まさに「落としどころ」に安定する様は後続の Kegan & Lahey (2001, 2009) による変化への免疫 (Immunity to Change)でも裏付けられています。
AI BPR で「落としどころ」を抜けるには、従来の “Solution” 提案型では困難なこともわかりました。文字通り Solution という工程では生成 AI に「提案/作成」させ人間が「確認」する構造を取っています。これは既知の専門知識と方法論で解ける技術的課題 (technical problem) に有効なアプローチです。一方、業務代替への不安や責任移動の回避のように、組織や働く人の価値観や行動様式の変容そのものが求められる課題は、Heifetz の言う 適応課題 (adaptive challenge) に該当します。技術的課題は専門家が答えを提供すれば解けますが、適応課題は当事者自身の認識が変わらない限り解決しません。Heifetz (1994) はこう述べています。
“The most common cause of failure in leadership is produced by treating adaptive challenges as if they were technical problems.”
ソフトウェア開発という技術的課題が主軸のアプローチをベースにした AI BPR がこの壁に直面するのは必然でした。
Schein (1999) はプロセス・コンサルテーションにて課題解決のアプローチを 1) 答え(薬)を提供する「専門家モデル」、2) 診断の上で処方を行う「医師 – 患者モデル」 3) クライアント自身の問題解決能力を開発する「プロセス・コンサルテーションモデル」の 3 つに分類しています。適応課題にはこの 3 が最も整合します。
理論研究の調査から判明したことは大きく 2 点です。一点目は、「落としどころ」で止まるのは個人や特定企業の問題ではなく、組織に広く観察される構造的な防衛反応であるということ。二点目は、落としどころを超えていくにはプログラム全体を「提案を受ける」場ではなく当事者自身の気づきと判断を引き出すアプローチに組み換える必要があるということです。ここに、似たキーワードである “AI BPO”、単に AI へ仕事をアウトソースする方式との最大の違いがあります。
AI BPR を「組み直す」
分析を経て、執筆時点で AI BPR は次の 3 点を特徴とする 4 ステップのフレームワークで構成されます。
- 強み起点 : 今の業務の何が「問題」か ? ではなく、提供できている顧客価値、市場や社内で認知されている強みを発見する。どのように強みを強化し顧客価値をより高めることができるのか ? を考える
- 心理的安全なロールシフト : 業務プロセスを構成する要素について、強みの有無から「AI エージェントに委譲するか価値を高め卓越させるか」を一つ一つ判断し「何を手放し何に集中するか」を能動的に決定する
- 即時的フィードバック : AI とのインタラクティブな会話で成果物を「持ち帰り時間ゼロ」で作成する
組み直し後の 4 Step は次の通りです。
| Step | 内容 | 所要時間 |
|---|---|---|
| Step 1: Observe | 業務ヒアリングと資料に基づく強み、価値、リスクのマッピング | 40分 |
| Step 2: Shift | サブプロセス分解と判断に基づく業務と顧客体験の変革シナリオ設計 | 50分 |
| Step 3: Simulate | Shift の実装と評価の改善を計測 | 60分 |
| Step 4: Forecast | 評価改善の Velocity に基づく Shift 計画の立案 | 20分 |
AI BPR を始める方法は簡単です。各ステップの実行はプロンプトといくつかの MCP により駆動されるため、例えば Kiro に “AI BPR をはじめて” というだけで始められます。
組み直しにあたっても、先行研究を参照しました。考え方の変容を促す適応課題に対するプロセス・コンサルテーションの具体的アプローチとして、Cooperrider & Srivastva (1987) が提唱した Appreciative Inquiry を採用しています。これは問題を分析して修正するアプローチを切り替え、組織の既存の強みと成功体験を発見し、それを増幅することで変革を実現する手法です。Bushe (2007, 2013) は Appreciative Inquiry が特に機能するのはその 生成性 (generativity) にあると論じています。参加者が従来持たなかった新しい視点・語彙・可能性を生み出す生成的対話が「適応」に有効であるということです。
生成的対話を AI BPR、プロンプトに基づく生成 AI との対話として実装するのに役立ったのは、意外にもよく知られるコンマリメソッドでした。コンマリメソッドでは、捨てるものではなく「ときめくもの (spark / not spark)」に注目します。これは、防衛的ルーティンを誘発する「何を捨てるか」という問いかけではなく、「何にときめくか」(成功体験に根付く生成的問い)を問うことで片づけに対する世界中の人の行動変容を促しています。判断の主語が常に本人/自組織にあること。一つ一つ手に取ること。判断の積み重ねで自己認識が変わること。上記の原則を具体的な方法論に翻訳するのに、この身近な成功例ほど適したものはありませんでした。
一方、今回取り上げた Appreciative Inquiry は銀の弾丸ではなく批判もあります。特に Bushe (2007) は、このアプローチが単にポジティブなところだけ見る活動に矮小化され、組織の構造的な課題や関係性を抑圧しうる点を指摘しました。これは、Edmondson (1999) の心理的安全性が長年「仲の良いチーム」と誤解され続けてきたことと構造が重なります。肯定的介入は、表層的な「優しさ」により容易に誤解され本来の変革の力を失うということです。 Bushe はこの批判に自ら応える形で、先に述べた通り Appreciative Inquiry の中核が生成性 (generativity)にあると再定義し (Bushe, 2013)、 2015 年に Marshak と共に Dialogic Organization Development として体系化しています (Bushe & Marshak, 2015)。AI BPR が AI との問いかけを中核に据え、委譲・卓越の識別を「あえて 2 択で問う」ことで新しい視点を引き出す設計は、この Dialogic OD の系譜に連なります。
「組み換え」の仮説検証の自動化
AI BPR の破壊的な変更は成功する保証がありませんでした。一方で、実際のお客様に提供する際は一回で効果を体験頂く必要があります。破壊的変更と効果の安定を両立させる方法として、AI エージェントによる AI BPR の Dry Run を実装しました。提供を予定しているお客様の事業内容や参加者、テーマから想定されるペルソナと発生しうるリスクをまとめたシナリオを作成します。そのシナリオと AI BPR のプロンプトを用い、AI エージェントに Dry Run を実行させ各工程の反応を予測させました。ソフトウェア開発での自動テスト (CI/CD) に近い仕組みです。この仕組みにより想定した変化・体験・効果があるかを事前に検証することで品質を安定させました。
事前のシミュレーションと、実際のデリバリーで得られたフィードバックを 4 階層で深掘りし、理論的裏付けを基に改善するサイクルを半自動で回転させました。一度ゼロベースになったフレームワークを、このサイクルで洗練させていきました。初回の実装を行った 2 月からの約 2 ヵ月で大小含め 40 回以上の変更を経て現在の形になり、その改善は今も続いています。
「課題は何ですか?」と聞くのをやめた成果
結果は、数字に現れました。以下がキーポイントとなった提供ごとの満足度、AI BPR を通じた業務変革の可能性を表にしたものです。
| 提供先 | 日付 | 満足度 | 変革可能性 | 提供者 |
|---|---|---|---|---|
| 大規模製造企業 (初期設計) | 3月 | 4.2 / 5.0 | 4.40 / 7.0 | DevRel |
| IT 企業 (変更初期) | 3月 | 3.63 / 5.0 | 4.63 / 7.0 | DevRel |
| 大規模物流企業 | 3月 | 4.86 / 5.0 | 6.71 / 7.0 | DevRel |
| 大規模製造業 | 4月 | 4.62 / 5.0 | 6.08 / 7.0 | DevRel |
| アパレル企業 | 4月 | 5.00 / 5.0 | 6.50 / 7.0 | アカウントチーム |
初期設計から組み直しを経て、一度満足度が 3.63 と下がったものの、最新では 5.00 のフルスコア、変革可能性は 4.63 から 6 点以上へ推移しました。特に最新の結果は開発した DevRel ではなくお客様を担当するアカウントチームからの提供であり AI BPR のアプローチの非属人性を示す例となっています。提供の中から、いくつか印象的なエピソードを紹介します。
物流企業の役員が自ら「置き換えたい」と言った理由
大規模物流企業様への提供では、物流拠点の支店長が行っている情報の収集と伝達業務を大幅に代替できる AI エージェントの発見に役員の方からも積極的な置き換え推進の意欲が示されました。このような防衛反応を生みかねない方針が生まれた背景には 2 つのポイントがありました。初めに、強みの源泉が「顧客との約束を守る」ことに対する強いコミットメントにあると特定されたこと。次に、生成 AI から提案したのではなく対話と Simulate による検証で自ら考え出した「生成的な」アイデアであったことです。約束を守るために何に集中すべきか、という問いのフレームが機能し、実際に「課題起点で考えていたらこれだけポジティブに受け入れられなかったかもしれない」とフィードバックを頂きました。
40 分で業務プロセスを可視化し、製造業役員から評価
大手製造業様へのデリバリーでは、役員の方から「業務分析・可視化は人間のコンサルタントより圧倒的に AI が良い」という評価をいただきました。この時、Observe で業務プロセスフローの整理にかかった時間はわずか 40 分でした。一般的に数時間から数日かかる業務整理が圧倒的短時間で完了しました。この速度と質問回答による簡易な進行を体験したことで、参加者側から自発的に 2 チーム目を立ち上げたい要望が上がりました。自らの意向を即時的に伝え「持ち帰り時間ゼロ」で成果物が手元に残る体験が参加者自身の行動変容を促した瞬間でした。
AI BPR 開発者なしの提供で全員満点の評価
アパレル企業様へのデリバリーは、プログラムを開発した DevRel ではなくアカウントチームが主導した初のケースでした。結果は、DevRel の提供も含めて過去最高の満足度である 5.00/5.0 (全員満点)、変革可能性も 6.50/7.0 に達しました。「今日 4 時間で 3 日分のタスクを終えた感覚」「チャットベースでプロセス改革ができてしまう」とフィードバックいただき、当日中に社長への報告会を設定することが決まりました。主なファシリテーションは AI エージェントに組み込まれており、人間のファシリテーターは注意点の修正のみに集中できることが大きな力を発揮しました。
途上にある洗練 : 40 年の研究の先へ
AI BPR の中核となっている Appreciative Inquiry は約 40 年にわたって理論的に支持され成果もあげてきました。一方で広まらなかった理由にファシリテーションの困難さと顧客側の技術的課題への渇望が指摘されています。
- 「答えを与えるのではなく問いかける」ことは、事前に「答え」を作り込める専門家型のアプローチに比べその場での即時性が求められる。そのため高いファシリテーションスキルが必要で、標準化も難しい
- 組織が適応課題に直面したとき、本能的に技術的解決を求める傾向がある。「答えをくれ」「計画を出せ」と要求することで意思決定の心理的コストを外部化している
AI BPR は、この 2 つの課題に明確な回答を提示します。プロンプトで問いの設計を「事前に」行うことでファシリテーターへの依存を下げ、生成 AI による Simulate/実装により技術的な課題についても解決の実証と計画 (Forecast) を数時間以内に出すことができます。AI BPR がより洗練されることで、理論の実証は加速度的に進むでしょう。そのためには、より多くの経験とフィードバックを得る必要があります。
AI BPR の共創
現在、AI BPR のコンセプトと進化に共感頂けた AWS パートナー様との共創活動を始めています。アクセルユニバース様とは AI BPR を通じデータ駆動の AI エージェントを業務プロセスに組み込むワークショップを開催しています。3 月には 5 社のお客様に参加いただき、5 月にも二度目のワークショップを開催予定です。
アクセルユニバース様は AWS はもちろん AI/ML の領域に強みを持つパートナー様で、AI BPR のより高度な実装に向け連携しています。3 月の開催では数日前に AI BPR の大規模な変更が発生するなど、激しい変化を前提に連携させて頂いています。型化したワークショップを開催し固まったユースケースを実装していく SI 的な連携とは根本的に異なります。最終的には、AI BPR 提案を通じた役員エンゲージメントからの全社プロセス最適化を主導頂けるようになることをゴールと考えています。
また、Stockmark 様とは Stockmark 様の強みである製造業向けのソリューション・モデルと AI BPR を組み合わせたより短時間で実効性の高いアプローチを開発しています。すでに Stockmark 様自身へ AI BPR の提供をさせて頂き、フィードバックを得て共同で改善をしています。
AWS は、Stockmark 様のようなソリューションプロバイダのお客様と共に AI BPR を提供し AI BPR で得られたフィードバックでソリューションを洗練させる活動を支援しています。この “AWS Forward Deployment 支援プログラム” の提供もまさに始まっているところです。Forward Deployment 支援プログラムでは、サービス導入先のお客様への AI BPR 提供、そこから得られらフィードバックをプロダクト (Agent) に反映するプロセスを ML Enablement Workshop で支援させて頂きます。
AWS の内部でも、アカウントチームが必要と感じたときに提案・実施できるよう AI BPR のトレーニングを実施し、60 名以上に参加いただいています。大規模な組織では、全社的な KPI の設計や各部署のステークホルダーを把握したうえでのオーケストレーションが必要になります。また、構築される Agent の全社的な管理が求められるケースもあります。こうしたニーズに備え、ProServe のチームとも連携し専用のメニューを構築予定です。
Amazon の創業者である Jeff Bezos は、「10 年経っても変わらないものは何か」に集中することこそが重要と説きました。冒頭お伝えした通り、業務変革の成功率は数十年を経て 30~40% に滞留し変わっていません。この「変わらないもの」が、組織変革の研究者たちが積み重ねてきた理論と生成 AI、そして変化と挑戦を受け入れて下さる AWS パートナー様との連携により「変わる」瞬間を目指していきたいと思います。
AI BPR を自社の業務変革に活用してみたい方、あるいは AWS との共創活動に意欲をお持ちの方は、担当の AWS アカウントチームまでお気軽にお問い合わせください。本記事で紹介した理論や AI BPR のナレッジについて議論したい方は筆者までご連絡いただければ幸いです。
参考文献
- Argyris, C. (1990). Overcoming Organizational Defenses: Facilitating Organizational Learning. Allyn & Bacon.
- Argyris, C. (1991). Teaching smart people how to learn. Harvard Business Review, 69(3), 99–109. https://hbr.org/1991/05/teaching-smart-people-how-to-learn
- Bushe, G. R. (2007). Appreciative Inquiry is not (just) about the positive. OD Practitioner, 39(4), 30–35. https://www.gervasebushe.ca/AI_pos.pdf
- Bushe, G. R. (2013). Generative process, generative outcome: The transformational potential of Appreciative Inquiry. In D. L. Cooperrider, D. P. Zandee, L. N. Godwin, M. Avital, & B. Boland (Eds.), Organizational Generativity: The Appreciative Inquiry Summit and a Scholarship of Transformation (pp. 89–113). Emerald. https://gervasebushe.ca/AI_generativity.pdf
- Bushe, G. R., & Marshak, R. J. (Eds.). (2015). Dialogic Organization Development: The Theory and Practice of Transformational Change. Berrett-Koehler. https://www.bkconnection.com/books/title/dialogic-organization-development
- Cooperrider, D. L., & Srivastva, S. (1987). Appreciative Inquiry in organizational life. Research in Organizational Change and Development, 1, 129–169. https://www.researchgate.net/publication/265225217_Appreciative_Inquiry_in_Organizational_Life
- De Smet, A., Pacthod, D., Relyea, C., & Sternfels, B. (2021, December 7). Losing from day one: Why even successful transformations fall short. McKinsey & Company. https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/successful-transformations
- Edmondson, A. (1999). Psychological safety and learning behavior in work teams. Administrative Science Quarterly, 44(2), 350–383. https://doi.org/10.2307/2666999
- Heifetz, R. A., Grashow, A., & Linsky, M. (2009). The Practice of Adaptive Leadership. Harvard Business Review Press. https://www.hks.harvard.edu/publications/practice-adaptive-leadership-tools-and-tactics-changing-your-organization-and-world
- IBM Global Business Services. (2008). Making Change Work: Continuing the Enterprise of the Future Conversation. IBM Corporation. https://public.dhe.ibm.com/software/be/Making_Change_Work_eff.pdf
- Kegan, R., & Lahey, L. L. (2001). The real reason people won’t change. Harvard Business Review, 79(10), 84–92. https://hbr.org/2001/11/the-real-reason-people-wont-change
- Kegan, R., & Lahey, L. L. (2009). Immunity to Change: How to Overcome It and Unlock the Potential in Yourself and Your Organization. Harvard Business Press. https://store.hbr.org/product/immunity-to-change-how-to-overcome-it-and-unlock-the-potential-in-yourself-and-your-organization/1736
- Kondo, M. (2011). 『人生がときめく片づけの魔法』 サンマーク出版. (English edition: The Life-Changing Magic of Tidying Up. Ten Speed Press, 2014.) https://www.penguinrandomhouse.com/books/240981/the-life-changing-magic-of-tidying-up-by-marie-kondo/
- Schein, E. H. (1999). Process Consultation Revisited: Building the Helping Relationship. Addison-Wesley.
- Shao, Z. et al. (2025). Future of work with AI agents: Auditing automation and augmentation potential across the U.S. workforce. Stanford SALT Lab. https://arxiv.org/abs/2506.06576





