Claude Managed Agents 複雑さがハーネス側に吸われると、何が起きるか。デザイナーへの挑戦状か

先日、Anthropic が AIエージェント構築に関する37分の無料ガイドを公開した。Claude を作っているエンジニア自身が、エージェント設計の全体像を解説している内容だ。

技術的な解説はすでにたくさん出ている。だから私が書きたいのは、その先のこと。この変化は、デザイナーの仕事にとって何を意味するのか。

結論から言うと、私はこれを脅威ではなく、招待状として読んだ。

エージェント開発は、3段階で「楽」になってきた

Claude でのエージェント開発は、ざっくり3段階で進化している。

Messages API → Agent SDK → Claude Managed Agents

Messages API は、Claude の「頭脳」だけを API 越しに借りる段階。ツールをどう実行するか、会話履歴をどう管理するか、エラーが起きたらどう復旧するか、長時間タスクをどう維持するか…その周辺はぜんぶ開発者が自前で書く。

Agent SDK は、Claude がツールを使って複数ステップの作業を進められるようにする開発基盤。ファイルを読み、書き換え、コマンドを実行し、結果を見て次を決める。よりエージェントらしい動きができる。ただし実行環境やセッション管理、長時間実行の安定性は、まだ開発者がかなり意識する必要がある。

そして Claude Managed Agents。2026年4月8日に公開ベータでローンチされた。エージェントループ、ツール実行環境、サンドボックス、状態管理、スケーリング、可観測性…これまで開発者が自前で抱えていた「ハーネス」の部分を、Anthropic 側が引き受ける。

ガイドの中では、エージェントの構造がきれいに3つに分解されている。

セッションは状態を持つ（stateful）から、PC を閉じても、しばらく中断しても、作業の途中状態が維持される。プロトタイプで作ったものを、本番運用に近い形までそのまま持っていける。

ここまでが、よくある解説だ。「インフラが楽になりました」で終わる話。

でも、デザイナーが読むべきはその先にある

複雑さがハーネス側に吸われると、何が起きるか。

差別化の余地が、ひとつ上のレイヤーに押し上げられる。

インフラが難しかった時代は、インフラを作れる人が価値を持っていた。それが解決されると、ボトルネックは別のところに移る。

• エージェントに、そもそも何をさせるのか

• 人間が、エージェントの動きをどう理解するのか

• いま途中で何が起きているのかを、どう見せるのか

• 間違えたとき、どうやって気づき、止め、やり直すのか

• どこまでの権限を、誰に、どう渡すのか

これは全部、インフラの問題ではない。設計の問題だ。

つまり、エージェント開発の主戦場は「モデルを呼ぶこと」から「モデルに何をさせ、人間とどうつなぐか」へ移っている。後者は、私たちデザイナーの土俵そのものだ。

3つの分解は、そのままUXの設計対象になる

面白いのは、Endpoint / Environment / Session という分解が、私が普段向き合っているUXの設計対象とほぼ一対一で対応することだ。

Environment（手足）は、コネクタと権限のUX。 エージェントがどのツールに触れ、どの認証情報を使えるのか。それを安全に、わかりやすく、ユーザーや管理者に渡す画面。AIプロダクトでコネクタ管理やOAuthフロー、エラーステートを設計したことがある人なら、ここがまるごと自分の領域だとわかるはず。

Session（接続＋状態）は、再開可能性と可観測性のUX。 「PCを閉じても状態が維持される」のはバックエンドの能力だけど、ユーザーがそれを信じられるかは別の話で、そここそ設計対象になる。長く動いているタスクが「まだ生きている」「離れても戻ってこられる」「いま何をしているか見える」を、どう伝えるか。Managed Agents 側では、すべてのツール呼び出しや意思決定、失敗モードがコンソールから追える。この「追える」をユーザー向けにどう翻訳するかが、UXの仕事だ。

Endpoint（頭脳）は、バージョンと信頼の問題。 エージェントの設定はバージョン管理され、セッションはあるバージョンに固定される。どのバージョンのエージェントが、いつ、何をしたか…監査やトレーサビリティのUIは、B2Bプロダクトでは特に重い。

そして Managed Agents は、複数エージェントの協調（multi-agent coordination）も出してきた。まだリサーチプレビュー段階だけど、複数のAIを比べ、束ね、協調させるプロダクトを作っている身としては、これはど真ん中の追い風だ。

ここで効いてくるのが、Google PAIR が言い続けてきたこと…メンタルモデル、信頼の伝え方、エラー時の振る舞い、説明可能性。インフラが吸われた結果、これらは薄まるどころか、製品の主戦場になる。

もうひとつ。私たち自身も、同じ進化を辿っている

これは作る側だけの話じゃない。AIを実務で使う私たち自身の自動化も、まったく同じ道を辿っている。

最初は、チャットでAIに聞くだけ。次に、スキルやフックを組んで、AIにツールを使わせ、作業を任せるようになる。私はいま、自分のマシンの上で、フックとスキルで「自前のハーネス」を回している。

Managed Agents は、その一部をクラウドに逃がす選択肢を出してきた。ローカルだと環境が壊れて動かなかった常駐ジョブ…私にも、一度も稼働しないままお役御免にさせたスケジュール自動化がある…は、クラウドのサンドボックスと状態永続のほうが明らかに向いている。

ただ、ここは正直に書いておきたい。急いで全部を乗り換える必要はないと思う。

料金はモデルのトークン課金に加えて、エージェントが動いている時間に対する課金が乗る。まだベータだ。そして何より、いま自分の手で動かせているローカルの仕組みは、それ自体が資産だ。「AIに聞くだけでなく、自分で作れる状態」を手放してまで新しいものに飛びつくのは、違う。

正解は「乗り換え」ではなく「レイヤーごとに最適な道具を選ぶ」こと。ローカルで脆かった1個だけをクラウドで試してみる。それくらいの距離感が、ちょうどいい。

インフラが解けた世界で、希少になるもの

私が最近よりどころにしている考え方に、「プロダクトセンスで役割の境界を越える」というものがある。デザイナーだからここまで、エンジニアだからここまで、と線を引かない。プロダクトを良くするために必要なら、越える。

Claude Managed Agents が指し示しているのは、まさにそういう世界だ。インフラの複雑さが下に吸われるほど、希少になるのは…

エージェントに何をさせるかを決める力と、その動きを人間が信じられるように設計する力。

どちらも、肩書きが「デザイナー」かどうかとは関係ない。でも、プロダクトセンスとUXの訓練を積んできた人間が、いちばん自然に踏み込める領域だと思う。

だから私は、これを脅威ではなく招待状として読んだ。

インフラが消えていくその先で、残るのはデザインのはず。