この記事は Google Maps Platform エンジニアリング マネージャー Stas Kuvshinov と Google Maps Platform UX デザイナー Chris Raykovich とによる Google Cloud Blog の記事 "Introducing the latest in cloud-based maps styling" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 ...Read More

この記事は Google Maps Platform エンジニアリング マネージャー Stas Kuvshinov と Google Maps Platform UX デザイナー Chris Raykovich とによる Google Cloud Blog の記事 "Introducing the latest in cloud-based maps styling" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

このたび、Cloud ベースのマップスタイル設定に関する新しい試験運用版の提供を開始しました。これは、Maps JavaScript API 向けのもので、これまで以上に地図の外観を詳細に調整できるようになります。より多くの重要なコンテンツにターゲットを当てて、地理空間のユースケースを微調整するためのオプションが増えました。ラベルの公開設定、領域の塗りつぶしの色、外形線の色や太さの設定など、スタイル設定可能な要素をより細かく調整できるようになるため、ユーザー独自のデザインをマップのスタイルにより適切に反映できるようになります。

拡張された地図上の対象物とスポット

これらの改善を支えるのが、100 近い個別のマップ要素をサポートする、カスタマイズ可能な地図上の対象物の新しいインベントリです。現在の一般提供バージョンの Cloud ベースのマップスタイル設定と比較して、対象物は 2 倍、スポットのカテゴリは 4 倍になりました。そのため、2 億以上の企業や場所をカバーする Google のスポットデータを使用してマップを構築し、マップに表示するデータをより詳細にフィルタおよびカスタマイズできます。また、以前はアクセスできなかった新しい地図作成の詳細情報を使用することで、地図のスタイルの外観をより細かく調整できるようになります。たとえば、保留地、農作物、水面の種類などを異なる方法でスタイル設定できるようになりました。さらに、観光スポット、レクリエーション エリア、緊急サービス、小売店などのスポットのカテゴリに適用されるラベル間で、さまざまな設定もできます。

拡張された地図上の対象物タイプのリスト

スタイラーの改良

分類方法の拡張に加えて、ジオメトリやラベルなど、さまざまな地図作成要素に関する新しいスタイル設定機能をリリースします。これらの新しいカスタム プロパティはすべて、柔軟性をさらに高めるように設計されており、これにより、ブランドやアプリケーション固有のニーズを反映したカスタム スタイルを作成できます。

マップ要素の色とラベルのカスタマイズの例

ご利用方法

Cloud ベースのマップスタイル設定は、Maps JavaScript API 向けの Dynamic Maps に含まれています。デベロッパーは、Google Cloud コンソールで JavaScript Vector Map 構成の MapID と新しい地図のスタイルを作成することで、Dynamic Maps の Cloud ベースのマップのスタイル設定機能を使用できます。

これらの試験運用版のスタイル設定機能を試すには、新しい地図のスタイルの作成時に、試験運用版のオプションを選択します。

「新しい地図のスタイル」の作成時に試験運用版を有効にする例

試験運用版の地図のスタイルを使用するには、JavaScript Maps API バージョン 3.47 以降（ベクターベースの地図の場合）、または 3.49 以降（ラスターベースの地図の場合）をウェブアプリで使用する必要があります。試験運用版のほとんどの機能を使用するには、JavaScript Maps API Beta チャンネルをご検討ください。この試験運用フェーズの期間で、カスタマイズ可能な地図上の対象物と関連するスタイラーのリストを拡張し、あらゆるズームレベルにおいてユーザビリティの向上とスタイル設定の強化を実現します。

Google Maps Platform の新しい Cloud ベースのマップのスタイル設定により、これまで以上に魅力的で有益な地図を作成できるようになると確信しています。ご利用とご感想をお待ちしております。

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

Posted by 丸山 智康 (Tomoyasu Maruyama) - Developer Relations Engineer 

この記事は Bob Hancock による Google Ads Developer Blog の記事 "Image and Location Auto-migration August 2023" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 ...Read More

この記事は Bob Hancock による Google Ads Developer Blog の記事 "Image and Location Auto-migration August 2023" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

