エージェンティックエンジニアリングとは？バイブコーディングとの違い・始め方・ツール比較を解説

エージェンティックエンジニアリング（Agentic Engineering）とは、AIコーディングエージェントに実装を任せつつ、仕様・設計・テスト・レビューで人間が品質と責任を持つソフトウェア開発のやり方です。2026年2月上旬にAndrej Karpathy（OpenAI共同創業者で、現在はAnthropic所属）が呼び名として提案し、「バイブコーディングの次の段階」として広まりました。

言葉の定義と提唱の経緯、バイブコーディングや関連用語との違い、2026年10月時点の主要ツールと料金、実際に起きた事故から学ぶセキュリティ対策、個人とチームでの始め方を、一次情報へのリンクつきでまとめています。

この記事は、次のような方に向けて書いています。

• AIコーディングツールを使い始めたが、本番コードにどこまで任せてよいか迷っている開発者
• バイブコーディングやハーネスエンジニアリングとの違いを整理したいエンジニア・マネージャー
• チームでコーディングエージェントの導入を検討している技術リーダー

エージェンティックエンジニアリングとは何か

エージェンティックエンジニアリングは、特定のツール名ではなく、コーディングエージェントを使ってソフトウェアを作るときの「規律」の名前です。コードを書く作業の大半をエージェントに任せ、人間は何を作るかを決め、出来上がったものを検証し、最終的な責任を持ちます。

提唱の経緯

Karpathyは2025年2月2日に「バイブコーディング（vibe coding）」という言葉をXに投稿しました。それからちょうど1年後の2026年2月4日（米国時間）ごろ、彼はXのスレッドで、プロがLLMエージェントを使って開発するやり方の呼び名として「agentic engineering」を「今いちばん気に入っている名前」と挙げています。

言葉の意味は次のように説明されています。

• Agentic（エージェンティック）：開発者は99%の時間、自分でコードを直接書かず、コードを書くエージェントを指揮し監督する。それが新しい標準になった、という意味
• Engineering（エンジニアリング）：そこには技術・科学・専門性がある、という意味

その後、2026年4月末にSequoia「AI Ascent 2026」でKarpathyの対談が行われました。タイトルは「From Vibe Coding to Agentic Engineering」で、聞き手のStephanie Zhan氏は要点を「バイブコーディングは誰もが作れる下限を引き上げた。エージェンティックエンジニアリングは上限を引き上げる」とまとめています。対談でKarpathyは、ソフトウェアに責任を持つのは以前と同じで、そのうえでどれだけ速く進めるかが問われる、という趣旨を話しています。なお、Karpathyは2026年5月19日にAnthropicの事前学習チームへの参加を発表しました。

主な定義

用語を広めた3人の定義は、表現は違っても中身はほぼ同じです。

Willisonはエージェントを「目標を達成するために、ループの中でツールを実行するもの」と定義し、コードを実行できることがこの開発スタイルを成り立たせていると述べています。エージェントが自分で書いたコードを動かし、テストの結果を見て直せるからこそ、人間は1行ずつ書かなくて済むわけです。

なお、日本語では「エージェンティックエンジニアリング」と「エージェントエンジニアリング」の2通りの表記が見られます。ただし「Agent Engineering」は、AIエージェントそのものを作る技術の意味で使われることも多い言葉です（2026年10月にロンドンで開かれたイベント「Agent Engineering London」など）。この記事で扱うのは、エージェントを使ってソフトウェアを作るほうです。原語に忠実で、@ITなど国内の技術メディアでも主流なのは「エージェンティック」の表記です。

バイブコーディングとの違い

一番大きな違いは、AIが書いたコードを人間が検証するかどうかです。バイブコーディングはコードを細かく見ずに動けばよしとするやり方で、エージェンティックエンジニアリングはAIの出力を同僚のプルリクエストと同じ厳しさでレビューし、テストで裏づけます。

