AIの要件定義は通常のシステム要件と何が違うか
通常の業務システムの要件定義では、機能・画面・帳票・性能・セキュリティなどを決めます。AIシステムでも同じ項目は必要ですが、加えてAI固有の項目があります。AIの判定は100%正しくはならず、データの変化で性能が変わり、モデルが更新されるからです。
Googleの研究者が2015年に発表した論文「Hidden Technical Debt in Machine Learning Systems」は、実際の機械学習システムのうち、機械学習のコードはごく一部で、周辺のインフラの方がはるかに大きく複雑だと指摘しました。要件定義でも、モデルの精度より、データの入出力・例外処理・再学習・監視といった周辺の要件の方が多くなります。
発注前に決める10項目
1. 判定対象と範囲
何を判定するのかを、品種・工程・不良種のレベルで書きます。外観検査なら「対象品番」「検査面」「対象とする不良種と対象外の不良種」、予知保全なら「対象設備」「対象とする故障モード」です。範囲外のものが来たときの扱い（判定しない、警告を出す）も決めます。
2. 精度目標と評価方法
精度は、運用する閾値での見逃し率・過検出率のように、閾値を決めた状態の指標で書きます。AUROCのような閾値に依存しない指標だけでは、実運用の性能は分かりません。あわせて、評価に使うデータ（学習に使わない、実際の不良を含むデータ）と評価の手順も要件に書きます。精度の考え方は AIの「精度95%」をどう読むか で扱っています。
3. 処理時間
ラインのタクトタイムに間に合う判定時間を書きます。公開されている例では、外観検査の手法EfficientADはRTX A6000上で1枚約2.2ミリ秒、PatchCoreは約32ミリ秒でした（Batzner et al.）。手法と推論ハードウェアで1桁以上変わるため、「1個あたり何秒以内」「1時間あたり何個」を要件として書き、ハードウェアの選定はベンダーに提案させます。
4. 入出力
入力（カメラ画像・センサーデータ・MESの実績）の形式と取得方法、出力（判定結果・スコア・不良箇所）の形式と送り先を決めます。判定結果をMESに書き戻す場合は、どのタイミングで、どの項目に、ロット番号と結んで記録するかまで書きます。
5. 例外時の扱い
AIが判定できないとき（画像が暗い、データが欠けている、範囲外の品種が来た）、システムが停止したときの扱いを決めます。ラインを止めるのか、人の検査に切り替えるのか、判定を保留して後で確認するのかです。この項目が抜けると、本番で最初のトラブルが起きたときに現場が混乱します。
6. 再学習
品種追加、材料変更、設備の改造、季節変動で、AIの性能は落ちる前提で考えます。再学習を誰が・どのくらいの頻度で・どのデータで行うか、ベンダーに依頼する場合の費用、社内で行う場合の手順と必要なツールを決めます。
7. モデルの版管理と判定記録
どのモデルで合否を判定したかを、ロットごとに記録できるようにします。品質監査や顧客のクレーム調査で、判定の根拠を後から確認する必要があるからです。モデルを更新したときの承認手順と、問題があったときに前の版に戻す手順も決めます。
8. 権限
閾値の変更、モデルの更新、判定結果の上書きを、誰ができるかを決めます。現場が閾値を変える場合は、変更の権限と記録を残す仕組みが必要です。AIの結果で設備の設定値を変える場合は、承認フローとインターロックを設けます。
9. 監視
本番でAIの性能が落ちていないかを監視する方法を決めます。過検出率・判定スコアの分布・入力データの変化（ドリフト）を定期的に確認し、閾値を超えたら通知する仕組みです。監視の方法は モデルドリフトの監視 で扱っています。
10. データとモデルの権利
学習データ、ラベル、学習済みモデルの権利が誰にあるかを決めます。ベンダーを替えるときにデータとラベルを持ち出せるか、学習済みモデルを他のラインに使えるかは、契約で決めておかないと後で問題になります。
PoCの結果から要件に落とす
| 項目 | PoCで確認すること | 要件への落とし方 |
|---|---|---|
| 判定対象 | どの不良種で精度が出たか | 精度が出た不良種だけを本番の対象にする |
| 精度目標 | 並行運用での見逃し・過検出の件数 | 閾値と目標値を数値で書く |
| 処理時間 | PoC環境での処理時間 | タクトに対する余裕を含めて書く |
| 例外 | PoCで判定できなかったケース | 例外の種類ごとに扱いを決める |
| 再学習 | 品種や条件が変わったときの性能の変化 | 再学習の頻度と費用の前提にする |
提案依頼書（RFP）への落とし方は AI開発のRFPの書き方 で、契約の注意点は AI開発契約の注意点 で扱っています。
よくある質問
要件定義はPoCの前と後のどちらで行いますか
両方です。PoCの前には目的と合格ラインを決め、PoCの後に本番の要件を詳しく決めます。PoCの結果を見ずに本番の要件を固めると、達成できない精度目標を約束することになります。
精度目標を100%にできないなら、要件にどう書けばよいですか
見逃しと過検出のどちらを優先するかを決め、許容できる値を数値で書きます。そのうえで、AIが見逃す可能性がある不良を後工程や抜き取り検査でどう拾うかを、例外時の扱いとして要件に含めます。
既製のAIパッケージを使う場合も要件定義は必要ですか
必要です。パッケージの場合、判定対象・精度目標・入出力・例外時の扱い・再学習の手順を要件として整理し、パッケージがそれを満たすかを確認します。満たさない部分はカスタマイズか運用でカバーします。
この記事に出てくる用語
この記事を書いた人
DELMIA Apriso を中核とした MES / 製造DX の導入・運用・人材育成と、製造業向けAIの調査・開発・教育を手がけるITコンサルティング企業。ISO 9001:2015 / ISO 27001:2022 認証取得。 日本・中国・米国で製造業のMES・データ基盤・AI導入を手がけた実務者が、欧米・中国の一次情報にあたって書いています。
