「課題は何ですか？」と聞くのをやめる：AWS AI BPRとは？

2026年6月21日更新 2026年6月22日

Shiori

先日、AWSのAI BPRについて知る機会がありました。これまで私がAIプロジェクトを進めるときは、課題やボトルネックを特定し、デザイン思考やシステム思考などの既存のビジネスフレームワークを採用することが多くありました。そのため、AWS公式記事の「『課題は何ですか？』と聞くのをやめた日」というタイトルは、とても斬新に映りました。このアプローチが従来の進め方と何を変えるのか、学びを深めたいと思ったことが本記事の出発点です。

AWSのAI BPR（AI-driven Business Process Re-Engineering）は、業務の問題点をAIで効率化するだけでなく、組織がすでに提供できている価値や強みから出発し、AIエージェントを前提に業務プロセスを組み替える手法です。公式には、4〜5時間で実施するプログラムとして紹介されています。[1]

この記事では、AWSの公式記事を手がかりに、AI BPRの考え方と実際のAIプロジェクトへの適用方法を整理します。

AWS AI BPRとは何か

AWS AI BPRは、「困っている作業をAIに置き換える」のではなく、「守るべき価値を明確にし、人とAIの役割を再設計する」ための業務変革手法です。

従来型のAIプロジェクトでは、次のような順番を取りやすいと思います。

現在の業務を可視化する
課題やボトルネックを特定する
AIによる解決策を考える
効果をKPIで測る

この流れ自体が誤りなのではありません。対象が明確で、既知の方法で解ける問題には有効です。一方で、「仕事をAIへ渡すことへの不安」や「責任範囲を変えたくない気持ち」が関係する変革では、合理的な解決策を提示するだけでは前に進まないことがあります。

AWSの初期プログラムも、目標設定、ボトルネック特定、解決案、シミュレーションという問題解決型でした。しかし、結果が参加者の予想する解決策の範囲にとどまることや、「やはり人間が担うべきだ」という結論へ戻ることがあり、フレームワークを組み直したと説明されています。[1]

ここで大切なのは、AI BPRが課題を見ない手法ではないということです。課題を最初の問いにせず、まず「どの価値をさらに強くしたいか」を共有します。そのうえで、業務を構成する要素を見直し、AIへ委譲する部分と、人がさらに卓越させる部分を選びます。

なぜ「課題」ではなく「強み」から始めるのか

「課題は何ですか？」と聞かれると、参加者は現在の業務の欠点や無駄を探します。そこから出てくる案は、作業時間の短縮、手入力の削減、検索の高速化など、既存業務を前提にした改善になりやすいものです。

一方、「顧客から選ばれている理由は何か」「絶対に失いたくない価値は何か」と聞くと、議論の基準が変わります。たとえば、単に「報告書作成が遅い」という課題を見るのではなく、「現場の判断を早くし、顧客との約束を守る」という価値を起点にできます。すると、報告書の一部を効率化するだけでなく、情報収集、判断、伝達までを含む業務全体を再設計する選択肢が見えてきます。

AWSは、再設計したAI BPRの特徴を次の3点に整理しています。[1]

強み起点：既存の顧客価値や組織の強みを見つけ、それをどう増幅するか考える
心理的安全なロールシフト：業務をAIへ委譲するか、人が価値を高めるかを当事者が選ぶ
即時的フィードバック：対話の場で成果物を作り、その日のうちに仮説を確かめる

私がここから得た重要な示唆は、問題分析と強み起点を二者択一にしないことです。デザイン思考やシステム思考で培った観察、関係性の把握、仮説検証は引き続き使えます。ただし、最初の問いを変えることで、分析が「現在の不具合の修正」だけに閉じるのを防げます。

4つのステップを理解する

組み直されたAI BPRは、Observe、Shift、Simulate、Forecastの4ステップで進みます。AWS公式記事に示された標準時間を含めると、次のように整理できます。[1]

ステップ	わかりやすい意味	主な活動	標準時間
Observe	大切なものを見つける	業務、顧客価値、強み、リスクを可視化する	40分
Shift	役割を組み替える	業務を分解し、AIへ委譲する部分と人が卓越させる部分を選ぶ	50分
Simulate	小さく動かして確かめる	変革シナリオを試作し、品質や効果の変化を評価する	60分
Forecast	実行計画へ変える	評価結果を基に、次の実験、担当、期限、判断条件を決める	20分

Observe：業務フローより先に価値を見る

ヒアリングや既存資料から、「誰に、どのような価値を届けているか」「その価値を支える判断や経験は何か」を明確にします。業務フローも確認しますが、単なる作業一覧ではなく、強みとリスクを対応づけることがポイントです。

Shift：人とAIの役割を選び直す

業務を小さな単位に分解し、それぞれを次の観点で判断します。

AIへ委譲しても価値が損なわれないか
AIによって人の専門性を高められるか
人が責任を持つべき判断はどこか
例外時に誰が介入し、どう復旧するか

