はじめに

下記は私が経験したAI・機械学習プロジェクトから得た教訓である。

「鬼十則」のタイトルでお気づきの方もいると思うが、これは某企業の社長が遺した行動規範¹をベースに作成している。~~当初ネタで作っていたものだが~~、これらは私の反省を基に作られたAIプロジェクトの担当者目線の行動規範である。

本稿ではこの教訓を得るに至ったプロジェクトの失敗談を共有し、この鬼十則を解説していきたい。

とあるAIプロジェクトの失敗

※この物語はフィクションです

登場人物

主人公：機械学習の導入経験を持つエンジニア
事業部担当者：AI検討を打診した事業部門の担当者
分析担当者：データ分析を専門とする受託会社のデータサイエンティスト
偉い人：プロジェクトオーナー

1. プロジェクトのはじまり

AIプロジェクトは唐突に降ってくる。
ある日、機械学習を使った故障予知システムを検討したい との依頼が職場に届いた。

この案件にアサインされた主人公は早速ヒアリングに向かった。

事業部担当者：
「このデータに機械学習ってやつで故障の予兆が見えないか試して欲しい」

渡されたのは10サンプル程度の測定データがまとめられたエクセルファイル。
初見で悟った。これはまだ機械学習のステージではない… と

主人公
「このデータでは機械学習の検討はできないと思います」
「ちゃんと検討したいなら、もっとデータを集める必要があります」

この進言と共に議論を行い、この案件はペンディングになるだろう。そう思い帰路についた。

しかし事態は思惑とは違う方向に進んでいく。

偉い人
「これから事業部門と一緒に故障予知技術に関してテーマ検討を進めていく」

かくしてAIプロジェクトは不安を残しつつもスタートを切った。

2. これ難くね？

事業部門の要求は以下の通り

突発的な故障がサービスサポートの負荷となっている。それを事前に予知する技術が欲しい
もともと壊れにくい製品。だからこそ予測も難しかった

主人公は引き続きヒアリングを進めターゲットの現状把握を進めた。
そして故障予知の実現に以下の課題が見えてきた。

たとえ故障を事前に予測できたとしても、誤報を出すと返ってサポートの負荷になる
上記トレードオフをメリット側に寄せるには相当の精度が求められる
本当に壊れているかがわからない中、アラートに納得してもらうには相当なハードルがある

要求を洗い出し実感したがこれはとても難しい。
しかもこの難易度に見合った恩恵が受けられるかも未知数である。

難しさは感じるがいったんターゲットの把握はできた。
次はデータ収集に舵を切ろう。そう考え主人公は次のステップに進んだ。

3. データが先か開発が先か…

先の要求を機械学習で実現するならば異常検知のアプローチだろう。
学習は正常データで進めるにしても、やはり評価には異常データが必須となる。

そこで主人公はこの検討を進めるため事業部門に足を運んだ。
しかしここで両者の思惑の違いが明らかになってくる。

事業部担当者：
「前に渡したエクセルファイルがすべて」
「まずはあのデータで結果を示してくれないとこちらは動けない」

主人公：
「やりたいのは検知ではなく予知ですよね？」
「あのデータでは測定頻度が粗すぎて予知の検証はできないです」
「検知なら検証できますが、N数が少ないので信頼性が乏しいと思います」

事業部担当者：
「じゃあどれくらいデータがあれば実現できるんですか？」

主人公：
「正直それはやってみないとわからない。それを確認検討するのが今のフェーズです」
「少なくとも今のデータでは機械学習の開発はできません。そもそも機械学習とは…」

データドリブンと結果ドリブンの思想の違いがここでぶつかってしまう。
そしてプロジェクトの雲行きは徐々に怪しくなっていく🌧

4. えっ、データ分割したんですか？

暗雲が立ち込める中、今回のPoC²を受託分析会社にお願いしたとの知らせが入った。
聞くと渡したデータはあのエクセルファイルらしい。

主人公はその知らせを聞き、あのデータで何を分析するんだ？と思った。
おそらく先方が出す答えも、これから予知の実現に向けてデータ収集をしていきましょう
そういった提案を示してくれることを期待した。

