上場企業 91APP-iCHEF のデバッグを無償でやってやった。台湾中の店の客単価が削られている

星五つのレビューひとつで、POS の同期が複数選択を単一選択に上書きしてしまうお粗末なバグが露見した。被害はうちの火鍋屋一軒ではない。追加注文のロジックを必要とする台湾中の店だ。

午後をまるごと潰して、91APP-iCHEF のデバッグをしてやった

5/12 追記：

この件をケースに、ビジネス・インサイトをひとつまとめた：http://case.4force.com.tw

興味ある？　こっちはいまも金を垂れ流している。AOV suppression case（客単価抑制ケース）とは何か。これがそうだ。どうも。

2026年5月10日、Uber 経由のコア顧客のひとり、うちの店で18回注文してくれている人が、Uber Eats に星五つのレビューを残した。

「お肉がチェックボックス式なので、2人前以上追加できません。改善をお願いします」

星五つ。それでも彼女は星五つをくれたのだ。そこで私はシステムを調べた。

問題は単純だ。うちは火鍋のデリバリーブランドで、iCHEF の POS を Uber Eats と foodpanda に連携させている。火鍋の追加注文の肝は、同じ肉を何皿でも頼めることにある。豚肉×2、牛肉×1、というように。飲食業界では Quantity in Modifiers と呼ばれる仕組みで、目新しい機能でもなんでもない。

現状：

foodpanda：正常
Uber Eats：同じ品目は1つしか選べない（単一選択のボックス）

午後いっぱいかけて、自分で再現してみた：

Uber Eats の管理画面で複数選択を手動でオンにする → 注文画面は正常
iCHEF の管理画面で同期（publish）を実行する → Uber Eats 側が単一選択に強制的に上書きされる

一連の操作は、ノーカットで全部録画してある。

これは大バグではない。初歩的な大ポカだ

クラッシュや強制終了は、エンジニアリングの事故だ。これは、プロダクトに対する認識の事故である。

Uber Eats の管理画面はこの機能をネイティブでサポートしていて、API も開いている。つまり、可能性は三つしかない：

BD が話をつけていない：ビジネス連携の交渉力に問題がある
開発（RD）が実装していない：プロダクトの優先順位が長年ずれたまま
サポートが放置している：問題が来ると、まず客の頭の中の「認識」を正しにかかり、問題の本質を見ない。

しかも foodpanda では動いている。ロジック層はすでにあるということだ。Uber 側がつながっていないのは、技術の問題ではない。

サポートの SOP は、この機械の縮図だ

今日、iCHEF のサポートと2時間近くやり合った。担当者はひたすら「単一選択に設定すれば、単一選択で同期されます」と説明し続けた。それは正しい。だが、私が訊いたことではない。

私が訊いたのは、複数選択に設定したのに、なぜ同期すると単一選択になるのか、だ。

この二つの文は、同じ文ではない。

サポートの SOP が彼女に叩き込んでいるのは「仕様を説明すること」であって、「客の問題を理解し、しかるべき層へエスカレーションすること」ではない。つまりこの会社のサービス設計の核は、自分たちがミスをしないよう身を守ることであって、店の問題を解決することではない。

結局、私が自分で完全なインシデントレポートをまとめ、口元まで運んでやって、ようやくエンジニアに回してもらえた。

それから、91APP の IR ページを見に行った

「AI 技術とインサイト分析を基盤となる能力とし、オンラインとオフラインを横断するオムニチャネル・ソリューションを提供する」

火鍋屋で肉を追加するための quantity modifier ひとつが、客のレビューでようやく発覚する。

91APP が iCHEF を買収したとき、市場が期待したのは統合によるアップグレードだった。いま見えているのは、大企業のプライオリティの狂いが、きれいな IR の文言で包装されている姿だ。

iCHEF の顧客は万単位の店舗に及ぶ。影響を受けるのは、「同じ品目を複数追加する」必要がある業態すべてだ。火鍋、焼肉、ドリンクスタンド。影響は何千店に及ぶのか。わからない。だが、客単価（AOV）を落とされた店が必ずあることはわかる。少なくとも私には、自分の店の数字がある。それに、あの星五つの常連客が好意で残してくれたスクリーンショットも。

「これが 91APP の過去2年の株価推移だ。」

これが検証動画だ

https://www.youtube.com/watch?v=hqcIungClbg

もし iCHEF の月額料金の引き落とし機能が72時間止まったら、彼らは「穏便に済ませる」だろうか。全社に明かりが灯ったまま、直るまで総出で徹夜するに決まっている。

ところが、店の売上を生む機能が壊れても、サポートに延々と堂々巡りの相手をさせておける。

エンジニア諸君に提言する：

Uber に payload を送ったあと、送信した値と iCHEF 管理画面の設定値が一致しているかを突き合わせる監視レイヤー、つまり diff check を、なぜ置いていない？

注文の特徴を監視するのが、そんなに難しいか？　複数追加の注記がついた注文の比率が0%になったら、アラートが自動で PM に飛ぶようにしていないのか？

これは技術の問題ではない。誰の金のほうが大事だと思っているか、の問題だ。

本稿の初出は方格子（Vocus）、2026.05.10。