Claudeで長期実行AIエージェントを構築する方法

要点

Claude Managed Agentsは、Anthropicが提供するプロダクションエージェント向けの新ホスト型ランタイムです。チームがインフラストラクチャをゼロから構築することなく、サンドボックス実行、長期間セッション、スコープ付きパーミッション、トレーシング、そしてオプションのマルチエージェント連携を提供します。エージェントが内部ツール、サードパーティAPI、または長時間のワークフローを呼び出す必要がある場合、Apidogはエージェントが実際のシステムに触れる前に、これらのツール契約を検証するのに役立ちます。

はじめに

Claude Managed Agentsは、エージェントプロジェクトが停滞する最大の理由の一つ、つまりプロンプトよりもランタイムの出荷が難しいという問題に対処します。Anthropicは、サンドボックス、パーミッション、トレーシング、セッション永続性を内蔵した、長期間稼働するエージェントを実行するためのホスト型方法を提供することで、チームが基盤構築に費やす時間を減らし、より有用なワークフローを出荷することに集中できるようにします。

💡

これはAPIチームにとっての議論を変えます。もはや、Claudeがタスクを推論できるかどうかは難しい部分ではありません。難しいのは、エージェントが適切なツールを安全に呼び出し、不正な応答から回復し、通常のチャットリクエストよりもタスクが長く実行される場合でも作業を継続できるかどうかです。

ボタン

エージェントに内部APIやツールエンドポイントを公開する予定がある場合、公開前にその表面をテストする必要があります。Apidogは、ツールエンドポイントをモックし、JSONスキーマを検証し、多段階テストシナリオを連鎖させ、Apidog CLIを使用してCIで回帰チェックを実行する直接的な方法を提供します。これは、新しいホスト型エージェントにライブアクセスを許可し、本番環境で契約バグを発見するよりも安全な出発点です。

プロダクションエージェントの出荷が依然として難しい理由

週末のデモエージェントは簡単です。プロダクションエージェントはそうではありません。

単一のリクエストと応答を超えると、すぐに難しい部分が現れます。

ファイルの生成、データの変換、カスタムスクリプトの呼び出しを行うアクションには、安全なコード実行が必要です。
ネットワーク切断やブラウザのリフレッシュ後も存続する状態が必要です。
エージェントが別のシステムを密かに編集することなく、あるシステムを読み取れるように、明確なパーミッション境界が必要です。
「モデルが奇妙なことをした」だけではインシデントレビュー時に十分ではないため、デバッグ用のトレースが必要です。
ワークフロー全体をゼロから再実行することなく、失敗したステップを再試行する方法が必要です。
エージェントが呼び出すAPIやツールには、予測可能な契約が必要です。

これが、多くのチームがプロトタイプとローンチの間で立ち往生する理由です。モデル部分は改善され続けていますが、運用部分は依然としてスケジュールを圧迫します。

このパターンは、あらゆるエージェント製品で共通しています。コーディングアシスタント、リサーチエージェント、会議準備ツール、ワークフロー自動化を構築するチームはすべて同じボトルネックに遭遇します。それは、ランタイム自体が独立した製品となることです。Anthropicは、そのレイヤーをマネージドサービスに集約しようとしています。

Claude Managed Agentsに含まれるもの

Anthropicのローンチ記事によると、Claude Managed AgentsはClaudeに最適化されたオーケストレーションハーネスとホスト型プロダクションインフラストラクチャを組み合わせています。実際には、このローンチはAPIチームにとって重要な5つの機能を提供します。

1. ホスト型エージェントランタイム

ジョブ、ツールアクセス、ガードレールを定義します。Anthropicが独自のインフラストラクチャでループを実行します。これにより、キュー、サンドボックスワーカー、セッション層、実行コントローラーを構築する必要があったチームのカスタムバックエンド作業が大幅に削減されます。

これが今回のローンチにおける最大の価値です。ほとんどのチームはすでにモデルを呼び出すことができます。彼らが持っていないのは、実際の作業のためのクリーンなランタイムです。

2. 長期間セッション

Anthropicによると、セッションは数時間にわたって実行でき、クライアントが切断しても出力と進行状況が保持されるとのことです。これは、研究タスク、大規模なファイル生成、多段階計画、または短いインタラクティブなリクエストに収まらないバックグラウンドでの運用作業にとって重要です。

