4月のある水曜日、僕はキーボードから手を離した。
正確に言うと、離さざるを得なかった。Cursor に投げたタスクの diff を 3 時間レビューし続けて、途中で「あれ、今日僕は 1 行もコードを書いていない」と気付いた。
去年までは「書いた量」がその日の満足感だった。2000 行書いた日は充実していたし、100 行の日は物足りなかった。プログラマーとして当たり前の感覚だった。
その感覚が壊れた。
Vibe Coding の残骸
2025 年は「Vibe Coding」の年だった。意図を伝えれば AI がコードを吐く。Cursor や Claude Code にプロンプトを投げれば、動くものが数分で立ち上がる。本当に気持ちよかった。
だが気持ちよさには代償がある。
年末から今年にかけて、僕のチームは去年「バイブスで」量産したコードの保守に追われた。レビューもそこそこにマージしたコンポーネントが、本番環境で変な壊れ方をする。エラーハンドリングが雑、アクセシビリティの考慮がゼロ、依存パッケージのライセンスが確認されていない。どれも「動く」段階では見えない問題ばかりだ。
業界ではこれを「AI Slop」と呼ぶようになった。AI が吐いた、一見まともだけど中身がスカスカなコード。美しくフォーマットされていて、テストも通る。でも半年後にバグ調査で開くと「誰がこれを書いた？」となるやつ。答えは「去年の僕が、AI にバイブスで書かせた」だ。
正直に言う。恥ずかしかった。
70/30 にたどり着くまで
「Vibe Coding」は死語になった。2026 年に残ったのは「Vibe & Verify」だ。
言葉にすると当たり前に聞こえる。AI が書いたコードを人間が検証する。それだけだ。だがこの「それだけ」を本気でやろうとすると、時間の使い方が根本から変わる。
今の僕のプロジェクトでは、開発時間の 70% を検証に使っている。仕様の定義、テスト戦略の設計、コードレビュー、アクセシビリティの確認。残りの 30% が AI による実装だ。
最初はこの比率に違和感があった。7 割も「書かない時間」に使うのか？ でも 2 ヶ月回してみて、Day 2（運用フェーズ）のバグが激減した。AI Slop が main ブランチに入る頻度が減ったからだ。
検証というのは、単に画面を触って「動いた」を確認する作業じゃない。この diff をマージしたとき、半年後にこのコードベースを開いた誰かが頭を抱えないか。ライセンスは大丈夫か？ セキュリティホールはないか？ そういう、地味だが致命的な観点を 1 個ずつ潰していく作業だ。
つまらない仕事に見える。でもこのつまらなさが、去年の僕に欠けていたものだった。
MCP の沼にハマった話
もう 1 つ、今年に入ってから嫌というほど思い知った問題がある。MCP Server Sprawl だ。
Model Context Protocol が標準化されて、エージェントは何でも触れるようになった。Slack、Figma、Jira、ローカルのファイルシステム、社内の API、SaaS。便利だ。便利すぎる。
プロジェクトに MCP サーバーを 7 つ繋いだことがある。最初は「全部アクセスできたほうが便利じゃん」と思っていた。甘かった。エージェントが Figma のデザイントークンを勝手に読みに行って、古いコンポーネントライブラリの命名規則に引きずられた CSS を量産し始めた。Jira のチケットを読んで、もう Close された仕様に基づいてコードを書いた。
コンテキストが広すぎると、AI は「正しそうだけど間違っている」ものを出してくる。これが一番タチが悪い。明らかにおかしければ気付けるが、もっともらしく間違っているものを見抜くのは、人間でもかなり難しい。
結局、MCP サーバーを 3 つに絞った。残した理由は「このエージェントが本当に必要とする情報源はどれか」を精査した結果だ。
「100x Engineer」という言葉があった。いまシニアに求められているのは「100x Orchestrator」だと思う。エージェントが走るための線路を敷く仕事。どの MCP にアクセスさせるか、コンテキストをどう絞るか。これはコードを書く仕事ではない。でもコードが読めない人間にはできない仕事でもある。
AI の出力は全部「生もの」だ
コードだけじゃない。
ドキュメント用の図版、デモ画像、README に貼るスクリーンショット。最近は全部 AI に作らせている。Gemini で UI モックアップを出すことも増えた。
で、生成画像をそのままドキュメントに貼ると、後で困る。Gemini の画像にはデフォルトで透かしが入っているからだ。
「検証用ならいいでしょ」と放置していたら、3 週間後に「この画像は本番素材か仮素材か」がわからなくなった。Issue のスクリーンショットにも透かし付きの画像が混じっていて、レビュワーが「この UI は実装済みなのか Gemini の出力なのか」で混乱する場面があった。
笑い話みたいだが、AI の出力が増えるほど、この手の管理コストは無視できなくなる。
透かしの除去自体は、技術的にはそこまで難しくない。Gemini の透かしはアルファ合成で画像に載せられている。合成パラメータが既知なら逆アルファブレンディングでピクセル単位の復元ができるし、もう少し汎用的にやりたければ LaMa のようなインペインティングモデルを ONNX Runtime でブラウザ内推論させる手もある。Gemini の透かしを削除するオンラインツールは両方のアプローチを載せていて、画像がサーバーに送られない設計になっている。問題の構造を見て重い方法を持ち出さない判断と、ローカル完結の設計思想は、最近の開発ツールと通じるものがある。
ただ、ここで言いたいのは個別のツールのことじゃない。もっと手前の話だ。AI が吐いたものは、コードであれ画像であれ文章であれ、全部「後処理」が要る。コードなら lint と test を通す。画像なら透かし除去と命名規則。文章ならレビュー。この後処理をパイプラインとして仕組み化できるかどうかが、Vibe & Verify の「Verify」の実態だと僕は思っている。
「マージしていいか」を判断する覚悟
コードを生成するだけなら、もう AI のほうが速い。去年の僕もそれは認めていた。
でも去年の僕は、その先を考えていなかった。AI は本番障害の責任を取れない。セキュリティインシデントの報告書を書けない。ライセンス違反で訴えられたとき法廷に立てない。
2026 年のシニアエンジニアの仕事は、「この diff を main にマージしていいか」を判断し、その判断に対して責任を持つことだと思っている。
実装力の定義が変わった。タイピングの速度でも、アルゴリズムの知識でもない。「マージボタンを押す覚悟」のことだ。
「実装を捨てた」と書くと語弊がある。捨てたのではなく、委譲した。AI に。そして委譲した分だけ、品質を保証する責任が人間の側に重くのしかかってきた。
去年より仕事は楽になっていない。むしろしんどい。でも「何をすべきか」の輪郭は、はっきり見えるようになった。
僕はもう、コードの量で 1 日を測らない。