はじめに
自動車・ロボット・医療機器などの安全関連システム（safety-critical systems）の開発において、要求工学（Requirements Engineering） は最も重要なフェーズの一つです。要求の不備がプロジェクト失敗の主因であることは、数十年前から繰り返し指摘されてきました。
しかし現場の実態はどうでしょうか。
- 数百〜数千件の要求を、レビュー会議で人手で確認している
- 要求間の矛盾（例：安全性とユーザビリティのトレードオフ）を見落としがち
- ISO 26262やSOTIFなどの規格準拠チェックが属人的
- DOORSやJamaに要求は入っているが、品質分析は手動
こうした課題に対して、LLM（大規模言語モデル）をマルチエージェントとして活用するアプローチが注目されています。本記事では、この分野の研究動向と、実際にどこまで使えるのかを整理します。
なぜ「マルチエージェント」なのか
LLMを要求工学に使う最もシンプルな方法は、「要求文をLLMに投げて品質チェックさせる」ことです。実際にこれだけでもある程度の効果はあります。
しかし、要求工学の本質的な難しさはステークホルダー間の視点の違いにあります。安全エンジニアは「この機能は危険だから制限すべき」と言い、UXデザイナーは「ユーザーが使いにくくなる」と言い、ビジネス側は「コストが増える」と言う。
この対立構造を単一のLLMプロンプトで扱うのは難しい。そこで、複数のLLMエージェントに異なるステークホルダーの役割を割り当て、議論（argumentation）させるというアプローチが出てきます。
[安全性エージェント] ← 議論 → [ユーザビリティエージェント]
↑ ↑
└──── [コンプライアンスエージェント] ────┘
各エージェントが自分の立場から要求を評価し、矛盾を指摘し、妥協案を提案する。人間のレビュー会議をシミュレーションするイメージです。
具体的に何ができるのか
1. 要求品質の多角的評価
単一LLMによる評価は、プロンプトのバイアスに引きずられやすい問題があります。マルチエージェント構成にすると、異なる品質属性（明確性、完全性、一貫性、検証可能性など）を別々のエージェントが評価し、最終的に統合できます。
2. 要求間コンフリクトの検出と解消
安全関連システムでは、要求間の矛盾が致命的になります。例えば：
要求A：「緊急時にはシステムを即座に停止すること」
要求B：「急停止による搭乗者への衝撃を最小化すること」
これらは明らかにトレードオフの関係にありますが、数百件の要求がある中で人手でこの種の矛盾を網羅的に検出するのは困難です。マルチエージェントシステムでは、あるエージェントが要求Aを支持し、別のエージェントが要求Bを支持し、議論を通じてコンフリクトを可視化できます。
3. 規格準拠のチェック
ISO 26262、SOTIF（ISO 21448）、IEC 61508などの規格が要求する事項に対して、各要求がどの程度準拠しているかをエージェントが評価します。ただし、これはあくまで「一次スクリーニング」であり、最終判断は人間のドメインエキスパートが行う前提です。
実際にやってみて感じた課題
研究としてこのアプローチを試みる中で、いくつかの現実的な課題が見えてきました。
LLMの判断のばらつき
同じ要求を同じプロンプトで評価しても、LLMの出力は毎回微妙に異なります。特にGPT-4oとClaude 3.5とGeminiでは評価傾向がかなり違います。これをどう扱うかは、まだ研究コミュニティでも議論が続いています。
対策のひとつとして、複数モデル間のクロスバリデーションや、多数決ベースの合意形成メカニズムが考えられます。
ドメイン知識の注入
汎用LLMは、ISO 26262のASILレベルの定義くらいは知っていますが、特定の製品ドメイン（例：パーソナルモビリティの転倒リスク）の深い知識は持っていません。RAG（Retrieval-Augmented Generation）で規格文書や過去の事故レポートを注入する必要がありますが、チャンク分割やretrievalの精度が品質に直結します。
評価の信頼性
「LLMが要求の品質を正しく評価できるのか」という根本的な疑問があります。人間のエキスパートの評価と比較した定量的な検証が不可欠で、ここを避けて通ると実用上の信頼は得られません。
既存ツールとの住み分け
| ツール | 得意なこと | 苦手なこと |
|---|---|---|
| DOORS / Jama / Polarion | トレーサビリティ管理、ベースライン管理 | 意味的な品質分析 |
| NLP系の既存研究 | 曖昧語の検出（"appropriate", "etc."） | 文脈を踏まえた総合判断 |
| LLMマルチエージェント | 多角的な意味分析、コンフリクト検出 | 大規模要求セットの処理速度、コスト |
現実的には、DOORSなどの既存ツールからエクスポートした要求に対して、LLMベースの分析を補助的にかける、という使い方が最も実用的だと考えています。
今後の展望
この分野はまだ黎明期ですが、以下の方向性が見えています。
ベンチマークの整備： 要求工学タスクに対するLLMの性能を客観的に測るためのベンチマークデータセットが必要です。NLPの世界ではGLUEやSQuADがありますが、REにはまだそれに相当するものがありません。
人間との協働設計： LLMがすべてを自動化するのではなく、エンジニアの意思決定を支援する「Co-Pilot」型のインタラクション設計が鍵になります。
産業界での実証： 自動車やロボティクスなど、実際の安全関連プロジェクトでのケーススタディを積み重ねることが、技術の成熟には不可欠です。
おわりに
LLMマルチエージェントによる要求工学の自動化・支援は、まだ研究段階ですが、安全関連システムの開発プロセスを大きく変える可能性を持っています。
もし同じような課題感を持っている方がいれば、ぜひコメントやDMで意見交換できればと思います。特に、実際の現場でどのような要求工学の課題に直面しているかを聞かせていただけると、研究としても非常に参考になります。
筆者について： 早稲田大学でソフトウェア工学を研究している博士課程の学生です。LLMを活用した要求工学の自動化に取り組んでいます。本記事の背景となる体系的文献レビュー（SLR）を発表していますので、より詳しく知りたい方はこちらをご参照ください：Generative AI for Requirements Engineering: A Systematic Literature Review (Wiley SPE, 2026) https://doi.org/10.1002/spe.70029