Lesson 0006: MaiML のデータ蓄積ベストプラクティスとシステム構成

MaiML のデータモデルを理解した次の実務的な疑問は、「日々の測定で発生する MaiML や生画像ファイルを、具体的にどのようなフォルダ構成やシステム構成で保存・管理していくべきか？」 という点です。

結論から言うと、最初から巨大な Web アプリケーションを一から開発する必要はありません。まずは「標準化されたフォルダ・ファイル規約」からスタートし、規模や共同研究・自動化の要件に応じて段階的にサーバー・Web システムへ発展させるのが最も手戻りの少ないベストプラクティスです。

1. フェーズ 1: ファイルシステム運用のベストプラクティス (小規模・PoC)

実験室内の NAS や共有ストレージ上に、以下のような「自己完結型」のディレクトリ階層を設けます。

/data/analytical_archive/
├── protocols/                                # 共通プロトコル定義 (資産)
│   ├── protocol_sem_eds_v1.maiml
│   └── protocol_xrd_v2.maiml
│
└── runs/                                     # 日々の測定実行データ
    └── 2026-09/
        └── LOT-202609-A20/                   # サンプル/ロット単位
            └── RUN_001_SEM-EDS/              # 1回の測定実行単位
                ├── run_metadata.maiml        # 完全なMaiML (Document, Protocol, Data, EventLog)
                └── raw/                      # 外部参照バイナリ (TIFF, CSV, HDF5等)
                    ├── sem_micrograph_01.tif
                    └── eds_spectrum_raw.csv

2. サーバーや Web アプリケーションを用意すべきか？

「Web アプリケーションを作るべきか？」に対する判断基準は、主に以下の 3 つの課題に直面したタイミングです。

3. 推奨システムアーキテクチャ (フェーズ 2 & 3)

Web システムを構築する場合でも、ゼロから巨大なフルスタックアプリを作るのではなく、「オブジェクトストレージ」＋「軽量メタデータDB」＋「REST API」 の疎結合アーキテクチャが標準的です。

【分析装置・Edge PC】
      │ (自動監視スクリプト: watchdog / pymaiml)
      ▼
【バックエンド / API サーバー】
  ├── (1) 実体ファイル保存 ──────> 【オブジェクトストレージ (MinIO / S3)】
  │                                ├── *.maiml (XMLメタデータ)
  │                                └── raw/ (大容量TIFF, バイナリ)
  │
  └── (2) メタデータ抽出・登録 ──> 【検索データベース (PostgreSQL / MongoDB)】
                                   ├── サンプル名, 元素, 条件, 粒子径指標
                                   └── MaiML XML への S3 URI リンク
      ▲
      │ (REST API / GraphQL)
【Web UI ダッシュボード / MI (マテリアルズインフォマティクス) パイプライン】

4. 理解度チェック (Retrieval Practice)