Vibe Coding: 2万ドルのエンタープライズ物流プラットフォームをAIで置き換える

多くのスタートアップにとって、「作るか買うか」という決断は、根本的な戦略的分岐点です。伝統的に、「買う」という選択肢（エンタープライズSaaSプラットフォームの採用）は、API統合の苦行や複雑な物流ロジックの管理を避けるための安全な賭けでした。しかし、大規模言語モデル（LLM）のおかげでソフトウェア開発のコストが急落している今、計算式が変わりつつあります。

TRMNLは、物流プロバイダーであるShipHeroのサービス停止をきっかけに、最近この分岐点に直面しました。その後に続いたのは、「vibe coding」の実験でした。つまり、年間20,000ドルのエンタープライズプラットフォームを、Claudeによって数週間で開発されたカスタムメイドのソリューションに置き換えるという試みです。

障害点：SaaSが負債となる時

TRMNLは、主に2つの機能のためにShipHeroを利用していました：注文の保留/メモの管理、および配送プロセスの実行です。システムは一定期間は適切に機能していましたが、いくつかの摩擦点が生じました：

ユーザーエクスペリエンスの低さ: モバイルレイアウトが存在せず、SSOが不十分な2つのドメインに分かれた断片的なウェブポータル。
サポートの欠如: 無視されるサポートチケットと、アカウントマネージャーの反応の鈍さ。
致命的な失敗: ベルリンの倉庫での完全なサービス停止、および不安定な郵便料金（同じ出荷物に対して12ドルから140ドルへ跳ね上がるなど）。

プロバイダーがメッセージへの返信を停止したとき、TRMNLはサービスの支払いを止め、AIを使用してプラットフォームを再構築することを決意しました。

「Vibe Coding」のワークフロー

プラットフォームの再構築プロセスは、すべてのコードを一行ずつ手書きすることではなく、デザインと統合の重労働をAIに処理させるためにオーケストレーションすることにありました。

スクリーンショットから高精度なモックアップへ

Claude Designを使用し、チームは既存のShipHeroポータルのスクリーンショットをAIに読み込ませました。目的は、単に革新のために革新を行うことではなく、「慣性の維持」を目指すことでした。倉庫チームが古いUIに対して筋肉の記憶（マッスルメモリー）を形成していたため、新しいシステムは、シームレスな当日切り替えを確実にするために、使い慣れた感覚を与える必要がありました。

驚くべきことに、AIは、明示的な「前後」の状態の説明なしに、「左側のアイテムをクリックして右側に移動させる」といった複雑なUXパターンを推論することができました。

統合の悪夢に対処する

物流プラットフォームの最も困難な部分は、配送業者（UPS, FedEx, DHL, USPS）のAPI統合です。これらの統合には、特に危険物や国際配送を扱う場合、1,000行を超えるJSONペイロードが含まれることがよくあります。

ここでLLMが最大のレバレッジを提供しました。これらの配送業者の技術ドキュメントをAIに読み込ませることで、TRMNLはFedExのドキュメントを読み込むという手作業の苦行を避け、数ヶ月かかるはずだったプロジェクトを迅速なデプロイへと変えました。

アーキテクチャとテスト

実際の構築を管理するために、チームはClaude CLIと、アーキテクチャに対してソクラテス式のアプローチをとる「Superpowers」というツールを使用しました。単にコードを生成するのではなく、このツールは、明確な要件を特定するために質問を投げかけます。これは、多倉庫サポートや外部キー管理のような複雑なロジックには不可欠です。

安定性を確保するために、チームは自動テストに大きく依存しました。著者が述べているように、「slop（適当なコード）は、テストされたものと同じ80%の安全性を持つ」と述べ、AI生成コードを本番環境で利用可能にするには、厳格なテスト用具（testing harness）が必要であることを強調しています。

最終製品：カスタム物流エンジン

完成したプラットフォームは、単なるクローンではありません。TRMNLの特定のニーズに最適化された、オーダーメイドのツールです：

ハードウェア統合: 4x6のラベルとパッキングスリップをワンクリックで印刷する、ネットワークプリンター用のカスタムSwiftユーティリティ。
Concurrency Control (並行制御): WebSocketsを使用して、注文を特定の倉庫チームメンバーにロックし、二重出荷を防ぐ。
Order Optimization (注文の最適化): 同じ顧客からの複数の注文を結合する「Merge Orders」インターフェース。
Automation Rules (自動化ルール): SKU、場所、およびIncotermsに基づいて、配送方法を自動的に割り当てるために、Python, Ruby, または Node を用いてルールを記述できるサーバーレススタイルのインフラストラクチャ。

結論：新しいSaaSの現実

このプロジェクトには、約80〜100時間の開発時間と、その後の1週間間のオンサイトでのデバッグが行われました。結果として、年間20,000ドルの契約よりも、読み込みが速く、印刷が速く、維持費が大幅に低いシステムが完成しました。

この変化は、ソフトウェア業界における成長傾向を浮き彫りにしています。Hacker Newsのあるコミュニティメンバーが次のように述べています：

"業務にカスタムソフトウェアをビルド・構築することのできる能力は、信じられないほどのスーパーパワーです。これは、SaaS企業全体に対して、価格競争力を強いることになると考えています。"

エンタープライズソフトウェアプロバイダーにとって、教訓は明確です：バリュープロポジション（価値提案）が「コードを書く手間を省く」から「優れたサービスを提供する」へとシフトしたとき、法的契約や高い解約率の障壁（churn barriers）に切り替えて顧客を維持しようとするプロバイダーは、「自動補完CLIへのサブスクリプションを持つ、賢い人間」に対して脆弱になるでしょう。