変更事項

2023 年 8 月 2 日より、画像表示オプションと住所表示オプションのアセットへの自動移行を開始しました。自動移行は、2023 年 9 月 30 日に終了する予定です。

アセットへ移行後、画像表示オプションと住所表示オプションは変更できなくなります。提供されるエンティティは、画像アセットと住所アセットになります。表示オプションの指標は、2024 年のある時点まで利用できます。

変更の理由

表示オプションがアセットに移行されます。

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

v12 は 2023 年 9 月末で提供終了となるため、v13 以降の Google Ads API にアップグレードしてください。v14 へのアップグレードを推奨しています。

自動移行では、フィード ID とアセット ID との対応付けは保持されません。フィード ID とアセット ID の対応付けを記録しておきたい場合は、フィードに基づいて新しい画像アセットや住所アセットを作成し、ID の対応付けをローカルに保存してください。

自動移行をオプトアウトすることはできますか？

いいえ。自動移行の最初のバッチではオプトアウトを提供しましたが、今回の自動移行はオプトアウトできません。

移行はどのように行われますか？

移行はアカウント レベルで行われます。アカウントの移行は数分で行われますが、その間は表示オプションとアセットの両方で、画像と住所が変更できなくなります。移行が完了すると、アセットにアクセスできるようになります。

画像と住所の移行は同期しません。ほとんどの場合、アカウントごとに別々のタイミングで移行されます。

どうすればアカウントが移行されたことがわかりますか？

移行のステータスを追跡するには、v13 以降の Customer リソースで提供される次のフィールドを使います。

• bool image_asset_auto_migration_done
• string image_asset_auto_migration_done_date_time
• bool location_asset_auto_migration_done
• string location_asset_auto_migration_done_date_time

v12 を使っている方は、UI で確認できます。アカウントが移行されると、アラートが表示されます。

自動移行されると何が起きますか？

移行されたアカウントでは、フィードベースのエンティティに対する変更呼び出しが拒否されます。

質問などございましたら、フォーラムからご連絡ください。

Posted by Thanet Knack Praneenararat - Ads Developer Relations Team

Google Cloud は、日本時間 11 月 15 日（水）～ 16 日（木）の 2 日間にわたり、旗艦イベント Google Cloud Next Tokyo '23 を東京ビッグサイトにて開催します。今日は、Expo と Innovators Hive についてご紹介します。実際に体験したいと思ったら、ぜひこちらから事前登録をしておきましょう。

☁︎ Innovators Hive

Google Cloud の最新技術が体験できる、デベロッパーやエンジニアのためのエリアです。

Google Cloud のデモに触れたり、学習プログラムや認定資格の最新情報を入手できます。ぜひ会場で Google Cloud を共に学び、デベロッパー コミュニティと繋がりましょう。

Read More

Google Cloud は、日本時間 11 月 15 日（水）～ 16 日（木）の 2 日間にわたり、旗艦イベント Google Cloud Next Tokyo '23 を東京ビッグサイトにて開催します。今日は、Expo と Innovators Hive についてご紹介します。実際に体験したいと思ったら、ぜひこちらから事前登録をしておきましょう。

☁︎ Innovators Hive

Google Cloud の最新技術が体験できる、デベロッパーやエンジニアのためのエリアです。

Google Cloud のデモに触れたり、学習プログラムや認定資格の最新情報を入手できます。ぜひ会場で Google Cloud を共に学び、デベロッパー コミュニティと繋がりましょう。

┗ ペルソナゾーン

┗ ハンズオン セッション

┗ ラーニング ＆ 認定資格ブース

┗ コミュニティ ゾーン

┗ Champion Innovators ラウンジ 

┗ Google Cloud Certified ラウンジ

Innovators Hive のプログラム詳細はこちら

☁︎ Expo

Google Cloud の最新プロダクトやソリューション、パートナー、お客様の事例やデモを、エキスパートと交流しながら体験できるエリアです。ブースでは、Google Cloud を活用したソリューションやサービスをご覧いただけます。

┗ Google Cloud ブース

