「AIに正確に指示を出すために、要件定義をきちんとやる」――IPAが示す、AI時代に社会を支える要求工学

AIはコードを書く速度を一変させた。だが速くなったのは実装であって、曖昧なままの要件も同じ速度でシステムへ流れ込んでいく。6月11日に開催された「AI要件定義サミット2026」の最終セッションで、IPA（情報処理推進機構）デジタル基盤センター長の平本 健二氏が「AI社会における要件の定義や管理、そして要求工学へ」と題して登壇した。政府横断で日本のAIの安全性を見据えるAISI（AIセーフティ・インスティテュート）副所長も務める人物である。平本氏が描いたのは、ソフトウェアにとどまらず、ルールもデータも含む社会全体がAIの速度でアップデートし続ける世界像だ。その中で価値を生み続ける条件として示したのが、要件を正しく定義し、可視化する力だった。

そもそも要件とは何か――AI時代に問い直す原点

サミットの最終登壇者が選んだテーマは、最新のAI論ではなかった。専門家も多くつまらない話かもしれないが、と前置きしたうえで、平本氏があえて話を引き戻したのは、要求工学の原点だった。AIをめぐる議論が続いた一日の最後に、まず立ち返るべきは「そもそも要件とは何か」だという。

平本氏が並べてみせたのが、「要望・要求・要件」の三つである。要望は「木の下で楽しく過ごしたい」という漠然とした望み、要求は「枝にロープでぶら下がりたい」という具体的な欲求、そして要件は「吊るすロープは1本」「座るためにタイヤを使う」という、実現しなければならない事項を指す。題材は、ソフトウェア業界で長く語り継がれてきた「木のブランコ」の風刺画だ。発注者の望みが伝言の途中で歪み、できあがった製品が食い違う――その古典的な失敗を、要望から要件への翻訳という観点で読み解いた。

問題は、この翻訳が文章だけでは崩れやすいことにある。短い文章なら通じるが、長くなれば要件はたちまち曖昧になる。だからこそ平本氏が肝に据えるのが、図による可視化だ。平本氏が例に挙げたのは、欧州委員会の幹部級の行政官とデータモデルのクラス図を前に議論できたという経験である。標準的な記法であれば、専門外の相手とも構造をそのまま共有できる。「なんとなく図で書いてあるのではなく、誰もが共通理解できるものが必要になる」と平本氏は語る。要件定義のあり方は、人が読むための文書から、人にも機械にも読める形へと移りつつある。

日本のソフトウェア設計は、街の工務店に負けている

では、その可視化はどこまで根づいているのか。平本氏の見立ては厳しい。日本では要件定義も要件管理も職人芸にとどまり、引き継がれないまま属人化している。レガシー問題の根源もここにある、と平本氏は指摘する。なぜそのコードが書かれたのかが残らない――その原因が、要件定義の弱さだという。

数字もそれを裏づける。日本情報システム・ユーザー協会（JUAS）が約900社に尋ねた調査では、要件定義など上流工程の能力が「充足している」とした企業は4社に1社にとどまり、「不足している」は半数を超えた。設計情報の多くは、いまもパワーポイントやエクセルといった文書ツールで管理されている。IPAのソフトウェア動向調査でも、業務プロセスや機能の設計にモデリングを使う企業はなお少数派だ。理由は人材不足とツールの費用。要件管理そのものにも不安が残る。

対して平本氏が引き合いに出したのは、街の工務店だ。かつてはドラフターで製図していた工務店も、いまやCADを入れていないところはない。正確で速いだけでなく、耐震シミュレーションまで回し、図面は専門外の施主にもそのまま伝わる。IT業界はみずからを洗練された存在と考えがちだが、設計の可視化やシミュレーションでは工務店のほうが先行している、と平本氏は問題提起した。要件定義という一点では、IT業界が建設業に後れを取っているというわけだ。

なぜソフトウェアだけが遅れたのか。車や建物と違って完成物のイメージを共有しにくいうえ、人月で稼ぐ収益構造の下では、設計を効率化する動機が働きにくかった。では、その職人芸を脱する手立ては何か。

可視化を、個人依存から工学へ――モデリングと要求工学の基礎

平本氏が強調したのは、要件定義はひらめきではなく、枯れた技術だという点だ。要求工学には「獲得・分析・仕様化・評価・管理」という五つの柱がある。ISO/IEC/IEEE 29148などの国際規格に加え、BABOKやINCOSEのハンドブック・ガイドにも、要求を扱う手順が体系化されている。属人的に見える領域は、すでに体系として整理されている。

