Anthropic、Claude を活用した高効率 EC AI エージェントの設計と評価を公開

本稿では、オンライン取引をよりスムーズにするための AI エージェントのアーキテクチャ設計、遅延（ユーザーが指示を出してからシステムからの応答が表示されるまでの待ち時間）とコスト削減のテクニック、そして実践的な評価方法について解説します。

過去 1 年間、私たちは小売業者や EC プラットフォーム、さらに旅行・エンタテインメント、通信サービスプロバイダーなど、商業分野のあらゆるチームと密接に協力し、Claude を活用した専用 EC AI エージェント（Commerce Agents）を構築してきました。

これらの AI エージェントはすでに実運用環境で稼働しています。企業客户は導入により、ユーザーのカート内商品単価が向上し、販売者の運営効率が劇的に改善されたことを実感しています。興味深いのは、これらすべてのシステムに共通する極めてシンプルなアーキテクチャです。それは、Claude をエージェント・ループ（大規模モデルが観察、思考、行動を繰り返し目標達成に至るまでの往復プロセス）の中に配置し、一連のスキルとツール、そして強力な評価スイート（モデルのパフォーマンスを体系的にテスト・採点するための自動化されたツール群）を付与するというものです。

この記事は、こうした（あるいは同様の消費者向け）AI エージェントを構築しているエンジニアや技術リーダーを対象としています。第 1 部では一度決断すればその後の運用が楽になるアーキテクチャ設計について、第 2 部では遅延とコストの最適化手法について、そして第 3 部では生産環境における実務課題——セッション間の記憶管理、セキュリティ、システム評価、大規模組織内での横展開——について詳しく掘り下げます。

本ガイドの内容：

• 第 1 部：アーキテクチャ設計 EC AI エージェントとは何か？

• サブエージェントよりもスキルを優先する

• システムプロンプトとスキルの使い分け：利用頻度で判断

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

• UI コンポーネントもツールとして扱う

• 第 2 部：高速化とコスト削減 タスク完了までの遅延を極限まで短縮する

• 知覚遅延の最適化

• プロンプトキャッシュの活用

• モデルとその設定の選定

• 第 3 部：本番環境での運用 セッションを跨ぐ永続的記憶の実装

• セキュリティ：Harness に任せる

• 評価：非確定的なシステムへのリリース方法

• 大規模組織内での共同リリース

• 未来への展望

01

アーキテクチャ設計

標準的なエージェント・ループ内で単一のモデルを実行し、長尾ニーズにはスキルでカバーし、既存システムとの連携にはツールを活用する。これは一度決断すれば十分な基本アーキテクチャです。

EC AI エージェントとは何か？

私たちが定義する EC AI エージェントとは、オンライン上の商品カタログ全体における取引プロセスを簡素化できるエージェントのことです。

AI エージェントには消費者向けと事業者向けの2種類があります。

消費者向けエージェントは、商品の検索や価格比較、代替品の提案を行い、最終的に注文へとつなげます。具体的には、ショッピングカートへの追加、旅行スケジュールの作成、携帯電話プランの変更、あるいはイベント席の予約などが該当します。

一方、事業者向けエージェントは、販売データに関する問い合わせへの回答、プロモーションやマーケティング活動の実行、在庫管理や価格設定などを担います。

その核心となるアーキテクチャは、モデルを「標準的なエージェント・サイクル」の中に配置することです。これは、目標達成のために推論を行い、文脈を探り、ツールを通じて行動し、スキルを通じて手順を学習し、不明点を明確にするための質問を投げかけ、実行結果を観察して最終目標が達成されるまで繰り返すプロセスです。

このアーキテクチャでは、会話の断片化を行うために「意図ルーター（ユーザーの意図を判断しタスクを振り分けるミドルウェア）」をフロントエンドに置くこともなければ、特定のドメイン向けに多数のサブエージェントをバックエンドに配置することもありません。

文脈エンジニアリング (Context Engineering)

サブエージェントよりもスキルを優先する

EC（電子商取引）AI エージェントは、複数の商品カテゴリやユーザーの多様な意図に対応できる広範な能力を備える必要があります。そのため、「各垂直領域ごとに専用のサブエージェントを作成すればいい」という誘惑に駆られがちです。

しかし、実際にはこのアプローチが最適解になるとは限りません。EC における対話は密接につながっており、複数の意図や会話のラウンド（やり取り）を跨ぎ、大量の文脈情報を共有する必要があるからです。

サブエージェントアーキテクチャでは、通常、メインのコーディネーターがショッピングカート情報や一時保存された変更点、ユーザーの好み、過去の対話履歴などを保持します。

タスクをサブエージェントに引き継ぐたびに、それは「状態の喪失（システム切り替え時に蓄積されたデータや文脈を忘れてしまうこと）」を伴う操作となります。これにより、サブエージェントからの回答品質が低下し、最終的に全体の性能が損なわれます。さらに深刻なのは、各引き継ぎでトークン使用量が数倍に跳ね上がり、応答遅延も数秒増える点です。

また、異なるビジネス領域をきれいに切り分けるのは容易ではありません。例えば、返品プロセスでは注文履歴の確認、現在のショッピングカート、商品カタログへのアクセスが同時に必要になる場合があります。「各ドメインごとにサブエージェント」という戦略を採用する場合、これらの権限を各エージェントに複製するか、タスク実行の途中で頻繁に引き継ぎを行う必要があります。

モデルは賢くなり、より長い文脈を処理し、より多くのスキルやツールを活用できるようになっています。そのため、「同じモデル内でタスクを処理する」といった過去の制約は、新世代のモデルが迭代されるごとに徐々に解き放たれてきています。

一方、エージェント・スキル (Agent Skills) を活用すれば、引き継ぎコストを発生させることなく、「ドメインごとの分割」に似たモジュール化と文脈制御を実現できます。スキル指令は、すでに完全な履歴を把握しているメインエージェントに直接読み込まれるためです。

複数の企業向けデプロイメントでの比較テストでは、「単一エージェント＋スキル」のアーキテクチャが、「すべての要素を一つのプロンプトに詰め込む」設計や「サブエージェント」設計よりも常に高品質であることが示されました。また、各タスク処理におけるコストは低く、遅延も小さい傾向にあります。

それでは、サブエージェントが活躍するのはどのような場合でしょうか？

メインのコーディネーターがそれをツールとして呼び出し、極めて垂直的で独立しており、専用の文脈ウィンドウを必要とするタスクを処理させる場合に、その真価を発揮します。

本稿は Anthropic の Claude ブログより抜粋した「高効率な EC AI エージェント解剖ガイド」です。

生産環境における典型的な例として、「深層調査（Deep Research）」サブエージェントが挙げられます。このエージェントは、膨大な文書の検索・読解、コードの作成と実行、データモデルの探索、行き詰まり時の道筋の模索など、複雑多岐にわたる業務を担います。これらの作業は 1 つまたは複数のサブエージェント内で完結し、最終的に主調整役（マスタークオレーター）へは簡潔な回答のみが返されます。

