こんにちは！
Google Cloud を使っていると、いろいろなもののサポート終了がちょこちょこやってきます。そのたびに、自分の環境に関係あるかを調べるのが地味に大変なので、毎週 Slack に教えてもらう仕組みを作りました。
作ったもの
毎週月曜の朝、こんな通知が Slack に届きます。
自分の Google Cloud 環境で使っているランタイムや Gemini モデルのうち、サポート終了が近いものだけを、残り日数で色分けして教えてくれます。
- 🔴 緊急：30 日以内
- 🟠 要対応：90 日以内
- 🟡 予告：180 日以内
全体の構成はこんな感じです。
ざっくりした流れはこうです。
- 毎週月曜 9 時に、Cloud Scheduler が関数を呼びます
- 関数が 3 か所からデータを集めます
- Asset Inventory：自分の環境のリソース（関数のランタイム、Cloud Run の環境変数に書いたモデル名）
- BigQuery：リリースノートの告知
- runtimes.list：ランタイムごとの終了日
- リリースノートだけ Gemini に読ませて、提供終了になるモデルと日付を抜き出します。抜き出した結果は、コードで本文と照らし合わせて確かめます
- 自分の環境のリソースと期限を突き合わせて、残り日数で段階分けします
- 該当があれば Slack に通知します（Webhook URL は Secret Manager に入れています）
なんで作ったか
Google Cloud のリリースノート、量が多すぎて追いきれないんですよね。
もちろん Google も大事な廃止はメールで知らせてくれます。ただ、実際には
- サービスごとにバラバラに届いて、全体が見えない
- メールが多くて埋もれる
- 「で、うちのどのリソースが該当するの？」が分からない
となりがちです。
なので、自分の環境と突き合わせて、該当するものだけを、期限が近づくたびに繰り返し教えてくれるものを作りました。直したリソースは次の週の一覧から自動で消えるので、「まだ残っているもの」だけが見えます。
仕組み
データの取り先は 3 つです。
| 知りたいこと | 取り先 |
|---|---|
| ランタイムの期限 | Cloud Run functions の API（runtimes.list） |
| Gemini モデルの提供終了日 | BigQuery の公開データセット（リリースノート） |
| 自分の環境のリソース | Cloud Asset Inventory |
ポイントは、決まった形で取れるものには AI を使わないことです。
ランタイムは runtimes.list を呼ぶと、nodejs20 の完全終了日が 2026-10-30、みたいな形でそのまま返ってきます。ここに AI を挟む必要はありません。
一方、モデルの提供終了は、リリースノートの文章の中に書いてあります。書き方もバラバラなので、ここだけ Gemini（gemini-3.5-flash-lite）に読んでもらっています。
照合、残り日数の計算、段階分け、通知はコードです。ここは毎回同じ答えが出てほしいので。
ただ、モデル名の書き方が一覧と違うときだけは、Gemini にどれに当たるかを選ばせて、その結果をコードで確かめています。
AI の強みを活かしたところ
ここが一番やりたかったところです。書き方がバラバラな文章を読んで意味を取るのは、ルールで書くと大変ですが、AI は得意です。その強みを活かしつつ、間違いは通さないようにしました。
根拠を引用させて、コードで確かめる
AI に「この告知で提供終了になるモデルと日付を抜き出して」と頼むと、だいたい正しく返してくれます。ただ、本文に書いてない情報を補ってくることもあります（実際に、本文にない後継モデルを返してきたことがありました）。
そこで、Gemini には答えと一緒に根拠として本文を引用させて、その引用が本当に本文にあるかをコードで確かめています。
たとえば、実際にあったリリースノートにこんな告知がありました。
Gemini 2.0 models are scheduled for deprecation on June 1st.
...
This applies to "flash lite" and "flash" variants.
本文のどこにも gemini-2.0-flash とは書いてありません。でも、人が読めば「Gemini 2.0 の Flash と Flash-Lite のことだな」と分かります。こういうあいまいな書き方は、ルールで拾うより AI の方が得意です。
Gemini はこんな形で返してきます（一部抜粋）。
{
"model_id": "gemini-2.0-flash",
"event_type": "deprecation",
"match_type": "inferred",
"evidence": [
"Gemini 2.0 models are scheduled for deprecation on June 1st.",
"This applies to \"flash lite\" and \"flash\" variants."
]
}
match_type の inferred は「本文にそのままは書いてないけど、文脈から推論しました」という意味です。evidence は、その根拠として Gemini が本文から引用した文です。
コード側では、この引用が本文に一字一句そのまま載っているかを確かめます。全部載っていれば採用、1 つでも見つからなければ捨てます。根拠の文が本当にあるなら、推論の筋道はあとから人が見ても確かめられるので。
これで、AI の推論は活かしつつ、でっち上げは通さないようにしています。
名前の部分一致に気をつける
地味に大事だったのがこれです。
gemini-2.5-flash で本文を探すと、gemini-2.5-flash-lite や gemini-2.5-flash-image にも引っかかります。Flash-Lite のことしか書いていない告知で、AI が間違えて gemini-2.5-flash を返しても、検証を通ってしまうんですよね。
なので、見つかった位置のすぐ後ろに -lite や -image のような続きがないことも確認しています。
本文にない「後継モデル」は出さない
通知には移行先のモデルも出しているんですが、ここも Gemini が本文にない後継を補ってくることがありました。移行先を間違えて案内するのはまずいので、後継も同じ検証にかけて、見つからなければ表示しないようにしています。
「非推奨」と「提供終了」を分ける
リリースノートには「非推奨になります（まだ使える）」と「提供終了します（使えなくなる）」が混ざっています。これを一緒にすると、まだ使えるモデルを「期限切れ」と通知してしまうので、Gemini に種類も判定させて、段階分けに使うのは提供終了だけにしました。
ちなみに：AI の答えは毎回ちょっと変わる
temperature を 0 にしても、リリースノートから拾う件数は実行ごとに 70〜100 件くらいブレました。
でも、最後に届く通知は毎回同じでした。結果に効くところは全部コードで確かめているからです。AI の答えが毎回少し変わっても、届く通知は変わらないようにしておくのが大事だなと思いました。
機密情報の扱い
Asset Inventory では、Cloud Run の環境変数の値が平文で取れます。なので、値に gemini を含むもの（＝モデル名）だけを残して、それ以外は保持しないようにしています。Gemini に渡すのは、基本的にリリースノートの本文だけです。環境の情報で渡る可能性があるのは、一覧の ID と完全に一致しなかったモデル名だけです。
動かしてみた結果
検証用に、わざと古いランタイムやモデルを使うダミーのリソースを Terraform で作って試しました。結果は 2026-09-30 時点のものです（段階は日付が進むと変わります）。
| ダミー | 期限 | 残り | 結果 |
|---|---|---|---|
Cloud Run の環境変数に gemini-2.5-flash
|
2026-10-16 | 16 日 | 🔴 緊急 |
Cloud Run functions（nodejs20） |
2026-10-30 | 30 日 | 🔴 緊急 |
Cloud Run の環境変数に gemini-2.5-flash-image
|
2027-03-15 | 166 日 | 🟡 予告 |
Cloud Run functions（python310） |
2027-04-04 | 186 日 | 対象外（180 日より先） |
期待どおりに分かれてくれました。
1 回の実行は 1 分くらいです。
あと、最初は 1 件の情報を 1 行に詰め込んでいたので、めちゃくちゃ読みにくかったです。
「何が・あと何日で・どのリソースに」の順に並べ直して、こうなりました。
ちょっとハマったところ
テストは通るのに、実環境では何も読めなかった
テストは全部通っているのに、実環境で動かすと「関数 0 件、Cloud Run 0 件」。
原因は、テスト用のサンプルを gcloud の出力（assetType）で作っていたのに、Python のライブラリが返すのは asset_type だったことでした。サンプルデータでテストするときは、本物のライブラリが返す形で作らないとダメですね（反省）。
注意点
- リリースノートの情報は、モデル一覧のページより古いことがあります。今回も
gemini-2.5-flashの提供終了日が、リリースノートでは 10/16、モデル一覧では 10/20 でした（延長されたっぽい）。このツールはリリースノートの日付で通知するので、少し早めに教えてくれる方向にずれます - BigQuery のリリースノートは、公式のリリースノートのページより少し遅れて更新されます。新しい告知が通知に出るまで、数日かかることがあります
- 今回見ているのは、Cloud Run functions のランタイムと、Cloud Run の環境変数に書いたモデル名です。コードに直接書いたモデル名や、コンテナの中の言語バージョン、ほかのサービスは対象外なので、このあたりは次にやりたいところです
まとめ
- 決まった形で取れるものはコードで、文章を読むところだけ AI に任せる
- AI の答えは根拠を引用させて、コードで確かめる
- AI の答えが毎回少し変わっても、届く通知は変わらないようにする
の 3 つを意識して作りました。「flash lite と flash の話です」くらいのざっくりした告知を読み取れたのは、ルールで書いていたらまず無理だったと思います。
次は、App Engine や GKE、Cloud SQL など見るサービスを増やしたり、該当したリソースのコードを Gemini に読ませて「移行するなら、どこを直せばいいか」まで出したりしてみたいです。
ここまで読んでいただき、ありがとうございました。