GEMINI LABEN
NANOLITE — Nano Banana 2 Liteが登場しました。Googleで最も速く、最もコスト効率の高いGemini Imageモデルで、軽量な画像生成を安く回したい用途に向いていますOMNIFLASH — Gemini Omni Flashがpublic previewになりました。ネイティブにマルチモーダルなモデルで、企業や開発者が独自の動的な動画ワークフローを構築できますAGENTS — Managed Agentsが拡張されました。background: trueでサーバー側の非同期実行とポーリング、リモートMCPサーバー連携、対話をまたぐ認証情報のリフレッシュに対応しますMEMORY — Memory BankのIngestEvents APIが一般提供になりました。イベントの取り込みとメモリ生成を分離し、コンテンツを継続的にストリームできますTHROUGHPUT — Provisioned Throughputで、同一モデル・同一リージョンに対して最大7件の保留オーダーを提出できるようになりましたDEPRECATE — 画像生成モデルは8月17日に、Gemini Enterprise Agent PlatformのGrok 4.1系は8月20日に停止される予定ですNANOLITE — Nano Banana 2 Liteが登場しました。Googleで最も速く、最もコスト効率の高いGemini Imageモデルで、軽量な画像生成を安く回したい用途に向いていますOMNIFLASH — Gemini Omni Flashがpublic previewになりました。ネイティブにマルチモーダルなモデルで、企業や開発者が独自の動的な動画ワークフローを構築できますAGENTS — Managed Agentsが拡張されました。background: trueでサーバー側の非同期実行とポーリング、リモートMCPサーバー連携、対話をまたぐ認証情報のリフレッシュに対応しますMEMORY — Memory BankのIngestEvents APIが一般提供になりました。イベントの取り込みとメモリ生成を分離し、コンテンツを継続的にストリームできますTHROUGHPUT — Provisioned Throughputで、同一モデル・同一リージョンに対して最大7件の保留オーダーを提出できるようになりましたDEPRECATE — 画像生成モデルは8月17日に、Gemini Enterprise Agent PlatformのGrok 4.1系は8月20日に停止される予定です
記事一覧/API / SDK
API / SDK/2026-06-03上級

Gemini Files API の孤児ファイルを棚卸しする — 多アプリ運用の照合と自動クリーンアップ設計

Files API にアップロードしたファイルは48時間で静かに消えます。多アプリ運用で発生する孤児ファイルとクォータ消費を、自前DBとの照合と定期クリーンアップで統制する本番設計を、壁紙アプリ運営の実装メモとしてまとめました。

Gemini API191Files API5本番運用47コスト最適化26個人開発91

プレミアム記事

ある朝、壁紙アプリの画像分類バッチが「File ... is not found」を連発して止まっていました。前夜にアップロードしたはずの画像が、Gemini の Files API 側から消えていたのです。原因はすぐに分かりました。Files API のファイルは、アップロードから48時間で自動的に失効します。私はそれを「知っているつもり」でしたが、実際の運用ではその前提を設計に織り込めていませんでした。

私は2014年から個人でアプリを作り続けていて、壁紙・癒し系を中心に累計5,000万ダウンロードほどのユーザーに使っていただいています。最近は、その壁紙アセットのカテゴリ分類を Gemini のマルチモーダル機能に任せていて、6本のアプリ分の画像を日々まとめてアップロードしています。件数が増えるほど、この「48時間で消える」という仕様と、消える前後の状態管理が運用の急所になりました。ここでまとめたいのは、単発の「消えたファイルをどうするか」という対処ではありません。多アプリ運用で孤児ファイルとクォータ消費をどう統制するか、その照合とクリーンアップの設計を実装込みで共有します。

Files API のライフサイクルを正確に把握する

最初に、設計の土台になる事実を正確に押さえておきます。曖昧なまま運用に乗せると、後で必ず痛い目を見ます。

Files API にアップロードしたファイルには、いくつか動かしようのない制約があります。第一に、保存期間は48時間で、これは延長できません。第二に、プロジェクトあたりの合計ストレージには上限があり、超えると新規アップロードが弾かれます。第三に、アップロード直後のファイルは PROCESSING 状態で、ACTIVE になるまで推論に使えません。動画など大きなファイルでは、この処理待ちが無視できない長さになります。

つまり Files API は「永続ストレージ」ではなく「48時間だけ有効な一時的な受け渡し場所」です。ここを取り違えると、アップロードしたファイルの uri を自前のデータベースに保存して使い回そうとして、翌々日に全滅する、という事故が起きます。私が最初にやったのが、まさにこれでした。

状態を確認するコードはこうなります。アップロード後に ACTIVE を待つ部分は、本番運用では必ず必要になります。

