この記事は Ian Ballantyne による Google Ads Developer Blog の記事 "Gmail on standard Shopping campaigns" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

この記事は Ian Ballantyne による Google Ads Developer Blog の記事 "Gmail on standard Shopping campaigns" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

2020 年 3 月 4 日の週より、Google ディスプレイ ネットワークを対象とした標準ショッピング キャンペーンのショッピング広告(商品ショッピング広告とショーケース ショッピング広告の両方)が、YouTube と Google Discover に加えて Gmail にも表示されるようになります。つまり、以下の構成で、レポート情報に YouTube と Google Discover に加えて Gmail も含まれるようになります。
広告主が標準ショッピング キャンペーンで Gmail、YouTube、Google Discover をオプトインおよびオプトアウトできるようにするには、以下の設定を有効化または無効化する必要があります。
  • Google Ads API - 標準ショッピング キャンペーンの NetworkSettings を変更し、target_content_networktrue(オプトイン)または false(オプトアウト)に設定します。
  • AdWords API - 標準ショッピング キャンペーンの NetworkSetting を変更し、targetContentNetworktrue または false に設定します。
ご質問やサポートが必要なことがありましたら、フォーラムからご連絡ください。


Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team


4 月 25 日開催の Google Play Indie Games Festival 2020 ファイナルイベントでトップ 20 作品を審査する審査員をご紹介します。なお、ゲームの応募締め切りは 6 日後の 3 月 2 日 23:00  (日本標準時)となっています。応募時点ではオープンベータ版として公開されている必要がありますが、最終評価が行われるファイナルイベントの 4 月 25 日 に向けて改良が見込まれるゲームであれば、応募フォームにその旨をご記載いただき、ぜひご応募ください ...

4 月 25 日開催の Google Play Indie Games Festival 2020 ファイナルイベントでトップ 20 作品を審査する審査員をご紹介します。なお、ゲームの応募締め切りは 6 日後の 3 月 2 日 23:00  (日本標準時)となっています。応募時点ではオープンベータ版として公開されている必要がありますが、最終評価が行われるファイナルイベントの 4 月 25 日 に向けて改良が見込まれるゲームであれば、応募フォームにその旨をご記載いただき、ぜひご応募ください。

Google Play Indie Games Festival 2020 審査員

※(五十音順、敬称略)

社外審査員:


安藤 武博
株式会社シシララ 代表取締役 ゲームDJ

ゲーム DJ・ゲームプロデューサー。1998 年、株式会社エニックス(現スクウェア・エニックス)入社。2015 年、株式会社シシララ設立。PlayStation® などの家庭用ゲームの他、スマートフォンゲーム、テレビ番組など様々なプラットフォームでプロデュースを手掛ける。19 年末、株式会社 Donuts ゲーム事業部長に就任。当フェスティバルでは昨年に続き審査員を務めている。

日高 幸子
ココネ株式会社
執行役員デザイン管掌プロデューサー

アバターアプリ「ポケコロ」の成長を支えるデザイン組織を牽引。商品を開発し、お客様を分析するデザイン内製組織を構築した立役者。現在は、かわいいを創り出すデザイナー兼プロデューサーとして『ポケコロツイン』の立上を行う。

田中 泰生
芸者東京株式会社 CEO

東京大学法学部卒。コンサルティング会社、大手ゲーム会社でのディレクター/プロデューサー(コンシューマ、モバイル、オンライン分野すべて)を経て、芸者東京を設立。AR 電脳フィギュア、ソーシャルゲームおみせやさんの大成功、そしてその後の大失敗をへて、2018 年より新卒のつもりになってハイパーカジュアルゲーム事業をスタート。現在までに、Snowball.io, Traffic run!, Dinosaur Rampage, Watermarbling といった US No.1 のハイパーカジュアルゲームをプロデュース。

特別賞審査員:


上田 太地【東宝賞審査員】
東宝株式会社 映像本部 映像事業部 部長

アニメ製作の TOHO animation レーベル、音楽ドキュメンタリー、DVD・Blu-ray、EC「ゴジラ・ストア」など多岐に渡る映像関連ビジネスを統括。2018 年から取り組み始めたゲーム事業も担当している。


木野 穣【avex 賞審査員】
エイベックス・テクノロジーズ株式会社  Product Management グループ ゼネラルマネージャー。株式会社 fuzz 取締役

出版や広告、ゲーム業界を経て、2019 年 8 月エイベックス・テクノロジーズ株式会社へ入社。ゼネラルマネージャーとしてモバイルゲームおよび新規事業を統括。また、エイベックス株式会社 テクノロジー本部にて XR Live 事業推進にも携わる。2019 年 11 月株式会社 fuzz 取締役に就任。


細野 修平【ジャンプ+デジタル賞審査員】
株式会社集英社 アプリ漫画雑誌『少年ジャンプ+』編集長

アプリ漫画雑誌『少年ジャンプ+』編集長。2000 年、集英社入社。『月刊少年ジャンプ』でマンガ編集者としてのキャリアを積む。以降、『ジャンプスクエア』を経て、2012 年から『週刊少年ジャンプ』に所属。『少年ジャンプ+』『少年ジャンプルーキー』『MANGA Plus』などの立ち上げに携わる。

Google 審査員:

Chongsa Kim (キム チョンサ)
Head of Japan Games Business Development, Google

Google Play ゲーム部門の日本統括部長として事業開発とゲーム開発企業とのパートナーシップ全般を担当。「デベロッパーコミュニティのためのエコシステム作り」が一貫してモチベーションの源泉であり、インディーゲームフェスティバルでは素晴らしいゲームに出会えることを楽しみにしている。


Adam Hoffeld (アダム ホッフェルド)
Strategic Partner Development Manager, Google Play Games

Atari が発売した「Pitfall」でプレイして以来の無類のゲーム好き。これまで、EA、Ubisoft、Tango、Twitch、そして今では Google Play で、ビジネス開発でゲームに携わっている。以前は、投資銀行に 8 年間勤務していた。

※審査員は変更になる場合がございます。最新の審査員情報は、ウェブサイトでご確認ください。

ファイナルイベントへの一般参加者も募集中 :

4 月 25 日、Google Play Indie Games Festival 2020 ファイナルイベントを 渋谷ストリーム  の Google Event Hub で開催します。応募作品から選出されたトップ 20 作品のゲームを展示。その場でゲームに触れ、トップ 10、トップ 3 を決める審査に加わっていただけます。 ぜひお誘い合わせの上、ご参加ください

ファイナルイベント開催概要

日時:4 月 25 日(土)10:00 〜 18:00
場所: 渋谷ストリーム 6 階 Google Event Hub
最新情報は Web サイトでご確認いただけます。

Posted by Hidenori Fujii - Google Play Developer Marketing APAC

この記事は Naina Raisinghani と Raghu Simha による The AMP Blog の記事 "Behind the Scenes: Deploying the AMP Runtime" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

AMP を使う大きなメリットの 1 つは、AMP が常に最新リリースであることです。現在、ウェブ デベロッパーやエンジニアのチームは、依存性管理に悩まされることなく、AMP が毎週提供している最高の機能を利用できます ...
この記事は Naina Raisinghani と Raghu Simha による The AMP Blog の記事 "Behind the Scenes: Deploying the AMP Runtime" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

AMP を使う大きなメリットの 1 つは、AMP が常に最新リリースであることです。現在、ウェブ デベロッパーやエンジニアのチームは、依存性管理に悩まされることなく、AMP が毎週提供している最高の機能を利用できます。
インフラストラクチャ ワーキング グループは、ここ数か月にわたって、AMP のランタイムやコンポーネントのリリース方法を改善する作業を懸命に続けてきました。この改善は、以下のフィードバックに基づいています。
  • ウェブサイトの品質保証(QA)を毎週行わなくてもいいように、リリース周期をもっと長くすることを希望する開発チームもある。
  • AMP リリースの既存ドキュメントが不完全だったりわかりにくかったりする場合がある。
  • 互換性を伴わない変更が行われた可能性がある場合、大半のエンドユーザーに反映される前にそれを検知できることが不可欠である。
  • 開発時に、AMP のランタイムやコンポーネントを cdn.ampproject.org からフェッチするのではなく、セルフホストしたいと考えているパートナーもいる。
このブログ投稿の目的は、現在の AMP リリースの仕組みと近日中に行われる改善(最新のリリース チャンネル名である LTS チャンネルと Nightly チャンネル、オリジン URL で AMP をセルフホストする機能など)を読者に理解してもらうことです。

AMP リリースを理解する

新しいバージョンの AMP ランタイムは毎週リリースされます。サイト運営者のウェブサイトの外見と動作が変わらないことを保証するため、リリースは複数のチャンネルで提供されます。主なリリース チャンネルは、Stable(安定版)、Beta(ベータ版)、Experimental(試験運用版)と呼ばれています。それぞれは異なる目的で提供され、参照している人数も異なります。加えて、テストとメンテナンスにさらに役立ててもらえるように、LTS(長期安定版)と Nightly(ナイトリー版)という 2 つのチャンネルを追加する予定です。以下では、それぞれのチャンネルについて簡単に説明します。

Stable チャンネル

本番環境用の AMP ランタイムのメイン リリース チャンネルで、大半の AMP ドキュメントに使用されています。AMP のコードベースに送信された変更は、他のチャンネルで複数レイヤーのテストや検証が行われた後、Stable チャンネルの一部になります。

Beta チャンネル

Beta チャンネルは、近日中に Stable チャンネルでリリースされるものを正確に反映しています。デベロッパーや QA チームが Beta チャンネルをオプトインすると、ウェブサイトで AMP ランタイムの最新の変更点を検証できます。これを行うには、ブラウザで AMP Experiments ページを開き、[AMP Beta Channel] を有効化します。
注: Beta チャンネルのオプトインは、 皆さんの ブラウザで使われているバージョンの AMP JS ライブラリにのみ影響します。ウェブサイトにアクセスしたユーザーに強制的に Beta チャンネル版の AMP を受信させることはできません。
Beta チャンネルは Stable チャンネルよりも信頼性が低く、すべてのユーザーがまだ利用できない機能が含まれている可能性もあります。このチャンネルで想定される用途は次のとおりです。
  • 次週にリリースされる予定の AMP の新機能を試す。
  • QA を実施し、ウェブサイトに次のバージョンの AMP と互換性があることを検証する。

Experimental チャンネル

AMP の新機能の中には、開発やテストに数週間かかるものもあります。そのため、Beta チャンネルや Stable チャンネルでは、そういった機能はオフになった試験運用版フラグの裏に隠されています。Experimental チャンネルを使うと、デベロッパーや QA チームは新機能の実験やテストを行えます。これを行うには、ブラウザで AMP Experiments ページを開き、[AMP Experimental Channel] を有効化します。
注: Experimental チャンネルのオプトインは、 皆さんの ブラウザで使われているバージョンの AMP JS ライブラリにのみ影響します。ウェブサイトにアクセスしたユーザーに強制的に Experimental チャンネル版の AMP を受信させることはできません。
Experimental チャンネルと Beta チャンネルの違いとして、開発中の一部の機能は Experimental で利用でき、Beta では無効にされている場合があります。機能の使用準備が整ったとみなされると、フラグがオンになり、まずは Beta チャンネルで、やがては Stable チャンネルで参照できるようになります。所要期間は、機能によって数日、数週間、数か月とさまざまです。

