データ処理工程の「見える化」ダッシュボード

Goose × oh-my-mermaid によるパイプライン可視化ツールの試作提案

2026年10月作成 | 現行実装: viewer/(静的プロトタイプ) | 情報源: Goose 公式・oh-my-mermaid

コンセプトと狙い

データ処理パイプラインは、ステップが増えるほど「何が起きているか」を把握するコストが急増します。本提案は、次の2つのオープンソース技術を接合することで、処理工程そのものを「生きた設計図」として可視化します。

Goose

ヒープなし・GCなし・メモリ安全なシステム言語。JSON/CSVのパース、高速なデータ変換、軽量HTTPエンドポイントの提供に適しています。データスタックによるゼロコピー処理が、メトリクス収集のオーバーヘッドを最小化します。

oh-my-mermaid

コードベースから Mermaid ダイアグラムと7種類のメタ情報を生成・管理するフレームワーク。.omm/ ディレクトリによる「視点(Perspective)」単位の構成と、@class-name によるクラス間リンク機構を持ちます。

組み合わせの核となる発想は、「ダイアグラムを静的なドキュメントではなく、実行時メトリクスを反映するライブ・ビューとして扱う」ことです。Goose が処理パイプラインの内部状態を JSON で出力し、oh-my-mermaid のビューアがそれを読み込んでノードの色やラベルを動的に更新します。

全体アーキテクチャ

graph LR A[データソース] -->| raw | B[Goose パイプライン エンジン] B -->| metrics.json | C[.omm/ ストア] B -->| transformed | D[出力先] C -->| HTTP poll / SSE(将来) | E[oh-my-mermaid ビューア] E -->| @drill-down | F[詳細 Perspective] style B fill:#8ef0cf,color:#0b0b0b,stroke:#0b0b0b style E fill:#b8dcff,color:#0b0b0b,stroke:#0b0b0b

主要コンポーネント

層役割技術要素
収集層各処理ステップの入力量、出力量、処理時間、エラーを計測Goose struct StepMetrics
蓄積層メトリクスとダイアグラム定義を統合管理.omm/ ディレクトリ + meta.yaml
可視化層Mermaid ダイアグラムのレンダリングとリアルタイム更新oh-my-mermaid ビューア + ポーリング(SSE は将来対応)
ナビゲーション層ステップのドリルダウン、diff表示、参照関係追跡@step-name リンク + ブレッドクラム

Goose 側の実装設計

Goose の「データスタック・ゼロコピー」特性を活かし、メトリクス収集がパイプライン本体に与える影響をゼロに近づけます。

コアデータ構造

import std;
import json;
import os;

enum Status { Healthy, Warning, Error, External }

struct StepMetrics {
  step_id: u8[varint],
  label: u8[varint],
  records_in: varint,
  records_out: varint,
  elapsed_ms: f64,
  status: Status,
  message: u8[varint],
}

struct PipelineSnapshot {
  timestamp: u8[varint],
  steps: StepMetrics[varint],
}

実装済みビューアは、この基本構造に加えて quarantine(隔離ノード)と errors[](エラーイベント)を参照します。最終的な JSON 形式は README のスナップショット形式を参照してください。

パイプライン・ラッパー

各ステップを measure() でラップし、実行前後のカウンタ差分を自動記録します。Goose の「スコープ終了時に一括解放」されるデータスタックを利用することで、高頻度処理でもメモリリークのリスクを排除します。

fn measure(step_name: u8[:], input_count: varint,
           f: fn() -> varint) -> StepMetrics {
  let t0 = os.now_ms();
  let out_count = f();
  let elapsed = os.now_ms() - t0;
  return StepMetrics {
    step_id: step_name,
    label: step_name,
    records_in: input_count,
    records_out: out_count,
    elapsed_ms: elapsed,
    status: Status.Healthy,
    message: "",
  };
}

メトリクス出力(.omm 連携)

パイプライン実行のたびに .omm/data-pipeline/meta.yaml と diagram.mmd を更新します。Goose の JSON サンプル(18_json.goose)と同様、単一のプール内にツリーを構築してから一括書き出しします。現行プロトタイプでは meta.yaml は静的な設定ファイルとして扱い、JSON スナップショットのみを差し替えて表示を確認しています。

fn emit_snapshot(steps: StepMetrics[:], out_path: u8[:]) {
  var buf: u8[>..] = [];
  json.render(buf, steps);   // 標準ライブラリ json モジュール活用
  os.write_file(out_path, buf);
}

oh-my-mermaid 拡張設計

既存の oh-my-mermaid ビューアに、リアルタイムダッシュボードとしての機能を追加します。元の設計思想(Perspective ベース、@ リンク、7フィールド構成)を崩さずに拡張します。

