◈ Agents & Manager/2026-06-15上級

Managed Agent をコスト上限つきの使い捨てワーカーとして扱う設計 — 外部入力を本番から隔離する

Gemini API で公開プレビューになった Managed Antigravity Agent を、永続させず1回で捨てる『使い捨てワーカー』として使う設計です。コスト上限・隔離・冪等性を実装の手順とともに整理しました。

antigravity³⁵⁵ managed-agent² gemini-api⁶ agent-design⁴ cost-control

✦ プレミアム記事

Gemini API で antigravity-preview-05-2026 という Managed Agent が公開プレビューになりました。サンドボックス内で計画・推論・コード実行・ファイル操作・ウェブ閲覧まで自律でこなせます。最初に試したとき、個人開発でこの種のツールを長く使ってきた私はこれを「常駐させて何でも任せる相棒」として使おうとして、すぐに方針を変えました。常駐させると、コストも権限も状態も、すべてが少しずつ積み上がって管理不能になっていくと気づいたからです。

そこで切り替えたのが、1 回のリクエストで生まれて、結果を返したら捨てるという使い方です。永続的なアシスタントではなく、使い捨てのワーカーとして扱う。この発想にしてから、Managed Agent はむしろ扱いやすくなりました。なぜ使い捨てが向いているのか、どう実装するのかを整理します。

なぜ「使い捨て」が外部入力に向くのか

Managed Agent の魅力は、自分の環境から隔離されたサンドボックスで動く点です。ということは、信頼できない外部入力を処理させるのに最適だということです。

たとえば、ユーザーから送られてきた URL の内容を要約する、外部 API から取った素性の知れない JSON を整形する——こうした処理を自分の本番環境で直接動かすのは怖いものです。サンドボックスで動く使い捨てワーカーに任せれば、何が起きてもその場限りで、本番に痕跡が残りません。

逆に、使い捨てにせず常駐させると、前のリクエストの状態が次に漏れる懸念が出てきます。外部入力を扱うほど、状態を持たないことが安全装置になります。私はこの「状態を持たせない」ことを、機能の制約ではなく設計上の利点として捉えるようにしています。

1 リクエストに上限を閉じ込める

使い捨てワーカーの肝は、1 回の起動にコストと時間の上限を必ず付けることです。常駐エージェントだと上限を後から足すのが難しいのですが、使い捨てなら起動のたびに明示できます。

from google import genai
 
client = genai.Client()
 
def run_ephemeral(task_prompt: str, untrusted_input: str) -> dict:
    # 1 リクエスト = 1 ワーカー。終わったら参照を捨てる
    resp = client.agents.run(
        model="antigravity-preview-05-2026",
        instructions=task_prompt,
        input=untrusted_input,
        config={
            "max_cost_usd": 0.20,   # このワーカーが使ってよい上限
            "timeout_s": 120,        # 暴走を時間で止める
            "tools": ["web_fetch"],  # 必要な道具だけ渡す（最小権限）
            "sandbox": "isolated",   # 本番ファイルへのアクセスを断つ
        },
    )
    return {"ok": resp.status == "completed", "output": resp.output}

ここで効くのは max_cost_usd と timeout_s の二段構えです。コスト上限はトークンの暴走を、タイムアウトは無限ループや待ち続ける状態を止めます。私の運用では、この二つを付けていなかった頃は月に数回、想定の数倍のコストが出るリクエストがありましたが、上限を入れてからはゼロになりました。

tools を必要なものだけに絞るのも重要です。Web 取得しかしないワーカーにファイル書き込みを渡す理由はありません。渡さなければ、たとえ指示が乗っ取られても被害が広がりません。

✦

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること

✦Managed Agent を永続させず1回で破棄する使い捨てワーカーの実装パターン

✦コスト上限・タイムアウト・最小権限を1リクエストに閉じ込める書き方

✦外部入力をサンドボックスに隔離し、本番を汚さないための冪等な取り込み手順

Stripe による安全な決済 · いつでもキャンセル可能

✦

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または

メンバーシップなら全記事が読み放題 →

結果の取り込みは本番と切り離す

使い捨てワーカーが返した結果を、そのまま本番のデータベースに書き込んではいけません。ワーカーは隔離されていても、その出力は信頼できない外部入力の加工物だからです。

私が挟んでいるのは、次の三段階です。

ワーカーの出力をいったん検疫用の領域に置く
スキーマ検証で形式を機械的にチェックする（想定外のキーや型は弾く）
検証を通ったものだけを本番に取り込む

def adopt_result(raw: dict) -> bool:
    # 期待するスキーマに合致しないものは本番に入れない
    required = {"title", "summary", "source_url"}
    if not required.issubset(raw.keys()):
        return False
    if len(raw["summary"]) > 2000:  # 異常に長い出力は弾く
        return False
    commit_to_production(raw)
    return True

この検疫を挟むだけで、ワーカーが妙な出力を返したときの被害が「本番が汚れる」から「1 件が弾かれる」に下がります。隔離は入力側だけでなく、出力側にも必要だというのが、運用してみての実感です。

同じ入力には同じ結果を返させる

使い捨てワーカーは失敗したら気軽に再実行できますが、再実行で副作用が二重に起きると意味がありません。そこで、取り込みを冪等にしておきます。

具体的には、外部入力からハッシュキーを作り、そのキーで取り込み済みかどうかを判定します。

import hashlib
 
def idempotency_key(untrusted_input: str) -> str:
    return hashlib.sha256(untrusted_input.encode()).hexdigest()[:16]
 
def adopt_once(key: str, raw: dict) -> bool:
    if already_adopted(key):   # 同じ入力は二度取り込まない
        return True
    return adopt_result(raw)

こうしておくと、ワーカーがタイムアウトして再起動しても、同じ URL を二度要約して二重に保存する、といった事故が起きません。使い捨てだからこそ再実行が前提になり、再実行が前提だからこそ冪等性が効いてきます。

落とし穴と回避策

運用していて踏んだ注意点を挙げます。

一つ目は、コスト上限を低くしすぎると途中で打ち切られることです。max_cost_usd を 0.05 のように絞りすぎると、複雑なタスクが完了前に止まり、不完全な出力が返ります。私は処理の重さに応じて 0.10〜0.30 の範囲を推奨しており、打ち切りが頻発するタスクだけ上限を上げるようにしています。

二つ目は、プレビュー版のレート制限です。公開プレビューの段階では、短時間に大量起動するとスロットルされます。使い捨てを並列で大量に走らせる設計にする場合は、起動側にキューを置いて流量を絞る必要があります。これを怠ると、本番のバッチが半分ほど失敗する事態になりました。

三つ目は、サンドボックスの起動コストです。1 リクエストごとにサンドボックスを立てるので、ごく軽い処理を使い捨てワーカーに投げると、処理本体よりも起動のオーバーヘッドが大きくなります。1 秒で終わるような整形は、わざわざ Managed Agent に出さず手元で処理するほうが速くて安いと判断しています。