チャット欄からソフトウェア工場へ――Antigravity が変えようとしているのはモデルではなく、開発の進め方

「Antigravity を使ったことがある人は、手を挙げてください」

Antigravity の deep dive は、こんな問いかけから始まった。登壇したのは、Google に約 6 年在籍する Antigravity チームのシニア開発者リレーションズエンジニアだ。続いて会場では何度か挙手が求められた。Gemini を使ったことがある人、主に IDE の自動補完だけを使っている人、画面横のチャット欄をメインの作業場所にしている人、そして完全に CLI で動かしている人。その分布自体が、彼が話そうとしていた問題を指し示していた。多くの人はまだ、AI によるプログラミングを「より賢い対話相手」と捉えている。

彼の見立てはもう一段先にある。ひとつのチャットスレッドだけを見つめているのは、職人が作業台ひとつに張り付いているようなものだ。同時に進められるプロジェクトの数は、タイピングの速さ、レビューの速さ、そしてコンテキストを切り替えるたびに払うコストに縛られる。生産量を増やしたいなら、チャットをより熱心にこなしても意味がない。組織の仕方を変える必要がある。作業台ひとつから、並列の組立ラインへ。彼が「ソフトウェア工場」と呼んだのは、そのことだ。

モデルが強くなり、モデルを載せる「ハーネス」も強くなった

彼は転換点を昨年 12 月に置く。それ以降、モデルの更新は波のように続いた。まず Gemini 3 Flash、次に Gemini 3.1 Pro、さらに Gemini 3.8 Flash を含む Flash シリーズ全体。そして今は Gemini 4、Argon、Carbon がある。どの更新にも、より能力の高いエージェントフレームワークが伴っていた。

Antigravity チームはモデルチームや研究部門と非常に密に連携している。彼の言葉を借りれば、自分たちが「ハーネス」の層で下す判断はモデルに直接影響し、モデルの変化もまたハーネスの設計を変える。最近公表されたベンチマークでは、どの Gemini モデルも Antigravity の中で動かすほうが良い結果になるという。彼の提案は明快だ。以前 Antigravity の外で Gemini を使ったことがあるなら、最新バージョンでもう一度試してほしい。

この変化は開発インターフェースの形も変えた。初期のモデルはコードを書くこと自体にはかなり熟練していたが、複雑なシステムを扱うには厳しい監督、広範なガードレール、丁寧なコンテキストの範囲設定が必要で、そうしなければ意図しないファイルやディレクトリに書き込んでしまう恐れがあった。モデルとハーネスがともに成熟するにつれ、やり取りは行単位の自動補完から IDE のチャットへ、さらに専用のデスクトップ環境や CLI エージェント環境へと移ってきた。会場の挙手もこの分化を裏づけていた。補完だけで十分な人もいれば、横のチャット欄に張り付く人もいて、すでにすべてをコマンドラインに任せている人もいる。

Antigravity を昨年末に発表したとき、チームの目標のひとつは「エージェントファースト」の開発環境をゼロから作ることだった。このエンジニアは以前 Project IDX を支援し（その後 Firebase Studio に再編された）、Gemini CLI にも関わってきた。最近では Jules の多くの機能が Antigravity に統合されている。そこではいつも、各プロダクトが別のプロダクトにどう入力し、継続的な改善につなげるかという問いが繰り返されてきた。今年の Google I/O では、機能を 4 つの入口に分けた。メインアプリ、CLI、IDE 拡張、Python SDK だ。アプリの中で視覚的にタスクを組んでも、ターミナルからタスクを起動しても、背後にあるのは同じハーネスであり、結果も同じはずだという。

「ソフトウェア工場」は新しい比喩ではない。日本では半世紀以上前に試されていた

「ソフトウェア工場」という言葉は、実は現代の人工知能より何十年も早く、日本で現実のものになっていた。1969 年、日立は横浜に世界初のソフトウェア工場を開設し、1977 年には東芝が東京にソフトウェア工場を設けた。マサチューセッツ工科大学の教授が記録したように、日本の技術指導者たちはソフトウェア開発を孤立した職人技から、再現可能な学問へと変えた。再利用可能なコンポーネントを採用し、厳格な品質管理の仕組みを築いたのだ。

この歴史は、「チャット欄をいくつも開けば規模が拡大する」わけではない理由をよく説明している。職人の作業台は優れた製品を生めるが、生産量は一人の人間に縛られる。組立ラインが変えたのは分業、引き継ぎ、そして検査のやり方だ。Antigravity がやろうとしているのは、この 3 つをエージェント開発に持ち込むことにある。

