Cursor Proサブスク契約とGrok 4.7 の調査

下記のブログ記事で、Codexのオートメーションの負荷を減らすために、Grok Botにニュース配信のオートメーションを移す検討を行ったことを紹介した。そのGrok Botを使うために、Cursor Proのサクブス契約を行ったが、この契約では、Grok Botの他にGrokが使えるので、その機能について調べてみた。調査の結果、Codexで行っている日常処理（オートメーション以外）の多くを肩代わりできる能力が、Cursor + Grok 4.6（途中で4.7に変わった）にあることが分かった。これにより、オートメーション以外の日常処理でもCodexの負担を減らすことができる。本記事では、Cursor Proのサブスク契約でのAI利用についての調査内容（ChatGPT-5.6 Solとの質疑応答に基づく内容を含む）を紹介する。

---

注）本記事の内容は正確性を保証するものではありません。

（2026年9月23日 追記）YouTube動画を追加しました。　https://youtu.be/PBx–kfLvcs

---

Cursorの操作画面

---

Grok Botのチャット画面

Cursor Pro契約概要

（以降、ChatGPT-5.6 Solの回答）

2026年9月22日現在の公式情報では、Cursor Proは月額20ドルの個人向け有料プランです。単なる「Cursorエディタの有料版」ではなく、現在は CursorのAIエージェント、Cloud Agents、Automations、Grok Bot、My Machines を使うための基盤になる契約、と考えると分かりやすいです。(Cursor)

Cursor Proの主な内容

項目	Cursor Pro
料金	$20/月（税別表示）
Tab補完	無制限
Cursor Agent	利用可能・無料版より上限拡大
Cursor Grok 4.6/4.7等	専用のCursor Models利用枠
GPT・Claude・Gemini等	Other Models利用枠から消費
Grok Bot	利用可能
Cloud Agents	利用可能
Cursor Automations	利用可能
My Machines	個人のMac等をCloud Agentの実行環境として利用可能
MCP・Skills・Hooks	利用可能
Bugbot	利用可能
超過利用	On-DemandをONにした場合のみ追加従量課金

(Cursor)

重要なのは、「月20ドル払えば、すべて無制限」ではないことです。

Cursor Proには大きく分けて、次の利用枠があります。

Cursor Pro
   │
   ├─ Cursor Models
   │    ├─ Cursor Grok 4.7 / 4.6
   │    ├─ Composer
   │    └─ 月間利用枠
   │
   ├─ Other Models
   │    ├─ GPT
   │    ├─ Claude
   │    └─ Geminiなど
   │         ↓
   │      月間利用枠
   │
   └─ Grok Bot
        └─ 別の「週間利用枠」

通常のCursor利用枠は毎月リセットされます。一方、Grok Botについては少し特殊で、Proに付属する独立した週間利用枠があります。Pro+、UltraになるほどGrok Botの週間利用枠も大きくなります。(Cursor)

ここは、以前お話ししていたGrok Botの利用率を見るうえでも重要です。たとえばGrok Bot画面で、

Weekly usage 23%

などと表示されている場合、それは基本的にCursor本体の月次モデル利用枠とは別のGrok Bot週間枠です。(Cursor)

さらに注意したいのがOn-Demandです。Proの含まれる利用量を使い切った後でも、On-Demandを有効にしていると処理は継続され、モデルのAPI価格に応じた追加料金が発生します。個人プランではOn-Demandは自分で有効化する仕組みなので、追加料金を絶対に出したくなければOFFにしておくのが安全です。(Cursor)

Grok Botも同様です。流れは、

Grok Bot週間枠 → 枠を使い切る → On-DemandがONなら追加従量課金

となります。On-DemandがOFFなら、週間枠を使い切ったところでGrok Botは停止し、週間枠のリセットを待つことになります。(Cursor)

また、現在検討されているCursor AutomationsやMy MachinesもPro契約と非常に関係があります。

Cursor Automationsは、決まった時刻やGitHub・Slack・WebhookなどのイベントをトリガーとしてCloud Agentを自動実行できます。ただし、Automationを作ったこと自体に固定の追加料金がかかるというより、起動したCloud Agentが使用したモデル量に応じて利用枠が消費される仕組みです。(Cursor)

My Machinesは少し構造が違います。

Cursorクラウド
   │
   │ AIの推論・計画
   ↓
Cloud Agent
   │
   │ 指示
   ↓
あなたのMac mini
(My Machines Worker)
   │
   ├─ Terminal操作
   ├─ ファイル編集
   ├─ ブラウザ操作
   ├─ Computer Use
   └─ ローカルMCP

つまり、AIそのものはCursor側で動作し、実際のファイル操作やTerminal操作などをMac mini側で実行する方式です。
My Machinesにしたからモデル利用料がゼロになるわけではなく、選択したモデルの利用料金・利用枠は通常どおり消費されます。(Cursor)

今回の用途を考えると、Proはかなり重要な位置づけになります。

月20ドルのCursor Pro
→ Cursor Desktop
→ Cursor Agent
→ Grok Bot
→ Cloud Agents
→ Cursor Automations
→ My Machines
→ Computer Use

という一連の機能を1つのCursorアカウントで使えるためです。

ただし、現在のように複数Bot＋毎日のニュース監視＋Automations＋My Machinesまで本格運用すると、公式も「複数エージェントやAutomationを使うパワーユーザーでは月200ドル以上になる場合がある」と案内しています。日常的にAgentを使うユーザーでは月60～100ドル程度という目安も示されています。(Cursor)

