モード変更


    言語

AIの産業化とデータの課題

2022/05/24

AI の産業化とデータの課題

AI が事業に活用されるようになって久しいですが、実のところ、現在の AI 事業はほぼラボの延長です。さまざまな産業の中で共通化され、相互運用性を持ったツールとして使われている状況とは、まだまだなっていません。 その理由はデータをとりまく環境にあるのではないかと思います。データの見直しなくして、AI の産業化はありません。

AI の産業化とはなにか

さまざまな業種のなかで、すでに AI が使われはじめているのは確かです。例えば画像認識技術によって、スマートフォンのロックは解除されますし、スマートスピーカーは、あなたの声を識別して応答するなど、さまざまなケースがあるでしょう。

しかしそれらは、産業全体からみるとごく一部に過ぎません。 農業・漁業・建設業・製造業・運輸業・小売業・金融業・不動産業・教育・研究・技術サービス、これらの各業種では、確かに AI の成果は聞こえ始めていますが、それらはまだまだ点在しているような状況です。

ここでいう「産業化」の定義は曖昧ですが、一般的には工業化と同じ意味でも使われます。つまり、「AI の産業化」とは、産業全体において AI が入り込み、富を生み出すような状況のイメージでここでは捉えています。

しかし現在のところ、少数の専門家が、特定の事業領域において AI を使って成果を上げる、いわゆる研究開発の成果を既存の業務に適用させるのが実情です。

多数の AI 人材が、部門や業種を超えたさまざまなデータを取り込んで、最大の効果を得るのには、まだまだ難しい状況にあると思います。

いっぽう、そうした状況に対し、AI 技術にそこまで習熟しなくとも、ある程度の結果を出すことのできる、AutoML といったソリューションが生まれ、気軽に学習や最適化を行える環境にはなってきました。

しかしそうした AI に関するツールだけでは、この問題は解決することはないように見えます。

これらの状況から推察するに、AI の産業化には

  • 体系的データ管理
  • 包括的なデータの民主化
  • 企業としてのデータガバナンス

といった課題への取り組みが求められると考えられます。

産業において AI はどこまで活用されているか

昨今、さまざまな産業において AI がキーとなるとされてきましたが、実際のところはどうでしょうか。

AI には潤沢なデータが必要です。しかし実際、それらのデータはどのようにデータ基盤に保持されているでしょうか?

例えば、ある EC サイトがあったとします。そこでの売上やユーザ行動といったデータは、ある程度 DWH 的なものに保持され、活用されるようになっていることでしょう。

しかしそこで疑問が生まれます。これらをどのように AI と接続するのがよいでしょうか。

AI の現場は実際のところ、まだまだラボによるピンポイント的な活用にとどまっているように見えます。AI の力の源泉は、学習データにあるはずです。しかしながら学習対象となるデータは、ラボに閉じているケースが多いように思います。

本当の意味で AI を産業化するためには、まずは企業内で AI を意識してデータを整備しなければなりません。

体系的データ管理

現在のところ、学習のためのデータの流れは、目で追える範囲のパイプライン構造ではあるものの、それぞれのラインでの処理まで含めるとやはり複雑です。データの構造化やモデリングはそこそこ困難ですし、場合によっては非構造化データも含めた統合についても考えなければなりません。

そして、さまざまな AI ユースケースに対応できるような、パイプラインの再利用には、まだまだ超えるべき壁があるように感じます。それはデータスキーマの共通化が困難なだけではなく、AI モデルの求める形式も発展途上であることも影響しています。

そのメタデータは救いとなるか

データ環境の全体に適用可能な、魔法のようなメタデータ管理手法は今のところ無いように思います。おそらくそこにあるのは、テクニカルなメタデータばかりで(それはそれで重要ですが)、データを意味ある情報として捉えたときの、データ系譜(リネージュ)についての整理はどうでしょうか。

たとえば、データソースに変更が起きた場合、パイプライン全体に影響が起き、結果的にダッシュボードの信頼性に影響するでしょう。そうしたケースを考えると、データ系譜の体系的な管理がなされているかは、データシステム設計において重要な指標となります。

KPI をどう扱いますか

従来の DWH 領域で、KPI といったビジネス指標を扱うのは自然な流れでしょう。しかし私たちの今の課題は、それらと AI との接続です。どのようにデータレイクとデータマートを設計すれば、これらを効率的に扱えるでしょうか。

包括的なデータの民主化

データの民主化とは、一般的には組織内で自由にデータを利用できる状態のことを指します。これは、DHW の世界ではさまざまな BI ツールより実現できています。(できていないこともありますが)

しかし私たちの課題は AI におけるデータの民主化です。AI の学習目的で用いられるデータは、DWH に格納された分析データだけではなく、DHW 格納以前の段階の、非構造化データが含まれるのが一般です。そうした構造化され整理される以前の、あらゆるタイプのデータに、あらゆるユーザがアクセス可能となる環境を目指す必要がありますが、ここにもいくつかのハードルが存在します。

データプロビジョニング