Osmaniは、バイブコーディングが「なんでも詰め込める言葉」になってしまったと指摘し、両者を分ける一番の境目はテストがあるかどうかだと整理しています。Willisonも、バイブコーディングという言葉はレビューしていない試作品質のコードに限って使い、本番品質に仕上げたコードには使わない、という立場です。

どちらが上という話ではなく、用途が違います。試作や個人の実験ならバイブコーディングの手軽さが生きますし、ユーザーが使うプロダクトにはエージェンティックエンジニアリングの手順が必要です。

バイブコーディングそのものについては、バイブコーディングとは？意味・やり方・注意点を解説で詳しく扱っています。

関連用語との違い

2026年に入ってから「〇〇エンジニアリング」という言葉がいくつも出てきました。どれもエージェンティックエンジニアリングの一部を切り出した言葉と考えると整理しやすくなります。

ハーネスエンジニアリングは、OpenAIが2026年2月11日に公開した記事「Harness engineering」で知られるようになった言葉です。OpenAIは5か月の社内実験で、人が手で書いたコードがゼロの社内ベータ製品（約100万行）をCodexで作ったと説明しています。テスト・CI設定・ドキュメントもCodexが書き、エンジニアの仕事は「環境を設計し、意図を明示し、フィードバックを返すこと」に移ったとされます（InfoQの解説）。

仕様駆動開発の具体例はKiroとは？、外部ツールとの接続についてはMCPとは？も参考になります。

エージェンティックエンジニアリングの基本原則

出典：GitHub Copilot 公式サイト

基本は、計画してから任せ、任せたものはレビューとテストで確かめ、システム全体の責任は人間が持つことです。Osmaniの原文にある4段階と、Willisonのガイドから実務で役立つ考え方を紹介します。

Addy Osmaniの4段階

1. Plan first（まず計画する）：仕様書や設計書を書き、タスクに分け、設計を決めてからプロンプトを書く
2. Direct, then review（指示して、レビューする）：任せる範囲を絞って指示し、同僚のプルリクエストと同じ厳しさでレビューする。理解できないコードはマージしない
3. Test heavily（徹底してテストする）：Osmaniは「テストが、当てにならないエージェントを当てにできる仕組みに変える」と書いている
4. Own the system（システムを自分で持つ）：ドキュメント、バージョン管理、CI、本番の監視は人間が責任を持つ

Osmaniは現在、この話題をまとめたページで「コーディングエージェントから、役に立ち信頼できる仕事を引き出すための規律」と定義し直しています。仕様の書き方、エージェントハーネス、評価（Evals）、レビューといった個別の記事をそこに束ねています。

Simon Willisonのガイドから押さえたい考え方

Willisonの「Agentic Engineering Patterns」は2026年2月23日に始まり、いまも更新が続いているガイドです。実務に役立つ考え方をいくつか挙げます。

• コードを書くコストは下がった：書き直しや試作をためらわなくてよい。そのぶん、どれを残すかの判断が重要になる
• やり方を蓄える：LLMは過去の失敗から学ばないが、指示ファイルやツールを人間が更新すれば、コーディングエージェントは学べる
• まずテストを走らせる：作業の最初に既存のテストを実行させ、Red/Green（失敗するテスト→通す実装）の順で進める
• AIはより良いコードを書くために使う：速く書くためだけでなく、テストや説明を厚くするためにも使う

どちらにも共通するのは、「AIに任せて終わり」ではなく、設計・レビュー・品質の主導権を人間が手放さないという点です。

開発者の役割はどう変わるのか

出典：Anthropic Claude Code 公式サイト

コードを手で書く「実装者」から、エージェントに仕事を割り振って結果を確かめる「設計者・監督者」へ、仕事の中心が移ります。

Anthropicが2026年1月に公開した「2026 Agentic Coding Trends Report」でも、開発工程の変化（書く仕事から、指揮と設計の仕事へ）がトレンドの1つ目に挙げられています（@ITの紹介記事）。

より重要になる仕事は、具体的には次のとおりです。

