Cursor 3.9のモバイル対応とは、AIコーディングエージェントをスマホから起動・遠隔操作できる仕組みのことです。
2026年6月29日、AIコードエディタのCursorがiOS向けネイティブアプリを公開ベータとして出しました。ノートPCの前に座っていなくても、スマホからクラウド上のエージェントを起動し、手元のPCで動いているエージェントを遠隔操作し、レビューからマージまで完了できるという設計です。EC開発の現場に引き寄せると、移動中や店舗のバックヤードから「Shopifyテーマのこの表示を直して」「この商品CSVをこのルールで整形して」とスマホで指示を出し、席に戻ったら差分だけ確認する、という働き方が視野に入ってきました。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援を2023年から提供する株式会社オルセル(うるチカラ運営)の現場知見にもとづき、Cursor 3.9系のモバイル機能をEC開発へどう落とし込むかを、確認できた一次情報と具体的な操作手順で解説します。読み終えたときに、自店のどの作業を最初にスマホ指示へ移すか、判断がつく状態を目指します。
Cursor 3.9のモバイル対応で開発現場の何が動いたか
Cursor 3.9系で動いた最大の変化は、開発作業が「PCの前にいる時間」から切り離された点です。理由は、エージェントの実行場所がローカルPCとクラウドの両方に広がり、その両方をスマホから制御できるようになったためです。具体的には、Cursor公式が同日のchangelogで示したとおり、モバイルアプリからリポジトリを選んでエージェントを起動でき、手元のPCで走っているエージェントはRemote Controlで遠隔操作できます。出典はCursor公式changelogです。
クラウドエージェントは、隔離された仮想マシン上で完結する開発環境を持ちます。公式ブログの表現を引くと「Cloud agents run in isolated virtual machines with full development environments to test, verify, and demo work(クラウドエージェントは、テスト・検証・デモまで行える完全な開発環境を備えた隔離仮想マシン上で動く)」とあります。ここが実務上の肝で、エージェントは非同期に長時間動き、マージ可能なプルリクエストまで自力で仕上げにいきます。ローカルで作った計画をクラウドへ送る、稼働中のエージェントをクラウドへ移してPCを閉じても走り続けさせる、逆にクラウドの作業をローカルへ戻して手元で検証する、といったローカルとクラウドの受け渡しが用意されています。この非同期・並列で動くエージェントの考え方は、Claude Codeのforkとバックグラウンド並列実行で解説した設計思想と地続きです。
Remote Controlは、ローカルPCで動かしているエージェントの手綱をスマホに渡す機能です。席を外している間もPCへ到達できるよう、コンピュータをスリープさせない設定を有効にできます。組織利用での注意点として、TeamsおよびEnterpriseプランでは管理者がCursorダッシュボードからRemote Controlを有効化する必要があります。社内でモバイル運用を始める際は、まずこの管理者設定の可否から確認するのが手戻りを防ぐ順序です。
通知と成果物の扱いも実務向きに整理されました。エージェントが動き出したあとはアプリを離れてよく、ロック画面のLive Activitiesと、完了・入力待ち・レビュー準備完了のタイミングでのプッシュ通知で状況を追えます。仕上がったらデモ・スクリーンショット・ログ・差分をスマホで確認し、追加指示を残すか、プルリクエストをそのままマージできます。海外の受け止めとしても、TechCrunchは「外出先でコーディングエージェントを導くためのモバイルアプリ」と位置づけて報じました。
事実確認として補足します。iOSアプリ、クラウドエージェント、Remote Controlの各機能は、いずれも2026年6月29日付でCursor公式ブログとchangelogに掲載されたものです。Cursorはビルド更新が速く、公式ページ上ではバージョン番号ではなく日付単位で更新が告知されるため、細かな版数(3.9系など)は公式changelogで随時確認してください。また、本稿執筆時点(2026年7月)で公式に公開が確認できるネイティブアプリはiOS版の公開ベータで、Android向けネイティブアプリの提供有無は公式発表を確認できていません(要確認)。対応端末とプランは、導入前にcursor.comで確認する前提で読み進めてください。
EC開発でスマホ指示が活きる3つの局面
スマホ指示が最も活きるのは、コードやデータを扱う定型作業を、思いついた瞬間に着手できる局面です。理由は、CursorのエージェントがGitリポジトリを対象に動くため、EC事業者の作業のうち「リポジトリで管理できるもの」がそのまま射程に入るからです。逆に言えば、楽天RMSやAmazonセラーセントラルの管理画面を直接クリック操作するわけではありません。ここを正しく捉えると、期待値のズレなく使い始められます。
第一の局面は、Shopifyや自社ECのフロントエンド改修です。ShopifyのテーマはGit連携でリポジトリ管理でき、Liquidテンプレートやセクション、CSSはコードとして扱えます。たとえば「商品ページの送料無料バッジが特定条件で二重表示される」という不具合を移動中に見つけたとき、その場でクラウドエージェントに調査と修正案の作成を投げ、席に戻る頃には差分とプレビューが揃っている、という流れが組めます。公式ブログも、Xなどで見かけたユーザーの声をスクリーンショットで撮り、注釈を付けてエージェントへ視覚的な文脈として渡す使い方を挙げています。画像を起点にしたUI修正の考え方は、画像を読ませてEC開発を進める手法でも整理しています。
第二の局面は、商品データの整形と変換です。各モールやカートからエクスポートした商品CSVを、命名規則の統一、価格帯での絞り込み、禁止ワードの検出、画像URLの一括置換といったルールで加工するスクリプトを、エージェントに書かせて実行させます。クラウドエージェントは仮想マシン内でスクリプトを走らせ、結果のログや出力ファイルまで用意できるため、スマホからでも「変換後の件数」「弾いた行数」を確認して品質を担保できます。食品ギフトのように季節で商品名やのし対応を一斉に変える必要があるジャンルでは、この即応性が活きます。
第三の局面は、モールAPIやバッチ連携の小改修です。楽天やAmazonの注文データを社内システムへ取り込む連携スクリプト、在庫同期のバッチ、レビュー収集の定期処理などは、いずれもコードで管理されているはずです。障害の一次調査や設定値の修正なら、オンコール対応の初動としてスマホから着手できます。ここで重要なのは、どのモデルにやらせるかの見極めです。Cursorは起動時に任意のフロンティアモデルを選べるため、複雑な設計判断はより上位のモデル、単純な整形は軽量モデル、と役割を分けると費用対効果が上がります。モデルの選び分けは、GitHub CopilotとClaude Sonnet 5を軸にしたEC開発でのモデル選択で詳しく扱っています。2026年7月時点のフロンティアモデルは、OpenAIのGPT-5.6(2026年7月9日公開)、AnthropicのClaude Opus 5とClaude Sonnet 5(Sonnet 5は2026年6月30日公開)、GoogleのGemini 3.6 Flash(2026年7月21日公開、出力トークンを従来比で約17%削減とGoogleが説明)などが挙がります。
ジャンル別に見ると、効果の出方には濃淡があります。アパレルや雑貨のように商品数が多くページ改修の頻度が高い店舗ほど、表示崩れの一次調査やキャンペーン用の軽微な差し替えをスマホ起点で回す価値が大きくなります。反対に、商品点数が少なく更新頻度も低い店舗では、CSV整形や連携バッチの保守といった裏方の作業のほうが恩恵を受けやすい傾向です。自店がどちらに寄るかで、最初にスマホ指示へ載せる作業を決めると迷いません。食品ギフトのように繁忙期と閑散期の落差が大きいジャンルでは、繁忙期の一次対応をスマホ側へ逃がす設計が有効です。
なお、こうしたスマホ起点の開発は、ノーコードでECアプリを組む発想とも接続します。要件が固まっていれば、Replit AgentでのEC向けアプリ内製のように、外出先で骨組みを起こしておき、PCに戻って仕上げる分担も現実的です。
スマホからCursorにEC開発を指示する手順
最短で成果を出す手順は、対象リポジトリの準備、モデルの選択、指示文の型化、レビュー基準の固定、という4段階に整理できます。理由は、スマホ指示は入力が短くなりがちで、前提を毎回書く手間がボトルネックになるためです。前提をリポジトリ側とプロンプトの型側に寄せておけば、現場では一文の依頼で動かせます。以下は自社EC・Shopify運用を想定した具体的な進め方です。
まず準備として、ShopifyテーマをGit連携し、商品CSVや変換スクリプトを1つのリポジトリに集約します。次にCursorのモバイルアプリでそのリポジトリを開き、タスクの重さに応じてモデルを選びます。設計を伴う改修は上位モデル、機械的な整形は軽量モデルという振り分けが目安です。指示は音声入力とスラッシュコマンドが使えるため、移動中でもハンズフリーで概要を伝え、細部は定型プロンプトに任せる形が回しやすいです。
音声入力を使うときは、固有名詞やファイル名を正確に伝えにくいという弱点があります。リポジトリ名やファイル名はスラッシュコマンドや候補選択から入力する運用にすると、誤認識による指示ミスを減らせます。移動中は改修の狙いや背景を音声で口述し、正確さが要る値やファイル名はテンプレートの穴埋めに寄せる、という役割分担が実務的です。細部まで音声で伝えようとすると、かえって修正のやり取りが増えます。
ここではスマホから出すEC開発指示のプロンプト例を2本示します。
用途タイトル:Shopifyテーマ(Liquid)の表示不具合をクラウドエージェントに調査・修正させる
あなたはShopifyテーマ開発に精通したフロントエンドエンジニアです。
このリポジトリのテーマコードを対象に、次の不具合を調査し、修正のプルリクエストを作成してください。
対象ジャンル:{ジャンル}
不具合の症状:{症状を1〜2文で。例:カート画面で送料無料バッジが特定条件のとき二重表示される}
再現条件:{分かる範囲で。例:カート金額が送料無料しきい値ちょうどのとき}
作業要件:
1. 原因箇所のLiquidテンプレートとCSSを特定し、なぜ起きるかを日本語で説明する
2. 影響範囲(他の商品ページ・モバイル表示)を確認し、副作用が出ないパッチにする
3. 修正前後のスクリーンショットまたはプレビューを成果物として残す
4. 楽天・Amazonなど外部モールのタグやURLをテーマに埋め込まない
5. コミットメッセージと変更点の要約を日本語で書く
完了したら、変更ファイル一覧と確認手順を通知してください。
用途タイトル:商品CSVを指定ルールで整形するスクリプトを書かせて実行・検証させる
あなたはEC運用の実務に強いデータエンジニアです。
このリポジトリにある商品CSVを、次のルールで整形するスクリプトを書き、仮想環境で実行してください。
入力ファイル:{ファイル名。例:products_export.csv}
対象ジャンル:{ジャンル}
ターゲットKW:{第1KW、第2KW}
整形ルール:
1. 商品名の先頭30字以内に{ターゲットKW}を1回だけ含める(重複KWは除去)
2. 「最強」「日本一」「No.1」「絶対」などの最大級・禁止表現を検出して一覧化する(自動置換はしない)
3. 価格が{下限}円未満の行を別ファイルに分離する
4. 画像URLのドメインを{旧ドメイン}から{新ドメイン}へ一括置換する
5. 文字コードと改行コードは元ファイルの仕様を維持する
出力要件:
- 整形後CSV、除外行CSV、検出した禁止表現のログの3ファイル
- 処理件数・除外件数・置換件数を要約して通知する
2本とも、変数は中括弧で統一し、モール規約に反する外部誘導や自動での表現改変を避ける安全策を組み込んでいます。運用のコツは、レビュー基準をあらかじめ決めておくことです。差分を見る観点を「規約違反の外部リンクが混ざっていないか」「数値の単位と件数が合っているか」「本番反映前にプレビューがあるか」の3点に固定すると、スマホの小さな画面でも短時間で可否を判断できます。仕上がったらプルリクエストをマージするか、追加指示を一言残して次の一手に進みます。
チーム運用で最初に決める権限とルール
チームで使い始めるときに最初に決めるべきは、誰のどの端末からリポジトリと手元のPCへ到達できるか、という到達範囲です。理由は、Remote Controlがローカルのマシンを外部から操作可能にする以上、権限設計の甘さがそのままリスクになるためです。TeamsとEnterpriseのプランでは、管理者がCursorダッシュボードからRemote Controlを有効化する必要があり、この一点が実質的な入口の鍵になります。
決めごとは3つに絞ると回り出します。1つ目は、モバイルから触れてよいリポジトリの範囲です。本番連携やAPIキーを含むリポジトリを最初から開放せず、テーマや表示まわりなど影響範囲の小さいものから許可します。2つ目は、マージ権限の所在です。エージェントがプルリクエストを作るところまでをスマホ運用に許し、本番反映のマージは責任者のレビューを通す、という段差を設けます。3つ目は、秘密情報の置き場所です。接続情報やトークンはシークレット管理へ寄せ、リポジトリ本体に平文で残さない運用を徹底します。
現場で繰り返し見るのは、便利さが先行して権限設計が後回しになるパターンです。5,000社支援の中で何度も再現したのは、運用ルールを最初に1枚へまとめておいた店舗ほど、モバイル運用の定着が早いという傾向でした。まずは表示改修のような低リスク領域でルールを固め、差し戻しが減ってから連携スクリプトなど影響の大きい領域へ広げるのが、無理のない順序です。
クラウドエージェントでつまずく点と回避策
つまずきの多くは、機能の万能視から生まれます。回避の原則は、対象をリポジトリ内に閉じ、モール規約と権限管理を先に固めることです。現場で繰り返し見るのは、次の3パターンです。
第一に、管理画面の直接操作を期待してしまうケースです。Cursorのエージェントはコードとファイルを扱うため、楽天RMSやAmazonセラーセントラルのボタンを押す作業はそのままでは代替できません。回避策は、モール操作をAPIやCSV連携としてコード化し、その部分だけをエージェントに任せる切り分けです。手作業の画面操作と、コード化できる処理を混同しないことが出発点になります。
第二に、モール規約に触れる変更が混入するケースです。たとえば楽天市場の商品ページやR-Mailに自社サイトやSNSへの外部リンクを差し込む改修は規約違反にあたります。エージェントは指示に忠実なので、あいまいな依頼だと意図せず外部誘導を足すことがあります。回避策は、プロンプトに「外部モールのタグやURLを埋め込まない」といった禁止条件を常時入れておくことと、レビュー時に外部リンクの有無を必ず確認することです。アパレル系の単一店舗で試したケースでは、この一文をテンプレートに固定しただけで差し戻しが目に見えて減りました。
第三に、権限とセキュリティの詰めが甘いケースです。クラウドエージェントは仮想マシン内で動くとはいえ、リポジトリには接続情報やAPIキーが含まれがちです。回避策は、秘密情報を環境変数やシークレット管理に寄せ、リポジトリ本体へ平文で置かないこと、そしてTeams・Enterpriseでは管理者がRemote Controlの有効範囲を管理することです。誰のどの端末からPCへ到達できるのかを、運用開始前に棚卸ししておくと安全です。
費用と工数の目安、見るべきKPI
費用対効果は、削減できる着手待ち時間と、レビューに残る人的工数のバランスで見ると判断しやすいです。理由は、スマホ指示の価値が「作業そのもの」より「着手までの時間短縮」に表れるためです。
工数の目安として、これまで席に戻ってから着手していた小改修や一次調査を、移動中の数分の指示に前倒しできると、1件あたり数十分から半日単位のリードタイム短縮が見込めます。直近の支援案件で観測したのは、軽微な表示崩れの修正が「翌営業日対応」から「当日中のプルリクエスト確認」へ縮まった例でした。数値は店舗の体制やリポジトリ整備状況に左右されるため、業界平均の見込みとして幅を持って捉えてください。
費用面では、モバイルアプリ自体はCursorの既存の有料プランで追加費用なく使える公開ベータとして提供されています。一方、クラウドエージェントは仮想マシン上での実行や利用モデルに応じたコストが関わるため、実行量が増えるほど費用も動きます。Cursorの現行プラン料金と、クラウド実行の課金条件は変動しうるため、cursor.com/pricingで最新の実額を確認してください(要確認)。モデル側の相場観としては、上位モデルほど1トークンあたりの単価が高いため、機械的な整形を軽量モデルに寄せるだけでも実行コストは下げられます。
追うべきKPIは、着手までのリードタイム、レビュー差し戻し率、そして本番反映後の不具合再発率の3つが軸になります。とくにレビュー差し戻し率は、プロンプトの型化がうまくいっているかを映す指標として有効です。差し戻しが多いなら、指示文に禁止条件や出力形式の指定を足していきます。
モール実務まで波及するのか、独自の見立て
この流れが最終的にモール実務まで届くかどうかは、EC事業者にとって最も気になる論点です。結論としては、直接のモール画面操作ではなく、モールと社内システムをつなぐ連携コードの内製・保守という側面から、じわじわと波及していくと見ています。
Cursor公式は今後、リポジトリを前提としない「repo-less chats」の追加を進めると述べています。これは、コードベースの文脈を必要としないタスクを、より気軽に投げられるようにする方向です。MCP(外部ツール連携の仕組み)経由でログ照会や情報集約を行う使い方も広がっており、社内の運用データをスマホから素早く問い合わせる用途は今後厚くなるでしょう。EC事業者の視点では、モールのデータをAPIで取り込み、加工し、判断材料に変えるまでの一連を、席を外していても回せる体制づくりが差になっていきます。
競合のノーコード系やエディタ系が「PCでの開発体験」を磨いてきたのに対し、Cursorのモバイル対応は「開発の着手点を場所から解放する」方向に一歩踏み込みました。日本のEC現場は、店舗運営と開発が同じ担当に集まりやすく、机に張り付ける時間が限られます。だからこそ、移動時間や店頭対応の合間に一次調査と修正着手を差し込めるかどうかが、対応スピードの差になります。ここを取りにいけるかが、2026年後半のEC×AI活用で見るべき分岐点だと考えます。
よくある質問
Cursor 3.9のモバイルアプリは無料で使えますか
いいえ、モバイルアプリはCursorの有料プラン向けの公開ベータとして提供されています。アプリ自体は既存の有料プランに追加費用なく含まれますが、無料プランのみでの利用可否や、クラウド実行にかかる費用は変動するため、cursor.com/pricingで最新条件を確認してください。
Androidでも使えますか
本稿執筆時点(2026年7月)で公式に公開が確認できるネイティブアプリはiOS版の公開ベータで、Android向けネイティブアプリの提供有無は公式発表を確認できていません(要確認)。対応端末は導入前にcursor.comで確認するのが確実です。
楽天RMSやAmazonセラーセントラルの画面操作を自動化できますか
いいえ、Cursorのエージェントはコードとファイルを扱う仕組みで、モール管理画面のボタン操作を直接代替するものではありません。モール連携をAPIやCSV処理としてコード化し、その部分をエージェントに任せる切り分けが現実的な使い方です。
どのAIモデルを選べばよいですか
用途で使い分けるのが結論です。設計判断を伴う改修はGPT-5.6やClaude Opus 5などの上位モデル、機械的なCSV整形やテキスト置換はより軽量なモデル、という振り分けが費用対効果の観点で無難です。Cursorは起動時に任意のフロンティアモデルを選べます。
スマホから本番サイトを壊してしまう心配はありませんか
差分を挟む運用にすれば、リスクは大きく下げられます。エージェントはプルリクエストとして変更を提案するため、本番反映の前に必ずレビューとプレビューを通す運用にしておけば、意図しない変更をマージ前に止められます。レビュー基準を数点に固定しておくと安全です。
導入の最初の一歩は何ですか
まずShopifyテーマや連携スクリプトを1つのGitリポジトリに集約し、モバイルアプリからそのリポジトリを開けるようにすることです。次に、外部モールへの誘導を禁止する条件を入れた定型プロンプトを用意し、軽微な表示修正から試すと、レビュー基準づくりまで一気通貫で回せます。
著者:齋藤竹紘(株式会社オルセル 編集長/5,000社以上のEC支援実績/書籍3冊)
参考文献
- Cursor公式ブログ「Build from anywhere with Cursor for iOS」
- Cursor公式changelog「Cursor Mobile App for iOS」
- TechCrunch「Cursor now has a mobile app for guiding your coding agent on the go」
- Cursor公式ドキュメント「Cloud Agents」
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談(30分)も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
【監修】齋藤竹紘(株式会社オルセル代表 / 19年・5,000社のEC支援実績)

株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。