...
この記事は Andrew Burke による Google Ads Developer Blog の記事 "Feed-based Extensions Migration Reminder and Opt Out Instructions" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

以前お知らせしたように、すべての広告表示オプションは新しいアセットベースの拡張機能(表示オプション) パラダイムに移行します。そのため、実装の拡張機能のサポートをアップデートして、既存のフィードベースの拡張機能をアセットベースの拡張機能に移行する必要があります。すべての重要な移行や提供終了の日程については、移行スケジュールをご覧ください。

最初の自動移行は、2021 年 10 月 20 日に始まり、数週間にかけて完了する予定です。移行にあたっては、自分で拡張機能を移行することも、自動移行に任せることも、クライアント アカウントをオプトアウトして自動移行の対象外にすることもできます。移行期間中に、クライアント アカウントのフィードベースのコールアウト、プロモーション、サイトリンク、構造化スニペットの拡張機能は、新しいアセットベースの拡張機能にコピーされます。その後、フィードベースの拡張機能の代わりに、新しいアセットベースの拡張機能が提供されます。


自動移行にはどのような影響がありますか?

アカウントが移行されると、フィードベースのコールアウト、プロモーション、サイトリンク、構造化スニペットの拡張機能について、新しいアセットのインスタンスが作成されます。新しいアセットは、コピー元のフィードベースの拡張機能と同じ広告グループ、キャンペーン、お客様にリンクされます。新しいアセットには新しい ID が付与され、過去の指標も含め、自動移行で作成されたアセットとオリジナルのフィードには、関連付けられません。その後のすべての拡張機能に関連する指標は、asset_field_type_view レポートからのみアクセスできます。さらに、以下のサービスで、アカウントに存在するコールアウト、プロモーション、サイトリンク、構造化スニペットの拡張機能に影響する CREATE リクエストや MUTATE リクエストは行えなくなります。

サービス API リファレンス
ExtensionFeedItemService Google Ads API
AdGroupExtensionSettingService AdWords API Google Ads API
CampaignExtensionSettingService AdWords API Google Ads API
CustomerExtensionSettingService AdWords API Google Ads API
FeedService AdWords API AdWords API
FeedItemService AdWords API Google Ads API
FeedMappingService AdWords API Google Ads API
AdGroupFeedService AdWords API Google Ads API
CampaignFeedService AdWords API Google Ads API
CustomerFeedService AdWords API Google Ads API
GoogleAdsService Google Ads API
BatchJobService AdWords API Google Ads API


自動移行に任せる場合は、コールアウト、プロモーション、サイトリンク、構造化スニペットの拡張機能に影響する上記のサービスへの MUTATE リクエストや CREATE リクエストがエラーを返すようになると、アカウントが移行されたことがわかります。


オプトアウトにはどのような影響がありますか?

お客様アカウントごとにオプトアウトをし、10 月の自動移行の対象から外すことができます。オプトアウトをしても、自動移行のタイミングが 2022 年 2 月 15 日から始まる 2 回目の自動移行まで延期されるだけです。オプトアウトをすると、10 月の自動移行の際に、そのアカウントでリソースの作成や変更は行われません。また、10 月の自動移行後に CREATE リクエストと MUTATE リクエストの発行を続けることができるのは、オプトアウトしたアカウントのみです。

2022 年 2 月 15 日の自動移行はオプトアウトできません。移行スケジュールに記載されているように、残されているフィードベースの拡張機能は 2022 年 2 月 15 日以降、すべて自動移行されます。この 2 回目の自動移行が終わると、フィードベースの拡張機能に影響する CREATE リクエストと MUTATE リクエストは、すべてエラーを返すようになります。

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

可能な場合は、ご自身で拡張機能を移行することを強くお勧めします。 拡張機能を移行する際のガイダンスとして、拡張機能の移行ドキュメントに従ってください。自動移行の際に重複を避けるため、拡張機能をアセットにコピーでき次第、フィードベースの拡張機能を忘れずに削除してください。

自動移行に任せる場合、必要になる実装の更新は、アカウントが移行されたタイミングを検知し、その後にフィードではなくアセットを管理するように切り替えることだけです。


オプトアウトする場合、そのアカウントが自動移行によって変更されることはありません。既存の API 実装は、2022 年 2 月 15 日に始まる 2 回目の自動移行まで動作を続けます。オプトアウトするには、こちらのフォームに以下の内容を入力する必要があります
  • オプトアウトのプロセスで問題が発生した場合に連絡がとれる連絡先メールアドレス
  • アカウントの管理に使用しているデベロッパー トークン
  • オプトアウトの効果の確認
  • オプトアウトしたいお客様 ID を 1 行につき 1 件記述したテキスト ファイルのアップロード。お客様 ID のリストを生成する必要がある場合は、各クライアント ライブラリの AccountManagement ディレクトリにある GetAccountHierarchy サンプルを利用することをお勧めします。このサンプルは、指定した管理者アカウントから到達可能なすべてのアカウントのリソースの名前を返します。