• 何を作るかの判断：複数の解決策のトレードオフを比べ、要件に合うものを選ぶ
• 設計と任せる範囲の決定：システム全体の構造を決め、エージェントに任せる範囲を定める
• レビューとフィードバック：生成されたコードを評価し、直すべき点を指示する
• 指示とテストの整備：規約・設計方針を指示ファイルに書き、テストとCIで機械的に守らせる
• 業務知識の適用：ビジネス要件や法規制の解釈など、AIだけでは判断できない部分を受け持つ

Karpathyも対談で、判断力や「何をなぜ作るか」の理解は人間に残ると話しています。Osmaniは2026年5月に「Don't Outsource the Learning（学ぶことを外注しない）」という記事を書き、エージェントに任せきりにすると自分の理解が育たない危うさを指摘しました。コードの良し悪しを見分ける力が前提になるため、経験の浅い開発者ほど、基礎を身につけながら段階的に取り入れるのが安全です。

できることと現時点の制約

エージェンティックエンジニアリングでは、複数ファイルにまたがる機能追加やテスト作成まで任せられます。一方で、任せたぶんだけレビューの仕事が人間に集まり、必ず速くなるとも限りません。

エージェンティックエンジニアリングでできること

Claude Codeの公式ドキュメントで確認できる範囲を例に挙げると、エージェントに任せられる作業は次のようなものです。

• コードベースを読み、複数ファイルにまたがる機能追加・バグ修正（原因の追跡→修正→動作確認まで）
• テストの作成と実行、失敗の修正、lintの修正、依存関係の更新
• Git操作（ブランチ作成・コミット・プルリクエスト作成）、GitHub ActionsなどCI上でのレビューやIssueの仕分け
• MCPで外部ツール（Jira、Slack、Google Driveなど）とつないだ作業
• サブエージェントやバックグラウンドのエージェントによる並行作業
• 夜間のCI失敗分析や週次の依存関係チェックといった定期実行

手法として見ると、1人で複数のタスクを並行して監督できること、COBOLなどのレガシーコードの読み解きや移行に使えることも挙げられます。Anthropicのレポートでは、TELUSがコードの出荷を30%以上速めた例や、Zapierが社内で800を超えるエージェントを動かしている例が紹介されています。

Claude Codeの並行作業はサブエージェントの使い方、CIへの組み込みはClaude Code GitHub Actionsの解説で詳しく扱っています。

現時点の制約（2026年10月時点）

• 責任ごと任せられる仕事はまだ一部：Anthropicのレポートによると、開発者は仕事の約60%でAIを使っているが、完全に任せられるのは0〜20%のタスクにとどまる
• 何を作るか、どのトレードオフを選ぶかは人間が決める：エージェントは実装できても、方向を決めることはできない
• 人間のレビュー量が上限になる：Osmaniは「The Orchestration Tax is You（調整のコストはあなた自身）」（2026年5月）で、エージェントを増やしても人間の注意力は増えないと指摘している。並行させられる数は、レビューできる量で決まる
• モデルの得意・不得意に振り回される：Karpathyは対談でエージェントの能力を「ぎざぎざ（jagged）」と表現し、得意な作業とそうでない作業の差が大きいと話している
• レビューを省くと品質の問題がたまる：検証せずに受け入れたコードは、後から直す負債になる

「速くなる」とは限らない

期待値を合わせるうえで知っておきたいのが、AI安全性の研究機関METRが2025年に行ったランダム化比較試験です。慣れたオープンソースのリポジトリで作業する経験豊富な開発者16人（246タスク）を調べたところ、AIを使ったほうが作業時間が19%長くなりました。一方で、本人たちは「20%ほど速くなった」と感じていました（arXiv:2507.09089）。

これは2025年前半のツールでの結果で、その後エージェントの性能は大きく上がっています。ただ、「体感の速さ」と「実際の成果」がずれうることは今も変わりません。導入するなら、プルリクエストの数や手戻り、レビューにかかった時間などを導入前後で比べるのがおすすめです。

