【PR】「しくじり」から学ぶAI開発で失敗しないためのポイントは?

menu

×AI

【PR】「しくじり」から学ぶ
AI開発で失敗しないためのポイントは?

ディープラーニングやビッグデータなどの技術革新、人手不足やDX化推進といった社会的・経済的な構造変化により、近年再び注目度が高まっているAI。「第三次ブーム」と言われるほど需要が増しているなかで、各企業で聞こえてきているのが「AIを導入したけど、上手くいかなかった…」という声です。AI導入に失敗してしまう要因はどこにあるのかをリサーチしました。

AI導入はなぜ失敗する?

AI

AI導入には労働力不足の解消、生産性の向上、人件費削減といった様々なメリットが享受できるにも関わらず、なぜ「失敗してしまった」という声が多く聞かれるのでしょうか?
よくある失敗例をAI開発の工程・フェーズごとに調べてみました。

フェーズ別:AI導入あるある失敗例

①企画・プロジェクト発足

  • AIの知識が浅いまま企画だけが立ち上がってしまった。
  • いつの間にかAI導入がプロジェクトの「目的」になってしまった。
  • 上層部や現場の理解を得られていない。

②ベンダー選定

  • 納期やコスト、完成したAI の権利について詳細な確認、合意を取らなかった。
  • よく検討せず、付き合いのあるベンダーに依頼してしまった。
  • ベンダーが指示待ちで、自発的に動いてくれない。

③要件定義

  • 必要な機能、動作が明確になっていない。
  • 要件の再確認をせずに進めてしまい、定量的なGOALを定めなかった。
  • どんなデータが必要かを確認しなかった。

④データ収集

  • アノテーション時、結果がグレーでもそのまま正解データとして使ってしまった。
  • 部署ごとにデータの管理方法、ラベリングなどがバラバラ。
  • データ収集に対して現場が非協力的。

⑤PoC(概念実証)

  • 見切り発車でPoCを実施してしまった。
  • 適切な問題設定をしなかった。
  • 精度が出ず、終わりのない検証を繰り返す。

⑥システム開発

  • 評価点が不明瞭で、検証が不十分だった。
  • 既存システムとの連携を考慮していなかった。
  • 想定よりもコストが膨大になってしまった。

⑦本番運用

  • 納品してもらったが、実際は現場で使えなかった。
  • 現場が求める精度や使いやすさが不足していた。
  • 運用後の再学習・カスタマイズを想定していなかった。

⑧保守・学習

  • ベンダー側から保守運用を丸投げされた。
  • AIを理解し、活用できる人材が自社にいない。
  • 社内でAIの利便性を浸透させられない。

主にWeb上の情報をリサーチしていくと、上記のような失敗例がありましたが、実際の現場ではどのような失敗が起きているのでしょうか?またAI開発で失敗しないためにはどのような点に関して、気をつけるべきでしょうか?

味の素・NTTコミュニケーションズ・大林組・博報堂など、業界を問わず数々の取引実績があり、“効くAI”を掲げる株式会社 Laboro.AI (ラボロ エーアイ)に、「実際に現場で起きているAI導入の失敗例」と「AI開発で失敗しないためのポイント」を伺ってきました

【PROFILE】株式会社Laboro.AI (ラボロ エーアイ)

株式会社Laboro.AI (ラボロ エーアイ)

