ソフトウェアは「使うもの」から
「任せるもの」へ
Claude Managed Agents が示す次世代ソフトウェアの条件

1 なぜ Managed Agents は重要なのか

最近のAIプロダクトの多くは、見た目としては「チャットUI」に収束している。自然言語で指示できる。文章を要約できる。コードも書ける。たしかに便利だ。だが、その多くは依然として人が横で付き添い続けることを前提としている。途中で確認し、コピーし、貼り付け、追加の指示を出し、失敗したらやり直す。AIは優秀なアシスタントではあっても、仕事を最後までやり切る実行主体には、まだなり切れていない。

Claude Managed Agents が重要なのは、この前提をさらに一歩先へ進めたからだ。Anthropic が今回提供し始めたのは、単なる「より高性能なモデル」ではない。長時間動き続けるエージェントを本番環境で動かすための runtime そのものである。セッション管理、サンドボックス実行、権限分離、障害復旧、トレーシング、スコープされたアクセス制御——これまで各社が泥臭く自前で組み上げてきた領域が、ようやくプロダクトとして提供され始めた。

本質は「AIが賢くなったこと」ではない。
ソフトウェアが、ユーザーの代わりに仕事を継続実行できるようになったことだ。

2 従来のソフトウェア形態の限界

従来のSaaSや業務システムは、基本的に human-in-the-loop を前提にした request/response 型 だった。ユーザーが画面を開き、入力し、次のページへ進み、判断し、必要に応じて別のツールへ移る。つまりソフトウェアは「機能の集合」であり、ワークフロー全体を最後まで回していたのは人間だった。

ここで重要なのは、多くの企業の仕事が本質的に「単一画面では終わらない」ことだ。現実の仕事では、Slack やメールを確認し、資料を読み、ブラウザを開き、表計算を作り、場合によってはコードにも触れ、途中で判断し、最後に関係者へ共有する。従来のソフトウェアは個別機能を提供することはできても、成果物が出るところまで責任を持つ仕組みにはなっていなかった。

Copilot や AI チャットは、この旧パラダイムを一段だけ拡張した存在だといえる。自然言語で指示できるようになり、部分作業の自動化は進んだ。しかし多くの場合、AIはまだ「賢いUI」の延長線上にあり、「任せられる実行基盤」には至っていない。だからこそ、Managed Agents の登場は構造的に重要なのである。

3 Managed Agents が示す新しい設計思想

Anthropic の engineering 記事でとりわけ重要なのは、Managed Agents を「モデルの新機能」としてではなく、brain・hands・session を分離したシステム設計として語っている点だ。これは、これからの agent runtime を考えるうえで非常に示唆に富む。

端的に言えば、brain は推論と計画、hands はツールや実行環境、session は出来事を記録する永続ログである。この3つを疎結合にしておけば、状態を特定のコンテナや一時的なプロセスに閉じ込めずに済む。障害が起きても再開しやすく、複数の実行環境にまたがる構成にも対応しやすい。将来モデルが進化したときも、harness 側を柔軟に更新できる。

これは単なるインフラ上の工夫ではない。プロダクト設計そのものが変わることを意味している。これまでのアプリは「どんな画面を用意するか」を中心に設計されてきた。これからのアプリは「どんな目標を、どんな条件で、どこまで自律的に進め、どこで人に戻すか」を中心に設計する必要がある。

4 未来のソフトウェアを特徴づける4つの要素

4-1. ソフトウェアは「応答」から「継続実行」へ移る

これまでのソフトウェアは、入力に対して応答を返すものだった。ボタンを押せば結果が出る。フォームを送れば処理される。だが agent runtime を前提にしたソフトウェアは、タスクを受け取ったあと、数十分から数時間、場合によっては数日単位で動き続ける。途中で必要な情報を集め、ツールを呼び出し、失敗したらやり直し、必要なときだけ人間に判断を戻す。

これはユーザー体験を根本から変える。ユーザーはソフトを「操作する」のではなく、仕事を「任せる」ようになる。これからのUXでは、ページ遷移やボタン配置だけでなく、途中経過の見せ方、介入ポイント、信頼の作り方が重要になる。

4-2. ソフトウェアは「機能の束」から「結果の配達システム」へ変わる

旧来のプロダクトは、機能を増やすことで強くなってきた。表計算、通知、ダッシュボード、テンプレート、ワークフロー設定。だが agent 時代には、単に機能が多いだけでは足りない。重要なのは、ユーザーが求める成果物を、安定して最後まで届けられるかという点にある。

