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 中心に組み替えていく。