引用元URL:Laboro.AI(https://laboro.ai/)

人工知能を用いたソリューション開発、AI活用に関するコンサルティング事業などを手掛けるAIベンダー。オーダーメイドによる「カスタムAI」の開発や提供を行ない、クライアントビジネスの真価を強くするためのAI開発を心掛けている。2016年4月、設立。

【インタビュー】
AI受託開発ベンダーに聞く!
実際に起きているAI開発の失敗例とは?

本メディアのインタビュー取材に応じてくれたのは、株式会社Laboro.AIでマーケティングディレクターを務める和田崇さんと、シニアソリューションデザイナの高塚皓正さん。
ビジネスとAIの最前線で日々クライアントの課題解決に向き合っているお二人に、今まさに起きているAI開発・AI導入の失敗例や、失敗しないための考え方や対策についてお話しを伺いました。

株式会社Laboro.AI (ラボロ エーアイ)、和田崇さん・高塚皓正さん

写真右:マーケティングディレクターの和田崇さん
写真左:シニアソリューションデザイナの高塚皓正さん

―御社は「他社で一度AI開発に失敗してしまった」という企業様から開発を依頼されるケースも多いかと思います。そういった企業様がよく陥りがちな失敗は、どんなものが挙げられますか?

和田さん:失敗の要因を大きく分けると、2つあると思っています。
ひとつは、私たちのようなAIの受託開発ベンダーに依頼する“外部由来の失敗例”。もうひとつが、社内でAIを内製化した場合に起きる“内部由来の失敗例”です。

AIは技術専門性が高い分野の一つで、「言われたものをそのまま作る」でうまくいくことはまずありません。ですが、ベンダー側が「何のためにAIを使うのか」「現場ではどう使うのか」を企業としっかり話し合いをせず、単に依頼されたとおりに作り、結果的に現場では使えないAIが出来上がってしまう。これがよくある「外部由来の失敗例」です。

たしかに言われたとおりに作ってはいるので、ベンダー側に非はないようにも見えます。ですが、使えないAIが出来上がってしまうという結末は両者にとって不幸でしかなく、そこには少なからずベンダー側の責任もあるように思います。

「我々は開発屋だ」という技術力を優先する思考の強いベンダーだと、こういう失敗は特に起こりがちですね。

―「言われた通りに作っている」のに、なぜ失敗してしまうのでしょうか?

高塚さん:典型的な例のひとつは、トップダウンでプロジェクトが進み「AIを作ることが目的化」しているケースですね。そもそもどんな課題を解決するためにAIを作るのか、という視点が抜け落ちてしまうと、いざ納品した際に「現場が全然使ってくれない」という最悪の事態を招いてしまいます。

全体的に見れば、お客様のAIに対するリテラシーが上がっているので、こういうケースは減ってきてはいますが、ありがちな失敗例のひとつではあります。

和田さん:外部ベンダーに依頼するケースで言うと、パッケージ型のAIを導入して失敗した例も挙げられますね。パッケージ型のAIは汎用的な機能を備えた製品で、比較的低コストで導入できます。

例えば、初めてAIを導入する企業様ですと、「まずは安いものから試してみよう」というコスト優先の思考に陥りがちで、課題を解決できそうもないパッケージ型AIを採用してしまうことがしばしばあります。

もちろんパッケージ型AIにもメリットはありますが、共通の問題を抱える広い層に向けて開発されたものなので、企業特有の複雑な課題解決には向いていません。

対照的に、企業個々の課題にあわせてカスタムしたAIで解決に導くのが、我々のような受託開発ベンダーです。DX化推進といった大きなプロジェクトになればなるほど、大きなビジネスインパクトが求められますし、汎用的な機能でそういった期待には応えられることはほとんどありません。やはりその企業、現場ごとに合わせて作る受託開発的なアプローチが必要になります

―ウェブ上のAIの失敗事例を調査していると、「そもそもAIへの理解が乏しい」「AIなら何でも解決できると過大な期待を頂いてしまう」という声もよく見かけました。おふたりから見て、こういったお客様は多い印象を受けますか?

和田さん:ゼロというわけではありませんが、数年前に比べるとかなり減ってきているのではないでしょうか。最近はAIの内製化やAI人材の育成に力を入れていらっしゃる企業様とご一緒させていただく機会もありますし、技術リテラシーは上がってきている気がします。
なかには、こちらがビックリするくらい詳しい方もいらっしゃいますよ(笑)。

高塚さん:私もその実感はありますね。今おっしゃった「AIなら何でもできる」と思っているような方は、少数派になりつつあります

ただ、あえて厳しい見方をすれば、ベンダーからの提案に対して、それが正しいか、本当に自分たちのビジネスが役立つのか、そこまで考え抜いて正確に判断を下せる企業様はまだ多くありません。

例えば、機械学習なら「教師あり学習」を使わないと解決できそうもない課題に対して、ベンダー側から「教師なし学習」を提案されてもそのまま受け入れてしまうとか…。
内製化や人材育成を進めている企業様であっても、こういった失敗は起こりがちです

株式会社Laboro.AI (ラボロ エーアイ)、高塚皓正さん

Laboro.AIでシニアソリューションデザイナを務める高塚さん

―和田さんが冒頭で二つ目の失敗例に挙げていた「社内でAIを内製化した場合の“内部由来の失敗例”」というのは、こういった例のことですか?

和田さん:そうですね。いくら理解が進んでいるとはいえ、AIはまだまだ開発から運用まで完全に内製化できるような、簡単な領域ではありません。AI人材の育成に取り組まれて、実際に成果を上げていらっしゃる企業様もいらっしゃいますが、あくまでごく一部の成功事例。やはりAIに関する高度な専門知識、経験やノウハウを持った外部サポーターは必要な段階です。

高塚さん:最近では、自社でエンジニアさんを雇っている企業様も増えています。ただ、そのエンジニアさんのスキルや知見を持ってしても理解できず、「(他社から導入した)AIがどうやって動いているのかわからないから、教えてほしい」という問い合わせを頂くことがあります。

なかにはソースコードを開示しないで、バイナリの状態で納品するベンダーさんもいらっしゃいますからね。そうすると、何かあったときにエンジニアがソースコードを触れず、どんどんAIの精度が悪くなってしまいます。

―御社は「効くAI」というコンセプトを掲げ、現場で実際に使えるデジタルツールとしてのAIを追求していらっしゃいます。ここまで挙げて頂いたような失敗例を起こさないために、どのようなアプローチを取られていますか?

高塚さん徹底的に伴走する、ということですね。
イチから開発をご依頼頂くケースでいえば、プロジェクトの初期、企画の立ち上げの段階、あるいは要件定義の段階から、ご一緒させていただきます。
我々は「言われたとおりに作ります」という受け身スタンスのベンダーではありません。「何のためにAIを作るのか」「導入後にどうやってAIを使っていくのか」をかなり踏み込んで一緒に議論していきます。

ご依頼頂いたお客様からは、
「ここまで一緒に考えてくれるベンダーは他にいなかった」
「どんな課題に対しても拒否の姿勢ではなく、前向きに考えてくれる」
といった声をよくいただきます。

伴走していくうえで、最初に行なうのが課題の再定義。例えば、過去に一度AI開発に失敗してしまった企業様からご依頼いただくケースだと、「そもそもそれは解決すべき課題だったのか」「本当にその課題は会社として解決すべきなのか」という段階から問題を考え直します。
そこから「AIで何が解決できるのか」「本当にAIが必要なのか」を話し合います。

―「AIが必要ない」という結論になることもあるのですか?

高塚さん:勿論あります。その場合、我々の担当領域は開発には及ばず、コンサルティングまでとなります。また、すでにお客様が何かしらAIのプロダクトを持っていて、それをうまく使って課題を解決できる可能性があれば、そちらをオススメするという考え方なんです。

なぜなら、我々のミッションはお客様のビジネス課題を解決することであって、AIを開発することではないからです

和田さん:我々はパッケージAIのような形ある商品を持っているわけでもありませんし、あくまでお客様のビジネスを高めることに使命感を持って仕事に取り組んでいます。そういう意識は、役職に関わらず、弊社の社員全員が持っていると思います。

高塚さん:たしかに「商品を持っていない」というのは、ある意味弊社の強みだと思います。パッケージの商品を持っていると、どうしても「売ろう」という意識が働いてしまい、課題解決の方法を無理矢理パッケージに当てはめようとしてしまいます。

課題を解決するためのソリューションは、一つとは限りません。AIの分野では、例えば、画像認識で解決できると思っていた課題が、実は音声認識など別の方法で解決できることがよくありますから。

株式会社Laboro.AI (ラボロ エーアイ)、和田崇さん

マーケティングディレクターの和田崇さん

―御社が「ソリューションデザイン」と呼ばれる、コンサルティングとサポートに力を入れているのは、そういった徹底した課題解決の意識があるからですか?

和田さん:はい。我々はAIをデザインすることよりも、「ビジネスソリューションをデザインする」ことを心掛けています。弊社ではAIの専門知識はもちろん、豊富なビジネス経験や業界特有のドメイン知識を備えた「ソリューションデザイナ」とAIに関する先端技術、開発・実装に関する豊富な知見を持つ「機械学習エンジニア」の2チームがタッグを組んで、企業様の課題に向き合います。

そのソリューションデザインの真髄と言えるのが、先ほどお話しさせて頂いた「課題の再定義」です。課題の再定義は最初に一回だけ、というわけではありません。様々なフェーズで、何度も繰り返し行ないます。ビジネスと技術の両面から見て、「目的は何なのか」「そもそも必要なのか」「本当に使えるのか」…。遠回りのようですが、こういったやり取りを繰り返して、ビジネスと技術という2つの視点を高めていくことで、初めてツールとして使えるビジネスAIを導入することができるのです。

高塚さん:お客様と議論することは、とても大切です。何度も話し合うことでお客様のビジネスに関して我々も理解が深まりますし、お客様もAIを理解してくださいます。

また、議論することで、お客様の社内で気付きが生まれこともありますね。我々の投げかけに対して、「私は○○だと思う」「いや、私の完成イメージは違う。△△だ」といった具合に話し合っていただき、社内のディスカッションだけでは気付けなかった部分まで、深い認識のすり合わせを行なうことができます。こういう密度の高いコミュニケーションを早い段階でやっておくと、「思っていたのと違う…」「現場では使えなかった…」という失敗を未然に防ぐことができます

―ソリューションデザインの真髄とおっしゃっていた「課題の再定義」が具体的に活かされた事例を教えてください。

和田さん:たくさんありますが、弊社の公式ホームページに記載している「大手生命保険会社様」の事例が分かりやすい例の一つです。

開発事例:画像アプローチからの手書き文字の読み取り

Laboro.AI対応事例)画像アプローチからの手書き文字の読み取り/大手保険会社様

