オントロジー設計理論・T字ER(TM)・三要素分析/X-TEAの比較分析レポートエグゼクティブサマリ本レポートは、①一般的なオントロジー設計理論（RDF/OWLを中心とする知識表現・意味論）、②佐藤正美のTM（Theory of Models：T字ER/T字形ER）、③渡辺幸三の三要素分析（TEA Method）／X-TEA（X-TEA Modeler/Driver）を、理論的基盤・目的・モデリング要素・成果物・適用範囲・導入条件の観点で横断比較する。加えてPalantir TechnologiesのFoundry Ontology（公式ドキュメントに基づく）を参照し、TMのイベント／リソース観との具体的対応を作る。

結論として、オントロジーは「意味（セマンティクス）の共有・再利用・推論」を軸に、複数システム横断の“語彙レベル統合”を実現するのに向く（OWLは形式意味論を持ち、クラス／プロパティ／個体などを提供する）。

**TM（T字ER）**は、文法（生成規則）による無矛盾性と、事実に一致すること（F-真）を明確に区別し、関係の網羅性・制約束縛の網羅性を検証して「事業構造に一対一対応するデータモデル」を導くのに強い。

三要素分析／X-TEAは、「データモデル・業務モデル・機能モデル（UI含む）」の相互牽制で整合を取り、さらに仕様（spec）を資産としてDriverが解釈実行する“仕様駆動”により、上流〜実装〜保守のサイクルを短く回す設計思想が特徴である。

特にPalantirのOntologyは「データ資産（datasets/virtual tables/models）の上に、現実世界の資産・注文・取引等へ対応づける“運用層”を載せる」ことを公式に謳い、Object Type／Link Type／Action Typeといった“運用可能なセマンティック層”として整理されている。

この構造はTMの「resource（主体）—event（出来事/取引）—関係の文法」という見方と強く共鳴する一方、Palantirは操作（Action）を単一トランザクションとして第一級に扱う点、Primary Key設計が編集保持・リンク維持の運用事故に直結する点、スキーマ移行を製品機能（フレームワーク）として内蔵する点が、方法論としてのTMとは性格が異なる（＝プラットフォーム設計の差）。

対象と分析フレーム本レポートの対象は次の三者である。未指定の「このオントロジーの話」は、固有名がないため一般的なオントロジー工学として扱い、後で特定オントロジー（例：上位オントロジーや業界標準語彙）へ差し替え可能な形で論じる。

オントロジー側は、Tom Gruberの「概念化の明示的仕様」という定義や、W3C仕様（RDF/RDFS/OWL）に基づく（RDFはトリプルの集合としてグラフを定義し、IRIを識別子として扱う）。

TM側は、T字形ER図（TMD）を核に、L-真（論理的に無矛盾）とF-真（事実に一致）を分け、関係・制約の網羅性を保証するという説明（住友電工情報システムの公開対談、ならびにTM解説スライド）を一次根拠として扱う。

三要素分析／X-TEA側は、三要素（データモデル／機能モデル／業務モデル）という定義（イベント告知ページ等での説明）と、渡辺自身の「データ・ファースト」論（情報システム学会MM寄稿PDF）およびX-TEA関連のGitHub（Modeler/Editor/Driver）記述を主要根拠とする。

Palantirについては、Foundry公式ドキュメントのみを引用対象とし、Ontologyが「運用層」「デジタルツイン」「Actionによる変更」「OSv2のスキーマ移行フレームワーク」等として規定されている事実を根拠に、TMとの概念対応・差異を技術的に検討する。

なお、調査過程で一部の日本語ページ（X-TEA HOMEのトップ等）で文字コード起因の取得エラー、また一部ベンダーサイトでゲートウェイエラーが発生したため、代替としてPDF・GitHub・イベント記録・出版社サイト等の一次/準一次資料を優先している（該当箇所は参考文献欄で明示）。

理論的基盤とモデリング要素オントロジー（RDF/OWL）・TM・三要素分析/X-TEAは、いずれも「現実世界（業務）をモデルとして表現し、再利用可能な成果物に落とす」点で共通するが、**“何を厳密化するか”と“厳密化の数学的根拠”**が異なる。

オントロジー（RDF/OWL）の理論基盤は、(a)RDFのグラフデータモデル（トリプル：subject/predicate/object）とIRIによる識別、(b)RDFSによるデータモデリング語彙（クラス、プロパティ、subClassOf、domain/range等）、(c)OWLの形式意味論（モデル理論）と推論である。RDFは「トリプルの集合＝RDFグラフ」を定義し、IRIをグラフデータモデル上のグローバル識別子として扱う。

RDFSはrdfs:subClassOfが推移的であり「あるクラスのインスタンスが別のクラスのインスタンスでもある」ことを述べる、と仕様で明確化される。

OWL 2は「形式的に定義された意味を持つオントロジー言語」であり、クラス・プロパティ・個体・データ値などを提供し、RDF文書として交換されることが一次仕様に記されている。

TM（T字ER）の理論基盤は「生成規則（構文論）で健全性・無矛盾性を保証し、指示規則（意味論）で完全性を保証する」という二層構造として説明される。TM解説スライドでは、生成規則が“健全性・無矛盾性”に、指示規則が“完全性”に対応し、手順1〜5は一般手続きがあると整理される。

住友電工情報システムの公開対談では、データベース設計がL-真レベル、データモデリング（TM）がL-真に加えてF-真まで実施し、関係と制約束縛の網羅性を保証する、と説明される。

モデリング要素としてはentity（箱）をevent（事態）とresource（主題）に分け、R-E/E-E/R-Rや対応表、再帰等の「関係の文法」を用いることが明確に述べられる。

三要素分析／X-TEAの理論基盤は、企業システムを「データモデル・機能モデル・業務モデル」の組み合わせとして認識・定義するという“相互牽制”の考え方にある（イベント告知ページ）。

さらに渡辺の「データ・ファースト」論では、先に確立したデータモデルがある場合、そこから導かれるプロセスモデルは“収束”し、逆にプロセス先行だとデータモデルが“発散”すると説明され、データモデルを最初に確立すること自体が品質保証フレームとして位置づけられる。

X-TEAのツール群は、Modelerが「データモデル・プロセスモデル・UIモデルを設計する」ツールであるとGitHub上で明示され、Driverは仕様書を解釈して“コード生成やコンパイル無しに起動する”と説明されている。

技術的比較以下では、ユーザ要求の重点項目（識別子設計、イベント表現、階層化、推論/整合性検査、マスタ管理、スキーマ進化、運用コスト）について、三者を横断比較し、PalantirとTMの対応も含めて評価する。

識別子設計オントロジーでは、IRIが「グラフデータモデルにおけるグローバルに一意な識別子」として位置づけられ、Linked Dataの文脈では参照可能性（dereference）も重要な性質とされる。RDF 1.1概念仕様は、IRIを識別子として扱い、語彙（namespace IRI）としても用いること、またIRI同士の等価性比較規則などを規定する。

