【iOS 27】店舗スタッフが話したメモに売場と依頼の種類のタグを付ける機能を作って、iPhone 15 Proで測ってみた

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

前回、店舗スタッフ全員に「毎回使っていいAI」を、なぜこれまで配れなかったのかという記事を書きました。呼び出すたびの費用を気にしなくてよいなら、店舗スタッフの引継ぎメモを売場・商品・残数・依頼事項の項目に振り分けて整えられる、という内容です。

この作業を端末の中だけで済ませる理由は、回数の多さです。店舗スタッフは1日に何度も引継ぎメモを残します。クラウドの従量課金AIでは、全員が毎回使える設計にすると呼び出し回数に比例して費用がかかりますが、端末の中で終える設計ならこの費用は増えません。

今回はその中で、スタッフが話した短いメモに売場・依頼の種類・急ぎのタグを付けるところだけを取り出してアプリを作り、iPhone 15 Proの実機で測りました。私が実際に声に出したメモを、iPhoneの中だけで動く音声認識にかけ、タグの正しさを数えています。

先に、前回の仮説への答え

前回の記事で書いたことを4つに分け、実物のメモ5本・各3回、計15回の結果で答えます。

売場と依頼の種類のタグ付けは、実物の声でもすべて正しく付きました。 1回目はタグ全体の正答が39/45 = 86.7%で、合格ラインの9割に届きませんでした。間違えた6回はすべて急ぎのタグで、原因は音声認識の聞き違いです。急ぎのルールを、字ではなく読みで照合する形に直すと、42/45 = 93.3%で合格ラインを越えました。実物を見てから直したあとの数字です。

作ったもの

売場10種・依頼の種類8種の候補から選ばせる構造化出力を作りました。候補の語にはそれぞれ意味を書いて渡しています。

enum StoreVocabulary {
    static let areas = ["食品", "日用品", "化粧品", "医薬品", "衣料", "家庭用品", "レジ", "バックヤード", "入口・通路", "その他"]
    static let requests = ["発注・在庫の確認", "補充・品出し", "清掃", "破損・不良", "値札・表示", "お客さまの要望", "設備の不具合", "その他"]
}

@Generable
struct StoreMemoTags {
    @Guide(description: """
    メモが関わる売場。レジの機械やレシートのことはレジ。食品は食べ物・飲み物と冷蔵・冷凍のケース。日用品は洗剤・トイレットペーパー・シャンプーなどの消耗品。
    化粧品は化粧水・メイク用品・テスター。医薬品は風邪薬などの薬。衣料は服・下着・子ども服とそのハンガー。
    家庭用品は食器・グラス・調理器具・収納用品。レジはレジとその機器。バックヤードは売場の裏の倉庫や作業場。入口・通路は入口、通路、床
    """, .anyOf(StoreVocabulary.areas))
    var area: String

    @Guide(description: """
    メモで頼んでいることの種類。発注・在庫の確認は、在庫が少ない・発注してほしい・入荷を確かめてほしいとき。
    補充・品出しは、売場の棚に商品を出してほしいとき。清掃は拭く・片付ける。破損・不良は壊れた・折れた・傷んだもの。
    値札・表示は値段の誤りや、外し忘れ・付け違いのPOPや札。お客さまの要望はお客さまに頼まれた・聞かれたこと。設備の不具合は機器やケースの故障や異常。
    物が置かれて通れない、散らかっている、は清掃。服や商品が伸びた・汚れた・つぶれた、は破損・不良
    """, .anyOf(StoreVocabulary.requests))
    var request: String
}

エンジニアではない私でも、候補の語に意味を書いて渡すだけでここまでの仕分けは作れました。

候補に意味を渡さないパターンで最初に試してみたところ、「3番棚の来客用グラスが残り2」というメモの売場を食品と答えました。候補の語ごとに何を含むかを説明に書いてから、この誤りは消えました！

急ぎのタグは、モデルには聞かせていません。メモの言葉（すぐ、今日中、開店前、至急など）が入っているかどうかをルールで決めます。

enum StoreUrgency {
    static let words = ["すぐ", "今日中", "本日中", "開店前", "至急", "急いで", "急ぎ", "早急", "午前中に", "閉店まで"]
    static func isUrgent(_ memo: String) -> Bool { words.contains { memo.contains($0) } }
}

というのも、事前の試しでモデルに急ぎかどうかを聞くと、ほぼ全部を急ぎと答えました（急ぎの正答12/30）。前の検証記事でたどり着いた「文字にするのは文字認識・音声認識、数字と有無はルール、モデルは整える・選ぶ・分ける」という原則どおり、急ぎの有無は最初からルールにしています。

測り方

では、こんな感じでタグ付けできれば現場でも助かるんだろうな、と考えてから測り方を決めました。合格ラインは、タグ（売場・依頼の種類・急ぎ）の9割以上が正しいことです。測る前に決めました。

見本は3種類用意しました。決まった言葉（レジ、品出しなど）が入った合成の見本10本、決まった言葉を避けた言い方にした言い換えの見本10本（例:「入ってすぐのところ、ジュースこぼれてベタベタ」）、私が実際にiPhoneに向かって声に出した実物5本です。実物の中身はすべて架空の記録です。各3回ずつ測りました。

音声認識はSFSpeechRecognizer（ja-JP）で、requiresOnDeviceRecognitionをtrueにし、端末の中だけで動く認識だけを使いました。

合成と言い換えの見本では、次の結果でした。

両方が合格ラインに届いたので、実物に進みました。

比べ役として、売場と依頼の種類も言葉の一覧だけで決めるルールを用意しています。言い方に合わせて言葉を足せば当たりますが、店舗の言い方が増えるたびに書き足すことになる作りです。

参考として、合成と言い換えの原稿をMacの読み上げ音声にして音声認識にかけた見本も測りました。書き起こしの文字の誤り率が18.6〜22.0%あり、私の声よりも大幅に崩れました。読み上げ音声は人の声の代わりにならないので、音声認識を通す条件は実物（人の声）で判断しています。

実物で測った結果

私が声に出した実物5本を、音声認識にかけた結果です。

間違えた6回は、すべて急ぎのタグでした。正直、ここは予想外でした。1件ずつ見ると、急ぎの言葉が音声認識の聞き違いで崩れていました。「すぐ拭いて欲しいです」は「すごい拭いて欲しいです」に、「開店前に見てほしい」は「回転前に見といて欲しいです」になっています。ルールは「すぐ」「開店前」という言葉があるかを見るので、崩れた言葉には当たりません。

これを直すために2つ試してみました。1つは、急ぎの判定をモデルにも「はい・いいえ」で聞かせ、聞き違いがありうると指示に書いて比べることです。もう1つは、場面の語彙（開店前、すぐ、レジなど）を認識器に渡す設定（contextualStrings）です。

急ぎの正答を、ルールとモデルで比べた結果です。

実物では変わらず、原稿のままの見本ではモデルに判定させたほうが悪くなりました。認識器に語彙を渡す設定では、実物5本の書き起こしが1文字も変わりませんでした。どちらも効きませんでした。ここは少しハマりました。

なので3つ目に、ルールの照合を字から読みに広げました。「回転前」と「開店前」は、字は違っても読みはどちらも「かいてんまえ」です。書き起こしを端末の中でローマ字の読みに直し（CFStringTokenizer の読みの属性）、急ぎの言葉の読みが含まれていれば急ぎとします。「すぐ」のように読みの短い言葉は、「まっすぐ」のような別の言葉の読みの一部に当たりやすいので、読みでは照合しません。

static func isUrgent(_ memo: String) -> Bool {
    if words.contains(where: { memo.contains($0) }) { return true }
    let r = reading(memo)
    return readings.contains { r.contains($0) }
}

同じ実物5本を、直した作りで測り直した結果です。

