Anthropic、Claude を活用した効果的なコマースエージェントの設計指針を公開

過去1年間、私たちは小売業者、マーケットプレイス、旅行、エンターテインメント、通信事業者など、業界を横断する多くのチームと協力し、Claude を活用したコマースエージェントの構築に取り組んできました。

これらのエージェントはすでに本番環境で稼働しており、導入した企業顧客ではカート内の商品点数が増加し、販売者の業務効率も向上しています。共通しているのはシンプルなアーキテクチャです。スキル、ツール、そして堅牢な評価スイート（eval suite）を備えたエージェントループの中に Claude を配置する構成です。

この記事は、こうしたエージェントやその他の消費者向けサービスを提供するエージェントを開発するエンジニアおよび技術リーダーを対象としています。第1部では一度決めるべきアーキテクチャについて解説します。第2部ではレイテンシとコストについて取り上げます。そして第3部では、メモリ管理、安全性、評価（evals）、組織全体でのスケーリングといった本番環境における課題を扱います。

参考実装も用意しています。Claude 上でコマースエージェントを構築するためのブループリントです。これには、エンジニアチームが数日でコマースエージェントを稼働させるために必要なハッチング、パターン、ガードレールが含まれています。また、小売、旅行、通信、チケットプラットフォーム向けのショッピングエージェントとマーチャントエージェントの参考実装も提供しています。

anthropics/commerce-agents →

このガイドの構成は以下の通りです。

• 第1部：アーキテクチャコマースエージェントとは何か？
• サブエージェントではなくスキル
• システムプロンプトかスキルか：頻度で判断する
• エージェント用ツールのエンジニアリング
• UI コンポーネントもツールである

効果的なコマースエージェントの解剖学ガイド

• パート2：高速化と低コスト化タスク完了の遅延最小化
• 知覚される遅延
• プロンプトキャッシング
• モデルとその構成の選択

• パート3：本番環境での運用セッションを超えて持続するメモリ
• セーフティ：実行はハーン（枠組み）に依存する
• Evals：非決定論的システムのリリース
• 大規模組織でのリリース

01

アーキテクチャ

標準的なエージェントループ内で動作する単一のモデル。長尾タスクに対応するスキルと、既存のシステムを呼び出すツールを備えています。この設計は一度決めるべきものです。

コマースエージェントとは何か？

私たちは、オンラインカタログを介した売買を簡素化するエージェントを「コマースエージェント」と定義します。

消費者向けに機能するエージェントもあれば、企業向けに機能するエージェントもあります。前者は検索、比較、代替案の提示、注文の組み立てを行います。具体的には、小売りのカート、旅行の行程表、モバイルプランの変更、あるいはイベントの座席確保などが該当します。後者は売上に関する質問への回答、プロモーションやキャンペーンの実行、在庫と価格の管理を担当します。

中核となるアーキテクチャは、標準的なエージェントループ内のモデルです。これは、目標について推論し、文脈を探求し、ツールを通じて行動を実行し、スキルを通じて手順を学習し、不明点を明確にする質問を行い、結果を観察して目標が達成されるまでループを回ります。

会話のセグメント化を行う意図ルーターも、背後に配置されたドメイン固有のエージェント群も存在しません。

エンジニアリングの文脈

サブエージェントではなくスキルを

コマースエージェントは多様なカテゴリと意図にわたる広範な機能をカバーする必要がありますが、そのために各ドメインごとにサブエージェントを作成したくなる誘惑があります。

しかし実際には、これは最適解ではありません。なぜなら、コマースでの会話は複数の意図やターンにまたがる密結合されたセッションであり、相当量の共有コンテキストを必要とするからです。

サブエージェントアーキテクチャでは、オーケストレーターがカートや一時変更、ユーザーの好み、会話履歴を保持することになります。

しかし、サブエージェントへのハンドオフは状態の一部を失う操作となり、これがサブエージェントの回答品質、ひいては全体の回答品質に悪影響を及ぼすことがよくあります。さらに、各ハンドオフにはトークン数が数倍かかり、レイテンシも数秒追加されることになります。

また、ドメインはきれいに分離されないことも珍しくありません。返品フローでは注文履歴や現在のカート、商品カタログが必要になるため、ドメインごとのサブエージェント方式では、どこでもアクセス権限を重複させるか、タスクの途中でハンドオフする必要が生じます。

モデルが賢くなるにつれて、扱えるコンテキストの長さもスキル数もツール数も増え、今日の設定ルール背後にある制限は、モデル世代が進むごとに緩やかになっていきます。

代わりに、エージェントスキル を利用すれば、ドメインごとのモジュール性や文脈制御を同様に実現できながら、ハンドオフに伴うコスト（手戻りやコンテキストの断絶など）を負担することなく済みます。これは、スキル指令がすでに全履歴を保持しているメインのエージェントに直接読み込まれるためです。

複数の企業導入事例を比較した結果、スキルを活用した単一エージェントは、「何でも一つのプロンプトで処理する」設計や「サブエージェント」構成よりも、品質面で常に優れていました。さらに、タスクあたりのコストとレイテンシーが低くなるケースも少なくありませんでした。

ただし、オーケストレーターが特定のツールとして呼び出す必要がある場合、つまり狭い範囲に特化したり、独立したタスクであったりして、専用のコンテキストウィンドウを必要とするような場面では、サブエージェントの活用が有効です。

典型的な実装例として、「深層調査」を行うサブエージェントがあります。このサブエージェントは文書の検索や読解、コードの記述と実行、データモデルの探索を行い、行き詰まりに直面することもあります。すべての作業はこのサブエージェント内で完結し、オーケストレーターへ返されるのはコンパクトな回答のみです。

もう一つの例外は、すでに独自の目的特化型エージェントを保有しているドメインの場合です。例えば、薬局や金融サービスで、コンプライアンス要件に対応した専用エージェントが稼働している場合、そのエージェントにタスクを委譲（ハンドオフ）するのが適切です。この場合、エージェント自身がユーザーと直接対話し、ループ処理を通じてタスク完了までを担当します。