このID戦略は、RDBの主キー設計よりも“外部連携・再利用”に寄り、同一実体の同定はowl:sameAs等の語彙や運用ポリシーに依存しやすい（閉世界の参照整合とは別設計になる）。

TMの識別子設計は対照的で、個体指定子（NO/コード）を「ユーザ言語として合意された認知単位」として扱い、一意性のための恣意的キー生成を避けると明言する。TMスライドでは「ユニークにするためのキーを作るのではない」「複合キーは関係によってのみ現れる」「箱を複合キーで認識すると論理が隠れる」と明示される。

これは、識別子を“実装都合の人工物”として増やすことで、関係（=事業の論理）が属性やキーに埋没し、将来的な変更が困難になる（あるいは性能面でも逆効果になる）という設計哲学に直結する。

三要素分析／渡辺流は、TMほど「キー生成禁止」を強く言語化していないが、ブログ等で繰り返し“単独主キー主義（全テーブルid）”への批判と、業務知識に応じた複合主キーの必要性を論じている。階層構造（自己参照型・部品表型）の説明では、部品表が正規化されていないと矛盾を招く可能性があること、複合主キーが必要になること、階層構造は「すべてid主義」では理解できないと述べられる。

さらにマスタ系テーブルの主キーに適用開始日や履歴番号を機械的に含める設計は、テーブル関連が見えなくなり保守性が著しく低下するとし、時限属性を別テーブルに切り出す処方箋を提示する。

Palantir FoundryのOntologyでは、Object TypeにPrimary Keyプロパティ指定が必須で、重複があるとOSv2ではFunnelパイプラインエラーにつながる、識別子は決定的であるべきで行番号やランダム生成を避けよ、編集が失われたりリンクが消える可能性がある、と日本語ドキュメントで具体的な運用事故と結び付けて説明される。

つまりPalantirのID戦略は「プラットフォームが編集・リンク・移行を担保するための実務要件」と強く結びついており、TM/渡辺流が“事業語彙としてのコード”に寄せるのとは別の強制力が働く。

イベント表現オントロジー（RDF/OWL）側は、RDFグラフ自体が“atemporal（非時間的）で静的スナップショット”である一方、適切な語彙を用いればイベントや時間的側面を表現できる、とRDF概念仕様が明示する。

ただし、イベントはしばしば多項関係（誰が・何を・いつ・どこで等）になり、RDFではn-ary関係を間接的に表現する必要がある（＝Event個体を立て、roleプロパティで関与者を束ねる設計になりやすい）。

TMでは、eventが「行為や出来事（取引）」であり、resourceがそれに関与するというR-E関係がビジネス表現の基本になる、とスライドで明確に述べられる。さらにE-E（後続関係・対応関係）、R-R（対照表：制約束縛/意味論）などが体系化され、関係を“線”として中心に据える。

住友電工情報システムの対談でも、在庫の例で「最終実装形が同じでも事業が違う」ことをモデルが読み取れるべきで、F-真は一つであると説明され、イベント・取引の捉え方が“事業の事実”そのものに接続している。

三要素分析では、イベントはDFD等で業務発生トリガーとして扱われ、業務モデル（アクションツリー等）で手順・操作として表され、データモデル上の取引・履歴と突き合わせて整合を取る、という設計観が紹介されている（外部資料だが三要素分析の図法・要素を解説）。

X-TEA Driverが仕様書を解釈して起動するという設計は、イベント/操作を“仕様として固定化”しやすく、手順変更＝仕様変更として運用に乗せやすい。

Palantir Foundryでは、Actionが「ユーザ定義ロジックに基づいて1つ以上のオブジェクトのプロパティを変更する単一のトランザクション」であり、行為（操作）を第一級に扱うことが強調される。

ここでTMとの類似点は「取引/操作を中心に、資源（resource/object）と関係（link）を変化させる」という構造で、相違点は「Actionを“業務操作API/UX”として前面に置き、事実（event）を必ずしも“データとして保持する”とは限らない」点である（事実保持はActionログや取引オブジェクト化など別設計が必要）。

階層化オントロジーでは、クラス階層が第一級であり、RDFS仕様はrdfs:subClassOfが推移的で「あるクラスのインスタンスは上位クラスのインスタンスでもある」ことを明確に述べる。

この推移性は推論と相性が良く、階層の整合性チェック（例：矛盾する分類）にも寄与するが、階層設計自体（どこを上位概念とするか）はガバナンス課題になる。

TMでは、再帰（自己参照）や「並び」をビジネス上の意味として扱い、再帰表で前後関係を表すが、RDB実装時には名前変更などの調整が必要になる、とスライドで指摘される。

さらに、event/resource分類や関係の性質（全順序/半順序）など、階層・順序を“事業の性質”として捉え直す枠組みが用意されている。

渡辺流（TEA/X-TEA）では、自己参照型（組織階層）と部品表型（BOM）を区別し、正規化なしの集約部品表は矛盾可能性があること、複合主キーと関数従属性の理解が重要であること、さらにレベル管理（LLC等）を含む実務アルゴリズムが必要になることが論じられる。

この「階層をデータ構造で表し、計算可能性（集計/展開）まで含めて設計する」態度は、オントロジーの分類階層（意味論 중심）とはゴールが異なる。

推論/整合性検査オントロジーは、形式意味論と推論が中心機能である。OWL 2は「形式的に定義された意味を持つ」こと、Direct Semantics（モデル理論）やRDF-Based Semanticsを持つことを仕様が述べ、プロファイル（例：OWL 2 RL）では、条件付きで推論が健全（sound）・完全（complete）になり得ることまで言及する。

また、RDFSはdomain/rangeやsubClassOf等で型制約を表現できる一方、ローカルな制約表現にはOWLのような“より豊かな言語”が必要だとRDFS仕様自身が指摘している。

TMは、推論というより「モデル品質（無矛盾性・完全性）を作る手続きと検証」が中心である。TMスライドは生成規則（文法）による無矛盾性保証と、指示規則（意味論）による完全性保証を対比し、網羅性確認・制約束縛確認を“早い段階で評価すべき”と整理する。

また住友電工情報システムの対談では、L-真とF-真を区別し、L-真（文法違反なし）は複数あり得るが、F-真（事実に一致）は一つであるという位置づけを明確にする。

この意味でTMの整合性検査は「複数のL-真候補から事実に一致する1つを選び取る＝業務の実体を確定させる」活動として設計レビューに組み込まれる。

三要素分析／X-TEAは、推論エンジンよりも「三種のモデル間整合（相互牽制）のプロセス」と「データモデル先行による発散抑制」が品質保証の軸になる。データ・ファースト寄稿では、データモデルに基づくプロセスモデルが収束しやすいことを説明し、逆にプロセス先行は発散しやすいと述べる。

ツール面では、Xead Modelerがデータ・プロセス・UIの設計を同一スコープで扱うと明示され、整合性確認やレビュー素材の一元化に寄与し得る。

