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




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 テクニカルアカウントマネージャ



Reviewed by Eiji Kitamura - Developer Relations Team

  • 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

ウェブページの外部リソースがサイトのドメインに一致しない 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 設定を適用する必要があります。ほとんどのデベロッパーは簡単な実装で済むはずです。しかし、以下のような複雑なケースや特殊なケースを判別するため、すぐにテストを開始することを強くお勧めします。
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
Share on Twitter Share on Facebook

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

Google Ads API チーム、Nadine Sundquist


Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team
Share on Twitter Share on Facebook


Google Ads API チーム、Ben Karl

Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team
Share on Twitter Share on Facebook


Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team
Share on Twitter Share on Facebook


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


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


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


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



開催概要

        〒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　懇親会



参加申し込み


https://goo.gle/33RnX1V


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


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



Posted by Takuo Suzuki - Developer Relations Team
Share on Twitter Share on Facebook


Reviewed by Eiji Kitamura - Developer Relations Team
Share on Twitter Share on Facebook


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

Share on Twitter Share on Facebook

素晴らしいですね！ぜひ 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 でメール（送信者アドレス）のホワイトリスト登録を行い、エンドユーザーにダイナミック メールがレンダリングされるようにします。本番環境のメールで利用する準備ができたら、登録フォームに入力して [email protected] に送信し、ホワイトリストへの登録を申請します。詳しいガイドはこちらをご覧ください。
なお、Gmail のホワイトリスト登録はドメインごとではなく、メール送信者ごとになります（[email protected] がホワイトリストに登録されていても、@example.com のアドレス全体に適用されるわけではありません）。
最後の 2 つは、Gmail 固有の手順です。Microsoft Outlook を使っている場合は、同じような手順を実行する必要があります。Outlook の公式ドキュメントを参照してください。mail.ru の AMP for Email に関する情報は、こちらをご覧ください。

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

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



ダイナミック メールで Gmail の Inbox を閉じることなくフィードバックを収集

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

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






まとめ

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

Reviewed by Chiko Shimizu - Developer Relations Team
Share on Twitter Share on Facebook


初めての 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


Share on Twitter Share on Facebook