はじめに

これまでの記事では、安全関連システムの要求に対してLLMをどう使うかを、研究側とASPICE側の двух視点から整理してきました。今回は少し性質が違って、まだ結論の出ていない仮説を書きます。

要求工学では長らく、曖昧性（ambiguity）は「検出して潰すべき欠陥」として扱われてきました。私自身もそう考えて手を動かしてきたのですが、LLMを要求分析のパイプラインに入れて出力を眺めているうちに、順序が逆かもしれないと思うようになりました。

曖昧なまま残っている要求より、LLMによって過剰に確定的な形へ書き換えられた要求のほうが、レビューをすり抜けやすく、後段への影響が大きいのではないか——という話です。

実験的な裏付けはまだありません。問題提起として読んでいただき、現場の感触をいただけると嬉しいです。

従来の前提：曖昧性は「潰すもの」だった

ISO/IEC/IEEE 29148が要求に求める性質のひとつに「明確であること（unambiguous）」があります。実務でも、曖昧語リストによるチェックは要求品質保証の定番です。

程度が定量化されていない語：速やかに 適切に 十分な 必要に応じて
主語や対象が不明確な受動態
範囲が閉じていない列挙：など その他

この考え方の前提は、曖昧な文は下流で誤解される、というものです。だから上流で潰しておく。これは正しい前提だと思いますし、今も有効です。

ただしこの前提には、暗黙にもう一つの仮定が乗っています。曖昧な文は、曖昧なまま下流に流れていくという仮定です。LLMを間に挟むと、この仮定が崩れます。

LLMは、曖昧性を「保存しない」

要求分析にLLMを使うとき、多くの場面で私たちは上位要求から下位要求を導出させたり、要求からテスト観点を起こさせたりします。このとき、入力に曖昧な文が含まれていても、LLMは「この要求は曖昧なので判断できません」とは返してきません。

代わりに、もっともらしい具体値を補完した出力を返します。

たとえば、こういう上位要求があったとします。

STK-021: 車両は、走行中に異常を検知した場合、速やかに安全な状態へ移行すること。

これに対してLLMに下位要求を導出させると、こういうものが出てきます。

SYS-118: システムは、異常検知後 500 ms 以内に減速制御を開始すること。
SYS-119: システムは、減速度 3.0 m/s² 以下で目標停止位置まで車両を減速させること。

文としては何の問題もありません。定量的で、検証可能で、曖昧語も含まれていません。曖昧性チェッカーは当然これを通します。トレーサビリティも STK-021 → SYS-118, SYS-119 として正しく張れます。

問題は、500 ms と 3.0 m/s² がどこから来たのかを、誰も説明できないことです。

原文に根拠はありません。ステークホルダーが決めた値でもありません。学習データ上「それらしい」値が、確定した仕様として出力されただけです。そしてその出自は、出力を見ただけでは判別できません。

これを私は暫定的に「過剰確定（false determinism）」と呼んでいます。曖昧性が解消されたのではなく、曖昧性が可視性を失ったまま埋め込まれた状態です。

なぜ「曖昧なまま」より危ないのか

ここが本題です。曖昧な要求文には、欠陥であると同時に、実は機能もありました。

曖昧さは、レビューの起点として働いていた、ということです。

「速やかに、って何秒ですか」——この一言がレビュー会で出ることによって、ステークホルダーへの確認が走り、値が決まり、その決定が議事録なり要求属性なりに残ります。曖昧な文は、読んだ人を立ち止まらせる力を持っていました。

500 ms と書かれた文は、誰も立ち止まらせません。むしろ「よく書けている要求」として通過します。レビュアーの認知負荷は、曖昧な文より確定的な文のほうが低いからです。

つまり、こういう非対称が生まれます。

	曖昧なまま残った要求	LLMが確定させた要求
品質チェック	検出される	通過する
レビュー会での挙動	議論を誘発する	議論を誘発しない
根拠の所在	「未決定」として明示的	出力に埋没して不可視
下流への伝播	決まるまで止まる	そのまま設計・テストへ流れる

