PC の前にいない時間にも、開発の断片を進められるか試してみました。Cursor のモバイル版を使ってみた使用感をまとめます。
特に刺さったのは マイクボタンからの音声指示 です。手が塞がっているときでも、話しかけるだけでエージェントに任せられます。この記事の下書きも、redamoon.net プロジェクト上でモバイルから進めています。
Cursor モバイル版とは
Cursor モバイル版は、Plan / Ask / Build の AI エージェント UI をスマホ向けに持ち込んだアプリです。
画面上部には戻る・検索・メニュー、中央にはプロジェクト名と Today の履歴、下部には「Plan, ask, build...」入力欄と + ボタン、マイク（音声入力）が常に固定されます。デスクトップ版の IDE そのものではなく、リポジトリに紐づいたエージェントへ指示を出す入口 として位置づけられます。
第一印象としての UI と操作感
ダークモードで目に優しく、プロジェクトを選ぶと Today の履歴が並びます。会話の続きがすぐ見える 構成です。下部の入力欄が常に固定されており、LINE や ChatGPT アプリに近い操作感があります。
プロジェクト単位で会話履歴が残ります。デスクトップ版ほど「IDE 感」はありません。代わりに 指示を投げる装置 として割り切れます。開いてすぐ使える軽さが、モバイル向きだと感じました。
obsidian リポジトリでファイル作成から PR まで
Obsidian はこれまで メモの置き場 として使ってきました。同じ obsidian リポジトリに対して、Cursor モバイルから音声やテキストで指示を出し、結果だけを受け取る、という使い方を試しました。
指示
Create a new file. Create a test file.
AI が実行したこと
new-file.md（新規ファイルのテンプレート）作成test-file.md（チェックリスト付きテストファイル）作成- ブランチ
cursor/create-test-files-2800作成 - commit → push
- GitHub に Draft PR #8 作成
所感
裏ではブランチ作成から PR 起票まで走りましたが、自分は結果通知を見るだけ で済みました。「Edited 1 file, 4 other tools +10」と表示され、ツール実行の概要がざっくり把握できます。View PR / Mark Ready ボタンで PR 操作までモバイル UI に統合されています。Checks Passed が一覧に出るのも 安心感 になります。詳細は後でデスクで確認すれば十分です。
モバイルで特に効いたこと
開発の視点では、特に小さいタスクはモバイルで片付けられる のがよいところです。自然言語 1 行 → ブランチ・commit・PR まで一気通貫、という流れがそのまま効きます。移動中・離席中の「種まき」に向いています。PR を Draft で作り、後からデスクトップで Mark Ready する。この使い方が自然です。
自分で管理できるアプリケーション（このブログ（redamoon.net）や Obsidian リポジトリのように、権限も方針も自分で決められるもの）では、モバイルから指示を出せる 点の価値が大きいです。個人端末なら携帯でさくっと作業できます。ここはかなり大きいところです。
出先でのウォーキング中の朝メモ
以前から、朝のウォーキング中に Obsidian でメモを書く習慣がありました。思いついたことをスマホに残す流れ自体は悪くありません。ただ 「メモを書く」→「あとで整理する」 という二段階が、どうしても残ります。
Cursor モバイルに切り替えてからは、話しかけた内容がそのままリポジトリに反映されます。メモと実行の距離が短いです。Obsidian への転記ステップが消え、直接きれいに残る感覚があります。その分、満足度が上がりました。
イメージとしては、これが 日次の積み上げ（デイリービルディング） になるのではないかと思っています。1 日 1 回、散歩の途中で種をまきます。帰宅後やデスクに着いたときには、すでに形になっています。
一方で、出先で歩きながら使うときの欠点 もあります。指示を投稿したあと、歩き続ける間は シンキングタイム（考えたり別のことに意識が向いたりする時間）が必ず挟まります。エージェントが動いている最中に結果を確認したり、すぐフォローアップを送ったり、という 同期的なやり取りができません。デスクにいるときのような即応性はなく、タイムラグ が生じます。
だからこそ、ウォーキング中は「投げっぱなしで種まき」、帰宅後やデスクで結果を確認する、という 非同期の使い方 が合います。Queued の通知が来ても、その場で深掘りせず、後から Mark Ready する流れと相性がよいです。
家事・家庭の時間
キーボードを開く余裕がない場面でも、話しかけるだけでエージェントが動きます。「子どもが寝たら確認する」程度の粒度で Draft PR を起票し、後からデスクで Mark Ready する、という流れが自然にできます。PC 時間と生活時間の境界が少し曖昧になります。悪い意味ではなく、生活の隙間に開発を差し込める感覚に近いです。
これからのメモのプロセス
Obsidian 単体のメモ書きから、Cursor 経由の 「話す → 残る → 積み上がる」 へ。プロセス自体を変える必要がある、と感じています。
ただ、その場でメモを取る行為自体は変わりません。変わるのは、そのあと AI に整理してもらう 部分です。
Obsidian だけでやっていたときの使い方は、振り返ると ちょっと強かった です。自分で構造を整え、リンクを張り、後から読み返せるように整える。その分、メモ段階で負荷が高くなります。Cursor 経由なら、走り書きを AI に任せられます。
一方で、要約ばかりのきれいなデータ より、実例に近い生の記録 の方が、あとからデータとして残る、という感触もあります。全部を AI が整えすぎると、当時の文脈やニュアンスが消えます。整理は必要ですが、一次記録はラフなまま残す 方がよいかもしれません。
| 流れ | |
|---|---|
| これまで | 散歩 → Obsidian にメモ → 後日デスクで整理・転用 |
| これから（案） | 散歩 → ラフに書き出す → デスクで AI に整理してもらう → 仕上げ |
散歩中に整理まで任せる のではなく、一旦書き出した内容をもとに、最後に整理してもらう。使ってみた中での実感はそんな感じです。ウォーキング中は投げっぱなし、精査と整理はデスクで行います。タイムラグの欠点とも相性がよいです。
Obsidian をやめるわけではなく、入口を Cursor に移し、整理のタイミングを後ろにずらす イメージです。まだ試行錯誤の途中で、もう少し研究が必要 ですが、方向性としてはここに落ち着きつつあります。
運用面から見た「歩きながら自走」の難しさ
実装・運用に落とすと、こういう整理になります。
確かに 歩きながら指示を出してエージェントに自走 させる、というイメージは持てます。反面、難しいところ もはっきりあります。
- 細かい修正：その場でサッと直したい箇所を、歩きながら即反映できるか。モバイル画面で diff を見ながら手直し、というのは現実的ではありません
- 大きい修正：こちらも散歩中は向きません。指示の粒度を間違えると、Queued のあとフォローアップまでタイムラグが長くなります
実際はどうかというと、メモをたくさん投げておき、帰ってから整理してもらう 運用がいちばんよさそうです。ウォーキング中は「書き出し専用」、デスクで「整理・修正・仕上げ」と役割を分けた方が、細かい修正も大きい修正も任せやすくなります。
自走させるより、非同期のバッチ処理 に近い使い方です。これまでの「種まき → デスクで Mark Ready」とも、メモの「ラフに書く → 最後に AI が整理」とも、同じ線上にあります。
障害時に VPN + SSH より AI へ任せる
ただ、視点を変えると 別の強み も見えてきます。
昔は、携帯に VPN を入れて SSH でサーバーにログインし、ターミナル越しに細かい作業をする、そんな モバイルオペレーション もありました。外出先から障害対応するには、それなりの手慣れが必要でした。
Cursor モバイルなら、同じような細かい作業も AI に任せる 形にできます。障害や二次障害 が来たとき（ネットワークが不安定、VPN がつながりにくい、画面が小さくて SSH が辛い、といった状況）では、かなり有効 ではないか、と感じました。
自分が直接ログインして手を動かすより、「ログを確認して」「ロールバック PR を作って」「Draft で起票して」 と指示を投げます。エージェントがクラウド側で動き、結果だけ通知で受け取れるので、オンコール中の 認知負荷を下げられます。
VPN + SSH の時代の延長ではなく、障害対応の入口が変わる 可能性があります。日常の「種まき」とは別に、ここは大きなメリットかもしれません。
クラウドと並行して指示を仰ぐ使い方
並行して動かせる作業は、クラウド側に流しておき、モバイルから指示を仰ぐ 形に寄せていきたいです。デスクでエージェントが走っている間に、別のリポジトリへ音声で種まきをする。そんな 並行運用 が現実的な落としどころかもしれません。
音声で指示できる点は、言語化能力を鍛える 側面もあります。何をどう任せるかを口頭で伝える練習になります。ただ、今のところ自分はそこが弱く、うまく指示できずに詰まる場面もあります。ツールの問題というより、指示の出し方そのもの を磨いていく必要がある、という認識です。
曖昧な言葉を補完してくれる音声 × AI
一方で、音声と AI の組み合わせの良さ もあります。多少曖昧な言い回しや、誤字脱字の混じった指示でも、エージェント側が意図を 補完しつつ修正・整理 してくれます。話し言葉のまま投げても、ファイルや PR として形に整えて返してくれます。この点は Obsidian に走り書きするだけのときとは違います。
言語化が完璧でなくても、話した内容を AI が仕上げてくれます。だからこそ、ウォーキング中の走り書きメモや、家事の合間のざっくりした指示でも、入口のハードルが下がります。ただし整理は その場ではなく最後に 行います。走り書きと仕上げのバランスは、まだ調整中です。
モバイルの限界・気になった点
細かい diff のレビューや、長文の記事執筆・推敲はデスク向きだと感じました。デスクトップ版にない / ある機能の差についても、引き続き使いながら整理していきます。
会社端末でモバイルが許可されないケース
一方で、会社の端末ではモバイル利用自体が許可されていない ケースもあります。業務リポジトリへの Cursor モバイル接続は、セキュリティポリシー上むずかしく、ここがボトルネックになります。個人端末・個人プロジェクトでは恩恵が大きいものの、仕事のコードベースにそのまま広げるのは難しい、という整理です。
音声入力でマイクが二重になる問題
入力欄をタップしてキーボードを出すと、マイクボタンが 2 つ 同時に見えます。
- Cursor 側：入力欄の右端（「Plan, ask, build...」の横）に常設のマイク
- iOS 側：キーボード右下のシステム音声入力ボタン
キーボードを閉じた状態でも、入力欄右の Cursor マイクと画面右下付近の iOS マイクが並びます。
どちらを押せばよいか迷います。同じ「音声で指示したい」という意図なのに、入口が 2 つあり、UI として少し冗長です。後述のとおり、Cursor 側のマイクは日本語が英語に変換されることもあり、実質的には iOS の音声入力の方が使いやすい 場面が多いです。
音声入力で日本語が英語に変換される問題
Cursor 側のマイクで日本語を話すと英語に変換されてしまいます。日本語で話しかけても、入力欄には英語として認識されたテキストが入ることがあります。音声指示が記事のメインテーマである以上、この点は無視できません。
現状は認識結果を確認してから送る、テキストで打ち直す、といった回避が必要になります。再送や言語の修正ができるようになれば、ウォーキング中や家事の合間での使い勝手はさらに上がるはずです。
入力欄のマイクボタンは別途必要か
そもそもモバイルでは、Cursor 入力欄右下の マイクボタン自体が不要 なのではないか、と感じてきました。iOS なら、キーボード上にもともと 音声入力（マイク） があります。普通の iOS の音声入力でテキストを入れてから送信する 方が、認識精度が高い ように感じます。
Cursor 側のマイクは、日本語が正しく入らない以上、余計な変換が一段挟まります。話した日本語 → 英語テキスト → 送信、という経路になります。OS 標準の 音声入力 → 日本語テキスト確定 → 送信 なら、変換レイヤーが少なくて済みます。音声指示の入口としては、アプリ内マイクより iOS キーボードの音声 の方が現実的です。
日本語 → 英語変換の「ありがたさ」と「見返すときの欠点」
一方で、日本語で話した内容が英語に変換されるのは、AI 側には都合がよい 場面もあるかもしれません。エージェントが英語コンテキストで動いているなら、英語テキストの方が意図が伝わりやすい、という ありがたい面 も否定はしません。
ただ、自分が投稿を見返すとき は話が変わります。日本語で指示したつもりが、履歴には英語が並びます。英語で解読し直さないといけないのが欠点です。何を送ったか確認したり、同じ流れでフォローアップしたりするとき、認知コストが上がります。
日本語ユーザーにとっては、入力は日本語のまま残る 方が見返しやすいです。Cursor のマイクで英語化される現状は、エージェント向けには助かるかもしれませんが、自分向けのログとしては読みにくいです。だからこそ iOS キーボードの音声入力で日本語のまま送る、という逃げ道が現実的になります。
画像添付が Cloud Agent に届かない
この記事のスクリーンショットをモバイルから何度添付して「public/assets/post/000113/ に保存して」と指示しても、Cloud Agent 側のワークスペースには画像ファイルが届かなかった。エージェントは画像の内容を理解しているように見えますが、リポジトリに PNG として保存する、という流れは通りません。
チャット添付は会話コンテキスト用で、Git へのバイナリ配置は別経路、という設計なのか、バグなのかは断定できません。いずれにせよ 「添付 → リポジトリ保存」は期待通り動きません。記事用の画像は、デスクの Cursor や GitHub Web から配置する必要がありました。
送信後も入力欄に文字が残る
指示を送ってエージェントが実行中（Queued）になっても、入力欄のテキストが消えずに残る ことがあります。Claude アプリでも同様の挙動を見ました。日本語特有の問題というより、モバイル AI チャットアプリ共通の UX または実装 に近い印象です。
IME の変換中テキストや音声入力の認識結果が残る場合もあり、日本語入力を使うと目立ちやすいです。再送を防ぐために送信前に確認する、実行後に手動でクリアする、といった運用が必要になります。
この記事をモバイルで書くというメタ体験
redamoon.net 上に「Cursol draft article / Setting up environment」と表示されていました。ブログの下書き構成を、Cursor モバイルから AstroPaper リポジトリに直接書き出しています。再帰的な体験です。
長文の執筆より 構成・方針の整理 向き、という感触があります。モバイルは種まきと下書き、仕上げはデスク、という役割分担が、この記事でもそのまま当てはまっています。スクリーンショットの配置だけは、Cloud Agent 経由では届かずデスク側の作業になりました。そこも含めて、メタな体験です。
まとめ
モバイル版 Cursor は 「フル開発環境の代替」ではなく「エージェントに任せる軽い開発」の入口 だと整理できます。小さなタスク・下書き・PR 起票には十分使えます。本格的なレビューや執筆はデスクトップと併用が現実的です。
個人端末 × 自分で管理できるリポジトリ では、携帯でさくっと作業できる点が大きいです。会社端末の制約がある以上、まずは個人プロジェクトで使い込み、クラウド側に流せる作業へ並行で指示を出す。そんな使い方が現実的でしょう。
朝のウォーキングで Obsidian にメモしていた習慣が、Cursor 経由の 日次の積み上げ として形を変えつつあります。Obsidian への転記が消え、話したことが直接きれいに残る。その満足度の高さが、使い続ける理由になっています。音声指示は言語化の練習にもなります。指示の出し方を磨きながら、メモのプロセス自体 を Cursor 中心に組み替えていきます。