会話の所有権をどう扱うかが重要な分岐点です。ハンドオフを行えば、ドメインエージェントがユーザーの対話相手となります。一方、委譲方式ではオーケストレーターが主導権を持ち続け、ドメインエージェントを1回のターン内で出入りさせます。この方式は、やり取りを重ねるたびに性能が低下する傾向があります。

システムプロンプトかスキルか：頻度で判断する

指示セットをシステムプロンプトに含めるか、別個のスキルとして管理するかを決める際の主要な基準は、エージェントがその指示をどの程度の頻度で必要とするかです。スキルの読み込みにはモデルのターン（処理サイクル）が1回消費されるため、ほとんどのターンで必要な情報はシステムプロンプトに記述するのが一般的です。

ただし、これはトラフィックの分布状況や、評価結果から得られるエージェントの振る舞いにも依存します。一つの目安として、ローンチ前に想定されていたか、あるいは本番環境で観測されたかを問わず、全トラフィックの3 分の1 以上に関連する情報はシステムプロンプトに含め、それ以外はスキルとして管理するのが良い出発点となります。

ユーザーがどのページから来たかなど、すでに入手可能なシグナルからスキルの内容を予測できる場合は、最初のモデル呼び出し前にハッチ（制御枠）から情報を注入し、スキル読み込みによる追加のターンを省略することを推奨します。

安全性や法的ルール、ブランド制約といった重要な指示、およびアレルギー情報など重要なユーザー事実については、常にシステムプロンプトに記述してください。

コマースエージェントにおいては、ほぼすべてのセッションで利用される製品検索はプロンプト内に配置し、長尾の機能群をスキルとして扱うのが適切です。

Anthropic の 参考実装 において、ショッピングエージェントのプロンプトには、基盤となる意味（グラウンディング）、カートや決済のロジック、表示ルールが組み込まれています。残りの機能は以下のスキルで補完されます：検索・発見、購入調査、目標計画、カスタマーケア、そして記憶によるパーソナライズです。

マーチャントエージェントも同様に機能領域ごとに役割を分担します。パフォーマンス分析、カタログ出品、在庫管理、価格設定とプロモーション、マーケティングキャンペーンがそれぞれのスキルとして定義され、1 つのドメインに 1 つのスキルという構成になっています。

プロンプト内での定義

*ショッピングエージェント*: 基盤となる意味、カート・決済ロジック、表示ルール、製品検索

ショッピングスキルの詳細

*ロングテール対応*

search-discovery · purchase-research · planning-goals · customer-care · memory-personalization

マーチャントスキルの詳細

*各業務ドメインに 1 つずつ*

performance-insights · catalog-listings · inventory-operations · pricing-promotions · marketing-campaigns

エンジニアリングエージェントのツール設計

「エージェント向けに効果的なツールを設計する」という過去の投稿で、ツールの設計原則について一般的な解説を行っています。EC 領域において特に重要視されたのは以下の 2 点です。

コアシステムとロジックの上にエージェント用ツールを構築する

EC 企業にはすでに、検索・ランキング機能、カート、ユーザー設定やプロフィール管理、在庫システム、プロモーションおよびキャンペーンエンジン、販売分析など、多数の既存システムが用意されています。これらは長年にわたり調整されたロジックを内包しており、AI モデルでは決して捉えきれない重要なシグナルも処理しています。

エージェントのツールは、既存システムを再実装するのではなく、それらを呼び出すべきです。ツールの境界線とは、ロジックがそこで終わり、モデルの判断が引き継がれる地点のことです。

例えば、search_products を呼び出した場合、その結果はすでにソートされた状態で返ってくる必要があります。エージェントの役割は、どの結果がユーザーの目的に合致するかを判断し、何件表示するか、どのように提示するかを決めることにあります。

ツールからの結果は文脈（コンテキスト）です。

モデルが推論に使用するフィールドのみを返し、それ以外は削除してください。検索結果の各行に含まれる画像 URL は、よく問題となる要素の一つです。

必要に応じて、ツールの内部で生レスポンスを整形します。データから次のステップが明らかな場合を除き、その情報を追加することも含まれます。

これは特にエラーシナリオにおいて重要です。モデルはエラーコードよりも指示文から恩恵を受けます。例えば、汎用的な 403 エラーの代わりに、「可用性を確認する際は製品 ID を含めてください」といった具体的なエラー指示を追加します。

UI コンポーネントもツールである

ほとんどのコマースエージェントのレスポンスは文章ではなく、プロダクトカルーセル、旅行計画、座席マップ、チャートなどの UI コンポーネントです。つまり、エージェントはテキストを生成するのではなく、スキーマを出力する必要があります。

チームによっては、モデルにカスタムタグを生成させるようプロンプトし、クライアント側でパースすることから始めることがあります。しかし、対象となる画面が拡大するとこの手法は機能しなくなります。その理由は以下の通りです：

このモデルは、ツール呼び出しに対しては十分に訓練されていますが、マークアップに対する訓練はそれほどではありません。そのため、ネストされたコンポーネントが増えるほど信頼性は低下します。プロンプトだけでデータが適切に構造化されていることを保証することはできません。

タグの定義はシステムプロンプト内に存在するため、新しいコンポーネントを追加するたびにコンテキストサイズが大きくなり、編集を行うとプロンプト内の他の部分で問題が発生するリスクがあります。

過去の会話履歴は、パーサーのみが読める形式で保存されるため、履歴を読み込む際には、クライアント側で生のメッセージを解析するか、モデル API のネイティブ形式ではない別の形式でコピーを保持する必要があります。

これまでの成功パターンは、各 UI コンポーネントをツールとして扱うことです。モデルは present_products や present_itinerary、present_plan_comparison といった関数を型付き引数とともに呼び出し、サーバー側でその呼び出しを検証・拡張してイベントを発行し、クライアント側がそれを受け取ってレンダリングします。