データプロビジョニングとは、例えば IoT 機器などのデータを、データレイクに接続して抽出することを指します。ここでの課題は、テクニカルな側面では I/F やアクセス権の定義などが考えられます。そして、エンドユーザの協力の下、パイプラインを開発することになりますが、データの所有者を含めた調整が発生するため、多くの反復プロセスが発生し得ます。したがって、これらのデータを利用する予定の AI プロジェクトにとって、大きなボトルネックとなりうるポイントとなってしまいます。

データエンジニアリング

狭い意味でのデータエンジニアリングとは、データモデリングと結合、そしてクレンジングを指します。基本的には、一部のデータサイエンティストとデータエンジニアによって進められますが、ここにも困難がつきまといます。

データエンジニアリングには、ソースシステムにおける、データ構造に関する知識が求められます。そしてそれらを扱う包括的なプログラミング能力も求められ、技術の総合格闘技のような領域になりつつあります。

データ探索での課題

データから情報と知見を引き出すためには、データサイエンティストは R や Pandas、ときに Spark Job を扱うでしょうし、データアナリストは BI ツールを操作することでしょう。

しかしここでも問題が起きます。扱っているデータの品質はどこまでのものなのか、ビジネス上の意味の詳細はどうなっているのか、データエンジニアに確認しなければならないことでしょう。そしてそのデータに法律的に問題は有りませんか?それはおそらく法務部に確認することになるでしょう。

企業としてのデータガバナンス

データガバナンスとは、データを企業資産として扱うものとして組織構造を定義することを指します。

そのデータレイクにあるデータの所有者は誰ですか? それは大抵の場合、ソースシステムのデータ所有者のはずです。

つまり、データレイクにあるデータを統合して扱うためには、それぞれのデータ所有者の承認が必要です。したがって、データは企業資産ではなく、より小さな人格の資産として取り扱われます。

たとえば、ある部品を製造する企業があったとします。そこでは製造部門のデータと、ビジネス部門のデータを組み合わせて、AI 予測による保守サービスを展開するとします。この場合、データの所有者であるそれぞれの部門がデータに責任を追う必要がありますが、データの利用方法自体が当初の想定外である可能性があります。また、それらを組み合わせて AI 予測保守で利益を生んだとき、メリットはエンジニアリング部門に発生します。このとき組み合わせたデータの所有権は、元のデータソースの所有権は切り離して考えるのが妥当と思われます。

こうした部門間などの調整を含めたデータスチュワードシップについては、これまでは個人情報や商品情報などを中心として扱われてきました。しかしこれからは業務プロセスで発生するあらゆるデータに対して、企業全体としてポリシー設定が求められるでしょう。

AI 時代のデータエコシステムを求めて

これまで課題となる点を整理してきましたが、実際のところこれらを解決する妥当な結論や、スタンダードなフレームワークがあるわけではありません。

これらの問題領域について、MLOps が回答となるかと言われれば、あくまで Techie な側面なのかなと感じます。

引き続きデータエンジニアとして、これらの課題に役立つようなアイディアを、日々の業務の隙間からでも、作り出せていけたら良いなと、そう考えています。

Links

Data Warehousing in the Age of Artificial Intelligence

A Chat with Andrew on MLOps: From Model-centric to Data-centric AI

Article Photo by Luke Chesser

data engineeringmachine learning

Author

Yoshiaki Sano

Yoshiaki Sano

Data & Backend Engineer

Emacs lover

その他おすすめ記事

2024/11/05

エンタープライズデータ基盤における dbt の活用戦略

近年、データ駆動型の意思決定が企業の競争力を左右する重要な要素となっており、大規模かつ複雑なデータ基盤の構築が不可欠となっています。この潮流の中で、dbt(data build tool)は、エンタープライズレベルのデータ変換とモデリングを効率化する強力なツールとして注目を集めています。 dbt は、SQL を使用してデータ変換を定義し、バージョン管理、テスト、ドキュメンテーションを統合的に行うことができるオープンソースツールです。特に以下の点で、エンタープライズデータ基盤の構築に大きな価値をもたらします...

Yoshiaki Sano

Yoshiaki Sano

Architecture

2024/11/04

データエンジニアリング初心者でも分かる!dbtの魅力と基本

データ駆動型ビジネスが当たり前となった今日、多くの企業がデータ分析の課題に直面しています。複雑な SQL クエリの管理、データの整合性確保、分析プロセスの再現性など、様々な問題が山積みです。そんな中で注目を集めているのが「dbt(data build tool)」です。 本記事では、データエンジニアリングの深い知識がなくても理解できるよう、dbt の基本と魅力について解説します。 dbt とは? dbt は、SQL を中心としたデータ変換ワークフローを管理するためのオープンソースツールです。従来の SQL...

Yoshiaki Sano

Yoshiaki Sano

Architecture

サービス開発実績会社情報
採用情報インサイトお問い合わせ
© 2022 Monstarlab
情報セキュリティ基本方針個人情報の取り扱いについて個人情報保護方針