安全関連システムでは、この差が効いてきます。ISO 26262の文脈でセーフティケースを構成するとき、要求値そのものより「その値がどういう根拠で決まったか」が問われます。ハザード分析の結果から導かれた値なのか、規格の要求なのか、実測に基づくのか。この鎖のどこかが「LLMが出したので」で埋まっていると、論証としては成立しません。

そして厄介なのは、その事実が成果物の見た目には一切現れないことです。

検出が難しい理由

この問題が、既存の品質保証の枠組みで捉えにくい理由を整理しておきます。

1. 文単位の品質チェックでは原理的に検出できない
500 ms 以内に減速制御を開始すること は、単体で見れば模範的な要求文です。曖昧語がなく、定量的で、検証可能です。チェック対象が文の内部にある限り、この文は無傷で通ります。

2. トレーサビリティも成立してしまう
上位要求へのリンクは張れます。リンクの存在は、リンク先の内容が上位要求から導出可能であることを保証しません。前回の記事でBP5について書いたのと同じ構造です。

3. 比較対象が残っていない
原文の 速やかに が、いつ、何によって 500 ms に置き換わったのかは、最終成果物からは追えません。差分が記録されていない限り、確定は起きなかったことになります。

要するに、見るべき場所が成果物の中ではなく、成果物が作られる過程のほうにある、というのがこの問題の性質だと考えています。

実務でできそうなこと

仮説段階なので処方箋というより、試す価値がありそうな方向として書きます。

出力に「根拠の出所」を必ず併記させる
下位要求を生成させるとき、各要求に 導出根拠 の欄を強制し、そこに「原文の記述」「規格の条項」「モデルによる補完」のいずれかを明示させる。三つ目が付いた要求だけを人が見る、という運用にできます。実際にやってみると、想像より三つ目が多いです。

不確実性を潰さずに出させる
「最も適切な値を一つ出せ」ではなく「取りうる解釈を列挙し、それぞれの前提を書け」と指示する。曖昧性を解消させるのではなく、曖昧性を展開させる方向のプロンプト設計です。決めるのは人の仕事として残します。

原文にない具体値を差分としてハイライトする
上位要求のテキストに出現しない数値・単位が下位要求に現れたら、機械的にフラグを立てる。単純ですが、これだけでレビューの視線をかなり誘導できます。

曖昧語検出の意味づけを変える
曖昧語を「削除すべき欠陥」ではなく「人が決定すべき箇所のマーカー」として扱う。潰した瞬間に、そこが決定ポイントであった記録も消えます。決定が済むまでは、曖昧なまま持っておくほうが安全な場合があります。

まだ分かっていないこと

正直に書いておきます。以下はいずれも未検証です。

この現象がどの程度の頻度で起きるのか（モデル・タスク・プロンプトによる差）
経験のあるレビュアーが、確定的な出力の中の「根拠のない値」に気づけるのか
気づける場合、何が手がかりになっているのか
そもそも曖昧性がレビュー誘発として機能しているという前提自体が、どこまで一般的なのか

特に二つ目は、人を対象にした実験が必要な部分で、簡単ではありません。

おわりに

「LLMで要求を明確化できます」という話は増えていますが、明確化されたものが何によって明確化されたのかは、あまり議論されていない気がしています。曖昧さの解消と、曖昧さの隠蔽は、成果物の見た目が同じです。

現場で似た経験——生成された要求がきれいすぎて逆に不安になった、レビューで数値の出所を聞いたら誰も答えられなかった、など——をお持ちの方がいれば、ぜひコメントで教えていただけると嬉しいです。仮説の精度を上げたいと思っています。

筆者について

要求工学におけるLLM活用を研究しています。生成AIと要求工学に関する体系的文献レビューを以下で公開しています。

Generative AI for Requirements Engineering: A Systematic Literature Review, Software: Practice and Experience (Wiley), 2026. https://doi.org/10.1002/spe.70029