ですので、今の使い方なら私はまず、

Cursor Pro $20/月 + On-Demand OFF

を基本構成にして、Grok Botの週間枠とCursor本体の月間枠を1か月ほど実測する方法が分かりやすいと思います。
そのうえで不足するなら、Pro+（$60/月）を検討する、という順番が安全です。

なお、Pro → Pro+ → Ultraはそれぞれ月額 $20 → $60 → $200 です。(Cursor)

---

利用状況

Cursor Pro契約を行ってから、日次ニュース配信のため、5つのAIエージェント（Bot）設定および配信を行って、現在、Grok Bot週間枠を38％消費している。現在の記事量では6％/日の消費であり、1週間で42％程度の消費となる見込み。このGrok Bot枠の消費を考慮して、記事量の調整、新しいBotの追加数を考えなければいけない。現在の契約でオートメーションを継続的に利用する場合、感覚的には、Bot数は8つぐらいまでにしておいた方がよいように思われる。

Cursor Models月間枠の使用率が16％、Other Models月間枠の使用率が13％となっている。Grok 4.6に、細々とした日常処理（主にメンテナンス処理）を指示したが、思ったほど枠を消費していないという印象で、処理量が大きい処理でなければ、あまり枠を意識しないで利用できそうである。これまで、Codexに指示していた日常処理をGrok 4.7に頼めそうなので、オートメーション処理に限らず、Codexの負担を軽減することができる。現在、Codexには利用枠を考慮して作業を分割して実行してもらうことが多いが、Grok 4.7の場合は、あまり、考慮しなくてもよいように思われる。ただし、Cursor Modelsの利用枠は月間利用枠である点に注意が必要で、週間枠のつもりで使用していると足りなくなる恐れもある。

AIモデルGrok 4.6の概要

はい。Cursorで使う Grok 4.6 を中心に整理すると、これは単なる「コード生成モデル」ではなく、長時間のAgent作業やローカル／クラウドのツール操作まで想定した、Cursorの主力クラスのモデルです。

ただし、2026年9月22日現在は Grok 4.7が後継として登場しており、Cursor自身も4.7を推奨しています。Grok 4.6は引き続き利用できます。(Cursor)

項目	Grok 4.6
主用途	コーディング＋一般的な知識作業
特徴	長時間・多段階のAgent処理
Cursorでの扱い	Cursor Models枠
コンテキスト	Cursorでは256k（500kに変更可能）
Reasoning effort	Low / Medium / High / XHigh
標準	High
ローカルファイル検索・読取	○
ローカルファイル編集	○
Terminal	○
Web検索	○
Browser操作	○
画像入力	○
MCP	Cursor Agent経由で利用可能
Cloud Agent	○
Automations	○
CLI / SDK	○
iOS	○
API価格の基準	入力 $2/M、Cache $0.50/M、出力 $6/M

Cursor公式は、Grok 4.6を「複雑な長時間タスク」に特に強いモデルとして位置付けています。単にコードを1つ書くよりも、ファイルを調べる→修正する→Terminalでテストする→失敗を分析する→再修正するといった一連の作業に向いています。(Cursor)

Cursorで使う場合に重要な点

Grok 4.6自身がMacを直接操作するわけではありません。Cursor Agentが、

Grok 4.6＝頭脳
＋
Cursor Agent＝ファイル・Terminal・Browser・MCPなどの手足

という構成を作ります。

そのため、たとえば、

外部SSD上のObsidianファイルを調べる
→ Pythonスクリプトを修正
→ Terminalで実行
→ 結果を確認
→ Markdownに記録

という作業も、Cursor側からローカル環境へのアクセスが許されていればGrok 4.6で扱えます。Cursor公式もGrok 4.6に、ファイル検索・読取・編集、Shell、Web、Browserなど全Agent Toolsへのアクセスがあるとしています。(Cursor)

Pro契約との関係

ここは今回の一連の話ではかなり重要です。

Grok 4.6はClaudeやGPTとは違って、Proの 「Cursor Models」枠を使用します。

現在のCursor Models枠には、

• Grok 4.7
• Grok 4.6
• Grok 4.5
• Composer 2.5

などが含まれています。ClaudeやGPTなどの「Other Models枠」とは別です。(Cursor)

したがって、

日常処理をGrokで行う
→ Cursor Models枠を使う
→ Claude / GPT用のOther Models枠を温存する

という使い方ができます。

Effortの違い

Grok 4.6には4段階あります。

Effort	用途のイメージ
Low	単純な質問、軽い編集
Medium	通常のファイル処理、スクリプト修正
High	複雑な原因調査、複数ファイル、Agent作業
XHigh	難しい長時間処理、複雑な設計・調査

Cursorで明示的にGrok 4.6を選択した場合の標準はHighです。高いEffortほど難しい問題に時間をかけます。(Cursor)

普段のローカル作業なら、私はMedium〜Highを中心に使うのがよいと思います。単純なファイル整理に毎回XHighを使う必要はありません。

Grok 4.6の料金感

CursorのOn-Demand換算では、

Standard

• Input：$2 / 100万tokens
• Cached input：$0.50 / 100万tokens
• Output：$6 / 100万tokens

Fast

• Input：$4
• Cached：$1
• Output：$12

です。(Cursor)

ただしPro契約では通常、まずこの料金を直接払うのではなく、Cursor Modelsの契約内利用枠を消費すると考えればよいです。

Grok 4.6の得意な使い方

今回お話ししている用途なら、特に次のような作業との相性がよいです。

• Obsidianの大量Markdown整理
• Home Assistant設定・ログ調査
• MCPを使った情報取得
• Python / Shellスクリプトの作成・修正
• WordPressバックアップ用プログラムの開発
• 外部SSD上のファイル処理
• 複数ファイルをまたぐコード修正
• テスト→失敗→修正を繰り返す作業
• Cursor Cloud Agent / Automations

つまり、これまでCodexに集中させていた日常的なローカル作業のかなりの部分を分散できるモデルです。

ただし、今から使い始めるなら4.7も重要です

昨日公開されたGrok 4.7は、4.6よりも長時間タスクでの自己検証を強化し、CursorBench 4.0では4.6の40.4%から4.7は46.3%、Terminal-Bench 4.0では20.3%から38.0%へ改善したとCursorが発表しています。料金は基本的に4.6と同じです。(Cursor – Community Forum)

そのため、今から「Cursor Grokを主力モデルにする」なら、実際には4.6よりGrok 4.7を標準候補にした方がよいです。

今回の用途に当てはめると、

Grok 4.7
→ 普段のローカルファイル・MCP・Terminal・Agent作業

GPT-5.6 Sol / Claude Opus 5
→ Grokで解決しない難問や別モデルによるレビュー

Codex
→ 既に安定しているAutomationや、Codex固有機能を使う処理

という構成が、現時点ではかなり使いやすいと思います。

Cursor pro契約では、3つの利用枠があるが、前の記事でも紹介したように、Grok 4.6などがCursor Modelsの枠を使い切ったら、Other Models枠を使うことになっているらしいので、ChatGPTなどのサブスクを契約していて、そちらの枠をChatGPT-5.6 Solなどで使っている場合、このOther Models枠を、Grok 4.6などの予備枠として考えることができる。枠の残量は次月に持ち越すことはできないので、各月で、どのAIでどの枠を有効に利用できるかを考え、最適化を図る必要がある。

---

Grok 4.6 使用例

これまで、Codexで行っていた処理をGrok 4.6に依頼した例を紹介する。

HOME Assistantダッシュボード仕様変更

下図はHOME AssistantのダッシュボードにCodexとClaude Codeの処理や、5時間枠や7日枠の利用率・リセット日時を表示させたものであり、今回はそのダッシュボードに「Cursor」の処理と利用枠を追加してもらった。下図は処理後の画面である。

上図で、「Grok Bot」の枠は週次であるのに対し、「Cursor Models」や「Other Models」の枠は月次であることに注意が必要である。Codexの7日枠の利用率は86％であるが、Codexの手動での使用は80％で止めたが、オートメーションの処理によって86％まで上昇している。たぶん、リセットまでに7日枠を使い切り、オートメーションが止まることになる。

Cursorはアプリを使えばローカルセッションも可能でなので、このダッシュボードではローカルセッションなのか、クラウドセッションなのかが分かるように経路を表示させている。

この仕様変更処理は、Cursorのクラウドセッションで依頼したところ、ローカルセッションでローカルエージェントに依頼する必要があると回答され、ローカルエージェントへの依頼文が作成された。ローカルセッションを立ち上げ、Hookの設定や、MCPの設定など、それなりに修正処理が発生したが、スムーズに変更処理が行われた。他のAIに比べ、Grokはユーザーを混乱させるような長い回答をすることもなく、あまり、ユーザーに負担をかけないように配慮されているように感じる。

Stream Deckの状態調査・MCP設定

（以下、Grok 4.6の回答）

Stream Deck は稼働中です。 USB 実機は Stream Deck + と Stream Deck MK.2 の 2 台が接続済みで、Elgato アプリ 7.5.1 が約 27 時間動き続けています。

詳細はチャット横で開ける Stream Deck 状態 にまとめました。キャンバスはこの調査結果を後から見返せる一覧です。

稼働状態

• アプリ: /Applications/Elgato Stream Deck.app 7.5.1 (22901)、2026-09-20 06:32 起動
• USB: Stream Deck Plus（シリアル EL31L1A04916）、Stream Deck（AL03I1C01735）
• 仮想機: MCP Deck（8×4 の AI Stream Deck エミュレータ、待受 *:28198）
• プラグイン待受: 127.0.0.1:28196
• ネイティブプラグイン: インストール 56 のうち 25 プロセスが稼働。HTML / 暗号化プラグインは QtWebEngine 側

直近のクラッシュ記録は見つかりませんでした。バックアップは 2026-09-20 06:22 が最新です。

構成の要点

Stream Deck +（4×2 + 4 ダイヤル、輝度 30%）
優先プロファイルは Chrome 連動の「プロファイル 1」。Chrome 起動中なので、いま出ている可能性が高い current page は次のとおりです。

• ダイヤル: 天気予報 / 大気質 / TV音量（Home Assistant） / Mac音量
• キー: 外気温・居間・寝室・DJIプラグ / WBGT・Finder・CPU・RAM

Stream Deck MK.2（5×3、輝度 23%、アプリの優先デバイス）
優先はデフォルトの「ホーム」。画面キャプチャー、Downloads、Desktop、ChatGPT、Obsidian、Claude、サイト分析への切替などが載っています。

プロファイルは全体で 30（Plus 19、MK.2 10、MCP Deck 1）。DaVinci / OBS / Fusion / CLIP STUDIO / KiCad / Blender 向けのアプリ連動も揃っています。

このセッションでできなかったこと

Cursor 側には streamdeck-mcp がつながっていません。構成はディスク上の ProfilesV3 とプロセスから読みました。
プラグイン本体（streamdeck-mcp 0.2.0）は Stream Deck 側に入っています。

