要件定義にAIを入れると、何が変わるのか
生成AIで議事録を整理する。要件定義書のたたき台を作らせる。どちらも、以前よりずっと手軽になりました。ただ、実際の案件で使おうとすると、「どこまでAIに任せてよいのか」「AIが書いた要件を、誰がどう確かめるのか」で手が止まります。
要件定義には、顧客の要望を聞き取るだけでなく、既存システムの仕様や業務上の制約を調べ、関係者が何に合意したかを整理する仕事があります。資料をきれいにまとめても、必要な条件が抜けていたり、関係者の認識が違っていたりすれば、後の設計や実装に影響します。
要件定義でAIが特に役立つのは、元の資料から必要な要件が漏れなく整理されているか、ほかに決めるべき事項がないかを確認する作業です。背景情報を集めてAIに渡し、出力の妥当性を判断して責任を持つのは人です。 後続工程への影響が大きい上流ほど、その判断は重くなります。
スーパーソフトウエアでは、顧客の開発案件を持ち帰り、準委任契約でチームとして進めるラボ型開発で、生成AIを幅広く活用しています。顧客先に常駐する案件でも、顧客のルールに従って利用しています。
この記事で扱うのは、要件定義という作業に生成AIを活用する方法です。AIを組み込んだシステムを開発する際の要件定義とは、テーマが異なります。要件定義そのものの役割や担当範囲は、「要件定義できます」の落とし穴で解説しています。
要件定義で生成AIが助けるのは、網羅性の確認
当社でよくあるのは、すでに動いている業務とシステムを前提にした、規模の大きな改修です。何をどう変えるか、どこまで影響が及ぶかを整理する場面になります。
こうした案件では、まず既存の設計書、業務マニュアル、ソースコードなど、分析に必要な資料をディレクトリに集めます。そのうえで、どの資料を基準に現行仕様を把握するか、画面・処理・データの関係をどの順番で調べるか、情報をどの単位で整理するかといった分析の進め方を決めていきます。
確認対象は、文書に書かれた仕様だけにとどまりません。既存ドキュメントでは十分に説明されていない業務フロー、画面遷移、データベース（DB）の構造なども含めて整理します。項目に番号を振り、要件と既存仕様の対応、変更箇所同士の依存関係を追えるようにしたうえで、生成AIを確認作業に活用します。
たとえば、ある画面の入力項目を一つ変えるだけでも、その値を使う後続画面や処理、DBの項目、帳票まで影響が及びます。AIには、集めた資料をもとに関連箇所の候補を挙げさせ、「この変更によって影響を受ける箇所はほかにないか」「資料同士で記載が食い違う部分はないか」と問いかけます。
整理した内容は、新しい定義書、変更管理表、決定稿、未決事項の管理にもつなげます。要件ごとに根拠や関連項目をたどれる状態にしておくと、変更が入った際にも確認すべき範囲を洗い出しやすくなります。
生成AIを要件定義に使う価値は、文書を書く速さだけでなく、複数の資料を突き合わせ、見落としや確認不足に気づく機会を増やせることにあります。ただし、AIが挙げた影響範囲や不足項目も、そのまま採用するわけではありません。実際の仕様と照らして、要件に採るかどうかを決めます。
人が受け持つのは、入力と出力への責任
要件定義で人が受け持つ仕事は、大きく二つ。判断に必要な背景情報を集めてAIに渡すことと、AIが出した内容を確かめ、成果物に責任を負うことです。
同じ「この処理を速くしたい」という要望でも、時間がかかる原因が画面操作なのか、承認の待ち時間なのか、データ処理なのかで、必要な対応は変わります。要望の言葉だけをAIに渡せば、もっともらしい改善案や要件は並んできます。それが現場の運用や、顧客が本当に困っていることに合っているかは別の話です。
担当者はまず既存資料を集め、何のための改修か、どの業務に影響するか、何がすでに決まっていて何が未決かを整理します。資料だけでは分からないことは、関係者に聞きます。AIへの入力の質は、担当者がどれだけ顧客とシステムを理解しているかに左右されます。
出力を受け取った後も仕事は続きます。AIが挙げた要件に根拠はあるか。既存仕様と矛盾しないか。未決の事項を、合意済みの仕様として書いていないか。こうした点を人が確かめ、必要なら再調査し、顧客と合意を取ります。
当社のマネージャーも、AIの出力をどう判断するかを扱った記事で、曖昧な指示を投げると、業務の本質からずれた成果物まで速く生み出される危険を指摘しています。文章が整っていることと、要件が正しいことは同じではありません。
AIが作成した成果物は、一見きれいに整っています。それでもレビューをかけると、抜けや詰めの甘さが出てきます。何を採用し、何を保留し、誰に確認するかを決めるところまでが、エンジニアやプロジェクトリーダー（PL）の仕事です。
生成AIを入れても、上流工程ほど人の判断が重くなる
生成AIの活用範囲は、要件定義だけに限りません。当社では進捗管理や、設計・実装・テストの計画段階からも利用しています。ただし、工程によってAIに支援させる作業と、人が引き取る判断は変わります。
| 工程 | AIに任せること | 人が受け持つこと |
|---|---|---|
| 要件定義 | 既存資料と要件一覧の突き合わせ、抜け漏れ・矛盾・未決事項・変更影響の候補の洗い出し | 背景や制約の把握、要件の採否、優先順位の判断、関係者との確認・合意 |
| 進捗管理 | 進捗情報や課題の整理、遅延・未解決事項の確認、対応が必要な論点の提示 | 発生した問題を誰が引き取り、どう対応するかの決定、関係者への説明と調整 |
| 設計・実装・テスト | 計画時に確認すべき情報の洗い出し、入力資料の網羅性の確認、設計・コード・テスト観点の検討支援 | 設計方針の決定、既存構成との整合や品質の検証、成果物のレビューと承認 |
進捗管理なら、予定と実績の差を並べるところまでは定型的な作業です。難しいのはその先で、ある作業が遅れたとき、担当者が巻き返すのか、別チームに確認するのか、顧客と合意を取り直すのかは、遅れの原因によって変わります。AIに論点を整理させながら、誰が何をするかを決めるのは人です。
要件定義では、その判断が後続の設計、実装、テスト全体に波及します。たとえば、ある業務上の例外処理を要件から落としてしまうと、後の工程でどれだけ速くコードを生成しても、必要な処理は実現されません。AIによって作業が速くなるほど、誤った前提をもとに成果物が増えてしまうリスクもあります。
だからこそ、上流工程で求められるのは、何を作るべきかを正確に整理し、判断の根拠を持ち、関係者と合意してから先に進める力です。生成AIが支えるのは、そのための確認と整理の部分です。決めた内容の影響範囲が広い分だけ、人の判断と責任も重くなります。
AIを毎日使う人ほど、確認を重く見ている
似た傾向は、当社が実施したエンジニア1,265人への調査にも出ています。
「AIの出力が正しいか確認すること」の重要性が増したと回答した割合は、生成AIをほぼ毎日使う人で62.6%、週に数回使う人で35.8%、月に数回使う人で19.9%でした。利用頻度が高い層ほど、確認の重要性を感じている人の割合が高い結果です。
また、人が責任を持つべきこととして挙がったのは、「AIが作ったコードや資料の正しさを確認すること」39.9%、「品質や安全性を判断すること」30.7%、「設計方針を決めること」25.2%、「顧客や利用者に内容を説明すること」24.0%でした。
もちろん、この調査だけで「AIを使うほど確認作業が増える」という因果関係は示せません。ただ、AIを日常的に使うエンジニアの多くが、出力を確かめる役割の重要性を認識していることは読み取れます。
要件定義でAIを使う際も、出力の量や速さと、要件の正しさは分けて考える必要があります。調査全体の結果は、生成AI時代のエンジニアの仕事・キャリアで紹介しています。
要件定義でAIを活用し始めるときの、最初の一歩
これから要件定義にAIを活用するなら、まずは自分で作成した要件一覧を、元の資料と突き合わせて確認する使い方から始めるとよいでしょう。要件定義書を最初から丸ごと作らせるよりも、確認する対象と根拠が明確だからです。
たとえば、既存の仕様書と、自分が整理した要件一覧を用意します。その際、「今回の改修の目的」「変更対象」「既存業務で守るべき条件」「まだ決まっていない事項」を短く書き添えます。AIには、要件一覧に反映されていない記述、矛盾する記述、追加の確認が必要そうな事項を、該当する元資料の箇所とともに挙げるよう依頼します。
出てきた指摘は、原文と照らして確かめます。実際に漏れていたものは要件に反映し、判断が必要なものは未決事項として残します。AIの指摘が外れていることもあるので、何を採り、何を却下したかは記録に残しておきます。次の案件で効いてきます。
顧客の資料を扱う際は、利用許可と通信先の制限が前提です。当社では、顧客が許可した資料だけを使用し、AIの通信先を開発元に限定することや、変更履歴を追跡できるようにすることなどを、社内基準と顧客ごとのルールに沿って運用しています。
最初から大きな工程を変える必要はありません。小さな確認作業で使い方を確かめ、判断の精度を落とさずに活用範囲を広げていくことが現実的です。
スーパーソフトウエアの開発現場では
スーパーソフトウエアでは、顧客案件をチームで継続支援するラボ型開発で、生成AI・開発支援ツールを標準的に活用しています。要件の整理や確認に加え、設計、実装、テストまで、作業の性質に応じた使い方を進めています。設計書のレビューでの使い方は設計書のレビューにAIをどう使うかで紹介しています。
顧客先に常駐する案件でも、顧客のルールで認められた範囲で活用しています。実際に、API仕様書の整合性を確認するためにAIを使ったり、実装にAIを取り入れたりしている現場もあります。現場ごとに使えるツールや設定は違いますが、許可された範囲で使い方を広げています。
今後は、案件で培った知見と生成AIを組み合わせ、プロジェクト初動の整理、合意事項のチェックリスト化、成果物レビューの観点整理などを、さらに標準化・高度化していく方針です。経験者の判断を支え、抜け漏れを減らす仕組みとして育てていきます。
当社の評価項目には、「AI・自動化による生産性の改善」があります。単にツールを使ったかどうかにとどまらず、AIを活用して仕事の進め方や生産性をどう改善したかも評価の対象です。
当社が掲げる「開発推進力」は、技術を基盤に、顧客とシステムを理解し、人とAIを組み合わせながら、開発を前に進める力です。要件の背景を考え、必要なことを判断し、周囲と共有して前に進める。その経験を積める環境を目指しています。考え方はキャリアページでも紹介しています。
実装経験を生かしながら、要件整理や設計方針の判断へ担当領域を広げたい方には、上流SE・PL候補（AI活用）の募集もあります。実際の案件でAIをどう使っているか、どのような役割を担えるのかは、カジュアル面談でもお話しできます。
この記事のテーマについて、もっと話を聞いてみたい方へ：
- カジュアル面談を申し込む — 30〜45分のオンライン面談
- 募集職種を見る — 上流SE・PL候補（AI活用）を含む求人一覧
- AIが出したコードを、どう判断するか — 現場のマネージャーが見ている5つの観点
- 生成AI時代のエンジニアの仕事・キャリア — 1,265人調査
- 「要件定義できます」の落とし穴 — 要件定義そのものの中身
- 他のキャリア記事を読む — PL／上流工程／キャリアに関する他の記事
