こんにちは！しょぼちむ（@syobochim）です。AWS Japanでアプリケーション開発のコンサルタントとしてお客様のシステム設計・開発をご支援しています。
ご支援の中で日々向き合っているのは、複雑なビジネスロジックを持つシステムの開発です。既存のシステムは古くて大きく、複雑で、誰も全体を把握できていない。現場の業務部門はそれぞれ担当しているプロセスを知っているものの、全体を見渡せる人は限られている。そんなプロジェクトで、生成AIを要件ヒアリング・設計・開発のプロセスに組み込む試行錯誤を続けています。
この記事で伝えたいのは、AI開発の質は「AIに何を渡すか」で大きく変わるということです。
そのために私たちの現場では、イベントストーミング（Event Storming）で人間同士の認識を揃え、その結果をKiroに渡すという進め方を試しています。
AIが速くなるほど、人間の「理解のボトルネック」が露わに
生成AIを活用した開発手法として、Vibe Codingに取り組んでいる方も多いと思います。プロトタイプやアイデア検証のように、つくり直しが容易でスピード重視の場面、生成AIを使いこなせる方が主導する開発、つくりたいもののイメージがある程度固まっている場面、細かい業務ルールをこれから決めていく段階など、Vibe Codingの方が速く進められる状況は確かにあります。一方で、現状のVibe Codingで生成したコードは品質の担保が難しく、そのまま本番環境で運用されるケースはまだ多くありません。Vibe Codingはプロトタイプや検証用途を中心に活用し、本番運用を見据えた開発では別のアプローチを組み合わせるのが現実的です。
一方で、チームで開発し、ビジネスサイドと合意しながら、一定の品質のものを継続的につくっていく場合は話が変わります。複雑なビジネスロジックを持つシステムでは、明確な仕様を定義してから設計・実装・テストへと進める「仕様駆動開発」のアプローチが有効です。仕様を起点にしてルールや成果物のイメージをビジネスサイドと合意しながら進めることで、AIの出力精度が上がり、人間は「何つくるか」に集中できます。
ただし、仕様駆動開発には前提があります。それは「仕様が明確であること」です。
複雑なビジネスロジックを持つシステムでは、この前提を満たすこと自体が難しいです。ステークホルダー間で業務理解や「こう改善したい」というイメージが異なり、開発者も、ビジネスサイドが本当に求めているものを十分に理解しないまま、手を動かしてしまうことがあります。結果として、実装後に「想定と違う」という大きな手戻りが発生します。ヒアリングをしても、そこで得られた理解を「テスト可能な要件」としてチーム全員で合意するまでには、まだまだギャップがあります。
AIによって開発の速度が上がった今、人間側の理解のボトルネックが以前より顕著に見えるようになってきました。AIに渡す要件がブレれば、以降の工程すべてに影響が出ます。仕様駆動開発で開発速度を上げるには、その手前の「要件の認識合わせをどう進めるか」が鍵になります。
この課題に対して、私たちの現場で特に有効だったのがイベントストーミングでした。
イベントストーミングで人間同士の認識を揃える
私がKiroと組み合わせて活用しているのがイベントストーミングです。ドメイン駆動設計（DDD）のプラクティスの一つで、色分けされた付箋を使い、業務プロセスを時系列で可視化するワークショップ手法です。
イベントストーミングには、ビジネス全体を俯瞰するBig Picture、業務フローを詳細化するProcess Modeling、実装に落とし込むDesign Levelの3つのレベルがあります。この記事で主に扱うのは、Process Modelingです。業務カテゴリごとの全体像はBig Pictureで押さえ、個別の業務フローの整理にはProcess Modelingを使います。
開発者とドメインエキスパートが集まって、「予約が作成された」「在庫が補充された」といった業務上の出来事（ドメインイベント）を付箋に書き出し、時系列に並べていきます。そこにコマンド（アクション）、ポリシー（ビジネスルール）、集約（関連するオブジェクトのまとまり）などを追加して、業務フロー全体を一枚の図として可視化します。
イベントストーミングにはAIを使っていません。ここでは、AIに整理してもらう前に、人間同士で業務の認識を合わせることを重視しています。イベントストーミングで人間同士の認識を合わせてから、Kiroに渡す。この順序を守ることが重要です。
とはいえ、人力でやるからこそ時間がかかるのも事実です。私がご支援している案件では、Kiroと組み合わせてからは、イベントストーミングの粒度を「イベント・アクター・ポリシーまで」に絞ることが増えました。集約などの細かい整理はKiroのDesignフェーズに譲り、イベントストーミングはチーム全員で業務の地図や認識を共有する場に集中させています。
以下は、図書予約の業務フローを簡略化して整理した例です。誰が関わり、どのイベントが起き、どこにルールや分岐があるのかを、チーム全員で見える形にしています。
Kiroで仕様駆動開発につなげる
イベントストーミングで整理した内容を渡す先が、AWSが提供するエージェント型AI統合開発環境「Kiro」です。エディタ（IDE）とCLIの両方で利用できます。
Kiroには2つのモードがあります。Vibe Codingのように対話しながら進める「Vibeモード」と、明確な仕様を定義してから段階的に進める「Specモード」です。どちらも使いますが、要件定義の主役はSpecモードです。Vibeモードは、Requirementsをもとに画面モックや状態遷移図などの補助ドキュメントを生成する場面で活用しています。
Specモードでは、以下の3つのドキュメントを順に生成しながら作業を進めます。
- requirements.md：要件定義（EARS (Easy Approach to Requirements Syntax) 形式で「WHEN〜THEN〜」の形で記述）
- design.md：設計ドキュメント（アーキテクチャ、ドメインモデル、プロパティベーステストなど）
- tasks.md：実装のタスクリスト
一気にコードを書くのではなく、プロセスが3つの段階に分かれることで、要件や設計がレビューしやすくなります。各段階で人間がレビューと修正を入れてから次に進められるので、認識のズレが積み重なる前に軌道修正できます。
たとえばRequirements生成では、ユーザーストーリーや受け入れ条件をつくるだけでなく、仕様として曖昧な点を質問として洗い出してくれます。
イベントストーミングとKiroは、どちらも「仕様をつくるため」のツールですが、担う役割が違います。イベントストーミングは人間同士で業務の認識を合わせる場、Kiroはその合意をテスト可能な要件に翻訳する相棒、という分担です。
この分担を守らないと、どうなるか。人間同士の合意ができていない状態でKiroに「要件をつくって」と頼むと、Kiroは足りない情報を推測で埋めてしまいます。出てくるRequirementsは一見それらしく整っているので、人が違和感に気づくのも難しい。そのまま先に進んで、後工程で「こんな要件、合意した覚えがない」というズレが発覚します。
先に人間が合意をつくり、それをKiroに渡す。この順序を守ることが、人間とAIでうまく役割分担するための土台になります。
「業務の地図」をつくるのが人間、翻訳するのがAI
ここからは、イベントストーミングとKiroをどう繋いでいくか、私のご支援している現場での進め方を紹介します。
全体の進め方は次のとおりです。
- イベントストーミング：業務フローの可視化・業務プロセスの理解
- Requirements生成（→
requirements.md）：Kiroで要件を生成 - 画面モックなどで認識合わせ：KiroのVibeモードでRequirementsを基に画面モックを作成し、ビジネス側と一緒に確認しながら認識を合わせる
- Design生成（→
design.md）：Kiroで設計ドキュメントの生成 - Tasks + Implementation（→
tasks.md）：Kiroでタスク分解と実装 - Business Review：全員で動作確認
ポイントは、各フェーズの間には必ず「人間によるレビュー」が入ることです。AIが生成したものをそのまま次のフェーズに流すのではなく、毎回立ち止まって確認します。Kiroも各ドキュメントを生成した後、次のフェーズに進む前に人間のレビューを待つようになっているので、この「立ち止まって確認する」流れがプロセスに自然に組み込まれます。
やってみてわかった、落とし穴と発見
ここからは、実際にこの進め方を続けるなかで見つけた工夫や、ハマった落とし穴をTipsとして紹介します。
役割と目的を最初にKiroへ渡す
Kiroに業務フローを入力する際、最初は業務プロセスの説明からいきなり始めていました。しかし、それだとKiroが生成するユーザーストーリーの精度がいまひとつでした。というのも、業務プロセスの説明だけでは、各ステークホルダーの目的や意図が明示されにくいからです。その結果、「利用者として、図書を検索したい」のような表面的なストーリーになりがちで、業務の目的や背景が反映されませんでした。
そこで、業務フローの説明に入る前に「この業務では誰がどんな役割で、何を実現したいのか」を先に伝えるようにしました。たとえば図書予約システムなら、こんな形です。
図書予約に出てくる役割は以下のとおりです。
利用者：読みたい本を、待たず・忘れず・確実に手に入れたい
図書館員：限られた蔵書を、公平かつ整合的に、自動で回したい
これを先に伝えてから業務フローを説明すると、Kiroが出すユーザーストーリーが「利用者として、読みたい本を確実に借りるために事前予約したい。これにより、貸出中でも本を取り逃さない」のように、目的と価値まで踏み込んだ形に変わります。業務の「なぜ」が入るかどうかで、この後の設計の深さが違ってきます。
イベントストーミングでも最初に「ステークホルダーと目的の列挙」を行いますが、その情報をKiroへの入力でも改めて明示的に渡しているわけです。イベントストーミングでの議論はKiroには届いていないので、前提を一度テキストに起こして渡す必要があります。このひと手間が、後続の要件全体の精度に大きく影響します。
RequirementsをSSOTにして、仕様のズレを防ぐ
requirements.md を「単一情報源（SSOT: Single Source of Truth）」として扱うことも重要です。すべての変更はRequirementsの修正を起点にし、そこから画面モック・設計・実装へ反映しています。
例えば、
- 画面モックをつくるとき：Kiroに直接「こういう画面をつくって」「ここを変更して」と指示せず、必ず
requirements.mdを読み込ませて生成する - 仕様変更が発生したとき：まず
requirements.mdを修正し、その後で設計・実装に反映する - レビューで指摘が出たとき：該当箇所を
requirements.mdまで遡って修正する。もしくは別のrequirements.mdを作成する。
これにより、ビジネスサイドと合意した requirements.md や画面モックと、最終的な成果物の仕様が食い違いにくくなります。
なお、Kiroには「Hook機能」があり、requirements.mdの保存をトリガーに用語の不整合や業務フローの矛盾を自動でチェックさせることもできます。私は業務を跨った要件や言葉の不整合がないかをHook機能を使ってチェックしています。
画面モックを出すと、「ここが違う」が見えてくる
画面モックは、テキストのRequirementsだけでは見えない認識のズレを明らかにしてくれます。
Requirementsを生成した後、すべての受け入れ条件をビジネスサイドと読み合わせているのですが、テキストの要件だけだと、どういった成果物ができるのかがいまいち想像しにくいです。そこで、KiroのVibeモードでHTMLファイルの画面モックを作成し、読み合わせと一緒に確認しています。そうすると、「ここは違う」「この項目が足りない」と具体的なフィードバックが出てきます。テキストだけを見せていたときは「なんとなくわかった」と見過ごされていた曖昧さが、画面になると急に具体化して見えてきます。
ただし、こんな落とし穴もあります。
- Kiroが画面モックを必要以上につくり込んでしまう（JSファイルをたくさんつくる）：ディスカッション中のアップデートに時間がかかったり、画面が正しく開かなかったりして、進行を阻害します
- ビジネス側がデザインの細部（色、フォント、レイアウト）に注目してしまう：「ボタンの色をもう少し濃くして」といった話になり、本来の目的「機能や業務フローの認識合わせ」から脱線します
そのため、画面モックをつくる際は「HTMLを1ファイルだけでつくって」とKiroに指示し、かつビジネスサイドにも「これは最終デザインではなく、機能の確認用です」と必ず前置きするようにしています。1ファイルに絞ることで、会議に参加していなかったメンバーにもファイルをそのまま共有でき、使い方のイメージを手軽に伝えられるという副次効果もありました。
2割の業務プロセスが、Requirementsに入っていなかった
Requirementsがある程度まとまったら、Big PictureやProcess Modelingで整理した図に戻り、業務フロー全体をカバーできているかを検証しています。
実際にやってみると、テキストベースのRequirementsだけでは個々の要件は詳細に書けても、業務フロー全体の抜け漏れに気づきにくいことがわかりました。イベントストーミングのビジュアルを使ってRequirementsと付き合わせることで、考慮漏れを発見できます。
あるプロジェクトでは、「これでしっかり要件をRequirementsに整理できたね！」と全員が達成感を感じていたにもかかわらず、この照合をやってみると約2割の業務プロセスがRequirementsに取り込まれていないことがわかりました。特に業務上の例外ケースなどでそういった漏れが起こりやすく、テキストだけを追っていたら、気づけなかったと思います。結局、どこが漏れていたのかをチェックし、その２割も後からRequirementsに整理をすることになりました。
AIに任せると、部分最適の粒度では綺麗にまとまっているように見えてしまいますが、全体像に戻って確認する時間を意図的に取ることが、とても重要だと学びました。
集約まで人間が出さない選択肢もある
イベントストーミングの教科書的な進め方では、最終的に集約（Aggregate）を特定するところまで行います。私がご支援しているプロジェクトでは、最近それを思い切って省いています。
Kiroが生成するRequirementsは、業務ルールや状態遷移をEARS形式で表現してくれます。さらにDesignフェーズではドメインモデル（集約、値オブジェクト）も生成してくれます。そのため、付箋で集約を議論していた場面を、Kiroが生成したRequirementsやDesignをレビューする形に置き換えています。ワークショップの時間が半分以下に短縮され、実務上もメリットが大きいです。
これがイベントストーミングの正解というわけではなく、あくまで私が関わっているプロジェクトでの実践例です。チームやプロジェクトによっては、集約まで付箋で議論した方が良い場面もあると思います。AIとどこまで分担するかは、その都度、見極めていく必要があると感じています。
AIと一緒に設計するには、人間同士の認識合わせと合意が大切
この記事で紹介したプロセスは、まだまだ試行錯誤中です。プロジェクトの特性やチームの状況によって、最適なやり方は変わります。
そんな試行錯誤のなかで感じているのは、AIに任せる部分と人間が判断する部分の線引きが、開発の質を決めるということです。
AIに任せられること：
- 要件・設計の整理と構造化（Requirements、Design、Tasks）
- ドキュメントと実装の連動
人間が判断すべきこと：
- ビジネスの優先順位
- ドメイン知識の正確性
- アーキテクチャの戦略的選択
業務の全体像を理解し、何を仕様としてAIに渡すべきかを判断する力があれば、AIの速度をうまく活かせるようになり、開発の効率は大きく上がります。要件定義・設計が明確なら、AIが大部分を実装してくれますし、レビューの負荷も軽くなります。逆に、設計の力がないままAIに丸投げしても、良いものにはなりません。
ここでいう「設計する力」は、業務要件を仕様に落とす力だけではありません。可読性やテスト容易性の高い実装を導くためのスキル、動かすためのアーキテクチャやインフラ構成、デプロイの自動化、オブザーバビリティの設計まで含まれます。特にクラウド上でシステムを運用することが当たり前になった今、クラウドのサービスを有効に活用するスキルも、AI時代の「設計する力」の大切な要素です。AIが実装のスピードを上げてくれるからこそ、運用まで見据えた設計を描ける人間の役割は、より重要になっています。もちろん、これらを一人で全部抱える必要はなく、チームで得意を持ち寄って補い合えば十分です。
そして、これら幅広い設計判断のどれもが、「この業務で何を実現したいのか」という土台の上に成り立っています。業務の全体像が見えていなければ、どのアーキテクチャが適切かも、どこにオブザーバビリティを効かせるべきかも判断できません。つまり、「設計する力」の出発点は、業務の全体像を理解することにあります。業務が見えていないと、AIに何を渡せばいいかもわかりません。だからこそ、イベントストーミングで業務を可視化し、ステークホルダー全員で共通理解をつくることが重要です。そこから始めれば、AIに渡すインプットの質が自然と上がり、AIの出力精度も向上します。
「AIに任せる」ではなく「AIと一緒に設計する」。その第一歩は、人間同士の認識合わせから始まります。ぜひ、イベントストーミングやKiroを活用いただき、皆様の開発ライフがより良いものになれば幸いです！