前提
自分がキャッチアップするために、仕様をAIに聞きました。
この記事は、内容をそのままドーンしただけです。
ハルシネーションの可能性も大いにあるので、内容の判断は自己責任でお願いします。
ADK Python v2.0.0-beta.1 新機能調査レポート
調査日: 2026-04-23
目次
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 ──┐ ├──▶ joinC ──┘
|
条件分岐の例
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 までに仕様が変更される可能性があります。