Long Term Stable(LTS)チャンネル

デベロッパー チームからは、QA サイクルを現在の週次サイクルよりも長くできるように、AMP リリース チャンネルのバージョン間の間隔をさらに長くしてほしいというリクエストが繰り返し寄せられています。
この問題を解決するのが、今回新たに設けられる Long Term Stable(LTS)リリース チャンネルです。ほぼ月に 1 回のペースで、最新の Stable チャンネル リリースが LTS チャンネルに昇格します。
なお、LTS チャンネルはすべての AMP サイト運営者に推奨されるものではないと認識しておくことが重要です。このチャンネルは、新機能を使うために数週間待っても構わないので、ウェブサイトのテスト頻度を減らしたいという方のために提供されるものです。サイト運営者は、ウェブサイトの特定のページで LTS チャンネルを使うようにオプトインすることもできます。LTS チャンネルを使うウェブページは、Stable チャンネルと同じキャッシュのメリットを活用できます。
個人ごとにブラウザの Cookie を設定してオプトインできる Beta チャンネルや Experimental チャンネルとは異なり、サイト運営者がそのページで LTS チャンネルを使うようオプトインすると、ウェブページのすべてのユーザーに対して LTS チャンネルが提供されます。
毎月第 2 月曜日に、その前の週の Stable チャンネル リリースが昇格し、新しい LTS バージョンを利用できるようになります。LTS チャンネルのスケジュールについては、こちらをご覧ください。
ウェブページで LTS チャンネルを使用する:
次に、Stable チャンネルを使用するウェブページの例を示します。
<script async src="https://cdn.ampproject.org/v0.js"></script>
<script
  async
  custom-element="amp-ad"
  src="https://cdn.ampproject.org/v0/amp-ad-0.1.js"
></script>
代わりに LTS チャンネルを使用するには、ランタイムと拡張機能のスクリプトの「src」属性に記述する URL に「lts/」を追加します。次の例をご覧ください。
<script async src="https://cdn.ampproject.org/lts/v0.js"></script>
<script
  async
  custom-element="amp-ad"
  src="https://cdn.ampproject.org/lts/v0/amp-ad-0.1.js"
></script>
注: AMP ドキュメントが有効であるためには、AMP ランタイムと拡張機能のスクリプトは同じチャンネルでなければなりません。たとえば、LTS チャンネルの v0.js と Stable チャンネルの amp-carousel-0.1.js を同時に使った場合、検証エラーが発生します。

Nightly チャンネル

今後の AMP リリースの品質について信頼を高めるため、近日中に、AMP ランタイムのナイトリー ビルドを自動生成して、新しい Nightly チャンネルで公開する予定です。このチャンネルは、エラー比率の減少、ランタイムのパフォーマンス改善、全体的なコードの品質保証に役立てることができます。Nightly チャンネルのコードは、将来的に Beta / Experimental、Stable、そして LTS チャンネルに昇格します。このチャンネルが導入されると、デベロッパーは Experimental や Beta をオプトインするのと同じ方法(前述)で Nightly チャンネルをオプトインできるようになります。
注: Nightly チャンネルは Beta、Experimental、Stable チャンネルよりも安定していないので、毎日変更をテストしたい場合を除き、このチャンネルをオプトインすることは推奨しません。

リリース スケジュール

前のセクションでは、既存および追加予定のすべてのリリース チャンネルについて説明しました。ここでは、あるコードがプル リクエストでオープンソース リポジトリに送信されてから、さまざまなリリース チャンネルに適用されるまでの道のりについて説明します。






あるコードがある月(N 月)の 8 日にオープンソース リポジトリにマージされたとします。このマージは平日に発生したので、このコードは次のナイトリー ビルド(9 日)に含まれます。数日間のテストを経た後、Beta チャンネルまたは Experimental チャンネルをオプトインしているユーザーは、翌週の火曜日(16 日)にこのコードを見ることができます。何の問題も見つからなかった場合、コードは次の火曜日(23 日)に Stable チャンネルに反映されます。最後に、翌月の第 2 月曜日(N+1 月の 13 日)に新しい LTS チャンネル リリースに反映されます。
AMP のリリース チャンネルとスケジュールの詳細については、プロジェクトのリリース スケジュールのページをご覧ください。amphtml GitHub リポジトリにマージされた新しいコードがサイト運営者、デベロッパー、エンドユーザーに到達するタイミングを視覚的に表現したページもご覧いただけます。

AMP ランタイムをセルフホストする新しい方法

現在、ウェブサイトの所有者が AMP の有効性を維持したまま AMP ランタイムをセルフホストできるように、作業を進めています。これには、以下のようなメリットがあります。
  • 独立性: オリジン URL で提供する AMP ページで、AMP のランタイムとコンポーネントを https://cdn.ampproject.org から読み込む必要がなくなります。
  • コントロール: ウェブサイトで、新しい AMP バージョンのロールアウトのタイミングと QA のタイミングを合わせることができます。必要な場合は、異なるバージョンの AMP ランタイムにロールバックすることもできます。
  • パフォーマンス: 追加の HTTPS 接続が不要になるため、ページの読み込み時間や TTI が短縮されます。
目標は、サイト運営者が AMP の有効性を維持したままセルフホスト版の AMP ランタイムにリンクできるようにすることです。つまり、次の AMP も有効と見なされるようになります。
<!DOCTYPE html><html amp transformed="self;v=1">
<head>
  <script async src="https://example.com/amp/v0.js"></script>
  <script
   async custom-element="amp-bind"
   src="https://example.com/amp/v0/amp-bind-0.1.js"
  ></script>  
   ...
注: ユーザーのプライバシー保護のため、AMP Cache はランタイムのセルフホストをサポートせず、代わりに、キャッシュにホストされたスクリプトへのリンクを書き換えます。
AMP ランタイムのセルフホストは、今年中にリリースする予定です。実装の詳細については、実装の意図設計ドキュメントをご覧ください。
* * *
これらの変更によって、AMP リリースがわかりやすく、採用しやすく、テストしやすく、デプロイしやすくなることを期待しています。AMP 開発コミュニティや、皆さんの作業およびフィードバックに感謝いたします。いつものように、問題や機能リクエストがありましたら遠慮なくお知らせください
投稿者: AMP Project、Naina Raisinghani、Raghu Simha

Reviewed by Chiko Shimizu - Developer Relations Team

この記事は Adam Ohren による Google Ads Developer Blog の記事 "Complete sunset of accelerated budget delivery" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

この記事は Adam Ohren による Google Ads Developer Blog の記事 "Complete sunset of accelerated budget delivery" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

昨年の 10 月に、検索キャンペーン、ショッピング キャンペーン、共有予算での広告配信の集中化の提供終了についてお知らせしました。それ以降、上記のキャンペーンで広告配信の集中化は利用できなくなっています。

今年は、その他すべてのキャンペーンのタイプでも広告配信の集中化の提供が終了する予定です。共有予算と非共有予算の両方が対象となります。ディスプレイ、アプリ、動画などのキャンペーンが含まれ、すべてのバージョンの AdWords API、Google Ads API、Google 広告スクリプトの予算に影響します。

2020 年 4 月末より、スクリプトおよび両方の API で、配信方法ACCELERATED である新規および既存の予算をキャンペーンに使用できなくなります。
  • 配信方法項目を ACCELERATED に設定して新規予算を作成することができなくなります。
  • 既存の予算の配信方法を STANDARD から ACCELERATED に変更することができなくなります。
  • 以前から存在する予算で、配信方法が ACCELERATED になっているものをキャンペーンで使うように設定できなくなります。
API やスクリプトから前述のオペレーションを行った場合、次の表に示すとおり、すべてエラーとなります。
AdWords API
サービス 項目値 エラー
BudgetService deliveryMethod: ACCELERATED OperationAccessDenied.ACTION_NOT_PERMITTED
CampaignService budget*
[*] 配信の集中化に設定された場合のみ
OperationAccessDenied.ACTION_NOT_PERMITTED

Google Ads API
サービス 項目値 エラー
CampaignBudgetService delivery_method: ACCELERATED OperationAccessDenied.ACTION_NOT_PERMITTED
CampaignService campaign_budget*
[*] 配信の集中化に設定された場合のみ
OperationAccessDenied.ACTION_NOT_PERMITTED

Google 広告スクリプト
メソッド エラー
AdsApp.​Budget.setDeliveryMethod(“ACCELERATED”) “Action not permitted”

既存の ACCELERATED 予算を変更する操作は(例: API で amount 項目または status 項目を更新する、またはスクリプトで対応する AdsApp.Budget メソッドを使用する)、2020 年 5 月まで可能です。その後は、これらの予算に対するいかなる修正も同様のエラーとなります。

Google Ads API と Google 広告スクリプトの将来のバージョンでは、広告配信の集中化オプションのサポートが完全に削除される可能性があります。

この変更に関して質問がある方は、遠慮なく AdWords API / Google Ads API フォーラムGoogle 広告スクリプト フォーラムからお知らせください。

Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team

この記事は Chrome セキュリティ チーム、Joe DeBlasio による Chromium Blog の記事 "Protecting users from insecure downloads in Google Chrome" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


本日は、今後、Chrome が徐々に安全な(HTTPS)ページから安全なファイルのみをダウンロードするようになることをお知らせします。以下で説明する一連の手順を経て、「Mixed Contents のダウンロード」(安全なページで開始される HTTPS でないダウンロード)のブロックを開始します。この変更は 昨年お知らせした計画に従っており、安全なページで、すべての安全でないサブリソースのブロックが開始されます。

安全でない方式でダウンロードされるファイルは、ユーザーにとってセキュリティやプライバシーのリスクになります。たとえば、安全でない方式でプログラムをダウンロードすると、攻撃者がそれを不正なソフトウェアと入れ替えることができます。また、安全でない方式で銀行の明細書をダウンロードすると、盗聴者はそれを読むことができます。このようなリスクに対処するため、将来的に Chrome で安全でないダウンロードのサポートを削除したいと考えています。

その第一段階として、安全なページにおける安全でないダウンロードに対処します。このような場合は特に懸念があります。現在 Chrome では、プライバシーやセキュリティの危険があることをユーザーに通知していないからです ...
この記事は Chrome セキュリティ チーム、Joe DeBlasio による Chromium Blog の記事 "Protecting users from insecure downloads in Google Chrome" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


本日は、今後、Chrome が徐々に安全な(HTTPS)ページから安全なファイルのみをダウンロードするようになることをお知らせします。以下で説明する一連の手順を経て、「Mixed Contents のダウンロード」(安全なページで開始される HTTPS でないダウンロード)のブロックを開始します。この変更は昨年お知らせした計画に従っており、安全なページで、すべての安全でないサブリソースのブロックが開始されます。

安全でない方式でダウンロードされるファイルは、ユーザーにとってセキュリティやプライバシーのリスクになります。たとえば、安全でない方式でプログラムをダウンロードすると、攻撃者がそれを不正なソフトウェアと入れ替えることができます。また、安全でない方式で銀行の明細書をダウンロードすると、盗聴者はそれを読むことができます。このようなリスクに対処するため、将来的に Chrome で安全でないダウンロードのサポートを削除したいと考えています。

その第一段階として、安全なページにおける安全でないダウンロードに対処します。このような場合は特に懸念があります。現在 Chrome では、プライバシーやセキュリティの危険があることをユーザーに通知していないからです。