もう一つの例外ケースとして、特定の事業領域にすでに専門的で成熟したエージェントが存在する場合があります。例えば、自社の薬局事業や金融サービスで、独自のコンプライアンス要件を持つ専用エージェントが運用されている場合です。この場合、最も適切な対応は「完全な引き渡し（Hand-off）」を行うことです。つまり、その専門エージェントが任務を完全に引き継ぎ、タスク完了までユーザーと直接対話するサイクルを維持します。

ここで重要なのは「会話の所有権」の違いです。「引き渡し（Hand-off）」とは、ドメイン固有のエージェントが直接的な窓口となることを意味します。一方、「委譲（Delegation）」では主調整役が全体を統制し続け、単発の対話でドメインエージェントを一時的に呼び出して使用し、すぐに切り離すことになります。この方法では、情報の伝達過程で内容が逐次減衰してしまうリスクがあります。

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

ある一連の指示をシステムプロンプト（System Prompt）に記述するか、別個のスキルとして実装するかを決める際、最も重要な判断基準は「その機能を利用する頻度」です。スキルのロードにはモデルの 1 ラウンド分の対話コストが発生するため、エージェントが対話の大半で必要とする情報は、原則としてシステムプロンプトに含めるべきです。

ただし、これはトラフィックの分布状況や、評価結果から浮かび上がるエージェントの振る舞いにも依存します。有用な経験則として、「全トラフィックの 3 割以上に関わる指示」は、リリース前に予測されたものでも、本番環境で観察されたものでも、すべてシステムプロンプトに記述し、残りの長尾ニーズをスキルとして実装するのがおすすめです。

ユーザーがどのページから遷移してきたかといった既存のシグナルから、特定のスキルが必要とされることを事前に予測できる場合は、モデルの初回呼び出し前に Harness を介してその情報を注入することを推奨します。これにより、別途スキルをロードする 1 ラウンド分のオーバーヘッドを削減できます。

安全性や法的制約、ブランドトーン、ユーザーの重要な属性（アレルギー歴など）といった、極めて重要な指示は、常にシステムプロンプト内に保持すべきです。

EC AI エージェントにおいては、「商品検索」機能はほぼすべてのセッションで必要となるため、必ず提示詞に含める必要があります。一方、スキルには長尾の細々とした機能を任せるのが適切です。

Anthropic が提供する 参考実装 では、ショッピングエージェントのプロンプトには背景設定、カートおよび決済ルール、UI 表示ルールが含まれています。残りの機能は以下のスキル群が担います：検索発見、購入調査、目標計画、カスタマーケア、記憶とパーソナライズ。

マーチャント（店舗運営者）向けエージェントも同様の分割アプローチを採用しています。そのスキルには、パフォーマンスインサイト、カタログ一覧、在庫操作、価格・プロモーション設定、マーケティングキャンペーンが含まれており、それぞれの業務領域が 1 つのスキルに対応しています。

提示詞に含まれるもの *ショッピングエージェント*: 背景設定、カートおよび決済ルール、表示ルール、商品検索。

ショッピング用スキル *長尾機能*: 検索発見 · 購入調査 · 目標計画 · カスタマーケア · 記憶とパーソナライズ

マーチャント用スキル *各業務領域ごとに 1 つ*: パフォーマンスインサイト · カタログ一覧 · 在庫操作 · 価格・プロモーション設定 · マーケティングキャンペーン

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

「エージェント向けに効果的なツールを作成する」に関する当社の記事では、ツール設計の一般的な原則を解説しています。EC 分野においては、特に以下の 2 点が重要です。

エージェントツールは、コアシステムとビジネスロジックの上に構築せよ。

EC 企業には通常、すでに成熟した検索・ソートシステム、カート機能、嗜好・プロファイル管理、在庫管理、プロモーションおよびキャンペーンエンジン、販売分析など、多岐にわたるシステムが整備されています。これらの各システムは、長年の熟成によって磨き上げられたビジネスロジックを含んでおり、大規模言語モデル（LLM）が直接アクセスできない基盤レベルのシグナルも取得可能です。

AI エージェントが扱うべきツールは、大規模言語モデルで既存システムを再実装するものではなく、それらを呼び出すためのものです。「ツールの境界」とは、既存システムのビジネスロジックが終了し、大規模言語モデルの判断力が引き継ぐ地点を指します。

例えば、エージェントが search_products（商品検索）を呼び出した場合、返される結果は既にソート済みであるべきです。大規模言語モデルの役割は、どの結果がユーザーの目的に合致するかを判断し、いくつ表示すべきか、そしてどのようにユーザーに提示するかを決定することにあります。

ツールの返却値が文脈となります。

大規模言語モデルが推論する際に必要なフィールドのみを返し、それ以外の不要なデータはすべて削除してください。最もよくある違反例として、各検索結果に含まれる長い画像 URL の列挙があります。

必要であれば、ツール内部で元の返却データを再構築することも可能です。例えば、次の操作がデータ自体から明確でない場合、結果に「次の指示」を追加して付与できます。

これはエラー処理の場面で特に有効です。大規模言語モデルは、単なるエラーコードよりも具体的な指示を好むからです。汎用的な 403 エラーを返す代わりに、「在庫照会時には商品 ID の指定が必須です」といったエラーメッセージを追加しましょう。

UI コンポーネントもツールとして扱う

多くの EC AI エージェントの応答は、長大な散文ではなく、具体的な UI コンポーネント——商品カルーセル、旅行スケジュール、座席図、あるいはチャートなどです。つまり、エージェントは純粋なテキストではなく、特定の形式（Schema）に則ったデータを出力する必要があります。

チームが初期段階では、プロンプトを通じて大規模言語モデルにカスタムタグを出力させ、クライアント側で解析するという手法をとることがあります。しかし、事業範囲が拡大するとこの手法はすぐに通用しなくなります。その理由は以下の通りです。

• 専用ツール呼び出しと比較して、大規模言語モデルはカスタムタグの記法に対する習熟度が低いため、ネストされたコンポーネントが増えるほどシステムの信頼性は急激に低下します。プロンプトのみでは、データ形式が常に正確であることを保証できません。

• タグ定義をすべてシステムプロンプト内に記述すると、新しいコンポーネントを追加するたびに文脈が肥大化し、修正を行うたびにプロンプトの他の部分でバグが発生するリスクが高まります。

過去の会話履歴は、最終的にあなたのパーサーだけが理解できる形式で保存されます。つまり、履歴をロードする際は、クライアント側でこれらの生メッセージを再解析するか、ネイティブなモデル API 形式とは別に、独自のデータコピーを保持する必要があります。

最も信頼性の高いパターンは、すべての UI コンポーネントをツールとして扱うことです。大規模言語モデル（LLM）は特定の引数付きで present_products（商品表示）、present_itinerary（行程表示）、present_plan_comparison（プラン比較）などのツールを呼び出します。サーバー側でこれらの呼び出しを検証・補完した後、イベントを発行し、クライアント側がレンダリングを行います。

これらのコンポーネントは本質的にツール呼び出しであるため、メッセージ配列内にネイティブな形式で既に存在しています。古い対話を再ロードする際も、再度解析する必要はありません。表示系ツールの契約例については、以下の画像および 参考コードリポジトリ をご覧ください。

