AIエージェント基盤で何を削り、何を残すか：Anthropic SDK 0.100–0.102とCloudflare移行

AIエージェント運用を変えたSDK 0.100〜0.102の中身

8日間で3回のリリースが続き、Python SDKのAPIサーフェスは、それ以前の6か月を上回るほど大きく変わりました。この日付が重要なのは、本番環境をanthropic==0.99.xに固定していた場合、わずか1スプリントの間にManaged Agentsランタイム一式を取り逃しているからです。

**v0.100.0（2026年5月6日）**では、beta名前空間にマルチエージェント、outcomes、Webhook、vault validationのサポートが追加されました。実装上の要点は、client.beta.managed_agents.sessions.create(thread=..., outcome=..., metadata=...)がsession_idを返し、Anthropicのインフラ上で非同期実行されることです。オーケストレーションループを自前で抱える必要がなくなります。

**v0.101.0（2026年5月11日）**では、Claude Platform on AWS向けのAWSクライアントが追加され、すべてのcookbook例がclaude-sonnet-4-5-20250929へ更新されました。Bedrockを使っているなら必要なのはこのリリースです。ANTHROPIC_BEDROCK_SERVICE_TIER環境変数によるdefault/flex/priorityの指定は0.100ではなく、ここで入りました。

**v0.102.0（2026年5月13日）**では、BetaManagedAgentsSearchResultBlock型、prompt cache betaのキャッシュ診断、Pydantic iteratorの即時検証が追加されました。ブロック型のAPIサーフェスは今も変化しており、私がまだマルチエージェントコードを移行しない最大の理由もここにあります。

最大の新機能はoutcomesです。評価基準を定義すると、独立した評価エージェントが結果を採点し、合格するまでエージェントを再実行します。Anthropicの社内evalでは、通常のプロンプトループに比べてタスク成功率が最大+10ポイント、docx生成が+8.4%、pptx生成が+10.1%向上したとされています。私自身のCritic Durable Objectでも、判定役の指摘を添えた再プロンプトを1回入れるだけで、モデルをおおむね1段階上げたほどの品質差が出ており、感触は一致します。

もう一方の柱がWebhookです。Claude Consoleで登録したURLに、session.status_run_started、session.status_idled、session.status_rescheduled、session.status_terminated、session.thread_created、session.thread_idled、session.thread_terminated、そして最も重要なsession.outcome_evaluation_endedという8種類のセッションイベントが送られます。署名シークレットはwhsec_…形式で、作成時に1度だけ表示されます。検証にはclient.webhooks.unwrap(payload, signature, secret)を使います。

マルチエージェント・オーケストレーションも追加されましたが、リサーチプレビューのため別途アクセス申請が必要です。なぜ今は有効にしないのかは後半で説明します。

非技術系の創業者にとって何が変わるのか

Anthropicがエージェントの実行まで引き受けるようになりました。「記事が2,000語に達しているか、一次情報を3件引用しているか、de-AI regexを通過しているか」といった評価基準を書けば、Anthropicの評価エージェントが出力を採点し、合格するまで再実行します。エンジニアが再試行ループを書く仕事はなくなります。

コストへの影響は2つあります。まず、コードベースから手作りの再試行ループが減り、シニアエンジニアがその保守に費やす時間も減ります。一方、Anthropicのセッション内部では再試行が増え、そのたびにトークン料金とは別にsession-hourあたり$0.08がかかります。得になるかどうかは、セッションの実行時間次第です。

率直に言えば、チームがv1のエージェント製品をこれから出す段階なら、Managed Agentsはシニアエンジニアが本来組むオーケストレーションコードの約40%を置き換えます。すでに製品を公開している場合、置き換わる割合は小さくなりますが、Webhook側だけでも、どこかに必ず残っているはずのポーリングループを削除できます。

今週CTOに聞くべきことは、*「完了確認はまだポーリングですか。それともsession.outcome_evaluation_endedへ切り替えましたか」*です。答えが「ポーリング」なら、半日で済むリファクタリングにより、インフラコストとリクエストのレイテンシを同時に下げられます。

現在運用しているCloudflare構成

何を削除できるのかを理解するため、まず現在のアーキテクチャを示します。Cloudflare Workers上の単一Hono worker（ES2021 target、Static Assets binding）が、パブリッシャールーチンごとに1つ、計6つのDurable Objectsのフロントに立っています。内訳はEditorial、Discovery、Writer、Distribution、Maintenance、Managerで、管理UIを支える7つ目のManualIntakeもあります。

各ルーチンは、PublishWorkflow、WriteArticle、PublishArticle、EnrichIdea、DiscoverIdeas、DistributeArticleという6つのCloudflare Workflowsのいずれかを通じて起動します。最も処理量の多いPublishWorkflowは、validate、ground、generate、clean、persist、index、cover、publishという8つの冪等なステップで構成されています。すべてのI/Oステップは次のようにラップしています。

