AIが去年の送料無料ラインで答えていませんか｜Gemini 3.6 Flashの知識カットオフとEC情報の鮮度対策

齋藤竹紘2026年8月7日2026年8月7日Gemini

Gemini 3.6 Flashの知識カットオフとは、2026年3月のことです。

「送料無料は5,500円からです」。AIに下書きさせた問い合わせ返信に、半年前に廃止した金額がそのまま入っていた。これは珍しい事故ではありません。原因はモデルの賢さではなく、学習データの締切日にあります。Gemini 3.6 Flashの知識カットオフは2026年3月で、そこから先に自店やモール側で変わった条件は、モデルの中に存在しないからです。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援を2023年から提供する株式会社オルセル（うるチカラ運営）の現場知見にもとづき、カットオフ以降に変わる情報をどう差し込むか、鮮度が要る質問をどう振り分けるかを手順に落とします。

知識カットオフが2026年3月へ前進しても、埋まらない穴がある

先に結論を置きます。カットオフが1年以上前進しても、EC運営で事故が起きやすい領域はほぼ埋まりません。埋まらないのは自店固有の条件と、カットオフ後に変わった仕様だからです。

Gemini 3.6 Flashのモデルカードによれば、知識カットオフは2026年3月。前世代のGemini 3.5 Flashが2025年1月でしたから、1年2か月ぶん前に進んだ計算です。コンテキストウィンドウは100万トークン、出力上限は64,000トークン。出力トークン量は3.5 Flash比で約17%削減され、コンピュータ操作の指標であるOSWorld-Verifiedは78.4%から83%へ上がりました。公開は2026年7月21日で、Geminiファミリーの新しいデフォルト主力モデルという位置づけです（9to5Google）。

見落とされやすいのが、モデルカードに添えられた但し書きです。ドメインによっては2025年1月止まりの知識しか持たない場合がある、と明記されています。カットオフは「その日まで全分野を均一に知っている」という保証ではなく、「それ以降は知らない」という上限の宣言に近いものだと理解しておくほうが安全です。日本のEC実務のように、更新が速く、一次情報が各モールの出店者向けマニュアル側に閉じている領域は、学習データの密度がとりわけ薄くなります。

では何が抜けるのか。具体的には、モール側のシステム利用料や配送関連ルールの改定、広告メニューの入れ替え、商品登録項目の仕様変更、そして自店の送料無料ライン・返品規定・営業日・同梱可否・のし対応といった条件です。前者はカットオフ後に変わったぶんが抜け、後者はそもそも学習データに一度も入っていません。自店の返品期間が7日なのか14日なのかを、Googleのモデルが知っているはずがないという、当たり前の事実です。

現場で繰り返し見るのは、この2種類の欠落を同じ「AIが間違えた」という言葉でまとめてしまう扱いです。前者は検索で補える欠落、後者は自社データを渡さないと永久に補えない欠落で、対処が別物になります。ここを分けないまま「Geminiは間違いが多い」と結論づけて導入を止めた店舗を、これまで何度か見てきました。

モデルを乗り換えても構造は変わりません。Anthropicが2026年7月24日に公開したClaude Opus 5でも、OpenAIが2026年8月に無料ユーザーのデフォルトへ据えたGPT-5.6 Lunaでも、学習データに締切がある点は同じです。ベンダー選定で解決する問題ではなく、情報の入れ方で解決する問題だと切り分けてください。モデルごとの得手不得手そのものはGemini 3.1 Proと3.6 Flashの使い分け記事で整理しています。

鮮度が要る質問と、要らない質問を3層で振り分ける

判断を仕組みにするために、店舗で扱う質問を3層に分けます。層が決まれば、検索を付けるか、自社データを渡すか、そのまま投げるかが自動的に決まります。

第1層は、時間が経っても答えが変わらない質問です。文章の要約、言い換え、誤字脱字の検出、レビューの感情分類、キャッチコピーの案出し、箇条書きの構造整理などが該当します。この層はカットオフの影響を受けません。Gemini 3.6 Flashにそのまま投げてよく、検索を付けるとかえって余計な情報が混ざって遅くなります。日々の作業量で言えば、EC運営でAIに投げる仕事の6割前後はここに収まるというのが店舗運営の現場感覚です。

