投稿者 投稿日: カテゴリー Gemini
反復ツール呼び出しとは、AIが外部機能を複数回呼んで答えを組み立てる動きのことです。
「このワンピースのMサイズ、ネイビーはいつ届きますか」。EC店舗に届く問い合わせのうち、在庫と納期に関するものは、担当者が在庫表、入荷予定、配送のリードタイムを順に確かめないと答えられません。2026年9月2日に一般提供が始まったGemini 3.8 Flashは、こうした「複数の情報を順に確かめて答える」作業で、ツールを何度も呼び分けながら回答を組み立てる動きが強化されたモデルです。この記事では、Gemini APIのFunction Calling（AIに自社の機能を呼び出させる仕組み）を使って、在庫確認を自動化する設計を5つの手順とプロンプト4本で解説します。費用は2026年12月31日までの導入価格を前提に、問い合わせ1件あたりの目安まで試算します。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）の現場知見にもとづいて解説します。
在庫確認の自動化でGemini 3.8 Flashが候補になる理由
在庫確認の自動化に向いているのは、速くて安く、ツールの呼び出しが安定しているモデルです。Gemini 3.8 Flashは、この3つの条件を満たす現実的な選択肢の1つです。
Google AI Studioの最新モデル一覧では、Gemini 3.8 Flash（モデルID: gemini-3.8-flash）は「日常的なアプリとエージェントの推奨デフォルト」と位置づけられています。入力は最大100万トークン、出力は最大64,000トークンで、思考の深さをlow、medium（既定）、highの3段階で選べます。Function Calling、構造化出力（あらかじめ決めた形式で回答を返させる機能）、Google検索によるグラウンディング、コード実行に対応しています。
価格は、2026年12月31日までの導入価格として、100万トークンあたり入力0.75米ドル、出力3.75米ドルと掲載されています。2027年1月以降の通常価格は、同ページでは示されていないため要確認です。同じページには、上位のGemini 4 ArgonとGemini 4 Carbonが入力2.00米ドル、出力10.00米ドル（11月30日までの導入価格）、さらに軽量なGemini 3.5 Flash-Liteが入力0.30米ドル、出力2.50米ドルで並んでいます。
3.8 Flashの特徴として業界の解説記事でよく取り上げられるのが、複雑な依頼に対して推論の段階を増やし、ツールを繰り返し呼び出す動きです。i-SCOOPの解説など複数の記事が、3.7 Flashからエージェント的な作業や多段の推論が改善したと伝えています。一方で、トークンあたりの単価が同じでも、1つのタスクで使うトークンが増えるため、タスクあたりの費用は上がりうるという指摘もあります。この点はGemini 3.8 Flashのタスク単価に関する速報で整理しています。
在庫確認は、この「繰り返し呼び出す」動きが素直に効く業務です。SKUの在庫を見て、なければ入荷予定を見て、入荷日から配送日数を足してお届け予定を出す。人が頭の中で行っている順番を、AIがツールの呼び出しとして再現できるからです。商品説明文の大量生成など、3.8 Flashの別の使い方はGemini 3.8 FlashのEC活用の解説を参照してください。
在庫確認の業務を「ツール」に分解する
自動化の成否は、モデルの性能よりも、業務をどう「ツール」に切り分けるかで決まります。Function Callingでは、店舗側が用意した機能（関数）の名前、目的、受け取る引数を宣言し、AIがその中から必要なものを選んで呼び出します。
在庫と納期の問い合わせに答えるために必要な機能は、多くの店舗で次の5つに整理できます。1つ目は、SKU（色やサイズまで特定した商品の単位）ごとの現在の在庫数を返す機能。2つ目は、入荷予定日と予定数量を返す機能。3つ目は、配送先の地域から配送日数を返す機能。4つ目は、商品名や色・サイズの言い方からSKUを特定する機能。5つ目は、受注済みで引き当てられている数量を返す機能です。
このとき大切なのは、AIに渡す機能を「読み取り専用」に限ることです。在庫数を書き換える機能や、注文を確定させる機能は、最初の段階では渡しません。問い合わせへの回答の下書きに使う範囲であれば、読み取りだけで十分に役割を果たせます。
在庫データの取り出し元は、販売チャネルによって異なります。Shopifyなら管理APIの在庫レベル、Amazonなら出品者向けのSP-APIの在庫系API、楽天市場ならRMSのWeb APIに用意された在庫系のAPIが候補になります。複数のチャネルで在庫を共有している場合は、在庫連携システム側の在庫を正として、そこから読む機能を1つ用意するほうが、チャネルごとのずれに振り回されずに済みます。
業務を分解する段階で、もう1つ決めておくべきなのが「AIが答えてはいけない質問」です。在庫が0で入荷予定もない商品の再販時期、セール価格の予定、他店との価格比較などは、ツールの結果から答えられない質問です。こうした質問には「担当者から折り返します」と返す、と最初から決めておくと、AIが推測で答える事故を防げます。
実装の5手順と、そのまま使えるプロンプト4本
ここからは、在庫確認の自動化を5つの手順で進めます。プロンプトは、設計の下準備をChatGPT、Claude、Geminiのいずれかで作るためのものと、Gemini 3.8 Flashに組み込むシステム指示の2種類です。
手順1は、過去の問い合わせから質問の型を洗い出すことです。直近1〜3か月の在庫・納期に関する問い合わせを集め、どんな聞き方が多いかを分類します。
プロンプト1：在庫・納期の問い合わせを型に分類する
あなたはEC店舗のカスタマーサポート設計を支援するアナリストです。
以下は当店に届いた在庫・納期に関する問い合わせ{件数}件です（個人情報は削除済み）。
次の作業をしてください。
1. 質問の型を10種類以内に分類し、それぞれの件数と代表的な聞き方を示す
2. 型ごとに、答えるために必要な情報（在庫数、入荷予定、配送日数など）を列挙する
3. ツールの結果だけでは答えられない型を抜き出し、「担当者対応」とする
4. 自動回答の対象にすべき型の優先順位を、件数と難易度から提案する
問い合わせ：
{問い合わせ本文を1件ずつ貼り付け}
手順2は、ツール（関数）の宣言を設計することです。手順1で洗い出した「必要な情報」から、AIに渡す機能の一覧と引数を決めます。
プロンプト2：Function Callingのツール宣言を設計する
あなたはECの在庫システムとAIの連携を設計するエンジニアです。
Gemini APIのFunction Callingで使うツール宣言の案を作ってください。
前提：
- 目的：在庫・納期の問い合わせへの回答の下書きを作る
- 渡すツールはすべて読み取り専用とする
- 在庫データの取り出し元：{例：在庫連携システムのAPI}
- 必要な情報：{プロンプト1で洗い出した情報を貼り付け}
出力してほしいもの：
1. ツールごとの名前（英語の小文字とアンダースコア）、目的の説明、引数と型、必須かどうか
2. 各ツールの説明文（AIが使い分けを判断できるよう、いつ使うかを具体的に書く）
3. ツール同士の呼び出し順の典型パターン（例：SKU特定→在庫照会→入荷予定照会）
4. 書き込み系の機能を含めていないことの確認
条件：
- 実在しないAPIの仕様を断定しない。取り出し元のAPI仕様は当社で確認する前提とする
手順3は、Gemini 3.8 Flashに渡すシステム指示を書くことです。ツールの結果だけを根拠に答えること、呼び出しの回数に上限を設けること、答えられない場合の返し方を明記します。
プロンプト3：在庫確認エージェントのシステム指示（Gemini 3.8 Flashに設定）
あなたは{店舗名}の在庫・納期に関する問い合わせに、回答の下書きを作るアシスタントです。
守ること：
1. 在庫数、入荷予定日、お届け予定日は、ツールの結果だけを根拠に書く。推測で数字を補わない
2. 商品の特定があいまいな場合は、find_sku で候補を出し、候補が複数あれば確認の質問を返す
3. ツールの呼び出しは1件の問い合わせにつき最大{回数}回までとする。上限に達したら、その時点で分かったことと「担当者から折り返します」を返す
4. 再販時期の約束、価格の予定、他店との比較には答えず、担当者対応とする
5. 回答はですます調で、200字以内にまとめる
6. 最後に、根拠にしたツールの結果（ツール名と値）を「確認メモ」として別に出力する
出力形式（構造化出力で返す）：
- reply：お客様への回答の下書き
- needs_human：担当者の確認が必要か（true／false）
- evidence：根拠にしたツール名と値の一覧
手順4は、テストケースを作って動作を確かめることです。在庫あり、在庫なしで入荷予定あり、入荷予定なし、商品の特定があいまい、という4つの状況を最低限そろえます。
プロンプト4：在庫確認エージェントのテストケースを作る
あなたはAIエージェントの品質を検証するテスト担当です。
在庫・納期の問い合わせに答えるAIエージェントのテストケースを20件作ってください。
含めてほしい状況：
1. 在庫ありで即日発送できる
2. 在庫なしで入荷予定がある
3. 在庫なしで入荷予定がない（担当者対応になるべき）
4. 色やサイズの言い方があいまいで、商品が特定できない
5. 複数の商品をまとめて聞いている
6. 再販時期や値下げ予定など、答えてはいけない質問を含む
各テストケースについて：
- お客様の問い合わせ文
- ツールが返す想定の値（在庫数、入荷予定日など）
- 期待する回答の要点と、needs_human の期待値
商品ジャンル：{ジャンル}
手順5は、運用に乗せることです。最初の1〜2か月は、AIが作った下書きを担当者が確認してから送る形にし、修正が必要だった割合を記録します。修正率が十分に下がった型から、自動送信の対象を広げていきます。
自動送信に切り替える基準は、型ごとに決めておきます。たとえば「在庫ありで即日発送できる」という型は、ツールの結果がそのまま答えになるため、修正率が早い段階で下がりやすい型です。一方、「在庫なしで入荷予定がある」という型は、入荷予定日がずれる可能性をどう伝えるかで表現の調整が続きやすく、自動送信への切り替えは慎重に判断します。型ごとに切り替えるほうが、全体を一度に切り替えるよりも事故が起きにくく、担当者の安心感も保てます。
商品ジャンルによって、ツールに持たせる情報も変わります。食品ギフトであれば、在庫数に加えて賞味期限の目安や、のし・包装に対応できる在庫かどうかが回答に必要になります。アパレルであれば、色とサイズの組み合わせごとの在庫と、取り寄せ扱いになるかどうかが焦点です。手順1の分類で、自店のジャンルに固有の質問がどれだけあるかを確かめておくと、手順2のツール設計で漏れが出にくくなります。
5手順のうち最も時間がかかるのは、手順2のツール設計と、取り出し元のAPIとの接続です。プロンプトそのものの調整は、テストケースが手元にあれば短期間で済みます。
失敗しやすいポイントと回避策
1つ目の失敗は、ツールの呼び出し回数に上限を設けないことです。反復して呼び出す動きは便利な反面、商品が特定できないまま検索を繰り返すと、1件の問い合わせで想定以上のトークンを使います。システム指示で上限回数を決め、APIを呼ぶ側のプログラムでも同じ上限をかけておくと、費用が読めなくなる事態を防げます。
2つ目の失敗は、AIが在庫数を「それらしく」答えてしまうことです。ツールがエラーを返したときや、タイムアウトしたときに、直前の会話から推測した数字を書いてしまうケースがあります。回避策は、プロンプト3のように「ツールの結果だけを根拠にする」と明記し、さらに根拠にしたツール名と値を別の欄に出力させることです。担当者は根拠欄を見るだけで、回答の正しさを確かめられます。
3つ目の失敗は、チャネルごとに在庫がずれていることに気づかないまま自動化することです。モールと自社ECで在庫を別々に管理していると、AIが参照した在庫と、お客様が見ている商品ページの在庫が食い違います。自動化の前に、どの在庫を正とするかを決め、在庫連携の仕組みを整えておくことが前提になります。
KPI設計と費用の目安
KPIは、自動化の範囲と品質の2軸で見ます。範囲の指標は、在庫・納期の問い合わせのうちAIが下書きを作れた割合。品質の指標は、担当者が下書きを修正せずに送れた割合と、AIが「担当者対応」と判断した割合です。初回の回答までの時間も、あわせて記録しておくと効果が説明しやすくなります。
費用は、導入価格（入力0.75米ドル、出力3.75米ドル／100万トークン）で試算できます。たとえば、1件の問い合わせでシステム指示とツールの結果を合わせて入力5,000トークン、出力1,000トークンを使うとすると、入力0.00375米ドル、出力0.00375米ドルで合計0.0075米ドルです。1米ドル150円で換算すると約1.1円になります。ツールを3回呼び出すと、そのたびに会話の内容が積み重なって入力が増えるため、余裕を見て1件あたり3〜5円程度を見込んでおくのが安全です。いずれも前提を置いた試算で、実際のトークン数は問い合わせの内容とツールの返す情報量によって変わります。
月に1,000件の在庫・納期の問い合わせがある店舗なら、モデルの利用料は月数千円の規模に収まる計算です。2027年1月からは通常価格に切り替わるため、その時点で単価を確かめて再試算してください。軽量なGemini 3.5 Flash-Liteで質問の振り分けだけを行い、複雑な問い合わせだけを3.8 Flashに回す構成にすれば、さらに費用を抑えられる可能性があります。
工数の目安は、手順1の分類に1〜2日、手順2のツール設計と接続に1〜3週間、手順3と4の調整に3〜5日です。取り出し元のAPIの整備状況によって、手順2の期間は大きく変わります。
今後の展望：問い合わせ対応から在庫の判断へ
在庫確認の自動化は、問い合わせ対応の効率化から始まりますが、その先には在庫の判断そのものをAIが支える段階があります。問い合わせの内容とツールの呼び出し履歴を蓄積すると、「入荷予定を聞かれることが多いのに、入荷予定が登録されていないSKU」や「在庫切れの問い合わせが集中している色・サイズ」が見えてきます。これは発注や生産の判断に直接使える情報です。
Googleのモデルラインナップは、2026年11月時点で上位のGemini 4 ArgonとGemini 4 Carbon、日常用途の3.8 Flash、振り分け向けの3.5 Flash-Liteという4層に整理されています。在庫確認のように手順が決まった業務は、上位モデルではなく3.8 Flashや3.5 Flash-Liteで十分に回せる領域です。上位モデルは、需要予測や発注量の判断など、複数の要因を比べる業務に回すのが費用対効果の高い使い分けになります。
もう1つの流れは、AIが管理画面を直接操作する仕組みです。APIが用意されていない在庫システムでも、画面操作で情報を読み取る方法が現実味を帯びてきました。この方向についてはGemini Computer Useの解説で整理しています。業務全体をエージェントとして組み立てる方法は、Gemini Enterprise Agent PlatformでEC業務エージェントを組む解説が参考になります。
よくある質問
反復ツール呼び出しとは何ですか
反復ツール呼び出しとは、AIが1つの依頼の中で外部の機能を複数回呼び出し、その結果を組み合わせて答えを作る動きのことです。在庫確認なら、SKUの特定、在庫照会、入荷予定の照会を順に呼び出してお届け予定を答える、といった使い方になります。
Gemini 3.8 Flashの料金はいくらですか
2026年12月31日までの導入価格は、100万トークンあたり入力0.75米ドル、出力3.75米ドルとGoogle AI Studioに掲載されています。2027年1月以降の通常価格は同ページに示されていないため、切り替え前に公式の料金ページで確認してください。
エンジニアがいなくても在庫確認を自動化できますか
ツールの接続にはプログラムが必要なため、エンジニアか外部の開発会社の協力が必要です。ただし、問い合わせの分類やツールの設計、テストケースづくりは、プロンプト1・2・4を使えば運営担当が下準備できます。
AIが在庫数を間違えて答える心配はありませんか
ツールの結果だけを根拠にするようシステム指示で縛り、根拠にした値を別の欄に出力させれば、間違いはかなり防げます。最初の1〜2か月は、担当者が下書きを確認してから送る運用にするのが安全です。
楽天市場の問い合わせにも使えますか
はい、回答の下書きづくりには使えます。在庫の取り出し元としてRMSのWeb APIや在庫連携システムを使い、回答は店舗の担当者が楽天市場の問い合わせ管理から送る形が基本です。回答の中で楽天市場外のサイトへ誘導する内容は入れないでください。
上位のGemini 4系を使うべきではありませんか
在庫確認のように手順が決まった業務では、3.8 Flashで十分なケースが多いと考えられます。Gemini 4 ArgonやCarbonは単価が高いため、需要予測や発注判断など、複数の要因を比べる業務に回すほうが費用対効果は高くなります。
まとめ
Gemini 3.8 Flashの反復ツール呼び出しは、在庫を見て、入荷予定を見て、配送日数を足すという人の手順を、そのままAIに再現させるのに向いた機能です。成否を分けるのは、業務を読み取り専用のツールに分解すること、ツールの結果だけを根拠に答えさせること、呼び出し回数に上限を設けることの3点です。費用は導入価格で問い合わせ1件あたり数円の規模に収まる試算になるため、まずは過去の問い合わせの分類から始めてみてください。
参考文献
- Google AI Studio「Latest Gemini models」
- Gemini API「Function calling」
- i-SCOOP：Gemini 3.8 Flash brings near-frontier reasoning to a workhorse model
- The Decoder：Gemini 3.8 Flash is Google’s third budget model in six weeks
著者：齋藤竹紘（株式会社オルセル 編集長／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実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
