実行可能なビジネスオントロジーを使うべきでないのはどんなときか？

結論から言うと、5 つのワークロードには向かない。しかもそれは ObjectStack のドキュメント自身が名指ししている。 大企業の基幹 ERP や財務システムの置き換え。多数の既存システムを統合することに価値があるもの。データレイク上の分析。アルゴリズムをアクションとして包まないかぎりの、プライシングやスケジューリングのようなアルゴリズム中心の領域。そして認証済みプラットフォーム上で動かさなければならないすべて。それぞれにより適した道具があり、本稿はそれがどれか、なぜそれが正しい選択か、選び間違えると何を払うことになるかを述べる。最後に、各行に出典を付けた判断表と、何かをインストールする前に自分のケースで試せる 10 問のセルフチェックを置く。

ある製品がどこで不向きかを正直に書いた一覧は、ベンダーが公開できるもののうちでいちばん役に立つ。買い手が営業資料から決して得られない唯一のものだからだ。ObjectStack の一行ポジショニングは「実行可能なビジネスオントロジーをひとつ。AI が書き、ランタイムが動かし、エージェントが操作し、あなたが所有する。」である。以下はすべてこの一文の縁についてであり、材料はプロジェクト自身の when-to-use ページと比較ページ（タグ @objectstack/cli@18.2.0、2026-10-28 読取）、そして境界がちょうど一行のコードであるソースファイルから取った。本サイトの比較ページはすでに 5 つのワークロードと 5 つの質問を一行ずつ挙げている。本稿はその長い版だ。それぞれにシナリオ、代替案とその根拠、代償、決め手となる事実を与える。

六種テスト

ひとつのテストで 5 つのケース全部を覆えるので、先に述べておく。コンセプトのページは、実行可能なビジネスオントロジーの核を六種のものとして定義する。オブジェクトとフィールド、リレーション、アクション、権限、フロー、そしてエージェントとツールの定義だ。ランタイムはこの六種からデータベース、API、UI、エージェントのツールを導出し、呼び出しのたびにそれらを強制する。コードは消えない。だがランタイムの中へ、フック、アクション本体、CEL、制約付き JSX として移り、六種が引いた柵の内側で動く。

だからどのワークロードにもこう問えばよい。難しい部分は六種のどれかか？ 仕事のうち難しく、価値があり、リスクのある部分が、何が存在し、どう関係し、何ができ、誰ができ、いつ何が起きるかを決めることであるなら、オントロジーが道具であり、エージェントがそれを書ける。難しい部分がそれ以外のもの、法定の計算、40 のシステムへの接続、ペタバイトの走査、ソルバー、監査人の証明書であるなら、その部分は定義として表現できず、オントロジーはせいぜいそれを包み、最悪の場合それを真似る。これを六種テストと呼ぶ。以下の 5 つのワークロードはそれぞれ別の理由でこのテストに落ちる。だから必要なのはひとつではなく 5 つの異なる代替案なのだ。

1. 大企業の基幹 ERP や財務システム

シナリオ。 従業員 4,000 人の製造業者が、総勘定元帳、連結、給与計算をパッケージ ERP で 12 年間運用している。勘定科目表を見せられたコーディングエージェントが、それをオブジェクトとして再宣言し、転記ルールをフローに、税を数式にすることを申し出る。デモは説得力がある。仕訳帳、試算表、すべての伝票への承認。

代わりに何を使い、なぜそれが正しいか。 パッケージシステムを使い、その周りに築く。when-to-use ページはこう言う。“A general ledger, consolidation, tax and payroll carry regulation and edge cases that packaged systems already encode. Build around that core, not instead of it.”（総勘定元帳、連結、税、給与は、パッケージシステムがすでに符号化している規制と例外を抱えている。その核の代わりにではなく、その周りに築け。）この市場では規制こそが製品だ。給与エンジンとは、管轄区域、申告カレンダー、遡及訂正のライブラリであり、それを最新に保つことだけを仕事にする人々が維持している。連結エンジンとは、長年にわたる内部取引消去と為替換算の例外の蓄積だ。どれも「何が存在し、誰が何をできるか」ではない。それは計算であり、あなたの事業が変わるときではなく、政府が変えるときに変わる。

