ADR-0007: プロセスは自作 YAML スキーマで定義しページと図を生成する

ステータス

採用(2026-07-09)

コンテキスト

プロセス表示 UI は、個別ページの手書きではなく共通スキーマで統一する必要がある。既存の DSL / OSS を調査した結果(research/20260709-process-dsl-options.md)、「開発プロセスを人間向けに記述する、現役でメンテされた交換形式」は2026年時点で空白地帯だと判明した。BPMN は知識ベース向けの語彙を持たず、SPEM のツール(EPF Composer)はアーカイブ済み、実行系ワークフロー DSL には人間系の語彙がない。

決定

1. データ層: 自作 YAML スキーマ + Astro Content Collections(Zod 検証)でプロセスを定義する。語彙は SPEM 2.0 を簡約して借用し、Process → Phase → Activity → Task の階層に、横串の Role / WorkProduct / Gate を持たせる(調査フレームワークの6+2要素と同型)
2. 描画層(第一段): データから Mermaid flowchart を生成し、click リンクで下位ページへ遷移するページ遷移型ドリルダウンとする(追加依存ゼロ)
3. データと描画を分離し、表現力不足になった時点で D2 や bpmn-js 等へ描画層のみ差し替え可能にしておく
4. スキーマには最初から schemaVersion を入れ、まず2プロセス(ウォーターフォール+スクラム)で検証してから残りへ展開する

検討した選択肢

• BPMN 2.0 + bpmn-js — ビューア内ドリルダウンは最良だが、ロール定義・適用条件など知識ベースの語彙がなく、提案ツール(M7)への転用で破綻。ウォーターマーク必須も難点
• SPEM 2.0 / EPF Composer — 概念モデルは完全一致だがツールが2018年で停止。語彙のみ借用する
• Serverless Workflow 等の実行系 DSL — 機械実行用で人間系プロセスの語彙がない。JSON Schema 公開という設計パターンのみ輸入する

影響

• 同じデータが将来のプロセス提案ツールの知識ベースにそのまま転用できる(調査した選択肢の中で唯一)
• スキーマ検証がビルドに統合され、プロセスデータの品質ゲートが npm run check に載る
• スキーマ設計の失敗は全ページに波及するため、2プロセスでの検証を必須とする