Domain Operating Model — テンプレートが実行可能なSOPになるしくみ

第13章と第14章では、variantテンプレートを作り昇格させる手順を学んだ。ところが2026年9月から、正規variantテンプレートには新しい基準が適用される。テンプレートは「エージェント・スキル・設定のファイル束」にとどまらず、何をどの順序で進め(ステージ)、誰が責任を負い(RACI)、どの判断を通過しないと次の段階に進めないか(判断ゲート)を、機械が読める形で自ら宣言する。この構造の正式名称はDomain Operating Modelであり、設計の根拠はADR-0083とADR-0084にある。

出典: ai-workspace-standards (GitHub)

ドメインOSとしてのテンプレート

ワークスペースのオーナーはかつてこう提案した。「各variantテンプレートを、そのドメインのオペレーティングシステムとして動かそう。プロセスとスキル、エージェントチーム、責任体系、成果物、判断ルールをテンプレートの中に一か所に集め、それらをつなぐグラフまで備えよう」。2026-09-19の検証パスは興味深い事実を確認した。手順スキーマ(ADR-0063)とスキルグラフ(ADR-0060)のおかげで、提案された構造のかなりの部分がすでに実装済みであり、本当に欠けていた部分はずっと狭かった — ドメインのステージ軸、RACIのC/I(相談・通知)、一般化された成果物・判断モデル、そしてそれらをつなぐグラフ語彙である。ADR-0083はこの欠落を5フェーズ計画(P1–P5)として実行した。

名前は必ずフルネームで

このフレームワークの正式名称はDomain Operating Modelであり、ワークスペースは略称の使用を禁止している。「DOM」と略すとブラウザーのDocument Object Modelと衝突する。co-deck・co-design・co-gameのようにHTMLやCSSを扱うvariantにとって、DOMはすでに生きた用語だ。「AOM」も禁止である。「Agent」という言葉はすでにPMゲートウェイの専門エージェントを指しており、フレームワークを自分の下位構成要素の一つの名前で呼ぶことはできない。ドキュメント・スキーマ・スクリプト・コミットメッセージのどこでも略称は許されない。一つの用語が一つの意味だけを持つというルール(第2章の「用語は資産である」)の好例だ。

4つの中核グループ

Domain Operating Modelの中核(Core)は4つのグループで構成される。各グループはテンプレート内の特定のファイルと結びつく。

たとえるなら組立ライン(assembly line)に近い。Processは工程がどの順序で並ぶかを決めるライン配置図であり、Governanceは各工程の前に付く担当者の名札であり、Executionは各工程が作り出す部品と、次のラインへ進む前に通過しなければならない品質検査台だ。そしてGraphはこのライン全体を見下ろし、「今どこに部品があり、誰が作り、どの検査を通過したか」を一目で答える管制塔である。下の図は、この4つのグループが一つのグラフへどう集約されるかを示している。

階層構造も明確だ。AI Workspaceがスキーマと契約を所有し(L0・L1層)、Domain Operating Modelがその上で各ドメインの運用原理を定義し、Template(templates/co-*/)がちょうど一つのドメインをパッケージし、Project(L3)がそれを実際の業務にインスタンス化する。第7章で見たL0→L1→L2→L3階層とドメイン運用モデルがどう重なり合うかを示すものである。

Process — ステージ軸

最初に埋められた欠落はステージ(stage)軸だ。手順スキーマには元々phaseフィールドがあったが、これはPMが作業を実行する軸(0–6: 設計承認から実行・QAまで)であり、ドメイン業務の流れではない。コンサルティングプロジェクトが「調査 → 分析 → 報告」へ流れること、発表資料が「リサーチ → ストーリーライン → ビルド → 出力」へ流れること — そのドメイン固有の進行段階が宣言される場所がなかったのだ。ADR-0083はこの軸をprocess/stages.yamlに宣言する。

# templates/co-deck/process/stages.yaml (抜粋)
schema_version: '1.0'
variant: co-deck
stages:
  - id: S1
    title: Deck Source Research
    order: 1
    owner_agent: version
  - id: S2
    title: Version Export Control
    order: 2
    owner_agent: version
  - id: S3
    title: Deck Publish and Versioning
    order: 3
    owner_agent: pdf-export