┗ AI Innovation

┗ スポンサーブース

┗ Mini TAP

┗ オープン ステージ

┗ Ask the Speaker

Expo の展示カテゴリ詳細はこちら

☁︎開催概要

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

日時 : 日本時間 2023 年 11 月 15 日（水） ~ 16 日（木）

会場 : 東京ビッグサイト（東京国際展示場）

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

ハッシュタグ : #googlecloudnext

- お問い合わせ -

Google Cloud Next Tokyo 運営事務局

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

この記事は Stephen Nusko による Chromium Blog の記事 "Smoothing out the scrolling experience in Chrome on Android" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 ...Read More

この記事は Stephen Nusko による Chromium Blog の記事 "Smoothing out the scrolling experience in Chrome on Android" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

一歩下がってすでにある機能に手を加えることで、パフォーマンスを大きく向上させることができる場合があります。今回の 速さと好奇心の投稿では、どのように Android 版 Chrome のスクロール操作を改善し、遅いスクロールによるジャンクを最終的に半分に減らすことができたかについて説明します。どのように問題を発見して評価したか、そしてそれがどのように今後のブラウザ エクスペリエンス設計の向上に役立ったかについて、お読みください。

ブラウザのパフォーマンスを測定するときは、ページ読み込み速度やウェブに関する指標を考えるのが一般的です。折りたたみ式などの新しいフォーム ファクタを含め、タッチ操作が一般的なモバイルでは、常にスムーズで応答性が高くなるようにするため、Chrome とのインタラクションも重視しています。特に最近力を入れているのが、スクロール時のジャンクを減らすことです。

先日は、ノイズをフィルタリングして、画面に表示されるコンテンツが瞬間的に移動するように見える現象を減らすことで、Android 版 Chrome のスクロール操作の指標を 2 倍に向上しました。この結果を得るためには、一歩下がって、Android 版 Chrome が iOS 版 Chrome に遅れをとっている理由を理解する必要がありました。 

プラットフォーム間で Chrome を比較したところ、あることがわかりました。iOS 版 Chrome のスクロールは一貫してスムーズでしたが、Android 版の Chrome のスクロールは、そこまで指に追従する感じではありませんでした。しかし、指標を確認したところ、ジャンクは時々起こるものの、iOS 版 Chrome と比較したときに感じたほど頻繁に発生するものではありませんでした。つまり、調査が求められる謎の現象が発生したということです。

入出力レートの調査

この指標が示していたのは、入力を受け取るレートが一貫していない場合が多いということです。しかし、入力レートはディスプレイのフレームレートよりも大きいため、通常は少なくとも 1 つの入力イベントで、表示するフレームの生成がトリガーされていました。ただし、このフレームが受け取る入力イベントが少なかったり多かったりすると、たとえ一定の速度でスクロールしていたとしても、画面のコンテンツが一貫性のない形で移動してしまう場合があります。

入力レートとフレームレートが異なるというこの問題は、以前に Chrome で対処しなければならなかった問題です。内部的には、入力を再サンプリングして、生成するフレームに対して相対的な一貫したポイントにおいて指があった場所を予測および推定しています。そのため、各フレームが一定の時間を表すようになり、スクロールは入力イベントのノイズに関係なくスムーズになるはずです。理想的なシナリオを次の図に示します。青い点は実際の入力イベント、緑は再サンプリング後の入力イベントです。再サンプリングしたものではなく、実際の入力イベントを使った場合、画面がスクロールする差分量は変動します。

すでに再サンプリングを行っているのに、問題が発生するのはなぜでしょうか？

苦難と再実装のストーリー

Chrome（と Android）に入力の再サンプリングが追加されたのは、90 Hz デバイスが登場し、上記の問題が目立ち始めた 2019 年です（フレームあたりの入力イベントが 2 つと 1 つで振動します。60 Hz デバイスでは、フレームあたり常に 2 つの入力イベントが一般的です）。Android には複数の再サンプリング アルゴリズム（カルマン、線形など）が実装されていますが、今回のユースケースには、線形再サンプリング（2 点間を線で結んで速度を計算し、指定されたタイムスタンプを補完する）で十分であるという結論に達しました。これにより、ほとんどの Android アプリの問題は修正されましたが、Chrome の問題には対処できませんでした。

