製品
ソリューション
会社情報
エンタープライズ
サインインネットワークを作成
AI · CRM · Production-readiness · Permissions · Routing · Theorem 3

CRM をルーティングするのは権限スコープで、生成された CRUD ではない

vibe-code された CRM はデモでは輝き、本番で失敗する。それを支えるメカニズムは権限スコープ——誰が何に作用できるかをルーティングする——であって、生成された CRUD ではない。Theorem 3 がその理由を説明する。

NocoBase のガイドの冒頭にある Reddit のスレッドは、営業主導チームが誰もが今問うている問いを投げかける。AI が午後の一息で CRM を生成できる今、あなたはまだ Salesforce や HubSpot を買うのか、それとも自分で vibe coding で書くのか。実際にやってみたビルダーからの正直な答えは、議論全体を支える一文だ——あなたは CRM を vibe-code できるが、実ユーザー、実データ、実ビジネスプロセスに直面しても信頼し続けるエンタープライズ CRM を vibe-code することはできない。コードを書くのは簡単な部分で、その背後にあるすべてがより難しい。

2026 年の NocoBase ガイド『How to Build a Production-Ready CRM with AI and NocoBase』はそのスレッドを真剣に受け止め、一つの役割分担を提案する。自然言語の要件から AI にアプリケーションを生成させ、データモデル、ロールベースの権限、セキュリティ監査、ワークフローを既に提供しているアプリケーション基盤に、実人が触れたときのシステムを支えさせる。2016 年から HAI Engine を本番で稼働させているチームとしての私たちの読みは、NocoBase は正しいメカニズムを名指したが、それを理論化しきれていなかった、というものだ。メカニズムは「AI プラス一つのプラットフォーム」ではない。それはルーティング層——権限スコープ、データ分離の境界、accounts を contacts に opportunities に quotations に繋ぐトポロジー——であり、生成されたどんな機能が応答するよりも先に、誰が何に対して作用できるかをルーティングする。それが the 21 papers シリーズの Theorem 3 だ。ある性質は、それを生み出すメカニズムが実装され測定しているときにちょうど保証される。本番対応度は性質である。権限スコープはそのメカニズムだ。

Reddit のスレッドはメカニズムを名指したが、それを主張しなかった

ガイドは r/CRM の Reddit 議論で始まる。そこで内部 CRM を vibe-code したビルダーが、AI は基本機能——顧客管理、ダッシュボード——を素早く生成するが、権限、データ分離、セキュリティ、継続的保守は依然として手作業で解決しなければならないと報告している。これは正直な現場報告で、ほとんどの AI ビルダー記事を囲むマーケティング文案より有用だ。ビルダーは AI が失敗したとは言わなかった。生成された表面が問題の簡単な割合で、難しい割合は AI 生成がデフォルトで届かないところにある、と言った。

[UNIQUE INSIGHT] このスレッドは、「AI がそれを作った」という主張すべてに現れるパターンの綺麗な実例だ。生成された成果物はデモ述語(描画する、入力を受け取る、レコードを返す)を満たし、本番述語(ある担当者が別の担当者のパイプラインを見る;閉じた案件が引き継ぎを発火させない;監査ログが存在しない)で失敗する。これらはモデルが忘れた機能ではない。実装されたことのないメカニズムであり、実装されないメカニズムは測定できず、だから性質は保証されない。Reddit のビルダーはメカニズムの不在に気づいた。NocoBase も気づき、それを巡ってプラットフォームを構築した。

これが CRM に特別に効くのは、CRM が権限の境界こそが製品であるシステムだからだ。共有スプレッドシートはロールベースのアクセス制御なしで生き延びる。信頼モデルが「シート内の全員が信頼できる」だからだ。CRM は違う。担当者のビュー、マネージャーのビュー、読み取り専用ステークホルダーのビューは、一つのスキーマを共有する三つの異なる製品だ。スコープを間違えれば、UX バグではなく機密性インシデントを得る。

コードを書くのは簡単な部分;その背後にあるすべてはルーティング層

ガイドの構造的主張は、「AI が CRM を作った」と「エンタープライズ使用に対応した CRM」の間にギャップがあり、既に困難な部分を提供するアプリケーション基盤を AI に与えることで閉じられる、というものだ。私たちはその診断に同意し、困難な部分が実際に何であるかを正確にしたい。ガイドはそれらを能力として並べ、Honest Architect はそれらをメカニズムとして読む。