マスタ管理オントロジーにおける“マスタ”は、(a)クラス階層としての分類体系、(b)個体としてのコード体系（例：国コードや製品分類）として表現されることが多い。RDFは「IRIやリテラルが資源を指示し、トリプルは資源間の関係を主張する」と定義しており、マスタ値も資源として扱える。

一方で、RDBの参照整合（FK制約）のような“閉世界での強制”はRDF/OWLの標準的な意味論には含まれず、実運用では別途バリデーション（例：SHACL）やガバナンスが必要になる（＝設計前提が違う）。

TMではresourceがマスタ的主体（顧客・社員・商品等）に対応しやすいが、TMが強く主張するのは「主体を更新するのではなく、主体間の関係（配属・販売禁止など）を対照表として表し、関係の変化を捉えよ」という点である。対照表は制約束縛を表すだけでなく、関係を表さなかった場合の悪弊（例：配属先をキーに組み込む、Null状態で定義不能になる等）を具体例で説明している。

この“関係の独立性”は、後述する渡辺の「時限属性」論（マスタ主キーに適用開始日を入れると関係が見えなくなる）と技術的に共鳴する。

三要素分析／渡辺流では、「商品台帳（商品マスター）を整備しないと誤集計が起きる」といった形で、マスタが“業務の合理性”に直結することを出版社転載記事で説明している。

さらに、更新履歴・更新予約のためにマスタ主キーへ適用開始日/履歴番号を機械的に含める設計は、テーブル間の豊かな関係が見えなくなり、可読性・保守性が著しく低下すると指摘し、時限属性を別テーブル化して関係を見える化する設計を推奨する。

PalantirのOntologyも、Primary Keyが編集・リンク・移行に直結する（決定的でないと編集が失われたりリンクが消えうる）と説明しており、“マスタ（=主体）をどう同定するか”が運用のボトルネックになる点はTM/渡辺流と同じである。

ただしPalantirは、そのボトルネックを「製品機能（移行フレームワーク、編集適用方式）」で緩和する方向に寄せている点が特徴である。

スキーマ進化オントロジー工学では“進化（evolution）”が方法論の中心課題として扱われる。METHONTOLOGYは要求定義から保守までのライフサイクルを示しつつ、evolving prototypes（進化するプロトタイプ）が適切なライフサイクルであると論じ、定義の追加・削除・修正が必要になることを前提にする。

NeOnはさらに、再利用・再工学・マージ、協調作業、分散環境での動的進化を支えるシナリオベース方法論として紹介されている。

TMは製品内蔵の移行機構を持たないが、(a)恣意的キー生成を避ける、(b)関係を属性に埋め込まず対照表として独立させる、といった設計規律がスキーマ進化の足かせを減らす方向に働く。TMスライドは「一意性のために作ると変更困難になる」「複合キーで論理が隠れる」と述べ、関係を表さないことの悪弊を具体例で示す。

住友電工情報システム対談でも、実装ポリシーに合わせた微調整は許されるがL-真（文法）を保証せよ、と述べ、実装変化とモデル本体を切り分ける姿勢が示される。

三要素分析／X-TEAでは、仕様駆動（Driverが仕様書を解釈）により、変更を“コード変更ではなく仕様変更”として扱いやすい。GitHub上でDriverは「仕様書を解釈し、コード生成やコンパイル無しに起動する」と明示され、Editorは仕様書を書く専用エディタとして説明される。

この設計は、仕様資産を中心にスキーマ進化（項目追加、画面追加、業務手順変更等）を回す構造になりやすい。

Palantirはスキーマ進化を“製品機能”として前面に出す。OSv2は「スキーマ移行フレームワーク」を提供し、重大なスキーマ変更後に既存ユーザー編集へ適用できる事前定義移行を列挙し、Ontology Managerが重大変更を自動検出して移行選択へ誘導すると日本語ドキュメントが述べる。

またOSv1→OSv2移行は全Object Typeで必須で、Ontology Managerが統合移行フレームワークを提供すると説明される。

運用コスト運用コストは「技術コスト」よりも「組織コスト（合意・ガバナンス・育成）」が支配的になりやすい。オントロジーは語彙合意（命名規約・URI方針）と再利用設計が不可欠で、方法論（METHONTOLOGY/NeOn）も要求定義や協調・再利用の重要性を強調する。

TMは、L-真/F-真と網羅性検証を実施するため、チーム共通の文法理解とレビュー文化が不可欠であり、住友電工情報システムの公開対談・講習会告知は、研修やセミナーを通じた組織導入が前提になることを示唆する。

渡辺流も、データモデリングに必要な専門知識が「文法知識・業務知識・事例知識の3つ」であり、それが参入障壁になるとブログで述べる。

Palantirは、状態（Status）の整合性やスキーマ移行をOntology Managerが担保するなど“製品側ガバナンス”を備える一方、Primary Key設計などプラットフォーム特有の運用要件が強く、学習・運用コストは別途発生する。

比較表三者比較表観点オントロジー設計理論（RDF/OWL） TM（Theory of Models／T字ER）三要素分析（TEA）／X-TEA 理論的基盤 RDFグラフ＋RDFS語彙＋OWL形式意味論／推論生成規則（構文論）で無矛盾、指示規則（意味論）で完全性三要素の相互牽制＋データ・ファースト（収束/発散）目的語彙と意味の共有、再利用、推論、横断統合事業の事実に一致するデータモデル（F-真）を導き、網羅性を保証データモデル起点で業務/機能(UI)を整合、仕様資産で開発・保守を加速主要モデリング要素クラス/個体/プロパティ、subClassOf、domain/range、トリプル event/resource、R-E/E-E/R-R、対照表、再帰、個体指定子データモデル/機能モデル(UI)/業務モデル、DFD、（仕様書）手順・手法要件定義→概念化→形式化→実装→保守（方法論、CQ等）手順1〜5（一般手続き）＋意味論的整理、網羅性/制約検証データモデル確立→プロトタイプ/仕様駆動→フィードバックで反復成果物 OWL/RDF/JSON-LD、SPARQL、知識グラフ、推論結果 TMD、対照表、RDBスキーマ、検証結果三要素一式（仕様書）、Driverでの動的実行適用範囲複数領域・複数組織の意味統合／標準語彙／知識共有基幹/業務系DB設計、事業事実の厳密化企業システム（業務系）に特化、設計資産化と高速開発利点再利用・推論・外部語彙連携、形式意味論文法に基づく品質、関係の網羅性、変更耐性（設計規律）データ↔業務↔機能の整合、仕様駆動で手戻り低減欠点合意形成・ガバナンス負荷、検証設計（制約）も別途必要学習・レビューコスト、文化定着が必要ツール/流儀依存、用途（企業システム）外では過剰になり得るスキル要件 RDF/OWL、語彙設計、推論/クエリ（SPARQL）文法（関係の文法）、L-真/F-真、制約束縛、レビュー文法知識＋業務知識＋事例知識、仕様駆動運用代表ツール Protégé、SPARQL、JSON-LD等 MODEBI、TMD-Maker X-TEA Modeler/Editor/Driver（GitHub）

