はじめに
早稲田大学の博士課程で、LLM ベースのマルチエージェントシステムを要求工学（Requirements Engineering）に応用する研究をしています。
最近、自動車業界のエンジニアリング現場で要求レビューがどのように行われているかを知りたくて、LinkedIn で MBSE（Model-Based Systems Engineering）に詳しい方に質問してみました。「要求レビューの現状や課題を教えてください」という漠然とした質問に対して、とても示唆に富んだ回答をいただいたので、自分の理解を整理するためにまとめます。
この記事は、いただいた助言を筆者なりに解釈したものです。解釈の誤りがあれば、それは筆者の責任です。
いただいた助言の要点
一言でまとめると、次のような考え方でした。
テキストのままの要求は、それだけでは十分にレビューできない。振る舞いとアーキテクチャに変換し、その写像がうまくいかない箇所に要求の異常が現れる。
もう少し分解すると、以下の流れです。
- 単なる文字列である要求を、振る舞いの要素に変換する
- MBSE であれば、要求 → ユースケース → アクティビティ、と変換し、アクティビティ図（act）で要求を振る舞いとして表現する
- アーキテクチャで静的な設計を定義し、アーキテクチャ要素を特定する
- act で表現した要求を、特定したアーキテクチャ要素を使ってシーケンス図（sd）で検証する
- act は上位設計、sd は詳細設計に相当する
- act に現れるトークン（オブジェクトトークンとコントロールトークン）を、sd 上のメッセージに変換する
- この変換ができない場合、要求・ユースケース・アクティビティ・アーキテクチャ・相互作用のどこかに異常がある
また、参考になる規格として ISO/IEC/IEEE 29148 と IEEE 1028 を教えていただきました。
具体例で考える：車速によるドアの自動ロック
抽象的な話だけだとわかりにくいので、簡単な例で追ってみます。
Step 1：テキストの要求
車速が 15 km/h を超えたら、ドアを自動でロックする。
一見、特に問題はなさそうです。
Step 2：振る舞いに変換する（アクティビティ）
この要求を、動作の流れとして書き出します。
ここで各ステップの間を流れているのがトークンです。
- オブジェクトトークン：「車速の値」のようなデータ
- コントロールトークン：「次のステップを実行してよい」という制御の流れ
Step 3：アーキテクチャ要素を特定する
システムが以下の要素で構成されているとします。
- 車速センサ
- ボディ制御 ECU
- ドアロックアクチュエータ
Step 4：トークンをメッセージに写像する（シーケンス）
アクティビティの各動作を担当する要素を割り当て、要素間のメッセージとして表現します。
act 上のトークンが、sd 上のメッセージに一つずつ対応していれば、少なくともこの範囲では要求と設計は整合しています。
Step 5：写像できないところに異常が現れる
実際にこの写像を試みると、テキストを読むだけでは見落としがちな問題が出てきます。
| 写像で詰まるところ | 示唆される異常 |
|---|---|
| 車速を提供する要素がアーキテクチャにない | アーキテクチャの欠落、または要求が存在しない前提に依存している |
| 車速が下がったとき、乗員がドアを開けようとしたときの振る舞いが描けない | 要求の不完全さ |
| ロック指令を出せる要素が複数あり、どちらが担当か決まらない | 設計の曖昧さ、競合の可能性 |
| 「15 km/h を超えた」の判定周期やヒステリシスが決まらない | 要求の曖昧さ、検証可能性の欠如 |
ポイントは、これらの問題がレビュアーの勘や経験で見つかるのではなく、写像という作業の過程で構造的に浮かび上がることです。
参考になる規格
教えていただいた規格を簡単にメモしておきます。
- ISO/IEC/IEEE 29148：要求工学のプロセスと、良い要求が持つべき特性（曖昧でない、完全である、一貫している、検証可能である など）を定めた規格
- IEEE 1028：ソフトウェアのレビューと監査（マネジメントレビュー、技術レビュー、インスペクション、ウォークスルー、監査）の進め方を定めた規格
LLM で要求レビューを自動化する研究でも、「何をもって良い要求とするか」「レビューをどう進めるか」をこれらの規格に対応づけておくと、工業界の方に説明しやすくなりそうです。
LLM による要求レビューへの示唆
ここからは、自分の研究に引きつけて考えたことです。
1. テキストだけを読む LLM レビューの限界
LLM に要求文書を読ませて問題点を指摘させるアプローチは、手軽で一定の効果があります。しかし、今回の助言に照らすと、それは人間がテキストを読んで勘で指摘するのと本質的に同じです。
特に LLM の場合、もっともらしいけれど根拠のない指摘（いわゆるハルシネーション）が混ざるという問題もあります。
2. モデルを「根拠」として使う
一方で、要求を振る舞いモデルに変換し、アーキテクチャとの写像を試みるというプロセスは、指摘に検証可能な根拠を与えてくれます。
「この要求は曖昧だと思います」ではなく、「この要求の act 上のトークンを、sd 上のどのメッセージにも写像できません」と言えるのは、エンジニアにとって受け入れやすい指摘です。
3. マルチエージェントへの組み込み案
筆者は、複数の LLM エージェントが議論し、反論し合いながら要求の問題を見つける仕組みを研究しています。今回の助言から、次のような拡張を考えています。
- モデリング担当エージェントが、テキスト要求からユースケース・アクティビティ・シーケンスの草案を生成する
- レビュー担当エージェントは、テキストから直接指摘するのではなく、写像に失敗した箇所を根拠として指摘する
- 写像の成否を、指摘の信頼度を評価する手がかりとして使う
小さな実験としては、既存の要求データセットから数十件を選び、LLM にアクティビティとシーケンスの草案を生成させ、写像に失敗した箇所と人手でラベル付けされた欠陥がどの程度重なるかを確かめてみたいと考えています。
まだわからないこと
今回の助言は「要求レビューはどうあるべきか」という方法論の視点でした。一方で、実際の現場で次のような点がどうなっているかは、まだわかっていません。
- 実際のプロジェクトで、この変換プロセスのどこが一番難しいのか（元の要求の品質、成果物間の一貫性維持、トレーサビリティ、手作業のレビュー工数など）
- テキスト中心で要求を管理している現場で、モデルへの移行はどの程度進んでいるのか
この点についても引き続き現場の方にお話を伺っていく予定です。わかったことがあれば、また記事にまとめます。
おわりに
「要求レビュー」というと、文書を読んで問題を探す作業をイメージしがちでした。しかし今回、要求を振る舞いとアーキテクチャに落とし込み、写像できない箇所を異常として扱うという考え方を知り、レビューを構造的な一貫性検証として捉え直すきっかけになりました。
快く知見を共有してくださった方に、改めて感謝いたします。
参考
- ISO/IEC/IEEE 29148: Systems and software engineering — Life cycle processes — Requirements engineering
- IEEE 1028: IEEE Standard for Software Reviews and Audits