AIエージェントが買う時代に、自社に残る顧客データは何か
エージェンティックコマースで店に渡る顧客データは、名前・メール・電話番号・住所など注文に要る情報までで、何と比べてなぜ選んだかは渡りません。OpenAIの仕様書とShopifyの記述をもとに、自社で持てる3つの打ち手を順に整理しました。
読むチャットボットを高度化すれば、効果は出るのか
結論：先に見るのは「賢さ」より「業務の分け方」
チャットボットを入れてしばらく経つと、こう言われることがあります。「問い合わせは減ったが、思ったほどではない」。私たちが入る案件では、この段階で「もっと賢いAIに替える」という案が出ることがあります。
私たちが先に見るのは、AIの賢さではなく、業務の分け方です。すでに動いているものを止める話ではありません。どこを分けるかを1つ決める話です。
根拠にしたのは、AIモデルを作っているAnthropicの記事です。AIエージェントを作る数十のチームと仕事をしてきたとしたうえで、「一貫して、最もうまくいっている実装は複雑なフレームワークや専用のライブラリ（開発の土台になる既製の部品群）を使っていませんでした。かわりに、単純で組み合わせ可能なパターンで作られていました」と書いています。高度なものを1つ入れるのではなく、単純なものを組み合わせる。これは「もっと賢いものに替える」の逆の向きです（この読み方は私たちのものです）。
具体：問い合わせ窓口で言うと、こうなる
身近な例は、問い合わせ窓口です。「返品したい」「配送はいつ届くか」「使い方が分からない」── 種類ごとに担当を分けて受けるのと、1人が全部を受けて毎回考えるのとでは、同じ人数でも回り方が違います。チャットボットも同じで、先に業務を分けてあるかどうかで効き方が変わる、というのが私たちの見立てです（種類ごとに担当を分けるか、1人が全部を受けるか、という言い方は私たちのものです）。
Anthropicの記事には、組み合わせ方のパターンが5つ挙がっています。日本語にするとこうなります（呼び名は私たちが付けたもので、原文にはありません。各行の例も原則として私たちのものですが、振り分ける型だけは原文にも近い例があるので、その旨を添えました。「5つ」と数えたのも私たちです）。
- つなげる型（prompt chaining）── 前の出力を次に渡す。「用件を聞く→内容を確認する→回答を作る」と順番に進める
- 振り分ける型（routing）── 入力を分類して、担当へ振り分ける。「返品」「配送」「使い方」に分けてから、それぞれの手順へ渡す。原文も振り分ける型の例として、カスタマーサービスの問い合わせ（一般的な質問・返金依頼・技術サポート）を別々の処理へ振り分けることを挙げています
- 同時に走らせる型（parallelization）── 同時に走らせて集める。1つの質問を複数の観点で同時に見て、結果をまとめる
- その場で割る型（orchestrator-workers）── 中心が動的に仕事を割って、結果を統合する。用件を見てから、何をどの順で進めるかを決める
- 見て直す型（evaluator-optimizer）── 生成と評価をループさせる。回答を作り、別の役が採点し、直す
5つのうち、実務でいちばん迷うのが「振り分ける型」と「その場で割る型」です。どちらも「複数の処理に分ける」ように見えます。振り分ける型は、種類が先に決められ、かつ正確に振り分けられるとき。その場で割る型は、何をすればよいか（必要な作業）が先に決められないときです。問い合わせ窓口で言えば、「返品・配送・使い方」に最初から分けられるなら振り分ける型。用件は分かっても、何をどの順で確認するかが毎回変わるなら、その場で割る型の側です（この対比は私たちの整理で、原文がこの2つを並べて論じているわけではありません）。
なお原文は振り分ける型の例に、難しい質問だけを高性能なモデルへ回す使い方も挙げています。賢いモデルを使わないという話ではなく、どこに使うかを先に分ける、という順番の話です（この整理は私たちのものです）。
いま動いているものに、何を足すか
ここからは私たちの進め方です。すでに動かしている場合も、決め直せます。3つあります。
- 問い合わせを、種類に分けられるかを試す。直近1か月分の問い合わせログを開いて、上から順に「返品」「配送」のように種類を書いていきます。明確な種類に分かれ、かつ迷わず振り分けられるなら、振り分ける型の使いどころです。分かれないなら、そこは先に分けられない業務です。分けきれていないところと、効果が出ていないところは、重なることがあります（私たちの見立てです）
- 1件の用件が、固定の手順で終わるかを見る。終わるならつなげる型。終わらないなら、下位タスクを予測できない側です。ここを取り違えると、固定の手順に収まらない用件がこぼれやすくなります
- 「良い回答」の基準を、先に1つ書く。見て直す型は、原文で「明確な評価基準があり、反復的な改善が測れる価値をもたらすとき」にとりわけ有効とされています。基準が無いまま自動で直させる仕組みを入れても、何に向かって直しているかが決まりません
賢さより、分け方に判断が寄ります。どこを固定してどこをAIに任せるかはAIエージェントとワークフローは、何が違うのかで、費用がどこで動くかはAIエージェントの費用は、何で決まるのかで扱いました。
根拠：Anthropicの記事は、何と書いているか
上の整理の根拠です。要点を先に書いてから引用します。
うまくいっていたのは「単純で組み合わせ可能なパターン」
要点は「一貫して、うまくいっていたのは、複雑なフレームワークや専用ライブラリを使ったところではなく、単純なものを組み合わせたところだった」です。
一貫して、最もうまくいっている実装は複雑なフレームワークや専用のライブラリを使っていませんでした。かわりに、単純で組み合わせ可能なパターンで作られていました
── Anthropic「Building effective agents」（2024年12月19日公開／2026年8月28日取得）。原文は原文［1］に置きました。
土台になる部品も定義されています。「エージェント的なシステムの基本的な構成部品は、検索・ツール・記憶といった拡張によって強化されたLLMです」。LLMとは大規模言語モデルのことで、文章を扱うAIの土台です。つまり「何を検索させ、どのツールを持たせ、何を覚えさせるか」が部品の中身になります（この言い換えは私たちのものです）。
5つのパターンの定義と、いつ使うか
原文の定義と「いつ使うか」を、表に並べます。実務で見るのは「いつ使うか」のほうです（私たちの進め方です）。
| パターン | 定義（原文） | 使いどころ（原文） |
|---|---|---|
| prompt chaining つなげる | 「Prompt chaining decomposes a task into a sequence of steps, where each LLM call processes the output of the previous one.」（タスクを一連のステップに分解し、各LLM呼び出しが前の出力を処理する） | 「…the task can be easily and cleanly decomposed into fixed subtasks」（固定された下位タスクに、簡単かつきれいに分解できる） |
| routing 振り分ける | 「Routing classifies an input and directs it to a specialized followup task.」（入力を分類し、それに特化した後続のタスクへ振り分ける） | 「別々に扱ったほうがよい明確なカテゴリがあり、かつ分類を正確に扱える複雑なタスクでうまく働く」 |
| parallelization 同時に走らせる | 「LLMs can sometimes work simultaneously on a task and have their outputs aggregated programmatically.」（LLMが同時に作業することがあり、その出力をプログラム的に集約する） | 「…the divided subtasks can be parallelized for speed, or when multiple perspectives or attempts are needed for higher confidence results」（分割した下位タスクを速さのために並列化できるとき、あるいは複数の視点や試行が必要なとき） |
| orchestrator-workers その場で割る | 「a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results」（中心のLLMが動的にタスクを分解し、作業側のLLMに委ね、結果を統合する） | 「…complex tasks where you can’t predict the subtasks needed」（必要な下位タスクを予測できない複雑なタスク） |
| evaluator-optimizer 見て直す | 「one LLM call generates a response while another provides evaluation and feedback in a loop」（一方が応答を生成し、もう一方が評価とフィードバックをループで返す） | 「…we have clear evaluation criteria, and when iterative refinement provides measurable value」（明確な評価基準があり、反復的な改善が測れる価値をもたらすとき） |
パターン名の下の日本語（つなげる・振り分ける等）は私たちが付けた呼び方です。「使いどころ」の列は原文の「When to use this workflow」から該当部分を抜き出しました。「5つ」と数えたのは私たちで、原文が数え上げているわけではありません。
よくある質問
チャットボットの効果が出ないのは、精度が低いからですか？
精度だけの問題とは限りません。Anthropicは「一貫して、最もうまくいっている実装は複雑なフレームワークや専用のライブラリを使っていませんでした。かわりに、単純で組み合わせ可能なパターンで作られていました」と書いています。複雑なフレームワークを使った側がうまくいっていた、とは書かれていません。同じ記事は組み合わせるパターンを5つ挙げ、それぞれに「使いどころ」を示しています。業務の分け方が先だ、というのが私たちの読み方です。これは業界共通の分類ではなく、Anthropicがこの記事の中で挙げているパターンです。（出典：Anthropic「Building effective agents」）
routing と orchestrator-workers は、何が違うのですか？
使いどころが違います。routing は「別々に扱ったほうがよい明確なカテゴリがあり、かつ分類を正確に扱える複雑なタスクでうまく働く」とされ、orchestrator-workers は「complex tasks where you can’t predict the subtasks needed」（必要な下位タスクを予測できない複雑なタスク）に向くとされています。カテゴリを先に決められるかどうかで分かれる、という対比は私たちの整理で、原文がこの2つを並べて論じているわけではありません。（出典：Anthropic「Building effective agents」）
もっと賢いAIに替えれば、解決しますか？
そうとは書かれていません。Anthropicは最もうまくいっている実装が、複雑なフレームワークや専用のライブラリを使っておらず、単純で組み合わせ可能なパターンで作られていたとしています。替える前に確かめたいのは、どのパターンで組んでいるかです。いまの問い合わせが明確なカテゴリに分かれるか（routing の使いどころ）、固定の手順で終わるか（prompt chaining の使いどころ）を見ると、足りないのが精度なのか分け方なのかが分かれます。これは私たちの進め方です。なおモデルを替えることの費用については、別の記事で扱いました。（出典：Anthropic「Building effective agents」）
自動で回答を改善させる仕組みは、入れたほうがよいですか？
評価基準があるかで変わります。Anthropicは evaluator-optimizer の使いどころを「明確な評価基準があり、反復的な改善が測れる価値をもたらすとき」としています。基準が無いまま入れても、何に向かって直しているかが決まりません。これは私たちの読み方です。（出典：Anthropic「Building effective agents」）
チャットボットに何を持たせればよいですか？
Anthropicは土台になる部品について「エージェント的なシステムの基本的な構成部品は、検索・ツール・記憶といった拡張によって強化されたLLMです」と書いています。「何を検索させ、どのツールを持たせ、何を覚えさせるか」が部品の中身になる、という言い換えは私たちのものです。なお持たせるツールの数は費用にも関わります（このページに費用の記載はなく、私たちの読みです。詳しくは別の記事で扱いました）。（出典：Anthropic「Building effective agents」）
出典と、書けなかったこと
出典と注記を開く
出典
・Anthropic「Building effective agents」ページを見る ── 最もうまくいっている実装は複雑なフレームワークを使っていなかった／基本的な構成部品は検索・ツール・記憶で強化されたLLM／5つのパターン（prompt chaining・routing・parallelization・orchestrator-workers・evaluator-optimizer）の定義と使いどころ。2026年8月28日に取得※ このページには、Anthropic自身による注記が付いています。「Note: Much of the tooling landscape described in this post has changed since December 2024.」（この記事で述べたツール周辺の多くは、2024年12月以降に変わっています）。記事の公開日は2024年12月19日です。ただしこの注記が「変わった」としているのはツール周辺であって、本稿が扱ったパターンの分類そのものではありません。本稿は分類と使いどころだけを扱い、ツールやフレームワークの選び方には触れていません。（2026年9月5日にブラウザで確認）
※ 本稿の事実は、上記1ページから取っています。他ページの記述を根拠にした箇所はありません。
※ ここで挙げた5つは、業界共通の分類ではありません。Anthropicがこの記事の中で挙げているパターンです。本稿でもそのように扱いました。
※ 「5つ」と数えたのは私たちで、原文が数え上げているわけではありません。同ページは「Workflow:」と題した節を並べており、このほかに土台となる augmented LLM と、エージェントそのものを別の節で扱っています。
※ パターン名に添えた日本語（つなげる・振り分ける・同時に走らせる・その場で割る・見て直す）は私たちが付けた呼び方で、原文にはありません。原文のパターン名は英語表記のみです。
※ 「先に分けられるか／分けられないか」という2列の整理、routing と orchestrator-workers を並べた対比、「基準が無い業務では回りにくい」という読み方、「何を検索させ・どのツールを持たせ・何を覚えさせるか」という言い換えは、私たちのものです。原文がこう書いているわけではありません。
※ 本稿に金額は出てきません。このページに金額の記載はありません。費用については別の記事で扱っています。
※ このページは英語のみで、日本語版は確認できていません。日本語はすべて私たちの訳です。判断に関わる箇所は原文を併記しました。
引用した原文
原文を開く
［原文］訳の元になった文
［1］Anthropic ── 最もうまくいっている実装
Consistently, the most successful implementations weren’t using complex frameworks or specialized libraries. Instead, they were building with simple, composable patterns.
── Anthropic「Building effective agents」（2024年12月19日公開／2026年8月28日取得）
執筆者
永野 陽平
お問い合わせ
御社の現在地を教えてください。
7つの質問で、御社の顧客がいま資産に変わっているかが分かります。
3分・登録不要。結果を見てからご相談いただけます。