AIBR プレミアム
拓海先生、最近社内で「要件定義（Requirements Engineering）がAIで楽になる」と聞きまして、でも本当かどうか見当がつかないのです。要するに現場の手戻りや人的コストが減ると期待してよいのでしょうか？
素晴らしい着眼点ですね！結論から言うと、できることは増えますが「どう使うか」が全てです。ポイントは三つ、ツールに任せる作業の明確化、与える指示＝プロンプトの作り方、評価基準の整備です。それを順に分かりやすくお伝えしますよ。
まずコスト削減の試算が必要で、下手に導入して現場が混乱するのは避けたい。具体的に何を自動化できるか、そしてそれでどれだけ人手が減るかの見積もりを知りたいのです。
大丈夫、一緒にやれば必ずできますよ。現実的な進め方はこうです。第一に、要件の分解作業や既存仕様の分類は自動化しやすいです。第二に、仕様の追跡（トレーシング）はテンプレ化で効率化できます。第三に、プロンプトの形を整えることで出力の品質が安定します。
その「プロンプト」とは要するにどのようなものですか？具体性がないと現場は信用しません。これって要するに、良い質問文のテンプレを作れば良いということ？
その通りです！ただし「テンプレ」には使いどころがあり、作業種類ごとに最適なパターンがあります。これはプロンプトパターンと呼ばれ、言ってみれば作業ごとの標準操作手順書です。まずは代表的な五つのパターンを試し、精度や再現性を計測して最適化していきますよ。
投資対効果はどう評価するのが現実的ですか？現場が細かくチェックする時間を減らしたら品質に影響しないか心配です。
良い懸念です。ここでも要点は三つ、まずは限定的なパイロットで精度（Precision）と網羅性（Recall）を測ること、次に人間の目で承認するフローを残すこと、最後に自動化で解放された時間を品質検査に回すことです。これで品質を落とさずに効率化できますよ。
わかりました。では社内でまず何を準備すればいいですか？データの用意と評価基準の整理くらいは私でもできるかなと。
素晴らしい流れです。まずは既存の要件文書から正解ラベル付きデータセットを用意し、同じ文書から識別子を除いた版を作ってモデルに与えるというやり方が有効です。その上で五つのプロンプトパターンを順に試し、精度やFスコアを比較します。これを踏まえて導入範囲を決めれば安全です。
なるほど。では私の理解を確認します。要するに、モデルに渡すデータを用意して、複数のプロンプトパターンを試し、結果を評価するという段階を踏めば導入は現実的だ、ということですね。これなら説明して投資判断もできそうです。
その理解で完璧ですよ。大丈夫、一緒に進めれば必ず成果が出せます。次回は具体的な評価指標の作り方と、社内でのパイロット計画を一緒に組み立てましょう。
