うまく依頼する技術

依頼に入れる5要素

上手な依頼は、長い必要はありません。次の5つが入っていれば十分です。足りない点があると、Agent が途中で確認の質問を返すことがあります。公式では、あなたの返事を待っているあいだもファイルの読み取りや編集は続け、返事が届いたらその内容を取り込みます（公式 Agent overview）。

• 背景: 誰が何に困っているか
• 対象: どの画面・ページ・機能か
• 変更: どうなってほしいか
• 制約: 触ってほしくない範囲、守るルール
• 完了条件: 何を見れば終わりか

悪い例 / 良い例

悪い例:「もっとよくして」「オシャレにして」「いい感じに直して」。気持ちは伝わりますが、完了したかどうかが判定しづらいです。

良い例:「料金ページの『お問い合わせ』ボタン文言を『相談する』に変え、他のページは変更しない。プレビューでボタンが見切れないことを確認して」。

添付と具体物

文言の原稿、スクリーンショット、競合サイトの URL、社内ルールの一文は、とても役立つ材料です。スマホアプリでは写真や手描き指示も使えます。

iPhone の Cursor アプリには Design Mode もあり、写真・カメラで撮った画面・ファイルを添付し、画像やプレビュー上の部品にタップや囲みで『ここをこう』と視覚で指せます。『センスよく』より『この画像の余白感に合わせて』『丸を付けたボタンを大きく』の方が再現されやすいです。

ラフや構成図がまだ無いときは、Agent に画像生成を頼めます。文章や参考画像から UI のラフ・製品素材・構成図を作り、会話に表示します。既定ではプロジェクトの `assets/` に保存されます（公式 Agent overview）。Design Mode は既存の画像やプレビューに印を付ける側、画像生成は新しい絵を作る側です。できた画像をそのまま本番に載せないで、方向が合ってから5要素で実装を依頼します。

言葉だけでは流れが伝わらないときは `/canvas` もあります。会話の横に、触って試せる画面やダッシュボードを出してくれます。導線の見本だけでなく、分析・監査・報告にも向きます（公式 Canvases / Agent Skills）。コード変更ではなく、理解用の見本です。開き方は返信末尾のカード、コマンドパレットの Open Canvas、Agents Window の新しいタブです。できた見本の部品を直したいときは、Canvas 上でも Design Mode で印を付けられます（公式 changelog Canvas Design Mode）。同僚に見せたいときは Shared Canvases（rules-and-skills の Canvas 節）。リンクをツールバーからコピーして送り、ダッシュボードに出るのは自分が公開したものだけです。

コピペ用：よくある3テンプレ

初めての依頼は、型を借りると失敗が減ります。次の3つは、そのまま貼ってカッコ内だけ書き換えれば使えます。

• 文言修正:『背景: （誰が）が見て分かりにくい / 対象: （ページ名）の（ボタンや見出し） / 変更: 「（旧）」を「（新）」に / 制約: 他ページ・レイアウトは触らない / 完了条件: プレビューで新文言が見え、見切れない』
• 調査だけ:『まず（機能名）の実装箇所を探し、変更案を3行で説明して。コード変更はまだしない。OK と言ってから実装して』
• 見た目の微調整:『添付スクショの赤丸部分だけ（大きく／余白を広げて）。トーンは既存ページに合わせ、他セクションは変更しない。完了条件: スクショか短い動画で Before/After を見せて』
• Slack で調査だけ: `@Cursor autopr=false まず（機能名）を調べて変更案を3行で。コード変更はまだしない`

終わるまで追い続ける目標（/goal）

Agent は通常、送った1通を『新しい仕事』として読みます。大きな目標を短い依頼に切り直していると、途中で終わったように見えることがあります。

`/goal` を使うと、『終わるまで追い続ける目標』を渡せます。公式の例は `/goal fix all flaky tests and make CI green`（フレークテストを全部直して CI を緑にする）。cursor.com/agents でも使えます（公式 Agent overview）。

`/goal` は順次公開中です。入力に出ないときは、新しいチャットで試してください。手順をいつも守らせたいときは Custom Mode（Skill をピン留め）と、定期確認なら `/loop` と組み合わせられます。Desktop の Custom Mode は `/` から Skill を選び、⌥ Enter（Windows は Alt+Enter）か『Use as Mode』でピン留めします。CLI では Enter は今の1通に付けるだけ、ピン留めは同じ ⌥ Enter です（公式 CLI using）。CLI の `/goal` は Ctrl+C で一時停止できます（公式 Agent overview）。レビューや CI を待って再開するのは Subscriptions（第2章の追加指示レッスン）です。開いた PR を見守って直してほしいときは `/autopilot`（review-and-merge）。1回のチャットで終わらない機能づくり・移行・日常の手入れは、左ナビの Projects（コーディネーター）です（when-desktop）。

最初から入っている Skills（任せ方の近道）

Cursor には、自分で SKILL.md を書かなくても使えるビルトイン Skills があります。チャットで `/` と打つと一覧できます。依頼内容がはっきりしていれば、Agent が自分で選ぶこともあります（公式 Agent Skills）。

