【iOS 27】店舗スタッフ全員に「毎回使っていいAI」を、なぜこれまで配れなかったのか

こんにちは。リテールアプリ共創部で事業企画を担当しているかめだです。

全国に何百店舗も展開している小売チェーンの方から、「店舗スタッフが使えるAIを入れたい、という話は何度も出ている」と聞くことがあります。

百貨店に多く出店している食品小売では、百貨店側のPOSと連携できず、売上や商品情報を店舗スタッフが手入力しています。アパレルでは、店舗スタッフの工数をこれ以上増やせないので、記録の手間が増える提案は通りません。ドラッグストアでは、店舗からの問い合わせ対応で本部の手が足りていません。

生活雑貨の大手チェーンでは、店員向けに3,000台以上のiPod touchを配り、バーコードリーダーを付けて発注や在庫確認に使っています。店員が業務端末で発注や在庫をバーコードで確認する店は珍しくありません。そこに、引継ぎメモや納品書、棚札とデータの突き合わせが手作業で残っています。

どの業種でも、手入力を減らすAI機能を店舗スタッフ全員に配ろうとすると、全店舗・全スタッフ分の費用を見積もれず、企画が通りません。数店舗の実証実験までは進み、全店舗展開の稟議で止まります。この記事は、その稟議を通すための費用の考え方を書きます。

上記の課題は、iPhoneの中だけで動くAI（Apple Intelligence）であれば、解決できるのではないかと考えています。端末内のAIと、在庫データをツールとして渡す仕組みはiOS 26からあり、iOS 27で文字やバーコードを読み取る標準のツールが加わりました。

数千人の店員が毎日使うAI機能のコストはどうするのか？

iPhoneの中だけで処理を終える機能にすれば、呼び出し回数がいくら増えても、AIを呼ぶたびの費用は増えません（端末の調達・開発・運用の費用は別に要ります）。処理をするのがスタッフのiPhoneだからです。

なぜこれまでAIの利用が難しいと判断されてきたかを、式にして考えてみます。

店舗スタッフ数 × 1日あたりの利用回数 × 営業日数 ＝ AIの呼び出し回数

クラウド型の従量課金AIでは、この式で出た回数に比例して費用がかかります。企画側が減らしたいのは費用であって、スタッフ数でも利用回数でも営業日数でもありません。しかし費用を抑えようとすると、削る候補になるのはこの3つです。対象店舗を絞る、1日の利用回数に上限を設ける、対象をベテランスタッフだけにする、という削り方です。全員が毎回使えるようにしたいという条件をつけるほど、最初の目的を達成しにくくなります。

条件をつけた企画は、稟議の場でも説明が難しくなります。「なぜこの店舗だけなのか」「なぜ1日3回までなのか」「来年出店が増えたら費用はどう変わるのか」を、担当者は聞かれるたびに答えなければなりません。店舗数は出店・閉店で毎年変わるので、費用の見積もりも毎年やり直します。情報システム部門にとっても、利用回数が読めない機能を予算化するのは扱いにくい話です。私は、この説明の難しさと見積もりをやり直す手間が、店舗スタッフ向けAI機能が何度も企画に上がりながら、実現まで進まなかった理由の一つだと見ています。

端末内で処理を終える設計なら、この式そのものが要りません。スタッフ数や利用回数、店舗数が増えても、AIを呼ぶたびの費用は変わらないからです。予算を組むときに毎年計算し直す数字も減ります。

会員向けアプリなら、利用回数は会員の行動で決まり、際限なくは増えません。1人の会員が1日に何十回もレシートを撮る、ということは起きにくいからです。店舗スタッフ向けの機能はそうなりません。勤務時間中は何度でも使う場面があり、スタッフ数も営業日数も企画側では動かせない数字です。回数の上限を決めにくい業務ほど、従量課金の費用は増えます。

回数を気にしないなら、処理はいつ動かすべきか？

回数で費用が増えないなら、処理する時間帯を選べます。

