Google Antigravityで複数のAIエージェントを並列に動かす方法は、2026年10月31日時点のAntigravity App(v2.28.2)とAntigravity CLI(v1.4.10)で4つあります。プロジェクト内で会話を複数立てる方法、親エージェントからサブエージェントを呼ぶ方法、有料プラン向けの /boost と /teamwork です。以前 /teamwork-preview という名前だったコマンドは /teamwork になり、旧来のWorkflowsは10月19日に停止しました。
この記事では、4つの方法の使い分け、カスタムサブエージェントの定義、Skills(SKILL.md)の配置と優先順位、Rules・AGENTS.mdの読み込み範囲、スマホからの遠隔操作、並列実行時の権限設定を公式ドキュメントに沿って説明します。製品の全体像や料金はアンチグラビティ(Google Antigravity)とは?料金・日本語化・App/IDE/CLIの選び方【2026年10月】にまとめています。
まとめ:Antigravityのマルチエージェントの要点
- 並列の手段は4つ:並列会話とサブエージェントは全プラン、
/boostと/teamworkは有料プラン。数分の作業は並列会話、数時間までの難しい不具合は/boost、数日かかる移行は/teamworkを選びます。 - 衝突を避けるならNew Worktreeモード:Git管理下のフォルダでは会話ごとにworktreeが作られ、作業中の直接の上書きを避けられます。Git管理外のフォルダは共有され、変更を統合するときのマージ競合は別途解消が必要です。
- カスタムサブエージェントは
.agents/agents/<name>.md:ツール・モデル・コマンド実行方針・MCPサーバーをYAMLで絞れます。入れ子は10階層までです。 - Skillsのグローバル置き場は
~/.gemini/config/skills/にそろった:AppとCLIが共通で読みます。CLIだけが読む追加の置き場もあり、そこは最優先になります。 - Workflowsは2026年10月19日で停止:
/migrate-workflowsでSkillsへ変換します。 - 権限はDefaultかAuto(Preview)から始める:サブエージェントは親の権限をそのまま引き継ぐため、Turboで外部の文章を読ませないことが基本です。
Antigravityで複数エージェントを動かす4つの方法
1.0のIDEに付属していたAgent Managerは、2.0で独立したデスクトップアプリ(Antigravity App)に発展しました。エージェントは「プロジェクト」単位で動き、IDEとの違いはAntigravity 2.0で変わった点とIDEとの違い|エディタの戻し方・WSL対応・料金で扱っています。並列化の手段は次の4つで、公式の比較表に沿うと作業時間とプランで分かれます。
| 方法 | 起動 | プラン | 想定時間 | 作業場所 |
|---|---|---|---|---|
| 並列会話 | 会話を複数開始 | 全プラン | 数秒〜数分 | Local/New Worktree |
| サブエージェント | 親が invoke_subagent | 全プラン | タスク次第 | inherit/branch/share |
| Boost | /boost |
有料プラン | 数秒〜数時間 | 使い捨てのworktree |
| Teamwork | /teamwork |
有料プラン | 数時間〜数日 | マイルストーンごとのworktree |
4つともAntigravity AppとAntigravity CLI(agy)の両方で使えます。CLIの導入はAntigravity CLI(agy)の使い方|Linux導入・自動承認・無料枠とCIの終了コードを参照してください。
並列化とは別に、1つのエージェントを長く走らせるコマンドもあります。/goal は完了条件を満たすまでエージェントが手を止めないモードで、サブエージェントの終了は待ってから続行します。/schedule は「10分後にデプロイ結果を確認」のような予約を会話の中に置くコマンドです。どちらも全プランで使え、/boost や /teamwork の代わりではなく、並列で走らせたエージェントの完走を待つ補助として組み合わせます(Goal command)。
並列会話のLocalモードとNew Worktreeモードの使い分け
いちばん手軽な並列化は、同じプロジェクトで会話を複数立てることです。会話を始めるときのworktreeセレクターで、エージェントが作業する場所を選びます(Projects)。
同じフォルダで並列にするときの衝突対策
Localモードは、いま開いているフォルダやGitチェックアウトをそのまま使います。複数の会話が同じ作業ツリーを書き換えるので、画面の修正とAPIの修正のように触るファイルが分かれているときだけ向きます。New Worktreeモードは会話ごとに新しいGit worktreeを作り、手元の作業フォルダには触れません。公式ドキュメントは、複雑なタスクや並列サブエージェントの衝突防止にこちらを勧めています。
判断基準は単純で、2つの会話が同じファイルを編集する可能性が少しでもあればNew Worktreeを選びます。Gitで管理していないフォルダはworktreeを作れないため、Gitチェックアウトと混在したプロジェクトでは、Gitの方だけ新しいworktreeになり、Git以外のフォルダは元の場所で編集されます。
複数リポジトリをまたぐプロジェクト
プロジェクトは複数フォルダを持てます。フロントエンドとバックエンドのリポジトリを1つのプロジェクトに入れれば、1つの会話で両方を読み書きできます。プロジェクトごとに権限プリセットも個別に設定でき、新規プロジェクトは「Inherit Global」(全体設定を継承)から始まります。
サブエージェントの定義と作業委任
親エージェントが invoke_subagent ツールを呼ぶと、役割と初期プロンプトを持った別セッションが並行して立ち上がります。サブエージェントは親の会話履歴を引き継がず、空のコンテキストから始まります。調査や大量のファイル読み込みを任せると、親の文脈が汚れにくくなります。
作業場所の3つの指定と組み込みサブエージェント
作業場所は inherit(親と同じワークスペース)、branch(独立したGit worktree)、share(ディレクトリの保存領域を共有)から選びます。組み込みで用意されているのは次の3種類です。
research:コードベースの調査・ファイル探索・構造把握browser:サンドボックス化したブラウザでの操作確認(/browserからのみ起動)self:呼び出し元と同じシステム指示とツールを持つ複製
.agents/agents/ に置くカスタムエージェントの書き方
独自のサブエージェントはYAMLフロントマター付きのMarkdownで定義します。置き場所はワークスペースなら .agents/agents/<name>.md か .agents/agents/<name>/agent.md、全プロジェクト共通なら ~/.gemini/config/agents/ です。会話中にエージェントが define_subagent ツールで一時的なサブエージェントを作ることもできます。
---
name: code-auditor
description: セキュリティ監査と静的解析を担当する。PRのレビュー時に使う。
tools:
- view_file
- grep_search
- run_command
subagent: true
mainAgent: false
model: pro
commandExecutionPolicy: sandbox
# 独自スキルを用意した場合だけ、実際のパスをskillsに書く
skills: []
---
# System Prompt
ファイルは変更せず、脆弱性・未検証の入力・ハードコードされた秘密情報を指摘する。
指摘ごとに修正手順を1行で示す。
name と description が必須で、description は親エージェントが委任先を選ぶ判断材料になります。主な項目は次のとおりです。
| 項目 | 既定値 | 用途 |
|---|---|---|
| tools | [] | 使えるツールを列挙 |
| subagent | true | invoke_subagent から呼べるか |
| mainAgent | true | 主エージェントとして選べるか |
| model | inherit | inherit/flash/pro |
| commandExecutionPolicy | sandbox | off/auto/eager/sandbox |
| mcpServers | [] | このエージェント専用のMCPサーバー |
| skills/plugins | [] | 使わせるスキルやプラグイン |
Appの変更履歴では、2.9.1(2026年8月20日)で inheritCustomizations を書くと既存のスキル・ルール・サブエージェントを再利用できるようになり、2.17.0(9月22日)で hooks: にフックのファイルを列挙できるようになりました。公式ドキュメントは既知の不具合として、tools に存在しないツール名や綴り違いを書くとサブエージェントが実行中に固まる場合があると明記しています。view_file や run_command のように正確な名前で書いてください。
状態遷移・入れ子の上限・権限の継承
サブエージェントは「Running」「Idle」「Killed」の3状態を取ります。タスクを終えると結果を親に送ってIdleになり、メッセージを受け取ると以前の文脈を保ったまま再開します。Killedは再開できず、作ったworktreeは自動で片付けられます。入れ子は主エージェントの下に10階層までで、それ以上は強制的に止まります。
権限は親から引き継がれます。許可済みのコマンド接頭辞、読み書きできるディレクトリ、サンドボックス設定がそのまま適用され、承認が必要な操作はメイン画面のサブエージェントパネルに上がってきます。Appでは2.19.1(9月30日)から、親を経由せずサブエージェントへ直接メッセージを送れます。CLIでは /agents で一覧(Agent Managerパネル)を開き、Alt+J で承認待ちのサブエージェントへ移動、Ctrl+K で保留中の操作をその場で承認します。直接の指示は @research:API-Key-Header-Researcher Also check the tests. のように @ とサブエージェント名で始めます。
サブエージェントに役割を割り振る設計そのもの(オーケストレーターと作業役の分け方)は、Orchestrator-Subagentとは|Anthropic公式マルチエージェント協調5パターンの選び方【2026年版】で一般論として整理しています。
/boostと/teamworkの使い分け
サブエージェントを自分で組まなくても、Antigravityが役割分担を組み立てるコマンドが2つあります。どちらも有料プラン向けで、無料プランでは使えません。
/boost:数時間までの難しい不具合とリファクタリング
/boost は2.12.0(2026年9月2日)で追加されました。オーケストレーターが課題を検証できる単位に分解し、実装担当と調査担当のサブエージェントを使い捨てのworktreeで並行させます。各サブエージェントがローカルでビルドとテストを回し、失敗すれば診断を次の周回に戻して直し、全テストが通った時点で要約を返します。聞き取りの段階はなく、入力した直後に動き出します(Boost deep reasoning)。
/boost Investigate the race condition in the session cache and implement a thread-safe fix with tests.
競合状態やデッドロックの調査、同期APIから非同期への移行のように、1往復では解けないが数日はかからない作業に向きます。
/teamwork:数日規模の移行やサブシステム構築
/teamwork(旧 /teamwork-preview)は2段階で進みます(Teamwork agent teams)。
- 第1段階(スコープ定義):エージェントが目的・要件・要件ごとの検証方法・受け入れ基準を聞き取り、プロンプトの成果物にまとめます。承認するまで実装は始まりません。
- 第2段階(自律実行):Sentinelが依頼を記録し、Project Orchestratorがマイルストーンに分けて、Explorers(読み取り専用の調査)とWorkers(実装)に割り振ります。Critic・Challenger・Auditorが各マイルストーンを検証し、最後にSuccess Auditorが全体を確認します。
作業フォルダは既定で ~/teamwork_projects/{PROJECT_NAME} に作られ、1つのファイルを複数のWorkerが同時に編集しないよう割り当てが固定されます。
実行経路はプロンプトの書き方で変わります。既定は分散コーディングで、「keep it small」のように小さく収める指示を入れると分解しない軽い経路になり、「review this paper」なら文書レビュー、定理の証明なら数学向けの経路が選ばれます。検証の厳しさは development(既定)・demo・benchmark の3段階で、第1段階で「禁止したい近道」を答えた内容から決まります。聞き取りで4つの近道をすべて禁止すると benchmark になります。ただし、このモードは標準ライブラリだけを使った独立したゼロからの実装を要求します。既存のライブラリやフレームワークを使い続ける移行では、捏造された出力や見せかけの実装だけを指摘する既定の development が現実的です。
Antigravity Skills(SKILL.md)の作り方と配置
Skillsは、特定の作業手順をフォルダにまとめてエージェントに渡す仕組みです。オープン標準のAgent Skills(agentskills.io)に沿っており、同じSKILL.mdは他の対応ツールでも読めます。標準そのものの仕様はAgent Skillsとは?SKILL.md仕様とAAIF寄贈後も移植性を保つ実装手順で扱っています。
SKILL.mdの最小構成
フォルダの中に必須の SKILL.md を置き、必要なら scripts/・examples/・resources/ を足します。Antigravityのフロントマターで必須なのは description だけで、name を省くとフォルダ名が使われます(Agent skills)。
.agents/skills/
└── db-migration/
├── SKILL.md
└── scripts/
└── check_schema.sh
--- SKILL.md ---
---
name: db-migration
description: PostgreSQLのマイグレーションを作成・レビューする。スキーマ変更やインデックス追加の依頼で使う。
---
# DB Migration Skill
1. scripts/check_schema.sh は自分で用意する補助スクリプトの例。中身を読まず、先に --help を実行して使い方を確認する。
2. 列の削除や改名は1回のデプロイで行わず、追加と削除を分ける。
3. 稼働中の通常テーブルで書き込みを継続する必要がある場合は、CREATE INDEX CONCURRENTLY をトランザクションブロックの外で実行する。パーティション親テーブルには直接指定せず、各パーティションで並行作成したインデックスを親のインデックスへ接続する手順を検討する。
エージェントが毎ターン見るのは、スキルの名前と description の一覧だけです。依頼内容に合うと判断したときに初めてSKILL.md全体を読みます。公式ドキュメントは、description を三人称で書いて発動させたい場面の語を入れること、同梱スクリプトは中身を読ませず --help から実行させることを勧めています。description にコロンを含めるときは引用符で囲んでください。CLIの変更履歴に、引用符なしの「description: Runs checks: formatters and linters.」でスキルが読み込めなかった不具合の修正が載っています。
Skillsの配置場所と同名スキルの優先順位
9月時点ではグローバルの置き場所がAppとCLIで食い違っていましたが、現在の公式ドキュメントでは ~/.gemini/config/skills/ がApp・CLI・IDEに共通する置き場所です。
| 面 | ワークスペース | グローバル | 面固有の追加 |
|---|---|---|---|
| Antigravity App | .agents/skills/ | ~/.gemini/config/skills/ | なし |
| Antigravity CLI | .agents/skills/ | ~/.gemini/config/skills/ | ~/.gemini/antigravity-cli/skills/ と ~/.gemini/skills/ |
| Antigravity IDE | .agents/skills/ | ~/.gemini/config/skills/ | 旧 ~/.gemini/antigravity/skills/ |
ワークスペースの .agents/skills/ は、開いたフォルダからリポジトリのルートまで親フォルダごとに読まれます。走査は1階層だけなので、skills/database/migrate-schema/ のように1段深く置いたスキルは読まれません。読ませるには1段上げるか、.agents/skills.json の include_only で名前を挙げます(Customization discovery)。
同じ名前のスキルが複数あると、リポジトリ内の個人用フォルダ、ワークスペース、~/.gemini/config/、組み込みの順で1つだけが残ります。ただしCLIでは ~/.gemini/antigravity-cli/skills/ と ~/.gemini/skills/ のスキルがすべてに優先し、マニフェストの exclude でも隠せません。古いCLIの置き場所に同名のスキルが残っていると、チームで共有したワークスペースのスキルが黙って上書きされます。AppとCLIの設定をそろえる場合は、旧パスのスキルを共通パスへ移し、読み込み元と動作を確認してから旧パスの重複分を削除します。
スキルの呼び出しとプラグインでの配布
エージェントは依頼内容から自動でスキルを選びますが、AppとCLIでは /<スキル名> で明示的に呼べます。CLIは定義したスキルをスラッシュコマンドに変換し、実行中に追加したときは /skills reload か新しい会話で反映します。
チームに配るなら、スキル・ルール・サブエージェント・MCPサーバー・フックを1つにまとめるプラグインが使えます。Appの「Customizations」からマーケットプレイスのプラグインを追加でき、CLIでは次のように入れます。プラグイン由来のスキルは <plugin>:<skill> という名前になり、手元のスキルと衝突しません(Plugins)。
agy plugin list --json
agy plugin install <plugin-name>
agy plugin install https://github.com/<owner>/<repo>
agy plugin install ./my-skills-plugin
Rules・AGENTS.mdの読み込み範囲とWorkflowsの停止
公式ドキュメントの切り分けは明快で、「常に zod で検証する」のような制約や不変条件はRules、「マイグレーションの実行手順」のような複数ステップの作業はSkillsに書きます(Rules)。
AGENTS.mdと.agents/rulesの読み込み範囲
AGENTS.md と GEMINI.md はフロントマター不要で、常に有効です。読まれるのはワークスペースのフォルダと、そこからリポジトリのルートまでの親フォルダです。ワークスペースより下のサブフォルダの AGENTS.md は、エージェントがそのフォルダのファイルを編集しても読まれません。リポジトリのルートを開いたまま src/routes/AGENTS.md に規約を書いても効かないので、モノレポではパッケージのフォルダを開くか、規約をルート側に寄せます。見つかったルールは上書きされず、すべて足し合わされます。
.agents/rules/*.md は必ずフロントマターで trigger(always_on/model_decision/glob/manual)を指定します。書き忘れや alwaysOn のようなキャメルケースは警告なしに捨てられ、サブフォルダに入れたルールも .agents/rules.json に登録しない限り読まれません。1ファイルが24,000バイトを超えると切り詰められ、グローバルと常時有効のルールには合計20,000トークンの枠があります。枠を超えると大きいファイルから順に「パスと説明」だけの参照に格下げされます。
WorkflowsからSkillsへの移行
IDEの機能だったWorkflows(.agents/workflows/<name>.md を /<name> で呼ぶ手順書)は、2026年10月19日で停止しました。以後、旧来のworkflowsフォルダは索引されず、スラッシュコマンドでも実行できません。Googleは新しいワークフローの仕組みと移行手順を追って案内するとしています(Migrate from workflows to skills)。
手元の手順書は、Appのチャットで /migrate-workflows を実行するとスキルへ変換できます。~/.gemini/config/workflows/ と .agents/workflows/ を走査して .agents/skills/<name>/SKILL.md を作り、元のファイルは deploy.md.bak のように .bak を付けて残します。1ファイル12,000文字までだったWorkflowsと違い、スキルは補助スクリプトや参照資料を別ファイルに分けられます。同じ名前のスキルとWorkflowが両方あれば、スキルが実行されます。
スマホから操作するRemote Control
長時間の並列作業を任せていると、席を離れている間に承認待ちで止まることがあります。2.9.1(2026年8月20日)で追加されたRemote Controlは、PC上で動いているエージェントをブラウザから操作する機能です(Remote Control)。
- Appでの有効化:設定(macOSは
Cmd + ,、Windows・LinuxはCtrl + ,)の「Application」で「Enable Remote Control」をオンにし、スマホのブラウザで antigravity.google.com を開いて同じGoogleアカウントでログインします。ホーム画面にWebアプリを追加すると、完了や入力待ちのプッシュ通知を受け取れます。 - CLIの対話モード:実行中のセッションで
/remote-control、起動時ならagy --remote-control。承認や質問への回答は端末とブラウザのどちらからでも返せます。端末を閉じるとトンネルも切れます。 - CLIの常駐デーモン:
agy remote-control startでOSのサービス(Linuxはsystemdユーザーサービス、macOSはLaunchAgent、Windowsはタスクスケジューラ)として常駐させます。macOSはログイン時に起動し、サインアウトすると止まります。Windowsで起動時から動かすには管理者権限のプロンプトで登録します。
ファイルやGitのworktree、認証情報はPC側に残ったまま動くため、クラウドに環境を複製する必要はありません。反対に、PCがスリープしたりネットワークが切れたりすると一覧から消えます。
並列実行で情報漏洩を防ぐ権限設定
エージェントを増やすほど、1回の承認漏れの影響も大きくなります。サブエージェントは親の権限を引き継ぐので、最初にプロジェクトの権限プリセットを決めておきます。個人アカウントのAppでは、2.23.0(10月12日)以降のプリセットは次の4つです(Agent permissions)。
| プリセット | サンドボックス | ターミナルコマンド |
|---|---|---|
| Request Review | 無効 | 毎回確認 |
| Default | 有効 | サンドボックス内は自動・外は確認 |
| Auto(Preview) | 有効 | 外へ出るコマンドも安全なものは自動 |
| Turbo | 無効 | 確認なし・制限なし |
サンドボックスはLinuxがカーネル名前空間、macOSが sandbox-exec で動き、~/.ssh や .env を遮断し、通信は既定で切られます。read_url で許可したドメインだけが通ります。Auto(Preview)は、サンドボックスの外で実行する必要があるコマンドを別のエージェントが審査し、安全で元に戻せるものは自動で通し、破壊的なものは確認を求めます。なお、Business・Enterpriseのアカウントは旧方式の設定(Default/Full machine/Turbo modeとSandbox Modeの手動切替)のままで、Autoは使えません(Terminal sandbox)。
権限ルールは Deny・Ask・Allow の3つのリストで書き、衝突したときは Deny > Ask > Allow の順で優先されます。command(git push) のようなAllowルールはサンドボックス外の実行も承認不要にするため、中身を確認したコマンドに限って足します。CLIはAppと別設定で、サンドボックスは既定で無効です。CLIで隔離するには /config で有効にするか、~/.gemini/antigravity-cli/settings.json の enableTerminalSandbox を true にします。
公開された攻撃の報告も、並列運用の危険がどこにあるかを示しています。PromptArmorは2025年11月、Webページに埋め込んだ指示(間接プロンプトインジェクション)によってエージェントがブラウザのサブエージェントを起動し、.env の認証情報を外部URLへ送らせる手口を公開しました。既定のURL許可リストに webhook.site が含まれていた点も指摘しています。Pillar Securityは、ファイル検索ツール find_by_name の入力検証の不足を突いてSecure Modeを回避し、任意のコードを実行させる手口を報告しました。Pillar Securityの公開タイムラインによれば、報告は2026年1月7日で、Googleは2月28日に問題を修正済みとしました。
どちらも、エージェントが読んだ外部の文章が指示として働き、許可済みの操作を組み合わせて悪用される形です。サブエージェントは親の権限をそのまま引き継ぐため、Turboのまま外部サイトや第三者のリポジトリを読ませないことが対策の基本です。
マルチエージェントを使わないほうがよい場面
並列にすれば速くなるとは限りません。次の条件に当てはまるときは、1つの会話で進めたほうが結果的に早く終わります。
- 変更が1ファイルに集中している:同じファイルを複数のエージェントが触ると、worktreeを分けてもマージで衝突します。
/teamworkがWorkerにファイルを排他的に割り当てるのも、この衝突を避けるためです。 - 無料プランの残り利用枠が少ない:無料プランの利用枠は週単位で回復し、公式ドキュメントによれば上限はエージェントの作業量に連動します。並列にするとその分早く上限に届き、週の残りを待つことになります。
- 仕様が固まっていない:何を作るか決まっていない段階で並列にすると、各エージェントが別の解釈で実装します。
/planで計画を作って承認してから分けるほうが手戻りは少なくなります。 - 承認要求を見きれない:サブエージェントが増えるほど承認の通知も増えます。Request ReviewやTurboのようにサンドボックスを使わない設定なら、並列数を絞るか単一の会話で進めます。
並列化が効くのは、フロントエンドとバックエンド、実装とテスト作成のように作業の境界がファイル単位で切れるときです。単一エージェントで足りる条件はシングルエージェントとは?マルチエージェントとの違いと使い分けの判断基準【2026年10月】、構成パターン全般はマルチエージェントとは?仕組み・構成パターンと採用判断を研究データで解説【2026年10月】で扱っています。社内の開発や業務にAntigravityのようなエージェントを組み込む設計から相談したい場合は、AIエージェント開発の支援も行っています。
よくある質問
Antigravityのマルチエージェントは無料で使えますか?
並列会話とサブエージェントは無料プランでも使えます。/boost と /teamwork は有料プラン限定です。無料プランの利用枠は週単位で回復し、Google AI Proは5時間ごとに回復する枠を週次上限まで使えます。料金の詳細はCursorとAntigravityの違いを比較|新料金・Claude 5.5対応・法人利用とルール移行【2026年10月】でも比べています。
1.0のAgent Managerは2.0のどこにありますか?
2.0ではAntigravity App全体がエージェントの管理画面になりました。会話はプロジェクト単位で並び、サブエージェントは会話内のカードやサブエージェントパネルで確認します。CLIでは /agents で開く一覧が「Agent Manager」パネルと呼ばれています。
AGENTS.mdとGEMINI.mdはどちらに書けばよいですか?
Antigravityはどちらも同じ扱いで読み、フロントマターも要りません。CodexなどAGENTS.mdを読む他のコーディングエージェントと規約を共有するなら、AGENTS.mdに書くと1ファイルで済みます。常に守らせたい規約はAGENTS.md、特定の作業でだけ使う手順はSkillsに分けます。
Antigravityはスマホから操作できますか?
Remote Controlを有効にすれば、スマホのブラウザから antigravity.google.com にログインして、PCで動いているエージェントの進捗確認・承認・新しい指示ができます。エージェント自体はPC上で動くため、PCの電源とネットワークは入れておく必要があります。
マルチエージェントで使えるAIモデルは何ですか?
2026年10月31日時点の個人プランでは、無料とGoogle AI PlusはGemini 3.8 Flashが中心で、Google AI ProとUltraではClaude Sonnet 5.5・Opus 5.5(Proは無料トライアル中を除く)とGemini 4 Argon(Proは有料契約か対象端末のトライアル)も選べます。Claude Sonnet 4.6・Opus 4.6とGPT-OSS-120bは2026年11月2日に削除予定です。サブエージェントの定義では model に inherit・flash・pro のいずれかを指定します(Choose a model)。