上記の 2 つのパネルでは、同じ AI エージェントが同じツールとプロンプトを使用しています。唯一の違いは Agent Harness の実装です。全体の処理時間はほぼ同等ですが、ユーザーがシステムからの反応を感知するまでの体感時間には大きな差があります。

ここでのトレードオフはストリーミングの粒度にあります。ツール呼び出しの各トップレベルパラメータは、サーバー側で検証のために一旦バッファリングされるため、ストリーミング機能を有効にしても、表示系ツールのサブコンポーネントは段階的に表示されます。これにより、ユーザーの体感遅延に多少の影響が生じます。

トークンレベルの極限まで細かくストリーミングを実現したい場合は、ツール定義に eager_input_streaming: true を設定します。これによりバッファリングをスキップできますが、その代償としてサーバー側でのデータ形式の厳格な保証は失われます。

当社の評価では、Claude Sonnet 以上のモデルにおいてフォーマット違反は極めて稀です。しかし念のため、呼び出し処理にリトライ機構を設け、稀に漏れ出るエラーに対応することをお勧めします。

また、こうした表示系ツールは、エージェントに対して「現在画面に表示されているもの」の記録を提供します。顧客が「最初のホテル」や「左から三番目」と言った場合、レイアウト情報は直近の表示系呼び出しのパラメータに、メッセージ配列の中に格納されています。これにより、エージェントは瞬時にユーザーが指している対象を把握できます。

この仕組みを機能させるには、パラメータ構造が UI のレンダリングレイアウトを忠実に反映している必要があります。つまり、フラットなリストをクライアントに渡して並べ替えを任せるのではなく、インターフェースの構造（例えば順序付きの行やスライダーなど）に合わせてデータを整理してください。

02

速度とコストの両立を図る

エンドツーエンドの遅延とユーザーが感じる遅延の両面からアプローチし、キャッシュでコスト負担を軽減しましょう。これらの最適化は、大モデルの「知能」を犠牲にしてはいけません。

EC（電子商取引）領域において、遅延は致命的です。特に消費者向けのインターフェースでは、遅延に対する許容度は極めて低いです。しかし、エージェントアプリケーションを観察していると、一つの傾向が見えてきます。リテンション率や参加度、ショッピングカートの規模といった主要指標を押し上げるのは、往々にして最終結果の品質なのです。

わずかな遅延を削り出すことよりも、「回答が関連しているか」「タスクが本当に完了したか」の方が、これらの指標に与える影響は遥かに大きいです。

したがって、遅延問題への対策は二つの軸で進めます。一つは優れたエンジニアリング設計によってエンドツーエンドの絶対的な遅延を可能な限り短縮すること。もう一つは、ユーザーが「エージェントが着実に作業を進めている」と感じることで待ち時間を意味あるものと感じさせる、いわゆる「知覚される遅延」を減らすことです。

各ユーザーには心の中で「許容できる遅延の予算」が存在します。以下のテクニックを使えば、モデルの賢さを損なうことなく、その予算内でタスクを完了させることができます。

タスク完了までの遅延を最小限に抑える

タスク完了までの遅延は、「大モデルが思考するラウンド数」と「初文字表示時間＋ツール処理時間の合計」を掛けたものです。これにより、最適化のレバー（手段）が三つ浮き彫りになります。

1. 会話ラウンド数を減らす
2. ツールをより高速に実行する
3. トークンの生成速度を上げる

これらのレバーは互いに牽制し合うこともあるため、特定の一点だけを極めるのではなく、それらの合計値を最適化することを目指してください。

会話ラウンド数を減らす： 将来必要となるコンテキストを事前に読み込み、モデルの知能を高めることで、依存関係のないツール呼び出しを並列実行できるようにする。

ツールを高速化する： ツール自体のバックエンドロジックを最適化し、パラメータ生成が完了次第即座に「Eagerly（意欲的に）」配信トリガーを発動させる。

トークン生成を高速化する： 評価スイートを実行して、最も適したモデルとそのパラメータ設定を選定する。

会話ラウンド数を減らす

ユーザーの質問が複雑になればなるほど、必要な会話ラウンド数は増えます。これは通常、あなたがコントロールできる範囲外です。しかし、モデルの知能が高ければ高く、コンテキスト内の情報が関連性を持てば持つほど、エージェントはより少ないラウンド数でタスクを完了できます。この分野における重要な知見は以下の通りです。

• 頻出するコンテキストを事前に読み込む。 ユーザーが商品ページでアシスタントを起動した場合や、事業者がイベントダッシュボードで呼び出した場合は、そのページのデータをそのまま会話のコンテキストに含めてください。次の対話内容がそれに関連している可能性が高く、既存のコンテキストから回答を得ることは追加のラウンド数を消費しないからです。

• モデルの知能を高める。 より賢いモデルは、効率的な計画とツール呼び出しの実行が可能となり、タスク完了に必要な総ラウンド数を削減できます。このラウンド数の節約は、生成速度がやや遅くなるという欠点を十分に上回るメリットとなります。ユーザーの質問が複雑な場合や、本番環境のデータでタスク完了に 5 ラウンドを超えることが頻繁である場合は、最速のモデルではなく、最も賢いモデルを選ぶのが正解です。どのモデルを選定すべきかは実際のトラフィック次第ですので、後述する「モデル選択」セクションで説明しているようなスweep テスト（掃引テスト）を通じて決定してください。

• モデルに依存関係のないツールを並列呼び出させる。 EC（電子商取引）の現場では、複数の商品検索や複数件の返品・交換ポリシー文書の照会、あるいは複数の販売データソースからの記録取得など、大量の操作を並行して実行するケースが頻繁にあります。ツールの並列呼び出しにより、独立した複数のクエリに追加の会話ラウンドを割く必要がなくなります。プロンプトでモデルを誘導し、同一ラウンド内で複数のツールを呼び出させ、その結果をツール結果の配列としてまとめて 1 つのユーザーメッセージで返すことが可能です（詳細は 並列ツール呼び出しドキュメント を参照）。

ツールをより高速に動かす

• ツールのバックエンド自体を最適化する。 場合によっては、ツールが外部へ分散処理を行う必要があることもあります。例えば、「今日のサマリーを取得する」という問い合わせを受けた EC ドメインのスマートエージェントが、売上高・在庫状況・キャンペーンステータスをそれぞれ別々に取得するために 3 つの独立した呼び出しを実行するようなケースです。しかしよく見られるのは、ツールの境界が「欠落しているバックエンドロジックを寄せ集めたゴミ箱」化してしまっていることです。「在庫を確認する」というツール一つとっても、商品カタログから SKU を検索し、店舗在庫サービスで各店の在庫をチェックし、履行サービスで締め時間を確認し、最後にツール自身のコード内で代替ルールや店頭受取条件を適用してから初めて結果を返す、といった具合です。このようにツールが過剰なドメイン知識を担うと、ルールが少し変わるだけで正確性を保つことが極めて困難になります。本来は上位システムが担うべき業務ロジックをツール側で実装している状態です。

もしツール内でこのようなビジネスロジックを手書きしていることに気づいたら、正解は以下の通りです：バックエンドにその問い合わせに直接回答できるエンドポイント（Endpoint）を作成し、スマートエージェントのツールからはそのエンドポイントを呼び出すようにします。

