◉GEMINI LABEN
●ARGON — gemini-4-argon が 10/13 に GA。複雑なコーディング・エージェント・数学・科学向けです●DEEP RES — deep-research-pro-preview-12-2025 は 10/23 に停止、残り6日。移行先は deep-research-preview-04-2026●NANO — gemini-nano-banana-2.1 が GA(10/06)。gemini-3.1-flash-image は非推奨で停止日は未発表です●MCP — ツール結果が 8.5万トークンに膨らんだ事例を、ADK で 310 トークンに包んで抑えた報告が出ています●FLASH — gemini-3.7-flash と 3.5-flash は新しい Flash モデルに自動で回されます(10/08)●NEW — クラッシュ報告を毎回ゼロから読ませない — 既知バグ早見表を先に grep し…●ARGON — gemini-4-argon が 10/13 に GA。複雑なコーディング・エージェント・数学・科学向けです●DEEP RES — deep-research-pro-preview-12-2025 は 10/23 に停止、残り6日。移行先は deep-research-preview-04-2026●NANO — gemini-nano-banana-2.1 が GA(10/06)。gemini-3.1-flash-image は非推奨で停止日は未発表です●MCP — ツール結果が 8.5万トークンに膨らんだ事例を、ADK で 310 トークンに包んで抑えた報告が出ています●FLASH — gemini-3.7-flash と 3.5-flash は新しい Flash モデルに自動で回されます(10/08)●NEW — クラッシュ報告を毎回ゼロから読ませない — 既知バグ早見表を先に grep し…
記事一覧/API / SDK
◈ API / SDK/2026-06-03上級

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

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

Gemini API248Files API5本番運用49コスト最適化25個人開発121

✦ プレミアム記事

ある朝、壁紙アプリの画像分類バッチが「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-05-21
Gemini API × Cloud Pub/Sub によるイベント駆動 AI ワークフロー設計 — 個人開発者の実装メモ
Gemini API を Cloud Pub/Sub のイベント駆動型ワークフローに組み込む実装メモ。アプリレビュー解析パイプラインを題材に、リトライ・デッドレター・冪等性・コスト管理までを個人開発の視点で整理しました。
◈ API / SDK2026-05-06
Gemini 2.5 Flash を1ヶ月使い続けた個人開発者の正直レポート — 費用・速度・品質の実態
Gemini 2.5 Flash を個人開発で1ヶ月使い続けた実測レポートです。実際にかかった API 費用、速度の揺れ幅、品質が足りないと判断した2つの場面、Flash と Pro の切り替え判断フレームワーク、コスト上限アラートの設定まで数字で示します。
◈ API / SDK2026-09-29
『F6号』と『A4くらい』が同じ列に並ぶ作品台帳を、Gemini の読み取りと号数表の換算で cm に揃えるまで
作家さんの作品台帳に『F6号』『41×31.8cm』『A4くらい』が混ざっていました。Gemini API には読み取りだけを頼み、換算は号数表、向きは画像で決める小さな道具を、動くコードとともに一本ずつ組み立てます。