Palantir概念とTM（イベント/リソース）対応表 Palantir概念 Palantir側の定義（要旨） TM側の対応（近い概念）類似点相違点・注意 Ontology（Foundry）データ資産の上にある“運用層/デジタルツイン”。datasets/modelsをObject/Property/Link/Actionへ写像事業語彙と関係文法で事実を写像し、F-真を狙う「現実世界の概念をモデル化し、再利用/運用する」 Palantirはプラットフォーム実装（操作・権限・移行）まで含む Object Type / Object 型とインスタンス、Object setの概念 entity（箱）と個体指定子、クラス整理「型と実体」「集合（セット）」 TMは“認知語彙”から箱を立てる。Palantirはデータ資産マッピングが前提 Link Type / Link 型どうしの関係、関係インスタンス関係の文法（線）、対照表、対応表関係を第一級に扱う TMはR-E/E-E/R-R等を文法化。PalantirはUI/アプリ操作に統合 Action Type / Action 変更の集合。Actionはユーザ定義ロジックに基づく単一トランザクション event（事態）／業務手順取引/操作を中心に置く TMのeventは「事実（出来事/取引）」の表現に重点。PalantirのActionは“実行操作”で、事実保持は設計次第 Primary Key インスタンス一意識別。重複/非決定的は編集消失やリンク消失の原因個体指定子（NO/コード）を前提。キー生成を戒める同定が運用品質の要 PalantirはPKが必須で編集/移行機構と直結。TMは“合意語彙”起点でキー生成を避ける Schema migration framework OSv2でスキーマ移行フレームワーク。重大変更を自動検出し移行選択へ誘導設計規律で変更耐性を作る（関係の独立、キー方針）進化を前提 TMは製品内蔵移行ではなく、設計規律とレビューで対応

代表的適用事例オントロジー設計理論 Palantir Foundry Ontologyは、「データ資産の上に位置する運用層」であり、物理資産から注文・金融取引までを現実世界の対応物として結びつけると公式に述べる。Ontologyは“デジタルツイン”として、Object Type/Property/Link Type/Action Typeへデータセットやモデルを写像し、分析だけでなく操作可能なアプリの基盤として位置づけられる。

この事例は、オントロジーが「知識表現」だけでなく「運用（Action）＋ガバナンス（Status/移行）」へ進化していることを示す。

Gene Ontology ConsortiumのGene Ontologyは、生命科学領域の知識を標準化された語彙と関係で表現し、注釈（annotation）や計算解析の土台として利用される、と公式ドキュメントで説明されている。

この事例は、コミュニティ合意で語彙を維持し、再利用可能なオントロジーを中心に研究/実務の相互運用性を高める典型である。

TM（T字ER）住友電工情報システムの基幹系再構築事例では、DOAの設計手順の一部としてT字形ER図法を採用し、習得に時間は要したが採用自体に迷いはなかった、という記述がある。

また同社はTM（T字形ER手法）考案者の講習/対談コンテンツを公開し、2005年からTMセミナーを主催してきたと述べ、組織導入が「研修・知識移転」と結び付くことを示している。

別の事例として、ワークフロー製品の開発事例ページでは成果物の一例としてFit/Gapと要件表、T字型ER図、ワークフロー経路設計書などが列挙されている。

この事例は、T字ERが「上流成果物としての関係・データの可視化」を担い、要件調整や後続設計とセットで運用され得ることを示唆する。

三要素分析/X-TEA 「新型コロナウイルスワクチン接種管理システム」を題材にしたイベント記録では、X-TEAによるデータモデルが提示され、自治体・住民・接種申請・接種日程・ワクチン等の要素を含むと説明されている。

この事例は、三要素分析というより「データモデルの公開・共有」を核にしつつ、ローコード/仕様駆動の実装まで視野に入れるコミュニティ実践の形になっている。

また、TALONの生産管理パッケージ紹介ページでは「当システムの仕様はすべて渡辺幸三氏による」「X-TEAにレファレンスモデルとして公開しているCONCEPTWARE／受注生産を忠実に再現」と明示され、モデル事例を複数ツールで実装して仮説検証した経緯が述べられる。

これは、渡辺流が“モデル事例（レファレンスモデル）”と“実装可能性（ローコード/自動実行）”の両方に重心を置くことを示す。

実践ガイド導入時の選択基準オントロジーを選ぶべき条件は、「複数システム/部門を跨いで意味を統合し、再利用・推論を活用したい」場合である。IRI設計と語彙ガバナンス、推論/検証の設計に投資可能であることが前提になる。

TMを選ぶべき条件は、「基幹/業務系で事業要件（事実）に一致するDB構造を確立し、関係と制約束縛の網羅性を品質保証として回したい」場合である。L-真/F-真の理解と、文法に沿ったレビュー文化（研修含む）が不可欠になる。

三要素分析/X-TEAを選ぶべき条件は、「データモデルを起点にUI/機能/業務手順まで一体で整合させ、仕様を資産化して実装・保守を高速化したい」場合である。データ・ファースト（収束/発散の考え方）を採ることで、要件の曖昧さをプロトタイプで早期に潰す設計が取りやすい。

導入前チェックリスト目的は「意味統合（語彙と推論）」か「DB構造の厳密化」か「仕様駆動での一体開発」かを明文化している。既存データ資産の品質（キー重複、コード体系、履歴管理方針）を把握している。特にPalantirの場合、Primary Keyの重複・非決定性は編集消失やリンク消失に直結する。用語（業務語彙）合意を回す会（定例）と、成果物レビューの責任分界（誰が語彙/関係/制約を承認するか）を設計している。スキル育成計画がある（文法知識・業務知識・事例知識）。技術ポイント別の推奨識別子設計は、三者いずれにおいても“最重要の破壊点”になる。TMの個体指定子（合意語彙）方針と、PalantirのPrimary Key決定性要件、渡辺の「主キーに適用開始日を入れると関係が見えなくなる」という警告は、異なる言語で同じリスク（IDが論理を壊す/運用事故になる）を指しているため、IDを最初に設計レビュー対象にするのが合理的である。

イベント表現は、オントロジーではn-ary関係設計や語彙選定が課題になりやすく、TMではR-E/E-E等の文法化が強力なガイドになる。業務イベントを“操作（Action）”として扱うか、“事実（取引オブジェクト）”として保持するかを、要件（監査・トレーサビリティ）に基づき明示的に選ぶべきである。

階層は、オントロジーは分類階層（意味論）に強く、渡辺流は構成階層（計算・集計）に強い。どの階層が必要か（分類か、展開/集計か）を先に決めると、手法選択がぶれにくい。

スキーマ進化は、Palantirのように移行フレームワークを製品が担う場合でも、変更を小さくするモデリング規律（関係の独立、時限属性の分離、非決定的キー排除）が最終的な運用コストを左右するため、方法論（TM/三要素）とプラットフォーム機能を“二重化”させる方針が推奨される。

