なぜKintoneプラグインの多くは外部ポータル方式なのか
Kintoneのプラグイン市場を見ると、奇妙なことに気付きます。「Kintoneプラグイン」と呼ばれる製品のほとんどが、実はKintoneの中では完結しません。設定のために、別のWebサイト（各ベンダー固有のドメイン）へログインが必要です。なぜでしょうか。
これはベンダー側の「技術的な怠慢」ではありません。構造的な理由があります。この記事では、その理由と、逆にKintone内で完結させるアーキテクチャを選んだ場合に何が起きるかを整理します。
この記事の要点
Kintoneプラグイン市場の多くは、実は「Kintoneと連携する外部SaaS」です。設定には専用ポータルへのログインが必要で、ユーザー・権限・運用が二重になります。これはベンダーのビジネスモデルに起因しており、彼らが「ネイティブ化」しないのは、できないからではなく、するとビジネスが成立しなくなるからです。
実際に起きていること
まず事実確認から。Kintoneプラグインカテゴリで市場を広く見渡すと、以下のようなパターンで分かれます。
ネイティブプラグイン型
Kintoneの「プラグイン」機能を使って、Kintone内で完全に動作するタイプ。設定もKintoneの管理画面で完結します。代表的なのはCybozu Developer Networkで配布されている条件書式プラグインなど、機能が比較的シンプルなもの。独立系の個人開発者・小規模ベンダーが作ることが多く、スコープが限定的です。
外部ポータル型（連携サービス型）
Kintoneに薄いプラグインを入れますが、実際の処理・設定は外部Webサイトで行われます。ユーザーはKintoneと外部ポータルの両方にログインし、両方で設定を管理します。業界の主要な外部ポータル型サービスがこのパターンです。Kintoneプラグイン市場の売上シェアの大多数がこのタイプです。
JavaScript型（カスタム開発）
個別案件ごとにJavaScriptを書いてKintoneに注入するパターン。SIerやコンサルティング会社が提供することが多く、製品ではなく受託開発に近い形態です。
市場の収益の中心は2番目の外部ポータル型です。そしてこのカテゴリの有名プラグインの多くは、Kintone内で完結する作りではありません。
なぜ外部ポータル型が多いのか
「Kintoneの中で完結させればいいのに、なぜベンダーはそうしないのか」という問いに対する答えは、技術ではなくビジネスモデルにあります。
理由1. SaaSビジネスとして成立させるため
外部ポータルを持つことで、ベンダーは以下を実現できます。
- ユーザー単位での課金が可能：Kintoneの契約とは別に、ベンダー側のユーザーアカウントを管理できる。ユーザー数に応じた課金、アクセス制御、機能ゲーティングが実装しやすい。
- 使用量の可視化：誰が何回使ったか、どのAPIを叩いたか、どれだけデータ処理したか、を自社のダッシュボードで直接見られる。これがないとプランのグレード分けや従量課金が困難。
- リテンション指標の取得：DAU（日次アクティブユーザー）、MAU（月次アクティブユーザー）、機能別利用率、アップセル可能なシグナルの抽出。SaaS型ビジネスの健全性を計るためのデータが取れる。
- アップセル導線の設置：外部ポータルにログインさせることで、「上位プランに移行しませんか？」「新機能を試しませんか？」といった誘導が自然に可能。
Kintone内で完結するアーキテクチャを取ると、これらが全部できません。ベンダーは、ユーザーが何を設定しているか、どれだけ使っているかを、全く知ることができなくなります。それは、SaaS型ビジネスとしての指標が取れないということです。
理由2. Kintone APIレート制限を避けるため
Kintoneには、サブドメイン単位でAPIレート制限があります。重い処理（大量データ処理、帳票生成、メール送信等）をすべてKintone APIから呼ぶと、他のアプリの動作にも影響します。外部ポータル型は、処理の大部分をベンダー側のサーバーで実行することで、この制限を回避できます。
理由3. 複雑なロジックの実装しやすさ
Kintoneプラグインで書けるJavaScriptには、実行環境の制約（CORS、CSP、実行時間等）があります。複雑なPDF生成、画像処理、外部API呼び出し、ロングランニングタスクは、Kintone内では難しい。サーバー側で処理すれば、これらの制約を避けられます。
外部ポータル型の代償
ベンダー側のビジネスモデル上の利点は理解できます。ただし、それを選んだ瞬間、ユーザー側には具体的な負担が発生します。
管理画面が二重化する
Kintoneの管理画面と、ベンダーの外部ポータルの、両方を覚える必要があります。ユーザー管理、権限管理、設定変更を、それぞれのシステムで行います。ユーザーが退職した場合、両方から削除する必要があります。これを忘れると、退職者がベンダー側のポータルから情報にアクセスし続けるリスクが残ります。
ユーザー認証が二重化する
多くの外部ポータル型プラグインは、ユーザーが外部ポータルに別途アカウントを作ることを要求します。Kintoneはサイボウズ製のSAML統合が使えるのに、外部ポータルは独自の認証を持つため、パスワード管理が複雑になり、SSOの一貫性が崩れます。
データの越境が発生する
Kintone上のデータの一部が、処理のためにベンダーのサーバーに送られます。これは多くの場合、利用規約では「必要な処理のため」と正当化されますが、金融・医療・公共機関のセキュリティ監査では、データの越境ルートとして明示する必要があります。結果として、稟議プロセスが重くなり、導入判断が遅れます。
ベンダー依存が発生する
外部ポータルが停止すると、プラグインが動かなくなります。たとえKintoneが正常に動作していても、ベンダー側のインフラ障害で、社内の業務が止まります。ベンダーの事業継続が、自社の業務継続と直結します。
IP制限環境で導入が困難になる
金融・保険・医療・公共機関では、Kintone環境自体がIP制限下にあることが多いです。外部ポータルとの通信を許可するには、ベンダー側のIPレンジをホワイトリスト化する必要があり、これがベンダー変更時（または DR時）に運用の複雑性を生みます。
それでも外部ポータルが選ばれる理由
上記の代償は、実はユーザーにとって大きな痛みです。ではなぜ、市場は外部ポータル型が支配的なのか。
代替がなかった
2015年～2020年頃、Kintoneプラグイン市場が形成された時期、主要ベンダーは全員SaaS型のビジネスを目指していました。ネイティブプラグイン型を真剣に追求したベンダーが少なかったため、ユーザーは「外部ポータル型しか選択肢がない」状況が長く続きました。
機能面で差がつきやすい
外部ポータル型は、サーバー側で自由にロジックが書けるため、複雑な機能を実装しやすい。結果として、機能比較表ではネイティブ型より見栄えが良くなります。ユーザーが最初に機能面で選ぶと、アーキテクチャ面の代償を見逃しがちです。
導入時には問題が顕在化しない
外部ポータルへのログイン、ユーザー管理の二重化、データ越境といった問題は、導入後しばらく経たないと実感しない種類の問題です。契約時点では「Kintoneをもっと便利にする機能」しか目に入らず、代償は見えません。
ネイティブプラグインを本気で追求するとどうなるか
kinplugが選んだアーキテクチャはネイティブプラグイン型です。これを選ぶと、ベンダー側に以下の制約が発生します。
- ユーザー単位課金ができない → サブドメイン単位のフラットレート課金になる
- 使用量計測が直接できない → プランを「使い放題」で設計せざるを得ない
- アップセル導線が作れない → 営業による営業をあきらめる必要がある
- リテンション指標が取れない → 代わりに、契約更新率とサポートチケット内容で健全性を判断する
これは事実上、一般的なSaaS企業のプレイブックを使わない、という選択です。収益構造が変わるので、会社としての成長の仕方も変わります。具体的には、「大量の顧客に少しずつ課金する」モデルになります。ユーザー数で料金を積み上げる従来型SaaSと違い、サブドメイン単位の定額制になるため、単価は大きく伸びません。代わりに、顧客の負担感は劇的に低いので、解約率と紹介率で勝負することになります。
私たちが意図的にこの道を選んでいる理由は、Kintoneコンサルタントとしての現場経験から、外部ポータル型の代償がユーザーにとって大きすぎると判断したからです。これが、他社ができないのではなく、他社がビジネスモデル上選べない道だという認識です。
ユーザー側の判断基準
プラグインを選定する際、アーキテクチャ面で確認すべきポイント：
- 設定は完全にKintone内で完結するか？（外部ポータルへのログインを一度も求められないか）
- ユーザー管理は Kintoneの権限体系だけで済むか？（ベンダー側で別途アカウント作成が必要ないか）
- データがベンダーのサーバーを経由するか？（経由する場合、その範囲と理由は明記されているか）
- ベンダーの事業停止時の影響は？（プラグインはその後も使えるか、ソースコードのオープン化等の約束があるか）
- IP制限環境への対応は？（ホワイトリストに追加すべきドメインは明記されているか）
これらを最初に確認すると、アーキテクチャ面での選択が明確になります。機能比較表だけでは見えない部分が、後から運用負担として効いてきます。
結論
Kintoneプラグイン市場が「外部ポータル型」に傾いているのは、ベンダー側のビジネスモデルの都合です。ユーザー側にとっては、この構造は運用負担・セキュリティ監査・ベンダー依存といった代償を伴います。
ネイティブプラグイン型を選ぶと、ベンダーの成長戦略は変わり、顧客単価の伸ばし方が変わります。これを意図的に選ぶ会社が出てきた、というのが、現在のKintoneプラグイン市場で起きている小さな構造変化です。