この記事は Chromium Blog の記事 "Chrome 79 Beta: Virtual Reality Comes to the Web" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

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

ウェブにバーチャル リアリティがやってくる

Chrome に WebXR Device API が搭載されます。デベロッパーは、スマートフォンとヘッドマウント ディスプレイを使った没入型体験を作成できるようになります。Firefox Reality、Oculus Browser、Edge、Magic Leap の Helio ブラウザなどの他のブラウザも、まもなくこの仕様をサポートする予定です。

今回のリリースは、拡張現実や各種ツールなどのサポート、さらには現実世界での没入型体験の理解を広げるなど、今後の没入型機能の土台となります。没入型機能は、多くの体験を拡張できます。 たとえば、ゲーム、家の購入、購入前に自宅で製品を確認するなどがあげられます。バーチャル リアリティと新しい API を使ってみたい方は、ウェブにバーチャル リアリティがやってくるをお読みください。

オリジン トライアル

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

rendersubtree 属性のサポート

すべての HTML 要素に、表示用に DOM 要素をロックする rendersubtree 属性が追加されます。rendersubtree を "invisible" に設定すると、その要素の内容に対する描画やヒットテストが行われなくなり、レンダリングが最適化されます。rendersubtree で "activatable" トークンを使うと、ブラウザは非表示属性を削除し、内容をレンダリングして表示します。

Promise ベースの Wake Lock API

Wake Lock API のアップデートが追加され、Promise といくつかの種類のウェイクロックが導入されます。Wake Lock API を使うと、標準的で安全な方法により、画面や CPU サイクルの省電力モードといったいくつかの端末機能を停止できます。このアップデートは、古い API のいくつかの欠点に対処します。古い API は、画面のウェイクロックに制限があり、一部のセキュリティやプライバシーの問題に対処できていませんでした。

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

Android のインストール済み PWA のアダプティブ アイコン表示

Android Oreo で導入されたアダプティブ アイコンは、ホーム画面やランチャーのすべてのアイコンに同じ形状を強制します。Android O 以前のアイコンはどんな形状にすることもできたので、アイコンに背景はありませんでした。たとえば、GMail は四角形、Play は三角形だったため、これらのアイコンは白い円の中に配置されました。アダプティブ アイコン表示では、Android が自動的に不規則な形状のアイコンをマスクし、サイズを調整します。

すべてのフォーカス可能な HTML/SVG 要素がオートフォーカスをサポート

すべてのフォーカス可能な HTML または SVG 要素にautofocus 属性が追加されます。autofocus はこれまでも一部の HTML 要素でサポートされていましたが、フォーカスを受け取れるにもかかわらず autofocus 属性がサポートされていない要素もありました。この機能により、不一致が解消されます。

HTML 属性の width または height からイメージと動画のアスペクト比を計算

イメージのアスペクト比が計算され、読み込み前の CSS によるイメージのサイズ指定に利用できるようになります。これにより、イメージ読み込み時の不要な再レイアウトを避けることができます。

font-optical-sizing

font-optical-sizing プロパティは、フォントサイズを自動的に opsz（光学的サイズをサポートする可変フォントの光学的サイズ軸）に設定します。これにより、指定されたフォントサイズで最適に動作するグリフの形状が選択されるようになるため、フォントサイズに応じてスタイル設定が改善され、フォントが読みやすくなります。たとえば、ヘッダーのサイズのフォントの方が、本文のサイズの同じフォントよりもグリフのコントラストが高くなることがあります。

list-style-type: <文字列>

スタイルシートのリストスタイル マーカーで任意の文字を使えるようになります。たとえば、"-"、"+"、"★"、"▸" などです。CSS Level 2 以降、list-style-type は disc や decimal などのリストアイテム マーカーの外見を定義するキーワードをサポートしています。
これがないと、デベロッパーは多くの場合、実際のマーカーを隠し、コンテンツ プロパティで ::before 疑似要素を使って任意のマーカーを挿入せざるを得ません。残念ながら、list-style-position は疑似マーカーをうまく配置できません。

より明示的なエラーで Worklet.addModule() を拒否

Worklet.addModule() が失敗したとき、Promise はこれまでよりも明示的なエラー オブジェクトを使って拒否するようになります。Worklet.addModule() は、ネットワーク エラーや構文エラーなどのさまざまな理由で失敗する可能性があります。この変更が行われる前、Worklet.addModule() は実際の原因とは関係なく AbortError で拒否されていました。そのため、デベロッパーがワークレットをデバッグするのは困難でした。この変更後、Worklet.addModule() は SyntaxError などの明確なエラーで拒否するようになります。

Worker 自身の Service Worker オブジェクトの取得

Service Worker は、Service Worker スクリプトで self.serviceWorker を使って自身の ServiceWorker オブジェクトを取得し、self.serviceWorker.state を使って現在の状況を取得できるようになります。以前は、Service Worker のインスタンスが現在のライフサイクルの状態を取得する方法はありませんでした。これにより、グローバル変数を使って現在のライフサイクルの状態をトラッキングするというハックを使う必要はなくなります。この方法はエラーが起こりやすいうえ、待機時間を正常に取得できません。

フェッチの際にドキュメント間を移動する script 要素の評価の停止

フェッチの際に <script> 要素がドキュメント間を移動する場合、Chrome はスクリプトを評価しなくなり、error イベントや load イベントも発行しなくなります。script 要素がドキュメント間を移動できる点は変わりませんが、そのような要素は実行されません。これは、ドキュメント間を移動する <script> 要素の悪用によって発生する潜在的なセキュリティ バグを防ぎます。

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

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

任意の要素の -webkit-appearance キーワード

-webkit-appearance キーワードは、特定のタイプの要素でのみ動作するように変更されます。キーワードがサポート対象外の要素に適用された場合、要素はデフォルトの外見になります。



Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Google AMP Project マーケティング リード、Alex Durán による The AMP Blog の記事 "Users Prefer Tappable Stories On The Mobile Web" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


タップ可能なストーリーは、ユーザーがコンテンツを閲覧する重要な方法の 1 つになっています。実際、週に 1 回はモバイル コンテンツを閲覧するというユーザーの 60% が、ソーシャル メディアでタップ可能なストーリーを毎日閲覧しています。 タップ可能なストーリー とは、モバイル端末でのインタラクティブなコンテンツで、ユーザーがイメージ、動画、テキストなどの全画面の視覚表現を操作できるものを表します。しかし、この人気のあるフォーマットは、限られたクローズなプラットフォームでしか動作しないのが一般的です。タップ可能なストーリーを使ってユーザーに革新的なコンテンツを提供することで、サイト運営者はメリットを得られます。提供できるのは、サイト運営者のソーシャル プラットフォーム上だけではありません。AMP ストーリーを使えば、モバイルサイト上でも提供することができます。

サイト運営者が AMP ストーリーを使うメリットを深く理解できるように、Google は一流のグローバル リサーチおよび顧問会社である Forrester Consulting に委託し、モバイルウェブのユーザーはどの程度タップ可能なストーリーを求めているのかを評価してもらいました。この調査は、「Publishers: Capture The Mobile Web Opportunity With Tappable Content」（サイト運営者: タップ可能なコンテンツでモバイルウェブのチャンスをつかむ）と題されたもので、2019 年 9 月に実施されました。

Forrester はこの分析にあたって、週に 1 回以上モバイル端末でサイト運営者のコンテンツを閲覧する 18 歳から 65 歳までの 2,062 名の米国のオンライン ユーザーを対象に、オンライン アンケートを実施しました。また、同じユーザーを対象に、22 のリモート無制限ユーザーテストを行いました。どちらの調査でも、モバイルウェブにある実際のタップ可能なストーリーの例と、同等のスクロール式の記事を参加者に操作してもらいました。この調査により、回答者の 64% がスクロール式の記事よりもタップ可能なモバイルウェブ ストーリー形式を好むことが判明しました。

出典: Forrester Consulting が Google に代わって 2019 年 7 月に実施した委託調査

この調査の特に重要な結果を以下に示します。

• スマートフォン ユーザーの 74% が、少なくとも週に 1 回ソーシャル ストーリーを読むか閲覧します。ソーシャル ストーリーを閲覧したいという需要は、自分のストーリーを共有したいという需要を上回っています。サイト運営者には、自身のモバイルサイトでこの需要と供給のギャップを埋めるチャンスがあります。これにより、広告収入や豊かなデータ分析を実現できる可能性があります。 
• 84% のユーザーが、タップ可能なストーリーは期待どおりあるいは期待以上の操作性であると感じています。さらに、スクロール式の記事に比べて、タップ可能なストーリーの操作方法が魅力的と感じる割合は 1.4 倍にのぼりました。 
• 75% 以上のユーザーは、最もよく読むコンテンツ カテゴリのタップ可能なストーリーに何らかの興味を示しています。調査データから、ユーザーが非常に興味を持っているのは、以下のカテゴリの最新のライフスタイル コンテンツであることもわかりました。
  • DIY / ハウツー
  • 家庭 / 料理
  • スポーツ

出典: Forrester Consulting が Google に代わって 2019 年 7 月に実施した委託調査

Forrester の調査からわかるように、親しみやすいタップ可能なストーリー形式はサイト運営者がユーザーを獲得するまたとないチャンスです。AMP ストーリーなら、この形式をオープンウェブで実現し、サイト運営者は 1 つのエコシステムに縛られることなくコンテンツを制御できます。AMP ストーリーを支えているテクノロジーはまだ比較的新しいものですが、デベロッパーはいくつかの方法で使ってみることができます。

調査の全文はこちらから参照できます。ほかにはない魅力的なウェブ形式を使って、サイト運営者やコンテンツ制作者が既存の読者や新たなユーザーにアピールするチャンスについて詳しく説明されています。AMP ストーリー形式はウェブページとしてオンライン上に存在するため、検索インデックスへの登録が可能です。また、オープンウェブの一部なので、誰でも自分のサイトで試してみることができます。AMP ストーリーの広告オプションはまだ登場したばかりですが、私たちはこの領域を広げることに注力しています。サイト運営者がこのモバイル ファーストのフォーマットを使い、高度な視覚表現を駆使したタップ可能なストーリーとして情報を提供してくれることを楽しみにしています。

投稿者: Google AMP Project マーケティング リード、Alex Durán


Reviewed by Chiko Shimizu - Developer Relations Team

この記事は Google の Developer Advocate である Angela Yu による Google Maps Platform Blog の記事 " Google Maps Platform best practices: Securing API keys when using Static Maps and Street View APIs" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。



Google Maps Platform では、API キーをオープンな環境へ公表しなければならない場合でも、不正使用から API キーを守るために、複数レイヤにわたるセキュリティ措置を提供しています。この記事では、クレジットカードの利用に例えて、Google Maps Platform における様々なセキュリティ機能の仕組みを説明します。API キーをお財布の中のクレジットカードに記載されたカード番号だと考えてみてください。

クレジットカード番号と同じように、API キーを保護しよう

Maps Static API および Street View Static API は、カスタマイズされた地図または、ストリートビューのパノラマを公開するための、最も単純かつ効率の良い方法です。これらの API を使えば、どのようなウェブページにも、Google Maps Platform によってホスティングされているソース URL を伴う画像として、静的な地図やストリートビューの画像を追加できます。また、Google Maps Platform 使用状況に応じて適用される、1か月 $200 ドル分の無料クレジット の枠内で、最大 10 万件までの静的地図、または 28,000 件の静的なストリートビューの読み込みを提供できます。

ただし静的画像の API を使用するには、APIキーを誰でも閲覧可能なコードの中に含める必要があります。



グレートバリアーリーフのヘロン島で撮影された Google ストリートビューの水中写真。Street View Static API を使って埋め込んだ場合、このように表示されます。