Elgato 公式 MCP（@elgato/mcp-server）は ChatGPT / Codex 側 で 4 プロセス動いており、この Cursor 会話のものではありません。

実機の今の画面がディスク上の current page と一致するかは、本体を一目見て確認してください。

Cursor から streamdeck-mcp を使える状態になりました。 グローバル設定に入れ、この会話からプロファイル一覧の取得まで確認済みです。

設定ファイルは ~/.cursor/mcp.json です。Claude と同じ起動方法（uvx –with mcp<2 streamdeck-mcp）を使い、Dock から起動した Cursor でも動くよう uvx はフルパスにしています。

接続確認の結果:

サーバー名: streamdeck-profile-mcp 1.30.0
Cursor ログ: Successfully connected to stdio server
streamdeck_read_profiles が ProfilesV3 を返し、Stream Deck + のプロファイルが見えています
使えるツールは streamdeck_read_profiles / streamdeck_read_page / streamdeck_write_page / streamdeck_create_icon / streamdeck_create_action / streamdeck_restart_app / streamdeck_install_mcp_plugin です。全プロジェクトで共通です。

この会話のまま「このページを直して」などと依頼して大丈夫です。別チャットでツールが出ない場合は、Cursor のウィンドウを再読み込みしてください。

事前の起動テストは、サーバー本体（streamdeck-profile-mcp 1.30.0）の応答確認までは成功していました。ツール一覧の読み取りでプロセスが止まったため途中で切っていますが、その後 Cursor 側の接続と streamdeck_read_profiles は通っているので、設定自体に影響はありません。

Cursor 側に streamdeck-mcp がつながっていなかったため、ディスク上の ProfilesV3 とプロセスから構成を読んで回答が行われた。別手段を探し出して目的を果たすという動作が、他の処理でもみられ、その点でGrok 4.6（途中からGrok 4.7）は、余計なことは言わず、目的をさらりと達成する能力が高いと感じた。この例でも、MCPについて質疑応答を繰り返さず、いきなり、「使える状態になりました」と回答されており、ユーザーの負担を軽減している。

Obsidian保管庫へのノート保存

フォルダ名 Cursor_Tips で保存しました。

保存先:

保管庫: ssd_vault（/Volumes/TEKQPHYE748/obsidian/ssd_vault）
フォルダ: 30_Resources/Cursor_Tips
ノート: ローカルセッションを作業フォルダとGitHubリポに紐づける.md
テンプレート: General Note（title / created / tags / 要約 などを記入）
Obsidian で 30_Resources/Cursor_Tips を開けば、本文はそのまま確認できます。関連として、既存の [[ローカルCursorエージェントでssd_vaultを開いて作業する手順]] へのリンクも末尾に入れています。

難しい処理ではないが、ユーザーに問い合わせることもなく、自分で調べて処理している点がスマート。
また、関連リンクを提案するなど、保存場所の別のノートを調査して、様式などを合わせる配慮が他の処理でもみられた。

Cursor Automations概要

（以降、ChatGPT-5.6 Solの回答）

はい。Cursor Automations は、「条件が成立したらCursorのCloud Agentを自動起動する仕組み」です。
2026年9月現在、単なる時刻指定だけでなく、GitHub・GitLab・Slack・Linear・Webhook・Sentry・PagerDutyなどを起点にできます。(Cursor)

今回まで話してきた機能の関係を先に整理すると、

Cursor Automations = 自動起動の仕組み
Cloud Agent = 実際に仕事をするエージェント
Grok 4.7 / GPT-5.6 Sol / Claude Opus 5など = Agentの頭脳
MCP / Browser / Computer Use / GitHub等 = Agentが使う道具

という関係です。

Cursor Automationsで何ができるか

項目	内容
実行場所	基本はCursorのクラウド
時刻指定	○
cron	○
GitHub/GitLab/Bitbucketイベント	○
Slackメッセージ	○
Slack絵文字リアクション	○
Linear	○
Webhook	○
Sentry	○
PagerDuty	○
モデル指定	○
Grok 4.7	○
GPT / Claude	○
MCP	○
Browser / Computer Use	○
Git操作	○
PR作成	○
Slack通知	○
実行間のMemory	○
MacがOFFでも実行	○ クラウド処理なら
MacのローカルSSD直接操作	通常は×

Cursor公式では、Automation作成時に「Trigger → Prompt → Tools → Repository」を設定します。(Cursor)

1. 起動条件がかなり豊富です

例えば定期実行なら、

毎日 午前7時
毎週月曜日
1時間ごと
cron式

などを指定できます。

ただしScheduled triggerについてCursorは、指定時刻より前には開始しないが、多少遅れて開始する場合があると明記しています。したがって「7:00:00ちょうどに必ず実行」というリアルタイム用途には向きません。(Cursor)

時刻以外にも、

GitHubでPRが作られた
↓
Automation起動
↓
Grok 4.7がレビュー
↓
問題ならPRへコメント

あるいは、

Slackに特定のメッセージ
↓
Automation起動
↓
内容を調査
↓
Slackへ結果返却

という処理ができます。

Webhookも利用できるため、自作プログラムからHTTP POSTしてAgentを起動することもできます。(Cursor)

2. Grok 4.7を明示的に指定できます

ここはGrok Botとの大きな違いです。

Cursor Automationsでは、Automationごとに使うモデルを選択できます。(Cursor)

たとえば、

毎朝の軽い処理 → Composer
複雑な調査 → Grok 4.7
別モデルでレビュー → GPT-5.6 Sol