選び間違えたときの代償。 第二の元帳。あなたが再符号化したルールの一つひとつが、いまや維持すべき diff、通すべき監査、課税年度が替わるたびの不具合になる。一方で法定報告のために残したパッケージシステムは、四半期ごとにあなたの写しから少しずつずれていく。一日でルールを書いたエージェントは、あなたの代わりに税法を読んではくれない。

決め手となる事実。 README の機能表はランタイムが提供する 12 項目を挙げている。オブジェクトとフィールド、権限、自動化、承認、ビュー、ダッシュボードとレポート、アクション、API と SDK、AI ツール、翻訳、シードデータ、データソース。元帳、税エンジン、給与計算はそこにないし、プロジェクトはそれらが来るとも言っていない。

同じページが適していると言うのは、その核の周りのロングテールだ。“vendor onboarding, inspections, internal requests”（取引先オンボーディング、点検、社内申請）、つまり ERP が扱わないものを追跡するスプレッドシートやフォームである。その一つひとつが、メールで回されるファイルではなく型付きの定義になり、ERP のデータを所有せずに読める。それが次のケースだ。

2. 多数の既存システムを統合することに価値があるワークロード

シナリオ。 ある銀行は、エージェントが勘定系、CRM、カードプラットフォーム、チケットシステムから顧客の質問にまとめて答え、そのうち 2 つにステータスを書き戻せるようにしたい。どのシステムも動かない。仕事は、それらをエージェントに読めるようにし、横断して行動することだ。

代わりに何を使い、なぜか。 システムの上に載る層。読みにはセマンティック層やコンテキスト層、統治すべき書き戻しがあるなら Palantir 型の運用オントロジー。比較ページはこれを率直に認めている。“When the data already lives in a warehouse, a lakehouse and a dozen operational systems, these start where you are.”（データがすでにウェアハウス、レイクハウス、十数の業務システムに住んでいるなら、これらはあなたのいる場所から始める。）それらの製品は、記録システムが動かないという前提で作られている。オブジェクトモデルはビューであり、書き込みは書き戻しであり、価値は下にあるシステムの数とともに増える。ObjectStack は逆の前提、オントロジーこそがシステムでありデータベースはそこから導出される、という前提で作られている。

選び間違えたときの代償。 これはいちばんよく間違えられるケースだ。最初の一週間はうまくいくからである。ObjectStack は schemaMode: 'external' で外部データベースをデータソースとしてフェデレートでき、レガシーテーブル上の読み取りモデルは午後ひとつで済む。それから書き込みになる。フェデレートした書き込みは既定で二重に閉じている。データソースが external.allowWrites: true を宣言し、オブジェクトが external.writable: true を宣言しなければならず、“with either gate off, insert/update/delete on the federated object is rejected.”（どちらかのゲートが閉じていれば、フェデレートしたオブジェクトへの insert/update/delete は拒否される。）このゲートは助言ではない。assertWriteAllowed はエンジンの insert と update の先頭で、デフォルト値、フック、検証の前に走る。オブジェクトごとに両方のゲートを開けば、あなたは自分の制御下にないスキーマに対する書き込みの意味論を背負うことになり、schemaMode: 'external' はスキーマ不一致で起動を失敗させるので、上流で列名がひとつ変わればあなたのアプリは止まる。あるいは代わりに同期ジョブを作り、気づけば、買わずに済ませようとしていた統合層を、自分の文書でフェデレーションを “early”（初期段階）と呼ぶ道具の中に作り上げている。

決め手となる事実。 既定でどちらも無効な 2 つのオプトイン。データソースの allowWrites とオブジェクトの writable（content/docs/data-modeling/external-datasources.mdx の書き込みの節）であり、packages/objectql/src/engine.ts の assertWriteAllowed が強制する。

正直な道は存在するが、狭い。読み取り専用で接続し、測り、オブジェクトごとに書き込みを有効にし、オブジェクト単位で切り替える。How to move an internal system to metadata はその道を、まったく移行しないのが正解であるケースも含めて辿る。その道は置き換えるつもりのシステムのためのものだ。40 のシステムを残して横断的に読むつもりなら、それは間違った道である。