第2層は、業界共通だが時期によって変わる質問です。モールの手数料や利用料の水準、配送関連ルール、広告メニューの名称と課金方式、商品登録項目の必須・任意の区分、景表法や薬機法まわりの運用解釈などが入ります。この層は2026年3月より後に改定されていれば、モデルは古い答えを返します。しかも古いとは言わずに、自信のある口調で返してくるところが厄介です。ここは検索グラウンディングを付けるか、公式マニュアルのURLを渡して読ませる運用に切り替えてください。

第3層は、自店にしか答えがない質問です。送料無料ラインの金額、返品・交換の受付期間、営業日と出荷締め時間、同梱ルール、ギフト対応の可否、定期購入の解約条件、現在有効なクーポンの条件。この層は検索でも補えません。自社の一次情報をファイルやシステム連携でモデルに渡す以外に方法がありません。

振り分けの判定は2つの問いで足ります。「この答えは6か月前と今で変わりうるか」がイエスなら第2層以上。「この答えは他店と自店で違うか」がイエスなら第3層です。両方ノーなら第1層。この2問を業務手順書に書いておくだけで、担当者ごとの判断のばらつきがかなり減ります。

危険度が高いのは、1つの依頼文の中で層がまたがるケースです。たとえば「この商品の説明文を書いて、送料と返品条件も入れて」という指示は、前半が第1層、後半が第3層です。前半の品質が良いぶん、後半の古い数字を人間が見落とします。ある食品ジャンルの中規模店舗の事例では、ちょうどこの形で旧ラインの金額が入った説明文が数十商品に反映され、問い合わせ経由で発覚するまで11日かかりました。依頼を層でわけて出す、あるいは第3層の値をプロンプト側から与える、のどちらかを標準手順にしてください。

鮮度事故を止めるプロンプト5本

ここからは実装です。以下の5本を社内に置き、順番に回してください。ChatGPT・Claude・Geminiのいずれでも動きますが、Gemini 3.6 Flashで実行する前提で書いています。

1本目は振り分けです。依頼を投げる前に、その質問がどの層かを判定させます。担当者の勘に頼らないための入口になります。

プロンプト1：質問の鮮度リスク判定

あなたはEC事業者のAI運用を設計するコンサルタントです。
以下の依頼文を読み、鮮度リスクを3層で判定してください。

判定基準：
第1層 時間が経っても答えが変わらない（要約・分類・言い換え・構成整理など）
第2層 業界共通だが時期で変わる（モール仕様・手数料・広告メニュー・法令運用）
第3層 自店にしか答えがない（送料無料ライン・返品規定・営業日・在庫・価格・クーポン条件）

依頼文：{依頼文}

出力：
1. 依頼文を層ごとに分解した一覧（該当箇所を引用）
2. 層ごとの必要対応（第1層はそのまま／第2層は検索または公式URLを渡す／第3層は社内ファクトシートを渡す）
3. このまま実行した場合に古い情報が混ざるリスクを5段階で評価し、理由を1文

2本目は、社内ファクトシートの生成です。ばらばらの資料から、AIに読ませる前提でひとつのテキストにまとめさせます。

プロンプト2：社内ファクトシートの生成

あなたはEC店舗の運用ドキュメントを整備する担当者です。
以下の資料から、AIに毎回読ませる「社内ファクトシート」を作成してください。

必須項目：
1. 適用開始日と次回見直し予定日
2. 送料条件（無料ライン・地域別加算・離島扱い）
3. 出荷スケジュール（営業日・締め時間・休業日）
4. 返品交換条件（受付期間・条件・送料負担）
5. 支払方法と手数料
6. ギフト対応（のし・ラッピング・同梱明細の有無）
7. 定期購入の条件（解約・スキップ・変更期限）
8. 現在有効なキャンペーンとその終了日

資料：{既存の特商法表記・FAQ・社内マニュアルの該当箇所}

出力条件：
- 1項目1行、断定形で書く
- 数値には必ず税込・税別の別を書く
- 資料に記載がない項目は「未定義」と書き、推測で埋めない
- 全体で2,000文字以内

3本目が本番です。ファクトシートを最優先の根拠として扱わせ、モデルの記憶を上書きさせます。

プロンプト3：ファクトシート優先で回答を生成

あなたは当店のカスタマーサポート担当です。
回答は必ず以下の順で根拠を採用してください。

