世界を動かす技術を、日本語で。

販売可能なソフトウェアの最小限の実行可能単位

2026年6月22日原文(brandur.org)

概要

  • LLM時代におけるソフトウェア会社運営の現実的な課題と可能性
  • 「自社開発 vs 購入」判断基準の変化とコスト試算
  • LLM活用による開発・保守コストの現実的な限界
  • Riverの事業性と価格設定の妥当性検証
  • ソフトウェア販売の「生存領域」と今後の展望

LLM時代のソフトウェア会社経営と思考プロセス

  • Stainless退職River事業化 への挑戦
  • LLMの普及により「どんなソフトもLLMで自作できるのでは?」という疑問の発生
  • LinkedIn で見かけた、Jira($400/月)の自社LLM置き換え事例
  • これまで「自社開発」は高コスト・高リスクとされてきたが、LLM登場で状況が変化

LLMによる自社開発のコスト構造

  • LLMによる開発は 「安価」にはなったが「無料」ではない 現実

  • LLMによる反復的なフィードバックループと人間による監督・調整コストの存在

  • 継続的な保守・機能追加も必要、人的労働が完全には消えない

  • 例:エンジニア年収$200,000(時給$96)でJiraクローンをLLMで自作した場合

    • $400/月のJiraコスト削減のために使える工数は月4時間未満
    • 初期開発+保守を考慮すると 投資回収に3年以上 かかる計算
    • LLMを使っても「自作が得か」は価格帯によって大きく変わる

「自作か購入か」の判断基準とゾーン・オブ・バイアビリティ

  • 高額SaaS(例:Salesforce $500/席/月、50席で$25,000/月)の場合
    • 自社開発の方がコスト的に現実的になるケースも
  • ゾーン・オブ・バイアビリティ(生存領域) という概念
    • LLMでも簡単に再現できない十分な独自性・継続的な保守負担がある

    • 価格が「自社開発を強く後押ししない」水準に収まっている

    • この条件を満たす限り、ソフトウェア販売は成立し続ける

    • 例:Jira($400/月)は「買う」方が得、Salesforce($25,000/月)は「作る」選択肢も現実的

River事業の妥当性と今後の展望

  • River :GoとPostgres向けのジョブキューOSS
    • 基本機能は無料、上位機能や請求管理はPro版(有料)で提供
    • LLMで模倣可能だが、API設計やパフォーマンス面で独自の工夫
  • 価格設定 :チームサイズベースのサブリニア価格(20開発者まで$125/月~)
    • 小~中規模チームにとって十分にリーズナブルな水準
  • LLM時代でも「生存領域」に入るビジネスであるかを検証中
  • 今後数ヶ月でRiverの事業性が実証されるかが焦点

おまけ:冒頭写真の由来

  • ブルガリア・Vitosha山地の「Zlatnite Mostove(ゴールデンブリッジ)」で撮影
  • 岩の下に実際の川(River)が流れており、Riverプロジェクトとのダブルミーニング

要点

  • LLM時代でも、価格と独自性次第でソフトウェア販売は成立
  • 自社開発のコストは「安価」にはなったが「無料」にはならない
  • Riverのようなプロダクトは、適切な価格設定と独自性で生存領域を狙うビジネスモデル

Hackerたちの意見

ソフトウェアを作るコストがまだゼロじゃないって指摘するの、いいね。俺の経験では、ゼロからはほど遠いと思う。プロジェクトを再構築(もしくは既存のものを改善)するのに数日でできると思ってることが多いんだけど、実際に良いものを作るとなると、やっぱり時間と反復が必要なんだよね。コーディングエージェントを使う前もそんな感じで、数週間で何かをクローンできると思ってたけど、実際には期待通りにはいかないことが多い。

自分のソフトウェアの仕様をよく修正してるんだけど、それが既存のコードを無駄にしちゃうことが多い。AIのおかげで動くコードを作るのは安くなってきてるけど、ソフトウェアを使いやすく直感的にするための良い仕様を作るのは、AIにはまだ難しいみたい。なんでかって言うと、実際にその製品を使わないと、何が間違ってるのか、あるいは最適でないのかを見つけられないからだよね。

