はじめに こんにちは、WEAR開発部バックエンドブロックの小山です。普段は弊社サービスである WEAR のバックエンド開発を担当しています。 WEARではハイブリッド検索などの新たな検索体験の実現を目指しています。その実現に必要な ハイブリッド検索 はOpenSearch 2.11で導入された機能です。Elasticsearch 7.10.2では利用できないため、Amazon OpenSearch Service上のエンジンをOpenSearch 2.11.0以上へ移行する必要がありました。今回はOpenSearch 2系の最新バージョンだった2.19.0を採用しました。本記事では、この移行にあたり対応したSearchkickの導入、ダブルライト戦略によるインデクシング移行、カナリアリリースによる段階的トラフィック切り替えについてご紹介します。 目次 はじめに 目次 抱えていた課題 Elasticsearch 7.10.2の限界 既存のアーキテクチャ 課題を解決したアプローチ 1. Searchkickとopensearch-rubyへの移行 elasticsearch-modelからSearchkickへ elasticsearchからopensearch-rubyへ 既存Searchableとの並存 2. インデクシングのダブルライト戦略 embulk-outputの変更 RakeタスクとDigdagワークフローの追加 3. クエリ種別ごとの動作確認 確認の目的と方針 確認対象の抽出方法 確認したクエリ種別 確認方法 4. 負荷試験 試験条件 試験結果 5. カナリアリリースによる段階的トラフィック移行 リリーススケジュール 各段階での確認項目 確認結果 効果と得られた知見 移行後のアーキテクチャ Searchkickとopensearch-rubyへの移行による保守性向上 並行稼働時のインデクサー移行方法 カナリアリリースの有効性 おわりに 抱えていた課題 Elasticsearch 7.10.2の限界 WEARではコーディネートや動画、メイクの投稿検索にAmazon OpenSearch Service上でElasticsearch 7.10.2を利用していました。しかし、以下の課題がありました。 新機能の利用不可：WEARではハイブリッド検索などの新たな検索体験を計画していたが、Elasticsearch 7.10.2はハイブリッド検索に対応しておらず、実現できない状態 サポートの先行き不透明：Elasticsearch 7.10.2は、Amazon OpenSearch Serviceで提供される最終のオープンソースElasticsearchバージョン。今後の新機能追加やセキュリティパッチの提供が見込めない状態。Elasticsearch 7.1〜7.8の標準サポートは2025年11月に終了しており、7.10.2も同様のサポート終了が予想される状態。AWS側でもOpenSearchエンジンへの移行を推奨 ライブラリのメンテナンス性： elasticsearch gem 7.14.0以降ではAmazon OpenSearch Service上のElasticsearchへ接続不可。gemのバージョンを7.13.3に固定せざるを得ず、アップデートができない状態 既存のアーキテクチャ WEARの検索基盤は、以下のシステム構成で運用していました。 検索機能： elasticsearch-model gemを利用し、検索メソッドを提供。内部では elasticsearch gemが提供する Elasticsearch::Client を通じてOpenSearch Serviceと通信 マッピング定義： elasticsearch-model gemを利用し、モデルにマッピング定義を記述 インデックス操作： elasticsearch gemを利用し、Rakeタスクによるインデックス作成、エイリアス切り替え、旧インデックス削除、ドキュメント削除 インデクシング：トラフィックを考慮し、レコード更新ごとではなくDigdagワークフローと Embulk による定時バッチ（日次の洗い替えと差分更新）でインデクシング 課題を解決したアプローチ 今回の移行では、既存ドメインのインプレースアップグレードではなく、OpenSearch 2.19.0の新規ドメインを作成し、エンドポイントを段階的に切り替える方法を採用しました。その理由は以下の通りです。 インプレースアップグレードでは、Elasticsearch 7.10.2からOpenSearch 2.19.0へ直接移行できず、 OpenSearch 1.xを経由する必要がある elasticsearch-model / elasticsearch から searchkick / opensearch-ruby へのgem移行が必要であり、アプリケーションコードに破壊的変更が生じる 検索基盤は影響範囲が大きいため、カナリアリリースで段階的にリリースしたい これらを踏まえ、Elasticsearchをダウンタイムなく移行させるために以下のアプローチで段階的に進めました。 Searchkickとopensearch-rubyへの移行 インデクシングのダブルライト戦略 クエリ種別ごとの動作確認 負荷試験 カナリアリリースによる段階的トラフィック移行 1. Searchkickとopensearch-rubyへの移行 移行前後のgemの対応関係は以下の通りです。 責務 Elasticsearch利用時 OpenSearch移行後 検索機能 elasticsearch-model （内部で elasticsearch を利用） searchkick （内部で opensearch-ruby を利用） マッピング定義 elasticsearch-model searchkick インデックス操作 elasticsearch 直接利用 opensearch-ruby 直接利用 elasticsearch-modelからSearchkickへ 検索機能とマッピング定義については、既存の elasticsearch-model の代わりに、 searchkick に移行しました。Searchkickを選定した理由は以下の通りです。 OpenSearchを公式にサポートしている リポジトリが継続的にメンテナンスされている nested型への対応など、 elasticsearch-model との互換性がある reindex時のアトミックなエイリアス切り替えが組み込まれているほか、ハイブリッド検索やセマンティック検索にも対応しており、高度な機能を備えている elasticsearchからopensearch-rubyへ インデックス操作のRakeタスクでは、 elasticsearch を使用していました。OpenSearch移行に伴い、これを opensearch-ruby に置き換えました。 - require 'elasticsearch' - client = Elasticsearch::Client.new(client_options) + require 'opensearch-ruby' + client = OpenSearch::Client.new(client_options) client.indices.update_aliases(...) client.indices.delete(...) opensearch-ruby は elasticsearch とAPIの互換性が高いため、クライアントの初期化部分とエラークラスの変更で、既存のインデックス操作ロジックをそのまま利用できました。 唯一の例外がインデックス作成タスクで、ここではSearchkick経由でマッピング定義を取得して作成しています。 task :create_index , [ :index_name ] => :environment do |_, args| index_class = index_class_name(args[ :index_name ]).singularize.capitalize.constantize index = Searchkick :: Index .new(args[ :index_name ]) model_config = index_class.search_index.index_options # Searchkickからマッピング取得 index.create(model_config) # Searchkick経由で作成 end このように、マッピング定義はSearchkickに一元化しつつ、その他のインデックス操作は opensearch-ruby を直接使用する構成としました。 既存Searchableとの並存 WEARでは、モデルごとに *Searchable というconcernを定義し、 elasticsearch-model を利用した検索用のデータ定義とマッピング定義を集約していました。 移行期間中は、Elasticsearchを利用するサーバーとOpenSearchを利用するサーバーを並行稼働させる必要がありました。そこで、モデルごとに *OpensearchSearchable concernを新設し、既存の *Searchable と並存させる構成をとりました。 既存の *Searchable はElasticsearch用のconcernです。 # 既存: Elasticsearch用 module Searchable extend ActiveSupport :: Concern # elasticsearch-model を利用したデータ定義とマッピング定義 end 新設した *OpensearchSearchable はOpenSearch用のconcernです。 # 新規: OpenSearch用 module OpensearchSearchable extend ActiveSupport :: Concern included do searchkick index_name : Rails .configuration.x.application[ :opensearch ][ :index_name ], settings : Rails .configuration.x.application[ :opensearch ][ :settings ], callbacks : false , merge_mappings : true , mappings : search_mappings def search_data # searchkick を利用したデータ定義 end end module ClassMethods def search_mappings # searchkick を利用したマッピング定義 end end end merge_mappings: true を指定することで、独自に定義したマッピングをSearchkickの自動生成マッピングにマージしています。 callbacks: false を指定することで、Searchkickの自動インデクシングを無効化し、既存のEmbulkによるインデクシングとの競合を防いでいます。 2. インデクシングのダブルライト戦略 移行期間中、ElasticsearchとOpenSearchの両方にデータを投入するダブルライトを実施しました。WEARのインデクシングは日次バッチによる洗い替え方式のため、ダブルライトを開始した時点で既存データも含めてOpenSearchに自動で同期されます。そのため、既存データの移行作業を別途行う必要はありませんでした。 embulk-outputの変更 前述の通り、既存の構成ではEmbulkを介して、BigQueryからデータを取得してElasticsearchにインデクシングしていました。インデクシング時のBigQueryのクエリコストが高額なため、OpenSearchにもインデクシングを行う際に単純にジョブを複製してしまうと、費用が2重に掛かってしまうという課題がありました。 そこで、embulk-outputの出力先をElasticsearchとOpenSearchの両方に向けることで、SQLの実行は一度だけで双方にデータを転送できるようにしました。 移行前はElasticsearchのみに出力していました。 # Elasticsearchへのインデクシング時 out : type : elasticsearch mode : insert nodes : - { host : {{ elasticsearch_host }} , port : {{ elasticsearch_port }}} index : {{ elasticsearch_index }} { % Elasticsearchの設定値 % } ダブルライト時は type: multi を使い、ElasticsearchとOpenSearchの両方に出力しました。 # ElasticsearchとOpenSearchにダブルライトするインデクシング時 out : type : multi outputs : - type : elasticsearch mode : insert nodes : - { host : {{ elasticsearch_host }} , port : {{ elasticsearch_port }}} index : {{ elasticsearch_index }} { % Elasticsearchの設定値 % } - type : elasticsearch mode : insert nodes : - { host : {{ opensearch_host }} , port : {{ opensearch_port }}} index : {{ opensearch_index }} { % OpenSearchの設定値 % } ダブルライトのために embulk-output-multi を新たに導入し、複数出力先への分岐を実現しました。OpenSearch側の出力も type: elasticsearch を指定しています。 embulk-output-elasticsearch はOpenSearchとのAPI互換性により、そのままOpenSearchへの出力にも利用できました。 RakeタスクとDigdagワークフローの追加 OpenSearch向けのインデックス操作のRakeタスクとDigdagワークフローを作成し、OpenSearchに対しても実行できるようにしました。 # 既存のElasticsearchのインデックス作成 +create_index_elasticsearch: sh>: ... rails "elasticsearch:create_index[${index_name}]" # 追加したOpenSearchのインデックス作成 +create_index_opensearch: sh>: ... rails "opensearch:create_index[${index_name}]" 3. クエリ種別ごとの動作確認 OpenSearch移行後にすべてのクエリ種別が正常に動作するかをQA環境で確認しました。 確認の目的と方針 Elasticsearchに送信されるクエリの種別ごとに、OpenSearch上でも同等の結果が返ることを確認しました。クエリ種別が重複するエンドポイントは確認対象外とし、効率的に網羅性を担保しました。 確認対象の抽出方法 確認対象の抽出は以下の手順で行いました。 対象エンドポイントの洗い出し：リポジトリ内でElasticsearchのQueryクラスを呼び出している箇所をリストアップ WEAR Webの対象画面の特定：Webマスタ仕様書から対象エンドポイントが使用されている画面を確認 クエリの特定：APIのリクエストパラメーターから生成されるOpenSearchのクエリJSONを特定し、使用されているクエリ種別を分類 確認したクエリ種別 以下のクエリ種別を対象に、WEAR iOS・Android・Webの各プラットフォームで動作確認を実施しました。 分類 クエリ種別 検索クエリ term 、 terms 、 range 、 nested 、 bool （ filter / must_not / must / should ）、 function_score 、 exists ソート sort ページング from 、 size グループ化 collapse 複合検索 msearch 確認方法 WEAR iOS・Android・Webの各プラットフォームで、以下の方法で確認しました。また、対応するRSpecテストを実行し、OpenSearchに対するクエリが正常に動作することはCI上で確認しています。 WEAR iOS・Android：QA環境のAPIに対してcurlコマンドでリクエストを送信し、レスポンスを確認。 WEAR Web：ブラウザ上で対象画面を操作し、APIレスポンスと画面表示を目視確認。 すべてのクエリ種別で正常な動作を確認し、負荷試験に進みました。 4. 負荷試験 本番リリース前に、OpenSearchクラスターがElasticsearch利用時と同等のリクエスト量を処理できるかを確認するため、QA環境で負荷試験を実施しました。 試験条件 QA環境のOpenSearchクラスターを本番環境のElasticsearchと同等のスペックに設定 検索エンドポイントのRedisキャッシュを無効化し、OpenSearchへの直接的な負荷を計測 k6を用いて、各検索エンドポイントに対して本番のピーク帯のMAX rps相当のリクエストを6時間継続 試験結果 レイテンシ ：Datadog APMで各検索エンドポイントのp99レイテンシを直近1か月の平均と比較した結果、OpenSearchがボトルネックとなるレイテンシ劣化は観測されなかった エラー ：Datadog APMで各検索エンドポイントを確認した結果、OpenSearch起因のエラーは発生しなかった クラスターメトリクス ：本番のピーク帯MAX値相当のリクエストを6時間継続した。CPUUtilizationはリクエスト量に対して許容範囲内、JVMMemoryPressureは本番環境と同程度であり、各種メトリクスに大きな影響はなかった この結果をもとに、カナリアリリースによる段階的な本番投入を判断しました。 5. カナリアリリースによる段階的トラフィック移行 本番リリースでは、カナリアリリースによって段階的にトラフィックを移行しました。 リリーススケジュール 日時 内容 2025/9/30 13:00 canary podの作成、APIの正常確認、1％リリース 2025/9/30 17:00 10％リリース 2025/10/1 14:00 50％リリース 2025/10/2 13:30 100％リリース 2025/10/2〜10/6 正常性の継続監視 各段階での確認項目 各段階で以下の項目を確認し、問題がなければ次の段階に進みました。 OpenSearchのレイテンシ比較とエラー確認：Datadog APMでOpenSearchとElasticsearchのレイテンシを比較し、劣化がないことを確認。OpenSearchのエラーがないことを確認。 各検索エンドポイントのレイテンシ比較とエラー確認：Datadog APMで各検索エンドポイントのレイテンシを比較し、劣化がないことを確認。OpenSearch起因のエラーがないことを確認。 クラスターメトリクス：SearchLatency、IndexingLatency、CPUUtilization、JVMMemoryPressureを監視し、劣化がないことを確認。 インデックスの整合性：ElasticsearchとOpenSearchのドキュメント件数に差異がないことを確認。 確認結果 OpenSearchでレイテンシが低い傾向を確認した（平均・最小・最大いずれもOpenSearchの方が高速） OpenSearch起因のエラーが発生しなかった OpenSearchでJVMMemoryPressureがやや高い傾向にあったが、MAXでも60％未満であり問題なかった CPUUtilizationはOpenSearchの方が低い傾向だった 100％リリース後の監視でも劣化が見られず、移行完了を判断した 効果と得られた知見 移行後のアーキテクチャ 移行後の検索基盤は、以下のシステム構成になりました。 検索機能： searchkick gemを利用し、検索メソッドを提供。内部では opensearch-ruby gemが提供する OpenSearch::Client を通じてOpenSearch Serviceと通信 マッピング定義： searchkick gemを利用し、モデルにマッピング定義を記述 インデックス操作： opensearch-ruby gemを利用し、Rakeタスクによるインデックス作成、エイリアス切り替え、旧インデックス削除、ドキュメント削除 インデクシング：既存のDigdagワークフローと Embulk による定時バッチ（日次の洗い替えと差分更新）でのインデクシングを継続 Searchkickとopensearch-rubyへの移行による保守性向上 elasticsearch-model から searchkick 、 elasticsearch から opensearch-ruby に移行し、以下の効果と知見がありました。 OpenSearchの将来的なバージョンアップへの追随が容易になった reindex処理のアトミックなエイリアス切り替えが組み込みで利用可能になった ハイブリッド検索の機能が利用可能になった opensearch-ruby はAPI互換性が高く、Rakeタスクの移行コストが低かった 並行稼働時のインデクサー移行方法 ダブルライト戦略により、以下のメリットがありました。 ElasticsearchとOpenSearchを並行稼働させることで、いつでも切り戻し可能な状態を維持 Embulkを利用した既存のインデクシングパイプラインを最小限の変更で拡張 移行時のクエリコスト増大を防止 Digdagワークフロー層での制御により、アプリケーションコードへの影響を最小化 カナリアリリースの有効性 段階的なトラフィック移行により、以下の知見が得られました。 1％リリースと10％リリースで、JVMMemoryPressureの変動が大きく見られた。これは、リリース後の低トラフィック時にキャッシュヒット率が低いことに起因する可能性が高く、50％リリース以降は安定した。 検索基盤のような影響範囲の大きいミドルウェアの移行にはカナリアリリースが有効であることを実感した。 おわりに 本記事ではWEARにおけるElasticsearch 7.10.2からOpenSearch 2.19.0への移行プロセスを紹介しました。同様の移行を検討している方の参考になれば幸いです。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com

