3行でいうと

  • App の基本の流れは、「プロジェクトを作る → 指示を送る → Local か New worktree かを選ぶ → 計画（Implementation Plan）を読んでコメントし、Proceed を押す → 差分を見る」です。計画を先に出させたいときは /plan を使います。
  • 公式のページ同士で、用語が揃っていません。変更履歴（v2.17.0）は「Plan Review Policy」と書き、Artifact review のページは「artifact review policy」と、新しい会話を始めるときに選ぶ「Planning mode」「Fast mode」を書きます。CLI の Modes ページは、/planning と /fast は 1.1.0 で除かれたと書いています。どれが画面の現状かは決めず、この記事では分けて書きます。
  • ブラウザの操作は /browser（App と CLI。公式は IDE では使えないと書く）で、結果は WebM の録画と、スクリーンショットなどの成果物に残ります。初回は Chrome のリモートデバッグの許可を求められる、と公式は書いています。
  • CLI では、Ctrl + R で成果物の一覧を開き、y／n で承認・却下します。-p で、1回だけ動かして終わる使い方（ヘッドレス）もあります。

この記事は、公式の資料を2026年10月25日に読んでまとめたものです。この記事は、実際に使って確かめた記録ではありません。運営者はAntigravityを入れていますが、使い心地はこの記事には書いていません。手順は「公式の手順を順に並べたもの」で、「この記事の例」と書いた指示文は、公式の記載に合わせて組んだ例です（動作は確かめていません）。画面の表記は版で変わるので、手元の画面と照らして読んでください。

先に結論

前提：用語をそろえる

たとえ話：工務店に頼む順番

家の改修を頼むとき、いきなり壁を壊してもらうより、先に見積書と図面（計画）をもらって、直してほしい所に書き込みをしてから「進めてください」と言う、という順番があります。/plan と Proceed は、その順番にあたります。これは僕らのたとえで、公式の表現ではありません。

場面1：App で最初のプロジェクトを作って指示を送る

公式の Getting Started の順です。

  1. 左のサイドバーの New Project（フォルダに＋のアイコン）を押す。
  2. Add Folder を押し、作業するフォルダ（Git リポジトリでも、ただのフォルダでもよい）を選ぶ。複数のフォルダを足せます。公式の Projects ページは、フロントエンドとバックエンドのような関連するフォルダを1つのプロジェクトに入れると、複数のコードを見渡せると書いています。
  3. Create を押す。
  4. 入力欄に指示を書いて Enter。公式の例は次です。
Add unit tests for the authentication handlers
  1. 出てくる設定の画面で Mode を選ぶ。
Mode 公式の説明
Local mode エージェントが、あなたの今のフォルダで直接作業する。素早い対話的な編集向き。並行して動くエージェントは同じフォルダを共有する
New worktree mode この会話のために新しい Git の worktree を作る。あなたの作業フォルダはそのまま。並行して動くサブエージェント同士がぶつからない。Git のフォルダには worktree、Git でないフォルダは直接アクセスのまま
  1. 返ってくるもの：エージェントの進み具合の表示（ステップ）、編集したファイル、確認が必要な操作の承認の表示。

Local か worktree かの判断は、公式の説明（Local は直接、worktree は作業フォルダを汚さない）から読み取れる範囲では、「いまのフォルダを直接変えてよいか」で分かれます。これは僕らの見立てです。

プロジェクトに属さない一時的な会話は、公式によれば、隔離されたローカルの作業用フォルダで動き、独自の設定と権限を持ち、全体の権限も引き継ぎます。

画面の基本操作（App）

公式の Getting Started のショートカット表です。

操作 macOS Windows・Linux
会話の一覧を開く ⌘K Ctrl + K
ファイル検索 ⌘P Ctrl + P
入力欄に移る ⌘L Ctrl + L
新しい会話 ⌘N Ctrl + N
会話を順に切り替える ⌥ Up / Down Alt + Up / Down

機能一覧のページには、Ctrl/Cmd + バッククォートで統合ターミナル、Ctrl+M で音声の入力（マイクのボタンでも開始・停止）、とも書かれています。

場面2：先に計画を出させて、読んで、コメントして、進める（/plan）

入力する

App の入力欄で、/plan に続けて目的を書きます。/plan だけを打つと、自由な聞き取り（discovery）から始まり、エージェントが今開いているファイルと最近の会話を見て質問する、と公式は書いています。この記事の例（公式の説明に合わせた例）は次です。

