Claude Opus 5.5 でプロアクティブ・エージェント・ループを構築する

自分専用のプロアクティブエージェントを作るうえで居心地が悪いのは、面白い作業がモデル呼び出しではないことだ。Claude Opus 5.5 に質問へ答えさせるだけなら半日でできる。それをスケジュールで起動し、前回以降に変わったものだけを読み、人間に渡す価値がある何かがあるか判断し、アクションを下書きし、そして止まって待つ——ここには数週間かかり、そのほとんどはモデルの内側では起きない。Anthropic はこのループの一版を Claude Duet として出荷したが、自分で作る人にとってこの製品が有用なのは機能一覧のせいではなく、その組み立て方に見える判断のせいだ。公開 API はなく、自分のシステムに向け直すこともできない。だからアプリではなくループが欲しいなら、自分で作ることになる。以下ではそのアーキテクチャを段階ごとに、それぞれの正直なコストとともに示す。

まず形から。5つの段階が順に実行され、第5段階に到達するのは、人間が「はい」と言った後だけだ。スケジューラが起動する。ダイジェスト段階が、接続された各システムを差分へと縮約する。意思決定段階が、その差分とポリシーを型付きの提案に変える。モデルの外側にある承認ゲートが、その提案を実行してよいかを決める。実行者がそれを実行する。これが設計の全体であり、難しいことはすべて継ぎ目に宿る。

ステージ1：数時間ごとに起動するスケジューラー

最初の判断は、人々がエンジニアリングではなく熱意から間違えてしまう類のものだ。継続的にポーリングしてはいけない。AnthropicのDuetドキュメントは、数時間ごとに確認するというその間隔について、絶え間なく確認するとプランの制限をはるかに速く使い果たしてしまうと説明している。それはマーケティング上の慎重さではない。実際のコスト問題に対する正しい答えであり、自作エージェントが最初の週に必ず陥る罠だ。

継続的なポーリングが破滅的なのは、構造上の理由がある。各スイープは1つのフルコンテキストだ。指示、ツール定義、取り込んだ資料、そしてモデルがその上で行う推論のすべてを含む。1分間隔なら1日1,440回のフルコンテキストになり、その圧倒的大多数は何も新しいものを見つけない。メールボックスが変わっていないと告げられるために全額を支払うことになる。3時間間隔なら1日8回で、発見と支出の比率は、請求書に署名する誰に対しても説明できるものになる。

つまり、スケジューラは最小間隔に下限を設けたcron形式のタイマーであり、イベントストリームではありません。イベントは魅力的に聞こえます——何かが起きた瞬間に反応できる——が、常時稼働へと引き戻し、忙しい日のコストを無制限にしてしまいます。タイマーは予測可能な上限をもたらし、請求額が変動するときに必要なものです。特定のソースについてより速い反応が欲しい場合は、そのコネクタの間隔だけを短くし、追加の費用を受け入れてください。

第2段階：バイト単位で完全に同一のプレフィックスを1つ、キャッシュに保持する

ここが、公表されている数値が最も重要な役割を果たす場面だ。OrcaRouter 上の Claude Opus 5.5 は、入力トークン100万個あたり4.00ドル、出力トークン100万個あたり20.00ドルで、100万トークンのコンテキストウィンドウを持ち、キャッシュ読み取りは100万個あたり0.20ドル、プロバイダーの定価でマークアップは0パーセントだ。これらの数値は価格表ではなく、設計上の制約として読むべきだ。キャッシュ読み取りのコストは新規入力トークンの20分の1なので、スイープ間で安定させておくすべてのバイトは、正規価格を支払わずに済むバイトになる。

実際には、システムプロンプトとツールスキーマはデプロイ時に一度だけ組み立てられ、スイープごとに再生成されることは決してありません。キーの順序が異なる辞書から再シリアライズされることも、タイムスタンプやリクエストID、今日の接続アカウントが途中に差し込まれてテンプレート化されることもありません。1バイトでも異なればキャッシュされたプレフィックスは無効になり、スイープのたびに命令ブロックは入力の全額課金に戻ります。チームはこれを意図的にではなく偶発的に失うことのほうがずっと多く、たいていは便利な抽象化がプロンプトの先頭付近に実行識別子を注入し始めたことが原因です。

実際のコードに触れても生き残る規律は地味だ。安定したブロックには定数文字列を返す関数を1つ、ツールスキーマには凍結したリテラルを置き、可変要素はすべてその後に配置する。次に、そのブロックをハッシュ化し、ハッシュが変わったらビルドを失敗させるテストを置く。なぜなら、誰かがいつかスキーマフィールドを追加し、キャッシュのことをまったく考えないからだ。そのテストは1時間のコストで、キャッシュの利点全体を守ってくれる。

ステージ3：メールボックスのダンプではなく、接続ごとのダイジェスト