「自動化できるか」だけで決めず、価値、責任、例外対応まで含めて役割を再設計します。

Simulate：資料ではなく動く仮説を作る

選んだシナリオを、実データを模した安全なサンプルや限定された業務範囲で試します。完成したシステムを作ることが目的ではありません。「入力が曖昧でも使えるか」「品質を誰が判断できるか」「人の作業は本当に価値の高い部分へ移るか」を確かめます。

Forecast：PoCの感想を次の判断へ変える

シミュレーションの結果から、次に何を試すかを決めます。担当者と期限だけでなく、続行、修正、中止を判断する条件を置くことが重要です。これにより、「よいデモだった」で終わらず、実装可能性と業務変革の両方を検証できます。

実際のAIプロジェクトに適用する方法

AWSの4ステップをそのまま形式的に再現するより、プロジェクトの意思決定に接続することが重要です。私は、次の6段階に落とし込むと実務へ適用しやすいと考えます。

1. 変革対象を一つの顧客価値で表す

対象を「営業業務」や「問い合わせ対応」のような部門名・業務名だけで決めず、「顧客が最初の回答を得るまでの不確実性を減らす」のように、届けたい価値で表します。

2. 意思決定者と実務担当者を同じ場に置く

経営・業務・技術の誰か一方だけで進めると、価値、現実性、責任のいずれかが欠けます。業務を知る人、変更を承認できる人、AIの限界を説明できる人を参加者に含めます。

3. Observeで「強み・価値・リスク」を一枚にする

各業務について、作業内容だけでなく、次の項目を並べます。

確認項目	問いの例
顧客価値	この業務は誰のどの判断を助けているか
強み	他社や他チームより信頼されている理由は何か
暗黙知	熟練者だけが見ている兆候は何か
リスク	誤り、遅延、停止が起きたとき何が失われるか

4. Shiftで役割を4分類する

すべてを「自動化する・しない」の二択にせず、AIによる実行、人への提案、人とAIの共同作業、人が保持する判断の4つに分類します。高リスクな判断は人に残しつつ、情報収集や選択肢生成をAIへ移すなど、段階的な設計ができます。

5. Simulateで最小の変革シナリオを試す

最初の検証では、モデルの精度だけでなく、業務全体の変化を測ります。

顧客価値につながる時間や品質は改善したか
人の確認負荷は減ったか、それとも別の場所へ移ったか
例外時に安全に停止・復旧できたか
担当者が新しい役割を受け入れられるか

6. Forecastで「次の投資判断」を明文化する

次の30日程度で実施する検証、責任者、必要データ、セキュリティ・法務確認、成功条件を一枚にまとめます。成功条件は、技術指標と業務指標を分けて設定します。たとえば回答精度だけでなく、一次回答までの時間やエスカレーション率も確認します。

適用時に見落としたくない点

強み起点は、問題を隠すための方法ではない

強みに注目することを「前向きな話だけをする」と解釈すると、構造的な問題や対立を見落とします。Observeではリスクも明示し、Simulateでは失敗条件も試す必要があります。強みは議論の入口であり、検証を甘くする理由ではありません。

AIのデモ成功と業務変革の成功は別である

試作が動いても、データ更新、権限、監査、障害時対応、運用費用が未整理なら本番には進めません。Simulateでは魅力的な出力だけでなく、運用に必要な人の役割まで確認します。

AWSサービスの採用が目的ではない

AI BPRはAWSが提供する方法論ですが、最初に決めるべきことはサービス名ではなく、守りたい価値と役割変化です。技術選定は、データ、セキュリティ、既存環境、運用能力に基づいて後から行います。

4〜5時間で変革が完了するわけではない

短時間で得られるのは、変革シナリオ、試作、評価、次の計画です。組織への展開、ガバナンス、教育、継続的な評価は別途必要です。短いワークショップは終点ではなく、意思決定を早める起点として扱うのが適切です。

まとめ

AWS AI BPRの新しさは、AIを使うこと自体よりも、問いの順番を変えることにあります。

課題やボトルネックではなく、守り、増幅したい価値から始める
AIへ渡す仕事だけでなく、人が卓越させる仕事も選ぶ
提案書で終わらず、その場でシミュレーションする
PoCの結果を、次の投資判断と実行計画へつなげる

私にとって「『課題は何ですか？』と聞くのをやめた日」という言葉は、これまで使ってきたデザイン思考やシステム思考を否定するものではありませんでした。むしろ、観察や構造理解の前に置く問いを変え、AIプロジェクトを小さな効率化から業務価値の再設計へ広げるヒントだと受け止めています。

次のAIプロジェクトでは、「何が困っていますか？」の前に、「顧客に届け続けたい価値は何ですか？」「AIが加わったとき、人は何に集中したいですか？」と聞いてみる。この小さな変更から、AI BPRの考え方を実践に取り入れられます。

参考文献

Amazon Web Services, AI 駆動の業務変革手法：「課題は何ですか？」と聞くのをやめた日, 2026年4月21日