import time
from google import genai
 
client = genai.Client(api_key="YOUR_GEMINI_API_KEY")
 
def upload_and_wait(path: str, timeout_s: int = 120):
    """アップロードして ACTIVE になるまで待つ。PROCESSING のまま使うと失敗する。"""
    f = client.files.upload(file=path)
    deadline = time.time() + timeout_s
    while f.state.name == "PROCESSING":
        if time.time() > deadline:
            # 処理が長引くファイルは握りつぶさず、呼び出し側に判断を委ねる
            raise TimeoutError(f"{f.name} stuck in PROCESSING")
        time.sleep(2)
        f = client.files.get(name=f.name)
    if f.state.name != "ACTIVE":
        raise RuntimeError(f"{f.name} ended in state {f.state.name}")
    return f

ここで大事なのは、PROCESSING のまま推論に渡さないこと、そしてタイムアウトを設けて無限ループにしないことです。私は当初 sleep だけで待っていて、処理が詰まったファイル1件のせいでバッチ全体が朝まで止まっていたことがありました。

「アップロードして忘れる」設計が破綻する理由

個人開発でありがちなのが、アップロードしたら後は API が面倒を見てくれるだろう、という素朴な期待です。小さな検証では問題が表面化しないので、なおさら気づきにくいのが厄介なところです。

私が最初に書いていたコードは、おおよそ次のようなものでした。問題のある書き方として、まず見てください。

# Before: アップロードしっぱなしで状態を一切記録しない
def classify_wallpaper(path: str):
    f = client.files.upload(file=path)
    resp = client.models.generate_content(
        model="gemini-2.5-flash",
        contents=[f, "この画像を30カテゴリのいずれかに分類してください"],
    )
    return resp.text
    # f は二度と参照されない。削除もしない。記録も残らない。

この書き方には三つの問題があります。ひとつ目は、アップロードしたファイルを削除していないので、48時間は無駄にストレージを占有し続けることです。ふたつ目は、どのファイルをいつアップロードしたかの記録がないので、後から「いま何件分のファイルが Files API 側に残っているのか」を把握できないことです。みっつ目は、分類処理が途中で失敗したとき、すでにアップロード済みのファイルが宙に浮いてしまうことです。これが孤児ファイルです。

1日に数十件なら、48時間で勝手に消えるので実害は小さく見えます。けれども6本のアプリで合計数千件をアップロードするようになると話が変わります。失効を待つだけの設計では、ストレージ上限に張り付いて新規アップロードが弾かれ始めますし、何より「いま何が残っているか分からない」状態そのものが、運用の不安の種になります。アプリ事業の収益はほぼ AdMob に依存していて、私は1円単位でコストに敏感です。把握できないリソースが裏で動いているのは、それだけで気持ちが悪いものでした。

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること
Files API の48時間自動失効を前提に、自前DBと照合して孤児ファイルを検出する照合スクリプトの実装
アップロード件数が日次で数千件規模になったときに効くクォータ・コストの会計と、削除を先送りしない設計判断
6本のアプリを1人で並行運用するための、ファイル命名規約とクリーンアップ・ジョブの運用ルール
Stripe による安全な決済 · いつでもキャンセル可能

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または
メンバーシップなら全記事が読み放題 →
シェア

お読みいただきありがとうございます

Gemini Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • コピー&ペーストで使える実装コード付き
  • 毎日新しい上級ガイドを追加
  • ¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

関連記事

API / SDK2026-07-11
Gemini のコンテキストキャッシュが途中で失効する — 一時停止するパイプラインで TTL 切れを検知して張り直す
夜間バッチや再試行で処理が一時停止すると、Gemini の明示的コンテキストキャッシュは静かに TTL 切れを起こし、以降の呼び出しが全トークン課金へ戻ります。残り有効期限を握って張り直すか素通しするかを費用で決める、小さなリース設計をまとめました。
API / SDK2026-06-28
Gemini API で動画を「時刻つき」で読む — 該当シーンだけを引き出す
画面録画やアプリのデモ動画から「あの操作はどこ?」を探すのは骨が折れます。Gemini API の動画理解を使い、タイムスタンプ付きで該当箇所だけを引き出す方法と、FPS・解像度でトークンを抑える設計をまとめます。
API / SDK2026-06-22
Gemini APIで商品画像を構造化分析する — 数千枚を回して固めた本番パイプライン
商品画像から自動でタグ・説明文・カテゴリを生成するツールを、単発の試作から数千枚を安定処理する本番パイプラインへ。構造化出力・再開可能なバッチ・実測コスト・モデルルーティングまで、個人開発の運用で固めた知見をまとめます。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →