AIエージェントに開発を任せる時代、要件定義はどう変わるのか。ウォーターフォール型仕様書との違い、プロンプト＝要求仕様の粒度、受け入れ条件の明文化、変更に強い進め方を、業務部門・PM向けに整理します。
AIコーディングエージェントが実務に入り始めたことで、ソフトウェア開発の力点が静かに移りつつあると考えられます。これまで開発の律速になっていたのは、多くの場合「実装そのもの」でした。仕様を決めても、それをコードに落とし込む工数が大きく、だからこそ手戻りを避けるために分厚い仕様書を先に固める必要があった、という側面があります。
ところが、自然言語で要求を伝えると相応の実装案を返してくれるエージェントが普及し始めると、実装のコストは相対的に下がっていきます。すると、開発全体のボトルネックは「どう作るか」ではなく「何を作るべきかを、いかに正確に言葉にできるか」へと移動します。つまり、要件定義の巧拙が、これまで以上に成果を左右する局面が増えていると考えられます。
業務部門やPMの方から、「AIに頼んでも思ったものが出てこない」「エンジニアに依頼したのに認識がずれる」という声をよく聞きます。しかし、その多くは相手の能力の問題というより、要求の側に「言語化されていない前提」が大量に残っていることが原因だと考えられます。人間の熟練者どうしであれば、暗黙の前提を空気で補完してくれます。AIエージェントや、業務背景を知らないエンジニアは、その補完をしてくれません。だからこそ、前提を明文化する作業＝要件定義が改めて重要になります。
本記事は、自分でコードを書くわけではないが、AIやエンジニアに開発を依頼する立場にある業務部門・PMの方を主な読者として想定しています。専門的な設計論ではなく、「要求をどう伝えれば破綻しにくいか」という実務の型を中心に整理します。あわせて、AIエージェントを社内に取り入れる全体像はAIエージェントを社内に導入するにはで扱っているため、組織としての進め方はそちらも参照いただければと考えます。
AI開発時代のキーワードとして「作りながら決める」がよく挙げられます。これ自体は有効な進め方ですが、誤解されやすい言葉でもあります。何も決めずに走り出すという意味ではありません。むしろ、「絶対に変えてはいけない芯」と「作りながら調整してよい枝葉」を意識的に分け、芯を先に固定しておくからこそ、枝葉を柔軟に変えられる、という構造だと考えます。芯を決めずに始めると、変更のたびに議論が振り出しに戻り、かえって時間を失うことになりかねません。
まず、従来の要件定義がなぜあの形になっていたのかを振り返ると、AI時代に何を引き継ぎ、何を手放すべきかが見えてきます。
ウォーターフォール型の開発では、要件定義・設計・実装・テストを一方向に進めます。この進め方が主流だったのは、実装や修正のコストが高く、後工程での変更が非常に高くつくためです。作り直しのダメージが大きいからこそ、着手前に仕様を可能な限り確定させ、合意の証跡として分厚いドキュメントを残す必要がありました。これは当時の制約に対する合理的な最適化だったと考えられます。
AIエージェントによって試作や修正のコストが下がると、「作り直しが高くつくから先に全部決める」という前提の一部が緩みます。動くものを短期間で用意し、それを見てから要求を詰められるなら、机上で完璧な仕様を目指すより、早く現物に当てて誤解を潰すほうが速く正確になりやすいと考えられます。この「動くものを先に作る」進め方の具体的な型は、AIエージェントPoCのスコープ設計でも整理しています。
ここで注意したいのは、実装コストが下がったからといって、要件を決める必要がなくなったわけではない、という点です。むしろ逆で、実装が速くなるほど「間違った方向に速く進む」リスクが高まります。方向を定めるのは依然として要求であり、その品質が低ければ、速く大量に間違ったものが出来上がるだけになりかねません。手放してよいのは「実装詳細を事前に確定させる負担」であって、「何を達成したいかを定義する責任」ではないと考えます。
この切り分けは業務やチームによって最適点が異なるため、一律の正解はありません。自社の状況に合わせて、現物での検証を通じて調整していくことが前提になると考えます。
AIエージェントに開発を任せるとき、あなたが書くプロンプトは、そのまま要求仕様として機能します。ここで多くの人がつまずくのが「どこまで細かく書くべきか」という粒度の問題です。細かすぎても粗すぎても、うまくいきにくいと考えられます。
「在庫管理ツールを作って」といった粗い依頼は、一見すると柔軟に見えますが、実際にはエージェントが無数の前提を勝手に補完することになります。誰が使うのか、どんなデータが入力されるのか、何をもって正しい動作とするのか──これらが曖昧なままだと、出てくるものは「それらしいが、現場では使えない」ものになりがちです。人間の新人に一言だけ指示して丸投げするのと同じ構図だと考えられます。
逆に、実装の手順やコードの書き方まで一字一句指定してしまうと、せっかくのエージェントの提案力を殺してしまいます。また、手順を固定すると、途中で前提が変わったときに全体を書き直す羽目になり、変更に弱くなります。指定すべきは「達成したい結果と守るべき制約」であって、「そこへ至る手順」ではない、という切り分けが有効だと考えます。
粒度に迷ったときは、次の三層を意識して書くと安定しやすいと考えられます。
手順（どう実装するか）はあえて空けておき、エージェントの提案を受けてから調整する、という余白を残すのが、変更に強い書き方だと考えます。
要求を言葉で精密に書こうとすると、かえって冗長で曖昧になることがあります。そんなときは、入力と出力の具体例を1組示すほうが、はるかに正確に伝わることが少なくありません。「このような入力に対して、このような出力になってほしい」という実例は、抽象的な説明を何行も重ねるより誤解を減らします。産業用の画像検査でも、良品・不良品の言葉による定義より、実際のサンプル画像を示すほうが判断基準が伝わりやすいのと同じ構図だと考えられます。
うまく伝わったプロンプトは、その人の頭の中だけに置いておくと再現性が生まれません。効果のあった要求の書き方を社内で共有し、型として蓄積していく取り組みが、組織としての開発力につながると考えます。この観点はプロンプトの社内共有と標準化で詳しく扱っています。要件定義の質を個人技から組織の能力へ引き上げるうえで、避けて通れないテーマだと考えます。
AI開発でもっとも軽視されがちで、しかし最も効くのが「受け入れ条件（Acceptance Criteria）」の明文化だと考えます。これは「何をもって、この依頼が完成したと言えるか」を、着手前に言葉にしておくものです。
受け入れ条件を決めずに進めると、出てきた成果物を見て「なんとなく違う」「もう少しこうしてほしい」というやり取りが延々と続きます。これは依頼者にも作り手にも消耗を強います。完成の基準が主観のままだと、いつまでも終わらないか、逆に妥協で終わってしまうかのどちらかに傾きやすいと考えられます。
良い受け入れ条件は、第三者が見ても達成・未達成を判定できる形になっています。「使いやすいこと」ではなく「この操作を3ステップ以内で完了できること」、「速いこと」ではなく「この処理が体感で待たされないこと（目安として数秒以内）」のように、判定できる粒度に落とし込むことが重要だと考えます。曖昧な形容詞を、確認可能な条件へ翻訳する作業とも言えます。
正常系（うまくいく場合）の条件は比較的書きやすいのですが、抜けやすく、かつトラブルの温床になるのが例外系です。入力が想定外だったとき、データが欠けていたとき、外部サービスが応答しないとき──こうした場面でどう振る舞ってほしいかを書いておかないと、エージェントは都合よく解釈するか、黙って握りつぶすことになりかねません。「エラー時は処理を止めて人に通知する」「不確かなときは自動で確定せず、確認を求める」といった方針を、受け入れ条件の一部として明記することを勧めます。
特に業務に組み込むツールでは、エージェントにどこまで自動で任せ、どこで人間の承認を挟むかを、受け入れ条件として最初から設計しておくことが重要だと考えます。全自動が常に正解とは限らず、影響の大きい操作の手前に確認を置くことで、失敗のダメージを抑えられます。この承認ポイントの設計は、AIエージェントに任せる範囲と人の承認ポイントの設計で具体的に整理しています。要件定義の段階で「どこで人が関与するか」を決めておくと、後からの作り込みが減ると考えます。
検証可能な形で受け入れ条件を書いておくと、それはそのまま「完成したかどうかを確かめる手順（テスト）」として使えます。AIエージェントに「この受け入れ条件を満たすか自己検証してから提出してほしい」と伝えられれば、手戻りを減らす助けになると考えられます。要求を書くことと、検品の基準を書くことが一体になる、という点が、AI時代の受け入れ条件の効きどころだと考えます。
「作りながら決める」を破綻させないためには、進め方そのものを変更に強い形にしておく必要があります。ここでは、要求を一度で固めきらず、小さく回しながら育てていくための実務的な工夫を整理します。
一度に大きな機能をまとめて依頼すると、どこがどう間違っているのかを切り分けにくくなります。小さな単位に分けて依頼し、一つずつ現物で確認してから次に進むほうが、誤解を早期に発見でき、結果として速いことが多いと考えられます。小さく回すことは、変更が起きたときの影響範囲を局所に留める効果もあります。
最初に作るものは、要求を確かめるための試作＝方向性の確認用と割り切り、いずれ作り直す前提で臨むと、意思決定が速くなります。試作で分かった要求を反映して本開発に進む、という二段構えです。試作を本番へそのまま昇格させようとすると、初期の割り切りが技術的な負債として残りやすいため、どこまでが使い捨てで、どこからが本番かの線引きを最初に共有しておくことが重要だと考えます。
要求は一度書いたら終わりではなく、検証で分かったことを反映して更新し続ける対象です。分厚い仕様書を完成させて凍結するのではなく、常に最新の合意が1か所にまとまっている状態を保つほうが、AI時代には機能しやすいと考えられます。更新のたびに「何を、なぜ変えたのか」を短く残しておくと、後から経緯を辿れて、認識のずれを防ぎやすくなります。
AIエージェントとのやり取り、関係者との合意は、後から辿れる形で残しておくことが、変更に強い進め方を支えます。「なぜこの仕様にしたのか」が失われると、変更のたびに議論が振り出しに戻ります。決定と、その理由を軽くでも記録しておく習慣が、長い目では大きな差になると考えます。
AI時代の要件定義で、実務上つまずきやすいポイントを整理します。いずれも、進める前に知っておくだけで回避しやすくなるものだと考えます。
これらはいずれも、技術の問題というより、要求の伝え方と進め方の設計の問題だと考えられます。裏を返せば、要件定義の型を整えることで、多くは着手前に回避できる余地があると考えます。
最後に、AI時代の要件定義を自社に根づかせるための現実的な進め方を、段階として整理します。いきなり全社で完璧を目指すより、小さく始めて型を育てるほうが定着しやすいと考えられます。
まずは影響範囲の小さい業務ツールを1つ選び、「目的・入力と出力・制約」で要求を書き、受け入れ条件を明文化してからAIエージェントに依頼してみる、という一連の型を一度通してみることを勧めます。最初から大きな基幹業務に適用しようとせず、失敗しても痛くない範囲で型の感触をつかむことが、定着の近道だと考えます。
試して効果のあった要求の書き方・プロンプト・受け入れ条件のパターンを、チームで共有できる形に残していきます。ここで個人技のままにせず、社内ナレッジ基盤に蓄積して再利用できるようにしておくと、次の依頼から立ち上がりが速くなります。要求を書く力を、個人の暗黙知から組織の形式知へ移していく作業だと考えます。
ツールが業務に組み込まれてくると、どこまで自動に任せ、どこで人が承認するか、どのデータを扱ってよいかといった統制が重要になります。要件定義の段階でこれらを織り込んでおくと、後からの手戻りが減ります。全体像の設計はAIエージェントを社内に導入するにはもあわせて参照いただければと考えます。
要件定義は机上で完結するものではなく、現物に当てて初めて分かることが数多くあります。特に業務の細部や例外は、実データ・実運用に触れて初めて言語化できることが少なくありません。だからこそ、動くものを早く現場に見せ、そこで得た気づきを要求に反映し続ける、という往復が本質だと考えます。
Nsightは、産業用画像検査・VLM/AIに加え、AI研修や社内AIエージェント・業務OSの内製化支援を手がけています。その現場知見は、元キーエンス画像処理事業部で、良品・不良品の判定基準という「言語化しにくい暗黙知を、検証可能な条件へ落とし込む」作業に向き合ってきた経験に根ざしています。良し悪しの基準を現物のサンプルで詰めていくプロセスは、AI開発における受け入れ条件の明文化と、驚くほど似た構造を持つと考えています。
要件定義の型づくりや、AIエージェントを使った内製の進め方でお悩みがあれば、机上の理想論ではなく、貴社の実際の業務・実データを前に、現物・現場での検証を通じて一緒に確かめていくことをご提案します。効果や適用可否は状況によって異なるため、断定はできませんが、小さく試して見極めるところからご一緒できればと考えます。
分厚い仕様書を先に完成させて凍結する、という進め方の必要性は下がったと考えられます。ただし「何を達成したいか」「何をもって完成とするか」を定義する責任はむしろ増しています。実装が速くなるほど、間違った方向にも速く進むためです。手放してよいのは実装詳細を事前に確定させる負担であって、目的と受け入れ条件を言葉にする作業ではないと考えます。
目的・入力と出力・制約の三層を書き、手順（どう実装するか）はあえて委ねるのが、変更に強く精度も出やすい書き方だと考えられます。粗すぎるとエージェントが前提を勝手に補完し、細かすぎると提案力を殺し変更に弱くなります。言葉で精密に書くより、入力と出力の具体例を1組示すほうが正確に伝わることも多いです。
第三者が達成・未達成を判定できる形で「完成の基準」を書きます。『使いやすい』ではなく『3ステップ以内で完了できる』のように、確認可能な粒度に落とすことが要点です。特に、入力が想定外だったときや外部サービスが応答しないときといった例外時の振る舞いと、人が承認すべきポイントを明記しておくと、手戻りを大きく減らせると考えます。
変えてはいけない芯（目的・受け入れ条件・扱ってよいデータの範囲・守るべき制約）を先に固定し、実装の詳細だけを作りながら調整するのが「作りながら決める」です。芯を決めずに走り出すと、変更のたびに議論が振り出しに戻ります。芯を固定するからこそ枝葉を柔軟に変えられる、という構造だと考えます。
影響範囲の小さいツールを1つ選び、目的・入力と出力・制約で要求を書き、受け入れ条件を明文化してから依頼する、という型を一度通してみることを勧めます。失敗しても痛くない範囲で感触をつかみ、うまくいった要求の書き方を社内で共有・蓄積していくと、組織としての開発力につながると考えます。現物・現場での検証を通じて育てていくことが前提です。
貴社の実際の業務・実データを前に、要求の伝え方や受け入れ条件の明文化を、机上の理想論ではなく現物・現場での検証を通じて一緒に確かめていきます。小さく試して見極めるところからご相談ください。
AI内製・要件定義の相談をする