という使い分けが可能です。

Grok 4.7はAutomationsに正式対応しており、ProならCursor Models枠を消費します。(Cursor)

これは今回の話では重要で、Grok Bot Weekly枠とは別です。

3. MCPも使えます

AutomationごとにMCPサーバーを接続できます。

つまり、

Scheduled Automation
↓
Grok 4.7
↓
MCP
↓
外部システム

という処理が可能です。

Cursorは、AutomationにMCPを接続すると、そのMCPが公開しているすべてのツールをAgentが利用可能になるため、信頼できるMCPだけ接続するよう注意しています。(Cursor)

したがって、Home Assistant MCPのようなものをクラウドから到達可能な形にできれば、

定刻にHome Assistant情報取得
→ 異常確認
→ レポート作成

といった使い方も考えられます。

ただし、Mac mini内だけで動いているstdio型ローカルMCPを、通常のCloud Automationがそのまま利用できるわけではありません。ここはMy Machinesとは区別する必要があります。

4. Memoryがあるのも特徴です

Cursor Automationsには実行間で持続するMemoryがあります。

例えば毎日、

昨日確認済みの記事
前回見つけた問題
前回の処理結果

などをAutomation自身が保存して、次回参照できます。

MemoryはAutomationの作業ファイルとは別に保持され、デフォルトでは有効です。ユーザーが内容を確認・編集・削除することもできます。(Cursor)

このため、

毎日同じ対象を全部調査する

のではなく、

前回との差分だけ調べる

というAgentを作りやすくなっています。

これはGrok Botで構築されているニュースWatcherのような用途にも近い考え方です。

5. Computer Useも正式対応しています

2026年6月の強化で、Automationから起動されたCloud AgentがComputer Useを利用できるようになっています。(Cursor)

公式ドキュメントでも、AutomationにはComputer Useが標準で含まれており、

• ブラウザ操作
• スクリーンショット
• 録画
• Webアプリ操作
• 内部サービス操作

などが可能とされています。(Cursor)

つまり単なる、

「Pythonを実行する自動化」

ではなく、

「Webページを開く → 状況を判断 → ボタンを操作 → 結果を確認」

のようなAutomationも作れます。

---

6. Repositoryは3種類あります

Automationには、

Repositoryなし
→ Slack、MCP、Webhookなどだけを扱う

Single Repository
→ 1つのGitリポジトリを操作

Multi-repo Environment
→ 複数リポジトリを横断

の3構成があります。(Cursor)

例えば、

GitHubにあるWordPressバックアップ用Pythonプログラム
↓
毎週テスト
↓
問題があれば修正
↓
PR作成

ならSingle Repositoryです。

複数の関連ツールをまとめてチェックするならMulti-repoにできます。

7. 一番重要な制限は「MacのローカルAutomationではない」ことです

ここはCodex Automationと混同しない方がよいです。

通常のCursor Automationは、

時刻になる
↓
CursorクラウドでCloud Agent起動
↓
クラウド上のsandboxで作業

です。

したがって、Mac miniにある、

/Volumes/.../obsidian/ssd_vault

のような外付SSD上のファイルを通常のAutomationが直接読みに行くわけではありません。

これは後述するMy Machinesとは違います。

そのため、あなたの用途では、

クラウドだけで完結
→ Cursor Automations

Mac mini・外付SSDが中心
→ Codex Automationまたはローカルスクリプト

と考えると分かりやすいです。

現在の用途に当てはめると

例えば次のように分けられます。

処理	Cursor Automationsとの相性
GitHub PRレビュー	◎
CI失敗の原因分析	◎
GitHub Issue対応	◎
Web上のニュース定期調査	◎
Webサービス監視	◎
MCP経由のクラウドサービス監視	◎
Slack→調査→回答	◎
WordPress REST APIから記事確認	○～◎
WordPressの記事バックアップ作成	○ クラウド保存先なら
外付SSDへの記事保存	△～×
Obsidian SSD Vaultの直接編集	× 通常構成では
Home Assistantのローカル設定ファイル編集	× 通常構成では
Mac上のPythonを直接定刻実行	× 通常構成では

ですから、WordPress記事バックアップで考えると、

Cursor Automation
→ WordPress REST API
→ 未保存記事検出
→ ZIP作成

まではクラウドでもできます。

しかし最後の、

→ Mac miniの外部SSDに保存

が問題になります。

そのためこの用途については、先ほど提案した「ローカルPythonスクリプト＋Codex Automation」の方が、現状は素直です。

Grok Bot Routineとの違い

この2つは似ていますが目的が少し違います。

Cursor Automations
→ 「条件が成立したらCloud Agentを1回起動して仕事をさせる」

Grok Bot Routines
→ 「常駐Botに定期的な仕事をさせる」

です。

開発・GitHub・PR・MCP・Webhook中心ならCursor Automations、ニュース監視など継続的な情報収集役ならGrok Bot Routineが分かりやすい棲み分けです。

またCursor AutomationsではモデルをGrok 4.7と明示指定できますから、ProのCursor Models枠を活用したクラウドAutomationを作りたい場合には、かなり重要な機能です。

---

My Machines 概要

（以降、ChatGPT-5.6 Solの回答）

はい。My Machines は、CursorのCloud Agentに「自分のMacやVMを実行環境として貸す」機能です。2026年9月に強化されたSelf-Hosted Machinesの個人向け構成で、Mac、開発用PC、リモートVMなどを自分のCursorアカウントに接続できます。(Cursor)

