Atmosphere Engineering Lab.

設計データのデータレイク・データウェアハウス・データマート — 他業界と製造業データのギャップ

はじめに

CFDデータのデータマネジメントでは、AI ReadyとMLOpsという2つの観点からCFDデータの管理を整理しました。 その中でRaw・Curated・ML-readyというレイヤー分けに触れましたが、これは実はアナリティクスの世界で何十年も前から使われてきた「データレイク・データウェアハウス・データマート」という型そのものです。

この記事では視点を変えて、EC・銀行のようにアナリティクス基盤が成熟した業界がどうデータを層に分けているかを起点に、なぜ製造業・設計データではこの型が当たり前に機能していないのかを掘り下げます。 そのうえで、実体データとメタデータを分けて管理するという考え方と、その加工パイプラインをサーバレスに実装するパターンまで見ていきます。

アナリティクスが成熟した業界の3層構造

EC・銀行のようにデータ活用が事業の中心にある業界では、データ基盤はおおよそ3つの層に分かれています。

  • データレイク: あらゆる形式の生データを、加工せずそのまま貯める層。スキーマは読み出す側が後から解釈する（schema-on-read）。EC ならクリックストリームやアプリのイベントログ、銀行なら勘定系システムのトランザクションログが、S3のようなオブジェクトストレージにそのまま流れ込みます
  • データウェアハウス: レイクのデータをクレンジング・正規化し、あらかじめ決めたスキーマに揃えて格納する層（schema-on-write）。誰がクエリを投げても同じ意味のテーブルが返ってくることを保証し、ここで初めて全社共通の「信頼できるデータ」になります
  • データマート: ウェアハウスのデータを、特定の部門・用途向けにさらに加工した層。ECならレコメンドエンジン用の特徴量テーブル、BIダッシュボード用の日次集計テーブル、銀行ならリスクスコアリング用・与信審査用のテーブルが、それぞれ別のマートとして存在します

銀行の例は特に示唆的です。 金融機関は規制上、「誰が・いつ・どの取引を・どのシステムで記録したか」という実体（取引記録そのもの）とメタデータ（記録の来歴）を厳密に分離し、両方を監査可能な状態で残すことを求められます。 取引データを直接書き換えることは許されず、修正はすべて追記として記録され、後から誰でも変更履歴を追跡できるようになっています。

この3層構造とガバナンスは、目新しい思想ではなく、大量データを継続的に・信頼できる形で扱うために行き着いた結果です。

製造業・設計データのギャップ

一方、CAD/CAEを中心とする設計データの世界では、この3層構造がほとんど機能していません。 理由はいくつかの点でEC・銀行のデータと性質が違うからです。

  • トランザクションの型が均一でない: ECの購買ログや銀行の取引記録は、「誰が・いつ・何を・いくつ」という共通の型に収まります。一方でCAEデータは、形状最適化なら設計変数と抗力係数、強度解析なら荷重条件と応力分布、熱流体なら境界条件と温度場というように、解析対象・目的ごとに必要な項目が根本的に異なり、業界横断の共通スキーマを作りにくい構造になっています
  • 実体データがソフトウェアによってまちまちで、可読性も低い: メッシュやフィールドデータは、ソルバーごとに異なる独自形式（OpenFOAMのケースディレクトリ、Fluentの.cas/.dat、STAR-CCM+の.simなど）で出力され、しかも1件あたりのサイズが数GBに達することも珍しくありません。EC・銀行のトランザクションがテキストや数値中心の軽量な構造化データであるのとは対照的です
  • schema-on-readすら整っていない: データレイクは「形式を問わず貯める」層ですが、それでも「どこに何があるか」を検索できるカタログが前提になっています。設計データの現場では、そのカタログ自体が存在せず、部門・プロジェクトごとに管理表（Excelなど）がバラバラに作られ、ファイルサーバの奥で個人の記憶に依存して探すしかない状態になっているケースが多く見られます

つまり製造業の設計データは、レイクにすらなっておらず、単なるファイルサーバに留まっているというのが実態に近いと感じています。 この状態からアナリティクス成熟業界の型を持ち込むには、標準化を諦めて業界固有の枠組みを一から作るのではなく、「何を実体として貯め、何をメタデータとして構造化するか」の切り分けから始めるのが現実的です。

実体データとメタデータを分けて管理する

設計データを扱いやすくする最初の一歩は、銀行の例にあった「実体とメタデータの分離」を持ち込むことです。

  • 実体データ: メッシュ、フィールドデータ、CADファイルなど、大容量でソルバー依存のバイナリ。書き換えを前提とせず、オブジェクトストレージ（S3など）にそのまま置き、case_idをキーにしたパスで一意に参照できるようにします
  • メタデータ: case_id・実行日時・ソルバー種別・設計変数・境界条件・メッシュ品質・収束ステータス・目的関数値・実体データの格納先といった構造化情報。前回の記事で挙げたスキーマがこれにあたり、DBやデータカタログ（AWSならDynamoDBやGlue Data Catalog）で管理します

1ケース分のメタデータは、たとえば次のような構造化レコードになります。

{
  "case_id": "case_00421",
  "created_at": "2026-08-06T03:12:00Z",
  "solver": { "name": "OpenFOAM", "version": "v2406" },
  "raw_data_uri": "s3://cfd-data-lake/raw/case_00421/",
  "design_vars": { "AoA_deg": 5.0, "chord_m": 1.2 },
  "conditions": { "inlet_velocity_mps": 20.0, "turbulence_model": "kOmegaSST" },
  "mesh_quality": { "max_skewness": 0.42, "negative_volume_cells": 0 },
  "convergence": { "final_residual": 8.7e-5, "converged": true },
  "objective": { "Cd": 0.031, "Cl": 0.412 },
  "status": "success"
}