上記のようなストリートビュー画像を、 Street View Static APIを使って、ご自身のウェブページに埋め込むには、下記の URL に設定された src 属性を持つ <img> タグをコードに埋め込む必要があります。ただし、以下のように、ウェブページのソースコードを閲覧したすべての人に、URL の一部として、API キーが見えてしまうことになります：


https://maps.googleapis.com/maps/api/streetview?location=-23.4427738,151.9276581&size=600x400&heading=75&key=AIzaSyCnltht8tNqkjMoAI-p2WzVVuT0DDl5iyI...

少し不安に感じますか？クレジットカードに例えると、泥棒にクレジットカード番号を盗まれてネットで好きなだけ買物をされてしまうように、誰かに自分の API キーをコピーされて、Google Maps Platform で好きなだけ API コールをされる恐れがあります。そこで、意図する用途以外に API キー使われることを防ぐために、API キーを保護する必要があるのです。

API キーを制限しよう

API キーは、特定の HTTP リファラからしか使えない、ということを Google Maps Platform に設定することで、用途制限をかけることができます（参考記事）。これは、クレジットカードを特定の小売チェーン店でしか使えないようにことと同様です。しかし、それでもまだ、誰かに一か所の店舗で大量に使われてしまうリスクは防ぎきれません。

さらなるセキュリティ措置として、この API キーが Street View Static API の呼び出しにしか使えないようにする制限をかけることもできます。すなわち、このクレジットカードは書籍を買うためにしか使えない、と制限をかけるのに似ています。こうすることで、悪意ある第三者にとって、クレジットカードの利用価値は大きく下がります。

あなただけが生成可能なデジタル署名

ホスティングされた画像の領域では、デジタル署名を追加することを推奨しています。これは、特定の書籍の購入をする際に、指紋認証を用いることに似ています。

デジタル署名された URL を生成するには、 API リクエストと API キーを、Google Cloud コンソールが管理する URL 署名シークレットと組み合わせる必要があります。署名シークレットとは、指紋のように、個人しか持っていないものであり、リクエストされる URL とは書籍の ISBN コードのようなものです。つまり、指紋と ISBN の数学的組み合わせに基づいてデジタル署名が生成されます。これは、あなたが公に共有できるものです。例えば、皆さんがご自身のクレジットカードを使って、特定の書籍購入を許可すると伝えているのと同等です（この場合、 API キーを使って特定の静的画像読み込みを許可していることになります）。




Google Cloud コンソールにおいて URL にデジタル署名を行っている画面のスクリーンショット


Google Cloud コンソールを使ってデジタル署名を生成できます　(Maps Static API および Street View Static API に関する手順はこちら)。または、デジタル署名を作成するために独自のサーバ側アプリケーションのコードを書くこともできます(文書の中にサンプルコードを記載しています)。デジタル署名は、皆さんの URL に添付されます。以下が、前掲のストリートビュー画像を読み込むために使える、署名された URL です。


https://maps.googleapis.com/maps/api/streetview?location=-23.4427738,151.9276581&size=600x400&heading=75&key=AIzaSyCnltht8tNqkjMoAI-p2WzVVuT0DDl5iyI&signature=Qt0k0Nrh8t6VFlEz2sdtIz__sPw=

サインされていない要求を制限する

静的な画像の URL にデジタル署名を追加する作業が済んだら、Maps Static API または Street View Static API へのキーを使ったデジタル署名を伴わないリクエスト件数の許容限界数をプロジェクトの中で低くすることで、さらにアカウントの安全度を強化できます。



この動画では、Google Cloud コンソールで量的制限値を管理する方法を示しています。Maps Static API と Street View Static API の量的上限値設定のページに関して、署名ありのリクエストの量的上限値、署名なしのリスクエストの量的上限値を管理する部分が、それぞれに設けられています。初期設定として、これら API を使ったプロジェクトは、1 日あたり 最大 25,000 件の署名なしリクエストを受付可能です。皆さんが API キーを使ってデジタル署名を伴った静的画像の URL のみを使用可能としたい場合は、この量的上限値を 0 に変更してください。

API キー、アプリケーション制限、API 制限、デジタル署名、量的上限値という 5 つのセキュリティ階層を設けることで、Google Maps Platform の認証情報を想定外に使用されてしまうのを防ぐことができます。ここで、前掲のストリートビュー画像を公開するために、5 つすべてを使用しました。したがって、たとえこの API キーが誰でも閲覧可能であっても、本ブログ上で、デジタル署名された要求先 URL によって、当該の Street View Static API を呼び出すためにしか使用できません。この特定のストリートビュー画像用の URL に基づいて、 1 つのデジタル署名しか作成していないため、この署名は他のどのストリートビュー画像に対しても機能しません。パノラマ画像のなかで向きを変えて別の角度から見ることさえできません。


クレジットカードの例えを最後まで当てはめるなら、次のようになります。クレジットカード番号を公開しましたが、同時に、クレジットカード会社に、そのクレジットカード番号は、パウエルズという書店からミゲル・ド・セルバンテス・サアヴェドラ Miguel de Cervantes Saavedra 作のペーパーバック書籍、『ドンキホーテ Don Quixote』を購入するためにのみ使うよう、指示を出したようなものなのです。 "El que lee mucho y anda mucho, ve mucho y sabe mucho."（よく読み、よく歩く人は、多くの事を見聞きし、多くの事を知る―「ドンキホーテ」からの引用）


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


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

この記事は Google の Support Program Manager である Mery Pardo による Google Maps Platform Blog の記事 " How to get started with Google Maps Platform and get support when you need it" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。



昨年、Google Maps Platform の更新と強化の実施について発表しました。全ての顧客向けの無料のカスタマーサポート、使用量を追跡してクラウド プロジェクトと同様にプロジェクトを管理しやすくするために Google Cloud Platform Console への統合を含んでいます。その後も、Google Maps Platform ソリューションの構築、最適化、管理をサポートする様々なリソースを提供してきました。Google Maps Platform を最大限に活用するために役立つリソースにはどのようなものがあるのか、見ていきましょう。

はじめてみよう

ドキュメント は有意義な最初の一歩です。ドキュメントは、技術情報、コードのサンプル、チュートリアルから成り、製品領域、プラットフォーム、API ごとに分類しています。また、よくある質問 リストも掲載しています。

コミュニティが牽引するサポート

StackOverflow というプログラマーのための質疑応答サイトに、現在活動中の Google Maps Platform 開発者コミュニティが存在します。Stack Overflow そのものは Google が運営しているわけではありませんが、Google アカウントを使ってサインインして、知りたい質問への答えを探したり、質問したり、質問に答えたり、役立つ回答に「役に立った」と投票することができます。これは、アプリを開発、バグ除去、保守するための技術的質問をするのに最適な場所です。Google Maps Platform のチームメンバーは、Google マップ 関連のタグをモニタリングしており、正確で役立つ情報が共有されるようにしています。

Google Maps Platform の専門家によるカスタマーサポート

もちろん、私たちも常に皆さんのために待機しています。現在入手できるリソースの中にご自身の質問に対する答えが見つからなかった場合、いつでもサポート担当者に直接連絡できます。アカウント特有の課題がある場合（例：容量制限や課金に関する課題）、特にサポートが関係してくることになり、私たちは皆さんの質問がどのようなことであれ、喜んでお役にたちたいと考えています。ケースを作成するには、Google Cloud Platform Console の中で Google Maps Platform サポートページ に移って、上部のドロップダウン バーから、ご自身の質問に関連するプロジェクトを選択するだけです。プロジェクトにおいて Google Maps Platform API が有効化されていない場合、サポートページは、皆さんが開始できるページを自動的に表示します。

また、最近、一部の顧客に対しサポート担当者にチャットで連絡できるようにしました。フィードバックも好評なため、現在、チャット機能を全てのユーザにご利用いただけるように準備を進めています。



皆さんがどのような方法でサポート依頼をするにせよ、私たちは、重大な課題 に関して1時間以内、全てのケースについて 24 時間以内に回答することを目標としています。

バグ、新機能の要望

Google では、Issue Tracker で既知および報告された多くの課題のリストを積極的に保持しています。ここでは、報告済みのバグや機能への要求を簡単に見ることができます。また、皆さんからのコメントは課題を調査する我々チームにとって手助けとなります。また、万一サービスが停止した場合、Google Cloud Console の Maps Support のセクションにバナーでメッセージと Issue Tracker へのリンクが表示されます。それを通じて、課題のリアルタイムな状況について、より詳しい情報が得られます。



バグ報告や新機能の要求を行いたい場合、あらゆる場面でサポートできるように我々は待機しています。まずは、Issue Tracker へ要求を送信してみましょう。その際に、サンプルコードや画面のキャプチャ画像を含めると、課題の特定、回答がより迅速になります。

API についての最新情報、サービス約款変更、サポートポータルの定期保守期間、その他の情報を得るには、新たな e メール通知グループに登録してください。全ての最新情報を一か所で受け取ることができます。


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




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

この記事は Google の Product Director である Ethan Russell による Google Maps Platform Blog の記事 " 9 things to know about Google's maps data: Beyond the Map" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。



毎日 10 億人以上が Google マップを使用し、Google Maps Platform を活用した500 万以上のアクティブなアプリとウェブサイトが存在する中、Google マップの地図データはどのように作られて、Google がその正確さをどのように維持しているのかについて質問をいただきます。シリーズ 3 回目となる今回は、Product Director である Ethan Russell によくある質問に回答してもらいました。地図データに関する質問や、個々のアプリケーションとエクスペリエンスに対して、Google の地図データを最新の状態に維持するためにどのようなことが行われているかを聞いてみました。

どのようにして Google の地図データを正確なものにしていますか？

世界は広大で絶えず変化しています。皆さんのご近所でレストランがどれほど頻繁に開店しては消えていくかを想像してみてください。次に、建設されたすべての企業、建物、家、道路について考え、 70 億人以上が住む世界 220 以上の国と地域に拡大してみてください。Google は地球上のすべての人に正確かつ最新の地図を提供したいと考えています、しかし、それらの多くが常に進行中なのです。そのため、地図データを提供するという仕事に終わりはなく、地図データを可能な限り最新の状態に保つためにさまざまな取り組みを行い、技術を開発しています。前回の記事をご覧いただいていない場合は、次の 2 本の記事は世界の地図を作成し、データを最新の状態に保つ方法を詳しく学ぶのに良い出発点となりす。最初の記事では、マッピングの取り組みの概要を説明し、2 番目の記事では、画像がどのようにマッピング技術の基盤となっているのかを説明しました。しかし、シリーズでまだ取り上げていないことがあります。顧客、企業、ユーザーが実世界について知っていることを提供でき、自分自身やお互いのデータを最新の状態に保てるようにする方法についてです。

情報を更新するにはどうすればよいか

地図データに正確でない箇所がある場合に、それを更新するためのいくつかのチャネルがあります。Google マップのユーザーはどなたでも、”フィードバックの送信”（Google マップのデスクトップ版）および編集の提案（Google マップと Google 検索上にプロファイルを配置）ツールを使用して、データ上の問題を報告することができます。Google Maps Platform の利用者で業界別ソリューション（ゲームなど）を使用している場合、不具合を報告するための API が製品に含まれています。ゲーム スタジオ パートナーから問題が報告されると、Google はそれに対応します。顧客がカスタマー エンジニアリング チームまたはアカウント マネージャーと密接に連携している場合、いつでも直接彼らまたはサポートチームと協力して情報を更新できます。ビジネス情報を管理する企業や代理店も、Google マイビジネス経由でビジネス情報を更新できます。

ユーザーによる協力以外に、Google がどのようにして最新の情報を得ていますか？

