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

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

　内訳がどうあれ、これを「人間チームの代替が可能になった」と短絡的に理解してはいけません。並列化が成立するためには、タスクが互いに独立しているか、明確なインタフェースで切り分けられている必要があります。OSのコア構築のように、メモリ管理、ファイルシステム、スケジューラと、教科書のようにきれいに分解できる課題なら、93個に切り分けやすい。

　しかし、現場で出会う仕事はそうきれいには分解できないのではないでしょうか。ユーザーの曖昧な要望を仕様に翻訳する作業、レガシーコードを読み解きながらの段階的なリファクタリング、ステークホルダーの優先順位調整。こうした作業は、独立して並列化できる単位に切り分けるところで、既に人間の認知労働を要求します。並列に動くことと、チームとして動くことは、似ているようで違うのです。キーノートでのデモは、エージェントが何を可能にしたかは見せてくれましたが、それを現場の課題に当てはめるためには、私たち側の「分解の技術」がもう一段必要になります。

Markdownは「最も熱い言語」か、それとも「契約書」か

　Antigravity 2.0では、エージェントのスキルや指示を AGENTS.md というMarkdownファイルで定義します。コードを書く代わりに、Markdownで意図を書く。Googleの開発者向け責任者の1人、ローガン・キルパトリック（Logan Kilpatrick）氏はGoogle I/Oで、「正直なところ、今最も熱いプログラミング言語はMarkdownだ」と発言しました。スローガンとしてはよく効きます。

　ただ、ここで私は少し立ち止まりたいのです。Markdownは構文を持ちますが、意味論（セマンティクス）はモデル側にあります。同じ AGENTS.md を別のモデルに読ませれば、別の解釈で動きます。これは厳密な意味でのプログラミング言語というよりは、「人間と機械の間で交わされる契約書」と呼ぶ方が、実態に近いように私には感じられます。

　契約書だと考えると、幾つかのことがすっと納得できます。なぜ書き方の流儀が定まらないのか。なぜ同じ指示でモデルや時期によって挙動が変わるのか。なぜレビューやテストが必要なのか。

　プログラミング言語であれば、文法エラーがあればコンパイラが叱ってくれます。一方、契約書では、解釈のずれが後から問題になり、当事者間で擦り合わせるしかありません。Markdownを「言語」と呼ぶ高揚感は分かりますが、現場で扱うときは「契約書」だと思っておいた方が、誤読を減らせるのではないでしょうか。

　最近、「MarkdownよりもHTMLの方がいい」という言説があります。確かに、HTMLの方がコンテキストを言語化しやすいです。もしかしたら、エージェントへの指示書としてHTMLベースで標準化が進んでいくこともあるかもしれません。

24時間稼働するエージェントと、「見えなさ」の深化

　もう一つ強く印象に残ったのが、Google Cloud上で常時稼働するパーソナルエージェント「Gemini Spark」です。朝、ラップトップを開くと、Sparkは昨夜のメールスレッドを要約し、今日の会議の事前資料をピン留めし、今日私が判断するための材料を、寝ている間に整え終えている。そんな日常が、すぐそこにあります。これはもう「タスクを依頼する」というより、「肩越しに仕事を投げっぱなしにする」感覚です。

　連載第4回で、私はAIエージェントを「同僚」と呼ぶことの危うさを論じました。擬人化はチームを静かに壊していく、と書きました。Sparkを見ていると、その擬人化のわなが、より柔らかな形で日常に深く入り込もうとしているのを感じます。「同僚」と呼ぶか「道具」と呼ぶか──その線引きの問いは、解消されるどころか、ますます切実になっていきます。

　もう一つ重なるのが、可観測性（オブザーバビリティー）の問題です。Sparkが24時間、裏で動くということは、私たち人間が画面の前で見届けていない時間が、それだけ増えるということでもあります。さらに、93個のサブエージェントが並列で別のサンドボックスで動けば、何がどう動いたかを後から再現するのは、急激に難しくなります。エージェント数が増えれば、追跡すべき呼び出しグラフは二乗のオーダーで広がり、その上に並列実行のタイミングや共有ステートの遷移が組み合わせ的に重なってきます。原因を1つ突き止めようとして、呼び出し関係をたどり、トークン予算の配分を見て、状態遷移を追って──と作業はみるみる拡散していきます。

　「見えなさ」の問題は、エージェントが普及することで解消されたのではなく、むしろ深化しているのです。透明度の高い1台のエージェントよりも、不透明な100台のエージェントの方が、圧倒的に強い成果を出してしまう。それが現実ではあります。Sparkは人間が見ていない時間を増やし、サブエージェントの並列実行は人間が見届けられる解像度を下げる。両者は、「見えなさ」という同じ現象を今後顕在化させていくのではないかと予想します。これが危惧ではなく、杞憂（きゆう）だったとなることを祈ります。

「進んだ」ことと「成った」ことは違う

　ここまで、私が選んだGoogle I/Oにおける6つのテーマを見てきました。CLIが主役になり、Antigravityがエディタを外し、WebMCPがブラウザに入り、マルチエージェントの並列実行が現実になり、Markdownがエージェントを動かし、24時間稼働のエージェントが日常に入ろうとしている。エージェント時代のソフトウェア開発は、確実に「進んだ」と言える状況です。

　しかし、「進んだ」ことと「成った」ことは違います。両者の違いには、2つの軸があるように思います。

　1つは、進歩の傍らで何かが失われる、という軸です。CLIが主役になったこととGemini CLIが廃止されたこと。Antigravityが進化したこととエディタが切り離されたこと。進歩は、それまで馴染んできた何かとの別れを伴います。

　もう一つは、機能が動くことと、その機能が概念として成り立つことは別だ、という軸です。WebMCPがブラウザに入ることと、Webサイトが「AX」に応答するようになることは別。マルチエージェントが動くことと、それを「チーム」と呼べることは別。Markdownでエージェントを書けることと、それが「言語」になることは別。AIが24時間動くことと、それを「同僚」と呼べることもまた別なのです。

　今年のGoogle I/Oが示したのは、エージェント時代の輪郭です。輪郭は鮮明になりましたが、その中身を埋めていくのは、これからの私たちエンジニアの仕事です。「派手な発表」と「現場で機能する設計」の間には、まだ距離があります。

　エンジニアとして見極めるべきは、次のような問いでしょう。自分の現場で、どのタスクをエージェントに切り出せるのか。どこまでをエージェントに任せ、どこからを人間が判断するのか。AGENTS.md という契約書を、どうレビューし、どうメンテナンスするのか。見えない時間が増えていく中で、どう可観測性を確保するのか。Google I/Oの発表は答えではなく、こうした問いを立てるための材料です。われわれは、その距離を縮めていく作業を、急がず、ただし手を止めず、続けていく必要があるでしょう。