根拠の優先順位：
1. 社内ファクトシート（最優先。モデル自身の知識と矛盾する場合は必ずこちらを採用）
2. 提示された公式マニュアルの引用
3. それでも判断できない場合は「確認して折り返します」と書く

禁止事項：
- ファクトシートに書かれていない金額・期間・条件を推測で書かない
- 「一般的には」で始まる一般論で数値を埋めない
- 断定できない箇所は文末に［要確認］と付ける

社内ファクトシート：
{ファクトシート全文}

お客様からの質問：{質問文}

出力：回答文（200〜400文字）と、使った根拠の項目番号

4本目は監査です。すでに生成した文章に、古い前提が紛れていないかを機械的に洗います。公開前の最後の関門として使います。

プロンプト4：生成物の鮮度監査

あなたは公開前チェックの担当者です。
以下の文章に、社内ファクトシートと矛盾する記述、または出典のない数値・日付・条件が含まれていないか検査してください。

検査項目：
1. 金額（送料・手数料・価格・無料ライン）
2. 期間（返品・保証・キャンペーン・お届け日数）
3. 対応可否（同梱・のし・時間指定・海外配送）
4. 制度・仕様の名称（サービス名や機能名が現行のものか）
5. 出典のない断定表現

社内ファクトシート：{ファクトシート全文}
検査対象の文章：{本文}

出力：
- 問題箇所を原文引用し、矛盾の内容と修正案を並べる
- 判定できない箇所は「要確認」として理由を1文
- 問題ゼロなら「検出なし」とだけ出力する

5本目は更新のための差分抽出です。月次でファクトシートを直すとき、どこが変わったかを人間が思い出す作業をやめられます。

プロンプト5：月次ファクトシートの差分抽出

あなたはドキュメント管理の担当者です。
先月版と今月の実態を突き合わせ、更新すべき箇所を抽出してください。

先月版のファクトシート：{先月版全文}
今月の変更情報：{社内連絡・モールからの通知・変更した設定値}

出力：
1. 変更が必要な項目とその新旧値
2. 変更の適用開始日
3. 変更にともなって書き換えが必要な既存文面の候補（商品ページ・FAQ・自動返信文など）
4. 変更なしと判断した項目の一覧

この5本を回すと、鮮度の管理が担当者の記憶から手順へ移ります。特にプロンプト4は、公開前チェックの工程に組み込んでしまうのが効きます。

月次で更新する社内ファクトシートの作り方

ファクトシートは、AIに読ませる前提で書いた自店ルールの一枚紙です。既存の特商法表記やFAQをそのまま渡すのではなく、AIが誤読しない形に整えるところに手間の価値があります。

書式の原則は3つです。ひとつ、1項目1行で断定形にする。「原則として〜の場合があります」のような含みのある表現は、モデルが都合よく解釈します。ふたつ、数値には単位と税区分を添える。「6,600円（税込）」と書けば、税別と誤解した回答が生成される余地が消えます。みっつ、記載がない項目は空欄にせず「未定義」と明記する。空欄はモデルが勝手に埋めますが、「未定義」と書いてあれば埋めずに確認を促す挙動になります。

冒頭には適用開始日と次回見直し日を入れてください。「適用開始：2026年8月1日／次回見直し：2026年9月1日」の2行です。これがあると、監査プロンプトで「シートそのものが古い可能性」を検知できます。運用上は、見直し日を過ぎたシートを使って生成した文章は公開前に人間が見る、というルールと組み合わせます。

更新の担当は1人に固定してください。複数人が更新できる状態にすると、いずれ版が分岐します。置き場所も1か所に決め、AIツール側には常にその1ファイルだけを参照させます。編集部で実際に運用しているプロンプトでは、シートの1行目にバージョン番号を書き、生成物の末尾にそのバージョン番号を出力させる形にしています。あとから「どの版で書いた文章か」を追えるようにするためです。

更新のきっかけは、社内の変更と外部の変更の2系統で拾います。社内側は価格改定・送料改定・キャンペーン開始終了・営業日の変更。外部側は各モールの出店者向け通知です。楽天RMSであれば店舗運営ナビの通知、AmazonであればSeller Centralの通知、Yahoo!ショッピングであればストアクリエイターProの通知が該当します。月初にこの2系統をまとめて確認し、プロンプト5で差分を出す流れが軽く回ります。