Mixed Contents のダウンロードは、Chrome 82(2020 年 4 月リリース)以降で徐々に警告が表示されるようになり、やがてブロックされます。最初は特にユーザーへのリスクが高いファイル形式(例: 実行可能ファイル)に適用され、続くリリースでその他のファイル形式にも適用されます。徐々にロールアウトする設計となっているのは、早い段階で特に大きなリスクを緩和しつつ、デベロッパーにサイトを更新する機会を提供して Chrome ユーザーに表示される警告の数を最低限にとどめるためです。

Mixed Contents のダウンロードに関する制限は、まず PC プラットフォーム(Windows、macOS、Chrome OS、Linux)を対象にロールアウトする予定です。PC プラットフォームでの予定は次のようになっています。


警告が有効になるタイミングをまとめた図

  • Chrome 81(2020 年 3 月リリース)以降:
    • すべての Mixed Contents のダウンロードについて、コンソールに警告メッセージが表示されます。
  • Chrome 82(2020 年 4 月リリース):
    • Mixed Contents の実行可能ファイル(例: exe)のダウンロードに対して警告が表示されます。
  • Chrome 83(2020 年 6 月リリース):
    • Mixed Contents の実行可能ファイルブロックされます。
    • Mixed Contents のアーカイブ(.zip)やディスク イメージ(.iso)に対して警告が表示されます。
  • Chrome 84(2020 年 8 月リリース):
    • Mixed Contents の実行可能ファイル、アーカイブ、ディスク イメージブロックされます。
    • イメージ、オーディオ、動画、テキスト形式を除くその他すべてのMixed Contents のダウンロードに対して警告が表示されます。
  • Chrome 85(2020 年 9 月リリース):
    • イメージ、オーディオ、動画、テキストの Mixed Contents のダウンロードに対して警告が表示されます。
    • その他すべての Mixed Contents のダウンロードがブロックされます。
  • Chrome 86(2020 年 10 月リリース)以降では、すべての Mixed Contents のダウンロードがブロックされます。



表示される可能性のある警告の例



Android と iOS のユーザーに対してはリリースのロールアウトを 1 つ遅らせて、Chrome 83 で警告が開始されます。モバイル プラットフォームは、悪意のあるファイルに対するネイティブの保護が手厚くなっています。警告が表示されるタイミングを遅らせることで、デベロッパーはモバイル ユーザーに影響が発生する前に余裕をもってサイトを更新することができます。 

デベロッパーは、確実に HTTPS のみを使用してダウンロードすることで、ダウンロードの警告がユーザーに表示されるのを防ぐことができます。また、テスト用にすべての Mixed Contents のダウンロードに対する警告を有効化することもできます。これを行うには、現在のバージョンの Chrome Canary を使うか Chrome 81 がリリースされた後で、chrome://flags/#treat-unsafe-downloads-as-active-content から [Treat risky downloads over insecure connections as active mixed content] フラグをオンにします。 

エンタープライズおよび教育機関のユーザーは、既存の InsecureContentAllowedForUrls ポリシーにダウンロードをリクエストするページのパターン マッチングを追加することで、サイトごとにブロックを無効化できます。 

今後、Chrome での安全でないダウンロードの制限はさらに強化される予定です。デベロッパーの皆さんには、今後の制限を回避して完全にユーザーを保護できるように、完全に HTTPS に移行することをおすすめします。ご質問があれば、security-dev@chromium.org までメールをお送りください。





本日は、Google Play Indie Games Festival 2020 へ応募された数多くの作品から、トップ 20 ・トップ 10 ・ トップ 3 作品へ贈られる賞の詳細を紹介します。なお、コンテストへの応募は 3 月 2 日 23:00 (日本標準時)まで 引き続き受け付けています。この機会に、ぜひチャレンジしてください。締め切りまでにオープンベータ版として公開されているゲームであれば応募可能です。また、本年から従業員数 50 名以下の企業も応募いただけるようになりました。応募の際は、ウェブサイトの 参加資格をご確認いただけるようお願いします ...


本日は、Google Play Indie Games Festival 2020 へ応募された数多くの作品から、トップ 20 ・トップ 10 ・ トップ 3 作品へ贈られる賞の詳細を紹介します。なお、コンテストへの応募は 3 月 2 日 23:00 (日本標準時)まで 引き続き受け付けています。この機会に、ぜひチャレンジしてください。締め切りまでにオープンベータ版として公開されているゲームであれば応募可能です。また、本年から従業員数 50 名以下の企業も応募いただけるようになりました。応募の際は、ウェブサイトの参加資格をご確認いただけるようお願いします。

トップ 20 受賞者へ贈られる賞品:

  • 4 月 25 日に実施されるファイナルイベントでのゲーム展示
  • ファイナルイベント参加のための代表者 2 名の交通費とホテル宿泊費 2 泊分(2 部屋、関東圏外在住の場合のみ)
  • Google Play ストア特設コーナーへの掲載
  • プレゼンテーショントレーニング(30 分)

トップ 10 受賞者へ贈られる賞品 (トップ 20 への賞品に加えて):

  • Google Play チーム メンバーとの個別のコンサルティング 1 回(大会に応募したゲームに関するもの)
  • Google Pixel 4 を 1 台 

トップ 3  受賞者へ贈られる賞品 (トップ 10、 トップ 20 への賞品に加えて) :

  • Google Play ストアのプレミアム枠にゲームを掲載
  • Google Play ストアの他のコレクションへの掲載を検討

特別賞(トップ 20 作品の中から選定):

Indie Games Accelerator 賞( 2 作品を Google 審査員が選定):

  • 世界中から選ばれたインディーゲーム 開発者が集い、ゲームビジネス成功のノウハウを学ぶ Indie Games Accelerator 2020 への優先参加権。昨年のシンガポールでの実施実績はこちらでご参照いただけます。

avex 賞( 1 作品を avex 特別審査員が選定):

  • コワーキングスペース「avex EYE」 入居権+、エイベックス所属クリエイターによる受賞ゲーム作品オリジナルのプロモーション・ムービーや音楽制作

ジャンプ+デジタル賞( 1 作品を集英社特別審査員が選定):

受賞者は、賞品 A、B の 2 つから 1 つお選びいただけます。

  • A パターン:新たなゲームの開発費援助(最大 1,000 万円まで)。ジャンプの IP を使用することも可能です。
  • B パターン:プロモーションやプロジェクトへの追加出資、売り上げを伸ばすための支援。

東宝賞( 1 作品を東宝特別審査員が選定):

  • 最大 1,000 万円の開発費支援と東宝 IP を使用したゲーム化ライセンス(オリジナルゲームでも可)

なお、賞品は予告なく変更される可能性がありますのでご了承ください。詳しくは必ず大会参加規約をご確認ください。

ファイナルイベントへの一般参加者も募集中 : 

4 月 25 日、Google Play Indie Games Festival 2020 ファイナルイベントを渋谷ストリームの Google Event Hub で開催します。応募作品から選出されたトップ 20 作品のゲームを展示。その場でゲームに触れ、トップ 10、トップ 3 を決める審査に加わっていただけます。ぜひお誘い合わせの上、ご参加ください

ファイナルイベント開催概要

日時:4 月 25 日(土)10:00 〜 18:00
場所: 渋谷ストリーム 6 階 Google Event Hub
最新情報は Web サイトでご確認いただけます。

Posted by Hidenori Fujii - Google Play Developer Marketing APAC

この記事はプロダクト マネージャー、Jason James による Chromium Blog の記事 "Videos with fewer intrusive ads" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


Chrome は、ウェブを閲覧するユーザーにできる限り最高の体験を提供することに常に注力しています。私たちには、ポップアップ ウィンドウをブロックする、ページに不正なソフトウェアが含まれている場合に警告するなど、長きにわたり悩ましく有害な体験からユーザーを守ってきたという歴史があります。ここ数年間は、Chrome ユーザーが共通して抱えている不満、すなわち悩ましく煩わしい広告に対処するための作業を続けています。2018 年には、業界基準に従わず、煩わしい広告を継続的に表示しているウェブサイトから広告を削除する作業に着手しました。また、Google は、インターネット ユーザーが特に悩ましいと感じるような広告は販売および提供しないよう、自社の広告サービスを更新しました。それ以降、北米とヨーロッパでの Chrome の広告ブロック率は大きく低下しました。

ウェブ エクスペリエンスにとって最も煩わしい広告を把握するにあたって、 Better Ads Standards ...
この記事はプロダクト マネージャー、Jason James による Chromium Blog の記事 "Videos with fewer intrusive ads" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


Chrome は、ウェブを閲覧するユーザーにできる限り最高の体験を提供することに常に注力しています。私たちには、ポップアップ ウィンドウをブロックする、ページに不正なソフトウェアが含まれている場合に警告するなど、長きにわたり悩ましく有害な体験からユーザーを守ってきたという歴史があります。ここ数年間は、Chrome ユーザーが共通して抱えている不満、すなわち悩ましく煩わしい広告に対処するための作業を続けています。2018 年には、業界基準に従わず、煩わしい広告を継続的に表示しているウェブサイトから広告を削除する作業に着手しました。また、Google は、インターネット ユーザーが特に悩ましいと感じるような広告は販売および提供しないよう、自社の広告サービスを更新しました。それ以降、北米とヨーロッパでの Chrome の広告ブロック率は大きく低下しました。

ウェブ エクスペリエンスにとって最も煩わしい広告を把握するにあたって、Better Ads Standards を使っています。これは、世界中のユーザーのフィードバックに基づき、Google などの企業にガイダンスを提供している標準です。

本日、Better Ads Standards の作成を担当するグループである Coalition for Better Ads は、世界中の 45,000 人を対象にしたユーザー調査に基づき、動画コンテンツを表示する際の一連の新しい広告標準を発表しました。

動画の再生前、再生中、再生後に表示される広告にはさまざまな種類がありますが、Coalition の調査によると、ユーザーは 8 分以内の動画コンテンツで次の 3 つの広告を特に煩わしいと感じています。
イメージの出典: Coalition for Better Ads
スキップできない 31 秒を超える長いプリロール広告または広告グループ。動画の直前に表示され、最初の 5 秒間はスキップできないもの。
イメージの出典: Coalition for Better Ads

長さを問わないミッドロール広告。動画の再生中に表示され、ユーザー体験を中断させるもの。
イメージの出典: Coalition for Better Ads

再生中の動画の上に表示されるイメージまたはテキスト広告で、動画プレイヤー ウィンドウの中央 3 分の 1、または動画コンテンツの 20% を超える部分を覆うもの。

動画コンテンツへの影響の有無

Coalition は、ウェブサイトの所有者は今後 4 か月以内に、サイトにアクセスするユーザーにこういった広告を表示するのをやめるべきだと述べています。それを受けて、Chrome も 2020 年 8 月 5 日からユーザー保護を拡大し、どの国においても、煩わしい広告を繰り返し表示しているサイトですべての広告を表示しなくなります。重要な点として、動画コンテンツを表示する他のサイトと同様、YouTube.com でもこの標準に準拠しているかどうかが確認されます。これまでの Better Ads Standards と同じく、この標準を受けて YouTube を含む広告プラットフォーム全体のプロダクト計画をアップデートするとともに、調査結果をツールとして活用して今後のプロダクト開発に役立てたいと考えています。

