Google Cloud は、旗艦イベント Google Cloud Next Tokyo を 2025 年 8 月 5 日(火)、 6 日(水)に東京ビッグサイト 南展示棟にて開催します。

Next Tokyo は、ビジネス リーダー、イノベーター、エンジニアのためのクラウド カンファレンスです。Google Cloud を活用したアプリケーション開発、データ・AI の利活用、従業員同士のコラボレーションなど、企業の課題を解決するナレッジをブレイクアウト セッションにてスピーカーとしてご紹介いただける方を募集します。

いま、生成 AI の活用がビジネスや社会のあり方を大きく変えようとしています。
一緒に生成 AI や最新のテクノロジーの新たな可能性を模索し、イベントを盛り上げましょう!


Google Cloud は、旗艦イベント Google Cloud Next Tokyo を 2025 年 8 月 5 日(火)、 6 日(水)に東京ビッグサイト 南展示棟にて開催します。

Next Tokyo は、ビジネス リーダー、イノベーター、エンジニアのためのクラウド カンファレンスです。Google Cloud を活用したアプリケーション開発、データ・AI の利活用、従業員同士のコラボレーションなど、企業の課題を解決するナレッジをブレイクアウト セッションにてスピーカーとしてご紹介いただける方を募集します。

いま、生成 AI の活用がビジネスや社会のあり方を大きく変えようとしています。
一緒に生成 AI や最新のテクノロジーの新たな可能性を模索し、イベントを盛り上げましょう!


ブレイクアウト セッションの応募はこちら

https://goo.gle/nexttokyo25-cfp
募集期日 : 2025 年 3 月 6 日(木)17 時まで

開催概要 

名称 : Google Cloud Next Tokyo(略称 Next Tokyo)

日時 : 2025 年 8 月 5 日(火)、6 日(水)

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

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

ハッシュタグ : #googlecloudnext


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

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

GoogleCloudNextTokyo-Speakers@google.com


Google Cloud は、3 月 13 日 (木) に「 AI Agent Summit ’25 Spring」を 開催します。

2025 年は「AI エージェント元年」。生成 AI の活用が大きくシフトする年になると予測されます。その活用は、従来のチャットボットから、より高度な「AI エージェント」へと進化しつつあります。

本イベントでは、AI エージェントを活用して生産性を向上する方法や、独自の AI エージェントを構築するためのヒント、そして Google Cloud の最新の生成 AI 製品のアップデート、多くのお客様のユースケースをお届けします。

今回は現地会場参加者に抽選でオリジナル T シャツをプレゼントいたします。
(※ T シャツのプレゼントには諸条件がございます。詳細は Web サイトをご覧ください)

Google Cloud は、3 月 13 日 (木) に「 AI Agent Summit ’25 Spring」を 開催します。

2025 年は「AI エージェント元年」。生成 AI の活用が大きくシフトする年になると予測されます。その活用は、従来のチャットボットから、より高度な「AI エージェント」へと進化しつつあります。

本イベントでは、AI エージェントを活用して生産性を向上する方法や、独自の AI エージェントを構築するためのヒント、そして Google Cloud の最新の生成 AI 製品のアップデート、多くのお客様のユースケースをお届けします。

今回は現地会場参加者に抽選でオリジナル T シャツをプレゼントいたします。
(※ T シャツのプレゼントには諸条件がございます。詳細は Web サイトをご覧ください)

ぜひ、 AI Agent Summit ’25 Spring にご参加ください。

■ 開催概要

日時 : 3 月 13 日(木)10:30 - 18:30(予定)

開催方法 : ハイブリッド(ベルサール渋谷ガーデン / オンライン配信)

参加費 : 無料(事前登録制)

会場定員 : 1,000 名

※来場希望者多数の場合は抽選制となります。

※ プログラムは変更になる可能性がございます。最新の情報は上記 Web ページにてご確認ください。


基調講演、ブレイクアウトセッション

Google Cloud の生成 AI 「Gemini」を始め、最新の 生成 AI の動向や企業活動へどのように取り入れていくかを事例を踏まえてご紹介します。

基調講演のゲストとして、各業界を代表する 3 社、日本電気、博報堂DYメディアパートナーズ、アダストリアの皆様にご登壇いただきます。



デモブース

最新の生成 AI 製品やソリューション、パートナー、お客様の事例やデモを、体験できるエリアです。各階にブースをご用意していますのでぜひお立ち寄りください。





生成 AI 事例 ピッチコンテスト

第 3 回 生成 AI Innovation Awards のファイナリストによるピッチコンテストを同イベントで開催。

企業の課題を解決するために、生成 AI 技術を活用したアイデアやソリューションを促進し、革新的かつ実用的な事例を発掘します。


AI Agent Hackathon ピッチコンテスト& 表彰式

