Anthropicの4月二大リリース — Opus 4.7とManaged Agentsがエージェント開発を変える方法

4月の第2週、Anthropic公式ブログを2度更新確認した。4月8日にManaged Agentsパブリックベータ、4月16日にClaude Opus 4.7。同じ月に「インフラレイヤー」と「モデルレイヤー」を同時にアップグレードしたのだ。

正直、最初の反応は興奮だった。SWE-bench Pro 64.3%という数字は前バージョン比で約10.9ポイント向上で、Managed Agentsは毎月自分で管理していたエージェントセッションインフラをAnthropicが代わりに担当してくれるという話だった。しかしコミュニティの反応を読み始めると、状況が複雑になってきた。

Opus 4.7が実際に変えたこと

4月16日の出荷時点で公開された変更点は4つだ。

ベンチマーク数値：SWE-bench Proで64.3%、前バージョン比+10.9ポイント、CursorBenchで70%、+12ポイント。コーディングエージェントの観点では明確な改善だ。

高解像度画像サポート：最大2576px、3.75MPに拡張された。以前の1568px/1.15MPの制限を超えたことで、UIテスト自動化やスクリーンショットベースのエージェントには実質的なアップグレードになる。

task_budgetパラメータ：ベータ機能だが、私が最も注目した変更だ。エージェントループ全体にトークン予算を設定できる。task-budgets-2026-03-13ヘッダーで有効化し、最低値は20kトークン。hard capではなくadvisory方式で動作する — 予算を超えても即座に停止するのではなく、モデルが「予算内で完了するよう努力する」方式だ。

xhighエフォートレベル：既存のlow/medium/highにxhighが追加された。複雑な推論タスクでより深く考えさせる設定だ。

APIコール例でtask_budgetの適用方法を整理すると：

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=4096,
    extra_headers={
        "anthropic-beta": "task-budgets-2026-03-13"
    },
    # task_budgetはエージェントループ全体のトークン予算
    # 最低20000、advisory（hard capではない）
    task_budget=50000,
    messages=[
        {
            "role": "user",
            "content": "このリポジトリのすべてのPythonファイルでdeprecated API呼び出しを見つけて最新バージョンに置き換えてください。"
        }
    ]
)

このコードはAnthropicのAPIキーなしに直接実行できなかった。上記コードは公式ドキュメントとリリースノートを基に作成したもので、task_budgetのadvisory動作方式はManaged Agentsの本番デプロイ記事で直接テストした経験と繋がっている。

Managed Agentsは何が違うのか

4月8日にパブリックベータに移行したClaude Managed Agentsは概念的にシンプルだ。開発者が自分で管理しなければならなかったエージェント実行環境 — サンドボックス、セッション状態、権限検証、長時間実行コンテナ — をAnthropicプラットフォームが代わりに運用してくれる。

公式ドキュメントが示すコア機能：

• 隔離されたサンドボックス：Bashコマンド、ファイル操作、ウェブ検索、MCPサーバー実行が隔離環境で動作
• セッション状態の維持：数分から数時間のタスクでもファイルシステムと会話コンテキストが保存される
• 認証情報セキュリティ：APIキーとシークレットをエージェントに直接露出せず権限委任方式で処理
• マルチエージェント調整：リサーチプレビュー状態だが複数エージェントが協力するワークフロー構成が可能

価格体系はセッション時間あたり$0.08 + 標準Claude APIトークン費用だ。アイドル時間は除外されないことを公式ドキュメントで明記している。

Notion、Rakuten、Sentryがすでに本番に適用したという事例が公開されており、Notionは90%のコスト削減と85%のレイテンシ改善、Rakutenは70以上のビジネスユニットでエラー率97%削減を報告した。

良い点：エージェントインフラ管理負担の実質的な軽減

私はこのブログの自動化システムを自分で運営しながら、エージェントセッション管理がいかに面倒かを体感している。セッションが予期せず切断し、コンテキストが失われ、長時間タスクがサイレントに失敗する状況を防御するコードがビジネスロジックより多くなる時点が来る。

Managed Agentsがこの負担を軽減してくれるなら — 実際にSentryが「数週間でパッチエージェントを本番リリースした」と言った背景がこれなら — 価値は明確だ。

Claude Codeエージェントワークフローパターン5種で扱ったオーケストレーター-サブエージェント構造をManaged Agents上に載せると、以前は自分で実装しなければならなかったリカバリーロジックと状態同期をプラットフォームが処理してくれることになる。

task_budgetも方向性は正しい。エージェントが予算内で優先順位を自分で決めるよう誘導する方式は、ハードカットより実際のタスク完成度を高める可能性がある。

残念な点：ベンチマークと実務の乖離、そして隠れたコスト

しかしOpus 4.7リリースの24時間後にコミュニティの反応が入ってきて、不穏なパターンを発見した。

byteiota.comで収集された開発者フィードバックのまとめを見ると、一部のパワーユーザーがOpus 4.7を「legendarily bad（伝説的にひどい）」と表現した。具体的な不満は3つに収束する。