追加 Perspective

.omm/ ├── config.yaml ├── overall-architecture/ │ ├── description.md │ ├── diagram.mmd # @data-pipeline, @error-handler 等 │ └── ... ├── data-pipeline/ │ ├── description.md │ ├── diagram.mmd # パイプライン本流(動的更新対象) │ ├── context.md │ ├── constraint.md │ ├── concern.md │ ├── todo.md │ ├── note.md │ └── meta.yaml # prev_diagram / live_metrics_url / pipelines ├── error-handler/ │ └── ... └── performance-metrics/ ├── description.md ├── diagram.mmd # 時系列ダイアグラム(Goose 生成) └── ...

meta.yaml 拡張

既存の prev_diagram 保持機構に加え、ライブメトリクスへの参照を追加します。以下は現行プロトタイプの設定例です(パスは meta.yaml からの相対パス)。

# meta.yaml 拡張案
updated: 2026-10-27T09:15:02Z
git_commit: a1b2c3d
prev_diagram: |-
  graph LR
    Extract["Extract"]:::healthy --> Transform["Transform"]:::warning
    Transform --> Load["Load"]:::healthy
    Transform -.->|errors| ErrorLog["@error-handler"]:::external
live_metrics_url: ../../viewer/data/metrics.json
poll_interval_ms: 2500
default_pipeline: etl-main
pipelines:
  - id: etl-main
    label: ETL 本流
    metrics_url: ../../viewer/data/metrics.json
    prev_url: ../../viewer/data/metrics-prev.json
  - id: etl-reporting
    label: 日次レポート
    metrics_url: ../../viewer/data/etl-reporting.json
    prev_url: ../../viewer/data/etl-reporting-prev.json
status_map:
  Healthy: "classDef healthy fill:#8ef0cf,stroke:#0b0b0b,color:#0b0b0b"
  Warning: "classDef warning fill:#ffc857,stroke:#0b0b0b,color:#0b0b0b"
  Error:   "classDef error fill:#ff6b6b,stroke:#0b0b0b,color:#0b0b0b"
  External: "classDef external fill:#b8dcff,stroke:#0b0b0b,color:#0b0b0b"

ビューア拡張機能

機能内容
設定駆動meta.yaml からメトリクス URL、ポーリング間隔、ステータス色、パイプライン一覧を解決
複数パイプラインpipelines[] をサイドバーのセレクタと ?pipeline= で切り替え
スキーマ検証必須フィールド、数値、前段との件数整合、隔離件数を表示前に検証
リアルタイム色反映metrics.json の status に応じ、Mermaid ノードに classDef を動的注入
スループットオーバーレイノードラベルに records_in → records_out と elapsed_ms をバッジ表示
Diff モードprev_url の前回 JSON と現在値を比較し、レコード数・処理時間の変化をハイライト(prev_diagram の図差分は将来対応)
アラート連携Status.Error のステップを上部とサイドバーに自動表示、ブレッドクラムに警告アイコン表示

現行プロトタイプでは、設定駆動・複数パイプライン切替・スキーマ検証・Diff・アラートを実装済みです。リアルタイム更新は poll_interval_ms(既定 2.5 秒)間隔のポーリングで行い、SSE / WebSocket と Goose ランタイムへの実接続は未実装です。

ダッシュボード UI 仕様

oh-my-mermaid ビューアのインターフェースに、ダッシュボード特有の情報を追加します。

画面構成

┌─────────────────────────────────────────────────────┐ │ Pipeline Viz [更新: 09:15:02] [Diff] [Alert] │ ├──────────┬────────────────────────────────────────────┤ │ Classes │ ┌────────────────────────────────────┐ │ │ │ │ ┌─────┐ ┌─────┐ ┌─────┐ │ │ │ ● data │ │ │Extract│──│Transform│──│Load │ │ │ │ pipeline│ │ │ 1.2k │ │ 1.1k │ │ 1.1k│ │ │ │ error │ │ │ 46ms │ │ 121ms│ │ 31ms│ │ │ │ perform│ │ └─────┘ └─────┘ └─────┘ │ │ │ │ │ ↘ @error-handler │ │ │ │ └────────────────────────────────────┘ │ │ │ │ │ │ Description │ │ │ ETL パイプラインの主要3ステップを示す │ │ │ │ │ │ Metrics (auto) │ │ │ • スループット: 5,960 rec/s │ │ │ • 隔離率: 4.84% │ │ │ • 遅延ステップ: Transform (121ms) │ │ │ │ │ │ Meta │ │ │ Updated: 2026-10-27 09:15:02 │ └──────────┴──────────────────────────────────────────┘

