💥バイブコーディングは終着点じゃない ──エージェントエンジニアリングの時代が来る前に備えておきたいこと

ちょっと気になるニュースを見かけました。それが次です。

「バイブコーディング」の名付け親、次は「エージェントエンジニアリング」だと語る→記事はコチラ

この記事で、かの「バイブコーディング」の名付け親である、アンドレイ・カーパシー氏が次の言葉を提唱しました。

「エージェントエンジニアリング」

「また新しいバズワードか」と思った人も多いかもしれません。ただ今回は少し違う気がします。これは技術の話というより、私たちの仕事の構造が変わるサインだと思えるからです。

そこで本記事では「エージェントエンジニアリングによって世の中がどう変わるか」を具体的に予想したうえで、それをどう受け止め、何を準備すべきかについて考えてみたいと思います。

🤖バイブコーディングとエージェントエンジニアリングの違いを整理する

簡単に言うとこうです。

• バイブコーディング → 人間がAIに指示して、コードを書かせる

• エージェントエンジニアリング → AIエージェントが、自律的に開発を進める

「似たようなものでは？」という感覚はよくわかります。でも実際に最近のAIツールを触っていると、この差がじわじわ見えてきます。

バイブコーディングは、あくまで
「人間が運転席にいて、AIが助手席でナビをする」イメージ
です。一方のエージェントエンジニアリングは、
「AIが運転を代わる」
に近い。タスクを渡すと、AIが自分でリポジトリを読み、コードを書き、テストし、修正する。その一連を、人間の逐一指示なしに進めます。

これがすでに実験的に起き始めています。

🤖バイブコーディングは「通過点」だった

「バイブコーディングって便利すぎ」と感じている人は多いと思います。自分もそうでした。でもこれは最終地点ではなく、実はただの通過点だとカーパシー氏は言っています。

その理由を少し説明します。

一般企業ではまだ本格導入されていない

バイブコーディングが話題になって久しいですが、実際のところ、多くの一般企業ではまだ積極的には取り入れられていません。なぜか。

一番大きな理由はブラックボックス問題です。

AIが生成したコードは、動いてはいる。でも「なぜこの構造になっているのか」「この変更を加えたときに何が壊れるか」が、人間側に見えにくい。特に既存システムとの連携や、長期にわたる保守を考えると、企業としてはリスクを感じて当然です。

「AIが書いたコードで問題が起きたとき、誰が責任を取るのか」という問いに、まだ答えが出ていない。これが普及を遅らせている実態です。

規模が大きくなると、途端に難しくなる

もう一つの問題はスケールの壁です。

2,000行程度のコードなら、バイブコーディングでもかなり対応できます。ちょっとしたWebアプリ、スクレイパー、自動化スクリプトなど、個人プロジェクトのレベルなら十分に使えます。

しかし、10万行規模のプロジェクトになると話が変わります。AIはコンテキストの限界があり、プロジェクト全体の構造を把握したうえで「今ここに変更を加えると、あそこに影響が出る」という判断ができません。部分的には動くコードを生成できても、システム全体の一貫性を保つのは苦手です。

つまりバイブコーディングは、「小さく速く作る」には強いが、「大きく長く育てる」には弱いという特性があります。

だから、次の段階が必要になってくる

この2つの限界——ブラックボックス問題とスケールの壁——を乗り越えようとするのが、エージェントエンジニアリングの文脈です。AIが自律的に動くだけでなく、説明できる形で、大きなプロジェクトでも整合性を保ちながら開発を進めることが、次の目標になっています。

バイブコーディングは、確かにAI開発の革命の第一歩です。でもそれはまだ入口であり、その先があります。だから、あくまでも今現在は「その先」への移行期だと考えておくのが懸命です。

では、その変化は、いつどれくらいのスパンで起こるのか。それを大胆に予測してみたいと思います。

📈【予測①】2〜3年以内に「自分でゼロから書く作業」は一部の職種でほぼ消える

これはかなり確実です。

CRUD実装、APIつなぎこみ、UIコンポーネントの量産、テストコードの生成——こういった「定型的な実装作業」は、2〜3年以内にAIエージェントがほぼ担うようになるはずです。

「いやいや、まだ先でしょ」

と思いたくもなりますが、すでにその片鱗が現れています。
CursorやClaude系ツールを使っている人であれば、「あ、これもう自分で書かなくていいな」という瞬間、確実に増えているからです。

