エージェント工学：新たな学問分野として確立
LangChain Blog は、AI エージェントの設計と構築を体系化する「エージェント工学」という新たな学問分野の確立を提唱し、業界標準の確立を求めている。
キーポイント
新分野の定義と必要性
AI エージェントの複雑な設計・構築プロセスを体系化するため、「エージェント工学」という独立した学問分野の確立が提案されている。
標準化への提言
散在するベストプラクティスを整理し、エンジニアリングの専門性を高めるための共通フレームワークや教育カリキュラムの構築を促している。
実用性とスケーラビリティ
個別の実装に依存しない普遍的な設計原則を確立することで、大規模で信頼性の高いエージェントシステムの開発を可能にする狙いがある。
影響分析・編集コメントを表示
影響分析
この記事は、AI エージェント開発が単なるプロトタイピング段階から、産業レベルで信頼できるシステムを構築する「工学」へと成熟しようとする転換点を示唆しています。業界全体として標準化された設計原則や評価基準が確立されれば、開発コストの削減とシステムの安定性が飛躍的に向上し、実社会への導入スピードが加速すると予想されます。
編集コメント
「エンジニアリング」という言葉が単なる実装技術を指すのではなく、学問分野として確立されるべき段階に来たことを示す重要な提言です。今後はこの分野の教育やツールの標準化が競合の焦点となるでしょう。
エージェントを構築したことがある方ならご存知の通り、「自分のマシンでは動く」と「本番環境で動作する」の間には大きな隔たりがあります。従来のソフトウェア開発は、入力を主に把握しており出力を定義できると仮定しています。しかし、エージェントにおいてはどちらも保証されません：ユーザーは何でも言い放つ可能性があり、起こりうる行動の範囲も極めて広範です。だからこそエージェントは強力な存在となる一方で、予期せぬ方向へ逸脱してしまうリスクも抱えています。
過去 3 年間で、私たちは数千ものチームがこの現実と格闘する姿を目にしてきました。本番環境に信頼性の高い成果物を納品することに成功した企業、例えば Clay、Vanta、LinkedIn、Cloudflare などは、従来のソフトウェア開発のプレイブックに従っているわけではありません。彼らは新しい領域を切り開いています：エージェントエンジニアリングです。
エージェントエンジニアリングとは何か？
エージェントエンジニアリングとは、非決定性の大規模言語モデル（LLM: Large Language Model）システムを、信頼性のある本番環境での体験へと洗練させる反復プロセスのことです。これは「構築し、テストし、リリースし、観測し、改善し、繰り返す」という循環的なプロセスです。
ここで重要なのは、リリースすることが最終目標ではないということです。それは、新たな洞察を得てエージェントを改善し続けるための手段に過ぎません。意味のある改善を行うためには、本番環境で何が起きているかを理解する必要があります。このサイクルを速く回すほど、エージェントの信頼性は高まります。
私たちは、エージェントエンジニアリングを 3 つのスキルセットが連携する新しい学問分野と捉えています:
- プロダクト思考は範囲を定義し、エージェントの振る舞いを形作ります。これには以下が含まれます: エージェントの振る舞いを駆動するプロンプトの作成（しばしば数百行から数千行に及ぶ）。ここでは優れたコミュニケーション能力と文章力が鍵となります。
- エージェントが複製する「達成すべき仕事」を深く理解すること
- 「達成すべき仕事」に従ってエージェントが意図通りに機能しているかをテストする評価基準を定義すること
- エンジニアリングは、本番環境で利用可能なエージェントを実現するためのインフラストラクチャを構築します。これには以下が含まれます: エージェントが使用するツールの作成
- エージェントとのインタラクションのための UI/UX の開発（ストリーミング処理、割り込みハンドリングなどを含む）
- 永続的な実行、人間によるループの一時停止、メモリ管理に対応する堅牢なランタイムの構築
- データサイエンスは、時間経過に伴うエージェントのパフォーマンスを測定し改善します。これには以下が含まれます: エージェントのパフォーマンスと信頼性を測定するためのシステム（評価、A/B テスト、モニタリングなど）の構築
- 使用パターンの分析およびエラー分析（従来のソフトウェアよりもユーザーがエージェントを利用する範囲が広いため）
エージェントエンジニアリングが現れる場所
エージェントエンジニアリングは新しい職種名ではありません。むしろ、推論し、適応し、予測不能な振る舞いをするシステムを構築する際に既存のチームが引き受ける責任の一セットです。今日信頼性の高いエージェントをリリースしている組織は、非決定論的（non-deterministic）システムの要求に応えるために、エンジニアリング、プロダクト、データチームのスキルを拡張しています。
この実践が典型的に現れる場所は以下の通りです：
- ソフトウェアエンジニアや機械学習エンジニアがエージェントが使用するプロンプトを作成しツールを構築し、なぜエージェントが特定のツール呼び出しを行ったかを追跡し、基盤となるモデルを洗練させること
- 永続的な実行と人間をループに組み込んだワークフロー（human-in-the-loop workflows）を処理するエージェントインフラストラクチャを構築するプラットフォームエンジニア
- プロンプトを作成し、エージェントのスコープを定義し、エージェントが正しい問題を解決していることを保証するプロダクトマネージャー
- エージェントの信頼性を測定し改善の機会を特定するデータサイエンティスト
これらのチームは迅速な反復（rapid iteration）を受け入れ、ソフトウェアエンジニアがエラーを追跡して PM に引き渡し、その洞察に基づいてプロンプトを調整したり、PM がエンジニアによる新しいツールの必要性を伴うスコープの問題を特定したりする様子をよく見かけます。それぞれが、エージェントの堅牢化における真の仕事は、生産環境での振る舞いを観察し、そこで得た知見に基づいて体系的に洗練させるというこのサイクルを通じて行われることを認識しています。
なぜエージェントエンジニアリングなのか、そしてなぜ今なのか？
2 つの根本的な変化が、エージェントエンジニアリングを必要としています。
まず、LLM は複雑で多段階のワークフローを処理するのに十分なほど強力です。エージェントが単なるタスクではなく、職務全体を引き受ける様子を見てきました。Clay では、見込み顧客のリサーチからパーソナライズされたアウトリーチ、CRM の更新まで、あらゆる業務をエージェントに任せています。LinkedIn では、採用のために膨大な人材プールをスキャンし、候補者をランク付けして、最も強力なマッチングを即座に提示するためにエージェントを活用しています。私たちはついに、エージェントが生産環境で意味のあるビジネス価値を提供する閾値を超えつつあります。
第二に、その力には現実的な予測不可能性が伴います。単純な LLM アプリは非決定論的ですが、行動がより限定された範囲に収まる傾向があります。しかし、エージェントは異なります。彼らは複数のステップにわたって推論を行い、ツールを呼び出し、文脈に基づいて適応します。エージェントを有用にする同じ特性が、従来のソフトウェアとは異なる振る舞いをもたらすのです。これは通常、以下のような意味を持ちます：
- すべての入力はエッジケースです。ユーザーが自然言語で何でも質問できる場合、「通常の」入力などというものは存在しません。「ポップにしてください」や「前と同じことを、でも違うやり方でやって」と入力すると、エージェント（人間と同様に）はプロンプトを異なる方法で解釈する可能性があります。
- 従来のデバッグ手法では対応できません。ロジックの多くがモデル内部に組み込まれているため、各意思決定とツール呼び出しを検証する必要があります。小さなプロンプトや設定の変更が、動作に大きな変化をもたらすことがあります。
- 「動作している」という状態は二値（Yes/No）ではありません。エージェントが 99.99% の稼働率を維持していても、軌道から外れて破損している可能性があります。重要な問いに対して常に単純な Yes/No で答えられるわけではありません。例えば、「エージェントは正しい判断を下しているか？」「ツールを適切に使用しているか？」「指示の背後にある意図に従っているか？」といった問いです。
- これらをすべて総合すると、従来のソフトウェアでは解決できない方法で動作しながらも、実際には高インパクトなワークフローを実行するエージェントが存在します。ここに新たな分野が必要とされ、その機会が生まれます。エージェントエンジニアリング（Agent Engineering）により、LLM の力を活用しつつ、本番環境でも実際に信頼できるシステムを構築することが可能になります。
エージェントエンジニアリングは実際にはどのようなものか？
エージェントエンジニアリングは、従来のソフトウェア開発とは異なる原則に基づいています。信頼性の高いエージェントシステムを実現するためには、「学習した後に実装する」のではなく、「実装すること自体が学習である」という考え方が基本となります。
私たちは、成功しているエンジニアリングチームが、以下のようなリズムでエージェント開発を行っている様子を目にしてきました：
- エージェントの基盤を構築する。エージェントの基盤設計から始めましょう。これは、ツール付きの単純な LLM 呼び出しであっても、複雑なマルチエージェントシステムであっても構いません。必要なワークフロー（決定論的な段階ごとのプロセス）とエンタインスメント（LLM に駆動された意思決定）のバランスに応じて、アーキテクチャは決まります。
- 想像できるシナリオに基づいてテストする。プロンプト、ツール定義、ワークフローにおける明白な問題を発見するために、例示されたシナリオに対してエージェントをテストしてください。ユーザーフローをマッピングできる従来のソフトウェアとは異なり、自然言語入力に対するユーザーのあらゆる相互作用方法を事前に予測することはできません。「徹底的にテストしてからリリースする」という思考から、「合理的にテストして、実際に何が重要かを学ぶためにリリースする」へとマインドセットを変えましょう。
- 実際の動作を確認するためにリリースする。一度リリースすれば、考慮していなかった入力が即座に見え始め、すべての本番環境のトレースが、エージェントが実際に対処する必要のあるものが何であるかを示します。
- 観察する。各対話の完全な会話履歴、呼び出されたすべてのツール、そしてエージェントが下した各意思決定に影響を与えた正確なコンテキストを把握するために、すべての相互作用を追跡してください。精度、レイテンシ、ユーザー満足度、またはその他の基準に関係なく、本番データに対して評価（evals）を実行してエージェントの品質を測定します。
- 改善する。失敗のパターンを特定したら、プロンプトの編集やツール定義の変更によって改善を行います。これは継続的なプロセスであり、問題のあるケースを回帰テスト用の例示シナリオセットに再度追加することができます。
- 繰り返す。改善分をリリースし、本番環境で何が変わっているかを見守ってください。各サイクルを通じて、ユーザーがどのようにエージェントと相互作用しているかについて新たな知見を得られ、あなたの文脈において信頼性（reliability）が実際に何を意味するのかを理解できます。
エンジニアリングにおける新たな基準
今日、信頼性の高いエージェントをリリースしているチームに共通する点は一つあります。それは、ローンチ前にエージェントを完璧にしようとするのをやめ、生産環境こそが最大の教師であると捉え始めたことです。つまり、すべての意思決定を追跡し、大規模な評価を行い、改善点を四半期単位ではなく数日でリリースすることです。
エージェントエンジニアリングが台頭しているのは、その機会がそれを求めているからです。エージェントは以前は人間の判断を必要としていたワークフローを処理できるようになりましたが、信頼して任せられるだけの信頼性を確保できる場合に限り可能です。近道はありません。あるのは反復という体系的な作業だけです。エージェントエンジニアリングが標準的な実践になるかどうかではなく、あなたのチームがいかに迅速にこれを採用し、エージェントの可能性を引き出すかが問われています。
関連コンテンツ
Deep Agents
Open Source
Agent Architecture
ループエンジニアリングの芸術
Sydney Runkle
2026 年 6 月 16 日
7 分
Open Source
LangChain
Agent Architecture
Deep Agents
カスタムエージェントハッチの構築方法
Sydney Runkle
2026 年 6 月 3 日
6
分
Deep Agents
Open Source
Agent Architecture
ルブリックの導入：自己評価と修正を行うエージェントを構築する
S. Seshadri,
S. Runkle
2026 年 6 月 2 日
4
分
エージェントが実際に何をしているかを確認する
LangSmith は、エージェントエンジニアリングプラットフォームであり、開発者がすべてのエージェントの意思決定をデバッグし、評価の変更を行い、ワンクリックでデプロイできるよう支援します。
原文を表示
If you’ve built an agent, you know that the delta between “it works on my machine” and “it works in production” can be huge. Traditional software assumes you mostly know the inputs and can define the outputs. Agents give you neither: users can say literally anything, and the space of possible behaviors is wide open. That’s why they’re powerful — and why they can also go a little sideways in ways you didn’t see coming.
Over the past 3 years, we’ve watched thousands of teams struggle with this reality. The ones who’ve succeeded in shipping something reliable to production — companies like Clay, Vanta, LinkedIn, and Cloudflare — aren’t following the traditional software playbook. They’re pioneering something new: agent engineering.
What is agent engineering?
Agent engineering is the iterative process of refining non-deterministic LLM systems into reliable production experiences. It is a cyclical process: build, test, ship, observe, refine, repeat.
The key here is that shipping isn't the end goal. It’s just the way you keep moving to get new insights and improve your agent. To make improvements that matter, you need to understand what’s happening in production. The faster you move through this cycle, the more reliable your agent becomes.
We see agent engineering as a new discipline that combines 3 skillsets working together:
- Product thinking defines the scope and shapes agent behavior. This involves:Writing prompts that drive agent behavior (often hundreds or thousands of lines). Good communication and writing skills are key here.
- Deeply understanding the "job to be done" that the agent replicates
- Defining evaluations that test whether the agent performs as intended by the “job to be done”
- Engineering builds the infrastructure that makes agents production-ready. This involves:Writing tools for agents to use
- Developing UI/UX for agent interactions (with streaming, interrupt handling, etc.)
- Creating robust runtimes that handle durable execution, human-in-the-loop pauses, and memory management.
- Data science measures and improves agent performance over time. This involves:Building systems (evals, A/B testing, monitoring etc.) to measure agent performance and reliability
- Analyzing usage patterns and error analysis (since agents have a broader scope of how users use them than traditional software)
Where agent engineering shows up
Agent engineering isn’t a new job title. Instead, it’s a set of responsibilities that existing teams take on when they’re building systems that reason, adapt, and behave unpredictably. The organizations shipping reliable agents today are extending the skills of engineering, product, and data teams to meet the demands of non-deterministic systems.
Here’s where the practice typically shows up:
- Software engineers and ML engineers writing prompts and building tools for agents to use, tracing why an agent made specific tool calls, and refining the underlying models
- Platform engineers building agent infrastructure that handles durable execution and human-in-the-loop workflows
- Product managers writing prompts, defining agent scope, and ensuring the agent solves the right problem
- Data scientists measuring agent reliability and identifying opportunities for improvement
These teams embrace rapid iteration, and you'll often see software engineers tracing errors and handing off to PMs to tweak prompts based on those insights, or PMs identifying scope issues that require new tools from engineers. Each recognizes that the real work of hardening an agent happens through this cycle of observing production behavior and systematically refining based on what they learn.
Why agent engineering, and why now?
Two fundamental shifts have made agent engineering necessary.
First, LLMs are powerful enough to handle complex, multi-step workflows. We’ve been seeing it with agents taking on whole jobs, not just tasks. Clay uses agents to handle everything from prospect research to personalized outreach and CRM updates. LinkedIn uses agents to scan massive talent pools for recruiting, ranking candidates and surfacing the strongest matches instantly. We’re starting to cross the threshold where agents are delivering meaningful business value in production.
Second, that power comes with real unpredictability. Simple LLM apps, though non-deterministic, tend to have more contained behavior. Agents are different. They reason across multiple steps, call tools, and adapt based on context. The same things that make agents useful also make them behave differently than traditional software. This usually means that:
- Every input is an edge case. There's no such thing as a "normal" input when users can ask anything in natural language. When you type in “make it pop” or “do what you did last time but differently”, the agent (just like a human) can interpret the prompts in different ways.
- You can’t debug the old way. Because so much logic lives inside the model, you have to inspect each decision and tool call. Small prompt or config tweaks can create huge shifts in behavior.
- “Working” isn’t binary. An agent can have 99.99% uptime while still being off the rails and broken. There aren’t always simple yes/no answers to the questions that matter, like: is the agent making the right calls? Using tools the right way? Following the intent behind your instructions?
When you put this all together — agents running real, high impact workflows yet behaving in ways that traditional software can’t solve — there’s an opportunity and the need for a new discipline. Agent engineering lets you harness the power of LLMs while building systems you can actually trust in production.
What does agent engineering look like in practice?
Agent engineering operates on a different principle than traditional software development. To achieve a reliable agent system, shipping is how you learn, not what you do after learning.
We’ve seen successful eng teams follow a cadence for agent development that looks something like this:
- Build your agent’s foundation. Start with designing your agent's foundation, whether it's a simple LLM call with tools or a complex multi-agent system. Your architecture depends on how much workflow (deterministic step-by-step processes) versus agency (LLM-driven decisions) you need.
- Test based on scenario you can imagine. Test your agent against example scenarios to catch obvious issues with prompts, tool definitions, and workflows. Unlike traditional software where you can map out user flows, you can't anticipate every way users will interact with natural language input. Shift your mindset from "test exhaustively, then ship" to "test reasonably, ship to learn what actually matters.”
- Ship to see real-world behavior. Once you ship, you’ll immediately start seeing inputs you hadn’t considered and every production trace shows what your agent actually needs to handle.
- Observe. Trace every every interaction to see the full conversation, every tool called, and the exact context that informed each decision the agent made. Run evals over your production data to measure agent quality, whether you care about accuracy, latency, user satisfaction, or other criteria.
- Refine. Once you’ve identified patterns in what's failing, refine by editing prompts and modifying tool definitions. It’s all continuous, as you can add problematic cases back to your set of example scenarios for regression testing.
- Repeat. Ship your improvements and watch what’s changing in production. Each cycle teaches you something new about how users are interacting with your agent and what reliability actually means in your context.
A new standard for engineering
The teams shipping reliable agents today share one thing: they've stopped trying to perfect agents before launch and started treating production as their primary teacher. In other words, tracing every decision, evaluating at scale, and shipping improvements in days instead of quarters.
Agent engineering is emerging because the opportunity demands it. Agents can now handle workflows that previously required human judgment, but only if you can make them reliable enough to trust. There is no shortcut, just the systematic work of iteration. The question isn't whether agent engineering will become standard practice. It's how quickly your team can adopt it to unlock what agents can do.
Related content
Deep Agents
Open Source
Agent Architecture
The Art of Loop Engineering
Sydney Runkle
June 16, 2026
7
min
Open Source
LangChain
Agent Architecture
Deep Agents
How to Build a Custom Agent Harness
Sydney Runkle
June 3, 2026
6
min
Deep Agents
Open Source
Agent Architecture
Introducing Rubrics: Build Agents that Evaluate and Correct Their Work
S. Seshadri,
S. Runkle
June 2, 2026
4
min
See what your agent is really doing
LangSmith, our agent engineering platform, helps developers debug every agent decision, eval changes, and deploy in one click.
関連記事
AI エージェント向けの生産環境インフラストラクチャ（19 分読）
TLDR AI が、AI エージェントを実際の運用環境で安定稼働させるための基盤整備や設計手法について解説している。
[AINews] GLM は GPT より優れているか？GLM-5.2 が実用性を証明、Z.ai が 12 月までに「Open Fable」を公開予定
Latent Space のニュースでは、中国のモデル「GLM-5.2」がベンチマークで優れた結果を示し実用性があると評価されたことと、Z.ai が 12 月までにオープンソースプロジェクト「Open Fable」を発表する見込みについて報じられています。
Salesforce CodeGen チュートリアル：ユニットテストと安全性チェック付きの Python 関数の生成・検証・再ランク付け
Salesforce は Hugging Face からモデルを読み込み、自然言語から Python 関数を生成するエンドツーエンドワークフローを公開した。この手法には構文チェックや静的解析、ユニットテストによる検証が含まれる。
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み