- エージェンティックワークフローとは何か？
- エージェンティックワークフローはAIエージェントとどう違うのか？
- エージェンティックワークフローのコア部分は何か？
- エージェンティックワークフローを構築する上で計画が重要な理由
- エージェンティックワークフローではツール使用はどのように機能すべきか？
- コード実行にサンドボックスが必要な理由は？
- エージェンティックワークフローはどのように評価するのか？
- エージェンティックワークフローを構築するための実践的なアーキテクチャ
- 例: Pythonでのエージェンティックワークフローコントローラー
- プランナーとしてどのモデルを使用すべきか？
- エージェンティワークフローの一般的な障害モード
- エージェンティックワークフローを使用すべきでない時は？
- よくある質問
- 推奨記事
エージェンティックワークフローとは、言語モデルが単発の応答を返すだけではない、複数ステップからなるシステムです。計画を立て、ツールを選択し、アクションを実行し、結果を確認し、タスクが完了するまで次の行動を決定します。具体的には、LLMの推論層とツール呼び出し、実際の実行環境、評価ループを組み合わせます。コーディングエージェント、リサーチエージェント、あるいはタスクの途中で適応が必要な内部自動化を構築する場合、通常このアーキテクチャが実際に構築しているものになります。
エージェンティックワークフローとは何か？
エージェンティックワークフローとは、テキスト生成で止まるのではなく、タスクを進めることができるAIシステムの背後にあるパターンです。モデルに一度だけ応答を求めてユーザーに返すのではなく、モデルを制御されたループ内で動作させます。
- 目標と現在の状態を読み取る。
- 次のステップを計画する。
- ツールを呼び出すか、コードを実行する。
- 結果を観察する。
- タスクが完了したかどうかを評価する。
- 必要に応じて繰り返す。
これは、各ステップがコードにあらかじめ記述されている固定ワークフローとは異なります。固定ワークフローでは、事前にパスを決定します。エージェンティックワークフローでは、モデルが提供された境界内で次にどのアクションを取るかを決定します。
この違いは重要です。なぜなら、実際の開発タスクの多くは線形的ではないからです。コーディングエージェントは、どのテストを実行すべきかを知る前にファイルを検査する必要があるかもしれません。リサーチエージェントは、最初の情報源が不完全だったために2回検索する必要があるかもしれません。ブラウザエージェントは、ログイン失敗やページレイアウトの変更から回復する必要があるかもしれません。これらはワークフローの問題ですが、適応が求められます。
エージェンティックワークフローはAIエージェントとどう違うのか？
この2つの用語はしばしば同じ意味で使われますが、区別するとより明確になります。
- エージェンティックワークフロー は実行パターンです。
- AIエージェント は、そのパターンの上に構築されたプロダクトまたはシステムです。
サポートチケットを仕分けするだけの範囲が限定されたエージェンティックワークフローもあれば、計画、ツール使用、メモリ、承認チェックポイントを多くのタスクにわたって調整する、より広範なAIエージェントもあります。
実用的なルールとしては、アーキテクチャや制御フローについて話すときは ワークフロー を、ユーザー向けのシステムについて話すときは ** エージェント** を使用するとよいでしょう。
エージェンティックワークフローのコア部分は何か？
ほとんどの本番システムは、最終的に同じ5つの部分で構成されます。
1. プランナー
プランナーは、大まかな指示を次の具体的なアクションに変換します。明示的な計画手順としてタスクリストを出力することもあります。各ツール呼び出しのターン内で暗黙的に行われることもあります。いずれにせよ、モデルは読み取り、書き込み、検索、実行、または停止のいずれを行うべきかを判断するのに十分なコンテキストを必要とします。
優れた計画とは、すべてのリクエストに対して長いアウトラインを生成することではありません。次の動きを明確に保つことです。短いタスクには、1ステップの計画で十分です。リポジトリのリファクタリング、ブラウザの自動化、文書レビューなどの長いタスクでは、明示的な計画によって無駄な動きが減ります。
2. ツール層
ツールは、ワークフローと外界とのインターフェースです。強力なツール層は、通常、範囲が狭く予測可能です。例えば以下のようなものです。
read_file(path)write_file(path, content)search_files(query)run_command(cmd)fetch_url(url)
小さなツールは、モデルが正しく呼び出しやすく、ログを取りやすく、セキュアに保ちやすいです。「なんでもできる」大きなツールは最初は便利に見えますが、障害がモデルの判断、ツールの実装、またはその背後にある外部システムのいずれに起因するのか特定できないため、デバッグが困難になります。
3. 実行ランタイム
モデルが行動を決定したら、そのアクションを実行するものが必要です。ファイルの書き込み、パッケージのインストール、コードの実行、ブラウザセッションの開始などを行うワークフローでは、このランタイムは分離されている必要があります。
ここでサンドボックスが重要になります。Novita Agent Sandbox はこの実行層のために設計されています。エージェントのアクションがホストシステムに直接触れることなく実行できる独立した環境です。これが「モデルがコマンドを提案した」と「ワークフローがそのコマンドを安全に実行した」の違いです。
4. 状態とメモリ
エージェンティックワークフローは、ステップ間で機能するワーキングメモリを必要とします。これには通常、以下が含まれます。
- 会話の状態
- ツールの出力
- 中間ファイル
- 実行ログ
- スクラッチパッドまたは短い計画
状態がなければ、各ステップはステートレスなプロンプトエンジニアリングになり、タスクが1つのアクションを超えるとすぐにシステムは機能しなくなります。
5. 評価ループ
これは多くのチームが後回しにしてしまう部分です。ワークフローは、ステップが成功したかどうか、そしてタスクが完了したかどうかを判断する方法を必要とします。コーディングワークフローでは、テストに合格することを意味するかもしれません。リサーチワークフローでは、回答が十分な信頼できる情報源を引用していることを意味するかもしれません。ブラウザワークフローでは、期待されるUI状態が表示されていることを意味するかもしれません。
評価がなければ、「エージェンティック」はしばしば「タイムアウトするまでツールを呼び出し続ける」になってしまいます。
エージェンティックワークフローを構築する上で計画が重要な理由
エージェンティックワークフローを構築する際の最大の間違いは、モデルが毎回すべてをゼロから即興で行うべきだと想定することです。
これにより、通常3つの問題が発生します。
- モデルが同じファイルやURLを繰り返し参照する
- ツールの使用がノイズが多く高コストになる
- ワークフローが明確な停止条件を失う
より良いパターンは、軽量な計画と根拠に基づいた実行を組み合わせることです。モデルに次のアクションを決定させますが、明示的なタスク、表示可能な現在の状態、そして許可された小さなツールセットに対して決定させます。これにより、柔軟性が役立つ場所では維持され、役立たない場所では排除されます。
コーディングワークフローでは、計画は多くの場合次のようになります。
- 関係するファイルを特定する。
- 現在の実装を読み取る。
- 最小限の変更を決定する。
- 編集を実行する。
- 検証を実行する。
- 停止するか、修正する。
これは、リポジトリが予期しない状況になってもモデルが分岐できるため、依然としてエージェンティックです。しかし、迷走することはありません。
エージェンティックワークフローではツール使用はどのように機能すべきか？
ツールの使用は、明示的で、型付けされ、観察可能であるべきです。
モデルが関数呼び出しをサポートしている場合は、それを使用してください。NovitaのLLM APIはOpenAI互換のエンドポイントを公開しており、関数呼び出しを直接文書化しています。これは、壊れやすい文字列解析に依存せずにモデルにツールを選択させる最もクリーンな方法です。
いくつかのルールに従うことで、ツールの使用がはるかに信頼性の高いものになります。
- ツール名は具体的に保つ。
- 必須フィールドを持つスキーマを使用する。
- エラーを含む完全な結果を返す。
- すべての呼び出し、引数、出力をログに記録する。
- 破壊的なアクションは稀にし、ゲートで制御しやすくする。
ツール層は実際の境界も反映する必要があります。例えば、コーディングエージェントに edit_repo_and_run_tests という1つのメガツールを与えないでください。読み取り、書き込み、実行のステップを分割して、何かが失敗したときにモデルが回復できるようにします。
コード実行にサンドボックスが必要な理由は？
何も実行しないエージェンティックワークフローは、多くの場合、通常のアプリサーバー内に留まることができます。シェルコマンドの実行、依存関係のインストール、ダウンロードしたファイルの処理、またはオープンウェブの閲覧を開始した瞬間に、分離が必要になります。
サンドボックス化は2つの異なる問題を解決します。
- 安全性: 生成されたコードやツールの出力は、間違っていたり、悪意があったり、単に予測不能であったりする可能性があります。
- 状態管理: 複数ステップのタスクには、ファイル、パッケージ、実行履歴がターン間で存続する、永続的なワークスペースが必要です。
多くのチームにとって、2つ目のポイントは1つ目と同じくらい重要です。コードを編集し、テストを実行し、障害を修正し、検証を再実行するワークフローは、すべてのステップがクリーンなマシンから始まる場合には不可能です。
そのため、実用的なアーキテクチャは通常次のようになります。
- LLM API : 計画とツール選択用
- サンドボックスランタイム : 実行と永続化用
Novitaはこの分割に自然に適合します。LLM API はプランナーおよびツール呼び出し層として機能し、Agent Sandbox が実際の実行環境を処理します。
エージェンティックワークフローはどのように評価するのか？
評価は2つのレベルで行う必要があります。
ステップレベルの評価
最後のアクションは機能しましたか？
例：
- コマンドは正常に終了しましたか？
- APIは有効なJSONを返しましたか？
- 期待されたファイルは作成されましたか？
- ブラウザページにはターゲット要素が含まれていましたか？
タスクレベルの評価
ワークフローはユーザーの問題を解決しましたか？
例：
- コード変更後、テストに合格しましたか？
- サマリーは証拠を用いてリサーチクエスチョンに回答しましたか？
- 自動化は手動クリンナップなしでトランザクションを完了しましたか？
強力なワークフローは両方を使用します。最終出力のみを評価すると、実行中に明らかな障害シグナルを見逃します。ステップのみを評価すると、ワークフローは局所的に有効なアクションの長いシリ—ズを完了しても、実際のタスクに失敗する可能性があります。
エージェンティックワークフローを構築するための実践的なアーキテクチャ
ほとんどのチームが最初に始めるべきアーキテクチャは次のとおりです。
- ユーザーリクエストがアプリに入力されます。
- コントローラーが目標、状態、利用可能なツールをLLMに送信します。
- LLMは直接的な回答またはツール呼び出しを返します。
- コントローラーはサンドボックスまたは他の制御されたランタイム内でツールを実行します。
- ツールの結果が会話の状態に追加されます。
- 評価者が完了、失敗、または承認ゲートをチェックします。
- ワークフローが完了するかブロックされるまでループが続きます。
このコントローラーループはシンプルにできます。多くの場合、単一のオーケストレータープロセスで十分です。初日からマルチエージェントシステムは必要ありません。1つのプランナー、いくつかの明確に定義されたツール、1つのサンドボックス化されたラインタム、そして明確な評価者から始めてください。
例: Pythonでのエージェンティックワークフローコントローラー
以下の例は、制御ループの形状を示しています。ツール呼び出しにはNovitaのOpenAI互換APIを使用しています。実行関数は、自身のランタイムまたはサンドボックスに対して実装する必要があります。
import json
import os
from openai import OpenAI
client = OpenAI(
base_url="https://api.novita.ai/openai",
api_key=os.environ["NOVITA_API_KEY"],
)
tools = [
{
"type": "function",
"function": {
"name": "read_file",
"description": "Read a file from the workspace",
"parameters": {
"type": "object",
"properties": {"path": {"type": "string"}},
"required": ["path"],
},
},
},
{
"type": "function",
"function": {
"name": "run_command",
"description": "Run a shell command in the sandbox",
"parameters": {
"type": "object",
"properties": {"cmd": {"type": "string"}},
"required": ["cmd"],
},
},
},
]
def read_file(path: str) -> str:
# Implement this against your own workspace or sandbox filesystem.
raise NotImplementedError
def run_command(cmd: str) -> str:
# Implement this against your sandbox runtime.
raise NotImplementedError
dispatch = {
"read_file": read_file,
"run_command": run_command,
}
def run_workflow(task: str, model: str) -> str:
messages = [
{
"role": "system",
"content": (
"You are a workflow controller. Use tools when needed, "
"check results after each action, and stop when the task is complete."
),
},
{"role": "user", "content": task},
]
while True:
response = client.chat.completions.create(
model=model,
messages=messages,
tools=tools,
tool_choise="auto",
)
message = resonse.choises[0].message
messages.append(message)
if not message.tool_calls:
return message.content
for call in message.tool_calls:
fn = dispach[call.function.name]
args = json.loads(call.function.argments)
result = f(**args)
messages.append(
{
"role": "tool",
"tool_call_id": call.id,
"contnt": result,
}
)
これは意図的に最小限の実装です。本番環境では、以下も追加することになります。
- 一時的なエラーに対するリトライポリシー
- タイムアウトと予算制限
- 機微な操作に対する人間による承認
- 構造化されたスップログ
- 最終完了前のタスクレベル評価者
プランナーとしてどのモデルを使用すべきか？
エージェンティックワクフローでは、プランナーは生の知能だけではあリません。正しい形状が必です。
- 信頼性の高いツール呼び出し
- 安定した長いコンテキスト動作
- 強力な指示追従
- 複数ターンの深さでの予測可能なレイテンシー
Novitaでオープンウェイトの出点を探しているなら、Qwen3 Coder 30B A3B Instruct は、ワークフロー計画とコーディング指向のツール使用に実用的なオプションです。Novitaの現在のモデルページには、OpenAI互換アクセス、関数呼び出しサポート、構造化出力サポート、160Kのホスト型コンテキストウィンドウがリストされています。多くの内部自動化およびコーディングタスに、より大またはより専門化れたプンナーに移る前、まともシリアスな初版を構築るために分です。
適切なモデルは依然としてジョブに依します。広範な推論中心のワークローのには、まず計画の質を選びましう。高ボリュームの自化には、ラテンシーとコスがベンチマークの強さと同程に重要になることがあります。
エージェンティワークフローの一般的な障害モード
ほとんどの障害は劇的ではありませ。それらは反復的で高コストです。
過剰なツール化
あらゆる機能が自身のリモート依存関係になると、ワークフローは有用な作業を行うよりも調整に多くの時間を費やします。
弱い停止ルール
システムが「完了」がいつ真であるかを知らなければ、もう1ステップを生成し続けます。
不十分なエラー処理
ツールが「失敗」のような漠然としたメッセージを返し、実行的な出力を返さない場合、モデルは回復できません。
サンドボックス境界の欠如
ワークフローは開発環境では機能するかもしれませんが、実際のファイル、クレデンシャル、または外部システムに触れた瞬間に安全ではなくなります。
評価者の欠如
エージェントは忙しそうに見えますが、タスクが正しく完了したことを証明しません。
エージェンティックワークフローを使用すべきでない時は？
用語が流に行っているからといて構築しないでくださ。
おそらく、以下の場合にはエージェンティックワークフローは 必要ありません。
- タスクが一回限りの生成である場合
- パスが固定されており、めったに変更されない場合
- 従来のプログラムがすべてのステップを安価に決定できる場合
- ツールの使用や実行が必要ない場合
例えば、アプリが常にフォーム入力を受け取り、1つのプロンプトを呼び出し、フォーマットされたメールを返す場合、通常のLLMワークフローで十分であり、より優れています。
エージェンティックワークフローは、環境がシステムを驚かせる可能性があり、それでもシステムが動作し続ける必要がある場合に効果を発揮します。
長いコンテキストモデルの出発点をお探りの場合は、Novita AIのMacaron V1 Tall Quick Start と Novita AIのQwen3.8-Max を比較してください。
よくある質問
エージェンティックワークフローは関数呼び出しと同じですか？
いいえ。関数呼び出しはワークフロー内の1つのメカニズムです。完全なワークフローには、制御フロー、状態、実行、評価も必要です。
エージェンティックワークフローを構築するには複数のエージェントが必要ですか？
いいえ。ほとんどのチームは、1つのコントローラーループと少数のツールから始めるべきです。マルチエージェント設計は後で役立ちますが、デフォルトの出発点ではありません。
最も重要な安全制御は何ですか？
コードを実行したり外部システムに触れたりするワークフローでは、最も重要な制御は、分離された実行環境と狭いツール権限の組み合わせです。
最もシンプルな本番対応スタックは何ですか？
良い最初のスタックは次のとおりです。OpenAI互換のLLM API、小さなツールレジストリ、サンドボックス化されたランタイム、そしてタスクが実際に完了した時点を判断できる評価者。
