Vibe codingはもう時代遅れ——それはプロダクトマネージャーにとって朗報だ

2026年、「vibe coding」という言葉を世に広めた張本人のAndrej Karpathyが壇上に立ち、それはもう時代遅れだと宣言した。代わりに提示した概念が **agentic engineering（エージェント工学）**だ。その中身は一連の行動として語られた：設計仕様の記述、計画の監督、diffの確認、テストの作成、評価ループの構築、権限の管理、品質の維持。

そのリストからエンジニアリング固有の言葉を取り除いて、もう一度読んでみよう。何を作るべきかを決める。結果が意図と一致しているか確認する。「十分良い」の基準を定め、それ以下のものは出荷しないと決める。これは新しい学問ではない。Jeff Gothelfの言葉を借りれば、判断する側のバージョンこそがその仕事だ——それは昔からそうだった。 AIは、私たちがそれを隠していた場所を全部取り除いただけだ。

今プロダクトを作っている人にとって、これが最も重要な転換点だ。そしてその方向は、多くの人が直感に反すると感じるものを指している。

生き残るスキルはコーディングではない

10年間、「コードを学べ」はプロダクトアイデアを持つすべての人への定番アドバイスだった。2026年、そのアドバイスは静かに逆転した。AIエージェントが明確に定義された問題を動くソフトウェアに変えられるなら、ドキュメントを書くことが仕事ではなくなる——意図、明確さ、判断力が仕事になる。 業界が今重要視する人材の呼び名は「プロンプトエンジニア」ではない。Product Schoolの見立ては率直だ：2026年に本当に重要なPMは、AIプロダクトマネージャーだ。

具体的な動き方も、これを裏付けている。AIネイティブPMが実際に何をするのかについて、業界の共識は三つの動詞に収束している：

• 描述する（Describe）：有能なエージェントが行動できる程度に、求めるものを明確に言語化する。
• 分解する（Decompose）：検証できる単位まで問題を細かく切り分ける。
• 判断する（Judge）：アウトプットが意図と合っているか評価し、合っていない15%をどうするか決める。

この三つのいずれも、コーディングではない。三つすべてが、プロダクト管理だ。

コードが書けないことが強みになる理由

ここからが、一見おかしく聞こえるが実は正しい話だ。コードが書ける人は、頭の片隅で常に「これを作るのはどれだけ大変か」という見積もりを走らせている。自分が作る立場なら、その見積もりは有用だ——しかし何が存在すべきかを決める立場では、それが足かせになる。アイデアは口に出す前に刈り込まれ、ユーザー価値ではなく実装コストで形が決まってしまう。

コードが書けなければ、そのブレーキはない。手元に残るのは、最初に持つべき唯一の問いだけだ：ユーザーが本当に必要としているのは何か、この体験は正しいか。そしてあなたの仕事は、それを明確に言葉にすることだ。「アイデアを明確に言葉にする」こと——これはプロダクトマネージャーが持つ最も古いコアスキルだ。

これは無知でいることを勧めているわけではない。ボトルネックが移動したと言っているのだ。今や稀少なリソースはテキストエディタでの入力速度ではなく、求めているものそのものの明確さだ。

「言出法随 / Speak it, AI builds it」は方法論であり、感覚ではない

落とし穴がある。vibe codingが訃報を受け取ったのには理由がある。プロンプトがざっくりしていると、実行のたびにずれていく——デザイナーたちはすでに気づいている。AIプロトタイプがかつてワイヤーフレームを埋めていた場所を占めるようになったが、同じプロンプトを毎回実行すると、微妙に違うものができる。このセマンティックドリフトは急速に広がる。意図が曖昧なまま入力すれば、一貫性のないプロダクトが出てくる。

だから答えは「もっと頑張ってプロンプトを書く」ことではない。規律を持って取り組むことだ。その規律を私たちは DO AI PM と呼んでいる。いくつかのコミットメントに集約される：

• 高忠実度から始める。 ワイヤーフレームを飛ばして、本物の動くものを作る——本物のコンテンツ、本物の状態（ローディング、空、エラー、成功）、本物のインタラクション——そして実際に動かして検証する。動くプロトタイプは、言葉で説明されたプロトタイプに必ず勝る。意思決定の場でも同様だ。
• 五つのフェーズ、小さなステップ。 Discover（発見）→ Define（定義）→ Design（設計）→ Develop（開発）→ Validate（検証）。定義フェーズでは、仕様を書く前にAIにあなたへ質問させる。開発フェーズでは、一度に一つのことだけ変える。
• セーフティネット。 プロトタイプに本物のシークレットや本番データを入れない。取り消せない操作——公開、削除、支払い——は人間が押す。本番環境には触れない。わからなければ聞く。

この最後のリストが、「たまたまプロンプトがうまくいった」と「月曜日にもまた同じことができる」の差だ。

成果が証拠だ

説明するだけの方法論に価値はない。だからここにあるすべては、Claude Codeで同じ方法を使って作られた実際のプロダクトから来ている：SoloMD（Markdownエディタ）、Unterm（AIが操作できるターミナル）、unfetch（人間とAIのためのダウンロードマネージャー）、StoryAlter（AIライティングコンパニオン）、Unflick（人間とAIのためのメディアプレイヤー）。このウェブサイト自体——八言語、このブログ、デッキ——も同じ方法で「言葉にして」作られた。一行も手書きのコードはない。

方法論が作品を説明し、作品が方法論を証明する。

Karpathyは正しかった。vibe codingは終わった。しかしそれに取って代わるのは、より難しいエンジニアリングではない——よく判断し、明確に言葉にする規律だ。それには名前がある。そして今こそ、その仕事をする好機だ。

「言出法随 / Speak it, AI builds it」が実際にどんな感覚か体験したいなら、メソドロジーセンターから始めよう。

参考リンク

• Jeff Gothelf — Karpathy said vibe coding is obsolete. What he described instead is product management.
• Product School — AI Product Managers Are the PMs That Matter in 2026
• monday.com — Vibe coding for product managers: the complete 2026 implementation guide