ADOPTION

AIの要件定義は、ふつうのシステムと何が違うか

AIを使うシステムの要件定義は、正解が一つに決まらないこと、精度の基準、データの用意、評価の方法、人の確認の入れ方、運用で直す前提を決める点で、ふつうのシステムと違います。決め方と、段階を分けて進める考え方を説明します。

この記事の要点

  • AIの要件定義では、機能に加えて、精度の基準・使うデータ・評価の方法を要件として決める
  • 誤りが出ることを前提に、人がどこで確かめるかと、作った後に直し続ける運用まで要件に入れる
  • 結果を見ながら要件を見直せるよう、段階を分けて進め、段階ごとに次へ進むかを判断する

AIを使うシステムの要件定義は、「何ができればよいか」を決める点ではふつうのシステムと同じですが、正しい出力を一つに決めにくいこと、精度の基準とデータが要件の一部になること、誤りと運用を前提にすることの3点で違います。作る前に決めきれない部分があるため、段階を分けて、結果を見ながら要件を見直す進め方が合っています。

要件定義の基本(業務の流れ・機能・画面・データ・非機能)は、要件定義で決めること:はじめての方へで説明しています。この記事では、AIを使うときに足すことに絞ります。

ふつうのシステムとの違い

ふつうのシステムは、決めた手順のとおりに動けば完成ですが、AIは過去のデータや例から答えを導くため、同じ手順で作っても結果の出来がデータに左右されます。違いを表にまとめます。

観点ふつうのシステムAIを使うシステム
正しい動き入力に対する出力を一つに決められる正解が一つに決まらないことがある
完成の基準決めたとおりに動くか決めた精度の水準に届くか
データ扱う情報の形を決めるデータの量と質が出来を左右する
誤りへの備え不具合として直す一定の誤りを前提に、人の確認を組み込む
作った後変更があれば改修する精度を見守り、直し続ける

正解が一つに決まらないことを前提にする

AIの要件では、「正しい出力」を一つ書く代わりに、出力の例と、守るべき条件を決めます。

問い合わせの分類や帳票の読み取りのように答えが決まる仕事でも、人によって判断が分かれる例があります。まず、よい例・よくない例・判断が分かれる例を実際の業務から集め、どう扱うかを関係者で決めます。判断が分かれる例の扱いを決めておかないと、評価の結果を見たときに、AIの誤りなのか基準のあいまいさなのかを区別できません。

生成AIは、同じ質問でも答えの言い回しが変わることがあります。そのため、文面を一つに決めるのではなく、「根拠にした文書を示す」「決まった形式で返す」「答えられないときは答えられないと返す」のような、守ってほしい条件を要件として書きます。もっともらしい誤り(ハルシネーション)への備えは、ハルシネーションとはで取り上げています。

精度の基準を業務の言葉で決める

精度の基準は、「何を測るか」「どの誤りが重いか」「どの水準なら使うか」の3つを、業務の言葉で決めます。

AIの誤りには、拾うべきものを見落とす誤りと、拾わなくてよいものを拾う誤りがあり、どちらが重いかは業務によって違います。見落としが重い業務では、AIが拾う範囲を広めにし、人が確かめる件数が増えることを受け入れます。誤って拾うことが重い業務では、確度の高いものだけをAIが扱い、残りは人に回します。

どちらの誤りが重いかで変わる、AIと人の分担

  • 見落としが重い業務AIが拾う範囲を広めにし、人が確かめる件数が増えることを受け入れる
  • 誤って拾うのが重い業務確度の高いものだけをAIが扱い、残りは人に回す

どちらの誤りが重いかは、業務によって違います

水準は、いまの人の作業と比べて決めると合意しやすくなります。人が行っても一定の誤りは出ているため、AIにだけ誤りのない状態を求めると、いつまでも本番に進めません。本番に進む水準とやめる水準を、試す前に決めておく考え方は、AIの試し(PoC)で終わらせないためにで説明しています。

データを要件として扱う

AIの出来はデータで決まるため、使うデータの所在・量・質・使ってよいかを、要件定義の段階で確かめます。

  • 所在:どのシステムやファイルに、いつからのデータがあるか
  • 量と偏り:めったに起きないが重要な例が含まれているか
  • 質:書き方の揺れ、欠け、重なりがないか
  • 使ってよいか:個人の情報や、取引先から預かった情報が含まれていないか、使う目的が契約や社内の規程に合っているか

