AIが進め、人が決める ― AI駆動開発の本当のボトルネックはどこにあったか

こんにちは。AWS ソリューションアーキテクトの崔 祐碩（Woosuk Choi）です。AI 開発を進めている多くのお客様から「開発を加速したい」というご相談をいただいています。お客様と議論を重ねるたびに、本当のボトルネックは開発そのものではなく、意思決定をめぐるプロセスと組織ではないか、と感じることが増えてきました。本ブログでは、2026年7月29日に MBK Wellness 株式会社と実施した AI-DLC ワークショップを題材に、私たちがこの仮説をどう確かめ、どんな答えが返ってきたのかをご紹介します。

MBK Wellness 株式会社について

MBK Wellness 株式会社は、三井物産グループのウェルネス企業です。1946年に創業した保健同人社をルーツに持ち、2025年8月にグループ4社が合併して現在の体制となり、健康経営支援・EAP（従業員支援プログラム）、企業研修・人材育成、人材紹介という、人的資本に関わる3つの事業を1社で展開しています。

新しいサービスを立ち上げたいという意欲はきわめて高く、その一方で、性格の異なる3つの事業本部が並ぶ構造となったことで、部門をまたぐ調整に時間がかかるという、統合企業ならではの悩みも抱えていらっしゃいました。

ワークショップのきっかけは、社長付の古屋 和樹氏からいただいた「開発と組織を、AI で Empower したい」というご相談でした。特定の AI ツールを導入したい、というお話ではなく、開発の進め方そのものと、それを取り巻く組織のあり方を、あわせて変えていきたい。そういうご相談でした。

では、何から手をつけるのがよいか。議論を重ね、経営層の役員とビジネス側のリーダーを交えて実際に体験していただくほうが早い、という結論に至りました。こうして実施したのが、AI-DLC（AI-Driven Development Lifecycle）を1日で体験するワークショップです。

なぜ、経営層に加わっていただいたのか

ご相談が「開発」だけでなく「組織」も含んでいたことが、この設計の理由です。開発チームだけを速くしても、プロダクトやサービスの開発はなかなか速くなりません。理由は技術の外側、つまり部署をまたぐ意思決定の側にあります。開発チームだけではサービスの仕様やビジネスへのインパクトを判断できず、待つしかないのです。AI によって開発のアウトプットが速くなっても、既存のワークスタイルのままでは全体は速くなりません。組織間の連携プロセスを改革し、AI 開発に合ったワークスタイルへ変えていく。ここに経営層が向き合っていただかなければ、この課題は解けません。

これは私たちだけの考えではありません。AWS の AI-Driven Development Lifecycle for Financial Services でも、AI-DLC 導入の第1フェーズを Executive Alignment と位置づけ、「Without executive sponsorship, transformation stalls at the pilot stage（経営層の後押しがなければ、変革は試行段階で止まる）」と述べています。

AI-DLC とは何か ― AI が進め、人が決める

AI-DLC は、AI を前提にソフトウェア開発のライフサイクルを組み直す方法論です。全体は Inception（意図の詳細化と計画）、Construction（設計・実装・テスト）、Operation（デプロイと運用）という3つのフェーズで構成され、各ステージの成果物がそのまま次のステージの入力になっていきます。

図1: AI-DLC の3フェーズ。Inception・Construction・Operation の各ステージが、次のステージのためにより豊かなコンテキストを積み上げていく

そして、この流れを回すうえでのポイントが役割分担です。プランニング、タスク分解、アーキテクチャの提案といった実行は AI が担い、検証・意思決定・監督の最終責任は人間が持ち続けます。AI にすべてを任せるのでも、コーディングだけを AI に切り出すのでもありません。

もうひとつの特徴が、Mob Elaboration と Mob Construction という進め方です。要件の詳細化も実装も、関係者が同じ場に集まって AI の出力をその場でレビューし、その場で決めていきます。集まるのは開発者だけではなく、ビジネスのステークホルダーも含まれます。経営や事業部門の方に加わっていただく設計は、この方法論とよく合っていました。実装には Claude Code と、AWS が OSS として公開している awslabs/aidlc-workflows（当日は v1.0.1）を使いました。aidlc-workflows は、Claude Code のほかにも、AWS の Kiro などさまざまなコーディングエージェントで使えます。

そして、ワークショップの冒頭で私たちからお伝えしたのが、このメッセージです。

図2: 本ワークショップの中核メッセージ

AI を使えば、開発のアウトプットは速くできます。けれども、開発チームの外との意思決定が速くならなければ、スピードはそこで頭打ちになってしまいます。本丸はツールの導入ではなく、組織全体の意思決定のスピードと、そのカルチャーをどう変えていくか。これが、私たちがこの日いちばんお伝えしたかったことでした。

