社内でAI活用の話が進むと、次のような提案が出ることがあります。「在庫が減ったら自動で発注させましょう」「競合が下げたら価格も自動で追随させましょう」
止める理由をうまく説明できないまま、なんとなく見送りになることが多い議論です。反対する側も「危ないから」以上の言葉を持っていません。実際には危ないのは自動化そのものではなく、間違えたときに誰も気づけない作りにすることなのですが、その差を設計として示すのは簡単ではありません。
Anthropic が公開した商取引向けエージェントの設計図は、この線引きの実装例として読む価値があります。
公開されたのは、動くコードの形をした設計図
2026年9月3日、Anthropic は Claude Commerce Agents をオープンソースとして公開しました。ライセンスは Apache 2.0 です。
含まれているのは2種類のエージェントです。ひとつは消費者側で、商品を検索し、比較し、カートに入れるところまでを担います。もうひとつは事業者側で、販売状況・在庫・価格・販促の管理を扱います。小売、旅行、通信、エンターテインメントの参照実装が付いており、ゼロから組む代わりの出発点として使える形になっています。
動作環境は Python 3.11 以降と Node 22、それに API キーを用意すればローカルで動きます。実行基盤も Claude API に固定されておらず、Amazon Bedrock、Microsoft Foundry、Google Cloud Vertex AI でも同じコードが動くとされています。
これは自社で保守する参照実装です。Anthropic の公式案内でも、サポート付きの製品や SLA があるサービスとは区別されています。導入効果は自社の商材・業務で評価する必要があります。
実装で参考になるのは、できることより「させないこと」
機能一覧より重要なのは、事業者側エージェントの権限の切り方です。
このエージェントは、価格の調整、在庫の補充、キャンペーンの変更について、提案を生成するところまでしか行いません。 実際に反映するには人の承認が要ります。
注目すべきなのは、その制約の置き場所です。支払い、商品の調達、価格変更の上限、人による承認といったルールは、プロンプトによる指示ではなくコードのレベルで強制されています。
この差は実務で決定的です。プロンプトに「価格は10%以上下げないこと」と書く方式は、モデルが指示を取り違えたとき、あるいは入力に細工があったときに破れます。破れたかどうかを事後に判定するのも困難です。一方、実行側で承認者と承認対象を検証し、モデル自身が承認状態を書き換えられないようにすれば、モデルの指示解釈に頼らず制御できます。単に承認済みフラグを置くだけでは不十分で、迂回できる更新経路も塞ぐ必要があります。
AIエージェントを業務に入れるときの安全側の設計は、多くの場合ここに集約されます。禁止事項を言葉で増やすのではなく、危険な操作を実行側で制御する。この考え方は商取引に限りません。基幹システムにAIから直接アクセスさせる場合の権限設計でも、結論は同じところに来ます。
自社で考えるのは2方向ある
商材を扱う会社にとって、この動きは2つの側面を持ちます。
買われる側として。 商品情報がエージェントに読める形で出ているかという論点です。人が見て分かるページと、機械が構造として解釈できるページは別物です。価格・在庫・仕様が画像の中にしかないサイトは、情報を正確に取得してもらいにくくなります。ここは新しい話ではなく、これまでの構造化データの延長線上にあります。
使う側として。 在庫や価格の判断をエージェントに任せる場合、承認と実行権限の設計が重要です。承認者を決めていない、承認画面が業務時間中に見られない、承認がスタンプになっている、のいずれかが起きると、承認を挟んだ意味がなくなります。承認を仕組みとして置くことと、承認が機能することは別です。
承認の運用状況は、継続的に点検します。提案された件数のうち、差し戻された件数がどれくらいあるか。差し戻しがゼロでも、それだけで承認が形骸化しているとは判断できません。承認の所要時間、抜き取りレビュー、誤承認の有無、提案の難易度を併せて確認します。これらを確かめたうえで、承認が機能しているか判断します。
なお、こうしたエージェント基盤を自社で持つ場合の費用は、モデルの利用料だけでは収まりません。エージェント基盤を自前で組むときに見えにくいコストで整理した通り、監視・ログ・承認フローの運用が継続的に乗ってきます。決済まわりを含む場合は、決済事業者の乗り換えやすさも同時に見ておくと、後から構成を変えにくくなる事態を避けられます。
設計図があることの意味
オープンソースで参照実装が出たことの実務的な効果は、自前で作るかどうかを判断する前に、中身を読めるという点にあります。
「AIエージェントでECを効率化する」という提案を受けたとき、公開されたコードを比較材料にできます。提案に含まれる機能、独自開発が必要な部分、運用責任を具体的に確認しやすくなります。ただし参照実装ひとつが、業界全体の標準構成を定めるわけではありません。
段階的にシステムを置き換えていく進め方については、コマース基盤を段階的に載せ替える設計も合わせて確認しておくと、一度に全部を作り替える提案に流されにくくなります。
次にやること
自社の業務で、AIに任せたいと言われている作業をひとつ挙げてください。そのうえで、その作業のうち「提案までなら任せてよい部分」と「実行には人の判断が要る部分」を線で分けます。
線が引けない作業は、まだ自動化の対象にする段階ではありません。線が引けたら、次は実行側をどう塞ぐかの設計に移ります。ここまで来て初めて、見積もりの話ができる状態になります。
AIエージェントの業務適用、承認フローを含む実装設計、既存システムとの接続については、グリームハブの開発・AI・自動化のご相談で承っています。対象業務と既存構成によって進め方が変わるため、お問い合わせから個別にご相談ください。
