Data Engineeringとは

アルゴリズムより先にデータ基盤を整えるData Engineeringの全体像

AIモデルの精度はアルゴリズムではなくデータで決まる。これは現場の常識である。だが多くの企業はデータサイエンスにばかり予算を投じる。

本当に必要なのはData Engineeringである。

社内のファイルサーバーに眠るExcel、基幹システムの古いデータベース、外部APIから取得したJSON。これらはそのままではAIに食わせられない。フォーマットの不一致や欠損値が山のようにあるからである。これを放置して機械学習を回してもゴミしか出てこない。

どこまでデータを綺麗にするか。これは常に悩ましい。

データの収集からAIモデル連携までのプロセス

データパイプラインの構築は泥臭い作業の連続である。

まずETLツールでデータを抽出・変換・ロードする。オンプレミスのOracle DBからデータを吸い上げ、データレイクに生データとして放り込む。そこから必要なデータだけを抽出し、データウェアハウスに格納する。

この一連の流れをどう設計するかで、後続のAIモデルのパフォーマンスが劇的に変わる。

バッチ処理で夜間に回すのか、ストリーミングでリアルタイム処理するのか。要件によって判断が分かれる。

物流ネットワークにおける泥臭いデータ統合と主要ツール

物流業界の配車計画AIを構築した時のこと。

各営業所がバラバラのフォーマットで持っている配車実績データを統合する必要があった。ここで活躍したのがSnowflakeとdbtである。Snowflakeのコンピュートリソースを柔軟にスケールさせながら、dbtでSQLベースのデータ変換をゴリゴリ書いた。

ワークフロー管理にはApache Airflowを使った。

ツールを導入すれば解決するわけではない。現場のドライバーが入力する手書きの日報データをどうデジタル化してパイプラインに乗せるか。ここが一番の落とし穴だった。

データ基盤整備の投資対効果と現場の落とし穴

データ基盤の構築には莫大なクラウドインフラ費用がかかる。BigQueryのクエリ課金で月末に青ざめた経験はないだろうか。

経営陣はすぐにROIを求めてくる。だがデータガバナンスの整備やパイプラインの安定稼働は、すぐには売上に直結しない。ここで予算が尽きてプロジェクトが頓挫するケースを山ほど見てきた。

スモールスタートでPoCを回すのは一つの手だが、本番環境への移行時にアーキテクチャの作り直しが発生することも多い。最初からスケーラビリティを考慮すべきか、とりあえず動くものを作るか。正解はない。

自社にデータエンジニアリング体制が必要か見極める基準

すべての企業に専任のデータエンジニアが必要なわけではない。

扱うデータが数GB程度で、更新頻度も月に1回なら、SaaSの標準機能で十分かもしれない。しかしテラバイト級のデータを日次で処理し、独自のAIモデルを運用するなら内製化は避けられない。

外注に丸投げするとどうなるか。

業務ドメインの知識がないベンダーが作ったパイプラインは、ちょっとした仕様変更で簡単に壊れる。自社のデータは自社で面倒を見る覚悟があるか。そこが分かれ道である。