エージェンティックエンジニアリング2026年9月12日 | |
🐧 要するにどういう話かエージェンティックエンジニアリングとエージェントエンジニアリングは名前が似ていてややこしいが、後者はエージェントをどうやって作るかだが、前者はエージェントを使ってソフトウェアをどう作るかの話である。 1. はじめに本書はエージェンティックエンジニアリングの入門書である。エージェンティックエンジニアリングとは何か、なぜ登場したのか、周辺分野と何が違うのか、どのような実践パターンがあるのかを説明する。 2. エージェンティックエンジニアリングとは何か一言でいうと、エージェンティックエンジニアリングとは、コーディングエージェントの支援を受けながらソフトウェアを開発する実践である。 エージェントとはエージェンティックエンジニアリングを理解するためには、まず「エージェント」が何かを理解する必要がある。LLM（大規模言語モデル）の文脈における実用的な定義は次の通りである。
具体的には、エージェントとは、プロンプトをLLMに渡し、ツールの定義セットを渡して、LLMが要求したツールを呼び出し、その結果をLLMにフィードバックするソフトウェアである。このループは、目標が達成されるまで繰り返される。 コーディングエージェントコーディングエージェントとは、コードを書き、コードを実行できるエージェントである。代表的なものにClaude Code、OpenAI Codex、Gemini CLIがある。 コーディングエージェントの場合、ツールにはコードを実行するものを含む。ユーザーが目標をプロンプトとして与えると、エージェントはコードを生成し、実行し、その目標が達成されるまでループで繰り返す。 コード実行こそが、エージェンティックエンジニアリングを可能にする決定的な能力である。 コードを実行できない場合、LLMの出力は限られた価値しか持たない。コード実行があれば、エージェントは明らかに動作するソフトウェアに向けて反復できるようになる。 人間の役割動作するコードを書けるソフトウェアが存在するようになった今、人間には何が残されているのか。 コードを書くことは、ソフトウェアエンジニアの唯一の活動ではなかった。この仕事の本質は、常に「どのコードを書くか」を決めることである。ソフトウェアの問題には数十通りの解決策があり、それぞれトレードオフが異なる。私たちの仕事は、それらの選択肢の中で、自分の状況や要件に最も合うものを見つけることである。 コーディングエージェントから良い結果を引き出すには、以下が必要である。
LLMは過去の失敗から学習しないが、コーディングエージェントはそれができる。ただし、学習したことを反映するために、指示書やツールハーネスを意図的に更新する必要がある。 3. 登場した背景コードは常に高価だったコードの生成は常に高価だった。数百行のクリーンでテスト済みのコードを作るのに、多くのソフトウェア開発者が1日以上かかっていた。我々のエンジニアリングの習慣は、マクロレベルでもミクロレベルでも、この制約を前提に築かれている。 マクロレベルでは、高価なコーディング時間を効率的に使うために、設計・見積もり・計画に多くの時間を費やしてきた。プロダクトの機能アイデアは、その時間に対してどれだけの価値を提供できるかで評価される。 ミクロレベルでは、1日に何百もの判断を、使える時間と想定されるトレードオフに基づいて行っている。
現在、コードは安くなったコーディングエージェントは、コードを書くコストを劇的に下げる。これにより、どのトレードオフが合理的なのかについての、個人も組織も持っていた直感が大きく揺らぐ。 並列エージェントを実行できることで、この評価がさらに難しくなる。1人の人間が、同時に複数箇所で実装・リファクタリング・テスト・ドキュメント作成を並行して行えるようになったからである。 良いコードには依然としてコストがかかる新しいコードを納品するコストはほぼ無料になった。しかし、良いコードを納品するコストは、それに比べれば依然として高い。 「良いコード」とは以下を意味する。
コーディングエージェントのツールはこれら大半を支援できるが、現在のプロジェクトに必要な「良さ」の部分集合について、プロンプトを操作する開発者がこれを確実にする責任は残る。 新しい習慣が必要課題は、エージェンティックエンジニアリングの可能性に応じた、新しい個人・組織の習慣を作ることである。これらのベストプラクティスは、業界全体でまだ模索中である。 実用的な指針としては、直感が「そんなものを作るな、時間の無駄だ」と言うたびに、とにかく非同期エージェントセッションにプロンプトを投げるだけでよい。最悪の場合、10分後に確認して「トークンを無駄にした」となるだけである。 4. 周辺分野との違い4.1 バイブコーディングとの違い「バイブコーディング」という用語は、Andrej Karpathy氏が2025年2月に作ったもので、コードの存在を「忘れて」LLMにコードを書かせることを指す。 エージェンティックエンジニアリングはバイブコーディングではない。バイブコーディングは未レビューのプロトタイプ品質のコードを産む。エージェンティックエンジニアリングでは、作者がコードを本番品質の基準まで引き上げることが前提である。未レビューのプロトタイプ品質のLLM生成コードと、検証されて本番品質の基準に達したコードを区別する用語が必要なのである。 4.2 AIコーディングエージェント（Claude Code、Codex等）との違いClaude CodeやCodexのようなAIコーディングエージェントは、単一のユーザー駆動セッション内で、意図をコードに変換することに長けている。リポジトリの文脈の中で、リファクタリング、説明、デバッグができる。 エージェンティックエンジニアリングは、より高い抽象度で動作する。チーム横断のワークフローをオーケストレーションし、エージェント間で長期メモリを維持し、ソフトウェアデリバリの全ライフサイクルにわたる状態と追跡可能性を管理する制御平面である。 これらは競合関係ではない。Claude Codeのようなコーディングエージェントは、エージェンティックエンジニアリングのシステム内部で、推論やコード生成エンジンとして動作しうる。 4.3 エージェントエンジニアリングとの違いエージェントエンジニアリングとは、非決定論的なLLMシステムを、本番環境で信頼できる運用に磨き上げる反復プロセスである。その対象は、有界自律システム全体である。目標、停止条件、コンテキスト、ツール、評価、運用を含む。 エージェントエンジニアリングの6本柱は次の通り。
エージェンティックエンジニアリングとの関係は次のようになる。エージェントエンジニアリングはエージェントシステムそのものを設計する。エージェンティックエンジニアリングはコーディングエージェントを使ってソフトウェアを開発する実践である。 一方は機械を造り、他方は機械を運転する。 4.4 ハーネスエンジニアリングとの違いハーネスエンジニアリングとは、AIエージェントをスケールして信頼可能にする環境・制約・フィードバックループ・インフラを設計する実践である。 実用的な定義は 馬と具の比喩がこれによく当てはまる。馬（モデル）は原始的な力を提供する。具（ハーネス）は制御と方向を与える。 ハーネスには以下が含まれる。
ハーネスエンジニアリングの3本柱は次の通り。
3つの関連分野を区別する簡潔な方法は次の通り。
エージェンティックエンジニアリングとの関係は次のようになる。ハーネスエンジニアリングはモデルを包む環境を設計する。エージェンティックエンジニアリングは、コーディングエージェント（＝モデル＋組み込みハーネス＋ユーザーが定義する外側ハーネス）を使ってソフトウェアを開発する実践である。 4.5 マルチエージェント協調最も高い抽象度で考えると、エージェンティックエンジニアリングはマルチエージェント協調に拡張できる。複数のエージェントがチームとして動作する形である。 CiscoのエンジニアがLangChainのフレームワーク（LangGraph、LangSmith、LangMem）を用いて設計した参照アーキテクチャは、2つの補完的役割から成る。
核心の洞察は次の通り。最大の飛躍は、より良いツールだけでは生まれない。実際のチームを模倣するシステムから生まれる。 5. 基礎：実践パターン5.1 より良いコードを生み出す技術的負債の回避技術的負債の最良の緩和策は、最初から負債を作らないことである。技術的負債の修正としてよくあるカテゴリーは、概念的には単純だが時間のかかる変更である。
これらはすべて、コーディングエージェントの理想の用途である。エージェントを起動し、変更すべきことを伝え、バックグラウンドのブランチやワークツリーで作業させる。プルリクエストで結果を評価する。良ければマージし、あと少しならプロンプトで改善を指示し、悪ければ捨てればよい。 これらのコード改善のコストは十分に下がったため、軽微なコードスメル（コードに潜む、将来の問題の兆し）や不便さを見逃す理由がなくなった。 探索的プロトタイピング技術選択に自信を持つ最良の方法は、プロトタイプで目的適合性を証明することである。コーディングエージェントは、1つの丁寧に作られたプロンプトからシミュレーションを構築できる。これにより、この種の実験のコストはほぼゼロに下がる。それほど安いなら、複数の実験を同時に走らせて、複数のソリューションから最も合うものを選べる。 LLMは、我々が思いつかなかった自明の解決策を見逃さないようにも手伝える。LLMが提案するのは学習データで一般的なソリューションだけであるが、それらは多くの場合、最もうまくいく地味な技術である。 複合エンジニアリングループエージェントは指示に従う。過去に学んだことをもとに、指示書を時間とともに進化させれば、今後の実行からより良い結果が得られる。 EveryのDan ShipperとKieran Klaassenが説明するパターン：すべてのコーディングプロジェクトの最後に振り返り（compound step）を行い、うまくいったことを記録して、今後のエージェント実行に活かす。 小さな改善が複利的に積まる。かつて時間がかかっていた品質向上が、コストが下がり、新機能のリリースと同時に品質に投資しない理由がなくなった。コーディングエージェントのおかげで、両立できるようになったのである。 5.2 知っていることの蓄積（Hoard）ソフトウェア構築におけるスキルの大きな部分は、何が可能で何が不可能かを理解し、それらがどのように実現できるのかを少なくともおおまかに知っていることである。 これらの質問への答えに自信を持つ最良の方法は、動作するコードによってそれが示されたのを見ていることである。理論的に可能だということを知っていることと、自分の目でそれを見たこととは異なる。ソフトウェアプロフェッショナルとして育むべき重要資産は、この種の質問への答えの深いコレクションであり、それらの答えの証明である。 なぜ蓄積するのか？ 自分の能力を高めるだけでなく、生成した資産がコーディングエージェントへの強力な入力になるからである。効果的なプロンプトパターンの1つは、エージェントに2つ以上の既存の動作する例を組み合わせて新しいものを作らせることである。 コーディングエージェントは、動作する例の蓄積をさらに価値あるものにしている。
核心はこれである。コーディングエージェントのおかげで、有用なトリックは一度だけ考えればよい。そのトリックが動作するコードの例とともにどこかに記録されていれば、エージェントはその例を参照して、将来の類似プロジェクトを解決できる。 5.3 アンチターン（避けるべきこと）未レビューのコードを同僚に押し付けないこれは一般的で、深く苛立たしいアンチパターンである。自分でレビューしていないコードでプルリクエストを立てるべきではない。 エージェントが生成した何百・何千行のコードでPRを開き、それが動作することを自分で確認していなければ、実際の仕事の他者への委任である。相手もエージェントにプロンプトを投げられる（あなたの価値は何？）。 良いエージェンティックエンジニアリングのプルリクエストには、以下の特性がある。
自分が検証作業をしたことの証拠を添えることをお勧めする。どのように手動テストしたかのメモ、実装選択についてのコメント、機能が動作しているスクリーンショットや動画は、レビュアーの時間が無駄にならないことを示すのに非常に役立つ。 6. マルチエージェント協調の具体的例CiscoのエンジニアがLangChainのフレームワーク（LangGraph、LangSmith、LangMem）を用いて、実世界の開発・テスト・デバッグワークフローにマルチエージェントフレームワークを適用したパイロット調査の結果を以下に示す。 アーキテクチャシステムは、A2Aプロトコル経由で通信するワーカーエージェントとリーダーエージェントからなる。ワーカーエージェントは、A2AをサポートしないエージェントともMCPラッパー経由でやり取りできる。エンジニアは、IDE、CLI、またはGitHubやJiraアクションなどの外部トリガーを通じて意図を表現する。 ワーカーエージェントの4段階フロー
パイロット結果
残るボトルネックPRレビュープロセス自体が、人間が関わることで生じるボトルネックになった。このことは、マルチエージェントシステムであっても、品質保証の速度制限ステップとして人間の判断が依然として残ることを示している。 7. まとめエージェンティックエンジニアリングは、コーディングエージェントの支援を受けながらソフトウェアを開発する実践である。コードを書くコストが劇的に下がり、マクロレベルでもミクロレベルでもソフトウェア開発の経済学が変わったことにより登場した。 周辺分野との違いを整理する。
人間に依然として求められること。
この分野は進化の真っ最中である。ベストプラクティスはまだ模索中である。しかし方向性は明確である。コーディングエージェントは、より野心的なプロジェクトに挑戦するのを手伝ってくれる。エージェンティックエンジニアリングは、それを責任を持って実現する方法である。 📚 参考文献 | |
| PENGUINITIS | |