可視化には、UML、SysML v2.0、ArchiMate、ER図などの代表的なモデリング記法・手法がある。平本氏によれば、欧州ではER図に相当する用途でも、UMLのクラス図を用いるケースが多いという。記法が乱立しにくいぶん、共通理解を得やすい。誰が描いても同じ意味になる――それが標準記法の効きどころだ。

両者を分けるのは、お絵描きツールとモデリングツールの違いだ。モデリングツールは図の裏側にデータを持ち、矢印で結べる関係をルールで縛り、論理チェックやシミュレーションを回せる。たとえばBPMNで「1時間に6件の来客」を正規分布で流し込めば、所要時間や待ち時間をリリース前に試算できる。導入直後にコールセンターが詰まる、といった事故を未然に防げるわけだ。

残るのは費用への抵抗だ。だが平本氏はこう切り返す。「ワープロや表計算には金を払うのだから、作図ツールも買えばいい」。生産性も正確性も上がり、管理もしやすくなる効果は、ライセンス料を上回るという立場だ。しかも標準形式で書いておけば、M&Aや事業売却で相手のシステムを引き継ぐときも、図を渡すだけで構造が伝わる。要件定義は、社内の手続きから、企業をまたいで通用する共通言語になる。

社会はアップデートし続ける――なぜ今、要件定義なのか

ここで視点は、ソフトウェアの外側へ移る。平本氏はまず、AIを冷静に俯瞰すべきだと説いた。変化速度は加速し、技術はエージェントへと多様化し、システムどうしがつながって社会は複雑になる。一方で、法律も標準も人の意識も追いつかない。技術だけがジャンプアップし、制度との間に開いた溝こそが、大きなビジネスチャンスを生む。社会の仕組みを考える単位は、もはや年単位ではなく四半期だという。

平本氏の見取り図はこうだ。社会は建物や機械、システムといったエンジニアリングで構成され、法律や条例というルールで枠づけられ、データで駆動する。そしてAIが、その全体を加速させる。デジタルツインの時代には、あらゆるものがモデル化され、シミュレーションできる。

この世界では、更新が連鎖する。技術の更新がルールの更新を呼び、ビジネスや働き方まで巻き込んで、そのサイクルが速く回っている、と平本氏は説く。だからこそ、ルールも文字ではなくモデルで書けないかと問う。法律や社内規則を機械可読にするリーガルエンジニアリングである。要件定義の話は、いつのまにか社会制度の設計へとつながっているわけだ。

なぜ今、要件定義なのか。複雑さとスピードが増すほど、要件を可視化して確認と検証を素早く回す必要があり、事故が起きたときのトレースも速くなる。コンプライアンスの透明性も、可視化が支える。「プロンプトエンジニアリングも、一種の要求工学だ」。AIに何をどう求めるかを書く行為は、要件定義そのものだという見立てだ。

AIは万能ではない――実践のリアルと展望

AIは、要件の世界に何をもたらしたのか。平本氏は二つ挙げた。要求から一気にコードを生成できること、そして要求の検証がしやすくなったことだ。対話型のAIは、要求工学を知らない人でもある程度まで要件を整理し、既存システムをモデル化することもできる。ただし、話はそう単純ではない。要求工学が分かっていなければ、その出力が十分なのかを判断できない。

だからこそ要点は、AIの出力を「共通理解できる形」にすることにある。発注者と開発者が同じ図を見られるよう、標準的なモデルで吐き出させる。アジャイルのプロセスは、そこから始まる。バグが見つかっても、要件定義があれば影響範囲を素早く特定できる。逆にコードがスパゲッティ状態では、AIにパッチを作らせても修正は手探りになる。

AIの得手不得手も見えてきた。SNSや問い合わせから大量の要求を収集・分類する用途には活用しやすい一方、学習データに現れにくい新しい潜在要求は取りこぼすことがある。取引先の存在確認を尋ねれば、AIは登記簿謄本と答える。だが専門家なら、国の法人番号公表サイトやgBizINFOで保有特許まで引けると返す。光る原石を見つけるのは、まだ人間の役割だ。

「AIに正確に指示を出すことが重要だ。そう考えると、要件定義をきちんとやることが重要になる」。平本氏が描く到達点は、要求から要件へ、モデリングから実装へと回り続け、なお生きたまま管理される要件である。問われるのは、この可視化と標準化を現場で回る仕組みにまで落とせるかだ。モデリング人材の育成、ツールへの投資、そしてルールまで機械可読にするリーガルエンジニアリング。AIの速度に社会を追いつかせる条件は、技術の側ではなく、運用の側に残されている。