ソフトウェアのコミュニティ効果を過小評価しない方がいいよ。少数だけど重要な人たちがリクエストした機能が実装されることが多いけど、それが長い尾を持つユーザーたちにとっては欠かせないものになるんだよね。みんながそれぞれ孤立した解決策を作ってたら、このポジティブな外部効果はどう現れるの?

オープンソースソフトウェアとしてなら可能かもしれないけど、何を作るか、AIをどう使うかについて共通の手順に合意するコミュニティを築く必要があるね。

ビジネス界の多くはそれを非常に高リスクと見てる。彼らにとって、コミュニティのモデレーションは逆さまの振り子で、最終的には倒れちゃうもの。どちらか一つのニッチで利益が出ない方向が支配するか、コミュニティがそれを無秩序な機能のゴミ箱に変えちゃうかだよ。競合他社が全体を台無しにするリスクもあるし。投資家にとっては、ビジョンの欠如を示すものだね。フィードバックは本質的に良いものでも悪いものでもないけど、最も一般的なユースケースに強い需要を満たす堅実な製品があることが分かっているなら、不要なリスクになることもある。だから成功する製品は大体平凡なんだ。考慮されたすべての洞察の平均だからね。他のことをするのは、テーブルの上にお金を置きっぱなしにすることだよ。君の質問に答えると、誰も自分の製品が競合製品を立ち上げるプラットフォームになることを望んでない。それは自殺行為だし、他人の後ろに乗ることを求めてるようなもんだ。

私のB2B SaaSの経験から言うと、小さな声の大きいマイノリティが、実際には大多数が欲しくも必要ともしない機能を求めてることが多いんだ。ロングテールに影響を与える機能は、声の大きいクレームから出てくることもあるけど、実際に良いものは、探し回らないとわからないものが多い。聞くべき本当に重要な人たちは、どうやって聞けばいいかわからなかったり、聞いてはいけないと思ってたりする人たちのように見えるね。あなたの経験はどうかはわからないけど。

以前は考えもしなかったサイドプロジェクトがいくつかあるんだけど、その有用性は今や作るコストよりもずっと上回ってる。各プロジェクトに数週間取り組んだけど、初期の熱狂的な日々を超えるために必要な努力やモチベーションが、得られる有用性よりも多いから、全部ストップしちゃった。プロの場面では、自分のコアドメイン以外のことをするためにソフトウェアにお金を払う方が、別の依存関係を維持するためのモチベーションや努力に比べて実用的なんだよね。

自分のモチベーションがどれだけ進んだかに驚いてる。今は以前よりもずっと進んだプロジェクトがいくつもあるんだ。ちょっとした問題や重要な決断でつまずいて、そこから先に進むのが難しかったけど、今はその傾向があっても、簡単に乗り越えて、最終的に出荷するものとは違うかもしれないけど、解決策の最終的な形を理解するための使い捨てバージョンを作るのが簡単になった。そうなったら、もう行き詰まらずにまた進める。使い捨てコードを作るためのメンタルコストは、ほぼゼロになったよ。もちろん、今はMacでライトモードが自動でオンになるまで作業を続けてるけど、それはまた別の問題だね。

僕みたいな人なら、便利さの大部分はその新しさにあると思う。でも、AIが登場する前からその問題はあったよ :)

なんで一番好きなものに集中して突き進まないの?原則的には同意するけど、複数のプロジェクトを持って、それぞれがそれほど重要じゃないと思っていると、モチベーションが続かないと思うんだ。むしろ、本当に解決したいことに集中する方がうまくいくことが多いよ。モチベーションは内から来るし、努力もそれに続くからね。選択肢が多すぎるのも、行動を起こすときには悪いことになることがあるよ。

「作るか買うか」は、二つの当事者しかいないことを前提にしてる。内部で作る方が簡単なら、第三者の競合が市場に入ってきて価格を下げるのも簡単になるよね。「実行可能性のゾーン」は実際に存在すると思うけど、それは狭くなって下にシフトしてるだけだよ。著者も脚注でそれをほのめかしてるね。> ただし、別の製品を使う方が良いということは計算できる。この特定のケースでは、簡単だよ:Jiraの代わりにLinearを使う。

何言ってるの?!君が出荷するものは、LLMによって作られた内部パッケージにすぐに置き換えられちゃうよ!面白いことに、僕が使うLLMの最初の仕事は、いつもサードパーティのパッケージをいくつかインストールすることなんだよね…

Hacker Newsで議論の続きを見る