• ツールを「イーガー（Eagerly）」に配信する。 ツールのパラメータも、大規模モデルが出力する他の通常のテキストと同様にストリーム形式で生成されます。そのため、Harness はツールのパラメータが出力され次第即座にその呼び出しを実行し、モデルがまだ並列で他のツールやコンテンツブロックをストリーミングしている最中でも、そのリクエストの処理を開始できます。このテクニックにより、これまで数秒にも及んでいた待ち時間を数百ミリ秒未満に短縮した事例があります。Claude Agent SDK ではデフォルトでこの方式が採用されています。また、プロンプトでモデルに対して最も遅い呼び出しを最初に出力するように指示することで、レイテンシの圧縮効果を最大化できます。

上の2つのパネルは、同じAIエージェントが同じツールとプロンプトで動作していますが、唯一の違いは「Agent Harness」です。全体の処理時間はほぼ同じですが、ユーザーが感じるシステムの反応速度には大きな差があります。

知覚遅延の最適化

知覚遅延とは、画面に何らかの変化が表示されるまでユーザーが待たされる時間のことを指します。消費者向けサービスでは特に致命的で、購入フローにおけるわずかな摩擦も、成約率や収益に直結するリスクとなります。

モデル自体を変更しなくても、以下の2つの手法で知覚遅延を大幅に短縮できます：

• コンポーネントの生成とレンダリングを並行して行う。 典型的なECサイトのAI回答には500〜700トークンが含まれます。ストリーミング処理を行わない場合、ユーザーはローディングアニメーションが回るのを5秒以上見続けることになります。ツールからパラメータが出力されるたびに即座にクライアントへ送信し、ページ上で順次レンダリングしていくことが重要です。

思考プロセスの可視化

AI エージェントが大量のコンテキスト情報を収集している最中、各ステップで簡潔な自然言語による進捗表示を出力しましょう（例：「海沿いのホテルを検索しています…」）。このメッセージは、既存ツールのパラメータ（商品検索のクエリなど）から直接抽出して生成するか、ツールに user_facing_message という追加パラメータを用意し、モデル自身に記述させる方法があります。

上記の 2 つのパネルは、同じ AI エージェントが同一のツールとプロンプトを使用しています。唯一の違いは「Agent Harness」の有無です。実際の処理時間はほぼ同等ですが、ユーザーがシステムからの反応を感知するまでの体感時間は大きく異なります。

プロンプトキャッシュ（Prompt Caching）

コスト削減において最も強力な武器となるのがプロンプトキャッシュです。特に EC サイトのような高トラフィック環境では、その効果を最大限に発揮できます。キャッシュされた入力トークンの読み取りコストは、新規読み込みの 10 分の 1 です。書き込み時には約 1.25 倍のコストがかかりますが、キャッシュされたプレフィックスが二度目以降に利用されれば、すぐにその差額を回収できます。顧客向けの高トラフィックアプリケーションでは、デフォルトの 5 分という短いキャッシュ有効期限を採用するだけで、極めて高いキャッシュヒット率を達成できる環境にあります。

これまで見てきた EC サイトでの最適な導入事例では、キャッシュヒット率が 90〜99% に達しています。プロジェクトの初期段階からこの数値を目標に設計を進めるべきです。また、約 10 万トークン規模の処理においては、キャッシュされたトークンの読み取り速度が従来の 1.5〜2 倍になることが確認されています。さらに、扱うトークン数が増えるほど、その速度向上効果は線形的に拡大します。

キャッシュはプレフィックスマッチングに基づいて動作します。リクエストが来ると、システムはキャッシュから順次読み出し、直前のリクエストと異なる最初のバイトに到達するまで停止します。つまり、重要なのはコンテキスト内に「何が」含まれているかだけでなく、「どのように順序付けられているか」です。

1 つのリクエストを、変化の頻度に応じて並べられた 3 つのブロックから構成されるものとして捉えてみましょう。

• グローバルブロック（Global）： システムプロンプトとツール定義の大半が含まれます。この部分はすべてのセッションで完全に同一です。最もホットなキャッシュ領域であり、大規模な同時接続下でもほぼ永続的に有効です。異なるラウンドやセッション間で、この部分に 1 バイトも変化がないように徹底し、末尾には必ず「キャッシュブレイクポイント（Cache Breakpoint）」を配置してください。

• セッションブロック（Session）： ユーザー固有のコンテキストと会話履歴が含まれます。ユーザー間では異なりますが、単一のユーザー内での会話は安定しています。このブロックはグローバルブロックの直後に配置します。

• 変動ブロック（Volatile）： 1 つのセッション内で頻繁に変化する要素（現在時刻や、ユーザーが現在閲覧中のページなど）です。リクエストの末尾に配置してください。最新のリクエストで特定のタグを付けたテキストブロックとして記述するか、会話中システムメッセージ をサポートするモデルであれば、メッセージ配列の末尾に system-role のメッセージとして追加します。

最も多い失敗例の一つが、タイムスタンプや現在のページリンクをシステムプロンプトの先頭に直接配置してしまうことです。これにより、キャッシュは毎回静かに無効化（バust）されてしまいます。

実装において、特に注意すべき2つのポイントがあります。

まず、スキルはシステムプロンプトに無理やり追加するのではなく、「ツール結果 (Tool Results)」として読み込むようにしてください。これにより、スキルの本体が会話のプレフィックス部分に含まれるようになり、キャッシュの対象となります。

次に、各対話ラウンドでブレークポイントを前方へスライドさせます。1回のリクエストで許可されるブレークポイント数には上限があるため、最新のブレークポイントをユーザーの各ラウンド末尾に移動させるのです。これにより、各ラウンドで累積された履歴（膨大な検索結果のような長いツール応答データを含む）をキャッシュから読み取ることが可能になります。

適切なモデルと設定の選定

モデル規模と努力レベルの設定 (Effort Setting) も、同じく「知能（IQ）と遅延、コスト」のトレードオフに直面します。決定を下す際は、確かなデータに基づいたテストを行うべきです。

• 北極星指標と許容範囲を明確にする。 事業の根幹を支える品質指標（タスク完了率、回答の関連性、事実に基づく正確さなど）を選び出し、絶対に妥協できない評価スコアの下限を設定します。同時に、p50 と p99 の遅延時間およびコスト予算の範囲も確定させておきましょう。

• 包括的なスweep テスト（全モデル・設定テスト）を実行する。 検討しているすべてのモデルと努力レベルに対して、評価スイート全体を走らせてください。分析タスクが中心となる B2B エージェントの場合は Opus から、遅延に敏感な B2C エージェントの場合は Sonnet からテストを開始することを推奨します。もし生産環境の実トラフィックデータをお持ちであれば、実際のクエリ比率に基づいてテスト結果に重み付けを行いましょう。最終的には数字で判断してください。場合によっては、Opus 5 がカートへの追加や購入完了といったタスクにおいて、Sonnet よりも高いコストに見合うだけの大きな効果をもたらすことがあります。しかし、そうならないケースもあるのです。

テスト結果を注意深く読み解きましょう。チームが驚かされるケースは主に2つあります。

