前提

自分がキャッチアップするために、仕様をAIに聞きました。
この記事は、内容をそのままドーンしただけです。
ハルシネーションの可能性も大いにあるので、内容の判断は自己責任でお願いします。

ADK Python v2.0.0-beta.1 新機能調査レポート

調査日: 2026-04-23

目次

変更概要
Workflow Engine
Agent Mode（エージェントモード）
その他の新機能
変更なしの領域
v1.x との対比

1. 変更概要

v2.0.0-beta.1 では、ADK の根幹となるエージェント実行モデルが大幅に刷新されました。最大の変更は Workflow Engine の導入と Agent Mode の追加です。

主要カテゴリ別の変更一覧

カテゴリ	変更内容	影響度
Workflow Engine	ノードベースのグラフオーケストレーション	大
Agent Mode	`chat` / `task` / `single_turn` の3モード導入	大
CLI / Web UI	ワークフローグラフ可視化、ノードタイプ別アイコン	中
Live / ストリーミング	`save_live_blob`, `live_session_id` 追加	中
テレメトリ	ネイティブ OpenTelemetry メトリクス	中
セキュリティ	ネスト YAML 設定の RCE 脆弱性修正	中
互換性	Python 3.10 サポート廃止（3.11+）	小
Skills	変更なし（v1.x と同一）	-

2. Workflow Engine

2.1 全体アーキテクチャ

Workflow Engine は ノードベースのグラフオーケストレーション を提供します。従来の transfer_to_agent によるLLM任せの制御移動に代わり、明示的なグラフ定義で処理フローを構築します。

                    ┌──────────────────────────────────────┐
                    │          Workflow (orchestrator)     │
                    │                                      │
  ┌───────┐         │   ┌─────┐     ┌─────┐     ┌─────┐    │
  │ START │────────▶│   │ A   │────▶│ B   │────▶│ C   │    │
  └───────┘         │   └─────┘     └─────┘     └─────┘    │
                    │       │                      ▲       │
                    │       │      ┌─────┐         │       │
                    │       └─────▶│ D   │─────────┘       │
                    │              └─────┘    (JoinNode)   │
                    └──────────────────────────────────────┘

設計思想:

確定的なフロー制御 — LLM の判断ではなく、グラフ構造がフローを決定
明示的な状態管理 — ctx.state による読み書きと state_delta による追跡
完全な再開可能性 — セッションイベントのスキャンによる Resume
組み込みの耐障害性 — リトライ、タイムアウト、エラー伝播

2.2 ノードの種類

全ノードは BaseNode を継承しています。

ノード一覧

ノード	ファイル	役割
`BaseNode`	`_base_node.py`	抽象基底クラス。全ノード共通のインターフェース
`FunctionNode`	`_function_node.py`	sync/async 関数・ジェネレータをノード化
`JoinNode`	`_join_node.py`	Fan-in: 全先行ノード完了まで待機し、入力を集約
`Node`	`_node.py`	カスタムノードの基底。`run_node_impl()` をオーバーライド
`_ToolNode`	`_tool_node.py`	`BaseTool` をノードとしてラップ
`_ParallelWorker`	`_parallel_worker.py`	Fan-out: 入力リストに対してノードを並列実行
`START`	`_base_node.py`	ワークフロー開始の起点（実行されない）

BaseNode の主要プロパティ

class BaseNode(BaseModel):
    name: str                        # Python識別子（必須）
    input_schema: type | None        # 入力バリデーション
    output_schema: type | None       # 出力バリデーション
    state_schema: type | None        # state 変更のバリデーション
    wait_for_output: bool            # True なら明示的出力まで待機（HITL用）
    rerun_on_resume: bool            # resume 時に再実行するか
    timeout: float | None            # タイムアウト（秒）
    retry_config: RetryConfig        # リトライ設定

FunctionNode の特徴

sync / async / ジェネレータ / async ジェネレータに対応
パラメータバインドモード:
- 'state'（デフォルト）: ctx.state からパラメータを取得
- 'node_input': ノード入力 dict からパラメータを取得
Pydantic TypeAdapter による型変換（dict → BaseModel 等）
auth_config による認証ゲート（HITL の変形）

2.3 Workflow クラスとエッジ定義

基本的な定義

from google.adk.workflow import Workflow, START