しかしこの報告会では予想していなかった内容が報告される。

分析担当者：
「今回はデータが少なかったので、データを分割し疑似的に増やすことで学習と評価を行いました」
「その結果9割を超える高い精度で故障サンプルの検知を行うことができました！」

主人公：
「えっ、あのデータ分割して評価したんですか？　Leakage³とかは大丈夫ですか？」

分析担当者：
「テストデータは別のサンプルを使って評価しているので大丈夫だと思います」

ポジティブな報告に関係者が色めき立つ中、主人公だけが疑念を拭えずにいた…

5. Leakの発覚

本当にあの評価で大丈夫だったのか？

時系列データの分割はLeakageのリスクが高い行為だ。
おそらく分類モデルは前後の類似データを記憶し推論しているのではないか？

そう考えて主人公は検証を進めた。

検証を進めた結果、異常サンプルの信号のみに不可解なバイアスがのっているのが見つかった。
そしてバイアスを取り除き学習、評価をすると精度を大きく落とすことが発覚した。
作成されたモデルはこのバイアスを頼りに判定を行っていたのである。

主人公はこの結果を関係者に共有し、ようやく現状のデータではろくな開発、評価できないことが周知された。

6. 困ったときのAI

先の検証でプロジェクトは完全にふり出しに戻った。
この結果を受けて各部署の上長を含めた関係者が招集された。

偉い人：
「このプロジェクトは長く平行線を進んでいた。メンバーで腹を割って話し合おう」

事業部担当者：
「機械学習はデータをもとに学習する技術と理解している」
「人での判断が難しいところを機械学習がデータから答えてくれるのを期待していた」

主人公：
（まじか… 機械学習をドラえもんか何かだと思ってたのか…）
「基本的に人がわからないものを機械学習で学習させるのは難しいです」
「よくわからないデータを学習して得られた結果を、本当に信じれますか？」
「たとえ高精度にアラートを出せたとして、その結果を現場は納得してくれるでしょうか？」

機械学習に対する期待値のずれが明らかになり、それがようやく修正された。
ここで互いの認識が揃えられ、プロジェクトは一度仕切り直す形となった。

7. プロジェクトの終焉

データをきちんと集めていこう。関係者の意思は統一された。

しかし肝心の故障サンプルは中々手に入らない。
またデータ収集にはコストがかかる。将来的にシステム化を見据えなければならない。
データ収集もまた課題が山積みであった。

こうした課題を受け、これだけ投資をしてビジネス的メリットは本当に出せるのか？
との懸念が事業部門の中で芽生え始めた。

程なくして、本プロジェクトはビジネスメリットの不透明性から中止を告げられた。

こうしてこのAIプロジェクトは終わりを迎えたのである…

そして主人公は、今度はちゃんと機械学習の開発をしたいなぁ
そう想いを抱きながら転職サイトに会員登録をするのであった。

〜おしまい〜

AIプロジェクト鬼十則

いかがだっただろうか？
この物語を読んで身に覚えのある事象や苦労を経験した人もきっといるだろう。
細かい違いはあるが失敗するAIプロジェクトの多くは同じ道（アンチパターン）を辿っていると思う。

下記表はAIに関する調査結果のフェーズごとの課題をまとめたものである⁴。
先の物語はここに挙がっている課題ともリンクした内容となっている。

	企画立案段階	企画〜実証実験段階	実証実験〜実用化段階
1位	課題が不明（41.7%）	課題が不明（38.8%）	課題が不明（37.5%）
2位	十分な量・質を備えたデータの取得（28.1%）	十分な量・質を備えたデータの取得（13.6%）	十分な量・質を備えたデータの取得（5.2%）
3位	AI人材・知識不足（17.8%）	AIの精度が不十分（10.2%）	AI人材・知識不足（4.7%）

私自身もこういったアンチパターンに遭遇し失敗した経験がある。
冒頭にあげた鬼十則はその反省から生まれたものであるが、ここからそれぞれの項目を解説していきたい。