安全性のオーバーフィット：悪意あるコードを検知する基準が高くなりすぎて、通常のネットワーク呼び出しや標準ライブラリ使用も拒否されるケースが報告された。

命令解釈の硬直性：前バージョンより指示をリテラルに解釈する傾向が強くなった。柔軟な推論より明示的な指示遵守を優先しているように感じるという反応だ。

出力スタイルの変化：散文形式よりも箇条書き整理の好みが強くなった。これを改善と見る人もいるが、創造的作業では欠点として捉える人もいる。

そして私が最も重要だと思う問題は別にある。新トークナイザーだ。Opus 4.7は新トークナイザーを搭載し、同じテキストに対して以前比で1〜1.35倍多くのトークンを使用する。公表された価格は変わっていないが、実質コストが最大35%上昇する可能性があることを意味する。

AIエージェントのコスト現実で本番エージェントの運用コストを分析したことがあるが、トークナイザーの変更は予算シミュレーションを完全にやり直すレベルの変数だ。

コスト現実：どれだけ上がったか

公開された数値を基にシナリオ別比較をすると：

シナリオ	Opus 4.6基準	Opus 4.7予想（トークン+25%）
簡単なQ&A（1Kトークン）	$0.005	〜$0.006
コードレビュー（10Kトークン）	$0.05	〜$0.063
長時間エージェント（100Kトークン）	$0.50	〜$0.625

ここにManaged Agentsのセッションコスト（$0.08/時間）が加わる。1時間のエージェントタスクなら、トークンコストに$0.08を追加する計算だ。

task_budgetをなぜ今学ぶべきか

task_budgetパラメータは今回のリリースで最も静かに埋もれた機能だ。メディアはベンチマーク数値とManaged Agentsの華やかな事例を取り上げたが、エージェントを長期運用する開発者にとって最も実質的な変化はこのパラメータかもしれない。

問題はこうだ。複雑なリファクタリングエージェントを実行すると、どれくらいかかるか、トークンをどれだけ使うか予測が難しい。max_tokensは1つの応答の長さを制限するが、マルチターンエージェントループ全体を制御するわけではない。task_budgetはこのギャップを埋めようとする試みだ。

advisory方式という点が興味深い。モデルが予算上限に近づいても強制的に停止するのではなく、「この予算内で終わらせる方法を自分で見つけるよう」動作する。

Managed Agentsが変える開発プロセス

Managed Agentsを最初に聞いたとき「既存のClaude APIにサンドボックスが付く程度だろう」と思った。ドキュメントを詳しく読んで考えが変わった。

最大の変化は状態管理だ。エージェントセッションを自分で運営すると次の問題が繰り返される：コンテキスト消失、セッション再起動コスト、認証情報セキュリティ。Managed Agentsはこの3つをプラットフォームレイヤーで処理する。

Sentryが「数週間でパッチエージェントを本番リリースした」という事例が誇張でないかもしれない。このインフラレイヤーを自分で構築するのに数ヶ月かかるチームもあるのだから。

誰にOpus 4.7が合い、誰に合わないか

コミュニティのフィードバックと公式ドキュメントを総合すると、使用適合性がかなり明確に分かれる。

Opus 4.7が真価を発揮する状況：複雑なマルチファイルリファクタリングや、コードベース全体を分析するエージェント作業で性能改善が顕著と報告されている。大型レガシーコードベースの移行、テストカバレッジの自動拡張、セキュリティ脆弱性分析では有効だ。

Opus 4.7を避けるべき状況：日常的なコーディング補助作業には過剰だ。「この関数をリファクタリングして」レベルの作業はClaude Sonnet 4.6の方が速くコストも低い。

今月のAnthropicリリースの大きな絵

4月のAnthropicリリースを一つの物語として読むと興味深い。先月の性能低下論争でコミュニティの信頼が揺らいでいたとき、Anthropicはベンチマーク改善数値とともに一ヶ月で帰ってきた。

しかし開発者たちの反応は「数字より実務が大事」という方向に成熟しつつある。SWE-benchが高くても自分のコードベースでうまく動くという保証はなく、「legendarily bad」というフィードバックは無視しにくい。

私の結論：Opus 4.7はコーディングベンチマーク上明確な改善だが、実務への全面移行は慎重に。task_budgetとxhighエフォートレベルはエージェントコスト制御に実質的な助けになりうる。Managed Agentsは新プロジェクト開始時点で真剣な代替案だ。そして新トークナイザーのコスト影響は必ず自分で計算する必要がある。

---

実行可能性の判断（Source Reviewベース）

この記事で紹介したtask_budgetコード例とManaged Agents機能説明は、公式ドキュメント（platform.claude.com/docs）とリリースノートを基に作成した。Anthropic APIキーなしに直接実行環境を構成できなかったため、実際のtask_budgetのadvisory動作やセッションコスト請求方式は直接検証していない。「ドキュメント上の設計と公開事例基準」で判断した内容であることを明示する。