workflow = Workflow(
    name="my_workflow",
    edges=[
        (START, node_a),                              # 無条件エッジ
        (node_a, {"high": node_b, "low": node_c}),   # 条件分岐
        (node_a, (node_d, node_e)),                   # Fan-out
        ((node_d, node_e), join_node),                # Fan-in
    ],
    max_concurrency=5,
)

エッジパターン一覧

パターン	Python	イメージ
無条件	`(A, B)`	`A ──▶ B`
チェーン	`(A, B, C)`	`A ──▶ B ──▶ C`
条件分岐	`(A, {"x": B, "y": C})`	`A ──◆── "x" ──▶ B` 　　　`└─ "y" ──▶ C`
Fan-out	`(A, (B, C))`	`A ──┬──▶ B` 　　　`└──▶ C`
Fan-in	`((B, C), join)`	`B ──┐` 　　　`├──▶ join` `C ──┘`

条件分岐の例

async def classifier(ctx):
    score = ctx.state["score"]
    ctx.output = score
    ctx.route = "high" if score > 10 else "low"

workflow = Workflow(
    name="routing_example",
    edges=[
        (START, classifier),
        (classifier, {
            "high": high_priority_handler,
            "low":  low_priority_handler,
        }),
    ],
)

実行ループ（3フェーズ）

 SETUP
 ─────────────────────────────────────────
  - セッションイベントからノード状態を復元
  - resume 用トリガーを処理
  - 動的ノードスケジューラの closure を作成

          │
          ▼

 LOOP
 ─────────────────────────────────────────
  while True:
    1. 準備完了ノードをスケジュール (→ RUNNING)
    2. asyncio.wait() で完了を待機
    3. 完了処理 → 後続ノードをトリガー
    4. 全ノード完了 or エラー → break

          │
          ▼

 FINALIZE
 ─────────────────────────────────────────
  - WAITING ノードの中断情報を収集
  - 出力 / 状態変更を親に伝播

2.4 ノードの状態遷移

 ┌──────────┐     ┌─────────┐     ┌─────────┐     ┌───────────┐
 │ INACTIVE │────▶│ PENDING │────▶│ RUNNING │────▶│ COMPLETED │
 └──────────┘     └─────────┘     └─────────┘     └───────────┘
                                       │
                                       ├──────────▶ WAITING
                                       │           (HITL 待ち)
                                       │
                                       ├──────────▶ FAILED
                                       │           (例外発生)
                                       │
                                       └──────────▶ CANCELLED
                                                   (タイムアウト)

NodeState が各ノードの実行メタデータを保持します:

class NodeState:
    status: NodeStatus          # 上記の状態値
    input: Any                  # ノードへの入力
    attempt_count: int          # リトライ回数（1始まり）
    interrupts: list[str]       # 未解決の中断ID
    resume_inputs: dict         # ユーザー回答（interrupt_id → 値）
    run_counter: int            # 実行カウンタ
    run_id: str | None          # 実行ID
    parent_run_id: str | None   # 親の実行ID（動的ノード用）

2.5 Context（コンテキスト）

各ノード実行時に渡される中心オブジェクトです。

主要プロパティ

プロパティ	型	用途
`ctx.state`	`StateDict`	状態の読み書き（`state_delta` として追跡）
`ctx.output`	`Any`	ノードの出力値を設定
`ctx.route`	`RouteValue`	条件分岐のルート値を設定
`ctx.node_path`	`str`	階層パス（例: `/wf@1/node_a@2`）
`ctx.run_id`	`str`	実行ID
`ctx.attempt_count`	`int`	現在の試行回数
`ctx.resume_inputs`	`dict`	HITL 応答（`interrupt_id` → 値）
`ctx.error`	`Exception`	エラー情報（読み取り専用）
`ctx.error_node_path`	`str`	エラー発生ノードのパス（読み取り専用）

使用例

async def process_data(ctx):
    # 状態の読み書き
    data = ctx.state["input_data"]
    ctx.state["processed"] = transform(data)

    # 出力の設定
    ctx.output = {"status": "done", "count": len(data)}

    # 条件分岐のルート指定
    ctx.route = "success" if len(data) > 0 else "empty"

2.6 動的ノード実行（`ctx.run_node()`）

ノード内から別のノードを動的に呼び出す仕組みです。

async def orchestrator(ctx):
    # 動的にエージェントを呼び出し
    result = await ctx.run_node(
        agent,                        # NodeLike（BaseNode, 関数, ツール）
        node_input=data,              # 入力データ
        use_as_output=False,          # True なら子の出力を自分の出力にする
        use_sub_branch=True,          # ブランチ分離
    )
    ctx.state["agent_result"] = result