第一歩：同期チャットを構造化された委任に置き換える

Antigravity でこの一歩を象徴する機能が /boost と /teamwork-preview だ。

/boost は、直線的な組立ライン上のサブエージェント群を調整する。タスクと、各「工程」の実行範囲を指定でき、結果を返す前に検証も行う。このエンジニアはよく Boost を Carbon や Argon と組み合わせ、時間が長く、コンテキストの圧縮をできるだけ抑えたいタスクを走らせている。

一方 /teamwork-preview は、専門的な役割を持つチーム全体を定義する。メンバー同士が提案し、批判し、互いの仕事を改善できる。チームは実行中に動的に調整される。50 以上のサブエージェントを起動することもでき、大量のトークンを消費するが、何時間も、ときには数日間、無人で走り続ける。彼のチームの多くはこれで「徹夜の会議」を開いている。退勤前に流れを起動し、翌朝にはレビューできる成果が揃っているという。

I/O のデモはこの規模の可能性を示した。Teamwork Preview と Flash モデルを使い、ゼロからオペレーティングシステムを構築したのだ。C++ をコンパイルして OS にし、なんと Doom を動かすところまで見せた。同じ方法で複数のライブラリの C++ 性能も最適化している。アルゴンヌ国立研究所での発表では、Fortran、COBOL、旧版 C++ で書かれたコードベースを現代の Rust へ移行し、メモリ性能の問題を解決して科学計算を現代のハードウェアで効率よく動かす方法についても語った。

タスクが長引くほど、人間がずっと見張ることはできない。Antigravity の Remote Control を使えば、任意のブラウザからワークステーションに接続できる。さらに重要なのは、通知をスマートフォンや時計に送れることだ。今やモデルが結果を返すまでに 1 時間半から 3 時間かかることもある。権限の確認を承認するとき、あるいは方向が違うと気づいて軌道修正するときだけ、人間が現れればよい。彼の言い方を借りれば、「議会」が判断を求めたときだけ介入する、ということだ。

第二歩：「手動での起動」さえも外す

チャットから委任へ移ることは、工場に流れ作業を持ち込むことに等しい。しかし流れ作業でも、材料を運び、開始ボタンを押す人が要る。次の一歩は、手動の呼び出しをなくすことだ。

Antigravity には cron スケジュールで動く定期タスクと自動化フローがある。設定も簡単になった。@automation コマンドをひとつ使えば、セットアップを済ませてくれる。自動化に向いているのは、毎日繰り返している作業だ。夜間のエラーレポートの分類、ベンチマークの分析、依存関係の監査。あるいは、ノート PC を開く前に動き始めている能動的なエージェントを作ることもできる。

スケジュールだけでなく、.agents/hooks.json には宣言的な JSON フックも用意されている。バックグラウンドのサイドカーがライフサイクルとイベントを監視し、コードを自動検証してラインを起動する。イベントが起きた瞬間に、工場の現場が動き出すわけだ。サイドカーをまだ使ったことがないなら、必要なときに Antigravity を呼び出す webhook のような仕組みだと考えればよい。

自働化――ラインが止まるべきときに、自分で止まる

本当のソフトウェア工場になるには、材料を一方から入れ、完成品を他方から出す仕組みが要る。トヨタ生産方式の「自働化（Jidoka）」は「人の介入を伴う自動化」と訳されることが多い。その原点は 1924 年の自動織機だ。

それ以前、織機は 1 台につき 1 人の作業者がつきっきりで見守る必要があった。糸が 1 本切れるだけで、大量の布が不良品になりうるからだ。監督されない AI にも似た危険がある。大量のコンテキストやトークンが、無関係な情報や誤った方向に浪費されかねない。その織機が違ったのは、糸が切れると自分で止まったことだ。その結果、1 人の作業者が 40 台の織機を同時に見られるようになった。

トヨタは後にこの考え方を 4 つの手順に広げた。異常を即座に見つける。綱を引いてラインを止め、不良が下流に流れるのを防ぐ。目の前の問題を直す。そして、同じ誤りが再発しないようポカヨケを施す。

Antigravity は同じ原則を開発プロセスに組み込もうとしている。作成したどのラインにも、.gemini/brain フォルダが背後にある。チャット履歴、操作手順のドキュメント、独立した Git ワークツリーの完全な JSON トレースが残り、すべてが自動的に永続化される。このディスク上の状態があるからこそ、進捗を失わずにワークフローを止め、切り替え、再開できる。割り当てを使い切ったとき、モデルを替える必要が出たとき、あるいは壊れた箇所を直したいときにも、きれいに一時停止できる。

