戦略をソースで売るのはリスクが高く、ホスト型サービスとして売るのは重い。売り手がライセンスの範囲を決められるコンパイル済みバイナリとして売る道こそ、PineForge が計画するマーケットプレイスの設計の軸です。そこに至るまでの設計の探求をまとめます。
2026-09-30 時点の状況：この記事は設計の探求です。ここで扱うマーケットプレイス、ライセンスサーバー、売り手向けツールは計画段階で、まだ構築されておらず、リリース日も決まっていません。その土台となるエンジンとトランスパイラは、すでに存在します。
戦略の作者は、ソースを渡さずに収益化したいと考えます。購入者は、自分のデータでバックテストし、自分のブローカーで運用したいと考えます。この二つの要件は本質的に相反しており、現在ある解決策の多くは、その対立をうまく解消できていません。この記事では、PineForge のマーケットプレイスの土台としてコンパイル済みバイナリのライセンスに落ち着くまでに、私たちが探った設計空間を紹介します。
問題を平たく言うと
ある戦略の作者が、うまく機能するものを作り上げたとします。何か月もかけてパラメータを調整し、エッジケースを直し、アウトオブサンプルでも検証しました。作者はそれを売りたい。一方、購入者はそれを自分のデータで動かし、作者の言うとおりのバックテスト結果になるかを検証し、自分の執行パイプラインに組み込みたいと考えます。
作者がソースコードを渡した瞬間、収益化は終わります。購入者はそれを無期限に動かし、自由に改変し、他人に転売できます。作者が手にするのは、ちょうど一回分の売上だけです。その後に現れる購入者は、みな取り逃した見込み客になります。
逆に作者がソースコードを手元に留めた瞬間、購入者は戦略を検証することも、調整することも、信頼することもできなくなります。ブラックボックスを購読しているのと同じです。作者のサーバーが止まれば、購入者の取引も止まります。
この問題を切り抜けようとする一般的な解決策が二つあります。どちらにも、よく知られた失敗パターンがあります。
パターン1：ソースを売る
作者は Pine スクリプトそのものを販売します。購入者は一回の購入で .pine ファイルを受け取ります。
購入者にとっての利点は本物です。すべてにアクセスでき、すべてを検証でき、すべてを自分で制御できます。どんなデータでもバックテストでき、パラメータを調整でき、売り手に頼らずいつまでも運用できます。
売り手にとっての欠点も、同じく本物です。いったんソースを渡してしまえば、売り手には継続的な交渉力が残りません。海賊版への備えは、購入者の善意の強さに頼るしかありません。戦略は他のプラットフォームに再出品されることも、改変されて派生物として売られることも、単に無料で共有されることもありえます。収益は、正直に初めて買ってくれる購入者の数で頭打ちになります。
このモデルは、継続的な収益よりシンプルさを重視する作者には向いています。一方、戦略に本当に価値があり、それを何年にもわたって守りたい作者には向きません。
パターン2：シグナルを売る
作者は自分で戦略を動かし、エントリー、エグジット、ポジションサイズといったシグナルを、購読者が受け取るフィードに配信します。ソースが作者の管理下から出ることはありません。
売り手にとっての利点は、ソースを完全に守れること、継続的な購読収益が得られること、そしてすべての価値を一度に手放すような取引がないことです。
購入者にとっての欠点は深刻です。自分のデータで戦略をバックテストできません。作者が主張する過去のパフォーマンスを信じるしかありません。作者のインフラに全面的に依存するので、作者が休暇に出たり、サーバー障害が起きたり、サービスをやめると決めたりすれば、購入者の手元には何も残りません。パラメータも調整できず、作者が設定したものを受け取るだけです。
シグナルサービスは、自分で戦略を動かす技術力を持たない購入者には向いています。しかし、自分が何を動かしているのかを理解し、独立して検証したい技術系の購入者にとっては、このモデルは最初から選択肢になりません。
パターン3：コンパイル済みバイナリを売る
三つ目のパターンが、PineForge が計画しているマーケットプレイスの設計の中心です。Pine 戦略を共有ライブラリ（Linux では .so、macOS では .dylib）にコンパイルします。作者が配布するのはソースではなくバイナリです。購入者はオープンソースの PineForge ランタイムを通じて、自分のマシン上で自分の OHLCV データに対してバイナリを実行します。
これで、対立する双方の要求に応えられます。
作者にとって： ソースが作者のマシンから出ることはありません。バイナリは作者の Pine スクリプトからコンパイルされますが、コンパイル済みの .so を読める Pine に戻すには相当な労力が必要です。仮に戻せたとしても、得られるのはアセンブリレベルの出力で、Pine らしいコードではありません。戦略の中核ロジックは実質的に守られます。
購入者にとって： バックテストは自分のデータを使ってローカルで実行されます。執行には自分のブローカー連携を使います。ランタイムはオープンソースなので監査できます。セキュリティを重視する購入者は、戦略そのものは読めなくても、自分のお金を動かすコードは読めます。バックテストそのものが売り手のサーバーに依存することもありません。
このパターンは PineForge が初めて考えたものではありません。MetaTrader のエコシステムは、2011 年に MetaQuotes が MQL5 Market を開設して以来、この方式で動いています。MetaTrader の戦略は .ex4 または .ex5 のバイナリにコンパイルされます。Market で購入したものは購入者のコンピューターに紐付けられ、アクティベーションできる回数は売り手が設定します。売り手は商品をレンタルで提供することもできます。購入者は MetaTrader のストラテジーテスターでローカルにバックテストし、ソースは開発者の手元に残ります。実績のあるモデルです。
私たちは同じやり方を Pine に当てはめ、二つの点を加えます。一つはライセンスの調整項目をより細かくすること（後述）、もう一つはランタイムをオープンソースにして、自分の取引を執行する部分を誰でも監査できるようにすることです。
ライセンスの次元
ライセンスの枠組みを持たないコンパイル済みバイナリは、誰でもコピーできるただのファイルです。ビジネスモデルを成り立たせているのは、ライセンスの層です。
この設計には、六つのライセンス次元があります。
期間制限。 ライセンスには有効期限があり、購入から数日、数週間、あるいは数か月で切れます。ライセンスが切れると、バイナリは戦略を実行しなくなります。購入者は更新でき、売り手は継続的な収益を得られます。最も一般的な次元で、マーケットプレイスのほぼすべての戦略がこれを使うことになるでしょう。
マシン紐付け。 ライセンスはハードウェアのフィンガープリントに紐付きます。購入者は登録したマシンでは戦略を実行できますが、2 台目のマシンやクラウドインスタンスでは実行できません。受け取った側のマシンには有効なライセンスがないので、バイナリを共有する意味が薄れます。気軽な共有よりも大規模な海賊版を懸念する売り手は、この次元を有効にできます。
ブローカー紐付け。 ライセンスで、戦略が執行に使ってよいブローカー連携を指定します。特定のブローカー API と提携している売り手は、執行をそれらの連携に限定でき、サポート外の執行先や望ましくない執行先で戦略が使われるのを防げます。
シンボル紐付け。 ライセンスで、戦略が取引できるティッカーシンボルを制限します。BTC/USDT で戦略を構築・検証した作者は、そのシンボルだけを許可するライセンスを配布できます。これにより、ある資産向けに最適化された戦略を購入者がまったく別の資産で使い、予想外の結果になって作者のせいにする、という事態を防げます。
入力範囲の制限。 購入者は戦略のパラメータを調整できますが、売り手が許可した範囲内に限られます。たとえばルックバック期間のパラメータを持つ戦略なら、10〜50 バーの範囲では設定できても、10 未満（作者がひどく過剰適合すると分かっている領域）や 50 超（意味をなさなくなる領域）には設定できない、といった具合です。範囲は売り手が公開し、ランタイムがそれを強制します。
失効可能。 ライセンスサーバーは、次回の定期ライセンスチェックで 403 を返すことができ、その時点でバイナリは実行を停止します。購入者がバイナリの共有や未許可のハードウェアでの実行といった規約違反をしていると分かれば、作者は返金や法的手続きを経ずにライセンスを失効させられます。失効は最後の切り札であり、売り手は明確な違反の場合にだけ使うべきです。
あえてやらないこと
DRM 風の難読化という見せかけはやらない。 .so は本物のコンパイル済みバイナリです。十分な時間と適切なツールがあれば、熟練したエンジニアはそのロジックをリバースエンジニアリングできます。それを否定するつもりはありません。契約となるのはライセンスであって、バイナリ形式ではありません。保護は、購入者が同意した規約とランタイムによるライセンスの強制から生まれるもので、逆アセンブルが不可能だからではありません。バイナリが破られないふりをするのは不誠実です。
バックテストのたびにサーバーへ問い合わせることはしない。 ライセンスチェックは定期的に行うもので、呼び出しごとではありません。ランタイムは有効なライセンスをローカルにキャッシュし、スケジュールに従ってライセンスサーバーを確認します（間隔はライセンスごとに設定でき、デフォルトは 1 日 1 回）。ライセンスの有効期間中は、オフラインでもバックテストできます。バーを計算するたびにサーバーへ問い合わせることもしません。そうするとバックテストがネットワークの状態に左右され、実質的なセキュリティ上の利点もないまま遅延が増えるだけです。ライセンスチェックを 1 回傍受できる攻撃者なら、100 回でも傍受できます。
後出しの収益配分はしない。 マーケットプレイスの手数料率は固定のパーセンテージで、ローンチ前に公表します。ウェイトリストに登録した売り手は、出品する前に条件を知ることができます。商品が公開されてから初めて手数料体系を明かすマーケットプレイスも見てきましたが、私たちはそれを不誠実だと考えており、そうするつもりはありません。
まだ検討中の未解決の問い
ライセンスキーの漏洩。 購入者のマシンが侵害され、ライセンスキーが抜き取られたらどうなるでしょうか。選択肢は二つあります。(a) キーを失効させて正当な購入者に再発行する。ただし利用者に支障が出ます。(b) 購入者ごとのキーローテーション方式を維持し、マシンのインスタンスごとに異なる派生キーを持たせることで、1 台のマシンが侵害されてもすべての購入者には波及しないようにする。私たちは (b) に傾いていますが、実装には簡単ではない鍵管理の要件が伴います。
範囲とあわせて、売り手が入力のデフォルト値も定められるようにするか。 入力範囲の制限により、売り手は各パラメータの上下限を公開できます。では、購入者が最初に戦略を設定するときに表示される初期値、つまりデフォルト値も売り手が公開できるべきでしょうか。おそらく答えはイエスです。ルックバックが 20 バーのときに最もよく機能すると分かっている売り手が、それを購入者に試行錯誤で見つけさせる理由はありません。デフォルト値はあくまで推奨で、強制はしません。
売り手が公開する「デモバックテスト」レポート。 購入者は購入前に、売り手の主張だけでなく、戦略が機能するという証拠を確認できるべきです。現在の計画では、売り手が自分のデータと OHLCV の期間を使って、ギャラリー形式のバックテストレポート（/gallery のギャラリーと同じスキーマ）を公開できるようにします。そのレポートは、記載された入力で PineForge エンジンが生成したものであることが検証されます。購入者が目にするのはマーケティング用のスクリーンショットではなく、本物のトレード一覧、本物のシャープレシオ、本物のスパークラインです。「買う前に見られる」を誠実に実現したものです。
オープンコアとの整合
コンパイル済みバイナリのマーケットプレイスには、懸念が一つあります。購入者の資金の安全が、バイナリを実行する部分に全面的に依存することです。しかも、その実行部はほとんどの実装でプロプライエタリなブラックボックスです。MetaTrader で .ex5 ファイルを動かすなら、MetaQuotes のランタイムと、開示されていない挙動を実行しないという同社の保証を信じることになります。
PineForge のエンジンは Apache-2.0 ライセンスで公開されています（pineforge-engine。エンジンとトランスパイラを同梱した Docker イメージは ghcr.io/pineforge-4pass/pineforge-release）。トランスパイラ（Pine を C++ にコンパイルする部分）は、個人のトレードには無料で使えますが、商用利用にはライセンスが必要です。実行部、つまりコンパイル済みバイナリを実際に OHLCV に対して動かしてトレード一覧を出力するコードは、オープンソースです。
つまり、セキュリティを重視する購入者は、バックテストを任せる前に実行部を監査できます。戦略のソースは監査できませんが（それこそが狙いです）、それを動かすコードは監査できます。この分け方は意図的なものです。戦略を動かす部分はオープンにし、トランスパイラは商用利用についてライセンスを設けます。
マーケットプレイスの現状
日程は決まっていません。エンジンとトランスパイラはすでにありますが、ライセンスサーバー、売り手向けダッシュボード、購入者向けの購入フローはまだありません。
計画では、まず売り手のオンボーディングを手作業で行うベータ版から始めます。審査を通った少人数の作者を対象に、出品内容はチームがレビューし、カタログを限定して、規模を広げる前に連携上の問題を洗い出します。その後にセルフサービス型のマーケットプレイスが続く想定で、売り手は自分で出品し、ライセンスの次元を設定し、デモバックテストのレポートを公開し、チームの手を借りずにカタログを管理できるようになります。
次のステップ
- 売り手のウェイトリストに登録する — 出品したい戦略を作っているなら、ウェイトリストに登録してください。ベータのオンボーディングが始まったらご連絡します。
- 今すぐランタイムを試す：MCP サーバーの
backtest_pineは、マーケットプレイスの戦略が動く予定のエンジンと同じものを実行します。 - パリティの測り方：TradingView と比べたエンジンの最新の結果。