DynamicNodeScheduler の3つの実行モード

モード	条件	動作
新規実行	初回呼び出し	NodeRunner で実行
重複排除	前回完了済み	キャッシュから即座に返却（再実行なし）
Resume	中断があり応答済み	ユーザー応答を反映して再実行

2.7 HITL（Human-in-the-Loop）

ノード実行中にユーザー入力を待つ仕組みです。

基本的な使い方

from google.adk.workflow.utils import RequestInput

async def approval_node(ctx):
    # ユーザーに質問を投げる
    yield RequestInput(
        interrupt_id="approve",
        message="この操作を承認しますか？",
        response_schema=bool,
    )

    # resume 後にここに到達
    approved = ctx.resume_inputs["approve"]
    if approved:
        ctx.output = "承認されました"
    else:
        ctx.output = "却下されました"

動作フロー

 1. ノードが RequestInput を yield
          │
          ▼
 2. Event に変換、long_running_tool_ids に ID を記録
          │
          ▼
 3. ノードは WAITING 状態に遷移
          │
          ▼
 4. ユーザーが応答を返す
          │
          ▼
 5. セッションイベントをスキャンし resume_inputs を復元
          │
          ▼
 6. ノードを再実行（rerun_on_resume=True の場合）

認証（Auth）による HITL

FunctionNode に auth_config を設定すると、認証情報の取得を HITL として自動処理します。

node = FunctionNode(
    func=my_api_call,
    auth_config=AuthConfig(...),
    rerun_on_resume=True,   # 必須
)
# → 認証情報未取得なら自動で認証リクエストイベントを生成
# → ユーザーが認証完了後、ノードを再実行

2.8 リトライとタイムアウト

from google.adk.workflow import RetryConfig

node = FunctionNode(
    func=flaky_api_call,
    retry_config=RetryConfig(
        max_attempts=5,             # 最大試行回数（デフォルト: 5）
        initial_delay=1.0,          # 初回リトライ待機秒数（デフォルト: 1.0）
        max_delay=60.0,             # 最大待機時間（デフォルト: 60.0）
        backoff_factor=2.0,         # 指数バックオフ倍率（デフォルト: 2.0）
        jitter=1.0,                 # ランダム揺らぎ（デフォルト: 1.0）
        exceptions=[TimeoutError],  # リトライ対象例外（デフォルト: 全例外）
    ),
    timeout=30.0,                   # 30秒でタイムアウト → NodeTimeoutError
)

エラー型	発生条件	用途
`NodeTimeoutError`	ノードが `timeout` を超過	リトライ対象にもなる
`NodeInterruptedError`	動的子ノードに未解決の中断あり	内部シグナル
`DynamicNodeFailError`	動的子ノードが失敗	親への伝播用

2.9 LlmAgent との統合

LlmAgent はワークフロー内でノードとして直接使用できます。

from google.adk.agents import LlmAgent
from google.adk.workflow import Workflow, START

classifier = LlmAgent(
    name="classifier",
    model="gemini-2.5-flash",
    instruction="入力テキストを positive / negative に分類してください",
    output_schema=ClassificationResult,
)

handler_positive = FunctionNode(func=handle_positive)
handler_negative = FunctionNode(func=handle_negative)

workflow = Workflow(
    name="sentiment_pipeline",
    edges=[
        (START, classifier),
        (classifier, {
            "positive": handler_positive,
            "negative": handler_negative,
        }),
    ],
)

ワークフロー内での LlmAgent の動作

設定	ワークフロー内でのデフォルト
`mode`	`'single_turn'`（1回のリクエスト・レスポンスで完結）
`wait_for_output`	`False`（single_turn）/ `True`（task, chat）
会話履歴	ノード単位で独立（親の履歴は引き継がない）

mode='task' や mode='chat' を明示指定すると wait_for_output=True となり、複数ターンの対話が可能になります。

2.10 NodeRunner（ノード実行エンジン）