CRUD は表面;権限スコープは耐力壁

プロンプトから生成された CRM は五つのコレクション——accounts、contacts、opportunities、products、quotations——とその間の関係を生成する。AI エージェントが業務記述の一段落からそのデータモデルを生成できるのは本当に有用だ。だがデータモデルは平面図であって建物ではない。耐力壁は権限スコープだ。営業担当者は自分に割り当てられた顧客、案件、フォローアップだけを見る、営業マネージャーはチーム全体のデータを見て所有者を再割り当てできる、読み取り専用ユーザーは見ることはできるが触れない、というルールだ。

NocoBase のガイドは第三セクションでこれを正しくやる——システムを再生成するのではなく、既存の CRM に対して AI にロール、データスコープ、操作権限を設定させる。それが正しい順序だ。スキーマを生成し、それからアクセスをルーティングする。ガイドがかすめ、Reddit のビルダーが陥った誤りは、権限を最後に追加する機能として扱うことだ。権限はルーティング層だ。いかなるページが描画されるよりも先に、どのレコードがどのセッションに流れるかを決める。最後に追加すれば、最初の一週間は全担当者が管理者だったシステムを出荷済みになる。

データ分離はルーティング問題であって、データベース機能ではない

ガイドは権限とセキュリティの隣にデータ分離を挙げ、Reddit のビルダーはそれを vibe coding が解決しないことの一つとして並べる。データ分離は、担当者 A の案件がマネージャーによって横断的に割り当てられない限り担当者 B に見えないという要件だ。素朴に実装すれば、各クエリの WHERE owner_id = current_user() 句だ。正しく実装すれば、それはルーティングの決定だ。セッションのロールと割り当てグラフが accounts コレクションのどの部分集合をアドレス可能にするかを決め、クエリ層がそれを境界で強制し、生成されたページが行を直接取得して迂回できないようにする。

[PERSONAL EXPERIENCE] 私たち自身のプラットフォームでは、同じ原則が「the space is the router」として現れる。リクエストが応答される前に、network→community→room トポロジーが呼び出し元が世界のどのスライスをアドレスしているかを決める。ルーターが先に走る;ハンドラーが次に走る。私たちは HAI Engine の初年にそれを学んだ。自分自身のロジックの中でスコープを強制しようとしたハンドラーは、忘れられた一つの分岐が常にテナント間漏洩の縁にあった。スコープの検査をルーターへ——ハンドラーが見ることを許されるものさえ決める層へ——移すことで、そのバグのクラス全体が除去された。実販売チームを生き延びたい CRM は同じ形を必要とする。権限スコープは境界で走り、機能の内側ではない。

Theorem 3 は NocoBase の役割分担をちょうど読み取る

ガイドの結論は、新たな役割分担を記述する。AI は業務を理解し、アプリケーションを生成し、反復し続ける;エンタープライズプラットフォームは、システムが長期にわたり信頼でき動くために必要なデータ管理、権限、ワークフロー、監査、その他の基盤を提供する。Theorem 3 は、なぜそれが正しい分割かを語らせる。

Theorem 3 は、the 21 papers の中で、あるシステムの性質は、その性質を生み出すメカニズムが実装され測定しているときにちょうど保証されると述べる。対偶が噛む部分だ。メカニズムが不在か、存在しても測定していなければ、性質は保証されない——生成されたコードがどれほど良く見えても。本番対応度は性質だ。そのメカニズムは権限スコープ、監査トレイル、ワークフロートリガー、データ分離境界だ。CRM を vibe-code すれば、あなたが実装したのは CRUD であって、それらのメカニズムではない。だから Theorem 3 は Reddit のビルダーが観察したことをちょうど予測する。デモは動くがシステムは本番対応でない。なぜなら本番対応を保証するはずのメカニズムが一度も構築されなかったからだ。

だから「AI プラス一つのプラットフォーム」は構造的な組であって、マーケティングのそれではない。プラットフォームは事前実装され事前測定するメカニズムの集合であり;AI はメカニズムでなくてよい部分——ページ、フィールド、この会社の販売プロセスのための個別の関係——を生成する。NocoBase が CRM はその後長期にわたり信頼でき動くと言うとき、それはそれらのメカニズムが真実で活性であるときにのみ成り立つ保証を主張している。

基盤が既にそこにあるとき CRM が受け継ぐもの