第3段階は、消費者向け製品なら無料で得られるものだが、あなたには得られない。Duet は Anthropic のアカウント内に存在し、接続されたアプリにまで届くため、特定の時点以降に何が変わったかを尋ねて、小さな回答を得ることができる。そのアカウントの外で構築する場合、あなたは通常のクライアントと同じ API とやり取りすることになる。インクリメンタル読み取りを実装するか、すべてを取得してモデルに長大なテキストの壁を渡すかのどちらかだ。

すべてを取り込むのがデフォルトなのは、初日から機能するからです。しかし、これがスイープごとのコストを予測不能にする最速の方法でもあります。入力が変更された内容ではなくメールボックス全体に応じて増えるからです。変更のない40個のスレッドに対するスイープは、1つのスレッドだけが重要な40個のスレッドに対するスイープと同じコストがかかりますが、有用な提案の可能性があったのはそのうち一方だけです。それを1か月続けると、予算の大半は現状を確認するために消えていました。

ダイジェストのステップはプロンプトではなくコードであるべきです。接続ごとに、APIが提供するカーソルやデルタを使って取得し、その結果を構造化された要約にまとめます。何が出現したか、何が変更されたか、何が解決されたかです。各項目には後続のステージから参照できる安定した識別子を付け、接続ごとに最後に成功したカーソルを記録して、取得に失敗しても昨日の内容を新規であるかのように再生しないようにします。「何も起きなかった」と「確認できなかった」を区別できないダイジェストは、やがて、実際には観測していない状態について自信を持って報告するようになります。

第4段階：散文ではなくオブジェクトを出力する決定ステップ

ここにClaude Opus 5.5が位置し、それが出力する内容によって、システムの残りをそもそも構築できるかどうかが決まる。最初に思いつくのは、モデルに要約を書かせて人間に読ませる方法だ。それはダッシュボードには向くが、ゲートには通用しない。次の段階はある行動を許可するかどうかを判断しなければならず、許可を段落に与えることはできない。

意思決定ステップは、型付きのアクション提案を返すべきです。すなわち、クローズドリストからのアクション名、それが適用される対象、パラメータ、1行の根拠、および明示的な信頼度またはエスカレーションフラグです。クローズドなアクションリストは官僚主義ではなく、承認ゲートを強制可能にする仕組みです。なぜなら、ゲートは列挙できるアクションしか検証できないからです。任意の動詞を出力できるエージェントは、ゲートで制御できず、信頼するしかありません。

実務上の注意点が2つあります。モデルにはダイジェストを先に、次にポリシーを渡してください。そうすればポリシーは可変部分の後ろに置かれ、キャッシュのプレフィックスがそのまま保たれます。また、デフォルトの結果は「何もしない」にしてください。行動のように読める空の提案にするのではなく。沈黙を失敗とみなすループは量を生みますし、役に立っているように見せるために仕事を作り出すエージェントは、何も変わらなかったと報告するエージェントより悪いです。

ステージ5：実際に「ノー」と言える承認ゲート

ゲートは、エージェント自身のコード内の分岐ではなく、独立したサービスでなければならない。これはビルドにおける最も重要な構造上の決定だ。エージェントのプロセスがアクションを自ら実行できるなら、そのプロセス内のバグ、プロンプトインジェクション、設定ミスのフラグが実際の効果にまで届いてしまう。実行者がゲートの署名済み提案だけを受け入れるなら、エージェントにできる最悪のことは誤った提案をすることであり、ゲートによる拒否は現実の効力を持つ。

Duet に関する Anthropic の公表済みポリシーは、あなたのリストが異なる場合でも、その形だけはコピーする価値がある。ゲートは、アクションがメッセージを送信する前、支払いを行う前、文書に署名する前、または何かを削除する前に承認を求める。その上に、承認があっても拒否される第2層がある。Duet の場合、それは証券取引と口座間の資金移動だ。このパターンは二層ポリシーである。つまり、人間が許可できる多数のゲート対象アクションと、承認では解錠できない少数の集合だ。項目がすべて変わっても、この層はコピーせよ。なぜなら、それらは異なる問題を解決するからだ。ゲートはミスから守る。禁止リストは、侵害された運用者から守る。人間の運用者も含めて。

本物のゲートのもう半分は、それが割り込むことです。Duetの承認リクエストは正確なアクションを表示して待機し、フローに注記を付けるのではなく意図的に停止させます。誰も読まないログに一行書き込むだけのゲートはゲートではありません。それは領収書です。承認ステップで午前3時に誰かがダッシュボードを見張る必要があるなら、間隔が短すぎるか、アクションリストが広すぎるかのどちらかです。どちらも修正可能で、どちらも通知を追加することで直るものではありません。

メモリ、認証情報、そしてテストだけではどうにもならない2つの表面

5つの段階の下には2つの困難な問題が横たわっており、どちらも機能のように見えるが、そうではない。

