AI駆動開発時代、要件定義はどう変わる？思考支援AIとau PAYアプリ開発チームの実践｜第10回エンタープライズDXセミナーより

レポート生成AI ウェビナー事例

11日前

Graat セミナー事務局

2026年6月24日、Graatは「第10回エンタープライズDXセミナー」を開催しました。

今回のテーマは、「AI駆動開発時代に求められる『要件定義』とは？」。

生成AIやAIエージェントの活用によってソフトウェア開発の効率化が進む一方、開発の起点となる要件定義では、情報の抜け漏れや認識のずれ、担当者への知識の偏りといった課題があります。

本セミナーでは、AIに作業を代行させるだけでなく、人の思考や判断を支援する「思考支援モード」の考え方と、KDDI株式会社のau PAYアプリ開発チームで進められているAIを活用した要件定義の取り組みを紹介しました。

後半のパネルトークでは、実際にAIを活用する中で生まれた変化や、AIエージェントの育成、人とAIの役割分担、AI駆動開発時代における要件定義のあり方について意見を交わしました。

― 本記事の構成

▹ AIに「作業を任せる」だけでなく、「考えること」を支援する
▹ 人とAIがともに成長する「EBAAD」
▹ au PAYアプリ開発チームで進める、AIを活用した要件定義
▹ 有識者の知識を組み込んだ「バックログ作成支援システム」
▹ AIがバックログを作るだけではない――複数の視点から要件を評価

現場で使って見えてきた、AIと要件定義のこれから－パネルトーク

▹ まとめ

AIに「作業を任せる」だけでなく、「考えること」を支援する

はじめに、Graat代表の鈴木雄介より、生成AIを活用する際の一般的なプロセスについて紹介しました。

生成AIを使って成果物を作る際には、まず「どのようなプロンプトを与えるか」「どのようなコンテキストを準備するか」といった準備を行い、その上でAIに生成を依頼します。

さらに、生成されたものをそのまま成果物とするのではなく、内容の良し悪しや不足している点を人が評価し、必要に応じて再生成したり、人自身が手を加えたりしながら調整します。

このように、「準備 → 生成 → 評価 → 調整」というサイクルを繰り返しながら成果物を作ることが、一般的な生成AIの使い方です。

スライド08

では、このプロセスの中でAIに何を担わせるのか。

Graatでは、AIの使い方を「作業代行モード」と「思考支援モード」の2つに整理しています。

「作業代行モード」は、人が指示を出し、AIが作業を代わりに実行する使い方です。一方、「思考支援モード」では、人が「判断」や「思考」に集中できるよう、AIがそのための「準備」や「評価」を支援します。

たとえば、判断に必要な情報をAIが準備したり、人が考えた内容を異なる観点から評価したりすることで、人自身が考えながら仕事を進めることができます。

さらに、この2つのモードを状況に応じて使い分けながら、仕事の進め方そのものをガイドするのが「ガイド型AIエージェント」です。

人とAIがともに成長する「EBAAD」

ガイド型AIエージェントの活用は、業務の効率化だけでなく、組織における知識継承や人材育成にもつながります。

熟練者が持つ暗黙知を形式知化し、AIエージェントに蓄積することで、経験の浅いメンバーもAIの支援を受けながら仕事を進めることができます。

また、AIを活用して仕事をする中で得られた知識や経験をフィードバックすることで、AIエージェント側にも組織の知識が蓄積されていきます。

スライド09

このように、人がAIを育て、AIが人の成長を支援する循環を通じて、人とAIの双方を成長させていく考え方が「EBAAD（Experience Based AI-Agent Development）」です。

EBAADでは、人に蓄積される知識や経験、判断力などの「人的資本」に加えて、AIシステムに蓄積される能力を「トークン資本」と捉えます。

スライド10

人が持つ知識や判断基準、業務の文脈をAIへ与えてトークン資本を高め、成長したAIが人の作業や学習、判断を支援することで、人的資本も高めていく。

こうした相互作用を継続的に生み出し、人とAIがともに成長する仕組みを構築することを目指しています。

au PAYアプリ開発チームで進める、AIを活用した要件定義

続いて、EBAADを活用したau PAYアプリ開発チームでの取り組みが紹介されました。

au PAYアプリ開発チームでは、まずワークショップを通じてAIを体験し、組織の中でどのように活用できるかを検討しました。その後、開発プロセスを可視化しながら、「どこにAIが効果を発揮するか」という観点で適用箇所を整理しました。