Google には、データを日々最新の状態に保つための専任チームがあります。第三者機関のリソースからのデータの取り込み、データを自動的に更新してスパムや不正を識別するアルゴリズムの開発、企業や組織に直接連絡して正確な情報を取得する作業などを行っています。

地図データはどのくらいの頻度で更新していますか？

地図は、文字通り毎日毎秒更新しています。Google では、衛星画像やストリートビューカー、Google マップユーザー、地元の企業主などから世界中の最新情報を常に収集しており、その情報を使用して地図を更新しています。Google マップのユーザーは、毎日 2,000 万を超える情報を Google へ提供しています。これは、毎秒 200 を超える情報量です。ユーザーからの最新情報に基づく更新に加えて、2 番目の記事でも紹介しましたが、画像や機械学習による取り組みなど、他の手段を通じて明らかになった数多くの更新も行っています。

企業や組織が多くのデータを提供できる場合、どのように提供すれば良いでしょうか？

新しい道路や新しい建物の住所などに関する大量のデータを持っている政府、非営利団体、教育機関などの組織は、Geo Data Upload ツールを使用できます。このツールを使ってデータを送信する場合、適切な形式でデータを送信することが重要です。そうすることで、Google は送付されたファイルをより簡単に取り込むことができます。空間属性を持つシェープファイル（.shp）または .csv が推奨ファイルタイプです。データを送信する準備ができたら、みなさん自身でアップロードコンテンツの要件をぜひ確認してください（こちらのサポートページ（英語）で確認できます）。

さまざまな分野でオンライン マーケティングを行う代理店は、Google マイビジネスを使用してビジネス情報を追加および更新できます。Places API にビジネス情報を取り込むだけでなく、メッセージング、製品在庫、さらに Googleマップや検索などの機能を通じて企業が消費者とより密接に連携できる幅広いツールを提供します。

変化する世界に対応するために必要な膨大な量のデータにどのように対処していますか？

Google は真にグローバルな規模で地図を構築しており、多くの情報を処理しています。道路、建物、住所、企業、およびそれらの多様な属性など、さまざまな種類のデータと、異なる視点からの画像を高解像度で取得しています。幸いなことに、これをゼロから始めているわけではありません。Dataflow や Cloud Spanner のような処理およびストレージシステムから、TensorFlow のような機械学習ライブラリやフレームワークを活用することで入ってくるデータの流れを理解することができます。

世界のさまざまな地域でデータ品質に違いがあるのはなぜですか？そして、企業があらゆる場所で Google Maps Platform を使用できるようにするために、これらの違いに対してどのように対処していますか？

地球全体をマッピングすることの面白さと挑戦のひとつに、すべての地域の違いに対処することがあります。郵便番号の粒度の違いや、建物の住所が通りの端から反対側の端まで直線的に延びているか、ブロックの周りにエリア状に分散しているかなど、歴史的・政治的背景の違いを把握するところから始まります。次に、都市内で建物が連続して接している場合や、異なる階に複数のビジネス（および個人の住宅）がある場合など、物理的な違いもあります。または、樹木が多く覆っていて、その下にある道路が見えにくい地域や、そうした樹木が無い一方で乾燥した河床が未舗装道路のように見える地域。さらに、新しい道路や建物の建設スピードの速さ、新しい事業の開業のスピードなど、経済的な違いもあります。アルゴリズム、機械学習、人間のオペレーターが理解する必要のあるさまざまな言語やスクリプトが加わると、世界のさまざまな地域でさまざまな種類の問題を引き起こす多くの複雑な要因を考慮する必要が生まれるわけです。

これらの違いに対処するために、新しい異なるマッピングアプローチを上述の領域には採用しています。参照可能な信頼のおけるデータソースがほとんどない地域では、衛星および街路レベルの画像と機械学習を使用して、道路や企業を識別し、地図データに情報を追加します。また、道路が狭いために地図を作成できない場合は、「ストリートビュー用三輪バイク」を作製して、それらの道路を追加するのに役立つ画像をキャプチャします。マッピングの新たな課題を発見するたびに、常に新しいソリューションの開発に熱心に取り組んでいます。

Google や他の組織が地図データを提供した方法の中で最も興味深いものは何でしたか？

Sheep View は個人的なお気に入りです。毛に覆われた羊の背中にソーラーカメラを取り付けて、フェロー諸島の画像をストリートビュー用に収集しました。 18 の島々からなるフェロー諸島には 50,000 人しか住んでいませんが、「羊の島」という名の通り、70,000 頭の羊が群島の緑の丘と火山の崖を歩き回っています。そのため、羊はその地域の画像を撮影するのに最高の方法であり、間違いなく最もクリエイティブな方法でした。

ハロウィーンと言えば、3 本足の人や湖に沈んでいる飛行機などの不気味なストリートビューの画像は一体どうなっているのでしょうか？

Google マップに表示され、Maps および Street View API を介して利用できる画像は、数十億枚の写真をまとめたものです。同じシーンの写真をつなぎ合わせても、物事が正確には揃わないことがあります。これは特に、歩いている人や飛んでいる飛行機のような、動いているもので起こります。これらの状況をより良く処理するために、Google はシステムとアルゴリズムを常に調整しています。実際、前回のハロウィーンの際にも、最も一般的なタイプの「不気味な」画像の背景にある撮影上の課題をブログ記事（英語）で説明しました。


地図データに関する一般的な質問について回答しました。Google が世界をどのようにマッピングし、企業が世界中でロケーションベースのエクスペリエンスを構築するのにそれがどれほど役立っているかについてさらに詳しく見ていきますので、今後のブログ記事もぜひ注目してください。


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




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

この記事は Chrome プロダクト マネージャー、Kenji Baheux による Chromium Blog の記事 "Addressing some misconceptions about our plans for improving the security of DNS" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。



ブラウザに URL を入力すると（たとえば「redcross.org」）、その情報がドメイン ネーム システム（DNS）プロバイダに送られ、リクエストは一意な数値の「IP アドレス」（例: 162.6.217.119）に変換されます。この IP アドレスが、インターネット上のウェブサイトを識別しています。その後、ブラウザは数値の IP アドレスを使い、皆さんが探しているサイトを開きます。残念なことに、現在のブラウザから DNS プロバイダへのリクエストは暗号化されておらず（他人によるパッシブ モニタリングに対して無防備）、認証もされていません（オンラインの攻撃者に対して無防備）。カフェや空港などのパブリック Wi-Fi に接続している場合、特にその点に注意すべきです。皆さんがアクセスするウェブサイトは、ネットワークを使っているすべての人が表示およびトラッキングできるだけでなく、皆さんのブラウザが悪意のあるサイトにリダイレクトされる可能性まであるからです。

9 月に、ある実験を Chrome で行うことをお知らせしました。この実験では、DNS-over-HTTPS（DoH）をサポートしている DNS プロバイダを既に使用しているユーザーが DoH による安全な DNS 接続を使用できるようにして、オンラインのプライバシーとセキュリティを強化することが目的です。DoH は、セキュリティとプライバシーの向上に向けたステップの 1 つとしてインターネット標準コミュニティによって開発されており、ブラウザと DNS プロバイダ間のトラフィックを暗号化します。悪意のある者が同じネットワーク上の他のユーザーのブラウジング動作を監視する際に使う手法の 1 つを排除できるので、プライバシーが向上します。また、DoH は DNS ルックアップにおける中間者攻撃の防止に役立つので、セキュリティも大幅に向上します。プライバシーを重視する組織やジャーナリスト、他のブラウザのプロバイダ、インターネット サービス プロバイダ（ISP）の多くが、この変更によってプライバシーとセキュリティが向上することに賛同しています。

残念なことに、私たちのアプローチの目的や、ISP が提供する既存のコンテンツ制御に DoH が影響を与えるかどうかについて、多少の誤解や混乱が発生しています。混乱の原因となっているのは 2 つの主張ですが、ここではその両方に対処したいと思います。

最初の主張は、Google がユーザーの DNS トラフィックを Google の DNS やその他の DoH 対応 DNS プロバイダにリダイレクトしようとしているというものです。この主張は誤りです。私たちはユーザーの選択肢とユーザーによる制御を重視しているので、DNS プロバイダの変更を強制するような計画はありません。現在のところ、ユーザーによる DNS のニーズの約 97% は ISP が処理していますが、多くの独立した DNS プロバイダも存在しています。こういったサービス プロバイダがユーザーのニーズや懸念に対応できている限り、多様なエコシステムが維持されることになるでしょう。私たちが行っているのは、ユーザーが選択した DNS プロバイダが DoH を提供している場合に、Chrome で安全な DoH 接続のサポートを有効にすることだけです。Chrome はユーザーの DNS プロバイダが実験に参加している DoH 対応プロバイダのリストに含まれているかどうかをチェックし、含まれていれば DoH を有効化します。DNS プロバイダがリストに掲載されていない場合、Chrome は DoH を有効化せず、現在の動作を続けます。DoH の採用が増えるにつれて、DoH 対応の DNS プロバイダの数も増えるはずです。

2 つ目の主張は、安全な DoH 接続が導入されると、一部の ISP が提供している家族向けのコンテンツ制御が制限されるというものです。実際には、DNS プロバイダが行っている既存のコンテンツ制御は、子ども向けの保護も含め、すべてそのまま動作するはずです。DoH によって URL データが保護されるのは、そのデータがブラウザと DNS プロバイダとの間を移動する間だけです。そのため、プロバイダが提供する不正なソフトウェアからの保護やペアレンタル コントロール機能は、今までと同じように動作し続けます。その証拠として、CleanBrowsing は暗号化されていないサービスと同じペアレンタル コントロール機能を DoH サービスでも提供しています。

先月お伝えしたように、この実験では段階的なアプローチを取っています。現在の計画では、DoH のサポートが有効になるのはユーザーの 1% だけで、既に DoH 対応の DNS プロバイダを使っていることが条件です。これにより、Google と DoH プロバイダは DoH のパフォーマンスと信頼性をテストできます。また、ユーザーからのフィードバックや、ISP などのステークホルダーからのフィードバックにも注目しています。学校や企業などで使われているマネージド Chrome リリースのほとんどは、デフォルトで実験の対象外になります。管理者が機能を制御できるポリシーも提供しています。さらに、Chrome 79 以降のユーザーは、chrome://flags/#dns-over-https から DoH の実験を完全にオプトアウトすることもできます。

私たちは、DoH によってユーザーのプライバシーやセキュリティが向上することについて楽観的に考えています。ただし、DNS の重要性や、私たちが予見していなかった実装上の懸念もありえることは理解しています。そのため、計画は慎重かつ透過的に進める予定です。私たちはフィードバックや建設的な協力関係を歓迎します。DoH の導入によって意図しない結果が生まれないよう、ISP や DNS プロバイダ、そしてインターネットや子どもの安全を擁護する団体などのステークホルダーと連携しながら進めてまいります。


Reviewed by Eiji Kitamura - Developer Relations Team

2020 年 2 月より AI を活用したスタートアップ向けに実施する 3 か月集中型のプログラム「Google for Startups Accelerator 」を実施します。このプログラムは、確立された製品・サービスを擁するスタートアップを対象に、これからの成長に備えるためのツールを提供します。AI や機械学習の活用を主な要素とすることで、テクノロジーを活用した社会、経済、環境への取り組みに対する支援を加速し、ひいては、スタートアップの成長が日本経済のさらなる活性化につながることを期待しています。本日より、本プログラムに参加を希望するスタートアップ企業を募集開始します。


Gooogle for Startups Accelerator 活用の利点

