Agent ループと実行器

ツール利用では提案を検証可能な実行記録へ変えます。在庫照会の最小ループから、結果の対応付け・停止状態・依存・書き込み結果不明の扱いへ進みます。提案、実行済み、タスク検証済みを区別できることが目標です。

固定されたプロセスからフィードバックに基づく意思決定へ

固定されたワークフローは、プログラムによって主要なステップが事前に計画される。例えば、注文の読み取り、フィールドの抽出、検証、データベースへの保存などである。モデルは特定のステップに関与できるが、主要なパスはコードによって制御される。一方、エージェントはモデルが観察に基づいて次のステップを動的に決定する。例えば、テストが失敗した場合、モデルは関連するファイルを自ら特定し、新しい修正行動を選択する。これら2つは組み合わせることができる。決定論的な外側のフローに、制限されたエージェントのサブタスクを含めることもできる。Building effective agents

ReActの研究は、推論と行動を交互に組織し、モデルが環境からのフィードバックに基づいて後続の処理を更新することを可能にする。ReAct これは「チャットインターフェースがあるかどうか」で製品を分類するものではない。チャットシステムもツールを呼び出すことができ、エージェントが1回の応答で簡単なリクエストを完了することもある。

モデルの推論は表現と出力を生成し、外部の行動は実行環境によって実現される。クライアント側のツールはアプリケーションによって実行され、サーバー側のツールはベンダーによって実行される可能性がある。したがって、権限と監査の境界は実際の実行コンポーネントに分散されており、すべての操作がローカルホスト上で行われると仮定することはできず、モデルが生成したコマンドテキストがすでに実行されたものとして扱うこともできない。

完了の主張と根拠

完了は検証すべき主張です。未実行・未観測でも宣言できますが、受入層は独立して根拠を検査します。変更前の読み取りでは変更後の状態を証明できません。

1回のツール呼び出しの完全なパス

ツールの定義はモデルのインターフェースであり、実行契約でもある

名前はモデルが行動を識別するのに役立ち、説明は用途と制限を説明し、スキーマはパラメータの構造を定義する。読み取り専用の在庫照会を例にとると、説明では、照会するのは販売可能数量であり、商品にどの識別子が使用されているか、結果の時間的またはバージョン的な意味合いを説明する必要がある。「在庫を取得する」という4文字だけでは、これらの境界を表現できない。

{
  "name": "lookup_stock",
  "description": "商品SKUに基づいて現在販売可能な数量を照会する；読み取り専用で、在庫を予約しない。",
  "input_schema": {
    "type": "object",
    "properties": {"sku": {"type": "string"}},
    "required": ["sku"],
    "additionalProperties": false
  }
}

これはClaudeスタイルのツール定義である。他のプロトコルではフィールド名が異なる可能性がある。スキーマは形状を制約するだけで、身元、商品が現在のテナントに属しているかどうか、または操作者が閲覧できるかどうかを自動的に検証するものではない。構造化された出力も実行側の検証に代わるものではない。実行側は、登録されたツールのみをディスパッチし、入力と権限を再検証しなければならない。Tool use with Claude

1回の照会は、以下の記録で追跡できる。

実行結果には、明確なステータス、必要なデータ、およびソースの位置指定を含めるのがよい。エラーも、商品なし、無効なパラメータ、権限不足、レート制限、または結果不明を区別するべきである。「失敗、再試行」という漠然とした返答は、意味のないループを誘発する。

メッセージプロトコルは完全でなければならない

Claudeのクライアントツールは、tool_use と一致する tool_result によって関連付けられる。1つの応答に複数の呼び出しを含めることができる。アプリケーションは、完全なアシスタント応答を保持し、プロトコルに従ってすべての対応する結果を整理する必要がある。思考、不透明な状態、および非テキストコンテンツは、「textのみを保存する」という単純化されたロジックによって失ってはならない。

エラー形式のフィードバックは後のモデルの行動に影響を与える可能性があるが、リクエストの中で「モデルの重みを密かに訓練している」わけではない。プロトコルの要件と推測的な行動解釈は分離され、具体的なツールメッセージの配置ルールは ツールインターフェースドキュメント に従う。

応答の停止とタスクの状態