コンポーネントがツール呼び出しとして扱われるため、ネイティブ形式のメッセージ配列にそのまま含まれています。過去の会話を再読み込みする際にも、再度解析する必要はありません。プレゼンテーションツールの契約仕様は、以下の図および リファレンスリポジトリ で確認できます。

ただし、ストリーミングの粒度についてはトレードオフが生じます。ツール呼び出しの各トップレベル引数はサーバー側で検証のためにバッファリングされるため、プレゼンテーションツールのサブコンポーネントは、ストリーミングを有効にしていても段階的に到着します。これが体感遅延に影響を与えます。

トークンレベルのストリームを取得するには、ツール定義に eager_input_streaming: true を設定します。これによりバッファリングがスキップされ、サーバー側のスキーマ保証も無効化されます。

評価結果では、Claude Sonnet クラス以上のモデルにおいてスキーマ違反は極めて稀ですが、万一発生した場合に備えて呼び出しをリトライ処理で囲むことを推奨します。

プレゼンテーションツールを使用すると、エージェントは画面に表示されている内容を記録として取得できます。顧客が「最初のホテル」や「左側の3番目」といった表現を使った場合、そのレイアウト情報はメッセージ配列に含まれ、直前のプレゼンテーション呼び出しの引数に格納されます。

これを正しく機能させるには、引数がレンダリングされたレイアウトを反映している必要があります。つまり、クライアント側で再配置される単なるフラットリストではなく、UI の構造に合わせて順序付きの行やカルーセルとして構造化して記述してください。

02

高速化とコスト削減を実現する

遅延対策は「実測値」と「体感値」の両面から攻め、キャッシュでコストを賄うのが基本です。いずれの場合も、そこに知能リソースを浪費してはいけません。

EC 領域では遅延が重要視されますが、特に消費者向けインターフェースでは許容範囲が狭いのが実情です。しかし、エージェント型サービスにおいて一貫して保持率、エンゲージメント、カート内商品数といった指標を向上させる要因として最も重要なのは、結果の質です。

回答が適切だったか、タスクが実際に完了したかが、わずかな遅延短縮よりもこれらの指標に与える影響は圧倒的に大きいです。

したがって、遅延対策は二つの側面から行います。まず、優れたエンジニアリングによってエンドツーエンドの遅延を最小化し、同時に体感遅延を下げる工夫を組み合わせます。エージェントが作業している様子を見守る時間は、ユーザーにとっては「進行中」の証拠として認識されるためです。

すべてのユーザーには、許容できる応答時間の上限（レイテンシー・バジェット）が存在します。以下のテクニックは、その範囲内でエージェントを動作させるための手法であり、無理に知能を投入して対応するものではありません。

タスク完了までの遅延の最小化

タスク完了までの遅延とは、モデルの応答ターン数全体を通じて、「最後のトークンが生成されるまでの時間」と「ツールの処理時間」を合計したものです。これに対応するには、主に3 つのレバー（調整要素）があります。

1. ターン数を減らす
2. ツール処理を高速化する
3. トークンの生成速度を上げる

これらの要素は互いに競合することもあるため、特定の項目だけを最適化するのではなく、全体としての合計値を最小化することが重要です。

ターン数を減らす

必要なコンテキストを事前に読み込み、モデルの知能度を高め、独立したツール呼び出しを並列実行させることで実現します。

ツール処理を高速化する

ツールのバックエンド自体を最適化し、引数の準備が整い次第、積極的に（eagerly）ツールを実行するようにします。

トークン生成速度を上げる

評価スイート（eval suite）全体をスキャンしてモデルとその設定を選定します。

ターン数を減らすための具体的手法

クエリの複雑さはターン数に直結しますが、これは通常、開発者が直接制御できない要因です。一方、モデルの知能度と関連するコンテキストの充実度は、エージェントがより少ないターンでタスクを完了させるために有効です。

この分野における主な知見は以下の通りです：

まず、関連する文脈を事前に読み込むようにしてください。ユーザーが商品ページからアシスタントを開いた場合や、出店者がキャンペーンダッシュボードから開いた場合は、そのページのデータをセッションコンテキストに含めてください。会話はそのページに関するものである可能性が高く、文脈に基づいて回答すれば追加のターン数を消費することはありません。

モデルの知能を高めることも重要です。賢いモデルを使えば、エージェントがより効率的に計画を立ててツール呼び出しを実行できるため、タスク完了までの全体のターン数を減らせます。これにより、トークン生成速度が遅くなるデメリットを上回るメリットが生まれるケースが多いです。クエリが複雑な場合や、生産環境でタスクあたり 5 ターンを超える傾向がある場合は、むしろ高速なモデルの方が賢い選択となる場合があります。どちらを選ぶべきかはトラフィック状況に依存するため、「モデルの選び方」で説明する通り、スweep（比較検証）によって決定してください。

モデルには独立したツールを並列実行させるように指示してください。コマースユースケースでは、複数の商品検索や多数のポリシー文書の照会、あるいは複数の販売データソースからのレコード取得など、多くの操作を並行して行う必要があります。ツールを並列に呼び出すことで、複数の独立したクエリが追加のターン数を消費するのを防げます。1 つのターン内でモデルが複数のツールを呼び出し、その結果をツール結果の配列として 1 つのユーザーメッセージとして返すようプロンプトしてください（詳細は 並列ツール使用ドキュメント を参照）。

より高速なツール

