Google I/O 2026を読み解く AIエージェント時代のソフトウェア開発はどこにたどりついたのか：及川卓也からエージェント時代の開発者たちへ（9）（2/3 ページ）

[及川卓也，Tably株式会社]

Antigravityがエディタを「外した」

　次に大きかったのが、「Antigravity 2.0」の発表です。半年前にお披露目された1.0は、「VS Code」をフォークしたエディタ機能を内包する、いわば「AIファーストのIDE（統合開発環境）」という体裁でした。ところが2.0では、そのエディタそのものを切り離し、エージェントのオーケストレーション専用のデスクトップアプリケーションへと再定義したのです。

　Googleは、好みのエディタ（VS Code、JetBrains、あるいは旧Antigravity IDE）とAntigravity 2.0を「二刀流」で併用するワークフローを公式に推奨しています。コードを書く場所としてのIDEは、もはやAntigravityの中にはありません。

　これは「IDE＝AI機能付きエディタ」から、「IDE＝エージェント群の指揮所」への再定義です。連載第6回で、私はAntigravityを「AI開発OS」と呼びました。エディタ、ターミナル、ブラウザという3つのサーフェスを統合し、AIエージェントがそれらを「アプリケーション」として呼び出す。IDEは中心ではなく、エージェントが目的を達成するための周辺ツールへと降格する、と書いたのです。

　正直に言えば、私は「降格」までは見えていましたが、「切り離し」までは予想していませんでした。1.0時点ではエディタを開けば直接タイピングもできましたから、IDEは降格しつつも残り続けると考えていたのです。2.0でエディタが外されたことは、「もはや開発者が手直しすることはない」という宣言にも見えます。

　ただ、現場の足元はそうきれいには進んでいません。米国の開発者コミュニティーでは、「強制アップデートで既存のAntigravity IDEが起動しなくなった」「共有クォータの統合で実質的に7日間ロックアウトされた」といった辛辣（しんらつ）な報告がHacker NewsやRedditにあふれています。製品としての完成度と、概念としての先進性は、いつの時代でも別の話です。新しい時代の幕開けを宣言するには少し残念な門出となったように思います。もしかしたら、Google I/Oに合わせるために、多少無理をした結果なのかもしれません。

WebMCPが「AX」を本流に押し上げる

　Web側の発表で目を引いたのが、「WebMCP（Web Model Context Protocol）」のChrome 149からのOrigin Trial（試験運用）開始です。これに合わせて、Webサイトを「AIエージェントが操作・参照しやすいか」という観点で評価する時代が来ることが、Google自身の口から語られました。

　連載第2回で、私はAIブラウザの構造的課題を論じました。AIエージェントがWebサイトを操作するとき、なぜスムーズに動かないのか。それはWebがそもそも「人間の視覚認知のため」に作られているからだ、というのが核心でした。AIに画面のピクセルを読ませても、DOMを読ませても、視覚的推測の壁にぶつかります。

　WebMCPは、その課題への1つの解です。Googleの説明によれば、Webサイト側がエージェント向けに「このページでできる操作」を、JSON Schemaを使ってツールとして宣言できる。例えば購入や検索といったJavaScript関数を明示的に登録しておけば、エージェントはDOMを画面上から推測するのではなく、サイトが提供した関数を直接呼び出せるようになります。

　HTMLフォームに属性を1つ足すだけで宣言できる仕組みもあり、開発者は chrome://flags/#enable-webmcp-testing を有効にすればローカルで検証を始められます。セキュリティ面では、ツールの登録範囲はデフォルトで同一オリジンに制限され、悪意あるクロスオリジンiframeからの不正登録は防がれる設計です。

　Antigravity 2.0もWebMCPをサポートしており、Google I/Oでは「Chrome側」と「エージェント基盤側」の両輪での推進が示された形です。スクレイピングが「クライアントが推測する」関係だとすれば、WebMCPは「サーバが提示する」関係になります。

