Gemini Lab の廣川政樹です。
5月の第4週が終わりました。Google I/O 2026 の発表ラッシュの直後ということもあり、今週は「華やかな新機能の解説」ではなく、本番のアプリで何ヶ月も動かし続けるための、地味で大事な設計の話に自然と引き寄せられた週でした。
振り返ると4つの軸に整理できます。本番安定運用の設計（サーキットブレーカー・縮退・スキーマ進化・継続監視）、累計5,000万DLの壁紙アプリ6本での実装（Crashlytics 自動分析、AdMob 連携、レビュー解析、リリース日のコードレビュー）、Gemini Computer Use と Claude in Chrome の試運転（AdMob 管理画面を1週間自動操作した所感）、そして 小さな本番事故と現実的な対処（ストリーミング・スキーマ enum・MALFORMED_FUNCTION_CALL・Deep Research 停止）。新機能を追いかける週ではなく、「3ヶ月後も動いていてほしい」設計を書き残した週でした。
軸①：本番安定運用の設計 — 落ちないための地味な装備
今週いちばん時間をかけて書いたのが Gemini API にサーキットブレーカーと段階的縮退を組み込む — 個人アプリの安定運用に効く設計の所感 です。Gemini API がレイテンシ的にぐらつく時間帯は、12ヶ月間運用していると確実にあります。Closed → Open → Half-Open の3状態と、4段階の縮退（フルレスポンス → 簡略レスポンス → キャッシュ → 完全停止）を組み合わせると、ユーザーから見て「APIが死んでいる」体験を相当抑えられる、という設計の話を書きました。p95 を見ながら段階を切り替えるアイデアは個人開発でも十分機能します。
スキーマ側では Gemini API 構造化出力スキーマを本番アプリで安全に進化させる設計記録 がいちばん設計に時間がかかった記事でした。バージョン1.0 のスキーマでリリースした構造化出力を、運用しながら 1.1、2.0 へ進化させる必要が出てきたとき、何も考えずに変えるとクライアントが一斉に壊れます。Internal IR と公開スキーマを分離し、Dual-Emit 期間を挟んでから Sunset する、という設計パターンを Python の互換性チェッカーごと書きました。
監視側では Gemini API の出力品質を継続監視する評価基盤の設計 を書きました。Gemini 2.5 Pro はモデル更新のたびに少しずつ挙動が変わるので、ゴールデンデータセットと LLM-as-judge を組み合わせて週次で品質を測る仕組みがあると、サイレントな品質低下に気づけます。私のところでは月 ¥4,200 ほどで動いていて、過去には 2.4%・47% の劣化を実際に検知できました。「壊れてから気づく」のは、12年個人開発を続けてきた中でいちばん避けたいパターンです。
asyncio 並列化の本番パターンを書いたのが Gemini API asyncio 非同期処理の本番パターン——並列リクエストで処理時間を1/5に短縮した実装記録 です。asyncio.gather を素朴に並べるだけだと、Gemini 側のレート制限と DLQ 設計を破ったときに被害が大きくなります。セマフォ + リトライバジェット + バックプレッシャーの組み合わせを、個人開発の規模でちゃんと回す形に落として書きました。
軸②：6アプリ並行運用 × Gemini — 5,000万DLの現場で動かす
私は2014年から個人開発でアプリ事業を続けていて、現在は壁紙系・癒し系・引き寄せ系を中心に6本のアプリを iOS / Android で並行運用しています。今週はその現場に Gemini を組み込む話を集中的に書きました。
Firebase Crashlytics のクラッシュログを Gemini API で自動分析した記録 — 個人開発アプリ v2.1.0 での実証 は、Android 版 v2.1.0 のリリース直後に Crashlytics のクラッシュを Gemini に分類・要約させたパイプラインの話です。Glide 5.0.5 × AGP 9.x の Java 8 Supplier NoClassDefFoundError を、原因クラスタとして自動でまとめてくれたときは「朝の通知1つで原因が見える」ありがたさを実感しました。
AdMob 側では Gemini 2.5 Pro × AdMob 週次フロアプライス候補出力パイプラインの設計と運用 と Gemini API × 多アプリポートフォリオ用コントロールプレーン設計 — Firebase Remote Config + Cloudflare Workers 構成 の2本で、収益最適化と運用の話をまとめました。AdMob メディエーションの eCPM を週次の CSV から Gemini に渡してフロアプライス候補を Function Calling で構造化出力させる構成は、6アプリそれぞれを手で見ていた時間を一気に削ってくれました。
レビュー側は Gemini Batch API で8,000件のアプリレビューを一晩で分類した実装メモ と、その伏線として書いた App Store / Google Play のレビュー返信を Gemini API で自動化したときにはまった「8秒ルール」 が対になっています。8,000件のレビューを Batch API で一晩で分類できると、月初の運用判断がだいぶ楽になります。一方で App Store 側は連投すると弾かれるので、各送信間に約8秒の待機を挟むという地味な作法を守る必要があります。両方を書いてようやくレビュー運用がまわるようになりました。
メタデータ生成では Gemini API で iOS/Android アプリのメタデータを30言語自動生成した実装 — Beautiful HD Wallpapers の多言語化で気づいたこと を書きました。30言語に展開するときの「文字数制限・禁則語・iOS と Google Play のローカライズ仕様の差」をプロンプトに織り込むまでに、Beautiful HD Wallpapers の現場で何度かやり直しています。
リリース日の話は今週火曜のブログ記事 Android アプリのリリース日に Gemini 3.2 でコードレビューを通したら、Glide のクラッシュが一行で消えた話 に書きました。coreLibraryDesugaringEnabled true の1行追加で Android 6.0.1 ユーザー全員のクラッシュが消えた、というのは Gemini のコードレビューがなければ気づくのにもっと時間がかかったと思います。同じ流れで Gemini API で git log から日英リリースノートを自動生成した — Beautiful HD Wallpapers v2.1.0 での実装記録 も今週の運用記録です。
軸③：Gemini Computer Use と Claude in Chrome を試運転した1週間
今週いちばん「新しいことを試した」記事が Gemini Computer Use と Claude in Chrome を AdMob 管理画面で1週間比較した所感 です。
AdMob 管理画面の操作は今まで「画面構成が変わるたびにスクリプトが壊れる」前提で半分手作業に戻していました。今週は Gemini Computer Use と Claude in Chrome の両方で1週間動かしてみて、「どちらが何に向くか」「どちらも詰まる場面はどこか」を実機で確かめました。広告ユニットの編集のような視覚的に確定できる操作には強い一方、メディエーション設定の細部のような「画面が階層化されているところ」はまだ人の補助が要る、というのが正直な結論です。
長文の検証も書きました。Gemini 2.5 Pro の 1M コンテキストを実運用で2ヶ月使ってわかった、向く作業と向かない作業 は、Beautiful HD Wallpapers の Android プロジェクト全体を 1M コンテキストに流し込んで2ヶ月使った所感です。「広く眺める作業」には強く、「狭く深く詰める作業」には別の作戦を組んだ方がよい、というのが現時点の整理です。
Apple Privacy Manifest 側は Gemini 2.5 Pro × Apple Privacy Manifest — 個人アプリ4本で1ヶ月運用した所感 で iOS 4本の運用記録をまとめました。Privacy Manifest の差分チェックを Gemini に任せられるようになると、月次の運用負荷がかなり違ってきます。
Files API × R2 構成では Gemini Files API × Cloudflare R2 で画像処理パイプラインを設計した を書きました。Files API は48時間でファイルが消える前提なので、R2 を一次保管にして Files API を二次の処理用に使い分ける構成にしています。再アップロードコストを月 ¥3,000 台に抑えるレート制御と、ハッシュキーでの冪等性が要点です。
そして Gemini 3.2 Flash の Image Output で壁紙アプリの色違いバリエーション生成パイプラインを設計した実装メモ — Imagen 4 との使い分けと月額APIコストの実測 は、Gemini 3.2 Flash の Image Output と Imagen 4 を役割分担させて月額 API コストを 40% 圧縮した実測の話です。
ワークフロー側では Gemini API × Cloud Pub/Sub によるイベント駆動 AI ワークフロー設計 — 個人開発者の実装メモ と Gemini 2.5 Flash × Firebase Remote Config で多言語オンボーディングを段階公開する設計 を書いて、Pub/Sub と Remote Config を使った段階公開・冪等性・DLQ の組み立てを整理しました。
軸④：小さな本番事故と現実的な対処 — トラブルシュート4本
新機能の話と並行して、今週は「実際にぶつかった本番事故」をそのまま記事にした4本があります。
Gemini API のストリーミングが本番だけまとめて返ってくる — Cloud Run・Vercel・Cloudflare のバッファリング対処 は、ローカルでは動いているストリーミングが本番だけ「全部終わってから一気に返ってくる」現象の話です。プラットフォーム別のバッファリング挙動を1つずつ切り分けています。
responseSchema の enum 指定なのに違う文字列が返る — Gemini API で起きる原因と回避策 は、構造化出力で enum を指定したのに範囲外の文字列が返ってきた本番事故をそのまま書いた記事です。Gemini API で MALFORMED_FUNCTION_CALL が返ってくるときの原因と対処 と合わせて、構造化出力まわりで「動いていたのに動かなくなった」ときの初動として読んでいただけたらと思います。
そして Gemini Deep Research が長時間ジョブの途中で止まる — 5つの原因と切り抜け方 は、Deep Research を長時間動かす運用に踏み込んだ方なら一度はぶつかる「中途半端な停止」の整理記事です。Gemini API の seed を指定しても出力が変わる原因と現実的な対処（壁紙アプリ自動分類の実例） も同じ系統の「期待通りに決まらない」話で、私のところでは壁紙アプリのカテゴリ自動分類の検証中に詰まりました。
ほかにも Apps Script から Gemini API を呼ぶと長い生成で止まる原因と対処 — UrlFetchApp タイムアウトと 6 分実行上限の壁 と Gemini API で画像バッチ分析の INVALID_ARGUMENT エラーを診断する、Next.js App Router の Server Actions から Gemini API を呼ぶときのエラー診断と解決策 は、私自身が「3時間溶かした」種類の問題を残しておいた記事です。
来週に向けて
今週は「本番でゆっくり動かし続けるための装備」を整える週でした。来週は Google I/O 2026 の発表からもう少し時間が経つので、新機能の中で**「3ヶ月後にも残っているか」を実機で測れたもの**を中心に書いていく予定です。
新しい機能の派手な発表より、地味な装備の積み重ねが、12年個人開発を続けてきた感覚としては結局いちばん効くと感じています。今週もお読みいただきありがとうございました。来週もよろしくお願いします。