主要ツールの比較と何から始めるか

出典: Cursor 公式サイト

エージェンティックエンジニアリングは手法なので、それ自体に料金はかかりません。実践には何らかのコーディングエージェントが必要で、2026年10月時点ではClaude Code・OpenAI Codex・GitHub Copilotがいずれも月額$20以下から使えます。2026年6月にWindsurfがDevin Desktopへ移行し、8月にはCursorが買収されるなど大きな変化があったため、以前の情報のまま選ばないよう注意してください。

※料金は2026年10月時点の各社公式ページの表記です。使用量の上限や為替で実際の負担は変わるため、契約前に公式サイトで確認してください。

料金の細かな枠は、Claude Codeの料金、GitHub Copilotの料金、Codexの使用量制限で整理しています。

用途別おすすめ

ツールは1つに絞る必要はありません。たとえば「実装はClaude Code、レビューは別のツールのエージェント」のように役割で分けるやり方もあります。AIコーディングツール全体の比較はAIコーディングツールおすすめ比較にまとめています。

各ツールの個別解説もあります。

• Claude Codeとは？できること・料金・使い方を解説
• GitHub Copilotとは？
• Cursorとは？機能・料金・特徴を解説
• Devinとは？

セキュリティリスクと対策

コーディングエージェントはファイルを書き換え、コマンドを実行し、外部サービスにアクセスします。一番の危険は、エージェントに渡した権限や認証情報が作業に必要な範囲より広いことです。2026年に実際に起きた事故も、ほとんどがここから始まっています。

2026年に実際に起きた事故

• 2026年3月（DataTalks.Club）：サーバー移行の作業中に、Claude Codeが破壊的なTerraformコマンドを実行し、2.5年分のデータが失われたと報告されている（OECD AI Incidents）
• 2026年4月（PocketOS）：Cursor上のエージェントがステージング環境で作業中に認証の食い違いに当たり、タスクと無関係なファイルにあったAPIトークンを使って、本番データベースとバックアップを1回のAPI呼び出しで削除した。約9秒の出来事とされ、後にホスティング事業者の協力で復旧した（Giskardの解説）

どちらも、エージェントが本番環境を使えない状態にできる権限を持っていたことが原因です。ほかの事例はAIエージェントによるデータ削除事故まとめで整理しています。

OWASP Top 10 for Agentic Applications 2026

OWASPは2025年12月9日、エージェント型AIに固有のリスクをまとめた「OWASP Top 10 for Agentic Applications for 2026」を公開しました。正式な10項目と、コーディングエージェントで起こりうる例は次のとおりです。

基本的な対策

1. 最小権限にする：本番の認証情報をエージェントの作業環境に置かない。トークンはタスク単位で範囲を絞る
2. 重要な操作は人間が承認する：本番操作・削除・デプロイ・外部への送信は承認を必須にする
3. サンドボックスで動かす：コンテナやローカルサンドボックスの中で実行し、中で何かがおかしくなっても影響が外に出ないようにする
4. テストとCIを関門にする：テストが通らない変更はマージしない
5. 監査ログを残す：どのエージェントが、いつ、何をしたかを追えるようにする
6. 指示ファイルと拡張の出どころを確かめる：CLAUDE.md／AGENTS.md、MCPサーバー、外部スキルは信頼できるものだけを使う

対策の詳細はAIエージェントのセキュリティ対策やAIコーディングのセキュリティリスクで解説しています。

導入ステップとどこから始めるか

いきなりチーム全体に広げる必要はありません。小さく試し、テストとレビューの仕組みができてから任せる範囲を広げるのが現実的です。

Step 1：小さな作業でエージェントに慣れる

個人の小さなプロジェクトや、本番に影響しない作業から始めます。無料枠のあるGitHub CopilotやCodex、Pro以上で使えるClaude Codeなどで、どんな指示だとどんな出力になるかをつかみます。初めての方はAIコーディング初心者向けガイドも参考にしてください。