Zenn が主催する「AI Agent Hackathon with Google Cloud 」にご応募いただいたプロジェクトのうち、上位 3 位の最終ピッチ コンテストと他全ての賞の表彰式を実施いたします。



詳細・お申し込みはこちら

【お問い合わせ】
Google Cloud イベント事務局
Email : googlecloud-genai-japan@google.com
#gcai_agent



この記事は Google Maps Platform、デベロッパーリレーションズ エンジニア Ken Nevarez とUbilabs、ソフトウェア エンジニアMartin Schuhfuss 氏 による Google Maps Platform Blog の記事 "Streamline the use of the Maps JavaScript API within your React applications" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
...

この記事は Google Maps Platform、デベロッパーリレーションズ エンジニア Ken Nevarez とUbilabs、ソフトウェア エンジニアMartin Schuhfuss 氏 による Google Maps Platform Blog の記事 "Streamline the use of the Maps JavaScript API within your React applications" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

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 に関する詳しい情報はこちらをご覧ください。ご質問やご意見はページ右上の「お問い合わせ」より承っております。


この記事は Hyunwook Baek, Duy Truong, Justin Dunlap, Lauren Stan, Oliver Chang による Google Security Blog の記事 "Announcing the launch of Vanir: Open-source Security Patch Validation" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 ...
この記事は Hyunwook Baek, Duy Truong, Justin Dunlap, Lauren Stan, Oliver Chang による Google Security Blog の記事 "Announcing the launch of Vanir: Open-source Security Patch Validation" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

本日(元記事公開当時)、新しいオープンソース セキュリティ パッチ検証ツール Vanir が公開されました。4 月の Android Bootcamp で紹介しましたが、Android プラットフォーム デベロッパーは、Vanir を使ってカスタム プラットフォームのコードをすばやく効率的にスキャンし、足りないセキュリティ パッチや適用可能なセキュリティ パッチを特定することができます。Vanir は、このプロセスを自動化することでパッチ検証にかかる時間を大幅に短縮します。OEM は重要なセキュリティ アップデートを従来よりもはるかに短い時間で提供できるようになるので、デバイスが確実に保護されるようになります。そのため、Android エコシステムのセキュリティが強化され、世界中の Android ユーザーの安全が確保されます。

Vanir をオープンソース化した目的は、さまざまなセキュリティ コミュニティがこのツールに貢献し、その恩恵を受けられるようにするためです。また、採用が広がることで、最終的にさまざまなエコシステムのセキュリティ向上につながります。当初の Vanir は Android 向けに設計されていましたが、比較的小さな変更で簡単に他のエコシステムに対応できるため、ソフトウェアのセキュリティを全体的に強化できる汎用性の高いツールとなっています。Google オープンソース セキュリティ チームと協力して先行ユーザーからのフィードバックを取り入れることで、Vanir を改善し、セキュリティ専門家にとって利便性の高いものにしました。このツールは公開されているので、これをベースに開発したり、システムに組み込んだりできます。

Android エコシステムは、複数段階のプロセスを使って脆弱性を緩和しています。新しい脆弱性が発見されると、アップストリームの AOSP デベロッパーがアップストリームのパッチを作成してリリースします。ダウンストリームのデバイスとチップメーカーは、特定のデバイスへの影響を評価し、必要な修正をバックポートします。このプロセスは効果的ですが、特に多様なデバイスを管理しているメーカーや複雑なアップデート履歴を持つ古いモデルでは、スケーラビリティの面で問題となる可能性があります。手動でバックポートする必要があるため、カスタマイズされた多様なデバイスでパッチのカバレッジを管理する場合、かなりの労力がかかることが多くなります。

Vanir を開発した目的は、重要なセキュリティ ワークフローを効率化することにあります。Vanir は、セキュリティ パッチの採用と検証に利用できるスケーラブルでサステナブルなソリューションで、Android デバイスを潜在的な脅威からタイムリーに保護できるようにします。

Vanir の機能

ソースコードベースの静的分析

Vanir の Android セキュリティ パッチ検証に対する最初のアプローチは、ソースコードベースの静的分析です。ここでは、ターゲットのソースコードと既知の脆弱なコードのパターンを直接比較します。Vanir では、バージョン番号、リポジトリ履歴、ビルド構成など、メタデータをベースとした誤りの多い従来型の検証メカニズムは利用しません。このユニークなアプローチにより、Vanir はコードベース全体を分析できるようになるほか、完全な履歴も、個々のファイルも、部分的なコード スニペットも利用できます。