　ここで重要なのは、WebMCPが「ある」ということではなく、それが意味することの大きさです。これまでのWebは「人間がブラウザを通して見るもの」が暗黙の前提でした。これからのWebは、人間とエージェントという2種類のクライアントを同時に相手にします。設計者は、その両方に対する応答性を、1つのコードベースから生み出す方法を見つけなければなりません。

　これは15年前のモバイル普及期によく似た構図です。あのときWebは「人間がデスクトップPCで見るもの」という前提が崩れ、画面幅という新しい軸でレスポンシブ設計を迫られました。今回はエージェントという、視覚を持たず意図を持つ新しいクライアントが、設計指標の軸をもう1本増やしている。UX（User Experience）に加えて「AX（Agent Experience）」という軸が生まれているのです。レスポンシブ設計が「メディアクエリと流動グリッド」を当たり前にしたように、AXは「エージェント向けのツール宣言」を当たり前にしていくのでしょう。

　なお、WebMCPとその周辺で議論されている技術については、私の個人ブログでも書いていますので、興味があれば読んでみてください。

マルチエージェントの並列実行が現実になった、ただし……

　キーノートで多くのエンジニアの度肝を抜いたのは、Antigravity 2.0がGemini 3.5 Flashと組み、12時間でOSのコアを構築したというデモでした。いや、私だけじゃないと思いたい。「AIでできないことはあるんです、例えばOSの開発とか……」と昨年何度言ったことか。

　このデモでは、93個の動的サブエージェントを並列稼働させ、26億トークンを処理した。APIコストは1000ドル未満。動作したOSの上で名作ゲーム「Doom」を動かそうとして、キーボードドライバが足りずに失敗しましたが、その場で「足りないドライバを書け」と指示すると、数分で書き上げて起動した。これはもう、技術デモというより、未来の風景を切り取った予告編でした。

　連載第7回で、私は『人月の神話』（The Mythical Man-Month）で知られるフレッド・ブルックス（Fred Brooks）のブルックスの法則を引いて、「人を増やすほど開発は遅くなる」というメカニズムを論じました。その根っこにあるのは、コミュニケーションコストの増大と、認知負荷の限界という人間特有の制約です。

　エージェントの世界では、この前提が同じようには成立しません。人間チームでは6人で15本、12人で66本と指数関数的に増えるコミュニケーション経路が、エージェント間では明示的なメッセージパッシングへと整理されます。認知負荷も、人間の頭ではなく、コンテキストウィンドウとトークン予算という別の制約に置き換わります。だから、人間チームではどう頑張っても無理だった「93人が同時に同じプロジェクトに取り組む」という形式が、エージェントの世界では現実的なオプションになるのです。

　とはいえ、人間特有の制約が消える代わりに、「オーケストレーションのコスト」「サンドボックス間の状態同期」「トークン予算の配分」といった、人間チームにはなかった種類の制約が新しく生まれてもいます。ブルックスの法則は消えるのではなく、別の語彙（ごい）で書き直されつつあるのかもしれません。

　もっとも、I/Oで提示された「93個」という数字に、私はもう少し興味があります。これが同時並列のピーク数なのか、12時間を通じた累計起動数なのか、平均的な並列数なのか。少なくとも私が確認できる範囲では、内訳は明らかにされていません。並列度の時系列推移、ピーク時の調整、サブエージェント間の競合や待ち時間。こうした情報が公開されれば、エージェントの並列実行を、もう少し解像度高く理解できるはずです。

　というのも、その内訳次第では、私自身の見方──ブルックスの法則はエージェントの世界でも形を変えて姿を現す、という私の持論──を改めなければいけないかもしれないからです。仮に93個が常時フル稼働していたのだとすれば、人間チームの限界を本当に突破した話として読み直す必要があります。逆に、実際に動いていたのは少数で、残りはアイドル時間が長かったのだとすれば、ブルックスの法則は形を変えて生きていると見るべきでしょう。派手な数字を派手なまま消費せず、内訳を確かめたい。これは、私が次に追いかけたい問いの一つです。