バイブコーディングを発明した男が、もうその言葉を使うのをやめた。
2026年2月5日、Andrej Karpathyは「バイブコーディング」誕生から1年を機に、新しい言葉を提唱した。その名も「エージェンティック・エンジニアリング（Agentic Engineering）」。ただの言葉の言い換えではない。開発の哲学そのものが変わったのだ。
バイブコーディングを「発明」した男の転換
Karpathyが「バイブコーディング（Vibe Coding）」という言葉を初めて使ったのは2025年2月2日のX（旧Twitter）への投稿だった。「AIに全てを委ねてバイブ（雰囲気）だけで乗り切る新しいコーディングスタイル」と説明したその投稿は、670万回以上視聴された。
それからちょうど1年後の2026年2月5日、Karpathyは投稿した。「LLMははるかに賢くなった。バイブコーディングは今となっては時代遅れだ」と。
彼が選んだ新しい言葉がこうだ。
「99%の時間において開発者はコードを直接書かず、エージェントを統制し、監視役として機能する。そこにアートとサイエンス、専門的知見が伴う。個人的には『エージェンティック・エンジニアリング』という言葉が気に入っている」— Andrej Karpathy（The New Stack）
「エージェンティック（agentic）」とは「エージェント（自律的に動くAI）を使って動かす」という意味だ。「エンジニアリング」という言葉を意図的に残したのは、専門的な技術と判断が依然として必要だからだという。
バイブコーディングの何が問題だったのか
バイブコーディングは入口として優れていた。プログラミング未経験者でも「動くもの」が手に入る。Karpathy自身も、LLMが今ほど賢くなかった時代には合っていたと認めている。
では、何が問題なのか。
AI生成コードの45%にセキュリティ欠陥がある
Veracodeが2025年に発表した調査（GenAI Code Security Report）によると、AIが生成したコードの45%に1つ以上のOWASP Top 10（代表的なセキュリティ脆弱性のリスト）に該当する欠陥が含まれている。
特に深刻なのがXSS（クロスサイトスクリプティング——悪意のあるスクリプトをページに埋め込む攻撃）で、AIが生成したコードの86%でこの欠陥が確認された。ログを記録するコードに至っては88%が、外部からの入力を適切に処理していなかったという。
さらに重要なのはこの数字が改善していないことだ。同レポートでは、モデルの規模が大きくなってもコードの安全性は向上しないと指摘している。つまり、「AIが賢くなれば自然に解決する」問題ではない。
本番データベースが消えた
数字だけでは実感しにくいかもしれない。具体的な失敗事例を見よう。
自律AIエージェントを使っていたある開発者は、「クリーンアップが必要」と判断したエージェントによって本番データベースを削除された。Replitで起きた実際の事例だ。また、AIコーディングツールのWindsurfでは、プロンプトインジェクション（AIへの悪意ある命令の注入）によって長期記憶に不正な命令が書き込まれ、数ヶ月にわたるデータ窃取が続いたケースも報告されている（Vidoc Security Lab）。
バイブコーディングの本質的な問題は、「コードを確認しない」ことにある。動いているから良し。テストは書かない。AIが「完了しました」と言ったら信じる。この姿勢が、上記の事故を生む土壌になる。
エージェンティック・エンジニアリングとは何か
Googleのエンジニアリングディレクター・Addy Osmaniは、エージェンティック・エンジニアリングを次のように整理している。
「AIが自律的なマルチステップワークフローを処理する、一方で人間がアーキテクチャ・品質・正確さに責任を持つソフトウェア開発アプローチ」（addyosmani.com）
バイブコーディングとの最大の違いは、検証（テスト）を必ずやることだ。
PEVループ：三段階のサイクル
エージェンティック・エンジニアリングの核となる考え方が「PEVループ」だ（Addy Osmaniより）。
Plan（設計）: コードを書き始める前に、設計書や要件定義書を作る。「何を作るか」「何を作らないか」「どんな制約があるか」を明確にする。バイブコーディングが飛ばすのがここだ。
Execute（実行）: AIエージェントに明確なタスクを渡す。あいまいな指示ではなく、範囲が絞られた具体的な要件を与える。
Verify（検証）: AIが「完了」と言っても、そのまま信じない。テストを走らせ、コードレビューをする。テストが通るまでエージェントに修正させる。
このループを回すのが「現場監督」の仕事だ。設計図を書いて、職人（AI）に指示を出し、完成した箇所を検査して承認する。職人の作業そのものはAIに任せていい。でも検査をサボったら、欠陥住宅ができあがる。
バイブコーディングとの具体的な違い
言葉で説明するより、実際のプロンプトの違いを見たほうが分かりやすい。
コード例1：AIへの指示の質
ユーザー認証機能を作るとき、バイブコーダーとエージェンティック・エンジニアではこれだけ違う。
❌ バイブコーディング（雰囲気任せ）
ユーザー認証機能を作って
✅ エージェンティック・エンジニアリング（設計から始める）
## 要件定義
- JWTベースの認証（アクセストークン15分、リフレッシュトークン7日）
- パスワードはbcryptでハッシュ化（ソルトラウンド12）
- レート制限：5回失敗でアカウントロック（30分）
## 制約
- 既存のUserエンティティのスキーマを変更しない
- 環境変数はすべて.env.localで管理
- テストは必ず書く（正常系・異常系・境界値）
## 完了条件
- ユニットテストが全て通ること
- 不正なトークンで401が返ること
- 5回連続失敗でロックがかかること
「作って」の一言でも動くものはできる。でもレート制限がなければ総当たり攻撃が通り、有効期限の設定がなければトークンが永遠に有効になる。指示の質が、コードの品質を決める。
コード例2：テストに対する姿勢
AIが「完成しました」と返してきたとき、どうするか。
❌ バイブコーディング（確認なし）
AI: 認証機能を実装しました。
開発者: ありがとう。次はダッシュボードを作って。
✅ エージェンティック・エンジニアリング（検証してから先へ進む）
# テストを走らせる
bun test src/features/auth/
# 型チェック
bun run typecheck
# AI: ✅ 全テスト通過（17件）
# → 承認。次のタスクへ
テストが通るまでエージェントに修正させる。この一手間が、本番環境での障害を防ぐ。
2026年、プロの現場ではどうなっているか
「理論はわかった。でも本当に現場で使われているのか？」という疑問はもっともだ。
Anthropicが2026年1月に発表した「2026 Agentic Coding Trends Report」によると、開発者はすでに仕事の約60%でAIを活用している。一方で、AIに「完全委任」できているのは仕事の0〜20%に過ぎない。
また関連するAnthropicの「2026 State of AI Agents Report」では、57%の組織がすでにマルチステップのエージェントワークフローを導入済みだという。「AIに丸投げ」ではなく「AIを組み込んだプロセス設計」が、プロの標準になりつつある。
AIエージェント市場は2025年の78.4億ドルから2030年には526.2億ドルに成長すると予測されている（年平均成長率46.3%）。「流行で終わる技術」ではなく、産業として定着するフェーズに入っている。
どうすれば「エージェンティック」になれるか
バイブコーダーからエージェンティック・エンジニアへの移行は、ツールの変更ではなく習慣の変更だ。3つのことを変えるだけでいい。
1. コードを書く前に「設計書」を書く
AIに指示を出す前に、テキストで要件を整理する習慣をつける。箇条書きでいい。「何を作るか」「何を作らないか」「どう動けば完了か」の3点を書くだけで、AIへの指示の精度が劇的に上がる。
これは現場監督が職人に仕事を頼む前に、図面を確認するのと同じだ。口頭で「いい感じに」と言う現場監督がいたら、できあがりに文句は言えない。
2. AIの「完了」を鵜呑みにしない
AIが「実装しました」と言っても、それはAIの自己評価に過ぎない。実際に動かして確認する。テストコードがあればそれを走らせる。なければ、手動でも動作確認する。
「AIが言ったから大丈夫」という思考が、本番データベース削除の事故につながる。
3. テストを「面倒なもの」ではなく「エージェントへの指示書」として書く
テストの本質は「こう動けば正しい」という定義だ。テストがあれば、AIエージェントは「テストが通るまで修正する」という自律的なループを回せる。テストがなければ、AIは何が正しいかわからず、あなたが判断するしかない。
テストはAIを信頼するための道具だ。テストを書くほど、AIに委任できる範囲が広がる。
バイブコーディングは間違っていない。でも入り口に過ぎない
Karpathyがバイブコーディングを否定したわけではない。彼は「LLMがまだ未成熟だった時代には適切だった」と言った。入り口として機能した言葉だ。
でも今は違う。AIエージェントははるかに賢くなり、複雑なタスクを自律的に実行できる。だからこそ、人間が担う役割も変わった。
実装者からオーケストレーター（指揮者）へ。コードを書く人から、AI を指揮し、検証する人へ。
次のプロジェクトで、最初に設計書を書いてみよう。たった数行の箇条書きでいい。そこから始めると、AIへの指示が変わり、返ってくるコードが変わり、最終的に動くものの品質が変わる。
バイブは卒業。エンジニアリングが始まる。