このフォームは、2021 年 8 月 30 日から送信可能です。デベロッパー トークンは、2021 年 7 月 16 日以降にお客様アカウントよりリクエストをしたことが必要がある点に注意してください。フォームの提出の締め切りは、2021 年 10 月 13 日です。


ご質問やさらにサポートが必要なことがありましたら、フォーラムまたは googleadsapi-support@google.com にご連絡ください。



この度、 ...
この記事は Google Cloud プロダクト マネージャー、Christiaan Brand による Google Online Security Blog の記事 "Simplifying Titan Security Key options for our users" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

この度、Google ストアの Titan セキュリティ キーのラインナップの変更についてお知らせします。この変更によって、これまでよりもシンプルになり、適切なセキュリティ キーを簡単に選べるようになります。今後は、USB-A バージョンと USB-C バージョンの 2 種類の Titan セキュリティ キーのみを提供します。どちらのキーにも近距離無線通信(NFC)機能が搭載されているので、ほとんどのモバイル デバイスで利用でき、モバイル デバイスに接続したキーをタップするだけで安全にログインできます。

Google は 2018 年に、認証情報のフィッシングに対する直接的な防御として Titan セキュリティ キーを導入しました。フィッシングとは、攻撃者がユーザーを欺いてユーザー名とパスワードを入力させることを指します。これは、オンライン アカウントを侵害する方法の中でも、特に簡単で成功率の高い方法であり続けています。Titan セキュリティ キーと高度な保護機能プログラムによる業界トップクラスの自動保護の組み合わせは、Google アカウントを安全に保つために特に効果的な方法の 1 つです。


新しい Titan セキュリティ キー オプションの紹介

現在、NFC 機能はさまざまな Android スマートフォンや iPhone でサポートされているので、Bluetooth Titan セキュリティ キーは終了し、今後は、より簡単で広く使われている NFC 機能に注力します。ただし、Bluetooth Titan セキュリティ キーを使っている既存ユーザーのために、これらのキーは引き続き Bluetooth でも動作し、ほとんどの最新モバイル デバイスでは NFC キーとして利用することもできます。既存の Bluetooth Titan セキュリティ キーに適用されている保証は、利用規約に応じて今後も継続されます。すべての Titan セキュリティ キーには、Google が制作したファームウェアを搭載したハードウェア セキュア エレメント チップが組み込まれているので、キーの整合性を検証できます。

USB-A ポートを搭載したコンピュータをお持ちの方には、USB-A + NFC セキュリティ キーをお勧めします。

USB-C ポートを搭載したコンピュータをお持ちの方には、USB-C + NFC セキュリティ キーをお勧めします。


USB-C コネクタを搭載した iPad をお持ちの方は、USB-C Titan セキュリティ キーを利用できます。Lightning コネクタを搭載した iPad をお持ちの方には、USB-A Titan セキュリティ キーと Apple Lightning アダプタをお勧めします。


Titan セキュリティ キーは、Google ストアで購入できます。USB-A + NFC キー(USB-A to USB-C アダプタ付き)は 30 ドル、USB-C + NFC キーは 35 ドルで販売しています。
セキュリティ キーがフィッシング対策にどう役立つかを詳しく知りたい方は、Titan セキュリティ キー プロダクト ページをご覧ください。

Reviewed by Eiji Kitamura - Developer Relations Team

この記事はデベロッパー アドボケート、Charles Maxson、戦略クラウド エンジニア、Justin Wexler による Google Developers Blog の記事 "Deliver asynchronous notifications in Google Chat using webhooks" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google Workspace がチーム コラボレーションの未来を再定義し、Google Chat のルームは Spaces へと進化している中で、現在のチャットルームですでに利用できる Webhook は、ユーザーが作業するチャットルームに直接非同期メッセージを提供できる便利な機能です。Chat の Webhook は、使いやすい機能で、Google Chat API を使ってユーザーと同期的に通信する専用のアプリケーションである Chatbot と違い、ボットではないアプリケーションで Google Chat への非同期メッセージングを実現します。この投稿では、Chat での Webhook の使い方について説明し、Google 内部で実際に使っているユースケースを紹介します。

Google Chat で Webhook を使う事例

Google Chat では、さまざまな目的でルーム(現在は Spaces)を作成して使用することができます。セールス サポートやカスタマー サービスといったトピックなど、テーマに沿ったルームもあれば、特定の部門や全社での会話のように、もう少し汎用的なルームもあります。しかし、こういったユースケースは、すべて人間の活動が中心になっています。そのため、これらへの依存が高まれば高まるほど、お互いのコミュニケーションにとって重要な方法になります。

