GEMINI LABEN
DEADLINE — gemini-robotics-er-1.6-preview は昨日8月31日でシャットダウンされました。今日からエラーが出るコードがあれば、原因はまずこの停止を疑ってくださいNEXT — 次の期限は9月30日です。gemini-omni-flash-preview エンドポイントが廃止され、移行先は8月27日に GA になった gemini-omni-1.1-flash になりますAPIKEY — Gemini API は9月中に標準 API キーからのリクエストを拒否し始めます。auth キーへの移行がまだの場合、今月が実質の移行期限ですSHEETS — Gemini を組み込んだ Sheets canvas が8月31日から Scheduled Release ドメインへ段階展開されています。表示まで最大15日の時間差がありますMEET — Google Meet ハードウェアのタッチコントローラから「Take notes for me」の開始・停止・管理ができる展開が8月31日に始まりましたPARAMS — temperature・top_p・top_k は受理されたまま無視される「静かな非推奨」が続いています。決定性を前提にしたコードは実測での確認が必要ですDEADLINE — gemini-robotics-er-1.6-preview は昨日8月31日でシャットダウンされました。今日からエラーが出るコードがあれば、原因はまずこの停止を疑ってくださいNEXT — 次の期限は9月30日です。gemini-omni-flash-preview エンドポイントが廃止され、移行先は8月27日に GA になった gemini-omni-1.1-flash になりますAPIKEY — Gemini API は9月中に標準 API キーからのリクエストを拒否し始めます。auth キーへの移行がまだの場合、今月が実質の移行期限ですSHEETS — Gemini を組み込んだ Sheets canvas が8月31日から Scheduled Release ドメインへ段階展開されています。表示まで最大15日の時間差がありますMEET — Google Meet ハードウェアのタッチコントローラから「Take notes for me」の開始・停止・管理ができる展開が8月31日に始まりましたPARAMS — temperature・top_p・top_k は受理されたまま無視される「静かな非推奨」が続いています。決定性を前提にしたコードは実測での確認が必要です
記事一覧/API / SDK
API / SDK/2026-09-01上級

Gemini の API キーを差し替えても旧キーが勝つ。決め手は読み込み順ではありませんでした

同じ環境変数名を複数の経路が供給していると、キーを差し替えても古い値が残ります。読み込み順を四通り入れ替えた実測と、供給と読み取りを台帳に残す監査シムの実装をまとめました。

Gemini API228APIキー4環境変数移行7運用11

プレミアム記事

9月に入りました。手元の Gemini 関連コードで今月中に片付けなければならないのは、標準 API キーから auth キーへの移行です。個人開発で回している壁紙アプリのカテゴリ分類バッチが一番わかりやすい対象だったので、そこから手を付けました。

.env の値を新しいキーに書き換え、ローカルで一度走らせ、応答が返ることを確認して、そのまま定期実行へ戻しました。ところが翌朝のログを見ると、リクエストに乗っていたのは古いキーのままでした。

.env は確かに書き換わっています。プロセスは確かにそのファイルを読んでいます。それでも古い値が使われていました。

同じ名前を三つの経路が取り合っていました

原因を探す前に、まず「そのプロセスに GEMINI_API_KEY を渡している場所」を全部並べました。私の環境では三つありました。

供給経路置き場所コード検索で見つかるか
シェル環境変数定期実行のラッパースクリプト内の export見つかる(ただし別リポジトリ)
dotenv ファイルプロジェクト直下の .envファイル名は見つかるが値は追えない
シークレットファイルデプロイ時に配置される JSON見つからない

ここで最初のつまずきが起きます。grep -rn "GEMINI_API_KEY" で出てくるのは、ほとんどが読む側のコードです。os.environ.get(...)process.env.... の行です。値を入れる側は、CI の設定画面、デプロイ時に展開されるファイル、ラッパースクリプトの export といった、リポジトリの外か、リポジトリの隅に散らばっています。

読む側だけを数えて「三箇所で読んでいるから三箇所直せばいい」と考えると、供給側の棚卸しが丸ごと抜け落ちます。私はここで一度、手順の順番を間違えました。

読み込み順を四通り入れ替えても、勝者は変わりませんでした