/plan このリポジトリの認証まわりに、ログインの失敗回数の記録を追加したい

公式が書く流れ

  1. 調べる：コードを書かずに、影響のあるファイルや依存関係を見る。
  2. 質問する：要件があいまいなときや、やり方が複数あるときは、選択肢つきで質問する。
  3. 計画を出す：「Implementation Plan」の成果物を作る。作業の分解と、確認の節目が入る。
  4. あなたがレビューする：成果物の画面で、計画を読み、インラインでコメントできる。範囲を減らす、技術を変える、食い違いを直す、といった依頼がコメントの例として挙げられています。
  5. 進める：会話か成果物のヘッダーの Proceed を押すと、承認して実装に進みます。コメントの有無にかかわらず押せます。コメントを送りたいときは、成果物のヘッダーの Review を押すと、コメントがまとめて見られ、進めずにメッセージとして送れます。
  6. 実装のあと、エージェントは計画の節目ごとにテストなどで確かめながら進める、と公式の /plan のページは書いています。

計画のレビューを止める・止めない

公式の Artifact review のページは、レビューの方針を Agent タブで選ぶと書き、2つを挙げています。

変更履歴には、v2.17.0（2026年9月22日）で /plan が加わり、設定が「Plan Review Policy」になった、とあります。その選択肢として、変更履歴は「すべての計画をレビューする」「選んでレビューする」「レビューを飛ばす」の3つの趣旨を挙げます。一方、Artifact review のページは、選択肢を「Request review (recommended)」と「Always proceed」の2つだけ挙げ、この方針を「Planning mode」と結びつけ、「Fast mode」は計画の段階を設けず直接実行するので対象外、と書きます。CLI の設定（artifactReviewPolicy）は、asks-for-review、agent-decides、always-proceed の3つです（05）。選択肢の数と名前が、ページごとに違います。いま画面に出る名前は、手元の Settings で確かめてください。

終わったあと

エージェントが実装を終えると、「Walkthrough」の成果物が作られる、と公式は書いています。変更の要約で、ブラウザを使った作業ではスクリーンショットや画面の録画も入ることがある、という説明です（App と IDE で使える、と書かれています）。

場面3：質問されてから進める（/grill-me）

仕様があいまいなとき向けに、公式は /grill-me を用意しています。1つずつ質問され、各質問に「(Recommended)」と付いた答えが先頭に並ぶ（公式の表記）。自分の答えも書けます。

  1. 入力欄に、公式の例の形で書く。
/grill-me Add per-user rate limiting to the bookmarks API
  1. エージェントがコードを調べ、質問を1つずつ出す。App では入力欄の上のカードに出る。答えを選ぶか、Other に書き、Submit を押す。Skip で飛ばす。閉じるボタンで、聞き取りも作業も止まる。
  2. 質問がなくなったら、あなたの答えに沿って作業が進む。
  3. 計画を先に作りたいなら、/plan /grill-me <task> と重ねて書く、と公式は書いています。

CLI では、質問が番号つきの一覧で出て、矢印と Enter（または番号）で選び、「Write-in…」で自由に書き、Esc で飛ばします。

場面4：変更を確かめる（差分、コミット、巻き戻し）

App

機能一覧のページによると、App には VCS（バージョン管理）のパネルがあり、次ができます。

エディタ（IDE）

公式の Review changes のページの順です。

  1. 会話でエージェントにコードを書かせる。
  2. エージェントのパネルの下のツールバーに「Review Changes」の項目が出る。
  3. それを押すと、エディタの中に変更の画面が開く。
  4. 会話の中で2人（あなたとエージェント）が変えた内容を、スクロールして見る。
  5. ファイルの差分にコメントして、エージェントに伝える。成果物にコメントするときと同じ使い方、と書かれています。

CLI

後述の場面7で、Ctrl + R の成果物の画面と、/diff を扱います。履歴を戻すコマンドは /rewind（/undo）です。

場面5：エージェントにブラウザを操作させる（/browser）

公式の /browser のページの内容です。