広告を表示するウェブサイトを運営している方は、広告に関する問題レポートでサイトのステータスを確認することを検討してください。このツールを使うと、Chrome が違反とみなす広告エクスペリエンスがあるかどうかを、サイト運営者が確認できます。今週より(元記事公開当時)、広告に関する問題レポートをアップデートし、サイト運営者が現在のサイトで新しい動画基準に関する問題を解決する際に役立つ情報を追加していきます。このプロセスに関する詳しい情報については、ヘルプセンターおよびコミュニティ フォーラムをご覧ください

Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Rails-to-Trails Conservancy の Chief Technology Officer である Frederick Schaedtler による Google Maps Platform Blog の記事 "A non-profit’s journey to guiding Americans across trails with Google Maps Platform" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
この記事は Rails-to-Trails Conservancy の Chief Technology Officer である Frederick Schaedtler による Google Maps Platform Blog の記事 "A non-profit’s journey to guiding Americans across trails with Google Maps Platform" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。



Rails-to-Trails Conservancy は、鉄道の廃線や軌道を再利用して、全米にトレイルのネットワークを築き、人々がさらに健康になれる場所を提供することに貢献しています。同団体は、全米のパートナーと協力し、多目的のウォーキング トレイルやサイクリング トレイルを作るとともに、アメリカ全土で 36,000 マイル以上にもなる多目的トレイルを検索し活用することを奨励する活動をしています。この組織が 1986 年に設立された当時は、かつての鉄道の軌道をトレイルとして保存することを主目的に活動をしていました。それ以来、全米で 24,000 マイルを超える鉄道の廃線をトレイルに作り変えていくコミュニティを支援してきました。

当初、トレイルを促進する取り組みでは、紙のガイドブックを使用していました。その後、独自のトレイル データベースを構築し、古い紙の地図をデジタル化することに初めて成功すると、私たちが保有している空間情報をオンラインで公開するには協力者が必要であることにすぐに気付きました。



2006 年に Google マップを活用し、ウェブサイト TrailLink.com ですべてのインタラクティブ マップが公開できるようになりました。TrailLink は、トレイルを探すための Rails-to-Trails Conservancy のウェブサイトと TrailLink モバイルアプリです。初期の段階で Google Maps Platform を選択した理由は、正確な位置データと柔軟なプラットフォームにあります。特にインタラクティブなトレイルマップをユーザー向けにウェブサイトに公開することを可能にする Maps JavaScript API の存在です。

そして長年にわたって、36,000 マイル以上の多目的トレイルをマッピングし、自転車用のルートを作るために数千マイルのトレイル データを提供することで Google マップに貢献してきました。私たちは、この貢献が多くの人々にもたらす永続的な価値を本当に誇りに思っています。

将来の展望として、Google Maps Platform の継続的なサポートにより、モバイル ファーストのアプローチも取り入れながら、さらに多くのユーザーにリーチし、数 100 万人のアメリカ人にトレイル データの宣伝と公開をするつもりです。Rails-to-Trails Conservancy の取り組みについては動画もご覧ください。



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

Posted by 丸山 智康 (Tomoyasu Maruyama) - Google Maps テクニカル アカウントマネージャ

この記事は Google Maps Platform の Product Manager である Yaron Fidler による Google Maps Platform Blog の記事 "How to Use the Distance Matrix API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
この記事は Google Maps Platform の Product Manager である Yaron Fidler による Google Maps Platform Blog の記事 "How to Use the Distance Matrix API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。




Google Maps Platform を使用して複数の場所をプロットすると、最寄りのマーカーを視覚的に確認することができます。しかしながら、交通量を考慮すると、実際の距離が必ずしも明確ではなくなります。一般的に、2 点間の距離は、Maps Javascript API を使用した距離を計算することで明らかにできます(参考:Maps JavaScript API を使って地図上の 2 地点間の距離を計算する)。しかし、一度に多点間の距離を決定したい場合は、Distance Matrix API を使用することで、必要なすべてのデータの取得が 1 回の呼び出しで済みます。配達所要時間でレストランのリストを絞り込んだり、利用者との距離の近さに応じて最適なドライバーを割り当てたり、顧客に最も近い場所にいる技術者を見極めて現場に派遣させるなどのユースケースには有効な方法です。

この記事では、「技術者の派遣」というユースケースを例に Distance Matrix API の使い方を紹介します。まず、API から返されるすべてのデータを理解することが重要です。そこで、米国中西部の主要都市間の走行距離を求めるという基本的な例からはじめましょう。

各都市にマーカーをつける

距離を計算する前に、地図上で該当する場所を明らかにすると便利です。そこで、シカゴ、ミルウォーキー、デトロイト、インディアナポリス、セントルイスの 5 つの都市にマーカーを作成していきます。

これらの都市にマークがついた地図を作成するための HTML と JavaScript の定義がこちらです。

<!DOCTYPE html>
<html>
  <head>
    <style>
       /* Set the size of the div element that contains the map */
      #map {
        height: 400px;  /* The height is 400 pixels */
        width: 600px;  /* The width is 600 pixels */
       }
    </style>
  </head>
  <body>
    <!--The div element for the map -->
    <div id="map"></div>
    <script>
      // Initialize and add the map
      let map;
      function initMap() {
        map = new google.maps.Map(document.getElementById('map'), {
          zoom: 6,
          center: {lat: 41, lng: -86}
        });

        const cities = [
          {lat: 41.88, lng: -87.62}, // Chicago
          {lat: 43.05, lng: -87.95}, // Milwaukee
          {lat: 42.33, lng: -83.04}, // Detroit
          {lat: 39.76, lng: -86.15}, // Indianapolis
          {lat: 38.62, lng: -90.19} // St. Louis
        ];

        // Loop through cities, adding markers
        for (let i=0; i<cities.length; i++) {
          let position = cities[i]; // location of one city
          // create marker for a city
          let mk = new google.maps.Marker({position: position, map: map});
        }

        // Add Distance Matrix here
      }
    </script>
    <script async defer
      src="https://maps.googleapis.com/maps/api/js?key=YOUR_API_KEY
              &callback=initMap">
    </script>
  </body>
</html>


Google Cloud Console で API キーを調べて、上記のコードにある YOUR_API_KEY の部分を書き換えます。上記のコードは、米国中西部を中心とするマップを作成し、都市ごとにマーカーをマップ上にプロットする例です。



コードを保存してブラウザで読み込むと、上記のようなマップが表示されます。マップを一見するだけで、シカゴに最も近い都市はどこかわかると思いますが、ここでは Distance Matrix API がどのように解を求めるかを見てみましょう。

走行距離表で距離行列を視覚化する

Distance Matrix API の概念は、スマートフォンやユビキタス GPS が登場するよりも前の時代に遡ります。当時、旅行者は走行距離と所要時間を決めるためにある印刷物を参照していました。左側と上部に都市名が並ぶ 2 次元の走行距離表です。紙の道路地図に添えられていたり、ガソリンスタンドの壁に貼られていたこのような表には、都市間の距離が記されていました。



たとえば、シカゴの近くにいたとしましょう。最初の行からミルウォーキー(92 マイル)やデトロイト(281 マイル)までの距離を容易に確認できます。空のセルが斜めに並んでいることから、これが走行距離表だということがすぐに理解できるでしょう。なぜなら、シカゴからシカゴへ運転することはありませんから。

Distance Matrix API は、車のグローブ ボックスにあったこうした印刷物を現代化したものと言えます。各行には出発地が、各列は目的地が表されており、従来の距離行列を再作成したり、1 つの出発地点に複数の到着地点を組み合わせることもできます。何よりも、印刷する必要がありません。リクエストを作成し、JSON で回答を得るまで、数秒でできてしまいます。

複数の出発地点からの運転時間を計算する

紙の道路地図なら都市間の距離だけで問題ないかもしれませんが、実際の利用においてはもっと細かいニーズがあり、こうしたニーズを Distance Matrix API がサポートします。たとえば、たくさんの出発地や目的地がある派遣業務や配送業務に、この API は役立ちます。最寄りの修理技術者を Distance Matrix API を使用して選択する方法を見てみましょう。

ここで、Distance Matrix API には、複数の出発地(潜在的な技術者たちがいる場所)と 1 つの目的地(顧客がいる場所)とを与えます。ここでは、GPS などで、各技術者の現在位置を把握していると仮定します。

JavaScript コードの // Add Distance Matrix here コメントの後に、次のコードを追加します。

  const service = new google.maps.DistanceMatrixService(); 
                                     // instantiate Distance Matrix service
      const matrixOptions = {
        origins: ["41.8848274,-87.6320859", "41.878729,-87.6301087", 
                     "41.8855277,-87.6440611"], // technician locations
        destinations: ["233 S Wacker Dr, Chicago, IL 60606"], // customer address
        travelMode: 'DRIVING',
        unitSystem: google.maps.UnitSystem.IMPERIAL
      };
      // Call Distance Matrix service
      service.getDistanceMatrix(matrixOptions, callback);

      // Callback function used to process Distance Matrix response
      function callback(response, status) {
        if (status !== "OK") {
          alert("Error with distance matrix");
          return;
        }
        console.log(response);        
      }


