moatはどこにあるのか Ecosystem · Community · Governance · MCP

競争優位を語るとき、多くの分析はプロダクト本体の機能に目を向けます。UIが洗練されているか、処理速度が速いか、他社にない独自機能があるか。SaaS業界の比較記事の大半は、この粒度で書かれています。

ただ、この見方はサイボウズを取りこぼします。kintone単体の機能一覧を並べて優劣を競うなら、Power PlatformやAirtableと比べてkintoneが圧倒するわけではありません。機能の網羅性で言えばMicrosoftのほうが厚く、データベース設計の自由度で言えばAirtableのほうが尖っています。にもかかわらず、日本市場でkintoneが契約社数3.9万社、東証プライム浸透率46%という位置に立っているのは、機能の比較では説明できない別のレイヤーで勝負が決まっているからです。

そのレイヤーが、外側です。kintoneというアプリの周囲に、長い時間をかけて積み上がってきた運用の生態系そのものが、競合が一朝一夕に真似できない厚みを形成している。moatを内側で探している限り、この厚みは視界に入りません。第4章で三層の外側に接続口があると置いたのは、この章のための伏線でした。内側の構造は単体でも優れていますが、その優れた内側が外側の生態系を引き寄せ続けたことで、内側と外側の往復運動がもうひとつの資産になっている。これがmoatの核です。

外側の第一層は、パートナーエコシステムです。kintoneを中心に、三つの役割を担う企業群が制度として整備されています。開発パートナー（現場の業務に合わせてアプリを組む）、プラグイン提供パートナー（標準機能では届かない領域を製品として補う）、システム連携パートナー（外部サービスとkintoneをつなぐ）。この三類型は、パートナーが成長するほど中心にあるkintoneの価値も増えるという相互強化の関係で設計されています。

注目すべきは、これが単なる代理店網ではなく、間接販売比率が高いこと自体がサイボウズの戦略になっている点です。自社で売り切るのではなく、パートナーが現場に入り、現場の業務知識を吸い上げてアプリを組み、運用を支える。サイボウズ本体は中心のkintoneを磨き続け、外周の実装と運用はエコシステム側が担う。この分業が効いているから、サイボウズは全国の業種・業態・規模にまたがる導入を、自社人員を爆発的に増やさずに支えられています。

プラグイン経済圏の層も見過ごせません。標準機能では細かすぎて拾えない業種特化の要件、たとえば建設業の原価計算、医療機関の予約管理、自治体の申請フォーム生成といった領域を、サードパーティのプラグイン製品が埋めています。現場は標準のkintoneに必要なプラグインを載せるだけで、自分の業種に最適化された運用を組み立てられる。中心が標準に徹し、周辺が特化を担うという役割分担が、kintoneを汎用性と具体性の両立という位置に押し上げています。

この構造を競合が模倣するには、プロダクトの機能をコピーするだけでは足りません。何百社ものパートナーが長年かけて積み上げた現場知識と実装ノウハウの層を、並行して作り直す必要がある。そして、その層が育つには、中心となるプロダクトが十分に普及し、パートナーが商売として成立する規模の市場が必要です。時間と市場規模、どちらも資本では縮められません。

外側の第二層はコミュニティです。ここが他社との差が最も露骨に出る領域で、サイボウズは三つの異なるコミュニティを並行して育ててきました。

ユーザーコミュニティ「キンコミ」は、kintoneを日常的に使う現場担当者が集まる場です。業種も規模も異なる実務者どうしが、自分のアプリ設計のコツや運用上の工夫を持ち寄る。ここで交換されているのは機能の使い方ではなく、業務の組み立て方そのものです。公式ドキュメントでは拾えないローカルな知恵が蓄積され、次の現場担当者がそれを参照して立ち上がる。

自治体向けの「ガブキン」は、自治体固有の事情にフォーカスしたコミュニティです。kintone導入自治体は1,000を超えており、制度対応のスピード、住民応対の効率化、部局横断の情報共有といった行政特有の論点が、自治体職員どうしのあいだで直接共有されています。民間企業のベストプラクティスをそのまま持ち込めない行政の世界で、同じ立場の人間が運用知を交換できる場所があるかどうかは、導入判断そのものを左右します。

大企業向けには「Enterprise Circle」が用意されています。大手20社が参加する招待制のコミュニティで、数千〜数万人規模の組織でkintoneを運用する際のガバナンス設計、市民開発と情報システム部門の役割分担、セキュリティとスピードの両立といった、規模固有の論点を持ち寄る場です。ここで共有されるのは、Microsoftのドキュメントや外資SaaSのベストプラクティスでは代替できない、日本の大企業組織の中でノーコード基盤をどう運用するかという経験知です。