手順

  1. 入力欄に /browser と、やってほしい作業を書く。終わりの条件（「〜を報告して」「〜のスクリーンショットを撮って」）を入れると、戻るタイミングが分かりやすい、と公式は書いています。公式の例は次のようなものです（要旨）。
  2. localhost のURLを開いて、幅390pxの表示に切り替えて、ナビゲーションの引き出しを開いた状態と閉じた状態を撮る。
  3. ダッシュボードを開いて、グラフが描かれているか確かめ、コンソールのエラーを報告する。
  4. この記事の例（公式の例の形に合わせたもの）：
/browser http://localhost:3000 を開いて、ログインのボタンが表示されているかを確認し、結果とスクリーンショットを報告して
  1. 初回は、Chrome がリモートデバッグを許可するかどうかを聞いてくるので、許可する必要がある、と公式は書いています。
  2. 進み具合は、App ではサブエージェントのパネルに出ます。CLI では Alt+J か /agents で見ます。
  3. 結果：セッションごとに WebM の録画が会話の成果物に保存されます。処理は非同期で、できあがるとエージェントが知らせる、と書かれています。

ブラウザの権限（公式の記載）

IDE の「Browser Tools」のスイッチ（ユーザー設定の Browser の項）で、ブラウザのツールを止められる、とも書かれています。

場面6：長い作業を任せる（/goal、/schedule、/boost、/teamwork-preview）

コマンド 公式の説明 使える範囲
/goal <目的> 目的が確かめられるまで、止まらずに進める。完了の条件を、確かめられる形で書く。1つの会話で有効な goal は1つ 一覧のページは「All plans」。入口は、/goal のページが App・CLI・IDE、一覧のページは App・CLI（ページ間で違う）
/schedule <いつ> <何を> 一度きりのタイマーか、cron の繰り返しで、今の会話のエージェントを起こす 一覧のページは「All plans」。入口は、/schedule のページが App・CLI・IDE、一覧のページは App・CLI（ページ間で違う）
/boost <task> 複数のエージェントで深く考える。聞き取りなしですぐ実行 有料のプラン。App・CLI
/teamwork-preview <task> 複数のエージェントのチーム。最初に範囲を聞き取り、承認後に自律で実行 有料のプラン。App・CLI
/btw <質問> 作業を止めずに、背景で小さな質問をする 全プラン
/learn 会話の中の訂正を、ルールかスキルとして残す案を作る（08） 全プラン

/goal の例（公式の例）

/goal Migrate the auth package from session cookies to OAuth2 and make sure all unit and integration tests pass

公式は、権限と成果物のレビューの方針は、goal でも変わらないと書いています。止めたいときは「Stop the current goal」のような追加の指示を送ると Cancelled になります。回数の上限はなく、完了の条件が明確かどうかが、止まり方の分かれ目になる、と書かれています。

/schedule の例（公式の例）

/schedule in 10 minutes, check whether the deploy to staging finished and summarize any errors
/schedule every weekday at 9am, run git fetch, list stale local branches, and summarize open PR reviews

スケジュールは、作った会話に結びついていて、会話がないところで動く仕事は、スケジュール用のサイドカー（08）を使う、と公式は書いています。CLI では /tasks で管理し、k で止め、x で終わったものを消します。App は、変更履歴で、以前の「Scheduled Tasks」が v2.21.1 で「Automations」に改名され、Run Now やエージェントによる作成ができる、と書かれています。機能一覧のページは、いまも「Scheduled tasks」の名前を使っています（ページ間で違う）。

/teamwork-preview は、最初の段階（Phase 1）で、目的、検証の方法、受け入れの条件、作業フォルダ（既定は ~/teamwork_projects/{PROJECT_NAME}）を聞き取り、できあがった内容を承認してから、自律の段階に入る、と公式は書いています。

場面7：CLI（agy）で使う

7-1：公式のクイックスタートの順

  1. 練習用のフォルダで agy を起動する（05）。
  2. 公式の例のとおり入力して Enter。
Write a simple python script to fetch web page text
  1. エージェントがフォルダを調べ、計画を作り、変更案を出す。
  2. Ctrl + R で成果物のレビューの画面（Artifact Picker）を開く。矢印で main.py を選び、Y で作成を承認する。Esc で閉じる。
  3. 続けて入力する。
Run the python script and show me the output
  1. python3 main.py の実行の承認を求められたら Y。終わるときは Ctrl + D か /exit。

7-2：成果物のレビュー画面のキー（公式の表）