• Google for Startups Campus ( 東京 ) の利用 ：本プログラムに参加するスタートアップ（以下、参加企業）は、参加期間中 Campus 内のワークスペースを活用することができます。また、Campus 内にある施設の全て（飲食スペースや一部の会議室を含む）を利用できます。
• Google 社員によるメンター制度：Google AI チームをはじめとする様々なチームとのコラボレーションや Google のテクノロジーや製品、サービス、さらに人的ネットワークを活用する機会を提供します。ベスト プラクティスの共有に加え、企業や製品に関する大枠の戦略策定サポートも提供しています。
• トレーニング プログラム：参加企業は機械学習や人材獲得・育成、製品開発管理に関する各種トレーニングを受講できます。機械学習など技術の活用を中心としたものからリーダーシップ トレーニング等を通じ、スタートアップが必要とするサポートを提供します。
• スタートアップ エコシステム（コミュニティ）への参画：異業種のスタートアップや VC、技術者、技術アドボケイト等との交流を通じ、人的ネットワークの拡大にも貢献します。

募集概要

• 対象 : 社会的課題を AI/ML の技術で解決したいと考えているスタートアップ
• 募集開始 : 2019 年 11 月 19 日（火）
• 募集締め切り : 2019 年 12 月 13 日（金）18 時
• 参加企業の発表 : 2020 年 2 月中旬頃を予定
• プログラム実施機関 : 2 月 中旬〜 5 月末（予定）
• 応募条件や審査など詳細はウェブサイトをご参照ください。

参加者の皆さんの応募をお待ちしております。


Posted by Takuo Suzuki - Developer Relations Team

この記事は Addy Osmani、Scott Little、Raj T - lazy な Chrome エンジニアたちによる Chromium Blog の記事 "Automatically lazy-loading offscreen images & iframes for Lite mode users" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


Chrome 76 で、イメージおよび iframe のネイティブ遅延読み込みを導入しました。これは `loading` 属性に基づいて行われ、デベロッパーによるオプトインとなります。Chrome 77 では、ライトモード（データセーバー）を有効にしている Android 版の Chrome ユーザーに対して、自動的にイメージおよび iframe のネイティブ遅延読み込みのメリットがもたらされます。

ライトモードを利用すると、ユーザーのデータ使用量を最大 60% 削減できます。削減のほとんどは、ユーザーがリクエストしたページをダウンロード前に圧縮することによって実現します。


通常、ウェブページには、下の方にあって画面に入りきらないイメージや埋め込みコンテンツが存在します。ユーザーが下までスクロールしてそういったコンテンツを表示することはほとんどありません。現在、端末はこのようなコンテンツを読み込むためにリソースを使う必要があります。データプランが限られているユーザーや、ネットワーク接続状態が悪いユーザーにとって、この点は問題です。


ユーザーが Chrome for Android でライトモードを有効にしている場合、画面外にあるイメージおよび iframe の近くにスクロールするまで、読み込みが先送りされます。これは、デベロッパーが何もしなくても実行されます。自動遅延読み込みにより、ネットワークのデータ使用量やメモリの消費量を抑えることができます。さらに、ユーザーの目に見えるコンテンツが優先されるので、サイトのスピードが上がる可能性もあります。


私たちの実験では、イメージおよび iframe のネイティブ遅延読み込みによって、1 ページあたりのダウンロード バイト数（75 パーセンタイル）が最大 10% 削減されました。また、ダウンロードされる合計バイト数（中央値）は 8% 少なくなっています。さらに、自動遅延読み込みによって First Contentful Paint（最初のコンテンツの描画）の中央値が 1～2%、First Input Delay（最初の入力までの遅延）の 95 パーセンタイルが 2%、ページあたりのメモリ削減量の中央値が 0.7% 改善されました。将来的には、さらにメリットが増えることが予想されます。


Chrome のネイティブ遅延読み込みには、先送りしたコンテンツの読み込みがどのくらいで開始されるかを表す距離しきい値があります。このしきい値はそれぞれ異なり、実質的な接続タイプなどの要素によって決まります。この距離は、コンテンツが見えるようになるまでにほぼ読み込みが完了するように選ばれます。


`loading` 属性の値が `auto` に設定されている <iframe> や <img> にも、ライトモードの自動遅延読み込みが適用されます。<picture> 要素や CSS の背景画像も含まれます。


重要な点として、イメージおよび iframe の自動遅延読み込みは、ライトモードを有効にしているユーザーのみに適用されることを覚えておいてください。ライトモードは、接続環境が悪い地域や、接続に多額の費用がかかる地域で多用されています。この機能によって特にメリットを受けることができるのは、そういった地域のユーザーであると確信しています。ライトモードをオンにしているユーザーの割合を知りたい場合は、アナリティクスの SaveData JavaScript API から近似値をモニタリングできます。

ライトモードを有効にするには、[Settings] > [Lite mode] を選択し、設定をオンに切り替えます。この機能によってユーザーのページ読み込みが少しばかり軽くなることを期待しています。

Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Chrome セキュリティ チーム、Emily Stark、Carlos Joan Rafael Ibarra Lopez による Chromium Blog の記事 "No More Mixed Messages About HTTPS" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


本日は、Chrome で https:// ページが安全な https:// サブリソースのみを読み込むようにする対応が徐々に始まることをお知らせします。以下で説明する一連の手順により、デフォルトで Mixed Contents（混在コンテンツ = https:// ページに安全でない http:// サブリソースがあるコンテンツ）がブロックされるようになります。この変更が行われると、ウェブでのユーザーのプライバシーとセキュリティが改善され、ブラウザでわかりやすいセキュリティ UX を提供できるようになります。

HTTPS への移行において、ウェブはここ数年間で大きな進展を遂げています。現在、すべての主要なプラットフォームで、Chrome ユーザーのブラウズ時間の 90% 以上で HTTPS が使用されています。そのため、私たちは、ウェブ全体の HTTPS 設定が安全かつ最新のものになることに注意を向けつつあります。

HTTPS ページでは Mixed Contents と呼ばれる問題がよく発生します。これは、ページのサブリソースが安全ではない http:// で読み込まれることを指します。ブラウザはデフォルトで、スクリプトや iframe などのさまざまなタイプの Mixed Contents をブロックします。しかし、イメージ、オーディオ、動画は依然として読み込みが許可されており、それがユーザーのプライバシーとセキュリティを脅かしています。たとえば、攻撃者は株価の混合イメージを改ざんして投資家をだましたり、混合したリソースを読み込む際にトラッキング用の Cookie を送り込んだりすることができます。Mixed Contents を読み込むと、ページが安全とも安全でないとも言えない中間状態となるので、ブラウザのセキュリティ UX にも混乱が起こります。

Chrome 79 から開始される一連の手順を通して、 デフォルトですべての Mixed Contents がブロックされるように徐々に移行されます。サイトの表示の問題を最低限にとどめるため、混合したリソースを https:// に自動アップグレードします。これにより、サブリソースが https:// でも利用できるようになっている場合、サイトはそのまま動作します。ユーザーは、特定のウェブサイトで Mixed Contents のブロックをオプトアウトする設定を行える予定です。のちほど、Mixed Contents の検出と修正に役立つデベロッパー向けリソースを紹介します。

タイムライン

一度にすべての Mixed Contents をブロックするのではなく、一連の手順を通して段階的に変更をロールアウトします。

• 2019 年 12 月に Stable チャンネルにリリースされる Chrome 79 では、新しい設定を導入し、特定のサイトで Mixed Contents のブロックを解除できるようにする予定です。この設定は、スクリプトや iframe など、現在 Chrome がデフォルトでブロックしている Mixed Contents に適用されます。ユーザーは、https:// ページに表示される鍵アイコンをクリックし、さらに [Site Settings] をクリックすることで、この設定を切り替えることができます。このアイコンは、アドレスバーの右側に表示される盾アイコン（以前のバージョンの PC 向け Chrome で Mixed Contents のブロック解除に使うもの）に代わって表示されます。

• Chrome 80 では、オーディオと動画の混合したリソースが https:// に自動アップグレードされます。https:// での読み込みに失敗した場合、デフォルトでこれらのリソースはブロックされます。Chrome 80 は、2020 年 1 月に早期リリース チャンネルにリリースされる予定です。影響を受けるオーディオと動画のリソースは、上記の設定でブロック解除できます。
• また、Chrome 80 では混合したイメージの読み込みは許可されますが、その場合、アドレスバーに「Not Secure」チップが表示されます。これはユーザーにとって明確なセキュリティ UI になり、ウェブサイトでイメージを HTTPS に移行するきっかけにもなるはずです。デベロッパーは、コンテンツ セキュリティ ポリシー ディレクティブの upgrade-insecure-requests または block-all-mixed-content を使ってこの警告を避けることができます。次のような表示が行われる予定です。

• Chrome 81 では、混合したイメージが https:// に自動アップグレードされます。https:// での読み込みに失敗した場合、デフォルトでこれらのリソースはブロックされます。Chrome 81 は、2020 年 2 月に早期リリース チャンネルにリリースされる予定です。

デベロッパー向けリソース

デベロッパーの皆さんは、警告やサイトの表示の問題を避けるため、ただちに Mixed Contents を https:// に移行してください。次のようなリソースが利用できます。

• サイトの Mixed Contents の検出と修正を行うには、コンテンツ セキュリティ ポリシーや Lighthouse の Mixed Contents 監査を利用します。
• サーバーを HTTPS に移行するにあたっての一般的なアドバイスは、こちらのガイドから参照できます。
• CDN やウェブホスト、コンテンツ管理システムをチェックし、Mixed Contents をデバッグできる特別なツールがあるかを確認します。たとえば Cloudflare は、Mixed Contents を https:// に書き換えるツールを提供しています。また、WordPress のプラグインも利用できます。

Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Chrome およびウェブ プラットフォーム パートナーシップ、Barb Palser による Chromium Blog の記事 "Developers: Get Ready for New SameSite=None; Secure Cookie Settings" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


5 月に Chrome から Cookie をデフォルトで安全な状態にするモデルについてお知らせしました。これは、新しい Cookie 分類システム（仕様）によって実現されます。この取り組みは、ウェブのプライバシーとセキュリティを改善するための継続的な作業の一部です。
Chrome は、2020 年 2 月の Chrome 80 でこの新しいモデルを実現する予定です。Mozilla と Microsoft も、それぞれのタイムラインでこの新しいモデルを Firefox と Edge に実装する予定であることを表明しています。Chrome の変更はまだ数か月先のことですが、Cookie を管理しているデベロッパーの皆さんはすぐに準備状況を評価することが重要です。本ブログ投稿では、大まかな考え方について説明します。デベロッパー向けのガイダンスについては、web.dev の SameSite Cookie の説明をご覧ください。

クロスサイトおよび同一サイトの Cookie コンテキストを理解する

広告、お勧めコンテンツ、サードパーティ製ウィジェット、ソーシャル メディアの埋め込みなどの機能を実現するため、ウェブサイトに外部サービスが組み込まれることがよくあります。ウェブサイトをブラウジングすると、こういった外部サービスが皆さんのブラウザに Cookie を保存し、のちほどその Cookie にアクセスしてユーザーに応じた内容を表示したり、エンゲージメントを計測したりすることがあります。すべての Cookie には、ドメインが関連付けられています。Cookie に関連付けられたドメインが外部サービスに一致し、ユーザーのアドレスバーに表示されているウェブサイトには一致しない場合、クロスサイト（すなわち「サードパーティ」）コンテキストと見なされます。

わかりにくいクロスサイトの例として、複数のウェブサイトを所有するエンティティが複数のサイトをまたぐ Cookie を使う場合などがあげられます。この場合、Cookie とウェブサイトは同じエンティティが所有しています。しかし、Cookie のドメインがその Cookie にアクセスするサイトのドメインと一致しなければ、クロスサイトすなわち「サードパーティ」コンテキストという扱いになります。

ウェブページの外部リソースがサイトのドメインに一致しない Cookie にアクセスする場合、クロスサイトすなわち「サードパーティ」コンテキストとなる。

