本文へ移動

AI Buildersのための最新のニュース、知見、事例を毎日お届け

運営会社
ループエンジニアリングを学ぶAnthropic

「常駐エージェント」は大半の時間を眠っている Anthropicが示す5つの部品

常駐エージェントを受信箱・タイマー・メモリ・権限・送信箱の5つの部品に分けて設計する考え方と、Anthropicの記事が数字で示す点と示さない点を整理する。Claudeで背景に回るエージェントを作る時の部品の洗い出しに使える。

米Anthropicは11月13日、常駐エージェントの作り方を解説する記事を公開した。エージェントのループ自体は他と同じで、作るのは受信箱・タイマー・メモリ・権限・送信箱の5つの部品だという。記事が挙げる数字は、Opus 5.5の費用がOpus 5よりコーディングの課題で78%、通常の負荷で40%少ないという費用の比較だけで、設計の推奨に効果を測った数字は無い。

記事の内容を自社でどう進めるか、内容が固まっていない段階でも相談できます。仕事の相談

毎週 1 回、その週の記事から 5 本と実践の 1 本を選んでメールで届けます。ニュースレターを購読する(無料)

薄い灰色の背景に、白い吹き出しと黒い波のような手描きの線を描いた米Anthropicの記事の告知用の絵
画像: Anthropic

米Anthropicは11月13日、常駐エージェントの作り方を解説する記事を公式サイトで公開した。Claude Platformの分類で公開した同社の解説で、第三者の評価ではない。

記事によると、エージェントのループ自体は普通のエージェントと同じで、作るのはイベントの受信箱・タイマー・メモリ・権限・送信箱の5つの部品だ。記事が挙げる数字はモデルの費用の比較(78%と40%)だけで、どの部品が効くかを測った数字は無い。

数字は費用の比較だけ

記事が挙げる数字は費用の比較だけだ。長期のコーディングのベンチマークで、Opus 5.5は解けた課題1件あたりの費用がOpus 5より78%少なく、通常の負荷では40%少ないという。記事はこれを、判断の良さと並べて、常駐エージェントが実用になった理由に挙げる。

記事の図は7枚あり、どれも仕組みを描いた図で数値は無い。最初の図は、常駐エージェントが実は大半の時間を眠っており、トークンを使わずに待つ姿を描く。イベントが来ると起きて作業し、結果を保存してまた眠る。この1回の作業を記事は「run」と呼ぶ。

残りの6枚は、受信箱・タイマー・メモリ・送信箱の4つの部品、コンテキストの使われ方、5つの部品のつながりを描く。権限の図は無い。受信箱はデータベースのテーブルで、HTTPの受け口が書き込み、ワーカーが読んで作業を始める。タイマーは別のテーブルに置き、スケジューラーが期日の物を受信箱にイベントとして入れる。メモリはファイルのディレクトリで、送信箱は送るメッセージのテーブルとディスパッチャーで作る。

受信箱には記事が細かい決まりを付けている。Webhookの送り手は遅い応答を失敗とみなすので、受け口はすぐ応答し、プロンプトインジェクションの確認のような重い検査はrunの中で行う。1つの受信箱で動くワーカーは常に1つにし、続けて届いたメッセージは1回のrunにまとめて返事を1つにする。

78%は478問の課題で測った

記事の数字のリンク先、モデルの費用を最適化するページによると、78%はSWE-bench Proの478問の部分集合で測った。各モデルのデフォルトの設定で、effortはOpus 5がhigh、Opus 5.5がmediumだ。

解いた割合は91.9%と92.8%でほぼ同じで、解けた課題1件あたりの費用は1.01ドルから0.22ドルに下がった。費用は表示価格で計算し、キャッシュの寿命は5分とした。Opus 5の価格で計算し直すと、差は約69%に縮む。

40%の方について、同じページは出典をOpus 5.5の発表としている。「通常の負荷」が何の作業かと測り方は、記事にもこのページにも記載がない。受信箱やタイマーの推奨も、効果を測った数字は記事に記載がない。

