Anthropicはコマース向けエージェントのアーキテクチャガイドを公開し、あわせてGitHub上でリファレンス実装anthropics/commerce-agentsをオープンソース化した。対象は購買エージェントと加盟店エージェント、そして小売・旅行・通信・チケット販売という4つのシナリオ向けのフレームワークと評価ツールだ。執筆はAli ShazalとMatthew Koenの両氏による。
冒頭の提案は、直感に反するほど素朴だ。モデルは1つ、標準的なエージェントループも1つ、ロングテールの能力はスキルに任せ、ツールは既存のバックエンドシステムを直接呼び出す。
サブエージェントよりスキルを優先
この文書は「サブエージェントではなくスキルを使う」をアーキテクチャ原則の第一項に据えている。理由は、サブエージェント構成における引き継ぎ処理は状態が欠落しやすく、品質が落ちるからだ。Anthropicによれば、自社での比較において、単一エージェント+スキルの組み合わせは、万能プロンプト1つで済ませる方式と、複数のサブエージェントに分割する方式の両方を、品質面で安定して上回ったという。
システムプロンプトとスキルの振り分けについては、頻度に基づくルールが示されている。全体のリクエストの3分の1以上で使われる指示はシステムプロンプトに書き、残りはスキルに入れる。ショッピングの場面では商品検索がほぼすべてのセッションで発生するため、プロンプト側に残す。
UIコンポーネントについても、モデルに独自タグを出力させるのではなく、ツールとして扱う。タグ出力方式は本番環境での信頼性がこれまで芳しくなく、モデルが出すタグの形式に強い制約をかけられないためだ。
キャッシュヒット率がレイテンシのコストを決める
パフォーマンスの章の核心はキャッシュに集中している。文書によれば、本番環境のキャッシュヒット率は90%から99%に達し、キャッシュ読み出しの価格は新規トークンの10分の1にすぎない。手法としては、リクエストを固定順序の3セグメントに分割する。全体セグメントにはシステムプロンプトとツール定義を、セッションセグメントにはユーザーコンテキストを、可変セグメントには現在の状態を置く。
ある落とし穴がはっきりと指摘されている。タイムスタンプや現在表示中のページをシステムプロンプトの先頭に置くと、リクエストのたびにキャッシュが無効化されてしまう。開発者が「現在のカート」を先頭に詰め込みがちなため、この誤りはEコマースの現場でよく見られる。文書はまた、Eコマースの応答は通常500から700出力トークン程度という目安も示している。
モデル選定の方法論は、評価セット全体をすべての候補モデル・すべての推論ティアで一通り実行し、品質指標をレイテンシとコストの予算とあわせて見る、というものだ。両者を切り離して評価しない。
安全性はプロンプトだけに頼れない
本番デプロイの章の立場は明確だ。プロンプトは安全な振る舞いの出発点にはなるが、Eコマースにおいては実行を担保する場所にはなり得ない。支払い、返金、価格変更といった操作は、すべてサーバー側でのステージングと承認を経る必要がある。文書が説明する仕組みはID単位のアクセス制御と呼ばれ、ハーネスがセッションごとに、サーバーがモデルに渡した各IDを記録する。書き込みや描画で受け入れられるのは、この記録にあるIDだけだ。モデルが自ら作り出した商品IDは、その時点で弾かれる。
記憶についても同様にモデルの外側に押し出されている。長期記憶は自社データベースに保存され、キー・値・カテゴリー・出典セッションという型付きレコードとして扱われる。別のスレッドまたはプロセスが非同期にセッションを読み取り、事実の追加・削除・更新を行う。この非同期抽出により、事実の再現率は13%向上したという。
評価については、複数ターンの対話をシミュレートする方式を捨て、スナップショット方式を採用している。テスト用の状態を構築し、ユーザーメッセージを1件追加して、結果を採点する。推奨される最初の規模は、ユーザーフローごとに50から100件のテストケースで、正例と負例をペアにし、文脈依存のリクエストと複数能力にまたがるリクエストの両方をカバーする。
Anthropicによれば、これらのエージェントはすでに本番環境で稼働しており、企業顧客の受注額はより大きくなっているという。具体的な顧客名は公開されていない。
参考資料：Anthropic公式ブログ、GitHubリポジトリanthropics/commerce-agents、CocoLoop。キャッシュヒット率、13%の再現率向上、500〜700出力トークンといった数値はいずれも同文書からの引用。