3. データレイク上の分析

シナリオ。 ある小売業者は 3 年分のクリックストリームと POS のイベントを Parquet と Iceberg のテーブルとしてオブジェクトストレージに持ち、マーチャンダイジングチームはダッシュボードを欲しがっている。誰かが、このプラットフォームにはダッシュボード、レポート、そして文書がセマンティックと呼ぶデータセット層があることに気づき、それをレイクに向けようと提案する。

代わりに何を使い、なぜか。 ウェアハウスのスタック。列指向の走査のために作られたクエリエンジン、その上のメトリクス層またはセマンティック層、そのうえの BI ツール。ObjectStack の分析層は、アプリケーション自身の行のためのメトリクス層だ。その文書はデータセットを “a base object, the relationships to include, and the declared dimensions and measures”（ベースオブジェクト、含めるリレーション、宣言されたディメンションとメジャー）と定義し、結合はオブジェクトグラフから導出される。スキーマはそれを文字どおりにし、データセットの object を “Base object name”（ベースオブジェクト名）と記述する。when-to-use ページは一文で言う。分析層は “defines metrics over the app’s own objects for its reports and dashboards. It is not built to query a lake.”（アプリ自身のオブジェクト上にレポートとダッシュボードのためのメトリクスを定義する。レイクに問い合わせるためには作られていない。）ウェアハウスのセマンティック層はレイク上で同じ仕事をし、本サイトの比較ページも、本格的に BI をやる会社はやはりそれを欲しがるだろうと言っている。

選び間違えたときの代償。 2 つの写しのどちらか。レイクをアプリのオブジェクトに読み込めば、3 年分のイベントの第二の写しが、独自の鮮度と独自の請求書を伴って、走査用に設計されたのではなく業務定義から導出された行ストアに置かれる。あるいはウェアハウスのテーブルをフェデレートし、分析の質問を、アプリケーションのために行単位のクエリに答えるよう作られたエンジン、フィルタのプッシュダウンはあるが列指向ファイルを知るものは何もないエンジンに流していることに気づく。ダッシュボードは描画される。だがマーチャンダイジングチームが求めたダッシュボードにはならない。

決め手となる事実。 README が挙げるデータソースは PostgreSQL、MySQL、SQLite、MongoDB、インメモリであり、README がいま CONTRIBUTING.md に委ねているパッケージ一覧が Turso と WebAssembly 上の SQLite を加える。レイクのフォーマットも、列指向エンジンも、オブジェクトストレージのドライバもなく、データセット層が束縛されるのはオブジェクトであって、レイクの中のテーブルではない。

4. プライシングやスケジューリングのようなアルゴリズム中心の領域

シナリオ。 ある物流会社の製品は配送経路最適化だ。一日分の注文と車両群を受け取って計画を出すソルバーと、計画担当者が停車地を車両間でドラッグし、計画が再計算されるのを見るディスパッチボード。注文、車両、ドライバー、計画は明らかにオブジェクトである。会社は、全体を実行可能なオントロジーにできないかと尋ねる。

代わりに何を使い、なぜか。 ソルバーにもボードにもコードを。そしてここでは、オントロジー自身の文書が代替案の最も強い論拠になる。when-to-use ページはこう言う。オントロジーは “declares what can be done; it does not express an optimiser.”（何ができるかを宣言する。最適化器を表現するものではない。）アクションの type は script、url、modal、flow、api、form のいずれかであり、script アクションのハンドラは、アプリの全データ権限で動くコードだ。定義が所有するのは扉、扉の権限、誰がそこを通ったかの監査である。扉の向こうのアルゴリズムはあなたのもので、解ける言語なら何でもいい。インターフェースは同じ話の逆方向だ。比較ページは Console を “server-driven from metadata, and an interface unlike any business app is easier to build directly.”（メタデータからサーバー駆動であり、どの業務アプリにも似ていないインターフェースは直接作るほうが容易だ）と言う。

