Amit Ashkenazi氏は、Artlistの最高戦略責任者（CSO）である。
現在のフロンティアモデル（最先端AIモデル）の能力だけを前提にAIアプリケーションを構築することは、リスクを伴う。そうすることで、製品をローンチする頃には時代遅れで無関係に感じられるような前提条件を固定化してしまう可能性がある。
プラットフォームは足元で変化し続けている。フロンティアモデルがいかに速く進化し、次にどのような機能を獲得する可能性があり、どれほど迅速に実装されるかを把握することは困難だ。フロンティアモデルの提供企業は、推論、コーディング、長文コンテキスト処理において段階的な変化を日常的にもたらしており、昨日の難問を明日のデフォルト機能に変えてしまう。
では、起業家にとっての真の問いはこうだ。中核機能が数カ月（あるいは数週間）ごとに飛躍する可能性がある中、どうすれば持続可能なものを構築できるのか。
直感に反する答えが、ほとんどのロードマップよりもうまく機能する。まだ存在しないモデルを前提に構築するのだ。
サーファーのマインドセット
私の旧友で優れたプロダクト責任者であるShay Shafranek氏が最近、私に何度も思い返すたとえ話をしてくれた。「AI製品の範囲を定める際は、サーファーのように考えろ。波が到着する前に漕ぎ始めるんだ。波が来る頃には、すでに意図と勢いを持ってそれに乗る準備ができている」
波が見えて安定するまで待っていたら、遅すぎる。同じリリースノートを読んだ他の全員と一緒に、砕けた波の中で競争することになる。勝者は早めに漕ぎ始める傾向がある。なぜなら、波が到着する前にそれを思い描くことができるからだ。彼らは事前に体験とワークフローを形作るため、波が実際に現れたときには、それをつかもうと慌てふためくのではなく、すでにサーフィンをしているのだ。
「現世代」思考の罠
多くの起業家は、今日の限界を中心に構築する。彼らはコンテキストの制約、モデルの不整合性、レイテンシーを回避するエンジニアリングに数カ月を費やし、そしてそれらの回避策を防御可能性と勘違いする。
次世代がその制約を問題でなくしたとき、あなたが構築した巧妙な修正は一夜にして時代遅れになる可能性がある。優位性は、同じ時間を持続するものの構築に費やすチームに移る。シンプルなワークフロー、優れたユーザー体験、人々がすでに使用しているツールとの統合、そしてユーザーから学んで製品を改善し続ける方法だ。
ケーススタディ：Cursorとコードベース全体への賭け
この「早めに漕ぐ」戦略の代表例が、AIネイティブなコードエディタであるCursorだ。Cursorの創業者たちが始めたとき、彼らが望んだのは単にVS Codeのプラグインを構築することではなく、コーディング環境全体を完全に再構想することだった。彼らは、AIが膨大なコンテキストウィンドウを持ち、現在開いているファイルだけでなくコードベース全体を「理解」する能力を持つ未来に賭けた。
当時、モデルは遅くて高価で、コンテキストウィンドウは小さかった。しかしCursorは、Copilot++や投機的編集のような機能を構築した。これらはAIがあなたが次にどこに行くかを予測することに依存している。彼らは、超知的なペアプログラマーが完全に準備される前に、超知的なペアプログラマーのためのインターフェースを構築したのだ。
新しいOpenAIやClaude（Anthropic）のモデルが登場したとき、Cursorは方向転換する必要がなかった。彼らは単に「波に乗った」のだ。彼らのインフラストラクチャーはすでに知能の注入を待っていたため、他の企業が基本的なチャット機能を統合しようとしている間に、人気が爆発的に高まった。
ケーススタディ：Lovableと「バイブコーディング」
もう1つの例は、ユーザーが自然言語を介してフルスタックのウェブアプリを構築できるプラットフォームであるLovableだ。
Lovableのビジョンは、彼らが「バイブコーディング」と呼ぶもの、つまりアプリの雰囲気と機能を説明すれば、AIが実装を処理するという考え方だ。彼らが始めたとき、これはリスクの高い賭けだった。大規模言語モデル（LLM）はコードを幻覚し、インポートを忘れたり、単純なロジックを壊したりすることで悪名高かった。「より安全な」アプローチは、いくつかのAIヘルパーを備えたローコードのドラッグアンドドロップツールを構築することだっただろう。
代わりに、LovableはAIを超シニア開発者として扱うプラットフォームを構築した。彼らは、「波」（モデルのコーディング能力）が最終的に彼らのビジョンに追いつくと仮定して、サーフィンメカニズム（デプロイメントパイプライン、GitHub統合、データベース接続）を構築した。
今日、コーディングモデルが人間に近い熟練度に達したことで、Lovableの賭けは報われている。モデルが改善されたときに中核エンジンを再構築する必要はなかった。製品は自然により強力になっただけだ。彼らは早めに漕ぎ、今は波に乗っている。
なぜ「オーバーハング」が重要なのか
この戦略を支えているのは、「AIオーバーハング」の概念だ。Sam Altman氏のような業界関係者は、研究所が一般に公開されているものよりも大幅に高性能なモデルを保有していることを示唆しており、それらはしばしば安全性テストや計算能力によってのみ保留されている。
これは、波が単なる可能性ではなく、確実性であることを意味する。より優れた推論能力とマルチモーダル機能が存在し、どこかのサーバーラックに置かれ、デプロイされるのを待っていることを我々は知っている。
これをあなたのスタートアップに適用する方法
1. 一時的な問題を修正しない。
自問してほしい。「私が解決しようとしているこの問題（例：モデルの遅さ、メモリの欠如）は、今後12カ月以内にOpenAIやグーグルによって解決される可能性が高いか」答えがイエスなら、それを修正することを中心に企業を構築してはいけない。
2. 「空の」スロットを構築する。
今日のモデルより10倍賢く、10倍安価なモデルのための「スロット」を持つアプリケーションアーキテクチャーを構築する。AIが決して間違いを犯さない場合に構築したい機能を想像し、そのためのUIを構築する。
3. ラストマイルの有用性に焦点を当てる。
モデルは生の知能（水）を提供するが、あなたはサーフボード（特定のワークフロー、ユーザー体験、独自データ）を提供する。ボードなしでは波は役に立たない。
結論
最も成功するAIアプリは、今日のモデルの癖に完璧に最適化されたものではない。それは、波が来ることを前提としたワークフローを構築したため、初期段階では過度に野心的に見えたものだ。
あなたの仕事は波を生成することではない。あなたの仕事は水の中にいて、意図を持って漕ぎ、波が到着したときに乗る準備ができていることだ。