その中で選ばれたのが、開発の上流に位置する要件定義です。

AI駆動開発によって設計や実装など後工程の自動化が進むほど、その起点となる要件の品質が後工程にも大きく影響します。そこでau PAYアプリ開発チームでは、要件定義をより高度化することで後工程の品質向上につなげることを目指し、AIによる要件定義支援に取り組みました。

有識者の知識を組み込んだ「バックログ作成支援システム」

こうした検討をもとに開発されたのが、内製アジャイルにおける要件定義を支援する「バックログ作成支援システム」です。

このシステムでは、有識者がどのように要件定義を進めているのかを「仕事の型」としてワークフローに落とし込み、システムの概要や仕様書、関連図など、要件定義に必要なドメイン知識をAIから参照できるようにしています。

メンバーは専用UIを通じてAIと対話しながら要件を整理し、バックログを作成します。画面上でどのような情報を確認し、どのような順序で判断するのかというプロセスにも、有識者のノウハウが組み込まれています。

作成したバックログはJiraと連携し、そのまま実際の開発プロセスへつなげることもできます。

スライド13

AIがバックログを作るだけではない――複数の視点から要件を評価

デモでは、実際の画面を操作しながら、AIとの対話を通じてバックログを作成していく流れが紹介されました。

画面遷移やAIとの具体的なやり取りについては、以下のスライドもあわせてご覧ください。

au PAYに学ぶ、AI駆動開発を支える『AI要件定義』の実践 - Graat エンタープライズDXセミナー from Graat（グラーツ）

デモで取り上げたのは、au PAYアプリのHOME面に新しいボタンを追加するケースです。

実現したい内容を入力すると、AIから要件を具体化するための質問が提示されます。利用者はその質問に答えながら、必要な情報や条件を整理します。

情報が揃うと、それまでのやり取りをもとにAIがバックログを生成します。しかし、このシステムは生成して終わりではありません。

作成されたバックログに対して、異なる役割を持つ複数のAIエージェントが、それぞれの立場から内容を評価します。
たとえばテストの観点などからフィードバックを提示することで、起案者自身では気づかなかった要件の抜け漏れや、新たな検討事項に気づくきっかけを作ります。

利用者はAIからの評価を確認し、必要に応じて内容を修正した上で、完成したバックログをJiraへ連携します。

これは、前半で紹介した「思考支援モード」を要件定義に適用した例でもあります。 AIがバックログ作成を単に代行するのではなく、準備や評価を支援しながら、人自身に判断を促します。

また、このシステムでは、人間だけでなくAIにとっても理解しやすいバックログを作成することが意識されています。後続のAI駆動開発へつなげることを前提に要件を整理することで、その後の設計や実装における生成精度を高めることも狙いの一つです。

現場で使って見えてきた、AIと要件定義のこれから－パネルトーク

では、この仕組みを実際の開発現場で使うことで、要件定義やチームの仕事にはどのような変化が生まれたのでしょうか。

ここからは、KDDIの打田氏、枝川氏と、Graat鈴木によるパネルトークの内容をご紹介します。

AIによる事前評価が、要件の精度とチームの議論を変える

バックログ作成支援システムを実際に利用する中で、要件そのものだけでなく、チーム内のコミュニケーションにも変化が生まれています。

枝川氏は、アプリ開発者や将来の保守担当者など、複数の立場からAIが要件を評価することで、起案者一人では気づかなかった観点をPBI（プロダクトバックログアイテム）に盛り込めるようになった点を挙げました。加えて、PBIの作成にかかる時間も、従来と比べて削減できたといいます。

これについて鈴木は、AIによる「作業代行」と、異なる立場からの「評価」を組み合わせることが、バックログの精度向上につながっていると説明しました。

一方、打田氏は、導入前には「組織固有のやり方やドメイン知識を、AIがどこまでバックログへ反映できるのか」という懸念があったと振り返りました。
今回のシステムには、KDDIでのバックログの作り方や、これまで暗黙知となっていたノウハウも組み込まれています。実際に利用することで導入前の懸念は解消され、組織のやり方に沿ったバックログを作成できる手応えを感じたといいます。また、自身が気になっていた部分をAIからも指摘されたことで、自分の考えを確認でき、自信や成長にもつながったと話しました。