たとえば、ユーザー登録・ログイン機能の実装を考えてみてください。フォームのバリデーション、パスワードのハッシュ化、JWTトークンの発行、エラーハンドリング——以前なら最低1〜2日はかかっていました。これが今やプロンプトひとつで雛形が生成され、数時間で動きます。これが「テストも含めて全自動」になる。2〜3年もかからないかもしれません。

勘違いしてほしくないのは、「エンジニアが不要になる」わけではないことです。あくまでも、作業の種類が変わる、という話であることを強調しておきます。

📈【予測②】「AIを動かす人」という役割が、独立した職能になる

エージェントエンジニアリングが普及すると、こんな逆説が起きます。

AI頼みになるほど、AIを設計・管理できる専門の人間が必要になる。

どのエージェントにどのタスクを渡すか、エージェント同士の役割をどう分けるか、出力の品質をどう担保するか、どこで人間が判断を挟むか——こういった「AIオーケストレーション」の仕事は、人間が担う必要があります。なぜなら、人間の感覚や文脈に根ざした判断は、どんなに突き詰めてもAIには完全には理解できないからです。

たとえばECサイトの開発を例にすると、「商品検索エージェント」「決済フローエージェント」「レコメンドロジックエージェント」をそれぞれ別に立て、それらの連携と品質チェックを人間が設計する、という形になっていきます。コードを書く量は減っても、どう分けて、どうつなぐかという設計の比重は上がります。

これは今のところ、エンジニアが兼務している作業です。でも数年以内に、独立したスキルセット・役割として認識されるようになると思います。

これが「エージェントエンジニアリング」という言葉の本質です。コードを書く技術ではなく、AIに仕事をさせる構造を設計する技術。

少し極端な例で考えてみます。エンジニアでもない経営者が「こんなことできるといいな」とざっくりした要望をAIに投げたとします。しかし、そこに設計思想がなければ、AIは困惑してちぐはぐなものしか生成できません。「ビルを建てて」と言われても、どんなビルを建てればいいか誰でも困るのと同じです。間に「鉄筋4階建てで、窓はこのサイズで、用途はオフィスで…」と具体化できる人間が必要なように、AIと要件の間を翻訳・設計できる人の役割が、これから一層重要になってきます。

📈【予測③】上流の仕事（設計・判断・責任）の価値が、相対的に上がる

AIがコードを書けるようになればなるほど、「何を作るか」「なぜ作るか」「どこまでやるか」という問いが、逆に重くなります。

アーキテクチャ設計、UX設計、セキュリティ判断、プロダクトの方向性——これらはAIには任せられません。AIは「作れ」と言われたものを作るのは得意ですが、「これを作るべきか？」という判断は持っていないからです。

たとえばセキュリティの話をすると、AIが生成した認証コードは「動く」ことは多い。でもそれが「この会社の個人情報の扱いとして適切か」「法令的に問題ないか」という判断は、AIには出せません。あるいはUX設計でも、「ユーザーがどこで迷うか」「このボタン配置が離脱につながるか」という感覚は、実際のユーザーを知っている人間の側にしかない。そういった判断の責任は、むしろ明確に人間に残ります。

つまりこういう構造になってきます。

$$
\begin{array}{|c|c|c|} \hline
\text{領域} & \text{AIの関与} & \text{人間の役割} \\ \hline
\text{実装・テスト} & \text{大きく増える} & \text{確認・判断のみ} \\ \hline
\text{AIの管理・設計} & \text{AIを使う側} & \text{構造設計が必要} \\ \hline
\text{設計・判断・責任} & \text{ほぼ入れない} & \text{むしろ価値が上がる} \\ \hline
\end{array}
$$

🤔この変化を、どう受け止めるか

ここが一番大事なところです。

よくある受け止め方は2つに分かれます。

「AIに仕事を奪われる」 と感じるか、「仕事の場所が変わる」 と捉えるか。

個人的には後者が実態に近いと思います。ただし、「場所が変わる」という変化は、準備なしに乗り越えられるものでもありません。気づいたら自分のいた場所がなくなっていた、という形で静かに進む可能性があります。

大事なのは「自分の仕事の中で、何がAIに置き換わりやすいか」を今から意識することです。置き換わる部分を嘆くよりも、その上流にあたる部分に少しずつ意識を移す。それだけで、立ち位置はかなり変わります。

🤔では、具体的に何を準備すればいいか

大きく転換する必要はありません。今やっていることの「解像度」を少し上げるだけでいいと思っています。

① AIを使い続けること（まず触れる）

当たり前に聞こえますが、一番効きます。

「まだ信用できない」という感覚は自然です。ただ、触らないまま距離を置くと、変化への感度がどんどん落ちます。完璧に信頼しなくていい。ただ、どこまでできるかを自分の手で確かめ続けることが、これからの判断力の土台になります。

具体的には、「今日やろうとしている作業を、まずAIに投げてみる」という習慣から始めるだけで十分です。うまくいかなかったとしても、「なぜうまくいかなかったか」がわかること自体が、貴重な経験になります。

② 自分の思考を「言語化する力」を鍛える

エージェントを動かすには、タスクを正確に言葉にする必要があります。これはプロンプトの書き方というより、問題を分解し、目的を明確にする力です。

ただし、言語化に向かないものがあることも知っておく必要があります。典型的なのがUIのレイアウト設計です。「使いやすく配置して」というプロンプトで出てくる結果は、往々にして「惜しいが違う」という状態になります。スライダーの位置、要素の上下関係、余白の感覚——こういうビジュアルの細部は、言葉で伝えるよりFigmaやAdobeXDなどのUIツールで自分が直接設計したほうが速いです。

言語化できるものはAIに任せ、言語化しにくいものは別のツールで補う。この「切り分け」ができること自体が、これからの重要なスキルです。

③ 「構造を見る習慣」をつける

実装の細部よりも、この機能はどこに置くべきか、データフローはどう設計すべきか、責務はどう分けるべきか——という問いに慣れておく。AIがコードを生成する時代ほど、「生成されたものが正しい構造に乗っているか」を判断できる人の価値が上がります。

たとえばAIが生成したコードをレビューするとき、「動くかどうか」だけでなく「このロジックはビジネス層に置くべきか、それともDB層か」「この処理は将来の仕様変更に耐えられるか」という視点で見られるかどうか。それが今後の差になってきます。

④ AIを「疑う力」も同時に持つ

AIが強くなるほど、「AIが言ったから正しい」という空気が出てきます。でも現場では、微妙に間違ったコード、セキュリティ的に危ういコード、保守性を無視した設計が混ざることがあります。

たとえばAIが生成したSQLクエリは、機能的には正しくてもインデックスを全く考慮していないために本番環境でパフォーマンス問題を起こすことがあります。また、ユーザー入力をそのまま受け取るコードを生成してSQLインジェクションの脆弱性を埋め込んでくることも珍しくない。動いているだけでは安全ではない、という感覚を持ち続けることが大切です。

使いこなす人ほど、疑える人である必要がある。 これは矛盾に聞こえますが、実際そうです。

⑤ 「先を予想する力」をつける

これは、AIが最も苦手とする領域の一つです。

AIは「今の仕様に対して正しいコード」を生成するのは得意です。しかし、「この設計が2年後にどう変わるか」を見越した実装は、まだ人間の経験に頼る部分が大きい。

たとえばデータベース設計を考えてみてください。現時点では必要ない項目でも、「将来的にこういう拡張が来そうだ」という予測のもとで、あらかじめフックになる列や分類コードの枠を用意しておく——これは経験のある人間にしかできない判断です。在庫管理システムなら、今は大カテゴリだけで十分でも、取り扱い商品が増えれば分類コードが細分化されることは容易に想像できます。そのとき初めから拡張できる設計になっているかどうかで、後から発生する改修コストは大きく変わります。

AIに「将来のことも考えて設計して」と指示することはできます。でも、その「将来」が何を意味するかは、その業界・その会社・そのプロダクトを知っている人間にしかわかりません。

先を読む力は、一朝一夕には身につきません。ただ、「今の設計がどんな変化に弱いか」を日頃から意識しておくことが、その第一歩になります。

💬まとめ：エージェントエンジニアリングは、仕事の「形」が変わるサイン

カーパシー氏が提唱した「エージェントエンジニアリング」というワードが定着するかどうかは、正直わかりません。ただ、この言葉が指している変化——AIが補助ツールから自律的な開発者へ移行しつつある——は、すでに静かに始まっているとみていいでしょう。

バイブコーディングは革命の入口でした。でもブラックボックス問題とスケールの壁によって、それだけでは限界がある。その先にエージェントエンジニアリングがあり、人間の役割はさらに「上流」へと動いていく。

コードを書く仕事がなくなるわけではない。でも、コードを書く「理由」と「場所」は確実に変わっていく。

その変化を先に知っておくことで、波に飲まれるのではなく、波を使う側に回れるはずです。

すでに、AIに仕事をさせている人は確実に増えていますが、AIの仕事をどう設計するかに到達している人は、まだわずかです。今から、来るべき時代を想定し、備えておくべきかと思います。

以上！

✨この記事を出した直後ビッグニュースを補足しました

書いた直後に、

「そのうちでしょ」が覆る出来事がありました。

