概要 メルカリでは、CoreDB と呼ばれる中核データベースを長年オンプレミス上の MySQL で運用してきました。本記事では、2026 年 4 月に完了した MySQL から TiDB への移行を振り返り、長期的なスケーラビリティの改善、弾力的なリソース確保、クラウド化による運用負荷の軽減といった成果を紹介します。また、移行フローや ProxySQL を活用した段階的な切り替えでうまくいった点、実トラフィックを用いた検証やコスト見積もりで直面した課題、移行後に見えてきた改善テーマについても整理します。 TL;DR 中核データベースであるCoreDBを 2026/04 にオンプレミスMySQLからTiDBへ移行完了 移行により下記の当初目的を達成 長期的スケーラビリティの改善 トラフィック変動に応じたリソース調整 オンプレミス運用からの脱却 DBREのEM/ICを募集中 もう少し詳しい内容が知りたい方へのポイントまとめ 移行は問題があればMySQLに切り戻し可能な構成を維持しながら実施 ProxySQLを活用し段階的にTiDBに本番トラフィックを移行 切り替えを中央管理し、アプリケーションから透過的な切替を実現 バッチ(OLAP)エンドポイントの先行移行、切り替え前の実トラフィックの9回のテストで問題を事前に検出 クエリリプレイによるテストを心がけるも80%負荷再現が当時の限界 事前のベンチマークには問題があり、不正確なコスト見積もりに TiDB DDLはオンライン化/分散実行による高速化を達成 DDL運用負荷が減り、「あるべきテーブル定義」ベースに 上記の内容を、記事内で順に説明していきます。 背景 メルカリには、商品・取引・ユーザーなどのクリティカルなビジネスデータを扱う中核データベースとして CoreDB と呼ばれるデータベースがあります。これは、メルカリのサービス開始当初から利用されていたモノリスアプリケーションのデータを格納してきたものです。下記の記事でもある通り、マイクロサービス化とともに、新規のドメインの独立したマイクロサービスに関しては、各々の独立したデータベースを持ち開発チームがデータベースを持つ運用を想定して、データベースも可能なものは分割してきました。しかし、現在でもなお多くのデータが CoreDB に格納されています。 https://www.publickey1.jp/blog/18/mercari_tech_conf_2018.html この CoreDB は、長らくオンプレミスサーバー上の MySQL で運用してきました。以前は石狩のデータセンターで稼働していましたが、多くのアプリケーションが Google Cloud の東京リージョンへ移行したことを受け、主にアプリケーションとの通信レイテンシを削減する目的で、東京のオンプレミスサーバー上の MySQL へ移行しました。 また、スケールアウト、つまり Read Replica を増やすことで、メルカリのトラフィックの大多数を占める読み取りトラフィックのスケールを実現しながら、同時にスケールアップも行い、運用に収まる現実的な台数を維持しながら運用を行っていました。 https://engineering.mercari.com/blog/entry/20220218-3c7faca4cc/ (Stateful なレガシー MySQL server の章) また、このスケールアップおよびスケールアウトとともに、必要なデータ保存量やトラフィックの増加に伴い、垂直シャーディングを繰り返してきました。すなわち、データの性質が異なり、結合クエリの発行が必要ない範囲に関しては、ソースおよびレプリカのセット、以後クラスタと呼びます、を分け、複数のクラスタで運用をしてきました。 垂直シャーディング( 他のブログ記事 より画像を引用) 今回、2026 年 4 月に全ての MySQL サーバーの書き込みトラフィックを TiDB に移行完了しました。それにあたり、当初何を解決したかったか、それがどのようになったかについて簡単に振り返りたいと思います。 移行にあたって、個別の事象としては、数々の解決してきた課題があり、これについては別のブログ記事で紹介します。 TiDB 移行で何を解決したかったか まずは、移行当初の目的について振り返ります。TiDB 移行により、主に次の 3 つの課題を解決しようと考えていました。 長期のスケーラビリティーの改善 MySQL は Write ノードが単一であるため、書き込み性能を上げるためには、基本的により高性能なサーバーへ置き換えるスケールアップが主な選択肢になります。読み取り性能は Read Replica を増やすことで伸ばしやすい一方、書き込み性能は同じようには水平に伸ばしにくく、大規模なサービスでは長期的な制約になりやすい領域です。 TiDBはMulti Writer, 実データを保存するTiKVもスケール メルカリではスケールアウトとスケールアップを繰り返してきた結果、クラウドなどへの移行を検討する際に、必要なスペックのサーバー、つまりインスタンスクラスがない、あるいは性能が不足する、といったことが発生してきました。また、オンプレミス環境でスケールアップの対応を行うには、非連続なコスト、特にハードウェア調達時に多額のキャッシュアウトが発生し、特異なスペックのサーバーを運用することのリスクなどを含め、限界を迎えつつありました。 トラフィックの増減に対する弾力的なリソース確保 トラフィック増への対応は、物理サーバーの調達、設置など含め、数ヶ月の時間がかかります。また、物理サーバーがある状態でも、スケールアウトを行おうとした場合に、トラフィックの増加に合わせて新規のサーバーをサービスで利用可能にするまでは時間がかかりました。 主に多量のデータを複製する必要があるところに時間がかかったのですが、 XtraBackup と呼ばれるオンラインバックアップ取得ツールで一貫性のあるバックアップを取得しながら、データを新規サーバーにストリームで転送し、その後リカバリ、そして遅延の解消といった工程が必要で、最終的に利用可能になるまで全作業で 2 日ほどかかりました。 オンプレミス運用からの脱却 自社のデータセンターで物理サーバーをホスティングしている以上、維持、運用にも一定のエンジニアリングが求められます。一方で、自社データセンターでは何千、何万台以上といった規模のサーバーを運用しているわけではないため、該当スキルを全面に押し出して積極採用するわけにもいきません。さらに、世の中全体としてクラウド化が進んできた現在、オンプレミス環境の運用に関する経験を有するエンジニアの採用自体が難しくなりつつあります。 また、現状の自社のサーバー運用規模においては、OS / MySQL のデプロイといったことからは解放された上で、性能問題などを解決し、高効率化したい要望がありました。 移行によりどうなったか 今回、TiDB への移行が完了し、それぞれどうなったかを振り返ります。 長期スケーラビリティーの改善 書き込み性能に関してもスケールアウトにて対応可能になったことで、書き込みキャパシティーが大幅に向上しました。 TiDB 移行とともに、大量の不要なデータを削除していたのですが、この際に削除を含めた書き込みのボトルネックが MySQL 側、つまり高いハードウェアスペックのサーバーにあり、TiDB 側は十分な余力がある状態でした。 弾力的なリソース確保 物理サーバーの調達の時間が必要なくなったのは当然ながら、物理サーバーでのリストアは 1 日を超える時間がかかっていたところ、1 日の中で負荷に合わせてリソースをスケールできるようになりました。 https://engineering.mercari.com/blog/entry/20260421-7b2dff6bce/ このスケールの速度の変化により、より効率的な、具体的には高いリソース利用率目標での運用が可能になりました。また、必要なリソース量に対して、細かい粒度でのリソース利用量の調整が可能になりました。 弾力的なリソース確保 オンプレミス運用からの脱却 必要があれば、オンプレミスの MySQL への依存をなくす目処がたち、採用の問題についての懸念事項解消へ大きく前進しました。 また、OS や MySQL のセットアップ、OS への Security Patch 適用、といった問題への対処からも解放されました。 移行全体の振り返り ここまで、当初の大きな目論見に対して、実際にどうだったかを振り返りました。 ここからは、移行全体でのプロセスとしてうまくいったこと、うまくいかなかったことの振り返りを行います。 うまくいったこと：移行のフロー全体 https://pingcap.co.jp/case-study/mercari-tidb-cloud/ TiDB User Day 2025 でも紹介した上記の切り替えに関する大雑把なフローは、手のかかるものでしたが、事前に多くの課題を抽出可能とし、かつ、仮に問題に直面した場合にも、MySQL に再度トラフィックを戻すことができるシステム構成を整えました。 このような、システムの更新・切り替えに問題があった際に元に戻せるようにすることは、変更の適用における基本事項の 1 つではありますが、愚直にやり切りました。これにより移行の是非の意思決定をスムーズに行うこともでき、移行全体を成功に導きました。 うまくいったこと：バッチエンドポイントの先行リリース データベースには複数のエンドポイントがあり、また、データベースは複数のマイクロサービスから利用されている状況でした。切り替えを段階的に行う方法は複数考えられ、例えば、マイクロサービス毎に読み取りを切り替えていく、などの方法も考えられました。 その中で、マイクロサービス毎の切り替えは行わず、アプリケーションとデータベースの間に ProxySQL とよばれる Proxy を配置し、Reader エンドポイントに対しては、徐々に TiDB にトラフィックをシフトしていくことにしました。 ProxySQL を活用した目的は、大きく 2 つありました。1 つは、多くのマイクロサービスに対して、接続先データベースの切り替えを透過的に行えるようにすることです。もう 1 つは、切り替え主体である DBRE（DataBase Reliability Engineering）チームがトラフィックの切り替えを一元的に管理し、問題発生時に迅速に対応できるようにすることです。 一方で、Reader エンドポイントの中でも、OLAP（Online Analytical Processing）に近いよりリスクの高いクエリを含むエンドポイント（バッチエンドポイントと呼ぶ）へのトラフィックを先行して切り替えることにし、複数の問題を事前に発見し対処することができました。 バッチエンドポイント切り替えは、その他の Reader エンドポイント切り替えの 5 日前に実施しました。その前に、前提となる MySQL から DM（Data Migration）を通じた TiDB へのデータ同期の遅延の問題を先に解消したり、万が一一定の遅延が発生した際に、TiDB から自動的に MySQL に参照先が戻るような実装を行いました。 https://docs.pingcap.com/tidb/stable/dm-overview/ うまくいかなかったこと：クエリリプレイの限界 TiDB クラスタの移行は、大体トラフィックの少ない順に移行を行い、多くのクラスタは予定通りに進行したものの、一番最後に残った最大のトラフィックをかかえるクラスタで、複数回の予定延伸が発生しました。 移行のフローに記載していないこととして、クエリリプレイを行った上で、一定期間、読み取りの実トラフィックを TiDB に流す、という予行演習・テストを複数回実施しました。 実トラフィックを流すことによるテストは、もちろん一定のリスクがありますが、最終的に全てのトラフィックを TiDB で処理しようとしている、ということから、切替えの必要条件として少なくとも一定時間、実際のトラフィックを切り替え後の構成で処理できている必要があります。 最後の最大のトラフィック流量を持つクラスタでは、永続運用を目指す本番の切り替え前に、9 回実トラフィックを一時的に試験的に実際のサービスに切り替えました。日中のトラフィックがあまり変わらない時間帯で短時間テストを行い、最終的にはピークタイムで問題なく処理できることの確認を行なっています。 この 9 回の中には最終的な本番切り替え成功に導くための、多くの失敗、つまり学びが含まれていました。負荷を増やすと明らかになった不具合事象の発見もあれば、象徴的な事象として、100% の負荷を流したところ、必要なノード数が多くなった結果、TiDB Cloud の監視サーバーが想定していない負荷となり、メトリックが何も見えなくなった、といったことも発生しました。 最終的な動作確認は、実トラフィックで必要なものの、例えば、上記であげたハイトラフィックの状態で監視が正常通り稼働するかなど、できるだけ多くの観点を実際のトラフィックに影響を与えずに確認できるのが望ましいです。実トラフィックの 100% を移行先の環境にミラーして比較ができることが理想的です。 これに対して、メルカリではリプレイツールなどを利用してそれに対応していたものの、一定以上のトラフィック量だと、リプレイによる「取りこぼし」がありました。実際のユーザートラフィックに影響を与えず、できるだけ取りこぼさず本番に近い負荷をかけることが目標で、これに対して独自ツールは当初、最大トラフィックの 50% 程度のリプレイが実現できていました。様々なボトルネックの解析などを経て、最終的にはメルカリの負荷の 80% 程度はリプレイ可能になりました。 しかし、この 80% 以上はリプレイでは負荷再現ができず、ピークトラフィックとのギャップを埋めた上で検証を行うため、実トラフィックによる試験を行いました。この 20% の負荷の差分に対しても、いくつかの問題へ直面するポイントがありました。 うまくいかなかったこと：コスト見積もり 規模の小さいクラスタは予想通りのコストに概ね収まっていましたが、大きなクラスタになるにつれ、予想していたコストとの乖離が大きくなり、予想コスト超過になりました。 予想コストとの乖離の最も支配的な要因は、自社のトラフィックを模擬したベンチマークにおいて、実トラフィックのうち最も負荷割合の高い、複数の行の同時取得の SELECT ... FROM xxx WHERE id IN (...) という SQL に対するベンチマークシナリオの再現度が低かったため、と推測しています。 この問題が発生した経緯としては、ベンチマークデータに対して、大量の IN 句の要素を妥当な数用意するところに一定の難しさがありました。id は、かなりの数を用意しないと、短期間で id の候補がなくなってしまう一方で、id の払い出しが性能ネックになったりベンチマークに影響を与えても困ります。実装上の都合からこれを簡易化した結果、ベンチマークにおいて、負荷の期待値を実際よりも低く見積もる結果となりました。 一方で分散データベースにおいては、データが複数ノードに分散している状態での取得の再現度は極めて重要であり、これに失敗した結果、実際に多くのコンピュートリソースが必要となりました。 移行後に得られた想定以上の効果 全ての DDL（Data Definition Language）に対する運用上の負荷が大きく下がりました。 以前はオンラインスキーマ変更のツールである gh-ost を利用しており、概ね変更の安定性については満足していたものの、次のような問題がありました。 一部のケースでは gh-ost が使えない 大規模なテーブルの変更は時間がかかる、数週間かかることもある TiDB では、DDL がオンラインで行われることはもちろん、分散データベースにおける分散実行、DXF（TiDB Distributed eXecution Framework）がとても効いており、基本的には全ての DDL が、MySQL に比べて非常に短期間で完了します。具体的には、数週間かかるものが数時間になる、などのケースがいくつか観測されました。 https://docs.pingcap.com/tidb/stable/tidb-distributed-execution-framework/ このように、DDL に対する運用負荷が下がった結果、一部の非常に大規模なテーブルについては、そのテーブルに関わる設計変更を検討した際に、大規模テーブルの定義の変更を見送るような設計をしがちだったのに対し、どちらのテーブル定義であるべきか、というあるべき論に基づき変更が検討しやすくなりました。 この変化により、テーブル設計の修正を含む最適化などがとてもしやすくなりました。 なお、下記の記事のように、稀なケースで TiDB で DDL にとても時間がかかるケースも観測しましたが、最新のバージョンでは改善されております。 https://engineering.mercari.com/blog/entry/20260304-b782487108/ 現在の課題 ここまでで、移行のプロセスでうまくいった点、うまくいかなかった点、移行後に思ったより良かったことについて振り返りました。 最後に、TiDB の移行完了後に対応した、あるいは現在対応している課題についてお知らせします。 分散データベースへの適応 TiDB 切り替え後に、TiDB が分散データベースであることに関連するいくつかの問題への対処を行いました。こちらも追加のブログ記事の公開を予定しております。 コストの問題・安定性の向上 現在のところ、TiDB は全体として非常に安定して稼働しております。 しかし、コスト見積もりが当初予測より上振れたことから、コストの最適化を積極的に行なっております。コストの最適化は、安定性と相反するところであり、最適化を行うことで明らかになる質的な問題を 1 つずつ解消していっております。 ストックアウト問題への対応 クラウドへの移行により、基本的には弾力的なリソース確保ができるようになった一方で、近日のクラウドリソース需要の高まりにより時折発生している、ストック不足のリスクにどのように対応するか、といった検討・検証をしています。 バージョンアップへの対応 TiDB は機能追加や改善の速度が非常に速く、かつ、バージョンアップもオンラインで可能です。 そのため、バージョンアップに迅速に追従し、バージョンアップの恩恵を受けることは TiDB を運用する上では重要です。 一方で、TiDB Cloud では、現状、ダウングレードへのサポートがないため、万が一問題に直面した際に、元のバージョンへ戻せるような仕組みでバージョンアップを行う必要があります。このための手順を確立したり、バージョンアップに対する検証を簡易化するためのツールを開発しています。 TiDB への移行によって多くの課題は解消されましたが、移行完了はゴールではなく、新しい運用フェーズの始まりでもあります。分散データベースやクラウド環境を前提とした運用に適応しながら、コスト、安定性、バージョンアップ対応などを継続的に改善していく必要があります。 まとめ この記事では、メルカリの中核データベースである CoreDB を MySQL から TiDB へ移行した取り組みを振り返りました。TiDB への移行により、当初の目的であった長期的なスケーラビリティの改善、トラフィックの増減に対する弾力的なリソース確保、そしてクラウド化による運用負荷の軽減について、大きな前進がありました。 移行プロセスでは、事前に設計した移行フローが有効に機能し、ProxySQL を活用したトラフィック切り替えの一元管理や、リスクの高いエンドポイントの先行切り替えによって、問題を段階的に発見・解消できました。一方で、実トラフィックを用いた予行演習では多くの学びがあり、トラフィックリプレイの再現性やコスト見積もりには課題も残りました。 移行後には、DDL の運用負荷が想定以上に下がるなど、TiDB の利点も見えてきました。同時に、分散データベースやクラウド環境を前提とした運用では、コスト、安定性、リソース確保、バージョンアップ対応など、継続的に向き合うべきテーマもあります。今回の移行で得た学びを活かしながら、今後も CoreDB の運用をより安定的で持続可能なものに改善していきます。 おしらせ 最後に、現在メルカリでは、この記事の発行者の所属する DBRE チームの EM（Engineering Manager）および IC（individual Contributor）を募集しています。 この記事を読んで興味を持たれた方は、その旨をお知らせください。 詳しくは以下をご覧ください。 EM: https://apply.workable.com/mercari/j/7AD4EF9218/ IC: https://apply.workable.com/mercari/j/ACD2689E9E/

