AI導入・技術活用プロジェクトの失敗と反省 ～とりあえずやってみよう！という落とし穴～

「こちらの会社は AI を導入した新サービスの開始をしました」などというニュースや記事をよく目にします。すっかり市民権を得た AI というキーワード、数年前までは「それって AI って呼んでいいの？」などという議論をよく耳にしたものですが、最近ではAIという言葉自体に慣れてしまい、あまり深く考えずに受け入れられているように思います。しかし、華々しい成功事例やニュースリリースがある一方で、うまくいかないプロジェクトや闇に葬り去られるプロジェクトの、なんと多いことでしょう。

筆者は営業という立場で日々数多くの相談や依頼をいただいていますが、最近は特に「このプロジェクトを実施してお客様は幸せになるのか」 という点を重視してご提案することを心がけています。技術的とは必ずしも言えない "差し出がましい" 話になってしまうことも多いのですが、ご相談の背景のことなども積極的にディスカッションさせていただいています。この "差し出がましい" 部分がいわゆる「デジタル時代のソリューションパートナー」なのかどうか、よくわからない部分もありますが、そういった体験を元に本記事を書いてみようというモチベーションです。SEO対策もこめてカタカナ語を使いましたが本心は「せっかくやるのだからお金も時間も有意義に使ってもらいたい！」という程度のものでございます。

AI活用プロジェクトって何？

特定の技術領域を「AI」と呼ぶ場合もありますが、この記事の立ち位置としては「AI」の定義に特に大きなこだわりはありません。強いて言うならば当社NTTデータ数理システムの掲げている「数理科学とコンピュータサイエンス」という抽象的な技術領域をイメージしています。具体的な技術としては、機械学習・シミュレーション・数理最適化・統計解析などが挙げられます。これらはいわゆる「数理モデル」に基づく手法であると括ることができますが、このような手法を活用した場合のシステム構築の具体的なアプローチは通常のシステム構築の案件とは異なる特徴があると思います。

私は特に「入力 ⇒ 出力の関係が自明でない」というところが大きな特徴かと思っています。通常のシステム開発では、仕様書／設計書の段階で「入力（アクション） ⇒ 出力（リアクション）」が定義されることに対して、数理モデルを用いたアプローチでは、入力に対してあたかも人が一生懸命に考えて出したような「感動」できる結果を出力として期待します。

「感動」への期待も大きい反面、「落胆」の可能性もあり、できることならば少しでも「感動」がある出力ができる AI を作りたいものです。そのままでは「感動」がいまいちだったとしたら、使いどころを工夫して「感動」を演出することもAIプロジェクトとして重要なのだろうと思います。

AI とやらに任せれば感動のアウトプットが出てくるのか？

AI とは個別具体的なアルゴリズム（ロジック）を指しているのではなく、色々な技術によって実現されるものです。Deep Learning も数多くある手法の一つです。昨今では、これまで数理科学的なアプローチとは縁遠かった方々も多くこの界隈にご興味を持ち、この技術を活用したいという機運は高まっています。「教師あり学習」「教師なし学習」などという言葉も一般的なレベルで使われるようになりつつあります。

「AI活用のためには個別具体的なアルゴリズムをどこまで知っておく必要があるのか？」というご質問はよく頂きます。数理モデル構築のプロに外注すればあとはお任せでいいのか？答えは半分は YES ですし、半分は NO かなと思います。

「カテゴリのラベルを自動で付与したい、何らかの分類モデルがあればいい、教師データはない」
という状況があったとします。教師なしの分類モデルであれば、技術的にはクラスタリングのタスクに落とし込むというのが素直な考え方で、K-means などのクラスタリングアルゴリズムで実現できそうです。ただし、経験的にはクラスタリングで人間の感覚に気持ちよくマッチするカテゴリ分けができるかというと疑問符が付きます。カテゴリとして使うにはしっくりこないクラスタができてしまい、結局人間が考えて振り分け直さなければいけない部分が残るかもしれません。
「何らかの分析ロジックを適用した結果を見てからカテゴリのラベル候補を考えようと思っていました。」
最初の作業としては、とりあえず計算機に任せてクラスタリングさせてみるというのも悪くない選択肢です。結果を見てから、必要に応じて人力でクラスタを結合したり細分化したりして、人間にとって適切なカテゴリ分けを作り上げることもできます。カテゴリの調整に人力で手間をかけるのであれば、最初に教師データを作成して教師あり学習の課題として解いてしまうという選択肢もあり得ます。教師データ作成と言うと単純作業と思われるかもしれませんがカテゴリ設計や判断が難しいデータの振り分けなどに人間のノウハウが入るもので、良い教師データを作成して学習させることができればこちらの方が手っ取り早く納得できる結果が出せるかもしれません。

