この記事はシリーズ構成となっており▶️マークが現在の記事となります
プロローグ
AIは「新人」であり「Web開発」である - 成果を最大化する生成AIとの付き合い方
第1部 僕がAIを最高の相棒にするまで：ブログ運営改善プロジェクト全記録
第2部 PMP資格の学習教材を、AIを相棒にしてゼロから作り上げる
第3部 AIを相棒にしたシステム開発プロジェクト全記録
▶️【第1回】AIとの「壁打ち」が、曖昧な要求を「勝てる仕様書」に変えるまで
【第2回】ゼロから始めるWebアプリ設計：AIと一緒にモダンなAWSアーキテクチャを描く
【第3回】AIにコードを書かせる前に人間がすべきこと：高品質な成果物を生む「設計書」の作り方
【第4回】巨大なタスクを分解する技術：AIに「開発ロードマップ」を作らせてプロジェクト全体を見通す
【第5回】ログイン機能のセキュリティと利便性、その最適なバランス
【第6回】開発プロセスにおけるAIとの協働：ログイン機能設計のケーススタディ
【第7回】認証管理の弱点とボトルネック：AIは「見えないリスク」をどう可視化するか【第8回】1つの対話から無限のコンテンツを：AIとの開発プロセスを新人研修資料やインフォグラフィックに変える方法
今回のテーマ: 要件定義フェーズ
前回の記事はこちら：https://axis.migalo.co.jp/column/k023
① はじめに（導入）
「とりあえずログイン機能が欲しいんだよね」
システム開発の現場では、こんな風にざっくりとした要求からプロジェクトがスタートすることが少なくありません。ここから具体的な仕様に落とし込んでいく「要件定義」は、プロジェクトの成否を分ける最も重要な工程の一つです。しかし、担当者の経験やスキルに依存しがちで、考慮漏れが発生しやすいという課題も抱えています。
もし、この複雑で難しい要件定義のプロセスに、経験豊富なITコンサルタントのように的確な質問を投げかけてくれる「思考のパートナー」 がいたらどうでしょうか？
この記事では、生成AI（本記事ではGoogleのGeminiを使用）をその「思考のパートナー」として活用し、曖昧な要求を具体的な「要件定義書」という成果物に昇華させていく実践的なプロセスを、実際のAIとの対話ログを交えながらご紹介します。
この記事を読めば、AIを使って要件定義の質を向上させ、手戻りを減らすための具体的なヒントが得られるはずです。
※この事例は個人的に行っていたプロジェクトでAI活用した事例です。
② 課題・目的
今回のプロジェクトの出発点は、次のような非常にシンプルな要求でした。
【最初の要求】 Webアプリケーションにログイン機能を実装したい。
この状態では、当然ながらエンジニアは何も作ることができません。「どんなログイン方法？」「パスワードを忘れた時は？」「セキュリティは？」など、無数の「？」が浮かびます。
そこで、今回の目的を以下のように設定しました。
目的: 曖昧な「ログイン機能が欲しい」という要求を、誰が読んでも実装内容を理解できる具体的な「要件定義書」に落とし込むこと。
課題: 開発経験が浅い担当者でも、セキュリティやユーザビリティの観点を含んだ、抜け漏れのない仕様を効率的に作成すること。
この課題を解決するために、Geminiとの「壁打ち」を開始しました。
③ AIへの指示（プロンプト）
まず、私がGeminiに投げかけた最初のプロンプトは、意図的に曖昧さを残したものです。AIがどのように解釈し、どのような応答を返すかを見るためです。
【プロンプト】 Webアプリケーションを開発し、下記のログイン機能を開発します。 ログイン画面 ・ユーザーIDとパスワードを入力 ・ユーザー／パスワードが一致したら...（中略）...
その他 ・二要素認証成功後にセッション発行...（中略）...
ログイン機能の要件として過不足や一般的な同様の機能と比較して変な箇所ないかレビューしてください。
【プロンプトのポイント】
役割を与える: 最後の「レビューしてください」という一文で、AIに「コードを書く作業者」ではなく「仕様を確認するレビュアー」という役割を与えています。
評価軸を与える: 「過不足」「変な箇所はないか」という評価の観点を与えることで、AIが何をすべきかを明確にしています。
④ AIによる生成物（アウトプット）
このプロンプトに対し、Geminiは単に「承知しました」と返すのではなく、経験豊富なエンジニアやコンサルタントのように、網羅的なレビューを開始しました。
【Geminiからのレビュー（抜粋）】
全体として網羅的に検討されていますが、一般的な機能との比較やセキュリティ、ユーザビリティの観点からいくつかレビューさせていただきます。
１．ログイン画面
〇 検討・確認事項:
・ログイン試行回数制限とアカウントロック: 不正アクセス対策として、一定回数ログインに失敗した場合にアカウントを一時的にロックする機能は一般的です。この要件が不足しているようです。
・CAPTCHA認証: ログイン試行失敗時や、不審なアクセスが見られる場合にCAPTCHAを要求することも有効なセキュリティ対策です。
２．新規ユーザー追加画面
〇 検討・確認事項:
・利用規約／プライバシーポリシーへの同意: 新規登録時には、利用規約やプライバシーポリシーへの同意を得るためのチェックボックスを設置するのが一般的です。
・アクティベーションフローの複雑さ: 「メールのリンクを押下したら電話番号宛てにアクティベーションメッセージを送付」というフローは、ユーザーにとっては登録完了までのステップが多く感じられる可能性があります。ユーザーの離脱ポイントになる可能性も考慮し、バランスを検討することをお勧めします。
【生成物のポイント】
観点の提示: AIは「セキュリティ」「ユーザビリティ」といった明確な観点からレビューを行っています。
不足点の指摘: 「アカウントロック機能が不足している」といった、初期要件にはなかった重要な機能の抜け漏れを的確に指摘しています。
リスクと代替案の提示: 「ユーザーの離脱ポイントになる可能性」というユーザー体験上のリスクを指摘し、より一般的なフローを代替案として提示しています。AIが技術的な正しさだけでなく、ビジネス的な観点も持っていることがわかります。
⑤ 考察・ポイント
今回の対話から、AIを要件定義のパートナーとして活用する上で、以下の3つの重要なポイントが見えてきました。
・AIは「思考の触媒」である
AIにレビューを依頼することで、自分一人では気づきにくかった観点（セキュリティリスクやユーザー体験の悪化）を強制的に意識させられます。AIからの指摘が「思考の触媒」となり、より深く、多角的に仕様を検討するきっかけを与えてくれます。「これで十分だろうか？」と常に問いかけてくれる優秀な相談役が隣にいる感覚です。
・対話のキャッチボールが仕様を磨く 最初から完璧なプロンプトを用意する必要はありません。
むしろ、少し曖昧な要求を投げかけ、AIからのフィードバックを受けて修正し、また投げかける…という「対話のキャッチボール」を繰り返すことで、仕様は徐々に磨かれていきます。このプロセス自体が、アジャイル開発の考え方に非常に近いと言えます。
・最終的な「意思決定」は人間の役割
AIは様々な選択肢やリスクを提示してくれますが、最終的に「どの機能を採用し、どのリスクを許容するか」を決定するのは人間の役割です。
例えば、今回AIが提案した「CAPTCHA認証」は、セキュリティを高める一方でユーザーの手間を増やすため、今回は「採用しない」という意思決定をしました。AIを便利な相談相手としつつ、プロジェクトの目的やリソースに合わせた最適な判断を下すことが重要です。
あなたのプロジェクトで試すには あなたのプロジェクトで、今まさに議論されている機能要件はありませんか？ その要件を箇条書きでAIに伝え、「この要件について、セキュリティやユーザビリティの観点から考慮すべき点や、不足している仕様がないかレビューしてください」と依頼してみましょう。AIが、あなたのチームの「第三の目」となってくれます。
⑥ まとめと次回予告
今回は、曖昧な機能要求をAIとの「壁打ち」を通じて具体的な仕様へと昇華させていくプロセスをご紹介しました。AIを思考のパートナーとして活用することで、要件定義の質を飛躍的に向上させることができます。
こうして、曖昧だった「ログイン機能が欲しい」という要求は、AIとの対話を通じて、開発チーム全員が迷わず進める具体的な「要件定義書」へと進化しました。「何を作るか」が固まった今、次に待っているのは「どう作るか」という、巨大な問いです。
次回、 「第2回：ゼロから始めるWebアプリ設計：AIと一緒にモダンなAWSアーキテクチャを描く」 では、この要件定義書を基に、AIと対話しながら複雑なクラウドのシステム構成図を作成していくプロセスを解説します。ご期待ください。
