はじめに
生成AIやLLMエージェントを使ったプロダクト開発では、「どのモデルを使うか」「どのプロンプトが良いか」といった議論に目が向きがちです。
しかし、モデル単体の性能が高いだけでは、プロダクトにはなりません。
顧客の課題を要求として整理し、データを設計し、適切なアーキテクチャを選び、評価し、本番で運用し、そのフィードバックを再び要求へ戻す。この一連の流れを一つのループとして設計して、初めて継続的に改善できるAIプロダクトになります。
私は普段、LLMベースのマルチエージェントによる要求工学（Requirements Engineering）を研究しつつ、データ基盤まわりの開発にも関わっています。本記事では、その両方の経験から「Model-centricではなくSystem-centricに考える」という視点で、この流れを整理してみます。
1. 「AIで何をするか」ではなく「何を解決するか」から始める
AIプロジェクトは「LLMで何かできないか」から始まりがちですが、本来の出発点は現場で何が問題になっているかです。
製造業の現場であれば、例えば次のような課題があります。
- 設備異常の原因調査に時間がかかる
- 品質問題が起きたとき、関連データを探すのが難しい
- 大量の要求仕様を人手だけでレビューしている
- 過去のトラブル対応のノウハウが担当者ごとに分散している
この段階では、LLM・RAG・Agentといった技術を決める必要はありません。整理すべきなのは次の点です。
- 誰が困っているのか
- 現在どのような作業をしているのか
- どこに時間・コスト・品質上の問題があるのか
- 改善できた場合、どの程度の価値があるのか
例えば「エンジニアが毎週、複数システムからログを集めて原因分析に多くの時間を使っている」という状況なら、プロダクトとしての要求は「ログ分析AIを作る」ではなく、「原因調査にかかる時間を大きく削減する」です。AIは目的ではなく手段です。
2. 顧客課題を「AIシステムの要求」に変換する
課題が明確になったら、システム要求に落とします。ここは要求工学の考え方が最も効いてくる部分です。
「AIが要求仕様書をレビューする」だけでは要求として曖昧です。入出力を具体化すると、例えば次のようになります。
入力：要求仕様書
出力：
- 曖昧な要求
- 要求間の矛盾
- 不足している要求
- 安全上の懸念
- 修正案（根拠付き）
さらにAIシステムでは、機能要求以上に非機能要求が重要になります。
| 観点 | 問うべきこと |
|---|---|
| Accuracy | どの種類の問題を、どの程度検出できればよいか |
| Explainability | 判断の根拠を提示する必要があるか |
| Latency | 数秒で返すべきか、数分かかってもよいか |
| Privacy | 顧客データを外部APIに送ってよいか（ローカルLLMが必要か） |
| Reliability | 同じ入力に対して結果がどこまで揺れてよいか |
| Human oversight | 出力をそのまま使ってよいか、人間の承認が必要か |
LLMシステムでは「動くかどうか」だけでなく、「どの条件下なら使ってよいか」まで定義しておく必要があります。特にReliabilityは見落とされがちですが、LLMは同じ入力でも出力が変わるため、後述の評価設計と直結します。
3. データも「要求」として扱う
従来のソフトウェアは Requirement → Design → Code が中心でしたが、AIシステムでは要求とモデルの間にデータが入ります。
Requirement → Data → Model
品質異常検出AIを例にすると、モデルより先に決めるべきことが多くあります。
- どの設備から、どの期間のデータを取得するか
- 正常・異常データの比率はどうか、欠損値をどう扱うか
- ラベルは誰が付け、品質をどう確認するか
- 本番環境と学習データの分布は一致しているか
どれだけ高性能なモデルを使っても、データ品質が低ければシステム品質は上がりません。だからこそ、データ品質も検証可能な要求として書くことが重要です。
- アノテーター間一致率（Cohen's κ）≥ 0.8
- 必須カラムの欠損率 < 1%
- 重要クラス（重大不良）の Recall ≥ 98%
実務では、こうした基準をドキュメントに書くだけでなく、Great Expectations や dbt tests のようなデータ品質制約としてパイプラインに組み込み、自動でチェックするところまでやって初めて機能します。
4. Model / RAG / Agent は問題構造で選ぶ
ここで初めてアーキテクチャを考えます。すべての問題をAgentにする必要はありません。
| 問題の構造 | 適した構成 |
|---|---|
| 入力を決まったカテゴリに分ける | 単一モデル（分類） |
| 社内知識を参照して答える | RAG |
| 複数の観点から判断し、観点間のトレードオフを扱う | Multi-Agent |
例えば要求レビューでは、安全性・効率性・セキュリティなど、品質特性ごとに観点が対立することがよくあります。この場合、観点ごとにAgentを分け、議論させてから集約する構成が有効です。
要求仕様
│
┌────────┼────────┐
↓ ↓ ↓
Safety Efficiency Security
Agent Agent Agent
└────────┼────────┘
↓
Negotiation / Argumentation
↓
最終レビュー結果
私の研究では、ISO/IEC 25010の品質特性に対応したAgentを用意し、Agent間の主張と反論を形式的な論証フレームワーク（Dungの抽象論証）で整理することで、要求間の衝突を根拠付きで解消するアプローチを扱っています（QUARE、ArgRE）。
ただし、ここで強調したいのは「Agentは多ければ良いわけではない」という点です。Agentを増やすほど、トークンコスト・レイテンシ・障害点・デバッグの難しさが増えます。
実際、Agent構成の違いを比較した実験では、全観点のAgentをすべて投入する構成に対し、ドメインに応じてAgent構成を自動で絞り込む構成が、約60%のトークン予算で、専門家が手動設計した構成の約96%の性能に到達しました（PROFES 2026採録論文、文末参照）。
「Agentを使うかどうか」ではなく、「この問題構造にAgentが何体、どの役割で必要か」を設計対象として扱うべきだと考えています。
5. 評価は4つのレベルで設計する
AIシステム開発で最も難しいのが評価です。Accuracy や F1 だけでは、プロダクトとして使えるかは分かりません。
| レベル | 何を見るか | 例 |
|---|---|---|
| Model | モデル単体の性能 | Precision / Recall / F1 |
| Task | タスクを達成できたか | 矛盾・不足要求を見つけられたか、修正案は妥当か |
| System | プロダクトとして動くか | Latency / Cost / Availability / 出力の安定性 |
| Business | 導入する意味があったか | レビュー工数がどれだけ減ったか |
LLMシステム、特に要求レビューのような生成タスクでは、いくつか実践上のポイントがあります。
正解との文字列一致では測れない
BLEUやBERTScoreのような指標は、レビュー指摘の妥当性をほとんど反映しません。専門家が作成した指摘リストとの対応付けや、評価基準を明示したLLM-as-a-judgeを組み合わせる方が実態に近くなります。ただしLLM-as-a-judgeを使う場合は、一部を人手評価と突き合わせて、判定の信頼性を確認しておく必要があります。
複数回実行して分散を見る
LLMは同じ入力でも出力が揺れます。1回の実行結果で良し悪しを判断せず、シードや実行を複数回変えて平均だけでなくばらつきも報告すべきです。2章のReliability要求は、ここで初めて検証可能になります。
最終的にはBusiness Levelで語る
例えば（数字は例示です）レビュー工数が100人時から30人時になれば、70人時の削減です。現場にとっては、F1が数ポイント上がることより、この削減幅の方が意味を持つ場合があります。
6. PoCから本番へ、そして要求へ戻す
PoCとProductionの壁
「デモでは動く」と「毎日安定して使える」の間には大きな壁があります。本番では、AIモデルはシステム全体の一部にすぎません。
User
↓
Application
↓
Input Validation
↓
AI Pipeline（LLM / Agent）
↓
Output Validation
↓
Logging / Monitoring
LLM特有の論点の中でも、特に効いてくるのは次の3つです。
- Prompt / Model のバージョン管理：モデルの更新やプロンプトの修正で挙動が変わるため、どのバージョンで何を出力したかを追跡できるようにする
- Output Validation：出力形式の検証に加えて、根拠のない指摘（ハルシネーション）を弾く仕組みを入れる
- Fallback とコスト制御：API障害やレート制限時の代替経路、トークン消費の上限を事前に決めておく
Human-in-the-loop をどこに置くか
「どこまで自動化できるか」と同じくらい、「どこを自動化しないか」を決めることが重要です。安全・金銭・本番環境への変更・顧客対応などでは、人間の最終承認を残す方が合理的です。
Agent manages the process, humans make critical decisions.
Agentが情報収集・状態管理・候補生成を担い、人間が承認・トレードオフ判断・最終意思決定を担う。この役割分担については、次の記事で詳しく書く予定です。
本番の問題を要求に戻す
運用中に「特定の種類の入力でAIが頻繁に間違える」と分かったとき、プロンプトをその場で直すだけでは再現性がありません。
Production Issue
→ Root Cause Analysis
→ Requirement Update
→ Data / Test Case Update
→ Model / Prompt Update
→ Evaluation
→ Deployment
例えば「安全要求と運用要求の間の矛盾を見落とす」という問題が見つかったなら、
The system shall detect inconsistencies between safety requirements and operational requirements.
という要求を追加し、それに対応する評価データとテストケースを増やします。こうして、本番のフィードバックが要求工学に戻ってくることで、改善が場当たり的なプロンプト修正ではなく、検証可能なプロセスになります。
まとめ
AIプロダクトを現場に導入するには、モデル開発だけでなく、顧客課題から運用・フィードバックまでを一つのループとして設計する必要があります。
最終的なプロダクト価値を左右するのは、最先端のモデルを使っているかどうかよりも、次のような点だと考えています。
- 正しい問題を解いているか
- データ品質が要求として定義・検証されているか
- 問題構造に合ったアーキテクチャを選んでいるか
- 評価が複数レベルで設計されているか
- 人間との役割分担が明確か
- 運用から要求へ戻すループがあるか
生成AIやLLMエージェントが広がる今、問われているのは「AIに何ができるか」だけではなく、どの課題に、どのようなAIを、どの品質基準で導入し、どう継続的に改善するかを設計する力だと思います。
筆者について
早稲田大学でソフトウェア工学を研究している博士課程の学生です。LLMを活用した要求工学の自動化に取り組んでいます。本記事に関連する研究は以下です。
-
Generative AI for Requirements Engineering: A Systematic Literature Review
Software: Practice and Experience (Wiley), 2026
https://doi.org/10.1002/spe.70029 -
QUARE: Quality-Aware Requirements Engineering through Multi-Agent Dialectic Negotiation
RE 2026 (Research Track)
https://ieeexplore.ieee.org/document/11676644 -
ArgRE: Formal Argumentation for Conflict Resolution in Multi-Agent Requirements Negotiation
IEEE Access, vol. 14, pp. 108729–108755, 2026
https://ieeexplore.ieee.org/abstract/document/11610972 -
Does Agent Configuration Matter? An Empirical Study of Process-Level Quality Adaptation in Multi-Agent Requirements Engineering
PROFES 2026 (Research Track, to appear)