Google Cloud を活用したアプリケーション開発、データ・AI の利活用、従業員同士のコラボレーションなど、企業の課題を解決するナレッジをブレイクアウト セッションにてご紹介いただける方を募集しています。

セッション登壇でスポットライトを浴びて一緒にイベントを盛り上げましょう！

公式サイトよりご応募ください

期日 : 2025 年 3 月 6 日（木）17 時まで

- セッション募集に関するお問い合わせ -

Google Cloud Next Tokyo スピーカー事務局 : 
GoogleCloudNextTokyo-Speakers@google.com

開催概要

名称 : Google Cloud Next Tokyo（略称 Next Tokyo）

日時 : 2025 年 8 月 5 日（火）、6 日（水）

会場 : 東京ビッグサイト 南展示棟

対象 : 開発者から経営者まで、生成 AI やクラウド テクノロジーを使ってビジネス課題の解決を探求するすべての方

ハッシュタグ : #googlecloudnext

- Next Tokyo に関するお問い合わせ -

Google Cloud Next Tokyo 運営事務局

E-mail: gc-nexttokyo-info@google.com

2025 年 3 月 3 日より、Google Ads API と Google 広告スクリプトの検索キーワード インサイト レポートで、返される検索サブカテゴリがすべて空になります。Google 広告 UI では、すでにこのフィールドが削除されています。Google 広告全体で一貫性を維持するため、API にもこの変更をロールアウトします。

何をする必要がありますか？

2025 年 3 月 3 日より、segments.search_subcategory のすべての値が空になります。

campaign_search_term_insight または customer_search_term_insight レポートで、クエリに segments.search_subcategory が含まれている場合は、次のようにしてください。

1. segments.search_subcategory が空の値になっても、コードが問題なく処理できることを確認します。空の文字列はさまざまな状況に対応できるので、コードはすでにこれに対応しているはずです。
2. クエリから segments.search_subcategory を削除することをおすすめします。

質問や懸念事項がある方は、サポート フォームからお問い合わせください。

開催概要 

名称 : Google Cloud Next Tokyo（略称 Next Tokyo）

日時 : 2025 年 8 月 5 日（火）、6 日（水）

会場 : 東京ビッグサイト 南展示棟

対象 : 開発者から経営者まで、生成 AI やクラウド テクノロジーを使ってビジネス課題の解決を探求するすべての方

ハッシュタグ : #googlecloudnext

- セッション募集に関するお問い合わせ - 

Google Cloud Next Tokyo スピーカー事務局 : 

GoogleCloudNextTokyo-Speakers@google.com

Google Maps Platform と vis.gl チームによって開発された @vis.gl/react-google-maps ライブラリは、Google マップを React に統合するための強力で効率的な方法を提供し続けています。このライブラリは、React の宣言型という特性と Google マップの豊富な機能が魅力的な方法で組み合わされています。

デベロッパーにとっての主なメリット

• React とのシームレスな統合: Google マップを完全に制御された React コンポーネントとして直接埋め込むため、React ワークフローとの十分な調和が確保されます。

• 拡張性: カスタム コンポーネントを活用し、React フックとコンテキストを使用して、ライブラリの機能を簡単に拡張できます。

• vis.gl の強力な機能: 他の vis.gl ライブラリ（deck.gl など）と簡単に統合して、Google マップ上で直接、魅力的な 2D および 3D データ可視化を実現できます。

設計の移行: React の哲学を Maps JavaScript API に取り入れる

React と他のコンポーネント ベースのアプローチに関する重要なポイントとして、宣言型 / リアクティブ プログラミングと単方向データフローの 2 つの考え方があります。

React の宣言型スタイルで簡単な Google マップ実装を実行する TypeScript の例。

React では、アプリケーションのユーザー インターフェースとその複雑さおよび詳細すべてが、アプリケーションの状態を形成する一連の変数に基づいて完全に記述されます。この状態には、表示されているデータ（場所のリストなど）だけでなく、「この InfoWindow は現在開いているか？」や「マウスカーソルは現在これらの地点情報のいずれかに合わせられているか？」などの詳細も含まれます。これらの状態変数のいずれかが変更されるたびに、React は新しい状態に基づいて UI を更新します。

状態の変更は常に、コンポーネント階層を通じて下向きに伝播されます。たとえば、コンポーネント <PlacesList> は場所のリストを保存し、それらをフィルタリングして並べ替えてから、リスト内の単一の場所の表示を記述する複数の <Place> コンポーネントに渡します。この階層の下位にあるコンポーネントは、そのデータスライスにのみアクセスでき、データに関する変更が必要な場合にイベントをパブリッシュする必要があります（たとえば、場所の詳細のある地点に存在する [お気に入りに追加] ボタンをクリックするなど）。これは単方向データフロー パターンとして知られています。データは常に下向きに流れ、イベントは常に上向きに流れます。

ユーザー インターフェースを構築するこの動的なアプローチは、大規模なアプリケーションにも非常にうまく適応します。そのため、一般的には再利用可能なコンポーネントと非常に堅牢なアプリケーション アーキテクチャが実現し、アプリケーションが大きくなってもメンテナンス性と開発者にとっての効率性は維持されます。表示全体を状態変数のみから引き出すと、状態のデータがどこかに保存されている場合にもかなり役立ちます。状態を復元すると、UI とその中にあるあらゆるものも復元されることが保証されます。これにより、元に戻す / やり直し機能、ページ再読み込み後の永続性、その他多くのユースケースを簡単に実装できるようになります。

命令型スタイルで簡単な Google マップ実装を実行する TypeScript の例。