1. データは自ら集めるべきで、与えられるべきではない

主人公の「データがないから開発できない」の発言は間違ってはいない。しかしデータがないと嘆くのではなく、そのデータを取りに行く努力が必要である。昨年データサイエンティスト界隈で話題となった『アルキメデスの大戦』では上のいざこざでデータ（設計図）が手に入らない時、自らデータを集めて突破口を開くエピソードが綴られている⁵。この姿はまさに理想のデータサイエンティスト像といえるだろう。データ収集の壁は数多く挙げられるが⁶、その壁を乗り越える努力を怠ってはいけない。自らが安心して開発を進めるためにも、データ取りには十分に入り込んでいくべきである。

2. 目標とは、先手先手と働き掛けていくことで、受け身で決めるものではない

機械学習に過度な期待がかかるのはよくある話で、「人でわからなかったことが機械学習ではできると思ってた」はそれが表れた言葉となっている。次節にも通じるが課題解決に本当に機械学習が適しているかをきちんと見極め、妥当な目標を定めるのが大切である。目標を定める前にまず期待値調整を行うべきで、できない目標は絵にかいた餅となる。重要なのは目標の妥当性とその目標を達成するための筋道を立てることであり、これを実行できるのは機械学習の実務担当者に他ならない。

3. 目的意識のある現場と取組め。意識の低い現場は開発物の価値を小さくする

開発目標については機械学習担当者にも委ねられるが、本当にそれが課題を解決するものであるか？の判断基準はクライアント側に大きく依存する。機械学習を使うことを目的に始まるプロジェクトもあると思うが、これら技術は現場の課題に落とし込まなければいくら高い精度を示しても価値にはならない。そういう意味では機械学習を使うことを目的に走り続けるプロジェクトは地雷と考えた方がよいだろう。

4. 定式化が難しいタスクを狙え。そしてこれを成し遂げるところに進歩がある

機械学習は人の感や経験に頼るようなタスクで効果を発揮する。この特徴を活かしつつ、技術的負債⁷や解釈性の難しさにも目を向けなければならない。物語の終盤「たとえ高い精度を示したとしても、現場がその結果に納得できるか？」の問いがある。こういった特性を理解した上で、よくよく機械学習を使う意義があるかを考え、決して機械学習ありきでプロジェクトを進めてはいけない⁸。

5. 評価を怠るな。殺されても怠るな。プロジェクトを完遂するまでは…

機械学習の検討には評価の確からしさがなによりも大切である。今回の物語は時系列データの典型的なLeakage³事例であったが、少なくとも検証とテストのサンプルを分けるセオリーは守っている。しかし「データが少なかったので分割した」「良い結果に対して疑いを持たなかった」のは悪手である。評価を誤るとこれまでの検討結果がすべてひっくり返ると考えるべきである。これらの評価はPoCのみならず、導入可否判断、運用後のモニタリングと機械学習のモデルを使い続ける限りずっと付きまとう問題であることを忘れてはならない。

6. クライアントを引きずり回せ。引きずるのと引きずられるのとでは、永い間に天地の開きができる

悲しいかな実務担当者レベルでは、クライアントやその他組織を動かすには力（権限）が足りない。プロジェクトを進める中で相手が全然動いてくれず、「力が欲しい…」そう思ったことがある人もいるだろう。非常に泥臭いが自分の力でどうにもならないならば、上を使ってでも動かすしかない。決して自分だけで相手を動かそうとするのではなく、上や役職者を巻き込んで相手を動かす力もまた必要になってくるのである。

7. ベンチマークを持て。感触がわかれば、忍耐と工夫と、そして正しい努力と希望が生まれる

機械学習ではすでに世の中で実施されている取り組みと類似のタスクを解こうとしても同じことができる保証はない。それはデータや、使用条件に大きく依存してしまうからである。こういった「やってみないとわからない」状態をいち早く抜け出すことが重要である。まず一度、学習・評価のプロセスを回せば、箸にも棒にもかかからない状態か？データから所望の学習ができているか？の感触がつかめる。その結果を出すことができれば、現状の課題や改善点、どれくらいデータを集めればものになりそうか？といった建設的な議論が可能になるのである。

