Amazon Web Services ブログ

顧客駆動のチームでAI 駆動の手綱を握る : ML Enablement Workshop による副作用の解消

Claude Code や Kiro といった AI 駆動の開発ツールや開発環境によりコーディングの生産性が飛躍的に高まっています。さらに、AI DLC をはじめとした開発方法論が AI の適用範囲を開発プロセス全体に広げることで、 “本番リリースまでの時間” は数倍に短縮されつつあります。その生産性向上に着目が集まる一方で、リリース速度が事業の成長を阻害するリスクが観測され始めています。

リスクは技術・ビジネス両面で発生します。技術面では、今まで年 1~2 回だった本番環境に影響するバグが週次で発生するリスクが報告されています (参考 : AWS の VP/Distinguished Engineer である Joe Magerramov の記事 “The New Calculus of AI-based Coding”)。ビジネス面で顕著な報告はまだありませんが、リスクを示唆する研究として 1995 年にコロンビア大学のシーナ・アイエンガー教授が示した「ジャムの法則」があります。この実験では 6 種類のジャムを用意した場合と 24 種類用意した場合とで購買行動を比べており、選択肢が多い 24 種類の方が売上が少なく 1/10 になることを示しています。開発に当てはめれば、機能が 4 倍の速度で実装されたとき (6 種類から 24 種類)、 逆に利用率が 1/10 になりえるということです。リスクを低減するには削除や撤退の意思決定が必要になりますが、 IPA の報告によれば日本ではスタートアップにおいても製品やサービスの転換 (ピボット) が不得手であり、米国に比べて成長率が 30 分の 1 程度となる要因として指摘されています (参考 : “成長しない日本のソフトウェアスタートアップ 国内競争を促進してエコシステムを創出する”)。AI 駆動開発によるリリースの増加はプロダクトマネージャーや事業責任者をはじめとした意思決定者の負荷を高める副作用があり、意思決定の量と質を高める実践と仕組化なしに開発と価値向上のバランスを取ることは困難です。

Amazon では「顧客に必要とされないものを作らない」ための Working Backwards という製品開発プロセスがあり、リスクに対する有効な対策の一つとなっています。今回ご紹介する ML Enablement Workshop (MLEW) はそれを誰もが実践できるよう体系化されたワークショップです。これまで、JINS 様 (AWS Summit 2025 ご登壇) や MUFG 様 (re:Invent 2024 ご登壇)、また BASE 様など業種を問わず多くのお客様が「顧客駆動」でプロダクトを開発するために利用され成果を実感されています。「誰もが」とある通り、MLEW の資料は GitHub で公開されており事例を含め参照できます。2025 年 9 月に GitHub で公開された version 3 は Working Backwards の各プロセスを進めるために生成 AI を活用しており、よりスムーズに進められるようになっています。公開後 1 ヵ月ほどで約 20 社に提供されており、この数は昨年 1 年分の提供数に匹敵します。この提供スピードは、お客様のニーズはもちろん「誰でも」行えるようにするための体系化と生成 AI による効率化が機能していることを示しています。2025 年 10 月に行われた 7 社同時での提供では、ほぼすべての会社がサポートなしにプロセスを完了しました。

MLEW version 3 では机上で企画をまとめるのに留まらず、AI 開発エージェントを用い複数本の企画から複数本の動くモックを構築します。これにより、今までワークショップ実施後にしかできなかった「想定顧客の反応の計測」をワークショップ期間内に行うことができ、事前に定めた基準に基づき企画を「切る」あるいは「転換」する判断、ピボットを実践できます。重要な点は、MLEW を通じ「計測した反応(データ)」と Working Backwards という「プロセス」により誰もが高品質な意思決定を実践できるようになることです。

MLEW と AI DLC のような開発プロセスは補完関係にあります。組み合わせることで、顧客駆動の意思決定で AI 駆動の方向性をコントロールでき開発生産性と製品価値向上の比例関係を維持できます。

本ブログでは、MLEW の流れをリポジトリに掲載されているコンテンツにそって解説し、実際得られているお客様の反応もご紹介します。解説に沿って皆さん自身でワークショップを実施いただくことも、AWS アカウント担当がいる場合は提供を依頼することも可能です。また、AWS パートナーからの提供に向けて伝授も進められています。

ML Enablement Workshop とは ?

ML Enablement Workshop は、1~3 ヵ月以内に計測可能な成果を得るために、組織横断で関係者を招集し価値検証の打率・速度・本数を高めたプロジェクトをキックオフするためのワークショップです。 1~3 ヵ月という期間は、過去 AI/ML 等の新規プロジェクトを始めると大体 3 ヵ月以内に緊急かつ優先度の高い突発的なタスクが発生し中断することが多い観測結果に基づいています。そのため、3 ヵ月以内にプロジェクトを継続すべき定量的な成果を観測することが重要になり、このスピードには「意思決定できる最小単位」となるチームの組成が不可欠です。

開催する際は、次の基準を満たしていることを推奨します。

  • 経営層の合意と支援
  • 意思決定できる最小単位を構成する、ビジネス面で事業責任者 (プロダクトマネージャーなど)、技術面で開発者、必要に応じデータサイエンティストの参加