Vanir が特に焦点を当てているのは、オープンソース ソフトウェア エコシステムで不足しているセキュリティ パッチを特定する際の、時間とコストがかかるプロセスを自動化することです。不足している大量のパッチを手動で識別すると、非常に手間がかかるだけでなく、ユーザーのデバイスを意図せずにしばらくの間、既知の脆弱性にさらしてしまう可能性があります。この点は、Vanir の初期開発の際に明らかになったことです。Vanir はこれに対処するため、Jang et al. [1] と Kim et al. [2] が提案する脆弱なコードクローン検出アルゴリズムに着想を得て、新しい自動シグネチャ調整手法と複数のパターン分析アルゴリズムを利用します。こういったアルゴリズムは、誤アラート率が低く、コードパッチ プロセスに現れる可能性のあるさまざまな種類のコード変更に効果的に対応できます。実際に Vanir を 2 年間運用した結果によると、誤アラートが発生したのはシグネチャのわずか 2.72% でした。この仕組みにより、コードを変更しても、Vanir は不足しているパッチを効率的に見つけることができます。同時に、不必要なアラートや手動レビュー作業を最小限に抑えることができます。

Vanir はソースコードベースのアプローチをとっているので、あらゆるエコシステムにすばやくスケーリングできます。サポートされている言語で書かれていれば、どんなソースファイルのシグネチャでも生成できます。Vanir のシグネチャ生成ツールは、シグネチャを自動的に生成、テスト、調整するので、ユーザーはセキュリティ パッチを適用したソースファイルを提供するだけで、エコシステムの新しい脆弱性に対して、シグネチャをすばやく作成できます。

Android で Vanir の活用が成功したことから、従来のパッチ検証方法よりも効率が高いことが明らかになっています。Vanir を使うと、1 人のエンジニアが 150 以上の脆弱性のシグネチャを生成し、ダウンストリーム ブランチ全体で不足しているセキュリティ パッチを検証する作業をわずか 5 日で行えます。

Android 版 Vanir

現在の Vanir は C/C++ と Java のターゲットをサポートしており、Android カーネルとユーザースペース CVE の 95% を公開セキュリティ パッチでカバーしています。Google Android セキュリティ チームは、Vanir のカバレッジに最新の CVE を組み込む作業を続けています。これにより、Android エコシステムのパッチ採用に関連するリスク状況の全体像を俯瞰できるようにします。

Android の脆弱性の Vanir シグネチャは、Open Source Vulnerabilities(OSV)データベースで公開されます。そのため、Vanir ユーザーは追加で更新を行わなくても、最新の Android の脆弱性からコードベースをシームレスに保護できます。現在、OSV には 2,000 を超える Android の脆弱性が登録されており、最新の PC でAndroid ソースツリー全体をスキャンするのに 10~20 分かかります。

柔軟な連携、導入、拡張

Vanir は、スタンドアロン アプリケーションとしてだけでなく、Python ライブラリとしても動作するように開発されています。パッチ検証プロセスを継続的ビルドやテストチェーンに組み込みたい方は、ビルド統合ツールと Vanir のスキャナ ライブラリを連携させることで、簡単に実現できます。たとえば、Google の継続的テスト パイプラインには Vanir が組み込まれているため、進化し続ける Android コードベースとそのファーストパーティ ダウンストリーム ブランチに、すべてのセキュリティ パッチが適用されていることを確認できます。

さらに、Vanir は完全なオープンソースで、BSD-3 ライセンスで利用できます。Vanir は基本的に Android エコシステムに限定されるものではないため、比較的小さな変更を加えるだけで、保護したいエコシステムに簡単に導入できます。さらに、Vanir の基礎アルゴリズムはセキュリティ パッチ検証に限定されるものではないので、ソースを変更すれば、ライセンス コード検出やコードクローン検出など、さまざまな目的に利用できます。Android セキュリティ チームは、Vanir への皆さんの寄与を歓迎します。機能やスコープを拡大するものなら、方向性は問いません。また、Vanir シグネチャ付きの脆弱性データを OSV に提供することで、Vanir に寄与することもできます。

Vanir の成果

昨年初めから、数社の Android OEM と連携してツールの有効性をテストしています。社内では、このツールをビルドシステムに統合し、1,300 を超える脆弱性に対して継続的にテストすることができました。現在の Vanir は、Android カーネルとユーザースペース全般にわたる公開修正プログラムによって、Android、Wear、Pixel の全脆弱性の 95% をカバーしています。精度は 97% で、内部チームはこれまで 500 時間以上のパッチ修正時間を節約できました。

次のステップ

現在、Vanir は一般公開されています。技術的には、Vanir は Android に限定されるものではありません。私たちは、OSV スキャナーとの連携による汎用的な C/C++ の依存関係管理など、Vanir が役立つ可能性のある問題についても積極的に検討しています。Vanir の利用または寄与に興味がある方は、github.com/google/vanir をご覧ください。公開コミュニティに参加すると、ツールのフィードバックや質問を送信できます。

Vanir で皆さんと協力できることを楽しみにしています!

Posted by Eiji Kitamura - Developer Relations Team