Superblocksはどのように社内アプリをAIガバナンスへ変えたか

Brad MenezesとRan Maは、企業のinternal softwareが重要なのに、作る速度とenterpriseの統制が両立しない問題に取り組んだ。出典

出発点

Superblocksは、business teamが必要なアプリを作れる速度と、ITが担うsecurityを一つのplatformに置いた。

転機

生成AIの普及後は、自然言語によるapp creation、MCP、既存アプリのimportへ広げた。出典

企業導入

VPC deployment、RBAC、SSO/SAML、SCIM、audit loggingを備え、AIの速さをproductionの条件へ接続した。出典

現在地

Bradが語る「Every company must become a software company」という見立ては、AIで作れることではなく、企業が安全に自分のsoftwareを持つことを意味する。出典

Superblocksは、業務部門のスピードとIT部門の統制が衝突するenterpriseに刺さる。

既存DB・APIを使いながらinternal appを作り、RBAC・監査・VPCまで同じ導入文脈で扱えるため、単なるno-codeより高い痛みを解く。出典

AI生成の速さが加わったことで、要求を待つだけの開発から、業務側が試作しITがgovernする流れへ移れる。

moatは、生成UIそのものではなく、enterpriseのpermission・audit・deployment要件を実装した運用面にある。

既存システムとの接続と顧客側の承認フローが蓄積されるほど乗り換えコストが生まれる。

ネットワーク効果は弱い。

利用者が増えても直接の二面市場にはならないが、integration・template・運用知見の蓄積は間接的に導入価値を高める。

主対象は、業務部門の内部ツールを大量に持つenterpriseのIT・Security・Operationsチーム。

個人向けの小規模フォーム作成だけを求める利用者には過剰になりやすい。

第一にAI生成をsecurityとgovernanceから切り離さない。

第二にcustomer VPCやSSOなどenterpriseの既存条件へ適応する。

第三にcustomer storiesとAWS連携で信頼を補強する。出典

AI生成アプリは品質・権限・データ漏洩のリスクを伴う。

governance機能が増えるほど導入は複雑になり、self-serveの軽さとenterprise契約の重さをどう両立するかは未解決の課題である。出典

セルフサービスの試用で入口を広げ、顧客事例とパートナー連携でenterpriseへ拡張する。

AWS VPCやapp importは、既存環境を捨てずに導入できるための摩擦低減策である。出典

主要チャネル: content, customerStories, partners, productLed

AI productのenterprise化では、生成品質だけでなく、誰が何を作り、どのデータへ触れ、どう監査するかを先に設計する必要がある。

機能の追加ではなく責任分界の再設計が価値になる。

日本ではExcel・Access・部門SaaSの置換より、まず既存データを変えずに監査可能なinternal appへ包む提案が現実的だ。

金融・製造・大企業の情報システム部門向けに、VPCと権限を前面に出すべきだ。