こんにちは、コアシステム開発グループのたなかです。
私は、エンジニア全体でやっている外部サービスの変更確認のうち、Google Cloud のリリースノートの確認を担当しています。最初は目視で確認していましたが、2026 年 2 月から Claude Code のスキルに任せるようにしました。
今回は、このスキルに確認を任せられるようにするためにやったことを紹介します。
1. 外部サービスの変更確認と、引き継いだ手順
当社では、リネットで使っている外部サービスの仕様変更やメンテナンスのお知らせを、エンジニアが毎週確認しています。
決済やメール配信、配送、クラウドなどサービスごとに担当者を決めていて、確認した結果はスプレッドシートに記録し、リネットに影響のあるお知らせがあれば共有して対応につなげる運用です。
Google Cloud の担当は、2025 年 10 月に前任者から引き継ぎました。
インフラ担当もインフラの観点で確認していますが、使っている側でも確認したほうがよいという考えで、この担当が置かれています。そのため、Web アプリケーションの開発をしている私が見るのは「アプリケーションに影響があるか」という観点です。
引き継ぎ当時、前任者から確認方法と、これまで確認してきたサービス（14 個）を教わりました。引き継いだ手順書は、次のようなシンプルなものです。
- 毎週、使っているサービスのリリースノートを見る
BreakingやDeprecatedのラベルが付いた変更に注意する- 終わったらスプレッドシートにチェックを入れる
この確認の目的は、Google 側の仕様変更やサポート期限切れで、本番がある日突然動かなくなるのを防ぐことです。そのため、破壊的変更や非推奨でなくても、影響がありそうな変更は把握しておく必要があります。
ただ、目視で続けていると困ることがいくつかありました。
- リリースノートはほぼ毎日何かしら出ていて量が多く、どこを見ればいいか分かりにくい
- 1 回に 20〜30 分くらいかかり、地味に時間を使う
- 本文は英語なので、まず
BreakingとDeprecatedのラベルを起点に読む。Google Cloud のリリースノートにはFeature・Change・Fixedなどのラベルもあり、Changeの中にも既存の挙動が変わるものがある。そうした破壊的変更・非推奨ではないが影響のある仕様変更は、見落としていたかもしれない Breakingな変更を見つけても、リネットが対象になるかは別に調べる必要がある- インフラに詳しくないので、影響があるかの判断に迷う
- 使うサービスが増えても、手順書が更新されないと私には分からない
2. リリースノートの確認をスキルにした
2 月に、この確認を Claude Code の個人スキルにしました。最初は「リリースノートを見て、対象の変更があるか教えて」くらいの内容で作り、使いながら直してきました。
今のスキルは、ざっくり次の流れで動いています。
オレンジの 2 は、4 章で詳しく書く「取りこぼしがないかの検査」です。
図の 5 で「コードの修正が要るか」まで出すのは、私が見る観点がアプリケーションへの影響だからです。ラベルを見つけても、それがリネットに関係あるかが分からなければ結局私が調べることになります。
今の運用では、スキルのレポートを読んだあと、念のため目視でもリリースノートのラベルを流し見しています。スキルの結果だけで終わらせず、最後に人の目も通すためです。
3. 見る範囲をコードから広げた
スキルを使い始めて 2 か月ほど経ったころ、GKE の破壊的変更の告知を目にしました。スキルが拾っていたかを確かめると、GKE は引き継いだ確認対象に入っておらず、レポートにも出ていません。
ここで GKE だけを足すと、同じことがまた起きます。そこで、引き継いだ確認対象をもとに、リネットのコードで実際に使っている Google Cloud のサービスを確認して見る範囲を広げることにしました。Claude に見てもらった観点は 3 つです。
- Kubernetes のマニフェストやビルドの設定ファイル
- SDK の読み込み（PHP の
use文、Go の import） - コードに書かれた API の URL（
*.googleapis.comなど）
実際に使っているかは、依存の宣言だけでは判断できません。
PHP の google/cloud のように、いくつものサービスのライブラリをまとめて入れるパッケージがあります。composer.json に載っているだけでは根拠にならないので、Claude には実際のコードの use 文まで確かめてもらいました。
結果、見るサービスは 14 個から 20 個に増えました。GKE、Cloud SQL、Secret Manager などを足した一方で、依存にはあっても実際のコードで使っていなかった 3 つは入れていません。
見るサービスの範囲は一度決めて終わりではありません。インフラやライブラリが増えたら見直す必要があると考えています。
4. AI の要約を、そのまま結論にしない
スキルは、リリースノートのページを取得して AI に要約させ、確認する期間の変更を拾います。ところが使っていくうちに、要約の結論が間違うことがありました。
たとえば、確認する期間が 7/6〜7/13 のとき、7/10 に載ったエントリを「期間外」として外したことがあります。期間の判定ルールはプロンプトに書いてあったのに、です。
ルールを書き足しても同じことが起きるので、問題はルールの不足ではなく、要約の結論を検証せずにそのまま信じていたことにありました。
そこで入れたのが、次の 3 つの仕組みです。
4.1 日付の判定を、要約の結論に任せない
要約には、結論とは別に「ページから取れた日付の一覧」も返させています。その一覧から期間内の日付を抜き出し直し、要約の結論と突き合わせる仕組みです。
- 一覧に期間内の日付があるのに、結論が「期間内なし」 → 結論を捨てて、その日付のエントリを取り直す
- 一覧に期間内の日付がなく、結論も「期間内なし」 → この時点では確定させず、次の 4.2 に回す
- 一覧と結論が食い違う、一覧そのものがない → 取り直すか、私が確認する
4.2 「0 件」のときだけ、スクリプトで裏を取る
取りこぼしがいちばん起きやすいのは、「期間内の変更は 0 件」と結論したときです。そこで、0 件と結論したサービスについてだけ、リリースノートのページから日付の見出しを抜き出すスクリプトを実行し、その出力で 0 件を確定させています。
この仕組みを入れた当初は「全サービスでスクリプトを回すのは重い」という Claude の判断で、0 件のときに絞っていました。その後、4.3 の件数の突き合わせのために、今は全サービスでスクリプトを回しています。
4.3 件数を突き合わせる
同じ日付に複数のエントリが並んでいると、要約がそれらを 1 つにまとめてしまい、片方のラベルが消えることがありました。そこで、スクリプトが数えたエントリの件数と、要約が返した件数を比べて、差があれば足りない分を取り直すようにしています。
4.4 実際に拾ったもの
直近 5 週のレポートを見返すと、4 週でこれらの仕組みが要約の誤りを拾っていました。
| 週 | サービス | 要約の誤り | どうしたか |
|---|---|---|---|
| 8/21 の週 | Cloud Run | 期間内のエントリがあるのに「期間内なし」と結論した | 結論を捨てて、エントリを取り直した |
| 8/21 の週 | Cloud Trace | 期間内のエントリがあるのに「期間内なし」と結論した | 結論を捨てて、エントリを取り直した |
| 8/21 の週 | GKE | 期間内の 4 日分のうち、1 日分しか拾わなかった | 残りの 3 日分を取り直した |
| 8/28 の週 | Cloud Build | 日付の一覧には期間内の日付があるのに、結論は「期間内なし」だった | 結論を捨てて、エントリを取り直した |
| 9/11 の週 | Artifact Registry | 期間内のエントリを 1 件落とした | 件数の突き合わせで気づき、補った |
| 9/18 の週 | Cloud SQL | 結論に「期間内なし」と「期間内あり」が両方書かれていた | 結論を捨て、スクリプトが数えた 3 件で確定した |
どれも、要約の結論だけを読んでいたら期間内の変更を見落としていたものです。
5. リリースノートに載らない廃止を拾う
7 月に、他のメンバーが Cloud Run functions のランタイムの廃止予定を Slack で共有してくれました。調べてみると、この情報はリリースノートにはなく、ランタイムのサポートスケジュールのページにだけ載っていたのです。
リリースノートを見ていれば廃止を拾える、という前提はここで崩れました。そこで、次の照合をスキルに足しています。
- ランタイムや DB バージョンなどの廃止スケジュールのページを取得する
- 実環境で使っているバージョンを
gcloudコマンドで取得する - 両者を照合して、期限が近いものを出す
使っているバージョンを、リポジトリの定義ではなく gcloud で実環境から取っているのには理由があります。手動でデプロイされたものはリポジトリを検索しても見つからないので、実際に動いているものを正にしました。
6. Before / After
引き継いだ目視の手順と、今のスキルを並べるとこうなります。
| 観点 | 目視（引き継いだ手順） | スキル |
|---|---|---|
| 見るサービス | 引き継いだ確認対象の 14 個 | コードを確認して広げた 20 個 |
| 見るもの | Breaking と Deprecated のラベル |
左に加えて、将来の廃止予告・既知の障害・Change などの参考情報 |
| リリースノートに載らない廃止 | 手順の対象外 | 廃止スケジュールと実環境のバージョンを照合する |
| リネットへの影響 | 見つけたあとに自分で別途調べる | リポジトリを検索して、コードの修正が要るかまで出す |
まとめ
前任者から引き継いだ Google Cloud のリリースノートの確認を、目視から Claude Code のスキルに切り替えました。やったことは次の 3 つです。
- 見る範囲を、引き継いだ確認対象からコードと実環境を確認して広げた
- AI の要約をそのまま結論にせず、日付や件数、スクリプトの出力と突き合わせてから確定させるようにした
- リリースノートに載らない廃止を、廃止スケジュールと実環境のバージョンの照合で拾うようにした
直近 5 週では、そのうち 4 週で要約の取りこぼしを拾えました。今の私の作業は、スキルのレポートを読んで共有が必要かを判断し、最後にリリースノートのラベルを流し見するところだけで済んでいます。
ホワイトプラスでは一緒に働いてくれるエンジニアを募集しています。興味を持っていただけたら、ぜひ採用ページやエントランスブックをご覧ください！