これまでの経緯や未加工の入力に対するウェブ仕様の要件の関係で、Chrome ではバッファリングされていない入力が使われています。そのため、入力に適合しないサンプリング レートのデバイスが登場し始めたときに、Chrome になんらかのバージョンの再サンプリングを実装する必要が生じました。下の図から、各フレーム（入力から表示までの時間を測定したもの）が受け取る入力イベントの数は異なることがわかります（最初のフレームは 2 つ、2 番目のフレームは 3 つ、3 番目のフレームは 1 つ）。入力が一貫して到着し、それぞれが正確に 30 ピクセルの変位であれば、次に示すように、1 フレームあたり 60 ピクセルに平滑化するのが理想です。

しかし、もともとの謎を調査している間にわかったのは、現実は上の理想的な状況とは大きく異なることでした。実際の画面の入力の動きは急激で（予想以上に）一貫性がなく、予測によって多少は改善されているものの、期待したほどではありませんでした。左は画面上の実際の指の変位（各点は入力イベント）、右は平滑化後の実際のコンテンツのオフセットの予測結果（各点はフレーム）です。

右側ではフレームは一貫して表示されていますが、互いの変位スパイクのレートは一貫していません（最も激しいのは、-50、-40、-52 の部分です）。人間の指は、（フレームレベルの精度で）このような不連続な動きにはなりません。むしろ、徐々に加速したり減速したりしながら、少しずつ移動したり方向を変えたりします。そのため、ここに問題があると考えました。Chrome の実装を詳しく調べたところ、そこに根本的な違いがあることがわかりました（Android の実装をコピーしたものだと思われます）。

1. Android ではネイティブの C++ MotionEvent タイムスタンプ（ナノ秒精度）が使われていますが、Chrome では Java の MotionEvent.getEventTime と MotionEvent.getHistoricalEventTime（ミリ秒精度）が使われています。残念ながら、ナノ秒精度の機能は、パブリック API には含まれていませんでした。しかし、ミリ秒に丸めてしまうと、イベントのタイムスタンプ間の速度を計算するときにうまく予測ができなくなる可能性があります。 

2. Android の実装では、2 つの入力イベントを慎重に選択しています。そのため、再サンプリングには最も関連性の高いイベントが使われています。一方の Chrome は、入力イベントの単純な FIFO キューを使っています。そのため、高リフレッシュレート デバイスでは、まれに未来のイベントを使用して過去の速度を予測するという奇妙なケースが発生する可能性があります。

Android の再サンプリングを使って Chrome のプロトタイプを作成しましたが、それはまだ Chrome のアーキテクチャとして完璧ではなく、ジャンクが起きることがわかりました。これを改善するため、自動化を活用して同じ入力を何度も繰り返し再生し、画面の変位曲線を評価するさまざまなアルゴリズムを実験しました。チューニングの結果、1€ フィルタの実装が最適であることがわかり、スクロール操作が目に見える形で大幅に改善しました。このフィルタを使うことで、画面が指を細かくトラッキングできるようになり、ウェブサイトのスクロールがスムーズになって、一貫性のない入力イベントによるジャンクを防止できるようになりました。手動で検証しても、トップエンド デバイスとローエンド デバイスの両方で、この改善の成果を明確に確認できます（redmi 9A の動画サンプルはこちら）。

今後に向けて

Android 14 では、SDK で Java の MotionEvents 用のナノ秒 API が公開されるため、Chrome（や入力をバッファリングしていない他のアプリ）から呼び出せるようになります。スクロール予測フレームの品質を追跡する新しい指標も作成しました。これは、ピクセルレベルのフレームの違い（その他の形態のジャンクは含めていません）を作り出すテストアプリを作成し、気づいたことを確認する実験をもとにしています。この分析の詳細は、こちらから確認できます。今後、さらに効果的なパフォーマンスの改善や、目に見える形でのリグレッションの追跡に活用する予定です。最終的にチューニングをし 1€ フィルタを有効にした結果、ゆっくりスクロールしているときの目に見えるジャンクは、指標上半分に減少しました。この改善はデフォルトとして M116 で公開されますが、M110 までさかのぼってリリースされます。これにより、Android 版 Chrome が iOS 版 Chrome と同等になります。