• コンテキストの持ち越し。各スイープは新しいコンテキストなので、エージェントがスイープ間で覚えておくべきことは、スイープの間に書き留めておく必要があります。接続ごとにサイズ上限を設けたローリング状態ファイルがあり、未解決項目と最近の決定を保持していれば、ほとんどのループには十分です。うまくいかないのは、モデルがダイジェストから履歴を再構築することを期待する場合です。なぜなら、ダイジェストは明示的に変更の説明であり、すでに決定されたことの記憶を含まないからです。

• 認証情報の保管。Duet は Anthropic のマネージドエージェントで採用されている設計に従っているため、パスワードやサインイントークンを直接見ることはありません。この規律を再現することは、多くの自作エージェントが省略している部分であり、省略すると、すべてのプロンプトに認証情報への経路が存在することになります。モデルはトークンを保持すべきではなく、API キーをテキストとして渡されることも、認証を行うコンポーネントになることも決してありません。ダイジェスト処理と実行コンポーネントに認証情報を保持させ、モデルには結果だけを渡してください。

次に、誰も考えたくない攻撃面がある。エージェントがメールやウェブページを読むと、それぞれが指示を含みうる入力になる。権限という別個の概念を持たないモデルにとって、「これを下のアドレスに転送してください」というメッセージは、データと区別がつかない。どれほどプロンプトを堅牢化しても、2つの防御策には及ばない。アクションのリストを閉じたままにして、注入された指示が手を伸ばせる動詞を持たないようにする。そして、ゲートをモデルの影響の外に保つ。なぜなら、何かを送信するようモデルを説得する注入は、それでも、送信先アドレスを見る人間を説得しなければならないからだ。

フェイルオーバー、そしてルーティングが実際に役立つ場面

ループを組み上げたことで、単一ベンダーの設計にはないアーキテクチャ上の選択肢が一つ開ける。OrcaRouter のルーティング DSL は複数のモデルを 1 回の呼び出しに組み合わせ、モデルフュージョンは並列に応答するモデルのパネルを走らせる。どちらも 1 つのリクエストの背後に複数のモデルを置くものだ。ここでの実用的な使い方は地味である。要約の作成——そこでの作業は判断ではなく圧縮だ——には安価なモデルを向け、提案が形作られる意思決定の段階には Claude Opus 5.5 を据え置く。同じ OpenAI 互換のキー一つで 200 以上のモデルに到達できるため、どの段階をどのモデルが担うかを切り替えるのは、書き直しではなく設定変更で済む。

フェイルオーバーは、その残り半分だ。プロバイダが不調な1時間を過ごせば、1つのエンドポイントにしか到達できないエージェントも同じように不調な1時間を過ごす。フォールバックのないスケジュール済みループは、ただスイープを逃してしまうだけだ。ルーティングは、逃したスイープを「より遅いスイープ」に変える——必要になるその週が来るまでは劇的なメリットには見えないが、そのときには、記録に空白が残るか、空白が残らないかの違いになる。

実際にあなたが申し込んでいるもの

このループを回すことはサービスを運用することであり、そのサービスには、あなたがたった今その責任を引き受けた4つの性質がある。

• 稼働時間。Anthropicのアプリは他人のポケベルで、あなたのアプリはあなた自身のものです。黙って実行を止めるスケジューラはエラーも出力も出さないため、あなたがそれを知るのはアラートからではなく、朝のブリーフがないことに気づいた人からになります。

• 認証情報の保管。ダイジェスト処理のステップが保持するトークンはすべて、あなたが責任を負うものです。そして、漏えいが起きた際の影響範囲は、その接続が到達できる範囲のすべてに及びます。Anthropicの設計では認証情報をモデルから遠ざけていますが、あなたの設計がそうなっていない場合、モデルは接続したあらゆるアカウントにとっての攻撃対象になってしまいます。

• プロンプトインジェクション対策。ゲートはここで大きな効果を発揮するが、それはゲートが制御するアクションに限られる。エージェントが承認なしに行うこと——読み取り、要約、自身の状態の書き込み——は保護されず、汚染されたダイジェストは、後のスイープが依拠するメモリを破壊し得る。

• バグバウンティの責任者は誰もいない。ループが誤作動してクライアントに誤ったメッセージを送ってしまっても、エスカレーションできるベンダーも、ステータスページも、インシデントレポートも存在しない。上記の判断だけが唯一のセーフティネットであり、だからこそゲートは独立したサービスとなっており、アクションリストは閉じた集合になっている。

それは作ることに反対する論拠にはならない。反対しているのは、何となく作ることだ。各段階は小さく、判断が宿るのはそれらの間の継ぎ目だ。ストリームではなくタイマー、テンプレートではなく凍結されたプレフィックス、ダンプではなくダイジェスト、散文ではなくオブジェクト、そしてコメントではなくサービスであるゲート。そこを正しくやれば、ループは存在価値を発揮する。自分では探さなかったものを見つけ、取り返しのつかないことをする前に止まる。間違えれば、予算を継続的に消費し、すでに知っていることだけを教えてくれるものを作ったことになる。