プロトタイプを10分で出すだけなら、いまのAIは本当に強いです。画面を1枚作る。フォームをつなぐ。適当な管理画面を生やす。このあたりはもう、人間が最初から全部書く理由がかなり薄くなりました。
でも、現場で困るのは Day 1 ではありません。Day 2 です。
そのコードに型を足せるか。別の人が PR を出せるか。障害調査で読めるか。アクセシビリティを直せるか。ここで崩れるなら、それは開発速度の向上ではなく単なる前借りです。
最近はこのズレを雑に「バイブコーディングの限界」と呼びがちですが、もう少し正確に言うと、雰囲気だけで AI に投げた実装を、エンジニアリングの手続きなしに本番コードへ昇格させるのが無理になってきた、という話です。
バイブコーディングがダメなわけじゃない
誤解してほしくないのですが、バイブコーディング自体は便利です。自分もガンガン使っています。
向いているのはこのへんです。
- 検証用のプロトタイプ
- 一回限りの社内ツール
- 要件を固める前の UI たたき台
- 「まず動くものを見たい」初期フェーズ
この用途なら、多少コードが荒くても元は取れます。1時間で作って1週間で捨てる。そういうソフトウェアは普通にありますし、AIの使い所として間違っていません。
問題はそこから先です。顧客向けのフロントエンド、本番の管理画面、複数人で触るコンポーネント群にそのまま持ち込むと、だいたい後で痛い目を見ます。
よくある症状はかなり単純で、次のようなものです。
-
anyが静かに増殖している - state の責務が曖昧なまま画面だけそれっぽく動く
-
useEffectが何でもありの配線箱になる - DOM は出るけどキーボード操作が死んでいる
- API エラー時の分岐が薄くて運用で詰む
このへんは「AIがポンコツ」というより、AI に対して「どこまでを自由にしてよくて、何は守らせるのか」を人間側が渡していないのが原因です。
要するに、vibe はあっても spec がない状態です。
Day 2 で壊れるコードは、だいたい Plan がない
いま一番まずいなと思っているのは、AI がコードを書くことではなく、AIを使うことで「設計の前工程を飛ばせる」という気分になってしまうことです。
「検索モーダル作って。Cmd+K で開いて、いい感じにして」
これでも一応何かは出てきます。むしろ見た目はそこそこ良いことが多いです。
ただし、その時点では次の重要情報がほぼ欠落しています。
- どのファイルを触ってよいのか
- state の境界をどこに置くのか
- a11y の必須条件は何か
- 失敗時の UI をどうするか
- 型とテストの完了条件は何か
ここを空欄のまま AI に実装させると、あとから人間がレビューで全部回収することになります。これは開発の高速化ではなく、レビュー工程への丸投げでしかありません。
Agentic Engineering は「AIが暴走しないレール」を先に敷く
そこで必要になるのが、ここ数か月で自分の中ではしっくり来ている Agentic Engineering という考え方です。名前は大げさですが、やることはそんなに派手ではありません。
AI に自由作文させるのではなく、以下のループに閉じ込めるだけです。
- Plan
- Execute
- Verify
1. Plan
まず仕様を短くてもいいので書きます。Jiraの雑な issue より、実装境界が明確に読めるマークダウンのメモのほうが強いです。
# search-modal spec
- Cmd+K で開閉する
- `aria-modal="true"` を必須
- 入力は 300ms debounce
- API 失敗時は再試行ボタンを表示
- `src/features/search` 配下だけを変更対象にする
- 既存の `SearchResult` 型を壊さない
これだけでも、AI が勝手にアーキテクチャを広げてしまう事故はかなり減らせます。
2. Execute
ここは Cursor でも Claude Code でも同じです。
「検索モーダル作って」ではなく、「この spec を読んで、この範囲だけ変えて、終わったら自分で検証して」と書きます。
docs/search-modal.md を読んで実装してください。
変更対象は src/features/search 配下のみ。
完了条件:
- pnpm lint
- pnpm exec tsc --noEmit
- pnpm test search-modal
- キーボード操作とフォーカストラップを確認
失敗したら修正してから完了にしてください。
これをやると、AI が急に賢くなるというより「急に暴れにくく」なります。ここが大事です。
3. Verify
最後は人間が読む前に機械で落とします。
lint、typecheck、ユニットテスト、最低限の E2E。この4つを通らないコードは、どれだけ画面の雰囲気が良くても採用しません。
package.json にこういう最低ラインのスクリプトを置いておくと運用しやすいです。
{
"scripts": {
"verify:search": "pnpm lint && pnpm exec tsc --noEmit && pnpm test search-modal && pnpm exec playwright test search-modal.spec.ts"
}
}
「AI が書いたコードかどうか」は本質ではありません。
「このリポジトリの合格条件を通っているかどうか」だけ見ればいいんです。
MCP が効くのは、AIを賢くするからではなく、文脈の取り違えを減らせるから
MCP（Model Context Protocol）まわりは少し過剰に持ち上げられがちですが、現場で本当に効く理由はもっと地味です。
AI に社内ドキュメント、API スキーマ、デザインルール、運用手順を読ませる入口を標準化できる。これだけで十分な価値があります。
例えばフロントエンドなら、最低でも以下を取れるようにしておくだけでAIの出力はかなりマシになります。
- デザイントークンの参照元
- OpenAPI / GraphQL schema
- ADR や設計メモ
- コンポーネント使用ルール
- 監視や運用で見ているエラーパターン
これがない AI は、毎回「別の会社から来た優秀だけど空気を読めない新人」みたいなものです。
タイピングは速い。でも、うちのプロジェクトの都合を知らない。だから微妙にズレる。MCP が埋めてくれるのはこのズレです。
2026年のフロントエンドで、人間がまだ握るべきところ
AI がどれだけ強くなっても、人間の仕事は減りません。減るのはキーボードを叩く量だけです。
むしろ価値が上がっているのは、次の3つだと感じています。
境界を決める
どこまでを server component に寄せるか。
どこから client state にするか。
どの API を BFF で吸収するか。
この判断を曖昧にしたまま AI に書かせると、速く作ったはずのものが後で重荷になります。
完了条件を決める
「動いたら OK」ではなく、「何を満たしたら merge してよいか」を先に定義する。
React Compiler 前提のプロジェクトなら、手で useMemo をこねるより、再レンダリング境界や副作用の位置をきちんと分けるほうがずっと重要です。
捨てていいコードを見極める
全部を長期保守前提で作る必要はありません。
一方で、全部を使い捨て前提で作るのも乱暴です。
- 検証ツールなら荒くてよい
- 顧客接点の UI は荒くてはいけない
- 共通基盤は AI の生成量より変更耐性を優先する
ここを人間が線引きしないと、AI は全部同じテンションで量産してきます。そこが一番危ない。
いま実際に回している最小ワークフロー
自分の中では、フロントエンドで AI を使うときは次の形が一番安定しています。
- issue ではなく薄い spec を先に書く
- 変更対象ディレクトリを固定する
- AI に一度に一機能しか触らせない
- lint / typecheck / test / a11y を自動で通す
- 人間は実装の美しさより、境界と失敗時の挙動を見る
要するに「AI を信じる」のではなく、「AI が雑に壊せないレールを先に敷く」です。
このやり方に変えてから、プロトタイプの速さはほぼ落ちませんでした。
その代わり、Day 2 でコードを読み返したときの絶望がかなり減りました。ここは本当に大きいです。
結局どうするべきか
繰り返しになりますが、バイブコーディング自体は強力な武器です。
ただ、それをプロダクションコードにそのまま昇格させる標準手続きにしてしまうと、あとで必ず制御不能な負債になります。
2026年のフロントエンド開発で必要なのは、AI に全部丸投げする勇気ではなく、AI をちゃんと「工程」に閉じ込める設計です。
コードを書く時間は減っても、何を守らせるかを決める仕事は減りません。ここを握っているチームだけが、AIの速さをそのまま戦力に変えられるのだと思います。