このストーリーから、次の教訓を得ることになりました。指標はすべてのケースをカバーしていない場合があります。一歩下がって徹底的に調査して状況を理解することで、ユーザーにとって優れたスクロール操作を実現できます。

Posted by Eiji Kitamura - Developer Relations Team

この記事は Thanet Knack Praneenararat による XXX Blog の記事 "Announcing v14 of the Google Ads API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 ...Read More

この記事は Thanet Knack Praneenararat による XXX Blog の記事 "Announcing v14 of the Google Ads API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

この度、Google Ads API の v14 リリースをお知らせします。v14 の一部の機能を使うには、クライアント ライブラリとクライアントのコードをアップグレードする必要があります。更新版のクライアント ライブラリとコードサンプルは、来週（元記事公開時）公開されます。

主な機能は以下のとおりです。

• 次の最適化案の種類を追加しました。DynamicImageExtensionOptInRecommendation、LowerTargetRoasRecommendation、RaiseTargetCpaRecommendation

• Customer.offline_conversion_client_summaries を追加し、顧客のオフライン コンバージョン アップロードと調整のステータスと診断情報を表示できるようにしました。

• CustomerNegativeCriterion.negative_keyword_list を使ったアカウント単位での除外キーワードの取得、作成、更新に対応しました。

• コンバージョン アクション タイプと ConversionAction.google_analytics_4_settings を追加し、Google アナリティクスのコンバージョンを特定したり、コンバージョンは GA4 またはユニバーサル アナリティクスからインポートされたかを特定できるようにします。

• campaign_criterion_simulation レポート取得のサポートを削除しました。

• KeywordPlanIdeaService.GenerateKeywordForecastMetrics を追加し、KeywordPlanService で削除された複数のメソッドの代替としました。この新しいメソッドでは、最初にキーワード プランを作成する必要はありません。

さらに詳しく知りたい方へ

以下のリソースが役立ちます。

• リリースノート

• ガイド

• リファレンス

• v13 と v14 の差分

ご質問やさらにサポートが必要なことがありましたら、フォーラムからご連絡ください。

Posted by Thanet Knack Praneenararat - Ads Developer Relations Team

この記事は Joshua Cruz による Chromium Blog の記事 "Redesigning Chrome downloads, to keep you productive and safe online" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

...Read More

この記事は Joshua Cruz による Chromium Blog の記事 "Redesigning Chrome downloads, to keep you productive and safe online" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

デスクトップ版 Chrome の最新リリースで、Chrome のダウンロード エクスペリエンスを刷新し、最近のダウンロードに対する操作をさらに簡単に行えるようにしました。Chrome シニア プロダクト マネージャーの Jasika Bawa から、今回の刷新の舞台裏について詳しい話を聞いてみましょう。

Chrome のダウンロードを刷新するという判断をしたのはなぜですか？

ダウンロードは日々のウェブ ブラウジングに欠かせない操作です。猫をテーマにした完璧な背景をパソコン用に入手することから、納税申告書のコピーを保存することまで、その用途はさまざまです。私たちは、Chrome の以前のダウンロード エクスペリエンスについてのフィードバックを長年にわたって受け取ってきました。中核的なダウンロード操作のサポートや潜在的に有害なファイルに対する組み込みの保護など、優れた機能がたくさんあることはわかっていますが、問題点もありました。たとえば、次のようなことです。

• 画面下部の貴重なピクセルを占有するため、ウェブ コンテンツ領域が狭くなり、画面の幅によって一度に表示できるファイルの数が制限されていた

• 自動で消えることがなく、固定のオーバーフロー メニューで提供されていたアクションは、一時停止や再開、フォルダを開くなどだけだった