• ツールのバックエンド自体を最適化する。場合によっては、ツールが本来複数の並列処理を行う必要があります。例えば、「今日の売上スナップショットを取得する」というクエリを実行する商取引エージェントは、販売データ、在庫状況、キャンペーンステータスをそれぞれ独立した 3 つの呼び出しで取得します。しかしよく見られるのは、ツールの境界部分が欠落しているバックエンドロジックをつなぎ合わせる場所になっているケースです。例えば、利用可能チェックでは、SKU のカタログ照会、店舗ごとの在庫サービスへの問い合わせ、納期カットオフの確認を行う fulfillment サービスへのアクセスを行い、その後、置換ルールや受け取り eligibility をツール内のコードで適用してから回答を返します。このようにツールにドメイン知識が過剰に詰め込まれると、ルール変更に対応できなくなり、本来は上位システムに置くべきロジックまで担わされることになります。もしツール内でそのようなロジックを書いていることに気づいたら、解決策は「その問いに対する答え」を提供するバックエンドエンドポイントを 1 つ用意し、エージェントがそのツールから呼び出すようにすることです。
• ツールを積極的に実行させる。ツールの引数は他のトークンと同様にモデルからストリーミングされるため、ハーン（実行環境）は各ツールの引数が揃い次第即座に呼び出しを実行し、モデルがまだ他の並列ツールやコンテンツブロックをストリーミングしている最中でも処理を進めることができます。これにより、数秒かかっていた待ち時間が数百ミリ秒に短縮されるケースも確認されています。Claude Agent SDK ではデフォルトでこの機能が実装されています。最大限のレイテンシ削減を実現するには、モデルに対して最も遅い呼び出しを最初に出力するようプロンプトで指示してください。

知覚される遅延

知覚される遅延とは、ユーザーが画面に何らかの反応を感じるまでの時間のことです。これは特に一般消費者向けのユースケースにおいて極めて重要で、取引における摩擦はチェックアウト率や収益に直結します。モデル自体を変更しなくても、以下の 2 つの手法でこの時間を短縮できます。

• 構成要素が形成されるままストリーミングする。

レンダリングされたコマース応答には通常 500〜700 トークンが含まれており、ストリーミングを行わない場合、ユーザーはローディングスピナーを 5 秒以上見続けることになります。プレゼンテーションツールの各パラメータがストリーミングされるたびにクライアントへ送信し、ページを段階的にレンダリングしましょう。

• 作業過程を見せる。

エージェントが文脈情報を収集している間、各ステップについて平易な言葉で短い進行状況を表示します（例："水の近くのホテルを検索中"）。これはツールの既存引数（商品検索のクエリなど）から作成するか、モデルにその行を書かせるよう促す user_facing_message パラメータを持つ追加ツールを追加することで実現できます。

プロンプトキャッシング

プロンプトキャッシングは、コスト削減において最も効果的な手段の一つであり、コマース（EC）のトラフィックには特に適しています。キャッシュされた入力トークンの読み取りコストは新規のものより 10 分の 1 で済み、キャッシュへの書き込みには約 1.25 倍のプレミアムがかかりますが、キャッシュされたプレフィックスは 2 回目の利用でそのコストを回収できます。

大量のトラフィックを扱う顧客向けアプリケーションでは、最も安価なデフォルト設定である「5 分間のキャッシュ有効期限」を活用することで、極めて高いキャッシュヒット率を実現する絶好の機会があります。

これまで見てきた最適なコマース環境では、キャッシュヒット率が 90–99% に達しており、設計段階からこの範囲を目標に据えるべきです。経験則として、トークン数が約 10 万の場合、キャッシュされたトークンの読み取り速度は新規のものより 1.5〜2 倍速く、トークン数が増えるほどほぼ線形にスケーリングすることがわかっています。

キャッシングはプレフィックスベースで行われます。リクエストは、以前のものと異なる最初のバイトに至るまでキャッシュから読み込まれるため、重要なのはコンテキストに含まれる内容だけでなく、その順序もまた重要です。リクエストを頻繁に変化する度合いに応じて 3 つのセグメントに分割して考えるとわかりやすいでしょう：

システムプロンプトとツール定義の大半は「グローバル」領域に属し、すべてのセッションで共通です。これは最も効果的なキャッシュとなり、大規模運用では期限切れになることはまずありません。ターンやセッションを跨いでバイト単位で同一性を保ち、その末尾にキャッシュブレイクポイントを設けてください。

次に「セッション」領域は、ユーザーごとの文脈と会話履歴を含みます。セッション間では異なりますが、1 つのセッション内では安定しています。このセグメントはグローバル領域の後に配置します。

最後に「揮発性」データです。現在時刻や現在のページなど、セッション内で変化する情報はすべてここに含めます。リクエストの末尾に配置し、最新ユーザーのターン内にタグ付きブロックとして記述するか、会話中のシステムメッセージ をサポートするモデルでは、メッセージ配列の末尾にシステムロールメッセージとして追加します。最も多いミスは、タイムスタンプや現在のページをシステムプロンプトの先頭に配置してしまうことで、これによりすべてのリクエストでキャッシュが静かに無効化されてしまいます。

実装にあたっては、以下の 2 つのポイントを覚えておいてください。まず、スキルはシステムプロンプトに追加するのではなく、ツール結果として読み込む必要があります。これにより、スキルの本体が会話プレフィックスに配置され、キャッシュの対象となります。

次に、各ターンでブレークポイントを前方へシフトしてください。リクエストには許容されるブレークポイント数に制限があるため、最新のものを各ユーザーのターンの末尾へ移動させます。その後、検索応答などの長いツール結果を含む蓄積履歴をキャッシュから読み取ります。

モデルと設定の選択

モデルサイズとエフォート設定 は、知能性とレイテンシ・コストとのトレードオフという点で同じです。両方とも測定に基づいて選択してください。

効果的なコマースエージェントの設計指針

評価指標と許容下限を明確に定義する。

自社のビジネスで重視している品質指標（タスク完了率、回答の関連性、根拠のある精度など）を選定し、これらを下回ってはいけない評価スコアの閾値を設定します。さらに、p50 および p99 のレイテンシとコストに関する予算枠も事前に決めておきましょう。

包括的なモデル比較を実施する。

