記事
AI-native ソフトウェア構築に関する 39 本の記事。
おすすめ記事
おすすめ記事
まずはここから：ビジネスセマンティックレイヤーがなぜオープンであるべきか、AI-native の核心がなぜコードではなくメタデータなのか、そして一文がどうガバナンス可能なアプリになるのか。
-
公開済みオープンな
企業 オントロジー： 業務 セマンティックレイヤーは 誰が 所有すべきか 2025年11月から2026年8月にかけて5つのプラットフォームが業務セマンティックレイヤーを投入し、その多くが MCP の読み取り経路を開放した。だが定義そのものは内部に残る。プロトコルは開放、定義は封鎖——所有権の問いはより鋭くなった。
セキュリティとガバナンス ビジネスリーダー オントロジーセマンティックレイヤーMCPFabric IQUnity CatalogSnowflakePalantirLooker -
公開済みAI ネイティブアプリケーションの
核心は コード 生成ではなく メタデータ 生成 コード生成はプロトタイプを速くしますが、エンタープライズアプリケーションには、オブジェクト、フィールド、関係、ビュー、権限、ワークフロー、アクション、Agent ツールをまとめて管理するメタデータ Runtime が必要です。
アプリ開発 ビジネスリーダー -
公開済みVibe Coding の
技術的 負債：AI が 作った アプリはなぜ 後から 変えにくいのか AI が作った経費精算システムは数か月動いたが、税務ルールが変わると誰も 12,000 行の未読コードに触れなかった。長期システムには、コードではなくレビュー可能な定義が必要だ。
アプリ開発 IT / CIO -
公開済み一文から
オブジェクト、 ビュー、 権限、Agent へ：AI Builder の 生成 チェーン AI Builder で重要なのは、一文をページに変えることではなく、業務要求をオブジェクト、フィールド、ビュー、ワークフロー、権限、自動化、Agent ツールに分解することです。
アプリ開発 ビジネスリーダー AI エージェント
最新記事
最新記事
ObjectOS ブログの新着記事です。
-
公開済み「オントロジーが
ソフトウェアである」とはどういう 意味か？ 実行 可能な ビジネスオントロジーの 定義 この一文は ObjectStack のポジショニングであり、本稿はその定義だ。実行可能なビジネスオントロジーには六種の中核、四つの投影、三つの「ではないもの」があり、中核と投影を見分けるテストがある。
アプリ開発 開発者 オントロジー実行可能なビジネスオントロジー -
公開済み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 と AI ネイティブな
アプリ 基盤：それが 統治するのは 誰が アプリを 開くかであって、 ロジックが 何をするかではない Retool はローコードで最高のアクセス統治を備える——RBAC、監査ログ、SSO、セルフホスト。だが業務ロジックは画面に散らばった JavaScript で、人間が diff として精査できず、AI も監査できない。そこにギャップがある。
アプリ開発 開発者 Retool -
公開済みPower Platform ロックイン：Dataverse、Azure、
セルフホストの 判断 基準 Power Platform の強みは本物だ。ID、Teams、Dynamics、請求が同じテナントにある。ただし主権、規模コスト、AI 変更レビューを重視するなら、Dataverse と Azure ランタイムの境界は先に確認したい。
セキュリティとガバナンス IT / CIO DataversePower AppsPower Platform -
公開済みLovable は
本番 運用に 安全か： アクセス 制御 レビューの 問題 Lovable は高速なプロトタイプに向いている。だが本番システムで問うべきは動くかではなく、誰がアクセス制御をレビューできるかだ。RLS、フロントエンドフィルタ、安全スキャンの境界を見極めたい。
セキュリティとガバナンス 開発者 Lovable -
公開済みAirtable Omni vs ガバナンス
付き AI アプリプラットフォーム：なぜ 「元に 戻す」 ボタンではなく diffが 必要なのか Airtable Omni は自然言語と表形式アプリを強く結びつける。記録システムで問うべきは生成できるかではなく、AI が権限、フィールド、フローを変える前にレビュー可能な diff を出せるかだ。
アプリ開発 ビジネスリーダー 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 -
公開済み企業 AI Ontology：
業務 定義と ランタイムをともに オープンにすべき 理由 2026 年 6 月、Ontology MCP が GA。ベンダー自身が agent インターフェースを開放プロトコルに委ねた。定義層も追随している。開かれなかったのは実行層だけだ。
セキュリティとガバナンス ビジネスリーダー オントロジーMCPPalantir -
公開済み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 を載せられます。
連携とデータ 一般