選び間違えたときの代償。 いちばん重要な部分を、いちばん自由の少ない場所に作ること。ソルバーはアクションの裏に住めるし、レコードから起動されるスケジューリング実行にはまさにそれが正しい。ディスパッチボードはそうはいかない。ページ内の制約付き JSX は意図的に “is parsed into a server-driven UI tree, never executed as code”（サーバー駆動の UI ツリーに解析され、コードとして実行されることはない）ので、計画担当者が必要とするすべての操作が、リスト、フォーム、ボードのために作られたレンダラーとの交渉になる。半年後、オントロジーは、あなたが実際に売っているものの周りの薄い皮になっている。

うまくいく切り分けはこうだ。業務の半分、注文、車両、ドライバー、誰が計画を承認できるか、計画が公開されたら何が起きるか、をオントロジーにし、エージェントが書いて操作できるようにする。ソルバーは script アクションの裏のコードにし、権限、監査、エージェントのアクセスが他のアクションと同じように適用されるようにする。計画担当者のボードは独立したアプリケーションにする。ボードが製品なら、そこから始めればよい。

5. 認証済みプラットフォームを必要とするワークロード

シナリオ。 ある病院グループが入院受付のワークフローを欲しがっていて、その調達部門は、それが動くプラットフォームが特定の認証を保持していることを求める。公共入札が ISO 認証について同じ問いを立てる。ワークロード自体、フォーム、ルーティング、承認、監査証跡は、教科書どおりの適合だ。

代わりに何を使い、なぜか。 認証を持つプラットフォームか、自分で認証を取るデプロイメントか。そして決めるのは買い手のカレンダーであって、ベンダーのロードマップではない。when-to-use ページはこう言う。“ObjectStack is open-source software you deploy and operate, and it carries no compliance certification of its own. Where a workload must run on a certified platform, certifying your deployment is work you own.”（ObjectStack はあなたがデプロイし運用するオープンソースソフトウェアであり、それ自体のコンプライアンス認証を持たない。ワークロードが認証済みプラットフォーム上で動かなければならない場合、あなたのデプロイメントを認証することはあなたが負う仕事だ。）これは逃げではなく、認証とはそういうものだ。認証が覆うのは稼働中の環境、その統制、その運用者であり、Apache-2.0 のリポジトリはそのどれでもない。本サイトのセキュリティページは商用版についても同じことを言う。“Certification depends on your running deployment, not a binary alone.”（認証は稼働中のデプロイメントに依存し、バイナリ単体では決まらない。）

選び間違えたときの代償。 設計時ではなく調達時にこれに気づくこと。スケジュールはすでにプラットフォームが認証を持ってくる前提で組まれている。すると監査は予算なしで、本番稼働の直前にあなたの計画に落ちてくる。

決め手となる事実。 プロジェクトの用語集は、自身のプロトコル適合キットさえ “planned”（計画中）とし、“no TCK program or certification mechanism in the codebase today”（今日のコードベースに TCK プログラムも認証の仕組みもない）と書いている。監査人に示せるものは、あなたのデプロイメント以外にない。

ワークロードは依然として適合する。問題はホストだ。正直な順序は、まず認証作業の費用を見積もり、それから決めることである。

もう 2 か所、別のカテゴリが先行する場面

比較ページはさらに 2 つの譲歩を加えている。それらは不適合の一覧にはない。ワークロードの種類ではなく問題の種類についてだからだ。どちらも六種テストを同じように通る。

異種データ上の推論。 問いが「我々の知るすべてから何が導かれるか」であり、クラス階層、導出された事実、語彙を横断する整合性検査を伴うなら、それは知識オントロジーの仕事であり、ObjectStack には “no object inheritance, no axioms and no reasoner”（オブジェクト継承も、公理も、推論器もない）。abstract キーは約束として残されるのではなく仕様から削除された。定義は検証され、それから実行される。実行時に推論されるものは何もない。定義の記事がこの否定を余すところなく扱っている。

