機能要件 / 非機能要件のVerifiability（検証可能性）を向上させるためのアプローチ

はじめに

2025年現在、システム開発現場において、システムの複雑性は引き続き増大しています。 マイクロサービス化、クラウドネイティブ化、そして頻繁な法改正対応など、開発現場に求められる要求は増加の一途をたどっているといって良いでしょう。 こうした状況下で重要なのが「検証可能性（Verifiability）」の確保です。

従来、検証可能性は「テストが書ける設計になっているか」という設計論の文脈で語られることが多くありました。 しかし、現代の実装規模は、人間が手動でテストケースを網羅できる限界を超えています。 機能要件はもちろんのこと、セキュリティや性能といった非機能要件の検証は、リリースの直前までブラックボックス化しやすい傾向にあります。

本レポートでは、生成AI（Generative AI）およびLLM（Large Language Models）を単なるコード生成ツールとしてではなく、「検証プロセスそのものを変革するエンジン」として位置づけます。 ISO/IEC 25010に基づく品質モデルを再整理し、AIエージェントを用いた自律的なテストや、高度なコードレビューを通じて、いかにして検証可能性を向上させるか、その具体的アプローチと組織導入のロードマップを提示します。

そもそも検証可能性（Verifiability）とは何か

システム開発における「検証可能性（Verifiability）」とは、構築されたシステムやソフトウェアが、事前に定義された要件（仕様）や期待される動作を満たしているかどうかを、客観的な手段によって確認できる能力や度合いを指します。

ソフトウェアエンジニアリングの世界には「検証できない要件は、要件ではない」という言葉があります。

例えば、要件定義書に「ユーザーにとって使いやすい画面にする」や「高速に処理する」といった記述があったとします。 これらは主観的であり、開発者が実装を完了したとしても、それが本当に達成されたのかを客観的に判定することができません。

一方で、「特定の操作を3クリック以内で完了できること」や「99パーセンタイルのリクエストに対して1秒以内に応答すること」といった記述であれば、テストによって明確に合否を判定できます。

このように、要件自体が具体的で測定可能であるかどうかが、検証可能性の第一歩です。

しかし、現代の文脈における検証可能性の課題は、単なる要件記述の曖昧さだけにとどまりません。

システムの実装構造における「テスト容易性（Testability）」と、検証プロセスの「実行可能性」が密接に関わっています。

検証可能性を確保するためには、システム自体がテストしやすい構造で作られている必要があります。

これをテスト容易性と呼びます。 内部状態を外部から観測できるためのログ出力やAPI、コンポーネント間の結合度の低さ（モジュール性）などが確保されていなければ、いかに要件が明確でも、実際にそれを検証するコストが無限大に膨れ上がってしまいます。

クラウドネイティブなアーキテクチャやマイクロサービスの普及により、システムはかつてないほど複雑化しました。 単体レベルでは正常に動作していても、複数のサービスが連携した際の複雑なエッジケースや、特定のタイミングでしか発生しない競合状態（レースコンディション）など、人間が事前にテストケースとして想定しきれない領域が増大しています。

つまり、現代における検証可能性の低下とは、「要件は定義されているが、その組み合わせが膨大すぎて、限られたリソースと時間では事実上確認（検証）が不可能になっている状態」を指します。

この「検証の空白」を放置することは、本番環境での障害リスクを許容することと同義であり、開発組織にとって看過できない経営リスクとなっています。

したがって、本レポートで扱う検証可能性の向上とは、単にテストケースを増やすことではなく、AI等の技術を用いてこの膨大な検証空間を効率的に探索し、システムの挙動に対する説明責任（Accountability）を取り戻すプロセスを意味します。

現代のシステム開発における検証可能性の課題とボトルネック

開発プロセスにおいて、検証可能性の向上を阻害している要因は複合的です。 多くの現場では、V字モデルの右側（テスト工程）で品質を作り込もうとするあまり、以下のような構造的な欠陥を抱えています。