Mermaid図 TMの典型（Resource-Event）をERで表す（例：受注） places

contains

is_ordered_as

CUSTOMER

string

customer_code

string

name

ORDER

string

order_no

date

order_date

ORDER_LINE

string

order_no

int

line_no

string

product_code

int

qty

PRODUCT

string

product_code

string

name

コードを表示する三要素分析（データ・機能・業務）の整合ループ（概念） CRUD/操作整合

業務手順整合

業務要件の検証

フィードバック

データモデル（ER）

機能モデル（画面/機能展開）

業務モデル（手順/アクションツリー）

プロトタイプ/仕様駆動実行（X-TEA Driver等）

コードを表示する主要参考文献公式仕様・一次資料 World Wide Web Consortium（W3C）の仕様として、OWL 2概要（形式意味論、クラス/プロパティ/個体、RDF交換）およびRDF/RDFS（トリプル、IRI、subClassOf等）を主要根拠とした。

JSON-LD 1.1（JSONベースのLinked Data直列化）も、運用上の表記法として参照した。

オントロジー方法論として、METHONTOLOGY（要求定義〜保守、進化するプロトタイプ）とNeOn（再利用・協調・動的進化）を参照した。

定義・入門としてGruberの定義PDFとNoy/McGuinnessのOntology Development 101を参照した。

ツールとしてProtégéの公式ページを参照した。

Palantir（Foundry Ontology公式ドキュメント） Ontologyが運用層であり、デジタル資産をオブジェクト等に写像すること、Actionが単一トランザクションであること、Primary Keyの決定性要件、Status整合、OSv2移行・スキーマ移行フレームワーク等は公式ドキュメントを根拠にした。

TM（T字ER） L-真/F-真、網羅性、event/resource観、関係の文法、個体指定子（NO/コード）方針は、住友電工情報システム公開対談とソフトウェアシンポジウム2009スライド等を根拠にした。

ツール（MODEBI、TMD-Maker）と書籍情報（技術評論社）も参照した。

三要素分析/X-TEA（渡辺）「データ・ファースト」論、専門知識（文法知識・業務知識・事例知識）、時限属性（マスタ主キー問題）、階層構造（自己参照/部品表）は、ISSJ寄稿PDFとブログおよび出版社転載記事を根拠にした。

X-TEA（XEAD）ツールの説明はGitHub（Modeler/Editor/Driver）を根拠にした。

三要素分析の要旨（データ/機能/業務の組み合わせとして認識・定義）についてはイベント告知ページ等の外部資料も併用した。

Download the Markdown file

markdown コピーする

オントロジー設計理論・T字ER(TM)・三要素分析/X-TEAの比較分析レポート（2026-02-18）

エグゼクティブサマリ

本レポートは、(1)一般的なオントロジー設計理論（RDF/OWLを中心とする知識表現・意味論）、(2) 佐藤正美のTM（Theory of Models：T字ER/T字形ER）、(3) 渡辺幸三『システム開発・刷新のためのデータモデル大全』で中核となる三要素分析（TEA Method）およびX-TEA（X-TEA Modeler / Driver）を、同一の評価軸で比較する。
結論として、オントロジーは「意味（セマンティクス）を共有し、推論や再利用を前提に知識を流通させる」ことに強みがあり、TMは「事業の事実（F-真）と無矛盾性（L-真）を厳密な文法で詰め、変化に強いDB構造を導く」ことに強みがある。三要素分析/X-TEAは「データモデルを起点に、機能・業務（UIや手順）まで整合させ、仕様（spec）駆動で実装・保守を加速する」ことに強い。
また、Palantir FoundryのOntologyは「データ資産の上に“運用可能なセマンティック層”を載せる」実装アーキテクチャとして、TMの“イベント/リソース観”と多くの共通点（取引＝出来事、資源＝主体/参照対象、関係の重視）を持つ一方、Action（操作）を“単一トランザクション”として前面に出す点や、スキーマ移行を製品機能として組み込む点は、方法論（TM）よりもプラットフォーム（Foundry）の設計思想を強く反映している。

対象の定義と前提

「このオントロジーの話」は固有名が未指定のため、一般的なオントロジー工学（RDF/OWL、代表的手法論としてMETHONTOLOGY/NeOn等）として扱う。後で特定の理論（例：BFO、DOLCE、UFO、OBO等）に差し替え可能。
「T字ER」は、佐藤正美が提唱したTM（Theory of Models）におけるT字形ER図（TMD）を主対象とする。
渡辺幸三の手法は、(a)三要素分析（データモデル/機能モデル/業務モデルを相互牽制で整合）と、(b)その実装支援としてのX-TEA（X-TEA Modeler / Driver / Editor）を中心に扱う。

※調査中、いくつかの一次情報（日本語のX-TEA HOMEや一部の古い記事ページ、SDIサイト等）にアクセス障害（文字コード/ゲートウェイエラー）が発生したため、代替として公式仕様・PDF・GitHub・イベント記録等を優先して参照した。

理論的基盤とモデリング要素

オントロジー設計理論（RDF/OWL中心）

理論基盤：RDFのグラフデータモデル（主語・述語・目的語のトリプル）と、RDFS/OWLによる語彙（クラス/プロパティ/個体）定義、さらにOWLの形式意味論（モデル理論）と推論。
モデリング要素：
- クラス（概念の集合）、個体（インスタンス）、プロパティ（関係/属性）
- クラス階層（subClassOf）やドメイン/レンジ、制約（OWLObjectPropertyの特性、クラス制約等）
成果物：OWL/RDF（Turtle/RDF/XML/JSON-LD等）としてのオントロジー、語彙定義、推論可能な知識グラフ、（要件として）Competency Questionsなど。
代表ツール：Protégé（デスクトップ/Web）、SPARQLエンドポイント、推論機（HermiT等）、検証（SHACL等）。

TM（Theory of Models／T字ER）

理論基盤：文法（生成規則）による無矛盾性の保証と、意味論（指示規則）による完全性（現実的事態＝事業の事実）への一致を狙う。
モデリング要素：
- entity（箱）を event（事態） と resource（主題） に分類
- 関係の文法（R-E, E-E, R-R、再帰、対応表など）
- 個体指定子（NO/コード）を「ユーザ合意語」として扱い、ユニーク化のための恣意的キー生成を戒める
成果物：T字形ER図（TMD）、対照表（関係・制約束縛の表現）、網羅性/制約の検証結果、最終的にはRDBスキーマ（論理〜物理）。
代表ツール：MODEBI、TMD-Maker 等。

三要素分析（TEA Method）／X-TEA

