21 ポイント 投稿者 GN⁺ 18 일 전 | まだコメントはありません。 | WhatsAppで共有
  • 長時間実行エージェント向けのホスティングサービス Managed Agents は、ハーネスがモデルの進化に応じて変化しても安定して維持されるインターフェースベースのアーキテクチャを採用
  • ハーネスは Claude が単独では実行できない作業に関する前提をエンコードするが、モデルが進化するとその前提は古くなり (stale)、不要なオーバーヘッドを生む
  • オペレーティングシステムがハードウェアをプロセス・ファイルのような抽象化で仮想化したのと同様に、Managed Agents はエージェント構成要素(セッション、ハーネス、サンドボックス)を仮想化し、独立して置き換え可能にする
  • 頭脳(ハーネス)と手(サンドボックス)を分離することで、p50 TTFT を約 60% 削減し、p95 では90% 以上削減という性能改善を達成
  • この設計は、今後どのようなハーネスやサンドボックスが登場しても受け入れられるメタハーネス (meta-harness) として機能

ハーネスの前提はモデルの進化とともに古くなる

  • ハーネスは Claude が自力ではできない作業に関する前提をエンコードする構造だが、モデルが進化するとその前提は不要になる
  • Claude Sonnet 4.5 では、コンテキストの限界が近づくと作業を早期終了する**"context anxiety"** 現象があり、コンテキストのリセットをハーネスに追加した
  • Claude Opus 4.5 ではこの挙動が消え、リセットロジックが不要なコードになった
  • ハーネスは今後も変化し続けると見込み、特定の実装に依存しない汎用インターフェースベースの Managed Agents サービスを構築

オペレーティングシステムに着想を得た設計哲学

  • オペレーティングシステムはハードウェアをプロセス、ファイルのような抽象化で仮想化し、まだ存在しないプログラムでも実行できるように設計されている
  • read() コマンドが 1970 年代のディスクパックでも最新の SSD でも同じように動作するように、抽象化はハードウェアより長く持続する
  • Managed Agents も同じパターンに従ってエージェント構成要素を仮想化
    • セッション (session): 発生したすべてのイベントの append-only ログ
    • ハーネス (harness): Claude を呼び出し、ツール呼び出しをルーティングするループ
    • サンドボックス (sandbox): Claude がコードを実行し、ファイルを編集する実行環境

初期設計: 単一コンテナの限界("Pet" 問題)

  • 初期には、セッション、ハーネス、サンドボックスを1 つのコンテナに配置
  • ファイル編集を直接 syscall で実行でき、サービス境界の設計が不要という利点があった
  • しかしコンテナが**"pet"**(交換不可能な個別インスタンス)になる問題が発生
    • コンテナ障害時にセッションが失われる
    • 応答不能時にコンテナを手動で復旧しなければならない
  • デバッグの観点では、WebSocket イベントストリームだけでは障害発生箇所を特定できず、コンテナにシェルアクセスするとユーザーデータが含まれているため、デバッグ自体が難しかった
  • ハーネスはすべての作業対象がコンテナ内部にあると仮定していたため、顧客のVPC 接続要求に対応するには、ネットワークピアリングや自前環境でのハーネス実行が必要だった

頭脳と手の分離(中核アーキテクチャ)

  • "頭脳"(Claude とハーネス)、"手"(サンドボックスとツール)、"セッション"(イベントログ)をそれぞれ独立したインターフェースとして分離
  • 各構成要素は独立して障害を起こしたり置き換えたりできる

ハーネスのコンテナ脱出

  • ハーネスがコンテナの外に移動し、コンテナを他のツールと同じく execute(name, input) → string として呼び出す
  • コンテナは**"cattle"**(交換可能なインスタンス)へと転換
  • コンテナ障害時には、ハーネスがそれをツール呼び出しエラーとして処理し、Claude が再試行を決めた場合は provision({resources})新しいコンテナを初期化

ハーネス障害からの復旧

  • セッションログはハーネスの外部に存在するため、ハーネス内部に生存している必要のある状態がない
  • 障害時には wake(sessionId)getSession(id) によってイベントログを取得し、最後のイベントから再開
  • ハーネスはエージェントループ中、emitEvent(id, event) により永続的なイベント記録を維持