分量は2,000文字前後に収めてください。長くしすぎると、毎回のトークン消費が増えるうえに、モデルが重要な行を見落とす確率が上がります。商品個別の情報はシートに入れず、商品マスタ側から都度渡す設計にわけると、シートが肥大化しません。

よくある失敗と回避策

4つ挙げます。いずれも実際に起きているものです。

1つ目は、検索グラウンディングを付ければ全部解決すると考えるケースです。検索は第2層の質問には効きますが、自店の返品期間は検索しても出てきません。むしろ検索結果に他店の条件が混ざり、それらしい数字を拾ってくる危険があります。回避策は、第3層の値をファクトシートで固定したうえで検索を併用し、プロンプト3のように根拠の優先順位を明示することです。

2つ目は、カットオフ後に名称が変わった機能を、古い名前のまま説明させるケースです。サービス名や画面名は改称されることがあり、モデルは旧称で答えます。読者や顧客が管理画面を開いても、その名前のメニューが見つからない。回避策は、画面名や機能名を含む文章はURL contextで公式マニュアルを読ませたうえで書かせるか、生成後にプロンプト4の検査項目4で洗うことです。

3つ目は、楽天R-Mailの本文をAIに書かせて、旧キャンペーンの終了日や外部サイトへの導線が混ざるケースです。前者は鮮度の問題、後者は規約の問題で、性質が違います。楽天市場のメルマガ本文に楽天市場外のURLを置く運用は認められていないため、AIに書かせるときはこの制約をプロンプトの禁止事項に明記しておいてください。楽天内で完結する導線だけを使う前提を最初に固定すると、生成物を毎回直す手間が消えます。

4つ目は、ファクトシートを作ったまま更新が止まるケースです。3か月放置されたシートは、モデルの記憶より少しましなだけの古い情報源に変わります。回避策は、更新日をカレンダーに固定タスクとして置くことと、シートの冒頭に次回見直し日を書いておくこと。楽天とAmazonの両方を回している店舗で観測されたのは、月初の受注処理と同じ日にシート更新を紐づけたところ、更新の遅延がほぼ消えたという例でした。

5つ目として、生成物の一括反映も挙げておきます。AIで作った商品説明文を検証せずに数百件まとめて反映すると、誤りも一括で広がります。反映は10件単位で区切り、最初の10件を目視してから残りを流す。この一手間が、11日気づかないという事態を防ぎます。

KPI設計と費用・工数の目安

測る指標は3つで足ります。第一に鮮度事故率。公開または送信した文章のうち、古い情報が含まれていた件数の割合です。第二にファクトシートの更新遅延日数。見直し予定日から実際の更新日までの日数で、ここが7日を超えると事故率が上がる傾向があります。第三に人手修正率。生成物のうち人間が手を入れた割合で、3割を超えるならプロンプトかシートのどちらかが足りていません。

導入前の基準値は、直近3か月の問い合わせのうち「案内内容が違った」という趣旨のものを数えるところから取れます。ゼロだと思っていても、実際に数えると月に数件は出るのが通例です。

費用面では、まずGoogle AI Studioの無料枠で検証してから有料へ移る流れが現実的です。個人向けの有料プランは月額20米ドル前後が相場ですが、名称も価格も改定されるため契約前に公式の料金ページで確認してください。API経由で回す場合の単価と月額試算の考え方は、前掲のモデル使い分け記事に置いた試算プロンプトが使えます。検索グラウンディングを有効にすると呼び出しあたりの費用が上がる点は、設計時に見込んでおいてください。

工数の目安は、ファクトシートの初版作成に3〜5時間、月次更新に30分前後というのが2026年8月時点の見込みです。初版は既存の特商法表記とFAQからの転記が中心になるため、プロンプト2に資料を貼れば下書きは20分程度で出ます。残りの時間は、記載がない項目を社内で確定させる作業に消えます。この「未定義だった項目を確定させる」作業自体が、社内の運用整理としての価値を持ちます。

効果の出方は、鮮度事故の減少より先に、確認のための往復が減る形で現れます。担当者が「これって今いくらだっけ」と社内に聞く回数が減り、返信の下書きが一発で通るようになる。ある化粧品ジャンルの店舗では、問い合わせ1件あたりの平均対応時間が導入前後で約3割短くなりました。数字の大きさより、確認待ちで止まる時間が消えたことのほうが体感としては大きかったという評価でした。