複数の出発地と 1 つの目的地があるため、計算結果は複数の行になります。1 行が 1 か所の出発地に該当します。結果がコールバック関数に返されると、コードはブラウザ コンソールへの応答を記録します。これはブラウザの開発者ツールで調べるか、JSON ペイロードを確認することができます。

  {
  "originAddresses": [ "120 W Randolph St, Chicago, IL 60602, USA", 
                       "204 S Clark St, Chicago, IL 60604, USA", 
                       "629 N Desplaines St, Chicago, IL 60661, USA" ],
  "destinationAddresses": [ "233 S Wacker Dr, Chicago, IL 60606, USA"],
"rows": [ {
  "elements": [ {
    "status": "OK",
    "duration": {
      "Value": 458,
      "text": "8 mins"
    },
    "distance": {
      "value": 1911,
      "text": "1.2 mi"
    }
  }], {
  "elements": [ {
    "status": "OK",
    "duration": {
      "value": 220,
      "text": "4 mins"
    },
    "distance": {
      "value": 924,
      "text": "0.6 mi"
    }
  }], {
  "elements": [ {
    "status": "OK",
    "duration": {
      "value": 383,
      "text": "6 mins"
    },
    "distance": {
      "value": 1531,
      "text": "1.0 mi"
    }
  }]
}]
}


出発地と目的地の住所が、最初に返されます。これは、以下に表示されている距離がどの出発地からのものであるかを理解するのに役立ちます。緯度経度座標で与えた出発地の情報は、自動的に最も近い住所に逆ジオコーディングされています。

次に、rows 配列には 3 つのアイテムがあり、それぞれの出発地(技術者)につき 1 つが該当します。各行には、各目的地の結果を含む要素配列があり、ステータス(”status”)、所要時間(”duration”)、距離(”distance”)が含まれます。

では、Distance Matrix データを理解したところで、これを使用してみましょう。たとえば、表にデータを入力したり、マップ上で距離を共有したり、最短の運転時間を検索したりできます。

運転時間で最も近い場所を見つける

顧客のいる場所から最寄りの技術者を派遣してみましょう。そのためには、距離行列 JSON を解析して最短の運転時間のものを見つけます。

Distance Matrix コールバックの console.log の後に次のコードを追加します。

  let routes = response.rows[0].elements;
          const leastseconds = 86400; // 24 hours
          let drivetime = "";
          let closest = "";

          for (let i=0; i<routes.length; i++) {
            const routeseconds = routes[i].elements[0].duration.value;
            if (routeseconds > 0 && routeseconds < leastseconds) {
              leastseconds = routeseconds; // this route is the shortest (so far)
              drivetime = routes[i].elements[0].duration.text; 
                 // hours and minutes
              closest = response.originAddresses[i]; 
                 // city name from destinations
            }
          }
          alert("The closest location is " + closest + " (" + drivetime + ")");


このコードはすべての行を調べて、各行の最初の(そして唯一の)要素から、運転にかかる時間を求めます。次に、運転時間を現在の最短時間と比較します。最終的に、最短の運転時間、すなわち最寄りの場所を求めることができます。



このようにして最寄りの技術者を見つけることができました。今回は、わずか 4 分のところの 204 S Clark 通りにいる技術者でした。ここでは、JavaScript アラートと通信していますが、実際には、おそらく独自のバックエンドシステムを呼び出し、技術者を顧客に割り当てることになるでしょう。

この記事では、Distance Matrix API の使用例をいくつか紹介しましたが、探るべきことはもっとたくさんあります。この例を使って、独自の配送サービス、配達ルートプランナー、または昔のスタイルの走行距離表に発展させることもできます。ルートを選択したら、Directions Service を使用して地図上にルートをプロットし、ユーザー向けにルート表示を追加させることもできます。

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

Posted by 丸山 智康 (Tomoyasu Maruyama) - Google Maps テクニカル アカウントマネージャ

この記事は Google Maps Platform の Senior Product Manager である Eli Danziger による Google Maps Platform Blog の記事 " How mapping for rides and deliveries use cases is a different world: Beyond the Map" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 ...
この記事は Google Maps Platform の Senior Product Manager である Eli Danziger による Google Maps Platform Blog の記事 " How mapping for rides and deliveries use cases is a different world: Beyond the Map" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。



Google Maps Platform を通常とは異なる特殊なユースケースで使用する際、その課題を解決する新しい方法を見つけ出すために、マップのデータの一部改良や、新しい種類の情報を追加、またはさまざまなデータ同士を組み合わせるなどの工夫が必要となります。今回は、配車サービスや配達サービスのユースケースに合わせたマッピングが一般のマッピングとどのような点で異なるか、以前にこの記事を執筆した Eli Danziger に聞きました。

タクシーを呼ぶ配車や、配達サービスを利用するといった体験に関して、ユーザーに届ける必要がある情報にはどのようなものがあるのでしょうか?通常の Google マップ アプリが提供する情報との違いは何なのでしょうか?



その答えはいくつか考えられます。まず、配車や配達サービスという体験は、私たちの生活の重要な局面で起きることがあります。これをマイクロモーメントと称する人もいますが、すばらしい製品体験を提供するには、同時に大きなリスクも伴います。たとえば、みなさんがとても急いでいる時に、時間通りに空港へ到着しなくてはいけないことを想像してみてください。近くに車が見つかりリアルタイムで ETA(到着時刻)を確認できることが、フライトに間に合うか否かの分かれ目となります。また、注文した料理が時間通りに来なければ、お腹が減ってイライラするでしょう。次に、ユーザー体験に対してお金を払うサービス利用者もいます。これらのユーザー体験に対してお金を払うことで、期待値は一気に高まることでしょう。サービス事業者としては、プロセス全体でユーザーが適切な期待感を持ち、双方の透明性を高めることが求められます。このため、配車・配達サービスの構築においては、ユーザーが 一般向けの Google マップから得られるものとは異なる種類のデータと機能を提供しなければなりません。


どのようにして、これを異なる種類のマップ データや Google Maps Platform の機能に転換するのですか?



配車サービスや配達サービスを営む企業は、大事な時にユーザーにサービスを提供することになるので、乗客がドライバーを見つける、あるいはベストなタイミングで料理を配達できるように、きわめて詳細なデータを必要としています。そこで、Google は、東南アジアに二輪車用のルートを追加しました。これについては、前回の記事で述べました。特定の地域では、ライドシェアや配達に二輪車用のルートがよく使われます。マップに上述のルートがなければ、企業は二輪車のドライバーを適切に案内することができなかったでしょう。

単なる地図データとしてだけでなく、API が配車サービスや配達サービスの特有のシナリオに対して、できるだけ効果的に作用するように工夫することも大切です。例えば、自動車を呼ぼうとしているユーザーは、まず自分がいる場所の情報をタイプし、Places Autocomplete によって提示される候補一覧から場所を選択します。そのプロセスをできるだけ便利に素早く行うために、Google は、Places Autocomplete の検索結果の新しいモデルを開発し、最初に出てくるオプションが、車を呼ぼうとしている人に最も関連があるものにしました。

最後に、配車サービスや配達サービスはオンデマンドなものなので、サービス事業者やサービス利用者に対して常に最新の情報を提供する必要があります。街で一番人気のブリトーを注文しようとしている利用者に対して、このブリトーが地図上のどこにあるのかがリアルタイムで確認できるようにしています(お腹が空き過ぎてイライラしなければいいのですが)。さらに、サービス事業者は、ドライバーにアラートや通知を送信したり、リアルタイムにドライバーの運転状況を確認することができます。

配車サービスや配達サービスの地図ソリューションを理解するために 読者が知っておくべきキーワードは何ですか?



配車サービスにおけるマッピングについてお話しする際、Google のマッピング作業に関して他の分野で普通は使用しない言葉がかなりたくさんでてきます。配車サービスを使っている人にとってはよく知られているものが、ピックアップ ポイントです。その名の通り、利用者をピックアップする場所のことですが、その言葉がシンプルであるが故に誤解を招きやすいのです。それは配車サービスのエクスペリエンスを正しく理解するために不可欠な要素のひとつであり、適切なピックアップ ポイントを正確に決めるのは簡単なことではないからです。建物の入口なのか、あるいは道路の右側なのかによって、乗客は道路を横断しなくてもよいかもしれません。また、ドライバーもU ターンせずに済むかもしれません。企業はこうしたユーザー体験を実現するために多大な投資をしています。ピックアップのユーザー体験をできる限り良くするために、Google は、マップ データが顧客の事業を支援できる新しい方法を常に探しています。

一方で、ドライバーの割り当てということについてサービス利用者側はさほど気にしていないのが通常でしょう。ユーザーは、自分がいる場所に車を停めてもらうことや、食べ物を温かいまま自分のところに届けてもらうことに期待しているからです。しかし、この期待に応えるためには、利用しているサービスが特定の要求に対して適切なドライバーを見つけることが求められます。リアルタイムで交通渋滞を見極めて、いちばん近くにいるドライバーや注文したレストランを特定することは、ドライバーと乗客、宅配業者とサービス利用者をマッチングするというプロセスを踏むことになります。

次に、先に述べた ETA があります。ETA とは到着予定時間の略です。配車サービスと配達サービスに限定されるものではありませんが、企業とエンドユーザーのユーザー体験の中心となるコンセプトです。ドライバーの現在地から乗客のピックアップポイントまで、そしてピックアップポイントから目的地までの ETA をリアルタイムで利用することにより、サービス事業者はすべての車を効率的に活用できるだけでなく、乗客にとってすばらしいエクスペリエンスを生み出すことができます。ETA が適切であれば、みんなが得をするわけです。

良いエクスペリエンスを顧客やエンドユーザーに提供するために、なぜ反応速度が重要なのですか?

ユーザー体験については、速いほど良いという場面を何度も目にしてきました。とはいえ、サービス事業者からするとコンポーネントが提供する性能を超える速さのエクスペリエンスは構築できないので、API とサービスに関して可能な限り待ち時間を減らす努力が必要となります。Google は、最前線で大きな進歩を遂げてきており、引き続き改良に努めていきます。

配車サービスは独自の要求を抱えながらもグローバル産業へと発展してきました。しかしそれは、関連する技術進歩の積み重ねがもたらしたものであり、比較的最近の出来事です。Google は、常に顧客と密接に連携し、その課題と目標を確実に理解できるよう努めています。そうすることで、利用者が求める位置情報データとソリューションを提供することができます。

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

Posted by 丸山 智康 (Tomoyasu Maruyama) - Google Maps テクニカル アカウントマネージャ

2019 年 11 月 19 日より募集を開始していました、AI や機械学習を活用したスタートアップを対象に実施する 3 か月集中型のプログラム Google for Startups Accelerator の参加企業が下記の 9 社に決定しました ...
2019 年 11 月 19 日より募集を開始していました、AI や機械学習を活用したスタートアップを対象に実施する 3 か月集中型のプログラム Google for Startups Accelerator の参加企業が下記の 9 社に決定しました。
参加企業一覧
  • Baobab : 学習データ ( アノテーション ) 作成サービスを提供
  • チャネルトーク : CX 用のチャットツールと実店舗のアナリティクスサービスを提供
  • KARAKURI: 顧客対応やカスタマーサポートのオートメーションサービスを提供
  • LeapMind : 組込み Deep Learning 導入に向けたサービスを提供
  • LPIXEL : AI 医療画像診断の支援技術を提供
  • RevComm : 電話営業や顧客対応を人工知能で可視化して、生産性向上を実現するクラウド IP 電話を提供
  • Selan : 子どものお迎えと英語教育を同時に解決するサービスを提供
  • Singular Perturbations : 最適なパトロール経路/安全な経路の策定および警備人員計画、犯罪要因分析などの犯罪リスクヘッジソリューションを提供
  • SORA : ホテルの予約や市場データを元に料金設定業務を最適化し、収益創出の仕組み化を促進するサービスを提供

今後の流れ
今後 3 ヶ月に渡って、今回参加が決定したスタートアップを対象に、これからの成長に備えるためのツールを提供します。AI や機械学習の活用を主な要素とすることで、テクノロジーを活用した社会、経済、環境への取り組みに対する支援を加速し、ひいては、スタートアップの成長が日本経済のさらなる活性化につながることを期待しています。


スピーカー :
  • 小泉 耕二 氏 株式会社アールジーン 代表取締役 IoTNEWS 代表
聞き手 :
  • 小島 英揮 氏、Still Day One 合同会社 代表社員 パラレルマーケター・エバンジェリスト


エッジデバイスの流れを追いかける


小島 : 今日は小泉さんとエッジデバイスの動向を深く切り込んで行こうと思います。

小泉 : IoTNEWS の小泉です。木曜日朝の J-WAVE Morning Radio で、記事解説を担当しています。別所哲也さんの番組なので聞かれたことがある方もいらっしゃるかもしれませんね。また、木曜日の夜はフジテレビの Live News α にコメンテーターとして出演しています ...
2019 年 12 月 17 日に開催した第 11 回目は、「エッジデバイスの不可避な流れ」がテーマでした。恒例の対談セッションのレポートです。パネル進行スライドはこちらからご覧いただけます。

スピーカー :
  • 小泉 耕二 氏 株式会社アールジーン 代表取締役 IoTNEWS 代表
聞き手 :
  • 小島 英揮 氏、Still Day One 合同会社 代表社員 パラレルマーケター・エバンジェリスト


エッジデバイスの流れを追いかける


小島 : 今日は小泉さんとエッジデバイスの動向を深く切り込んで行こうと思います。

小泉 : IoTNEWS の小泉です。木曜日朝の J-WAVE Morning Radio で、記事解説を担当しています。別所哲也さんの番組なので聞かれたことがある方もいらっしゃるかもしれませんね。また、木曜日の夜はフジテレビの Live News α にコメンテーターとして出演しています。

小島 : IoTNEWS についてもう少し教えていただけますか。

小泉 : IoTNEWS というと IoT に関連する技術情報がメインのコンテンツというイメージを持たれる方が多いのですが、私自身はビジネス コンサルティングの出身でどちらかというとビジネスの中でのデジタル活用をどのように行うべきかという観点で情報をお届けしています。したがって、事例やデータ活用の方法を中心にできるだけ事業に役立つことを探して、発信していくことを心がけています。

小島 : コンサルタントの方がメディアに関わるキャリアパスというのはあまり無い気がするのですが。

小泉 : コンサルタントは、基本的に 2 次情報で仕事をしていることが多いんですよ。例えば、調査会社のレポートや海外事例を参考にしながら何かを組み立てるという仕事です。したがって、コンサルタントが自ら現場に行くことは意外に少ないと思います。一方、私自身は自分でその実態を見ないと気が済まない性格なんです。

以前、日本が中国に負けているぞ、これはまずいぞという記事が新聞などで結構話題になりましたが、何がどの程度問題なのかを、そうした記事では踏み込んでいませんでした。雰囲気を伝える報道はあれど、具体的なことには触れていないわけです。実際に深センに行った方がそこで見たこと、聞いたことをすぐにブログにアップというのがもう当たり前になっていて、こうしたブログの方がよっぽど詳しい情報なわけです。

自分が知らないことはまだまだたくさんありますからね。とにかく、行って聞いて、返していく、事業会社さんであればその事業について勉強をさせていただき、そこで得たことをきちんと伝えるようにしています。

小島 : Inevitable ja night は今日が 11 回目、足掛け 2 年ほどになります。今日はエッジデバイスがテーマですが、まずは、細かいところにをいきなり入らずに、技術を俯瞰していただき、皆さんに理解してもらうこと、そして、自分ごととして考えていただけるような内容にしたいと思います。



エッジデバイスとは?


小島 : では、最初にエッジデバイスが何か、言葉の定義から入りましょう。これは、IoTNEWS さんでの定義を引用させていただいたものです。

【エッジデバイス】
エッジデバイスとは、別々のネットワーク間同士で通信をし、データの効果や統合、同期などをシームレスに仲介する機器のことをいう。
ルーターやスイッチのように LAN 環境におけるデータ交換や切り替えをしたりするものから、多数のネットワークのそれぞれのゲートウェイを接続するものまで幅広い製品が存在している。
出典 : IoTNEWS


小泉 : 自動車もある種のエッジデバイス(実際にはエッジデバイスの集合体)と捉えることができます。クラウドとは対極の概念ですね。

小島 : この定義からすると、個々の端末、デバイスに処理系があるイメージですね。一方、IoT はそこには処理だったりインテリジェンスが必ずしもあるわけではないですよね。

小泉 : そうですね。温度センサーや光センサーといった、データを取得するものは IoT と呼んでいます。

小島 : ということは、IoT はデータを送るために通信が関与しているわけですね。一方、エッジデバイスはそれ自体が独立して何かを処理するもの、こんなイメージでしょうか?

小泉 : そういう見方も確かにありますが、実際にはさまざまな機能のものがあります。例えば、お湯を沸かすポットには、単純に温度を上げるための簡単なチップが埋め込まれています。しかし、自動車には高性能なチップが搭載されているわけじゃないですか。ですから、単純なものから複雑なものまで、これらを総称してエッジデバイスと呼んだほうがいいかもしれません。

小島 : では、エッジデバイスで具体的にはどんなものがあるでしょう? TPU がエッジデバイスというのは衝撃的ですよね。

小泉 : ここ数年は曲がる基板が話題です。たとえば、ゴルフクラブのグリップにぐるぐると巻きつけるタイプのものがあります。クラブを振る速度を測るわけです。また、腕時計のバンドの部分に埋め込むというものもあります。物理的にデバイスを小さくする方向もありますが、これらのように一定の大きさを保ちつつ曲げることができる素材もあります。

したがって、コンピュータの処理能力で分類することもありますが、物理的にどういう性質を持っているかという分類もありますね。

小島 : カメラとの融合もありますね。撮影した情報をそのデバイスで処理してすぐに何かを制御するというものです。

小泉 : はい。さらに、自動運転の技術の一部の機能を切り出して使うこともありますね。無人搬送車(AGV)は決められた軌道を通るものですが、これまではビニールテープなどを床に貼るなどして軌道を最初に示しておく必要がありました。しかし、最近はロボット自身がセンシングして自ら移動経路を決めることが可能です。これも、エッジデバイスの進化に寄るところが大きいですね。

小島 : 別な観点ではいかがでしょうか? 情報システムの歴史を振り返ると、ホストから始まって、クライアント サーバーの分散時代に移り、クラウドで再び集約し、そしてまた分散へと集中と分散を繰り返していますよね。

小泉 : そうですね。行ったり来たりしています。処理もそうですが、データを一箇所に集めるべきか、分散管理すべきかという議論は良くあります。

ある工場でのお話ですが、データを一箇所に集約してどうするのという議論がありました。いろいろなデータを一箇所で集中的に管理するのは良さそうな感じもするのですが、最近ではエッジ側が保持するデータ量もそこそこになってきていて、それをすべて一箇所で管理することが現実的では無くなってきています。クラウドがすべてという流れも変わってきているのではないでしょうか。




エッジデバイスが求められる理由


小島 : 次に、エッジデバイスが求められる背景を整理したいと思います。次の図は、上段がエッジデバイスに対するニーズ、下段がユースケースを列挙したものです。

遅延が起きては困る状況、通信環境が整備できない状況、つまりオフラインの状況については詳しい説明は不要かもしれませんね。プライバシーやセキュリティに関しては、外部にデータを出せない、クラウドにはデータを上げずにエッジ側だけで処理したいというニーズはありますよね。これらは、クラウドを推進する際に良く出てくる話題でもありますね。



小泉 : センサーデータをクラウドに上げること無く、エッジ側で処理できたら良いというケースはたくさんありますよね。

小島 : 下段はユースケースですが、これも良く出てくる AI と VR/AR(xR)。体験っていうのはすごい大事ですからね。

小泉 : そうですね。工場の中でタブレットをパイプの上にかざすと、センサーで取得した温度情報がタブレットのパイプの画像の上に表示されるという事例があります。パイプの内部の温度はただいま 20 ℃ ですといった感じです。VR の例ですね。

小島 : パイプの温度情報を単に表示するだけでなく、タブレット側で何か処理することもありますよね。

小泉 : カメラがその典型的な例かもしれません。カメラで撮影したものをすべてクラウドに上げるのではなくて、必要なものだけを選択して上げる。この選択という処理はエッジ側で行われるわけです。

小島 : そして、自動運転。自動運転ができるようになると、そこから技術が切り出されて、使われるようになりますよね。(ロボット)掃除機もそうですよね。

ところで、今後、エッジデバイスはどんどん進化していくと、それを使うための環境も合わせて整備するべきという意見もあります。いかがでしょうか?技術の進化と環境の整備が伴わなければ、社会実装が難しいですよね。

小泉 : はい。さらに言えば、コストも考慮すべきです。スマートシティというコンセプトはとても素晴らしいのですが、では街中にセンサーをつけて、アクチュエータを整備してとなったら、膨大な費用がかかります。

小島 : そして、利用者のコンセンサスを取ることも大切ですね。

先日、中国の杭州市に行く機会がありました。アリババの本社がある街です。そこに、顔認証だけでものが購入できる自動販売機がありました。驚きましたね。ご存知のように、中国ではバーコード決済がかなり普及しています。しかし、もうスマートフォンをかざすこともなく、顔認証で決済が行われる時代になっているわけです。

アリペイを利用する際、本人確認のため顔データを提出するのでその顔データを使っているそうです。利用者からすると便利になるなら顔データを出すことに何ら抵抗は無いわけです。ちなみに、決済のみならず、新幹線の駅への入場も顔パスでした。(顔認証ができない外国人は別の列)


気になるカメラソリューション


小泉 : カメラを使ったソリューションをいくつかご紹介したいと思います。



小島 : 生徒の状態管理というのはどのようなものなのでしょうか?

小泉 : これは、中国の展示会に出展されていたもので、授業中に居眠りをしている学生をチェックするというサービスです。

最近、一番気になっているのが工場での利用です。たとえば、工場のラインにカメラを設置し、定点観測する。ライン上を流れるものを撮影し、画像認識を経てその認識結果をロボットアームに伝えて、アームが正確に物体を掴む。対象物が多少傾いていたとしてもアームが調整してその物体を正しく掴むことができるというものです。

また、インテルが最近発表したテニスボールぐらいの大きさのカメラには加速度センサーが備わっています。先ほどの例では、カメラを工場内に固定して定点観測するのですが、こちらは逆でカメラそのものが移動し、動いている対象物を認識してロボットに伝えることができます。

小島 : つまり、カメラと物体との相対的な距離をリアルタイムで測ることができるというわけですね。とても複雑な処理ができそうですね。

小泉 : これまでは、カメラは固定されていて俯瞰した状況を撮影して、その情報を元にロボットアームが動くというものだったのですが、このカメラはアームそのものにカメラをつけることもできます。

小島 : その次の倉庫の例は?

小泉 : 倉庫に高性能なカメラを設置して、ものや人の動きを把握しようというものです。たとえば、棚にある荷物をピッキングするソリューションがあります。さらに、逆に荷物を棚のどこに収めるかを目的としたソリューションも求められています。むしろこちらの方は技術的に難しくて、荷物を間違った場所に置いてしまうことがあります。倉庫に設置したカメラがその間違いを認識できればこの問題も解決できます。加えて、いちいちクラウドにデータを上げなくても良ければ、もっと良い解決策と言えますね。

小島 : 中国でバーコード決済が広まった理由の一つは、バーコードさえ表示しておけば決済ができる、つまり導入にコストがあまりかからなかったからです。しかし、今後、顔認証で決済することになると、そのためのデバイスが大量に必要になります。その結果、誰もが手に入れられるようなコストになれば、そこで新しいユースケースができて、フィードバックがあり、さらに別なユースケースができる、そういうことが繰り返されることになります。今の中国が持つ社会実装力の高さがなせる技と言っても良いかもしれません。



ロボットアームのリアルタイム制御


小泉 : ロボットアームの分野でも面白い事例があります。1 台の産業用 PC(IPC)で複数のロボットアームを統合制御するというソリューションです(詳しくはこちらの記事をご覧ください)。リアルタイム OS を搭載した IPC にはロボットコントローラが実装されていて、高速ネットワーク(EtherCAT)に接続された複数のロボットアームの協調動作を制御します。ロボットアーム単体でもかなり複雑な動作をしますが、このロボットアームが複数台で協調することで、より高度で複雑な作業をすることが可能になります。

小島 : 海外のカンファレンスで、お掃除ロボットメーカーの幹部が話していたことを思い出しました。人間がロボットに対して「掃除しておいて」というと、まずは部屋の上方の埃を落として、それから床を掃除して、最後は窓を開けて換気をして・・・と一連の作業をその環境にあわせてやってくれるというものでした。

小泉 : なるほど、今日は、外は雨が降っていて窓は開けられないから、埃は落とさずに床掃除だけをしておこうとか、環境にあわせて制御が行われるということですね。

小島 : 単純なシーケンス制御だとイレギュラーなことが起きた時の対応は難しいですが、協調による制御ができれば、人間にとってかなり心地良い結果をもたらしてくれますよね。

小泉 : 指示されたことを忠実に行うだけでなく、状況をきちんと把握して、適切な判断をしながら作業を進めていくということが、このエッジデバイスの世界でも急速に進んでいくと思います。


5G 時代におけるエッジデバイス


小島 : 5G が普及したら、もっと広域で同じような複雑な制御ができそうですね。

小泉 : 5G で世の中すべてが繋がったら確かに実現はできるでしょう。しかしながら、基地局からそのデバイスまでを 5G で接続できたとしても、そのデバイスの先が本当に高速で通信できるのか、また、高速通信に耐えられるコンピュータ リソースなのかということも考える必要があります。従来に比べて良くなりそうというのは間違いないでしょうが、それが保証できるというのは時期尚早だと思います。

小島 : 5G には多数同時接続という特徴もありますよね。

小泉 : 高速通信よりも同時に多くのデバイスと接続できるという特徴の方が IoT にとって喜ばしいことですね。スマートシティを実現することを考えた際に、街中の至るところに設置される大量のデバイス、センサーを超高速で、遅延を抑えて通信できるわけですからね。

小島 : 接続先がインテリジェントな形で協調すれば、さらにいろいろなことができそうですね。


小泉 : 5G で多くのデバイスを接続すれば、クラウド側のコンピュータ リソースとエッジデバイス側のコンピュータ リソースが溶け合うというか融合するというか、どちらでも処理が可能になって、相互にカバーできる状態になります。

小島 : クラウドとエッジデバイスが 1 つの大きなコンピュータ リソースになるということでしょうか。

小泉 : そうです。たとえば、3 つのエッジデバイスが接続されているとしましょう。そのうちの 1 つが機能不全になったとしても、隣のデバイスが代わりに動くというそんな形が考えられます。自動運転カーのコンピュータの動作が、運転中におかしくなった場合、そのコンピュータを停止しようというのは自然な対応です。しかし、コンピュータを停止することはすなわち誰かがその代わりに車を制御しなければなりません。では、いきなり自動から手動運転に切り替えてしまうというのもちょっと乱暴な話で、運転手に負担をかけることになり逆に危険を伴うかもしれません。しかし、隣のレーンを走っている自動車がその異常を検知して、その車の制御を代行することができれば、手動運転の必要は無くなります。

エッジデバイス単体の性能や安全性を高めることは重要ですが、そうではなくて周辺の複数のデバイスと協調することで、自分がダメだった時に他に委ねるとか、あるいは 1 台ではできない大量のデータ処理を複数のコンピュータ リソースと協調して行うとか、そういうことが実際にできる時が近づいていると思います。

小島 : クラウドではコンテナ技術によって可搬性を高める方向の流れがありますが、エッジデバイスでも同様な動きはあるのでしょうか。

小泉 : コンテナ技術を使った機器もどんどん増えています。これが進化すれば、いずれは、ロボットアームのようなところでもコンテナ技術が使われるようになるでしょう。同じプログラムをクラウド側のリソースとエッジ側のリソースのいずれかで動かすこともできるわけです。さらにクラウドとデバイスが 5G で接続されていれば、状況に応じて、すぐに切り替えることも可能でしょう。たとえば、アームが 2 本あった時に、一方のアームの処理の負荷が高いと判断したら、すぐに他方のアームに切り替えて処理を継続するということもできます。

小島 : エッジデバイスというと決められた処理を粛々とこなすものという印象があったのですが、今の話が現実になると、いいようにやってくれる感がさらに高まりますね。協調とかオーケストレーションの世界が楽しみですね。

では最後に、エッジデバイスの今後について、小泉さんはどのように見ていますか?

小泉 : 先ほどもお話ししたように、デバイス単体が自律的に何かをするというよりも、複数のデバイスが協調することで想像以上に面白い動きをするんじゃないでしょうか。もともとプログラムのとおりに動くいわゆるシーケンス処理を得意としており、今後はデバイスに搭載されるコンピュータ リソースも増えるのでますます賢くなることは確かです。ただ、搭載できるリソースも無限ではないですから、無理やりリソースを詰め込むのではなくて、複数のデバイスで協調することで、さらに賢くしていこうという方向に向かっていると思います。

小島 : わかりました。今日はありがとうございました。

この記事は Katharina Familia Almonte による The AMP Blog の記事 "Cookie classification on AMP" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

 投稿者: Google の AMP Project グローバル プロダクト リーダー、Katharina Familia Almonte



昨年、ウェブ全体のプライバシーとセキュリティを改善する継続的な作業の一環として、Chrome に Cookie 分類スキームを導入する計画について お知らせしました。この計画は、2020 年 2 月の Chrome 80 で実現される見込みです。Mozilla は、Firefox でクロスサイト Cookie の SameSite=None; Secure 要件 ...
この記事は Katharina Familia Almonte による The AMP Blog の記事 "Cookie classification on AMP" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

投稿者: Google の AMP Project グローバル プロダクト リーダー、Katharina Familia Almonte



昨年、ウェブ全体のプライバシーとセキュリティを改善する継続的な作業の一環として、Chrome に Cookie 分類スキームを導入する計画についてお知らせしました。この計画は、2020 年 2 月の Chrome 80 で実現される見込みです。Mozilla は、Firefox でクロスサイト Cookie の SameSite=None; Secure 要件を実装する予定で、新しい Cookie 分類モデルのサポートを確約しています。Microsoft は、Microsoft Edge 80 でまずは試験運用版としてこのモデルの実装を始める計画を発表しました

AMP チームはユーザーのプライバシー保護に注力しています。このブログ投稿では、まもなく行われるブラウザの変更に伴い、AMP による優れたユーザー エクスペリエンスを維持しつつ、透明性とユーザーの選択肢を増加させる方法について説明します。Chrome 80 が 2 月にリリースされるので、このブログ投稿は Chrome の変更点に特化して紹介します。

Chrome の新しい Cookie 設定の説明
Chrome の新しいモデルはデフォルトで安全で、特に指定がない限り、すべての Cookie が外部アクセスから保護されるべきだという前提に立っています。デベロッパーは、クロスサイト アクセス用の Cookie を新しい Cookie 設定である SameSite=None を使って明示しなければなりません。また、クロスサイト Cookie が HTTPS 接続でのみ利用されるように、Secure 属性も追加で指定する必要があります。SameSite 値が宣言されていない Cookie は SameSite=Lax として扱われます。外部アクセスは、SameSite=None; Secure 設定のある Cookie のみが可能になります。ただし、これらが安全な接続からアクセスされることが条件です。新しいモデルの詳細については、こちらのデベロッパー ブログ投稿をお読みください。

影響範囲
AMP Cache でレンダリングされる AMP ページでファースト パーティ Cookie にアクセスする必要がある場合は、まもなく行われるブラウザの変更によるユーザー エクスペリエンスへの影響の有無について慎重に評価することをおすすめします。たとえば、AMP Cache からオリジン ドメインへの移動、有料コンテンツ、ログイン状態、測定、ショッピング カート機能などにファースト パーティ Cookie を利用している場合、問題になる可能性があります。利用できるソリューションは 2 種類ありますが、最適なソリューションは各サイトの具体的なユースケースによって異なり、時間とともに変化する可能性もあります。

Cookie にクロスサイト アクセスを指定する
Chrome の Cookie 分類に伴う変更によって影響を受ける AMP サイト運営者が利用できるソリューションの 1 つは、AMP ページのファースト パーティ Cookie に SameSite=None; Secure を設定することです。これにより、この Cookie がクロスサイト アクセス用のファースト パーティ Cookie であることが明示されるので、ユーザー エクスペリエンスが損なわれることはなくなります。

Set-Cookie: widget_session=abc123; SameSite=None; Secure

このアプローチによるメリットは、実装が簡単なことです。しかし、将来的に複数のサイトが利用する Cookie とは別に 1 つのサイトのみが利用する Cookie を細かく管理できる機能がブラウザで提供されることになった場合、この Cookie はクロスサイト アクセスであることが明示されているので、キャッシュされた AMP ページでユーザーがファースト パーティ Cookie をクリアするリスクが高まります。

Signed Exchange による対応
別の方法として、サイト運営者は Signed Exchange を利用して AMP Cache でレンダリングされる AMP ページでファースト パーティ Cookie がファースト パーティ Cookie として扱われる状態を実現できます。Signed Exchange は、ページの URL と元のサイト運営者のドメインを関連付けることができる新技術です。これは、ページが AMP Cache 経由で配信される場合でも、スピードのメリットを損なうことなく利用できます(ブログ投稿ガイドをご覧ください)。ここでの Signed Exchange によるメリットは、ブラウザが外部アクセス用として明示されていない Cookie をブロックするようになっても、AMP Cache でレンダリングされるページでファースト パーティ Cookie を明示する必要がないことです。しかし、本投稿の執筆時点で、トップ ストーリー カルーセルは Signed Exchange をサポートしていないため、今のところすべてのユースケースに対処することはできません。

まとめ
以上の内容をまとめます。2 月に、新しい Cookie 設定 SameSite=None; Secure が Chrome に導入される予定です。ファースト パーティ Cookie を利用する必要がある AMP Cache ページで最適なユーザー エクスペリエンスを保証するために、サイト運営者の皆さんには、新しい設定を使ってクロスサイト アクセス用の Cookie であることを明示するか、Signed Exchange を実装することをおすすめします。ブラウザは新しい Cookie 分類モデルの採用を始めています。ユーザーが細かなプライバシー管理を行えるようにしつつ、優れたユーザー エクスペリエンスを維持するために、このブログ投稿を役立てていただけると幸いです。Chrome の SameSite Cookie の利用方法やテスト方法の詳細については、web.dev のガイドChromium の SameSite 最新情報に掲載されているヒントをご覧ください。


Reviewed by Chiko Shimizu - Developer Relations team

この記事は Chrome およびウェブ プラットフォーム パートナーシップ、Barb Smith による Chromium Blog の記事 "SameSite Cookie Changes in February 2020: What You Need to Know" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


 今月の Chrome 80 安定版のリリースより、Chrome はデフォルトで安全な新しい Cookie 分類システムを強制するようになります。これにより、SameSite 値を宣言していない Cookie ...
この記事は Chrome およびウェブ プラットフォーム パートナーシップ、Barb Smith による Chromium Blog の記事 "SameSite Cookie Changes in February 2020: What You Need to Know" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


 今月の Chrome 80 安定版のリリースより、Chrome はデフォルトで安全な新しい Cookie 分類システムを強制するようになります。これにより、SameSite 値を宣言していない Cookie は SameSite=Lax の Cookie として扱われます。サードパーティ コンテキストで利用できるのは SameSite=None; Secure が設定されている Cookie のみになり、それも安全な接続が使われている場合に限られます。

この変更は、2019 年 5 月に初めて発表され、それに合わせてデベロッパー ガイドが公開されました。また、2019 年 10 月にリマインダーと追加情報をお知らせしました。ロールアウトが迫っているため、次の動画と情報を確認して今後の変更について認識し、対応していただくようお願いいたします。




リリースのタイミング: Chrome 80 の安定版リリースは、2 月 4 日から始まりました。Chrome 80 は、2 月中に一部のユーザーに対して新しい Cookie 分類システムを強制するようになり、対象は徐々に拡大されます。ロールアウトのタイミングや手順に関する最新情報は、SameSite 最新情報ページをご覧ください。 ブラウザがアップデートされたかどうかを確認するには、こちらのページにアクセスしてください。すべての列が緑色になっている場合、ブラウザに新しいデフォルトが適用されています。


デベロッパー ツールのコンソールの警告: 必要な設定が行われていないクロスサイト Cookie がページに含まれている場合、デベロッパー ツールのコンソールに警告が表示されます。自分のサイトを参照しているときにデベロッパー ツールに次のような警告が表示される場合、サイトの機能を実現している Cookie が適切に設定されていない可能性があります。次に、Chrome 80 のデベロッパー ツールの警告を示します。以前のバージョンの Chrome(77 以降)でも同様の警告が表示されます。


例外となるのは、サービスが冗長な Cookie のペアを発行しており、一方の Cookie に新しい設定、もう一方の Cookie に互換性のないクライアント用の以前の設定が含まれている場合です。この場合、サービスが意図したとおりに動作するにもかかわらず、以前の Cookie によって警告が表示されることがあります。このアプローチについては、こちらに記載があります。


Google の Cookie: 一部の Google のサービスでは、上記のアプローチを採用し、新しい設定の Cookie と 以前の設定の Cookie を発行しています。そのため、Google のサービスは意図した通りに動作するにもかかわらず、Google の Cookie に関する警告がデベロッパー ツールのコンソールに表示される場合があります。


移行による一時的な影響: クロスサイト Cookie のプロバイダが Chrome 80 リリースの直前に Cookie をアップデートした場合、Chrome 80 を使っている既知のユーザーや復帰したユーザーが一時的に未知のユーザーや新しいユーザーに見える可能性があります。これは、ユーザーの Cookie が新しい設定に更新されると、元通りになります。それよりも前にあらかじめ Cookie を更新していたプロバイダは、ユーザーが新しい設定の Cookie を受け取れる時間が長くなるため、この影響を受けにくくなります。


ログインフローに関する一時的な対処法: 認証の過程でウェブサイトとサードパーティ プロバイダの間で Cookie が渡される場合、ユーザーのログイン操作に影響を与えないようにするため、Chrome には「Lax + POST」として知られている一時的な対処法が導入されています。これにより 2 分間、トップレベルのクロスサイト POST リクエストに SameSite 設定を指定していない Cookie を利用できます。トップレベルのクロスサイト POST リクエストは、ログインフローによく使われます(これにより、トップレベルのクロスサイト GET リクエストの動作が変更されることはありません。トップレベルのクロスサイト GET リクエストでは、SameSite が「Lax」の Cookie が送信されますが、「Strict」の Cookie は送信されません)。この対処法は、新しいモデルに関する Chromium トラッカーで説明されています。サードパーティ ログイン サービスを使用または提供している方には、ただちにログインフローをテストすることを強くおすすめします。


エンタープライズ ポリシー: ログインなどのサービスや社内アプリケーションが Chrome 80 の変更に対応できない場合、企業の管理者は特別なポリシーを実装し、Chrome ブラウザを一時的に以前の動きに戻す必要があるかもしれません。


テストとトラブルシューティング: 新しいモデルでサイトやサービスがどのように動作するかを確認するには、Chrome 76 以降で [SameSite by default cookies] および [Cookies without SameSite must be secure] 試験運用版フラグを有効にしてテストすることを強くおすすめします(フラグは、chrome://flags から有効にすることができます)。新しいモデルは Chrome 80 に徐々にロールアウトされるので、テストを行う場合は、Chrome 80 でフラグを有効にして新しいデフォルト設定がブラウザに確実に反映されるようにする必要があります。


また、Chrome 80 で想定しない動作が発生した場合、[SameSite by default cookies] および [Cookies without SameSite must be secure] フラグを無効にすることで、それが新しいモデルによるものかどうかを切り分けることができます。フラグを無効にしても問題が発生する場合は、問題の原因は Cookie の変更ではない可能性が高いでしょう。その他のテストやデバッグのヒントは、こちらに掲載されています。

その他のリソース:



Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Chrome プラットフォーム チーム テクニカル ディレクター、Anthony Laforge による Chromium Blog の記事 "Moving Forward from Chrome Apps" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


2013 年に Chrome アプリが リリースされてから、ウェブ プラットフォームは大幅な進化を遂げました。私たちは、コミュニティのメンバーとして他のブラウザと連携し、プラットフォームに高度な新機能を導入するために 注力 ...
この記事は Chrome プラットフォーム チーム テクニカル ディレクター、Anthony Laforge による Chromium Blog の記事 "Moving Forward from Chrome Apps" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


2013 年に Chrome アプリがリリースされてから、ウェブ プラットフォームは大幅な進化を遂げました。私たちは、コミュニティのメンバーとして他のブラウザと連携し、プラットフォームに高度な新機能を導入するために注力し続けています。この取り組みについては、昨年 11 月の Chrome Developer Summit でもお知らせしました。

モダンブラウザの進化により、ウェブは広範なユースケースに応えることができる好位置に押し上げられました。Figma などの企業や Google Earth などの私たちのプロダクトの成功はその証拠です。ウェブはオープン プラットフォームでこそ最上級の体験を提供できると、私たちは確信しています。

この継続的な進化を踏まえ、以前のお知らせからさらに発展させて、以下のように、すべてのオペレーティング システムで、Chrome アプリのサポートの段階的廃止に着手します。

  • 2020 年 3 月: Chrome ウェブストアで 新規 Chrome アプリの登録を終了します。デベロッパーによる既存 Chrome アプリのアップデートは 2022 年 6 月まで可能です。
  • 2020 年 6 月: Windows、Mac、Linux で Chrome アプリのサポートが終了します。Chrome Enterprise および Chrome Education Upgrade のユーザーは、サポートを 2020 年 12 月まで延長するポリシーにアクセスできます。
  • 2020 年 12 月: Windows、Mac、Linux で Chrome アプリのサポートが終了します。
  • 2021 年 6 月: NaCl、PNaCl、PPAPI API のサポートが終了します。
  • 2021 年 6 月: Chrome OS で Chrome アプリのサポートが終了します。Chrome Enterprise および Chrome Education Upgrade のユーザーは、サポートを 2022 年 6 月まで延長するポリシーにアクセスできます。
  • 2022 年 6 月: Chrome OS で、すべてのユーザーに対する Chrome アプリのサポートが終了します。
この変更は、Chrome 拡張機能のサポートには影響しません。Google は、すべての既存プラットフォームで Chrome 拡張機能に対するサポートと注力を継続します。堅牢な拡張機能エコシステムを育むことは Chrome のミッションにとって重要です。私たちは、すべてのユーザーのために、ブラウズ体験をカスタマイズできる便利な拡張機能プラットフォームを提供することを約束します。

さらに詳しい情報(例: タイムライン、推奨事項、よくある質問など)は、Chrome アプリ移行サイトをご覧ください。このページは、プロセスが進展するにつれて最新状態に更新されます。

Chrome チームを代表して、Chrome アプリを使ってすばらしい体験を構築してくださったデベロッパー コミュニティの皆さんに感謝します。オープンなウェブ標準(例: PWA)を活用してすべてのモダンブラウザで実現される同じような体験にご期待ください。

Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Google Cloud プロダクト マネージャー、Christiaan Brand、Google ソフトウェア エンジニア、Kaiyu Yan による Google Online Security Blog の記事 "Have an iPhone? Use it to protect your Google Account with the Advanced Protection Program" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 ...
この記事は Google Cloud プロダクト マネージャー、Christiaan Brand、Google ソフトウェア エンジニア、Kaiyu Yan による Google Online Security Blog の記事 "Have an iPhone? Use it to protect your Google Account with the Advanced Protection Program" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

 オンラインの攻撃者がユーザー名とパスワードをだまし取ろうとするフィッシングは、アカウントが侵害される主な原因の 1 つです。先日、私たちは The Harris Poll と連携し、米国在住の 500 名の高リスク ユーザー(政治家やそのスタッフ、ジャーナリスト、企業の重役、活動家、オンライン インフルエンサー)への調査を行ったところ、回答者のうち 74% がフィッシングのターゲットになったことがある、またはフィッシング攻撃の被害に遭ったことがあると答えました。

Gmail は毎日 1 億件以上のフィッシング メールを自動的にブロックし、政府から支援を受けた攻撃者に狙われている人々に警告しています。しかし、Advanced Protection Program に登録すれば、Google アカウントのセキュリティをさらに強化できます。攻撃者は、皆さんの個人用または仕事用の Google アカウントやデータにアクセスするために進化し続ける手法を使っています。Advanced Protection Program は、それらの手法に対して自動的に保護する Google 最強のセキュリティ保護機能です。

フィッシング攻撃に対して最強の保護を提供するセキュリティ キーは、Advanced Protection Program の重要な機能です。以前は物理セキュリティ キーを個別に購入して持ち運ぶ必要がありましたが、昨年にはセキュリティ キーが Android スマートフォンに組み込まれるようになりました。そして本日(元記事公開当時)より、iPhone でセキュリティ キーを有効化し、Google アカウントを保護できるようになります。

iPhone で Google の Smart Lock アプリを使ってセキュリティ キーを有効化

セキュリティ キーは、公開鍵暗号化を使って ID とログインページの URL を検証するので、たとえ攻撃者がユーザー名やパスワードを知っていたとしても、皆さんのアカウントにアクセスすることはできません。ログインの検証を試みるその他の 2 要素認証(2FA)手法とは異なり、セキュリティ キーには FIDO 標準が使われています。FIDO 標準は、自動ボット、大量フィッシング攻撃、標的型フィッシング攻撃に対する最強の保護を提供します。セキュリティ キーの詳細については、Cloud Next ‘19 のプレゼンテーションをご覧ください。


iPhone で Google の Smart Lock アプリを使って Google アカウントへのログインを承認

iPhone で、Google の Smart Lock アプリを使ってセキュリティ キーを有効化できます。Android スマートフォンには、この機能が組み込まれています。スマートフォンのセキュリティ キーは、Bluetooth を使って Chrome OS、iOS、macOS、Windows 10 の各端末でのログインを検証しますが、端末をペア設定する必要はありません。これにより、スマートフォンの便利さを維持したまま、ほぼあらゆる端末で Google アカウントが保護されます。

利用を開始するには

早速個人や仕事の Google アカウントを保護したい方は、以下の簡単な手順に従ってください。
  • スマートフォンのセキュリティ キーを有効化(Android 7 以上または iOS 10 以上)
  • Advanced Protection Program に登録
  • Google アカウントにログインする際に、スマートフォンとログインしようとしている端末で Bluetooth がオンになっていることを確認
また、アカウントにバックアップのセキュリティ キーを登録し、それを安全な場所で保管することを強くおすすめします。こうすることにより、スマートフォンを紛失したときもアカウントにログインできるようになります。Google の Titan Security Key を搭載したセキュリティ キーは、Google を含むさまざまなベンダーから入手できます。

Google Cloud ユーザーの方は、企業向けの Advanced Protection Program の詳細について、G Suite Updates ブログを参照してください。

皆さんのポケットの中にある強固なアカウントのセキュリティに、乾杯。

Reviewed by Eiji Kitamura - Developer Relations Team