エコシステムの成熟度。 Salesforce、Odoo、ERPNext は “bring years of production use, packaged applications, app marketplaces and implementation partners. ObjectStack is younger; expect to build more of it yourself.”（長年の本番利用、パッケージ化されたアプリケーション、アプリマーケットプレイス、導入パートナーをもたらす。ObjectStack はより若い。より多くを自分で作る覚悟をしてほしい。）今四半期にパッケージ化されたアプリが必要で、自分の街に導入パートナーが必要なら、定義がどう書かれていようと、より若いプラットフォームは間違った賭けだ。

判断表

各行は、ワークロード、今日適合するかと代わりに何を使うか、そしてそれを決めるひとつの事実と出典。「今日」は日付である。出典は objectstack のタグ @objectstack/cli@18.2.0、すなわち npm view @objectstack/cli dist-tags が 2026-10-28 に latest と報告したバージョンで、同日に読んだ。出典はファイル名で示す。when-to-use、compare、ontology は content/docs/concepts/*.mdx、external-datasources と analytics は content/docs/data-modeling/ 配下、glossary は content/docs/getting-started/ 配下、engine.ts は packages/objectql/src/engine.ts、dataset.zod.ts と action.zod.ts は packages/spec/src/ui/ 配下、README と CONTRIBUTING.md はリポジトリのルートにある。

ワークロード	今日適合するか？代わりに何を使うか	決め手となる事実（出典）
大企業の基幹 ERP や財務	否。パッケージシステム。その周りに築く	規制と例外が製品そのもの。ランタイムの 12 の機能に元帳、税、給与のエンジンはない（when-to-use、README 機能表）
多数の既存システムの統合	否。セマンティック層またはコンテキスト層。書き戻しがあるなら運用オントロジー	フェデレーションは既定で二重に読み取り専用。データソースの `allowWrites` とオブジェクトの `writable`（external-datasources、`engine.ts` の `assertWriteAllowed`）
データレイク上の分析	否。ウェアハウスのクエリエンジン、メトリクス層、BI	データセットはベースオブジェクトに束縛される。ドライバは行ストアで、レイクのフォーマットはない（analytics、`dataset.zod.ts`、README データソース、`CONTRIBUTING.md` ドライバ）
アルゴリズム中心の領域	アルゴリズムには不向き。コード。残りが業務アプリなら `script` アクションの裏に	`ActionType` は script、url、modal、flow、api、form。ソルバーが型になることはない（`action.zod.ts`、when-to-use）
認証済みプラットフォーム上で動かす必要がある	自分で負う作業なしには不向き。認証済みプラットフォーム、または自分のデプロイメントを認証する	自身のコンプライアンス認証はない。適合キットすら「計画中」（when-to-use、glossary）
異種データ上の推論	否。推論器を持つ知識オントロジー	継承も公理も推論器もない。`abstract` は ADR-0049 のもとで削除（ontology、compare）
成熟したエコシステムが今すぐ必要	まだ。パッケージアプリとパートナーを持つメタデータプラットフォーム	「ObjectStack はより若い。より多くを自分で作る覚悟を」（compare）
新しい業務アプリ：CRM、チケット、承認、オペレーション、社内ツール	是。	オブジェクト、リレーション、アクション、権限、フローがこれらのアプリの大半（when-to-use）
基幹 ERP の周りのロングテール	是。	小さく、具体的で、よく変わる。アプリごとに型付き定義ひとつ、ERP を所有せずに読む（when-to-use）
初日からエージェントが運用するバックオフィス	是。	すべてのデプロイメントが MCP サーバーで、既定で有効、ユーザーの権限のもとで動く（when-to-use、README）

セルフチェックを実行する

10 問、2 段階、10 分。第一段階は除外リスト、第二段階は when-to-use ページの “Five questions before you start”（始める前の 5 つの質問）を、そこに印字されているとおりに引用したものだ。

第一段階。どれかひとつでも「はい」なら、その部分にオントロジーは道具ではない。

このワークロードの難しい部分は、パッケージシステムがすでに符号化している規制上の計算か。元帳、連結、税、給与か。
価値の大半は、残すが所有しないシステムの読み書きから来るか。
分析したいデータは、アプリケーション自身のレコードではなく、レイクやウェアハウスに静置されているか。
製品の核はソルバー、最適化器、シミュレーションか、あるいはどの業務アプリにも似ていないインターフェースか。
ワークロードは特定の認証を保持するプラットフォーム上で動かなければならず、自分のデプロイメントを認証する予算はないか。

第二段階。あなたのチームは、事業についてこれらに今日答えられるか。

“What we have — the objects and their fields.”（何を持っているか。オブジェクトとそのフィールド。）
“How it relates — the lookups and master-detail links between them.”（どう関係するか。それらの間のルックアップとマスター・ディテールのリンク。）
“What can be done — the actions a user or an agent may take on a record.”（何ができるか。ユーザーやエージェントがレコードに対して取れるアクション。）
“Who may do it — permission sets, row-level and field-level security, sharing.”（誰ができるか。権限セット、行レベルとフィールドレベルのセキュリティ、共有。）
“What happens when — record triggers, scheduled jobs, approvals, workflows.”（いつ何が起きるか。レコードトリガー、スケジュールジョブ、承認、ワークフロー。）

5 つの「いいえ」と 5 つの答え。オントロジーは、そのページの言葉で “a day’s work, because an agent does the writing.”（一日の仕事だ。書くのはエージェントだから。）5 つの「いいえ」と答えなし。“no tool helps yet, this one included. The first investment is answering these five questions, not installing anything.”（まだどの道具も役に立たない。これも含めて。最初の投資は、何かをインストールすることではなく、この 5 つの質問に答えることだ。）第一段階に「はい」がひとつ。その線でワークロードを分割し、通った部分を残し、残りには表の代替案を使う。

この一覧が言っていないこと

これらの限界が恒久的だとは言っていない。ページのタイトルは「not a fit today」（今日は不向き）であり、フェデレーションは「early」（初期段階）と呼ばれ、上の表には日付が付いている。決める前に現在のページと照らし合わせてほしい。

代替案が一般に優れているとも言っていない。セマンティック層は 40 のシステムを横断して読むには正しい道具であり、チケットデスクを運用するには間違った道具である。理由は第 2 節が逆方向から述べたとおりだ。各行の代替案は、その行に対して正しい。

そして、一行に落ちればワークロード全体が落ちるとも言っていない。現実のケースの多くは分割される。入院受付のワークフローは適合し、ホストは調達の問題だ。ディスパッチの領域は適合し、ソルバーはコードだ。ERP の周りの部門アプリは適合し、元帳はそのままの場所に残る。六種テストが適用されるのは難しい部分であって、プロジェクト名ではない。

この一覧の中での ObjectOS の位置

上のどれもエディションによって変わらない。ObjectOS には 3 つのエディションがあります。オープンソースで無料でセルフホストできる ObjectOS Community、ブラウザ上でホストされインストール不要の ObjectOS Cloud、自社インフラでセルフマネージドの ObjectOS Enterprise です。オントロジーは通常の ObjectStack メタデータです。ObjectOS Cloud または ObjectOS Enterprise からエクスポートしてオープンソースの ObjectStack ランタイムで実行する機能は、計画中です。5 つのワークロードは実行可能なオントロジーが何を表現できるかについてであり、どこで動くかについてではない。だからこの一覧はどのホスト上でも同じように読める。ホストに関わる唯一の問い、認証については、セキュリティページが ObjectOS について、オープンソースのページと同じ言葉で答えている。稼働中のデプロイメントに依存する、と。

あなたのケースが通ったなら

最速で最も正直な次の一歩はデモではなく、定義だ。how to point your agent at ObjectStack で扱うルールファイル、スキルバンドル、ツールサーバーを使ってコーディングエージェントを ObjectStack に向け、最初のオブジェクトを頼む。いくつかのフィールド、ひとつのリレーション、ひとつのアクション、ひとつの権限セット、ひとつのトリガー。npm run validate を実行し、Console を読む前に diff を読む。diff を全部読めて、それがあなたの事業のしていることを語っているなら、六種テストは実践で通ったのであり、次にエージェントへ渡すページは定義とは何かだ。読めないなら、本稿の何もあなたの役には立たなかったはずで、あなたはいまプロジェクトをひとつ節約したことになる。