各ノードの実行を担う内部クラスです。

 NodeRunner.run()
  │
  ├── 1. 子 Context を作成
  │      - ブランチ、状態スキーマを継承
  │      - 前回の output / interrupt_ids を引き継ぎ（resume 時）
  │
  ├── 2. node.run() をイテレート
  │      ├── Event         → エンリッチ（author, node_path, branch）して queue へ
  │      ├── RequestInput  → HITL Event に変換
  │      └── 生データ       → Event にラップ
  │
  ├── 3. タイムアウト監視
  │
  ├── 4. リトライ制御（retry_config に基づく）
  │
  └── 5. 結果 Context を返却（output, route, interrupt_ids）

2.11 ファイル構成

src/google/adk/workflow/
│
├── _base_node.py                    # BaseNode 抽象基底
├── _node.py                         # Node（サブクラス用）+ @node デコレータ
├── _function_node.py                # FunctionNode
├── _join_node.py                    # JoinNode（Fan-in）
├── _tool_node.py                    # _ToolNode
├── _parallel_worker.py              # _ParallelWorker（Fan-out）
│
├── _workflow.py                     # Workflow オーケストレータ（約970行）
├── _workflow_graph.py               # WorkflowGraph グラフ構築
├── _graph_definitions.py            # Edge, Route, NodeLike 型定義
│
├── _node_runner.py                  # NodeRunner（約350行）
├── _node_state.py                   # NodeState
├── _node_status.py                  # NodeStatus enum
├── _trigger.py                      # Trigger データモデル
│
├── _dynamic_node_scheduler.py       # DynamicNodeScheduler
├── _dynamic_node_registry.py        # 動的ノード登録
├── _schedule_dynamic_node.py        # ScheduleDynamicNode プロトコル
│
├── _llm_agent_wrapper.py            # LlmAgent ノード統合
├── _retry_config.py                 # RetryConfig
├── _errors.py                       # NodeTimeoutError 等
│
└── utils/
    ├── _workflow_hitl_utils.py       # RequestInput, HITL イベント生成
    ├── _rehydration_utils.py         # Resume / イベントスキャン
    ├── _workflow_graph_utils.py      # build_node, グラフ構築ユーティリティ
    └── _retry_utils.py              # リトライロジック

3. Agent Mode（エージェントモード）

3.1 モードの定義

v2.0.0-beta.1 では LlmAgent に mode フィールドが新設されました。

mode: Literal['chat', 'task', 'single_turn'] | None = None

デフォルト: サブエージェントとして使う場合は 'chat'、ワークフローのノードとして使う場合は 'single_turn'

定義箇所: src/google/adk/agents/llm_agent.py

3.2 モード別の動作比較

観点	`chat`	`single_turn`	`task`
概要	通常のチャットエージェント	ユーザーと対話せず1回で完了	ユーザーと対話しつつタスクを遂行
回答権	子に移譲（子がユーザーと直接対話）	親が保持	親が保持
親に結果が返るか	構造化された結果は返らない。制御が親に戻るかは LLM の判断次第。戻った場合、親は共有された会話履歴から状況を把握する	返る（同期・ツール戻り値）	返る（非同期・`FinishTaskTool` 経由で構造化データ）
転送先になれるか	Yes	No	No
自分から転送できるか	Yes	No	No
親での扱い	通常のサブエージェント	`_SingleTurnAgentTool` でツール化	`_TaskAgentTool` でツール化
実行方式	`transfer_to_agent`	`ctx.run_node()` で同期実行	`request_task` で委譲（非同期的）
追加ツール	なし	なし	`FinishTaskTool` 自動追加
ユースケース	汎用チャット	分類・要約・変換	フォーム入力支援・複数ステップ調査

3.3 各モードの詳細

`chat`（デフォルト）

従来通りの動作です。親エージェントの LLM が transfer_to_agent ツールを使ってこのエージェントに制御を移します。エージェント間で会話コンテキストが共有されます。

assistant = LlmAgent(
    name="assistant",
    mode="chat",         # デフォルトなので省略可
    sub_agents=[specialist_a, specialist_b],
)

`single_turn`

親エージェントからは ツールコール として同期的に呼び出されます。ctx.run_node() 経由で実行され、結果を即座に返します。

summarizer = LlmAgent(
    name="summarizer",
    mode="single_turn",
    instruction="与えられたテキストを3行で要約してください",
    output_schema=SummaryResult,
)

`task`

親エージェントからは request_task アクションとして委譲されます。FinishTaskTool が自動追加され、タスク完了を明示的に宣言します。

researcher = LlmAgent(
    name="researcher",
    mode="task",
    instruction="ユーザーの質問に対して調査を行い、結果を報告してください",
)