引用元URL:Laboro.AI公式HP
(https://laboro.ai/case/画像系アプローチからの手書き文字の読み取り/)

事例を公式HPで詳しく見る

詳細は事例に記載しているとおりですが、簡単に言いますと、もともと企業様側では手書き文字をOCRで認識させようと四苦八苦していたところ、発想を転換させて画像認識で課題を解決できた事例です。
これも技術思考が強すぎると、OCRの精度を高める方向に進んでしまい、いつまで経っても文字が読み込めないという袋小路に陥ってしまいます。

このケースで言うと、必ずしも文字を読み込む必要はありませんでした。診断書の内容と病名コードと紐づけば問題なく、画像識別の技術を使って紐づけに成功しました。
このように課題を再定義し直すと、解くべき問題が変わり、使う技術も変わってきます。こういった発想の転換や一歩引いたスタンス、柔軟なアプローチが採れるのは弊社ならではの強みと言えます。

高塚さん:弊社のソリューションデザイナとエンジニアは、ビジネスとAIに関してどちらも深い知識と技術を持ち合わせています。この両輪がしっかり機能しているからこそ、課題の再定義が可能になるのだと思います。知識や技術が特定の分野に偏ると、解決するための手段が限られるので、本質的な問題に気付きにくくなってしまいます。

―ちなみに、高塚さんのようなソリューションデザイナの方はどんな経歴をお持ちなのでしょうか?やはり「AIに詳しい」というのが採用の前提になるのでしょうか?

高塚さん:AIは大学のときに学んでいましたが、仕事として携わるのは実はLaboro.AIが初めてでした。前職は事業会社で、新規事業や経営企画などに携わっていました。

和田さん:高塚は新規事業の立ち上げなどの業務ノウハウはもちろんですが、とくに製造業の専門的なドメイン知識を備えています。その他のメンバーとしては、ビジネスコンサルファームや戦略コンサルファームで、いろんな企業のビジネスに携わってきた経験を持つ人材がいます。

弊社で働くソリューションデザイナの経歴は様々ですが、共通しているのは、技術ノウハウよりも、ビジネス起点の思考を持っていること。そういう人材を積極的に採用しています。

―意外です…。てっきりAIの知識が優先されるものだと思っていました。

和田さん:よく言われます(笑)。もちろん、AIの知識やノウハウを当初から保有していれば強いことに間違いないのですが、ビジネスとAIを天秤にかけたときに、より習得が難しいのがビジネス側の知見なんです。
極端な話をすれば、AIの情報は今やネット上に溢れていて形式知化されていますし、論文などを読んで独学で習得することも比較的やりやすくなっています。

一方、ビジネスのノウハウは、やはり現場で経験してみないと得られません。そういう考えもあって、強いビジネスバックグラウンドを持つ方をより重視させて頂いています。

―御社をはじめ、AIベンダーも多種多様になってきています。そんな中で、自社に合ったベンダーを選ぶにはどんな点に注意すべきでしょうか?

高塚さん:ベンダーを選定する前に、まず自社がどれだけAIを理解しているのかを把握しておく必要があると思います。内製化できる社内体制が整っていて、ビジネス運用のノウハウも持っているなら、開発のみに特化したベンダーに依頼するのもアリだと思います。
ただ、そこまでのAIへの理解が進んでいない場合は、弊社のようにビジネス視点を持ち、踏み込んだ議論ができるようなベンダーが向いているのではないでしょうか。
遠回りかもしれませんが、そのほうが結果的に使えるAIが導入できる可能性が高くなりますし、運用もスムーズに行くと思います。

和田さん:我々はお客様のビジネスを理解するために、例えばその業界の専門知識を専門書から学ぶなどして、お客様とのお話し合いに必要な前提知識の獲得にまず力を注ぎます。

同じように、お客様側からもAIの領域に対して一歩、踏み込んできてほしいという気持ちもあります。お互いがお互いの領域の知識を少しでも得ることによって、共通言語ができ、AIの開発・導入に必要な意見交換がより濃密なものとできるからです。

相手の領域にはみ出す、覚悟と努力
これを携えてベンダーと向き合うのが、ベンダー選びはもちろんAI開発・導入・活用を成功に導く一番のポイントではないでしょうか。

【まとめ】AI開発はなぜ失敗する?

株式会社Laboro.AIに取材してわかったのは、AI開発におけるコミュニケーションの重要性です。「使えないAI」が出来上がってしまうのは、AI導入が目的化していたり、運用の想定が不十分だったりした場合に起きること。そういった失敗を起こさないためにも、プロジェクト初期の段階から「何のため導入するのか」「現場ではどう使うのか」などを十分にベンダーと議論してくことが大切です。
内製化するにしても、運用のノウハウは必須。ただソースコードを見るのではなく、検討した内容や意思決定の背景までベンダーと確認しながら進めていくことで、スムーズな運用が可能になるはずです。

Laboro.AIは「ソリューションデザイン」という徹底した課題解決思考を持ち、クライアントと伴走しながら“効くAI”を一緒に作り上げる受託開発ベンダーです。「本当に現場で使えるAIを導入したい」とお考えの方はホームページから詳細をチェックしてみてください。

Laboro.AIについて
詳しく見る

関連記事