打田氏は、au PAYアプリ開発チームで行われている「リファイメント」での変化も挙げました。リファイメントでは、ビジネス側が作成したバックログをもとに、開発者とともに仕様を具体化します。バックログ作成支援システムを利用することで、事前に「なぜこれを作りたいのか」という根本的な部分まで考えた上でバックログを持ち込めるようになりました。仕様だけでなく、その背景や目的についても話せるようになり、リファイメントでの議論の質も高まったといいます。

枝川氏は、POと開発者のコミュニケーションという観点から変化を振り返りました。バックログを起票するPOやビジネス側と、実際に開発を行うエンジニアでは、必要とする情報や着目するポイントが異なります。バックログ作成支援システムでは、AIが開発者などの視点から要件を評価することで、PO自身が事前に不足している観点へ気づくことができ、開発者の視点を学ぶ機会にもなっています。
また、リファイメントで不足している情報を確認するためのやり取りが減り、その分、本質的な議論により多くの時間を使えるようになったことも、変化の一つとして挙げました。

AIエージェントは、使うチームの中で育てていく

バックログ作成支援システムでは、専用システムとして構築することによる使いやすさに加え、実際に利用しながらAIエージェントを育てていくことも重視されています。

枝川氏が専用システムのメリットとして挙げたのは、非エンジニアでも利用できることです。Claude CodeなどのAIツールを使い、複数の観点から要件を評価させること自体は可能ですが、バックログ作成支援システムでは専用のUIを含めて構築することで、非エンジニアでも利用できるようにしています。

打田氏は、AIエージェントを育てていくという観点からメリットを挙げました。作成したバックログから実際にどのような成果物ができたのかをフィードバックし、次に作るものへ活かすことができます。また、過去の経緯や要件が作られた背景をAIがコンテキストとして持った状態で次の要件を扱うことで、より良い生成につなげていくこともできます。

AIエージェントの維持や改善には、実際にシステムを利用するメンバーも関わっています。バックログ作成支援システムの改善には、所属グループ内でAI活用に取り組むメンバーの一部が参加し、枝川氏や打田氏も改善提案を行っています。au PAY for BIZでは、POも交えて機能改善を検討する機会を定期的に設けており、実際に利用するビジネス側のメンバーも巻き込みながら取り組んでいます。

これについて鈴木は、AIエージェントの維持や育成を特別な活動として切り離すのではなく、チームの日々の活動の一つとして組み込んでいる形になっていると整理しました。

こうした形が最初からできていたわけではありません。
導入当初は、枝川氏や打田氏がPO向けに説明会を行い、まずシステムを知ってもらい、実際に使いながら理解してもらうところから始めました。そうした活動を通じて徐々にチームへ浸透し、現在の形へと整えていきました。

一方で、AIに組織の知識を組み込むためには、人が担う部分も残っています。
枝川氏は、現在のAIは生成したものをそのまま成果物として採用できる段階にはまだ至っていないと話しました。人が追加の指示を出したり、AIに相談したりしながら内容を調整しており、複数の立場から要件を評価するAIエージェントの観点をチューニングすることも、人が担っています。

打田氏がシステムを構築する中で特に難しかった点として挙げたのは、組織が持つノウハウをバックログ作成の過程としてワークフローへ落とし込むことでした。このワークフローは、KDDIとGraatが協力しながら構築しています。

AIから参照できる情報の整備も進められています。au PAY for BIZでは、以前Excelで整備していた仕様書をMarkdown形式へ移行し、RAGへアップロードできる形式に合わせています。一方、システム関連図やプロセスフロー図、アプリの画面キャプチャなど、画像として持っている情報については、AIに利用させたいものの、現時点ではまだ実現できていない部分もあります。

AIエージェントの育成が「手離れ」する段階には、まだ至っていません。
打田氏は今後、作成したバックログから開発されたものが実際にどのように使われ、どれくらい利用されているのかというデータを、次のバックログ作成に活用したいと話しました。実際の利用状況を数値として取り込み、次の作成にフィードバックする流れを回すことで、バックログの精度をさらに高めていく考えです。

AI駆動開発の定着には、ツールだけでなく使い方を身につけるプロセスが必要

AI駆動開発を既存の開発パートナーとどのように進めていくかという点も、パネルトークのテーマとなりました。

AIを活用して開発を効率化すれば、開発に必要な工数の削減にもつながります。一方、工数をベースとした契約では、効率化が開発パートナーにとって必ずしもメリットになるとは限りません。