エージェントがレポートを作成したり、コードベースを監査したり、ドキュメントを処理したり、複数のシステムから成果物を組み立てたりする場合、長期間セッションは大きな制約を取り除きます。短いチャットウィンドウを中心に設計するのをやめ、完了した作業を中心に設計するようになります。

3. サンドボックス実行とガバナンス

このローンチは、安全なサンドボックス化、認証、ID、スコープ付きパーミッションを重視しています。これは些細なことではありません。これは、興味深いデモとエンタープライズ対応システムとの違いです。

プルリクエストを開いたり、スプレッドシートを生成したり、財務データとやり取りしたりできるエージェントは、デフォルトで広範なアクセス権を持つべきではありません。ホスト型ガバナンスにより、ランタイムができることを制限し、セキュリティチームにより明確なレビュー表面を提供できます。

4. 組み込みのトレーシングとトラブルシューティング

Anthropicによると、ツール呼び出し、決定、分析、および障害モードはClaude Consoleで確認できるとのことです。優れたトレーシングは、「何かが失敗した」と「これが原因となった正確なリクエスト、ツール出力、および分岐です」の間のギャップを短縮します。

これは、プロンプトではなくツールをデバッグする際に特に役立ちます。多くのエージェントシステムでは、最も弱いリンクはモデル自体ではなく、ツールに関するAPI契約です。

5. マルチエージェント連携（研究プレビュー中）

Anthropicはまた、エージェントが他のエージェントに作業を並行して実行するよう指示できるマルチエージェント連携も発表しました。これはまだ研究プレビュー段階であるため、この記事の主要なトピックではありません。しかし、これはプラットフォームがどこに向かっているかを示しています。つまり、単一のワーカーから、調整されたエージェントチームへと移行しています。

エージェント製品のアーキテクチャがどのように変わるか

Managed Agentsが登場する前は、一般的なチームには2つの選択肢がありました。

オプションA：ランタイムを自社で構築する

これにより最大限の制御が可能になります。また、以下のものを自社で所有することになります。

コンテナまたはVMの分離
ツール実行ライフサイクル
セッションの永続性
チェックポイント
シークレットと認証情報
権限設定
ログとトレース
再試行とリカバリ
立ち上げ後の運用保守

この方法は、特殊なインフラストラクチャ、厳格な社内ホスティング要件、または非常にカスタムなオーケストレーションロジックが必要な場合に依然として有効です。

オプションB：マネージドランタイムを使用する

これは、速度と引き換えに一部の制御を譲るものです。ランタイムはすでに提供されているため、チームは基盤構築に時間を費やす代わりに、タスク設計、UX、ツールの品質に時間を割くことができます。

そのため、AnthropicはManaged Agentsをプロダクションへの移行を10倍速くする方法として位置づけています。ローンチ記事によると、構造化ファイル生成に関する内部テストでは、標準的なプロンプティングループと比較してタスクの成功率が最大10ポイント向上し、特に難しい問題で最大の向上が見られたとのことです。

重要な変化はこれです。ホスト型エージェントインフラストラクチャは、スタック内のサイドプロジェクトではなく、製品カテゴリになりつつあります。

Claude Managed Agentsと自社構築エージェントインフラストラクチャの比較

決定領域	Claude Managed Agents	自社構築ランタイム
初回プロダクション立ち上げまでの時間	ランタイムがすでにホストされているため速い	まずランタイムを構築するため遅い
サンドボックス化とガバナンス	組み込み済み	設計全体を自社で所有
長期間セッション	組み込み済み	セッション状態を自社で構築・維持
トレーシング	Claude Consoleで利用可能	独自の可観測性レイヤーを構築
柔軟性	サポートされるモデルとランタイムパターンに良好	最高の柔軟性
継続的な運用負荷	低い	高い
最適な用途	エージェント製品を迅速に出荷したいチーム	特殊なインフラストラクチャや厳格なカスタムランタイム要件を持つチーム

実用的なルールは次のとおりです。

今四半期にエージェント製品を出荷したいチームで、その主要な差別化要因がワークフロー、UI、またはその背後にある独自のツールである場合は、Managed Agentsを選択してください。

ランタイム自体が自社の競合優位性の一部である場合、ホスティングとオーケストレーションを完全に制御する必要がある場合、またはセキュリティモデルがマネージドサービスでは提供できないより深いカスタム処理を要求する場合は、自社構築（DIY）を選択してください。

理解すべき価格とトレードオフ