Webhook を利用すると、他のシステムやアプリケーションから、ルームや会話のテーマに沿った最新の情報を導入できます。そのため、ルームのレベルが飛躍的に向上します。たとえば、セールス サポートのルームで Webhook を使うと、商談がまとまったタイミングや RFP の締め切りが近づいたタイミングで CRM システムからアラートをユーザーに通知できます。カスタマー サービスのルームで Webhook を使うと、リクエストに対して緊急のアラートを投稿し、チーム全体の注目を集めることができます。汎用的なルームで Webhook を使うと、部門のユーザーに今後の締め切りについて通知したり、株式市場の取引時間終了時に会社の株価を全社員に広く共有したりできます。Webhook を使うと、状況を問わず、効率的かつリアルタイムにデータや情報を提供できます。

Google での実際のユースケース

Google には、G Workspace Community という名前のチャットルームがあり、質問やプロダクト全体の最新ニュースを取得したい Google 社員同士や、Google Workspace のカスタマー チームとの交流に使われています。ご想像どおり、このルームは広く使われており、毎日たくさんの投稿や回答が行われています。特によく議論されるのは、リリースのタイミングに関する情報や、ロードマップでのステータスなど、新機能に関するトピックです。

Google では、Workspace の新機能が公開されるときに全員に周知できるように、Google Workspace Updates ブログの公開フィードも作成しています。G Workspace Community の全メンバーが Updates ブログも購読し、リリースされるすべての機能について最新情報を受け取れていると想定するのは論理的かもしれません。しかし実際は、G Workspace Community チャットルームが主要なリソースになっており、Google 社員はそこで Google Workspace の最新情報を取得しています。そのため、チャットルームにリリースについての質問を投稿する前にブログをチェックしてもらう代わりに、Google Workspace Community ルームに Google Workspace Updates フィードを持ち込むことにしました。これは、Google Chat の Webhook を使って簡単に実現できます。そして現在は、誰もが Google Workspace から簡単にすべての最新情報を取得できるようになっています。

Google Workspace Updates「ボット」の紹介

Updates ブログで Workspace の新機能についての投稿が公開されると、Google Workspace Updates「ボット」(内部的には、作成者の Justin Wexler にちなんで Google Wexbot と呼ばれています)がチャットルームに新しいスレッドを追加し、そこに投稿のタイトルとメイン コンテンツの最初の 250 文字を送信します。これにより、ルームのメンバーは新機能についてすばやく把握できるだけでなく、ブログの内容についてすぐに議論を始めることもできます。メンバーは、機能リリースについて質問したりコメントを追加したりできるので、はるかに高度なコラボレーション体験が実現します。また、[READ MORE] をクリックするだけで Updates ブログの全文を読むこともできます。

Google Workspace Updates ボットのイメージ

Webhook + Apps Script = 魔法

このような最新情報をタイムリーに受け取るコミュニティのメンバーにとって、この「ボット」は魔法のように思えるかもしれません。実際には、これは魔法でも従来型のチャットボットでもありません。そのため、Chat の UI でこれを「ボット」と呼ぶのは正しい表現ではありません。実は、Google Updates「ボット」は単純な Google Apps Script アプリケーションです。このアプリケーションは、新しい投稿の RSS フィードを解析し、Webhook 経由で非同期的にルームに送信します。

Apps Script は、一定の間隔で実行できるトリガー(すなわち cron ジョブ)を提供するので、このユースケースに適しています。この仕組みを利用して Updates ブログの新しい投稿をチェックし、投稿のフィード XML を解析し、UrlFetchApp を呼び出して待機している Webhook に Chat Card 形式で結果を返します。

Google Workspace Updates「ボット」の内部実装では、1 時間に 1 回 Apps Script トリガーが実行され、Update ブログの新しい投稿をチェックしています。さらに、プロジェクト自体がさほどコード量が多くない 1 つの Apps Script プロジェクト ファイルになっており、チャットルームの設定も簡単なうえ、実質的にメンテナンスの手間もかかりません。Justin がオリジナル バージョンを作るためにかけた時間は、たった数日でした。しかし、ユーザーにとっての価値は明らかだったため、作者にちなんだ名前が付けられることになったのです ;)

Google Workspace Updates「ボット」(通称 Wexbot)を自分のチャットルームに追加する

自分の Google Workspace Updates「ボット」を追加してみたい方や、他のユースケースを実現するために Apps Script を使って Webhook 経由で Google Chat に非同期メッセージを送る方法を知りたい方のために、GitHub でプロジェクトを公開しています。ぜひ確認して、実装してみてください。

Google Chat Updates Bot Project - GitHub

README | Apps Script Code.js

