ここ数か月でいちばん変わったのは、AIが書けるコード量ではなくて、雑に渡した仕事がそのまま事故になる速度だと思っている。

プロトタイプならまだいいです。v0 や Cursor で一気に画面を立てて、動くものを先に見る。その価値はむしろ上がっています。

ただ、本番運用まで含めると、2026年の開発はもう「Vibe だけ」では回りません。必要なのは、生成させた後にちゃんと検証する前提でワークフローを組むことです。

自分はこれを Vibe & Verify と呼ぶのがいちばんしっくりきています。

先に結論: 70/30 で考えるとだいぶ安定する

最近は AI が 7割書いてくれる、という意味で 70/30 を語る人もいますが、現場感では少し違います。

むしろ逆です。

70%: 仕様の固定、コンテキスト整備、検証手順の定義
30%: 実際のコード生成と差分作成

この比率で考えるようになってから、AI に振るタスクの失敗率がかなり下がりました。

コードを書く時間そのものは短くなります。でも、その前後にある「何を変えてよくて、何を壊したらダメか」を定義する時間は、むしろ増えます。

ここをサボると、生成速度だけ上がって手戻りが増える。たぶん今いちばんありがちな失敗です。

なぜ Vibe Coding だけだと危ないのか

Vibe Coding が刺さった理由は単純で、UI も CRUD も驚くほど速く出るからです。

でも実務で痛いのは、そこではありません。

認証の境界が曖昧なまま機能が増える
フォームのバリデーションが画面ごとにズレる
型は通るのに edge case が落ちる
テストがないまま「動いたからOK」で進む

このあたりは、人間が最後に責任を持つしかない。

だから 2026 年のテーマは「AI が賢いか」ではなく、「AI が暴れても壊れにくいレールを敷けているか」になっています。

まず整えるのはプロンプトより作業条件

自分が AI コーディングで最初に書くのは、派手なプロンプトではなく、変更条件です。

例えばこんな形です。

目的:
- 請求フォームの送信処理を整理する

変更してよい範囲:
- src/features/billing/**
- src/shared/form/**

触ってはいけないもの:
- API レスポンスの型
- ルーティング構造
- デザインシステムの公開 props

完了条件:
- pnpm lint
- pnpm exec tsc --noEmit
- pnpm test

これだけでも、AI の挙動はかなり変わります。

逆に「フォーム周りいい感じに直して」は、まだ危険です。動くものは出てきます。でも、その差分をマージしていいかは別問題です。

Plan Mode を使うと「会話」から「レビュー」に変わる

Cursor でも Claude Code でも、最近いちばん効くのは Plan Mode 的な流れです。

いきなり実装させるより、先に計画を出させてレビューする。その1ステップを挟むだけで、だいぶマシになります。

自分はだいたい次の順番で見ます。

どのファイルを触るつもりか
どのテストを追加するつもりか
既存の責務分離を壊していないか
完了条件をどう満たすつもりか

この時点で危ない匂いがしたら止めます。ここで止められると安い。実装が始まってから止めると、急にレビューコストが上がる。

「エージェント憲法」を置くと drift が減る

2026 年に入ってから、CLAUDE.md や .cursor/rules を README の延長で扱うのはやめました。

あれはメモではなく、エージェント向けの憲法です。

例えば最低でもこれくらいは書いておくと効きます。

# Agent Constitution

- 新規 UI は既存の `src/components/ui` を優先して再利用する
- `any` を追加しない
- API 型は `src/schema` を単一の正とする
- 変更後は `pnpm check` を通す
- テストが追加できない変更は、その理由を必ず説明する

重要なのは、理想論を書くことではありません。現場で本当に守らせたいことだけを書くことです。

項目が多すぎると人間も AI も読まなくなります。5個から8個くらいに絞るとちょうどいい。

70% に入る作業は「準備」と「検証」

70/30 という話をすると、生成前の準備だけを想像しがちですが、後ろ側の検証もかなり重いです。

実際にはこうなります。

生成前

変更対象を限定する
依存している仕様を明文化する
失敗してはいけないケースを先に決める

生成後

テスト追加の妥当性を見る
例外系が落ちていないか確認する
命名や責務分離が崩れていないか見る
本番で踏みやすい導線を自分で触る

ここは完全自動化しにくいです。だからまだエンジニアの仕事が残る。

残るというより、むしろここが本体です。

30% の生成を強くするには、確認コマンドを一本化しておく

AI に複数回タスクを回させるなら、完了条件はコマンドで一本化したほうがいいです。

{
  "scripts": {
    "check": "pnpm lint && pnpm exec tsc --noEmit && pnpm test"
  }
}

この pnpm check があるだけで、AI が自力で戻ってこられる確率が上がります。

レビューする側も楽です。

何を通したのかが明確
失敗したらどこで止まったか見やすい
追加の修正依頼を出しやすい

細かい話ですが、2026 年の DX はこういう「人間にもエージェントにも読めるインターフェース」を作ることだと思っています。

役割分担は「1人の万能AI」ではなく「専門家艦隊」

最近うまくいくのは、1つの AI に全部やらせる形より、役割を切る形です。

例えばこんな分け方です。

UI 担当: コンポーネントと見た目の修正
ロジック担当: 状態管理と API 接続
テスト担当: ユニットテストと回帰確認

人間はその上で、

タスクの境界を切る
競合しそうな変更を避ける
最後に差分を見て統合判断する

この位置に立つほうが、全部を自分で書くより明らかに速いです。

ただし、放置していいわけではない。オーケストレーションの仕事が増えただけです。

小さい例: フォーム改修を Vibe & Verify で回す

請求フォームの修正を例にすると、最近はだいたいこう進めています。

1. 先に人間が固定するもの

変更対象ディレクトリ
バリデーション仕様
壊してはいけない E2E 導線
完了条件コマンド

2. AI に投げるもの

フィールド追加
既存 UI への組み込み
型定義の更新
テストのたたき台

3. 人間が最後に見るもの

バリデーションの抜け
エラーメッセージの実用性
既存コンポーネントとの整合性
レビューで説明できる差分かどうか

要するに、AI には「書かせる」。でも「保証」は人間が持つ。この割り切りが大事です。

エンジニアの価値は「実装量」より「保証能力」に寄っていく

少し極端に言うと、これから価値が落ちるのはコードを書く行為ではなく、「何も決めずに書き始めること」だと思っています。

逆に価値が上がるのはこのへんです。

仕様の曖昧さを減らす
タスク境界を切る
検証手順を先に決める
AI が壊しやすいポイントを知っている
最終的にマージしていい差分か判断する

この能力は、フロントエンドでもバックエンドでもかなり共通です。

AI によって実装速度が上がるほど、雑な設計や雑なレビューのコストは目立つようになります。そこから逃げる方法は今のところありません。

まとめ

Vibe Coding は入口としては強いです。自分も普通に使います。

でも、本番開発の標準フローとして残るのは Vibe & Verify のほうだと思っています。

70/30 の感覚で、

先に条件を決める
AI に生成させる
人間が検証して受け入れを決める

この流れを作っておくと、AI の速さを使いながら事故率をかなり下げられます。

2026 年の開発で問われているのは、コードを速く書けるかではなく、AI が書いたコードを安全に運用へ持っていけるかです。

その意味で、いま必要なのは Vibe Coding の延長ではなく、Verify を前提にした設計だと感じています。

Source notes