現在、世界中の人々がモバイル デバイスを使い、指先だけで、友人や家族とのつながりを維持したり、金銭を管理したり、ヘルスケア情報を追跡したりしています。しかし、デバイスが悪意のある人に盗まれると、機密データの流出、ID の盗難、金融詐欺、プライバシー侵害といった被害に遭う可能性があります。

先日、その対策として、Android の盗難防止機能をリリースしました。この包括的な機能は、デバイスの盗難前、盗難中、盗難後のすべての段階で、ユーザーとデータを保護できるように設計されています。Android の安全を確保するための取り組みの一環として、この機能を拡張して強化し、世界中のユーザーがさらに強力な保護を受けられるようにします。

 

ID チェックを Pixel および Samsung One UI 7 デバイスにロールアウト

最初に ID チェックが正式導入されるのは、Pixel と One UI 71 の対象となる Samsung Galaxy デバイスです。これらのデバイスでは、アカウントとデバイスに関する重要な設定の保護が強化されます。ID チェックをオンにすると、信頼できる場所以外から特定の機密リソースにアクセスする場合に、デバイスで明示的な生体認証が必須になります。さらに、サポートされているすべてのデバイスで Google アカウントの保護が強化されます。One UI 7 対応の Galaxy デバイスでは、Samsung アカウントのセキュリティが強化され、デバイスにログインしているアカウントの不正な乗っ取りがはるかに難しくなります。

ID チェックを有効化する際に、複数の信頼できる場所を指定できます。信頼できる場所以外にいる場合、デバイスの PIN や生体認証の変更、盗難防止の無効化、パスキーへのアクセスなど、アカウントやデバイスに関する重要な設定にアクセスする際に、生体認証が必須になります。

ID チェックを利用することで、特に機密性の高いデバイス資産が確実に不正アクセスから保護されるという安心感が得られます。たとえ盗難者や悪意のある者がデバイスの PIN を知ったとしても、セキュリティが破られることはありません。

現在、Android 15 を搭載した Pixel デバイスへのID チェックのロールアウトが行われています。One UI 7 対応の Galaxy デバイスは、今後数週間以内に利用できるようになります。今年中には、他のメーカーの対応 Android デバイスにもロールアウトされる予定です。

 

盗難検知ロック: AI を活用した保護を拡大

昨年導入した重要な盗難防止機能の 1 つが、盗難検出ロックです。これは、オンデバイス AI アルゴリズムを活用して、スマートフォンが盗難に遭った可能性を検出する機能です。機械学習アルゴリズムにより、ロックされていないデバイスで盗難に遭った可能性が検知されると、盗んだ人による操作を防ぐため、画面がロックされます。

盗難検知ロックは、世界中の Android 10 以上のスマートフォン2 へのロールアウトが完了しています。

 

Android デバイスの盗難保護

私たちは、GSMA や業界のエキスパートと協力し、情報やツール、予防技術を共有することで、モバイル デバイスの盗難に対抗しています。近日中に GSMA ホワイト ペーパーを公開しますので、ご期待ください。モバイル業界と協力して作成したこのホワイト ペーパーには、デバイスの盗難から自分自身や組織を保護するための詳しい情報を含める予定です。

Android では、ID チェックの追加と既存機能の継続的な拡張を通し、堅牢で包括的なツールセットを提供することで、デバイスとデータを盗難から保護します。私たちは、個人情報が確かに守られているという安心感を皆さんにお届けする取り組みを続けています。

サポートされている Android デバイスでこちらをクリックすると、新しい Android の盗難保護機能をオンにすることができます。盗難防止機能の詳細については、ヘルプセンターをご覧ください。

注


  1. One UI 7 では、タイミング、対象、機能名が異なる場合があります。 

  2. Android Go スマートフォンを除きます。 


Posted by Eiji Kitamura - Developer Relations Team


先着 1,000 名様に早期登録特典

先着 1,000 名様に Google Cloud を試すための 100 ドル分のクーポンをプレゼントします。

ぜひ、お早めに公式サイトからご登録ください!

※クーポンの利用上限は 100 ドルです。上限を超えると課金されますのでご注意ください。

※他のハンズオンなどでクーポンコードを使用された方は、本クーポンが適用されない場合があります。



ブレイクアウト セッション大募集中

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

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

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

期日 : 2025 å¹´ 3 月 6 日(木)17 時まで


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

Google Cloud Next Tokyo スピーカー事務局 : 
[email protected]


開催概要

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

日時 : 2025 å¹´ 8 月 5 日(火)、6 日(æ°´)

会場 : æ±äº¬ãƒ“ッグサイト 南展示棟

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

ハッシュタグ : #googlecloudnext


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

Google Cloud Next Tokyo 運営事務局

E-mail: [email protected]

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 ã‚’削除することをおすすめします。

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


Posted by Thanet Knack Praneenararat - Ads Developer Relations Team


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 スピーカー事務局 : 

[email protected]


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


Posted by 丸山 智康 (Tomoyasu Maruyama) - Developer Relations Engineer 
Share on Twitter Share on Facebook


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
Share on Twitter Share on Facebook