記事
実行可能なビジネスオントロジー、ランタイムガバナンス、エージェントが操作するアプリケーションに関する 51 本の記事。
おすすめ記事
おすすめ記事
まずはここから：「オントロジーがソフトウェアである」とはどういう意味か、業務定義層は誰が所有すべきか、AI が作ったアプリはなぜコードではなくメタデータならガバナンスでき変えられるのか。
-
「オントロジーが
ソフトウェアである」とはどういう 意味か？ 実行 可能な ビジネスオントロジーの 定義 この一文は ObjectStack のポジショニングであり、本稿はその定義だ。実行可能なビジネスオントロジーには六種の中核、四つの投影、三つの「ではないもの」があり、中核と投影を見分けるテストがある。
アプリ開発 開発者 オントロジー実行可能なビジネスオントロジー -
オープンな
企業 オントロジー： 業務 定義層は 誰が 所有すべきか 2025年11月から2026年8月にかけて5つのプラットフォームが業務定義層を投入し——2社はオントロジー、3社はセマンティックレイヤーとして——その多くが MCP の読み取り経路を開放した。だが定義そのものは内部に残る。プロトコルは開放、定義は封鎖——所有権の問いはより鋭くなった。
セキュリティとガバナンス ビジネスリーダー オントロジーセマンティックレイヤーMCPFabric IQUnity CatalogSnowflakePalantirLooker -
AI ネイティブアプリケーションの
核心は コード 生成ではなく メタデータ 生成 コード生成はプロトタイプを速くしますが、エンタープライズアプリケーションには、オブジェクト、フィールド、関係、ビュー、権限、ワークフロー、アクション、Agent ツールをまとめて管理するメタデータ Runtime が必要です。
アプリ開発 ビジネスリーダー -
Vibe Coding の
技術的 負債：AI が 作った アプリはなぜ 後から 変えにくいのか AI が作った経費精算システムは数か月動いたが、税務ルールが変わると誰も 12,000 行の未読コードに触れなかった。長期システムには、コードではなくレビュー可能な定義が必要だ。
アプリ開発 IT / CIO
最新記事
最新記事
ObjectOS ブログの新着記事です。
-
匿名の
訪問者に フォームを 送信させて、 統制された 業務 アプリに 取り込むには？ 公開の 扉はひとつ、 幅は フィールド 五つ v17 以降、匿名のデータアクセスは常に拒否される。唯一開いている扉は公開フォームビューだ。ランタイムはフォームそのものから権限を導出する——フィールド五つが入り、一行が作られ、返るのはその id だけ。18.3.0 で実測。
アプリ開発 ビジネスリーダー 公開フォームWeb-to-Lead匿名アクセス -
誰が
顧客 レコードを 開いたか、AI エージェントも 含めて 証明できますか？ レコード 閲覧 監査と、 閲覧行が 決して 記録しない 4 つのこと @objectstack/cli 18.3.0 で、人の REST 読み取りとエージェントの MCP get_record はそれぞれ sys_audit_log に read 行を 1 つ残し、一覧・未登録オブジェクト・拒否された読み取りは何も残さなかった。行が持つもの、決して持たない 4 つのこと。
セキュリティとガバナンス IT / CIO 監査証跡レコード閲覧監査AI エージェントコンプライアンス -
ビュー、
ダッシュボード、 アプリは オントロジーの 投影である：それは レビューの 何を 変えるか 同梱の ObjectStack アプリに項目を一つ足すと、テーブル、REST API、MCP の describe 呼び出し、Console のフォームは自分で追従し、項目名を固定したビュー、データセット、翻訳は動かない。命名テストがどちらかを教える。
アプリ開発 開発者 オントロジー実行可能なビジネスオントロジーレビューできる diffメタデータレビュー -
旧
システムの スプレッドシートを AI が 作った アプリに 取り込むには？ インポートマッピング、 ドライラン、そして 行が 一致しない 三つの 結末 ObjectStack 18.3.0 で計測：名前付きインポートマッピングが他社のヘッダーとコードを一つのオブジェクトの項目に射影し、ドライランは何も保存せずに行ごとの完全なレポートを返し、一致しない行は作成・スキップ・失敗のいずれかになる。
連携とデータ ビジネスリーダー CRM データインポートインポートマッピングドライラン -
AI モデルは
企業に 入ると 何が 足りないのか？ 世界と 手と 柵 足りないのは知能ではない。企業に入ったモデルには、推論する世界、動かす手、行動を囲う柵が欠けている。実行可能なビジネスオントロジーひとつがその三つを供給し、出典付きの表が各供給をランタイムの機構に対応づける。
AI とエージェント IT / CIO AI エージェント実行可能なビジネスオントロジーMCPエージェントの権限 -
バリデーションルール、
フック、 フロー？AI が 書いた アプリで ビジネスルールはどこに 置くべきか — 1 つの CRM、7 つの ルール、3 つの 住まい 1 つの CRM 上の 7 つのビジネスルールに、それぞれ 3 つの置き場所。選択は好みではなく表で決まる：述語はバリデーションルール、保存前のレコード書き換えはフック、それ以外はフロー — フローはデータとしてレビューできるから。
アプリ開発 開発者 CRM AI エージェントビジネスルール -
AI が
黙って 変えた 権限を 出荷前に 捕まえるには？ アクセスマトリクス・スナップショットゲートを、7 行の CRM で 実測する @objectstack/cli 18.2.0 では、エージェントが allowDelete を false から true に変えても os validate は何も報告しない。オプトインしたアプリでは os compile がビルドを失敗させ、誰が何を得たかを一行で示し、人がスナップショットを再生成するまで止める。
セキュリティとガバナンス 開発者 AI エージェントエージェントの権限レビューできる diff -
実行
可能な ビジネスオントロジーを 使うべきでないのはどんなときか？ 実行可能なビジネスオントロジーが今日は不向きな 5 つのワークロード、代わりに使うべきもの、選び間違えたときの代償、そして各行に出典を付けた判断表。
アプリ開発 IT / CIO オントロジー実行可能なビジネスオントロジー使いどころ -
エージェントが
操作できる アプリ：すべての オブジェクトと アクションが、 ユーザーの 権限のもとで MCP ツールになるとき エージェントが操作できるとは、アプリがすでに MCP サーバーであり、エージェントがユーザーとして接続することだ。一度の実行、二人のユーザー、一つのアクション：同じ十二のツールで、権限の判定はリストではなく呼び出しごとに下される。
AI とエージェント 開発者 AI エージェントMCPエージェントが操作できる -
ビジネスアプリが
「AI が 書ける」とは？ 四つの ゲート：Typed・Validated・Reviewed・Governed 「AI が書ける」はモデルではなく対象フォーマットの性質だ。四つのゲートと一回の実走：故意の三つのミス、49 のルール、三つの位置特定済みエラー、そして修正後の通過。
AI とエージェント 開発者 AI エージェントAI が書ける -
実行
可能 オントロジー vs 知識 オントロジー：「継承なし、 公理なし、 推論器なし」こそが 要点である 理由 知識オントロジーは推論されるために作られ、実行可能なビジネスオントロジーは検証され実行されるために作られる。証拠はひとつのキー abstract：継承を約束し、何もせず、残されるのではなく取り除かれた。
アプリ開発 開発者 オントロジー実行可能なビジネスオントロジーナレッジグラフ -
オントロジーが
ソフトウェアである 企業ソフトウェアはインターフェースを三度変えたが、ユーザーは一度も変わらなかった。エージェントは四十年ぶりの新しいユーザーだ。必要なのは API ではなく、ランタイムが動かし、AI が書き、エージェントが操作し、あなたが所有するオントロジーである。
AI とエージェント 一般 オントロジーAI エージェント実行可能なビジネスオントロジー -
FDE(フォワードデプロイドエンジニア)は
何を 使うのか？ オントロジー 優先の オープンスタック FDE が 60–180 日のデプロイメントで実際に何を作るのか、この仕事を定義する 5 つの痛み、そして 2026 年の模倣の波がなぜ職種だけを写し取り、その下の基盤を写さなかったのか。
AI とエージェント 開発者 オントロジーMCPフォワードデプロイドエンジニアPalantir -
業務
アプリは 何 トークンか？ 完全な CRM 全体が 150k 未満 完全な CRM は型付きメタデータ全体で 150k トークン未満です。ビジネスロジックは 100k 未満、UI は約 50k。同梱のリファレンス CRM は約 16k です。コンテキストに丸ごと収まるソフトウェアは保守のされ方が変わります。
AI とエージェント 開発者 CRM AI エージェント -
AI Agent が
本番 データを 削除するとき： ランタイムガードレールが 必要な 理由 Replit のデータベース事故が示した構造的な教訓は、agent の影響範囲をプロンプトだけに任せてはいけないということだ。権限、承認、監査はランタイムが強制する必要がある。
AI とエージェント IT / CIO AI エージェントReplit -
Retool の RBAC と
監査 ログ： 統治された AI アプリ 開発に Retool は 使えるか Retool の RBAC、監査ログ、アクセスポリシーを Retool の公式ドキュメントで検証。AI 生成アプリで何を統治するのか、エンタープライズアプリでの Retool と Lovable の違い、そして残る権限のギャップを整理する。
アプリ開発 開発者 RetoolRBAC監査ログLovable -
Power Platform ロックイン：Dataverse、Azure、
セルフホストの 判断 基準 Power Platform の強みは本物だ。ID、Teams、Dynamics、請求が同じテナントにある。ただし主権、規模コスト、AI 変更レビューを重視するなら、Dataverse と Azure ランタイムの境界は先に確認したい。
セキュリティとガバナンス IT / CIO DataversePower AppsPower Platform -
Lovable は
本番 運用に 安全か： アクセス 制御 レビューの 問題 Lovable は高速なプロトタイプに向いている。だが本番システムで問うべきは動くかではなく、誰がアクセス制御をレビューできるかだ。RLS、フロントエンドフィルタ、安全スキャンの境界を見極めたい。
セキュリティとガバナンス 開発者 Lovable -
Airtable Omni：
生成されたものは 編集できるのか、そして 変更を 承認するのは 誰か Airtable Omniは一文から本番稼働するアプリを作る。生成物は要素のソースコードまで編集できる。だが大半の変更はOmniの構築と同時に反映されるため、レビューは変更の前ではなく後になる。
アプリ開発 ビジネスリーダー AirtableAirtable Omni -
AI が
アプリを 書いたあと：その diff を レビューして Merge できるか AI は動くアプリをすばやく生成でき、CI も通るかもしれない。本当の問題は、誰も全体を理解していない大きな PR に、誰が責任を持って Merge できるかだ。
アプリ開発 開発者 -
Agent ルールファイルの
書き方：AI に ガバナンス 可能な アプリを 生成させる AGENTS.md、.cursor/rules、CLAUDE.md はコードスタイルだけを管理すべきではない。権限、承認、監査、対象メタデータ形式を書けば、AI 生成アプリはレビューしやすくなる。
AI とエージェント 開発者 MCPAI エージェント -
EU AI Act 監査
準備：あなたの AI ランタイムは 証拠を 出せるか AI 判断の完全な記録を求められたとき、モデル品質だけでは足りない。ランタイムは認可、証拠、監督、監査履歴を示せなければならない。
セキュリティとガバナンス IT / CIO -
MCP セキュリティ：
プロトコルだけではなぜ 足りないのか MCP と A2A は agent とツールの接続を簡単にする。だが接続は認可ではない。企業に必要なのは、呼び出しごとに身元、権限、監査を強制するツール層だ。
AI とエージェント IT / CIO MCPガバナンス付きツールAI エージェントA2A -
AI Agent 試験
導入が 本番に 進めない 理由： 欠けている 四つの 実行 基盤 デモで喝采を浴びた agent が、法務の一問で止まることがある。問題はモデルではなく、意味、権限、承認、監査の四層がないことだ。
AI とエージェント ビジネスリーダー AI エージェント -
AI Agent の
料金： アクション 課金と セルフホスト 実行 コスト アクション単位や token 単位の課金は柔軟に見えるが、agent が自律的になるほどツール呼び出しは増える。コストは使用量曲線、データ域外、ロックイン、自社運用の分岐点を一緒に見る必要がある。
セキュリティとガバナンス ビジネスリーダー AI エージェントAgentforce -
Agentforce、Copilot Studio の
先へ:なぜ 一部の 企業は オープンで セルフホストの ランタイムを 選ぶのか Agentforce や Copilot Studio は自社エコシステム内で強い。だがデータ、権限、モデル選択が複数システムにまたがる企業では、オープンでセルフホスト可能なランタイムも比較軸になる。
AI とエージェント IT / CIO AgentforceCopilot StudioServiceNow -
Ontology は AI スタックの
標準になるのか？ ランタイムが オープンであるべき 理由 Ontology は AI スタックの標準的な構成要素になるのか？agent インターフェースはすでにそうなった。Ontology MCP は 2026 年 6 月に GA。定義層も追随している。ランタイムは閉じたままで、可搬性はそこにある。
セキュリティとガバナンス ビジネスリーダー オントロジーMCPPalantirセマンティックレイヤー -
一文から
オブジェクト、 ビュー、 権限、Agent へ：AI Builder の 生成 チェーン AI Builder で重要なのは、一文をページに変えることではなく、業務要求をオブジェクト、フィールド、ビュー、ワークフロー、権限、自動化、Agent ツールに分解することです。
アプリ開発 ビジネスリーダー AI エージェント -
Airtable のように
作り、 会話のように 変更する AI Builder の最も分かりやすい製品像は、表形式のアプリ構築と自然言語インタラクションの組み合わせです。オブジェクト、フィールド、ビュー、権限、自動化を対話で生成・変更できます。
アプリ開発 ビジネスリーダー Airtable -
会話で
業務 システムを 変える： フィールド、 ワークフロー、 ビュー、 自動化 AI Builder の本当の価値は、継続的な会話型イテレーションにある。フィールド、ワークフロー、ビュー、権限、自動化をメタデータ層で安全に進化させられる。
アプリ開発 ビジネスリーダー -
サポートが
顧客 課題を 理解する：AI チケットハブを 構築する 問い合わせ、顧客履歴、SLA、ナレッジを一つのチケットハブにまとめる。AI は回答を急ぐだけでなく、権限と監査の境界内でサポートの次の一手を提案する。
アプリ開発 ビジネスリーダー ケース管理顧客ポータル -
営業が CRM を
手 入力しないために： 対話できる AI セールスアシスタント 営業メモ、商談、フォローアップを AI が整理する。大事なのは入力を減らすことだけではなく、顧客データを権限の範囲で扱うことだ。
アプリ開発 ビジネスリーダー CRM AI エージェント -
プロジェクトリスクは
進捗 更新に 隠れる：AI プロジェクト 管理 アシスタント 進捗更新、課題、遅延シグナルを読み取り、プロジェクトリスクを早く見つける。AI は提案できるが、ステータス変更や通知は権限と承認の下で動く。
アプリ開発 ビジネスリーダー -
サプライヤーリスクを
早く 見る：AI 調達 意思 決定 アプリ サプライヤー、価格、納期、コンプライアンス情報をつなぎ、調達判断のリスクを早く見つける。AI の提案は承認と監査のある業務フローに載せる。
アプリ開発 ビジネスリーダー サプライチェーンと調達 製造 -
経費
審査は OCR だけではない： ルールを 理解する AI 財務 審査 アプリ 経費審査は OCR だけでは終わらない。AI は領収書、社内規程、例外理由を読み、承認者がレビューできる形でリスクを提示する。
アプリ開発 ビジネスリーダー 金融サービス -
チケット
起票から 会話へ：AI 社内 サービスセンター 社内問い合わせをチケット起票から会話へ移す。AI は回答候補を出し、必要な手続きへ導くが、従業員データと承認はランタイムが守る。
アプリ開発 ビジネスリーダー 人事と社内アプリケース管理 -
契約
レビューをまず AI に 任せられるか：AI 契約 リスクアプリ 契約書のリスク、欠落条項、承認ルートを AI が下読みする。ただし法務判断は置き換えず、レビュー可能な差分と監査証跡を残す。
アプリ開発 ビジネスリーダー 金融サービス -
コンテンツチームの AI ワークベンチ：
企画から 振り返りまで 企画、執筆、レビュー、配信、振り返りを一つの AI ワークベンチにまとめる。コンテンツ制作でも、権限、承認、履歴は生成速度と同じくらい重要だ。
アプリ開発 ビジネスリーダー 通信・メディア -
制度を
手で 読むだけの コンプライアンスから：AI 内部 統制 アプリ 規程、証跡、例外、是正タスクをつなぎ、内部統制を継続的に確認する。AI は判断を支援し、人間の承認と監査ログを残す。
アプリ開発 IT / CIO 金融サービス -
業務
システムに Agent を 持たせる： 実行できる AI ワークベンチ 業務システムに agent を足すなら、チャット欄だけでは足りない。実行できるアクション、権限、承認、監査を同じワークベンチで扱う必要がある。
アプリ開発 IT / CIO ガバナンス付きツールAI エージェントエージェント権限 -
企業の AI アプリ
基盤をまず 自社 管理 ランタイムにすべき 理由 AI が業務データを読み、フローを動かし、アプリを生成し、ツールを呼ぶなら、企業が制御すべきなのはモデルだけでなく、オブジェクト、権限、ツール、承認、監査を担うランタイムです。
セキュリティとガバナンス IT / CIO -
一つの
要件から 動く アプリへ： 修理 業務で 見る ObjectStack メタデータ 設備修理の具体例で、AI Builder が一つの要件をオブジェクト、フィールド、関係、ビュー、権限、アクション、ワークフロー、API、Agent ツールへ変換する過程を示します。
アプリ開発 開発者 -
AI エージェントを
企業の 権限 境界内で 動かす 方法 企業に必要なのは、AI エージェントをスーパー管理者にすることではありません。ユーザー権限を継承し、危険な操作は承認へ回し、すべてを監査できる制御されたエージェントです。
セキュリティとガバナンス IT / CIO AI エージェントエージェント権限 -
製造業が
レガシーシステムに AI をつなぐ 方法：ERP 置き 換えではなく、 レポートと 作業 指示から 始める 製造業のシステムは古く、重く、置き換えが難しいことが多い。実用的な AI の道は既存システムを接続し、レポート、作業指示、例外分析から始めることです。
連携とデータ IT / CIO ケース管理サプライチェーンと調達 製造 -
複雑な
業務で ローコードが 限界に 達する 理由と、AI-native アプリ 基盤の 違い ローコードは画面やワークフローを速く作れますが、複雑な業務システムはオブジェクト、権限、連携、変更、保守性に制約されます。AI-native 基盤は別の層を解決します。
アプリ開発 IT / CIO 人事と社内アプリケース管理 -
CRM から
始める：AI が 顧客、 商談、 フォロー 履歴を 理解するには 多くの CRM には顧客、商談、連絡先、活動履歴がすでにあります。AI の実用的な入口は、データを書き出すことではなく、権限の下でそれらの業務オブジェクトを理解させることです。
連携とデータ ビジネスリーダー CRM AI エージェントエージェント権限 -
既存の
業務 システムを 移行せずに AI-native にする セルフマネージドの ObjectOS（Enterprise）で、すでに動いているデータベースを既定の読み取り専用で接続し、コーディングエージェントでテーブルをオブジェクトとしてモデル化すれば、元のシステムを壊さず、権限の下で実データに AI を載せられます。
連携とデータ 一般