機械が先に作り、人が仕上げる

ステージ軸はbootstrap-stages.tsが、手順間の成果物の受け渡しフロー(どの手順の成果物が次の手順の入力になるか)を分析してクラスタリングする方式で作られた。単にphaseごとにまとめるのではなく、実際に成果物の手が変わる地点を基準にする。ただし機械が作った一次結果は、purposeや開始・終了条件がPENDING_REVIEWのまま残る。構造は自動で、意味は人間が — それがワークスペースの一貫した分業方式だ。

ここには最低限の適格条件もある。DEG-P-01不変式は「ステージがphaseとは異なるものとして区別できること」を要求する。手順数とphase数とステージ数がすべて同じで1:1対応なら、それは新しい軸ではなくphaseの名前を変えただけだ。この検査を通過した9つのvariant(co-abap、co-consult、co-deck、co-design、co-export、co-game、co-hr、co-price、co-security)はgoverned等級を与えられ、通過できなかった4つ(co-develop、co-news、co-safety、co-work)は人がステージを直接執筆するまでcoreにとどまる。強制ではなく等級で成熟度を表す方式だ。

Governance — RACIマトリクス

第2のグループは責任体系だ。governance/raci.yamlは、各ステージの各活動(手順)についてAccountable(最終責任)とResponsible(実行)が誰かを宣言する。RACIはもともとプロジェクト管理の古典的ツールだ — Responsible、Accountable、Consulted、Informedの4役割で「誰が何をするか」を整理する。新しいのは、これが人が読む文書ではなく生成され検証されるデータだという点だ。

# templates/co-deck/governance/raci.yaml (抜粋)
schema_version: '1.0'
variant: co-deck
generated_from: procedures/
rows:
  - stage: S2
    activity: procedure.co-deck.deck-build-and-export
    accountable: version
    responsible:
      - html-build
      - measure
      - pdf-export

マトリクスはgenerate-raci.tsが手順のowner_agentとステージデータから導出する。ワークスペースの原則どおり、根拠のない値を合成しない。ConsultedとInformedは今のところ根拠となるデータがないため、意図的に空のままにしてある。「後に人が埋める空白」を機械が無理に埋めないためであり、この空白は文書化されたギャップだ。作られたマトリクスはvalidate-raci.tsが検証し、宣言された役割キーが実際のエージェントファイルまたは人間役割レジストリとして解決できるか(DEG-R-04)をfail-closedで確認する。

Execution — 成果物モデルと判断ゲート

第3のグループは「何が出て、何を通過しなければならないか」だ。二つの部品がある。一つは成果物(アーティファクト)モデル。procedures/_output-types.yamlは各variantが作れる成果物タイプの閉じたリストで、スキーマが1.1に上がり、各成果物タイプを実際にどの手順が作るか(owner_agent、description)を記録するようになった。もう一つは判断ゲート。decisions/gates.yamlは進行中に判断が必要な地点をgo/no-go形式で宣言する。

# templates/co-deck/decisions/gates.yaml (抜粋)
schema_version: "1.0"
variant: co-deck
gates:
  - id: DG-DECK-01
    title: "Layout gate passes with zero violations before export."
    stage: S2
    decider_agent: version
    inputs:
      - pdf_deck
    outcomes:
      - proceed
      - rework
    record_kind: DEC

参考Bで扱ったDecision Record(DEC-*.md)と混同しやすい。両者の関係はこうだ。ゲートは手順の中の判断地点である(「出力前にレイアウト検査を通過すること」というルール宣言)。判断記録は実際に下された判断の記録である(「2026-09-20 判定: proceed」)。record_kind: DECが二つの世界をつなぐ橋で、ゲートで出た判断は判断記録として残る。

この移行により、9つのgovernedテンプレートの手順から散文的なquality_gatesフィールドが完全に削除された。品質基準が文として散らばる代わりに、名前・判断者・入力・判定結果を持つデータになったのだ。