検討対象となるすべてのモデルと、それぞれの努力レベルに対して評価スイート全体を実行してください。商取引エージェントは分析タスクが中心となるため Opus から始め、レイテンシが重視される消費者向けエージェントには Sonnet を推奨します。すでに本番トラフィックがある場合は、実際のクエリミックスを重み付けして結果を評価しましょう。最終的には数値に委ねます。カートへの流入を促すタスクにおいて、Opus 5 の性能向上がコスト差に見合う場合もあれば、そうでないケースもあります。

結果を慎重に読み解く。

チームが意外に思うことが主に二つあります。一つ目は、プロンプトは特定のモデル向けに調整されているため、ある一つのモデルで評価した際、そのモデル用に設計されていない他のモデルでは期待通りの性能が出ないことです。小規模なモデルは、現在のモデルなら推測して処理できる指示を明示的に必要とする一方、大規模なモデルは小規模モデルが無視していた指示も厳密に実行します。候補から除外する前に、各候補の失敗事例に対して数回の反復調整を行うのは、コストのかからない有効なステップです。

二つ目は、より賢明な設定の方が、トークン生成速度が遅いにもかかわらずレイテンシ（特に p90 や p99）で優位になるケースがあるという点です。これは、複雑なリクエストにおいてツール呼び出しの計画が最適化され、必要なラウンド数が減るためです。

タスク完了ごとのコストを、モデル呼び出しごとのコストではなく測定すべきです。より安価なモデルでも、必要な対話ターン数が増えたり失敗率が高かったりすれば、結果として安くはなりません。結果の品質が十分で、1 タスクあたりの経済性とレイテンシ要件を満たすなら、知能（インテリジェンス）を優先してください。採用と継続利用を牽引するのは品質であり、モデルの進化に合わせて今後 6 ヶ月間の拡張余地も確保できます。

03

本番環境での運用

メモリ管理、安全性、評価（evals）、そして組織全体でのスケーリング：これらがエージェントを生産環境に送り込み、定着させる鍵となります。

最後に、エージェントが生産環境を生き残り、そこで安定稼働し続けるために必要な要素について解説します。それはすなわち、メモリ管理、安全性、評価、および組織横断的な運用のスケーラビリティです。

セッションを超えて持続するメモリ

顧客との関係性や対話は重要です。メモリ機能があれば、エージェントは前回の会話の続きから再開でき、ゼロから始めなくて済みます。3 月にナッツアレルギーを明言した顧客が、6 月になってもそれを繰り返す必要はありませんし、毎週月曜日に同じ 3 つのキャンペーンを確認する販売者も、毎回その名前を挙げ直す手間がかかりません。セッションを超えて保持すべき事実である「長期メモリ」は、構築すべきシステムであり、以下の 3 つの部分で構成されます。

1. 事実の保存方法
2. 書き込み方
3. 読み出し方

メモリの保存場所

メモリはモデルの中に置くのではなく、自社のシステム内に実装すべきです。

プロフィールが小さく、エージェントが唯一の閲覧者である場合のみ、フラットな Markdown プロフィールが機能します。しかし、実運用されているコマースエージェントの多くはこれを越える必要に迫られ、実際に推奨されるのはすでに運用しているデータベースです。

ファクトとは、小さな型付きレコードのことです。キー（shoe_size、default_store、preferred_report_cadence など）、短い値、カテゴリ、そしてそのデータが取得されたセッションから構成されます。一部のキーは事前に決定され全ユーザーに割り当てられますが、残りのキーは抽出器によって発見されます。データベースはストアが成長してもクエリ可能であり、特定の属性に基づいて決定的な動作を構築でき、既存のユーザーデータとも結合できます。

商人向けエージェントでは、アカウント単位ではなく個人単位でメモリを管理してください。商人のログイン情報はオペレーター間で共有されることが多いため、各オペレーターに個別のプロファイルが必要となり、読み取り操作はそのオペレーターの権限を尊重する必要があります。例えば、店舗マネージャーのエージェントが地区マネージャーが設定した事実を参照してはなりません。

コマース領域において、エージェントのメモリには個人データが含まれます。記憶すべきファクトこそが、最も規制の厳しいデータであることが多く、管轄区域ごとのルールも異なります。メモリ管理は単なるストレージの問題ではなく、データ処理設計の問題として捉えるべきです。実務的には、以下の 4 つの点が重要になります：

• 保持するメモリの種類を決定し、そのルールを実装する。プロンプト内での指定だけでなく、保存処理のパス全体で検証器（バリデーター）を導入し、すべての保存がそのルールに従うように強制してください。
• ユーザーが保存された情報を確認・修正・削除できる仕組みを提供する。アカウント削除やデータ開示リクエストのフローに、データの削除機能も組み込んでください。
• 保持期間を設定する。数年前の好みはすでに陳腐化している可能性が高いため、保持期間を設けることでメモリの事実関係を最新の状態に保つことができます。
• メモリ機能はデプロイ単位でオンオフできるスイッチとする。これにより、これらの義務を負えない地域でも、メモリ機能を無効にして運用することが可能になります。

メモリの書き込みについて

メモリの書き込みは非同期で行います。会話の各ターン終了時、あるいは長いセッションでは数ターンごとに、別スレッドまたは別プロセスで動作するエージェントが会話を参照し、ストア内の事実を作成・更新・削除します。これにより、セッションが進んでもエージェント自身のワーキングコンテキストを維持できます。

このアプローチは会話のレイテンシに何ら悪影響を与えず、社内で行ったコマースメモリ評価スイートでは、事実の想起率が 13% 向上しました。

対照的に、エージェントがツールを呼び出して事実を保存する方式は、レイテンシに敏感なコマースエージェントには不適切です。ユーザーが待つターン内で保存処理が行われるため、ストア全体をコンテキストに含めない限り、更新や重複排除のためにまず読み取りが必要となり、追加のラウンドトリップが発生します。

さらに、この方法は各ターンでエージェントに新たな判断を強いることになります。評価結果では、この注意散漫が「メモリの見落とし」という形で現れました。

抽出器を独立させることで、より精密なプロンプトが可能になります。この抽出器はユーザーとアシスタントのテキストのみを読み取り、ツールの結果は一切読みません。そのため、商品説明やレビューがユーザーに関する事実として誤って認識されることを防げます。