この仕組みは Alphabet 社内ですでに実績がある。彼の説明によれば、社内の Antigravity 環境では 10 万人を超える月間アクティブユーザーが Gemini 4 Argon を使っており、エージェントが書くコードは 35% 増え、投稿後のロールバックは 30% 減った。検証を生産フローに直接組み込んだことで、全体の生産速度は上がり、不良率は下がったという。これは独立した監査ではなく社内統計だが、ひとつのことを示している。ラインの価値は「速い」ことだけではなく、各工程が検証可能で、巻き戻せることにある。

ラインを組む 5 つのステップ

彼は Antigravity でソフトウェア工場を組む手順を 5 つに分けた。中心となる部品は、カスタムサブエージェント、スキル（Skills）、プラグインだ。

第一に、作業の基盤を定義する。 置き場所は .agents/agents だ。Markdown ファイルとカスタムサブエージェントで振る舞いを完全に定義できる。アクセスできる MCP サーバーとツールを限定し、実行環境のポリシーを定め、サブエージェントごとに使うモデルまで指定できる。これにより、多数のサブエージェントを用意しておき、実際に呼ばれたときだけコンテキストを読み込ませることも可能になる。実行時、これらの基盤はそれぞれ独立した Git ワークツリーで並行して動き、動的なモデル選択、範囲を絞ったサンドボックス、リアルタイムの状態追跡を備える。

第二に、Skills で手順を標準作業書にする。 置き場所は .agents/skills だ。ラインは、どの作業者を直接呼ぶのか、どの順番で呼ぶのか、独立したワークツリー間でいつどう引き継ぐのかを定める。次に進む前に必要な調査・定義の材料は何か、最終的にどの成果をレビューし要約するのかも決める。

第三に、読み取り専用の検査員を加える。 読み取り専用のカスタムサブエージェントで、システム内で起きていることをすべて監査する。セキュリティ検査、アクセシビリティの監視、ポリシーの強制に向いている。彼は別の用途でも好んで使う。サブエージェントが行き詰まったとき、あるいは誤ったコンテキストへ流れようとしているとき、この「検査員」に状況を管理させるのだ。Google のいくつかのチームは、この機能をプラグインとしてすでに提供している。Flutter チームのアクセシビリティ検査、Firebase ルールの検査、そして Google Play の提出前レビューだ。

第四に、移植可能なプラグインにまとめる。 工場のメインエージェント、サブエージェント、スキル、検査員をひとつの Antigravity プラグインに統合すれば、チーム全体でバージョン管理し、どこでも実行できる。プラグインマーケットの拡大も発表された。

第五に、自動化の入口をつなぐ。 材料が届いたらメインエージェントが自動で起動するようにする。GitHub で新しい issue が立ったとき、毎日の定時タスク、webhook、あるいは NAS 上の監視フォルダでもよい。そうすれば CI パイプラインが動き、最後に検証済みのプルリクエストとドライランの成果物を届けてくれる。

ラインの実行中、検査員が問題を見つけると生産を一時停止し、すぐに損害を食い止め、その改善をエージェント、スキル、ワークフローに反映して、次のラインをより賢くする。本当のアーキテクチャ上のトレードオフが必要なときは、スマートフォンのリモートコントロールから介入できる。これはますます重要になる。これらのシステムが自己修復と継続的改善の能力を強めているからだ。

いちばんリスクの低いところから始める

どこから手をつければいいか分からないなら、彼の助言はこうだ。再現可能で、検証できて、リスクの低い作業をひとつ選び、まずそれをラインにする。

彼自身の例は「古いコードを消すこと」だった。iOS、Android、Web の API を調べ、すでに時代遅れになった polyfill や使われなくなった API を見つけるシステムを組んだ。Web 開発の経験が長い彼には、こうした整理の価値がよく分かっている。コードベースを常に最先端に保ち、人間はチャットエージェントを本当に探索が必要な新しい技術に残しておけるからだ。

これがこのセッションの中心にある転換だ。対話の 1 ターンごとを管理するのをやめ、ラインを設計し、判断が必要なところにだけ入る。ソフトウェア工場の要点は「無人化」ではない。各工程を検証可能にし、止められ、再開できるようにすることにある。そうして初めて、規模の拡大は同じ作業台を何個も複製することではなく、生産のやり方そのものを変えることを意味する。