タイミングが良すぎて、自分でも驚いています。

📖用語辞典

「用語が難しくて」とお嘆きの方のために用意したうれしい用語辞典です。

【ツール・サービス名】

Cursor AIとの対話機能を搭載したプログラミング専用エディタ（コードを書くソフト）。コードを書きながらリアルタイムでAIに質問・修正依頼ができる。バイブコーディングを手軽に試せるツールとして人気が高い。

Figma / Adobe XD 画面デザインを作るための専用ツール。ボタンの位置・余白・色など、言葉で伝えにくいビジュアルの細部を、直接ドラッグ＆ドロップで設計できる。AIに任せるよりこちらで直接作るほうが速い場面も多い。

JWT（JSON Web Token） ユーザーが「ログイン済みかどうか」を確認するための電子的な証明書のようなもの。ログイン後に発行され、以降のアクセス時に「本人確認」のために使われる。

【概念・手法】

バイブコーディング 「ノリ（Vibe）でコードを書く」という意味で、AIにざっくり指示してコードを生成させる手法。OpenAIの研究者アンドレイ・カーパシー氏が命名した。人間が「運転席」にいて、AIが「助手席でナビをする」イメージ。

エージェントエンジニアリング AIを「指示を受けて動くだけ」ではなく、「自律的に判断して動く」エージェント（代理人）として扱い、その動き方を設計・管理する手法。バイブコーディングの次の段階とされる。「AIが運転を代わる」イメージ。

ブラックボックス問題 AIが生成したコードは動いてはいるが、「なぜこの構造なのか」「どこを変えると何が壊れるか」が人間側に見えにくい問題。企業がAI開発の本格導入をためらう主な理由のひとつ。

スケールの壁 AIには「一度に覚えられる量（コンテキスト）」に限界があるため、2,000行程度は作れても10万行規模になると整合性が保てなくなる問題。小さく速く作るには強いが、大きく長く育てるには弱いというAIの特性から来る。

AIオーケストレーション オーケストラの指揮者のように、複数のAIエージェントや処理を統括・調整すること。「どのエージェントにどのタスクを渡すか」「エージェント同士の役割をどう分けるか」を管理する仕事を指す。

プロンプト AIへの「指示文」のこと。何をどう作ってほしいか、どんな条件で動いてほしいかを言葉で伝える入力文のこと。プロンプトの書き方ひとつで、AIの出力品質が大きく変わる。

上流工程 システム開発における「要件定義・設計・判断」など、実装（コードを書くこと）より前の段階の作業。アーキテクチャ設計、UX設計、セキュリティ判断などが該当する。AIが得意な実装とは対照的に、人間の判断や責任が特に重要な領域。

【技術用語】

CRUD Create（作成）・Read（読み取り）・Update（更新）・Delete（削除）の頭文字。データベース操作の基本4パターンを指す。「CRUD実装」はWebアプリ開発における最も定番の作業のひとつ。

API（エーピーアイ） 異なるソフトウェア同士が「会話」するための接続口のこと。「APIつなぎこみ」とは、外部サービスのデータや機能を自分のアプリに組み込む作業を指す。

リポジトリ プログラムのコードや変更履歴をまとめて保存・管理する場所。Gitというバージョン管理ツールと組み合わせて使われることが多い。「倉庫」や「本棚」のようなイメージ。

フォームバリデーション ユーザーが入力フォームに入力した内容が正しいかどうかをチェックする処理。「メールアドレスの形式が正しいか」「必須項目が空になっていないか」などを自動確認する。

パスワードハッシュ化 パスワードをそのまま保存せず、元には戻せない特殊な文字列に変換して保存すること。万が一データが流出しても、元のパスワードがわからないようにするセキュリティ対策。

SQLクエリ / インデックス SQLはデータベースを操作するための専用言語。クエリはその「命令文」のこと。インデックスは「目次」にあたる仕組みで、これがないと大量のデータの中から目的の情報を探すのに時間がかかる。

SQLインジェクション 悪意のあるユーザーが入力欄に不正なSQL命令を紛れ込ませ、データベースを不正操作する攻撃手法。AIが生成したコードに対策が漏れることもあるため、確認が必要。

UIコンポーネント Webアプリの画面を構成するパーツのこと。ボタン・フォーム・カード・メニューなど、再利用できる形で部品化された画面要素を指す。

アーキテクチャ設計 プログラム全体の「設計思想・構造」を決めること。建物の設計図に例えられる。どのように機能を分けるか、データはどう流れるかを定めるもので、AIには任せにくい人間の重要な判断領域。