そのプロンプトでは、「何が事実か」を明確に定義しています。例えば「明記されたサイズ」「食事制限」「配送先への希望」「販売者の一般的な表示内容」などは事実とみなされます。一方、商品リストに含まれる情報や一時的な詳細情報は事実として扱いません。

メモリの読み込み

メモリは 3 つのレイヤーで読み込みます。

常にコンテキストに含まれるもの

各処理ターンごとに、小さな固定セットの事実がコンテキストに追加されます。これはほぼすべてのリクエストに必要な情報です。例えば、ショッピングユーザーのデフォルトストアや配送先への希望、オペレーターの店舗と役割などが該当します。

1 つのターンごとに事前取得されるもの

現在のリクエストに関連する事実は、スキルの事前読み込みと同じ信号源から、各ターンごとに事前に取得されます。例えば、靴の検索ではサイズやブランドの好みが、キャンペーンに関する質問にはオペレーターが通常使用する指標が取得されます。

ルックアップツールの背後にあるもの

それ以外の情報はすべて、ルックアップツールを介してアクセスします。

メモリはユーザーごとのコンテキストとして管理されるため、すべての情報がグローバルキャッシュのブレークポイントより下のセッションセグメントに格納されます。

安全性：実行環境で厳格に管理する

安全な動作の起点はプロンプトですが、EC 領域ではここで安全性を担保することはできません。失敗すれば金銭的損失となり、多くの場合取り返しがつかないからです。プロンプト上のルールは、1 つのインジェクション攻撃や不適切なサンプルで簡単に迂回されてしまいます。

そのため、以下のすべてのルールはコード上で実装され、消費者側と販売者側の両方のエージェントで適用されます。また、定義は一度行うだけで済み、あらゆる実行環境で共通して利用可能です。

モデルの段階：人間またはポリシーが最終判断を下す

どのモデルによるツール呼び出しも、直接お金の移動やビジネスの変更を行うことはありません。注文確定、決済、返金、価格変更、キャンペーン開始などはすべて、モデルではなく「ハルネス（実行環境）」が制御するアクションとして完了します。

消費者側ではこの仕組みが構造的に組み込まれています。チェックアウトツールはカートを表示し、「注文を確定」するボタンを提供しますが、エージェントが呼び出すバックエンドインターフェースには、課金機能そのものが存在しません。

販売者側では、すべての書き込み用ツールがサーバー生成 ID を付与した「ステージ化された変更」を作成します。そして apply_change（変更適用）が成功するのは、その ID が実際の画面を通じて承認された場合だけです。具体的には、オペレーターポータルのボタン、CLI での確認、または Managed Agents で実行される際のプラットフォーム固有のツール承認プロンプトなどです。

ガードレールは、変更をステージ化した時点の制限ではなく、適用時の現在の制限に対して再チェックされます。どのような画面を経由するにせよ、基本構造は同じです。「最も危険なアクション」はモデルが提案することであり、その承認フローは、貴社がすでにその種の変更に対して採用している「作成者 - 確認者（maker-checker）」のワークフローを踏襲します。

サーバー発行のIDのみが書き込みとレンダリングで許可される

ハレスは、サーバーからモデルに渡されたすべてのIDをセッションごとに記録しており、この記録こそが、書き込みやレンダリングが受け付ける唯一の鍵となります。

カート機能は、そのセッションに対してサーバーが返した商品IDのみを受け付けます。また、マーチャントツールも、エージェントが実際に読み込んだリストやキャンペーンIDのみを受け付けます。他の経路で入手されたID、つまりモデルが作り出したもの（ハルシネーション）、ユーザーが貼り付けたもの、レビューに仕込まれたものは、バックエンドがそれを見る前に拒否されます。

このルールはUIにも適用されます。プレゼンテーションツールはIDを受け取り、サーバー側が商品、注文、変更のレコードを直接埋め込むため、カードに表示されるのはサーバー自身が埋めたレコードのみとなります。

委任されたサブエージェントについても同様です。マーチャント分析用のサブエージェントはデータを読み取りますが、エージェントが書き込み可能なIDのセットに追加することはありません。

手数料や開示事項、その他規制対象となるコンテンツについては、モデルが開示すべき商品を選択しますが、実際の文章はすべて承認済みのコピーからサーバーが提供します。同じく、手数料項目もマーチャントエージェントの保護リストに含まれているため、双方がそれを変更したり言い換えたりすることはできず、評価（evals）ではレンダリングされた文字列をバイト単位で厳密にチェックします。

上限付きトランザクションは繰り返しリクエストでも維持される

多くのコマース画面では、チケットの割り当てやプロモーション価格設定、不正防止のために、1ユーザーが購入できるアイテム数に上限を設けています。しかし、エージェントは人間がボタンをクリックする際とは異なる方法で、再試行や言い換え、並列処理を行う可能性があります。

したがって、この制限は書き込み後と同じように行単位で適用されます。そのため、「さらに 2 つ追加」という操作を繰り返しても制限を超えて積み上がることはなく、1 つのセッションにおけるカートへの書き込みは直列化されるため、単一のターン内で並行して実行されるツール呼び出しが組み合わされても制限値を超えることはありません。

価格変動、割引の深さ、在庫補充量、キャンペーン予算に対する上限や、変更が許されない保護フィールドの一覧などに対して、商取引側の更新内容が同様の方法でチェックされます。このルールは一般化され、「リクエストそのもの」ではなく「結果として生じる状態」に対してすべての制限を適用し、セッションごとに書き込みを直列化するものです。

サードパーティ製コンテンツのサニタイズ

EC 領域では、コンテキストの多くがあなた自身ではなく、出品者やレビューヤー、競合他社などによって作成されたものです。そのため、バックエンドからの読み取りは信頼できない入力とみなされ、必ずサニタイザーを経由します。

