「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が迷わない現場を作る。今やるなら、そっちだと思う。

Source notes