OSSはどこまで無料にすべきか：オープンコアの設計図とPapillonの仮説

前回の記事では、ElasticとAWSの対立、RedisからValkeyへの分岐、TerraformからOpenTofuが生まれた経緯を通して、クラウド時代のOSSビジネスが抱える問題を紹介しました。

しかし、ライセンスをAGPLにすれば問題が解決するわけではありません。実際の製品開発では、さらに難しい問いが残ります。

何をOSSとして公開し、何を有償機能として販売するのか。

OSS版に機能を出しすぎれば、有償版を買う理由がなくなるかもしれません。反対に、価値のある機能をすべて有償版へ移せば、OSS版は単なるデモになり、利用者もコントリビューターも増えません。

本記事では、Elastic、Confluent、Grafanaが境界線をどこに引いたのかを比較し、現在開発中のBIツール「Papillon」でどのような線を引くべきか、私たちの現時点の仮説を公開します。

なお、記載内容は2026年8月5日時点の公開情報と開発中のコードに基づきます。Papillonの製品区分とライセンス設計は確定版ではなく、今後変更する可能性があります。本記事は法的助言ではありません。

オープンコアの境界は「機能」だけではない

オープンコアというと、「基本機能は無料、高度な機能は有料」という説明がよく使われます。しかし、実際の境界はもう少し複雑です。

製品を次の5層に分けると、各社の違いが見えやすくなります。

コア：製品が解決する中心的な課題
周辺機能：コアを実務で使いやすくする接続・変換・拡張
組織運用：認証、権限、監査、ガバナンス、レポート
ホスティング：インフラ運用、可用性、バックアップ、アップグレード
サポート：SLA、問い合わせ、導入支援、長期保守

どの層までを公開するかによって、OSS版が生む価値も、企業が対価を払う理由も変わります。

Elastic、Confluent、Grafana、Papillonのオープンコア境界比較

失敗しやすい二つの極端

境界線には、分かりやすい二つの失敗があります。

OSS版をデモにしてしまう

保存件数、ユーザー数、データ量などを厳しく制限し、実際の業務では使えない状態にすると、OSS版は製品ではなく体験版になります。

利用者は問題を解決できないため、定着する前に離脱します。開発者も、自分が利用しない製品へ継続的に貢献しにくくなります。オープンコアの入口は広く見えても、コミュニティが育つ土台がありません。

すべてを公開し、善意の還元に依存する

反対に、コア、組織運用、ホスティング自動化まで寛容なライセンスで公開すると、第三者がそのまま競合サービスを作れます。

それ自体はライセンスが認めた自由です。しかし、開発企業が「利用者が増えれば、自然にコードや売上が還元される」と期待していた場合、前回紹介したElasticとAWSのような衝突につながります。

重要なのは、無料と有料の割合ではありません。OSSだけで誰の課題を最後まで解決するのか。そして、有料版は別の誰の課題を解決するのかを定義することです。

Elastic：コアは無料、高度なデータ活用と運用で課金する

Elasticの中心価値は、データの検索・分析です。ElasticsearchとKibanaを外せば製品そのものが成立しないため、このコアを単なる制限版にはできません。

現在Elasticは、Elasticsearch、Kibana、データ取り込み、基本的な認証・RBAC・TLSなどを無償で利用できる領域として提供しています。無料部分のソースコードには、AGPLv3、SSPL、Elastic License 2.0から選べる部分があります。

一方、企業向けのサブスクリプションでは、次のような機能と価値を提供しています。

高度なAI・機械学習機能
オブジェクトストレージを活用するSearchable Snapshots
高度なクロスクラスター機能
セキュリティ・コンプライアンス機能
公式サポート
Elastic Cloudによるマネージド運用

Elasticの境界は、単純な「検索できる／できない」ではありません。検索という中心価値は無料で成立させ、規模・保存コスト・高度分析・組織運用の課題で課金する設計です。

ただしElasticは、ライセンス自体でもクラウド事業者による再サービス化を防ごうとしました。機能境界とライセンス境界の両方を使う、比較的強い防衛型です。

Confluent：所有できないコアの周囲に価値を積む

Confluentは、Kafkaの開発者たちが設立した企業です。しかしApache KafkaはApache Software Foundationのプロジェクトであり、Confluentが単独でライセンスを変更したり、有償化したりすることはできません。

そのため、Confluentの製品は三つの層に分かれています。

Apache-2.0のコア

Kafka本体、Kafka Connect、Kafka Streams、クライアントなどはApache-2.0です。誰でも利用、改変、再配布、サービス化できます。

Community Licenseの周辺

Schema Registry、REST Proxy、ksqlDB、一部のConnectorなどはConfluent Community Licenseです。ソースは公開されていますが、競合するマネージドサービスとしての提供が制限されるため、OSIが定義するOSSではありません。

Enterpriseの組織運用

有償領域には、商用・プレミアムConnector、Control Center、RBAC、監査ログ、Tiered Storage、Multi-Region Cluster、Cluster Linkingなどがあります。Confluent Cloudでは、さらにインフラ運用、プライベートネットワーク、暗号鍵管理、スケーリングをサービスとして提供します。

Confluentの面白さは、コアを閉じられない制約が、周辺と運用へ投資するビジネスを生んだことです。

AWSはAmazon MSKとしてKafkaをサービス化できます。しかし、ConfluentはKafka単体では解決しないデータ契約、接続、ガバナンス、複数リージョン運用を商品にできます。

この型では、OSSコアを守るのではなく、コアの周囲で発生する複雑さを解消することが収益になります。

Grafana：個人の達成をOSS、組織の不安をEnterpriseへ

Grafanaの境界は非常に分かりやすく、Papillonの参考になります。

Grafana OSSだけで、ダッシュボードの作成、可視化、アラート、データソース接続という中心的な仕事を完了できます。ユーザー数を増やさなければ保存できない、というような体験版ではありません。

一方、Grafana Enterpriseは次のような組織運用機能を追加します。

SAMLなどの企業向け認証
きめ細かなRBACとデータソース権限
監査ログ
PDFレポートとスケジュール配信
クエリキャッシュ
Vault連携
利用状況の分析
Premiumデータソース
24時間365日の公式サポート

Grafana Cloudでは、これらに加えて、メトリクス、ログ、トレースなどの可観測性基盤自体をマネージドサービスとして提供します。

つまり、Grafanaは「グラフを作れるか」を有料境界にせず、「組織で安全・継続的に運用できるか」を境界に置いています。

個人の利用者はOSSだけで成功できます。組織は、利用者が増えたときに発生する認証、統制、監査、運用のコストを減らすために対価を払います。無料版と有料版が同じ顧客を奪い合わず、異なる規模の課題を解決しています。

三社を比較すると見える三つの型

三社の境界を要約すると、次のようになります。

企業	OSS・無料で完結する価値	有償化する価値	境界の特徴
Elastic	検索、可視化、取り込み、基本セキュリティ	高度分析、低コスト保存、組織運用、Cloud、サポート	コアを開きつつライセンスでも防衛
Confluent	Kafkaによるストリーム処理	周辺機能、ガバナンス、複数拠点運用、Cloud	所有できないコアの周囲で収益化
Grafana	ダッシュボード、可視化、アラート	SSO、RBAC、監査、レポート、Cloud、サポート	個人の達成と組織の運用で分離

ここから得られる原則は、中心的なジョブを途中で分断しないことです。

検索ツールなら検索結果を得られるところまで、ストリーム基盤ならイベントを流せるところまで、BIならデータからダッシュボードを作れるところまでをOSSで完結させる。その後に発生する組織固有の複雑さを有償領域に置くと、境界を説明しやすくなります。

Papillonの仮説：「分析」と「組織運用」の間に線を引く

Papillonは、SQLワークスペース、Text-to-SQL、ダッシュボード、Data Prepを備えた、開発中のAI搭載BIツールです。

私たちが現在考えている境界は、Grafana型に近いものです。

OSSで完結させたい個人の分析

データベースへの接続
SQLの作成・実行・履歴・保存
Text-to-SQL
ダッシュボードとチャートの作成
フィルター、ドリルダウン、パラメータ
Data Prep
セマンティックモデルとビジュアルSQL
ローカルでのデータ・メタデータ管理

ここを有料化すると、Papillonの価値を理解する前に利用者が行き止まりになります。AI機能も体験版の呼び水ではなく、分析ワークフローの一部としてOSSコアに置く方針です。

有償価値にしたい組織の運用

組織アカウントとメンバー管理
SSO / OIDC
ダッシュボードの共有とブラウザ閲覧
高度なアクセス制御
監査ログ
データガバナンス
定期レポートと通知
組織単位のキャッシュ・運用最適化
導入支援とサポート

一人で分析する段階では不要でも、利用者が増えると必須になる機能です。Enterprise版は分析能力を解放する鍵ではなく、分析結果を安全に組織へ届け続けるための仕組みと位置づけます。

しかし、現行コードはこの境界になっていない

ここからがBuild in Publicとして重要な部分です。

PapillonのCOMMERCIAL-LICENSE.mdでは、SSO / OIDC、ダッシュボード共有、監査ログ、ガバナンス制御をEnterprise機能として記載しています。

しかし2026年8月5日時点のコードでは、それらの実装の多くがAGPLのpapillon-serverやpapillon-coreにあります。

SSO / OIDCの認証フローは組織サーバー側に実装済み
共有リンク、期限、パスワード、失効、埋め込みも組織サーバー側にある
ブラウザビューアはAGPLのアプリとして実装されている
サーバー監査ログは通常ビルドでも記録される
行レベルポリシーのコアロジックもOSS側にある
レポートのスケジュール、メール、Slack通知もOSS側にある

一方、商用ライセンスを検証してサーバー機能を切り替える仕組みは、まだ完成していません。

つまり、ドキュメント上の境界と、コード上の境界が一致していない状態です。

これは隠すべき失敗というより、製品仮説を実装しながら境界を探している初期プロジェクトの現実です。まず一連の機能を動かし、価値と依存関係を理解してから、どこを共通基盤とし、どこを商用コンポーネントとして分離するかを決める必要があります。

ただし、公開後に境界を変えれば利用者の期待に影響します。前回の記事で紹介した事例を繰り返さないためにも、正式リリース前に設計と実装を揃える必要があります。

簡単に線を引けない四つのグレーゾーン

Papillonでは、特に次の機能が明確に分類できていません。

1. 共有リンク

ダッシュボードをZIPで渡す機能は個人間でも使えます。では、期限・パスワード付きのURLで共有する機能はEnterpriseでしょうか。

単純な共有をOSSに残し、組織ポリシー、失効管理、監査、埋め込み先制限を有償にする方法もあります。しかし機能を細かく切りすぎると、利用者にとって分かりにくい製品になります。

2. ブラウザビューア

閲覧画面自体はOSSにし、認証・配置・運用をEnterpriseにする考え方があります。Grafanaと同様に、「見る」ことではなく「誰に、どの権限で、安全に見せるか」で課金する設計です。

一方、ブラウザ閲覧にはサーバー運用が必須です。セルフホスト可能なAGPLサーバーと、公式マネージドサービスを併存させる方法も検討できます。

3. 行レベルセキュリティ

RLSは企業向けのガバナンス機能に見えます。しかし、OSS版から完全に除くと、小規模チームでも本番データを安全に共有できません。

ポリシー適用の基本エンジンはOSSに残し、組織横断の管理UI、承認フロー、監査、ポリシーテンプレートをEnterpriseにする境界が考えられます。

なお、現在のPapillonでは行フィルターは部分実装で、列制限と管理UIは未完成です。現時点で完成したガバナンス製品として提供しているわけではありません。

4. 定期レポートと通知

個人がローカルでCSVを定期出力する機能と、組織サーバーが複数の宛先へメールやSlackで配信する機能では、運用責任が異なります。

ローカル実行をOSS、サーバー配信、履歴、失敗時の再送、監査、SLAをEnterpriseまたはCloudへ置くと、境界を説明しやすくなります。

「セキュリティを有料にする」ことへの違和感

Enterprise機能としてSSO、RBAC、監査、RLSを挙げると、「安全に使うための機能を有料にするのか」という疑問が生じます。

ここでは、最低限の安全性と、組織の統制を分ける必要があります。

読み取り専用クエリ、秘密情報の安全な保存、基本的な認証などは、OSSでも欠かせない
複数IdP、きめ細かな権限、監査証跡の長期保存、承認フローなどは、組織運用のコストを解決する

OSS版を意図的に危険にして有償版へ誘導してはいけません。有償版が売るのはセキュリティそのものではなく、組織固有のルールを継続的に適用・証明する能力です。

機能名ではなく、責任の移動で境界を決める

比較を通して、機能名だけでOSSとEnterpriseを分類する方法には限界があると分かりました。

同じ「共有」でも、ファイルを書き出すだけなら利用者の責任です。公開URLを継続運用し、認証、失効、監査、障害対応まで担うなら、製品側の責任が増えます。

同じ「レポート」でも、ローカルで生成するだけなら単機能です。数百の組織へ定刻に配信し、失敗を検知し、再送し、証跡を残すならサービスです。

したがって、Papillonでは次の原則が使えそうです。

OSSは、個人が自分の責任で分析を完了できるところまで。EnterpriseとCloudは、組織に代わって継続運用の責任を引き受けるところから。

この原則なら、単に人気機能を有料にするのではなく、開発・運用・サポートコストと価格を結びつけられます。

現時点の境界案

以上を踏まえたPapillonの境界案は次のとおりです。

OSS（AGPL）	Enterprise / Cloud	まだ検証する領域
SQL、Text-to-SQL、可視化、Data Prep	SSO、組織・メンバー管理	共有リンクの基本機能
ローカルダッシュボード	高度なRBAC、監査、承認	ブラウザビューア
セマンティックモデル	組織ポリシー管理	RLSの基本エンジン
ファイルによるExport / Import	管理された共有・埋め込み	ローカルスケジュール
基本的な安全性	配信運用、SLA、公式サポート	セルフホスト組織サーバー

これは決定事項ではありません。実際の利用者が、どの段階で何に困り、何の運用責任をConvergence Lab.へ任せたいと考えるかによって更新します。

まとめ

オープンコアの境界線は、無料版に何個の機能を入れるかという問題ではありません。

Elasticは検索を無料で成立させ、高度な分析と規模の課題を有償化しました。Confluentは自由なKafkaコアの周囲に接続・ガバナンス・運用を積みました。Grafanaは個人の可視化をOSSで完結させ、組織の不安を解決する機能をEnterpriseへ置きました。

Papillonも、SQLやAI、ダッシュボード作成を体験版にせず、個人の分析をOSSで完結させたいと考えています。そのうえで、組織が分析結果を安全に共有し、継続的に運用する責任をEnterpriseとCloudで引き受ける。この線が現在の仮説です。

そして現行コードは、まだその仮説どおりには分かれていません。だからこそ、完成した戦略として発表するのではなく、境界を決める過程そのものを公開します。

「この機能はOSSに残すべき」「ここまで運用してくれるなら有償でも使いたい」といった意見があれば、ぜひお聞かせください。利用者にとって納得でき、開発も継続できる境界を探していきます。