ここ数か月でいちばん変わったのは、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 を前提にした設計だと感じています。