最初に疑ったのは読み込み順です。「後から読んだ方が勝つのなら、新しいキーを最後に読ませればいい」と考えました。素直な仮説だと思います。

そこで、三つの経路を持つ最小のローダを書いて、順序を入れ替えながら実際に走らせました。

# probe.py — 供給経路が三つある設定ローダ。読み込み順を入れ替えて勝者を見る
import os, sys, json
from dotenv import load_dotenv
 
def from_shell():
    # すでにプロセスに入っている値を読むだけ(何も書き込まない)
    return os.environ.get("GEMINI_API_KEY")
 
def from_dotenv():
    # python-dotenv の既定は override=False。既存の値があれば書き込まない
    load_dotenv("/tmp/keyaudit/.env")
    return os.environ.get("GEMINI_API_KEY")
 
def from_secretfile():
    # 素直な代入。既存の値があっても無条件に上書きする
    d = json.load(open("/tmp/keyaudit/secrets.json"))
    os.environ["GEMINI_API_KEY"] = d["GEMINI_API_KEY"]
    return os.environ["GEMINI_API_KEY"]
 
fns = {"shell": from_shell, "dotenv": from_dotenv, "secretfile": from_secretfile}
for name in sys.argv[1].split(","):
    fns[name]()
 
print(f"order={sys.argv[1]:32s} winner={os.environ.get('GEMINI_API_KEY')}")

.env には新しいキー、シークレットファイルには古いキー、シェルにも古いキーを置いた状態で、順序を四通り試しました。実行結果はこうなりました。

order=shell,dotenv,secretfile          winner=OLD_STANDARD_KEY_from_secretfile
order=shell,secretfile,dotenv          winner=OLD_STANDARD_KEY_from_secretfile
order=dotenv,secretfile,shell          winner=OLD_STANDARD_KEY_from_secretfile
order=secretfile,dotenv,shell          winner=OLD_STANDARD_KEY_from_secretfile

四通りすべてで、勝ったのは古いキーを持つシークレットファイルでした。順番を入れ替えても結果が動きません。

理由は、経路ごとに「既存の値をどう扱うか」の方針が違うからです。load_dotenv() は既定で既存の値を尊重して書き込みません。素直な os.environ[...] = value は既存の値を見ずに上書きします。したがって、後から読まれるかどうかではなく、上書きを許す方針を持った経路が一つでもあれば、その経路が最終的な勝者になります

私はこの結果が出るまで、import 文の位置を並べ替えるという遠回りをしていました。順序に原因があると信じている間は、どれだけ並べ替えても症状が動かないので、手がかりが増えません。

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

この記事の続きを読む

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

この記事で得られること
キー移行を始める前に、自分のコードのどの供給経路が上書きを許していて、どれが黙って無視されるのかを見分けられるようになります
新旧どちらのキーが実際にリクエストへ乗ったのかを、値そのものをログに残さずに記録する台帳を、自分の実行環境へ入れられるようになります
読み込み順を四通り入れ替えても勝者が変わらなかった理由を説明でき、import 文を並べ替えて直そうとする遠回りを避けられるようになります
Stripe による安全な決済 · いつでもキャンセル可能

この記事を購入する

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

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

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

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

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

関連記事

API / SDK2026-08-19
gemini-2.5-flash が「no longer available」で404を返しても、公式表の停止日は未告知のままです
gemini-2.5-flash の停止日は公式の廃止一覧から消えたままですが、404 の報告は7月から出ています。停止日の欄を安全マージンとして読むと外れる理由と、手元のキーで確かめる手順をまとめました。
API / SDK2026-08-01
temperature 非推奨で先に困ったのは、決定性ではなく多様性の側でした
temperature・top_p・top_k の非推奨化で影響が出たのは決定性ではなく多様性を作る側でした。呼び出し箇所の数え方、多様性を入力層へ移す設計、実効多様度の測り方を実測値とともに残します。
API / SDK2026-07-29
出力トークンが17%減ると聞いて、総額はいくら下がるのかを分解した
出力単価16.67%減と出力トークン17%減が重なったとき、総額はいくら下がるのか。Gemini 3.6 Flash への切り替えを単価・数量・交差項に厳密分解し、エージェントループでは削減率がむしろ下がった実行結果と、請求との突き合わせ方をまとめました。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →