最近、技術顧問として経営者の相談に乗っている中で、これまでとは少し違うタイプの強さを持つ人に出会うことが増えた。
いわゆる「技術のわかる経営者」ではない。もともとプログラマ経験はないが、Cursor や Claude Code のようなツールを教えると、驚くほどの速度で吸収し、自分でどんどんプロダクトや業務ツールを作っていくタイプの経営者だ。
社内向けのBPOツールや業務改善ツールなど、自分が業務のことを最も理解しているからこそ、本当に欲しいものを自分で形にしていく。この強さは、現場で見るとかなり印象的だった。
非エンジニア経営者のVibe Codingは、想像以上に強い
私自身、LLMを使った開発では、これまで比較的オーソドックスな構成を多く採用してきた。React Router、FastAPI、PostgreSQL、Redis、必要に応じて DynamoDB といったスタックだ。
Supabase も触ってはいたが、PoCから本番の大規模サイトまで持っていった経験がまだ薄く、少し後回しにしていた部分がある。
一方で、ある経営者の方は、Vercel や Replit を使いながら、LLM経由でどんどんサイトや機能を作っていく。しかも、単なる試作ではなく、自社の業務や顧客価値にかなり近いところを前に進めていた。
それを見ていて感じたのは、業務の本質を深く理解している本人が、自らVibe Codingできることの強さだった。
画面を作る、導線を変える、欲しい機能を足す。こうした試行が、経営判断とほぼ直結した速度で回る。ここでの速度は、率直に言ってかなり強い。
問題は、その後の本番運用だった
ただ、その後に問題が起きる。
GUIベースのVibe Codingで作られたものは、多くの場合、React中心で、表示データもMockベースになっている。ここから先、実際に本番で使えるようにしようとすると、エンジニア側が巻き取って再設計を入れることになる。
- データを安全に扱えるようにする
- 認証認可を固める
- APIを整理する
- DBとつなぐ
- 運用できる形にする
私自身、ここで React Router + FastAPI という慣れた構成に巻き取り直すことが多かった。
この判断自体は、分業されたエンジニア組織ではかなり合理的だったと思う。フロントとAPIを分け、責務を分離し、保守しやすい構成にする。従来の文脈では正しい選択だ。
ただ、そこでひとつの問題にぶつかった。
エンジニアがきれいに巻き取った瞬間に、経営者が自分で触って進化させる速度が落ちるのである。
「ちょっとここ変えたい」が入りづらくなる
本番に耐えるように整えて、さあリリースしようという段階になると、経営者側からは自然にこういう要望が出る。
- ちょっとここの画面を変えたい
- この導線を足したい
- ここにAI Chatを入れたい
- ここだけすぐ試したい
Vibe Codingで自由に改変していた段階では、それがすぐできていた。ところが、エンジニアがデータセーフで堅い構成に巻き取ると、そこから先の小さな進化が入りづらくなる。
結果として、PoCや初期グロースの一番大事な時期に、サービスの進化速度が落ちる。
これはかなりもったいないと感じた。
DockerやCLIを教えるという選択肢も、簡単ではなかった
「では経営者側にもDockerやCLIを教えて、一緒に開発していく」という方向も当然考えた。実際に相談もしている。
ただ、ここには明確な壁があった。非エンジニアの方にとって、コマンドラインツールの導入ハードルはやはり高い。
Dockerひとつとっても、どこで何が動いているのか、何がコンテナで何がローカルなのか、何を起動して何を停止しているのかが、身体感覚として入りづらい。
UIやLook & FeelはLLMでかなり作れるようになった一方で、CLIやコンテナの世界は、まだ非エンジニア経営者にとって自然な作業空間にはなっていない。これはツールの優劣というより、作業空間としての相性の問題だと感じている。
そこで、Next.js + Supabase を試し始めている
そう考えたときに、今あらためて有力に見えているのが、Next.js + Supabase の組み合わせだ。
理由は単純で、非エンジニア経営者のVibe Codingを観察していると、彼らはLLMに聞きながらかなり自然に開発を進めている。
- LLM経由でVercelへデプロイする
- マスタデータを作る
- Role制御のあるログイン処理を入れる
- 軽いCRUDを作る
こうした流れを、驚くほど自然にこなしていく。
つまり、その世界ではすでに、LLMがフルサポートしている開発体験が成立しつつある。
この前提に立つと、フロントとAPIを別フレームワークに分け、Docker化し、複数サービスをまたいで開発する構成は、分業エンジニア組織には向いていても、LLMと非エンジニア経営者の共同作業には少し重いのではないか、という感覚が出てきた。
ここで言いたいのは、「今までの構成が悪い」という話ではない。誰が作り、誰が育て続けるのか を考えたときに、評価軸が増えてきたという感覚に近い。
LLMが全体を把握しやすい構成の方がいいのではないか
私が今考えている仮説はこうだ。
- Front層とAPI層を Next.js の中に収める
- DBは Supabase のようなPaaSに寄せる
- インフラの複雑性をできるだけ減らす
- LLMが「このシステム全体」を把握しやすい状態にする
そうすれば、エンジニア側がある程度本番用に調整したあとでも、経営者が再び自分で変更を入れたり、LLMと一緒に改修したりしやすいのではないか。
まだ実験段階であり、試行錯誤の途中ではある。ただ、少なくとも現時点では、かなり可能性を感じている。
ここで大事なのは、これを「最強構成」として語らないことだと思っている。今見えているのは、進化速度を止めにくい構成の有力仮説であって、万能解ではない。
フレームワーク選定の前提が変わってきている
繰り返しになるが、「Next.js + Supabase が最強」という話をしたいのではない。
LLM Vibe Coding時代に入ったことで、フレームワーク選定の前提そのものが変わってきているのではないか ということだ。
これまでのフレームワーク選定は、分業しやすいか、責務分離しやすいか、エンジニア組織で保守しやすいか、が主な評価軸だった。
でも今後は、それに加えて
- 非エンジニア経営者が触り続けられるか
- LLMが全体像を把握しやすいか
- 小さな変更要求を止めずに吸収できるか
- PoC後も進化速度を落とさないか
といった軸が、現実に重要になってくると感じている。
本番品質の担保は、また別の論点
もちろん、ここで話しているのは「開発速度」や「進化速度」の話であって、本番リリース後の品質担保はまた別の論点だ。テスト、脆弱性検査、監視、障害対応、セキュリティレビュー。こうした工程は当然必要になる。
ただ、それを理由に初期の進化速度まで止めてしまうと、そもそも事業としての打席数が減る。このバランスをどう取るかが、これからの設計論なのだと思う。
まとめ
経営層が自らVibe Codingでサービスや業務ツールを前に進めていく現場を見て、その強さを実感している。
その一方で、エンジニアが従来型の安全な構成に巻き取った瞬間に、そこから先の小さな進化が入りづらくなる問題にもぶつかった。
この経験から今感じているのは、LLM Vibe Coding時代には、フレームワーク選定の軸そのものが変わり始めているということだ。
まだ試行錯誤の途中ではあるが、少なくとも「非エンジニア経営者がLLMと一緒に育て続けられること」は、これからのプロダクト設計でかなり重要な条件になっていくと考えている。