人の判断と情報の欠けは残る

記事は自らの推奨にいくつか留保を付けている。権限の節では、Claude Codeの「auto mode」が分類器で危ない操作を止めると紹介しつつ、最も重要な判断には人のレビューが要ると書く。

コンテキストの節では、長くなったセッションは古いメッセージを圧縮するか新しいセッションにするが、どちらも細部を失うと書く。残すべき情報は、作業の途中でメモリに保存しておく前提だ。

送信箱の節では、送るメッセージの数を評価の仕組み(eval)で調整するよう勧め、最初は静かに始めるのがよいとする。多すぎればうるさく、少なすぎれば伝えるべきことを逃すからだという。

どれもAnthropicが自社の解説として書いた推奨で、他社の基盤で同じように効くかは記事からは分からない。

自分の仕事で試すなら

メモリから始めるなら、Messages APIのメモリツールが記事の推奨と同じ形だ。Claudeは「/memories」の下のファイル操作を頼むだけで、実際の保存はアプリが自前のストレージで行う。記事は、毎回読み込むのは指示と目次と伝えた内容の記録だけにし、細部のファイルは要る時に読む構成を例に挙げる。

APIキーなどの秘密情報は、安全なデプロイの文書と記事がともに、エージェントの外のプロキシで足す形を勧める。エージェントは秘密情報の無いリクエストを送り、プロキシが本物を差し込んで転送する。

人に確認を求める仕組みは、Claude Codeのhookの「defer」で試せる。ツール呼び出しを止めてセッションを保存し、答えが来たら再開する。Agent SDKの文書も、返事が遅い利用者を待つ時はプロセスを開いたままにせず、deferを返すよう勧める。hookの文書によると、deferが効くのは-pの非対話の実行で、1ターンのツール呼び出しが1つの時だけだ。

記事はプロンプトキャッシュで毎回の前置きの費用を下げるよう勧める。キャッシュの文書によると、キャッシュのデフォルトの寿命は5分で、1時間にすると書き込みの単価が基本の入力の2倍になる。費用のページは目安も示す。5分から1時間の間が空くターンがおよそ20回に1回以上あり、1時間を超える間が少なければ1時間の寿命にする。1時間を超える間が多ければ5分のままにする。Opus 5.5とSonnet 5.5では、5分のキャッシュを保つ要求を足す方が安い場合もある。常駐エージェントは起きる間隔をログで数えて目安に当てはめ、そのうえで自分の負荷で測るのがよい。

SAGUSの開発では、課題管理ツールに入った依頼を受け口に溜め、1件に1つの作業セッションだけを割り当てている。60分応答の無いセッションは外して開き直し、5分ごとの見回りが待ちの解けた件を起こし直す。記事の受信箱とタイマーに当たる形で、記事も1人の利用者に1つの受信箱から始めるよう勧めている。

編集部の見方

この記事で目を引くのは、数字が設計の効果ではなくモデルの費用の比較だけだという点だ。常駐エージェントは眠っては起きる作りなので、起きる間隔がキャッシュの寿命より長いと、記事が勧めるキャッシュは効かず、前置きを毎回書き込み直す費用がかかる。編集部は、部品の作り方より先に、起きる頻度と1回の前置きの大きさを測ってから構成を決めるのがよいと見る。Anthropicが常駐の構成で費用を測った数字を出せば、この見方も改める。

出典

に確認(日本時間)

  1. 常駐エージェントの作り方を解説する記事(claude.com)
  2. モデルの費用を最適化するページ(platform.claude.com)
  3. メモリツール(platform.claude.com)
  4. 安全なデプロイの文書(code.claude.com)
  5. hookの「defer」(code.claude.com)
  6. Agent SDKの文書(code.claude.com)
  7. キャッシュの文書(platform.claude.com)

この記事をシェア

この記事は役に立ちましたか