3.4 転送制御の仕組み

agent_transfer.py 内で、モードに基づく転送制御が実装されています。

転送指示の抑制

# agent_transfer.py
def _build_transfer_instruction(tool_name, agent, target_agents):
    if agent.mode in ('task', 'single_turn'):
        return ''    # 転送指示を一切生成しない
    # ...

転送先からの除外

# agent_transfer.py
def _get_transfer_targets(agent):
    result = []
    result.extend([
        sub_agent for sub_agent in agent.sub_agents
        if sub_agent.mode not in ('single_turn', 'task')   # 除外
    ])
    # peer agents も同様に除外

3.5 ツールラッパーの実装

モードに応じて、サブエージェントは自動的にツールとしてラップされます。

 親エージェント (mode='chat')
 │
 ├── sub_agent_A (mode='chat')
 │    └─→ transfer_to_agent で制御移動
 │
 ├── sub_agent_B (mode='single_turn')
 │    └─→ _SingleTurnAgentTool: ctx.run_node() で同期実行、結果を返す
 │
 └── sub_agent_C (mode='task')
      └─→ _TaskAgentTool: request_task で委譲、即座に返答

`_SingleTurnAgentTool`

class _SingleTurnAgentTool(AgentTool):
    async def run_async(self, *, args, tool_context):
        # ctx.run_node() で同期的に実行し、結果を返す
        return await tool_context.run_node(
            self.agent, node_input=node_input, use_sub_branch=True
        )

`_TaskAgentTool`

class _TaskAgentTool(AgentTool):
    async def run_async(self, *, args, tool_context):
        # request_task アクションに委譲情報を記録
        tool_context.actions.request_task[tool_context.function_call_id] = {
            'agentName': self.agent.name,
            'input': task_input,
        }
        return f'Task delegated to {self.agent.name}.'

4. その他の新機能

CLI / Web UI

ワークフローグラフ可視化 — ノードタイプ別アイコン、条件ノードのダイヤモンド表示、ダークモード対応
BaseNode をルートとした adk web / adk run のサポート
イベントグラフでのアクティブノード表示
サブワークフローの再帰的発見と複数ワークフロー表示

Live / ストリーミング

save_live_blob クエリパラメータ — /run_live エンドポイントに追加
live_session_id を LlmResponse に追加
入力文字起こしをユーザーメッセージとして扱う修正

テレメトリ / Observability

ネイティブ OpenTelemetry エージェントメトリクス の追加
ワークフロートレーシングのコンテキスト伝播修正

セキュリティ

ネスト YAML 設定による RCE 脆弱性のブロック

その他

変更	内容
`VertexAiMemoryBankService`	`memories.ingest_events` サポート追加
GitHub OAuth サンプル	トークンリクエストのデモ
`google-adk` ユーザーエージェント	Parameter Manager / Secret Manager クライアントに追加
App Engine デプロイ	v2 フラグによる v2 依存関係のインストール
Python 3.10	サポート廃止（3.11+ 必須）

5. 変更なしの領域

領域	状態
Skills (`src/google/adk/skills/`)	v1.x と完全に同一（diff なし）

6. v1.x との対比

観点	v1.x	v2.0.0-beta.1
フロー制御	`transfer_to_agent` で LLM 任せ	明示的なグラフ定義で確定的なフロー
状態管理	暗黙的な状態共有	`ctx.state` + `state_delta` による明示的管理
エラーハンドリング	エラー時の動作が不明確	リトライ、タイムアウト、エラー伝播が組み込み
ユーザー入力	会話フローに依存	`RequestInput` による構造化された HITL
並列実行	仕組みなし	Fan-out / Fan-in / `max_concurrency`
再開	困難	イベントスキャンによる完全な Resume
エージェント委譲	全て `transfer_to_agent`	`chat` / `single_turn` / `task` の3モード
可視化	エージェントツリー	ワークフローグラフ（ノードタイプ別アイコン）

7. Workflow の並列実行モデル

基本原則: グラフ構造が並列度を決定する

Workflow Engine は 「基本は非同期並列」ではなく、「グラフの依存関係に従って、可能な箇所だけ並列」 で動作します。

コアループは以下のように動きます:

while True:
    1. trigger_buffer から準備完了ノードを収集
    2. それぞれを asyncio.create_task() で起動
    3. asyncio.wait(return_when=FIRST_COMPLETED) で待機
    4. 完了したノードの後続をトリガー → trigger_buffer に追加
    5. 繰り返し

