- エージェンティックワークフローとは？
- エージェンティックワークフローとAIエージェントの違いは？
- エージェンティックワークフローのコア部分は何ですか？
- エージェンティックワークフロー構築において計画が重要な理由
- エージェンティックワークフローにおけるツール使用はどうあるべきか？
- コード実行にサンドボックスが必要な理由
- エージェンティックワークフローをどのように評価するか？
- エージェンティックワークフロー構築のための実用的なアーキテクチャ
- 例：Pythonでのエージェンティックワークフローコントローラー
- プランナーとしてどのモデルを使用すべきか？
- エージェンティックワークフローにおける一般的な障害モード
- エージェンティックワークフローを使用すべきでない場合
- FAQ
- おすすめ記事
エージェンティックワークフローは、言語モデルが単に一度応答するだけではなく、計画を立て、ツールを選択し、アクションを実行し、結果を確認し、タスクが完了するまで次に何をすべきかを判断するマルチステップシステムです。実際には、これは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 のようなメガツールを与えないでください。読み取り、書き込み、実行のステップを分割して、何かが失敗したときにモデルが回復できるようにします。
コード実行にサンドボックスが必要な理由
何も実行しないエージェンティックワークフローは、多くの場合通常のアプリサーバー内に留まることができます。シェルコマンドの実行、依存関係のインストール、ダウンロードファイルの処理、オープンウェブの閲覧を開始するとすぐに、分離が必要になります。
サンドボックス化は2つの異なる問題を解決します：
- 安全性：生成されたコードやツールの出力は、間違っていたり、敵対的であったり、単に予測不能である可能性があります。
- 状態管理：マルチステップのタスクには、ファイル、パッケージ、実行履歴がターン間で保持される永続的なワークスペースが必要です。
多くのチームにとって、2番目のポイントは最初のポイントと同じくらい重要です。コードを編集し、テストを実行し、失敗を修正し、再検証するワークフローは、すべてのステップがクリーンなマシンから始まる場合には不可能です。
そのため、実用的なアーキテクチャは通常次のようになります：
- 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": "ワークスペースからファイルを読み取る",
"parameters": {
"type": "object",
"properties": {"path": {"type": "string"}},
"required": ["path"],
},
},
},
{
"type": "function",
"function": {
"name": "run_command",
"description": "サンドボックス内でシェルコマンドを実行する",
"parameters": {
"type": "object",
"properties": {"cmd": {"type": "string"}},
"required": ["cmd"],
},
},
},
]
def read_file(path: str) -> str:
# 独自のワークスペースまたはサンドボックスファイルシステムに対して実装してください。
raise NotImplementedError
def run_command(cmd: str) -> str:
# サンドボックスランタイムに対して実装してください。
raise NotImplementedError
dispatch = {
"read_file": read_file,
"run_command": run_command,
}
def run_workflow(task: str, model: str) -> str:
messages = [
{
"role": "system",
"content": (
"あなたはワークフローコントローラーです。必要に応じてツールを使用し、"
"各アクション後に結果を確認し、タスクが完了したら停止してください。"
),
},
{"role": "user", "content": task},
]
while True:
response = client.chat.completions.create(
model=model,
messages=messages,
tools=tools,
tool_choice="auto",
)
message = response.choices[0].message
messages.append(message)
if not message.tool_calls:
return message.content
for call in message.tool_calls:
fn = dispatch[call.function.name]
args = json.loads(call.function.arguments)
result = fn(**args)
messages.append(
{
"role": "tool",
"tool_call_id": call.id,
"content": result,
}
)
これは意図的に最小限です。本番環境では、以下も追加します：
- 一時的なエラーに対する再試行ポリシー
- タイムアウトと予算制限
- 機密アクションに対する人間の承認
- 構造化されたステップログ
- 最終完了前のタスクレベル評価者
プランナーとしてどのモデルを使用すべきか？
エージェンティックワークフローでは、プランナーモデルは生の知能だけでなく、適切な形状が必要です：
- 信頼性の高いツール呼び出し
- 安定したロングコンテキスト動作
- 強力な指示追従
- マルチターン深さでの予測可能なレイテンシー
Novitaでオープンウェイトの出発点を探しているなら、Qwen3 Coder 30B A3B Instruct はワークフロー計画とコーディング指向のツール使用に実用的なオプションです。Novitaの現在のモデルページには、OpenAI互換アクセス、関数呼び出しサポート、構造化出力サポート、160Kのホスト型コンテキストウィンドウがリストされています。多くの内部自動化およびコーディングタスクでは、より大規模またはより専門化されたプランナーに移行する前に、本格的な初版を構築するには十分です。
適切なモデルは依然としてジョブに依存します。広範な推論重視のワークフローには、まず計画品質を選択してください。高ボリュームの自動化では、レイテンシーとコストがベンチマーク強度と同じくらい重要になる可能性があります。
エージェンティックワークフローにおける一般的な障害モード
ほとんどの障害は劇的ではありません。それらは反復的で高コストです。
過剰なツール使用
すべての機能が独自のリモート依存関係になると、ワークフローは有用な作業を行うよりも調整に多くの時間を費やします。
弱い停止ルール
システムが「完了」がいつ真であるかを知らなければ、さらに1ステップを生成し続けます。
不十分なエラー処理
ツールが「失敗」のような曖昧なメッセージを返し、アクション可能な出力を返さない場合、モデルは回復できません。
サンドボックス境界なし
ワークフローは開発では機能しても、実際のファイル、認証情報、外部システムに触れるとすぐに安全でなくなる可能性があります。
評価者なし
エージェントは忙しそうに見えますが、タスクが正しく完了したことを証明しません。
エージェンティックワークフローを使用すべきでない場合
用語が人気だからという理由だけで作成しないでください。
おそらく エージェンティックワークフローは必要ありません もし：
- タスクがワンショット生成である場合
- パスが固定されており、ほとんど変更されない場合
- 従来のプログラムがすべてのステップを安価に決定できる場合
- ツール使用や実行の必要がない場合
例えば、アプリが常にフォーム入力を受け取り、1つのプロンプトを呼び出し、フォーマットされたメールを返す場合、通常のLLMワークフローの方がシンプルで優れています。
エージェンティックワークフローは、環境がシステムを驚かせる可能性があり、それでもシステムが動作し続ける必要がある場合に効果を発揮します。
FAQ
エージェンティックワークフローは関数呼び出しと同じですか？
いいえ。関数呼び出しはワークフロー内のメカニズムの1つです。完全なワークフローには、制御フロー、状態、実行、評価も必要です。
エージェンティックワークフローを構築するには複数のエージェントが必要ですか？
いいえ。ほとんどのチームは1つのコントローラーループといくつかのツールから始めるべきです。マルチエージェント設計は後で役立ちますが、デフォルトの出発点ではありません。
最も重要な安全制御は何ですか？
コードを実行したり外部システムに触れたりするワークフローでは、最も重要な制御は、分離された実行環境と狭いツール権限の組み合わせです。
最もシンプルな本番対応スタックは何ですか？
優れた最初のスタックは次のとおりです：OpenAI互換のLLM API、小さなツールレジストリ、サンドボックス化されたランタイム、タスクが実際に完了したかどうかを判断できる評価者。
