Google I/O 2026のブログ記事を読んで、ちょっと面白いなと思った。
ステージで発表するAIを、そのイベント自体の制作にも使ったという話だ。
クラゲのプレショーや「TPU Training Day」という映像コンテンツも、Geminiを使ってプロトタイプを回しながら作ったらしい。
「out-innovate, out-create, out-efficient ourselves」という表現が印象に残った。
要するに「ドッグフーディング」なんだけど、あの規模でそれをやり切ったのはえぐい。
普通のプロダクトチームがInternalでツールを使うのとは話のスケールが違う。
マーケのVPが書いた記事なのに、「AI tools are getting better each month, effectively rewriting the rules of what we can create」という文が出てくる。
これ、エンジニアじゃない人間が書いてる文章として結構リアルだと思った。
自分の話に引きつけると、最近個人開発でGemini 2.5 ProのAPIを触り始めている。
コンテキストウィンドウが1Mトークンあるので、でかいコードベースをそのままぶち込める。
試しに自分のサイドプロジェクト(約8,000行のTypeScriptモノレポ)を全部渡してリファクタ指示を出したら、依存関係のグラフを正確に読んでくれた。
Claude 3.5 Sonnetと比べてコンテキスト圧縮の挙動が違うので、長いやりとりでの劣化の仕方を今観察中だ。
ブログに「prototyped in real-time」という表現が何度か出てくる。
これが具体的にどういう意味か気になって少し考えた。
おそらくコンテンツの絵コンテや演出案をGeminiに投げて、その場でバリエーションを出して選定していく、というフローだと思う。
デザイナーとAIが並走しながら成果物を収束させていくやつだ。
これはコードの世界でも同じ構造だと感じている。
自分はPRを出す前に、差分をGemini APIに流してコードレビューコメントを自動生成する小さなスクリプトを書いた。
ざっくりこんな感じ。
`repo_summary.md` にはディレクトリ構成とアーキテクチャの概要を書いている。
これを渡すことで「このプロジェクトではDIコンテナにInversifyを使っている」とか前提を毎回説明せずに済む。
トークン消費は1回あたり大体2〜4万トークンで、Gemini 2.5 Proだとinputが$1.25/1Mトークンなので1回数円レベル。
CIに組み込んでも月のコストは全然許容範囲に収まっている。
このスクリプトを作るときに一番ハマったのが、system instructionの書き方だった。
最初は「バグを探してください」みたいなふわっとした指示を書いていた。
そうすると毎回コメントの粒度が変わって、使い物にならなかった。
今はこんな形式で出力を固定している。
structured outputとしてJSON schemaを渡す方法もあるんだけど、yamlでsystem promptに書いた方が今のところ安定している。
Geminiはformat指定への追従がかなり素直な印象で、これは普通に神だと思っている。
GoogleがI/Oというイベント全体をAIで作り直した、という話の受け取り方は人によって違うと思う。
自分はどちらかというと、あのスケールの現場で「とりあえず動かしてみた」が通用するようになってきた、という事実の方に反応している。
半年前には試せなかった使い方が今は普通に試せる。
自分の手元のスクリプトも、今後モデルが変わったらどこを直すか、そっちをずっと考えている。
ステージで発表するAIを、そのイベント自体の制作にも使ったという話だ。
クラゲのプレショーや「TPU Training Day」という映像コンテンツも、Geminiを使ってプロトタイプを回しながら作ったらしい。
「out-innovate, out-create, out-efficient ourselves」という表現が印象に残った。
自分たちのツールで自分たちを作る、という発想
要するに「ドッグフーディング」なんだけど、あの規模でそれをやり切ったのはえぐい。
普通のプロダクトチームがInternalでツールを使うのとは話のスケールが違う。
マーケのVPが書いた記事なのに、「AI tools are getting better each month, effectively rewriting the rules of what we can create」という文が出てくる。
これ、エンジニアじゃない人間が書いてる文章として結構リアルだと思った。
自分の話に引きつけると、最近個人開発でGemini 2.5 ProのAPIを触り始めている。
コンテキストウィンドウが1Mトークンあるので、でかいコードベースをそのままぶち込める。
試しに自分のサイドプロジェクト(約8,000行のTypeScriptモノレポ)を全部渡してリファクタ指示を出したら、依存関係のグラフを正確に読んでくれた。
Claude 3.5 Sonnetと比べてコンテキスト圧縮の挙動が違うので、長いやりとりでの劣化の仕方を今観察中だ。
「プロトタイプをリアルタイムで回す」の解像度
ブログに「prototyped in real-time」という表現が何度か出てくる。
これが具体的にどういう意味か気になって少し考えた。
おそらくコンテンツの絵コンテや演出案をGeminiに投げて、その場でバリエーションを出して選定していく、というフローだと思う。
デザイナーとAIが並走しながら成果物を収束させていくやつだ。
これはコードの世界でも同じ構造だと感じている。
自分はPRを出す前に、差分をGemini APIに流してコードレビューコメントを自動生成する小さなスクリプトを書いた。
ざっくりこんな感じ。
git diff main...HEAD | \
python review.py --model gemini-2.5-pro --context repo_summary.md`repo_summary.md` にはディレクトリ構成とアーキテクチャの概要を書いている。
これを渡すことで「このプロジェクトではDIコンテナにInversifyを使っている」とか前提を毎回説明せずに済む。
トークン消費は1回あたり大体2〜4万トークンで、Gemini 2.5 Proだとinputが$1.25/1Mトークンなので1回数円レベル。
CIに組み込んでも月のコストは全然許容範囲に収まっている。
ハマったのはsystem instructionの設計
このスクリプトを作るときに一番ハマったのが、system instructionの書き方だった。
最初は「バグを探してください」みたいなふわっとした指示を書いていた。
そうすると毎回コメントの粒度が変わって、使い物にならなかった。
今はこんな形式で出力を固定している。
format:
- severity: [critical / warning / suggestion]
- location: ファイルパス + 行番号
- reason: 技術的な根拠
- suggestion: 修正案のコード断片structured outputとしてJSON schemaを渡す方法もあるんだけど、yamlでsystem promptに書いた方が今のところ安定している。
Geminiはformat指定への追従がかなり素直な印象で、これは普通に神だと思っている。
GoogleがI/Oというイベント全体をAIで作り直した、という話の受け取り方は人によって違うと思う。
自分はどちらかというと、あのスケールの現場で「とりあえず動かしてみた」が通用するようになってきた、という事実の方に反応している。
半年前には試せなかった使い方が今は普通に試せる。
自分の手元のスクリプトも、今後モデルが変わったらどこを直すか、そっちをずっと考えている。