エージェント型エンジニアリングとは、AI エージェントの支援を受けたソフトウェア開発の規律あるスタイルを指す用語である。このスタイルでは、人間がプロンプトを書く前に計画や仕様を書き、範囲が明確に定められたタスクについて AI エージェントに指示を出し、その出力を人間のチームメイトのプルリクエストに適用するのと同じ厳密さでレビューし、徹底的にテストし、出来上がったシステムのアーキテクチャ、正しさ、長期的な保守性に責任を持ち続ける。Andrej Karpathy が 2026 年 2 月初めにこの用語を提案し、Addy Osmani がこの記事で、その規律ある実践の名前として採用した。これは「バイブコーディング」とは区別される。バイブコーディングは廃止されるのではなく、本来の意味（Karpathy 自身が 1 年前に造語した、意図的に無謀でレビューを伴わない AI 駆動のワークフロー）を保つ。また、同じ規律ある到達点に対して Simon Willison が先に提案していた「バイブエンジニアリング」とも区別される。
用法
Karpathy 自身がこの用語で何を意味しているかについての説明は、彼が Sequoia Ascent 2026 で行った炉辺談話に由来し、Sequoia Ascent 2026 のまとめ にまとめられている。彼はこれをバイブコーディングと並べ、正反対の一対の動きとして位置づけている。バイブコーディングは下限を引き上げ、ほとんど誰もが欲しいものを説明するだけでソフトウェアを作れるようにする一方、エージェント型エンジニアリングは上限を押し広げる。彼がこれをエンジニアリングの規律と呼ぶのは、この用語が指す問題が調整だからである。エージェントは誤りを犯しうる確率的な存在だが極めて強力であり、問題は品質の基準を下げずにそれらを使ってより速く進むにはどうすればよいかである。責任は移らない。彼の説明では、あなたは依然として自分のソフトウェアに責任を負い、バイブコーディングをしていたからといって脆弱性を持ち込むことは許されない。彼は、バイブコーディングはプロトタイプや個人用ツールには問題ないが、真剣なチームに必要なのはエージェント型エンジニアリングだと明言しており、上限は高いと見込んでいる。かつての「10x エンジニア」という数字は、これに非常に長けた人がどこまで行けるかを過小評価している、と彼は論じる。
彼の語るところでは、この実践の中身は、生成されたコードを受け入れることではなく、仕様を設計し、計画を監督し、diff を精査し、テストを書き、評価ループを構築し、権限を管理し、ワークツリーを分離し、品質を保つことである。彼は人間の貢献を、記憶ではなく判断に位置づける。テンソルライブラリがどのキーワードを使うかはエージェントが覚えているが、人はストレージ、ビュー、メモリコピー、不変条件、同一性、セキュリティ境界を理解していなければならない。彼が挙げる具体例は自身のプロジェクトのひとつで起きた決済のバグで、エージェントは、メールアドレスが異なりうる 2 つのサービスをまたいで、購入とアカウントをメールアドレスで照合していた。コードはもっともらしく、システム設計が誤っていたのであり、それに気づくには永続的なユーザー ID を使うよう強く求めるべきだと知っている必要があった。彼はまた、この実践が採用のあり方を変えるべきだと論じ、小さなコーディングパズルに代えて実際の仕事に近いものを課すことを提案する。すなわち、エージェントを使って相当規模のプロジェクトを構築し、デプロイし、セキュアにし、そのうえで敵対的なエージェントにそれを壊させてみる、というものである。
このまとめの文章は、イベントのトランスクリプトからモデルが生成し、それを Karpathy が確認したものであるため、上の記述は彼の発言を再構成したものであって、逐語的な記録ではない。
この用語は、「バイブコーディング」が根本的に異なる 2 つの活動、すなわち本来の無謀なプロトタイピングという意味と、人間の監督を伴う規律あるエージェント支援開発の両方に当てはめられるのを止めるために提案されている。エージェント型エンジニアリングは、Osmani が現在その規律ある到達点に対して好んで使う名前である。これは、彼が以前「AI 支援エンジニアリング」と呼んでいたのと同じ到達点であり、Willison が「バイブエンジニアリング」と呼ぶことを提案していたのと同じ到達点でもある。そしてそれは、スペクトラムの無謀な端にあるバイブコーディングと対比される。バイブコーディングはコードレビューを伴わず、素早いプロトタイプを目指すのに対し、エージェント型エンジニアリングとは、アーキテクチャ、品質、正しさについて人間が責任を持つもとで AI が実装を担うことを意味する。実際には、出典はこれを次のように説明している。プロンプトを書く前に書面の計画や仕様から始めること、範囲が明確に定められたタスクについてエージェントに指示を出し、その出力を人間の PR と同じ厳密さでレビューすること、徹底的にテストすること（しっかりしたテストスイートこそが、エージェントが壊れたコードを「完了」と宣言するのではなく、信頼できる結果へと反復していけるようにするものだからである）、そして人間がドキュメント、バージョン管理、CI、本番環境の監視に責任を持ち続けることである。
この用語についての第二の独立した説明はエージェント型ソフトウェア：AI エージェントはソフトウェアのパラダイムをいかに再構築しているか に由来し、上の説明とは別のものについて述べているため、区別しておく価値がある。ブログの説明がコーディングエージェントに指示を出しレビューするという規律ある人間の実践を述べているのに対し、この論文はエージェント型エンジニアリングを分野として扱う。すなわち、ソフトウェアエンジニアリングという学問分野の拡張であって、その中心的な研究対象は静的なソースコードではなくエージェントシステムであり、その制御モデルは人間があらかじめ定めたものではなく LLM 駆動であり、その人間の役割はコードの作者ではなく意図のアーキテクトである。論文は、この意味でのこの用語の正式な導入を 2026 年 4 月の LangChain に帰しており、それを、AI エージェントがデジタルなチームメンバーとして機能するマルチエージェント協調モデルとする定義を引用している。そこでは各エージェントが定められた役割、共有メモリ、統一された可観測性レイヤーを持ち、単にコードをより速く生成するのではなく、デリバリーパイプライン全体を通してソフトウェアを推し進める。論文自身の主張は、エージェントもそれ自体がソフトウェアであるため、これはソフトウェアエンジニアリングを置き換えるのではなく拡張するものであり、エージェントシステムの構築・デプロイ・統治がこの分野の次のフロンティアである、というものである。
直接読んでみると、この説明が引用している LangChain の記事は、分野の定義よりも狭いものである。エージェント型エンジニアリング：AI エージェントの群れはソフトウェアエンジニアリングをどう再定義しているか は Cisco のエンジニア 2 人によるゲスト投稿で、特定のリファレンスアーキテクチャを提案している。一方には疎結合の Worker Agent があり、これは個々のコントリビューターのデジタルな対応物と説明され、意図を解釈し、ソースリポジトリ、イシュートラッカー、ログからコンテキストを収集し、ツール、コーディングエージェント、サブエージェントを通じて実行し、結果を検証し、計画・行動・結果を上位に報告する。もう一方には Leader Agent があり、これはプロジェクトリーダーのデジタルな類似物で、共有のプロンプトとワークフローのライブラリ、共通のツールゲートウェイ、スウォームのための長期記憶、グローバルな可観測性、そしてエージェントが何を生み出すかだけでなくいつ、どのように行動するかのオーケストレーションを提供する。著者たちはこの構成を、AI コーディングエージェントに対抗するものではなく、明示的にその上位に置いている。Codex クラスのモデルは、推論やコード生成のエンジンとして Worker Agent の内部に組み込まれるものとして説明されており、その論拠は、コーディングエージェントは範囲の限られたユーザー主導のループの中で意図をコードに変換することには優れているが、チームをまたぐワークフローをオーケストレーションする能力には限界がある、というものである。彼らのパイロットは 2 つの別々の改善を報告している。20 以上のデバッグワークフローにおいて、過去のデバッグ時間と比べて根本原因の特定までの時間が 93% 短縮されたと測定しており、チームをまたぐいくつかの調査は、エージェントの協調実行によって 5 分未満で完了した。15 以上の開発ワークフローにおいては実行時間が 65% 以上短縮されたと測定しており、この 2 つ目の数字について彼らは、より速いコード生成（これは AI コーディングエージェントがすでにうまくこなしていると彼らは言う）ではなく、PR マージ後の下流の機能テストを圧縮したことによるものだとしており、その結果として PR のレビュープロセスそのものがボトルネックになったと述べている。これらの測定は著者たち自身が自らのデプロイについて行ったものであり、そのベースラインは彼らのエンジニアリングチームが社内のブートキャンプで過去の証拠からまとめたものである。
この論文は、2 つの実践を 9 つの次元にわたって対比している。中核となる成果物は静的なソースコードから動的なエージェントシステムへ、制御の中心は人間のエンジニアから LLM の推論エンジンへ、意思決定のメカニズムはあらかじめ設計されたロジックから実行時に生成される推論へ、開発サイクルは線形の設計・コーディング・テストから自律的な反復ループへ、人間の役割はコードの作者から意図のアーキテクト、コーディネーター、監査者へ、複雑さの上限は固定された人間の認知からモデルの容量へ、出力の単位は機能するソフトウェアから提供される成果へ、エラー処理はプログラマーが定義するものからモデルが適応するものへ、進化は手動のリファクタリングから自己修正へと移る。論文は、新たな人間の差別化要因として、意図の明確化、アーキテクチャの監督、品質の較正、倫理的ガバナンスを挙げている。
第三の説明は Andrew Connell によるもので、この用語を 1 文の定義で述べたうえで、その分量の大半を対比に費やしている。エージェント型エンジニアリングとは、AI を活用したコーディングエージェントをあなたの指揮のもとで力の増幅装置として使いつつ、アーキテクチャ、コード品質、エンジニアリング上の判断に対する完全な責任をあなたが保持する実践である。これは上で述べた分野レベルの意味ではなく規律ある実践という意味に一致しており、しかも反対側から到達している。この記事は、バイブコーディング が何ではないかについての議論として構成されており、両者は表の形で示され、その行は、誰のためのものか、コードがレビューされるかどうか、リスクの水準、最適な用途、エンジニアリング上の判断がどこにあるか、保守性が優先されるかどうか、である。
Connell がエージェントに割り当てる仕事は、設計ではなく単調で退屈な部分である。彼の4 つの例は、長くて読みにくいファイルをより小さなモジュールに分割すること、とりわけ大規模なリファクタリングの前に最初のテストカバレッジとエッジケースを生成すること、チームメイトが見る前にエージェントにプルリクエストのバグ、セキュリティ上の問題、不整合をレビューさせること、そしてフレームワークのアップグレードやライブラリの移行に伴う反復的でパターン化された変更を任せ、厄介なエッジケースは開発者が引き受けること、である。彼がこの関係を表すのに用いるイメージは料理長と副料理長であり、エージェントは熟練していて有能で速いが、メニューを決めるのはエージェントではない。
第四の説明は Simon Willison によるもので、この用語を習慣の集まりではなく能力に結びつけている。彼は、コーディングエージェントの支援を受けてソフトウェアを開発する実践をエージェント型エンジニアリングと呼び、コーディングエージェントを、コードを書くことと実行することの両方ができるものと定義する。そして彼はこの実行の部分こそが要だとみなす。コードの実行こそが、この実践をそもそも可能にするものである。生成したものを実行する能力がなければ LLM が出力するものの価値は限られるが、それがあればエージェントは実証的に動作するソフトウェアに向けて反復していける。彼の定義は、さらに AI エージェント の定義、すなわち目標を達成するためにツールをループで実行するソフトウェアという定義に基づいており、コードの実行はそのツールのひとつにすぎない。彼のガイドエージェント型エンジニアリングのパターン を紹介する記事で、彼はここから導かれる性質を付け加えている。エージェントは、人間の監督者からの逐一の指示とは独立にテストし、反復できる、という性質である。
人間に何が残されるのかという問いに対する彼の答えは、この技能はそもそも最初からコードを書くことではなかった、というものである。それは、どんなコードを書くべきかを見極め、あらゆる問題に対して考えられる何十もの解決策とそのトレードオフを検討し、目の前の状況に合うものを見つけ出すことだった。彼がこの実践に割り当てる仕事は、エージェントに必要なツールを与え、問題を適切な詳細度で指定し、結果が堅牢で信頼に足るものになるまで検証と反復を行うことである。彼はまた、学習がどこで起こりうるかについて区別を設けている。LLM は過去の誤りから学ばないが、コーディングエージェントは学ぶことができる。ただしそれは、学んだことを反映するように指示やツールのハーネスが意図的に更新される場合に限られる。彼が述べる見通しは、うまく使えばこの実践によって人々は取り組む対象についてより野心的になれ、より影響の大きい問題に対して、より多くのより良いコードを生み出せる、というものである。
Willison はこの用語を バイブコーディング と単一の尺度の上で対置しており、本来の意味でのバイブコーディング、すなわちコードにまったく注意を払わないことを一方の端に、既存の専門性を増幅するプロのエンジニアをもう一方の端に置いている。彼はまた、この尺度が保たれていないことを最も明確に報告している出典でもある。バイブコーディングとエージェント型エンジニアリングが、望む以上に近づいている で彼は、エージェントがすべての行をレビューしなくてもよいほど信頼できるようになるにつれて、自身の仕事の中で両者が収束しつつあると述べ、その結果生じる関係を、他のチームのサービスを扱うのと同じようにエージェントを扱うこととして捉えている。ただし、チームには説明責任を負わせることができるがエージェントにはできない、とも指摘している。
第五の説明は定義ではなく実践者の報告であり、ここで挙げるものの中で唯一、英語圏の議論の外から書かれたものである。本当に「ポチッ」で全部できるのか？ — 保守的な開発者が AI エージェントでプロダクトをリリースして気づいたこと は、著者自身がコーディングエージェントを使ってコミュニティサイトをリリースした経験を、バイブコーディング ではなくこの用語のもとに位置づけ、名前の 2 つの部分を次のように説明している。エージェント型は、開発者が自らコードを書く代わりに、コードを書くエージェントを管理・監督することを意味し、エンジニアリングは、そのプロセスが学び、身につけていかなければならない専門性を要求することを意味する。この説明は、この一対の用語をどちらも Karpathy に帰して 1 年の間隔で年代づけており、バイブコーディングを 2025 年 2 月初め、エージェント型エンジニアリングを 2026 年 2 月初めとしている。そしてその後に出典の明示されていない引用ブロックを続けており、その配置からは彼の言葉と読める。その内容は、LLM エージェントを使うことの恩恵がソフトウェアの品質を犠牲にして得られるものとならないよう、エージェントがどこへ向かっているかを厳格に監督し検証することが必要だ、というものである。
この説明が定義を超えて付け加えているのは、このやり方で仕事をすることで到達した 3 つの立場である。1 つ目は節約すべき資源についてのもので、開発者の認知的なフローが中断されることのコストは節約されるトークンよりも大きいという理由から、トークンを節約することに反対し、著者が月額 100 ドルのプランへのアップグレードを出費ではなく投資と捉えたことを報告している。2 つ目はそこから導かれ、姿勢の変化として述べられている。エージェントをコード生成器としてではなく、問題について推論し解決する存在として扱い、デバッグを自分の手に取り戻すのではなく、エラーログや失敗しているテストをそのまま丸ごと渡す。開発者の役割は、適切なコンテキストを与え最終判断を下すディレクターのそれである。3 つ目は、エージェントが書いたコードを信頼できるものにするのはテストコードであり、テストが守るべきものはロジックを超えて、アーキテクチャ、最低限のカバレッジの閾値、テストパイプラインにおける静的解析にまで及ぶ、というものである。この説明の理由づけは、テスト結果はチームが意図する方向性をエージェントに伝える最も明確な手段のひとつであり、ドキュメントよりも明示的で、選択肢を狭めすぎることなくガードレールとして機能する、というものである。
最後にこの説明が示す立場は、責任がどこにあるかについてのものである。AI は仕事のおよそ 80% をカバーするとされ、残りの細部と結果に対する責任は人間に残される。エージェントは多くの答えを提示できるが、特定のサービスのコンテキストに合うものを選ぶことは、それを経験してきた開発者にしかできず、AI は責任を取らない。この説明は、ひとつのプロジェクトについての一人の開発者の経験であり、講演をもとに AI の助けを借りて書かれたもので、測定は報告していない。
適用される場面
出典は、エージェント型エンジニアリングが、既存の強固な基礎（システム設計、セキュリティのパターン、パフォーマンスのトレードオフ）を持つエンジニアに不釣り合いなほど大きな恩恵をもたらすものと位置づけている。良い AI の出力を見分けるには、良いコードがどのようなものかをすでに知っている必要があるからである。また、テストは信頼できないエージェントを信頼できるシステムに変えるメカニズムとして説明されているため、それを支えるテストスイートが整っていることを前提としている。出典が述べる失敗モードは、ジュニアエンジニアがそうした基礎を築く前に AI に頼ってしまい、スキルの萎縮を招く危険、すなわち理解することもデバッグすることもできないままコードを生み出し出荷してしまうことである。この記事の時点では、この用語は定着した用法ではなく、提案されたばかりで活発に議論されている段階のものとして提示されている。Karpathy がこれを提案したのは記事が書かれる数日前であり、その前にコミュニティは Willison の「バイブエンジニアリング」という代替案について何か月も議論していた、と著者は述べている。
学術的な説明は、個人の実践ではなく分野を記述しているため、独自の条件を異なる形で設定している。それはこの分野が初期段階にあることを明示している。EvoClawベンチマークの、エージェントの成功率が孤立したタスクでは 80% を超えるのに対し、継続的なソフトウェアの進化のもとでは最大でも 38% に落ちるという知見を報告し、エージェント型エンジニアリングは拡張のパラダイムとしては今日すでに現実のものであり変革的であるが、完全に自律的なソフトウェア開発は依然として数年がかりの研究課題であると結論づけている。この論文は、独自の測定を報告するのではなく他の研究を統合するポジションペーパーであり、そこで示される 9 次元の対比は分析的な枠組みとして提示されている。
Connell の条件は第一の説明のものに近く、実践に対する制約としてではなく、実践を学ぶべきだという主張として述べられている。彼は、このアプローチは開発者が常に取り入れてきたツールの系譜における自然な次の一歩であり（彼は IntelliSense、統合ドキュメント、コンパイル時チェックを挙げている）、時代に取り残されたくない開発者はこれらのツールとその効果的な使い方を理解する必要がある、と考えている。彼が示す入り口は意図的に小さい。現在のスプリントから退屈なタスクをひとつ選び、それをコーディングエージェントに渡し、それが生み出すすべての行をレビューする、というものである。
関連用語
バイブコーディング, ヒューマン・イン・ザ・ループ, スキルの萎縮, AI コーディングエージェント
- エージェント型ソフトウェア：AI エージェントはソフトウェアのパラダイムをいかに再構築しているか — 上で述べた、分野レベルの第二の説明の出典
- エージェント型ソフトウェア — その説明が、この分野が今や構築しているとする種類の成果物
- エージェント型エンジニアリングの 4 段階の進化 — 同じ論文による、この分野のロードマップ
- エージェント型エンジニア — 別の用語であり、別の問い、すなわち分野が何であるかではなく、AI エージェントがソフトウェアエンジニアとみなされるための条件を扱う
- エージェント型エンジニアリングのパターン — この実践のためのパターンを集めたガイドで、上で述べた第四の説明の出典
- バイブコーディングとエージェント型エンジニアリングが、望む以上に近づいている — 同じ著者が、バイブコーディングとの対比が自身の仕事の中で崩れつつあることを報告しているもの
- エージェント型エンジニアリング：AI エージェントの群れはソフトウェアエンジニアリングをどう再定義しているか — 分野レベルの説明が引用している LangChain の記事を、ここで直接読んだもの
- 本当に「ポチッ」で全部できるのか？ — 保守的な開発者が AI エージェントでプロダクトをリリースして気づいたこと — 上で述べた第五の説明の出典で、このやり方でプロダクトをリリースした実践者の報告