1 つ目は、プロンプトが特定のモデル向けに最適化されているという点です。そのため、モデル A 用に設計したプロンプトをモデル B で試すと、期待通りの結果が得られないことがあります。小規模なモデルでは「手取り足取り教える」ような指示が必要ですが、最新の大型モデルは自ら推論して対応できるケースも増えています。逆に、大型モデルは小規模モデルが無視する命令まで厳密に実行しようとするため、かえって失敗することがあります。したがって、候補モデルを却下する前に、そのモデルで発生した失敗事例に対して数回の微調整を行うことは、コストが極めて低くても非常に重要なステップです。

2 つ目は、「より賢い設定」の意外な強みです。トークン生成速度は遅くなるものの、最終的なレイテンシ（特に p90 や p99 の値）において勝るケースがあります。これは、ツール呼び出しをより適切に計画できるためで、最も複雑なリクエストに対しても、少ないラウンド数で確実に対応できるからです。

コスト計算では、「1 回のタスク完了にかかる費用」を基準にしてください。「1 回のモデル呼び出しあたりのコスト」だけで判断するのは危険です。安価なモデルでも、多くのラウンド数を要したり頻繁に失敗したりすれば、結局は高コストになります。テスト結果が拮抗し、コストもタスクごとの経済性と許容できるレイテンシの範囲内であれば、迷わず「知能の高い」モデルを選びましょう。ユーザーの採用と定着を左右するのは品質であり、その選択は将来 6 ヶ月でさらに強力になるモデルに対応する余地を残すことにもつながります。

03

本番環境での運用

記憶、安全性、評価、そしてチーム間での連携と公開——これらが AI エージェントを生産環境で成功させ、長期的に存続させるための基盤です。

最後に、生産環境でエージェントを生き残らせる鍵となる要素についてお話ししましょう。それは記憶、セキュリティ、評価、そして大規模組織内での協働の仕組みです。

跨セッションの永続的記憶

顧客との関係構築と対話は極めて重要です。記憶こそが、エージェントに「前回の続きから話をする」能力を与え、「初対面のように振る舞う」必要をなくす魔法のような機能です。3 月にナッツアレルギーについて言及した購入者が、6 月になっても同じことを繰り返さなければなりませんし、毎週月曜日に同じ 3 つのマーケティングキャンペーンを確認する事業者が、毎回キャンペーン名を手動で入力する必要もありません。セッションを超えて保持されるべき「長期記憶」は、手作業で構築すべきシステムです。それは「記憶をどのように保存するか」「どのように書き込むか」「どのように読み出すか」という 3 つの要素から成り立っています。

記憶の保存

記憶は、大規模言語モデル（LLM）ではなく、自社のシステム内に保存すべきです。

顧客データが少なく、エージェントが唯一の閲覧者である場合、フラットな Markdown ファイルに記録する程度でも許容できるかもしれません。しかし、多くの生産環境における EC エージェントは、そのような簡易的な方式ではすぐに限界を迎えます。最も実用的な代替手段は、すでに運用しているデータベースです。

記憶の事実は、構造化された小さなレコードとして扱うべきです。具体的には、キー（例：shoe_size 靴のサイズ、default_store デフォルト店舗、preferred_report_cadence 報告頻度の好み）、短い値、分類タグ、そしてその記憶がどのセッションで生成されたかを示す情報を含みます。一部のキーは事前に定義され、全ユーザーに共通して設定されますが、残りのキーは抽出器によって自動的に発見・作成されます。

保存量が増大してもデータベースは効率的なクエリを維持し、特定の属性に基づいて決定論的な行動を実装することが可能になります。また、既存のユーザーデータとの関連付けも容易です。

事業者向けエージェントの場合、記憶は「アカウント」単位ではなく、「個人」単位で構築すべきです。事業者のログインアカウントは複数のオペレーターが共有していることが多く、各オペレーターには独自のプロフィールが必要です。記憶を読み出す際には、その個人の権限を尊重する必要があります。例えば、店舗マネージャーのエージェントが、地域マネージャーから聞いた機密情報を参照することは絶対にあってはいけません。

EC 分野では、エージェントの記憶には必ず個人データが含まれます。最も記憶すべき事実は、しばしば規制対象となるデータであり、国や地域によって法規制は大きく異なります。記憶を単なる「保存の問題」ではなく、「データ処理とコンプライアンスに関する設計課題」として捉えるべきです。

実践的には、以下の 4 つの点が重要です。

• 保持する記憶の種類を明確に定義する。 データ書き込みの段階で厳格なチェックを行い、不合规な保存リクエストを検証器によって強制的にブロックします。プロンプト内に軽くルールを記述するだけでは不十分です。
• ユーザーが保存された情報を閲覧・修正・削除できる権利を保障する。 記憶の削除機能を、既存の「アカウント削除」や「データ請求」プロセスにシームレスに統合します。
• 保持期間を設定する。 数年前の嗜好はもはや古びています。有効期限を設定することで、記憶の鮮度を保つことができます。
• 記憶機能は、各デプロイ領域ごとに独立してオン/オフできるスイッチとして実装する。 これにより、コンプライアンス義務を負えない地域では、機能を完全に無効化して「裸で運用」することを回避できます。

記憶の書き込み

非同期方式で記憶を書き込むのが望ましいです。各対話ラウンドの終了時、あるいは長いセッションの間隔を置いて、別のエージェントが独立したスレッドまたはプロセスで実行され、対話履歴を読み込んでストレージに事実を作成・更新・削除します。同時に、そのエージェントは自身のセッションコンテキストも維持管理します。

この方式により、メインの対話に対する遅延には一切影響しません。社内で行った EC 記憶評価スイートでは、このアプローチによって事実の想起率が 13% 向上しました。

明白な代替案として、メインのエージェントに「事実を保存する」ツールを持たせて自ら呼び出させる方法がありますが、これは遅延に極めて敏感な EC エージェントにとっては最悪の選択肢です。なぜなら、保存操作ごとにユーザー向けの対話ラウンドが消費されてしまうからです。さらに、記憶全体がコンテキストに含まれていない場合、保存前に更新や重複排除のために一度読み込む必要があり、これもまた対話ラウンドを浪費することになります。

さらに、このアプローチは各会話ラウンドごとにメインエージェントに追加の意思決定負荷を課すことになりかねません。私たちの評価では、大モデルの注意力を巡るこうした争奪戦が、記憶すべき情報の見落としという形で直接的に現れています。

抽出器を独立させることで、より精密なプロンプト指示が可能になります。この抽出器はユーザーとアシスタントの純粋なテキスト対話のみを読み取り、ツールからの返却結果には一切触れません。これにより、商品説明や他者のレビューが誤ってユーザー自身の事実として認識されるのを防げます。プロンプトで「何が事実か」を明確に定義できます——例えば、明示されたサイズ、食事制限、配送の好み、店舗スタッフが頻繁に使用するカスタムレポートビューなどです。一方、「何が事実ではないか」（商品リスト内の情報や、一時的な些細な詳細など）も明確に区別します。

記憶の読み込み

記憶は3つの層に分けて読み込みます。

常にコンテキストに付随させる： 会話の各ラウンドで必ずコンテキストに含める、ごく一部の固定された核心事実があります。例えば、購入者のデフォルト店舗や配送設定、あるいはオペレーターが所属する店舗と役職など、ほぼすべてのリクエストで必要な情報です。