その他のリソース

Google Workspace の Chatbot や Webhook の詳細については、以下のリソースをご覧ください。

Google Workspace デベロッパー ニュースレターへの登録もお忘れなく!


Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Filip Verley(Google Identity、プロダクト マネージャー)による Google Developers Blog の記事 "Launching our new Google Identity Services APIs" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google は日々、デフォルトで安全で、設計上プライベートなプロダクトを構築することを通して、ユーザーが自分のデータを管理できるようにすることに注力しています。しかし、一般的なオンラインのセキュリティ脆弱性は、Google のプロダクト以外の部分、すなわちオンライン アカウントに不適切なパスワードでログインすることによって生じています。データ漏洩によって毎日膨大な数のパスワードが漏れ出し、ユーザーの個人情報が危険にさらされています。Google が最優先しているのは、オンラインのユーザーの安全を守ることです。そこで私たちは、個人情報を安全に保つための新しいツールや機能の開発に継続的に取り組んでいます。

この度(元記事公開当時)、Google Identity Services という新しい一連の Identity API をリリースします。これは、複数の ID サービスを 1 つのソフトウェア開発キット(SDK)にまとめたものです。この SDK には、Google でログインするためのボタンや、簡単に利用できる新しい認証プロンプトである One Tap が含まれています。Google でログインと One Tap は、パートナーのウェブサイトやアプリにログインするのにパスワードではなく、安全なトークンを利用します。

この取り組みは、プライバシーやセキュリティを損なわない ID ソリューションを提供することを目的として始まりました。そして今回、それが実現できました。新しい Google Identity Services は、業界トップクラスの Google のセキュリティと、簡単なログインによる究極の利便性を組み合わせることで、ユーザーを安全に保ちつつ、新しいユーザーの獲得やリピーターのシームレスなログインを促進する体験を提供します。

利用できる新機能

One Tap は、先回り型のシームレスなログイン プロンプトで、ユーザーがウェブサイトやアプリを使ってパーソナライズされたコンテンツに安全にアクセスする際に役立ちます。従来のログインボタンとは異なり、One Tap はどんなページからでもプロンプトを表示できます。そのため、ユーザーをランディング ページにリダイレクトする必要はなく、ユーザーのナビゲーションの意図が妨げられることはありません。One Tap プロンプトは、ウェブサイトでは右上から下に向かって、モバイル デバイスでは下から上に向かってスライドして表示されます。ユーザーは、1 回タップするだけでログインや登録をすることができ、認証情報を覚えたり、パスワードを作成したりする必要はありません。パートナーは、この認証ソリューションを使って大きな成果を上げています。劇的に手間が少なくなることで、ウェブサイトやアプリでのユーザーのログイン率や登録率が増加しました。 

モバイル デバイスで下から表示される One Tap プロンプト
モバイル デバイスで下から表示される One Tap プロンプト

Google Identity Services プロダクトは、クリック ジャッキングやピクセル トラッキングなどの脆弱性、その他の脅威からの保護も考慮されています。そのため、ユーザーは安心してウェブサイトやアプリを利用できます。すべての Google アカウントには、強固な不正利用対策や不正防止システムが適用されています。そのため、Google Identity Services を使うことで、重複アカウントや不正アカウントによるリスクを軽減でき、サポートの負荷も減少します。

さらに、Google でログインするためのボタンの改善版をロールアウトし、リピーターに対してユーザー固有の詳細情報を表示するようにしました。これにより、選択されるユーザー アカウントが表示されるようになります。Google でログインするボタンでは、ウェブ全体での UI/UX の整合性も向上しており、プラットフォーム全体で信頼性とセキュリティを向上することができます。


ユーザー固有の情報を含めた Google でログインするボタンを青と白の背景で表示



Reddit は先日、Google でログインするボタンと One Tap プロンプトの両方を実装しました。これにより、新しいユーザーの登録数と、リピーターのコンバージョンがほぼ 2 倍に増加しました。また、Pinterest は Google Identity Services を実装し、ログインと登録の両方で優れた成果を上げています。その方法もお読みいただくことができます。


Reddit のウェブサイトの右上に表示される One Tap プロンプト
Reddit のウェブサイトの右上に表示される One Tap プロンプト

使ってみるには

Google は、デベロッパーの実装プロセスを簡単にし、最低限のコードで実現できるように懸命に作業を進めています。ぜひこの新しい API スイートを使い、ビジネスの成長にお役立てください。新しい Google Identity Services の実装を始めるには、デベロッパー サイトで技術ドキュメントをご覧ください。技術サポートを受けたい方は、Stack Overflow で google-signin タグをチェックしてください。



Reviewed by Eiji Kitamura - Developer Relations Team

...
この記事は David Stevens による Google Ads Developer Blog の記事 "Google Ads API 2022 release and sunset schedule" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

