← MaiML Ecosystem
Version 1.0.0 Draft English

The MaiML Manifesto

— 研究を知識生成プロセスとして設計するための設計原理 —
MaiML Core Team（著者は承認時に確定）
Draft Version 1.0.0（論文体）｜2026-09-04

このMarkdown版は、保存済みのWord版 v1.0.0から生成した派生表現である。内容上の版はWord版と同じ1.0.0であり、本文は変更していない。

この文書の位置付け

本稿は、MaiMLの設計原理（design principles / design rationale）を述べる非規定の独立文書であり、承認前の草案である。MaiMLの仕様及び要求事項は、JIS K 0200及びMaiMLスキーマが規定する。本稿の内容は、規格文書（JIS、ISO working draft及びテクニカルレポート）の本文には含めない。

目次

要旨

計測分析の分野では、データの共有形式の標準化が進む一方で、そのデータがどのように生み出されたか——研究のワークフローそのもの——を機械可読に共有し継承する方法は確立されていない。本稿は、計測分析データフォーマットMaiML（Measurement Analysis Instrument Markup Language）の背後にある設計原理を、10箇条のマニフェストとして提示し、各原理の根拠と、原理がMaiMLの構造にどのように実装されているかを示す。中心命題は「研究の本質はワークフローであり、研究とは知識生成プロセスを設計・実行・改善・継承する営みである」という研究観である。この命題から、構造と意味の分離、設計と実施の分離、抽象化の純度、独立利用可能性、及び最小仕様・疎結合という設計原理が導かれ、ワークフローを人とAIが共有・学習できる知識資産（Knowledge Asset）として扱う道が開かれる。

キーワード：ワークフロー、知識生成プロセス、設計原理、Petri Net、XES、知識資産、Workflow Engineering、MaiML

1　序論：なぜ設計原理を述べるのか

科学は、データを蓄積することで進歩してきたと信じられてきた。計測分析の現場でも、データの保存形式や共有形式の標準化は着実に進んでいる。しかし、装置が更新され、担当者が入れ替わり、専用ソフトウェアが失われたとき、データだけが残っても研究は再現できない。受け継がれるべきは「研究のやり方」——知識を生成するプロセスそのもの——である。

MaiMLは、この問題意識から設計された計測分析データフォーマットであり、その仕様はJIS K 0200として規格化されている。規格文書は「何をどう記載するか」を規定するが、「なぜそのような構造なのか」という設計原理は規格の役割ではない。設計原理が言語化されていなければ、仕様の拡張・実装・運用の局面で判断の軸が失われ、場当たり的な解釈が仕様の一貫性を損なう。

本稿は、MaiMLの設計原理を10箇条のマニフェストとして宣言し（第3章）、その根拠を述べ（第4章）、原理が仕様の構造にどのように実装されているかの対応を示す（第5章）。本稿は規定を含まない。仕様への適合はJIS K 0200及びMaiMLスキーマのみが定める。

2　中心命題：研究の本質はワークフローである

研究の価値は、得られた数値そのものだけにあるのではなく、その数値がどのように生み出されたかにある。データは研究の痕跡であり、本質は、研究がどのように進み、知識がどのように生成されるかというワークフローにある。この見方に立つと、研究者はデータの生産者である以前に、知識生成プロセスの設計者である。

この研究観は、実験研究者の視点（Protocol → Experiment → Data）とソフトウェア工学の視点（Class → Instance）とを橋渡しする。再利用可能な手順（Protocol）を設計し、抽象モデル（Template）を定め、実行によって実体（Data）を得るという構図は、オブジェクト指向におけるクラスとインスタンスの関係に対応する。理学が世界の構造を理解する学問であり、工学が理解した構造を設計に活用する学問であるなら、MaiMLは「理解した研究構造を、設計可能な知識資産へ変える」という両者の接点に立つ。本稿ではこの方法論の一般形をWorkflow Engineeringと呼ぶ。すなわち、研究ワークフローを再利用可能な知識資産として設計・表現・管理・改善する方法論であり、MaiMLはその実装である。

3　The MaiML Manifesto（10箇条）

以下の前文・10箇条・信条が、MaiMLの設計原理の宣言である。

科学は、データを蓄積することで進歩してきたと信じられてきた。しかし研究の真の価値は、得られた数値そのものだけにあるのではなく、その数値がどのように生み出されたか——すなわち知識を生成するプロセスそのものにある。

装置が新しくなり、担当者が入れ替わり、専用ソフトウェアが失われても、受け継がれるべきは「研究のやり方」そのものである。データもまた知識の一部となるが、知識を生み出す根源はワークフローにこそある。

私たちは、研究という知識生成プロセスを、機械可読な知識資産として設計し、共有し、継承するために、MaiML の設計原則をここに定める。

