最近のコードレビュー、しんどくないですか。
昔のレビューは「この実装は遅い」とか「責務がズレている」とか、わりと人間っぽい癖を読む仕事だった。いま増えたのはもっと嫌なやつで、ぱっと見は整っているのに、ビジネスロジックだけ静かに壊れている差分です。
型は通る。Lint も通る。テストも一部は通る。でも、本番に出すと微妙に事故る。しかも犯人は明確で、AI が 99% 合っていて 1% だけ外してくる。
この 1% を拾う仕事が、2026 年のシニアの本体になってきた。
2月ごろから Agentic Engineering という言い方が広がり始めたけれど、自分はこれを単なる言い換えだとは思っていません。Vibe Coding の延長ではあるけれど、現場で求められる責任の置き場所がかなり変わったからです。
Vibe Coding が悪いわけではない
これは先に切り分けておきたいです。
Vibe Coding 自体は強い。雑に UI を立てる。新規画面の雛形を出す。管理画面の CRUD を先に作る。そういう仕事ではいまでもかなり効きます。
自分も普通に使います。ゼロから手で書くより速い場面は多い。
ただ、そのまま本番運用に持ち込むと急に苦しくなる。
- 変更範囲が広がる
- 既存の責務分離を平気でまたぐ
- 命名は自然なのに設計意図はズレる
- 例外系だけ人間に押し付けてくる
このへんは、使っている人ならたぶん一度は踏んでいるはずです。
問題は AI がコードを書くことではなく、AI に何を壊してはいけないかを渡していないことです。
いま必要なのは「うまいプロンプト」より「壊れにくい路線図」
2025 年の空気だと、AI コーディングのコツはプロンプト職人芸に寄りがちでした。けれど 2026 年の現場で効くのは、そこではないです。
効くのは、作業前に路線図を置くことです。
たとえば自分は、いきなり「請求フォーム直して」みたいな依頼はほぼ投げません。最初に書くのはだいたいこういうものです。
# Task Contract
目的:
- 請求フォームの送信処理を整理する
触ってよい範囲:
- src/features/billing/**
- src/shared/form/**
触ってはいけないもの:
- API レスポンスの型定義
- ルーティング構造
- 共通 UI の公開 props
完了条件:
- pnpm lint
- pnpm exec tsc --noEmit
- pnpm test
これだけでかなり変わります。
AI は賢くなったけれど、まだ普通に越境する。だから最初に「どこまでなら暴れていいか」を決めておく必要がある。
ここを雑にすると、あとでレビューにかかる時間が一気に増えます。
シニアの仕事は「実装」から「運行管理」に寄っている
ここがいちばん大事です。
AI エージェントが普及してから、シニアの価値はコード速度では測りにくくなりました。むしろ次の 4 つで差が出るようになっています。
- 変更境界を切れるか
- 失敗条件を先に言語化できるか
- 検証ループを短く作れるか
- 最後にマージしていい差分か判断できるか
要するに、実装者というより運行管理者です。
どの列車をどこまで走らせるか。脱線しそうならどこで止めるか。ポイント切り替えを誰が握るか。いまのシニアはこの仕事をやっている。
少し前までは「AI に全部書かせるか、人間が書くか」の二択っぽく見えた。でも実際はそうではなくて、AI に書かせる量が増えたぶん、人間が設計するべき制約も増えただけです。
Near Miss はバグというより運用事故
AI 由来の嫌な差分って、派手に壊れないことが多いです。
むしろ怖いのは Near Miss です。
- 税率計算の分岐が 1 ケースだけ古い
- 管理者だけ通るはずの導線が一般ユーザーでも通る
- null の扱いが 1 画面だけ微妙に違う
- optimistic update が失敗時に巻き戻らない
こういうのは構文レビューでは取りにくい。人間の「意味を見る力」が必要になる。
だから、2026 年のレビューで見ているのはコードの綺麗さより先にこの 3 つです。
- この変更は何を守るべきか
- どの条件で壊れるか
- 壊れたときに検知できるか
AI が書いた差分に対して「なんかいい感じ」ではもう危ない。見た目の整い方だけで安心すると、あとで必ず返ってきます。
CLAUDE.md や .cursorrules はメモではなく設計ファイル
ここも誤解されやすいところです。
CLAUDE.md や .cursorrules やプロジェクトのエージェント設定を README の補助資料みたいに置いているチームは多いです。でも、あれはもはやメモではないです。実質的には設計ファイルです。
たとえば最低限でも、これくらいは固定しておいたほうがいい。
# Agent Rules
- 新規 UI は src/components/ui を優先して再利用する
- any を追加しない
- API 型の正は src/schema に置く
- 副作用を持つ変更では必ずテストを追加する
- 変更後は pnpm check を通す
- 例外的に守れない場合は理由を差分内に残す
ポイントは、理想論を書かないことです。
チームの美学を全部書くと読まれません。AI は長文ルールを読んでくれるように見えて、現実には重みづけが安定しない。だったら「破ると事故るルール」だけを先に固定したほうがいい。
5 個から 8 個くらいで十分です。
VDD っぽく考えるとかなり安定する
最近しっくりきているのは、TDD をそのまま神格化することではなく、Verification Driven Development っぽく組み直すことです。
人間が先にやるべきなのは、実装ではなく検証条件を書くことです。
たとえばフォーム改修なら、先に欲しいのはコードではなく次の情報です。
type DoneWhen =
| "既存の請求作成フローが壊れない"
| "割引コード未入力でも送信できる"
| "法人請求時のみ companyName が必須"
| "エラー時に toast と field error の両方が出る";
この粒度が決まると、AI に書かせること自体はそんなに難しくないです。逆にここが曖昧なまま実装を始めると、生成は速いのに受け入れが終わらない。
AI 時代に再評価されているのは、テストコードそのものより「検証条件を先に固定する習慣」だと思っています。
ブラウザや DB を触れるエージェントほど、承認フローの設計が効く
MCP 経由でブラウザや外部ツールに触れるワークフローは、正直かなり便利です。Claude Code もそうだし、CLI 系のエージェントもどんどんそこに寄っている。
ただ、便利になったぶん、権限まわりをふわっと運用すると怖い。
自分はこの手の作業を 3 段階に分けています。
1. 読み取りだけは広めに許可する
- リポジトリ読み取り
- ローカルドキュメント参照
- ブラウザ確認
2. 書き込みは作業領域を限定する
- 変更可能ディレクトリを絞る
- 生成ファイルの命名規則を決める
- 破壊的コマンドは禁止にする
3. 外部副作用は必ず承認を挟む
- DB 更新
- Git push
- 本番 API 叩き
- 課金系の操作
この区切りがあるだけで、エージェントの便利さをかなり安全に使えます。
AI の性能より先に、承認フローの雑さで事故る。これは今年かなり増えると思う。
明日から変えるなら、この 3 つでいい
全部いきなりやる必要はないです。まずは次だけで十分変わります。
1. AI に頼む前に「変更境界」を書く
自由度を上げるより先に、越境禁止ラインを引く。
2. pnpm check みたいな共通ゴールを作る
Lint、型チェック、テストをばらばらに指示するより、1 本の完了条件にまとめる。
{
"scripts": {
"check": "pnpm lint && pnpm exec tsc --noEmit && pnpm test"
}
}
3. レビューでは構文より意味を見る
「綺麗に書けているか」より「壊してはいけない条件を守っているか」を先に見る。
これだけでも、AI に振ったタスクの歩留まりはかなり変わります。
まとめ
Vibe Coding は入口としてはいまでも強いです。速いし、楽しいし、試作フェーズでは本当に助かる。
でも、2026 年のシニアに必要なのは、その先です。
AI に実装させる能力より、AI が迷わない環境を作る能力。AI が壊したときにすぐ止める能力。最後にその差分を本番へ流していいか判断する能力。
この仕事は地味です。コードを書いている感も薄い。
ただ、現場でいちばん効くのはたぶんここです。
だから自分は、これから価値が上がるのは「たくさん書ける人」より「安全に走らせられる人」だと思っています。
2026 年のシニアは、もうタイピストではないです。運行管理者です。