バックグラウンドでのサブエージェントの実行
LangChain Blogは、Supervisorがサブエージェントの進行をリアルタイムで監視・制御・キャンセルできる非同期バックグラウンド処理機能「Deep Agents」のサポートを開始したと発表した。
キーポイント
同期処理の課題解決
従来のインラインサブエージェントはSupervisorをブロックし、タスク中断時の更新通知が途切れる問題があった。
非同期サブエージェントの実装
Deep Agentsが非同期サブエージェントをサポートし、Supervisorはバックグラウンドタスクを起動、誘導、キャンセルできるようになった。
リアルタイム制御の実現
これにより、複雑なマルチエージェントシステムにおける運用の柔軟性とレスポンス性が大幅に向上する。
影響分析・編集コメントを表示
影響分析
この機能強化は、LangChainエコシステムにおけるマルチエージェントシステムの堅牢性を高める重要な一歩である。特に、長時間実行されるタスクや対話型アプリケーションにおいて、リソースの最適化とユーザー体験の向上に寄与すると期待される。
編集コメント
エージェント間の依存関係管理における「ブロック」問題は実務上の痛ポイントであり、非同期処理のサポートは開発者のワークフローを大幅に効率化する実用的な改善と言える。
主要なポイント
- インラインサブエージェントは、タスクの完了までスーパーバイザーエージェントをブロックします。エージェントループ内のツール呼び出しは同期処理であるため、サブエージェントが完了するまで、スーパーバイザーはユーザーへの応答や他の作業の調整、軌道修正を行うことができません。これは、タスクに1時間以上かかる場合など、実際に大きな問題となります。
- 非同期サブエージェントはすぐにタスクIDを返すため、スーパーバイザーが制御を維持できます。スーパーバイザーは複数のサブエージェントを並列で起動し、ユーザーとの対話を継続したり、タスク途中の更新を送信したり、不要になった作業をキャンセルしたりできます。これは「放置型（fire-and-forget）」ではなく、「発射後制御型（fire-and-steer）」に近い動作です。
- 非同期サブエージェントは Agent Protocol を基盤としているため、特定のデプロイメントに縛られません。これらは独自のプロセスと状態を持つ完全に独立したエージェントとして実行され、LangSmith のデプロイメント上でホストすることも、自前のインフラストラクチャでセルフホスティングすることも可能です。どちらの場合でも、スーパーバイザーは同じ標準インターフェースを通じてこれらを管理します。
私たちはエージェントにより多くのことを求めるようになっています——より長く、より複雑なタスクを引き受けさせることです。その過程で、エージェントをオーケストレーションする典型的な方法にいくつかの亀裂が生じ始めています。
私たちは、この課題に対応するために、最近 非同期サブエージェント を Deep Agents に搭載しました。これは、エージェントが委任された作業をバックグラウンドで実行できるパターンであり、従来のエージェントアーキテクチャのいくつかの短所を解消するものであるため、私たちはこの機能に大きな期待を持っています。
従来のサブエージェントが抱える課題
サブエージェントとは、スーパーバイザーエージェントからスコープ限定の作業を委任されるエージェントのことです。サブエージェントはスーパーバイザーからの指示を受け、関連するツールへのアクセス権を持ち、作業完了後に要約を返します。これは私たちが過去数年間、構築するほぼすべてのエージェントで採用しているコンテキストエンジニアリングのパターンであり、重要な理由からそうしています：
- 作業を小さなタスクに分割すると、エージェントのパフォーマンスが向上します。スーパーバイザーエージェントは問題を把握し、タスクを整理してから、それを実行するワーカーを調整します。
- 小さなタスクに関するすべての情報が、大きな目標にとって重要であるわけではありません。焦点を絞った独立したエージェントの実行に分割することで、不要なコンテキストをスーパーバイザーから隠蔽します。
このパターンは機能しています。しかし、エージェントにより長く複雑なタスクを任せるにつれて、インラインサブエージェントの限界が目立つようになってきました。
サブエージェント動作中にエージェントがデッドロック状態になる
サブエージェントは、スーパーバイザーエージェントに渡されたツールを介して呼び出されます。エージェント内部でのツール呼び出しの動作方式により、サブエージェントからのレスポンスが返されるまで、スーパーバイザーは他の事柄について推論を行うことができません。
サブエージェントが小さく、リスクの低いタスクを担当していた頃は、この点は大きな問題ではありませんでした。しかし、今ではエージェントにより複雑なタスクとツール（そして実行に時間がかかるモデル）が与えられているため、この問題がより顕著に感じられるようになりました。サブエージェントの実行に1時間かかる場合、エージェントと再度やり取りできるのはその1時間後になります。
新情報の調整が困難
エージェントが作業を進める上で重要な情報伝達チャネルがいくつかあります：
- ユーザー入力 — タスク実行中に、ユーザーがエージェントの操作を指示したり、コンテキストを追加したり、優先順位を変更したい場合。
- 他の作業からの結果 — 1つのサブエージェントの出力が、別のサブエージェントの次の行動を決定する手がかりとなる場合。
- 部分的な進捗 — 完了する前に、間違った方向に進んでいるタスクの軌道修正を行いたい場合もあります。
インラインサブエージェントでは、これらの通信チャネルは利用できません。スーパーバイザーがブロックされているため、ユーザーはそれと対話できません。サブエージェントは並列実行できないため、結果の相互影響（クロスポーリネーション）がありません。また、サブエージェントの処理は「すべてまたは nothing」であり、タスク途中での更新送信や部分的な失敗の graceful な処理は不可能です。スーパーバイザーはサブエージェントを発射し、あとは運を天に任せる状態になります。
登場：非同期サブエージェント
非同期サブエージェントを考えると、それは順次実行されるのではなくバックグラウンドで動作するサブエージェントと理解できます。サブエージェントの完了を待って次に進むのではなく、スーパーバイザーはタスクを開始し、すぐにタスクIDを受け取り、作業を続行します。バックグラウンドで処理が行われている間、ユーザーと対話したり、さらに多くのサブエージェントを開始したり、問題の他の部分での進捗を図ったりできます。
サブエージェントは状態を保持し、独自の会話スレッドを維持するため、スーパーバイザーはフォローアップの指示を送信したり、タスク途中での軌道修正を行ったり、不要になった作業をキャンセルしたりできます。これは「発射して忘れ去る（fire-and-forget）」というよりは、「発射して誘導する（fire-and-steer）」に近い概念です。
動作原理
サブエージェントに対してスーパーバイザーが単一のブロッキングツール呼び出しを行うのではなく、非同期サブエージェントはスーパーバイザーにタスクキューのような動作をする一連の管理ツールを提供します。
| ツール | 目的 |
|---|---|
| start_async_task | リモートエージェントでタスクを開始します。すぐにタスクIDを返します。 |
| check_async_task | タスクのステータスをポーリングし、完了時に結果を取得します。 |
| update_async_task | 実行中のタスクにフォローアップ指示を送信します。 |
| cancel_async_task | 実行中のタスクをキャンセルします。 |
| list_async_tasks | 現在のステータスを含むすべての追跡対象タスクを一覧表示します。 |
スーパーバイザーは、これらのツールを推論ループの一部として自然に使用します。いくつかのタスクを開始し、ユーザーとの対話に戻り、進捗状況を確認し、必要に応じて軌道修正を行うことができます。
従来のサブエージェントは実際には親エージェントの一種の関数に過ぎません。プロセスを共有し、状態を共有し、スーパーバイザーの実行ループ内でのみ存在します。非同期サブエージェントは、これらを完全に個別にアドレス指定可能な別個のエージェントとして扱います。独自のプロセスで実行し、独自の状態を維持でき、数百または数千のサブエージェントを呼び出すような実行にスケールすることができます。
Agent Protocol を基盤とした設計
そのような分離を実現するには、プロセス内の関数呼び出しだけでは不十分です。非同期サブエージェントは Agent Protocol を基盤として構築されています。これは、リモートエージェントを管理するためのフレームワーク非依存の API 仕様です。スレッドの作成、実行の開始、ステータスのポーリング、更新の送信、長期記憶の管理といった標準エンドポイントを定義しています。これは、スーパーバイザーが一貫したインターフェースを通じて非同期作業を管理するために必要なすべての機能を含んでいます。
主な利点は、デプロイメントの柔軟性です。特定のホスティングプラットフォームに縛られることはありません。管理された環境が必要な場合は LangSmith デプロイメント で非同期サブエージェントを実行できますし、独自のインフラストラクチャ上で自らホスティングすることも可能です。スーパーバイザーはサブエージェントがどこに存在するかに関心を持ちません。タスクを送信し、タスク ID を取得し、どちらの場合でも同じ標準インターフェースを通じてライフサイクルを管理します。
Agent Protocol について詳しく知りたい場合は、仕様 と API リファレンス を参照してください。
Deep Agents における非同期サブエージェントの使用方法
Deep Agents は、私たちが頻繁に話題にする汎用エージェントハーンです。DeepAgents に非同期サブエージェントを追加するのは、サブエージェントリストに非同期サブエージェントの仕様を差し替えるだけです。インラインサブエージェントと自由に組み合わせて使用できます。
LangSmith でのデプロイ
エージェントを定義し、langgraph.json に登録します。リサーチャーは別個のエージェントであるため、スーパーバイザーには非同期管理ツールが自動的に付与されます：
// agents.ts
import { createAgent } from "langchain";
import { createDeepAgent } from "deepagents";
export const researcher = createAgent({
model: "anthropic:claude-sonnet-4-6",
instructions: "Perform deep research on the given topic.",
tools: [searchWeb, readUrl],
});
export const agent = createDeepAgent({
model: "anthropic:claude-opus-4-6",
subagents: [{
name: "researcher",
description: "Performs deep research on a topic.",
graphId: "researcher",
}],
});
// langgraph.json
{
"dependencies": ["."],
"graphs": {
"researcher": "./agents.ts:researcher",
"agent": "./agents.ts:agent"
}
}
サブエージェントは独自の状態を持つ独立したプロセスで実行され、スーパーバイザーは単に委任して後から確認を行います。
自前ホスティング（Self-hosted）
サブエージェントの実行場所を完全に制御したい場合、ご自身でホスティングすることができます。サブエージェントは Agent Protocol のエンドポイントを実装する必要があり、スーパーバイザーはグラフ ID ではなく URL を介してサブエージェントに接続します。
export const agent = createDeepAgent({
model: "anthropic:claude-opus-4-6",
subagents: [{
name: "researcher",
description: "Performs deep research on a topic.",
graphId: "researcher",
url: "http://localhost:2024", // 自前ホスティングサーバーを指す
}],
});
セルフホスト型サーバーは、Agent Protocol のエンドポイント（スレッドの作成、実行の開始、ステータスのポーリング、タスクのキャンセル）を実装しており、Docker コンテナ、VM、または独自の Kubernetes クラスターなど、あらゆる環境で実行可能です。Hono サーバー、Postgres による状態管理、および Docker Compose のセットアップを含む 完全なセルフホスト例 を用意しており、これを出発点としてご利用いただけます。
関連コンテンツ
コンセプトガイド
Deep Agents
本番環境のディープエージェントを支えるランタイム
S. Runkle,
V. Trivedy
2026 年 4 月 20 日
24 分
エージェントアーキテクチャ
パートナー
エージェントエンジニアリング：AI エージェントの群れがソフトウェアエンジニアリングを再定義する方法
R. Kumar,
P. Ramagopal
2026年4月17日
6分
ディープエージェント（Deep Agents）
エンジニアリング
どのようにしてドキュメントが自己テストを行うようにしたか
Naomi Pentrel
2026年4月15日
3分
エージェントの実際の動作を確認する
LangSmithは、当社のエージェントエンジニアリングプラットフォームであり、開発者がすべてのエージェントの意思決定をデバッグし、評価（eval）の変更を行い、ワンクリックでデプロイできるように支援します。
原文を表示
Key Takeaways
- Inline subagents block the supervisor agent for the duration of the task. Because tool calls in an agent loop are synchronous, the supervisor can't respond to users, coordinate other work, or course-correct until the subagent finishes, a real problem when a task takes an hour or more.
- Async subagents return a task ID immediately, so supervisors stay in control. The supervisor can launch multiple subagents in parallel, keep talking to the user, send mid-task updates, or cancel work that's no longer needed, more like "fire-and-steer" than "fire-and-forget."
- Async subagents are built on Agent Protocol, so you're not locked into one deployment. They run as fully separate agents with their own process and state, and can be hosted on LangSmith deployments or self-hosted on your own infrastructure, the supervisor manages them through the same standard interface either way.
We're starting to ask more of our agents — we want them to take on longer and more complex tasks. As we've done that, the typical way that we've orchestrated agents has started to show some cracks.
We shipped async subagents to Deep Agents recently to help address that! It's a pattern that lets agents run delegated work in the background, and is something we're excited about since it remedies some of the shortcomings of traditional agent architectures.
Where traditional subagents break down
A subagent is an agent that a supervisor agent delegates scoped work to. The subagent gets instructions from the supervisor, access to relevant tools, and returns a summary when it’s done. It’s a context engineering pattern that we’ve been adopting in practically all of the agents we build for a couple of important reasons:
- Agents perform better when work is broken up into smaller tasks - a supervisor agent gets an understanding of the problem, organizes the tasks, then coordinates workers that execute on them.
- Not all information about a small task is important for the large objective - by splitting things out into focused, independent agent runs, we hide away unnecessary context from the supervisor.
This pattern works. But as we’ve given agents longer and more complex tasks, inline subagents have started to break down.
Agent are put in a deadlock while subagents are working
Subagents are called via a tool that's given to the supervisor agent, and because of the way that tool calling works inside of an agent, the supervisor can't reason about anything else until the tool call has been answered with the subagent response.
This wasn't that big of an issue when subagents were tasked with smaller, low-stakes tasks. But now that we've given agents more complicated tasks and tooling (and with models that take longer to run), this becomes more strongly felt. If a subagent takes an hour, you have to wait an hour before you can interact with the agent again.
New information is hard to coordinate
There are a couple of channels of information that are important to an agent as it's working:
- User input — the user might want to steer the agent, add context, or change priorities while a task is in flight.
- Results from other work — one subagent's output might inform what another subagent should do next.
- Partial progress — sometimes you want to course-correct a task that's heading in the wrong direction before it finishes.
With inline subagents, none of these channels are available. The supervisor is blocked, so the user can't talk to it. Subagents can't run concurrently, so there's no cross-pollination of results. And subagent turns are all-or-nothing meaning there's no way to send a mid-task update or gracefully handle a partial failure. The supervisor fires off a subagent and hopes for the best.
Enter: Async Subagents
A simple way to think about async subagents are as subagents that run in the background instead of sequentially. Instead of waiting for the subagent to finish before moving on, the supervisor launches a task, gets a task ID back immediately, and continues working. It can talk to the user, kick off more subagents, or make progress on other parts of the problem while work is happening in the background.
Because subagents are stateful and maintain their own conversation thread, the supervisor can send follow-up instructions, course-correct mid-task, or cancel work that's no longer needed. Think of it less like "fire-and-forget" and more like "fire-and-steer."
How they work
Instead of giving the supervisor a single blocking tool call per subagent, async subagents give the supervisor a set of management tools that work more like a task queue:
Tool
Purpose
start_async_task
Launch a task on a remote agent. Returns a task ID immediately.
check_async_task
Poll a task's status and retrieve its result when complete.
update_async_task
Send follow-up instructions to a running task.
cancel_async_task
Cancel a running task.
list_async_tasks
List all tracked tasks with their current statuses.
The supervisor uses these tools naturally as part of its reasoning loop — it can start a few tasks, go back to talking with the user, check in on progress, and course-correct as needed.
Traditional subagents are really just a function of the parent agent — they share a process, they share state, and they only exist inside the supervisor's execution loop. Async subagents treat them as separate, individually addressable agents entirely. They can run in their own process, maintain their own state, and scale to runs that might call hundreds or thousands of subagents.
Built on Agent Protocol
That kind of separation requires more than in-process function calls. Async subagents are built on Agent Protocol, a framework-agnostic API specification for managing remote agents. It defines standard endpoints for creating threads, launching runs, polling status, sending updates, and managing long-term memory. Everything the supervisor needs to manage async work through a consistent interface.
The key benefit is deployment flexibility. You aren't locked into any single hosting platform. Run your async subagents on LangSmith deployments for a managed experience, or host them yourself on your own infrastructure. The supervisor doesn't care where the subagent lives. It sends a task, gets a task ID, and manages the lifecycle through the same standard interface either way.
To learn more about Agent Protocol, see the specification and API reference.
How to use async subagents in Deep Agents
Deep Agents is our general purpose agent harness that we talk a lot about. Adding async subagents to DeepAgents is as simple as swapping an async subagent spec into the subagents list — you can mix and match them freely with inline subagents.
With LangSmith Deployment
Define your agents and register them in langgraph.json. Because the researcher is a separate agent, the supervisor gets the async management tools automatically:
// agents.ts
import { createAgent } from "langchain";
import { createDeepAgent } from "deepagents";
export const researcher = createAgent({
model: "anthropic:claude-sonnet-4-6",
instructions: "Perform deep research on the given topic.",
tools: [searchWeb, readUrl],
});
export const agent = createDeepAgent({
model: "anthropic:claude-opus-4-6",
subagents: [{
name: "researcher",
description: "Performs deep research on a topic.",
graphId: "researcher",
}],
});
// langgraph.json
{
"dependencies": ["."],
"graphs": {
"researcher": "./agents.ts:researcher",
"agent": "./agents.ts:agent"
}
}
The subagent runs in its own process with its own state and the supervisor just delegates and checks back.
Self-hosted
If you want full control over where your subagents run, you can host them yourself. The subagent just needs to implement the Agent Protocol endpoints and the supervisor connects to it via a URL instead of a graph ID.
export const agent = createDeepAgent({
model: "anthropic:claude-opus-4-6",
subagents: [{
name: "researcher",
description: "Performs deep research on a topic.",
graphId: "researcher",
url: "http://localhost:2024", // points to your self-hosted server
}],
});
The self-hosted server implements the Agent Protocol endpoints (creating threads, launching runs, polling status, cancelling tasks) and can run anywhere — a Docker container, a VM, your own Kubernetes cluster. We have a complete self-hosted example that includes a Hono server, Postgres-backed state, and Docker Compose setup you can use as a starting point.
Related content
Conceptual Guide
Deep Agents
The runtime behind production deep agents
S. Runkle,
V. Trivedy
April 20, 2026
24
min
Agent Architecture
Partner
Agentic Engineering: How Swarms of AI Agents Are Redefining Software Engineering
R. Kumar,
P. Ramagopal
April 17, 2026
6
min
Deep Agents
Engineering
How We Made Our Docs Test Themselves
Naomi Pentrel
April 15, 2026
3
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 ヘルスコーチの構築：評価、安全性、規制対応について
LangChain が AI ヘルスコーチの開発において、評価手法や安全性確保、規制遵守の重要性を解説している。
AI エージェントに専用コンピューターを付与する
LangChain は、数百万のタスクを実行する AI エージェントが安全かつ効率的に動作するために、各エージェントに個別のファイルシステムやシェル環境を持つ仮想コンピューターを提供するインフラシフトの必要性を提唱している。
LangGraph の耐障害性：リトライ、タイムアウト、エラーハンドラー
LangChain が公開した記事で、LangGraph に組み込まれた耐障害性の三つの仕組み（バックオフ付き自動リトライの RetryPolicy、時間制限の TimeoutPolicy、リトライ失敗後のクリーンアップを行う error_handler）について解説し、SAGA パターンを用いた現実的なマルチステップワークフローの処理方法も紹介している。
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み