計画サイクルをより明確にするために、今後のバージョンの Google Ads API について、2022 年のリリースと提供終了の暫定スケジュールをお知らせします。以下の日付は単なる想定であり、今後変更される可能性があることにご注意ください。また、リリースの追加や削除、メジャー版とマイナー版の切り替えが発生する可能性もあります。最新情報は、リリースノートサポートの終了スケジュールでご確認ください。

注 : AdWords API は、2022 年 4 月に提供を終了する予定です。Google 広告アカウントの管理を続けるには、それまでにすべてのリクエストを Google Ads API に移行してください。
バージョン 計画されているリリースの
種類 *
プロジェクトのリリース * プロジェクトの提供終了 *
v7 メジャー 2021 年 4 月 28 日(リリース済み) 2022 年 1 月 / 2 月
v8 メジャー 2021 年 6 月 9 日(リリース済み) 2022 年 3 月 / 4 月
v8_1 マイナー 2021 年 8 月 2022 年 3 月 / 4 月
v9 メジャー 2021 年 10 月 2022 年 6 月 / 7 月
v10 メジャー 2022 年 2 月 / 3 月 2022 年 10 月 / 11 月
v10_1 マイナー 2022 年 4 月 / 5 月 2022 年 10 月 / 11 月
v11 メジャー 2022 年 6 月 / 7 月 2023 年 3 月 / 4 月
v11_1 マイナー 2022 年 8 月 / 9 月 2023 年 3 月 / 4 月
v12 メジャー 2022 年 10 月 / 11 月 2023 年 6 月 / 7 月
* 想定であり、変更される可能性があります

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

以下のリソースは、開発の計画を立てるうえで役立ちます。 ご質問やさらにサポートが必要なことがありましたら、フォーラムからご連絡ください。



この記事は Chromium Blog の記事 "Chrome 93: Multi-Screen Window Placement, PWAs as URL Handlers, and More" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

特に記載のない限り、下記の変更は Android、Android WebView、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2021 年 7 月 29 日の時点で Chrome 93 はベータ版です。

オリジン トライアル

このバージョンの Chrome には、以下のオリジン トライアルが導入されています。オリジン トライアルとして新機能を試せるようにすることで、ウェブ標準コミュニティにユーザビリティ、実用性、有効性についてのフィードバックを提供することができます。以下の項目を含め、現在 Chrome でサポートされているオリジン トライアルに登録するには、Chrome オリジン トライアル ダッシュボードをご覧ください。Chrome のオリジン トライアルの詳細については、ウェブ デベロッパーのためのオリジン トライアル ガイドをご覧ください。Microsoft Edge は、Chrome とは別に独自のオリジン トライアルを行っています。詳細については、Microsoft Edge オリジン トライアル デベロッパー コンソールをご覧ください。

新しいオリジン トライアル

Cross-Origin-Embedder-Policy: credentialless

credentialless キーワードを使って、Cookie やクライアント証明書などの認証情報を省略したクロスオリジン no-CORS リクエストが可能になりました。COEP: require-corp と同じように、クロスオリジン分離も有効化できます。

SharedArrayBuffer を使い続けたいサイトでは、クロスオリジン分離をオプトインする必要があります。現在は COEP: require-corp が存在し、クロスオリジン分離の有効化に利用されています。これは確実に機能しますが、すべてのサブリソースで明示的にオプトインしなければならないので、大規模な導入は難しいことがわかっています。これが問題にならないサイトもありますが、ユーザーからコンテンツを収集するサイト(Google Earth、一般的なソーシャル メディア、フォーラムなど)では、依存関係の問題が発生します。

マルチスクリーン ウィンドウの配置

Multi-Screen Window Placement API を使えば、マシンに接続された任意のディスプレイへのウィンドウの配置、その配置の保存、任意のディスプレイでのウィンドウの全画面表示が可能です。プレゼンテーション アプリでこの API を使うと、ある画面にスライドを、別の画面に発表者用のノートを表示できます。アートや音楽の制作アプリでは、2 つ目の画面にパレットを配置できます。また、レストランなら、座席側にタッチスクリーン メニューを、従業員側に別のウィンドウを表示できます。この API は、最初のオリジン トライアルでのデベロッパーからのフィードバックに基づいて形状や人間工学が改善され、2 回目のオリジン トライアルに入ります。

インストールされたデスクトップ版ウェブアプリ向けのウィンドウ コントロール オーバーレイ

