VS Code 1.121 がリリースされたという話を読んで、率直に「エディタの境界が今までで一番大きく動いた回かもしれない」と感じました。技術評論社の記事「VS Code 1.121 リリース。Markdown プレビューでの Mermaid 図と YAML フロントマター表示を標準搭載し、リモートエージェントにも対応」が伝えている変更は、見出しだけ追うと「Mermaid が標準化」「リモートエージェント追加」と短くまとまります。ただ、これは Antigravity ユーザーの目線で読み直すと、いくつかの意味が浮かび上がってきます。
私は 2014 年から個人で iOS / Android アプリを開発しており、累計 5,000 万ダウンロードを超えた今は、Antigravity Lab を含む 4 つの AI 技術ブログサイトを並行運用しています。エディタは Antigravity と VS Code の両方を場面によって使い分けており、片方の動きはもう片方にすぐ伝播します。今回の 1.121 は、エディタ単独の話ではなく、エディタが自分自身からどう離れていこうとしているか、を語っているように見えました。整理してみます。
Remote agents：エディタが起動していなくても、向こうではセッションが続く
最初に押さえておきたいのが、Agents ウィンドウのリモート対応です。1.120 でプレビューが入った Agents ウィンドウに、SSH または dev tunnels で接続したリモートマシン上でエージェントセッションを走らせる「Remote agents」が追加されました。
これが何を意味するかを、私の個人開発の文脈で書きます。これまでローカル VS Code でエージェントセッションを動かしていると、夕方に Mac を閉じればセッションも閉じます。長時間のリファクタや、4 サイト分のコンテンツ生成のような重い処理を流す場合、「夜のうちに走らせて朝に確認したい」と思っても、ローカルマシンを開けっぱなしにする必要がありました。
Remote agents が入ると、agent host というプロセスがリモート側で立ち上がり、Copilot SDK 上のエージェントループをホストします。クライアント（手元の VS Code）が切断されても、リモート側ではセッションが継続します。私の運用で言えば、自宅の Mac mini に code tunnel を仕込んでおき、外出先の MacBook Pro からは Agents ウィンドウだけ接続して様子を見る、という形が現実的になります。
これは厳密にはリモート開発拡張機能（SSH や Codespaces 経由でリモート上のソースを編集する）とは別物です。エディタ環境ごと向こうに置く話ではなく、長時間のエージェントセッションだけを向こうに置く 設計です。エディタの境界線が、人間の作業環境とエージェントの実行環境の 2 つに分かれ始めた、と読めます。
Agent Host Protocol（AHP）：エージェントの「セッション状態」を共有資源にする
Remote agents の通信に使われているのが、新しいオープンプロトコル「Agent Host Protocol（AHP）」です。これも単なる実装詳細ではなく、設計思想として重要な部分です。
AHP では、agent host がエージェントセッションの状態を一元管理し、接続中のすべてのクライアントへ同期します。状態変更は順序付けされるので、複数のクライアントから同じセッションを扱っても整合性が崩れません。私の理解では、Agent Client Protocol（ACP）が「エディタとエージェントのあいだの会話手順を揃える」ものだったのに対し、AHP は「ホスト側がセッション状態を持ち、複数クライアントへ同期する」役割を担います。
実務で何が変わるかというと、エージェントセッションが「特定のエディタウィンドウに紐づく一時的なもの」から「サーバー側で生き続ける資源」に近づきます。これは Antigravity がそもそも目指している方向（複数のエージェントが並列で動き、人間はそれを監督する）と完全に重なります。VS Code 側でこのプロトコルが標準化されてくると、Antigravity を含む派生 IDE がそのまま乗れる土台ができます。
Claude Agent の Auto モードと「安全弁」の置き方
Claude Agent では、権限確認のプロンプトなしで操作を実行できる Auto 権限モードがプレビュー提供されました。設定 github.copilot.chat.claudeAgent.allowAutoPermissions を有効にすると、権限モードの選択肢に Auto が表示されます。実行前には別の安全確認が入り、要求を超える権限昇格、認識されていないインフラへの操作、悪意あるコンテンツに起因するとみられる動作をブロックする、という設計です。
この Auto モードと並んで「Bypass all permissions」も用意されました。リリースノートでは安全チェックなしの「YOLO mode」と注記されており、allowDangerouslySkipPermissions という設定名そのものから、開発側の警戒の度合いがにじみます。
私が個人開発で Auto モードに乗るかを考えると、結論は条件付きで Yes です。条件は次の 3 つです。
- リモート側のマシンが分離された環境であること（本番リソースに直接触らない sandbox）
- 実行ログが必ず手元に届くこと
- 「これだけは聞いてほしい」操作リストを Skill / インストラクション側に明示しておくこと
特に 3 番目は、Skill 側の allowed-tools を絞る運用（先日 Claude Lab で書いた compile Skill の話と同じ発想）と組み合わせると効きます。Auto はオン / オフの 2 値ではなく、「何を Auto にするかをコード側に切り出す」設計と相性が良いです。
モデル選択と BYOK：ユーティリティモデルを上書きできる意味
地味だが重要な変更が、チャット関連のバックグラウンドタスクで使う「ユーティリティモデル」を、ユーザー側で上書きできるようになった点です。対象は、チャットセッションのタイトル生成・要約・コミットメッセージ・リネーム候補・プロンプト分類・意図検出などで、通常のチャット応答に使うモデルとは別に指定できます。
設定キーは chat.utilityModel（一般的なユーティリティ処理用）と chat.utilitySmallModel（より小型・高速なモデル向け）の 2 つです。VS Code 側のデフォルトでは前者が Copilot サービス側のデフォルトモデル、後者が gpt-4o-mini に解決されます。
これが効くのは、私のように「重い思考は最新モデル、軽い分類処理はコスパの良いモデル」と振り分けたい運用です。1 つのチャットセッションのなかで、本体応答は強力なモデル、要約や分類は安価で高速なモデル、と意図的に分ける設計が可能になります。VS Code Insiders では、BYOK 向けの新しい「Custom Endpoint」プロバイダーもプレビューで導入されました。Chat Completions、Responses、Messages 互換の任意のエンドポイントを 1 つの構成から接続できる、という形です。ここまで来ると、エディタは特定のベンダーに完全に依存する道具ではなくなり、複数のモデルを束ねる「ハブ」に近づいていきます。
統合ブラウザとターミナル：エージェントが動く周辺の整地
統合ブラウザ（Integrated Browser）では、ローカル HTML ファイルを拡張機能なしでプレビューする機能が追加されました。ファイルエクスプローラー上の HTML ファイル、または開いている HTML ファイルのエディタタブを右クリックし、「Open in Integrated Browser」を選びます。
チャットへブラウザ上の要素を追加する操作も改善され、クリックとドラッグで複数要素を範囲選択できるようになりました。私が個人開発でこれを使うとすれば、4 サイトの本番ページから「この部分の DOM を AI に渡してリファクタの相談をしたい」ときに、要素を範囲選択して Add Element to Chat に流す、というワークフローが現実的になります。これまでは DevTools 経由でセレクタを書き写す必要があり、ここに数分の摩擦がありました。
ターミナル側では、エージェントが開始したコマンドに環境変数 VSCODE_AGENT が設定されるようになりました。CLI やスクリプトは、この変数を確認することで、機械読み取りしやすい出力に切り替えたり、進捗アニメーションを抑制したり、対話プロンプトをスキップできます。私の自動投稿パイプライン側でも、これを読んで「人間が走らせている時は色付き、エージェント実行時は素のテキスト」と分岐する余地が出てきました。
加えて、バックグラウンドで動き続けるコマンドは「Running <command> in background - Show」と表示され、Show から対象のターミナルへフォーカスできます。エージェントが作成したバックグラウンドターミナルは、コマンド完了時に自動で破棄されます。長時間タスクを多数走らせる Antigravity 的なワークフローでは、これだけで実用度が体感で 2 段階上がります。
Mermaid 標準搭載と YAML フロントマター表示：地味でも効く 2 つ
最後に Markdown 関連の変更です。これまで Marketplace の「Markdown Preview Mermaid Support」拡張機能で提供されていた Mermaid 図のプレビューが、新しい組み込み拡張機能「Mermaid Markdown Features」として VS Code に統合されました。Markdown プレビュー、ノートブックの Markdown セル、チャット内で、mermaid のフェンス付きコードブロックを図として表示できます。
YAML フロントマターの表示を制御する設定 markdown.preview.frontMatter も追加され、デフォルト値は table。フロントマターを Markdown プレビューの先頭にテーブルとして表示します。codeBlock（YAML コードブロックとして表示）、hide（非表示）も選べます。
地味な変更ですが、私のように毎日 16 本の MDX を生成・レビューする運用では、フロントマターがテーブル整形されて目に入るだけで、premium / level / category の取り違えに気づける確率が上がります。Mermaid の標準化と合わせて、エディタが「ナレッジを書く道具」としての精度を 1 段引き上げてきた回だと感じています。
Antigravity ユーザーが、今回のアップデートをどう受け取るか
Antigravity は VS Code のコードベースをフォークして構築された AI ネイティブ IDE です。つまり VS Code 側で標準化される機能は、時間差はあれど Antigravity にも降りてくる可能性が高いです。今回の 1.121 が示しているのは、エディタが「ローカルで完結する道具」から「複数のクライアントが、向こう側で走り続けるエージェントを覗き込む窓」に変わりつつある、ということです。
私はこのアップデートを、Antigravity の今後のロードマップを読み解くヒントとしても受け取りました。AHP のような共通プロトコルが整備されると、IDE ベンダー単独の差別化は薄れていき、「向こう側でエージェントをどう運用するか」「Skill や権限をどう設計するか」というオペレーション側に主戦場が移ります。これは個人開発者にとって、選択肢が広がる方向の変化です。お読みいただきありがとうございました。