第1条　研究の本質は、ワークフローである。

データは研究の痕跡である。本質は、研究がどのように進み、知識がどのように生成されるかというワークフローにある。

第2条　研究とは、知識生成プロセスを設計・実行・改善・継承する営みである。

私たち研究者はデータを生産するだけではない。そのプロセスを設計するのである。

第3条　ワークフローは、資産である。

再利用可能なワークフローは Knowledge Asset となる。論文が人間のための記述であるなら、MaiML は機械のためのワークフロー記述である。

第4条　構造と意味を、分ける。

Petri Net が構造を、Template が意味を担う。両者を分離することで、ワークフローは数学的にも科学的にも再利用可能となる。

第5条　設計と実施を、分ける。

設計（Petri Net）と実施（XES）を分けて記録する。設計図と実行履歴がそろってはじめて、研究は再現される。

第6条　抽象化の純度を、守る。

ワークフローは再利用可能な概念のみを保持し、具体的な装置・人・日時は分離する。純度こそが再利用性を生み、データの破壊を防ぐ。

第7条　独立利用可能性を、保証する。

研究は、元の特定装置や特定の専用ソフトウェアに強く依存せず、記述それ自体から理解し、再現できなければならない。

第8条　汎化は、継承の方法である。

個別の事象から構造を抽出し、汎化し、次世代へ継承する。構造化は目的ではなく、汎化のための手段である。

第9条　人と AI が、ワークフローを共有し、学習する。

AI は、デジタル化されたデータだけでなく、デジタル化された知識生成プロセスそのものを学習できる。ワークフローは、人と機械が共に学ぶ共通言語となる。

第10条　仕様は最小に、運用とは疎結合としてデザインする。

MaiML は構造・識別・関係のみを定義する。検索・アクセス制御・意味解釈は外部に委ね、エコシステムとして連携する。MaiML はデータの枠と関係を定義し、中身は外部に委ねる。

信条

私たちは信じる——世界には、理解できる構造がある、と。

計測機器も、プログラミングも、MaiML も、構造を見出し、汎化し、継承するための営みであるといえる。

MaiML は、研究という知識生成プロセスを、人と AI が共有・継承できる形へ翻訳する言語として位置付ける。

これが、MaiML 設計原則である。

4　各原理の根拠

4.1　構造と意味の分離（第4条）

研究プロセスは、操作（transition）と状態（place）に分解でき、その順序・分岐・依存はPetri Netという数理で純粋に記述できる。Petri Netは「何を意味するか」を語らない。意味は、Templateが構造上の各ノードに「SEM観察」「測定条件」といった科学的意味として与える。構造（Structure）と意味（Semantics）を分けることで、同じ構造を異なる分野の手順に再利用でき、同じ意味体系を異なる構造に適用できる。ワークフローが数学的にも科学的にも再利用可能になるのは、この分離の帰結である。

4.2　設計と実施の分離（第5条）

Petri Netが表すのは研究の設計（Plan）であり、実施（Execution）ではない。実施は、プロセスマイニングの国際標準であるXESの概念に基づくイベントログとして、開始・完了・中断などの状態遷移と時刻、実施者を記録する。設計図と実行履歴の双方がそろってはじめて、研究は第三者によって再現される。結果（Data）と実行証拠（EventLog）を分けて保持することで、結果の静的構造と実行の動的履歴が混ざらない。

4.3　抽象化の純度（第6条）

ワークフローには「SEMによる観察」という概念は記述するが、特定の機種名・個人名・日時は記述しない。具体情報は識別・来歴の層に分離する。この純度は美学ではなく再利用性の条件である。機種名が混入したワークフローは、その機種が失われた時点で価値を失う。純度を守ることは、将来の対象・装置の変化に対してワークフローを開いておくことである。

4.4　独立利用可能性（第7条）

設計（Protocol）・結果（Data）・実施（EventLog）の三点がそろえば、元の装置や専用ソフトウェアに強く依存せず、記述それ自体から研究を理解し再現できる。これが独立利用可能性（independent availability）であり、設計の到達点である。三点のいずれが欠けても、再現は装置や記憶への依存に退行する。

4.5　最小仕様と疎結合（第10条）

MaiMLが定義するのはデータの枠——構造・識別・関係・汎用コンテナ——であり、データの科学的意味や物理表現それ自体は定義しない。意味は外部の語彙・オントロジーに、個別の生データはTIFF・CSV等の既存形式に委ね、位置（URI）・同一性（hash）・解釈（format）の三点で参照・接続する。検索、アクセス制御、鍵管理及び保存統制は外部システム又は運用が担う。この疎結合の帰結として、MaiMLはワークフローを軸に異種データを束ねるデータカタログとして機能するが、束ねる主体はあくまでワークフローであり、カタログ機能はその副産物である。

5　原理から実装へ：MaiMLの構造との対応

MaiML文書は、識別・完全性・責任を集約するdocument、設計を表すprotocol、実測の結果を表すdata、実行履歴を表すeventLogの4層で構成される。表1に、10箇条の原理が仕様のどの構造に実装されているかを示す。この対応が、設計原理から仕様へのトレーサビリティを与える。

表1　設計原理とMaiMLの構造との対応

原理 設計上の帰結 MaiMLでの実装
第1〜3条（ワークフロー中心・資産化） 設計対象はデータではなく研究ワークフロー protocol層を中核とし、ワークフローを機械可読に記述する
第4条（構造と意味の分離） 数理構造と科学的意味を別要素が担う Petri Net（place・transition・arc）が構造を、Template（materialTemplate・conditionTemplate・resultTemplate・instruction）が意味を担う
第5条（設計と実施の分離） 設計図と実行履歴を別層で記録 protocol（設計）とeventLog（XES概念に基づくlog・trace・event）を分離し、結果はdataに置く
第6条（抽象化の純度） 具体的な装置・人・日時をワークフローから排除 機種・人・組織・日時はdocument層（creator・vendor・owner・date）へ、実行時刻はeventLog層へ分離
第7条（独立利用可能性） 記述それ自体からの理解・再現 protocol・data・eventLogの三点を単一のXML文書に保持できる構成
第8条（汎化による継承） テンプレートと実体の二層化 Template／Instanceの分離と参照（ref属性、templateRef・instanceRef）
第9条（人とAIの共有・学習） 文脈付き・型付きの機械可読データ 型システム（xsi:type）、単位（units）、構造化された実行履歴による学習可能な記述
第10条（最小仕様・疎結合） データの枠のみを定義し中身は外部に委ねる insertion（uri・hash・format）による外部参照、UUIDと chain・parentによる識別・来歴、検索・アクセス制御の外部委譲

注　各実装の規定内容（要素の個数・型・適合条件）はJIS K 0200及びMaiMLスキーマによる。本表は対応関係のみを示す。

6　人とAIによる共有と学習

以上の原理に従う記述は、データサイエンス及びAIと高い親和性をもつ。第一に、結果値だけでなく試料・条件・操作・来歴が構造化されて記録されるため、文脈付き・型付きの機械可読データが得られ、比較可能性・再現性・説明可能性の高い学習データとなる。第二に、構造と意味、設計と実施が分離されているため、AIはデータだけでなく知識生成プロセスそのもの——Workflow Pattern——を学習できる。これは自律計測・自動実験、及びAIによるワークフロー提案の基盤となる。

個別のワークフローから共通構造を抽出し、Workflow Patternとして抽象化し、Workflow Libraryに蓄積することで、研究方法は組織や世代を越えて再利用される。ソフトウェア工学のDesign Patternが設計知を資産化したように、Workflow Patternは研究方法を資産化する。ワークフローは、人と機械が共に学ぶ共通言語となる。

7　位置付けと限界

本稿は設計原理を述べる文書であり、規定文書ではない。原理と仕様が競合する場合は、常に仕様（JIS K 0200及びMaiMLスキーマ）が優先する。また本稿は、検索・認証・認可・鍵管理・保存統制といった運用の設計を扱わない。これらは運用指針及び外部システムの領分である（第10条）。原理の適用範囲は計測分析に限定されない可能性があるが、その一般化——Workflow Engineeringの体系化——は今後の課題である。

8　結論

研究は、データだけでは継承できない。ワークフローを抽象化し、その純度を保ったまま構造化することで、はじめて研究は知識資産として継承される。MaiMLの構造——4層構成、Petri NetとTemplate、XES概念に基づく実行履歴、insertionによる外部参照——は、いずれも本稿の10箇条から導かれた帰結である。私たちは信じる——世界には、理解できる構造がある、と。MaiMLは、その構造を見出し、汎化し、継承するための言語である。

参考文献

[1] JIS K 0200:2024，計測分析データフォーマット（MaiML）．日本規格協会．

[2] Murata, T. (1989). Petri Nets: Properties, Analysis and Applications. Proceedings of the IEEE, 77(4), 541–580.

[3] IEEE Std 1849-2023, IEEE Standard for eXtensible Event Stream (XES) for Achieving Interoperability in Event Logs and Event Streams.

[4] Wilkinson, M. D., et al. (2016). The FAIR Guiding Principles for scientific data management and stewardship. Scientific Data, 3, 160018.

[5] Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley.

[6] W3C, Extensible Markup Language (XML) 1.0 (Fifth Edition), 2008.

生成情報: source MaiML_Manifesto_論文_v1.0.0.docx, SHA-256 020347e36fa64f9caf29bacd3a31aba9101b2d2438882bbdb4e82e95ed0cc3bd.