ここ数年、AIがプロダクトを大きく変えると感じ、従来と何が違うのかが気になってきた。投資家としても海外を含むスタートアップやプロダクトを見る機会が増える中で、AIを前提に設計されたプロダクトには、従来とは明らかに異なる成功パターンがあるように感じている。
それは、AIが中心となるプロダクトの設計には、「完璧な仕様」を追い求める従来の手法とは異なる、新しい姿勢が求められているということではないか。プロダクトを完成させるのではなく、変化し続ける前提で設計するという姿勢だ。
たとえば、AIコードエディタとして登場したCursorは、VS Codeという巨大な既存プロダクトが存在する市場において、またたく間に支持を集めた。VS CodeにもGitHub CopilotをはじめとするAIサービスのアドオンを追加することはでき、AI機能そのものは利用可能だったにもかかわらずである。
Cursor以前のアプローチは、既存のエディタに「AIアシスタント」を追加するというものだった。これは、従来のプロダクト開発の延長線上にある発想である。すでに完成されたプロダクト（VS Code）が存在し、そこに新しい機能（AI補完）を付け加える、という考え方だ。
一方、Cursorは異なる。Cursorは、AIがコアにあることを前提として、ゼロからエディタを再設計した。AIは「追加された機能」ではなく、プロダクトの中心的な存在である。リポジトリ全体をセマンティックにインデックス化し、複数ファイルにまたがる変更を生成し、開発者の意図を理解して自律的に行動する。これは、「AIが完璧に機能する」という前提に立ち、ワークフロー全体を再構築した結果である。
このCursorのアプローチが有効であることは、その後、GoogleがAntigravityという形で追従したことからも明らかだ。
決定論から確率論へ
ここでは、なぜAIネイティブプロダクトでは従来の仕様設計が限界を迎えるのかを整理しよう。
AIを「機能として追加する」のではなく、「プロダクトの中心に据える」という設計への転換。この変化を一言で言えば、「設計対象が変わった」ということだ。
それは、ソフトウェアが決定論的な存在から、確率論的な存在へと変わったことによって起きている。
従来のプロダクト設計は、振る舞いを固定した「完成物」を設計する仕事だった。入力と出力の関係を定義し、想定される状態やユーザーフローを網羅し、意図した通りに動作することを保証する。その前提にあるのは、ソフトウェアは設計者の意図通りに振る舞うべきだ、という考え方である。
しかし、生成AIを中核に据えたプロダクトでは、設計する対象は「完成物」ではなく、「学習し続ける存在」になる。プロダクトはリリースされた時点で完成するのではなく、利用される中で振る舞いを変え、進化し続けることが前提となる。ここで言う「学習し続ける存在」とは、1) どのデータを集め、2) どの文脈でAIに渡し、3) どのフィードバックを次の振る舞いに反映させるか、という一連の仕組みを指す。
このような変化の背景にあるのは、ソフトウェアの性質が決定論的なものから、確率論的なものへと移行したことである。
設計対象の変化は、既存のエディタにAIアシスタントを追加するアプローチと、AIネイティブエディタであるCursorを比較すると、より明確になる。この違いは、単なる機能や実装の差ではない。Cursorが示したのは、プロダクト設計における根本的なパラダイムシフトである。
従来のプロダクトは「完成させて出荷するもの」だった*1。しかし、生成AIを組み込んだプロダクトは、「リリース後に学習し続ける生態系」として設計される*2。
では、この前提の変化は、テックリードやプロダクトマネージャーの仕事を、どのように変えるのだろうか。
変わる人間の役割
テックリードやプロダクトマネージャーは何をすればよいのだろうか。
答えは、「完璧な仕様を書く」ことではない。「良い方向に学習する構造を設計する」こと、そして「プロダクトを進化させる仕組みを整える」ことである。
プロダクトは、もはや「完成させて出荷するもの」ではない。プロダクトは、「リリース後に学習し続ける存在」である。人間の仕事は、この生態系が健全に進化するための「構造」を設計することだ。
これは、特にプロダクトマネージャーの役割の根本的な変化を意味する。従来のプロダクトマネージャーは「機能の門番（Gatekeeper）」だった。どの機能を作るか、どの順番で作るか、どのように作るかを決める存在だった。
しかし、AIネイティブプロダクトを担当するプロダクトマネージャーは、学習システムの設計運用責任者である。具体的には、AIモデルそのものを鍛えるのではなく、どのデータや文脈を与えるか、どのフィードバックを取り込み、どの振る舞いを強化・抑制するかといった、学習が回る構造そのものを設計・運用する役割を担う。
AIモデルそのものを鍛えるのではないと言ったように、ここでの「学習」は、モデルの再学習を意味しない。多くのAIネイティブプロダクトは自らモデルを開発していない。また、モデルを持っている場合でも、有料プランの利用ユーザーデータを直接モデル学習に使わないことがほとんどだ。それでもプロダクトは、使われるほどに振る舞いを変えていく。その違いを生むのは、モデルの外側に設計されたデータ、文脈、履歴、フィードバックの構造である。それらは
つまり、プロンプトなどのAIへの指示方法であり、AIに参照させるデータとしてのコンテキストである。技術的には、RAGであったり、MCPであったりする。
ただし、AIネイティブプロダクトでは前提条件が変わる。振る舞いを完全に制御できない以上、問われるのは個々の機能ではなく、学習がどう回り、どう修正されるかという「構造」そのものだ。
要するに、人間に求められるのは「何を作るか」を細かく決めることではない。AIがどのように振る舞いを変えていくのか、その前提となる構造を設計し、方向を調整し続けることである。
では、人間が設計・運用すべき「構造」とは何か。
AIネイティブなプロダクトでは、その中心にあるのは学習の仕組みである。プロダクトの価値は、どんな機能を持つかではなく、その学習がどれだけ健全に回り続けるかによって決まる。
そして、この学習を成立させるために不可欠なのが、データとフィードバックである。
AIネイティブプロダクトにおける学習
では、ここから「人間が設計すべき構造」が、実際のプロダクトの中でどのように形になっているのかを見てみたい。AIネイティブなプロダクトにおいて、人間がどこに介在し、何を設計しているのか。
ここでは、AIを前提にゼロから設計されたエディタ、例えばCursorやAntigravityといった「AIネイティブエディタ」を例に考えてみよう。
AIネイティブエディタでは、リポジトリ全体がセマンティックにインデックス化され、コードは単なるテキストの集合ではなく、「意味」を持つ構造として扱われる。さらに、開発者がどのような編集を行ったか、どの提案を受け入れ、どの提案を拒否したかといった利用の痕跡が継続的に蓄積される。
重要なのは、これらが単なるログではなく、次にAIを使う際の入力文脈として再利用される点だ。どの情報を参照させるか、どの履歴を重ねるかといった判断は、人間が設計した前提に基づいて行われる。
すでに説明したように、ここで起きているのは、AIの中身が変わることではない。固定されたモデルはそのままに、どの情報を参照させ、どの履歴を重ね、どのフィードバックを次に活かすか。その積み重ねによって、プロダクト全体の振る舞いが変わっていく。
この意味で、AIネイティブプロダクトは「学習し続ける存在」として設計されている。利用のたびに得られるデータが、次の振る舞いに影響を与える。
このように、モデルを自ら開発しないプロダクトであっても、学習する構造を内包することは可能である。そして、この構造をどう設計し、どう運用するかこそが、人間に委ねられた最も重要な仕事なのである。
ここで、超ざっくりとした設計イメージを一つ挙げてみよう。
AIコードエディタであれば、たとえば次のようなサイクルを設計する。
- AIが出した修正提案に対して、開発者が「採用したか」「拒否したか」をログとして残す。
- そのログを用いて、次回以降の提案時に、採用されやすい修正パターンを優先的に提示する。
- 繰り返し拒否される提案パターンについては、ルールやプロンプトを調整し、出力されにくくする。
重要なのは精度の高いアルゴリズムではない。提案→選択→次の提案に反映、という学習のループが、意図した方向に回るよう設計されているかどうかである。
データ設計 蓄積から循環へ
では、この「学習し続ける存在」を、どのように作り上げていけばよいのだろうか。鍵となるのはデータである。ただし、生成AI時代において問われているのは、データの量ではない。
従来、データの価値は「蓄積」にあった。どれだけ多くのデータを集めたか、どれだけ詳細な情報を記録したか。データウェアハウスに大量のデータを保存し、分析ツールで可視化する。これが、いわゆるデータ駆動型の意思決定だった。
しかし、生成AI時代におけるデータの価値は「循環」にある。データは、集めただけでは価値を生まない。利用され、学習に回され、AIの振る舞いを変え、その結果として新たなデータが生まれる。この循環が回って初めて、データは資産になる。
このフィードバックループの設計こそが、AIネイティブプロダクトの成否を分ける。AIを導入しても、フィードバックを回収せず、学習に活かさなければ、プロダクトは賢くならない。その結果、プロダクトは「学習する生態系」ではなく、「固定されたツール」のままにとどまる。
この循環が回り始めたとき、それは強力な競争優位性となる。他社が容易に模倣できない、独自のデータと学習ループが、いわば「データ・モート（防御壁）」として機能するからだ。生成AI時代においては、ソフトウェアそのものの差別化は急速に難しくなっている。AIがコードを書き、機能実装の大部分を肩代わりしてくれるようになったことで、ソフトウェア開発の再現性は飛躍的に高まった。オープンソースモデルや汎用APIの普及も相まって、技術的な障壁は大きく下がっている。誰でも、一定水準のAI機能を備えたプロダクトを作ることができるようになった。
だからこそ、差別化の源泉はデータに移る。ただし、重要なのは「独自のデータを持っているか」ではない。そのデータを学習に回し、改善のループを回し続けられているかどうかである。
実は、多くの企業はすでに独自のドメイン知識とデータを持っている。日本企業も例外ではない。問題は、それらが十分に循環していないことだ。生成AIを既存業務に部分的に導入するだけでは、この循環は生まれない。プロダクトそのものを、AIネイティブな前提で再設計する必要がある。
では、新興企業はどうすればよいのか。
答えは単純だ。フィードバックループを、できるだけ早く回すことである。データの量が少なくても、利用と改善の循環を高速に回すことができれば、AIは急速に賢くなる。AIが賢くなれば、ユーザー体験が向上し、ユーザーが増える。ユーザーが増えれば、データが増える。この好循環が、やがてデータ・モートを形成する。
Cursorの成長は、そのことを端的に示している。
そして、この「フィードバックループを早く回す」という考え方は、独自データをすでに持っている企業にとっても同様に重要である。派手な先行事例が出そろうのを待っていては、競争優位性は築けない。自社の事業にAIを組み込み、AIネイティブなプロダクトへと転換していく。そのための第一歩が、データを「蓄積」ではなく「循環」として設計し直すことなのである。
重要なのは、フィードバックの量ではなく向きである。誤ったシグナルを回せば、プロダクトは高速に劣化する。人間は、学習が向かう方向に最低限のガードレールを引く必要がある。
ここでも、設計イメージを極端に単純化すると理解しやすい。
たとえば、どの提案を評価対象とするのか、どの操作を「良いシグナル」と見なすのかを、最初からすべて自動化しようとしない。初期段階では、人間が明示的に「これは良い」「これは悪い」と判断するポイントを絞り込み、学習が誤った方向に進まないよう制御する。フィードバック設計とは、そのための最小限の安全装置である。
AIネイティブプロダクトは、AIネイティブな組織でしか作れない
正直に言うと、この話は技術の話だけではない。
ここまで述べてきたような学習システムは、個人の工夫や一部のチームの努力だけでは成立しない。AIネイティブなプロダクトは、AIネイティブな人と組織でなければ作れない。
少なくとも、私が見た・聞いた・調べた範囲では、プロダクトに関わる人間がAIを理解していない組織で、AIネイティブなプロダクトがうまくいった例はない。
たとえば、会議の中で「この挙動はモデルの限界なのか、それともコンテキストやデータ設計の問題なのか」を議論できるかどうか。KPIについても、「機能が予定通り完成したか」ではなく、「学習のループが回り、振る舞いが改善したか」を問う指標に置き換えられているか。こうした具体的な問いが日常的に交わされているかどうかが、AIネイティブ組織かどうかの分かれ目になる。論文を読めという話ではない。実際に使い、自分の手で試し、失敗し、挙動の癖を体感しているかどうかが重要だ。AIをブラックボックスとして扱ったままでは、学習する構造を設計することはできない。
同様に、「作る」経験も欠かせない。モデルを自作する必要はないが、プロンプトやコンテキスト、データの与え方ひとつで振る舞いが大きく変わることを、身体感覚として理解している必要がある。AIネイティブプロダクトとは、AIを前提に思考し、設計し、試行錯誤できる人間によってのみ生み出される。
そして何より重要なのは、意思決定の速さである。
生成AIの進化は極めて速い。半年待てば状況は一変する。このスピードに追いつくためには、完璧な検討や合意形成を待っている余裕はない。試し、学び、修正する。そのサイクルを回し続けられるアジリティの高い人と組織でなければ、AIネイティブな競争には参加できない。
これは、組織の規模の問題ではない。大企業であろうと、スタートアップであろうと条件は同じだ。AIネイティブプロダクトを作れるかどうかは、AIネイティブな人と組織になれているかどうかで決まる。
プロダクト設計とは、もはや機能や画面を設計する仕事ではない。冒頭で述べたように、変化し続ける前提に立ち、学習が回り続ける構造と、それを回し続けられる人と組織を設計する仕事なのである。
さて、あなたのチームは、どこまで『機能の設計』から『学習する構造と組織の設計』へと軸足を移せているだろうか。