コミュニティというと善意のボランティア集団のように聞こえますが、サイボウズの三つのコミュニティは制度として運営されている資産です。場の設計、運営者の配置、開催頻度の維持、アーカイブの整備。これらを十数年にわたって続けてきたことの累積が、いま新しい競合が同じ場を立ち上げようとしても数年では追いつけない時間差を生んでいます。機能は模倣できても、集まり続けている人の層は模倣できない。

外側の第三層は、ここ数年で急速に立ち上がってきたAI連携の層です。2025年8月にkintone MCPサーバーが正式リリースされ、外部のAIエージェントがkintoneのレコードを標準プロトコルで読み書きできるようになりました。続く2025年秋にはレコード一覧分析AI、kintone AIラボ（アプリ作成AI・検索AI・市民開発AI）が相次いで投入されています。パートナー側でもJAPAN AIをはじめとする外部AIサービスがkintoneを連携先として組み込み始めました。

この動きは、表面的には「AI機能を追加した」という話に見えます。しかし構造としてはもっと重要な交代が起きています。サイボウズはkintoneを、AIが叩く側のSystem of Recordに置き直したのです。

SaaS業界ではここ数年、AIに代替されるSaaSと代替されないSaaSという議論が繰り返されてきました。生成AIが人間の作業を直接代替できる領域では、SaaSは機能の価値を失い、AIがその作業自体を吸収してしまう。この代替圧力は確かに存在します。ただ、この議論が見落としているのは、AIが動くためにも、業務の事実を保持する基盤が必要だという点です。AIエージェントが受注状況を参照し、承認を進め、顧客とのやり取りを記録するとき、その背後には必ず「記録を持つ場所」が要ります。業務の事実が集まっている基盤が、AIの足場になる。

kintoneはまさにその基盤になる位置に立っています。三層統合によってデータ・プロセス・コミュニケーションが一枚の基盤に束ねられているので、AIエージェントから見ればkintoneを一つ叩くだけで、業務のほぼすべての情報にアクセスできる。MCPサーバーの正式対応は、このAIから叩かれるレールとしての位置づけを制度化した出来事です。

この位置は、AIが普及するほど価値が増える構造になっています。AIエージェントが業務に浸透するほど、「どこに業務の事実を置くか」という問いが中心に戻ってきます。バラバラのSaaSに散っていれば、AIはそれぞれと個別に連携しなければならない。kintoneに集まっていれば、一つのレールで済む。AIに代替されるSaaSの議論の裏側で、AIが叩く側として生き残るSaaSの条件が別に存在している。サイボウズは、その条件を満たすために早い段階から三層統合という形で基盤を設計し、いまMCP対応でレールを整えつつある会社です。

ここまで見てきたパートナー、コミュニティ、AI基盤という三つの外側は、それぞれ単体でもmoatとして働きます。ただ、サイボウズの強さはこの三つが重なって効くことにあります。

パートナーは現場の業務知識を実装に変え、コミュニティはその実装ノウハウを横展開し、AI基盤は集まったデータを次の時代の呼び出し先に変える。三つの外側が中心軸のkintoneを介して連動するので、それぞれの層の厚みが他の層の価値も押し上げる。新しい競合が一つの層を崩そうとしても、残り二つの層がkintoneを支える構造になっています。

この重層構造が日本市場で特に強く働く理由は、ローカルな運用知の非対称性にあります。回覧の作法、稟議の立て方、自治体固有の制度対応、大企業の市民開発ガバナンス。これらはグローバルSaaSが英語圏のベストプラクティスを翻訳して持ち込むだけでは埋まりません。日本の現場で運用され、日本のパートナーが実装し、日本のコミュニティで知見が蓄積されてきた層は、市場サイズの制約もあって外資の優先投資対象になりづらい領域です。市場が適度に大きく、かつグローバル標準化が届きにくいこの窓に、サイボウズは二十年かけて入り込んでいます。

第6章では、この外側のmoatを支えている内側の資産、すなわちサイボウズの企業文化を扱います。「100人100通り」「働き方宣言」「離職率28%→5%」といった文化の話は、しばしば美談として紹介されますが、本書ではそれをmoatを生み続ける運用の母体として読み直します。外側の生態系がなぜ二十年持続してきたのかは、最終的には内側の組織文化の話に戻ります。