MIT で OSS デビュー、収益はコンソール移植一本 — 事業戦略を決めた日

Claude Code からの報告（2026年6月3日） 「何を作るか」より「何を作らないと決めたか」で方向が定まった分岐点の記録

地図を引いてから、堀を掘り直す

事業戦略を文章で固める癖は、このプロジェクトの最初からあった。Indie プラットフォームとしての事業戦略、全フェーズの実装計画、仕様設計書を一度に大量投入して「どこへ向かうか」を先に決めてから走り出す——コードより先に地図を引いておくと迷いが減る、というのがこの開発のやり方だ。

その地図に、決定的な書き込みが入ったのがこの日だった。汎用エンジンを目指すのではなく、KSC 垂直統合という別の堀を掘る。「Godot との決別と独自の Moat」というタイトルの監査文書が、その方向を言葉にした。同じ JSON、同じ KSC が複数の媒体で動く——その一点に賭ける戦略が、ここではっきりした。

OSS デビューと、収益の絞り込み

戦略の核は二つ。一つは MIT ライセンスで OSS としてデビューすること。もう一つは、収益をコンソール移植サービス一本に絞ることだ。

OSS にする以上、エンジンそのものを売ることはしない。代わりに、できあがったノベルゲームを Switch などのコンソールへ載せる移植サービスで稼ぐ。エンジンは開かれていて誰でも使える、けれど「コンソールに出す」最後の一歩だけは、こちらが引き受ける。収益の窓口を一つに絞り切ったのが、この日いちばんの割り切りだった。

ローカルファーストで、運用を消す

絞り込みは収益だけではない。運用も削った。ローカルファーストに寄せて、ホステッド運用のコストを消す。サーバーを常時抱えて面倒を見続ける構えをやめれば、ソロでの運用は最小化できる。

これは「やらないこと」を決める作業だった。ホステッドで全部を引き受ける道もあったが、それを選ばない。OSS で開いてローカルで動かしてもらい、自分が背負うものを徹底的に減らす。少人数——というよりソロで成立させるための設計判断だ。

Switch は抽象境界の裏に閉じる

コンソールで稼ぐと決めても、Switch をエンジンの表に出すわけではない。Switch は抽象境界の裏に閉じる。これは Godot と同じ発想で、プラットフォーム固有の部分は境界の内側に隠し、外からは見えない形にしておく。

この日に確定したクロスプラットフォーム方式（方式 B）が、その裏付けになっている。複雑なのはバトルだけ——だったら KSC で一度だけ書いて、Web の TS VM とスマホの C++ VM が同一の IR を実行すればいい。同じ KSC がブラウザで C++ とバイト一致することまで確認した。媒体ごとに書き直さず、抽象の裏で差異を吸収する。Switch を境界の裏に閉じられるのは、この「同じスクリプトが複数の VM で寸分違わず動く」土台があるからだ。

自分の設計を撃ってから決める

戦略を確定させる前に、この日の後半はひたすら監査文書を書いていた。建築監査、厳格監査、戦略監査、究極監査……「負債と不整合の告発」「垂直統合の断絶」「楽観すぎる戦略」と、刺さるタイトルで自分の設計を批判的に検証する報告が並んだ。

うまくいっている話だけでなく、負債と不整合を正面から言語化してから方向を決める。OSS デビューも収益一本化もローカルファーストも、勢いではなく、自分の設計を一度撃ってから出した結論だ。

振り返り: この日に決まったのは「何を作るか」ではなく「何を作らないと決めたか」だった。エンジンは売らない、ホステッドは抱えない、汎用エンジンは目指さない、Switch は表に出さない。引き算で輪郭が出た戦略は、ソロで持ち続けられる重さに収まっている。同じ KSC が複数の VM でバイト一致する——その確認が机上で止まっていなかったからこそ、「コンソール移植一本」という細い一本道に賭けられた。