「Vibe Coding」という言葉、もう少しで古くなると思っている。
もちろん、雰囲気でプロンプトを書いて、AIにざっくり動くものを作らせる体験はまだ気持ちいい。最初の数分は魔法みたいに見える。僕も何度もそれで遊んだし、いまでも小さい試作ならそれで十分なことはある。
ただ、2026年4月のフロントエンド開発で本当に差が出ているのは、そこではない。
差が出るのは、AIに何を言うかではなく、AIが迷わず作業できる現場を作れているかだ。
自分はこれを、Vibe Coding ではなく Agentic Engineering と呼んだほうがしっくり来る。プロンプト芸ではなく、エージェントが動ける環境の設計である。
考えてみれば、これはプログラミングの歴史としては自然な流れだ。昔はアセンブリを書いていた。次に高級言語を書き、フレームワークを書き、CIを書き、IaCを書いた。人間が直接触る抽象度は、ずっと上がってきた。AIエージェントはその延長にある。
Claude 4.7 Opus は「賢い補完」ではなくなった
2026年4月16日に出た Claude 4.7 Opus は、空気を少し変えた。
SWE-bench Verified で 87.6%、SWE-bench Pro で 64.3%。ベンチマークの数字をそのまま現場の生産性に変換するのは危ないが、それでもこの数字には意味がある。もう「1ファイルの補完がうまい」みたいな話ではなく、リポジトリ単位の問題を読んで、調べて、直して、検証する方向へ寄っている。
特に xhigh Thinking のような長めの推論モードが効いてくると、タスクの渡し方が変わる。
昔なら、AIに頼むときはこうだった。
このコンポーネントをいい感じに直して
いまは、こうしたほうがいい。
目的:
- billing 設定画面の保存処理を React Hook Form に寄せる
制約:
- API のリクエスト形式は変えない
- 既存の E2E テストを壊さない
- shared/ui 以下の Button は変更しない
完了条件:
- pnpm test -- billing が通る
- pnpm lint が通る
- 差分の理由を最後に説明する
これは長文プロンプトを書けという話ではない。仕事の単位を、エージェントが実行できる形に切るという話だ。
ここを間違えると、どれだけモデルが強くなっても失敗する。人間の部下に「いい感じにやって」と言っても事故るのと同じで、AIも事故る。むしろ速いぶん、事故ったときの差分が大きい。
Vite 8 + Rolldown は、人間より先にエージェントを楽にした
Vite 8 と Rolldown の話も、単なる高速化として見るともったいない。
もちろん、production build が 10〜30倍速くなるとか、メモリ使用量が 75% 減るとか、そこは普通にうれしい。ビルド待ちが減るだけで、開発者の集中はかなり守られる。
ただ、自分が面白いと思ったのはもう一段先だ。
Vite 8 は、ツールチェーンが「人間が叩くCLI」から「エージェントが観測して操作する実行環境」へ寄っている感じがある。たとえば server.forwardConsole のように、AIエージェントが検出されたときにコンソール情報を渡しやすくする方向の機能は象徴的だ。
人間は多少ログが汚くても、画面と勘で補完する。エラー文の前後を読んで、「たぶんここだな」と当たりを付けられる。
AIエージェントは違う。観測できるログ、安定したコマンド、再現できる失敗がないと、急に迷う。だから AI 時代の DX は、開発者の体感速度だけではなく、機械が扱いやすい入出力まで含むようになる。
ここはかなり大きい変化だと思う。
Agentic Engineering で最初に整えるもの
Vibe Coding の中心はプロンプトだった。Agentic Engineering の中心は作業環境だ。
自分なら、まず次の4つを整える。
1. ディレクトリ構造の責務をにじませない
AIはファイル数が多いこと自体にはそこまで弱くない。弱いのは、責務の境界が曖昧なコードベースだ。
例えば、こういう構造はかなり扱いやすい。
src/
app/
routes/
features/
billing/
actions/
components/
hooks/
tests/
shared/
form/
ui/
utils/
features/billing の中を直せばいいのか、shared/ui まで触っていいのか。境界が見えているだけで、エージェントの暴れ方はかなり変わる。
逆に、components/ に業務ロジックが入り、lib/ に共通処理も機能固有処理も入り、utils/ に神関数がいるようなコードベースはつらい。人間にもつらいし、AIにはもっとつらい。
2. テストを「品質保証」ではなく「行動制約」として置く
AIに任せる量が増えるほど、テストの意味が変わる。
テストはあとから品質を確認するものではなく、エージェントの行動範囲を縛る柵になる。壊してはいけない仕様を、自然言語ではなく実行可能な形で置いておく。
フォーム送信なら、このくらいの小さいテストでも効く。
import { describe, expect, it } from "vitest";
import { buildPayload } from "./build-payload";
describe("buildPayload", () => {
it("空文字をAPIに送らない", () => {
expect(buildPayload({ nickname: "" })).toEqual({});
});
});
地味だが、この地味さが大事だ。AIは「意図」を読んでくれることもあるが、毎回読んでくれる前提で運用すると破綻する。読ませたい意図はテストに落とす。
3. 完了条件をコマンドにする
「ちゃんと動くようにして」は、指示として弱い。
人間でも解釈が割れる。AIならなおさらだ。だから完了条件は、できるだけコマンドに寄せる。
{
"scripts": {
"check": "pnpm lint && pnpm exec tsc --noEmit && pnpm test"
}
}
この pnpm check があるかどうかで、エージェントの仕事はかなり変わる。
成功条件が1本にまとまっていれば、AIは失敗を見て修正し、もう一度走らせることができる。逆に、検証手順が README の奥に散らばっていたり、担当者の記憶にしかなかったりすると、AIは運用に乗らない。
4. AI生成物を「そのまま成果物」にしない
Agentic Engineering というとコードの話に寄りがちだが、実際の開発現場では AI が生成するものはコードだけではない。
設計メモ、テストデータ、モックAPI、READMEのたたき台、画面キャプチャ、デモ用画像。全部が作業対象になる。
たとえば Gemini で作った画像をドキュメントや検証用UIに入れると、透かしや下書き感のある素材が混ざることがある。これをそのままリポジトリに入れると、あとで「これは本番用なのか、検証用なのか」がわからなくなる。
自分なら、画像もコードと同じように処理ステップを決める。生成したまま置かない。必要なら Gemini Watermark Remover のようなツールで Gemini 由来の透かしを落としてから、用途と出所をファイル名やメタ情報で残す。これは宣伝の話ではなく、成果物の状態管理の話だ。
重要なのはツール名ではなく、AIの生出力を成果物として扱わない というルールだ。コードなら lint と test。画像なら cleanup と命名。文章ならレビュー。媒体が変わっても、やっていることは同じである。
Cursor と Claude Code は競合ではない
この流れで見ると、Cursor と Claude Code をどちらか一方に決める話も、少し雑に見える。
自分の感覚では、両者は競合というより担当が違う。
| ツール | 向いている作業 | 感覚 |
|---|---|---|
| Cursor | いま開いている周辺を素早く直す | 手足 |
| Claude Code | 複数段の調査と変更をまとめて任せる | 部下 |
Cursor は日常作業にかなり自然に入る。コンポーネントの微修正、型エラーの解消、UIのちょっとした調整。人間が見ている文脈の延長で動かすと強い。
Claude Code は、もう少しタスクとして切り出した仕事に向いている。調査して方針を決める。複数ファイルを直す。テストを追加する。最後に差分を説明する。そういう仕事を任せる感覚だ。
月40ドルくらいで Cursor Pro と Claude Pro を両方使う、というのは冷静に見ると安くはない。ただ、1か月に数時間でもレビューや修正の往復が減るなら、エンジニアの人件費から見れば普通に回収できる。ここはきれいごとではなく、かなり生々しい費用対効果の話だ。
ただし、ツールを増やせば勝手に速くなるわけではない。担当を決めないまま両方使うと、単に文脈が分散する。Cursor は手元の加速装置。Claude Code はタスク実行者。このくらい割り切ったほうが運用しやすい。
エンジニアの仕事は「実装者」から「運行管理者」へ寄る
この変化を、仕事が奪われる話として見る必要はないと思っている。
むしろ人間の仕事は、別の場所に移る。
- どこまでを1タスクとして渡すか決める
- どのファイルを触ってよくて、どこから先は禁止か決める
- どのテストを成功条件にするか決める
- 生成物を成果物として受け入れていいか判断する
- 失敗したときに、モデルの問題なのか環境の問題なのか切り分ける
これは実装力が不要になるという話ではない。逆だ。実装をわかっていないと、エージェントの出した差分を評価できない。
ただ、価値の置き場所は変わる。全部自分で書く人より、AIが安全に走れるレールを敷ける人のほうが強くなる。
まとめ
2026年4月の時点で、Vibe Coding はもう入口の言葉になりつつある。
これから効いてくるのは、うまいプロンプトを一発で書く能力だけではない。リポジトリ構造、テスト、実行コマンド、ログ、生成物の扱い方まで含めて、エージェントが安定して働ける現場を設計できるかどうかだ。
Claude 4.7 Opus のようなモデルが出て、Vite 8 + Rolldown のようなツールチェーンが Agent-Native な方向へ進むなら、開発者の役割も変わる。
コードを書く人から、エージェントを指揮する人へ。
たぶんこの移行に早く慣れたチームほど、同じ人数でも出せる差分が大きくなる。魔法のプロンプトを探すより、AIが迷わない現場を作る。今やるなら、そっちだと思う。