Graph — Domain Execution Graph

第4のグループは関係層だ。参考Cで学んだスキル関係グラフ(docs/skill-graph.json)は毎回の/syncでソースファイルから再生成される投影(projection)であり、それ自体は一次ストアではない。Domain Execution Graphはこのグラフの上に重ねる語彙プロファイルだ — グラフにgraph_profile: "deg/v1"マーカーが付き、新しいノードとエッジ型が追加される。

• stageノードとin_stage・stage_followsエッジ — どの活動がどのステージに属し、ステージ同士はどの順序か
• step_uses_skill・step_by_agent・produces — 手順のステップがどのスキルを使い、誰が実行し、何を作るか(ADR-0060 Amendment 5で既存)
• accountable_for・consulted_on・informed_of — RACIから導出される責任関係
• decision_gateノードとgated_by・decides_on — どの活動がどのゲートの判定を待つか

要点は、ばらばらだった4グループのデータが一つのグラフの中でつながった実行可能な知識になることだ。「この活動はS2に属し(html-buildが実行し)、スキルXを使い、pdf_deckを作り、DG-DECK-01ゲートを通過しなければならない」が一度のグラフ照会で答えられる。参考Cの原則 — ソースから再生成され、助言的(advisory)である — はそのまま引き継がれる。ADR-0084はここにグラフデルタログを加えた。毎回の/syncで再生成されるグラフの構造変化を記録すれば、運用モデルそのものがどう進化したかを時系列で追跡できる。

拡張 — アクターモデル・エビデンス・バックポート・デルタログ

ADR-0083はアクターモデル、より豊かなエビデンスモデル、SkillHone進化ループといった拡張候補を「名前だけ決めて設計は後日」(named, not designed)のまま残した。続くADR-0084は、このうちアクターモデルを実装し、エビデンス・バックポートとグラフデルタログという二つの経路を新たに加えた。

• アクターモデル — s3で見たactor_typeの導出。人間かエージェントかはレジストリとファイルの存在から解決され、手では記録しない。
• エビデンス・バックポート — 各プロジェクト(L3)に蓄積された実行エビデンスをテンプレート(L2)へ戻す候補を見つける読み取り専用スキャナー(evidence-backport-scan.ts)。project-resyncパイプラインの「選択的バックポートレビュー」にエビデンスという表面が追加された。
• グラフデルタログ — s5のグラフ変化履歴の記録。

残りの拡張 — より豊かなエビデンスモデルとSkillHone進化ループ — は、必要性が実際のデータで確認されるまで設計されないままだ。「先に作らない」という原則は、このハンドブック第10章のロードマップの話と同じ文脈だ。

実践 — 検証と新しいvariant

この構造を直接扱う場面は大きく二つある。第一に、既存のgovernedテンプレートの運用モデルを確認・検証するとき。第二に、第13章で作った新しいvariantが昇格するときだ。昇格パイプラインを通過した正規テンプレートには、ステージ・RACI・ゲートの状態が等級として記録される。検証コマンドをまとめると次のとおり。

# ワークスペースルートで実行
bun scripts/validate-process.ts    # ステージ軸の検証 (DEG-P-01を含む)
bun scripts/validate-raci.ts       # RACIマトリクス + アクターモデルの検証 (DEG-R系)
bun scripts/validate-procedures.ts # 手順スキーマの検証 (ADR-0063、既存)
bun scripts/verify-skill-graph.ts  # グラフ再生成の一貫性 (ADR-0060、既存)

等級体系の意味を表にまとめると次のとおり。「governed」が「core」より優れているのではない。coreは「機械が代わりに作れず、人の執筆を待っている」という正直な状態表示だ。

次の第16章はこのハンドブックの最終実習だ。自分の繰り返し業務を選び、問題定義から検証・振り返りまで自分で設計する。その設計で「順序(stage)、責任(RACI)、判断(gate)」を先に決める感覚 — それがまさにこの章で見たDomain Operating Modelの感覚でもある。テンプレートから学んだことを、自分の設計に応用してみよう。