人的リソースに依存した網羅性の限界

機能要件の検証（単体テスト、結合テスト）において、Excelベースのテスト仕様書と手動実行がいまだに主流である現場は少なくありません。 この手法では、正常系の検証に手一杯で、異常系や境界値（エッジケース）の検証がおろそかになりがちです。 結果として、本番環境で予期せぬデータが入力された際にエラーが発生するリスクが残ります。

非機能要件検証の後回しと専門家不足

ISO/IEC 25010で定義される「セキュリティ」や「性能効率性」などの非機能要件は、高度な専門知識を要します。 セキュリティ診断や負荷テストを実施できるエンジニアは組織内で希少であり、開発サイクルの最終盤にボトルネックとして顕在化します。 「検証したくても、検証できる人が空いていない」という状況が、検証可能性を著しく低下させています。

承認プロセスの形骸化

コードレビューや設計レビューにおいて、レビュアーは大量のドキュメントやコードを短時間で確認することを強いられています。 これにより、レビューが「形式的な承認」となり、論理的な矛盾や潜在的なバグ（検証漏れ）が見過ごされるケースが発生する可能性があります。

ISO/IEC 25010に基づく機能要件・非機能要件とAI適用の整理

システム品質を体系的に捉えるために、国際規格であるISO/IEC 25010（システム及びソフトウェア製品品質モデル）を参照します。 各品質特性に対し、従来の検証課題と生成AIによる解決アプローチをマッピングすると、以下のようになります。

参考：https://webdesk.jsa.or.jp/books/W11M0090/index/?bunsyo_id=JIS+X+25010%3A2013

この表からもわかる通り、AIは特に、人間が苦手とする「大量パターンの網羅」や「多角的な視点でのチェック」において威力を発揮します。

生成AI・LLMを活用した検証可能性向上のための具体的アプローチ

前述の課題を解決するため、開発プロセスにAIを深く統合する3つのアプローチを提案します。

ソースコード生成とAIエージェントによるテスト自動化

アプローチの概要 GitHub CopilotやCursorなどのAIコーディングアシスタントの利用を超え、テストコードの生成と実行を半自律化させます。 ここでは「実装を見てテストを書く」だけでなく、「テストコード自体をAIに生成させ、TDD（テスト駆動開発）を加速させる」手法を含みます。

具体的な手法

• Property-based Testingの自動生成: 具体的な値によるテスト（Example-based）だけでなく、データの性質（型、範囲、不変条件）に基づいたランダムテスト（Property-based Testing）のコードをAIに生成させます。例えばPythonのHypothesisライブラリなどを用いた複雑なテストケースを、AIは仕様の記述から高速に構築できます。

• Legacy Codeへのテスト追加: 仕様書が存在しない、あるいは古いレガシーコードに対し、LLMにコードを読ませて「現在の挙動」を正とする回帰テスト（Regression Test）を一括生成させます。これにより、リファクタリング時の安全網（検証可能性）を即座に構築できます。

効果 C0（命令網羅）/C1（分岐網羅）カバレッジの向上だけでなく、人間が想定しづらい境界値条件におけるバグを早期に発見可能になります。

LLMを活用した高度なコードレビュー（Code Review）と静的解析

アプローチの概要 人間によるコードレビューの負担を軽減し、質を向上させるために、LLMを「最初のレビュアー」としてパイプライン（CI/CD）に組み込みます。CodeRabbitなどのサービスや、GitLab/GitHub Actions上で動作するカスタムスクリプトがこれに該当します。

具体的な手法

• Chain-of-Thought（思考の連鎖）による論理検証: 単に「バグがないか」を問うのではなく、「この変更によって、認証機能のセキュリティ要件（ISO 25010 セキュリティ）が損なわれる可能性について、攻撃者の視点でステップバイステップで検討せよ」といったプロンプトエンジニアリングを適用した自動レビューを実施します。