Step 2：テストとレビューを組み込む

エージェントに作業させる前に既存のテストを走らせ、変更後もテストが通ることを確かめる習慣をつけます。生成されたコードは、人が書いたプルリクエストと同じ基準でレビューします。バイブコーディングからエージェンティックエンジニアリングへ移るのは、この段階です。

Step 3：仕様と指示ファイルを先に書く

コードを書かせる前に、仕様や設計をエージェント向けの指示として書きます。プロジェクト共通のルールは、Claude CodeならCLAUDE.md、CodexなどならAGENTS.mdに書いておくと毎回読み込まれます。最初は次のような短いもので十分です。

# プロジェクトの約束
- 変更の前後で `npm test` を実行し、失敗したまま終えない
- 本番環境の設定ファイル（config/production.*）は編集しない
- 新しい依存パッケージを追加するときは理由を説明し、人間の承認を待つ
- 1つのプルリクエストでは1つの目的だけを扱う

コミット前のlintなどは、Claude CodeのHooksで自動実行させることもできます（Hooksの使い方）。

Step 4：複数のエージェントを使い分ける

1つのエージェントで安定した成果が出るようになったら、作業を分けて並行させます。たとえば実装用とレビュー用でエージェントを分ける運用です。並行させる数は、自分がレビューしきれる量を上限に考えます。

Step 5：チームに広げる

個人で固めたやり方をチームに広げます。最初に決めておきたいのは、①AIが書いたコードのレビュー基準、②エージェントに渡す権限の範囲、③マージ前に必ず通すテストの3つです。

社内の業務システムで本格的に使うときは、手元で試すときとは別の準備が要ります。承認・停止・やり直しをどう組み込むか、どこにログを残すかといった仕組みです。必要になる作業はAIエージェントの本番導入で追加する開発範囲で整理しています。

エージェンティックエンジニアリングの今後の展望

2026年10月時点で、この言葉の新しい定義や公式な発表は出ていません。言葉自体はすでに定着し、議論の中心は「エージェントを動かす環境（ハーネス）をどう作るか」「人間の承認をどこに置くか」「レビューの負担をどう減らすか」に移っています。

確認できる主な出来事を時系列でまとめます。

標準化の動きとしては、2025年12月9日にLinux Foundation傘下でAgentic AI Foundation（AAIF）が発足しました。最初のプロジェクトはAnthropicのMCP、BlockのGoose、OpenAIのAGENTS.mdで、発足時の発表ではAWS・Anthropic・Google・Microsoft・OpenAIなどがプラチナ会員に名を連ねています。ツールが違っても同じ指示ファイルや接続方式を使える方向に進んでおり、特定のツールに縛られにくくなりつつあります。

学術の場でも、ソフトウェア工学の国際会議ASE 2026に、エージェントを使った開発をテーマにしたワークショップ「AgenticDev 2026」が設けられています。エージェント型AI全体の期待と現実のギャップについては、Gartnerのハイプサイクルの解説も参考になります。

こんな方に向いています / おすすめしない方

コードの良し悪しを判断でき、テストとレビューの手間をかけられる人ほど効果が出ます。逆に、検証を省きたい人や、コードを読めない段階の人には向きません。

エージェンティックエンジニアリングが向いている方

• 中級〜上級のエンジニア：コードレビューの経験があり、生成されたコードの品質を判断できる方
• 設計に関心がある方：手を動かすより「何をどう作るか」を考えることに価値を感じる方
• チーム開発のリーダー：レビュー基準や権限の設計を含めて、開発の進め方を整えたい方
• 本番で使うコードをAIで効率化したい方：試作ではなく、ユーザーが使うプロダクトにAIを取り入れたい方

おすすめしない方（現時点では）