セキュリティ境界

  • 結合設計では、Claude が生成した信頼できないコードが認証情報と同じコンテナで実行されるため、プロンプトインジェクションで環境変数を窃取できた
  • 攻撃者がトークンを入手すると、制限なく新しいセッションを作成し、作業を委任できる
  • 構造的な解決策として、サンドボックスがトークンに絶対にアクセスできないよう分離
  • Git: リポジトリアクセストークンでサンドボックスを初期化する際にクローンし、ローカルの git remote に接続することで、エージェントはトークンを直接扱わずに push / pull を実行
  • MCP カスタムツール: OAuth トークンをセキュアボールト (vault) に保存し、専用プロキシを介して MCP ツール呼び出し時にセッション関連トークンでボールトから認証情報を取得し、外部サービスを呼び出す

セッションは Claude のコンテキストウィンドウではない

  • 長時間の作業は Claude のコンテキストウィンドウ長を超えることが多く、何を保持するかについて不可逆な判断が必要
  • 圧縮 (compaction): Claude がコンテキストウィンドウの要約を保存
  • メモリツール: Claude がコンテキストをファイルに記録し、セッションをまたいで学習できるようにする
  • コンテキストトリミング: 古いツール結果や思考ブロックなど、選択的にトークンを削除
  • 不可逆なコンテキスト破棄は、将来のターンが必要とするトークンを予測しにくいため、失敗につながる可能性がある
  • 先行研究では、コンテキストをコンテキストウィンドウの外側に存在するオブジェクトとして保存し、LLM がコードを書いてプログラム的にアクセスする方式を探求してきた

Managed Agents におけるセッションログ活用

  • セッションはコンテキストウィンドウの外側に存在するコンテキストオブジェクトとして機能
  • サンドボックスや REPL ではなく、セッションログに永続的に保存される
  • getEvents() インターフェースでイベントストリームの位置ベースのスライスを選択可能
    • 最後に読んだ位置から続けて読む
    • 特定時点より前の数イベントを巻き戻して確認する
    • 特定アクションの前のコンテキストを再読する
  • 取得したイベントはハーネスで変換して Claude のコンテキストウィンドウに渡すことができる
  • 変換内容には、高いプロンプトキャッシュ命中率のためのコンテキスト整理やコンテキストエンジニアリングが含まれる
  • セッションは永続保存と取得だけを保証し、具体的なコンテキスト管理はハーネスに委ねることで、将来のモデル要件の変化に対応

多数の頭脳、多数の手

多数の頭脳 (Many Brains)

  • 頭脳と手の分離により、初期の顧客不満を解消: VPC 内リソースで作業する際にも、もはやネットワークピアリングは不要
  • 初期設計では各頭脳ごとにコンテナが必要で、コンテナのプロビジョニングが終わるまで推論を開始できなかった
  • サンドボックスが不要なセッションでも、リポジトリのクローン、プロセス起動、保留イベントの取得など、フルコンテナセットアップのコストを負担していた
  • 分離後は、コンテナが必要な場合にのみツール呼び出しとしてプロビジョニングし、不要な待機時間を除去
  • 推論は、オーケストレーションレイヤーがセッションログから保留イベントを取得した直後に開始可能
  • p50 TTFT を約 60% 削減p95 TTFT を 90% 以上削減
  • 多数の頭脳への拡張は、単にステートレスなハーネスを多数起動し、必要なときだけ手に接続することで実現

多数の手 (Many Hands)

  • 各頭脳を複数の実行環境に接続する機能が必要
  • Claude が複数の実行環境について推論し、作業配分を決めなければならないため、単一シェルより認知的に難しい課題
  • 初期にはモデル能力不足のため頭脳を単一コンテナに配置したが、知能が向上するにつれて単一コンテナがかえって制約となった
  • 分離設計では各手を execute(name, input) → string ツールとして扱う
    • カスタムツール、MCP サーバー、自前ツールをすべてサポート
    • ハーネスは、サンドボックスがコンテナなのか、スマートフォンなのか、ポケモンエミュレータなのかを知る必要がない
  • 頭脳と手が結合していないため、頭脳間で手を受け渡すことも可能

結論: メタハーネスとしての Managed Agents

  • オペレーティングシステムがハードウェアを仮想化し、まだ存在しないプログラムを受け入れたのと同じアプローチ
  • Managed Agents は特定のハーネスに依存しないメタハーネスとして、さまざまなハーネスを受け入れる汎用インターフェースを提供
  • Claude Code も 1 つのハーネスとして利用可能で、作業特化型エージェントハーネスにも対応
  • インターフェースについては明確な立場を持つ: Claude には**状態操作(セッション)計算実行(サンドボックス)**の能力が必要だという点
  • 多数の頭脳と手への拡張、長期的に安定かつ安全な運用のためのインターフェース設計
  • 頭脳と手の数や配置についてはいかなる前提も置かない

まだコメントはありません。

まだコメントはありません。