8. 当事者意識を持て。当事者意識がないから君の仕事には、迫力も粘りも、そして厚みすらがない

データサイエンティスト：「ろくなデータが集まってないから話にならない」
現場：「できるかどうかもわからないものに工数はかけられない」
偉い人：「まだAIプロジェクトはものにならないのか？」

このように他責をあげればキリがなく、上手くいかないプロジェクトの多くは関係者の当事者意識が希薄である。それぞれの言い分ももちろんあるが、皆がそれぞれの役割で課題解決に向け行動しなければ先には進まないのである。少なくともこの中のどれが欠けても上手くまわることはなく、プロジェクトの成功は各組織の当事者意識にかかっている。

9. PoCは常に全回転。投資効果に気を配って、一分の隙もあってはならぬ。 AIプロジェクトとはそのようなものだ

データ分析案件に多い事象だが、そのデータがダメならこれ、これがダメならあの観点でと、むやみやたらにPoCを引き延ばすのは良くない。闇雲にデータを掘ったところで、得られる知見や成果はたかが知れている。PoCで何を確認し、その結果をもとにプロジェクトをどう進めていくかを明確にした上で素早くまわすのが大切である。PoCを乗り越えても、その先にはいくつも壁が待ち構えているのだから⁹。

10. 不確実性を怖れるな。 AIは進歩の母、革新の種だ。でないと君は時代遅れになる

AIプロジェクトは一般的なソフト開発と比べて不確実性が高いと言われるが¹⁰、この不確実性を恐れてはいけない。大切なのは不確実性があるポイントを予測してシナリオを組むことである ¹¹。AI活用の二極化が進む中、プロジェクトの各ステークホルダーがこの特性を正しく理解し活用していくことが、今後の発展には必要不可欠になってくるだろう。

おわりに

以上、AI・機械学習プロジェクトの失敗談を共有し、そこから得た教訓を紹介した。
プロジェクトが失敗するとそこには貴重なお金と時間、そしてメンバーのモチベーションが失われる。
確実に成功する方法こそないが失敗の再現性は高く、やはりアンチパターンは避けるべき事象である。

私は本稿以外にも機械学習プロジェクトにおける失敗事例をまとめた資料を作成し公開している¹²。
本稿と合わせてこれら資料がAI・機械学習プロジェクトのアンチパターン回避に少しでも役立てば幸いである。

公益財団法人　吉田秀雄記念事業財団 | 財団の概要 | 吉田秀雄について | 「鬼十則」 ↩
Proof of Concept（実証実験）の略。実際に上手くいくかを確認する活動のこと ↩
モデルの学習時に使用しているデータに、予測しようとしている情報（変数やデータ）が含まれ不当に使ってしまうこと ↩
47%のプロジェクトがPoC（実証実験）に至らない。AI活用の課題は「課題がわからない」こと。−AIに関する調査結果が公開 | AI専門ニュースメディア AINOW ↩
データサイエンティストが今すぐ「アルキメデスの大戦」を見るべき理由 - ITmedia NEWS ↩
組織の壁、セキュリティーの壁、データ収集基盤がない、アノテーションにかかるコストが高い、と挙げればきりがない ↩
機械学習システムにおける「技術的負債」とその回避策 ↩
O'Reilly Japan - 仕事ではじめる機械学習 ↩
機械学習を「社会実装」するということ / Social Implementation of Machine Learning - Speaker Deck ↩
プロジェクトマネジメントとAI開発 | AI専門ニュースメディア AINOW ↩
はてなのMackerelが明かす、機械学習プロジェクトに潜む2つの「不確実性の山」を乗り越えるコツ：手掛かりは「スクラム」「ゲームソフト開発」 - ＠IT ↩
失敗から学ぶ機械学習応用 ↩

とあるAIプロジェクトの失敗とそこから得た鬼十則