LLM開発の要件定義で押さえるべき5つのポイント｜曖昧さをなくす設計術

なぜLLM開発では要件定義が難しいのか

従来のシステム開発では、要件定義は「入力がこうなら、出力はこう」という決定的なルールを明文化する作業でした。

しかしLLM開発では、従来のシステムのように「常に同じ入力なら同じ出力が返る」とは限りません。
同じ質問を繰り返しても微妙に表現が変わる、あるいはその場の文脈によって答えが揺らぐ、といった現象が当たり前に起こります。

さらに、正解が一つに定まらないケースも多いのが特徴です。
たとえば「良い要件定義の書き方は？」という質問に対して、A社なら「テンプレートを使う」と答えを求め、B社なら「顧客との合意形成を重視」と答えを期待するかもしれません。
どちらも間違いではなく、それぞれの文脈で「正解」になり得ます。

従来の開発では「要件＝固定化された仕様」でしたが、LLMでは「要件＝正解の幅をどう許容するか」を設計する必要があります。
この発想の転換ができないまま進めると、

• 「出力が安定しないからNG」
• 「期待した答えじゃないから不具合扱い」
  といった議論に終始し、プロジェクトが迷走するのです。

よくある失敗例

• 「自然な文章で回答すること」とだけ記載 → 開発者ごとに解釈が割れ、レビューで「硬すぎる／砕けすぎる」と対立
• 「精度を高める」とだけ定義 → PoC段階で「どこまで行けば合格か」判断できず、無限に調整が続く

実務での工夫

• 曖昧な言葉は数値基準やサンプル出力に置き換える
• 要件定義書には出力例やテスト基準を必ず添付し、合意形成を支える

要件定義で迷走しないためのLLM開発5つのチェックポイント

①出力条件を明確化する｜曖昧な表現を避ける

LLMは「自然に」「丁寧に」といった曖昧な指示でも動きますが、これは現場では混乱のもとになります。

失敗例

• 「わかりやすく丁寧な文章」とだけ定義 → Aさんは敬語を徹底、Bさんはカジュアル寄り、と真逆の出力が発生
• テスト設計でも「わかりやすさ」が基準化できず、品質保証が進まない

実務での工夫

• フォーマットを固定する
  　例：「質問→回答→補足」の3段構成。誰が実行しても同じ形式になる。
• 禁止事項を明文化する
  　例：「スラング禁止」「必ずです・ます調」。暗黙知に頼らず明記する。
• サンプル出力を添付する
  　例：「発送はいつ？」→「○月○日に発送予定です。補足：発送完了後にメールでお知らせします。」
  　クライアントと「これが正解」と合意形成でき、レビュー・テスト基準としても活用できる。

👉 この3つをセットで実施すれば、「曖昧な要件」が「誰が読んでも同じ解釈になる仕様」に変わります。

②評価基準を数値で定義する｜PoC段階の混乱を防ぐ

LLM開発で一番多いトラブルは「もっと精度を上げて」という曖昧な要求です。
これでは「どのくらいできれば合格か」が不明確で、プロジェクトが終わりません。

そこで大切なのが数値化です。数字で「合格ライン」を決めれば、誰が見ても同じ判断ができます。

1.合格の基準を数字で決める

「正しく答える」とだけ書いても、人によって解釈は違います。
そこで「何問中、何問できれば合格か」を具体的に決めます。

例：「FAQ100件をテストして、そのうち80件以上正しく答えられれば合格」

※合否の基準がはっきりするので、「まだ不十分」など主観で迷走しなくなる

2.利用者の声を数字にする

LLMは「正解かどうか」だけでなく「役に立つか」も重要です。
そこで利用者の評価を割合で表すようにします。

例：「テストユーザーの7割以上が『役に立った』と回答したら合格」

※技術者だけでなく実際の利用者の感覚を反映できる

3.ダメな基準も数字で決める

「誤情報が出たらダメ」とだけ書くと、ゼロを目指して終わらなくなります。
現実的には「多少の誤りは起こり得る」ので、どこまでなら許容するかを数字にします。

例：「テストで10件に1件までの誤答なら許容」

※現実的な落とし所が決まり、PoCを止めずに進められる

おさらい