ウィンドウ コントロール オーバーレイは、ウィンドウ全体を覆うようにアプリのクライアント領域を拡張します。この領域には、タイトルバー、ウィンドウのコントロール ボタン(閉じる、最大化/復元、最小化)も含まれます。ウェブアプリのデベロッパーは、ウィンドウ コントロール オーバーレイを除くウィンドウ全体の描画と入力ハンドリングをする必要があります。この機能を使うと、デベロッパーはインストールされたデスクトップ版ウェブアプリを OS のアプリのように見せることができます。詳しくは、PWA のタイトルバーのウィンドウ コントロール オーバーレイをカスタマイズするをご覧ください。

URL ハンドラとしての PWA

URL ハンドラとしての PWA を使うと、music.example.com のようなアプリが、自分自身を https://music.example.comhttps://*.music.example.comhttps://🎵.example.com といったパターンに一致する URL のハンドラとして登録できます。これにより、インスタント メッセンジャー アプリケーションやメール クライアントなどの PWA の外部からのリンクが、ブラウザのタブではなく、インストールした PWA で開くようになります。

完了したオリジン トライアル

Chrome で以前にオリジン トライアルが行われていた以下の機能は、現在デフォルトで有効化されています。

ウェブバンドルによるサブリソースの読み込み

ウェブバンドルは、複数のリソースをバンドルできるフォーマットを使って大量のリソースを効率的に読み込むための新たなアプローチです。この機能は、以前のリソース バンドルへのアプローチが抱えていた問題に対処します。

一部の JavaScript バンドラの出力は、HTTP キャッシュをうまく扱うことができず、設定が難しくなる場合もあります。バンドルされた JavaScript でも、すべてのバイトがダウンロードされるまで実行を待つ必要があります。複数のサブリソースを読み込む場合、ストリーミングと並列化を使用するのが理想ですが、これは 1 つの JavaScript ファイルでは実現できません。JavaScript モジュールでは、決定的実行の関係で、リソースツリー全体がダウンロードされるのを待ってから実行する必要があります。

WebXR Plane Detection API

WebXR アプリケーションで、ユーザーの環境に存在する平面のデータを取得できるようになります。これにより、拡張現実アプリケーションでさらに臨場感の高い体験を実現できます。この機能がない場合、デベロッパーは getUserMedia()navigatorMediaDevices で利用可能)のデータに対して独自のコンピュータ ビジョン アルゴリズムを実行してユーザーの環境に存在する平面を検知するしかありませんでした。そのため、このようなソリューションでは、ネイティブの拡張現実機能に匹敵する質や精度を実現したり、ワールド スケールをサポートしたりすることはできませんでした。

今回のリリースに追加されたその他の機能

AbortSignal.abort() 静的メソッド

静的メソッドである AbortSignal.abort() は、すでに中止された AbortSignal オブジェクトを新しく作成します。これは Promise.reject() と同じような考え方で、デベロッパーの人間工学を改善します。

ウェブ デベロッパーは、中止された AbortSignal オブジェクトをさまざまな目的に役立てることができます。これを使って、作業をしないように JavaScript API に指示します。現在、すでに中止された AbortSignal オブジェクトを作るには、複数行のコードが必要です。AbortSignal.abort() を使うと、次の 1 行で作成できます。

return AbortSignal.abort();

CSS Flexbox: alignment キーワードが start、end、self-start、self-end、left、right をサポート

flexbox と flex 項目が位置ベースの alignment キーワード従うようになります。これまでの flexbox は、centerflex-startflex-end のみに従っていました。追加された alignment キーワード(startendself-startself-endleftright)を使うと、flex 項目の位置をさまざまな書き込みモードや flex フローに簡単に合わせることができます。

これらの追加キーワードがない場合、書き込みモード、テキストの方向、flex の逆方向プロパティ(flex-direction: row-reverseflex-direction:column-reversealign-content: wrap-reverse)を変えるたびに、キーワードの値を変更する必要があります。今回実装されたキーワードを使うと、alignment を一度設定するだけで済みます。

Error.cause プロパティ

Error() コンストラクタが cause という新しいオプション プロパティをサポートし、これはプロパティとしてエラーに割り当てられます。これにより、エラーを条件でラップするという不必要で複雑な作業をすることなく、エラーをチェーンさせることができます。

meta name=theme-color が media HTML 属性を反映

meta[name="theme-color"]meta 要素の "media" 属性が反映されます。これにより、ウェブ デベロッパーがメディア クエリに基づいてサイトのテーマカラーを調整できるようになります(ダークモードとライトモードなど)。最初に一致したものが選択されます。

HTMLMediaElement.controlsList の noplaybackrate

HTMLMediaElement.controlsList プロパティが noplaybackrate をサポートします。これにより、ブラウザが公開する再生速度のコントロールをウェブサイトで有効化または無効化できるようになります。ブラウザ ベンダーが再生速度のコントロールをメディア コントロールに追加したことで、デベロッパーはこの新しいコントロールの表示を制御する方法が得られます。新しいプロパティは、HTMLMediaElement.controlsList のサンプルの noplaybackrate で試すことができます。