• 可読性と保守性のスコアリング: 変数名の適切さ、関数の長さ、ネストの深さなどを解析し、将来的なメンテナンスコスト（保守性）への懸念を指摘させます。人間関係に配慮する必要のないAIは、忖度のない客観的な指摘を行うことができます。

効果 レビュー待ち時間の短縮と、レビュアーの疲労軽減により、人間はより本質的な「設計思想の整合性」や「ビジネスロジックの妥当性」の検証に集中できるようになります。

Agentic Testによるプロダクション環境の自律的検証

アプローチの概要 従来のE2Eテストツール（Selenium/Playwright）は、セレクタの変更で壊れやすく、メンテナンスコストが高いという課題がありました。「Agentic Test（エージェント型テスト）」は、GPTやGeminiのような視覚情報（Vision）を処理できるモデルを用い、人間と同じようにGUIを見て操作を行う手法です。

具体的な手法

• 自律的な探索テスト: 「ECサイトで購入フローを完了させる」というゴールだけをAIエージェントに与えます。エージェントは画面上の要素を認識し、自律的にクリックや入力を試行します。途中で予期せぬポップアップやレイアウト崩れ（使用性の欠陥）が発生した場合、スクリーンショットと共にレポートします。

• 外形監視の高度化: 定期的に本番環境を巡回し、「表示崩れ」「不適切な画像の表示」「翻訳ミス」などを視覚的に検知します。DOM構造が変わっても、見た目が人間にとって正しければテストを通過させるなど、柔軟な検証が可能です。

効果 厳密なスクリプト記述が不要になるため、UI変更に強いテスト環境が構築できます。また、使用性（Usability）や快美性といった、これまで定量化が難しかった領域の検証が可能になります。

SIerの組織課題を乗り越えるためのAI駆動開発導入ステップ

技術的な有効性が明らかでも、セキュリティ要件や組織の硬直性により導入が進まないケースがあります。以下のステップでの導入を推奨します。

セキュリティリスクを考慮したローカル/プライベートLLMの活用

顧客データの流出を懸念する場合、パブリックなAPI利用は制限されます。 Azure OpenAI Serviceのようなプライベートエンドポイントを持つ環境や、AWS Bedrock、あるいは社内サーバー上のOllama等で動作するローカルLLM（Llama 3等）を活用します。 まずはインターネット遮断環境での「コード生成・解説」から開始し、現場の心理的ハードルを下げます。

既存プロセスへの「アドオン」形式でのAI導入

既存の開発フローを破壊せず、BotとしてAIを追加します。 例えば、Pull Requestが作成されたら自動的にAIがコメントをつける、Slackに障害通知が来たらAIが一次切り分けを行うなど、「人間の作業をAIが補助する」形をとります。 これにより、既存の品質管理規定を変更することなく、実質的な検証品質を向上させることができます。

社内リソース育成とナレッジ蓄積（RAG）

各プロジェクトで発生したバグ票や設計書をベクトルデータベースなどに蓄積し、RAG（Retrieval-Augmented Generation）システムを構築します。 「過去の類似プロジェクトで発生した性能トラブル」をAIが提示できるようにし、組織全体での検証ノウハウの属人化を解消します。

まとめ

本レポートでは、ISO/IEC 25010の品質モデルを軸に、機能要件・非機能要件の検証可能性を向上させるためのAI活用アプローチを論じました。

ソースコード生成によるテストのカバレッジ向上、AIレビュアーによる静的解析の高度化、そしてAgentic Testによるユーザー視点の検証は、従来トレードオフの関係にあった「品質」と「速度」を両立させる鍵となります。 AI駆動開発へのシフトは、単なる工数削減の手段ではありません。それは、複雑化するシステムに対し、人間が制御可能な「検証可能性」を取り戻し、確信を持ってソフトウェアをリリースするための必須の進化です。 今こそ、手動検証の限界を認め、AIをパートナーとした新たな品質保証プロセスへと舵を切る時です。