「回転前に見といて欲しいです」は、3回とも急ぎになりました。「すごい拭いて欲しいです」は、読みも「すぐ」と違うので、直りませんでした。「すごい」まで急ぎに数えると、「すごい混んでる」のような急ぎでないメモまで急ぎになります。

合成と言い換えの見本でも測り直し、急ぎの正答は変わりませんでした（原稿のままで合成30/30、言い換え30/30）。2回目は機内モードでWi-Fiも切った状態で測ってみました。通信がなくても同じように動きました。かかった時間は、モデルの呼び出しが中央値1.69秒、音声認識が中央値0.28秒でした。

ルールだけでは、どこまで読めたか

売場と依頼の種類も、言葉の一覧だけで決めるルールと比べました。急ぎはどちらも同じルール（字と読みで照合）です。

実物の書き起こしで、ルールが間違えた例です。

「入り口のイカが濡れていて滑りやすいです。すごい拭いて欲しいです。」は、ルールの言葉が「入口」だったため売場がその他になりました。モデルは入口・通路と清掃を選んでいます。

「食品の売り場なんだけど、卵の値札が先週の値段のままになってました」は、「卵」も「食品」もルールの一覧になく、売場がその他になりました。モデルは食品と値札・表示を選んでいます。

「0時1番のバーコードが読めなくなっちゃってました。回転前に見といて欲しいです。」は、売場も依頼もその他になりました。モデルはレジと設備の不具合を選んでいます。

この業務で、Apple Intelligence で輝けるか？

輝けます。売場と依頼の種類を選ぶところは、崩れた書き起こしからでもモデルがすべて正しく選び、ルールだけの作りを上回りました。

モデルは、候補に意味を添えて渡され、売場と依頼の種類を選ぶことです。ルールは、急ぎの言葉があるかどうかを、字と読みの両方で見ることです。急ぎの判定をモデルに任せると、かえって悪くなりました。

まだ言えないのは、「すぐ」が「すごい」になったように、読みも違う言葉に聞き違えた急ぎの扱いです。ルールでもモデルでも直せていません。タグを人が直す画面は、今回は作っていません。

次に試すこと

実物はいまのところ私1人の声、5本だけです。次に試すのは、件数を増やすこと、複数のスタッフの声で試すこと、店舗の騒音がある場所で話した声で試すことです。「すごい」のような聞き違いがどのくらいの割合で起きるかも、件数を増やして数えます。端末は同じiPhone 15 Proのままにします。画面側で急ぎを1タップで選ばせるような手当ては、今回の範囲では扱いません。

よくある質問

急ぎの判定は、AIモデルに任せたほうがよいのではありませんか。

試しましたが、悪化しました。実物（1回目の書き起こし）では9/15で変わらず、合成の見本では30/30から21/30、言い換えの見本では30/30から12/30に下がりました。急ぎはルールのままにしています。

話した内容ではなく、写真の文字から同じタグは付けられませんか。

別に測る必要があります。前回の記事では引継ぎメモを撮る例で書きましたが、文字を写す業務は文字認識の範囲だとパスポートと免許証を撮って宿泊者名簿の下書きにする機能を作って、iPhone 15 Proで測ってみたで分かったので、今回は話して入力する形で測りました。写真からの精度は測っていません。

在庫データとの突き合わせは、いつ測りますか。

前回の記事でも2段階目としていて、今回も測っていません。次の段階の課題です。

参考

• Apple Developer Documentation, Foundation Models: https://developer.apple.com/documentation/foundationmodels
• Apple Developer Documentation, requiresOnDeviceRecognition: https://developer.apple.com/documentation/speech/sfspeechrecognitionrequest/requiresondevicerecognition
• Apple公式（WWDC2026）: https://developer.apple.com/videos/play/wwdc2026/241/

話したメモにタグを付ける仕組み、店舗のiPhoneでもぜひ一度試してみてください！

では、おつかめ！

--

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