たとえば「営業提案書を作る」「リポジトリを読んで不具合修正のPRを出す」「会議準備をまとめる」といった仕事では、必要な機能は毎回少しずつ異なる。だから未来のプロダクト価値は、機能一覧の多さではなく、goal acceptance → planning → tool use → self-correction → delivery という一連の流れを、どれだけ安定して回せるかへ移っていく。

4-3. ソフトウェアは「単一UI」ではなく「many brains / many hands」になる

Managed Agents の engineering 解説で印象的なのが、many brains, many hands という発想である。これは、そのまま未来のソフトウェア構造を言い表している。1つのbrainが計画を立て、複数のbrainがサブタスクを並列に実行し、複数のhandsがそれぞれ別のツールや環境で作業する。コード生成用のサンドボックス、ブラウザ、文書処理系、社内DB、CRM、チケット管理、MCPサーバー——これらはすべて、agent にとっての「手」になる。

すると、ソフトウェアの形は単一画面の集合ではなくなる。むしろ、オーケストレーション層・記憶層・実行層・監査層から成る「運用システム」に近づいていく。これからのソフトウェア会社は、UIベンダーというより、小さな agent operating system を作る会社へと近づいていくはずだ。

4-4. 企業導入では「より賢い」より「より任せられる」が勝つ

一般消費者向けプロダクトでは、デモの派手さや瞬間的な賢さが目立ちやすい。しかし、企業が本当に買うのはそこではない。企業にとって重要なのは、任せても事故につながらないか、追跡できるか、止まっても戻れるか、権限が漏れないかである。

Managed Agents が企業文脈で意味を持つのは、まさにここにある。セッションが持続する。権限がスコープされる。サンドボックスが分離される。トレースが残る。失敗時に回復できる。つまり、企業が「試してみる」のではなく「業務を任せる」ための条件が、ようやく runtime 側で揃い始めたということだ。

5 なぜ企業で先に普及するのか

実際、Anthropic の公開情報を見ると、Managed Agents のユースケースはきわめて企業的である。コードを読んでPRを出す。Asana や Notion の中でタスクを引き受ける。会議準備を自動化する。社内文書から必要な情報を引き出す。営業資料やスプレッドシートを生成する。どれも派手な消費者向けアプリではないが、人件費と時間コストに直結する高付加価値業務ばかりである。

しかも、こうした仕事は1クリックでは完結しない。長い文脈、複数システムへのアクセス、途中での再試行、権限の取り扱い、成果物の品質担保が必要になる。従来の chatbot や point solution では、その全体を最後まで支え切れなかった。Managed Agents 型の runtime は、まさにその隙間を埋める。

だからこそ、この流れはまず次の領域から広がる可能性が高い。

• コード理解・修正・PR作成などのソフトウェア開発
• 法務・財務・契約・社内稟議といった文書ワークフロー
• 営業提案書・会議準備・調査などのナレッジワーク
• Jira / Asana / Notion / Slack に組み込まれるチーム向けエージェント
• 複数システムにまたがる基幹業務のオペレーション

共通点は明確である。どれも「画面で何ができるか」より、「最後に何が納品されるか」が重要な仕事だ。つまり、Outcome-first なソフトウェアと相性のよい領域なのである。

6 これからソフトウェア企業は何を作るべきか

この変化を前提にすると、これからのソフトウェア企業が設計すべきものも変わる。単にチャット欄を付けたり、既存機能に生成AIを埋め込んだりするだけでは足りない。重要なのは、ユーザーから「仕事を預かり」、途中で必要な処理を行い、「完了状態まで運ぶ」仕組みそのものを設計することにある。

そのとき、プロダクトチームに求められる視点は、従来の CRUD 中心の設計とはかなり異なる。たとえば、次のような問いが中心になる。

• ユーザーは何を「依頼」し、何を「結果」とみなすのか
• どこまで自律で進め、どこで人間確認を挟むのか
• セッションはどの粒度で保持し、何を再利用するのか
• エージェントに許す権限境界をどう切るのか
• 失敗したとき、どう安全に再開・巻き戻しするのか
• ユーザーが安心して任せられる可視化をどう作るのか

つまり、これからのプロダクト設計は、「UIフローの設計」から「委任フローの設計」へ移っていく。PM は画面遷移だけでなく委任モデルを定義し、デザイナーはボタン配置だけでなく信頼・介入・進捗の可視化を設計し、エンジニアは単純な API 実装だけでなく runtime・guardrails・observability を整えることになる。