• モダンでインタラクティブなものでなく、他のブラウザの UI やブラウザのエコシステム全体の外観との整合性がなくなっていた

こういったすべての点について考えれば、ダウンロード エクスペリエンスをさらに直感的なものにするために、Chrome を改善する余地があったのは明らかでした。

今回の刷新によって提供すべきものは何ですか？

画面下部にあった以前のダウンロード エクスペリエンスに代わり、Chrome のアドレスバーの右側に新しいダウンロード トレイが表示されます。ダウンロードが進行中の場合、アニメーションするリングから一目で進行状況を確認できます。ファイルのダウンロードが終わると、トレイが開き、自動的に非表示になります。そのため、すばやく簡単にアクセスできるだけでなく、閲覧が中断することもありません。

ダウンロード トレイでは、過去 24 時間のすべてのダウンロードのリストを確認できます。このトレイは、ダウンロードを始めたブラウザ ウィンドウだけでなく、すべてのウィンドウから確認できます。トレイにはインライン オプションも用意されており、ダウンロードしたフォルダを開く、ダウンロードをキャンセルする、なんらかの理由で失敗したダウンロードを再試行する、ダウンロードの一時停止や再開を行うといった操作が可能です。

新しいダウンロード エクスペリエンスは、オンラインで人々の安全を保つことにどう貢献しますか？

私たちがいつも重視しているのは、ファイルをダウンロードする際の安全性です。マルウェアやウィルスの可能性がある場合、Chrome は今後も明確な警告を表示し続け、デバイスやアカウントを守ります。実際に、Chrome の新しいダウンロード エクスペリエンスでは、スペースが広くなり、UI も柔軟になっているので、悪意のある可能性のあるファイルからユーザーを保護するために提供できる情報が増え、高度なディープ スキャン オプションも実現できるようになっています。これは、以前にはできなかったことです。詳しくは、近日公開予定の Google セキュリティ ブログをご覧ください。

ダウンロードの警告だけではありません。ダウンロード トレイは、Chrome のアドレスバーの横の決まった位置に表示されるので、信頼できるブラウザの UI とウェブ コンテンツを明確に分離するうえで役立ちます。これは、今回の刷新でどうしても実現したかった点でした。

新しいダウンロード エクスペリエンスに簡単に移行できるようにする方法として、どのようなことを考えましたか？

重要なことは、Chrome の新しいダウンロード エクスペリエンスで、以前の機能をすべて利用できるようにすることでした。 たとえば、今後も新しいダウンロード トレイから、ダウンロードしたファイルを別のフォルダやプログラム、ウェブサイトにドラッグしたり、「常に開く」などのアクションを行ったりできます。ダウンロードのさらに詳しい表示も、引き続き可能になっています。ダウンロード トレイの [ すべてのダウンロードを表示 ] オプションを選択するか、Chrome のその他メニューから [ ダウンロード ] をクリックするか、Chrome のアドレスバーに chrome://downloads と入力します。

また、初期の試験運用でのフィードバックを真摯に受け止め、ダウンロード トレイを開く頻度を調整するなどの変更を加えています。Chrome の設定から、自動でトレイを開かないようにすることもできます。

デベロッパーの対応が必要になることはありますか？

デベロッパーの皆さんにぜひお願いしたいのは、ユーザーのダウンロード操作をサポートするためにガイドやビジュアルを作成している場合、それを更新することです。まずは、Google Chrome ヘルプセンターのトピック、ファイルをダウンロードするを参照することを検討できるでしょう。

拡張機能デベロッパーの皆さんは、chrome.downloads 拡張機能 API の変更に注意してください。拡張機能の更新が必要になるかもしれません。具体的には、setShelfEnabled が setUiOptions に置き換えられ、新しいダウンロード エクスペリエンスの表示、非表示を切り替えられるようになっています。

公開されたばかりの新機能ですが、ぜひ使ってみてください！今後のリリースでは、ウェブからファイルをダウンロードする際の安全性を保ちながら、Chrome の生産性を維持できるように、引き続きこの機能を強化していきます。

Posted by Eiji Kitamura - Developer Relations Team