AIに正解を教えるための学習データが要る場合は、正解をつける作業(アノテーション)の手間と、判断の基準も見積もります。業務の知識が要るため、現場の方の時間を計画に入れておきます。

評価の方法を先に決める

評価の方法とは、どのデータで、何を、だれが測るかを決めることです。作った後で決めると、結果に合わせて基準が動いてしまうため、作る前に決めます。

評価用のデータは、学習に使っていないもので、本番の入力に近いものを用意します。生成AIでは、実際の質問と望ましい答えの組を問題集として用意し、直すたびに同じ問題集で比べます。評価の考え方は、用語集のAIの評価にもまとめています。

人の確認をどこに入れるか

AIの結果をだれが、どの時点で確かめ、だれの責任で確定するかを、業務の流れの中に書き込みます。

たとえば、AIが確信を持てなかったものだけを人に回す、AIが作った案を担当者が承認してから確定する、例外のときは人に引き継ぐ、といった入れ方があります。人の確認の手間も業務の時間に含めて、AIを入れる前と後を比べます。

運用で直す前提を要件に入れる

AIは、使い始めた後にデータの傾向が変わると精度が下がることがあるため、直し続ける運用を最初から要件に入れます。

  • 精度を見る方法と頻度、下がったときの連絡の先
  • 入力と出力の記録(ログ)の残し方と、残す期間
  • 使っているAIのモデルが更新されたときの確かめ方
  • 改善を担う人と、直すときの手順

こうした運用はLLMOps・MLOpsと呼ばれます。具体的な進め方はつくったAIを直し続ける運用(LLMOps)をご覧ください。

段階を分けて決める

AIの要件は作る前に決めきれないため、段階を分け、段階ごとに要件を見直して次に進むかを判断します。

経済産業省の「AI・データの利用に関する契約ガイドライン(AI編)」(2018年6月)は、学習済みモデルの内容や性能が契約のときにはっきりしないことが多く、学習用のデータに左右されることがある点を、AIの開発の特徴として挙げています。そのうえで、学習済みモデルの実現可能性を検討するアセスメント段階、PoC段階、開発段階、追加学習段階に分け、段階ごとに目的を実現できるか、次の段階に進むかを確かめながら進める「探索的段階型」の開発方式を提唱しています。必要な性能に届かないと分かった段階で、次に進まない選択もできます。

「探索的段階型」の開発方式(経済産業省「AI・データの利用に関する契約ガイドライン(AI編)」)

アセスメント段階学習済みモデルの実現可能性を検討する
PoC段階
開発段階
追加学習段階

段階ごとに、目的を実現できるか、次の段階に進むかを確かめます。必要な性能に届かないと分かれば、次に進まない選択もできます。※ 個別の契約の判断は専門家にご確認ください

経済産業省は、2025年2月に「AIの利用・開発に関する契約チェックリスト」も取りまとめています。段階ごとの契約の形や、精度を約束するかどうかは、システム開発の請負契約と準委任契約は、何が違うかもあわせてご覧のうえ、個別の契約の判断は弁護士などの専門家にご相談ください。

出典:リアルデータの共有・利活用(AI・データの利用に関する契約ガイドライン、AIの利用・開発に関する契約チェックリスト)(経済産業省)

当社のご支援

アメリア・テクノロジーは、成果の測り方を、開発の前にお客様と決めるところからお手伝いします。何にAIを使い、どの順番で進めるかの整理はAI・DXコンサルティングで承ります。技術者がお客様の現場に入り、要件を決めながら試作と改善を短い間隔でくり返す形は、現場に入るチーム(FDE)をご覧ください。

  • 要件定義
  • AI開発
  • 評価
  • 運用

この記事に出てくる用語

この記事を書いた人

石田 誠 フロレンティナ 取締役CTO

インターネットの黎明期から、ホスティング事業の立ち上げや、インフラ・セキュリティのプロジェクトに携わってきました。現在は、AWS・Azure へのクラウド移行の支援と、業務アプリケーションの要件定義から実装までを担っています。

このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。

あわせて読みたい

導入の進め方のコラムを見る コラムの一覧に戻る

無料で相談する無料の診断