投稿者 投稿日: カテゴリー Claude
Claudeのアドバイザーツールとは、実行役が上位モデルに助言を求める仕組みです。
商品説明文をAIで量産するとき、安いモデルを使えば品質が不安になり、高いモデルを使えば費用がかさみます。この板挟みに対する Anthropic の答えの1つが、Claude API のアドバイザーツールです。処理の大半は速くて安い「実行役」のモデルが担い、方針に迷う場面だけ上位の「助言役」のモデルに相談します。ただし、これは書き終わった文章を別のAIが見直す「二重チェック」とは仕組みが違い、使いどころを間違えると費用だけが増えます。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）の現場知見にもとづき、アドバイザーツールの仕組みと、商品説明の品質を守るための二重チェックとの使い分けを、設定例とプロンプト4本つきで解説します。
アドバイザーツールはどう動くのか
アドバイザーツールは、実行役のモデルが作業の途中で、必要だと判断したときに助言役のモデルを呼び出す仕組みです。呼び出しから助言の受け取りまでが、1回のAPIリクエストの中で完結します。
Claude の公式ドキュメントによると、アドバイザーツールは2026年11月時点でベータ提供で、リクエストに advisor-tool-2026-03-01 というベータヘッダーを付けて使います。実行役はリクエストの最上位の model で指定し、助言役はツール定義の中の model で指定します。助言役は Claude Sonnet 4.6 以降で、かつ実行役と同等以上の能力を持つモデルである必要があり、使える組み合わせは公式ドキュメントに一覧で示されています。
動き方は次のとおりです。実行役は、ほかのツールを使うのと同じように、自分の判断で助言役を呼び出します。呼び出されると、Anthropic のサーバー側で助言役のモデルが別に推論を行います。助言役が見るのは、システムプロンプト、ツール定義、それまでの会話、ツールの結果、そしてその時点までに実行役が書いた文章を含む、やり取りの全体です。助言役自身はツールを使えず、返すのは助言の文章だけで、実行役はそれを踏まえて作業を続けます。
費用の仕組みも押さえておきます。助言役の推論は、助言役のモデルの料金で課金されます。公式ドキュメントによると、助言1回の出力はおよそ400〜700トークン、思考を含めると1,400〜1,800トークン程度が典型で、難しい課題ではさらに長くなります。応答の usage の最上位の数字には実行役の分しか含まれず、助言役の分は usage.iterations に「advisor_message」として別に記録されます。費用を集計するときは、この内訳まで見る必要があります。
助言役を呼ぶ回数は max_uses で、1回あたりの出力量は max_tokens で上限を設定できます。max_tokens は最小1,024で、公式ドキュメントは2,048から始めることを勧めています。提供先は Claude API、Claude Platform on AWS、Google Cloud 上の Anthropic 管理環境で、いずれもベータです。
「二重チェック」と何が違うのか
結論として、アドバイザーツールは作業の途中で方針を相談する仕組みで、書き上がった文章を後から検査する二重チェックの代わりにはなりません。EC事業者が商品説明の品質を担保するには、両者を使い分ける必要があります。
公式ドキュメントは、アドバイザーツールが向いている用途として、複雑な作業を Sonnet クラスの実行役でこなしつつ Opus クラスに助言させる使い方や、コーディング、コンピューター操作、多段階の調査のような長い工程のエージェント作業を挙げています。反対に、向かない用途として、計画の余地がない1回きりの質問応答をはっきり挙げています。
商品説明に当てはめると、1商品の説明文を1回のリクエストで書かせるだけの作業は、計画の余地がほとんどないため、アドバイザーツールの効果は出にくいと考えられます。一方、商品マスタを読み、ジャンルごとに訴求の方針を決め、50商品分の説明文を書き、表現のルールに照らして直す、という長い工程をエージェントに任せる場合は、方針を決める場面や判断に迷う場面で助言役が効いてきます。
もう1つ見落としやすい点があります。公式ドキュメントによると、新しい世代の実行役（Sonnet 5.5、Opus 5.5、Fable 5.1 など）と組み合わせる助言役は、助言の中身を暗号化した形で返します。この場合、助言の文章をレスポンスから読むことはできません。「AIが何を根拠に表現を直したか」を記録に残したい事業者にとっては、助言の中身が監査できないことになります。表現の可否を記録として残す必要がある工程は、後から独立して行う二重チェックで担保するのが確実です。
二重チェックとは、書き上がった商品説明を、別のリクエストで、別の観点から点検させる工程のことです。薬機法や景品表示法に触れる表現、楽天市場や Amazon の規約に反する表現、商品データと食い違う数字などを、チェック専用の指示で洗い出させます。こちらは結果をそのまま記録に残せます。
整理すると、アドバイザーツールは「書く途中の判断の質」を上げる仕組み、二重チェックは「書いた結果の安全性」を確かめる仕組みです。商品説明の量産では、長い工程のエージェントにはアドバイザーツールを、公開前の最終確認には二重チェックを、という組み合わせが現実的です。モデルの選び方全体についてはClaudeモデルの選び方とEC業務別の使い分けで整理しています。
商品説明の量産に組み込む設定とプロンプト4本
結論として、設計は「実行役に助言を求めるタイミングを教える」「助言の回数と量に上限を付ける」「公開前に独立した二重チェックを通す」の3点で組みます。
まず設定です。Messages API のリクエストに、ベータヘッダーとして advisor-tool-2026-03-01 を付け、tools に次のようなツール定義を加えます。助言役のモデルIDは、公式ドキュメントの組み合わせ表で実行役と組めるものを選びます。
"tools": [
{
"type": "advisor_20260301",
"name": "advisor",
"model": "{助言役のモデルID}",
"max_uses": 3,
"max_tokens": 2048
}
]
max_uses は、1ターンで助言役を呼べる回数の上限です。指定しないと無制限になるため、量産の工程では必ず設定してください。会話全体での上限は組み込まれていないので、長いエージェント処理では自社の側で回数を数える必要があります。
ここからは、この設定と組み合わせて使うプロンプトを4本紹介します。1本目は、実行役のシステムプロンプトに入れる「助言を求めるタイミング」の指示です。実行役が自分の判断で助言役を呼ぶ仕組みなので、どんな場面で呼ぶべきかを言葉で伝えておくことが品質と費用の両方に効きます。
プロンプト1：実行役のシステムプロンプト（助言を求めるタイミング）
あなたはEC店舗{店舗名}の商品説明文を作成する担当です。
作業中、次の場面では advisor ツールを使って助言を求めてください。
1. 商品ジャンルごとの訴求方針を最初に決めるとき
2. 効果や効能に触れそうな表現を使うか迷ったとき（化粧品、健康食品、雑貨の機能表現など）
3. 商品データ同士が食い違っていて、どちらを採用するか判断できないとき
次の場面では助言を求めず、自分で進めてください。
- 文字数の調整、語尾の統一、改行位置の調整
- すでに決めた方針どおりに書き進める作業
助言を受けた場合は、その助言を踏まえて方針を決め、同じ迷いで繰り返し助言を求めないでください。
2本目は、エージェントに渡す商品説明の量産指示です。工程を段階に分けて書くことで、実行役が「方針を決める場面」を認識しやすくなります。
プロンプト2：商品説明の量産指示（エージェント用）
添付の商品マスタ（{件数}件、{モール名}向け）をもとに、商品説明文を作成してください。
工程：
1. 商品をジャンルごとに分け、ジャンルごとの訴求方針を決める
2. 各商品の説明文を{文字数}字程度で書く。商品マスタにない情報は書かない
3. 書き終えたら、表現ルール（下記）に照らして自分で見直す
表現ルール：
- 「最高」「No.1」「必ず」など根拠のない最上級表現や断定表現を使わない
- 化粧品・健康食品では、効果・効能をうたう表現を使わない
- サイズ、素材、容量は商品マスタの値をそのまま使う
出力：商品管理番号ごとに説明文を出し、最後に「判断に迷った商品」とその理由を一覧にしてください。
3本目は、公開前の二重チェック用のプロンプトです。アドバイザーツールとは別のリクエストで、書き上がった説明文だけを点検させます。点検役は、書いたモデルと別の観点を持たせるため、役割を明確に分けて指示します。
プロンプト3：公開前の二重チェック（独立した点検）
あなたはEC商品ページの表現チェック担当です。文章は書き直さず、問題の指摘だけを行ってください。
添付の商品説明文（{件数}件）と商品マスタを照らし合わせ、次の観点で点検してください。
1. 薬機法・景品表示法上、問題になりうる表現（効果効能、最上級表現、根拠のない比較）
2. {モール名}の規約で問題になりうる表現（外部サイトへの誘導など）
3. 商品マスタとの食い違い（サイズ、素材、容量、価格、原産国）
4. 誤字脱字、同じ表現の不自然な繰り返し
出力：問題のある商品管理番号、該当箇所、問題の種類、深刻度（高・中・低）を一覧にしてください。
問題がない商品は「問題なし」とだけ書いてください。判断に迷うものは「要人間確認」としてください。
4本目は、アドバイザーツールを入れたことで品質が本当に上がったかを確かめるための評価プロンプトです。同じ商品群について、助言ありと助言なしで作った説明文を比べます。
プロンプト4：助言あり・なしの品質比較評価
同じ商品{件数}件について、作成方法の違う2種類の商品説明文があります。
- A：{作成方法A}
- B：{作成方法B}
どちらがどちらかは伏せたまま、各商品について次の4項目を5段階で採点してください。
1. 商品マスタとの正確さ
2. 表現ルールの順守
3. 購入を検討する人にとっての分かりやすさ
4. ジャンル内での訴求の一貫性
出力：商品ごとの採点と、A・Bそれぞれの平均点、差が大きかった商品の特徴を3つまで書いてください。
プロンプト4では、評価する側に作成方法を明かさないことが大切です。どちらが上位モデルの助言を受けたかを知っていると、評価が甘くなるおそれがあります。
運用でよくある失敗例と回避策
結論として、アドバイザーツールの失敗は「上限を付けない」「費用の数字を見誤る」「向かない作業に使う」の3つに集約されます。
1つ目は、max_uses を設定せずに量産を回すことです。実行役が迷うたびに助言役を呼ぶと、助言役の料金で費用が膨らみます。回避策は、プロンプト1のように呼ぶ場面を限定したうえで、max_uses に上限を付けることです。最初は2〜3回から始め、品質の評価を見ながら調整するのが定石です。
2つ目は、応答の usage の最上位の数字だけで費用を計算することです。公式ドキュメントのとおり、最上位の数字には実行役の分しか入っていません。助言役の分は usage.iterations に別に記録されるため、ここを集計に入れないと、実際の請求額より安く見積もってしまいます。トークン数を事前に見積もる機能も実行役の最初の分しか返さないため、助言役の分は別に見積もる必要があります。
3つ目は、1商品ずつ単発で説明文を書かせる作業にアドバイザーツールを使うことです。公式ドキュメントも、計画の余地がない単発の質問応答は向かないとしています。単発の作業で品質を上げたいなら、プロンプト3の二重チェックを通すほうが、費用に対する効果がはっきりします。
もう1点、長い処理の途中で助言の呼び出しが終わらないまま応答が止まり、stop_reason が pause_turn になることがあります。この場合は、返ってきた内容をそのまま送り返して続きを処理させます。ツール定義を外して送り返すとエラーになるため、自動化の仕組みに組み込むときは注意してください。
KPI設計と費用・工数の目安
結論として、アドバイザーツールの導入効果は「二重チェックで指摘される件数」と「100商品あたりの費用」の2つで判断するのが分かりやすいです。
品質の指標には、プロンプト3の二重チェックで「深刻度：高」と指摘される件数を使います。アドバイザーツールを入れる前と後で、同じジャンルの商品群について比べれば、助言が品質に効いているかが分かります。指摘がほとんど減らないなら、助言のタイミングの指示を見直すか、アドバイザーツールをやめて二重チェックだけに絞る判断も十分ありえます。
費用は、実行役の料金、助言役の料金、二重チェックの料金の合計で見ます。公式ドキュメントが示す典型値で考えると、助言1回の出力は400〜700トークン程度で、100商品の量産で助言を10回呼ぶなら、助言役の出力は4,000〜7,000トークン程度、思考を含めても1万数千トークン規模に収まる計算です。助言役は会話全体を読むため、入力側のトークンは会話が長くなるほど増える点に注意が必要です。長い処理では、助言役側のキャッシュを有効にすると、公式ドキュメントの目安では1つの会話で3回程度呼べば元が取れるとされています。モデル別の単価は公式の料金ページで確認してください。
工数は、既存の商品説明生成の仕組みにツール定義とシステムプロンプトを加えるだけなら、エンジニア1人で1〜2日が目安です。品質比較の評価を1回回すのに、さらに半日ほどを見込んでください。処理費用全体を抑える手法はClaude公式が示すコスト削減の4レバーも参考になります。
今後の展望：モデルの組み合わせが前提の時代へ
結論として、今後のAI活用は「どのモデルを使うか」から「どのモデルをどう組み合わせるか」へと考え方が移っていくと見ています。
アドバイザーツールは、速くて安いモデルと賢いモデルを1つのリクエストの中で組み合わせる仕組みを、API の標準機能として提供した点に意味があります。これまでは、複数のモデルを使い分けるには、事業者側で処理を分けて呼び出す仕組みを作る必要がありました。Managed Agents でも、エージェントの設定で助言役を指定できるようになっており、組み合わせの設計はさらに手軽になっています。
一方で、ベータ提供である以上、仕様や料金、提供範囲は変わる可能性があります。助言の中身が暗号化されて読めない組み合わせが増えている点も、品質の説明責任を重視するEC事業者にとっては見逃せない変化です。AIの判断の中身が見えなくなるほど、公開前の独立した点検と、その結果の記録の価値は上がっていきます。複数のAIに作業を分担させる設計については、Claude Codeのマルチエージェントで商品ページを並列処理する方法もあわせてご覧ください。
よくある質問
Claudeのアドバイザーツールとは何ですか？
Claude のアドバイザーツールとは、速くて安い実行役のモデルが、作業の途中で上位の助言役のモデルに相談できる仕組みのことです。呼び出しから助言の受け取りまでが1回のAPIリクエストの中で完結します。2026年11月時点ではベータ提供です。
アドバイザーツールで商品説明の二重チェックはできますか？
いいえ、書き上がった文章を後から検査する二重チェックとは仕組みが違います。アドバイザーツールは作業の途中で方針を相談するもので、新しい世代の組み合わせでは助言の中身も読めません。公開前の点検は、別のリクエストで独立した二重チェックを行うのが確実です。
費用は高くなりますか？
助言役を呼んだ分だけ、助言役のモデルの料金が加わります。ただし処理の大半を安い実行役が担うため、上位モデルだけで処理するより総額を抑えられる場合があります。応答の usage の最上位の数字には助言役の分が含まれないため、usage.iterations まで集計してください。
どのモデルを組み合わせればよいですか？
助言役は Claude Sonnet 4.6 以降で、実行役と同等以上の能力を持つモデルを選ぶ必要があります。使える組み合わせは公式ドキュメントに一覧があり、時期によって変わります。導入前に最新の組み合わせ表を確認してください。
1商品ずつ説明文を書く作業にも使うべきですか？
いいえ、単発の作業には向きません。公式ドキュメントも、計画の余地がない1回きりの質問応答は向かない用途として挙げています。単発の作業の品質を上げたい場合は、二重チェックを通すほうが効果を確かめやすいです。
Amazon BedrockでClaudeを使っている場合も使えますか？
公式ドキュメントでは、提供先は Claude API、Claude Platform on AWS、Google Cloud 上の Anthropic 管理環境とされています。Amazon Bedrock での提供は、この一覧に含まれていません。利用中の環境で使えるかどうかは、各サービスの最新情報で確認してください（要確認）。
まとめ
Claude のアドバイザーツールは、安い実行役が判断に迷う場面だけ上位の助言役に相談する仕組みで、長い工程のエージェント作業で品質と費用の両立を狙えます。ただし、書き上がった商品説明を点検する二重チェックの代わりにはならず、単発の作業には向きません。EC事業者は、量産のエージェントにはアドバイザーツールを、公開前の最終確認には独立した二重チェックを組み合わせるのが現実的です。まずはプロンプト3の二重チェックを今の運用に入れ、指摘件数を測るところから始めてください。
参考文献
- Claude Platform Docs「Advisor tool」
- Anthropic「The advisor strategy: Give agents an intelligence boost」
- Claude Code Docs「Advisor」
著者：齋藤竹紘（株式会社オルセル 編集長／5,000社以上のEC支援実績／書籍3冊）
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