一方、Cookie のドメインがユーザーのアドレスバーに表示されているウェブサイトのドメインと一致する場合は、同一サイト（すなわち「ファースト パーティ」）コンテキストによる Cookie アクセスとなります。同一サイトの Cookie は、個々のウェブサイトでログイン状態を維持する、ユーザー設定を保存する、サイトのアナリティクスを行う、といった目的でよく使用されています。

 

ウェブページ上のリソースがアクセスする Cookie が、ユーザーの訪問先サイトと一致する場合、同一サイトすなわち「ファースト パーティ」コンテキストとなる

Cookie のセキュリティと透過性を実現するための新しいモデル

現在のところ、Cookie がファースト パーティ コンテキストからのみアクセスできるようにする場合、デベロッパーは 2 つの設定（SameSite=Lax または SameSite=Strict）のいずれかを選んで外部アクセスを防ぐことができます。しかし、この推奨手法に従っているデベロッパーはほとんどおらず、大多数の同一サイト Cookie はクロスサイト リクエスト フォージェリ攻撃などの脅威に不要にさらされています。

そこで、ウェブサイトとユーザーを保護するため、デフォルトで安全な状態にする新しいモデルでは、明示的な指定がない限り、すべての Cookie を外部アクセスからの保護対象と見なします。デベロッパーは新しい Cookie 設定 SameSite=None を使い、Cookie をクロスサイト アクセスの対象として指定する必要があります。SameSite=None 属性が存在する場合は、クロスサイト Cookie に HTTPS 接続のみでアクセスできるように、Secure 属性も追加する必要があります。これでクロスサイト アクセスに関連するすべてのリスクが緩和されるわけではありませんが、ネットワーク攻撃に対する保護は実現できます。

このようにクロスサイト Cookie を明示的に宣言すると、すぐにセキュリティを向上できるだけでなく、透過性が高まり、ユーザーの選択肢も増えます。たとえば、1 つのサイトからアクセスされる Cookie と複数のサイトからアクセスされる Cookie を分けて管理するなど、ブラウザで Cookie の細やかな制御を行えるようになります。

Chrome は 2020 年 2 月より新しいモデルを適用

2 月の Chrome 80 以降、SameSite 値が宣言されていない Cookie は SameSite=Lax として扱われます。外部アクセスは、SameSite=None; Secure 設定のある Cookie のみ可能になります。ただし、これらが安全な接続からアクセスされることが条件です。Chrome プラットフォームの SameSite=None と Secure の Status Tracker は、最新のリリース情報に基づいて今後もアップデートが継続されます。

Mozilla は、Firefox でクロスサイト Cookie の SameSite=None; Secure 要件を実装する予定で、新しい Cookie 分類モデルのサポートを確約しています。Microsoft は先日、Microsoft Edge 80 より試験運用版としてこのモデルの実装を開始する計画を発表しました。

準備方法と既知の複雑なケース

クロスサイト Cookie を管理している方は、Cookie に SameSite=None; Secure 設定を適用する必要があります。ほとんどのデベロッパーは簡単な実装で済むはずです。しかし、以下のような複雑なケースや特殊なケースを判別するため、すぐにテストを開始することを強くお勧めします。

• 現時点で、すべての言語やライブラリが None 値をサポートしているわけではありません。サポートされていない場合は、デベロッパーは直接 Cookie ヘッダーを設定する必要があります。こちらの Github リポジトリには、さまざまな言語、ライブラリ、フレームワークで SameSite=None; Secure を実装する手順が示されています。
• 特定のバージョンの Chrome、Safari、UC Browser など、一部のブラウザは None 値を意図しない方法で処理する可能性があります。その場合、デベロッパーはそのようなクライアント向けに例外処理をコーディングする必要があります。これには、古いバージョンの Chrome が提供している Android の WebView も含まれます。既知の互換性のないクライアントの一覧はこちらです。
• アプリ デベロッパーは、None 値と互換性のある Chrome のバージョンに基づいて Android WebView 用に適切な SameSite Cookie 設定を宣言するようにします。これは、HTTP（S）ヘッダーを通してアクセスされる Cookie と、Android WebView の CookieManager API を通してアクセスされる Cookie の両方について行う必要があります。ただし、新しいモデルによって Android WebView が影響を受けるようになるのはまだ先のことです。
• シングル サインオンなどのサービスや社内アプリケーションが 2 月のリリースに対応できない場合、企業の IT 管理者が特別なポリシーを実装し、Chrome ブラウザを一時的に以前の動きに戻す必要があるかもしれません。
• ファースト パーティ コンテキストとサードパーティ コンテキストの両方でアクセスする Cookie がある場合、ファースト パーティ コンテキストで別の Cookie を使って SameSite=Lax によるセキュリティのメリットを得ることを検討してください。

SameSite Cookie の説明には、前述の状況についての具体的なガイダンスや、問題や質問を送信できるチャンネルが記載されています。

管理しているサイトや Cookie に対する Chrome の新しい動作の影響をテストしたい場合は、Chrome 76 以降で chrome://flags を開き、試験運用版機能である [SameSite by default cookies] と [Cookies without SameSite must be secure] を有効にします。また、一部の Chrome 79 ベータ版ユーザーは、これらの試験運用版機能が自動的に有効になります。試験運用版機能を有効にしたベータ版ユーザーによっては、新しいモデルをまだサポートしていないサービスによって互換性に関する問題が起きることがあります。ユーザーは、chrome://flags に移動してベータ版の試験運用を無効にすることで、対象の機能をオプトアウトできます。

同一サイト コンテキストのみでアクセスされる Cookie（同一サイト Cookie）を管理している場合、何もする必要はありません。SameSite 属性がない、または値が設定されていない場合でも、Chrome は外部エンティティからこれらの Cookie へのアクセスを自動的にブロックします。ただし、すべてのブラウザがデフォルトで同一サイト Cookie を保護するとは限らないため、適切な SameSite 値（Lax または Strict）を設定し、デフォルトのブラウザの動作に依存しないことを強くお勧めします。

最後に、皆さんのウェブサイトにサービスを提供しているベンダーなどの対応を懸念している方へお伝えします。必要な設定が行われていないクロスサイト Cookie がページに含まれる場合、Chrome 77 以降のデベロッパー ツールのコンソールに次の警告が表示されます。この警告を確認してください。



2 月の Chrome 80 のリリースまでの数か月間で必要な変更を実装するプロバイダ（一部の Google 製サービスを含む）もあります。対応状況を確認するために、パートナーに連絡してみるのもよいでしょう。

Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Nadine Sundquist による Google Ads Developer Blog の記事 "Video and Channel IDs Change in AdWords API, Google Ads API, and Google Ads Scripts Starting November 15, 2019" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


データ保持ポリシーの変更により、AdWords API、Google Ads API、Google 広告スクリプトは、2019 年 11 月 15 日以降、削除された YouTube のチャンネルと動画に対して null ID 条件を返すようになります。特定の広告グループ用に条件自体は残りますが、その条件で動画 ID やチャンネル ID を参照すると null が返されます。

• AdWords API v201809 では、レポーティングにおいて null 値はダッシュ 2 つ（--）として返されます。
• Google Ads API では、null 値は NULL 値として返されます。
• Google 広告スクリプトでは、null 値は JavaScript の null 値として返されます。

以下の項目を使っている場合は、コードをアップデートしてください。

AdWords API	Google Ads API	Google 広告スクリプト
YouTubeVideo.videoId	YouTubeVideoInfo.video_id	YouTubeVideo.getVideoId()
YouTubeChannel.channelId	YouTubeChannelInfo.channel_id	VideoYouTubeVideo.getVideoId()
CAMPAIGN_CRITERIA_REPORT の Criteria		Media.getYouTubeVideoId()
CRITERIA_PERFORMANCE_REPORT の Criteria
SHARED_SET_CRITERIA_REPORT の Criteria

コードをアップグレードする際に疑問に思うことがありましたら、フォーラムからご連絡ください。

Google Ads API チーム、Nadine Sundquist


Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team

この記事は Ben Karl による Google Ads Developer Blog の記事 "Python 2 Deprecation in Google Ads API Client Library" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


2019 年 7 月 11 日に、AdWords/Google アド マネージャー Python クライアント ライブラリの Python 2 サポートが終了し、非推奨となりました。以前にお知らせした計画の一環として、2019 年 11 月中旬には Google Ads Python クライアント ライブラリのサポートも終了します。

Google Ads Python クライアント ライブラリのバージョン 4.0.0 がリリースされたタイミングで、Python 2 および 3.6.0 以前の Python 3 のサポートは正式に終了します。

Google Ads Python クライアント ライブラリを使っている方は、以下の点に注意してください。

• 既にバージョン 3.6.0 以降の Python を使っている方は、Google Ads クライアント ライブラリを 4.0.0 にアップグレードできます。その他のアクションは必要ありません。そうでない方は、バージョン 3.6.0 以降の Python にアップグレードするまでバージョン 4.0.0 にアップグレードしないでください。
• バージョン 4.0.0 では、v1_3 などの以前の API バージョンも引き続きサポートされますが、Python 2 との互換性に関連するクライアント ライブラリの問題はサポートされなくなります。たとえば、Python 2 ユーザーでしか発生しないバグの修正を行うためにバージョン 4.0.1 がリリースされることはありません。

Python 3 への移行について質問がある方は、Google 広告クライアント ライブラリ リポジトリの Issue ページに送信してください。一般的な API サポートについては、Google Ads API フォーラムでお尋ねください。

Google Ads API チーム、Ben Karl

Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team

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


既にお知らせしているように、2019 年 10 月 14 日以降、AdWords API、Google Ads API、Google 広告スクリプトで共有予算、検索キャンペーン、ショッピング キャンペーンの広告配信の集中化が利用できなくなります。

すべてのデベロッパーは、サポート終了のお知らせを確認してください。このお知らせは最近改訂され、変更後に返されることが想定されるエラーコードについての最新情報が追加されています。

質問がある方は、遠慮なく AdWords API および Google Ads API フォーラムか Google 広告スクリプト フォーラムからお知らせください。

Adam Ohren（Google Ads API チーム）

Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team

この記事はサイト分離者、Alex Moshchuk、Łukasz Anforowicz による Chromium Blog の記事 "Recent Site Isolation improvements" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 



2018 年 7 月、私たちは Chrome で Site Isolation をリリースしました。Site Isolation は、Spectre のようなサイドチャネル攻撃のリスクからパソコンのブラウザを保護する手法です。先日、このリリースのメリットについて取り上げた USENIX Security カンファレンス論文を発表しました。本日は、Chrome 77 でロールアウトした以下の改善についてお知らせします。

• Chrome for Android で、ユーザーがパスワードを入力するサイトの分離が可能になりました。
• PC プラットフォームの Site Isolation は、サイドチャネル攻撃だけでなく、完全に侵害されたレンダラー プロセスからの攻撃に対する保護にも対応しました。

Android の Site Isolation

Chrome 77 では、Android ユーザーが Site Isolation とそれによるメリットを得られるようになりました。パソコンでの Site Isolation と同様に、このリリースでも OS のプロセスを活用して、攻撃者が他のウェブサイトからデータを盗むのを難しくしています。特に、この仕組みは Spectre のような CPU 脆弱性に対する保護に抜群の効果を発揮します。

私たちは、Android のようなリソースに制約のある環境で、Site Isolation がユーザー エクスペリエンスに悪影響を及ぼさないようにしたいと考えました。そのため、すべてのサイトを分離する PC プラットフォームとは異なり、Android 版 Chrome の Site Isolation はスリム化され、保護対象のサイトを少なくしてオーバーヘッドを低く抑えています。具体的には、ユーザーがパスワードを使ってログインする重要なサイトでのみ、Site Isolation が有効になります。これにより、ユーザーが心配するプライベートなデータを扱うサイト（銀行やショッピングなど）を保護しつつ、そこまで重要でないサイトではプロセスの共有を許可しています。