店舗スタッフは、前の勤務者からの引継ぎメモを読み、納品書や棚札を確認し、お客様から口頭で受けた要望をメモします。これを1日に何度も繰り返します。今は、その都度スタッフが自分で内容を整理し、店舗アプリの在庫データや発注データと突き合わせています。

呼び出し回数を気にしなくてよいなら、この整理をスタッフが画面を開く前にAIに済ませておけます。休憩中や勤務交代の直前にまとめて整形する、スタッフが画面を開く前にバックヤードで処理を進めておく、という使い方です。たとえば、閉店後の棚卸しメモは翌朝のオープン前にまとめて整形しておき、出勤したスタッフは確認するだけで済むようにする、という使い方です。シフトの入れ替わりが多い時間帯なら、交代前の30分でその日の引継ぎメモをまとめて整形しておきます。操作の直後に結果を見せる必要がない場面なら、処理に時間がかかっても困りません。回数を絞る前提では検討しなかった使い方です。

バックヤードは什器に囲まれていて電波が弱いことが多いのですが、端末の中で処理する分には影響しません。通信が必要になるのは、整形結果を店舗アプリの在庫データや発注データに反映するときだけです。在庫・発注データは、端末に保存してある最新の取得分を使い、取得日時を画面に出します。通信が戻ったら照合し直してから確定します。

店舗スタッフはパート・アルバイトを中心に入れ替わりが多い仕事です。新しく入ったスタッフに、引継ぎメモの書き方や在庫データの参照ルールを一から教えるのは、教える側にも負担になります。整形をAIに任せる設計なら、スタッフは普段どおりの言葉でメモを残すだけで済み、書式そのものを覚えてもらう必要が減ります。書式に慣れていない新人スタッフほど、覚える項目が減ります。

端末内で処理する設計を選ぶのは、通信が弱いバックヤードでも動くこと、呼び出し回数で費用が増えないことが、この業務では重要だからです。逆に、支給端末の対応比率が低い場合、整形の精度が店長の確認で十分と言えない場合、まとめ処理でも件数が多く間に合わない場合は、端末内を選ばず、いまの運用を続けるか別の設計を検討します。

在庫データを丸ごとAIに渡す必要はあるか？

その必要はありません。AIに渡すのは、担当している売場の在庫・発注データだけに絞ります。

店舗アプリの在庫データや発注データをAIが参照できるようにする場合、渡す機能はその作業に必要なものだけに絞ります。汎用のAIは、そのチェーン独自の在庫データを知りません。参照する自作ツールを一つ用意すれば、AIはその場でメモの内容と在庫・発注データを照合できます。逆に、店舗の全売場・全カテゴリの在庫データをまとめて渡す設計にすると、AIに説明する情報量が増えるだけでなく、担当外の売場のデータまでスタッフの端末から見えてしまいます。担当している売場の分だけを見せるツールにしておけば、AIに説明する情報量を絞れますし、スタッフが確認できる範囲も担当売場に限定できます。スタッフが売場を異動したときは、参照できる範囲をその都度切り替える運用も、あわせて決めておく必要があります。

文字の読み取り（OCR）やバーコードの読み取り、端末内の検索といった標準機能（AI にツールを持たせる（OCRTool・バーコード・端末内検索））と、この在庫・発注データを参照する自作ツールを組み合わせれば、納品書や棚札の情報と、システム上の在庫・発注データを、その場で突き合わせる設計になります。納品書の数量はOCRで、棚札はバーコードの読み取りで、それぞれ発注データを自作ツールで引き当てて数量の差分を出します。たとえば、スタッフが残したメモ「3番棚の来客用グラスが残り2、明日入荷か確認」は、AIが「売場: 3番棚」「商品: 来客用グラス」「残数: 2」「依頼事項: 明日入荷か確認」と項目に振り分けた下書きになります。

店長は何を見て確定するのか？