リスト情報、レビュー、ポリシー、出品者からのメッセージ、保存されたメモリなど、サードパーティが作成したすべてのツール結果は、モデルがそれらを確認する前にサニタイズされ、固定ラベル付きのフェンスで囲われます。

サニタイザーは制御文字や双方向文字を除去し、フェンスマーカーを模倣する要素を排除します。また、会話のターンやツール呼び出しを模したテキストを無力化し、サイズ制限も設けています。これにより、悪意のあるリストがシステムに成りすましたり、コンテキストを埋め尽くしたりするのを防ぎます。

プロンプトには、この契約のもう一つの側面が含まれています。「フェンスで囲まれたテキスト」は報告対象の素材であり、決して実行すべきアクションではありません。

評価：非決定論的システムのリリース

プロンプトのわずかな変更やツールの追加など、些細な変化がエージェントの挙動に予測不能な影響を与える可能性があります。また、実際にリリースした変更が問題を引き起こす原因とは限らないケースも少なくありません。こうしたリスクをデプロイ前に発見するのが「評価（evals）」です。

Anthropic の以前のブログ記事 AI エージェントの評価 では、評価の一般的な実践方法について解説しています。ここでは、特に EC（電子商取引）エージェントに特化した具体的な手法について説明します。

会話そのものではなく、状態のスナップショットを評価する

モデルの API はステートレス（無記憶性）であるため、エージェントが出力する内容は「システムプロンプト」「利用可能なツール」「メッセージ配列」の組み合わせによって決定されます。つまり、EC 会話で到達しうるあらゆる状態は、直接構築することが可能です。

したがって、評価ケースを作成するには、まずテスト対象の状態を構築し、そこにテスト用のユーザーメッセージを追加して、そこからエージェントを実行させます。

その結果を評価する際は、「最終的な状態」と「レンダリングされたレスポンス（最後の書き込み操作に含まれる引数を含む）」に焦点を当ててください。多くの場合、エージェントがどのようにしてその状態に至ったかという「経路」の評価は推奨されません。なぜなら、そのようなテストケースは脆く、柔軟性に欠けるからです。

シミュレーションユーザー評価、つまりもう一つのモデルがユーザーを演じ、判事が会話全体に採点を行う手法は、測定ツールとしては不十分です。非決定性のシステム同士が相互作用する場合、サンプル数を増やす必要があり、試行あたりのコストも高くなり、判断が難しくなり、原因の特定が困難な失敗が発生します。これらはカバレッジのギャップを発見したり、エージェント全体の雰囲気をチェックする目的には有用ですが、ケースを見つけるために使い、その後は各ケースをスナップショットとして記述するようにしましょう。

困難な条件下での振る舞いを評価する

多くのチームは、注入された状態を適切にテストできていません。ケースは単なるタスクではなく、失敗の前提条件を記述すべきです。例えば、複数のツール呼び出しを伴う最初のターンで混雑した後や、セッションの前半で矛盾が生じた後にのみ現れる振る舞いがある場合、クリーンな状態から始まるケースはあらゆる設定で通過してしまい、意味のあるデータを提供しません。

私たちは多くの評価スイートがこうしたクリーン状態のケースに偏っていることを観察しています。そのため、あなたのスイートにも、長く複雑で矛盾を含む履歴から始まるケースを一定割合含めるようにしてください。

コマースエージェントの評価タイプを網羅する

効果的な評価には、望ましい振る舞いと望ましくない振る舞いの両方をテストする必要があります。

ポジティブなケース一つに対して、ネガティブな対応ケースを作成してください。「拒否すべき」ことには「提供すべき」ことを、「確認すべき」ことには「即座に実行すべき」ことを対応させます。ネガティブケースの欠如は、私たちがスイートで最もよく見つけるギャップです。

以下の点を評価対象とします：

トラフィックの大部分を占めるコアなリクエストでは、ここで失敗するとセッション全体に影響が出るため注意が必要です。これには単純な検索、複数の制約条件を含むリクエスト、商品やプランに関する質問、そして複数の意図を持つメッセージが含まれます。質問に対しては、価格・在庫状況・属性情報がすべて返されたデータに遡って検証可能であることを確認し、データが存在しない場合は推測で答えるのではなく「データがありません」と明確に伝えるようチェックしてください。

文脈依存型リクエストには、画面に表示されている内容への言及、以前の会話から引き継がれた制約条件、既存のカートに対する書き込み操作などが該当します。記憶機能の評価もこのカテゴリに含まれます。記憶の抽出・取得が行われ、それが回答に実際に反映されたかを確認してください。

安全性とブランド関連ケースでは、失敗すると金銭的損失や信頼失墜につながるため厳格な対応が必要です。これには試行されるプロンプトインジェクション攻撃、他ユーザーデータの不正読み取りの試み、規制対象となる言語の使用などが含まれます。特に規制言語はバイト単位で厳密にチェックします。インジェクションは2つのケースに分けて評価します。1 つ目は「ユーザー作成型インジェクション」で、指示がユーザー自身のメッセージから来ている場合です。2 つ目は「データプレーン型インジェクション」で、商品名・レビュー・ツール結果として取得されるウェブスニペットなどに仕込まれた場合です。

インターフェース評価では、適切なコンポーネントが正しくレンダリングされているか、アイテム数の上限制限が守られているか、ユーザー向けテキストに内部識別子が含まれていないかを検証します。タイムアウトや空の結果に対する処理もテスト対象に含まれます。

• 複数の能力にまたがるリクエストへの対応

オペレーターが「この商品を 15% 値引きした場合、需要を賄えるだけの在庫はあるか？」と尋ねた場合、それは価格設定に関する質問であると同時に在庫管理に関する質問でもあります。正解は、在庫予測を添えた値引きシミュレーションを示すものですが、誤った回答の多くは片方しか対応していません。各能力ごとに評価基準を作成しても、こうしたケースは見逃されてしまいます。なぜなら、それぞれの評価項目は自分の担当範囲しかチェックしないからです。

