Google I/O 2026 を受けてタイムラインが賑やかだった。
Search Agents とか Generative UI in Search とか、聞いたことないキーワードが一気に増えた。
とりあえず記事を読んでみたら、思ったより深い話だった。
まず驚いたのが、検索ボックスが 25 年ぶりに刷新されるというところだ。
テキストだけじゃなく、画像・音声・ファイルのマルチモーダル入力に対応する「intelligent Search box」になるらしい。
それ自体はまあそうなるよね、という感じだけど、問題は AI mode に Gemini 3.5 が積まれること。
MAU が 10 億人超えの AI mode をそのまま最新モデルに切り替えるとは、Googleのインフラ規模えぐいとしか言いようがない。
もう一個気になったのが Search Agents だ。
ユーザーが「この条件を満たす情報が出たら教えて」と設定しておくと、エージェントが Web・SNS・フォーラムを自動監視して、ヒットしたらプッシュ通知してくれる。
自分の仕事に引きつけると、「特定の OSS に脆弱性が出たら即通知」みたいなユースケースで使えそうだ。
今は GitHub の Dependabot と RSS リーダーを組み合わせて対応しているけど、Search Agents がそのへんを根こそぎ代替してくるかもしれない。
一番テンション上がったのが Generative UI in Search という機能だ。
検索結果の上にミニアプリを自動生成してくれる、らしい。
バックエンドは Anti-Gravity というエージェントプラットフォームで、Gemini 3.5 Flash のコーディング機能を使って UI を構築するという。
正直、最初読んだとき「それ自分のプロダクトを検索結果の上に置かれたら普通にやばい」と思った。
たとえば旅行の日程調整ミニアプリが検索結果に出てきたら、ユーザーは自分のサービスを開かずにそこで完結してしまう。
SEO どうこうのレベルじゃなくて、サービスのエントリーポイント設計から見直しが必要になる話だ。
彼女と先週話していたとき、「最近 Google で調べても広告ばっかだよね」と言ってた。
ユーザー目線ではむしろ Generative UI みたいな形のほうが嬉しいのかもしれない。
だとすると、エンジニアとしては「検索経由のトラフィックをどう設計し直すか」が切実な問いになる。
現状の自分のプロダクトを確認してみた。
OGP・structured data・sitemap の整備が甘いページが複数ある。
具体的には以下あたりが放置されている。
Generative UI in Search がどの粒度でコンテンツを読み取るかはまだわからない。
だけど Gemini が検索結果を構造化するなら、マークアップが整っているほうが有利に決まっている。
とりあえず直せるところから直す。
Search Agents についても、自分でも似たような監視ロジックを書いたことがある。
Webhook と cron で組んだ簡易クローラーだ。
Search Agents が一般公開されたとき、そのコードは完全に用途を失うかもしれない。
それはそれで「ちゃんと問題を解決できていた証拠」として受け取ることにした。
キャリアの文脈では、LLM エージェントの設計力が今後もっと差になってくると感じる。
Search Agents が一般化した世界でも、エージェントに何をさせるかを設計できる人間の価値は落ちない。
プロダクトのエントリーポイントが変わるなら、それに合わせた API 設計・Webhook 設計を考えておくのが先手だ。
まず今週中に structured data を入れ直す。
そこから先は、Search Agents の公開を待ちながら自分なりのユースケースを試すつもりだ。
Search Agents とか Generative UI in Search とか、聞いたことないキーワードが一気に増えた。
とりあえず記事を読んでみたら、思ったより深い話だった。
25年ぶりに検索ボックスが変わるらしい
まず驚いたのが、検索ボックスが 25 年ぶりに刷新されるというところだ。
テキストだけじゃなく、画像・音声・ファイルのマルチモーダル入力に対応する「intelligent Search box」になるらしい。
それ自体はまあそうなるよね、という感じだけど、問題は AI mode に Gemini 3.5 が積まれること。
MAU が 10 億人超えの AI mode をそのまま最新モデルに切り替えるとは、Googleのインフラ規模えぐいとしか言いようがない。
もう一個気になったのが Search Agents だ。
ユーザーが「この条件を満たす情報が出たら教えて」と設定しておくと、エージェントが Web・SNS・フォーラムを自動監視して、ヒットしたらプッシュ通知してくれる。
自分の仕事に引きつけると、「特定の OSS に脆弱性が出たら即通知」みたいなユースケースで使えそうだ。
今は GitHub の Dependabot と RSS リーダーを組み合わせて対応しているけど、Search Agents がそのへんを根こそぎ代替してくるかもしれない。
Generative UI in Search が個人開発にも刺さる
一番テンション上がったのが Generative UI in Search という機能だ。
検索結果の上にミニアプリを自動生成してくれる、らしい。
バックエンドは Anti-Gravity というエージェントプラットフォームで、Gemini 3.5 Flash のコーディング機能を使って UI を構築するという。
正直、最初読んだとき「それ自分のプロダクトを検索結果の上に置かれたら普通にやばい」と思った。
たとえば旅行の日程調整ミニアプリが検索結果に出てきたら、ユーザーは自分のサービスを開かずにそこで完結してしまう。
SEO どうこうのレベルじゃなくて、サービスのエントリーポイント設計から見直しが必要になる話だ。
彼女と先週話していたとき、「最近 Google で調べても広告ばっかだよね」と言ってた。
ユーザー目線ではむしろ Generative UI みたいな形のほうが嬉しいのかもしれない。
だとすると、エンジニアとしては「検索経由のトラフィックをどう設計し直すか」が切実な問いになる。
自分のコードのどこを直すか
現状の自分のプロダクトを確認してみた。
OGP・structured data・sitemap の整備が甘いページが複数ある。
具体的には以下あたりが放置されている。
- article ページに schema.org の Article マークアップなし
- 動的ページの meta description が空のまま
- sitemap の lastmod が更新されていない
Generative UI in Search がどの粒度でコンテンツを読み取るかはまだわからない。
だけど Gemini が検索結果を構造化するなら、マークアップが整っているほうが有利に決まっている。
とりあえず直せるところから直す。
# structured data のバリデーションを手元で走らせる例
npx schema-dts-gen --url https://example.com/article/1Search Agents についても、自分でも似たような監視ロジックを書いたことがある。
Webhook と cron で組んだ簡易クローラーだ。
Search Agents が一般公開されたとき、そのコードは完全に用途を失うかもしれない。
それはそれで「ちゃんと問題を解決できていた証拠」として受け取ることにした。
キャリアの文脈では、LLM エージェントの設計力が今後もっと差になってくると感じる。
Search Agents が一般化した世界でも、エージェントに何をさせるかを設計できる人間の価値は落ちない。
プロダクトのエントリーポイントが変わるなら、それに合わせた API 設計・Webhook 設計を考えておくのが先手だ。
まず今週中に structured data を入れ直す。
そこから先は、Search Agents の公開を待ちながら自分なりのユースケースを試すつもりだ。