理論基盤：企業システムに特化し、業務システムの姿を「データモデル」「機能モデル」「業務モデル」の相互牽制（整合）で定義する。さらに渡辺の“データ・ファースト”思想では、先に確立したデータモデルがプロセス/UIの設計を収束させる（＝発散を抑える）と説明される。
モデリング要素：
- データモデル（ER的）
- 機能モデル（画面・機能展開、UIモデル）
- 業務モデル（手順・業務マニュアル、アクションツリー等）
- （上位図として）データフロー図（DFD）
成果物：三要素一式の設計情報（「仕様書」）、およびX-TEA Driverが解釈可能な仕様。
代表ツール：X-TEA Modeler（= XEAD Modeler）、X-TEA Driver、X-TEA Editor（= XEAD Editor）。

技術的比較（横断ポイント）

識別子設計（ID戦略）

オントロジー：IRI/URIを基本単位として「世界で一意」な識別を行い、必要なら外部語彙の再利用も行う。RDFではIRIはグラフデータモデルにおける識別子であり、語彙（namespace）としても用いられる。
TM：個体指定子は「現場で認知されたNO/コード」を前提とし、ユニーク化のための人工キーを作らない。複合キーは主として「関係が生むもの」と位置付け、箱（entity）を複合キーで認識すると論理が隠れるとする。
三要素分析/X-TEA（渡辺）：現実の業務知識（例：品目、組織、部品表）に即した正規化と複合主キーの合理的利用を重視する。マスターの主キーに有効期間を機械的に組み込むと、テーブル関係が見えにくくなり保守性が落ちるため、時限属性を別テーブル化する等の整理が推奨される。
Palantir Foundry Ontology（参考）：Object Typeには一意識別のためのPrimary Keyプロパティが必須で、重複や非決定的キー（行番号、乱数等）を避けよと明示される。ユーザー編集とリンクがPrimary Keyに紐づくため、キー設計は運用事故（編集消失等）に直結する。

イベント表現（イベント/トランザクション/履歴）

オントロジー：RDFグラフ自体は静的スナップショットだが、適切な語彙を用いてイベントや時間的側面を表現できる。一般には「Eventクラス＋時刻＋関与者（roles）」のn-ary関係設計が必要になる。
TM：eventは「行為・出来事・取引」として位置付けられ、resource（主体）がeventに関与する（R-E）がビジネス表現の基本となる。さらにevent間の後続関係（E-E）や対応表、resource間の対照表（制約/履歴）等が体系化される。
三要素分析/X-TEA：事件（イベント）をDFD等で“業務発生のトリガー”として扱い、業務モデル（アクションツリー等）で業務手順・操作を表し、データモデル（取引・履歴）と突き合わせる。Driverは「仕様書」を解釈して動作するため、イベント/操作が仕様化されやすい。
Palantir：Actionは「1つ以上のオブジェクトのプロパティ変更を行う単一トランザクション」として説明され、操作（=業務アクション）を第一級に扱う。イベントを“Actionログ”として扱うのか、“取引オブジェクト”としてモデル化するのかは設計選択となる。

階層化（分類階層・構成階層）

オントロジー：rdfs:subClassOfによりクラス階層を表現し、推論により上位概念も含めた分類が可能。プロパティ階層やドメイン/レンジも語彙として扱える。
TM：再帰（自己参照）や「並び」（全順序）をビジネス上の意味として扱い、再帰表や侵入（Re-Use）等で表現する。
三要素分析/X-TEA（渡辺）：自己参照型（組織階層等）と部品表型（BOM）を区別し、正規化・複合主キー・レベル管理（LLC等）を含めてデータ構造として表す。

推論/整合性検査（品質保証の仕組み）

オントロジー：OWLは形式意味論を持ち、プロファイルに応じて推論（含意）を行える。RDFS/OWLの不整合（例えば互いに排他的なクラスに同時所属する等）を検出できる。
TM：文法（生成規則）で“健全性・無矛盾性”を担保しつつ、意味論（指示規則）により“完全性（現実的事態への一致）”を狙う。L-真（論理的に無矛盾）とF-真（事実に一致）の区別に基づき、関係の網羅性や制約・束縛の網羅性を検証する。
三要素分析/X-TEA：三要素（データ/機能/業務）の相互整合により“業務とシステムの整合”を高めることを狙う。データモデルが形式化されているため、それに基づくプロセス/UIが収束しやすい、という主張がある。ツールとしてはModelerがデータ・プロセス・UIの設計を同一環境で扱う。

マスタ管理（意味の再利用と参照整合）

オントロジー：クラス階層（分類）と個体（インスタンス）を分け、マスタ値（コード体系）を「個体」として管理することもできる。IRIを通じて外部語彙との連携・再利用がしやすい半面、RDBの参照整合（FK制約）のような“閉世界での強制”とは設計前提が異なる（別途SHACL等でバリデーションする設計が多い）。
TM：resourceはマスタ的な主体（顧客、社員、商品等）になりやすい。重要なのは、属性に埋め込むのではなく、関係（線）として表現し、対照表等で制約・履歴・割当といった「関係の変化」を捉えること。
三要素分析/X-TEA（渡辺）：「商品台帳（商品マスター）」の整備が、表計算の誤集計防止など実務上の合理性に直結する、という説明がある。さらに、マスターに時限属性管理を機械的に埋め込むと論理関係が見えなくなるため、項目の性質に応じたテーブル分割（時限属性の切り出し）を推奨する。

スキーマ進化（変更に強い構造・移行）

オントロジー：METHONTOLOGYは、要求定義から保守までのライフサイクルを示しつつ、進化するプロトタイプ（evolving prototypes）を適切なライフサイクルとみなす。NeOnは再利用・協調・動的進化を前提に、シナリオベースでガイダンスを与える。
TM：個体指定子を恣意的に作らない、複合キーで箱を認識しない等は、スキーマ進化の足かせを避ける設計規律として働く。関係が変わる（社員と部署の配属関係等）なら、関係を表す対照表としてモデル化し、主体側を“更新させない”ことが勧められる。
三要素分析/X-TEA：Driverは仕様書を解釈してシステムを立ち上げるため、「保守フェーズでも仕様書を修正するだけ」という思想になりやすい（=コード再生成/再コンパイルを避ける）。
Palantir：OSv2はスキーマ移行フレームワークを提供し、重大なスキーマ変更後に既存ユーザー編集へ移行を適用できる事前定義移行を列挙する。Ontology Managerが破壊的変更を検出し、移行手順選択へ誘導する。

運用コスト（組織導入・ガバナンス）

オントロジー：語彙の合意形成、URI設計、データ統合、推論コスト、権限/データガバナンスなど、技術だけでなく組織設計が重くなる。
TM：熟練が必要。L-真/F-真、網羅性、制約束縛などの検証を回すため、チーム共通の文法理解とレビュー文化が不可欠。
三要素分析/X-TEA：データモデリングの専門知識に加え、事例知識・業務知識の蓄積が参入障壁になるという指摘がある。一方、仕様駆動により実装・レビューを早めることで手戻りを抑える設計が可能。
Palantir：製品機能として状態（Status）整合や移行フレームワークを備えるため、ガバナンスを“実装で補助”しやすい。ただしプラットフォームの学習・運用コストは別途発生する。