仕組みは次のようになります。

Cursorクラウド
AIモデルが推論・計画
↓
My Machines worker
自分のMac miniなど
↓
Terminal、ファイル編集、Browser、MCP、Computer Useを実行

重要なのは、AIそのものがMac上で動くわけではない点です。
Agent loop、つまり「次に何をするか考える部分」はCursorクラウドに残ります。
実際のコマンド実行、ファイル編集、ブラウザ操作などを自分のMacで行います。(Cursor)

項目	My Machines
AIの推論	Cursorクラウド
Terminal実行	自分のMac
ファイル読取・編集	自分のMac
Git	自分のMacの環境を利用
ローカルMCP	利用可能
ローカルネットワーク	利用可能
Browser操作	○
Computer Use	○ macOS対応
外部SSD	macOS権限があればアクセス可能
SSH鍵・認証情報	Mac側の既存環境を利用可能
Macの電源	必要
workerプロセス	起動している必要あり
外部からMacへのポート開放	不要

特にネットワーク構成は安全面で分かりやすく、Mac側のworkerがCursorへ外向きHTTPS接続を張ります。
Cursor側から自宅Macへ直接着信接続する仕組みではないため、ルーターのポート開放やVPNは基本的に不要です。(Cursor)

実際にはどう設定するのか

基本はCursor CLIを入れ、ログインしてworkerを起動します。

agent login

その後、

agent worker start --name "my-mac"

とすると、そのMacがMy Machinesとして登録されます。

ブラウザの cursor.com/agents を開くと、実行環境の選択肢にそのMacが表示され、そこを選んでCloud Agentへ仕事を依頼できます。workerは停止するまで接続を維持し、別のCloud Agentセッションでも再利用できます。(Cursor)

複数の作業フォルダも登録できます

たとえばMac miniに、

~/projects/blog-tools
~/projects/home-assistant
~/projects/streamdeck

などがあれば、複数の--worker-dirを指定できます。

agent worker \
  --worker-dir "$HOME/projects/blog-tools" \
  --worker-dir "$HOME/projects/home-assistant" \
  start

Git remoteの情報も利用して、Cursorがどのリポジトリの処理をどのworkerへ送るか判断します。(Cursor)

MCPとの相性がかなり良いです

My MachinesではMCPも利用できます。

特に stdio型MCP はMac上で起動されます。そのため、

Cursor Cloud Agent
↓
My MachinesのMac mini
↓
ローカルMCP
↓
Home AssistantやLAN内サービス

という接続が可能です。

Cursor公式も、stdio MCPはworker側で実行され、プライベートネットワークやローカルサービスへアクセスできると説明しています。HTTP/SSE型MCPについてはCursorバックエンド側が接続します。(Cursor)

これはHome Assistant用途にはかなり重要です。

Computer Useも利用できます

現在はmacOSのMy MachinesでComputer Useにも対応しています。

起動時に、

agent worker --computer-use --name "my-mac" start

とします。

初回にはCursor Computer Use helperがインストールされ、macOSの

システム設定 → プライバシーとセキュリティ

で、

• アクセシビリティ
• 画面収録

を許可します。するとAgentがMac上でクリック、入力、スクリーンショット取得、アプリ操作、Browser操作を行えます。(Cursor)

これは「--computer-use付きworker」がまさにこの仕組みです。

あなたのMac miniなら、かなり用途があります

現在の環境なら、例えば次の構成ができます。

Cursor Grok 4.7 / GPT-5.6 Sol / Claude Opus 5
↓ Cursor Cloud Agent
My Machines：Mac mini
↓
外付SSD
↓
Obsidian Vault
↓
Home Assistant関連ファイル
↓
Terminal / Python / MCP

つまり、これまでCodexに依頼していた

• ObsidianのMarkdown更新
• Home Assistantログ確認
• Pythonスクリプト修正
• 外部SSD上のファイル調査
• ローカルMCP利用
• Git操作

などのかなりの部分を、Cursor Models枠のGrok 4.7などを使ってMy Machines上で実行することができます。

ただしAutomationとの関係には注意が必要です

ここは非常に重要です。

現時点の公式ドキュメントでは、My Machinesを明示的に指定できる外部トリガーとして、

• Slack
• GitHub
• Linear

が案内されています。例えばSlackなら、

@Cursor worker=my-mac ...

のように指定できます。(Cursor)

一方、「毎日午前2時のCursor Automationを必ずmy-macで実行する」という個人向けScheduled Automation → My Machinesの直接ルーティングは、現在の公式My Machinesドキュメントでは明示されていません。

したがって現時点では、

My Machines = 手動または外部イベントから、自分のMacをCloud Agentの実行環境として使う

と考えるのが安全です。

（以降、ChatGPT-5.6 Solの回答）

はい。ここは 「Cursor Automations」と「My Machines」はつながっているように見えるのに、現状は“時刻指定”では直接つながらない、という点が分かりにくいところです。

Cursor公式ドキュメントを改めて確認すると、かなり明確です。My Machinesを名指しして実行先にできるトリガーは、現時点では Slack・GitHub・Linear の3種類だけです。Cursor自身が「These are the only trigger options that target My Machines」と明記しています。

つまり、「My Machines」は、時刻指定をトリガーにできないと言いたいらしい。

Codexとの最大の違い

かなり単純化すると、

Codex
→ Mac上の作業を直接行うAgentとして使いやすい

Cursor My Machines
→ Cursor Cloud Agentの「手足」を自分のMacに置く

という違いです。