ラウンドごとに必要に応じてプリフェッチ： 現在の要求と強く関連する事実は、各ラウンドで事前に読み込みます。これはスキルをプリロードする場合のトリガーロジックに似ています。例えば、「靴を検索」というリクエストがあれば、自動的にユーザーのサイズや好むブランドが引き出されます。「キャンペーンについて」という質問であれば、オペレーターが頻繁に確認する指標が自動で表示されます。

クエリートールの背後に格納： その他、あまり頻繁に使わない記憶はすべて、「クエリートール」に一任し、必要に応じて取得させます。

記憶はユーザーレベルのコンテキストに属するため、すべての記憶は「セッション (Session) ブロック」に収め、グローバルキャッシュのブレークポイントの下に配置する必要があります。

セキュリティ：Harness が管理する

プロンプトは大モデルが安全な行動をとるよう導く第一歩ですが、金銭を直接扱い、かつ往々にして不可逆的な結果をもたらすEC（電子商取引）という文脈では、プロンプトだけでセキュリティ防護の最終防线とするのは危険です。プロンプトインジェクション攻撃が1回発生するだけでも、あるいは大モデルがふとした瞬間に誤作動を起こすだけでも、プロンプト内のルールは無力化されてしまいます。以下に挙げるすべての規則は、消費者向けと事業者向けの両方のエージェントにおいて、コードレベルで強制されるべきです。一度定義すれば、すべての実行環境でこの堅牢な防御壁を共有できます。

モデルは「下書き」のみ；最終判断は人間または既定のポリシーが

大モデルによるツール呼び出しが、直接資金を移動したり業務データを改変したりすることは絶対にありません。注文や決済、返金処理、価格変更、キャンペーン公開など、すべての最終アクションは Harness が厳格に管理し、大モデルが直接手を触れることは許されません。

消費者向けエージェンツでは、これは構造的に封じられています。チェックアウトツールは「確認して注文する」ボタン付きのカートページをレンダリングするだけであり、その背後にあるエージェント呼び出しのバックエンドインターフェースには、「資金を引き落とす」というメソッド自体が存在しません。

事業者向けエージェンツでは、すべての「書き込み」ツールは、サーバーが割り当てた ID を付与された「一時保存された変更」を生成するだけです。真の経路（例えば、オペレーションダッシュボードでボタンをクリックするか、コマンドラインで確認を入力するか、あるいは Managed Agents 上で実行される際にプラットフォーム標準のツール承認ポップアップを通じて）によって承認された ID のみが、apply_change を呼び出して実際に有効化されます。

これらの防護壁は、「変更を適用する」最後の瞬間にも、現在の制限条件に基づいて再検証を行います。一時保存時のデータではなく、リアルタイムの制限でチェックします。フロントエンドのインターフェースがどうあれ、核心となるロジックは同じです。大モデルが行える最も危険な行為は「提案を行うこと」に過ぎず、承認フローは必ず、貴社の業務システムに既に構築されている「作成者 - 検証者 (Maker-checker)」という確立されたプロセスに従って実行されます。

書き込みとレンダリング操作は「サーバー発行の ID」のみを認める

Harness は各セッションにおいて、サーバーが大モデルに渡したすべての ID を記録します。そしてこの記録が、あらゆる書き込みや画面レンダリング操作に対する唯一の通行証となります。

カート内には、そのセッションでサーバーが実際に返した商品 ID のみが追加可能です。同様に、店舗管理ツールも、エージェントが実際に読み込んだ商品リスト ID やキャンペーン ID のみを受理します。もし ID が他の不正な経路（例えば大規模言語モデルのハルシネーションによる捏造、ユーザーの手動コピー＆ペースト、あるいはコメントに紛れ込ませたものなど）で入力された場合、それはバックエンドに到達する前に厳格に拒否されます。

このルールは UI 画面にも適用されます。表示用のツールは ID パラメータのみを受け取り、サーバー側がその ID に紐づく商品、注文、または変更履歴の詳細情報を自ら取得・補完します。したがって、フロントエンドのカードに表示される情報は、常にサーバーから直接取得された絶対的な真実のデータとなります。

この管理は代理エージェントにも及んでいます。店舗分析用のサブエージェントはデータを自由に参照できますが、メインエージェントが書き込み権限を持つ ID リストに、勝手に新しい ID を追加することは一切許されません。

また、費用明細や免責事項など、厳重に規制されるべきコンテンツについては、モデルの役割は「どの製品の条項を表示するか」を選定することのみです。実際の条文は、サーバーが審査済みの標準文言を一字一句正確に提供します。店舗側エージェントの保護フィールドリストにもこれらの費用項目はロックされており、双方とも改変したり、独自に捏造した説明を加えたりすることはできません。評価システムも、表示された文字列に対してバイトレベルで厳密な照合を行います。

上限設定のある取引は、高頻度のリクエスト攻撃に耐えられる必要がある

多くの EC システムでは、チケットの確保やプロモーション価格の利用、不正利用（ボットによる買い占め）を防ぐため、ユーザーが同一商品を購入できる数量に制限を設けています。しかし AI エージェントは人間がボタンをクリックする速度とは比較にならないほど高速でリトライし、様々な手を使ってその制限に挑戦したり、並列処理で同時に攻撃を仕掛けたりします。

そのため、「数量上限」の検証ロジックは、書き込み完了後の最終状態に対して厳格に適用されます。これにより、「もう 2 つ追加して」という二回目のリクエストが上限を超えて積み重なることは不可能になります。また、単一セッション内でのカートへの書き込み操作も並列処理ではなく順次実行されるため、大規模言語モデルが一度の対話で複数のツール呼び出しを並行して行ったとしても、数量制限の抜け道を利用することはできません。

価格改定や割引率、在庫補充数、キャンペーン予算など、店舗側による各種変更操作についても同様のロジックが適用され、「一切の変更を禁止する」保護フィールドのブラックリストも併用されます。このルールは普遍的に有効です：制限条件の境界線は「リクエストのプロセス」ではなく「最終状態」に設定し、単一セッション内ではすべての書き込み操作を順次実行させるのです。

第三者によるコンテンツは必ず消毒・浄化される必要がある

EC の環境において、コンテキストの大部分は自社以外の者によって作成されます。例えば、サードパーティの出品者やレビューを書く購入者、さらには競合他社です。したがって、バックエンドからのデータ読み込みはすべて「信頼できない入力」と見なし、必ず浄化プロセスを経る必要があります。

第三者が作成したツールからの返却結果（商品詳細、購入者のレビュー、ポリシー規定、出品者のメッセージ、保存された記憶など）は、モデルが参照する前に徹底的に浄化され、固定タグ付きのフェンスで囲い込まれる必要があります。

この浄化プロセスでは、すべての制御文字や双方向テキスト制御記号を除去し、フェンスのマークを偽装しようとする試行を削除します。また、人間の会話ラウンドや大規模言語モデルのツール呼び出しを模倣した「テキスト爆弾」も分解し、全体の長さを制限して、悪意ある出品がシステムコマンドに擬態したり、コンテキストウィンドウを悪意を持って埋め尽くそうとするのを防ぎます。