比較表

三手法の比較

観点	オントロジー設計理論（RDF/OWL）	TM（Theory of Models／T字ER）	三要素分析（TEA）／X-TEA
目的	語彙と意味の共有、再利用、推論・知識統合	事業の事実に一致したDB構造（F-真）を、文法で無矛盾に導く	データを起点に機能・業務まで整合させ、仕様駆動で開発・保守を加速
モデリング要素	クラス/プロパティ/個体、トリプル、階層（subClassOf）	entityをevent/resourceに分類、関係の文法（R-E等）、対照表	データモデル/機能モデル/UI/業務モデル、DFD、仕様書
成果物	OWL/RDF、語彙、知識グラフ、SPARQLクエリ	TMD、対照表、RDBスキーマ、検証結果	三要素一式の設計情報、Driverが解釈する仕様、（場合により）自動実行環境
適用範囲	複数領域・複数組織での意味統合、標準語彙、知識共有	基幹系/業務系のDB設計、業務事実の厳密化	企業システム（業務系）に特化、上流〜実装・保守の一体化
強み	セマンティクス、再利用、推論、外部語彙連携	文法に基づく品質、関係の網羅性、変化に強い論理	データ・プロセス・UIの整合、仕様駆動、実装とレビューの高速化
弱み	設計・合意形成コスト、検証設計（SHACL等）が別途必要	学習コスト高、組織に文法レビュー文化が必要	ツール/流儀への依存、企業システム以外では過剰になりうる
ツール/表記	OWL/RDF/JSON-LD、Protégé、SPARQL	TMD（T字形ER図）、MODEBI、TMD-Maker	X-TEA Modeler/Editor/Driver、ER図/DFD/アクションツリー等
典型の検証	推論（整合性、不整合検出）、SHACL等	L-真/F-真、網羅性、制約束縛の網羅性	三要素間整合（CRUD等）、データモデル起点の収束性
組織導入の鍵	語彙ガバナンス、URI/命名規約、データ統合体制	研修・レビュー、用語合意、文法徹底	設計情報の資産化、仕様駆動の運用（変更管理）

Palantir Ontology概念とTM（イベント/リソース）対応表

Palantir概念	Palantir側の説明（要旨）	TM側の対応（近い概念）	類似点	相違点・注意
Object Type / Object	特性を定義する型／そのインスタンス	resourceやeventを含むentity（箱）	「型と実体」を分ける	TMはまず“事業語の認知”から箱を立てる。Palantirはデータ資産へのマッピングが前提
Property	オブジェクトの属性値	attribute（性質）	属性を明示する	RDF/OWLではプロパティは“関係”にもなる（データ型プロパティ/オブジェクトプロパティ）
Link Type / Link	型どうしの関係／その関係インスタンス	関係の文法（線）、対照表	関係を第一級に扱う	TMはR-E/E-E/R-R等を文法化。Palantirはリンク型としてUI/運用に統合
Action Type / Action	変更の集合を単一トランザクションとして定義	event（事態）or 業務手順	“取引/操作”を中心に置く	TMのeventは「事実（取引）」のモデル。PalantirのActionは“操作”で、事実オブジェクト化は設計次第
Primary Key	インスタンス一意識別。非決定的識別子は禁物	個体指定子（NO/コード）	識別子が運用の要	TMは“キー生成しない”が、PalantirはPKプロパティを必須とし、データ品質・編集保持と結び付く
Schema migration framework	破壊的変更後の移行手順を製品で提供	（方法論としての）変更耐性設計	進化を前提	TMは製品機能ではなく、設計規律とレビューで変更耐性を作る

代表的適用事例（各対象2件程度）

オントロジー設計理論

Palantir Foundry Ontology（企業の“デジタルツイン/運用層”）

FoundryではOntologyがデータセット等のデジタル資産の上に位置し、現実世界の資産・注文・取引などに対応付ける“運用層”として説明される。Object Type/Link Type/Action Typeの定義を通じて、分析だけでなく“操作（Action）”を含むアプリ開発に接続する。
[Source] https://www.palantir.com/docs/foundry/ontology/overview
[Source] https://www.palantir.com/docs/foundry/ontology/core-concepts

Gene Ontology（生命科学の標準オントロジー）

Gene Ontologyは、生物学知識を標準化された形で表現し、概念（terms/classes）と形式的に定義された関係で結ぶ。種を跨いだ注釈（annotation）に利用され、コミュニティで維持される。
[Source] https://geneontology.org/docs/ontology-documentation/

TM（T字ER）

住友電工情報システムの事例（基幹系再構築におけるT字形ER図法）

基幹系再構築プロジェクトにおいて、DOAによる設計手順の一部としてT字形ER図法を採用し、習得に時間がかかったが採用自体に迷いはなかった、と述べられている。
[Source] https://www.sei-info.co.jp/framework/cases/smbj/

ワークフロー製品開発事例（成果物としてのT字型ER図）

上流工程〜成果物の例として、Fit/Gap、T字型ER図、ワークフロー経路設計書などが並列に示されている。
[Source] https://www.sei-info.co.jp/workflow/cases/sdc/

三要素分析/X-TEA

「新型コロナウイルスワクチン接種管理システム」のデータモデル例

イベント記録では、X-TEAによるワクチン接種管理システムのデータモデル（自治体、住民、接種申請、接種時程、ワクチン等）が提示されている。
[Source] https://note.com/xrad_rmodel/n/n0a50de405733
（補足：詳細説明のテキスト化がある再配信ページ）https://ungrimed29.rssing.com/chan-15665352/latest.php

X-TEAのレファレンスモデルを再現した生産管理パッケージ（TALON）

商品ページ上で「当システムの仕様は全て渡辺幸三氏による」「X-TEAにレファレンスモデルとして公開しているCONCEPTWARE／受注生産を忠実に再現」と明示され、モデル事例を複数ツールで実装して仮説検証した経緯が述べられる。
[Source] https://talon.jp/products/businesspackage/businesspackage-mfs/

実践ガイド（短いチェックリスト）

導入前チェック

目的は「意味統合（語彙と推論）」か「DB構造の厳密化」か「仕様駆動での一体開発」か
既存データ資産の品質（キー重複、コード体系、履歴管理方針）は把握できているか
用語（業務語彙）の合意形成を回す会（全社/部門横断の定例）が設計されているか

オントロジー（RDF/OWL）を選ぶとき

複数ドメイン/複数システムの意味統合が主目的
推論・分類・整合性検査を使って「人が見落とす矛盾」を機械で検出したい
URI設計・語彙ガバナンス・再利用（既存語彙の採用）に投資できる

TM（T字ER）を選ぶとき

基幹系/業務系で「事実に一致したDB構造」を確立したい
複合キー/対照表/履歴の設計を、文法とレビューで“規律化”したい
L-真/F-真、網羅性、制約束縛の検証をチームプロセスとして回せる

