AWS が公開した「AI 駆動の業務変革手法 AI BPR」の記事が話題になっている。単なる成功事例ではなく、「正しいアプローチが全く機能しない」という壁に正直にぶつかった失敗報告から始まる点が異色で、AI 導入に苦戦する多くの組織にとって示唆に富む内容だ。

AWS が3ヶ月間で発見した「正しいアプローチが機能しない」現実

AWS は自社で3ヶ月間、お客様に AI エージェント導入プログラムを提供してみた。最初に試みたのは、いわゆる BPR の教科書通りのアプローチだ。

  1. ゴール設定
  2. 業務フロー分析
  3. ボトルネック特定
  4. AI エージェントで解決
  5. 計測

整然としたフローに見えるが、現場から返ってきた反応は想定外だった。

  • 「AI エージェントに任せるのは BCP 上危険」
  • 「提案の枠が狭くて大きな進歩を感じない」

一見もっともらしい抵抗なのだが、よく分解すると全然別の構造が見えてくる。

抵抗の本質：2つの根本的障壁

1. アイデンティティへの脅威

長年積み上げてきた専門性が AI に代替されることへの「存在意義の危機」だ。Stanford の研究でも、45% が AI の精度を懸念し、23% が職の代替を恐れているという。これは能力の問題ではなく存在意義の問題であり、ツール改善では解決できない。

2. 責任の所在を人間に残したい組織心理

「この業務は◯◯さんが詳しい」という言葉の裏を返せば、責任分担の合意だ。AI に委譲するということは、業務停止時の責任も IT 部門に一気に流れ込むということ。それは組織として受け入れがたい。

この2つが合わさると、「やっぱり人間でないと難しい」という一見合理的な「落としどころ」に着地してしまう。AWS はこれを Argyris の言う防衛的ルーティン（defensive routines）・熟達した無能力（skilled incompetence）と結びつけて説明しており、ここが本当に鋭い。

アプローチの転換：「課題は何ですか？」を捨てる

AWS が下した判断は、AI BPR を一旦抜本的に見直してゼロから組み直すことだった。

従来の「課題は何ですか？」という問いかけをやめ、「強みは何ですか？」から入る設計に変えた。

「課題は何ですか？」という問い自体が、実は防衛反応を誘発する最悪のフレームだったという発見も重要だ。問題を分析して修正するアプローチは、当事者を「自分たちは問題を抱えた存在」として位置づけてしまう。

Appreciative Inquiry の採用

具体的に採用したのが、Cooperrider & Srivastva が提唱した Appreciative Inquiry（アプリシエイティブ・インクワイアリー、以下 AI）という手法だ。

問題を分析して修正するのではなく、組織の既存の強みと成功体験を発見して増幅することで変革を起こす。

Appreciative Inquiry とは何か

AI は 1987 年に Case Western Reserve University の David Cooperrider と Suresh Srivastva が発表した組織開発手法だ。Cooperrider の博士論文（1986 年）が出発点で、以後 40 年近く理論的な拡張と実践が積み重ねられてきた。日本でも 2005 年以降、ヒューマンバリュー社が Diana Whitney を招聘して『ポジティブ・チェンジ』として翻訳・紹介したことで広まっている。

二人の問題意識は明快で、「問題解決の過剰使用が、社会や組織の改善を逆に阻害している」という直観だった。「何が悪いのか」を分析する伝統的アプローチは、当事者を「欠陥を抱えた存在」として位置づけ、結果として防衛反応を引き出してしまう。AWS が 3 ヶ月の実験でぶつかった壁とまったく同じ構造だ。

5 つの原則

2001 年に Cooperrider と Whitney が定式化した AI の理論基盤は、社会構成主義（social constructionism）に立脚した次の 5 原則だ。

原則内容
構成主義原則（Constructionist）組織は会話によって創られ、維持され、変化する
同時性原則（Simultaneity）問いと変化は同時に起きる。問いは中立ではなく、現実をつくる
詩的原則（Poetic）組織の物語は日々共同執筆されている
予期原則（Anticipatory）現在の行動は未来へのイメージに導かれる
肯定的原則（Positive）持続的な変化には肯定的感情と社会的結合が必要

特に重要なのが同時性原則だ。「課題は何ですか？」と聞いた瞬間に、組織は「課題を抱えた組織」になる。AWS が「問いの設計」を起点に方法論を組み直したのは、まさにこの原則の実装と言える。

4D サイクル

AI の標準的な実装は 4D サイクルと呼ばれる 4 段階で進む。

フェーズ内容代表的な問い
Discovery（発見）組織の「最高の瞬間」を引き出す「最も生き生きしていた時を思い出してください。何があなたをそのピーク経験にさせましたか？」
Dream（夢想）強みを増幅した未来像を描く「最も大胆な希望を実現したら、組織はどう変わっていますか？」
Design（設計）その未来を実現する仕組みを設計「その姿を支える構造・関係・対話とは何か？」
Destiny（実行）実装と継続的進化「明日からの一歩として、誰が何を始めますか？」

Discovery と Dream の段階で 「最高の瞬間（peak experience）」と「ときめき」を起点にするのが AI の核心であり、AWS の Observe / Shift もこのパターンを忠実になぞっている。

AWS が AI BPR で行った翻訳

AWS の 4 ステップは、AI の 4D サイクルを業務変革向けに読み替えたものと見ると理解しやすい。