この先の見立てと、いま固定してよいこと

知識カットオフは今後も前進し続けます。Gemini 3.5 Flashの2025年1月から3.6 Flashの2026年3月へ動いたように、次の世代ではさらに新しい日付が並ぶはずです。ただし、その前進で埋まるのは第2層の一部だけで、第3層は永久に埋まりません。自店の返品期間を学習データに含んだモデルは、原理的に登場しないからです。

むしろ変化が効いてくるのは、AIエージェントが顧客の代わりに商品情報を読みに来る局面です。人ではなくエージェントが送料条件や返品条件を読み取り、購入可否を判断する場面が増えるほど、自社が持つ一次情報の構造と鮮度がそのまま売上に効きます。社内向けに作ったファクトシートは、そのとき外向けの構造化情報の土台としても使えます。内部用と外部用で同じ事実を持つ設計にしておけば、二重管理の手間が消えます。

いま固定してよいのは、3層の振り分け基準とファクトシートの項目定義です。どちらもモデル非依存で、乗り換えても書き直す必要がありません。固定すべきでないのは、特定モデルの挙動に合わせて書いた細かい言い回しです。モデルが変われば最適な表現は変わるので、プロンプトの構造だけを残し、文面は差し替え可能な状態にしておいてください。

競合のモデル比較記事はベンチマークとトークン単価に集中しがちですが、EC事業者にとっての実害はスコアではなく、古い金額で顧客に案内してしまうことです。ベンチマークで数ポイント上のモデルを選んでも、カットオフ後の自店ルールを渡さなければ結果は同じ。どのモデルを使うかより、何を読ませるかのほうが先に効きます。

よくある質問

Gemini 3.6 Flashの知識カットオフはいつですか

2026年3月です。前世代のGemini 3.5 Flashは2025年1月でした。ただしモデルカードには、ドメインによっては2025年1月止まりの知識しか持たない場合があるという但し書きがあるため、分野によって知識の厚みは一様ではないと考えてください。

カットオフ後の情報はどうやって渡せばよいですか

業界共通の情報は検索グラウンディングかURL contextで公式ページを読ませ、自店固有の情報は社内ファクトシートで渡します。前者は検索で補える欠落、後者は自社データを渡さないと補えない欠落で、手段が違います。両方を同時に使う場合は、根拠の優先順位をプロンプトで明示してください。

検索を常に有効にしておけば安全ですか

いいえ、常時有効は推奨しません。要約や分類のように時間で答えが変わらない処理では、検索結果が混ざって精度と速度が落ちるためです。鮮度が要る質問だけに検索を付ける振り分けを、本記事のプロンプト1で自動化してください。

社内ファクトシートはどのくらいの頻度で更新しますか

月1回が基準です。価格改定やキャンペーン開始のように即時性のある変更があった日は、その都度追加更新します。見直し日を過ぎたシートで生成した文章は公開前に人間が確認する、というルールをセットで置いておくと安全側に倒れます。

ChatGPTやClaudeでも同じ問題は起きますか

はい、起きます。Claude Opus 5もGPT-5.6ファミリーも学習データに締切がある点は同じで、自店固有の条件を知らないことも変わりません。モデルを乗り換えて解決する問題ではなく、情報の渡し方で解決する問題です。

最初の一歩は何から始めればよいですか

社内ファクトシートの作成からです。本記事のプロンプト2に既存の特商法表記とFAQを貼れば、下書きは20分程度で出ます。記載がない項目が「未定義」として並ぶので、それを社内で確定させる作業が実質的な初期工数になります。

まとめ

Gemini 3.6 Flashの知識カットオフは2026年3月ですが、EC実務で問題になるのはカットオフ日そのものではなく、そこから先に変わった仕様と、最初から学習データに入っていない自店の条件です。質問を3層に振り分け、第2層は検索とURL contextで、第3層は社内ファクトシートで埋める。この2つを分けて設計すれば、古い金額で顧客に案内する事故は止まります。まずはプロンプト2でファクトシートの初版を作り、公開前チェックにプロンプト4を組み込むところから着手してください。

参考文献

著者：齋藤竹紘（株式会社オルセル編集長／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実装」を一次情報として発信しています。

投稿者: 齋藤竹紘

株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。齋藤竹紘のすべての投稿を表示

EC×AIでビジネスを爆速させるメディア