NocoBase アプローチの実用的価値は、タイプを省くことではない。生成された CRM が、自分では構築しなくてよかったメカニズムの集合を受け継ぎ、だから otherwise は主張できなかった保証の集合を受け継ぐことだ。その三つは、Reddit のビルダーが vibe coding が欠くと言ったものだ。データスコープ付きのロールベース権限で、データ層で強制され、生成されたページがロールが見るべきでないレコードを露出できないようにするもの。セキュリティ監査——誰が何をいつ変えたかの追記専用記録で、CRM が生成される前にプラットフォームの監査メカニズムが既に測定していたからこそ存在するもの。そしてワークフロー、トリガー条件と期待結果のルール(閉じた案件が顧客ステータスを更新しフォローアップタスクを作る;停滞した案件が七日以内にリマインドを出す)で、ページに貼るのではなくイベント層に配線しなければならないもの。

それぞれが Theorem 3 の実例だ。メカニズムが実装され測定しているから性質が成り立つ。いずれかのメカニズムを取り除けば、対応する保証が消え、生成された UI がどれほど流暢でも関係ない。

AI Employees は記録を整理する;境界を所有するわけではない

ガイドは第四の層を加える——会議メモや顧客メールを受け取り、コミュニケーションを整理し、要点と次のアクションを抽出し、フォローアップを提案する AI Employees。これは最も過剰に主張されやすい部分なので、注意したい。会議を要約する AI Employee は有用なアシスタントだ。それは本番対応のメカニズムではない。権限スコープを強制しない。それ自体では監査エントリを作らない。記録を整理する;境界は依然としてプラットフォームが所有しなければならない。二つの層は組み合わさる——AI Employees はシステム内の記録の質を上げ、プラットフォームのメカニズムは記録を信頼でき、スコープされ、帰属可能に保つ。それらを混同すれば、vibe code の失敗モードに戻る。間違った担当者が読めるシステムに美しいメモを書く AI になる。

The space is the router——CRM の内側と外側で

私たちが Everythink ブログで NocoBase の CRM ガイドについて書く理由は、メカニズムが同じメカニズムだからだ。CRM の内側では、権限スコープがいかなるページが応答するよりも先に、誰が何に作用できるかをルーティングする。CRM の外側では、私たちのプラットフォームで、network→community→room トポロジーがいかなるエージェントや予測が応答するよりも先に、誰が誰をアドレスしているかをルーティングする。「the space is the router」はスローガンではない。ルーティングを第一に、ハンドラーを第二に置くという設計決定の名前だ。

Everythink の network→community→room トポロジー

Everythink で、network は顧客が所有するブランド付きの世界だ。その内側で、communities が共通の目的の周りにメンバーを集め、その内側で、rooms が実際の仕事をホストする——一つの Campaigns、一つの Marketplace リスティング、一つの Calendar、一つの Matchmaking。リクエストが応答される前に、トポロジーが呼び出し元がどの network、どの community、どの room にいるかを決め、だからどのデータのスライス、どのエージェント、どの予測がアドレス可能かを決める。Social モジュール ✅、Campaigns ✅、Whitelabel Network ✅ は今日このトポロジーの中で動く。Matchmaking ⚠️、Marketplace ⚠️、Calendar ⚠️ は部分的だ——利用可能だが、メカニズムはまだ硬化中。World Monitor ✅ は同じルーティングを通じて地理シグナルをストリームし、呼び出し元のビューポートが実際にアドレスするタイルにスコープされる。

これはうまく構築された CRM と同じ形だ。CRM の accounts→contacts→opportunities→quotations トポロジーはアクセスをルーティングする;Everythink のトポロジーはアドレス指定をルーティングする。両方で、ルーターがハンドラーの前に走り、その順序がシステムを実ユーザーに晒しても安全にする。The Sisters ✅——実世界のアクターのために妥当な未来をシミュレートする型付けされた AI エージェント——と、そのドラフトを較正された予測へ融合する The Oracle ✅ は、ルーティングされた rooms の中でのみ動く。それらはルーターが開かなかった境界を決して越えない。

顧客主権:あなたのデータ、あなたの権限グラフ