Maps JavaScript API は、命令型 API と呼ばれる異なるアプローチを採用しています。このアプローチでは、開発者はオブジェクトを作成してメソッドを呼び出すことで API をより直接的に操作し、望ましい結果を記述するのではなく、API に何をすべきかを 段階的かつ効果的に指示しています。

命令型アプローチと宣言型アプローチのこのギャップを埋めるため、@vis.gl/react-google-maps ライブラリには、React でマップの外観と動作を記述するために使用される <Map> や <AdvancedMarker> などの一連のコンポーネントが用意されています。この記述は命令型 Maps JavaScript API の対応する指示に変換されます。

これは、場合によっては単純です。<AdvancedMarker> コンポーネントが React のコンポーネント ツリーに追加されると、ライブラリは内部で google.maps.AdvancedMarkerElement オブジェクトを作成し、それを <Map> コンポーネント用に作成されたマップ インスタンスに追加します。このコンポーネントが後で階層から削除されたタイミングで、マーカーもマップから削除されます。

他のケース（たとえばマップ自体の場合）では、もう少し複雑になります。マップは通常、たとえば動画プレーヤーのように、ページ内の独立したコンポーネントとして機能しているため、マップコンテナ内で、マップは独自のイベント処理とユーザー インタラクションを定義し、Maps API のユーザーにはほとんど表示されない独自の状態変数セットを維持するようにします。

さらに、一般的なユースケースでは、マップとそのコンテンツが初期化され、ユーザーに表示された後は、マップ内で起きることをアプリケーションが制御する必要はありません。ほとんどの場合はこれで問題ありませんが、マップがアプリケーションにさらに深く統合されている場合もあります。その場合、マップのビューポートを制御するプロパティをアプリケーション状態から取得する必要があります。同時に、マップが通常どおりにユーザー インタラクションを処理することも引き続き許可します。

@vis.gl/react-google-maps ライブラリは、これら両方のユースケースに加えて他のユースケースにも対応します。なんらかのコンテンツを含むマップを表示するためだけにライブラリを使用した後、そこからすべてをマップに処理させることができますが、マップを完全に制御し、マップ自体のユーザー インタラクションの処理を無効にする程度にまで、マップに表示される内容を、アプリケーションに保存されている状態変数と常に完全に同期することもできます。

持続性を念頭に置いた構築: @vis.gl/react-google-maps の維持の背後にある哲学

初めて使用するユーザーは、@vis.gl/react-google-maps ライブラリでは選択できるコンポーネントがそれほど多くないことに気づくでしょう。これは意図的であり、このライブラリがオープンソースの世界で今後長期間にわたって拡大し、維持され続けるための計画の一部です。

まず、初期段階では、ライブラリが小さいほどメンテナンスが明らかに容易になります。よって、メンテナンス担当者は最も重要な機能を実装してから機能の拡張に取り組むことができます。ライブラリが小さいとバンドルも小さくなるため、すべてのユーザーにとってメリットがあります。しかし、これについてはもう一つ重要な点があります。このライブラリの目的は、明確に定義されたユースケース向けに固定されたコンポーネント コレクションを提供することではなく、あらゆる種類のユースケースをできるだけ簡単に構築するのに必要なフレームワークとツールを提供することです。

これは、新機能の実装方法として選択されたアプローチにも反映されています。つまり、新機能は、まずその使用方法を示すサンプルとして実装する必要があります。ライブラリを使用して機能を実装するのが難しいことに気づいた場合、それを利用して、改善点や低レベルの機能をライブラリに追加し、汎用性とデベロッパー エクスペリエンスを向上させることができます。また、再利用性を考慮して例を記述し、開発者がサンプルからコンポーネントをコピーしてアプリケーションで使用できるようにすることも目指しています。安定していて普遍的に有用であることが実証された機能は、後日ライブラリに追加することができます。

このような方法で機能を開発することで、以下の2 つのメリットをもたらします。まず、すべての新機能について、サンプル事例がドキュメントとして用意されています。また、同様のユースケースを持つすべての人がコードをコピーし、ニーズに合わせて変更できるように工夫されています。開発者はコードをコピーして必要に応じて調整することでコードの所有権を得るため、サンプルコードはバージョニングや互換性を損なう変更などの一般的な問題の制約を受けません。そのため、より自由に反復して、可能な限り最適な実装を見つけることができます。

オープンソースと OpenJS Foundation について

@vis.gl/react-google-maps はその登場以来、オープンソースの価値を擁護してきました。OpenJS Foundation の実績（Node.js、jQuery、vis.gl 自体など）に基づき、私たちはこのライブラリの管理を OpenJS Foundation に委託しました。その結果、ベストなアイデアが開花するコラボレーション環境が生まれ、ライブラリの品質と長寿命性が保証されています。

Google は、@vis.gl/react-google-maps が最新かつ堅牢な状態を維持できるよう引き続き尽力しています。ライブラリの原動力である vis.gl チームは、pull リクエストとリリースを積極的に管理しています。

使ってみる

@vis.gl/react-google-maps のバージョン 1.0 へのバージョン アップは重要なマイルストーンですが、エキサイティングな取り組みの始まりでもあります。このライブラリを実際にお試しいただき、その発展に貢献していただければ嬉しく思います。React でのマップ作成の未来を一緒に作っていきましょう。

インストールは、npm install @vis.gl/react-google-maps または yarn add @vis.gl/react-google-maps を実行するだけです。

プロダクトのドキュメントと例については、React Google Maps ウェブサイトをご覧ください。コードサンプルを含む構造化されたチュートリアルについては、Google Maps Platform デベロッパー サイトの Codelab をご覧ください。ぜひ @vis.gl/react-google-maps を使用した体験やサービスを共有してください。皆様がどのようなものを構築されるかとても楽しみにしております。

Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やご意見はページ右上の「お問い合わせ」より承っております。