そしてプロンプトは契約のもう一方の側面を果たします：フェンス内のコンテンツは報告資料としてのみ使用でき、実行命令として利用することは絶対にできません。

評価：非決定性システム (Non-deterministic System) のリリース方法

提示词のわずかな修正やツールの追加だけで、AI エージェントの挙動が予測不能な変化を遂げることがあります。また、新しくリリースした機能は無事でも、既存の機能が壊れてしまう（後退する）ケースも珍しくありません。こうしたリスクを検出するのが「評価 (Eval)」です。本番環境へのリリース前に問題を見つけ出すための検知器として機能します。

Anthropic のエンジニアリングブログで公開した AI エージェントの評価 記事では、一般的なベストプラクティスについて詳しく解説しています。ここでは、特に EC（電子商取引）向け AI エージェントの評価に焦点を当てて解説します。

「完全な会話」ではなく「スナップショット (Snapshots)」で評価する

モデルの API は本質的にステートレス（状態を持たない）です。つまり、エージェントが最終的に何を出力するかは、システムプロンプト、利用可能なツールのリスト、そして現在表示されているメッセージ配列（会話履歴）によってのみ決定されます。これは、EC におけるあらゆる会話の状態を、手動で再現可能であることを意味します。

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

次に、出力された結果に対して採点を行います。評価の対象は最終的な状態と、レンダリングされた回答（最後に実行された操作に含まれるパラメータも含む）です。ほとんどの場合、その結果に至るまでの「経路」自体を評価することは強く推奨されません。なぜなら、そのようなテスト用例は非常に脆弱であり、テストの範囲が狭まってしまうからです。

別の大規模言語モデル (LLM) にユーザーを演じさせ、もう一つの「審判用モデル」が会話全体にスコアをつける「シミュレーション型評価」という手法がありますが、これは精密な測定のための適切なツールではありません。非確定的なシステム（同じ入力でも出力が異なる可能性があるモデル）同士が相互作用する場合、有意義な結論を得るには膨大なサンプル数が必要になります。単発のテストではコストが高くつき、評価基準も統一しにくく、問題が発生してもどこで失敗したのか特定できないという欠点があります。

この手法の最大の価値は、網羅されていない領域を発見する「教育」として、あるいはエージェント全体の雰囲気や傾向を把握するための「概観」に役立ちます。したがって、新しいエッジケースを見つける際には活用すべきですが、それらをコードとして実装する際は、必ず個々のケースを静的な「スナップショット」として記述してください。

悪条件下でのシステム挙動テスト

多くのチームは、注入された状態のテストを十分に実施できていません。優れたテストケースとは、単にタスクを投げるだけでなく、システムがクラッシュする「悪条件」をシミュレートするものです。特定の動作が、最初の数回で十数回のツール呼び出しが行き交う混乱した状況や、会話初期に矛盾した条件が発生した場合にのみ顕在化するなら、「クリーンな初期状態」から常に起動するテストケースは、あらゆる設定下で合格点を与えられ、何ら有用なデータを提供できません。

我々が目にする多くの評価スイートには、こうした「過度に清潔な」ケースが溢れています。必ずテストライブラリに、長く複雑で混乱を極め、時には相互矛盾する履歴対話から始まるケースを一定割合含めるようにしてください。

多様な电商評価用例のカバー

効果的な評価では、「システムがどうあるべきか」だけでなく、「システムがどうあってはならないか」もテストする必要があります。

あなたが記述したすべての「ポジティブな期待値を持つ用例」に対して、必ず「ネガティブなリスク領域の用例」を一つ追加してください。「サービスを提供すべき」ケースをテストするなら、「機密用語に遭遇した場合に毅然と拒否するべき」ケースもテストします。「直接実行すべき」ケースをテストするなら、「条件が整わない場合に自ら質問して確認すべき」ケースもテストします。ネガティブなリスク領域のテストを欠いていることは、我々が目にしたテストスイートで最も普遍的な欠陥です。

以下の主要な次元について評価を行ってください：

核心高频请求

これらはあなたのトラフィックの大部分を占めるものであり、ここで失敗すればほぼすべてのセッションに影響が及びます。単純な情報照会から、複数の制約条件を持つ検索、商品やパッケージに関する問い合わせ、そして一つのメッセージに複数の意図が含まれるような複雑なリクエストまでが含まれます。

照会タスクにおいては、各見積もり、在庫データ、属性説明のすべてが実際のデータソースに遡って検証できるか重点的にチェックする必要があります。もしデータが存在しない場合は、AI エージェントは率直に「わからない」と認め、ありえない情報をでっち上げるような「ハルシネーション（幻覚）」を起こしてはいけません。

文脈依存型リクエスト

例えば、ユーザーが画面上のものを指差して指示を出したり、数輪前の会話で設定した制限条件を引き継いだり、既存のカート内容を変更しようとするケースです。このカテゴリには「記憶」の評価も含まれます。システムが記憶を正しく抽出・検索できているか、そしてその記憶が実際に最終回答に反映されているかを検証する必要があります。

セキュリティとブランドの底线に関するユースケース

ここで失敗すれば、失われるのは真金白银（資金）か、ユーザーからの信頼です。具体的には、悪意あるプロンプトインジェクション攻撃や、他ユーザーのデータを盗もうとする不正な権限逸脱試行、そして厳格に規制された法的条項に関する問い合わせなどが該当します。これらについては、1 バイト単位での正確な照合が必須となります。

インジェクション攻撃は、重点的に扱うべき2 つの種類に分けて対処する必要があります。

1. ユーザー発生のインジェクション: 悪意ある指示が直接、ユーザーのチャット入力欄に記述されるケースです。
2. データ層からのインジェクション: 悪意ある指示が商品名やコメント欄、ウェブページの断片などに忍ばされ、ツールによる照会結果としてシステム内に持ち込まれるケースです。

インターフェース評価

正しくレンダリングされたフロントエンドコンポーネントが表示されているか確認し、商品の数量上限が厳守されているかをチェックしてください。また、ユーザーからのテキスト入力に対して内部の不明な ID や文字化けが露呈しないよう注意が必要です。タイムアウト処理や空の結果表示についても、忘れずにテストに含めてください。

複数の能力領域を跨ぐクロスリクエスト

あるオペレーターから「この商品の価格を 15% 値下げした場合、増大する需要に対して現在の在庫で十分か？」という質問が来たとしましょう。これは価格設定と在庫管理の両方の知識を必要とするケースです。

完璧な回答は、「値下げのドラフトを作成し、ついでに在庫消費の予測表も添付して提供する」ことです。一方、失敗したエージェントは片方しか実行せず、もう片方をすっかり忘れてしまいます。もし各能力モジュールごとに個別に評価基準を設けているとすれば、このようなミスを捉えることはできません。なぜなら、各モジュールは自分たちの担当範囲内でのみ採点を行うからです。

したがって、隣接する 2 つの能力が「合体」して初めて解決できるリクエストに対しては、統合テストケースを作成し、両方の部分の完成度を総合的に評価する必要があります。

ビジネス専門家と共に評価を設計し、実際のオンライン事故から学ぶ