const result = await step.do(
  "generate-article",
  { retries: { limit: 3, backoff: "exponential" } },
  async () => env.WRITER.generate(brief)
);

D1が正規の状態を保持し、editorial_brief.statusはdispatched → drafting → published / failedと遷移します。Vectorizeはブロック単位の埋め込みを担当します（Gemini-2 768d、非対称検索形式）。有料モデルの呼び出しはすべて単一の一元管理ポイントであるcallAi(env, ctx, runner)を通り、agent_id、workflow_instance_id、idea_idとともにai_call_logへ記録されます。これによりコストを集計し、1日$20、インスタンスごとに$1の上限を適用しています。

これは以前紹介した6-DO構成です。Managed Agentsへの移行で重要なのは、再試行ロジックが置かれている場所です。次の2か所にあります。

1. Workflowステップの再試行（基になる呼び出しが成功すれば安価で無料）：一時的なネットワーク障害、レート制限、上流プロバイダーの一時的な5xxを処理します。
2. clean.tsに手書きした「判定・再試行」ループ：Writerを実行し、Criticを実行して、score < 0.75ならCriticの指摘を添えて再プロンプトします。試行は最大3回です。

Managed Agentsが置き換えるのは2番目です。1番目は残します。

SDK 0.100で削除できる280行

src/worker/workflows/publish/clean.tsの判定・再試行ループは、outcomesへ最も素直に対応づけられます。現在は約120行のオーケストレーションがあり、Writerを呼び出し、editorial_brief.rubric_mdに保存した評価基準でCriticを実行し、スコアを解析して閾値で分岐し、指摘をsystem blockとして添えて再プロンプトする処理を最大3回繰り返しています。Critic自体も80行のDurable Objectで、ハイバネーション用フック、評価基準の履歴を持つインスタンス単位のSQLite、試行ごとの冪等性キーを備えます。さらにcallAi.tsには、試行ごとに個別記録しダッシュボードで集計するためのai_call_log処理が40行あります。

この3つの処理は、Managed Agentsの1回の呼び出しに集約できます。

const session = await anthropic.beta.managedAgents.sessions.create({
  thread: { messages: [{ role: "user", content: brief.body_md }] },
  outcome: {
    rubric: brief.rubric_md,
    evaluator: "claude-sonnet-4-5-20250929"
  },
  metadata: { brief_id: brief.id, workflow_instance: ctx.instanceId }
});
return { session_id: session.id, status: "pending" };

必要なのはこれだけです。セッションはAnthropic側で非同期に完了まで実行されます。outcomeパラメータが、これまでCritic DOで担っていた仕事を引き受けます。独立した評価エージェントが評価基準に沿って出力を採点し、合格するまで実行エージェントを再実行します。

追加するコードは、whsec_…署名を検証し、event.type === "session.outcome_evaluation_ended"で分岐して結果をD1へ書き戻す/api/admin/webhooks/managed-agentsルートだけです。

app.post("/api/admin/webhooks/managed-agents", async (c) => {
  const raw = await c.req.text();
  const event = await anthropic.webhooks.unwrap(
    raw, c.req.header("anthropic-signature")!, c.env.WEBHOOK_SECRET
  );

  if (event.type !== "session.outcome_evaluation_ended") {
    return c.json({ ok: true });
  }

  await c.env.DB.update(editorial_brief).set({
    status: event.outcome.passed ? "published" : "failed",
    body_md: event.result.body,
    session_cost_usd: event.session.usage.total_cost_usd
  }).where(eq(editorial_brief.id, event.session.metadata.brief_id));

  return c.json({ ok: true });
});

40行で、署名検証済み、brief_idをキーにした冪等な処理です。

**差分の合計：**オーケストレーションを240行削減。wrangler.jsonからDurable Object bindingを1つ削除。migration fileを1つ削除。Webhook処理を40行追加。Cloudflare Secrets Storeにシークレットを1つ追加します。

GET /api/admin/workflows/:id/statusのポーリング用エンドポイントはそのまま機能します。ただし、env.PUBLISH_WORKFLOW.get(id).status()ではなく、Webhookが更新したD1のセッション状態を読むようになります。UIに変更はなく、管理ダッシュボードから見ても違いはありません。

注意点が1つあります。その他すべてのI/Oステップでは、step.doの再試行ラッパーを残します。カバー画像生成、Vercelの再検証、Cloudflareのキャッシュパージはいずれもoutcomeの評価基準の恩恵を受けませんが、Workflowsの再実行に安全なステップキャッシュは有効です。機能している部分まで外す必要はありません。

残すべき1ファイルと、規模拡大で逆転するコスト計算

callAi.tsは残します。1日$20、インスタンスごとに$1という上限があるためです。直接呼び出し、AI Gateway経由、Managed Agents経由のいずれでも、有料モデルの呼び出しはすべてここを通します。