本ブログは 2026 年 7 月 30 日に公開された AWS Blog “ Extend Amazon Inspector SBOM Generator with Plugins ” を翻訳したものです。 Amazon Inspector は、 Amazon Web Services (AWS) のワークロードを継続的にスキャンしてソフトウェアの脆弱性を検出する、自動化された脆弱性管理サービスです。Amazon Inspector の脆弱性管理機能は、 Amazon Inspector SBOM Generator (inspector-sbomgen) と呼ばれる資産インベントリエンジンによって支えられています。これはスタンドアロンのコマンドラインツールで、コンテナイメージ、ディレクトリ、アーカイブ、ローカルシステム、コンパイル済みバイナリなどから ソフトウェア部品表 (SBOM) を生成します。過去 2 年間で、AWS は inspector-sbomgen のカバレッジを数十のプログラミング言語エコシステム、オペレーティングシステム、広く導入されているアプリケーションへと拡大してきました。 今回、inspector-sbomgen を利用するビルダー向けの新機能として、独自のカスタムパッケージコレクターを記述できる プラグインシステム を発表します。ソースコードのコンパイルや公式リリースを待つ必要はなく、すぐに使い始めることができます。 inspector-sbomgen の最新バージョンは、 Amazon Inspector ユーザーガイド からダウンロードできます。 この記事では、inspector-sbomgen プラグインシステムでできること、これを構築した理由、そして数分で最初のプラグインを書く方法を紹介します。あわせて、プラグインが生成したパッケージコンポーネントを Amazon Inspector の脆弱性スキャンと統合する方法や、セキュリティが強化された予測可能なプラグイン動作を実現するプラグインの安全性モデルについても解説します。 プラグインシステムを構築した理由 ソフトウェアのエコシステムは動的です。新しい言語パッケージマネージャー、ロックファイル形式、エンドユーザーアプリケーションが絶えずリリースされ、その多くは迅速に採用されます。中にはセキュリティの検証がほとんど行われないまま使われるものもあります。その結果、セキュリティチームには可視性のギャップが残ります。つまり、SBOM ツールがまだ認識できないソフトウェアが本番ワークロードで動いているという状態です。お客様からは、こうしたエコシステムの多くを直接インベントリ化したいという要望をいただいてきました。最近まで、それを実現する唯一の方法は、機能リクエストを出して inspector-sbomgen チームがエコシステムに対応し、新しいリリースをデプロイするのを待つことでした。 inspector-sbomgen プラグインシステムは、この状況を変えます。プラグインを使うと、次のことができます。 inspector-sbomgen が標準では対応していないエコシステムへの対応 – 新しいオープンソースエコシステム、ニッチまたは変化の速いパッケージ形式、組織独自のツールなど、inspector-sbomgen を変更することなくインベントリ化できます エコシステム検出の迅速なプロトタイピング – 開発者にも AI コーディングアシスタントにも扱いやすいプラグインシステムを設計しました。プラグインは Lua で記述され、実行時にロードされるため、Go ツールチェーンもコンパイルも不要です。組み込みのテストハーネスを使ってプラグインを繰り返し改善し、すぐに結果を確認できます 安定した基盤の上での構築 – プラグイン API はアーティファクトの種類による違いを抽象化するため、検出ロジックを一度書くだけで、コンテナイメージ、アーカイブ、ローカルシステムなどでシームレスに動作します。また、プラグインは sbomgen の内部構造から分離されているため、コアツールでリグレッションが発生した場合の影響範囲も小さく抑えられます 実際、私たち自身もこのプラグインシステムを内部で活用し、新しいエコシステムのカバレッジを以前より速く提供できるようになりました。 1.13 リリース では、Apache Tomcat、NGINX、MySQL、Redis、WordPress、OpenSSH ツールチェーンなど、これまで Go で実装されていた 20 以上のエコシステムが、プラグインとして sbomgen バイナリに組み込まれています。同じリリースでは、Apache Cassandra、Apache Struts、Conda、Swift パッケージ、AI エージェントコレクター (Amazon Q Developer、Kiro CLI、Claude Code、GitHub Copilot、Ollama) など、10 を超える新しいエコシステムもプラグインとして追加されました。 inspector-sbomgen プラグインの仕組み sbomgen プラグインは 2 段階のパイプラインで動作します。 検出 (discovery) – アーティファクトのファイルシステムをスキャンし、インストール済みパッケージのメタデータを含むファイルを特定します 収集 (collection) – 検出された各ファイルを開き、ファイルの内容を解析して、結果を SBOM にパブリッシュします 内部では、イベントバスが検出プラグインと収集プラグインをつないでいます。検出プラグインは検出したファイルの一覧をイベントとしてパブリッシュし、1 つ以上の収集プラグインがそのイベントをサブスクライブして、パッケージ収集をトリガーします。開発者にとっては、これは オブザーバーパターン としておなじみの動作でしょう。 この分離により、1 つの検出プラグインが複数のコレクターにデータを供給できます。例えば、あるコレクターはパッケージメタデータを抽出し、別のコレクターはシークレットをスキャンし、さらに別のコレクターはポリシーをチェックする、といった構成が可能です。各収集プラグインは、計算コストの高いアーティファクトファイルシステムの再走査を行うことなく、同じファイルリストを利用できます。 5 分で書ける最初のプラグイン inspector-sbomgen を使えば、プラグイン環境を簡単にセットアップできます。 plugin new コマンドで sbomgen に新しいプラグインワークスペースを作成させ、 --with-example フラグを指定すると、すぐに実行できる検出プラグインと収集プラグインのペアがワークスペースに用意されます。 inspector-sbomgen plugin new --with-example 上記のコマンドを実行すると、プラグイン名と、プラグインワークスペースを格納するディレクトリの入力を求められます。カスタム値を指定することも、デフォルト値をそのまま使うこともできます。 Plugin name (identifies the software ecosystem your plugin will inventory, e.g. debian-dpkg, rhel-rpm, python-pip, cmake) [my-custom-ecosystem]: <enter> Project directory [my-sbomgen-plugins]: <enter> Created plugin "my-custom-ecosystem" in my-sbomgen-plugins/ なお、対応するコマンドラインインターフェイス (CLI) 引数でプラグイン名とディレクトリを指定すれば、対話形式のプロンプトをスキップできます。 inspector-sbomgen plugin new \ --with-example \ --name my-custom-ecosystem \ --path my-sbomgen-plugins プラグインワークスペースを作成すると、inspector-sbomgen は次のステップを案内する画面を表示します。開発者や AI コーディングアシスタントに対して、変更が必要なソースファイルや関連ドキュメントの場所を示してくれます。 Next steps: Get started: 1. Open plugin folder in a code editor (VS Code recommended) 2. Add test files that your plugin will discover and parse (e.g., config files, lockfiles, binaries, etc.): my-sbomgen-plugins/discovery/cross-platform/extra-ecosystems/my-custom-ecosystem/_testdata/ Develop: 3. Edit discovery: my-sbomgen-plugins/discovery/cross-platform/extra-ecosystems/my-custom-ecosystem/init.lua 4. Edit collection: my-sbomgen-plugins/collection/cross-platform/extra-ecosystems/my-custom-ecosystem/init.lua Test: 5. Write unit tests: my-sbomgen-plugins/discovery/cross-platform/extra-ecosystems/my-custom-ecosystem/init_test.lua 6. Run unit tests: inspector-sbomgen plugin test --path my-sbomgen-plugins Deploy: 7. Distribute your plugin directory wherever you run inspector-sbomgen: inspector-sbomgen <arguments> --plugin-dir /path/to/my-sbomgen-plugins Example: inspector-sbomgen container --image alpine:latest -o /tmp/sbom.json --plugin-dir /path/to/my-sbomgen-plugins For code completion, install the VS Code Lua language server extension: https://luals.github.io/#vscode-install For more information: - Plugin guide: my-sbomgen-plugins/docs/sbomgen-plugin-developer-guide.md - Testing guide: my-sbomgen-plugins/docs/sbomgen-plugin-testing-guide.md - API reference: my-sbomgen-plugins/docs/sbomgen-plugin-api-reference.md - Documentation: https://docs.aws.amazon.com/inspector/latest/user/sbom-generator.html プラグインワークスペースができたので、その中身を詳しく見てみましょう。 tree my-sbomgen-plugins ├── AGENTS.md ├── collection │   └── cross-platform │   └── extra-ecosystems │   └── my-custom-ecosystem │   └── init.lua ├── discovery │   └── cross-platform │   └── extra-ecosystems │   └── my-custom-ecosystem │   ├── _testdata │   │   ├── empty │   │   └── example.lock │   ├── init_test.lua │   └── init.lua ├── docs │   ├── sbomgen-plugin-api-reference.md │   ├── sbomgen-plugin-developer-guide.md │   └── sbomgen-plugin-testing-guide.md ├── library │   └── sbomgen.lua └── README.md スキャフォールディングされたプロジェクトには、動作する検出プラグインと収集プラグインのペア、 _testdata/ 配下のテストフィクスチャを使ってパスするユニットテスト、統合開発環境 (IDE) 連携用の .vscode/settings.json 、開発者ドキュメントのローカルコピーが含まれています。 スキャフォールディングは、人間と AI コーディングアシスタントの両方が読みやすいように、意図的に簡潔で完結した内容になっています。各ファイルには、それぞれの関数の役割と、プラグイン作成者が記述すべき箇所を説明する明確なコメントが付いています。 プラグインをテストするには、まずパッケージロックファイルやコンパイル済みバイナリなど、スキャン対象となるものが必要です。サンプルプラグインは、次の内容を持つ架空の example.lock をインベントリ化します。 my-package-alpha==1.0.0 my-package-beta==2.3.1 my-package-gamma==0.9.5 付属の検出プラグインは、アーティファクトのファイルシステム内で example.lock のインスタンスを探す方法を知っています。 -- my-custom-ecosystem discovery plugin -- Discovers example.lock files in the artifact file list. function discover() return sbomgen.find_files_by_name({"example.lock"}) end そして、付属の収集プラグインは、 example.lock の内容を解析し、パッケージ情報を出力 SBOM にパブリッシュする方法を知っています。 -- my-custom-ecosystem collection plugin -- Parses example.lock files and extracts package name and version. function collect(file_path) local content = sbomgen.read_file(file_path) if content == nil then return end for line in content:gmatch("[^\n]+") do local name, ver = line:match("^(.+)==(.+)$") if name and ver then sbomgen.push_package({ name = name, version = ver, purl_type = "generic", namespace = "my-custom-ecosystem", component_type = sbomgen.component_types.APPLICATION, }) end end end テストの実行 プラグインにはテストフレームワークが組み込まれているため、実際のアーティファクトをスキャンする前にロジックを検証できます。テストは Lua で記述し、プラグインと同じ場所の init_test.lua に配置して、 _testdata/ 内のフィクスチャデータを参照します。 function test_discovers_packages() local result = testing.scan_directory("_testdata") testing.assert_equals(3, #result.findings) testing.assert_equals("my-package-alpha", result.findings[1].name) testing.assert_equals("1.0.0", result.findings[1].version) end function test_no_findings_for_empty_directory() local result = testing.scan_directory("_testdata/empty") testing.assert_equals(0, #result.findings) end 次のコマンドでテストを実行します。 inspector-sbomgen plugin test --path my-sbomgen-plugins -v === RUN my-custom-ecosystem/discovery/init_test/test_discovers_packages --- PASS: my-custom-ecosystem/discovery/init_test/test_discovers_packages (0.04s) === RUN my-custom-ecosystem/discovery/init_test/test_no_findings_for_empty_directory --- PASS: my-custom-ecosystem/discovery/init_test/test_no_findings_for_empty_directory (0.04s) ok 2 tests passed これは、私たちが設計し得た最も短い開発ループです。Go ツールチェーンも、再ビルドも、コンテナの起動も不要です。テストを書き、実行し、繰り返し改善するだけです。 実際のアーティファクトのスキャン プラグインが結果を生成するには、プラグインが探すファイルを含むアーティファクトを inspector-sbomgen に与える必要があります。サンプルプラグインの場合、 example.lock ファイルを含む任意のディレクトリが対象になります。先ほど生成したフィクスチャがちょうど良い題材です。 inspector-sbomgen directory \ --plugin-dir ./my-sbomgen-plugins \ --path ./my-sbomgen-plugins/discovery/cross-platform/extra-ecosystems/my-custom-ecosystem/_testdata \ -o sbom.json --plugin-dir フラグは、Lua プラグインの読み込み元を inspector-sbomgen に伝えます。生成される SBOM には、 example.lock 内の 3 つのパッケージそれぞれに対応する CycloneDX コンポーネントが含まれます。例を以下に示します。 { "bom-ref": "comp-2", "type": "application", "name": "my-package-alpha", "version": "1.0.0", "scope": "optional", "purl": "pkg:generic/my-sbomgen-plugin/my-package-alpha@1.0.0", "properties": [ { "name": "amazon:inspector:sbom_generator:source_path", "value": "./my-sbomgen-plugins/example.lock" } ] } プラグインが生成するすべてのコンポーネントには、収集元のファイルを記録する amazon:inspector:sbom_generator:source_path プロパティが付いています。そのため、コンポーネントを生成元のアーティファクトまで常にたどることができます。 Amazon Inspector による脆弱性スキャン プラグインが生成したパッケージ情報は、他のコンポーネントと同等の正式な SBOM コンポーネントとして扱われます。Amazon Inspector を含め、CycloneDX SBOM を読み取るあらゆる下流のツールで利用できます。SBOM を Amazon Inspector に送信して脆弱性分析を行うには、 --scan-sbom フラグを追加します (有効な AWS アカウントが必要です)。 inspector-sbomgen directory \ --path ./my-sbomgen-plugins/discovery/cross-platform/extra-ecosystems/my-custom-ecosystem/_testdata \ --plugin-dir ./my-sbomgen-plugins \ --scan-sbom \ --aws-profile your_profile \ --aws-region your_region \ -o /tmp/sbom.json まったく新しいエコシステムに対応する際の重要な注意点 : プラグイン作成者は任意のエコシステムをインベントリ化できますが、Amazon Inspector が脆弱性を報告できるのは、アドバイザリが存在するコンポーネントに限られます。アドバイザリフィードにまだ含まれていないエコシステムのコンポーネントを Amazon Inspector に渡すと、Amazon Inspector は Component skipped: no supported rules found (コンポーネントはスキップされました: サポートされるルールが見つかりません) というプロパティ付きでコンポーネントを返します。以下に例を示します。 { "bom-ref": "comp-1", "name": "my-package-alpha", "properties": [ { "name": "amazon:inspector:sbom_scanner:path", "value": "my-sbomgen-plugins/discovery/cross-platform/extra-ecosystems/my-custom-ecosystem/_testdata/example.lock" }, { "name": "amazon:inspector:sbom_scanner:info", "value": "Component skipped: no supported rules found." } ], "purl": "pkg:generic/my-custom-ecosystem/my-package-alpha@1.0.0", "type": "application", "version": "1.0.0" } これはエラーではなく、想定どおりの動作です。SBOM は正しく生成され、コンポーネントは引き続き追跡され、 source_path によってどのファイルから生成されたかを正確に把握できます。Amazon Inspector がそのエコシステムのアドバイザリカバレッジを追加すれば、プラグインを一切変更することなく、同じ SBOM から脆弱性の検出結果が生成されるようになります。Amazon Inspector がすでにサポートしているエコシステムについては、プラグインが生成したコンポーネントは組み込みスキャナーが生成したコンポーネントと区別なく扱われます。 ファーストクラスの IDE サポート AWS は、プラグインを書くときの生産性と効率を重視しています。オートコンプリートのようなモダンな便利機能なしで Lua を書くのは快適とは言えません。そのため、 plugin new コマンドでスキャフォールディングされたすべてのプラグインプロジェクトには、 library/sbomgen.lua 定義ファイルと、それを VS Code の Lua Language Server 拡張機能に自動的に接続する .vscode/settings.json が付属します。 コード補完と IDE サポートを利用するには、まず sumneko.lua 拡張機能をインストールし、VS Code でプラグインプロジェクトを開きます。これにより、すべての sbomgen.* 関数で次の機能が使えるようになります。 型情報付きのパラメータヒント ホバー時のドキュメント表示 定数のオートコンプリート ( sbomgen.component_types.* 、 sbomgen.groups.* 、 sbomgen.platform.* ) 関数呼び出しの型チェック push_package() に必須フィールドが欠けている場合のインライン警告 この定義ファイルのおかげで、AI コーディングアシスタントによるプラグイン開発もうまく機能します。型情報とドキュメントがツールで読み取れる形式で埋め込まれているため、アシスタントは、素の Lua で記述する場合に比べてはるかに少ない人手の確認で正しいプラグインコードを生成できます。 安全な基盤 プラグインは inspector-sbomgen と同じプロセス内で実際のコードを実行するため、そのコードが安定し、セキュリティが強化された状態を保てるように実行環境を設計しました。すべての Lua プラグインは隔離されたサンドボックス内で実行されます。各 Lua 仮想マシン (VM) は、安全な操作のみが許可されるように、Lua 標準ライブラリの制限されたサブセットにのみアクセスできます。 ファイルシステムへの直接アクセスの禁止 – Lua の io ライブラリはロードされません。すべてのファイル操作は sbomgen.* 関数を経由して sbomgen の内部処理にルーティングされるため、ディスク上のディレクトリ、コンテナイメージ、圧縮アーカイブ、マウントされたボリュームのいずれをスキャンする場合でも、プラグインは同じように動作します サブプロセスの実行や環境の変更の禁止 – Lua の os ライブラリはブロックされているため、プラグインはプロセスの起動、環境変数の変更、アーティファクト外のファイルへのアクセスができません VM のイントロスペクションの禁止 – Lua の debug ライブラリはブロックされています 無制限なコードロードの禁止 – dofile 、 loadfile 、 loadstring は削除されています。 require() は利用できますが、プラグイン自身のディレクトリツリーに制限されているため、プラグインは自身のヘルパーモジュールを共有できる一方、他のプラグインやシステムパスからコードをロードすることはできません プラグインが未処理の Lua エラーを発生させた場合、inspector-sbomgen は警告をログに記録し、次のファイルまたはプラグインの処理を続行します。1 つの不具合のあるプラグインが他のプラグインの実行を妨げることはありません。また、プラグインが inspector-sbomgen の組み込みパッケージコレクターを上書きすることもありません。すべてのプラグインは一意の名前を宣言する必要があり、カスタムプラグインが公式の組み込みプラグインですでに使われている名前を使用した場合、そのカスタムプラグインは警告付きでスキップされます。組み込みプラグインが常に優先されるため、カスタムプラグインがツール自身の検出動作をひそかに置き換えたり隠したりすることはできません。 次のステップ 今すぐ独自のプラグインの構築を始めるには、次の手順に従ってください。 Amazon Inspector ユーザーガイド から最新の inspector-sbomgen をインストールします inspector-sbomgen plugin new --with-example を実行し、プロンプトに従います inspector-sbomgen plugin test --path ./my-sbomgen-plugins -v を実行し、サンプルテストがパスすることを確認します サンプルのロジックを、独自のエコシステム向けの検出ロジックに置き換えます すべての関数、定数、コマンドについては、以下の完全なリファレンスドキュメントで詳しく説明しています。 Lua プラグイン開発者ガイド : プラグインの概念、ディレクトリ構造、ライフサイクル Lua プラグインテストガイド : テストフレームワークのリファレンスとフィクスチャの規約 Lua プラグイン API リファレンス : sbomgen.* API の完全なカタログ まとめ 組織独自のロックファイル形式への対応の追加、新しいオープンソースエコシステム向け検出のプロトタイピング、あるいは自作スキャナーから組織全体で大規模に運用できる仕組みへの置き換えなど、どのような用途であっても、このプラグインシステムは、アイデアから動作する SBOM までの道のりをできる限り短くするように設計されています。皆さんがこれを使って何を作るのか、とても楽しみにしています。 この記事に関するご質問がある場合は、 AWS サポートにお問い合わせください 。 Michael Long Michael は AWS の Amazon Inspector 担当 Senior Security Researcher です。Amazon Inspector SBOM Generator と Amazon Inspector for GitHub Actions の研究開発を率いています。AWS 入社前は、MITRE ATT&CK チームで principal adversary emulation engineer を務めていました。また、U.S. Army (米国陸軍) で約 10 年間、軍事情報およびサイバー作戦に従事しました。 Charlie Bacon Charlie は AWS の Amazon Inspector 担当 Head of Security Engineering and Research です。Amazon Inspector や他の Amazon Security の脆弱性管理ツールを支える脆弱性スキャンおよびインベントリ収集サービスを担当するチームを率いています。AWS 入社前は、金融業界とセキュリティ業界で 20 年間にわたり、研究と製品開発の両分野で上級職を務めました。 Anthony Verleysen Anthony は Amazon Inspector 担当の Senior Technical Product Management です。Amazon Inspector の前は、AWS Systems Manager の Product Manager として Node Management 機能を担当していました。仕事以外では、テニスとサッカーに熱心に取り組んでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