隣り合う複数の能力を組み合わせて扱うリクエストについては、専用のテストケースを用意し、回答の両側面を同時に採点する必要があります。

専門家の協力を得て、実際の事例から評価基準を作成する

製品、法務、マーチャント運営、カスタマーサポート、カテゴリ管理など、現場で失敗を目撃している専門家と連携してテストケースを設計しましょう。実際に起きた失敗こそが最良の評価基準を生み出します。ユーザーフローごとに 50〜100 の評価ケースを用意するのが、まず始めに目指すべき目標です。

前述したように、多様なケースを用意することが重要です。本番環境のログは、特に難易度の高いケースを見つけるための優れた情報源となります。コード生成エージェントは、追加のテストケースや敵対的なバリエーションを自動生成する能力にも優れています。参照リポジトリ には、推奨アプローチに基づいて評価作成機能を備えた Claude Code プラグインも含まれています。

大規模組織での実装

EC エンタープライズにおいて、エージェントは複数のエンジニアリングチームによって構築されます。検索、チェックアウト、価格設定、マーケティング技術、カスタマーケア、カタログプラットフォームなど、各チームがそれぞれ異なるシステムを管理しており、それらはすべてエージェントの依存関係にあります。さらに、各チームは独自の開発サイクルでリリースを行い、ツールやスキル、プロンプトルールの変更や追加を望むことになります。

サービスとは異なり、エージェントには他者を保護する厳格なモジュール境界が存在しません。価格設定チームによる変更は、チェックアウトの文脈ウィンドウと共有されるためです。

システムを多数のサブエージェントに分割し、各ビジネスユニットごとに一つずつ割り当てるという誘惑的な解決策があります。しかし、第1部で議論した通り、品質上の理由からこのアプローチは推奨されません。代わりに、多チーム間の協力をリスク低減するためのプロセスについて解説します。

所有権はシステムに紐付きます。各スキルとツールには単一の担当チームが割り当てられています。例えば、価格設定チームがプロモーションツールおよび価格設定スキルの責任を持ち、カスタマーケアチームが注文・返品ツールや顧客対応スキルの責任を負います。共有プロンプトについては、共通部分はプラットフォームレベルの単一オーナーが管理し、ドメイン固有のセクションは各ドメインのオーナーが担当します。

変更には関連するテストケースを同梱し、CI はそのケースセットに対して実行されます。スキルを提供するチームは、ネガティブケースや隣接するスキルとの境界条件を含む、すべてのテストケースも同時に提供しなければなりません。プルリクエストごとにフルスイートを実行するのは時間がかかりすぎ、コストが高すぎるため、代わりにその中から必要なケースセットを構築して CI に組み込みます。

テストセットは、トラフィックの多いリクエストとすべての安全性関連ケースからなるコアケースで構成します。さらに、変更対象となった機能に対応するケースも実行します。

スキル（Skill）の場合は、そのスキル固有のケースと隣接スキルの境界ケースを実行します。ツール（Tool）の場合は、それを呼び出すすべてのケースを実行します。共有プロンプト（Shared Prompt）の場合は、システムプロンプトを参照する全機能が影響を受けるため、評価スイート全体を実行する必要があります。

パス率については数回の試行にわたって閾値を設定し、キャッシュヒット率や1ターンあたりのコストも併せて監視することを推奨します。また、夜間にフルスイートを定期的に実行し、リリース前にも必ず実施するのが良いプラクティスです。これにより、チーム間での回帰問題（Cross-team regressions）を早期に検出できます。

エージェントはリリースカレンダーにも組み込むべきです。デプロイ単位として 1 つのユニットであるため、変更が失敗すると全ユーザーに同時に影響が及びます。まずプロンプトとスキルの更新をカナリーコホートへ段階的に展開し、デプロイなしで特定のスキルだけを無効化するスイッチを用意してください。また、繁忙期には他のシステムと同様にエージェントの更新を凍結しておく必要があります。

この仕組みにおける人間側の役割については、『効果的なヒューマン・エージェントチームの構築』をご覧ください：Building effective human-agent teams。

今後の展望

本記事で説明した内容の多くは、モデルそのものに関する話ではありません。ツール呼び出しシステムはすでに運用中のシステムであり、スキルは既存の手順をコード化したものです。評価（evals）はテストとして記述された製品要件書であり、ハーン（harness）はあらゆるクライアントに対して適用するポリシーを強制する仕組みです。モデルの性能は向上し続けるため、より優れたモデルがリリースされた際は、設定変更と評価スイープを行うだけで本アーキテクチャに組み込むことができます。それ以外の部分はそのまま動作し続けます。

製品画面（product surfaces）へのロードマップについても考える必要があります。このアーキテクチャはチャットパネルよりも長く存続します。同じエージェントが音声経由でも機能でき、ユーザーからの要求を待たずに運賃の下落を検知して事前に行動することも可能です。すでに評価とツールを整備しているチームにとっては、これらはプレゼンテーション層でのプロジェクトに過ぎません。

さらに先を見据えると、ストアフロントへのトラフィックの一部は、ユーザーに代わって買い物を行うエージェントから来るようになります。自社エージェントを適切に管理するためのプロベナンス（出所証明）、ステージング、承認ルールは、外部のエージェントに対してツールを安全に開放する際にも同じく必要となります。

EC 業界では、購入プロセスをいかにスムーズにするかが常に成功の鍵となってきました。エージェントは、その実現をさらに容易にします。

消費者向けと事業者向けの両方のエージェントを含む完全な参考実装および、小売・旅行・通信・エンターテインメント分野で実行可能なサンプルコードについては、以下の GitHub リポジトリをご確認ください：complete reference implementation

謝辞

*執筆者：Matthew Koen, Ali Shazal。貢献いただいた Michael Segner 氏、Rodrigo Olivares 氏、Amandeep Khurana 氏、Aiza Usman 氏、John Lopus 氏およびその他関係者の方々に深く感謝いたします。*