枝川氏は、難しい課題であるとした上で、まずAIを使うことに慣れてもらう必要があると話しました。
KDDIではGitHub CopilotやClaude CodeなどのAIツールを開発パートナーへ提供しているものの、現状では利用率が十分に高くないという課題があるといいます。そこで今後は、KDDIの社員自身が開発の中に入り、開発パートナーと一緒にモブワークを行うことを検討しています。AI駆動開発のプロセスに沿って並走しながら、AIを活用した開発そのものに慣れてもらう考えです。

AI駆動開発によるコスト削減についても、単純にAIツールを導入すれば効果が得られるわけではありません。
枝川氏は、コスト削減と品質向上のどちらを実感できるかは「作業者による」と話しました。
開発者のスキルセットによっては、AIが生成した成果物の品質が十分ではなく、かえってレビューする側の負担が増えることもあります。これは、一見それらしい成果物が作られる一方、その確認や修正によって周囲の負担が増える「ワークスロップ」の問題にもつながります。
こうした課題に対して、開発者のスキルセットによらず一定水準以上のアウトプットを得られるよう、AIの利用を支える「ハーネス」を組み込んだ開発プロセスを作ることも検討されています。

開発をベンダーへ委託している場合について、
枝川氏は、委託元とベンダーが協力してAI駆動開発に取り組み、その成果を双方のメリットにつなげる方法を一つのアイデアとして挙げました。
たとえば、AI駆動開発によってどれだけ効率化できたのかを共同で検証し、その成果を対外的に発表できれば、ベンダーにとってもAI駆動開発の実績となり、新たな受注につながる可能性があります。AI駆動開発が今後避けて通れないものになるのであれば、ベンダー側にも取り組むインセンティブを作ることが、一つの方法ではないかと話しました。

鈴木は、今回の取り組みを通じて、要件定義をAIで支援し内容を充実させることで、その後のAI駆動開発自体も良くなっていくことを体感したと振り返りました。

AI駆動開発時代は、要件定義と人材育成の重要性も高まる

AIを使った開発の今後についても、さまざまな意見が交わされました。

打田氏は若手エンジニアの立場から、AIの活用が若手の育成につながることへの期待を挙げました。
バックログ作成支援システムを使うことで、知識が十分にない状態でも、自分だけでは気づかなかった視点や、さまざまな観点からのアドバイスを得ることができます。そうした経験が自身の知識となり、要件定義だけでなく、AI駆動開発における若手の育成にもつながる可能性があります。
また、バックログを作成する際に先輩へ相談することが難しい場合でも、AIを気軽に相談できる相手として利用できます。

鈴木は、要件定義は教科書で学ぶだけでなく、実践の中で身につけることが重要であり、その進め方をAIがガイドすることの意義にも触れました。AIが事前に内容をある程度整理することで、相談する側だけでなく、レビューする先輩側の負担も軽減され、コミュニケーションの改善にもつながります。

枝川氏は、今後のAI駆動開発では要件定義そのものの重要性も高まると話しました。仕様駆動開発やインテント駆動開発といった開発プロセスが主流になっていく中では、あらかじめ仕様をどれだけ詰められるかが、これまで以上に重要になります。こうした背景から、バックログ作成支援システムのようなツールを活用して要件定義の精度を高めることも、今後ますます必要になってきます。

まとめ

今回のセミナーでは、AIに作業を任せる「作業代行モード」と、人が考えることをAIが支援する「思考支援モード」、Graatが提唱する「EBAAD」、そしてau PAYアプリ開発チームで取り組んでいるバックログ作成支援システムについて紹介しました。

パネルトークでは、システムを利用して感じた効果や、チームのコミュニケーションの変化、AIエージェントを育てる体制、AI駆動開発を進める上での課題など、実践を通じて見えてきたテーマについてお話ししました。

Graatでは、生成AIをはじめ、アジャイルやサービスデザインなど、さまざまなアプローチを通じて、DXを推進するための組織・チームづくりを支援しています。
今回の内容にご興味をお持ちいただいた方や、自社での取り組みについてお悩みの方は、ぜひお気軽にお問い合わせください。

最後に、ご参加いただいた皆さま、ありがとうございました。また、ご登壇いただいたKDDI株式会社の打田将吾氏、枝川廉氏にも、改めて御礼申し上げます。