経営層との合意は、仮に 3 ヵ月の間に突発的な優先度の高い案件が入ってきても活動の継続を保証するために必要です。その代わり、チームはこの期間内にあらかじめ決められた定量的な基準を超える成果を出すことにコミットします。条件を確認し、実施が確定したらワークショップの流れに沿って進めていきます。MLEW は過去 2 回大型のアップデートを行っており、現在公開されているのは version 3 になります。本ブログで記載している内容は最新版の version 3 に基づいています。

ワークショップの流れ

GitHub のリポジトリで流れを確認してみましょう。アクセス先に書いてある通り、ワークショップは全 3 つのプロセスで行われます。

リポジトリの URL : https://github.com/aws-samples/aws-ml-enablement-workshop

それぞれのプロセスの資料は、リンクからアクセスできます。まず Day0 から見ていきましょう。

Day0 は、ワークショップを行う目的と期待する役割を全員で確認するフェーズです。MLEW を実施したい意向がある方は、経営層だったりプロダクトマネージャーだったり、あるいは開発者だったりと様々です。誰かが「無意味な時間」と感じていれば意思決定への本気度も履行の意欲も担保できないため全員の合意が不可欠です。例えば経営層は乗り気だがプロダクトマネージャーは当面のロードマップの実現に注力していて考える余裕がなかったり、プロダクトマネージャーは乗り気だが開発者は実装の余裕がないといった状況はよく起こります。今行う意味や意義について認識が合わないと気付いた場合、見送りや対象チームの変更、参加者の変更などを事前に検討できます。

Day0 の進め方は Day0 のガイドに沿って行います。各担当がワークショップ前に準備すべき内容もこちらに記載されています。事前準備として特に重要な点は下記 3 点です。成果物にはフォーマットがあり、情報さえ集まっていれば容易に準備出来ます。1 と 2 については、後続の実践編で生成 AI へのインプットとして使用します。

  1. 顧客を知る : 対象とする顧客について具体化しておく
  2. 市場を知る : 顧客の課題に対し、解決策になりそうな競合や市場のソリューションについて一覧化しておく
  3. 環境を整える : 生成 AI を用いワークを進めるため生成 AI が利用できる環境を整える (AWS なので Amazon Q Developer が推奨だが他の AI エージェントツールも利用可能)

実践編、改善編が本編になります。実践編と改善編の構成は次のようになっています。

実践編は Working Backwards をやり切り体得することに注力しており、改善編は体得したプロセスを自ら行い企画を改善することに注力しています。改善編の後半では、具体的なタスクとスケジュールを必ず決めて終了します。

以降は、実践編と改善編について解説します。

実践編 : Working Backwards をやり切る

実践編は Working Backwards の 5 つのプロセスに沿って進行します。Listen で顧客は誰か? 顧客はどのように行動しているか ? を観察し、Define で潜在する課題と企画を特定、Invent で課題を解決・機会を活用する発明を考案、Refine で発明による新しい顧客の体験をプレスリリースの形で描画し、Test/Iterate でその効果を計測、改善のサイクルを回していきます。各プロセスの時間が決められている通り、実践編では時間厳守でやり切ることにフォーカスしています。実践編の目的はプロセスの理解と体得で、ユースケースの質は改善編で高める構成となっています。実践編の資料は下記リンクからアクセスできます。

https://github.com/aws-samples/aws-ml-enablement-workshop/blob/main/docs/organizer/day1.md

プロセス全体の流れを図にすると、次のようになります。Listen、Define で製品やサービスを届ける顧客の声から根本的な課題を特定し、Invent で解決のための発明、Refine と Test/Iterate で解決しているかどうか答え合わせをする形になります。事業責任者の方であればカスタマージャーニーマップやユーザーストーリーマッピングによる体験分析をされたことがある方もいるかもしれません。Working Backwards では、 Listen / Define の分析フェーズに当たります。また、ビジネスモデルキャンバスなどで収益を生むプロセスを立てる方もいると思いますが、Working Backwards では Test/Iterate で具体的に観測すべきビジネスの指標と目標値を決めます。Working Backwards のコンセプトは「最も難しい判断を最も最初に行う」ことであり、Refine でプレスリリースを書くことに象徴されるよう “明日この製品をリリースしたらそれは顧客に受け入れられ売れるのか ?” を顧客の体験面、ビジネスの成果指標面両方で検証するフレームワークになっています。

MLEW は、Working Backwards を「誰もが」実践できるよう、顧客・課題・発明・体験・観測、といった人により解釈が異なる言葉やプロセスを明確に定義しています。例えば、Define のフェーズでは「課題」とは何か、課題が顧客の声 (Listen) とどのように異なるのかを明確に示しています。また、Invent で行う課題に対する解決策 (発明) の考案でも、まず 「発明」とは何かを定義し、それと Define (課題) を発見するために立てた問いとどういう関係があるのか示しています。

このような「言語化」により生成 AI へ正確な指示を与えることができ、ファシリテーションの精度を高めています。下記の「当日のガイド」に従い進めていけば、手早くかつ再現性の高いプロダクト開発プロセスを実践できるようになっています。

https://github.com/aws-samples/aws-ml-enablement-workshop/blob/main/yourwork/README.md

Generative AI Use Cases (GenU) を導入済みのお客様は、ユースケースビルダーにワークショップ専用のユースケースをインポートすることで GenU 上でワークショップを進めることができます。

もちろん、生成 AI の出力結果は完璧ではありません。参加者の知見や経験を持ち寄り、生成された顧客の体験や発明が妥当かどうか、確認しながら進めていきます。主催者 (ファシリテーター)用のガイドもページに記載しており、これまでのワークショップの経験から気を付けるべき点やタイムテーブルの例などをまとめています。

企画をプレスリリースとして執筆する Refine のフェーズが終了した後、AI 開発エージェントにプレスリリースを与えアプリケーションのモックを作成します。以下は EC サイトごとに異なるサイズや規格で商材を作るのが面倒という課題を生成 AI で解決する企画から生成した例です。ランディングページ、体験可能なモック、またモック内のページビューなどが参照可能なダッシュボードを構築します。

モックを作成させている間に人間は最後の Test/Iterate を行い、構築したモックでどのような反応が得られたら次のフェーズに進むのかを定量的に定義します。実践編終了時点で、顧客に対する解決策の仮説、仮説を検証するための動くモック、モックで計測する顧客の反応と合格基準がそろっている状態になります。

改善編 : 現実のデータに向き合いプロセスを繰り返す

改善編は Working Backwards の最後のプロセスである Test/Iterate を実践します。すなわち、モックを通じ顧客候補の反応を “Test” し、そのインプットを “Listen” することで Working Backwards を “Iterate” するということです。通常のワークショップはウォーターフォールのようにプログラムをすべて終えてアウトプットが出たら終了ということが多いですが、MLEW では多くの製品開発プロセスがそうであるようにアウトプットから得られた反応を基に改善するまで行います。これまで、ワークショップで作成するのはプレスリリースのみ、しかも 1 本にしぼっていましたが、生成 AI により複数本のプレスリリースとモックが作れるようになりました。複数本の検証結果があることで、反応が芳しくない企画を捨てる、方向を変えるといった判断が行いやすくなりました。モックから反応を得る期間を確保するため、実践編と改善編の間は 1 週間は空けるスケジュールを推奨しています。

改善編の前半は参加者自身による Working Backwards 、後半 1 時間は今後の計画を立てるために配分しています。前半の時間配分は、参加者の Working Backwards に対する評価に応じ時間配分を頂きます。プロセスが明確に区切られていることで、Listen に時間をあて顧客の反応分析に注力する、反応は良好であるためより差別化された体験を目指し Invent に注力する、といった状況に応じた対応を取ることが出来ます。

改善編では、今後に向けて実際のプレスリリースまでのマイルストンを立てます。実際のプレスリリースまでに何個のマイルストンがあるのかについても、スポンサー、ファン、シェアの獲得といった明確な段階を定義し達成すべき段階について解釈がぶれないよう構成しています。

マイルストンの到達計画を立てたら、その計画が確実に履行されるようワークショップ期間中にスケジューラーに定期ミーティングやスポンサーとなった役員報告への時間を登録いただきます。

実施してのフィードバック

これまで、お客様から次のようなフィードバックを頂いています。ワークショップの密度の濃さとモックまで作るスピード感を高く評価いただいています。

  • 「各フェーズが意味がありとても密度の濃い良いワークショップでした。」
  • 「一連の流れをAIを活用してスピーディに体感できた」
  • 「数時間で問題の整理からモックの作成、その後の計画までできた」
  • 「すごいフレームワークですね。人手だけでやるととても疲れると思いますが、AIの力でやりやすいと思います」
  • 「当たり前を疑う問いを作ることができた」

MLEW 自身も Working Backwards に沿い、お客様からのフィードバックを基に改善を続けています。今年開催された「ビジネスをグロースする生成AIコンテスト2025」で提供した内容を基に作成しており、version 3 公開後もすでに 2 回アップデートしておりモックのメトリクス計測やプロンプトの修正を行っています。生成 AI コンテストに参加いただいたお客様の開発したサービスのいくつかは AWS のブログとして公開いただいており、今後より多くのお客様の事業成長を支援すべく今後も改善を続けていきます。

終わりに

本ブログでは、生成 AI による開発の加速は意思決定負荷が増える副作用があり、技術的・ビジネス的な判断を誤る回数が増える問題を明らかにしました。そして、この問題は特に日本企業で顕著に観測される可能性があることを IPA のレポートを基に示しました。その解決策の一つとして、Amazon で実践されている顧客起点で「必要とされない」ものを作らない Working Backwards をチームで身に着けるための実績あるワークショップ ML Enablement Workshop を解説しました。生成 AI が生成するコードの量に比べ、製品や事業の成長に伸び悩みやリスクを感じられている場合ぜひ活用いただければ幸いです。