この仕組みが重要になる理由は、Managed Agentsに3種類の課金軸があるからです。標準料金のトークン代に加え、session-hourあたり$0.08、さらにweb検索1000回あたり$10が発生します。私の現在の規模はパブリッシャールーチンが6本で、1回の起動につき各1記事、セッションは約3分です。トークン代とは別にかかるsession-hourコストは記事あたり約$0.004で、無視できる水準です。

分岐点はセッションが長時間化したときに来ます。4時間のAnthropic Skillsセッションなら、ランタイムだけで$0.32かかり、トークン料金はさらに上乗せされます。同じセッションを1日50回実行すると、トークン料金を含める前の純粋なsession-hour課金だけで月$480です。web検索キューを1時間待つ複数ステップのリサーチセッションなら、従来は不要だった$0.08が発生します。下流サービスを待つ時間も課金対象です（Anthropicのドキュメントではミリ秒単位とされていますが、待機中も課金メーターは動き続けます）。

この一元管理ポイントは、Managed Agentsのダッシュボードにはない厳格な上限を適用します。ダッシュボードでセッションコストが分かるのは事後です。一方、callAi.tsは事前見積もりが1日の上限を超える場合、セッション開始前にワークフローの途中でNonRetryableErrorを送出します。

事前見積もりは安全側に寄せています。

async function estimateSessionCost(brief: Brief): Promise<number> {
  const tokenEstimate = brief.body_md.length / 3.5;
  const inputCost = (tokenEstimate / 1_000_000) * 3.0;
  const outputCost = (tokenEstimate * 1.5 / 1_000_000) * 15.0;
  const sessionHourEstimate = (brief.expected_minutes / 60) * 0.08;
  const safetyMargin = 1.4;
  return (inputCost + outputCost + sessionHourEstimate) * safetyMargin;
}

session-hour単位のコスト計算は、個人エンジニアの構成で最も早く判断を誤りやすい部分です。上限がなければ、評価基準が厳しすぎるとoutcomeの再試行ループが助長しかねない暴走エージェントが、気づく前に1日分の予算を使い切ります。実際に私はそれを見ています。

一元管理ポイントは残してください。sessions.create()をここへ通し、セッション開始前に事前見積もりを記録します。セッション終了時には、Webhookペイロードのevent.session.usage.total_cost_usdと突き合わせます。

まだ移行しない領域：マルチエージェント・オーケストレーション

Anthropic Dev Dayの目玉は、マルチエージェント・オーケストレーションです。リードエージェントがタスクを分割し、モデル、プロンプト、ツールを個別に持つ専門サブエージェントへサブタスクを渡します。サブエージェントは共有ファイルシステム上で並列に作業し、リードが結果を集約します。仕組みだけを見れば、現在のManager DOとまったく同じです。Writer、Discovery、DistributionへDO RPCで並列に振り分け、それぞれが独自のSQLite状態を持ち、R2とD1を共有「ファイルシステム」として利用しています。

それでも見送る理由は3つあります。

**1つ目はAPI変更の激しさです。**マルチエージェント・オーケストレーションはリサーチプレビューで、別途アクセス申請が必要です。BetaManagedAgentsSearchResultBlockが入ったのも0.102になってからです。マルチエージェント結果のブロック型は今も変化しています。この時点で移行すると、次の2〜3リリースのたびに連携コードを書き直すことになります。WebhookのAPIサーフェスは0.100で安定しましたが、マルチエージェント側はまだ動いています。

**2つ目は、共有ファイルシステムがセッション単位かつ一時的であることです。**Managed Agentsセッション内の共有ファイルシステムは、セッション終了時に消えます。R2とD1はすべてのルーチンをまたいで永続化され、どのworkerからも照会でき、セッションがクラッシュしても残ります。共有ファイルシステムが永続化されるか、セッションのサンドボックスへR2を直接マウントできるようになるまでは、私のワークロードにとって機能低下です。

**3つ目は、Anthropicのリード／サブエージェント分割が特定の設計を前提としていることです。**リードエージェントの役割は固定されています。私のEditorial DOは、パブリッシャールーチンが起動した日にはリードですが、管理UIがbriefを振り分け、Editorialがパイプラインの途中から参加する日にはpeerです。ホステッド抽象化に合わせるために、この有用な非対称性を平坦化することになります。

判断が変わるのは、共有ファイルシステムが永続化され、セッションをまたいで使えるようになったとき、またはR2をサンドボックスへマウントできるようになったときです。現時点ではアップグレードではなく、横方向の移行にすぎません。

SDK 0.100〜0.102へ移行するための完全チェックリスト

Discoveryの移行に午後1回、Writerにもう1回使えば、その後は同じ手順で展開できます。0.102.0に固定し、Webhookを登録し、Critic DOを削除してください。ただし、一元管理ポイントは残します。