空のブログは正直である。出す予定のもの——Pineの意味論、トランスパイラ設計、パリティ級バックテストのエンジニアリング深掘り——と、雑に書くより待つ理由。
この記事の数値は2026年5月7日に計測したもので、当時のまま掲載しています。最新の結果はパリティの測定方法をご覧ください。
この記事を書いた時点では、このブログはあえて空にしていました。
2026年5月当時、PineForge チームはエンジンの開発に没頭していました。パリティ・スイープの対象は 162 本の戦略で、そのうち 158 本がトレード単位の厳密な一致を達成しており、codegen も当時は無料のホスト型 API として提供していました。先にマーケティングサイトを立ち上げ、記事はその後、という順番でした。
これから書くこと
エンジニアリング記事がいくつか控えています。雰囲気だけの記事を出すより、再現できる CSV、並べて比べられるトレース、実際に動くコードといった具体的な成果物を添えて、一本ずつ公開したいと考えています。おおまかなロードマップは次のとおりです。
-
トランスパイラのアーキテクチャ。 Pine v6 の lexer / parser / analyzer が C++ codegen にどうつながっているのか、なぜインタプリタではなく AOT コンパイルを選んだのか、そしてトランスパイラがどこで終わり、Apache-2.0 のランタイムがどこから始まるのか。
-
ひとつの専門分野としてのパリティ・エンジニアリング。 TradingView とトレード単位で一致させるには、実際に何が必要なのか。インフラ（CI スイープ、比較ハーネス）、コーパスの設計、そして二つのエンジンの結果がちょうどバー 1 本分だけ食い違ったときに使う方法論について。
-
コンパイル済みバイナリとしての戦略。 マーケットプレイスの構想（計画中、時期は未定）。売り手が定めたライセンス条件付きの
.soが、JSON でエンコードしたシグナルフィードより優れた配布モデルである理由と、バックテストのたびにサーバーへ問い合わせることなく、ランタイムでライセンスを確認する仕組みをどう作るかについて。 -
Optuna とウォークフォワードの統合。 計画中、時期は未定。オプティマイザが、UI で組み立てるフィットネス用スライダーではなく、Python の lambda 目的関数を受け取る設計にする理由と、すべての最適化の実行にアウトオブサンプル検証をどう組み込むかについて。
それまでのあいだに
記事を待たずに、まずはエンジンを使ってみたい方はこちらからどうぞ。
記事を公開したら、このリストにも追加していきます。ニュースレターを乱発することはありません。読む価値のあるものができたときに、一度だけお送りします。