モデルがツールを要求しなくなったことは、今回のモデル応答が停止したことを示すのみである。タスクが正しく完了した可能性もあれば、検証を漏らした、ユーザーからの情報補充が必要、切り捨てられた、または誤って成功を宣言した可能性もある。アプリケーションは、running、waiting、succeeded、failed、budget_exhausted などのタスク状態を独立して記録し、タスクの受入条件に基づいていつ succeeded とするかを決定する必要がある。

以下の表は、Claudeインターフェースにおける一般的な分岐であり、完全な列挙と後続のリクエスト形式は Stop reasons and fallback を参照のこと。

ストリーミングは max_tokens を解除しない。ツールパラメータのJSONが半分しか受信できない状態でストリームが切断された場合、残りのフィールドを推測して実行してはならない。サーバー側のツールがまだ実行中の場合、pauseをクライアントが同じ副作用を再度実行するシグナルとして扱うこともできない。

「インポートされた重複コミットの修正」を例にとると、受入条件は、パッチが存在し、通常のテストが通過し、再起動後のリカバリテストが通過することかもしれない。モデルが「修正済み」と出力しても、通常のテストしか実行していない場合、タスクは未完了である。受入基準は最初に明確にし、実際のアーティファクトのバージョンに関連付けるべきである。

依存関係、再生、および副作用

並列実行の資格は依存関係による

2つの独立したドキュメントを同時に読み取ることは通常、並列実行可能である。「在庫を照会し、その結果に基づいて予約する」にはデータ依存関係があり、パラメータを推測して並列に送信することはできない。2つの行動の入力が独立していても、同じファイルまたは同じリソースを同時に変更する場合、競合が発生する可能性がある。

実行器は、データ依存関係、共有リソース、サービスの同時実行数の上限、および権限を同時に考慮する必要がある。並列実行が節約するのは、重複する待機時間のみであり、その代償にはピーク負荷と結果のマージが含まれる。モデルが1つのラウンドで複数の呼び出しを提案したからといって、無条件にすべてを並列実行してはならない。

呼び出しIDはビジネスの冪等キーではない

呼び出しIDは、応答を提案に関連付けるために使用される。モデルが再試行する場合、新しい呼び出しIDを生成する可能性があるが、同じビジネス行動を表現している。この場合、呼び出しIDのみで重複排除を行っても、注文の重複作成や通知の送信を防ぐことはできない。ビジネス操作キーは、アプリケーションによって明確なトランザクションセマンティクスに基づいて生成、保存され、冪等性をサポートするサービスによって、同じキーと同一のリクエストが一致するかどうかを検証する必要がある。

キャンセルもロールバックではない。モデルの生成を停止するか、ローカルの待機をキャンセルしても、リモートで開始された行動が取り消されることは保証されない。実行器は、「未実行の確認」、「完了」、「結果不明」を区別し、復元時には不明な状態を最初に解消する必要がある。

タイムアウト後、書き込みは何回か

ネットワーク結果と業務結果を分けます。応答なしは未書込を意味しません。サーバーの事実が見えても呼出側では不明であり、照会や同じキーの再試行で確認します。重複排除はサーバーの保証が必要です。

実行可能なローカル実行器の例

以下では、あらかじめ用意したモデル応答を使用して、1回の読み取り専用在庫照会をシミュレートする。これは、ツールのホワイトリスト、パラメータ、呼び出し結果の関連付け、およびリクエストの上限を検証する。モデルAPIを呼び出したり、実際のビジネス書き込みを実行したりすることはない。本番システムには、永続的な状態、身元と権限、タイムアウト、完全なプロトコル適応、および監査が必要である。

STOCK = {"A1": 3}

def execute(call):
    if call.get("name") != "lookup_stock":
        return {"ok": False, "error": "unknown_tool"}
    args = call.get("input")
    if not isinstance(args, dict) or set(args) != {"sku"}:
        return {"ok": False, "error": "invalid_arguments"}
    if not isinstance(args["sku"], str):
        return {"ok": False, "error": "invalid_sku"}
    if args["sku"] not in STOCK:
        return {"ok": False, "error": "not_found"}
    return {"ok": True, "available": STOCK[args["sku"]]}

