アプリ開発
アプリ開発に関する記事。実行可能なビジネスオントロジー、管理されたデータ、アプリ開発、エージェントワークフローを実践的に扱います。
-
匿名の
訪問者に フォームを 送信させて、 統制された 業務 アプリに 取り込むには？ 公開の 扉はひとつ、 幅は フィールド 五つ v17 以降、匿名のデータアクセスは常に拒否される。唯一開いている扉は公開フォームビューだ。ランタイムはフォームそのものから権限を導出する——フィールド五つが入り、一行が作られ、返るのはその id だけ。18.3.0 で実測。
アプリ開発 ビジネスリーダー 公開フォームWeb-to-Lead匿名アクセス -
ビュー、
ダッシュボード、 アプリは オントロジーの 投影である：それは レビューの 何を 変えるか 同梱の ObjectStack アプリに項目を一つ足すと、テーブル、REST API、MCP の describe 呼び出し、Console のフォームは自分で追従し、項目名を固定したビュー、データセット、翻訳は動かない。命名テストがどちらかを教える。
アプリ開発 開発者 オントロジー実行可能なビジネスオントロジーレビューできる diffメタデータレビュー -
バリデーションルール、
フック、 フロー？AI が 書いた アプリで ビジネスルールはどこに 置くべきか — 1 つの CRM、7 つの ルール、3 つの 住まい 1 つの CRM 上の 7 つのビジネスルールに、それぞれ 3 つの置き場所。選択は好みではなく表で決まる：述語はバリデーションルール、保存前のレコード書き換えはフック、それ以外はフロー — フローはデータとしてレビューできるから。
アプリ開発 開発者 CRM AI エージェントビジネスルール -
実行
可能な ビジネスオントロジーを 使うべきでないのはどんなときか？ 実行可能なビジネスオントロジーが今日は不向きな 5 つのワークロード、代わりに使うべきもの、選び間違えたときの代償、そして各行に出典を付けた判断表。
アプリ開発 IT / CIO オントロジー実行可能なビジネスオントロジー使いどころ -
実行
可能 オントロジー vs 知識 オントロジー：「継承なし、 公理なし、 推論器なし」こそが 要点である 理由 知識オントロジーは推論されるために作られ、実行可能なビジネスオントロジーは検証され実行されるために作られる。証拠はひとつのキー abstract：継承を約束し、何もせず、残されるのではなく取り除かれた。
アプリ開発 開発者 オントロジー実行可能なビジネスオントロジーナレッジグラフ -
「オントロジーが
ソフトウェアである」とはどういう 意味か？ 実行 可能な ビジネスオントロジーの 定義 この一文は ObjectStack のポジショニングであり、本稿はその定義だ。実行可能なビジネスオントロジーには六種の中核、四つの投影、三つの「ではないもの」があり、中核と投影を見分けるテストがある。
アプリ開発 開発者 オントロジー実行可能なビジネスオントロジー -
Retool の RBAC と
監査 ログ： 統治された AI アプリ 開発に Retool は 使えるか Retool の RBAC、監査ログ、アクセスポリシーを Retool の公式ドキュメントで検証。AI 生成アプリで何を統治するのか、エンタープライズアプリでの Retool と Lovable の違い、そして残る権限のギャップを整理する。
アプリ開発 開発者 RetoolRBAC監査ログLovable -
Airtable Omni：
生成されたものは 編集できるのか、そして 変更を 承認するのは 誰か Airtable Omniは一文から本番稼働するアプリを作る。生成物は要素のソースコードまで編集できる。だが大半の変更はOmniの構築と同時に反映されるため、レビューは変更の前ではなく後になる。
アプリ開発 ビジネスリーダー AirtableAirtable Omni -
AI が
アプリを 書いたあと：その diff を レビューして Merge できるか AI は動くアプリをすばやく生成でき、CI も通るかもしれない。本当の問題は、誰も全体を理解していない大きな PR に、誰が責任を持って Merge できるかだ。
アプリ開発 開発者 -
Vibe Coding の
技術的 負債：AI が 作った アプリはなぜ 後から 変えにくいのか AI が作った経費精算システムは数か月動いたが、税務ルールが変わると誰も 12,000 行の未読コードに触れなかった。長期システムには、コードではなくレビュー可能な定義が必要だ。
アプリ開発 IT / CIO -
AI ネイティブアプリケーションの
核心は コード 生成ではなく メタデータ 生成 コード生成はプロトタイプを速くしますが、エンタープライズアプリケーションには、オブジェクト、フィールド、関係、ビュー、権限、ワークフロー、アクション、Agent ツールをまとめて管理するメタデータ Runtime が必要です。
アプリ開発 ビジネスリーダー -
一文から
オブジェクト、 ビュー、 権限、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 エージェントエージェント権限 -
一つの
要件から 動く アプリへ： 修理 業務で 見る ObjectStack メタデータ 設備修理の具体例で、AI Builder が一つの要件をオブジェクト、フィールド、関係、ビュー、権限、アクション、ワークフロー、API、Agent ツールへ変換する過程を示します。
アプリ開発 開発者 -
複雑な
業務で ローコードが 限界に 達する 理由と、AI-native アプリ 基盤の 違い ローコードは画面やワークフローを速く作れますが、複雑な業務システムはオブジェクト、権限、連携、変更、保守性に制約されます。AI-native 基盤は別の層を解決します。
アプリ開発 IT / CIO 人事と社内アプリケース管理