最近のコードレビュー、しんどくないですか。

昔のレビューは「この実装は遅い」とか「責務がズレている」とか、わりと人間っぽい癖を読む仕事だった。いま増えたのはもっと嫌なやつで、ぱっと見は整っているのに、ビジネスロジックだけ静かに壊れている差分です。

型は通る。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 年のシニアは、もうタイピストではないです。運行管理者です。

Source notes