機械学習などの技術でやりたいことを完全に実現するというのは難しい場合が多く、どこまでを人がやってどこから AI に任せるのか、ということを意識して決めていかないとプロジェクトを進めることはできません。「やりたいことは何か」と「ロジックができることの限界」のギャップを正しく把握し、必要に応じて人手で対応するということも選択肢に入れて、数理モデルのデザインを作り上げていくことが重要なのだと思います。ロジックで実現するべき領域を適切に要件定義できてしまえば実装は数理モデル構築のプロにお任せで良いのですが、「ロジックでどこまで実現するべきか」という点については数理モデル構築のプロとお互いの事情を理解し合ってコミュニケーションをとって決めていく必要があります。

一般的なシステム開発と同じ当たり前のことを言っていますが、AI開発となるとロジック側に対する期待が過度に膨らんで、ロジックで全てを解決する方向にしわ寄せをして問題を難しくしてしまうことが起こりがちです。現状のAI技術では具体的に何ができるのかという点を抑えておくと、コミュニケーションやプロジェクト進行が円滑に進めやすいのではないかと思います。

それって開発する必要本当にあるの？

みなさん電車に乗るときに、路線検索をよく使いますよね？乗換回数・金額・時間を小さくする、有料列車を使う使わない、時間指定など、非常にきめ細やかな仕様のシステムを無料で使うことができます。最近だと駅から近くのおすすめ飲食店が出たりですとか、感動するAIシステムといっても過言ではないものであると思います。たくさんのユーザーが使用することを想定して様々なニーズを取り込んできたため、人によっては無駄だと思うオプションもあるかもしれませんが、ほとんどの人のユースケースに必要な機能を満たした便利なシステムになっています。

AIシステム構築の検討に際して、ありもののサービスを使う方がよいのか、独自開発したほうがよいのか、そういった相談をよく受けます。私は個人的には「たくさんのユーザーのいる既存サービスがあるならば、それを使うことを優先的に検討するべき」というように考えています。路線検索のように、様々なユースケースに対応できるように検討済みの場合が多く、サービスの使い方に合わせていくことでサービス設計者の考えた標準的なやり方に沿って開発を進められます。逆に、貴社独自の特殊な工程を盛り込みたい、超高精度が必要、などの一般的なニーズと乖離した要件が必要であれば、独自開発しなければいけないということになります。

家建てるときに、森に木を伐りにいく？

家を建てるのにはいろいろな方法があります。建売を購入、中古物件のリノベーション、土地を買って設計から、あるいは賃貸まで。どれを実際に行うかは施主のこだわり次第です。でも、材料の木を自分で伐りにいくことまでは通常しないと思います。

機械学習界隈において参入者が増えた背景の1つとしては便利に使える道具が増えてきたことが大きく、簡単なプログラミングで機械学習モデルの学習や細かいパラメータチューニングができる Python のライブラリ、前処理やモデル作成をノーコードで実行できる分析ツール、モデル探索を自動実行するAutoMLツール、「壁のヒビを検出したい」「パンを自動判別するレジが欲しい」といった特定用途に応えるサービスなど、様々なスキルレベルや目的に合わせたツール（ライブラリ、サービス）がリリースされています。

AIプロジェクトにおいて「独自開発」のレベル感は様々ですが、現在では既存のツールを活用して開発するのが普通です。モデル作成などの機械学習のコアとなるロジックは既存のツールの機能を使用し、データ選択・特徴量抽出などの前処理、モデルの出力結果の活用方法などの周辺の処理で独自性を出していくことになります。画像認識や自然言語処理などの Deep Learning が得意なタスクでは大規模データで学習済みの高精度なモデルが利用できる場合もあり、学習済みのモデルをそのまま利用したり、自分のデータも使って転移学習や fine tuning してモデルを改良したりして開発するという選択肢もあります。新しい学習アルゴリズムを実装する、自分のタスクに特化した Deep Learning のレイヤー構造を1から試行錯誤する、というのは直接森に木を伐りにいくのに近い感じです。

