7 ポイント 投稿者 GN⁺ 2026-02-07 | 4件のコメント | WhatsAppで共有
  • SaaSがLLMに置き換えられるという主張には懐疑的だったが、実際に年間120ドルのLinkedIn/X推薦文表示サービスを20分で自前のコードに置き換えた経験を共有
  • 置き換え対象は決済システムが2023年から故障したまま放置されており、顧客サポートも壊れたリンクを送ってくる程度
  • Codexを活用し、既存の推薦文をJSONファイルに分離し、ビルド時にHTMLを生成するモジュール方式へ移行。見た目の結果は従来と同一
  • 開発者にとっては素早く興味深い作業だが、非開発者にとってはLLMのコード出力の検証が参入障壁になりうる
  • 継続的な価値を提供できない静的な性格のマイクロSaaSは、LLM時代に最初に置き換えられるリスクにさらされている

SaaSのLLM代替論に対する従来の懐疑論

  • SaaSがLLMに置き換えられるという理論の中核: SaaSは純粋なソフトウェア製品であり、LLMがカスタムソフトウェア構築のコストと時間を劇的に下げるため、大半のSaaSベンダーが消えるという論理
  • これに対する反論として、WorkdayのようなHRソフトウェアは単なるソフトウェアではなく、各国の規制遵守(休暇手当、給与明細など)を保証し、外部・内部環境の変化に合わせて継続的に更新されるサービス

Shoutout.ioの利用体験と離脱のきっかけ

  • pragmaticengineer.comにLinkedInとXの投稿ベースの推薦文セクションを表示するため、Shoutout.ioを年間120ドルで4年間利用
  • ログインは年1回程度で、直近のログインは経費処理のための年次請求書の確認が目的
  • 決済セクションが2023年から故障した状態で放置されており、サポートチームにメールを送ったが壊れたリンクが返信された
  • 翌年の料金がいくらなのかすら確認できない状況が、SaaS離脱の直接的なきっかけ

Codexを活用した20分の置き換え作業

  • 既存SaaS全体ではなく、自分の具体的なユースケース(推薦文表示、新しい推薦文の追加、デザイン維持)だけを再構築するアプローチ
  • Codexに対し、サードパーティ依存を除去し、GitHubリポジトリ内でホスティングする計画の立案を依頼
  • 推薦文を別個のJSONファイルで管理し、コンパイル時のビルド段階でHTMLとして生成するモジュール方式に調整
  • ローカルのビルド段階追加とNetlifyビルドトリガー設定、テスト、UX調整、スキーマ生成、デプロイまで合計20分所要
  • 最終成果物は見た目が従来と同一で、サードパーティ依存を完全に除去
  • カスタマーサポートが正常なリンクを送ってきた時点(2時間後)には、すでに移行完了状態

ソフトウェアエンジニアへの示唆

  • 開発者は今後の更新時にコマンドラインとAIエージェントを使ってコードベースに推薦文を挿入し、結果を検証することに慣れているが、非開発者にとってはLLMのコード出力の検証が参入障壁
  • 開発者がSaaSを自前のコードへ「ポーティング」する速度は、非開発者よりはるかに速い
    • 初回の試行ではCodexがflexboxモデルで誤って実装し、UIレイアウトフレームワークを自分で決める必要があった
    • 非開発者でも解決は可能だが、より長くかかると予想
  • サードパーティ機能を自分で書き直す作業は楽しく学習効果があり、ツールの実際の性能を体験する機会

SaaSビジネスへの示唆

  • SaaS全体を再構築することと、特定のユースケースだけを再構築することでは難易度が大きく異なる
    • Shoutoutは10以上のプラットフォームで引用追加、認証、決済など10倍以上の機能を保有
  • 推薦文表示後に継続的な価値を提供しない静的SaaSが最も置き換えられやすい
    • 一方で、規制遵守、分析、通知などリアルタイムのビジネス支援機能があれば置き換えははるかに難しい
  • SaaS売買ビジネスの収益性低下の可能性
    • Shoutoutは2020年に個人開発者が構築し、2022年にプロダクトスタジオへ売却、2025年にさらに別の開発者へ再売却
    • ユーザー視点では、決済システムが壊れたこと以外に変化はない
    • 買収者たちは投資なしで売上成長を期待していた可能性があるが、製品が放置されるとユーザーが離脱し、LLMで簡単に代替可能な時点が到来
  • 壊れた窓(Broken Windows)」を放置することが、過去よりはるかに許容されない時代

4件のコメント

 
github88 2026-02-07

保守コストもコストだからね

 
ddaemiri 2026-02-09

ソフトウェア導入は常に「5年」スパンで「TCO」の観点から見るべきです。そうしないと、後になって本当に爆発する「爆弾」を積み上げるだけになってしまいます。

 
anjwoc 2026-02-08

ずいぶん単純に考えていたみたいですね(笑)

 
sinbumu 2026-02-07

使用人が書いたものなのか、自分で構築したとしても、今後はその機能を外部業者ではなく社内で継続して動かし続けるよう管理しなければならないはずですが、これは時間もお金もかからないタダということですか??