raw_data_uriが実体データ（メッシュ・フィールドデータ）の格納先そのもので、case_idを介して両者が紐づきます。

design_varsをJSONのキーバリューにしているのは、値が未定・可変になりうるからです。 単発の解析ケースなら設計変数は存在しませんし、最適化ループでも形状の生成方法によって変数の数や名前が変わります。 固定の列を用意する代わりにキーバリューで持たせておけば、こうした値をそのまま格納できます。

この2つを分けずに、実体データのファイル名や配置場所に情報を埋め込んで管理する運用（case_0042_AoA5deg_converged.foamのような命名規則に頼る運用)は、項目が増えるたびにファイル名が破綻し、検索やフィルタもできません。 実体データはオブジェクトストレージに immutable なファイルとして置き、メタデータは構造化されたレコードとして別に持つことで、「境界条件が○○で収束したケースを一覧する」といったクエリが初めて可能になります。

生データとAI学習用データを別階層にする

実体・メタデータの分離ができたら、次はそれをレイク・ウェアハウス・マートの3層に対応づけます。 前回の記事のRaw・Curated・ML-readyというレイヤー分けは、実はこの型そのものです。

diagram rendering…
  • データレイク（Raw）: ソルバーが吐き出したファイル群を、加工せずそのまま保持する層。OpenFOAMならケースディレクトリ一式、Fluentなら.cas/.dat、STAR-CCM+なら.simというように、ソルバーごとに異なる形式のまま置きます。schema-on-readで、後から何にでも使えるよう再現性を優先します
  • データウェアハウス（Curated）: メタデータスキーマが確定し、品質ゲート（メッシュ品質・収束判定）を通過したケースだけが進む層。メタデータはクエリしやすい列指向形式（.parquet）で持ち、場データはソルバー非依存の共通スキーマであるCGNS（.cgns）に変換して統一します。メッシュ・境界条件・フィールドデータが標準化された構造で入っているため、どのソルバー由来のケースでも同じ読み方ができるようになり、ここで初めて「全社共通で信頼できるデータ」になります
  • データマート（ML-ready）: サロゲートモデルのアーキテクチャを選ぶで扱ったように、採用するアーキテクチャごとに必要な入力形式は異なります。規則格子に落としたCNN用は.npy/.h5、点群のままのPointNet用は.npz/.ply、グラフ化したGNN用はPyTorch Geometricの.pt形式や.npz（ノード・エッジ情報）というように、ウェアハウスのCGNSデータから用途別に複数のマートを作ることになります

この対応づけの利点は、「学習タスクが増えるたびに生データからやり直す」という事態を避けられることです。 ウェアハウス層まで整えておけば、新しいアーキテクチャを試したいときはそこからマートを作り直すだけで済み、Rawまで遡る必要がありません。

加工パイプラインの整備 — サーバレスパターン

レイクからウェアハウス、ウェアハウスからマートへの変換は、手作業のスクリプトではなく、イベント駆動のパイプラインとしてコード化しておきたい部分です。 解析ジョブは常時発生するわけではなく、最適化ループやサロゲート学習のタイミングでバースト的に大量発生する性質を持ちます。 そのため、常時稼働のサーバを維持するより、オンデマンドで(需要に応じて)スケールアップできるサーバレス構成のほうが適しています。

たとえば、AWSでパイプラインを組むと次のようなパターンが実務的です。

diagram rendering…
  • S3イベント起点のメタデータ登録: 計算結果がRawバケットに置かれたことをトリガーとして、AWS Lambdaが起動し、境界条件・メッシュ品質・収束履歴などをパースしてメタデータカタログに登録します。実体データ（S3上のファイル）とメタデータ（カタログのレコード）がcase_idで紐づく形です
  • Step Functionsによる品質ゲートの状態遷移: メッシュ品質・収束品質のチェックをStep Functionsにより実行していきます。各ケースが独立した1つの実行（Execution）になるため、途中で失敗したケースだけを狙って再実行でき、「発散したケースのせいで全体をやり直す」事態を避けられます
  • 変換処理の使い分け: メタデータのパースや軽量な判定はLambdaで十分ですが、メッシュの再サンプリングや点群化のような重い変換は、Lambdaの実行時間・メモリ制約に収まらないことがあります。その場合はAWS BatchやFargateに処理を委譲し、Step Functionsからは同じように1ステートとして呼び出す構成にすると、パイプライン全体の見通しを保てます

この構成が優れているのは、パイプラインの各ステップが疎結合な単位になっていることです。 品質ゲートの基準を見直したいときはそのLambdaだけを差し替えればよく、新しいアーキテクチャ向けのマートを追加したいときは、Step Functionsの後段に変換ステップを1つ足すだけで済みます。

おわりに

データレイク・データウェアハウス・データマートという型そのものは、EC・銀行のようなアナリティクス成熟業界がすでに答えを出している問題です。 製造業の設計データがそこに追いついていないのは、トランザクションの型が均一でないこと、実体データが大容量のベンダー依存バイナリであることに起因する、構造的なギャップだと捉えています。

だからといって一から独自の枠組みを作る必要はなく、「実体データとメタデータを分けて管理する」「生データと用途別の加工データを階層で分ける」という2つの原則を持ち込むだけで、既存のアナリティクス基盤の型とパイプラインパターンの多くがそのまま流用できます。 サーバレスな加工パイプラインは、その原則をコード化して継続的に回すための、現実的な実装手段のひとつだと考えています。