ガイドは主権の主張をしないが、メカニズムはそれを含意する。権限スコープが耐力壁なら、スコープを所有する者がシステムを所有する。あなたがホストするプラットフォームの上に構築された CRM は、あなたが権限グラフを制御する CRM だ;専有 SaaS に vibe-code された CRM は、ベンダーが権限グラフを制御する CRM だ。だから私たちは Everythink を顧客が所有する network として構築する——network はブランド、データ、権限グラフ、ルーティングであり、すべて顧客主権の下にある。HAI Engine は 2016 年から本番でそのルーティングを運んできた。メカニズムが九年間実装され測定し続け、だからルーティングされスコープされた性質が九年間保たれた。同じ保証を欲する CRM プラットフォームは、生成されたものではなく、同じ種類の稼働し測定するメカニズムを必要とする。

スコープの倫理とインクルージョン・バイ・デザイン

こうして構築された CRM に二つの不変条件が効く。Everythink は市民的・防御的のみだ;The Sisters と The Oracle は人々が調整するのを助ける結果を予測し、傷つけ合うのではない。CRM はデフォルトで市民的道具だ——営業チームが顧客への約束を守るのを助ける——そして担当者 A のパイプラインを担当者 B から守くのと同じ権限スコープは、一般化すれば、個人のデータを同意しない使われ方から守くメカニズムの種類だ。二つ目はインクルージョン・バイ・デザインだ。実顧客ベースに service する CRM は、言語、低接続性条件、スクリーンリーダーを横断して動く必要がある。Everythink では多言語とマルチモーダルはルーティングの中にあり、後からボルトで留めるのではない。インクルージョンを真剣に扱う基盤の上に構築された CRM はその性質を受け継ぐ;vibe-code された CRM は機能ごとにそれを追加しなければならず、大抵はしない。

主要な要点

  • 権限スコープがメカニズムであり、生成された CRUD ではない。 CRM が実チームを生き延びるのは、ルーティング層——スコープ、分離、監査、ワークフロー——が実装され測定しているからで、ページが描画されるからではない。
  • Theorem 3 は vibe code の失敗を予測する。 本番対応度は性質であり、そのメカニズムが実装され測定しているときにちょうど保証される。CRUD を vibe-code すればメカニズムは不在で、だから保証も不在だ。
  • NocoBase の役割分担は正しいが理論化不足だ。 AI は非メカニズム部分を生成する;プラットフォームは実装され測定するメカニズムを提供する。それが「AI プラス一つのプラットフォーム」を構造的組として読むことだ。
  • 「the space is the router」は CRM の内外で同じメカニズムだ。 CRM のトポロジーはアクセスをルーティングする;Everythink の network→community→room トポロジーはアドレス指定をルーティングする。両方でルーターがハンドラーの前に走る。
  • 顧客主権はルーティング層に従う。 権限グラフを所有する者がシステムを所有する。顧客が所有する network は、ルーティングを第一に置くことの構造的帰結だ。
  • AI Employees は記録の質を上げる;プラットフォームが境界を所有する。 会議を要約するのは有用だ。それは本番対応のメカニズムではない。二つの層を混同しないこと。

よくある質問

AI 単独で本番対応の CRM を構築できるか? デモ対応の CRM は構築できる。本番対応には、メカニズム——権限スコープ、データ分離、監査、ワークフロー——が実装され測定していることが必要だ。Theorem 3 は、性質はメカニズムがそうであるときにのみ保証されると言う。AI は表面を生成する;プラットフォームがメカニズムを運ぶ。

これは Everythink の「the space is the router」にどう対応するか? CRM の内側では、権限スコープが誰が何に作用できるかをルーティングする。CRM の外側では、network→community→room トポロジーが誰が誰をアドレスしているかをルーティングする。両方ともルーターをハンドラーの前に置く;両方ともシステムを実ユーザーに晒しても安全にする。The Sisters と The Oracle はルーターが開いた rooms の中でのみ動く。

HAI Engine の本番履歴は CRM に関連するか? それは同じ定理の経験版だ。HAI Engine は 2016 年からそのルーティングメカニズムを、実装され測定したまま運んできたので、ルーティングされスコープされた性質が九年間保たれた。CRM プラットフォームは同じ保証を主張するのに同じ種類の稼働し測定するメカニズムを必要とする。

Sources

もしあなたのチームが CRUD を vibe-code するのをやめ、顧客を支える空間をルーティングし始める準備ができているなら、Everythink であなたの network を作ろう——トポロジーは何かが応答する前にルーティングする。

自らの主張を証明するエンジンの上に、あなたの世界を築く。

2016 年から稼働し続けるエンジンの上に、あなた自身のネットワークを作る——あるいは 21 本の論文を書いたチームに話しかける。