AI 4D サイクルAWS AI BPR共通する設計思想
DiscoveryObserve強み・価値・リスクのマッピング
DreamShift委譲か卓越かの能動的選択
DesignSimulateAI との対話で即時実装・評価
DestinyForecast改善速度に基づく現実的計画

KonMari メソッドとは何か

ここで参考にされている KonMari メソッドは、片づけコンサルタントの近藤麻理恵が著書『人生がときめく片づけの魔法』（2010）で提唱した整理法だ。世界 40 言語以上で翻訳され、Netflix 番組『Tidying Up with Marie Kondo』（2019）で米国でも社会現象になった。

革新的だったのは判断軸の転換にある。普通の整理術は「不要なものを捨てる」から始まるが、KonMari は逆で、モノを 1 つずつ手に取って「ときめく（spark joy）か」だけを問う。ときめかなければ感謝して手放す。「不要 / 必要」という機能判断ではなく、主観的な感情を意思決定の中心に置いたことが特徴だ。

基本ルールは 6 つに整理されている。

  1. 片づけを終えると決意する
  2. 理想の暮らしを思い描く
  3. 「捨てる」を先に終わらせる
  4. 場所別ではなくカテゴリー別に片づける（衣類なら家中の衣類を一箇所に集める）
  5. 正しい順番で進める（衣類 → 本 → 書類 → 小物 → 思い出の品）
  6. 「ときめき」で判断する

なぜ KonMari が AI BPR にハマったのか

KonMari の問いの構造は、そのまま業務変革に転用できる。

領域防衛反応を誘発する問いKonMari / AI BPR の問い
片づけ「これは捨てる？」「これはときめく？」
業務変革「この業務に課題は？／AI に置き換える？」「この業務はときめく？」

「捨てる」「置き換える」と聞かれた瞬間、人は失うものを守ろうとして抵抗する。一方「ときめく？」と問われれば、当事者は残すものを主観で選ぶ立場になり、結果としてときめかない業務は自分から手放したくなる。これは 4D の Discovery / Dream で起きる「肯定的核（positive core）の発見」を、業務一覧に対して実行する翻訳になっている。「従業員自らが『AI に置き換えたい』と言い出した」現象は、この問いの設計が引き起こしたものだ。

なぜ AI が「生成性」を生むのか

近年の AI 研究では、Gervase Bushe がポジティブさそのものより「生成性」（generativity）こそが変化の源泉だと指摘している。生成性とは、参加者が「思わず動きたくなる新しいアイデアやイメージ」を共同で生み出す力のことだ。

AWS のワークショップで「従業員自らが『AI に置き換えたい』と言い出した」という現象は、まさに生成性が立ち上がった瞬間と読める。強みを語ることでアイデンティティの脅威が解除され、「卓越」の選択肢が用意されたことで責任の所在も保全された。その上で「ときめき」という主観的な判断軸が、参加者を能動的な意思決定者に変えた、という構造だ。

批判と限界も知っておく

AI には批判もある。代表的なのは次の 2 点だ。

  • 問題回避の温床になりうる: 肯定面ばかり強調すると、深刻な機能不全や人間関係の問題が「触れてはいけない話題」として温存される
  • ファシリテーション難度が高い: 強みを掘り起こす対話設計には熟練が必要で、過去 40 年で広く普及しなかった理由でもある

AWS の方法論はこの 2 点に対しても巧妙な回答を用意している。Shift で「委譲か卓越か」の二択を強制する設計は、ぼんやりとした肯定で終わらせず必ず判断を下させる仕掛けだし、プロンプトと進行を 170 分のパッケージに標準化したことで、ファシリテーション依存を大きく減らしている。「DevRel ではなくアカウントチームがデリバリーできるようになった」という属人性排除の成果は、この設計が AI 手法の歴史的な弱点を技術で補ったことを意味している。

組み直し後の4ステップ（合計約170分）

ステップ内容
Observe強み・価値・リスクのマッピング
Shift委譲か卓越かの二択判断
Simulate実装と評価
Forecast計画立案

所要時間は合計約170分。ワークショップ形式で実施できる現実的なスコープに収まっている。

驚くべき結果

指標最初最新
満足度3.63 / 5.05.0
変革可能性初回未計測6.50 / 7.0

大手物流企業では従業員自らが「AI に置き換えたい」と言い出し、製造業の従業員からは「業務可視化は人間のコンサルより圧倒的に AI が良い」という評価が出た。

さらに注目すべきは、最新のデリバリーが開発元の DevRel チームではなくアカウントチームによって実施された点だ。手法が属人性を排除してパッケージ化・移転可能になったことを示している。

技術より先に問いのデザインを見直す

ここから学べることを整理すると、AI エージェント導入で本当に躓くのは技術ではなく**「人間側の適応課題」**だということだ。

Heifetz の言う通り、適応課題を技術的課題として扱った瞬間に変革は失敗する。プロンプトやツールをいくら磨いても、当事者の認識が変わらなければ一歩も進まない。

強み起点・能動的な判断・即時的なアウトプットの3点セットで初めて、人は自ら手を挙げて変わり始める。

AI 導入で苦戦している企業の多くは、ツール選定や ROI 計算より先に、問いの設計を見直すべきなのかもしれない。これは AWS に限らず、あらゆる DX/AI 推進担当者が今すぐ読むべき一本だと思う。

元ツイート: @shin_sasaki19 (2026-04-22)