状態色の定義

Healthy(正常)
Warning(遅延・欠損あり)
Error(処理失敗)
External(外部依存)

ファイル構成と実装ステップ

目標リポジトリ構成

以下は Goose 実装を含む目標構成です。現行プロトタイプには viewer/、.omm/(config.yaml と data-pipeline/{meta.yaml, diagram.mmd})、サンプル JSON が含まれ、src/、Makefile、各 Perspective の説明 Markdown は未実装です。

PipelineViz/ ├── src/ │ ├── main.goose # エントリーポイント │ ├── pipeline.goose # ETL ステップ定義 │ ├── metrics.goose # メトリクス収集・JSON出力 │ └── server.goose # 静的ファイル配信 + SSE ├── .omm/ │ ├── config.yaml │ ├── data-pipeline/ │ │ ├── description.md │ │ ├── diagram.mmd │ │ ├── context.md │ │ ├── concern.md │ │ └── meta.yaml │ └── error-handler/ │ └── ... ├── viewer/ │ └── index.html # oh-my-mermaid ビューア拡張版 ├── Makefile └── README.md

実装ロードマップ

  1. Phase 1 — Goose パイプライン原型
    3ステップのサンプル ETL(Extract → Transform → Load)を Goose で実装し、StepMetrics の計測と JSON 出力を確認します。
  2. Phase 2 — .omm/ 連携
    omm init で data-pipeline / error-handler Perspective を作成し、diagram.mmd に @ リンクを埋め込みます。
  3. Phase 3 — ビューア拡張
    oh-my-mermaid ビューアに metrics_url(live_metrics_url)のポーリングを実装し、ノード色・バッジの動的更新を有効化します(プロトタイプではポーリングで実装済み)。
  4. Phase 4 — Diff & Alert
    prev_url の前回スナップショットとの差分と、Status.Error 時のアラート表示を実装します(プロトタイプで実装済み。prev_diagram の図差分は未実装)。
  5. Phase 5 — 運用改善
    メトリクス履歴の時系列保存、Goose ワーカースレッドによる並列ステップ計測を検討します。

技術的メリットと留意点

メリット
  • Goose のゼロコピー・データスタックにより、メトリクス収集のメモリオーバーヘッドが極小
  • oh-my-mermaid の Perspective 構造により、パイプラインの「構造」と「状態」を同じ枠組みで管理
  • @step-name リンクで、エラー発生時の原因追跡を直感的に
  • Mermaid テキストベースなので、Git diff でアーキテクチャ変更をコードレビュー可能
留意点
  • Goose に組み込み HTTP サーバーがないため、C FFI または外部サーバー(Python 等)での配信が必要
  • 高頻度更新時は SSE より WebSocket またはポーリング間隔の調整が必要
  • Mermaid の動的 classDef 注入は、大規模ダイアグラムで描画コストが増加する可能性あり
  • oh-my-mermaid 本体へのパッチ方針を事前に検討(fork vs プラグイン)

サンプル Mermaid ダイアグラム

Goose が生成するダイアグラムのイメージです。ステップ名に加え、スループットとレイテンシをラベルに埋め込み、状態に応じた色分けを行います。

graph LR Extract["Extract<br/>1,240 rec<br/>46ms"]:::healthy Transform["Transform<br/>1,180 rec<br/>121ms"]:::warning Load["Load<br/>1,180 rec<br/>31ms"]:::healthy ErrorLog["@error-handler<br/>60 rec<br/>8ms"]:::external Extract --> Transform Transform --> Load Transform -.->|"60"| ErrorLog classDef healthy fill:#8ef0cf,stroke:#0b0b0b,color:#0b0b0b classDef warning fill:#ffc857,stroke:#0b0b0b,color:#0b0b0b classDef external fill:#b8dcff,stroke:#0b0b0b,color:#0b0b0b

まとめ

本提案では、Goose の高性能・低オーバーヘッドなデータ処理能力と、oh-my-mermaid の構造化されたアーキテクチャ可視化フレームワークを接合することで、データ処理パイプラインの「構造」と「健康状態」を一枚のダッシュボードに統合する道筋を示しました。

特に、.omm/ ディレクトリを「実行時メトリクスのキャンバス」として再定義し、Mermaid ダイアグラムを静的ドキュメントからライブステータスボードへと昇華させる点が、本試作の独自性となります。

静的プロトタイプは viewer/ で確認できます。サンプル JSON のポーリングとクライアント側シミュレーションにより、提案した UI の挙動をブラウザ上で試せます。Goose ランタイムへの接続、SSE / WebSocket、prev_diagram の図差分は未実装です。