Gemini Lab の廣川政樹です。
前回の週次まとめから少し間が空いてしまったので、今回は6月に入ってからの12日間をまとめて振り返ります。改めて並べてみると、6月前半は 「人間の頭の中にある『決め』を、コードに書き起こして固定する」 という方向の記事が自然と多くなっていました。モデルIDや安全設定、生成物の来歴、機能ごとの採算ライン。どれも「決めたはずなのに、いつの間にかズレていた」が起きやすい場所です。
それと並行して、壁紙アプリ運用の現場で Gemini を1ヶ月〜数週間回した実地レビューが5本、本番で実際に詰まったトラブルの記録が3本。そして週の後半には Gemini 3.2 の API 移行ガイドと、Google I/O 2026 直前の見立てを書きました。順に振り返ります。
軸①：「決め」をコードに固定する — 設定・来歴・採算の設計群
この期間でいちばん手応えがあったのは Gemini APIの設定ドリフトを止める — モデルID・安全設定をコード化して環境差を検出する です。開発環境では gemini-3.1-pro、本番では古い gemini-2.5-pro のまま、安全設定も微妙に違う——複数アプリを並行運用していると、この種のズレは本当に静かに入り込みます。モデルIDと生成設定を宣言的なファイルに寄せて、環境間の差分を CI で検出する構成にしてから、「あれ、本番だけ挙動が違う」と首をかしげる時間が目に見えて減りました。
同じ系統で Gemini 生成物の来歴を残す — 再現と監査のためのプロベナンス設計 も書きました。生成結果だけ保存して、どのモデル・どのプロンプト・どの設定で作ったかを残していないと、数ヶ月後に「これを再現してほしい」と言われた瞬間に詰みます。生成のたびにメタデータを添えて保存する、それだけのことを設計として固めた記事です。
事業側の「決め」では Gemini を組み込んだ機能の採算を、機能単位で見る設計 — 残す・直す・畳むを判断するために をまとめました。API コストはアプリ単位の合計で眺めがちですが、機能単位でコストと利用率を割り付けてみると「ほとんど使われていないのに毎月コストだけ発生している機能」が浮かび上がってきます。残す・直す・畳むの判断は、数字を機能単位に割ってからの方が圧倒的にしやすくなります。
運用の足元では Gemini Files API の孤児ファイルを棚卸しする — 多アプリ運用の照合と自動クリーンアップ設計 を書きました。複数アプリから Files API を使っていると、アップロードしたまま参照されなくなったファイルが静かに溜まっていきます。手元の台帳と API 側の一覧を突き合わせて差分を掃除する、地味ですが効く仕組みです。
コスト構造に踏み込んだのが Gemini Embedding の次元を 3072 から 768 へ切り詰める — ベクトルDBのコストとレイテンシを下げる Matryoshka 設計 です。Matryoshka 表現学習を前提にした次元削減は「精度をどこまで落とさずにストレージを 1/4 にできるか」という実利の話で、ベクトル検索を運用している方には試す価値があると感じています。
そして軽量バックエンドの Bun と Hono で Gemini API の軽量バックエンドを組む — 個人開発の小さなツールを自分の手に取り戻す実装メモ。フレームワークの重さに付き合いきれなくなった小さな社内ツール級のものを、Bun + Hono で書き直したら起動もデプロイも気持ちよく軽くなりました。個人開発の規模だと、この「軽さ」がそのまま継続のしやすさになります。
軸②：壁紙アプリ運用の現場レビュー — 数週間回してわかったこと
2014年から続けている個人開発の現場で、Gemini を実際に数週間〜1ヶ月運用した記録が5本あります。
ローカライズでは アプリ説明文のローカライズで Gemini 2.5 Flash と Flash-Lite を使い分けた所感 を書きました。全言語を Flash で回すのではなく、主要言語は Flash、ロングテール言語は Flash-Lite という割り切りにすると、品質の体感をほぼ落とさずコストが下がります。どの言語を「主要」に置くかはアプリのDL分布次第なので、そこの判断材料も記事に残しました。
ストア運用では App Store のプロモーションテキストを Gemini で週次更新した1ヶ月の所感 が対になります。プロモーションテキストは審査なしで差し替えられる数少ない場所なのに、手動だと確実に放置される——そこを週次の生成と人間の最終チェックだけで回した1ヶ月の記録です。
審査対策では Gemini の画像理解で壁紙アプリの審査リスクを事前点検した2週間の運用メモ を書きました。壁紙アプリは画像の入れ替えが頻繁な分、審査リスクのある画像が紛れ込む確率もゼロにはできません。提出前に Gemini Vision で機械的にふるいにかける運用を2週間試して、引っかけてくれたケースと素通りしたケースの両方を正直に記録しています。
役割分担の設計では AdMob レポートの判定は Gemini にやらせない — 構造化出力を「抽出」に限定する設計 がこの期間の自分なりの結論でした。レポートからの数値抽出は Gemini に任せて、フロアプライスを上げ下げする「判定」はコード側の明示的なルールに置く。生成AIに判断まで委ねたくなる誘惑への、現時点での私の線引きです。
開発環境側では Gemini 3 Pro と進めた Firebase の CocoaPods → SPM 移行、3週間の所感 をまとめました。CocoaPods の配信終了が予告されている以上、iOS アプリを持っている方には避けて通れない移行です。3週間ぶんの詰まりどころを残してあります。
軸③：本番で詰まった3件 — 静かなエラーほど時間を奪う
トラブルシュートは3本です。Gemini 2.5/3 で本文が空なのに finish_reason が MAX_TOKENS になるときの原因と対処 は、thinking 系モデルで思考トークンが上限を食い潰して本文が空になる、知らないと途方に暮れるやつです。エラーではなく「空の成功」で返ってくるのが厄介なところでした。
Firebase AI Logic で iOS から Gemini を呼ぶと 403 になる原因と対処 は、設定としては正しく見えるのに 403 が返り続けるケースの切り分けです。App Check まわりの確認順序を一本道に整理しました。
Gemini Live API の応答音声が速回しに聞こえる — サンプルレート取り違えの直し方 は、音声が壊れているのではなく再生側のサンプルレート指定がズレているだけ、という小さくも実害の大きい話です。同じ症状で悩む方の検索に引っかかってほしい1本です。
軸④：Gemini 3.2 への移行と、I/O 直前の見立て
週の後半は最新動向に寄せました。Gemini 3.2 API 実装ガイド — 正しいモデルID・3.1 からの移行と本番チェックポイント は、「gemini-3.2-pro を指定したらエラーになる」という質問を何件か見かけたのがきっかけです。モデルIDの正解、3.1 からの差分、本番切り替え前のチェックリストを実装者視点で1本にまとめました。
そして Google I/O 2026 直前 — Gemini に何が起きそうか、個人的に注目しているポイント。Gemini 3 ファミリーの全体像の整理、Gemini Nano の次のステージ、Workspace をまたいだ文脈理解、Project Astra の一般化——外れたら外れたで面白い、という気持ちで書いた見立てです。答え合わせをするのも週次まとめの楽しみのひとつだと思っています。
次の一歩
6月前半は「決めをコードに固定する」設計の話が中心でした。もしどれか1つだけ試すなら、まず 設定ドリフト検出の記事 から、自分のプロジェクトのモデルIDと生成設定を1ファイルに書き出してみてください。30分の作業で「環境差で首をかしげる時間」が減っていくのを実感できるはずです。
I/O の答え合わせは、また次のまとめで。引き続きどうぞよろしくお願いいたします。