こんにちは、デジタルマーケティング事業に携わっている神崎です。 本記事では、Google Cloud の BigQuery で、ARIMA_PLUS 時系列モデルを使用して Google アナリティクスデータの異常検出を行う方法と、Data Science Agent の概要について紹介します。 本記事の目次は、下記のとおりです。 はじめに BigQuery ML でモデルを作成する 異常値を検出する Data Science Agent を使ってみた Data Science Agent 利用時の留意事項 おわりに はじめに BigQuery ML による異常検出は、BigQuery 上でト…

G-gen の杉村です。2026年3月に発表された、Google Cloud や Google Workspace のイチオシアップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに Google Cloud のアップデート Gemini 3.1 Flash-Lite が Preview 公開 IAM で Service account principal sets が使えるようになった BigQuery の Conversational Analytics がアップデート gemini-embedding-2-preview が登場 Cloud Storage に Rapid bucket が登場（GA） Cloud Run への IAP 認証の直接設定が一般公開（GA） BigQuery でグローバルデフォルトロケーションが設定可能に AlloyDB のエンハンストバックアップが一般公開（GA） BigQuery data preparation が Cloud Storage と Google ドライブに対応 Cloud NGFW（Enterprise tier）に URL フィルタリングが登場 Imagen モデルが廃止へ 音楽生成モデル Lyria 3 が Vertex AI 経由で使用可能に（Public Preview） Vertex AI Search の回答モデルに gemini-3.1-pro、gemini-3-flash が登場 AlloyDB と Cloud SQL で Conversational analytics が Preview 公開 TPU7x が提供開始 Google Workspace のアップデート Google Workspace の Gemini アプリの共有（公開リンク）が可能に Gemini in Chrome の対応地域が拡張（日本は未対応） NotebookLM にスライドの PPTX 形式エクスポートなどの機能追加 Google Meet の会議の参加者承認時、疑わしいリクエストが分けて表示される Gemini アプリでこれまでより長く3分間の音楽の生成が可能に Google Workspace に「ゲストアカウント」機能が登場 Google ドライブのランサムウェア検出が Beta 版 → 一般公開（GA） はじめに 当記事では、毎月の Google Cloud（旧称 GCP）や Google Workspace（旧称 GSuite）のアップデートのうち、特に重要なものをまとめます。 また当記事は、Google Cloud に関するある程度の知識を前提に記載されています。前提知識を得るには、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp リンク先の公式ガイドは、英語版で表示しないと最新情報が反映されていない場合がありますためご注意ください。 Google Cloud のアップデート Gemini 3.1 Flash-Lite が Preview 公開 Gemini 3.1 Flash-Lite (2026-03-03) Gemini 3.1 Flash-Lite が Preview 公開。 「Gemini 2.5 Flash に相当する回答品質」を目指している。Vertex AI や Google AI Studio から利用可能。 IAM で Service account principal sets が使えるようになった Service accounts (2026-03-03) IAM で Service account principal sets が使えるようになった。あるプロジェクト/フォルダ/組織配下の全サービスアカウント or 全サービスエージェントを指すセット。 あるプロジェクト内の全サービスアカウントは principalSet://cloudresourcemanager.googleapis.com/projects/123456789012/type/ServiceAccount 、あるフォルダ内の全サービスエージェントは principalSet://cloudresourcemanager.googleapis.com/folders/123456789012/type/ServiceAgent のように表現される。 IAM 許可ポリシーや拒否ポリシーに、プリンシパルとして書き込める。 BigQuery の Conversational Analytics がアップデート BigQuery release notes - March 09, 2026 (2026-03-09) BigQuery の Conversational Analytics がアップデート。 BigQuery Studio の SQL 実行結果から会話をスタートできる AI.FORECAST、AI.DETECT_ANOMALIES、AI.GENERATE に対応 ObjectRef 対応で非構造化データが扱える パーティション列で効率的にクエリをする ジョブ履歴に {‘ca-bq-job’: ‘true’} が付く 次の質問のサジェストが出る gemini-embedding-2-preview が登場 Gemini Embedding 2 (2026-03-10) gemini-embedding-2-preview が登場。 マルチモーダルなエンベディングモデルで、ドキュメントの OCR や動画から音声トラックを抽出することも可能。 Cloud Storage に Rapid bucket が登場（GA） Rapid Bucket (2026-03-10) Cloud Storage に Rapid bucket が登場（GA）。 VM と同じゾーンにバケットを配置することで低レイテンシで高スループットを実現。AI/MLやデータ分析、ロギング、ストリーミング記録などに使用することを想定。 Cloud Run への IAP 認証の直接設定が一般公開（GA） Configure IAP for Cloud Run (2026-03-13) Cloud Run にロードバランサーなしで IAP 認証を設定する機能が Preview → 一般公開（GA）。 GA にあわせて組織外ユーザーの認証も可能になった。これまでは組織内ユーザーに限定されていた。 BigQuery でグローバルデフォルトロケーションが設定可能に Specify global settings (2026-03-16) BigQuery でグローバルデフォルトロケーションが設定可能になった。 組織レベルまたはプロジェクトレベルで適用できる。これまで場所の指定がない場合はシステム側の挙動に依存していたが、このアップデートにより、意図しないリージョンでのリソース作成や、場所指定漏れによるエラーを未然に防ぐことができる。 AlloyDB のエンハンストバックアップが一般公開（GA） Manage enhanced backups (2026-03-16) AlloyDB のエンハンストバックアップ（拡張バックアップ）が一般公開（GA）。 Backup and DR サービスと連携。一元化されたバックアップ管理プロジェクトで管理および保存される。 変更不可のストレージ: バックアップは、Backup and DR で管理される Backup Vault に保存される 保持の適用: ポリシーにより、バックアップの誤った削除や悪意のある削除を防ぐ 高度なスケジュール設定: バックアップの頻度と保持ルールを高度にカスタマイズできる 一元管理: AlloyDB、Cloud SQL、Compute Engine などの複数のGoogle Cloud ワークロードにわたって統一されたモニタリングとレポート BigQuery data preparation が Cloud Storage と Google ドライブに対応 BigQuery release notes - March 23, 2026 (2026-03-23) BigQuery の「データ準備（Data preparation）」が、Cloud Storage と Google ドライブからのデータ取り込みに対応。 Data preparation とは、AI によるデータエンジニアリング支援ツール。ファイルをテーブルに取り込んで変換等する作業などが簡単に実装できる。 Cloud NGFW（Enterprise tier）に URL フィルタリングが登場 URL filtering service overview (2026-03-24) Cloud NGFW（Enterprise tier）に URL フィルタリングが登場。 HTTP(S)トラフィックのドメイン / SNI 情報に基づいて URL フィルタリングを行う。 Cloud NGFW の Enterprise tier では、VPC にエンドポイントを構築し、パケットを横から検査する。エンドポイントの存在した時間に応じて料金が発生する。 参考 : Cloud Next Generation Firewall pricing Imagen モデルが廃止へ Vertex AI release notes - March 24, 2026 (2026-03-24) 画像生成モデル Imagen モデルが廃止へ。 推奨される後継モデルは gemini-2.5-flash-image （いわゆる Nano Banana 2）。以下のようなモデルが廃止される（一部抜粋）。 imagegeneration@006 imagetext@001 imagen-3.0-capability-002 imagen-3.0-fast-generate-001 imagen-3.0-generate-002 imagen-4.0-fast-generate-001 imagen-4.0-generate-001 imagen-4.0-ultra-generate-001 音楽生成モデル Lyria 3 が Vertex AI 経由で使用可能に（Public Preview） Lyria 3 (2026-03-25) 音楽生成モデル Lyria 3 が Vertex AI 経由で使用可能になった（Public Preview）。インプットにはテキストと画像が使える。 lyria-3-pro-preview : 184秒の音楽生成 lyria-3-clip-preview : 30秒の音楽生成 Vertex AI Search の回答モデルに gemini-3.1-pro、gemini-3-flash が登場 Answer generation model versions and lifecycle (2026-03-26) Vertex AI Search の回答モデルに新しいモデルが登場 gemini-3.1-pro-preview gemini-3-flash-preview なおこれまで使えていた Gemini 3 Pro Preview は使用不可になる。 AlloyDB と Cloud SQL で Conversational analytics が Preview 公開 Conversational analytics for Cloud SQL for PostgreSQL overview (2026-03-26) AlloyDB for PostgreSQL、Cloud SQL for PostgreSQL / MySQL で、Conversational analytics（会話型分析）が Preview 公開。 Google Cloud コンソールから自然言語を使って、テーブルに対するクエリを発行できる。BigQuery に続いて、運用データベースでも自然言語による DB へのクエリが可能になった。 TPU7x が提供開始 TPU7x (Ironwood) (2026-03-31) Google Cloud で新しい TPU「TPU7x」が提供開始。Google Kubernetes Engine（GKE）で使用可能。第7世代 TPU である Ironwood ファミリーであり、大規模 AI トレーニング・推論向け。 Google Workspace のアップデート Google Workspace の Gemini アプリの共有（公開リンク）が可能に Workspace admins can allow Gemini app conversation sharing for their organizations (2026-03-04) Google Workspace の Gemini アプリの共有（公開リンク）が可能になった。これまでは個人版のみ可能だった。 公開リンクは Google アカウントがなくても閲覧可。デフォルトで無効で、管理者設定で有効化の必要あり。許可するかどうかはセキュリティ上の考慮が必要。 Gemini in Chrome の対応地域が拡張（日本は未対応） Gemini in Chrome expands to more countries and languages, including Canada, New Zealand, and India (2026-03-13) Gemini in Chrome が従来の米国に加えて、カナダ、ニュージーランド、インドに対応。 Gemini in Chrome とは、開いているタブのコンテキストに基づいて記事の要約、解説、情報を検索したり、コンテンツの生成（テキスト・画像）、また Gemini Live などを使える機能のこと。 日本のユーザーは未対応なため注意。 NotebookLM にスライドの PPTX 形式エクスポートなどの機能追加 New ways to customize and interact with your content in NotebookLM (2026-03-20) NotebookLM に機能追加。 インフォグラフィックのスタイル指定 パワポ形式でのスライドのエクスポート スライド微調整 Cinematic Video Overviews (ただし英語のみ) ...など。 対象の Google Workspace エディションは全エディションだが、Cinematic Video Overviews のみ Business Standard 以上など。 Google Meet の会議の参加者承認時、疑わしいリクエストが分けて表示される Safeguarded guest admit flow in Google Meet (2026-03-24) Google Meetの会議の参加者承認にアップデート。信頼性が怪しい入室リクエストについては、通常のリクエストとは分けて表示されるようになる。 Gemini アプリでこれまでより長く3分間の音楽の生成が可能に Create longer musical tracks in the Gemini app with Lyria 3 Pro (2026-03-25) Gemini アプリで、新モデル Lyria 3 Pro により、3分間の音楽生成が可能になった。従来は30秒。 Google Workspace の Business Standard 以上のエディションで、2026年3月25日から数日かけてロールアウト。 Google Workspace に「ゲストアカウント」機能が登場 Introducing guest accounts: Collaborate securely and communicate with non-Workspace users in Google Chat (2026-03-30) Google Workspace に「ゲストアカウント」機能が登場。 外部の人を Google Chat 経由で招待すると、一意の ID が割り当てられたゲストアカウントが発行される。 Google ドライブ上のファイルの共同作業が可能（ファイル新規作成は不可）。Workspace Guests OU に配置され各種ポリシーを適用可能。 有償ライセンス数 × 5個のゲストアカウントが作成可能。 Google ドライブのランサムウェア検出が Beta 版 → 一般公開（GA） Ransomware detection and file restoration for Google Drive now generally available (2026-03-30) Google ドライブでランサムウェア検出＆ファイル修復機能が Beta 版 → 一般公開（GA）。 デスクトップ版 Google ドライブを使っている場合に、ランサムウェアが検出されると、ファイル同期が停止され、管理者や本人にアラート通知。 万一、ドライブ上のファイルが暗号化されても一括復元が可能。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it