• プログラミング未経験の方：出力を評価するには最低限のコーディング知識が必要。まずは基礎の学習から
• AIの出力をそのまま使いたい方：検証を省きたいなら、試作向けのバイブコーディングのほうが合っている
• 品質基準のゆるい個人プロジェクトだけの方：手順を整える手間のほうが大きくなりやすい
• 経験の浅い開発者が1人で取り組む場合：レビューしてくれる人がいないと、理解が追いつかないまま進んでしまう

まとめ

• エージェンティックエンジニアリングは、コーディングエージェントに実装を任せ、仕様・テスト・レビューで人間が品質と責任を持つ開発のやり方。2026年2月上旬にKarpathyが提案した
• バイブコーディングとの境目は「検証するかどうか」。テストを関門にし、プルリクエストと同じ厳しさでレビューする
• 2026年10月時点では、Claude Code・Codex・GitHub Copilotが月額$20以下から使える。Windsurfは6月にDevin Desktopへ移り、Cursorは8月の買収を経て10月に料金体系が変わった
• 任せられる範囲はまだ一部で、人間のレビュー量が上限になる。必ず速くなるとは限らない
• 事故の多くは権限の渡しすぎから起きる。最小権限・人間の承認・サンドボックス・テストの関門を最初に整える

よくある質問（FAQ）

Q1. エージェンティックエンジニアリングで「エンジニアの仕事がなくなる」のですか？

なくなるのではなく、中身が変わります。手でコードを書く時間は減りますが、仕様を書く、任せる範囲を決める、結果を検証する、本番の責任を持つ、といった仕事が残ります。Karpathyが「engineering」という語を選んだのも、そこに身につけるべき専門性があると考えたからです。

Q2. プログラミング未経験でもエージェンティックエンジニアリングはできますか？

現時点では難しいと考えてください。この手法の中心は、エージェントが書いたコードを人間が確かめることにあります。コードを読めないと、テストが正しいかどうかも判断できません。未経験の方は、バイブコーディングで「作る体験」をしながら、並行してプログラミングの基礎を学ぶのが近道です。

Q3. バイブコーディングはもう不要ですか？

不要ではありません。アイデアを素早く形にする試作や、自分だけが使う小さなツールには今も向いています。Karpathyの対談でも、バイブコーディングは「誰もが作れる下限を引き上げた」ものとして位置づけられています。試作で方向が見えたら、本番化の段階でエージェンティックエンジニアリングの手順に切り替える、という使い分けが現実的です。

Q4. どのツールから始めるのがおすすめですか？

お金をかけずに試すならGitHub CopilotのFreeか、ChatGPTのアカウントで使えるCodexが手軽です。規約やチェックを仕組みにして本格的に使うならClaude Code（Pro $20〜）が選択肢になります。どれもエージェントに作業を任せる基本は同じなので、まず1つを2〜3週間使い込み、物足りない部分が見えてから追加を考えるとよいでしょう。

Q5. CLAUDE.mdとAGENTS.mdはどちらを書けばよいですか？

使うツールに合わせます。CLAUDE.mdはClaude Code向け、AGENTS.mdはCodexなど多くのツールが読む共通形式で、Agentic AI Foundationのプロジェクトにもなっています。Claude CodeもAGENTS.mdを読めるため、複数のツールを併用するチームはAGENTS.mdに共通ルールをまとめ、ツール固有の設定だけを個別のファイルに書く方法が管理しやすいです。

Q6. セキュリティ面で特に注意すべきことは？

最低限、本番の認証情報をエージェントの作業環境に置かないことと、削除・デプロイなどの重要な操作に人間の承認を挟むことの2つは実施してください。2026年に起きたデータ削除事故は、どちらもエージェントが本番環境を使えない状態にできる権限を持っていたことが原因でした。OWASPのTop 10は、自社の運用に抜けがないかを点検するチェックリストとしても使えます。

関連記事

• AIエージェントとは？仕組み・種類・活用事例・注意点を解説
• バイブコーディングのやり方
• Claude Codeとは？できること・料金・使い方を解説
• AIコーディングツールおすすめ比較
• 生成AIツールおすすめ比較