三要素分析/X-TEAを選ぶとき

データモデルを起点に、画面/機能/業務手順まで一気通貫で整合させたい
仕様（設計情報）を資産化し、Driver等で実装・保守を高速化したい
“データ・ファースト”でプロトタイプを回し、要件の曖昧さを早期に潰したい

Mermaid図（概念図）

TMの典型（Resource-Event）をERで表す（例：受注）

erDiagram
    CUSTOMER ||--o{ ORDER : "places"
    ORDER ||--o{ ORDER_LINE : "contains"
    PRODUCT ||--o{ ORDER_LINE : "is_ordered_as"
    ORDER {
      string order_no PK
      date order_date
    }
    CUSTOMER {
      string customer_code PK
      string name
    }
    PRODUCT {
      string product_code PK
      string name
    }
    ORDER_LINE {
      string order_no FK
      int line_no
      string product_code FK
      int qty
    }
三要素分析（データ・機能・業務）の整合ループ（概念）
CRUD/操作整合

業務手順整合

業務要件の検証

フィードバック

データモデル（ER）

機能モデル（画面/機能展開）

業務モデル（手順/アクションツリー）

プロトタイプ/仕様駆動実行（X-TEA Driver等）



コードを表示する
主要参考文献・公式資料（URL）
公式仕様・一次資料（優先）
W3C OWL 2 Overview: https://www.w3.org/TR/owl2-overview/
W3C RDF 1.1 Concepts: https://www.w3.org/TR/rdf11-concepts/
W3C RDF 1.2 Schema: https://www.w3.org/TR/rdf12-schema/
W3C JSON-LD 1.1: https://www.w3.org/TR/json-ld11/
W3C SPARQL 1.1 Overview: https://www.w3.org/TR/sparql11-overview/
Gruber, “Definition of Ontology” (PDF): https://tomgruber.org/writing/definition-of-ontology.pdf
Noy & McGuinness, “Ontology Development 101” (PDF): https://protege.stanford.edu/publications/ontology_development/ontology101.pdf
Fernández-López et al., “METHONTOLOGY” (PDF): https://oa.upm.es/5484/1/METHONTOLOGY_.pdf
NeOn Methodology: https://oeg.fi.upm.es/index.php/en/methodologies/59-neon-methodology/index.html
Palantir Foundry Ontology（公式ドキュメント）
Ontology Overview: https://www.palantir.com/docs/foundry/ontology/overview
Core concepts: https://www.palantir.com/docs/foundry/ontology/core-concepts
Object set service overview: https://palantir.com/docs/foundry/object-backend/object-set-service/overview
Create object type (JP): https://www.palantir.com/docs/jp/foundry/object-link-types/create-object-type
Action types overview (JP): https://www.palantir.com/docs/jp/foundry/action-types/overview
Metadata statuses: https://palantir.com/docs/foundry/object-link-types/metadata-statuses
Schema migrations (JP): https://www.palantir.com/docs/jp/foundry/object-edits/schema-migrations
OSv1 → OSv2 migration: https://palantir.com/docs/foundry/object-backend/osv1-osv2-migration
How user edits are applied: https://palantir.com/docs/foundry/object-edits/how-edits-applied
TM（T字ER）
住友電工情報システム「データモデリング」対談: https://www.sei-info.co.jp/framework/column/data-modeling/
ソフトウェアシンポジウム2009 TMスライド（時本永吉）: https://www.sea.jp/Events/symposium/ss2009/contents/07-Modeling/ss2009-modeling-slide-tokimoto.pdf
TMコンテンツ公開（住友電工情報システム）: https://www.sei-info.co.jp/news/news_kw20180904.html
導入事例（基幹系再構築）: https://www.sei-info.co.jp/framework/cases/smbj/
導入事例（ワークフロー開発）: https://www.sei-info.co.jp/workflow/cases/sdc/
技術評論社『事業分析・データ設計のためのモデル作成技術入門』: https://gihyo.jp/book/2022/978-4-297-12946-0
MODEBI: https://www.modebi.jp/modbi/
TMD-Maker: https://www.tmdmaker.org/
三要素分析/X-TEA・渡辺幸三
情報システム学会MM「データ・ファースト」(PDF): https://www.issj.net/mm/mm17/07/mm1707-db-db.pdf
TECH PLAY（イベント説明に三要素分析の要旨）: https://techplay.jp/event/632152
GitHub: XeadModeler: https://github.com/xead/XeadModeler
GitHub: XeadDriver: https://github.com/xead/XeadDriver
GitHub: XeadEditor: https://github.com/xead/XeadEditor
日本実業出版社（書籍情報）: https://www.njg.co.jp/book/9784534057778/
日本実業出版社（「はじめに」抜粋記事）: https://www.njg.co.jp/post-32895/
渡辺幸三ブログ（必要な専門知識、時限属性、階層構造など）:
https://dbconcept.hatenablog.com/entry/2022/01/24/105521
https://dbconcept.hatenablog.com/entry/2023/06/04/135818
https://dbconcept.hatenablog.com/entry/2021/07/24/123217
ケース：ワクチン接種管理モデル（イベント記録）: https://note.com/xrad_rmodel/n/n0a50de405733
ケース：参考テキスト（再配信）: https://ungrimed29.rssing.com/chan-15665352/latest.php
ケース：TALON 生産管理パッケージ: https://talon.jp/products/businesspackage/businesspackage-mfs/
オントロジーの代表例（ケース）
Gene Ontology Docs: https://geneontology.org/docs/ontology-documentation/
SNOMED CT OWL Reference Set（仕様）: https://docs.snomed.org/snomed-ct-specifications/snomed-ct-owl-reference-set-specification/introduction/1-introduction
text
コピーする

2026-02-18-ontology-data-modeling-2.md

オントロジー設計理論・T字ER(TM)・三要素分析/X-TEAの比較分析レポート（2026-02-18）

エグゼクティブサマリ

対象の定義と前提

理論的基盤とモデリング要素

オントロジー設計理論（RDF/OWL中心）

TM（Theory of Models／T字ER）

三要素分析（TEA Method）／X-TEA

技術的比較（横断ポイント）

識別子設計（ID戦略）

イベント表現（イベント/トランザクション/履歴）

階層化（分類階層・構成階層）

推論/整合性検査（品質保証の仕組み）

マスタ管理（意味の再利用と参照整合）

スキーマ進化（変更に強い構造・移行）

運用コスト（組織導入・ガバナンス）

比較表

三手法の比較

Palantir Ontology概念とTM（イベント/リソース）対応表

代表的適用事例（各対象2件程度）

オントロジー設計理論

TM（T字ER）

三要素分析/X-TEA

実践ガイド（短いチェックリスト）

導入前チェック

オントロジー（RDF/OWL）を選ぶとき

TM（T字ER）を選ぶとき

三要素分析/X-TEAを選ぶとき

Mermaid図（概念図）

TMの典型（Resource-Event）をERで表す（例：受注）