Managed Agentsは、標準的なClaude Platformのトークン料金に加え、アクティブセッション時間あたり0.08ドルを使用します。これは、時間とともに実際の作業を行うエージェントにとっては理にかなっていますが、コストに関する考え方を変える必要があります。

通常のチャットAPIワークフローでは、コストは主にトークンから発生します。マネージドランタイムでは、コストはトークンに加えて経過したアクティブなランタイムから発生します。つまり、エージェントは作業をきれいに完了させ、不正な入力に対しては迅速に失敗し、無意味なループを避けるように設計すべきです。

採用する前に重要な3つの質問があります。

セッションはどれくらいの頻度で数分間実行され、どれくらいの頻度で数時間実行されるか？
1回の完了した実行はユーザーにとってどれだけの価値を生み出すか？
どのタスクを同期的に保ち、どのタスクをバックグラウンド実行に移行すべきか？

答えが「私たちのエージェントは主に短い決定論的な呼び出しを行う」であるならば、通常のAPI統合で十分かもしれません。

答えが「私たちのエージェントは調査、執筆、パッチ適用、ツールの連携を行い、後で成果物を返す」であるならば、マネージドランタイムははるかに魅力的に見え始めます。

ApidogでエージェントツールAPIを公開前にテストする方法

ここで記事は具体的にする必要があります。

多くのエージェントの立ち上げにおける弱点はモデルではありません。それはツール層です。エージェントがsearch_customers、create_invoice、open_pr、またはsend_slack_messageを呼び出すことができる場合、それらのツールはすべてAPI契約です。ペイロードが不正な形式の場合、スキーマがずれ込んだ場合、必須フィールドが消えた場合、または認証トークンのスコープが間違っている場合に何が起こるかを知る必要があります。

Apidogは、エージェントが本番環境に投入される前にツール契約をモデル化できるため、このワークフローにうまく適合します。

Smart Mockを使用してツールエンドポイントを早期に立ち上げる

Smart Mockは、API仕様から直接現実的な応答を生成し、JSONスキーマの制約を尊重します。これにより、実際のバックエンドがまだ変更されている間でも、チームは迅速に偽のツールエンドポイントを立ち上げることができます。

エージェントの作業にとって、これは重要です。なぜなら、すべてのダウンストリームサービスが準備できる前に、計画とツールの選択をテストできるからです。マネージドエージェントがticket_priority、account_id、またはstatus列挙型を期待する場合、Smart Mockはバグを隠す手書きのプレースホルダーではなく、スキーマに一致するデータを返すことができます。

チーム全体でこのワークフローを標準化している場合は、2026年のPostmanを使わないAPIテストも参照してください。

エージェントワークフローのための多段階テストシナリオを構築する

Apidogのテストシナリオは、あるツール呼び出しが次のツール呼び出しに引き継がれる場合に役立ちます。ドキュメントには、シーケンシャル実行、リクエスト間のデータ受け渡し、フロー制御、事前定義されたテストデータ、およびCI/CD統合のサポートが記載されています。

これはエージェントシステムにきれいに当てはまります。

現実的な検証フローは次のようになるかもしれません。

POST /tasksをモックまたは呼び出す
返されたtask_idを抽出する
GET /tasks/{task_id}を呼び出す
ステータス遷移をアサートする
無効な認証情報でエラーブランチをトリガーする
エージェント向けのエラーペイロードが契約内にあることを確認する

この種のシナリオは、エージェントランタイムが本番環境でそれらを回復する前にツールバグを捕捉します。

エージェントを壊す前に契約のずれを検証する

エージェントはスキーマのずれに敏感です。名前変更されたフィールド、緩い列挙型、または欠落したネストされたプロパティは、推論の失敗のように見える方法でツールチェーンを破壊する可能性があります。

Apidogを使用して、OpenAPIとJSONスキーマでリクエストとレスポンスの形状を固定し、バックエンドが変更されたときにシナリオベースのチェックを実行します。チームが生成されたツール定義を使用している場合、エージェントが提供された仕様を信頼するため、これはさらに重要です。

CIにCLIチェックを追加して回帰テストを網羅する

Apidog CLIは、コマンドラインからテストスイートを実行し、生成されたapidog-reports/ディレクトリにHTMLレポートを含むレポートを出力できます。これにより、エージェントツールのマージ前またはデプロイ前チェックに適しています。

単純なポリシーで十分です。

すべてのツールエンドポイントにはスキーマチェックが必要
すべての書き込みアクションには少なくとも1つの認証失敗テストが必要
すべての長期間ワークフローにはタイムアウトと再試行ケースが必要
すべての高リスクツールには、不正な状態に対する1つのネガティブテストが必要