Sec-CH-Prefers-Color-Scheme Client-Hint ヘッダー

CSS ユーザー プリファレンス メディア機能の prefers-color-scheme は、ページで提供する必要がある CSS の量とページ読み込み時のユーザー エクスペリエンスに大きな影響を与える可能性があります。新しい Sec-CH-Prefers-Color-Scheme Client-Hint ヘッダーを使うと、サイトのリクエスト時にオプションでユーザー プリファレンスを取得できるので、サーバーは適切な CSS をインラインで提供できます。そのため、一瞬だけ適切でないカラーテーマが表示されることを回避できます。

User-Agent Client-Hint API のアップデート

このバージョンの Chrome には、User-Agent Client-Hint API に 4 つの新機能と変更点が追加されています。

  • Sec-CH-UA-Bitness: ユーザー エージェントが動作するプラットフォーム アーキテクチャのビットネスに関する情報をサーバーに提供するためのリクエスト ヘッダーです。ビットネスとは、特定のシステムが評価できる基本値を構成するビットの数を表します。
  • Sec-CH-UA-Platform を低エントロピー ヒントに変更 : Sec-CH-UA-Platform は、ユーザー エージェントが動作するプラットフォームに関する情報をサーバーに提供するためのリクエスト ヘッダーです。
  • 低エントロピー ヒントを UADataValues.getHighEntropyValues() に追加 : ヒントが高エントロピーから低エントロピーに移動した場合、それに依存するコードの将来性が保証されます。
  • NavigatorUAData.toJSON() メソッドの改善 : このメソッドが便利なデータを返すようになります。

低エントロピー ヒントとは、あまり多くの情報を公開しないヒントや、他の方法で簡単に検出できるため現実的に隠蔽するのは難しい情報を提供するヒントです。Client-Hint においては、関連するオリジンがリクエストしたかどうかにかかわらず、また関連するフレームがファースト パーティかサード パーティかにかかわらず、すべてのリクエストで利用できるヒントを指します。

WebOTP API: クロスデバイスのサポート

デスクトップ向け Chrome と Android Chrome の両方が同じ Google アカウントにログインしている場合、PC でも WebOTP API がサポートされます。WebOPT API は、プログラムによってオリジン宛ての特定の形式の SMS メッセージからワンタイム コードを読み取る機能を提供するため、ログイン時のユーザーの手間を減らすことができます。これまで、この機能は SMS がサポートされるモバイル デバイスのみで利用できました。

JavaScript

このバージョンの Chrome には、V8 JavaScript エンジンのバージョン 9.3 が組み込まれます。具体的には、以下の変更点が含まれます。最新の機能リストをすべて確認したい方は、V8 リリースノートをご覧ください。

Object.hasOwn

新しい Boolean 型のプロパティである Object.hasOwn は、使いやすい静的メソッド バージョンの Object.prototype.hasOwnProperty を提供します。

サポートの終了と機能の削除

このバージョンの Chrome では、以下のサポートの終了と機能の削除が行われます。現在サポートが終了している機能および以前に削除された機能のリストは、ChromeStatus.com をご覧ください。

ポート 989 と 990 のブロック

ポート 989 と 990 による HTTP、HTTPS、FTP サーバーへの接続が失敗するようになります。これらのポートは FTPS プロトコルで使われていますが、FTPS は Chrome では実装されていません。ただし、悪意のあるウェブページが FTPS サーバーに対して、綿密に作成された HTTPS リクエストを使ったクロスプロトコル攻撃を仕掛ける可能性があります。これは、ALPACA 攻撃の緩和策になります。

TLS から 3DES を削除

Chrome で、TLS_RSA_WITH_3DES_EDE_CBC_SHA 暗号スイートのサポートが削除されます。TLS_RSA_WITH_3DES_EDE_CBC_SHA は、SSL 2.0 と SSL 3.0 時代の遺物です。トランスポート レイヤー セキュリティ(TLS)での 3DES は、Sweet32 攻撃に対して脆弱です。これは CBC 暗号スイートであるため、Lucky Thirteen 攻撃に対しても脆弱です。TLS では、最初の代替案である AES 暗号スイートが 19 年ほど前に公開された RFC3268 によって定義され、その後も何度かの反復が行われています。

WebAssembly のクロスオリジン モジュール共有

エージェント クラスタが長期的にオリジンにスコープできるように、クロスオリジンでありながら同一サイト環境であるサイト間での WebAssembly モジュール共有が非推奨となります。これは WebAssembly の仕様変更に従ったもので、プラットフォームにも影響します。


Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Google マップ、Google Maps Platform プロダクト マネージャー Alicia Sullivan による Google Cloud Blog の記事 " New Cloud-based maps styling features provide more options, control, and flexibility to enhance your user experience" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。



