はじめに
先日、AWS Japan麻布台オフィスでAI BPRのハンズオンに参加してきました。これまでの技術的なハンズオンとは異なるものでしたので、感じたことをアウトプットしておきたいと思います。
きっかけは、JAWS-UG事務局の福地さんからいただいた1通の案内でした。
案内文には、AWSで機械学習領域のDevRelを担当されている久保さんからのメッセージが添えられていました。
今回 DevRel で開発・提供しているビジネスモデルにAI エージェントを組み込むためのアプローチ手法である "AI BPR" を JAWS-UG の Leader の方中心にハンズオン含めて提供する機会を持たせていただく予定です。
AI/ML は皆さんご存知の通りなかなか本番に乗らない機能で、生成 AI が登場してからもその難しさは継続してます。DevRel として技術に留まらず "技術を活かせる機会を作る方法" を伝える必要があることがずっと頭の中にありました。
2026年7月某日、AWS Japan麻布台オフィス＆オンラインのハイブリッドで開催されました。今回は、JAWS-UG運営メンバー向けの小規模なお試し開催という位置づけでした。
普段は現場のエンジニアというより、プロジェクトマネジメントの立場で仕事をしている自分にとって、AIエージェントを技術の話に閉じずに、組織や事業の話として扱うという切り口には強く惹かれるものがあり、参加を決めました。
この記事では、当日の体験と、感じたことをまとめてみます。
AI BPRとは何か
AI BPR（AI-driven Business Process ReEngineering）は、一言でいうとビジネスモデルをAIエージェント前提に組み替えるための、4〜5時間のプログラムです。
AWSの久保さんがブログを執筆されています。
セッションの冒頭、久保さんは印象的な例えでAI BPRの考え方を説明してくれました。ラーメン屋の例えです。
目の前に出てきたラーメンが1人で作られていようと2人で作られていようと、お客さんにとっては関係ない。ラーメンが美味しいかどうかがすべて。効率化するだけではお客さんは増えない。
効率化ばかりに目が向きがちなAIエージェント活用ですが、大事なのは「何が今のお客様に選ばれている理由なのか＝強み」を起点に考えること。強みを支えている業務は伸ばし、強みに関係のない業務はAIエージェントに手放していく。この考え方が、AI BPRの土台になっています。
AI BPRには3つの特徴があります。
- 強み起点：今の業務の何が問題かではなく、今何が提供できていて、それがなぜ選ばれているのかを起点に考える
- 心理的安全なロールシフト：人間の役割をDoから、Plan・Seeにシフトし、AIエージェントにDoを委譲する
- 即時的フィードバック：AIとの対話を通じて、その場で成果物を作る。持ち帰り時間をゼロにする
なぜ生まれたのか
セッション中盤では、なぜ今までのBPRやDX推進がうまくいかなかったのか、その理由が紹介されました。
- 問題から始める：課題を洗い出して反射的に改善案を出す欠損反射的アプローチは、多くの組織変革が失敗する要因になっている
- 技術的に可能か否かの議論に閉じる：AIで効率化できると人員削減の恐怖につながり、心理的安全性が損なわれる
- コミュニケーションのオーバーヘッド：現場へのヒアリング → まとめ → 確認のサイクルに時間がかかりすぎて、本来変革すべきタイミングを逃す
課題からスタートするという点は始めやすいと思いますが、変革まで持っていくのが難しいのですよね。
これらを踏まえて設計されたのが、AI BPRのObserve → Shift → Simulate → Forecastという4つのステップです。
Observe → Shift → Simulate → Forecastを体験して
ちなみに今回はAmazon Quickを使って体験しましたが、これには理由があるそうです。AI BPRはKiroやClaude Codeで動かすこともできるのですが、久保さんによると、実際に組織へ展開していく場面ではKiroのようなエディタ然とした画面に対して、非エンジニアの方から「この黒くて見にくいものは何ですか」と言われてしまうことがあるとのこと。展開のしやすさを考えると、見た目にも親しみやすいAmazon Quickの方が広がりやすい、という実践から得た判断のようでした。
当日は、時間が限られていることもあり、Amazon QuickにインポートしたSkillで、まずはDry RunをしてAI BPRを疑似体験する形となりました。架空の顧客ペルソナを作り、Amazon Quick内でコンサルタントとペルソナを会話させ、AI BPRの4ステップを一気通貫で動かしてみる、というものです。
実際にAmazon Quickとの対話でObserveのフェーズが進んでいく様子を見ていると、業務ヒアリングのやり取りが数分で終わり、業務フローの図とともに顧客提供価値ストーリーがまとまっていく様子は正直驚きでした。今何を提供していて、その価値を支えている強みは何かという言語化を、AIとの対話だけでその場で終えてしまいます。いかに自らの状況を提供できるかが鍵になるなと感じました。
Shiftのフェーズでは、AIが「この業務は強みに直結していないので、AIエージェントに任せることに抵抗はありますか？」と聞いてくるやり取りが印象的でした。単に「効率化しましょう」ではなく、「感謝した上で手放す」という進め方をエージェントに指示している、という話も興味深かったです。
断捨離で有名なこんまりメソッドの考え方（自分が本当にときめくモノやコトを残して、ときめかないものには「感謝を伝えてサヨナラする」）がベースになっているとのことでした。
Simulateのフェーズでは実際に作ったエージェントの精度を何サイクルか検証し、数値で評価していきました。最後のForecastのフェーズでこの結果をベースにどう展開していくかの計画を立てる、という流れで、限られた時間の中でも一連の流れを掴むことができました。
なお、このDry Run、本番さながらの精度でシミュレーションしていくために、Dry Runを作るときは、シナリオの内容そのものよりも、どういう人が参加するのかを丁寧に書いておくと、本番を正確にシミュレーションできるとのことでした。何をテーマにするかより、誰が・どんな性格で・どんな背景を持って参加するのかを言語化することの方が、シミュレーションの精度を左右するというわけです。エージェントにペルソナを再現させることになるので、確かにその通りですね。
実際に自分でDry Runをやってみた
当日、自分自身でもペルソナを設定して、Dry Runを回してみました。
設定したのは、社内エンジニア組織で若手エンジニアの育成を担当するエンジニアリングリードというペルソナです。
架空の設定のため、私自身や私の業務ではありません。悪しからず。
登場自分物の名前は、すべてエージェントが生成した架空の名前です。
同姓同名の方がいらっしゃるかもしれないので、フルネームだけはマスキングしました。
- 業種・業界：IT・情報通信業（社内エンジニア組織）
- 職種・役職：エンジニアリングリード（若手エンジニア育成担当）
- 業務の概要：若手育成の企画・実行、技術力向上のための施策立案、社内勉強会の企画運営、育成状況を経営層へ報告する業務
- AI BPRで扱いたいテーマ：育成状況の報告資料作成、社内向け技術情報共有をAIエージェント前提でどう変えられるか
- ペルソナの性格・懸念：技術力に自負があり組織の技術力向上に熱意を持つ一方、「AIに任せてニュアンスが伝わらない、冷たいと思われないか」という懸念が強いタイプ
Dry Runは、シナリオ作成の対話で決めたペルソナ設定をもとに、AIがダミーの業務データ一式（1on1メモ、20名分の育成進捗トラッキング、月次報告資料、Slack共有ログなど）を自動生成し、それを「インプット」としてObserve → Shift → Simulate → Forecastの4フェーズを一気通貫で進めていく仕組みでした。フェーズごとに、どんなインプットからどんなアウトプットが生まれたかを振り返ってみます。
Observe：業務フローと会話をとおして顧客提供価値ストーリーを考える
インプット：全体像・アウトプット・インプット・強み・リスクを尋ねる7つの質問への、ペルソナの回答。
アウトプット：業務フロー図（Mermaid形式）と、「私たちは○○を通じて○○を提供している」という一文にまとめられた顧客提供価値ストーリー。強みとして「数字にならない成長を捉えて言語化する力」「メンターによる育成の連鎖」が、リスクとして「報告資料作成の高負荷（20名分の集約に半日〜1日）」「育成知見の属人化」「技術情報がSlackで流れて消えてしまうこと」が言語化されました。このストーリーをペルソナ自身に10点満点で自己採点させる仕組みがあり、今回は9点という評価でした。
Shift：業務の会話から委譲・卓越・強化の仕分け表をつくる
インプット：Observeで洗い出した5つのサブプロセスそれぞれについて「AIに任せることに抵抗はありますか？」と一つずつ確認していくやり取り。
アウトプット：各サブプロセスが「委譲（AIに完全に任せる）」「卓越（AIが下準備し人間が意思決定する）」「強化＝人間が守る」の3つに仕分けられた表と、4体のAIエージェント案（ロール名つき）。技術情報の共有と報告資料の集計・整形は委譲、成長エピソードの言語化と勉強会の企画・運営は卓越、そして1on1の対話そのものは人間が守る、という線引きになりました。「対話そのものは聖域として残しつつ、その前後の準備・記録はAIに任せる」という発想は、アウトプットを見て初めて納得できた発見でした。
Simulate：同じデータでも何を優先するかでアウトプットが変わる
Dry Runの中で一番具体的で、面白かったのがこのフェーズです。
インプット：1on1メモと、20名分の育成進捗トラッキング（CSV）。
1回目のアウトプット（評価11/20）：AIが4名分の「成長の兆し」を要約しましたが、ある若手について、CSV上の「モチベーション：中」という数値だけを見て「着実に成長、現状維持」と判定してしまいました。ただ、実際には1on1メモに「一時的にモチベーションが低下したが、振り返りを経て回復した」という記述がありました。
インプットの調整：この結果を見て、「CSVの数値ではなく、1on1メモに書かれた感情・変化の記述を優先して判断してほしい」というフィードバックをAIエージェントの実装ルールに反映しました。
2回目のアウトプット（評価18/20、+7）：同じ若手について「回復済みだが、同期比較で焦る傾向が本人に残っている可能性があり、再発を注視すべき」という評価に変わりました。同じインプットデータでも、何を優先して読むかというルール一つでアウトプットの質がまったく変わることを、数字と実例で確認できたのが大きな収穫でした。
ちなみに、AgentCardには、どういったAgentを作るかといったことがまとめられます。
Forecast：次の2週間で何をやるかという問いからアウトプットが生まれる
インプット：「この後の2週間で最初にやる、具体的で小さなアクションは何ですか？」という問い。
アウトプット：「報告ドラフトAgentを来月の実報告で"本当に"使ってみる」「メンター役の同僚に『面白いものを作ったから見て』と声をかける」という2つの具体的な行動計画。効果測定の指標には、作業時間の削減幅だけでなく、若手が「自分の成長をちゃんと見てもらえている」と感じているかという定性指標も含まれていました。
一番の収穫は「役割の再定義」
Dry Run全体を通じて一番印象に残ったのは、最終的にペルソナ自身の言葉で「AIに奪われる」から「作業が消えて対話に集中できる」へと役割認識が変わったことです。効率化の話として始めたはずが、最後には「本当に大事にしたいこと（1on1の対話）に集中するための変革」という文脈に着地していました。これはまさに、セッションで説明されていた「心理的安全なロールシフト」そのものだと感じました。
感じたこと
ここからは、当日メモに残していた自分の疑問や気づきをそのまま書いておきます。
私なりの理解なので、正確ではないかもしれません。ご了承ください。
AI-DLCとの違いへの疑問
AI BPRと似た概念に、開発プロセスにAIエージェントを組み込む「AI-DLC（AI-driven Development Life Cycle）」があります。共通点はAgentが主導して成果物を作成し、人間が意思決定するという点。違いは、AI-DLCが開発プロセス（SDLC）を対象にしているのに対し、AI BPRはビジネスモデル・ビジネスプロセスを対象にしている、という説明でした。
ここで最初に浮かんだ疑問は、対象が違うだけで、目指しているものは結局同じなのでは？という点でした。AI-DLCは開発速度・Time to Marketの短縮を目指す手法ですが、開発を速くすること自体も、突き詰めればビジネスアウトカムを向上させるための手段のはずです。だとすれば、両者の違いは対象領域というより、別のところにあるのではないかと考えました。
セッションを聞き進めるうちに、両者の違いは「技術的課題（どう変えるか）」と「適応課題（なぜ変われないのか）」という、課題の性質の違いなのではないかと考えました。開発チームの中だけで完結するAI-DLCでは、「どう開発プロセスを変えるか」は扱えても、「なぜ組織が変われないのか」という、より大きな組織的な部分にまでは踏み込みにくいと思います。AI BPRは、そのなぜ変われないのかに正面から向き合うために生まれた手法なのだと理解しました。
強みを言語化する難しさ
当日、説明資料の中にロジスティクス企業のバリューチェーン例（見積・プライシング／通関・コンプライアンス／請求・収益管理）の記載がありました。これを見ながら、自分としては「これ、結局課題から始まっていないか？」とメモしていました。「見積が属人化している」「関税政策の変更対応が大変」というのは、強みというよりリスクや課題そのものに見えたからです。
セッション中でも「強みと言われても私たちにはないです、というパターンと、意外と語ってくれるパターンに二極化する」という話がありました。たしかに、通常業務の中では強みを意識していないということも関係するのだと思います。バックオフィス業務のように細分化された仕事ほど、「強み」を言語化するのは簡単ではない、という点も率直に納得感がありました。
小さく始めること
事前の3原則の一つに「役員・役職者のスポンサーを獲得する」がありましたが、実施中の4原則を見ていると、うまくいかないパターンの多くは事前に考えていた活用方法の範囲内で終わってしまうというものでした。AIのために業務を変えるという視点への切り替えを、無意識に避けてしまうということです。
これは、大きな組織展開を最初から狙うと起きやすい話だと感じました。だからこそ、持ち帰りたいと思ったのは「1 to 100の提案を最初から狙わない」という原則でした。まずは自分自身の手元の業務でAI BPRを回してみて、そこで得た小さな実感を持って次の人に広げていく。実際にDry Runを回してみたところ、「AIには無理」と思い込んでいた領域にこそ大きな気づきがありました。何を大事にするか、大事にしなくて良い部分はAIエージェントへ。この考えをしっかりと持っていきたいです。
おわりに
AI BPRは「AIをどう使うか」から始めるのではなく「AIエージェント前提で業務や組織をどう組み替えるか」という、一段視座の高い問いに向き合うためのフレームワークでした。技術の話に閉じず、組織を巻き込むところまで含めて設計されている点が、マネージャー視点で見ても腹落ちする内容でした。
AI BPRは現在、AWSのアカウントチームを通じたデリバリーで利用できるとのことです。気になった方は、担当のAWSアカウントチームやソリューションアーキテクトさんにご相談してみてください。