My Machinesの利点は、Cloud Agentの強みとローカルMacの環境を組み合わせられることです。クラウド側でGrok 4.7などを使いつつ、Macにしかない外部SSD、SSH鍵、Home Assistant、ローカルMCP、開発環境などをそのまま利用できます。

今回の利用環境なら、まず Mac miniをmy-macとしてMy Machinesに登録し、Computer Useは後から追加する方法が分かりやすいと思います。最初から--computer-useを付けなくても、Terminal・ファイル・MCP用途は利用できます。Computer Useが必要な作業だけ、後から対応workerとして起動すればよいです。

Cursor My Machinesの機能を使えば、ローカルのMac miniのファイルなどを扱うことができるが、Mac miniをMy Machinesに「対応worker」として登録したり、実行環境として選択したりする必要があるらしく、Codexに比べて手間かかる点がデメリットである。特に、CodexではComputer Useが得意なAstraを使用することができるので、この点でCodexが有利である。ただし、一概に「Computer Use」といっても、各社、名称が異なったり、できることに違いがあるらしいので、どの処理が必要かを具体的に確認しておかないと、思っていたのと違うという結果になりかねない。また、Cursor My Machinesの仕様についても、必要になって時点で最新の仕様を確認することが必要。

---

Cursorのリモート運用・iOSでの使用要領

（以降、ChatGPT-5.6 Solの回答）

はい。Cursorのリモート運用は、2026年9月現在かなり実用的になっています。特に Cursor for iOS + Cloud Agents + My Machines + Remote Control を区別すると分かりやすくなります。

結論からいうと、iPhoneからCursorを使って、①クラウドだけで仕事をさせる、②Mac mini上で新しいAgent作業を開始する、③Macで既に始めたAgent作業の続きを遠隔操作する、の3通りができます。 (Cursor)

方式	iPhoneから開始	Mac必要	Macのローカルファイル	Mac上のTerminal	Macを閉じても継続
Cloud Agent	◎	不要	×	×	◎
My Machines	◎	必要	◎	◎	×
Remote Control	続きを操作	必要	◎	◎	×

ここが一番重要です。

1. iPhoneだけからCloud Agentを起動する

Cursorには現在、正式な Cursor for iOS アプリがあります。iOS 26以降のiPhone、iPadOS 26以降のiPadに対応しています。Proでも利用できます。 (Cursor)

iPhoneで、

Cursorアプリを開く
→ リポジトリを選択
→ モデルを選択
→ 「この不具合を調べて修正してください」

と指示できます。

すると、

iPhone
↓
Cursor Cloud Agent
↓
Cursorクラウド上のVM
↓
GitHub等のリポジトリ
↓
テスト・修正・PR作成

となります。

この場合はMac miniは必要ありません。iPhoneをロックしてもCloud Agentはそのまま作業を続けます。 (Cursor)

例えば外出先から、

「昨日失敗したCIの原因を調べて」
「このIssueを修正してPRを作って」
「Grok 4.7を使ってこのコードを調査して」

と指示できます。

2. iPhoneからMy MachinesのMac miniを直接使う

今回の話では、これがかなり重要です。

現在のCursor for iOSでは、Agentを開始するときに実行環境として、

• Cursor Cloud machine
• Team Pool
• My Machines

を選択できます。公式iOSドキュメントにも明記されています。 (Cursor)

つまりMac miniを、

agent worker start --name "my-mac"

などでMy Machinesとして登録しておけば、外出先のiPhoneから、

Run on → my-mac

を選び、新しいAgentを起動できます。

構造としては、

iPhone
↓
Cursorクラウド上のAgent
↓
My Machines：自宅Mac mini
↓
Terminal
↓
ローカルファイル
↓
外付SSD / Obsidian / 開発環境

となります。My MachinesではAIの推論はCursorクラウドで行いますが、ファイル編集、Terminalコマンド、Browserなどのツール実行はMac側で行われます。 (Cursor)

これは、かなり強力です。

例えば外出先から

iPhoneで、

「my-macを使って、外付SSDのObsidian VaultにあるHome Assistantの更新記録を確認してください」

と依頼する。

あるいは、

「my-mac上のブログバックアップスクリプトをdry-runしてください。ファイル変更はしないでください」

と依頼する。

こうした運用が可能になります。

ただし、Mac mini側は、

• 電源ON
• ネット接続
• worker起動中
• 必要なファイルアクセス権限あり

でなければなりません。 (Cursor)

これは「リモートデスクトップ」ではありません

ここは注意してください。

iPhoneからMacのFinderやTerminal画面をそのまま表示して操作する、Screen SharingやAnyDeskのようなものではありません。

AI AgentにMacを操作させ、そのAgentへiPhoneから指示する仕組みです。

したがって、

「Terminalでこのコマンドを実行して結果を確認して」

はできますが、

「MacのデスクトップをそのままiPhoneに映して、自分の指で操作する」

という機能ではありません。

3. Macで始めた作業をiPhoneへ引き継ぐ「Remote Control」

My Machinesとは別に、Remote Controlという機能があります。

これは、

Mac miniのCursorでAgent作業を開始
↓
外出することになった
↓
iPhoneからそのAgentへ続きを指示

という用途です。 (Cursor)

Mac側のCursorは 3.9.8以降が必要です。

MacのCursorで、

Settings → Agents → Remote Control

を有効にします。

そして作業中のAgentで、

/remote-control

を実行します。

するとそのセッションがiPhoneのCursorアプリにも表示されます。

以後は、

