Agentic Engineeringとは何か：従来のコード補完やvibe codingとの決定的な違い

ソフトウェア開発者のSimon Willison（サイモン・ウィリソン）氏は、「Agentic Engineering（エージェンティック・エンジニアリング）」という概念を提唱しました。これはコーディングエージェントの支援を受けてソフトウェアを開発する実践手法を指します[1]。

ウィリソン氏が定義するコーディングエージェントとは、コードの記述と実行の両方を担うソフトウェアです。エージェントは設定された目標を達成するまで、コードの生成と実行を自律的に繰り返します。この「コード実行能力」こそが、エージェントによる開発を成立させる決定的な要素とされています[2]。

従来のAIコード補完ツールとの境界線は、単にコードを生成できるか否かではありません。エージェント自身がコードを実行し、その結果を踏まえて人間が一往復ごとに指示を出さなくても、テストと修正を自律的に反復できるかどうかに置かれています[3]。

後輩コード補完とエージェントの違いって、単に賢くなっただけではないんですか？

先輩生成したコードを自分で実行してエラーを確かめられるかどうかが境界線なんだ。

後輩人間が動かしてエラーを貼り付け直す手間が、エージェント自身のループに移るわけですね。

先輩そうだね。ただしループが自律化する分、人間がどう検証基準を渡すかが重要になるよ。

また、ウィリソン氏は「vibe coding（バイブコーディング）」との違いも明確に区別しています。vibe codingとは、コードの中身に注意を払わずに大規模言語モデル（LLM）へ任せ、未レビューのプロトタイプ品質のコードを作成する行為を指します[4]。

これに対してAgentic Engineeringは、プロフェッショナルなソフトウェアエンジニアが既存の専門知識を拡張し、作業の質と速度を高めるための実践です[5]。ウィリソン氏は、コーディングエージェントから優れた成果を引き出すための実践知を「Agentic Engineering Patterns」として章形式で体系化し、ブログ上で更新可能な形式で公開しています[6, 7, 8]。

なぜ今転機を迎えているのか：コード生成から実行・検証ループへの進化

エージェント型開発が実務の転換点を迎えている背景には、単なるモデルの賢さだけでなく、ツールや環境の統合があります。実務上の境界は、コード生成能力そのものよりも、エージェントがコードを実行し、その出力を次の推論に戻して再びツールを呼び出す「閉ループ」を獲得した点にあります[9]。

最新のフロンティアLLMは、単発のコード補完ではなく、長時間の作業や大規模なコードベースの探索、デバッグを意識して最適化される段階に入りました[10]。さらに、リポジトリを搭載した分離環境の整備により、エージェント自身がファイル編集だけでなく、テストやリンター（静的解析ツール）、型チェッカーを実行できるようになっています[11]。

長時間の自律稼働を支える基盤技術も進化しています。コンテキスト（文脈）の圧縮技術や、Git履歴やセッション間の進捗記録、変更前のチェックポイント機能など、状態を引き継いで復旧する仕組みが整ってきました[16]。OpenAIの報告では、GPT-5-Codexが複雑な作業において7時間を超えて自律的に実装やテスト修正を反復した事例も示されています[26]。

加えて、クラウド上の仮想マシンを活用した並列実行により、複数のエージェントが実装やデバッグ、ドキュメント作成を分担する運用も登場しています[19]。エージェントはソースコードの閲覧だけでなく、UI、ログ、メトリクス、DOM（HTMLの構造情報）、スクリーンショットを直接扱い、バグの再現と修正検証を行えるようになっています[26]。

このように、自動テスト、長期状態管理、並列実行、分離環境、GitやCI（継続的インテグレーション）との接続がひとつの開発体験として連結したことが、現在の技術的転換点と評価されています[12]。

開発プロセスは何が変わるのか：設計・実装・テスト・レビューの再構築

コーディングエージェントの登場によって、コードを書き出す作業のコストは劇的に低下しました。しかしウィリソン氏は、「コードを書くこと」は安価になっても、正しく動き、保守性や安全性を備えた「良いコード」を届けるコストは依然として高いままであると指摘しています[13, 18]。

開発者が最適化すべき対象は、最初のコード記述時間を削ることではなく、要件の検証やテスト設計、レビューへと移行します[14]。要件定義では、単に機能名を指定するのではなく、ユーザーの目的や受入条件、失敗時の挙動をエージェントが検証できる粒度で提示することが求められます[20]。また設計面でも、巨大な指示書を一度に与えるのではなく、リポジトリ内の設計文書を参照させつつ、リンターや構造テストによって設計の不変条件を機械的に制約するアプローチが有効とされています[15, 18]。

後輩コードがすぐ書けるなら、事前の設計やテストは減らせるんじゃないですか？

先輩むしろ逆なんだ。エージェントは指示通りに不要なコードや誤った実装も素早く作ってしまう。

後輩だからこそ、何を満たせば成功なのかという判定基準を人間が厳密に設計する必要があるんですね。

先輩その通りだよ。判定基準がないまま生成を回しても、正しい目的地にはたどり着けないからね。