最前線で直面している分野の専門家（SMEs）と緊密に協力してください。具体的には、プロダクトマネージャー、法務部門、マーチャント運営担当者、カスタマーサポートチーム、そしてカテゴリ管理チームなどです。

実際のオンラインでの事故をテストケースとして取り込むのは非常に有効な手法です。各主要なユーザーフローにおいて、初期段階で 50〜100 個のテストケースを集めることが、信頼性の高い基準線となります。

前述した通り、テストケースの多様性を確保することが不可欠です。本番環境での実際のチャットログは、新しいテストケースを発掘するための富んだ鉱山であり、特に奇妙で難解な会話から多くのヒントが得られます。コード作成に長けた AI エージェントは、テストケースの拡張や敵対的なバリアントの生成を得意としています。

私たちが提供する 参考コードリポジトリ には、Claude Code プラグインを活用した「自動評価用例作成」機能が含まれており、これはまさに今回推奨するアプローチを採用しています。

大規模組織内での共同リリース

大規模な EC 企業において、このスーパーエージェントは複数の独立したエンジニアリングチームによって構成されることが一般的です。検索チーム、決済チーム、価格設定チーム、マーケティング技術チーム、カスタマーサポートチーム、そして商品カタログの中核チームなど、各チームがエージェントが依存する基盤システムをそれぞれ管理しています。

各チームには独自のリリーススケジュールがあり、新しいツールの追加や機能の変更、あるいはプロンプトへの「必須遵守」ルールの追加などを望む傾向があります。

このエージェントは API で分離されたマイクロサービスではないため、内部に他者を隔てる明確な境界線が存在しません。価格設定チームが追加した新ルールも、決済チームと同一のコンテキストウィンドウを共有しているのです。

「各業務部門に子エージェントを割り当て、それぞれが独自に管理する」という誘惑的な楽観策がありますが、第 1 部で詳しく解説した通り、全体の品質を担保するためには強く推奨できません。代わりに、私たちはチーム間の連携リスクを低減するためのプロセスを提案します。

• 誰のシステムかは誰が責任を持つ。すべてのスキルとツールは、明確な所有者が一人だけ存在する必要があります。例えば、価格設定チームがすべてのプロモーションツールや価格関連のスキルを管理し、カスタマーサポートチームが注文処理、返品・交換ツール、そして顧客対応スキルを担当します。また、全社で共有される「共通プロンプト」については、プラットフォームレベルの責任者が全体統括を行い、各分野固有の部分についてはそれぞれの領域担当者が審査を行う体制とします。

新機能は必ずテストケースを添えてリリースし、CI は精選されたセットのみを実行する。

チームが新しいスキルを追加したい場合、その機能に紐づくテストケース（トラップとなるケースや、隣接する機能との競合を検出する境界ケースを含む）も同時に提出する必要があります。Pull Request ごとに数百から数千のテストをすべて実行するのは、時間がかかりすぎてストレスが溜まるだけでなく、コストも膨大になります。そのため、CI では広大なテストライブラリの中から精選されたセットを実行すべきです。

この精選セットには、最も頻繁にトラフィックが集中するコアケースと、すべての安全基準を満たすための必須ケースが含まれます。さらに、今回のコード変更で影響を受ける可能性のあるケースを別途追加します。具体的には、機能を変更した場合はその機能自体のテストと隣接機能の境界テストを実行し、ツールを変更した場合はそのツールを使用している全テストを実行します。ただし、「共有プロンプト」を変更する場合は、システム全体のプロンプトに影響が出るため、残念ながら大規模なテストスイート全体を丸ごと実行する必要があります。

単に通過率の安定性を確認するだけでなく、「キャッシュヒット率」や「1 対話あたりのコスト」といった指標にも重点的に注視することを推奨します。また、夜間やメジャーバージョンリリース前には、全テストスイートを完走させることが極めて有効なプラクティスです。チーム間の相互依存による隠れた破壊的変更は、この段階で初めて検出されることがほとんどです。

AI エージェントのリリース頻度は、全体のシステム状況と同期させる必要があります。

これは一挙に全体に影響を及ぼすデプロイ単位であり、一度でも有害な変更が公開されてしまうと、全ユーザーが即座に被害を受けます。そのため、プロンプトや機能に対するあらゆる修正は、まず限られた灰度テストユーザー（カナリアリリース）に対してのみ適用し、その後に段階的に展開すべきです。

また、バックエンドでワンクリックで特定の機能を即時停止できる「緊急停止スイッチ」を必ず用意しておく必要があります。これはリリースプロセスを経由せずに即座に機能させるためのものです。さらに、双 11（ショッピングフェスト）のようなトラフィックのピークが到来する前には、他の重要取引システムと同様に、AI エージェントへのあらゆるリリースを断固として凍結すべきです。

この仕組みの背後にある「人間」側の要素については、効率的な人間と AI エージェントのコラボレーションチームを構築する をご参照ください。

未来への展望

この記事で詳しく解説した内容のほとんどは、「大規模言語モデル（LLM）」そのものとの直接的な関係が薄いです。ツールは、すでにスムーズに稼働している既存システムを呼び出す役割を果たすだけです。スキルは、日常業務のワークフローをコードとして記述する手段です。評価スイートは、テストケースの形式で書かれた製品要件定義書そのものです。そして Harness は、クライアントに対して厳格に適用されるルールを実行する仕組みです。

モデル自体は着実に進化し、より強力なものへと発展していきます。より優れた新モデルが登場しても、今回紹介したアーキテクチャでは設定を一行変更し、評価プロセスを再実行するだけで、新しいモデルが完璧に引き継ぐことができます。それ以外のすべての要素は、引き続き安定して稼働し続けます。

製品のインターフェースが今後どう進化していくかを考えることも重要です。この基盤となるアーキテクチャの寿命は、単なる「チャットパネル」という狭い画面よりもずっと長く続きます。同じ基盤上の AI エージェントであれば、音声で対話する形に切り替えることも可能ですし、ユーザーが発言する前に価格の急落を検知して自ら購入を完了させるような能動的な行動も取れます。評価ツールや各種機能をすでに完璧に使いこなしているチームにとっては、これらは単なるフロントエンドの機能拡張に過ぎません。

さらに先を見据えると、今後あなたの店舗を訪れるトラフィックの多くは、人間ではなく、人間の代わりに買い物を代行する他の AI エージェントである可能性が高まります。そして、自社のエージェントを厳格に管理するための追跡、一時保存時の検証、承認ルールといった仕組みこそが、将来、外部のエージェントに対して API ツールを安全に開放できるという自信の源泉となるのです。

EC 業界には不変の鉄則があります。それは「ユーザーが購入するまでの道のりにあるあらゆる障壁を可能な限り取り除く」ことです。AI エージェントは、この課題をこれまでになく容易に解決します。ぜひ、私たちが提供する 完全な参考実装 をご覧ください。そこには消費者向けと事業者向けの両方のエージェントが含まれており、小売、旅行、通信、エンターテインメントなど複数の業界でそのまま動作するサンプルも用意されています。

謝辞

*著者：Matthew Koen と Ali Shazal。特に Michael Segner、Rodrigo Olivares、Amandeep Khurana、Aiza Usman、John Lopus の各位をはじめとする同僚の皆様の貢献に感謝いたします。*