「この業務にAIを入れたい」「競合もAIを使っているので自社も導入したい」といった話から、AI・機械学習の検討が始まることがあります。
AIが有効な業務は数多くあります。しかし、業務課題によっては、単純な閾値判定や条件分岐、統計的な分析の方が、必要な品質をより少ない開発・運用負荷で実現できる場合もあります。
重要なのは「AIを使えるか」ではなく、「業務上の判断を、必要な品質・説明性・コストで実現するには何が適切か」を考えることです。
本記事では、ルールベース、統計的アプローチ、機械学習を単純な高度化の順番として扱わず、業務課題、データ、誤判定リスク、説明性、運用・保守費用から手法を選ぶ考え方を整理します。
「AI導入」が目的になると手段選択を誤りやすい
本来、AIやデータ分析は業務上の課題を解決するための手段です。
ところが、「AIを導入する」という方針が先に決まると、AIを利用できそうなデータや業務を後から探す形になりやすくなります。
例えば、担当者が明確な条件に従って判定している業務でも、機械学習モデルを構築すること自体が目的になる場合があります。
機械学習には、複雑なパターンを人手で定義せず、データから学習できる強みがあります。一方で、学習データの準備、評価、本番環境への組み込み、監視、必要に応じた再学習など、モデル以外の運用も必要になります。実運用の機械学習システムでは、モデルそのもの以外のデータ・設定・依存関係・監視等が長期的な保守負荷になることが指摘されています（Sculley et al., 2015）。
そのため、まず解決したい業務課題を定義し、その課題に必要な複雑さを持つ手法を選ぶことが重要です。
技術探索や研究開発では技術を起点に可能性を探ることにも意味があります。一方、企業の業務改善・投資判断ではProblem / Decision Firstの方が、必要以上に複雑な仕組みを導入するリスクを抑えやすくなります。
AI・機械学習・ルールベースの関係を整理する
AIと機械学習は完全な同義語ではありません。
機械学習は、データからパターンや規則性を学習し、予測・分類等を行う方法です。一方、広い意味でのAIには、人間が定義したルールに基づく判断システム等も含まれる場合があります。
本記事では企業の技術選定を分かりやすくするため、実務上の整理として次の3つを比較します。
| アプローチ | 基本的な考え方 | 例 |
|---|---|---|
| ルールベース | 人が条件・判定ルールを明示する | 閾値、条件分岐、業務ルール |
| 統計的アプローチ | データの傾向、関係性、不確実性をモデル化する | 傾向分析、回帰、時系列分析等 |
| 機械学習 | データから複雑な規則性・パターンを学習する | 分類、予測、画像・文章分析等 |
ただし、統計と機械学習には重複する領域があります。例えば回帰や分類は双方の文脈で利用されます。ここでは学問領域を厳密に区切ることではなく、企業が方式を比較するための整理として扱います。
まず単純なルールで解けないか確認する
業務担当者が現在どのように判断しているかを書き出すと、AIが必要かどうかを考えやすくなります。
例えば「温度が管理基準を超えたら点検する」「一定金額以上なら上長承認を行う」など、少数の明確な条件で業務が成立している場合があります。
このようなケースでは、まず既存ルールや単純な条件分岐をBaselineとして検討します。
Baselineとは、高度な方法を導入する価値を比較するための基準となる方法です。
機械学習がBaselineより高い性能を示したとしても、その差が小さく、業務効果がほとんど変わらない一方で運用負荷が大きく増えるなら、単純な方法を採用する判断もあり得ます。分類問題では、複雑な方法による性能改善が、現実の問題に存在する他の不確実性と比較すると限定的な場合があることも指摘されています（Hand, 2006）。
単純な閾値判定なのに画像AIを提案された架空例
説明用の架空工場を考えます。
業務要件は、「タンク液位が管理上の基準を超えた場合、担当者へ確認を促したい」というものです。
既存設備ではPLCから液位の数値データを取得でき、現在の業務ルールも「所定の閾値を超えたら確認する」と明確に決まっているとします。
ここで外部ベンダーから、「新しくカメラを設置し、タンク画像をAIで解析して液位異常を判定する」という提案を受けたとします。
この場合、「画像AIだから高度で良い」とも、「閾値で済むから画像AIは不要」とも即断しません。
まず、次の点を確認します。
- 既存の液位計は十分な信頼性を持っているか
- 閾値判定だけで実際の業務要件を満たせるか
- 画像からしか取得できない状態があるか
- 既存センサーでは検知できない異常を画像から把握できるか
- 画像AIによる追加価値が導入・運用コストに見合うか
| 比較項目 | 既存液位データ＋閾値 | カメラ＋画像AI |
|---|---|---|
| 入力 | 既存センサー値 | 新規画像データ |
| 学習データ | 原則として不要 | 学習・評価用画像が必要 |
| 判断根拠 | 閾値として明示しやすい | モデル仕様によって異なる |
| 追加設備 | 既存設備を利用可能 | カメラ・撮影環境等が必要 |
| 主な注意点 | 液位計の品質・故障 | 照明、角度、汚れ、データ品質、モデル保守等 |
| 追加価値 | 既存計測範囲での判断 | 画像からしか取得できない状態を扱える可能性 |
画像AIを採用する理由は、「AIだから」ではなく、既存センサーと単純ルールでは満たせない要件に対して追加価値を提供できる場合です。
ルール・統計・機械学習を選ぶ7つの判断軸
1. 判断ルールを人が明示できるか
判断条件が少数で安定しており、「この条件ならこの対応」と明確に書ける場合は、ルールベースをまず検討します。
反対に、熟練者が多数の特徴を同時に見ながら判断しており、ルールとして列挙することが難しい場合は、データから規則性を学習する方法の価値が高まります。
2. 問題の複雑性はどの程度か
少数の変数と単純な関係なら、ルールや比較的シンプルな統計モデルで十分な場合があります。
多数の変数が複雑に関係する場合や、画像・文章など非構造データを扱う場合には、機械学習を検討する理由が増えます。
3. 利用できるデータの量・品質は十分か
「○件あれば機械学習できる」という一律の基準はありません。
必要量は問題の複雑性、特徴量、対象クラス、求める精度等によって変わります。また件数だけでなく、本番環境を代表しているか、正解ラベルを信頼できるかも重要です。
4. 誤判定による業務影響はどの程度か
モデル性能はAccuracyのような一つの数字だけで判断せず、どの誤りが業務上問題になるかを確認します。
False Positive（実際には該当しない対象を該当と判断すること）とFalse Negative（実際には該当する対象を見逃すこと）では、業務上のコストが大きく異なる場合があります。
5. どの程度の説明性・監査性が必要か
明示的なルールや単純なモデルは、判断根拠を説明しやすい傾向があります。一方、複雑な機械学習でも説明支援手法はあります。
ただし、高い説明責任が求められる場面では、モデル性能だけではなく、そもそも解釈可能な方法で要件を満たせないか検討することも重要です（Rudin, 2019）。
6. 業務環境・判断条件はどの程度変化するか
業務条件が安定しており、変更も明示的に管理できるなら、ルール変更で対応しやすい場合があります。
一方、人が条件を更新し続けることが難しいほど複雑な変化があり、十分なデータが継続的に得られる場合には、機械学習による適応を検討する価値があります。
7. 開発費だけでなく運用・保守費を比較する
技術選定では初期開発費だけでなく、データ収集、ラベル作成、クラウド・推論環境、監視、モデル更新、障害対応等も確認します。
一方、ルールベースもルール数が増え続けると、条件同士の矛盾や変更影響の確認に大きな工数がかかる場合があります。
したがって、「ルールは安い」「機械学習は高い」と固定せず、対象業務についてTotal Cost of Ownership（導入後を含む総保有コスト）を比較します。
統計と機械学習は明確に二分できるわけではない
「統計を使うか、機械学習を使うか」と二者択一で考えることがありますが、両者には重複する領域があります。
例えば回帰モデルは、統計的推測を目的として利用することも、未知データの予測を目的とする機械学習として利用することもできます。
企業の技術選定では、「これは統計かAIか」という名称よりも、必要な精度、説明性、データ、実装負荷、業務価値を満たすかを見る方が実務的です。
Baselineを作って追加価値を比較する
機械学習を検討する場合でも、最初に比較対象となるBaselineを用意すると、導入価値を判断しやすくなります。
Baselineは高度なモデルである必要はありません。
- 現在の担当者判断
- 単純な閾値
- If-Then条件
- 平均値・移動平均等の単純な統計
- 比較的単純な予測モデル
などが候補になります。
重要なのは、高度なモデルがBaselineより良いかどうかだけではありません。
その改善幅が、開発・導入・運用コストを追加しても意味のある業務価値になるかを確認します。
AWSのMachine Learning Lensでも、ML採用前にルールベース等の単純な方法をBaselineとして設定し、性能、推論時間、総運用コスト、説明性等を比較する考え方が推奨されています。
機械学習を使う価値が高まりやすいケース
例えば次のような課題では、機械学習を検討する理由が増えます。
- 人間が判断ルールを明確に列挙することが難しい
- 多数の変数が複雑に関係している
- 画像、文章、音声等の非構造データを利用したい
- 既存ルールでは誤判定が多く、業務影響が大きい
- 十分な代表データと信頼できるラベルを準備できる
- 単純なBaselineに対して実務上意味のある改善が確認できる
機械学習は、手作業では記述しにくい複雑な規則性を扱えることが大きな強みです（Domingos, 2012）。
AIを使わない方が合理的なケース
反対に、次のような状況では、まず単純な方法を検討する余地があります。
- 判断条件が少数・明確で、頻繁には変化しない
- 閾値や業務ルールで必要な品質を満たせる
- モデル学習に使えるデータが限定的である
- 機械学習による性能改善が業務上ほとんど意味を持たない
- 非常に高い説明性・監査性が必要である
- 継続的なモデル運用コストが期待効果に見合わない
ただし、これは「AIは使わない方がよい」という一般論ではありません。
現在はルールで十分でも、対象業務やデータが複雑化した時点で機械学習へ移行することもできます。
Hybridという選択肢もある
ルールベースと機械学習は二者択一ではありません。
例えば明確な禁止条件や安全条件はルールで処理し、それ以外の対象についてのみ機械学習で優先順位を付ける方法もあります。
また、単純なモデルで大半のケースを処理し、判断が難しいケースだけ人間や高度なモデルへ回す構成も考えられます。
業務要件によっては、このようなHybrid構成がコスト、性能、説明性のバランスを取りやすい場合があります。
AI導入判断チェックリスト
| 確認項目 | 確認内容 |
|---|---|
| 業務課題 | 解決したい課題を一文で説明できるか |
| 意思決定 | AI等によって何の判断を変えたいか明確か |
| 現行ルール | 現在の判断条件を書き出せるか |
| Baseline | 閾値・条件分岐等の単純な方法を比較したか |
| 統計 | 統計的な分析で要求を満たせないか確認したか |
| 複雑性 | 人間がルールとして記述しにくい複雑な関係があるか |
| データ | 利用可能なデータの量・品質・代表性を確認したか |
| ラベル | 必要な場合、信頼できる正解データを準備できるか |
| 誤判定 | False Positive・False Negativeの業務影響を整理したか |
| 説明性 | 必要な説明性・監査性を整理したか |
| 追加価値 | 高度な方法がBaselineをどの程度上回る必要があるか |
| 開発費 | PoC・本番開発の費用を確認したか |
| 保守費 | 監視、モデル更新、インフラ等も考慮したか |
| 代替案 | AIを利用しない方式も比較したか |
現在AI化を検討している業務について、まず「担当者が判断ルールを紙に書き出せるか」を確認してみてください。
少数の明確な条件だけで業務要件を満たせるのであれば、機械学習を構築する前に、その方法をBaselineとして比較する余地があります。
まとめ
AI・機械学習は、複雑なデータから人手では記述しにくい規則性を抽出できる有力な手段です。
一方、すべての業務課題に最も複雑なAIが必要なわけではありません。
まず、何を判断・改善したいのかを明確にし、現在のルール、単純なBaseline、統計的方法、機械学習を比較します。そのうえで、データ、誤判定リスク、説明性、性能改善、開発・保守費まで含めて選択します。
「最も単純な方法を選ぶ」とは、常にルールベースを選ぶことではありません。要求品質を満たす中で、必要以上に複雑でない方法を選ぶという意味です。
SCI総合研究所株式会社のRASHINRAでは、「AIを使うこと」から始めるのではなく、まず何を判断・改善したいのかを整理し、基礎集計、統計解析、機械学習等から意思決定に必要な分析方法を選択します。
「AIを提案されているが本当に必要か分からない」「単純なルールでも実現できそう」「PoCへ進む前に手法選択を整理したい」といった段階から、技術選定とデータ活用の論点を整理できます。
参考文献
- Hand, D. J. 2006. Classifier Technology and the Illusion of Progress. Statistical Science. Vol. 21. Issue 1. pp. 1-14. https://doi.org/10.1214/088342306000000060
- Domingos, P. 2012. A Few Useful Things to Know about Machine Learning. Communications of the ACM. Vol. 55. Issue 10. pp. 78-87. https://doi.org/10.1145/2347736.2347755
- Sculley, D. et al. 2015. Hidden Technical Debt in Machine Learning Systems. Advances in Neural Information Processing Systems. Vol. 28. pp. 2503-2511. https://proceedings.neurips.cc/paper/2015/hash/86df7dcfd896fcaf2674f757a2463eba-Abstract.html
- Rudin, C. 2019. Stop explaining black box machine learning models for high stakes decisions and use interpretable models instead. Nature Machine Intelligence. Vol. 1. pp. 206-215. https://doi.org/10.1038/s42256-019-0048-x