AIが整形した引継ぎメモと、在庫・発注データの突き合わせ結果は、店長の画面に下書きとして並びます。下書き一覧には、引継ぎメモごとに「元のメモの原文」「AIが読み取った内容」「在庫・発注データとの差分」「記録したスタッフと時刻」が並び、差分があれば色を付けて表示します。差分が大きい項目は一覧の上に表示し、店長が見落とさないようにします。大きいの基準は、発注数量に関わる差か、欠品につながる差です。原文のメモが読み取れない場合や、在庫データの取得日時が古い場合は、店長は確定を保留し、内容を確認してから確定します。店長はこの一覧を確認し、内容に誤りがなければ確定ボタンを押します。確定した内容だけが、発注量の変更や欠品対応の優先順位づけに使われます。

この確認と確定を挟むことで、AIが読み間違えた内容や、在庫・発注データと矛盾する内容が、そのまま発注の判断に使われることを減らせます。記録したスタッフと確定した店長の両方が画面に残るので、あとから誰が書いて誰が確定したかを確認できます。内容に誤りがあれば、店長はそのまま確定するのではなく、下書きを直してから確定ボタンを押します。複数の売場を掛け持ちする店長なら、一覧を売場ごとに並べ替えられるようにしておくと、確認の抜け漏れを減らせます。最終判断は、これまでどおり店長や発注担当者が担います。

対応端末・費用などの共通の前提は、iPhoneの中でAIが動くと、どの業界の何が変わるのか（Apple Intelligence 業界別活用マップ） の「どの業務にも共通する前提」にまとめています。

1店舗、引継ぎメモの整形だけで始める

まず1店舗で、引継ぎメモの整形だけを試します。棚卸しや発注判断そのものは対象に含めず、引継ぎメモをAIが整形し、店長が確認して確定する、という手順だけに絞ります。在庫データとの突き合わせは2段階目とし、初回の試作には含めません。

継続するかどうかの基準は、試す前に決めておきます。

この表は試す前に埋めておきます。結果を見てから基準を決めると、結果に合わせた基準になります。

用意するものは、対応端末（iPhone 15 Pro/Pro Max か iPhone 16 以降）がそろい、Apple Intelligenceをオンにできる店舗、引継ぎメモのお手本数十件、そして店長が確認して確定する画面です。試作は自社の開発部門か開発会社に、メモを撮る、下書きにする、店長が確認して確定する、という最小の画面を作ってもらうところから始めます。

よくある質問

全店舗に一度に配る必要がありますか？

その必要はありません。まずは対応端末（iPhone 15 Pro/Pro Max か iPhone 16 以降）がそろい、Apple Intelligenceをオンにできる店舗を選んで始め、効果を確かめてから対象店舗を広げる進め方で足ります。対象店舗を絞る判断は、費用ではなく検証の順番として説明できます。

在庫・発注データを参照する自作ツールは、店舗アプリの改修が必要になりますか？

改修の規模は未検証です。担当している売場の在庫・発注データだけを渡す設計にすれば、改修する範囲を絞れるのではないかと考えています。

パート・アルバイトの入れ替わりが多い店舗でも運用できますか？

そのための設計だと考えています。整形をAIに任せる分、スタッフは引継ぎメモの書式を覚えなくてよく、普段どおりの言葉でメモを残せば足ります。新しく入ったスタッフに教える項目が減ります。

参考

• Apple公式（WWDC2026）: https://developer.apple.com/videos/play/wwdc2026/241/
• Apple公式（Apple Foundation Models 第3世代）: https://machinelearning.apple.com/research/introducing-third-generation-of-apple-foundation-models
• 「生活雑貨の大手チェーンでは、店員向けに3,000台以上のiPod touchを配り、バーコードリーダーを付けて発注や在庫確認に使っています」（SHOPCOUNTER Magazine） https://shopcounter.jp/magazine/success-story/tokyu-hands-use-ipod-touch-and-ipad

では、おつかめ！

--

クラスメソッドでは、既存スマホアプリをFlutterでiOS/Android同時に作り直し、バックエンドはAWSで再構築する「AI駆動アプリリニューアル」を提供しています。現行アプリの仕様読み解きから設計・実装まで生成AIを組み込んだ開発プロセスで進めるため、レガシー化したアプリのリニューアルを短い期間で作り直します。
サービス詳細・お問い合わせはこちら