実装段階においてウィリソン氏が推奨しているのが「Red/Green TDD（テスト駆動開発）」です。これは、失敗するテストを先に作成し、そのテストを通過するようにエージェントに実装させる手法です。実装前にテストの失敗を確認することで、不要なコードや動かないコードが作られるリスクを抑えられます[20, 33]。既存のリポジトリで作業を開始する際にも、まず既存のテストスイートを実行させてプロジェクトの文脈やテスト方法を理解させることが推奨されています[17]。

テストの役割も変化しています。テストは開発の最後に人間が行う確認工程ではなく、エージェントが変更を行うたびに自動実行されるフィードバック信号として機能します[26]。ただし、自動テストが通過してもUIの崩壊や起動失敗は残り得るため、Playwrightなどのブラウザ自動化ツールによる画面確認や、人間による実環境での手動確認を組み合わせる必要があります[27, 28]。

バージョン管理の面では、Gitが作業のチェックポイントや履歴探索の基盤となります。複数エージェントを動かす場合はGit worktreeなどで環境を分離し、衝突を防ぎながら別々の実装案を試行できます[29, 30]。レビュー工程においても、エージェントによる自己レビューやログ・証拠の提示を経た上で、人間が設計の妥当性や最終的な責任を確認する多層的な体制が求められます[31, 31]。

エンジニアやチームに誰にどう影響するか：専門知識の重要性と組織の課題

エージェント型開発の普及は、エンジニアの役割と組織のあり方に大きな影響を与えています。Anthropicが実施した約40万セッションの実利用データ分析によると、人間が計画判断（何を作るか）の約70％を担い、エージェントが実行判断（どう作るか）の約80％を担っているという明確な分業構造が観察されました[33, 34]。

この分析では、問題領域の専門知識が高いユーザーほど成功率が高いことも示されています。初学者と判定されたセッションの検証済み成功率は15％にとどまったのに対し、中級以上の層では28〜33％でした。また、問題に直面した際のタスク放棄率も、初学者が19％であったのに対し、中級以上では5〜7％と大きな差が生じています[35, 36]。

後輩エージェントがあれば、専門知識がなくても誰でも同じように開発できると思っていました。

先輩実際は、エラーが起きたときの原因特定や方針転換で専門知識の差が大きく出るんだ。

後輩何が起きているか分からないと、途中で諦めるしかなくなってしまうわけですね。

先輩エージェントを導くための前提知識や課題の理解度が、結果を左右しているよ。

一方で、非エンジニア職であっても、業務上の課題や制約条件を正確に把握していれば、コード生成セッションにおいてエンジニアに近い成功率を収めたデータも報告されています[39, 38]。

しかし、AIツールの導入が直ちに生産性向上につながるわけではありません。METRが実施した2025年初頭のランダム化比較試験（RCT）では、経験豊富なオープンソース開発者がAIツールを利用した際、タスクの完了時間が非利用時と比べて19％長くなったという結果が報告されています[39]。この調査は特定条件のスナップショットであるものの、ベンチマークと実務環境の乖離を示す例として挙げられています[40, 20]。

Googleの2025年DORA調査では、回答者の90％がAIを利用し生産性向上を実感している一方で、30％はAI生成コードを信頼していないと回答しました[21]。DORAは、AIはチームの課題を解決するのではなく現状の体制を増幅するため、強固なテスト基盤やバージョン管理、迅速なロールバック体制がなければ、コード量の増加がシステムの不安定化を招くと指摘しています[27, 28]。またオープンソースの現場でも、容易に作成されたPRの急増によって保守者のレビュー負荷が増大する懸念が浮き彫りになっています[45, 29]。

安全な運用のための留意点と適用範囲の評価

エージェントにファイル編集やコマンド実行権限を与える際には、セキュリティ上の統制設計が不可欠です。外部のWebページやリポジトリに悪意ある指示を埋め込んでエージェントを操る「プロンプトインジェクション」や、機密情報の流出リスクが存在するため、ファイルシステムとネットワークの両面を分離するサンドボックス環境の構築が求められます[30, 48]。

依存関係の管理にも注意が必要です。AIが架空のパッケージ名を生成する現象（ハルシネーション）があり、攻撃者がその架空のパッケージ名を第三者として先回り登録して悪用する「slopsquatting（スロップスクワッティング）」と呼ばれる攻撃手法が指摘されています[49]。そのため、提案されたパッケージの正当性を人間が検証する体制が欠かせません[34]。

さらに、欧州のEU AI Actや米FDAの規制基準に見られるように、高リスク領域や医療等の規制対象システムでは、変更理由や活動ログのトレーサビリティ、人間による監督が厳格に義務付けられています[51, 18]。エージェントによるコード生成を導入しても、コンプライアンスや検証責任のコストを省くことはできません[31]。

後輩安全基準が厳しい現場だと、エージェントの強みを活かすのは難しいのでしょうか？

先輩監査証跡や承認プロセスの整備が必要だから、単にコードを速く書くだけでは済まないね。

後輩逆に、どんな環境なら一番スムーズに導入できそうですか？

先輩目的や受入条件が明確で、テストで自動検証できるような領域から適用するのが現実的だと考えられているよ。

総合的な評価として、Agentic Engineeringのパターンは、目的と受入条件が人間によって明確に定義され、自動テストなどの客観的な基準で成否を検証できる環境において効果を発揮しやすいと考えられています[54]。コード生成がどれほど容易になっても、要件を定義し、生成物を検証し、最終的な責任を負う人間の役割が開発の中心であり続けます[55]。