def run(model, max_requests=3):
    observations, seen = [], set()
    for _ in range(max_requests):
        response = model(list(observations))
        if response["kind"] == "final":
            # モデルの終了はビジネス受入の成功を意味しない。
            return {"state": "model_ended", "text": response["text"],
                    "observations": observations}
        if response["kind"] != "tool":
            return {"state": "invalid_response"}
        call = response["call"]
        call_id = call.get("id")
        if not isinstance(call_id, str) or not call_id or call_id in seen:
            return {"state": "invalid_call_id"}
        seen.add(call_id)
        observations.append({"call_id": call_id, "result": execute(call)})
    return {"state": "budget_exhausted", "observations": observations}

def scripted(observations):
    if not observations:
        return {"kind": "tool", "call": {
            "id": "c17", "name": "lookup_stock", "input": {"sku": "A1"}}}
    assert observations[0] == {
        "call_id": "c17", "result": {"ok": True, "available": 3}}
    return {"kind": "final", "text": "現在、販売可能数量が3件照会されました。予約はされていません。"}

result = run(scripted)
assert result["state"] == "model_ended"
assert execute({"name": "delete_stock"})["error"] == "unknown_tool"
assert execute({"name": "lookup_stock", "input": {"sku": 1}})["error"] == "invalid_sku"
assert run(scripted, max_requests=1)["state"] == "budget_exhausted"
print(result["text"])

この例では、1回のツール呼び出し後、最終応答を取得する前にリクエスト予算が枯渇すると、明確に budget_exhausted を返す。これは、ループの終了をすべて「成功」とマッピングするよりも正確である。実際のアプリケーションでも、完了した呼び出しを永続的に保存し、プロセスの再起動後に副作用の記録が失われるのを防ぐべきである。

ツールの境界とループの収束

「最大10ラウンドで実行する」という最後の保険だけでは不十分である。各ラウンドで新しい証拠が得られたか、アーティファクトが変更されたか、エラーが解消されたかを観察するべきである。同じ失敗が連続して発生し、条件が変化しない場合、繰り返しの行動は通常、進展をもたらさない。無限に再送信するのではなく、より具体的なエラーを返す、検索範囲を変更する、または不足している条件を報告するべきである。

ツールの出力はサイズを制限し、読み続けられる位置を保持する必要がある。ログを切り捨てる場合は、切り捨てられた範囲、合計量、およびファイルの位置指定を明確に表示し、モデルが完全な証拠を取得したと誤解させないようにする。コンテキスト管理については コンテキストエンジニアリング を参照。

専用ツールは、パラメータとビジネスセマンティクスを実行器に公開し、検証、認可、記録を容易にする。Shellツールはより一般的な機能を提供するが、コマンドの許可リストだけでは、プログラムが行えるすべての操作を制限するには不十分である。実際の権限は、実行身份、ファイルおよびネットワークアクセスの範囲、隔離環境、およびリソース制限によって制御する必要がある。具体的な戦略は、すでに認可されたタスクに一致させるべきであり、各ステップの取り消し可能な操作を繰り返しの確認に退化させないこと。詳細は セキュリティと保護 を参照。

補足：環境シミュレータと実際の実行

エージェントのトレーニングと評価には、環境シミュレータを使用できる。ポリシーが行動を提案し、シミュレータが観察を生成し、ポリシーを継続する。言語世界モデルは、このような環境応答の学習を試みる。例えば、Qwen-AgentWorld モデルカード は、多様な対話環境を対象としたシミュレーション能力について記述している。これは、ファイルを直接変更したり、ビジネスサービスを呼び出したりする実際の実行パスとは異なる。

シミュレータは、一見合理的だが状態が矛盾した結果を生成する可能性がある。評価時には、単一の観察が本物のように見えるかどうかだけでなく、連続した行動の因果的一貫性、リソース制約、および長期状態が維持されているかも確認する必要がある。シミュレーション環境での高スコアが、実際のツール実行の成功率を直接証明するものではない。シミュレータまたはエージェントとして適しているかどうかは、それぞれ測定し、アクティベートされたパラメータの量だけで、ある種のロールが本質的に実行可能か不可能かを主張してはならない。

今後の MCP と Skills では、機能がどのように接続され、オンデマンドで提供されるかについて議論し、記憶と状態 では、長時間のタスクと障害復旧時に何を保存する必要があるかについて議論する。

次に読む：ツールインターフェースと MCP。