• 合格ラインを数字で決める
• 利用者の感覚も数字で測る
• 許容できる失敗も数字で表す

👉 こうして「数字での約束事」を先に決めておけば、PoCの途中で「まだ足りない」「いや十分だ」と意見が割れることを防げます。
結果として、チームもクライアントも納得感を持って次のステップに進めます。

③PoCの目的を限定する｜本番品質を求めない

PoC（概念実証）は「仮にやってみて、動くかどうかを確かめる実験」です。
ところが、ここで本番レベルの品質を求めてしまうと、必ず迷走します。

学びたいことを一つに絞る

良い例：「FAQで、よくある質問100件に対してどれくらい正しく答えられるかを確認する」
悪い例：「FAQの精度を確認しつつ、UIもデザインし、監視機能も入れて、ついでに多言語対応も試す」

👉 1つに絞ることで、結果が「できた／できなかった」で判断しやすくなります。

合格ラインを先に決める

「精度を上げろ」だけではいつ終わるかわかりません。数字で区切りをつけることが大事です。

良い例：「100件中80件以上が正解なら合格」
応用例：「テストユーザー10人中7人が『役に立った』と答えたら合格」

👉 数字で決めておけば、チーム内の主観が入り込まず、PoCを終わらせることができます。

期間を区切る

PoCはあくまで「短期で学びを得る実験」です。
期間を決めずに始めると、延々と改善し続けてしまいます。

良い例：「3週間で一区切り。結果が良ければ次のステップ、ダメなら撤退」
悪い例：「とりあえず精度が出るまでやり続ける」

👉 期間を切ることで「ここで判断する」と関係者全員が腹をくくれます。

おさらい

• やることは一つに絞る（最も確かめたいことだけ）
• 合格ラインを数値で決める（主観を排除できる）
• 期間を区切る（ダラダラ続けない）

これでPoCは「小さな実験」らしいシンプルな形になります。
逆に言えば、この3つが守れていないPoCは、ほぼ必ず迷走します。

④コストをシナリオ単位で試算する｜従量課金に備える

LLMは「使った分だけ課金」される仕組みです。
ところが、ざっくり「月10万円くらいでしょ」と見積もると、大体外れます。

よくある失敗

• 実際のユーザー数や利用回数を考慮せず、費用が想定の3倍以上に膨れ上がった
• デモでは数回しか使わなかったのに、本番では毎日数百回呼ばれ、一気に赤字化した

実務での工夫

1. ユーザー数×利用回数×平均トークン数で試算する
   • 例：「1日100人が平均5回利用、1回あたりの入力＋出力が500トークン → 100×5×500＝25万トークン／日」
   • 単価を掛ければ、1日の想定コストが見える
2. シナリオごとに分けて考える
   • FAQ回答、文章要約、コードレビュー…シナリオごとに負荷が違う
   • まとめて1本の数字で見積もらず、「シナリオ別の試算」を必ずする
3. 早めに負荷テストする
   • PoCのうちに「実際に100回呼んでみたらいくらになるか」を測っておく
   • 感覚ではなく実データで語れるようにする

👉 「1ユーザー1日あたりいくら」まで落とし込むと、クライアントにも説明しやすくなります。

⑤運用改善サイクルを要件化する｜作って終わりにしない

LLMはリリースしても「完璧な答え」を出し続けるわけではありません。
むしろ、誤答や表現のぶれが必ず残ります。

よくある失敗

• 改善の仕組みを用意せずリリース → 誤答報告が山のように溜まるだけ
• ユーザーの声を拾えず、「現場が困っているのに直せない」状態になる

実務での工夫

1. ログを収集する
   • ユーザーの質問とLLMの回答を必ず記録する
   • 「どこで間違えたか」を後から分析できるようにしておく
2. 改善の場を定期化する
   • 例：「週1回レビュー会議を開き、誤答の代表事例を確認」
   • 現場の声を拾い、改善優先度を決める
3. 改善ループを仕組みに組み込む
   • 「収集 → 分析 → 調整 → 再展開」を開発の要件に含めておく
   • これがないと、改善が属人的で止まってしまう

👉 LLM開発は「リリース＝完成」ではなく「リリース＝改善の始まり」。
改善ループを要件として最初から設計に入れることが成功の鍵です。