G-gen の杉村です。2026年7月に発表された、Google Cloud や Google Workspace のイチオシアップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに Google Cloud Next Tokyo 26 の開催 Google Cloud のアップデート Bigtable で Google フロントエンドをバイパスする Direct connectivity が登場 Gemini Enterprise app で東京リージョン（asia-northeast1）がサポート Cloud Run でサブプロセスとしてのサンドボックス環境が Preview 公開 C4N マシンシリーズが一般公開 BigQuery で多段階集計（Multi-level aggregation）が記述可能に（Preview） BigQuery の予約の Project caps（scheduling policies）が Preview BigQuery Conversational Analytics で AI.AGG 関数が使用可能に Google Skills 受講で資格の1年間延長が可能に Cloud NGFW Enterprise ティアで WildFire によるマルウェア検知が Preview Cloud SQL の Data API（executeSql）で Secret Manager 認証が可能に 「Gemini 3.6 Flash」と「Gemini 3.5 Flash-Lite」が公開（GA） コードセキュリティエージェント「CodeMender」が Preview 提供開始 AlloyDB for PostgreSQL で Transparent query forwarding が Preview 公開 利用料金に上限を設ける Spend cap budget が Public Preview 公開 BigQuery で追加・変更履歴を確認できる APPENDS/CHANGES関数が一般公開 AlloyDB で書き込みエンドポイントが Preview 公開 AlloyDB でクロスリージョンフェイルオーバーが Preview 公開 Dataform で Deployments 機能が Preview 公開 Google Cloud の Agent Platform で Feedback service が Preview 公開 Gemini 2.5 系モデルが Extended Lifecycle Access（ELA）扱いに Global external passthrough Network Load Balancer が Preview 公開 Google Workspace のアップデート Google Vids で Google スライドの動画へのAI変換機能が日本語に対応 Google Workspace でインバウンド SCIM API が一般公開（GA） Google Chat で組織外ユーザーとのグループ DM が使用可能に Google スプレッドシートが「集合縦棒 - 折れ線」などのグラフタイプに対応 Google Meet で録画や議事メモが会議ごとのサブフォルダに整理されるように Google Meet の自動メモ作成で投影物のスクリーンショット保存されるように Google ドキュメントで、画像、図、インフォグラフィックを生成可能に Google Forms で自然言語指示によるクイズ自動生成が可能に はじめに 当記事では、毎月の Google Cloud（旧称 GCP）や Google Workspace（旧称 GSuite）のアップデートのうち、特に重要なものをまとめます。 また当記事は、Google Cloud に関するある程度の知識を前提に記載されています。前提知識を得るには、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp リンク先の公式ガイドは、英語版で表示しないと最新情報が反映されていない場合がありますためご注意ください。 Google Cloud Next Tokyo 26 の開催 Google Cloud の年次旗艦イベントの東京版、Google Cloud Next Tokyo が、東京ビッグサイトにおいて7月29日（木）から30日（金）までの2日間、開催された。 スポンサーによるエキスポエリアでの展示や、キーノート（基調講演）、各種ブレイクアウトセッション、スポンサーセッションなどが行われ、国内での AI エージェント事例などが発表された。 キーノート（基調講演）については、以下の記事を参照されたい。 blog.g-gen.co.jp Google Cloud のアップデート Bigtable で Google フロントエンドをバイパスする Direct connectivity が登場 Direct connectivity (2026-07-06) Bigtable で Google フロントエンドを介さずにバックエンドへ直接通信する「直接接続（Direct connectivity）」が利用可能に。 VPC 内の VM からの通信、かつ特定条件を満たすトラフィックに適用されネットワークのホップ数が減り、レイテンシ低減とスループットが向上。 Gemini Enterprise app で東京リージョン（asia-northeast1）がサポート Gemini Enterprise release notes - July 06, 2026 (2026-07-06) Gemini Enterprise app および NotebookLM Enterprise で、東京（asia-northeast1）と英国（europe-west2）リージョンがサポート。 ただし Allowlist 付き一般公開（GA with allowlist）のため申請が必要。 これにより、データの保管（DRZ）と機械学習の処理（MLP）を日本国内のインフラで完結できる。Gemini 3.5 Flash モデルも対象に含まれる。 Cloud Run でサブプロセスとしてのサンドボックス環境が Preview 公開 Configure sandboxes for services (2026-07-08) Cloud Run サービスで、サブプロセスとしてサンドボックス環境を起動し AI エージェントツールや信頼できないコードを実行できる機能が Preview 公開。 メインのアプリから分離して動的なコード実行が可能。以下の解説記事も参照。 blog.g-gen.co.jp C4N マシンシリーズが一般公開 C4N machine series (2026-07-08) Compute Engine で C4N マシンシリーズが一般公開。C4N は、ネットワーク最適化マシンシリーズ。 スペック 第5世代 Intel Xeon Scalable processors（Emerald Rapids）を搭載 ネットワーク帯域 最大 400 Gbps ストレージ I/O 最大 25 GiB/s、1M IOPS （Hyperdisk Extreme） ユースケース ネットワーク・セキュリティアプライアンス 高性能データベース 大規模データ分析 分散ファイルシステム BigQuery で多段階集計（Multi-level aggregation）が記述可能に（Preview） Multi-level aggregation (2026-07-08) BigQuery の SQL で多段階集計（Multi-level aggregation）が記述可能になった（Preview）。集計関数の引数に別の集計関数を入れられる。 サブクエリや CTE を使わず、単一の SELECT 句で記述可能になり、クエリが簡素化する。以下はクエリのサンプル。 SELECT Product, AVG ( SUM (revenue) GROUP BY DATE (time)) AS avg_daily_sales FROM Sales GROUP BY Product ORDER BY Product; BigQuery の予約の Project caps（scheduling policies）が Preview Project caps and scheduling policies (2026-07-13) BigQuery の予約（Reservation）で、プロジェクト単位で最大スロット使用量と同時実行数（並列度）を制限できる Project caps（scheduling policies）が Preview 提供開始。 特定プロジェクトによるリソースの独占を防ぎワークロードの優先順位付けが可能になる。 BigQuery Conversational Analytics で AI.AGG 関数が使用可能に BigQuery AI and ML support (2026-07-14) BigQuery の Conversational Analytics（会話型分析）で AI.AGG 関数が使用可能になった。 AI.AGG は「意味論的な集計」とでもいえる機能で、マルチモーダルなデータを要約したり分析して文字列を返す関数。画像分析、コンテンツ要約、ログ分析などに使用できる。AI.AGG 関数自体はまだ Preview 公開である点に留意が必要。 Google Skills 受講で資格の1年間延長が可能に Google Cloud 認定資格を最新の状態に保ち、キャリアアップを図る新しい方法 (2026-07-15) Google Cloud 認定資格に、新しい更新方法が登場。 従来は試験を受験する必要があったが一部の資格は Google Skills（オンラインラボ）の所定コース受講でも更新（1年間延長）できるようになった。CDL、ACE、PCA、PDE がこの更新方法に対応している。 Cloud NGFW Enterprise ティアで WildFire によるマルウェア検知が Preview WildFire overview (2026-07-20) Google Cloud の Cloud NGFW Enterprise ティアで Palo Alto の脅威分析サービス「WildFire」によるマルウェア検知が Preview 提供開始。 サンドボックスとリアルタイム機械学習を組み合わせ VPC を通過するファイル転送を詳細に検査。ゼロデイ攻撃にも対応可。 Cloud SQL の Data API（executeSql）で Secret Manager 認証が可能に データベース ユーザーを構成する (2026-07-20) Cloud SQL for PostgreSQL/MySQL の Data API（executeSql）で Secret Manager による認証が可能になった。 Data API（executeSql）とは、Cloud SQL Admin API 経由で SQL を実行できる機能。 データベースのパスワードを Secret Manager のリージョンシークレットに保存しておき、API リクエスト時にそのリソース名を渡すことで認証。これにより、アプリケーション側でパスワードを保持する必要がなくなり、認証情報の漏洩リスク低減と管理の簡素化に繋がる。 「Gemini 3.6 Flash」と「Gemini 3.5 Flash-Lite」が公開（GA） Introducing Gemini 3.6 Flash, 3.5 Flash-Lite, and 3.5 Flash Cyber (2026-07-21) Google が新しい AI モデル「Gemini 3.6 Flash」と「Gemini 3.5 Flash-Lite」を公開（GA）。 コード生成やマルチモーダル推論の精度などが向上したほか、Flash については 3.5 よりもトークン効率が向上したとされる。top-K、top-P パラメータは使用できなくなった。レスポンスも高速化された印象。 また Google が「Gemini 3.5 Flash Cyber」を発表。脆弱性の発見、検証、パッチ適用を行うサイバーセキュリティモデル。limited-access pilot program として政府機関および信頼できるパートナー企業のみに提供される。 コードセキュリティエージェント「CodeMender」が Preview 提供開始 Now in preview: Find and fix software vulnerabilities with CodeMender (2026-07-22) Google がコードセaキュリティエージェント「CodeMender」を Preview 提供開始。 CI/CD パイプラインや IDE との統合や CLI を通じ、脆弱性の検知、修復、パッチ適用を補助。 AlloyDB for PostgreSQL で Transparent query forwarding が Preview 公開 Optimize resources and isolate read queries with transparent query forwarding (2026-07-20) AlloyDB for PostgreSQL で Transparent query forwarding が Preview 公開。 プライマリノードへの読み取りクエリが、自動的にリードプールインスタンスにフォワードされ、負荷分散される。アプリ側でエンドポイントを意識せずとも読み取り負荷の分散が可能になる。 従来は、 書き込みワークロードはプライマリインスタンス（書き込み/読み取り IP アドレス）へ、読み取りワークロードはリードプールインスタンス（読み取り IP アドレス）へ、それぞれ差し向ける必要があった。今後（Transparent query forwarding 使用）は、Transparent query forwarding を有効化して、すべてのクエリをプライマリインスタンスへ投入するだけでよくなる。 利用料金に上限を設ける Spend cap budget が Public Preview 公開 Manage spend cap budgets (2026-07-27) Google Cloud の利用料金に上限を設ける Spend cap budget が Public Preview 公開。予算を超過した際に新規リクエストを停止してそれ以上の課金を防止できる。 対応サービスは Gemini API、Agent Platform、Cloud Run、Cloud Run functions。 ただし重要な制限として、Google Cloud パートナー経由の請求先アカウントで 当機能は使用できない 。 2026年7月下旬現在、実際には使用できてしまっているが、今後修正され使用不可になる見込み。 BigQuery で追加・変更履歴を確認できる APPENDS/CHANGES関数が一般公開 Work with change history (2026-07-27) BigQueryでテーブルの追加・変更履歴を確認できる APPENDS() 関数、 CHANGES() 関数が一般公開（Preview → GA）。 それぞれ、指定期間内に追加された行 / 変更された行の一覧を返す関数。データパイプラインの増分更新やデータ監査に有用。CHANGES 関数は事前にテーブルでオプションを有効化する必要あり。 AlloyDB で書き込みエンドポイントが Preview 公開 Manage database connections with write endpoints (2026-07-27) AlloyDB で書き込みエンドポイントが Preview 公開。プライマリインスタンスを指すDNS名。 任意のインスタンスを指すよう設定できるため、バックアップから新規インスタンスを起動した際等も、アプリ側の構成変更が不要なまま新しい向き先を指定できる DB 移行の際にも使用できる。 AlloyDB でクロスリージョンフェイルオーバーが Preview 公開 Advanced disaster recovery (2026-07-27) AlloyDB でクロスリージョンフェイルオーバーが Preview 公開。 セカンダリクラスタをプライマリに昇格した際、旧プライマリの再構築を自動化し、レプリケーション構成を維持することが可能。従来は必要だったクラスタの手動削除や再作成が不要になる。 Dataform で Deployments 機能が Preview 公開 Create and manage deployments (2026-07-27) Dataform で Deployments 機能が Preview 公開。 リモート Git リポジトリ上のコードをスケジュール実行する機能。従来より対応する GitHub、GitLab、Bitbucket、Azure DevOps Services などに格納する SQLX ソースコードを直接呼び出して実行できる。 Google Cloud の Agent Platform で Feedback service が Preview 公開 Feedback service overview (2026-07-29) Google Cloud の Agent Platform で Feedback service が Preview 公開。 Agent Runtime の session と紐づけてユーザーフィードバック（サムズアップ、ダウン）を送信。Google Cloud コンソールでも結果を閲覧できる。 Gemini 2.5 系モデルが Extended Lifecycle Access（ELA）扱いに Model versions and lifecycle (2026-07-30) Google からの管理者宛て通知で、Gemini 2.5 Pro、Flash、Flash Liteが 2026-10-20 から Extended Lifecycle Access (ELA) に入ることが通知された。ただし、ELA についてはドキュメントに記載がなく、通知メールのみ。 モデルが ELA 期間に入ると、値上げされる代わりに継続利用できる。移行先として推奨されるモデルがドキュメントに掲示されている。 Global external passthrough Network Load Balancer が Preview 公開 Cloud Load Balancing release notes - July 31, 2026 (2026-07-31) Global external passthrough Network Load Balancer が Preview 公開。 external passthrough なロードバランサーはこれまで Regional しかなかった。TCP/UDP に加え、ESP や GRE、ICMP など多様なプロトコルに対応。 Google Workspace のアップデート Google Vids で Google スライドの動画へのAI変換機能が日本語に対応 Convert your Google Slides to videos in 7 additional languages (2026-07-08) Google Vids で Google スライドの動画へのAI変換機能が日本語に対応。これまでは英語のみだったが、今回、日本語、フランス語、ドイツ語、イタリア語、韓国語、ポルトガル語、スペイン語にも対応した。 当機能は、スライド資料から台本、ナレーション、BGM、アニメーションを含む動画を自動生成するもの。Google Workspace Business Starter 以上が必要。 Google Workspace でインバウンド SCIM API が一般公開（GA） Streamline identity lifecycle management in Google Workspace with new inbound SCIM support (2026-07-09) Google Workspace でインバウンド SCIM API が一般公開（GA）。 外部の IdP や人事システムからディレクトリ情報をリアルタイムで同期可能。同期されたグループを Google Workspace 側で編集できないようにロックする機能等も備わる。ID 管理運用の簡素化に繋がる。 Google Chat で組織外ユーザーとのグループ DM が使用可能に Now available: group conversations with external collaborators in Google Chat (2026-07-15) Google Chat で、組織外のユーザーを交えたグループダイレクトメッセージ（DM）の作成が可能になった。 これまで外部ユーザーとのコミュニケーションは、1対1のDMか「スペース」の作成に限定されていたが、このアップデートにより、複数の外部メンバーを含むグループ DM を開始できる。外部メンバーがいるグループには視覚的なバッジが表示される。 Google スプレッドシートが「集合縦棒 - 折れ線」などのグラフタイプに対応 Import and create combo charts in Google Sheets (2026-07-20) Google スプレッドシートが「集合縦棒 - 折れ線」や「第 2 軸を使用した集合縦棒 - 折れ線」などのグラフタイプに対応。 Excel からインポートする際の互換性向上にもなる。 Google Meet で録画や議事メモが会議ごとのサブフォルダに整理されるように Import and create combo charts in Google Sheets (2026-07-20) Google Meet で、録画や議事メモが会議ごとのサブフォルダに整理されるようになった。定期会議の出力は同じフォルダに作成される。 フォルダにアクセス権限をつけておけば毎回録画を共有する必要がなくなるなどのメリットがあると想定される。 2026-07-22 より順次展開。 Google Meet の自動メモ作成で投影物のスクリーンショット保存されるように Visual screenshots in Google Meet meeting notes will soon be generally available, pre-configure admin settings in advance (2026-07-27) Google Meet の自動メモ作成（Take notes for me）で投影されたスライドなどのスクリーンショットがメモ内に保存されるようになる。 ただし機能の展開は2026年第3四半期（10月〜）が予定されている。許可の粒度を決める管理者設定のみ、既に公開されている。 Google ドキュメントで、画像、図、インフォグラフィックを生成可能に Generate and edit visuals with Gemini in Google Docs (2026-07-28) Google ドキュメントの Gemini サイドパネル/下部バーで、画像、図、インフォグラフィックを生成できるようになった。 編集画面を離れることなく文章に付随するビジュアルを生成できる。画像の編集も可能。2026-07-28から15日程かけて段階的にロールアウト。 Google Forms で自然言語指示によるクイズ自動生成が可能に Use Gemini in Google Forms to quickly create a new quiz (2026-07-30) Google Forms で、自然言語で指示することで Gemini がクイズを自動生成。 Google ドライブ上のドキュメント、スライド、PDF などを情報源として、理解度チェッククイズなどを生成できる。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it