1日で何が起きたか

MBK Wellness からは、役員4名を含め、開発と各事業部門のステークホルダー22名にご参加いただきました。AWS からは3名が入っています。この22名を4つのグループに分け、それぞれに役員1名と、エンジニア・非エンジニアの双方が混在する形にしました。PC を操作するドライバーは開発部のメンバーが務め、事業部門の方と役員がその画面を一緒に見ながら議論しました。

ワークショップの様子。各テーブルでドライバーが AI とやりとりし、その画面を全員で見ながらレビューしていく

1日という限られた時間を有効に使うため、体験は Inception にフォーカスしました。プロンプトを投げ、AI が返してきた要件定義を組でレビューし、足りないところを指摘して書き直させる。この往復を役員の方に目の前で見ていただく、というのがねらいです。

題材選びも、より実感を持っていただくために、練習用のサンプル課題ではなく各チームが現在検討している実案件を持ち込んでいただきました。結果として、4チームがそれぞれ自分たちの事業領域のテーマを扱うことになりました。

• A チーム: 健康相談サービスの相談体験の改善。蓄積された Q&A は毎日更新されているのに、利用者から質問を投稿する導線が存在せず、受け身のまま読み終わっている、という課題
• B チーム: 人材紹介における候補者マッチング。応募者が自分の経歴を入力すると、AI が「職能」を読み取り、業種・職種を越えて求人と担当コンサルタントを提案する
• C チーム: 新人向けの社員研修システム
• D チーム: 管理職向けの育成支援。現場で残したメモから、部下への関わり方の変化を可視化する

午後はその先へ進み、Inception で作ったドキュメントをそのまま入力に使い、モックアップを作るところまで「AIが進め、人が決める」を続けていただきました。最後には各チームが構想するサービスのコンセプトと意図が伝わるモックアップが動く状態になり、そのまま発表とデモを行いました。

各チームの発表。モックアップが完成し、実物を確認しながら開発を進めたことで、事業部門の参加者の理解が深まった

「AIが進め、人が決める」が実際に起きた瞬間

1日という短い時間ではありましたが、各チームは想像以上に進みました。ここで素晴らしい成果を紹介させてください。A チームは要件定義からモック実装までを1日で終えました。

ただ、いちばん印象に残ったのは、進んだ作業量ではありません。このチームで起きた方針転換です。

実装を検討する段階で、連携先の API が読み取り専用であることが判明しました。つまり、利用者に質問を書いてもらっても、それを保存する先がない。企画の土台にあった「投稿してもらう」という前提が、そこで消えたわけです。

ここでチームが出した判断が見事でした。企画の方向性はそのままにして、手段だけを変えたのです。「書いて投稿してもらう」のをやめ、AI チャットが対話で相談内容を聞き取り、すでに蓄積されている回答から近いものを探して示す。それでも解決しなければ既存のサービスにつなぐ、という仕様に組み替えました。

ビジネス上の意思決定がその場で行われ、素早い方向転換につながったわけです。要件は AI が差分改訂にとどめ、ユーザーストーリー以降を再実行してくれるので、変更後の姿をその場で確認しながら判断できました。報告資料には、こう書かれていました。

手戻りが、手順として用意されている ― API の制約で方針転換が必要になったとき、要件を差分改訂してストーリー以降を再実行、という道筋が示されました。巻き戻しが例外扱いされていません。

AI が計画と実装を進め、前提が崩れたときには人間が「何のためのサービスか」を守って手段を選び直す。私たちが朝にお伝えした「AIが進め、人が決める」が、その日の午後に実際の出来事として起きていました。

手応えは、翌日届いた一通のメールに表れていた

ワークショップの翌日、代表取締役社長の森田 剛至氏から一通の返信をいただきました。

私自身は午前中だけの参加でしたが、目から鱗が何枚も落ちている自分に気付き、曇っていた視界が急に明るくなった気持ちでした。様々な気付きを頂いたと思っております。

— MBK Wellness 株式会社 代表取締役社長 森田 剛至氏

午前の参加だけで、経営トップの見方が変わった。役員に各グループへ加わっていただいた理由は、この一通に集約されていると思います。当日も、役員の方からこんなコメントをいただいていました。

よい体験。AI の成果物には感心した。これからの変化を実感。AI 導入のためには、組織・プロセス・カルチャーの多方面での変更が必須。

— ご参加いただいた役員の方のコメント

手応えは、経営層だけのものではありませんでした。事業側の参加者からは、次のコメントをいただいています。

開発とやりとりしながら作れ、AI による成果物がすぐ確認できてイメージしやすかった。すぐ作れるので、あまり遠慮しなくなった（今までは、頼むこと自体を躊躇するケースが多かった）。