キー 動作
↑／↓ 項目を移る
y／n 選んでいるファイルを承認／却下
Shift+A／Shift+R 保留中をすべて承認／却下
p 短いプレビューの切り替え
Enter ボタンを実行（open で詳細の画面）
Esc レビューの状態を保存し、承認と却下をエージェントに送って戻る

詳細の画面では、c で行にコメントを書けます（Esc で保存して送る）。公式は、ファイルを書く前に、承認・却下とコメントがエージェントに届く流れだと書いています。

7-3：実行モードを切り替える

Shift + Tab で default → accept-edits → auto → plan の順に切り替わります（auto が使えない環境では飛ばされる）。起動時は agy --mode=plan のように指定します。現在のモードは、右下のステータスバーに出ます。

モード 動き（公式）
default ファイルの作成・変更の前に差分を出して承認を待つ。コマンドも確認
accept-edits ワークスペース内のファイル編集を自動で承認。コマンドは確認
auto（Preview） 編集を自動で承認。コマンドは既定でサンドボックスの中。外に出るものは自動で判定
plan 読み取りの道具だけで調べ、アウトラインの承認までコードを書かない

default の差分の画面では、1 で承認、2 で却下、却下の欄で Tab を押すと、直してほしいことを伝えられます。f で全画面の差分です。/planning と /fast は 1.1.0 で除かれた、と公式の Modes ページは書いています。

7-4：入力のコツ（公式に書かれている範囲）

7-5：会話を管理する

操作 公式の説明
agy -c 今のワークスペースの、直近の会話を続ける
/resume 以前の会話の一覧から選ぶ。会話はいまの作業ディレクトリごとに絞られる
/fork 今の会話を新しいセッションに複製する。Git のチェックアウトは複製されない
/rewind（/undo） 前のメッセージまで履歴を戻す
/context 文脈の使用量を見る

7-6：1回だけ動かして終わる（ヘッドレス）

公式の Headless のページによると、agy -p "..." は1つのプロンプトを送り、答えを返して終わります。答えは標準出力、エラーや承認の通知は標準エラー出力です。この記事の例は次です。

agy -p "このリポジトリの README を要約して"

場面8：エディタの中で使う

公式の Getting Started のIDEのクイックスタートの順です。

  1. 使うエディタでプロジェクトを開く。
  2. エージェントのパネルを開く。VS Code はアクティビティバーの Antigravity のアイコン、Visual Studio は Ctrl+, Ctrl+A、JetBrains は JetBrains AI → Antigravity、Zed は External Agents、Xcode は Intelligence。
  3. 会話のパネルに作業を入力する。
  4. 計画と差分をレビューし、複数の手順の作業をエディタの中で進める。

エディタの機能として、公式のページに次が書かれています。

最初の1時間でやる順番（この記事の案）

ここから下は、公式の手順ではなく、この記事の案です（僕らの見立て）。

  1. （5分）サインインして、Settings で Enable Telemetry と Permission Preset の現在の値を見る。
  2. （10分）失ってよい練習用のフォルダで、Local mode のプロジェクトを作る。
  3. （10分）短い指示を1つ送り、承認の表示がどこに出るかを見る。
  4. （15分）/plan で計画を出させ、計画の1行にコメントをつけてから Proceed を押す。
  5. （10分）差分（VCS パネルか Review Changes）を見る。
  6. （10分）/browser で、localhost のページの表示の確認を1つ頼み、録画の成果物を開く。

つまずきと直し方

症状 公式の記載から読み取れること
/browser が出ない IDE では使えない。管理者がブラウザの利用を止めていると消える
/browser が止まる 初回の Chrome のリモートデバッグの許可の画面を確かめる。許可が必要と書かれている
計画が出ずに進む レビューの方針が「Always proceed」だと待たない、と Artifact review のページが書いている。/plan を明示して使う
コマンドのたびに確認が出る Permission Preset が Request Review のとき、毎回確認。Default は、サンドボックスの外で確認
ネットワークが要るコマンドが失敗する サンドボックスの中ではネットワークなしが既定。command(...) の許可ルールなどで外に出す（05・公式の Sandbox ページ）
CLI の承認を取り消せない（Esc が効かない） default では、Esc で保留中の編集は消えない、と Modes ページが書く。n／2 で却下
goal が止まらない 回数の上限はない、と書かれている。「Stop the current goal」と送る
/plan や /goal が選べない 公式のコマンド一覧の表示と、手元の版（v2.17.0 以降に /plan）を照らす

気をつけること

出典