Chrome がウェブサイトでのパスワードのやり取りを検出すると、次回以降そのサイトにアクセスしたときに Site Isolation で保護されるようになります。その結果、サイトは他のサイトから切り離され、専用のレンダラー プロセスでレンダリングされます。他のサイトに移動すると、タブのプロセスが切り替わります。また、クロスサイト iframe は別のプロセスで処理され、「プロセス外 iframe」となります。Chrome は端末のローカルに分離されたサイトのリストを保持しています。ユーザーが閲覧履歴などのサイトデータを削除すると、リストもクリアされます。また自衛策として、Chrome モバイル ユーザーが特に頻繁にパスワードを入力しているサイトに関する、クラウドソースから取得したリストも分離します。

Site Isolation の大部分は、舞台裏で行われるアーキテクチャの変更です。これによってユーザーやデベロッパーの表示や操作が変わるべきではありません。ただし、PC プラットフォームと同様に、Chrome が作成するプロセスの数が多くなるため、パフォーマンスとのトレードオフが発生します。プラスの面は、それぞれのレンダラー プロセスが小さく短命になり、内部的な衝突も少なくなります。しかし、実際のワークロードでは、合計約 3～5% のメモリのオーバーヘッドが発生します。私たちは、Chrome の速さと安全性を保つため、懸命にこの動作の最適化を続けています。

Chrome 77 では、十分な RAM（現在は 2 GB）を搭載した Android 端末ユーザーの 99%（残りの 1% は、パフォーマンスのモニタリングと改善のために保留）で、パスワードをトリガーとする Site Isolation が有効になっています。私たちはこの機能を他の端末にも広げる方法を検討していますが、自分の端末で完全な保護を実現したいユーザーは、chrome://flags/#enable-site-per-process から手動で Site Isolation をオプトインすることもできます。これにより、すべてのウェブサイトが分離されるようになりますが、メモリの消費量は増加します。

将来的には、Site Isolation によって保護すべきサイトを検出するために、他の手法も追加する予定です。たとえば、ユーザーのログインを必要とせずに、ウェブサイトの運営者が任意のサイトを Site Isolation にオプトインできるようにする作業を進めています。

侵害されたレンダラーの封じ込め

PC プラットフォームでは、Chrome 77 の Site Isolation がかなり強力な攻撃からの防御に貢献しています。Site Isolation の最初のリリースでは、特定のレンダラー プロセスから任意のデータを漏洩させる Spectre のような攻撃を対象としていました。現在の Site Isolation は、メモリ破損バグや Universal Cross-Site Scripting（UXSS）のロジックエラーなどのセキュリティ バグにより、レンダラー プロセスが完全に侵害されている状況で行われる激しい攻撃にも対処できます。

たとえば、攻撃者が Chrome のレンダリング エンジンである Blink にメモリ破損バグがあることを発見し、それを悪用したとしましょう。このバグにより、Blink のセキュリティ チェックによる制約を受けることがなくなり、攻撃者はサンドボックス化されたレンダラー プロセス内で任意のネイティブ コードを実行できるかもしれません。しかし、Chrome のブラウザ プロセスはどのサイト用のレンダラー プロセスであるかを把握しているので、プロセス全体が受け取ることができる Cookie、パスワード、サイトデータを制限できます。そのため、攻撃者がクロスサイト データを盗むのははるかに難しくなります。

Chrome 77 の Site Isolation は、侵害されたレンダラー プロセスから以下のようなさまざまな種類のプライベートなデータを保護します。

• 認証: Cookie や保存されたパスワードには、対応するサイトに結び付けられたプロセスのみがアクセスできます。
• ネットワーク データ: Site Isolation はクロスオリジン読み込みブロックを使ってプロセスからプライベートなリソースタイプ（例: HTML、XML、JSON、PDF）をフィルタリングします。この点は、プロセスが Chrome のネットワーク スタックに対してオリジンを偽装しようとした場合でも変わりません。Cross-Origin-Resource-Policy ヘッダーによってラベル付けされているリソースも保護されます。
• 保存されたデータとパーミッション: レンダラー プロセスは、プロセスのサイトロックに基づき、保存されたデータ（例: localStorage）やパーミッション（例: マイク）にのみアクセスできます。
• クロスオリジン メッセージング: Chrome のブラウザ プロセスは、postMessage および BroadcastChannel メッセージのソースオリジンを検証できます。これにより、レンダラー プロセスによるメッセージ送信元の偽装を防ぐことができます。

次のようないくつかの方法を通して、侵害されたレンダラーに対する保護の改善も続けています。

• 前述の保護を Chrome for Android でも実現: これには、追加の作業を行って一部のサイトのみが分離される場合に対処することが必要です。
• CSRF に対する保護: 侵害されたレンダラーがリクエスト ヘッダー Sec-Fetch-Site および Origin を偽装するのを防ぐため、これらのヘッダーを検証できます。
• 保護対象となるデータの種類を追加: デフォルトでクロスオリジン読み込みブロックが保護するデータの種類を増やす方法を検討しています。
• 例外の削減: 保護の適用外となるケースを減らす作業を行っています。たとえば、新しいセキュリティ モデルにアップデートしていない一部の拡張機能は、現在もコンテンツのスクリプトから幅広いクロスサイト アクセスを行っています。私たちは、拡張機能の作成者と連携し、影響を受ける Chrome ユーザーの数を既に 14% から 2% にまで削減しました。さらに、その他の拡張機能のセキュリティの問題も厳格化しています。また、Flash には Site Isolation が適用されません。Flash は現在デフォルトで無効になっており、サポート終了パスの途上にあります。

この取り組みによって Chrome 全体のセキュリティ モデルが改善されるのが楽しみです。その結果、Chrome Vulnerability Reward Program のスコープを広げ、侵害されたレンダラーが関与するクロスサイト データ開示攻撃もカバーしています。Site Isolation に影響するセキュリティ バグには、期限付きで情報開示バグの通常の金額よりも高い褒賞金が提供される場合があります。これまでに寄せられたセキュリティ研究者からの貢献に感謝します。ウェブのセキュリティ状況を改善するため、さらに協力し合えることを楽しみにしています。



Reviewed by Eiji Kitamura - Developer Relations Team

Google Cloud は、インターネットサービス業界で活躍するインフラエンジニア、サーバーアプリケーションエンジニア、テクニカルリーダーの皆様に向けて、"Google Cloud INSIDE Retail" を開催します。

業界をリードする方々や、深い専門知識をもつ Google 社員より、注目インターネットサービスの開発の裏側や、Google Cloud Platform（GCP） を中心としたテクノロジーアップデートをお届けします。この Google Cloud INSIDE Retail をきっかけに、新しいサービスやプロダクトが生まれるような会へ、参加者の皆様と共に育てて行きたいと考えています。


今回は、"小売業におけるデータ活用最前線〜GCP を活用した Tech Driven な小売業の事例〜 " がテーマです。小売業界に関わるエンジニアに向けて、GCP 活用により自社のビジネスがどう変化したか、テクノロジーが与えるインパクトなどを導入済みのお客様および Google 社員がお話します。


第 2 回となる今回は、データ活用に焦点をあて、データ収集からエッジでの機械学習まで、データ分析および活用の一連のプロセスを説明します。



開催概要

• 名 称 : Google Cloud INSIDE Retail
• 日 時 : 2019 年 12 月 2 日（月） 19 : 00 - 22 : 00
• 会 場 : グーグル合同会社

        〒150-0002 東京都渋谷区渋谷 3-21-3 渋谷ストリーム

• プログラム

18 : 30 受付開始 

19:00 ～ 19:05　オープニング 

19:05 ～ 19:30　ABEJA の製品開発における GCP の活用
                            菊池 佑太 氏、株式会社ABEJA 取締役 CPO

19:30 ～ 19:55　※タイトル調整中 

                            尾崎 広幸 氏、花王株式会社 コンシューマーリレーション開発部データサイエンス室

19:55 ～ 20:20　※タイトル調整中
                            常田 秀明 氏、日本情報通信株式会社クラウドテクニカルエバンジェリスト

20:20 ～ 20:45　コードを書かないエッジでの画像解析デモ
                             ~ Cloud IoT による Edge TPU の管理方法も ~
                             唐澤 匠、Google Cloud カスタマー エンジニア 

20:45 ～ 21:00　クロージング 

21:00 ～ 22:00　懇親会

• 主 催： グーグル・クラウド・ジャパン合同会社
• 定 員：200 名
• 参加費：無料 （事前登録制）

参加申し込み


https://goo.gle/33RnX1V


上記リンクからお申し込みください。


※ 競合他社様、パートナー企業様からのお申し込みはお断りさせていただくことがございます。
※ 報道関係者のご参加はお断りさせていただきます。
※ ビジネス向けのイベントとなっております。学生の方のご参加はご遠慮ください。
※ お申し込み多数の場合は抽選を行います。参加いただける方には、後日、ご登録されたメールアドレスに参加のご案内をお送りします。



Posted by Takuo Suzuki - Developer Relations Team

この記事は副社長、CIO、最高ドメイン愛好家、Ben Fried による Google Developers Blog の記事 "Build security into your next website" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

手紙で秘密のメッセージを送りたい場合、あなたなら封筒に入れて送りますか？それとも葉書に書くでしょうか？葉書に書いて送れば、受信者に届くまでの間でその葉書を見た人は、誰でもメッセージを読むことができます。さらに、書いてあることを改ざんすることまでできてしまいます。

ウェブサイトの暗号化は封筒のようなものです。ウェブサイトとそこにアクセスするユーザーとの間で受け渡しされる情報を保護することで、のぞき見や改ざんを防ぐことに加え、サイトのコンテンツを改変したり、トラフィックの宛先を変えたり、オープンな Wi-Fi ネットワークから情報を盗んだり、不正なソフトウェアやトラッキングを行うソフトウェアを紛れ込ませたりするなど、悪意をもった者からユーザーを守ります。ウェブサイトを暗号化するには、SSL（Secure Sockets Layer）証明書のインストールが必要です。この証明書によって、ウェブサーバーとブラウザとの間で受け渡しされるデータを秘匿できるようになります。

全米サイバー セキュリティ意識向上月間（National Cyber Security Awareness Month = 元記事公開当時）が始まる今、多くのウェブサイトの所有者が気づいていない事実を強調したいと思います。それは、暗号化されていないページが 1 つあれば、それがウェブサイト全体にアクセスするために使われてしまう可能性があることです。これを避けるには、クレジット カード番号やログイン情報を収集するページだけでなく、ウェブサイト全体を暗号化する必要があります。HTTPS ページにリダイレクトするための暗号化されていないランディング ページでさえ、リスクになる可能性があります。保護されていない 1 つのページが悪意を持つ者のバックドアとなり、サイト全体がのぞき見されてしまうかもしれないのです。では、どうすればサイト全体を暗号化できるのでしょうか。


HSTS プリロードされるトップレベル ドメインを使う
HSTS プリロード リストは、暗号化された接続でしか読み込みを行えないウェブサイトの一覧をモダンブラウザに渡すものです。 最も早くこの一覧に記載される方法は、既に HSTS プリロード リストに記載されているトップレベル ドメインを使うことです。たとえば、.app、.dev、.page などがこれに当たります。これらのドメインのウェブサイトは、HSTS プリロードによるセキュリティ上のメリットをすぐに利用できます。必要な操作は、SSL 証明書のインストールだけです。

自分でウェブサイトを HSTS プリロード リストに追加する
ウェブサイトの所有者は、hstspreload.org で個別にウェブサイトを HSTS プリロード リストに追加できます。リストはブラウザに手動で組み込まれるので、この手続きには時間がかかる点にご注意ください。つまり、リストのアップデートが反映されるのは、新しいブラウザがリリースされたタイミングになります。すべてのブラウザに反映されるまで数か月かかる場合もあります。

これまで以上にウェブサイトを作る人が増えています。米国の人口の 48% にあたる人が、サイトを作ろうとしています。 新しい動画シリーズを通じて、既存のクリエイターがウェブサイトを立ち上げるためのヒントを共有します。このシリーズは、safe.page/buildsecurely からご覧いただけます。

ドメイン セキュリティ エキスパートの Stephanie Duchesneau が、ウェブサイト暗号化の重要性と HSTS プリロードのメリットについて説明します。

Reviewed by Eiji Kitamura - Developer Relations Team

Google Cloud に代表されるクラウド技術の進化が引き起こすその先の世界を、機械学習、VR / AR、IoT などの領域で活躍されているスタートアップの方々と一緒に議論するイベント「INEVITABLE ja night」。

第 11 回目となる今回は、「エッジデバイスの不可避な流れ」がテーマです。あらゆるモノがネットワークに繋がり、日々膨大なデータが生み出され、処理が行われています。こうした膨大なデータをより高速かつプライバシーに配慮した形で処理するためエッジコンピューティングが注目されています。このエッジコンピューティングを支える「エッジデバイス」。今回は、エッジデバイスの最新テクノロジーと先端事例をご紹介し、今後の潮流について議論します。

Google からは EdgeTPU や TensorFlow lite などエッジコンピューティングを支えるテクノロジーをご紹介します。

本テーマにご関心のある方々のご参加をお待ちしています。

講演会後には恒例の交流会も行います。参加者様同士の交流はもちろん、日頃の業務の課題や悩みについても、ご相談 / 共有いただける良い機会となります。

本テーマにご関心のある方々のご参加をお待ちしています。

【開催概要】
イベント名 : INEVITABLE ja night - “インターネットの次にくるもの”
　　　　　　第 11 回 エッジデバイスの不可避な流れ
日程 : 2019 年 12 月 17 日（火） 19:00 〜 21:00（開場 18:30 より）
会場 : グーグル六本木オフィス
定員 : 200 名
ハッシュタグ : #inevitableja

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

Google テクノロジーアップデート：
　　鈴木 拓生 グーグル合同会社 Developer Relations Team Program Manager
　　Johan Euphrosine グーグル合同会社 Developer Programs Engineer

ゲスト講演：
　　櫻木 伸章 氏、京セラコミュニケーションシステム株式会社
　　プラットフォーム事業部 ITインフラ技術企画課

申し込みサイト：https://goo.gle/36AecHy

多数のご参加をお待ちしております。

NEVITABLE TV のご案内

INEVITABLE TV では、イベントでは取り上げることができなかったこと、語り尽くせなかったことを中心に、「インターネットの次に来るもの」に関連する話題を深く掘り下げていきます。INEVITABLE TV からご覧ください。

Posted by Takuo Suzuki - Developer Relations Team

この記事は Varun Kumar による The AMP Blog の記事 "How Goibibo Got Started With AMP For Email – And How You Can Too" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

編集者のメモ: 以下の記事は、Goibibo のフルスタック デベロッパーである Varun Kumar 氏によって Medium に投稿されたものです。

メールは、マーケティング キャンペーン、取引における警告、お客様からの苦情への対応、一斉伝達などの通信手段として今でも好まれています。The Radicati Group Inc. によると、2019 年末までに世界のメールユーザーの数は 29 億人以上に増加します。2019 年末には、世界の人口の 3 分の 1 以上がメールを使うことになります。しかし、メールの威力をもっと高めることはできないでしょうか。エンゲージメントやインタラクティブ性を高めて、ウェブサイトを見るような感覚にはできないでしょうか。いつメールを開いても、ダイナミックなデータをリアルタイムに提供することはできないでしょうか。Inbox を閉じることなく、メールの中から情報を集めることはできないでしょうか。

もちろん可能です。AMP Project は AMP for Email を導入し、これにより上記のことがすべて実現できるようになりました。

AMP for Email はダイナミック メールとも言われていますが、いったいどんなものですか？

AMP for Email は 2018 年に AMP Project が導入した新技術で、AMP コンポーネントのサブセットをメールの中で利用できるようにすることで、メールのエンゲージメントを高めます。これは AMP Project（ユーザー ファーストなウェブ コンテンツのフォーマットを提供するオープンソース プロジェクトで、ウェブサイトの運営者、販売者、広告主のすべてに長期的な成功をもたらします）の一部であり、メールで JavaScript に似た機能を提供しています。

AMP のことは知っています

もちろんそうでしょう。しかし、 AMP for Email は AMP for HTMLとは違います。どちらもオープンソースで AMP Project の一部であるという点は同じですが、ユーザーにスムーズなメール体験を提供するため、AMP for Email のルールは AMP for HTML のルールよりも少しばかり厳しくなっています。たとえば、AMP for HTML では <input type=”file” /> によるファイルのアップロードがサポートされていますが、AMP for Email では（現時点で）サポートされていません。

なるほど。では、その仕組みはどうなっていますか？

メールは、MIME（Multipurpose Internet Mail Extension）パートで構成されています。たとえば、書式なしテキストによるメールなら text/plain、HTML メールなら text/html となります。メール クライアントが AMP for Email を認識できるようにするため、新しい MIME タイプ text/x-amp-html が導入されました。この MIME パートには、AMP HTML マークアップが含まれることになります。
ほとんどのメール送信ライブラリやメール送信サービスは、既にこの新しい MIME のサポートを始めました。たとえば、Nodemailer（node.js のメール送信ライブラリ）は、v6.1.0 でサポートが追加されました。

おもしろそうですね。実際の AMP for Email を見せてもらえますか

もちろんです。ここで紹介しているデモは、架空の企業「Beautiful Flowers Shop」がさまざまな花についてのフィードバックをお客様に求めています。

素晴らしいですね！ぜひ AMP for Email も学びたいので、詳しく教えてください

ダイナミック メールの開発には、以下の 4 つの手順が必要になります。

1. 有効な AMP for Email マークアップを準備します。これが、メールでレンダリングされるテンプレートになります。マークアップは、https://amp.gmail.dev/playground/ で検証できます。次に、サンプルの hello-world マークアップを示します。

<!doctype html>
<html 4email>
<head>
 <meta charset="utf-8">
 <script async src="https://cdn.ampproject.org/v0.js"></script>
 <style amp4email-boilerplate>body{visibility:hidden}</style>
</head>
<body>
 Hello, AMP4EMAIL world.
</body>
</html>

2. メール本文として text/x-amp-html MIME パートをサポートするメール ライブラリを準備します。node.js では、Nodemailer を利用できます。サンプルのスニペットは、こちらで公開されています。ダイナミック メールに API 呼び出しを含める場合は、CORS 要件を満たす必要があります。
公式ドキュメント:
Gmail https://developers.google.com/gmail/ampemail/security-requirements
Mail.ru https://postmaster.mail.ru/amp
Outlook https://docs.microsoft.com/en-gb/outlook/amphtml/

res.set({
'Access-Control-Allow-Origin': origin,
'AMP-Access-Control-Allow-Source-Origin': sourceOrigin,
'Access-Control-Allow-Source-Origin':
'AMP-Access-Control-Allow-Source-Origin',
'Access-Control-Expose-Headers':
'Access-Control-Allow-Origin' +
', AMP-Access-Control-Allow-Source-Origin' +
', Access-Control-Allow-Source-Origin'
});

3. Gmail でダイナミック メールをテストします。 Gmail では、Google チームが正式にホワイトリストに登録（手順 4）したメールアドレスを除き、ダイナミック メールのレンダリングは許可されません（代わりに HTML がレンダリングされます）。ただし、特定の Gmail アカウントでメールをテストする場合は、ダイナミック メール デベロッパー設定から アドレスを指定してホワイトリストに登録できます。 https://developers.google.com/gmail/ampemail/testing-dynamic-email

4. Gmail でメール（送信者アドレス）のホワイトリスト登録を行い、エンドユーザーにダイナミック メールがレンダリングされるようにします。本番環境のメールで利用する準備ができたら、登録フォームに入力して ampforemail.whitelisting@gmail.com に送信し、ホワイトリストへの登録を申請します。詳しいガイドはこちらをご覧ください。

なお、Gmail のホワイトリスト登録はドメインごとではなく、メール送信者ごとになります（sender@example.com がホワイトリストに登録されていても、@example.com のアドレス全体に適用されるわけではありません）。
最後の 2 つは、Gmail 固有の手順です。Microsoft Outlook を使っている場合は、同じような手順を実行する必要があります。Outlook の公式ドキュメントを参照してください。mail.ru の AMP for Email に関する情報は、こちらをご覧ください。

情報がありすぎて、どうすればいいのかわかりません

大丈夫です！時間をかけて進めましょう。私たち Goibibo がこの Proof of Concept (PoC) を始めたとき、ダイナミック メールを開発して個人の Gmail アカウントでテストするまでにかかったのはわずか 2 日でした。しかし、このメールの事例を実際に本番環境に対応させ、Google によるホワイトリスト登録が完了してエンドユーザーにメールを送信できるようになるまでに 2 週間以上を要しました。パートナーのホテルにダイナミック メールを送り、Extranet（価格や客室を管理するホテル経営者向けプラットフォーム）についてのフィードバックを集めるために、次のようなものを作成しました。

実際に AMP for Email を使ったのは、ホテル経営者がチェックアウトしたお客様からの「レビューに返答」できるようにする部分です。たとえば、ホテルに宿泊してチェックアウトしたお客様がレビューを残した場合、ホテル経営者はメールの中でそのレビューに返答できます。

以前は、Extranet というホテル経営者向けプラットフォームへのハイパーリンクを使ってこれを行おうとしましたが、Hoteliers（B2B）からレビューの返答を集めるための B2B メールの開封率は 14% でした。異なる状況で 2 回行った PoC では、画期的なメールの開封率を実現でき、すばらしい返答も得られました。

まとめ

AMP for Email は非常に有望です。私たち Goibibo はさらに前進し、メール キャンペーンにも採用したいと考えています。AMP API リクエストを処理するインフラストラクチャのセットアップ、メールデザイン チームやマーケティング チームのトレーニングなど、最初にいくつかの課題を乗り越える必要はありますが、最終的には素晴らしい結果が得られるに違いありません。

Reviewed by Chiko Shimizu - Developer Relations Team

この記事は Malte Ubl による The AMP Blog の記事 "AMP is joining the OpenJS Foundation incubation program" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

AMP Project を代表して、AMP が OpenJS Foundation インキュベーション プログラムに合流することをお知らせします。

AMP は、ウェブ デベロッパーが高速でユーザー フレンドリーな体験を簡単に作成できるフレームワークを提供することを目指し、4 年前にオープンソース プロジェクトとして誕生しました。私たちは、AMP を貢献者にとって心地よいコミュニティにすることを目指し、これまで約 1000 人の貢献者が AMP にコードを提供してくれました。

昨年はコミュニティと連携してガバナンス モデルの改善に取り組みました。技術面、プロダクト面での AMP の方向性にコミュニティの多様な声を反映し、多くの AMP ステークホルダーや支持者の意見を代弁したものにするためです。

ガバナンスの変更に合わせて、今後の方針として、コミュニティが新しいガバナンス モデルに適応し、AMP にふさわしい財団が見つかった際には、AMP をその財団に移管することを発表しました。そして今、そのときがやってきました。さまざまな選択肢の中から AMP のすべてのニーズを満たす財団を検討してきましたが、AMP の理想的なホームとして OpenJS Foundation が際立っていることがわかりました。

OpenJS Foundation が AMP に ふさわしい理由はいろいろありますが、代表的なものを以下に示します。

• 「ユーザー ファーストなウェブ コンテンツのフォーマット」を提供するという AMP のミッションは、「主要な JavaScript およびウェブのソリューション、その関連技術の普及と継続的な開発を推進する」という Open JS Foundation の目的とぴったり一致しています。
• OpenJS Foundation では、プロジェクト自体や技術的な指向、プロダクトの方向性に関する独自性が保たれています。一方で、資金調達の仕組みや法的なサポートなど、プロジェクトが財団に求める重要な支援サービスが提供されています。
• AMP の新しいガバナンス モデルは、Open JS Foundation の母体となった JS Foundation と Node.js Foundation という 2 つの組織のガバナンス モデルから大きな影響を受けているので、AMP と Open JS Foundation のガバナンス理念にはもとより整合性があります。

財団を探す過程や OpenJS Foundation を選択した理由の詳細については、本日、AMP アドバイザリー コミッティ メンバーの Tobie Langel 氏および OpenJS Foundation のエグゼクティブ ディレクターである Robin Ginn 氏が AMP Contributor Summit で行うプレゼンテーションをご覧ください。

先日には、AMP のテクニカル ステアリング コミッティとアドバイザリー コミッティの承認のもと、AMP は OpenJS Foundation のプロジェクト提案プロセスを開始しました。そして、OpenJS Foundation の Cross Project Council（CPC）は、提案のレビューを経て、AMP を財団のインキュベーション プログラムとして受け入れました。今後数か月間のうちに、AMP は OpenJS Foundation と連携してオンボーディング チェックリストを完了させ、財団に合流する予定です。

Google は今後も AMP を強力にサポートします。Google は既に OpenJS Foundation のプラチナ メンバーになっています。AMP のコミュニティやエコシステムの繁栄を確かなものにするため、これからも金銭面を含めたサポートを続けます。AMP オープンソース プロジェクトの専任として貢献している Google 社員のチームも継続します。

インキュベーション フェーズ以降、さまざまな OpenJS Foundation コミュニティと連携し、オープンで持続可能なウェブを維持できることを楽しみにしています。

Malte Ubl（AMP テクニカル ステアリング コミッティを代表して）



Reviewed by Chiko Shimizu - Developer Relations Team

この記事は Chrome OS team による Medium Blog の記事 "Optimizing Android app experiences for Chrome OS" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

初めての Chrome OS 搭載 2-in-1 タブレットのリリースから、日本やドイツといった新たな市場での Chromebook の発売まで、Google では、Chrome OS デバイスのエコシステムを今日のアプリユーザーにもフィットするよう開発を進めてきました。画面が大きく多様なフォーム ファクタのデバイスでアプリを使用するユーザーはますます増えており、このような増大する新しいニーズにも柔軟に対応できるエコシステムを構築しています。

Android は、タブレット、折りたたみ式デバイス、Chrome OS 搭載のラップトップなど、その形態が常に進化する大画面デバイスを支えています。特に Chromebook はコンテナ内で Android フレームワーク全体を実行するため、ほとんどの Android アプリは Chrome OS 上で実行されます。つまり、1 つの Android APK をあらゆる Chrome OS デバイスで動作するように拡張することで、画面の大きいデバイスでより没入感の高い魅力的なエクスペリエンスを実現できます。

1 つの Android APK をあらゆる Chrome OS デバイスで動作するように拡張し、画面の大きいデバイスでより没入感の高い魅力的なエクスペリエンスを実現することができます。

昨年、Chrome OS 上での Android アプリの使用時間は 4 倍に増加しました¹。さらに、2018 年の第 4 四半期に米国で販売されたノートパソコンのうち 21% が Chromebook で、前年比の伸び率は 23% でした。²。

Chrome OS 向けにエクスペリエンスを最適化するには、わずかな調整を行うだけです。しかしこのわずかな調整が大きな効果をもたらします。一例として、大きい画面向けにアプリを最適化した Gameloft と TopHatch の成功事例をご紹介しましょう。Gameloft の「Asphalt 8: Airborne」では 1 日あたりのアプリユーザー数が 6 倍に、Chrome OS デバイスの収益は 9 倍に増加し、TopHatch のアプリ「コンセプト」では Chromebook での有料コンバージョン数が 2 倍に、Pixelbook でのアプリ利用時間は 20 倍にも増加しました。

今年の I/O では、アプリのデザインと動作をさまざまなフォーム ファクタや画面サイズに対応させるためのおすすめ方法を、いくつかのステップに分けて説明しました。以下に、Android デベロッパー向けのおすすめの方法、および Chrome OS に関する最新情報をご紹介します。

アプリのエクスペリエンスを Chrome OS 向けに最適化する

アプリの使い方は、ユーザーが使用するデバイスによって異なります。アプリで最適なユーザー エクスペリエンスを提供できるようにするには、以下の点を考慮する必要があります。

キーボード入力

アプリがキーボードをサポートしていない場合は、次のコードで実装できます。（ソースはこちら）

ハイライト表示されている部分では、使用されないキーを super に渡しています。これにより、Chrome OS は、割り当てがない各キーの機能を無効にすることなく必要なコマンドを処理できます。

更新キー

Chrome OS のキーボードには独自のキーコード（KEYCODE_REFRESH）を持つ更新用のキーがあるため、アプリで KEYCODE_REFRESH イベントを処理できるようにする必要があります。すでに SwipeRefreshLayout を使用している場合は、この更新キーを押すと Chrome OS によりレイアウトが自動的に更新されるようになります。

タッチパッド

ユーザーがタッチパッド搭載のパソコンでアプリを使用している場合、スクロール操作にタッチパッドを 2 本の指でスワイプすることが予想されます。一方モバイルの場合、通常、画面を押したままドラッグしてスクロールします。Chrome OS は、このようなタイプの異なるモーション イベントを自動的に解釈します。そのため、たとえば図形描画アプリの場合、モバイルでスクロールしたときに描画されることはありません。

より高度なタッチ モーション イベントが必要なアプリでは、(event.getButtonState() == 0) のときは MotionEvents を無視する設定にすることで、ボタンの状態を確認し、（上記の図形描画アプリの例のように）不要なイベントを無視できるようになります。

NDK

Chrome OS 上のゲームとアプリは、ARM から x86 への変換が自動的に実行されます。ただし、パフォーマンスを優先する場合は x86 のサポートが不可欠です。主要な Chrome OS デバイスのほとんどが 64 ビット x86 チップセットを搭載しており、こうしたデバイスは今後ますます増えていくと思われます。すべてのデバイスで最適なパフォーマンスを提供できるよう、ネイティブ コードを使用する場合は、ARM、ARM64、x86、x86_64 をビルド対象にするようにしてください。

Android Studio ではこの手順を簡単に実装できます。Android App Bundle を使用すれば、すべてのビルド対象を Play ストア向けにパッケージ化して、アプリユーザーが必要なビルド対象のみを送信することができ、ダウンロード サイズを最小限に抑えられます。

レイアウト

大きな画面での使用を考慮して設計されていないモバイルアプリは、無駄なスペースが多かったり、ナビゲーションがぎこちなかったりします。皆さんもおそらく目にしたことがあるでしょう。レイアウトが変わってもアプリが最適な形で表示されるようにするには、1 つのリソース ファイルに、各画面サイズに対応するレイアウト バケットを複数用意します。

ナビゲーション パターン

さらに、アプリはどのような画面サイズでも使いやすくなければなりません。利用可能な画面の幅に応じて、下部ナビゲーション、サイド ナビゲーション、展開状態のサイド ナビゲーションのパターンを切り替えることで、縦向き、横長の縦向き、横向きのレイアウトを作成できます。

メールアプリの Reply は、画面サイズに応じて機能や使いやすさが調整されるようレイアウトが再設計されています。また、Adobe Acrobat では、Chrome OS 向けにアプリの機能を最適化する一方、さまざまなデバイスに対応するためレイアウト全体を設計し直しました。

マルチウィンドウ

複数のウィンドウを使用する場合、一般にそれぞれの画面では密度が異なります。Chrome アクティビティ内の onConfigurationChanged で「density」の変化をリッスンすることで、アプリの密度を瞬時に変更できます。

Chromebook での開発に関する最新情報

I/O では、Chrome OS に加えられたその他の改良点についてもご紹介しました。いずれの変更も、ウェブアプリと Android アプリのデベロッパーが、Chrome OS のスピード、シンプルさ、セキュリティというメリットを活かせるようにするためのものです。

Android Studio のワンクリック インストール

Android Studio を、ダウンロードしてクリックするだけでインストールできるようになりました。もうターミナルを使用する必要はありません。

USB デバッグに対する ADB の改良

サポートされているデバイスでは、デベロッパー モードを使用しなくても、スマートフォンを接続するだけで USB 経由でデバッグできるようになりました。

lint チェック

画面の向きが不適切またはロックされている、アクティビティのサイズを変更できない、ハードウェア要件に誤りがあるなど、Chrome OS に適さない機能が検出されます。

Linux でのオーディオ再生

Chrome OS コンテナでは、Audacity などの Linux 対応オーディオ ツールすべてをサポートします。

仮想デスクトップ

最新の Stable チャネルである M76 のフラグにより、複数のウィンドウやさまざまなプラットフォーム ユースケースが原因で画面が動作しなくなったときに、仮想デスクトップをオンにできるようになりました。

マルチモニター / HDCP の完全サポート

DRM で保護された動画コンテンツを外部モニターに映して視聴できます。
*この機能を利用するには、SurfaceView.setSecure() を使用します。

ARCore の統合

World Facing カメラを使用して、アプリで ARCore を利用できます。

Instant App のサポート

Android P デバイスのユーザーは、アプリやゲームをインストールせずに試すことができます。

Android アプリ用の外部ストレージ

Android アプリで外付けディスクの読み取りおよびスキャンができます。

Play ファイル

Chrome OS のファイル マネージャーで、Play ファイルの下位にある Android の /sdcard フォルダを表示できます。これにより、Chrome コンテナから Android ファイルの読み取りと書き込みができるようになりました。

Android Cloud ストレージでの DocumentsProvider およびドキュメント プロバイダ カスタムアプリのサポート

Chrome OS で Android DocumentsProvider インターフェースをサポートするようになりました。

アプリのプロファイリングによるアニメーション ジャンクの検出

統合されたプロファイリング ツールを使用して、システムの状態（バッファの使用状況、垂直同期、CPU の使用状況、GPU と CPU の周波数、システムの温度など）を経時的にモニタリングし、アニメーションのジャンクやシステムの速度低下の原因を確認できます。

あらゆる画面で最適なエクスペリエンスを提供する

アプリの利用場面は、今やモバイルにとどまりません。デバイスとフォーム ファクタの多様化が進む現在、ユーザーにとって、アプリは設計が優れていていつでも使いやすいことが当然の前提となりつつあります。この機会に、さまざまな入力方法のサポート、画面サイズに応じたレイアウトやナビゲーションの最適化、追加の画面領域の活用、ネイティブ コードでの x86 のサポートなどに対応しましょう。

Chrome OS 向け Android アプリの開発についてさらに詳しく知りたい方は、2019 年の I/O で開催したセッションの動画をご覧ください。

出典

¹ Google 内部データ（2018 年 3 月～2019 年 3 月）。
² The NPD Group, Inc.、リテール トラッキング サービス、米国、ノートパソコン、Chrome OS、ユニットベース、2017 年 10 月 8 日～2018 年 1 月 6 日と 2018 年 10 月 7 日～ 2019 年 1 月 5 日の比較。

Posted by Yuichi Araki - Developer Relations Team