— 事業部門の参加者コメント

開発の速さというより、依頼のコストが下がったという話だと受け止めています。「作ってほしい」とお願いすること自体の心理的な重さが、本来生まれるはずのアイデアを社内で止めていた。目の前ですぐ形になる様子を見て、その重さが下がったわけです。

そして開発側では、先ほど引用した報告資料に、この日の学びとして次の3点が挙げられていました。

決めるべきことが、先に出てくる ― AI は曖昧なまま進まず、選択式で問いを投げてきます。「何を作らないか」を最初に決めきれたのは、この問いのおかげでした。

成果物が、そのまま次の入力になる ― ストーリーの受け入れ基準項目が、そのままテストの合格条件になりました。文書が捨てられません。

人間の仕事は、承認と判断に寄る ― コードを書く時間より、提示された選択肢を判断する時間のほうが長い。判断の質がそのまま成果物の質になります。

— 成果報告資料より

見えてきたボトルネックは、技術ではなく意思決定だった

アンケートでは「AI-DLC を社内で活用するために解決すべき課題」も自由記述で伺いました。すると、回答の多くが同じ方向の問題意識を挙げてきました。組織・意思決定・権限にかかわる課題です。一方で、技術的な課題の指摘は1件もありませんでした。「ツールが使いにくい」「環境構築が大変」といった声が、ひとつも出てこなかったのです。もっとも、開発環境は古屋氏が事前に検証を済ませており、範囲もモックアップまででした。技術面のつまずきが表に出にくい条件だったのは確かです。

何度も話にも出てましたが、意思決定できる人を確保することができないとスピーディーさの恩恵は受けれないのかなと思うので、AI-DLC を活用するためにはまずそこがクリアになるようなスケジュール調整やメンバー構成が必要になると思いました。

組織設計からの見直しが必要。

— 参加者アンケートの自由記述より

クロージングのディスカッションでも、参加者からこんな趣旨の言葉が出てきました。

短時間であっても、異なる部門が集まって要件を議論することで、出来上がるサービスの質が高まる。

AI 駆動開発の時代においては、人間がいかに評価し、判断するかの仕組みを考えることが重要である。

— クロージングでの参加者の発言

朝いちばんに私たちからお伝えしたことが、1日を経て、参加者ご自身の言葉になって返ってきた。このワークショップの到達点は、ここだったように思います。

では、その「評価し、判断する仕組み」は、実務のどこで詰まるのか。当日のディスカッションでは、その構造にまで踏み込みました。参加者の実感といちばん重なったのが、開発で起きる部署間のやり取りでした。例えば、ロケーションデータを地図に連携したいという1つの変更でも、図3の例のように、セキュリティ、データガバナンス、法務・コンプライアンスへと確認が順に連鎖していきます。

図3: 開発中の変更をめぐる部署間のやり取りの例。逐次・連鎖型の波及では、並列に相談できれば最長1部署分で済む待ちが、部署数ぶんの足し算になる

実務では、仕様変更や突発的な追加・確認が次々と発生し、影響範囲が最初から見えているとは限りません。かといって、すべての関係者とその領域の意思決定者を毎回巻き込んでプロジェクトを進めるのも現実的ではありません。必要なのは、関係や依存が判明したタイミングで、素早くコンテキストを確認して意思決定できる柔軟な組織体制です。

次の一歩と、AWS への期待

その柔軟な組織体制を、MBK Wellness は実際に作りにいくことを決めました。ワークショップの後、組織そのものを見直す方向で議論が始まり、森田氏の判断のもと、下期に向けた検討が動き出しています。テーマは意思決定権限の委譲と組織のフラット化、そしてプロジェクトベースの運用です。「決められる人」と「作るもの」をどう設計していくか、という問いに向き合っています。

具体的な論点は3つに整理されています。この体制で必要になる人材像はどのようなものか。開発のポジションを組織のどこに置くか。そして、この変更を社員にどう伝えるか。技術の話ではなく、組織と人の設計の話です。

先ほどの森田氏のメールには、もうひとつ、こう書き添えられていました。「引き続き古屋を窓口に色々とご指南頂ければ」。窓口を明確にしたうえで、継続してご一緒したいというお言葉です。私たちにとって、これ以上のものはありません。

AWS からは、開発プロセスに関するさまざまなナレッジを共有しつつ、実際の開発を MBK Wellness の新しい開発体制に合わせて進めていきます。AI-DLC の効果を最大限に発揮していただけるよう、技術とカルチャーの両面から支援を強化していく予定です。

ワークショップ終了後の MBK Wellness の皆様と AWS チーム

著者