自宅でClaude Codeベースの個人用AIアシスタントを動かしている。散歩しながらAWSインフラを整理したのも、対話とコード開発でモデルを分けたのも、この基盤の話だ。
エージェントに仕事をさせる基盤を自前で組むと、AI本体より周辺インフラのほうがずっと重いことを思い知る。コードを書き換えさせるなら作業領域を隔離しないと本体が壊れる。シェルを持たせるなら触れる範囲を絞らないと事故る。長いタスクは途中で死ぬ前提で、復旧の仕掛けがいる。うちではこれをgit worktreeとsystemdのサンドボックスとSQLiteのジョブ管理で作ってきた。
2026年4月にAnthropicが発表したClaude Managed Agentsのドキュメントを読んで、「これは全部、覚えがある」となった。自前で作った部品の一つひとつに、製品側の対応物がある。なのでこの記事はベンダー紹介ではなく、同じものを小さく作った者の答え合わせとして書く。
何のサービスか
一言でいえば「本番エージェントに必要なインフラ——実行サンドボックス・状態管理・クレデンシャル管理・トレーシング——を丸ごとAnthropicがホストするサービス」。エージェントの定義（システムプロンプト＋ツール）だけ書けば、実行環境はAPI一発で手に入る。エージェント定義（Agent）、コンテナテンプレート（Environment）、実行インスタンス（Session）の3つをAPIで作り、あとはイベントを流し込むだけだ。
答え合わせ — 自宅の部品と製品の対応
| 自宅で自作したもの | Managed Agents側 |
|---|---|
| git worktreeでタスクごとに作業コピーを隔離 | コンテナをセッション単位でオンデマンド起動・使い捨て |
systemdの ProtectSystem とsudoホワイトリストで触れる範囲を制限 | サンドボックス実行環境 + スコープ付き権限 |
| タスク状態をSQLiteに置き、プロセスが死んでも再開 | append-onlyのセッションログ + wake(sessionId) で復旧 |
| クレデンシャルは都度発行し、エージェント本体に長命の鍵を持たせない | Vault-proxied（実行環境にクレデンシャルを置かない） |
設計の答えがここまで揃うのは偶然ではないと思う。エージェントに実行環境を渡すと、誰が作っても同じ問題を踏む。隔離・権限・復旧・秘密の受け渡し。この4つから逃げられた自作エージェント基盤を見たことがない。
一番面白いのは「脳と手の分離」
アーキテクチャは3コンポーネントに分かれる。
| コンポーネント | 役割 | AWSで例えると |
|---|---|---|
| Brain（脳） | Claude + ハーネス（エージェントループ） | コントロールプレーン |
| Hands（手） | サンドボックスコンテナ（コード実行・ファイル操作） | データプレーン（ワーカーノード） |
| Session | 永続的なappend-onlyイベントログ | イミュータブルなログストア |
核心は、ハーネスがコンテナの中で動かないこと。ハーネスは実行環境を execute(name, input) → string という統一インターフェースの「ツール」として呼ぶ。コンテナはCattle（使い捨て）であってPet（手塩にかけるサーバー）ではない。
これは自作勢として一番うらやましい部分だ。うちのアシスタントはエージェント本体とワーカーが同じホストに同居しているので、ワーカーの暴走が本体を巻き込むリスクを常に設計で吸収している。脳を外に出してしまえば、この心配ごと自体が消える。コントロールプレーンとデータプレーンの分離という、インフラの定石がそのまま効いている。
分離の恩恵は速度にも出ていて、コンテナはセッション開始時ではなく必要になった時点でプロビジョニングされるため、推論はコンテナ起動を待たずに始まる。公称でTTFT（最初のトークンが出るまでの時間）がp50で約60%、p95で90%以上改善したとのこと。
障害回復も同じ原理で、状態はすべてセッションログ側にあるから、コンテナが死んでもハーネスが死んでも、新しい個体がログから復旧する。EC2のAuto Recoveryと同じで、ステートをインスタンスの外に持つものは強い。
クレデンシャル管理は2パターン。Gitトークンはリモート初期化時に仕込んでエージェントには触らせない（resource-bundled）、OAuthトークンは外部Vaultに置いてプロキシ経由で使う（Vault-proxied）。IAMロールをEC2に割り当てるのと同じ考え方で、実行環境に秘密を置かず、インフラ側が仲介する。
で、自作とどちらを選ぶか
答えは使う場面で分かれる。
個人の常駐アシスタントなら、自作を続ける。 理由は2つ。うちはClaude Codeの定額プランで回す設計で、Managed Agents（従量API + セッション時間 $0.08/時）に乗せると料金モデルごと変わってしまう。もう1つ、自宅のアシスタントはカレンダー・メール・ローカルのファイル・家のネットワークと密結合していて、その密結合こそが価値なので、実行環境だけクラウドに出すメリットが薄い。
仕事で「本番のエージェントを出せ」となったら、まずこれを検討する。 サンドボックス・権限・復旧・監査ログを自前で作る工数は、小さく作った経験から言って全く軽くない。それが数日で立つなら、浮いた時間をエージェントのロジックに使うほうが正しい。EC2に自分で組むか、Fargateに任せるかの判断と同じで、問うべきことも同じ——そのインフラは、自分たちの差別化要因か？
料金と提供形態
| 項目 | 料金 |
|---|---|
| トークン使用量 | 通常のAPI料金 |
| セッション実行時間 | $0.08/時（アクティブ時間のみ課金） |
| Web検索 | $10/1,000検索 |
Anthropicのエージェント提供形態は3層あり、位置づけはこう理解している。
| Messages API | Agent SDK | Managed Agents | |
|---|---|---|---|
| 何か | 直接モデル呼び出し | 自前インフラでエージェントループを組む | フルマネージドハーネス |
| AWSで例えると | EC2（全部自分で） | ECS（オーケストレーションは自前） | Lambda/Fargate（インフラ抽象化） |
うちの自宅基盤はAgent SDK相当を手組みしている位置づけになる。