• `/autopilot`: 開いた PR のレビュー指摘・コンフリクト・赤い Checks・残り仕事を見守って直す。マージまで任せたいときの最短入口
• `/cursor-blame`: AI が書いた変更と、そのときの依頼文を調べる。『この差分はなぜ入った？』のとき
• `/split-to-prs`: 大きな変更を小さな PR に分ける。『ついでに』が増えたとき
• `/canvas`: 会話の横に、触って試せる画面やダッシュボードを出す。言葉だけではイメージしにくいときの見本。同僚へ渡すなら Shared Canvases（リンクをコピー）
• `/review`: 状況に合うコードレビュー（Bugbot / Security Review など）を選んで走らせる。push やマージの前に先に読んでもらう入口。明示するなら `/review-bugbot` / `/review-security`。同じ差分のまま PR を出すと、保管庫側の Bugbot は再実行を飛ばすことがある
• `/agent-review`: Desktop で手元の変更を読む。PR の Bugbot や `/review` とは別。設定は Agents（Cursor 3.11 以降は Git & PRs → Pull Requests）。深さは Quick / Deep（公式 Agent Review）
• `/shell`: 渡した文をそのままシェルで実行する。コマンドを渡されたときだけ。はじめての方は5要素の依頼の方が安全です
• 終わるまで追い続ける目標は `/goal`。イベントを待って再開するのは Subscriptions（`/subscribe`）。定期確認は `/loop`。1回のチャットで終わらない機能づくりは Projects

調べるだけ・計画してから作る（Ask / Plan）

Desktop・CLI・Agents Window のチャット入力には、仕事の進め方を切り替えるモードがあります。公式 CLI overview の表は Agent・Plan・Ask の3つです。Shift+Tab で回せ、入力欄のモード選択からも変えられます。CLI なら `/plan` / `/ask`、起動時の `--plan` や `--mode=ask` もあります（公式 Plan Mode / CLI）。再現できるのに原因が分からない仕事は、次の節の Debug Mode です。

Ask は、ファイルを変えずに調べるモードです。『どこに書いてある？』『いまの動きは？』を先に知りたいときに使います。Cloud Agent（ブラウザ / スマホ）に Ask ボタンが無いときは、このレッスンの『調査だけ』テンプレや Slack の `autopr=false` が同じ役割です。

Plan は、コードを書く前に計画を出すモードです。確認の質問 → 保管庫を調べる → 計画を出す → あなたが直してから『作る』、という公式の流れです。やり方がいくつかある仕事、触る場所が多い仕事、要件がまだぼんやりしているときに向きます。小さな文言修正は、これまでどおり Agent（実装）で十分です（公式 Plan Mode）。

複雑な依頼を書くと、Plan を勧めてくることもあります。計画は既定ではホームに保存され、チームで残したいときは Save to workspace で保管庫へ移せます。CLI では計画のあとに手元で作るか、Cloud Agent で作るかを選べることがあります（公式 CLI changelog）。

• Agent: 実装する（既定）。小さな修正の本線
• Plan: 先に計画を見てから作る。大きな仕事・方針が複数あるとき
• Ask: 調べるだけ。ファイルは変えない
• Debug: 再現できるのに原因が分からないとき（次の節）
• Cloud Agent: Ask 相当は『調査だけ』。Plan 相当は『まず計画を出して。実装は OK と言ってから』。Debug 相当は再現手順つきで『ログを足して原因を特定してから直して』

再現できるのに原因が分からないとき（Debug）

Ask は調べるだけ、Plan は計画してから作る、Agent は実装する、という3つに加え、Desktop と CLI には Debug Mode があります。すぐコードを直すのではなく、仮説を立ててログを足し、あなたが再現したあとの実行記録から原因を絞ってから直します（公式 Debug Mode）。

向く仕事は、再現できるのにコードを読んでも原因が分からない不具合、タイミングで起きる不具合、遅さやメモリ、以前は動いていたのに壊れた、です。普通の Agent が当てずっぽうで直して外れるときに切り替えます。

公式の流れは次の6段です。①関連ファイルを読んで仮説を複数出す ②手元の Cursor 拡張にあるデバッグサーバーへ送るログを足す ③あなたに再現手順を出して、そのとおりに試してもらう ④集まったログから原因を特定する ⑤原因に絞った修正（数行のことが多い） ⑥もう一度再現して確認し、ログ用の追記を消す。

ブラウザやスマホの Cloud Agent には、このデバッグサーバーはありません。クラウド側では『再現手順を書いて、ログを足して原因を特定してから直して。当てずっぽうの修正はしない』と依頼します。

• 入口: モード選択、Shift+Tab、または `/debug`（CLI は `/debug` やプロンプト付き）
• あなたがやること: 症状・期待と実際・再現手順を詳しく書く。Agent が出した手順どおりに再現する。必要なら何度か試す
• Cloud Agent: Debug Mode 画面は無い。再現手順つきの調査依頼で代用