iPhoneから追加指示
↓
CursorクラウドのAgent loop
↓
元のMac上でツール実行

となります。 (Cursor)

例えば自宅で、

「Home Assistantのログを調査して」

とCursor Agentに依頼。

調査途中で外出。

Mac上で/remote-controlしておけば、電車の中からiPhoneで、

「Ollamaの問題だけもう少し詳しく調べてください。設定変更はまだしないでください」

と続きを指示できます。

Mac上の同じファイル、同じTerminal、同じ開発環境を使い続けます。

My MachinesとRemote Controlは何が違うのか

ここが最も混同しやすいです。

	My Machines	Remote Control
主目的	MacをAgentの実行環境として登録	既にMacで始めたAgentを遠隔継続
iPhoneから新規タスク開始	○	基本は既存セッションの引継ぎ
Macで先に作業開始	不要	必要
agent worker	必要	不要
/remote-control	不要	必要
Macのファイル	○	○
Terminal	○	○
長期的にMacを登録	○	セッション単位
用途	自宅MacをリモートAgent化	「続きをiPhoneで」

あなたのMac miniのような常設Macには、My Machinesの方が面白いと思います。
Mac miniを常時my-macとして待機させておけば、外から必要になったときにiPhoneで新しいAgentを起動できるからです。

Remote Controlは、

「Macで今やっているこの作業を、これからiPhoneへ持ち出したい」

という用途です。

iPhone版Cursorでできないこと

iOSアプリはCursor Desktopの縮小版エディタではありません。

公式にも、iOSアプリには、

コードエディタなし
Terminalなし
ファイルブラウザなし

と明記されています。 (Cursor)

つまりiPhoneで自分自身が、

Terminalを開く
→ cdする
→ nanoで編集する

という使い方はできません。

代わりに、

「このファイルを調べて」
「このコマンドを実行して」
「この修正をしてください」

とAgentに仕事を依頼するUIになっています。

これはむしろ、あなたの現在のAI Agent中心の使い方とは相性がよいと思います。

iPhone版でできることはかなり多いです

Cursor for iOSでは、

• 新しいAgentを起動
• モデルを選択
• 音声で指示
• Agentの作業状況を見る
• Agentへ追加指示
• ファイルdiff確認
• スクリーンショット・ログ・動画など成果物確認
• PRレビュー
• PRをmerge
• Agent完了通知
• 入力待ち通知
• Live Activitiesで進捗表示

などができます。 (Cursor)

特に音声入力は外出時には便利です。

例えばiPhoneに、

「my-macを使ってHome Assistantの今日のログを確認して。読み取りだけにして、問題があれば要約して」

と話して開始できます。

あなたの環境なら、こう使えます

例えば自宅にMac miniを置き、

Mac mini
 ├─ Cursor My Machines worker
 ├─ 外付SSD
 │   └─ Obsidian Vault
 ├─ Home Assistant関連環境
 ├─ Python
 ├─ Git
 └─ MCP

としておきます。

外出先からiPhoneで、

Cursor
→ New Agent
→ Run on: my-mac
→ Model: Grok 4.7
→ 「外付SSDの○○を確認して」

とすれば、

iPhone
↓ Internet
Cursor Cloud Agent / Grok 4.7
↓
自宅Mac mini
↓
外付SSD

というAIを介した遠隔Mac操作環境になります。

Computer Useも組み合わせられます

My Machinesのworkerを、

agent worker --computer-use --name "my-mac" start

としてComputer Use対応で起動し、Mac側でアクセシビリティ／画面収録など必要な権限を与えておけば、AgentにMacのGUI操作までさせられます。

ですから将来的には、

iPhone
→ Grok 4.7
→ My Machines
→ Mac mini
→ TerminalだけでなくGUI操作

という構成まで可能です。

私なら最初はこの3段階で試します

1. iPhone → Cloud Agent
   Macを使わずGitHubリポジトリで簡単な調査。
2. iPhone → My Machines → my-mac
   Mac mini上の読み取り専用ファイル確認。
3. 問題なければ My Machines + Computer Use
   GUI操作まで拡張。

特に第2段階が、これまでCodexに集中していたローカル作業をCursor Models枠のGrokへ分散できるかどうかを判断する良いテストになります。

なお、iPhoneからMy Machinesを利用できること自体は、現在の公式iOSドキュメントで明確にサポートされています。
一方、先ほど話していた「毎日2時のScheduled Automationから自動的にmy-macを選ぶ」という話は別問題です。
iPhoneから手動でmy-macを選んで開始することはできるが、Scheduled Automationが自動的にmy-macを選ぶ機能は現状明示されていない、という区別になります。 (Cursor)

「Mac miniを、my-macという名前で、My Machinesに登録する手順」は、Terminalを操作する必要があり、しかも、そのTerminalを立ち上げた状態にしておかなければならないらしい。これは、Claudeも同じで、Terminalでリモートモードを指定してClaudeを立ち上げ、Terminalをそのままにしておかなければならない。Codexの場合は、Mac mini側のChatGPTデスクトップアプリでRemoteを有効化し、iPhoneとQRコードでペアリングするだけなので一番簡単であり、この点でCodexの方が優れている。

---

Cursor（Grok 4.7）やGrok Botによって、オートメーションだけでなく、手動による日常処理においても、Codexの負担をかなり軽減できることが分かった。あとは、どの利用枠に、それらの処理を振り分けるかを見極めればよい。
Grok Botによって新しい経験ができそうなので、オートメーションはCursor（Grok 4.7）側に任せ、Grok Botで色々試行するのがいいかもしれない。