パターン別の動作

エッジ定義	動作
`(START, A)` → `(A, B)`	A → B の逐次実行
`(START, (A, B))`	A, B が並列実行
`(START, A)` → `(START, B)`	A, B が並列実行（START から2本のエッジ）
`(A, B)` → `(A, C)`	A 完了後、B と C が並列実行
`((B, C), join)`	B, C 両方完了まで join は待機

具体例

      START
       / \
      A   B     ← 並列（Fan-out）
      |   |
      C   D     ← それぞれ先行ノード完了後に開始（A→C, B→D は並列）
       \ /
      JOIN      ← C, D 両方完了まで待機
       |
       E        ← 逐次

並列度の制御

workflow = Workflow(
    name="example",
    edges=[...],
    max_concurrency=3,   # 同時実行ノードは最大3つ
)

max_concurrency 未設定 → 制限なし（トリガー可能なノードは全て即座に起動）
設定あり → len(pending_tasks) >= max_concurrency のとき、新規スケジュールを保留
動的ノード（ctx.run_node() 経由）はこの制限の対象外（呼び出し元ノード内で inline に await される）

注意点

asyncio ベースの協調的マルチタスクであり、マルチスレッドやマルチプロセスではない
明示的に Fan-out しない限り並列にはならない
直列チェーン (A, B, C) は必ず逐次実行

8. Agent Mode の回答権と結果の流れ

v1.x との対応関係

v2 の mode	v1.x での対応概念	回答権
`chat`	従来の `sub_agent`	子に移譲 — 子がユーザーと直接対話
`single_turn`	従来の `AgentTool`	親が保持 — 結果をツール戻り値として受け取る
`task`	新規	親が保持 — 別ブランチで隔離実行

親エージェントへの結果の返り方

mode	親に結果が返るか	仕組み
`single_turn`	返る（同期）	ツールコールの戻り値として結果が返る
`task`	返る（非同期・構造化）	`FinishTaskTool` 経由で `output_schema` に沿った結果が返る
`chat`	構造化された結果は返らない（LLM判断で制御が戻る可能性はある）	制御が子に移り、子がユーザーと直接対話。親に戻るかは子の LLM が判断。戻った場合は共有された会話履歴から状況を把握

各モードの実行フロー

`single_turn` — 同期的にツール結果が返る

親LLM → ツールコール(summarizer)
       → ctx.run_node() で同期実行
       → 結果が返る
       → 親LLMが結果を使って応答

`task` — 別ブランチで隔離実行、構造化された結果が返る

親LLM → ツールコール(researcher)
       → "Task delegated to researcher." が即座に返る
       → researcher は別ブランチ（task:{fc_id}）で起動
          → ユーザーと対話可能（質問したり、ツールを使ったり）
          → 完了時に FinishTaskTool を呼ぶ
          → output_schema に沿った構造化データを返す

`chat` — 制御そのものが移動（バトンタッチ）

親LLM → transfer_to_agent(specialist)
       → 制御が specialist に移る
       → specialist がユーザーと直接対話
       → specialist が transfer_to_agent(親) で戻すまで親は関与しない

task モードのポイント

コンテキスト隔離: task エージェントは task:{fc_id} という別ブランチで動くため、親のコンテキストを圧迫しない
構造化された結果: FinishTaskTool が output_schema に基づいてバリデーション済みの結果を返す。スキーマ未定義の場合は { result: "要約文字列" } がデフォルト
ユーザー対話可能: single_turn と異なり、task エージェントはユーザーに質問したりツールを使ったりできる
FinishTaskTool の自動追加: mode='task' を設定すると、タスク完了を宣言するための finish_task ツールが自動的にエージェントに追加される

`single_turn` と `task` の使い分け

観点	`single_turn`	`task`
実行モデル	同期（1回のLLM呼び出し）	非同期（複数ターン可能）
ユーザー対話	不可	可能
コンテキスト	サブブランチ（隔離）	別ブランチ（隔離）
結果の返し方	ツール戻り値	`FinishTaskTool`
適したタスク	分類・要約・変換	調査・フォーム入力支援・複数ステップ処理

注記: 本レポートは release/v2.0.0-beta.1 ブランチのコードを origin/main と比較した結果に基づいています。beta リリースのため、GA までに仕様が変更される可能性があります。