ひと昔前であれば自分で実装する必要があったことも、今では便利なツールで簡単にできてしまうということも多い日進月歩のAI・機械学習業界ですので、現在どのような技術・サービスが存在するのかを網羅的にキャッチアップしておくことも開発方針を決定する上で重要なことです。機械学習や技術系が本職でない方々には難しいかもしれませんので、当社のような本職の立場に相談するのも有効な手であると思います。

プロジェクトのゴールは設定できている？

AI活用プロジェクトは着地が見えない構想のまま話が進むこともよくあります。
「折角ためたビッグデータをAI・デジタル活用して、サービス向上を図ります」 「プロセスをデジタル化してグローバルSCMの全体最適を図ります」
こんなふんわりしたお題目で検討が始まるのではないでしょうか。このお題目から具体的なゴールを設定することもAI活用プロジェクトの大きな課題です。ふんわりした話を具体化するために、他社の事例、既存のサービス・ツールなどを調査して今の技術で「できそうなこと」を把握したり、各事業部が「やりたいこと」を集めてくることになるでしょう。この「できそうなこと」「やりたいこと」を誰かが全体最適化してゴールが設定されます。

「全体最適」というと響きはよいですが、たいていの場合は誰かの「やりたいこと」を妥協することになるもので、優先順位をや実現可能性を踏まえてどこを妥協するのかを（文句言われないようにインセンティブを配ったりしながら）調整を進めていくことになるでしょう。優先順位の第一が "お金" になることが多いですが、議論を進めていくにしたがい "お金" だけじゃないね、となって核となるコンセプトが固まっていくものです。

この検討をおざなりに済ませてしまうと、コンセプトなく予算の許す範囲でできそうなことをやってみる、という結局何がしたいのかよくわからないようなプロジェクトになってしまいがちです。「どのようになったら今よりハッピーか」ということを考えてしっかり検討していきましょう。

「やってみなければ分からないからとりあえずやってみる」の是非

「データがあるのでとりあえず予測モデルはできますよね？」と言われることがよくあります。「そのデータ（から得られる結果）に何を期待しているのか」というところは棚上げにして、とりあえずためたデータを有効に使いたい！という感じが多かったりします。極端なことを言いますと「アメリカの天気の情報があるので、インドの人口変動を予測してください」といったオーダーに対して、モデルを組もうと思えば数理モデルとしては成立しますが、やって意味があるかどうかは疑問ですよね。ここまで極端な例ですと納得いただけるとは思いますが、気づかないうちにそれに似たようなことを言ってしまうことはあると思います。

私は「仮説」が大事だと思っています。やってみないと何も始まらないのは確かですが、「仮説」がないと「やってみた！」の壁を超えることは難しいでしょう。用意できるデータをありったけかき集めて AI に入れてしまうよりも、データを吟味して「このデータからこんな予測ができそうだ」という仮説を立てて進める方が結果として近道になる場合が多いように思います。不幸なことに「仮説に基づいて作成した数理モデルの出力の精度は期待ほどではなかった」という結果になるかもしれませんが、それはそれで、あらかじめ立てた仮説が否定される方向での知見が得られたことになり次の打ち手が浮かび上がってくるものです。

仮説のない「やってみた」だとうまくいけば良いのですが、うまくいかなかったときに手詰まりになりがちです。プロジェクトを円滑に進めるためにぜひ仮説を立てて進めていきましょう。

おわりに

AI活用プロジェクト立ち上げにおいて、普段私が気にしていることや思うことを書かせて頂きました。私自身いつも手探りな部分もあり、体系立ててお伝えできていないことは自覚しつつも、ここまでお読みいただいたことに感謝しつつ、少しでも何かのヒントになれば幸いでございます。

動画アーカイブページで、AIの要素技術をデータドリブンとルールドリブンという観点で整理し、アプローチ・技術選定の考え方をご紹介する動画を公開しています。よろしければこちらも併せてご覧ください。

動画アーカイブページはこちら

当社にお問い合わせいただいた方に個別にこのような議論をさせていただいています。AI活用の一歩目で悩んでいる方や、これから技術活用していきたいという方は是非ともお気軽にご相談ください。

▼AI技術活用の相談窓口はこちら
AI技術活用相談（オンラインウェビナーもあります）

今後お仕事のご縁があれば嬉しく思いますが、特段具体的な課題がない方も、まずは気軽にウェビナーにご参加いただければ嬉しいです。