GeeLarkで全米の食事割引サービスを拡大した創業者の事例
GeeLarkは、SNS運用やマーケティング施策の拡大で使われることが多いサービスです。ただ、その活用範囲はそれだけにとどまりません。
今回は、単独で事業を運営するNick氏が、GeeLarkのクラウドスマホとAI主導の自動化を使い、全米の飲食店割引情報を見つけて利用できる仕組みをどう構築したのかを紹介します。実際の顧客のように都市ごとに動作する500ステップ規模のワークフローを、1人で運用している事例です。
Nick氏が目指したのは、アメリカ各地で使えるお得な食事キャンペーンを、ファストフードから着席型レストランまで幅広く見つけやすくすることでした。アイデア自体はシンプルですが、複数都市と複数アプリをまたいで安定して動かすには、手作業だけでは限界があります。
飲食店の割引は頻繁に変わり、表示される内容も都市や時間帯、利用するアプリによって変化します。そこで必要になったのが、複数の場所と複数のモバイルアプリを同時に扱える運用基盤でした。Nick氏にとって、その土台になったのがGeeLarkです。
全米の食事割引を追跡する仕組みをどう作ったか
この取り組みの目的は明快です。全米のユーザーが、自分の地域で使える飲食店の割引情報を見つけ、実際に活用しやすくすることでした。ところが、実行段階では地域差とアプリ差が大きな壁になります。
同じチェーンでも、ある都市で見える特典が別の都市では表示されないことがあります。時間限定のオファーも多く、1つの端末や1つのアカウントだけで全体を追うのは現実的ではありません。こうした前提のもとで、複数拠点を並行運用できる構成が求められました。
GeeLarkが複数都市の同時運用を可能にした理由
GeeLark導入前は、多くの確認作業を手動で回していたため、見られる場所もアプリ数も限られていました。規模を広げようとすると、端末の追加、アカウントの追加、同じ操作の繰り返しが必要になり、時間も管理コストも膨らみます。
いまはGeeLarkのクラウドスマホを使い、複数の環境を同時に動かせるようになりました。各クラウドスマホは次の要素を個別に持てます。
- 端末情報
- 位置情報
- プロキシ
- アプリ環境
実務上は、各端末がアメリカの各都市で実際にアプリを使うユーザーのように動作できることを意味します。物理端末を大量に管理しなくても、複数の飲食店アプリと複数地域を並行して扱えるようになった点が大きな変化でした。
事業を支える500ステップのAI自動化フロー
Nick氏が最も驚いたのは、クラウドスマホそのものよりも、自動化を細かく設計できることだったと言います。AIに設計を補助させながら、現在では約500ステップのワークフローを構築しています。
数字だけを見ると大がかりに感じますが、安定して運用するためには必要な粒度でした。ワークフローでは、次のような処理を順番に扱います。
- プロキシの検証
- GPSの連携と調整
- 飲食店アプリ内の画面遷移
- アプリ状態の管理
- エラー発生時の復旧
- 支払い処理
- 自動化チェックと再試行
こうした処理が自動で安定して回るため、バックグラウンドでは仕組みが動き続け、Nick氏自身は事業を伸ばすための判断や改善に集中できます。
1人でも構築を続けられる運用基盤になった
Nick氏にとって、GeeLarkの価値は単なるインフラ整備にとどまりませんでした。変化の速い環境でも、個人の創業者が意味のある仕組みを作り続けられるという手応えを得られたことが大きかったと語っています。
需要が伸びても供給側の処理は自動で拡張し、複雑さはAIを活用したワークフローが吸収する。その上で創業者本人はビジョンの整理と事業判断に集中する。この役割分担が、1人でも継続運営できる形を支えています。
この事業に取り組む理由が明確になった瞬間
Nick氏はもともとSNSマーケティングの文脈からGeeLarkに触れましたが、次第に「本当に広める価値があるものは何か」を考えるようになったそうです。その答えを探すなかで、食費支援をめぐる制度変更や栄養基準に関する議論を見聞きし、生活者が置かれた厳しい状況に向き合うことになりました。
市場調査では、生活費に困る人々がSNS上で食料品を不正に持ち出す方法を共有している場面まで目にしたと言います。そうした光景を前に、必要なのは説教ではなく、より良い選択肢を見つけやすくする仕組みだと考えるようになりました。
この事例は、GeeLarkがSNS運用だけでなく、地域差の大きいモバイルアプリ業務を個人でもスケールできる基盤になり得ることを示しています。複数都市で同時に検証しながら、複雑な処理を自動化したい場合の参考になる事例です。