今年の Google I/O にて、Google は Maps JavaScript API 向けクラウドベースのマップスタイル設定の一般提供を発表しました。この度 Google は、クラウドベースのマップスタイル設定の新機能を発表いたします。この新機能は選択肢の幅を広げ、制御性を高め、ユーザーに優れたエクスペリエンスを提供します。その新機能とは、ランドマークとビルディング フットプリント(建物の外形情報)の 2 つです。ウェブ版とアプリ版の一般向け Google マップをご利用の方はこれらの機能をすでにご存知かもしれません。また、業界別に最適化された地図スタイルの新バージョンもリリースします。新しいバージョンではより細やかな設定が設定できるようになると同時に柔軟性が向上し、優れたエクスペリエンスを実現します。それでは詳細を見てみましょう。

ランドマークの表示によりすばやく現在地を把握することが可能に

ウェブ版とアプリ版の一般向け Google マップをご利用の方は、主要なスポットが強調表示されていることにお気づきかもしれません。このランドマークは、ユーザーが自身の現在地を確認し、探索中または訪問中の都市でどのように移動すればよいかを決定するための目印として役立ちます。

サンパウロ(左)とローマ(右)のランドマーク

このたび、クラウドベースのマップスタイル設定を使用して地図を作成することで、一般向け Google マップと同じエクスペリエンスをユーザーに提供できるようになりました。この機能は、ニューヨーク、ドバイ、パリ、ムンバイ、シンガポールなど、世界中の 100 の都市で利用可能です。地図にランドマークを表示するには、Cloud Console にログインし、スタイル エディタで [Points of interest] の機能タイプに移動して、[Marker Style] で [Illustrated] を選択します。


ビルディング フットプリントへの切り替えで地図機能をシンプルに

場合によっては、シンプルな地図のほうが便利なときもあります。高い建物が密集している都市では、高い建物を 3D で表示するとユーザーにはわかりづらくなる場合があります。そのため、建物の 3D 表示の他に、スタイル エディタのオプションとしてビルディング フットプリント機能を追加しました。ビルディング フットプリントにより、基本的な地図のバランスや構成が大きく変更されるため、建物が 3D 表示された複雑な地図を必要としないユースケースにも対応できます。

ビルディング フットプリント

ビルディングフットプリント面の塗りつぶしと線幅も、それぞれ多様なカラーテーマで設定できます。ビルディング フットプリントを有効にするには、スタイル エディタで [Buildings] に移動し、[Building Style] で [Footprints] を選択します。

スタイル エディタのメニューで [Landscape] から [Human-made] を選択し、ビルディング フットプリントを有効にした地図。


業界別に最適化された地図のスタイルでは、ランドマークとビルディング フットプリントに加えて詳細なストリート マップも使用可能

Google は今年の 1 月、旅行、不動産、小売、ロジスティクス業界向けに最適化された地図のスタイルの提供を開始しました。これによりお客様は、クラウドベースのマップスタイル設定を通じて、事前設定されたスタイル付き地図が利用できるようになりました。ランドマークは業界別に最適化されたすべてのスタイル付き地図で使用でき、ビルディング フットプリントは旅行業界向けのスタイル付き地図のみで使用できます。業界別に最適化されたスタイル付き地図をすでに利用している場合、それらの新機能は地図に自動で適用されるため、追加操作は不要です。この変更を無効にしたい場合は、スタイル エディタで機能をオフにします。

また、業界別に最適化された地図のスタイルに限定されますが、詳細なストリート マップが利用可能になります。この機能は、2020 年 8 月に Google I/O で発表したウェブ版とアプリ版の一般向け Google マップの新しい機能ですでにご覧になっているかもしれません。詳細なストリート マップは、現在サンフランシスコ、ニューヨーク、ロンドン、東京で使用できますが、2021 年の終わりまでに新たに 50 都市をサポートをする予定です。


詳細なストリート マップは、業界別に最適化された地図の全スタイルでデフォルトで有効になります。この表示設定は、新たに作成された設定メニューから必要に応じて変更できます。将来的に、すべてのクラウドベースのマップスタイル設定に、詳細なストリート マップ機能を完全導入できるようこの取り組みを続けています。

ランドマークとビルディング フットプリントおよび業界別に最適化された地図のスタイルの新バージョンは、Google Cloud Console 内のクラウドベースのマップスタイル設定からご利用いただけます。利用料金は Google Maps Platform の料金に含まれています。ランドマーク、ビルディング フットプリント、業界別に最適化された地図スタイルの使用方法については、開発者ドキュメントをご参照ください。また、クラウドベースのマップスタイル設定を開始するには、JavaScript のドキュメントをご覧ください。

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



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