はじめに
前回の記事では、安全関連システムの要求工学にLLMマルチエージェントを使うアプローチについて、研究側の視点から整理しました。今回はもう少し現場寄りに、Automotive SPICE（以下ASPICE）のSYS.2という具体的なプロセスを起点に、どこまでが自動化の対象になり、どこからが人の仕事として残るのかを整理してみます。
「AIで要求レビューを効率化」という話は増えていますが、実際にアセスメントを受ける立場からすると、知りたいのは「何ができるか」ではなく「自分たちがやらなければならないことのうち、どれが機械に任せられるのか」だと思います。本記事はその整理を目的としています。
なお本記事はPAM 4.0を前提としています。3.1をお使いの現場も多いと思いますので、対応関係にも触れます。
SYS.2で何が変わったのか
ASPICE 4.0でSYS.2（System Requirements Analysis）のベースプラクティスは、3.1の8項目から6項目に統合されました。
| BP | 内容 |
|---|---|
| BP1 | システム要求の規定 |
| BP2 | システム要求の構造化 |
| BP3 | システム要求の分析 |
| BP4 | システムコンテキストへの影響分析 |
| BP5 | 一貫性の確保と双方向トレーサビリティの確立 |
| BP6 | 合意されたシステム要求と影響の伝達 |
注目したいのはBP5です。3.1では「双方向トレーサビリティの確立」と「一貫性の確保」が別々のBPに分かれていました。4.0ではこれが一本化されています。
これは単なる項目数の削減ではないと理解しています。トレースリンクが張られていることと、リンクされた要求同士の内容が矛盾していないことは、別の話である——この二つを分けて評価すること自体に無理があった、というメッセージだと読めます。
そして、この「リンクはあるが内容が食い違っている」という状態こそが、現場で最も検出しにくく、かつアセスメントで指摘されやすい部分ではないでしょうか。
BPごとに、自動化の余地を分けて考える
各BPについて、機械にどこまで任せられるかを三段階で整理してみます。
| BP | 内容 | 自動化 | 補足 |
|---|---|---|---|
| BP1 | システム要求の規定 | ✗ | 何を要求として立てるかは技術判断そのもの |
| BP2 | 要求の構造化・優先度付け | △ | グルーピング候補の提示は可能。優先度判断は人 |
| BP3 | 要求の分析 | ○ | 検証可能性・曖昧性・相互依存の抽出は機械向き |
| BP4 | システムコンテキストへの影響分析 | △ | 影響範囲の候補抽出は可能。妥当性評価は人 |
| BP5 | 一貫性とトレーサビリティ | ○ | 本記事の主題。ただし後述の条件付き |
| BP6 | 合意された要求の伝達 | ✗ | プロセスと組織の問題であり、ツールの話ではない |
まずBP1とBP6は自動化の対象外だと考えています。BP1は「システムに何を求めるか」を決める行為そのもので、これを機械に任せるという話は、少なくとも安全関連システムの文脈では成立しません。BP6も同様で、合意形成と伝達はプロセス設計の問題です。ツールが出力を出したところで、それが関係者に伝わり合意されたことにはなりません。
「AIで全部できます」という説明を見かけることがありますが、SYS.2の6つのBPのうち2つは、そもそも機械の仕事ではないと整理しておいたほうが、現場での議論は進めやすいと思います。
自動化の余地が大きいのはBP3とBP5です。以下ではBP5に絞ります。
「一文ずつのチェック」では届かない範囲がある
要求品質の自動チェックツールは既に複数存在します。曖昧語（"appropriate", "as necessary", "etc."）の検出、受動態の指摘、単位の不統一、EARSやINCOSEガイドラインへの適合——このあたりは成熟した領域です。
ただし、これらの多くは一つの要求文を単位として評価する設計になっています。文単位の評価で検出できる欠陥は確かに多いのですが、BP5が求める「一貫性」は、その外側にあります。
文単位のチェックでは原理的に見つからない不整合として、少なくとも次の四類型があると考えています。
1. 文書をまたいだ条件の矛盾
第3章に書かれた動作条件と、第7章に書かれた制約条件が両立しない。個々の文はどちらも明確で、曖昧語も含まれておらず、単独では何の問題も検出されません。
2. 上位要求と下位要求の内容的な断絶
トレースリンクは正しく張られている。しかしリンク先の下位要求が、上位要求の意図を満たしていない、あるいは範囲を超えている。トレーサビリティマトリクス上は完璧に見えます。
3. 用語のドリフト
同じ概念が、文書間・章間で異なる語で書かれている。あるいは同じ語が異なる意味で使われている。用語集があっても、運用の中で徐々にずれていきます。
4. 暗黙の前提の不一致
明文化されていない前提が、書き手によって異なる。これは要求文をいくら精読しても現れず、実装フェーズで初めて表面化します。
いずれも、複数の要求を横断して意味を突き合わせないと判定できないという共通点があります。
実例：条件の重なりが見えなくなるケース
実際のプロジェクトから、内容を抽象化・改変した例を挙げます。パーソナルモビリティ機器の仕様を想定してください。
ステークホルダ要求として、次のような記述があるとします。
STK-014: 本機は、路面勾配が緩やかな一般的な歩道環境において、搭乗者が安定した走行を維持できること。
これを受けたシステム要求が、別の章に二つ存在します。
SYS-102: 本機は、勾配5度以下の路面において、最高速度20 km/hでの走行時に車体姿勢を維持すること。
SYS-231: 走行速度が15 km/hを超える場合、本機は姿勢制御モードを高速モードへ遷移させること。高速モードでは勾配3度を超える路面での走行を許可しない。
三つの文はそれぞれ明確で、曖昧語もなく、単位も統一されています。文単位のチェックでは何も検出されません。トレースリンクもSTK-014から両方に正しく張られているとします。
しかし横断して読むと、15〜20 km/hかつ勾配3〜5度という条件領域で、SYS-102とSYS-231が矛盾しています。SYS-102はその領域での姿勢維持を要求し、SYS-231はその領域での走行を許可していません。
この種の不整合が厄介なのは、次の点です。
- 各文が独立して見れば正しいため、文単位のレビューでは通過する
- 章が離れているため、人間のレビューでも同時に視界に入りにくい
- 数値の重なりを人手で網羅的に確認するのは、要求が数百件規模になると現実的でない
- 実装段階では「どちらの仕様が正か」で議論が発生し、手戻りになる
そして、これはまさにBP5が「一貫性」として求めているものです。トレーサビリティは満たされているのに、一貫性は満たされていない。4.0でこの二つが同じBPに統合された理由が、こういうところにあるのだと思います。
検出できるだけでは足りない
ここからが、実際に使えるかどうかの分かれ目だと考えています。
上記のような不整合をツールが指摘したとして、アセスメントの場で問われるのは「ツールが何と言ったか」ではなく、「あなたたちがどう判断したか」です。スコアや警告フラグだけを出力するツールは、この問いに答えられません。
必要なのは、次のような形の出力だと考えています。
- どの要求とどの要求が対象なのか
- どの条件領域で矛盾するのか（上の例なら「15〜20 km/h かつ 勾配3〜5度」）
- なぜそう判断したのか、その推論過程
- 判定の確信度と、人間が確認すべき点
つまり根拠を含めて出力し、その根拠を人間が検証できる形で残すことです。これは技術的な好みの問題ではなく、規格準拠を証明する立場からの要請だと思います。
複数のLLMエージェントに議論させるアプローチに研究として取り組んでいるのも、この点が理由です。単一のモデルに判定させると出力は結論だけになりがちですが、異なる立場のエージェントが主張と反論を交わす構成にすると、その過程自体が根拠の記録になります。
もっとも、前回の記事でも書いたとおり、LLMの判断のばらつきや、ドメイン知識の不足といった課題は依然として残っています。現時点では一次スクリーニングとして使い、最終判断は人間が行うという位置づけが妥当だと考えています。
自動化できない部分をどう設計するか
BP1とBP6が機械の仕事ではない、と書きました。では自動化の対象外の部分をどう扱うか。
現実的には、既存のレビュープロセスを置き換えるのではなく、その入力を変えるという形が良いのではないかと思っています。
- レビュー会議の前に、横断的な不整合候補を機械的に抽出しておく
- 会議では、その候補リストの妥当性判断と、抽出されなかった部分の議論に時間を使う
- 判断結果と根拠を、そのままトレーサビリティの記録に残す
要求管理ツールを新しく導入する話にはしない、というのも重要だと考えています。DOORS、Polarion、Jamaを使っている現場もあれば、Excelで管理している現場もあります。どちらであっても、既存の運用の中に分析結果を戻せる形でないと、実際には使われないと思います。
おわりに
ASPICE SYS.2の6つのBPのうち、機械に任せられるのはBP3とBP5が中心で、BP1とBP6は対象外、BP2とBP4は部分的——というのが現時点での私の整理です。
そして自動化の余地が大きいBP5については、文単位のチェックでは届かない範囲があり、そこには要求を横断して意味を突き合わせる仕組みと、判断の根拠を残す仕組みの両方が必要になります。
この整理には異論もあると思います。特に、実際にアセスメントを受けておられる方から見て「そこは違う」という点があれば、ぜひコメントで教えていただけると嬉しいです。現場でSYS.2のどのBPが実際に負荷になっているのかを伺えると、研究としても非常に参考になります。
参考
- Automotive SPICE® Process Assessment Model v4.0（VDA QMC）
- 前回の記事: 安全関連システムの要求工学にLLMマルチエージェントを活用したら、何が変わるのか
筆者について
早稲田大学でソフトウェア工学を研究している博士課程の学生です。LLMを活用した要求工学の自動化に取り組んでいます。本記事の背景となる体系的文献レビュー（SLR）はこちらです：Generative AI for Requirements Engineering: A Systematic Literature Review (Wiley SPE, 2026) https://doi.org/10.1002/spe.70029