これを行うことで、マネージドエージェントはよりクリーンなツール表面で本番環境に投入されます。

まず始めるためのシンプルなアーキテクチャパターン

初日から大規模なエージェントプラットフォームは必要ありません。シンプルなパターンで十分です。

ユーザーリクエスト
  -> Claude Managed Agentセッション
  -> ツール選択
  -> 内部APIとサードパーティサービス
  -> 結果成果物またはアクション
  -> Claude Consoleでのトレースレビュー

公開前:
  Apidog仕様 -> Smart Mock -> テストシナリオ -> CIでのCLI回帰

この分離は健全です。

Claude Managed Agentsにはセッション管理、ホスト型実行、オーケストレーションなどのランタイムに関する懸念を扱わせましょう。Apidogには、エージェントが依存するツールに関するAPI契約設計、モック、テスト、回帰チェックを扱わせましょう。

これにより、モデル層とAPI品質層が分離され、ほとんどのチームが必要としている状態です。

このローンチが最も重要な場合

Claude Managed Agentsが最も興味深いのは、次の5つのグループです。

コーディングまたはデバッグエージェントを構築するチーム
数分以上かかるドキュメントまたは研究ワークフローを実行するチーム
アプリ内でバックグラウンドタスク実行を望む製品チーム
ガバナンス、トレーシング、スコープ付きパーミッションを必要とするエンタープライズチーム
既存の内部ツールを持ち、エージェント製品へのより迅速なルートを望むAPIチーム

チームがまだユースケースを検証中であれば、狭いワークフローと小さなツール表面から始めましょう。

ユースケースがすでに機能しており、インフラストラクチャがボトルネックになっている場合、このローンチは真剣に検討する価値があります。

結論

Claude Managed Agentsは、単なる別のモデル機能ではありません。これはAnthropicによる、エージェント提供における複雑な部分、すなわちホスト型実行、永続性、ガバナンス、トレーシングを製品化する試みです。

これが、このローンチが重要である理由です。「どのようにエージェントランタイムを作成するか」という構築に関する疑問を、「どのワークフローがエージェントに値するのか、そしてその背後にあるツールはどれほど安全なのか」という疑問へと転換させます。

その2番目の質問にApidogが適合します。長期間稼働するホスト型エージェントに内部APIを公開する前に、契約をモデル化し、応答をモックし、失敗パスをテストし、CIで回帰テストの網羅性を追加してください。その作業により、エージェントはよりクリーンな表面で動作し、チームはローンチ後の予期せぬ事態を減らすことができます。

ボタン

よくある質問

Claude Managed Agentsとは何ですか？

Claude Managed Agentsは、Claude Platform上のクラウドベースエージェント向けAnthropicのホスト型ランタイムです。サンドボックス実行、長期間セッション、トレーシング、スコープ付きパーミッション、ホスト型オーケストレーションが含まれています。

Claude Managed Agentsは現在利用可能ですか？

はい。Anthropicは2026年4月8日にこれをパブリックベータとして発表しました。マルチエージェント連携や自己評価ループなど、一部の機能はまだ研究プレビュー段階です。

Claude Managed Agentsの料金体系はどうなっていますか？

Anthropicによると、標準的なClaude Platformのトークン料金に加え、アクティブセッション時間あたり0.08ドルが適用されます。

独自のランタイムを構築する代わりに、いつManaged Agentsを使用すべきですか？

ランタイムの深いカスタマイズよりも、本番環境への迅速な展開が重要な場合にManaged Agentsを使用してください。チームが特別なホスティング、厳格な社内制御、またはマネージドプラットフォームではサポートできないカスタムオーケストレーションを必要とする場合、自社構築（DIY）の方が適しているかもしれません。

APIチームはなぜエージェントツールを個別にテストすべきですか？

多くのエージェントの失敗は、推論の不備ではなく、壊れたツール契約、認証問題、またはスキーマのずれに起因するからです。ツールを個別にテストすることで、それらの失敗がランタイムに到達する前に捕捉するのに役立ちます。

Apidogはエージェントツールのテストにどのように役立ちますか？

Apidogは、ツール契約を定義し、Smart Mockを使用してスキーマからモック応答を生成し、テストシナリオで多段階検証を連鎖させ、Apidog CLIを使用してCIで回帰チェックを実行するのに役立ちます。