投稿者 投稿日: カテゴリー Grok
Grokアドオンとは、SheetsやOutlookの中で直接Grokを呼び出せる無料の拡張機能のことです。
2026年7月、xAIがGoogle Workspace向けのGrokアドオンと、Microsoft 365向けの「Grok for Outlook」を相次いで公開しました。これまでAIを使うにはブラウザで別タブを開き、データをコピーして貼り付ける必要がありましたが、SheetsとOutlookの中で完結する形になりました。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）が、受注メールと在庫表という日本のEC現場でいちばん時間を食う2業務にどう当てるかを整理します。
SheetsとOutlookの中で完結するようになった、という変化
今回の変化を一言でいえば、AIが作業場所に移動してきたということです。xAIによると、Grok for Google Workspaceは無料のアドオンで、Google Workspace Marketplaceから1回インストールすればSheets、Slides、Docsの3つで使えるようになります。Microsoft 365側では、Word、Excel、PowerPoint、Outlookに対応しています。
Sheetsでの動きが、EC実務には直接効きます。スプレッドシート上で質問すると、Grokはシートの内容から回答し、そのとき参照したセルを示します。数式を書いて埋め、グラフを挿入し、前提の数字を変えるとシナリオを再計算し直します。ここで重要なのは「参照したセルを示す」という部分で、AIがどこを見て答えたかが追える設計になっている点です。在庫表や売上表のような、数字が合っているかを人が最終確認しなければならないデータでは、この追跡可能性が実用の分かれ目になります。
Outlook側は2026年7月21日に公開されました。短いメモから完成したメール文面を作り、受信箱をアーカイブ・フィルタ・フラグで整理し、添付ファイルを読み、ブラウザを開かずにメールとXの中を検索します。EC事業者の受注業務は、仕入先とのやり取り、モール担当者からの連絡、顧客からの問い合わせが同じ受信箱に混ざるのが常態です。この分類作業が受信箱の中で完結するのは、実務では小さくない差になります。
Grokそのものの性能面については、Grok 4.6の2兆パラメータとEC活用で扱いました。今回のアドオンは、その性能をどこで使えるようにするかという配置の話です。
配置が変わることの意味は、実務者ほど分かりやすいはずです。これまでスプレッドシートの数字をAIに見せるには、範囲を選択してコピーし、ブラウザのAIに貼り、返ってきた結果をまた貼り戻す、という3往復が必要でした。この往復のたびに、貼り忘れ、範囲のずれ、書式の崩れが起きます。EC事業者の在庫表は列が30を超えることが珍しくなく、コピー&ペーストの精度が落ちやすい構造をしています。アドオンとして常駐すると、この往復がゼロになります。
Slidesへの対応も、EC事業者にとって無縁ではありません。モール担当者との商談資料、社内の月次報告、仕入先へのプレゼンといった場面で、売上シートから資料を起こす作業は毎月発生します。アウトラインを渡すと構成されたスライドを作り、既存のテーマを保ったまま追加のスライドを足せる、という機能は、この月次作業に直接あたります。ただし、資料に載せる数字の正確さは人が担保する必要があります。
Xの検索がメールクライアントの中から使える点も、SNS運用をしている店舗には意味があります。自社商品の言及や競合の動きを、ブラウザを開かずに確認できます。ただしこの機能を業務に組み込むなら、何をどの頻度で確認するかを決めてからにしてください。決めずに使うと、情報収集という名目の時間だけが増えます。
なぜ「メールと表計算」がECのボトルネックなのか
EC事業者の業務時間の内訳を見ると、商品ページの作成や広告運用よりも、メール処理と表計算の時間のほうが長いことが珍しくありません。受注確認、在庫問い合わせへの返信、仕入先への発注、配送遅延の連絡、返品対応。これらはすべてメールで動き、その裏側で在庫表と売上表が更新されます。
現場で繰り返し見るのは、この2つが分断されているために起きる転記ミスです。受注メールの内容を手で在庫表に反映し、在庫表を見て仕入先にメールを書く。この往復の中で、数量の桁を間違える、単位を取り違える、旧版のシートを参照する、といった事故が起きます。楽天/Amazonの両方を回している店舗で観測されたのは、モールごとに在庫の締め時間が違うために、同じ商品の在庫数が2つのシートで食い違うという状態でした。
アドオン型のAIがここに効くのは、両方のアプリの中に同じアシスタントが常駐するからです。Outlookで受注メールを要約させ、Sheetsで在庫表と突き合わせる。この2工程が別ツールへのコピー&ペーストなしに回るようになると、転記の回数自体が減ります。転記回数が減れば、転記ミスも減る。これは精度の改善というより、工程数の削減による事故率の低下です。
在庫表と受注メールが分断されることで起きるもうひとつの問題が、判断の遅れです。仕入先から「その商品は次回入荷が2週間後になります」というメールが来たとき、その情報が在庫表に反映されるまでにタイムラグがあります。その間に販売ページの在庫表示は据え置かれ、注文が入り、あとから欠品連絡をすることになります。このパターンは、レビュー評価に直接跳ね返ります。メールの内容を即座に在庫表の判断材料にできる状態は、欠品連絡の件数そのものを減らします。
季節商材を扱う店舗では、この遅れがさらに効いてきます。お中元やお歳暮のように、需要期が2〜3週間に集中する商材では、判断を1日遅らせるだけで機会損失が発生します。仕入先からの入荷連絡を受けて、当日中に発注量を見直せるかどうかが売上を分けます。表計算の中でシナリオを振り直せる環境は、この場面で価値を発揮します。
もうひとつの論点が、データの外部送信です。アドオンとして動く以上、シートやメールの内容はxAIのサーバーに送られます。顧客の氏名・住所・電話番号を含む受注メールを扱う場合、社内の個人情報保護方針と利用規約の突き合わせが先に必要です。この確認を飛ばして全社展開すると、後から止めるコストのほうが大きくなります。まずは個人情報を含まない在庫表・仕入表から始めるのが現実的な順序です。
受注メールと在庫表に当てる6つのプロンプト
ここからは実装です。Google Workspace版とOutlook版の両方で使える形で、6本のプロンプトを示します。宣言どおり6本を以下に実装します。いずれも変数部分を自店の条件に置き換えて使ってください。
まずOutlook側です。受信箱に混ざった連絡を、対応の緊急度で仕分けるところから始めます。
プロンプト1：受注・問い合わせメールの緊急度仕分け
あなたはECショップのカスタマーサポート責任者です。
以下のメールを読み、対応区分を判定してください。
判定区分：
A（当日中に返信が必要）：配送遅延、破損、誤配送、キャンセル希望、クレーム
B（翌営業日でよい）：在庫問い合わせ、仕様の質問、領収書依頼
C（自動処理でよい）：受注確認の自動返信、システム通知、モールからの一斉連絡
D（社内転送）：仕入先からの連絡、請求関連、法務・規約関連
出力：
1. 対応区分（A〜D）と、その判断理由を1文
2. 区分Aの場合、返信の骨子を3行以内で（送料や返金の可否は断定せず「確認のうえ」と書く）
3. 顧客が明示的に求めていること（1文）
4. 社内で確認が必要な情報があれば列挙
メール本文：
{メール本文を貼り付け}
返信文面の作成は、トーンの統一が課題になります。担当者ごとに文体が変わると、店舗としての印象が揺れます。
プロンプト2：配送遅延の謝罪メール文面を作る
あなたは日本のECショップの顧客対応担当です。
以下の状況に対する返信メールを作成してください。
守る条件：
1. 件名は30文字以内、状況が一目で分かる表現にする
2. 冒頭で事実と謝罪、次に現在の状況、最後に今後の対応の順で書く
3. 確定していない納期を断定しない。「〜の見込みです」と書く
4. 補償の可否を勝手に確約しない。判断が必要な場合は「社内で確認のうえご連絡します」とする
5. 定型文らしさを避けるため、顧客が書いた具体的な状況に1文だけ触れる
6. 全体で250〜350文字に収める
状況：
- 商品名：{商品名}
- 遅延理由：{理由}
- 現時点で分かっている出荷見込み：{日付}
- 顧客が伝えてきた事情：{内容}
ここからSheets側です。在庫表の異常検知は、目視では見つからない誤りを拾います。
プロンプト3：在庫表の異常値・不整合を検出する
あなたはEC事業者の在庫管理を担当するデータアナリストです。
このシートの在庫データを読み、以下の観点で異常を検出してください。
検出の際は、参照したセル範囲を必ず明示してください。
検出観点：
1. 在庫数がマイナスになっている行
2. 発注点を下回っているのに発注済フラグが立っていない行
3. 直近30日の出荷実績がゼロなのに在庫を多く抱えている行
4. 同一商品が複数行に重複して登録されている行
5. 単位（個・箱・ケース）が同一商品内で揺れている行
6. 販売価格が仕入価格を下回っている行
出力：
- 観点ごとに、該当する商品管理番号と該当セル
- 対応の優先度（高／中／低）と、その根拠を1文
- 判断がつかない行は「要確認」と明記する
発注量の検討は、シナリオを振って比べるのが実務的です。
プロンプト4：発注量のシナリオを3案作る
あなたはEC事業者の仕入担当です。
このシートの過去12か月の出荷実績と現在庫をもとに、次回発注量の案を3つ作ってください。
前提として使う数字：
- リードタイム：{日数}
- 最小発注ロット：{数量}
- 保管スペースの上限：{数量}
- 欠品時の機会損失（1件あたり）：{金額}
- 過剰在庫の保管コスト（1個1か月あたり）：{金額}
作る案：
1. 欠品回避を優先した案
2. 在庫回転を優先した案
3. 期待金額が最大になる案
各案について出力すること：
- 発注数量と、その根拠となる計算式
- 想定される欠品確率（根拠となるセル範囲を明示）
- 保管コストと機会損失の合計見込み
- この案が不利になる条件（どういう状況なら外れるか）
売上データの読み解きは、担当者の勘に頼りがちな領域です。数字を根拠に落とします。
プロンプト5：売上シートから施策の候補を出す
あなたはECの売上分析を担当するコンサルタントです。
このシートの商品別売上データを読み、次の1か月で着手すべき施策を5つ提案してください。
各提案には、根拠となったセル範囲を必ず添えてください。
分析の観点：
1. 売上が前年同月比で落ちている商品と、その落ち幅
2. アクセス数は維持しているのに転換率だけ落ちている商品
3. 転換率は高いのにアクセス数が少ない商品（露出不足の候補）
4. 粗利率が低いのに売上構成比が高い商品
5. 併売されやすい商品の組み合わせ
出力フォーマット：
- 施策名、対象商品、根拠データ（セル範囲つき）、想定される効果、着手の優先度
- 効果の見込みは「目安」と明記し、断定しない
最後に、メールとシートをつなぐ工程です。ここが転記ミスの発生源になります。
プロンプト6：仕入先への発注メールをシートの数字から起こす
あなたはEC事業者の仕入担当です。
以下の発注リスト（シートから抽出したもの）をもとに、仕入先への発注メールを作成してください。
守る条件：
1. 商品コード・数量・単価は、渡されたデータから一字一句変えない
2. 合計金額は自分で計算し、計算式も本文に併記する
3. 希望納期は指定された日付をそのまま書く。前後させない
4. 前回の発注から変更した点があれば、本文冒頭で1行触れる
5. 添付ファイルの有無を末尾に明記する
6. 敬語は簡潔に。定型の時候の挨拶は入れない
発注リスト：
{シートから抽出した発注データ}
仕入先名：{社名}
希望納期：{日付}
前回発注からの変更点：{内容}
導入の順序：3週間で回るところまで持っていく
いきなり全業務に広げるのではなく、3週間で1つの型を作るのが現実的です。ある食品ジャンルの中規模店舗の事例では、この順序で進めて、4週目には担当者が自分でプロンプトを直せる状態になりました。
1週目は在庫表だけに絞ります。プロンプト3を週に2回動かし、検出された異常を人が確認します。ここで拾えなかった異常があれば、観点を1つ追加してプロンプトを更新します。この1週間で、AIが自店のシート構造を理解できているかが分かります。列名が独自の略語だらけだと精度が落ちるので、必要なら列名を分かりやすい表記に直します。この作業自体が、シートの可読性を上げる副産物を生みます。
2週目でメールの仕分けに広げます。プロンプト1を、個人情報を含まない社内メールと仕入先メールに限定して使います。判定区分が自店の運用と合っているかを見て、区分の定義を書き直します。多くの店舗では、最初に用意した4区分では足りず、5〜6区分に増えます。増えたぶんだけ後工程が楽になるので、ここは丁寧にやる価値があります。
3週目に発注メールの生成と、売上分析を足します。プロンプト5と6を使い、出てきた施策案のうち1つを実際に実行します。ここまでやって初めて、AI導入が売上側の指標につながります。分析だけして実行しない状態が続くと、社内で「使ってみたが特に変わらなかった」という評価になりがちです。実行までを1セットとして設計してください。
4週目以降は、担当者がプロンプトを自分で直せる状態にするのが目標です。プロンプトの管理場所を1か所に決め、変更履歴が分かる形にしておきます。担当者が変わったときに、この資産が引き継げるかどうかで、半年後の運用が変わります。
導入でつまずく3つのパターン
ひとつ目が、AIの回答をそのまま数字として採用してしまうケースです。Sheetsのアドオンは参照セルを示す設計になっていますが、示されたセル範囲が意図した範囲とずれていることがあります。特に行が追加され続けるシートでは、範囲指定が古いままになりやすい。回避策は、プロンプトの中で「参照したセル範囲を必ず明示」と書くことと、出た数字を1件だけ手計算で検算する習慣です。この1件検算を省いた店舗で、発注数量が1桁ずれた事例を見ています。
ふたつ目は、個人情報を含むメールを最初から対象にしてしまうケースです。顧客の氏名・住所・電話番号・注文履歴は、外部サービスに送る前に社内の判断が要ります。まずは仕入先とのやり取りや社内メールなど、個人情報を含まない範囲から始め、運用が固まってから顧客対応に広げるのが安全な順序です。
個人情報の扱いについては、社内ルールを1枚にまとめておくと運用が安定します。含める項目は、AIに渡してよいデータの種類、渡す前に伏せるべき項目（氏名・電話番号・住所・注文番号）、使ってよいアプリの範囲、判断に迷ったときの相談先の4つで足ります。この1枚があるだけで、担当者が個別に判断して事故を起こす確率が下がります。5,000社支援の中で何度も再現したパターンとして、ルールが口頭のままの組織ほど、担当者交代のタイミングで運用が崩れます。
3つ目が、楽天市場のメルマガ運用と混同するケースです。ここは特に注意が必要で、楽天R-Mailの本文に自社ECサイトやSNSなど楽天市場外のURLを置くことは、楽天市場の店舗運営規約で認められていません。GrokをOutlookで使ってメール文面を作る場合、その文面が楽天R-Mailに転用されるなら、外部URLを含まない形で生成させる必要があります。楽天R-Mailの改善は、件名の最適化、配信時間帯とセグメントの調整、楽天市場内の他商品ページへの遷移、といった楽天内で完結する施策に限定します。この論点はGrokのオートメーション機能を使った業務自動化でも触れています。
コストと工数の目安
Grok for Google Workspaceは無料のアドオンとして提供されています。Microsoft 365向けのGrok for Outlookも同様にアドインとして提供されており、追加のライセンス費用がかからない点が、検証開始のハードルを下げています。ただし利用回数の上限や、上位プランの要否については提供元の最新情報を確認する必要があります（2026年7月時点の条件は要確認）。
工数の見積もりとしては、受注メールの仕分けと一次返信の作成に1件あたり5分かかっていた店舗が、プロンプト1と2を併用して2分程度に短縮するイメージです。1日40件の対応があれば、月あたり約40時間の削減という計算になります。在庫表の異常検知は、月次で2時間かけていた目視チェックが20〜30分に収まるケースが多く見られます。いずれも商品数と業務フローで変動するため、あくまで目安として扱ってください。
費用対効果を社内で説明するときは、削減時間を金額に換算するより、対応品質の指標で語るほうが通りやすいことがあります。たとえば当日中に返信できた割合、欠品連絡の件数、発注の桁ミス件数といった数字です。時間の削減は「本当にその時間が浮いたのか」を問われやすい一方、対応品質の数字は月次で追いやすく、担当者以外にも意味が伝わります。導入前の3か月分を基準値として控えておくと、後から比較できます。
比較検討の材料として、他社のフラッグシップモデルの価格帯も押さえておくと判断しやすくなります。Claude Opus 5とGrok 4.6、GPT-5.6のコスト比較で整理したとおり、アドオン型の無料提供とAPI従量課金では、コスト構造がまったく違います。定型業務はアドオン、大量一括処理はAPI、という役割分担が実務的です。
今後の展望と独自の見方
アドオン型のAI提供が広がると、モデルの性能差よりも「どこに常駐しているか」が選定理由になる場面が増えると見ています。EC事業者の現場では、優秀だが別タブにいるAIより、そこそこ賢くて手元にいるAIのほうが使われます。実際、業務ツールに組み込まれたAIの利用頻度は、ブラウザ版の数倍になるという傾向を支援先で観測しています。
xAIがGoogle WorkspaceとMicrosoft 365の両方に同時期に展開したのは、この土俵で先に面を取りにいく動きだと解釈できます。今後は、SheetsやOutlookの中で複数のAIアシスタントが並ぶ状態になり、店舗側は「どのアプリでどのAIを使うか」を決める必要が出てきます。判断軸としては、参照根拠を示せるか、データの取り扱い規約が自社の方針に合うか、日本語の商品文脈で安定しているか、の3点で足ります。
もうひとつの見立てとして、この流れは在庫管理システムや受注管理システムのあり方にも影響します。専用システムを入れずにSheetsで在庫を回している中小事業者は日本に多く、そこにAIが常駐すると、専用システムへの移行圧力が下がる可能性があります。専用システムの価値が「機能」から「データ連携の確実さ」に移っていく、という構造変化です。
一方で、ここには落とし穴もあります。Sheetsでの運用がAIによって快適になるほど、シートの構造が複雑化しやすくなります。人が読まなくてもAIが読めるから、という理由で列が増え続けると、いざシステム移行するときの移行コストが跳ね上がります。現場感覚では、シートの列数が50を超えたあたりが1つの目安で、そこから先は専用システムへの移行を検討したほうが総コストは下がります。AIで延命できる範囲と、構造を変えるべき範囲を分けて考えてください。
3つ目の見方として、アドオン型AIの普及は、担当者のスキル要件も変えます。これまでExcelの関数を暗記していることが評価された領域で、これからは「何を検証すべきかを言語化できること」が効いてきます。数式そのものはAIが書くので、人に残るのは、出てきた数字を疑う目と、業務上の制約を正確に伝える力です。採用や教育の設計も、この方向に寄せていく必要があります。
よくある質問
Grokのアドオンは無料で使えますか
はい、Google Workspace向けのアドオンは無料で提供されています。Marketplaceから1回インストールすればSheets、Slides、Docsで使えます。Microsoft 365向けもアドインとして提供されていますが、利用上限や上位プランの要否は提供元の最新情報を確認してください。
Sheetsで数式を間違えられる心配はありませんか
あります。だからこそ参照セルの明示を必ず指示してください。Grokは参照したセルを示す設計になっているため、出力された数字の根拠を追えます。重要な数字は1件だけ手計算で検算する運用をおすすめします。
顧客情報を含むメールに使っても大丈夫ですか
社内の判断が先に必要です。アドオンとして動く以上、メール内容は外部に送信されます。個人情報保護方針と利用規約を突き合わせてから使ってください。最初は仕入先とのやり取りなど、個人情報を含まない範囲から始めるのが安全です。
楽天のメルマガ作成に使えますか
使えますが、条件があります。楽天R-Mailの本文に楽天市場外のURLを入れることは規約で認められていないため、生成時に外部URLを含めない指示を入れる必要があります。改善は件名、配信時間帯、セグメント、楽天市場内の遷移先に絞ってください。
ChatGPTやClaudeから乗り換えるべきですか
乗り換える必要はありません。用途で使い分けるのが現実的です。SheetsとOutlookの中で完結する定型作業はGrokアドオン、大量の商品データを一括処理する作業はAPI経由の別モデル、という分け方が実務に合います。
どの業務から始めるのが効率的ですか
在庫表の異常検知から始めるのが効率的です。個人情報を含まず、効果が数字で見えやすく、失敗しても影響範囲が限定されるためです。ここで運用が固まってから、メール対応に広げてください。
導入して効果が出るまでの期間はどのくらいですか
在庫表の検知は初日から効果が出ますが、メール対応のトーンが安定するには2〜4週間程度かかるのが目安です。最初の2週間は生成された文面を人が必ず確認し、修正した箇所をプロンプトに反映していく工程が必要になります。
著者：齋藤竹紘（株式会社オルセル 編集長／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実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
