Local blog for Japanese speaking developers
Cloud Firestore のクエリが遅くなる理由
2019年10月28日月曜日
この記事は Todd Kerpelman(Developer Advocate) による The Firebase Blog の記事 "
Why is my Cloud Firestore query slow?
" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Cloud Firestore のパフォーマンスについては、「ベースのデータセットではなく結果セットのサイズに比例して高速化する」、「低速のクエリを作成するのは実質的に不可能だ」など、その素晴らしさを評価する声がよく聞かれます。そしてほとんどの場合、それは事実です。アプリでは莫大な数のレコードが格納されたデータセットに対するクエリを実行し、ユーザーが画面から親指を離すよりも早く結果を取得できます。
とは言え、デベロッパーからは「特定の状況では Cloud Firestore の動作が遅く感じられ、クエリの結果を取得するのに予想よりも時間がかかる」という意見を聞くこともあります。それはなぜでしょうか。今回は、Cloud Firestore の動作が遅くなったように見える場合に考えられる原因と、その対処方法をご紹介します。
理由その 1: データが多すぎる
クエリが遅くなったと感じる場合に第一に考えられる原因としてクエリ自体は非常に高速に実行されているのですが、クエリが完了した後にすべてのデータをデバイスに転送する必要があり、実際にはその処理に時間がかかっているのです。
たとえば、組織内の全営業担当者を対象にしたクエリを実行するとしましょう。このクエリは非常に高速に実行されます。しかし、その結果セットが 2,000 人の従業員のドキュメントで構成されていて、各ドキュメントに 75 KB のデータが含まれていたらどうでしょう。デバイスでは 150 MB のデータをダウンロードする必要があり、それが完了するまで結果は確認できません。
パフォーマンスを改善するには
この問題を解決するには、必要なデータ以外は転送しないようにするとよいでしょう。簡単なのは、クエリに制限を追加する方法です。従業員リストの結果のうち、ユーザーが必要なのは先頭のごく一部だけだと思われる場合は、クエリの最後に limit(25) を追加すれば、最初の方のデータのみダウンロードされ、その他のレコードはユーザーがリクエストした場合に限りダウンロードされるようにすることができます。これについては
こちらの動画
で詳しく説明していますので、ぜひご覧ください。
一方、営業担当者 2,000 人全員のデータをクエリで取得する必要があると考える場合は、別の方法があります。最初のクエリで取得したいデータのみを含むドキュメントをこれらのレコードから分離し、その他の詳細なデータを含むドキュメントは個別のコレクションまたはサブコレクションにまとめるのです。後者のドキュメントは最初の取得時には転送されませんが、ユーザーの必要に応じて後からリクエストできます。
ドキュメントのサイズを小さくすると他にもメリットがあります。たとえば、クエリにリアルタイム リスナーを設定して、ドキュメントが更新されるとそのドキュメントがデバイスに送信されるようにしたい場合です。ドキュメントのサイズを小さくしておけば、リスナーで変更が発生するたびに転送されるデータの量も少なくなります。
理由その 2: オフライン キャッシュが大きすぎる
Cloud Firestore のオフライン キャッシュはとても優れた機能です。オフラインの永続性を有効にすると、ユーザーがトンネル内に入ったときや飛行機に 9 時間乗っている間でも、アプリはオンラインと「同じように機能」します。つまり、オンライン中に読み取ったドキュメントをオフラインでも利用でき、オフライン中に書き込んだデータは、アプリがオンラインに戻るまでローカルでキューに追加されます。さらに、クライアントの SDK ではこのオフライン キャッシュを利用して、大量のデータがダウンロードされないようにすることができるため、ドキュメントの書き込みなどのアクションを高速化できます。ただし Cloud Firestore は「オフライン優先」のデータベースとして設計されているわけではないので、今のところローカルでの大量のデータの処理には向いていません。
Cloud Firestore はクラウド内で、すべてのコレクションの全ドキュメントとそのフィールドをもれなくインデックスに登録しますが、（現時点では）オフライン キャッシュ用にこうしたインデックスを作成することはありません。つまり、オフライン キャッシュ内のドキュメントにクエリを実行する場合、Cloud Firestore ではクエリ対象のコレクションについて、ローカルに保存されているすべてのドキュメントを展開してからクエリと照合する必要があります。
別の言い方をすれば、バックエンドでのクエリは結果セットのサイズに応じて遅くなりますが、ローカルのオフライン キャッシュ内でのクエリは、クエリ対象のコレクションに含まれるデータのサイズに応じて遅くなります。
ところで、ローカルでのクエリが実際にどの程度遅くなるかは、状況によって異なります。ここで話題にしているのはローカル、つまりネットワークに接続していない状態でのオペレーションですが、これはネットワーク呼び出しを行うよりも速い可能性が（しかもかなりの確率で）あります。ただし、1 つのコレクションに含まれる大量のデータを分類しなければならない場合、あるいは単に動作が遅いデバイスを使用している場合、大きなオフライン キャッシュに対するローカル オペレーションは著しく遅くなる可能性もあります。
パフォーマンスを改善するには
最初に、前のセクションで説明したおすすめの方法を試してみてください。つまり、ユーザーが必要とするデータのみを取得できるようクエリに制限を追加し、不要な細かいデータはサブコレクションに移動することを検討します。また、
以前の投稿
の最後に取り上げた「複数のサブコレクションと単独の最上位コレクション」のどちらを使うべきかという観点で考えた場合、このケースでは「複数のサブコレクション」を採用した方がよいでしょう。そうすれば、キャッシュの検索対象が、こうした小さめのコレクションに含まれるデータのみとなるからです。
2 番目の方法は、必要以上のデータをキャッシュに詰め込まないようにすることです。私は、デベロッパーがキャッシュを意図的にこのように使用するケースをいくつか見たことがあります。アプリの最初の起動時に膨大な数のドキュメントにクエリを実行し、その後のすべてのデータベース リクエストにローカル キャッシュを強制的に参照させるというものです。通常、データベース コストを削減したり、以降の呼び出しを高速化したりする目的で用いられますが、実際にはメリットよりデメリットの方が大きい場合がほとんどです。
3 番目の方法は、オフライン キャッシュのサイズを小さくすることです。モバイル デバイスのキャッシュのサイズはデフォルトで 100 MB に設定されていますが、状況によっては（特に、大規模な 1 つのコレクションにほとんどのデータが格納されている場合は）、このサイズではデータが多すぎてデバイスで処理できない可能性があります。このサイズは、Firebase の設定で
cacheSizeBytes
の値を変更することで調整できます。特定のクライアントに対してサイズを調整するとよいでしょう。
4 番目に、
永続性を完全に無効にして
、何か変化があるか確認してみてください。この方法は通常はおすすめしません。前に述べたように、オフライン キャッシュは非常に優れた機能だからです。それでも、クエリが遅くなったように感じて、その理由がわからない場合は、永続性を無効にしてアプリを再実行することでキャッシュが問題の原因かどうかを判断できるでしょう。
理由その 3: ジグザグマージ結合に問題がある
「ジグザグマージ結合」という名前を私が個人的に気に入っていることはさておき、このアルゴリズムは複合インデックスに依存せずに複数のインデックスからの結果を統合できる点で非常に便利です。基本的には、ドキュメント ID 順に並べ替えた 2 つ（またはそれ以上）のインデックス間を行き来して一致を見つける仕組みになっています。
しかし、ジグザグマージ結合にも 1 つ弱点があります。どちらの結果セットもサイズが大きいにもかかわらず両者の共通部分が少ないと、パフォーマンスの問題が発生する場合があるのです。一例として、カウンター サービスも提供している高級レストランを検索するクエリを考えてみましょう。
restaurants.where('price', '==', '$$$$').where('orderAtCounter', '==', 'true')
両方ともかなり大きいグループですが、共通部分はおそらくほとんどありません。この場合、ジグザグマージ結合では、必要な結果を取得するために多くの検索を行う必要があります。
クエリのほとんどが高速に実行されているのに、特定のクエリを複数のフィールドに対して一度に実行している最中に遅くなる場合は、この状況に陥っている可能性があります。
パフォーマンスを改善するには
複数のフィールドにわたるクエリがが遅くなる場合、それらのフィールドに対する
複合インデックス
を作成することでパフォーマンスを改善できます。バックエンドでは、その後のすべてのクエリで、ジグザグマージ結合ではなくこの複合インデックスを使用するようになります。つまり、クエリは結果セットのサイズに比例して高速になるということです。
理由その 4: Realtime Database に慣れてしまっている
Cloud Firestore は、クエリ機能、信頼性、スケーラビリティの点で Firebase Realtime Database を上回ります。ただし北米で利用する場合は、一般に Realtime Database の方が低レイテンシです。通常はそれほど大きな差はなく、チャットアプリなどでは違いに気付くことはおそらくないでしょう。しかし、データベースの超高速応答に依存するアプリ（たとえばリアルタイム描画アプリやマルチプレーヤー型ゲームなど）の場合は、Realtime Database の方が「まさにリアルタイム」だと感じられるかもしれません。
パフォーマンスを改善するには
Realtime Database の低レイテンシが求められるプロジェクトを進めている（かつ、大部分のユーザーが北米にいると予想される）場合、もし Cloud Firestore の特有の機能が必要ないのであれば、そのプロジェクトの該当箇所には Realtime Database を使用するとよいでしょう。ただしその前に、
以前のブログ投稿
や
公式ドキュメント
を確認して、2 つのデータベースそれぞれのメリットとデメリットを十分に理解しておくことをおすすめします。
理由その 5: 物理的な制約がある
ほぼ完ぺきな状況であっても、利用している Cloud Firestore インスタンスがオクラホマでホストされていて、ユーザーがニューデリーにいる場合、「光の速度」の関係で少なくとも 80 ミリ秒のレイテンシが発生します。そして現実的に、どのネットワーク呼び出しでも
242 ミリ秒
前後のラウンドトリップ時間がかかります。そのため、Cloud Firestore がどれほど高速に応答しても、その応答が Cloud Firestore とデバイス間を移動する時間がどうしてもかかってしまうのです。
パフォーマンスを改善するには
まず、
単回のフェッチの代わりにリアルタイム リスナーを使用する
ことをおすすめします。クライアントの SDK 内でリアルタイム リスナーを使用すると、非常に優れた多くのレイテンシ補正機能が提供されるためです。たとえば Cloud Firestore は、ネットワーク呼び出しが戻るのを待っている間、キャッシュされたデータをリスナーに提示するため、ユーザーに結果を表示する時間がより高速になります。また、データベースへの書き込みはすぐにローカル キャッシュに適用されます。つまり、デバイスがサーバーによる確認を待っている間に、これらの変更が即座に反映されることがわかるでしょう。
次に、ユーザーの大半が所在する場所でデータをホストするようにします。最初にデータベース インスタンスを初期化する際に
Cloud Firestore のロケーションを選択
できるので、アプリに最適なロケーションはどこか、コスト面だけでなくパフォーマンス面も含めて十分に検討しましょう。
3 番目の方法としては、量子エンタングルメントに基づいた信頼性の高い安価なグローバル通信ネットワークを実装することが挙げられます。これにより、光の速度の問題を回避できるためです。この対応が済めば、おそらくライセンス料の支払いを終わらせることができ、そもそもどんなアプリを作っていたかも忘れてしまうかもしれません。
最後に
今後、Cloud Firestore のクエリが遅く感じる場面に遭遇したときは、上記の内容に目を通していずれかの状況に当てはまるかどうかを確認してください。なお、アプリのパフォーマンスを確認するには、実際の使用環境でのパフォーマンスを測定するのが一番です。この目的に最適なサービスとして、Firebase Performance Monitoring があります。
Performance Monitoring をアプリに統合して、クエリの実際のパフォーマンスを確認できるようカスタム トレースを 1～2 つ設定してみることをおすすめします。
Reviewed by Sophia Hu - Data Management Specialist, Google Cloud
以前の TLS バージョンのサポート終了に伴う Chrome UI の変更点
2019年10月25日金曜日
この記事は Chrome セキュリティ チーム、Chris Thompson による Google Online Security Blog の記事 "
Chrome UI for Deprecating Legacy TLS Versions
" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
昨年 10 月、Chrome 81 で TLS 1.0 と 1.1 のサポートを削除する計画について
お知らせしました
。この投稿では、削除の前段階として穏やかな警告 UI を導入すること、Chrome 81 で TLS 1.0 と 1.1 をブロックすることになる UI についてお知らせします。サイト管理者は、ただちに TLS 1.2 以降を有効にし、ここで紹介する UI が表示されないようにしてください。
以前の TLS の使用は減少していますが、現在も
ページ読み込みの 0.5% 以上
で非推奨のバージョンが使われています。最終的なサポートの削除に向けた移行を容易にし、古い設定が動作しなくなったときにユーザーを驚かせることがないように、Chrome は 2 段階でサポートの終了に対応します。まず、非推奨のバージョンを使っているサイトに対して、新しいセキュリティ インジケーターを表示します。次に、ページ全面に警告を表示してサイトへの接続をブロックします。
削除前の警告
2020 年 1 月 13 日より、Chrome 79 以降で、TLS 1.0 または 1.1 を使用しているサイトに「Not Secure」インジケーターを表示し、ユーザーに古い設定であることを警告します。
新しいセキュリティ インジケーターと接続セキュリティ情報。2020 年 1 月以降、ユーザーが TLS 1.0 または 1.1 を使っているサイトにアクセスした際に表示される。
サイトで TLS 1.0 または 1.1 を使っている場合、Chrome はセキュリティ インジケーターをダウングレードし、ページ情報に詳細な警告メッセージを表示します。この変更では、ユーザーがページにアクセスする操作がブロックされることはありませんが、接続のセキュリティがダウングレードされていることが警告されます。
なお、Chrome の DevTools には既に警告が表示されるようになっています。非推奨のバージョンの TLS を使っていることをサイトオーナーに警告するためです。
削除後の UI
2020 年 3 月に Stable チャンネルにリリースされる予定の Chrome 81 以降では、TLS 1.0 または 1.1 を使っているサイトにアクセスしようとすると、ページ全体を覆うインタースティシャル警告が表示されて接続がブロックされます。
Chrome 81 以降では、TLS 1.0 または 1.1 を使っているサイトにアクセスしたユーザーに、全画面のインタースティシャル警告が表示される。最終的な警告は、今後変更される可能性がある。
サイト管理者は、ただちに TLS 1.2 以降を有効にしてください。サーバー ソフトウェアによっては（Apache や nginx など）、構成の変更やソフトウェアのアップデートが必要になる場合があります。さらに、すべてのサイトで TLS 設定を再確認することをお勧めします。
最初のお知らせ
の際に、最新の TLS の基準について概要を説明しています。
企業向けリリースで SSLVersionMin ポリシーを “tls1.2” に設定すると、TLS 1.0 と 1.1 の最終的な削除について事前に確認することができます。この設定を行うと、クライアントが TLS 1.0 および 1.1 プロトコルで接続できなくなります。対応に時間がかかる企業は、このポリシーを使って TLS 1.0 や TLS 1.1 を有効化し直し、警告 UI を無効化することができます。ただし、この操作を行えるのは、2021 年 1 月までに限られます。
Reviewed by
Eiji Kitamura - Developer Relations Team
同一プロバイダによる DNS-over-HTTPS アップグレードの実験について
2019年10月24日木曜日
この記事は Chrome プロダクト マネージャー、Kenji Baheux による Chromium Blog の記事 "
Experimenting with same-provider DNS-over-HTTPS upgrade
" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
ウェブを安全に使えるようにする
という長年にわたる私たちの取り組みの一環として、Chrome 78 で
DNS-over-HTTPS
（DoH）実装を検証するための実験を行います。名前からもわかるとおり、この考え方は、HTTPS によって確保されるセキュリティとプライバシー上の重要な利点を DNS にもたらします。DNS は、指定されたウェブサイトをホスティングしているサーバーをブラウザが判断する仕組みです。たとえば、パブリック WiFi に接続しても、DoH を使っていれば、他の WiFi ユーザーが皆さんの見ているサイトを知ることはできなくなります。また、
なりすまし
や
フィッシング
攻撃も防ぐことができます。この実験は、既に DoH をサポートしている DNS プロバイダと連携して実施します。実験の目的は、現在の DNS サービスを DoH バージョンにアップグレードすることで、ユーザー間のセキュリティやプライバシーを改善することにあります。このアプローチでは、使用する DNS サービスは変わらず、プロトコルだけが変わります。そのため、既存の子ども向けの保護を含め、現在の DNS プロバイダが行っているコンテンツ制御の有効性は変わりません。
さらに具体的に説明します。Chrome 78 で行う実験では、ユーザーの現在の DNS プロバイダが
DoH 対応プロバイダのリスト
に掲載されているかどうかを確認し、そのプロバイダが提供する同等の DoH サービスにアップグレードします。DNS プロバイダがリストに掲載されていない場合、Chrome は現在の動作を継続します。リストに掲載されるプロバイダは、プライバシーとセキュリティに対する強い姿勢、DoH サービスに向けた準備の完了、実験の参加への同意という条件を満たすプロバイダから選択されました。実験の目的は、Chrome の実装を検証し、パフォーマンスへの影響を評価することです。
この実験は、サポートされているすべてのプラットフォーム（Linux と iOS を除く）で、一部の Chrome ユーザーを対象に行われます。Android 9 以上で、ユーザーが
Private DNS 設定
で DNS-over-TLS プロバイダを指定している場合、Chrome は関連付けられている DoH プロバイダを使い、エラー時にはシステムの Private DNS にフォールバックする場合があります。
DNS プロバイダの現状を維持し、プロバイダの同等な DoH サービスへのアップグレードのみを行うので、同じユーザー エクスペリエンスが維持されます。たとえば、DNS プロバイダが提供する不正なソフトウェアからの保護やペアレンタル コントロール機能は引き続き動作します。DoH が失敗した場合、Chrome はプロバイダの通常の DNS サービスを使います。Chrome 78 の chrome://flags/#dns-over-https でフラグを無効にして、実験をオプトアウトすることも可能です。
ほとんどのマネージド Chrome リリースは、実験の対象外になります。企業や教育機関の管理者の方は、今後のリリースノートを読んで DoH ポリシーについての詳細をご確認ください。このポリシーは、
Chrome Enterprise ブログ
でも公開する予定です。
DNS には 35 年の歴史があり、さまざまな関係者が利用して多様なユースケースを実現しています。特に、ISP が提供する家族向けの安全なコンテンツ フィルタリングにおいて、DNS が重要な役割を果たせることは承知しています。そのため、重要なステークホルダー（ISP や DNS プロバイダ、オンラインの安全性を専門とする組織など）を巻き込んで手順についての議論を行いつつ、家族向けフィルターなどの現在利用されているユーザー向け機能を尊重した段階的なアプローチをとります。また、
Chrome の機能とパフォーマンスの改善への協力
に同意したユーザーから送られるパフォーマンスや信頼性に関する統計、
ユーザーによるフィードバック
も考慮します。
この実験は、ユーザーのプライバシー、セキュリティ、安全性を改善するために、協力して歩まなければならない長い道のりのつつましい第一歩です。DoH が実環境でどのように動作するか、確認するのが待ち遠しくてたまりません。皆さんからのフィードバックもお待ちしています！
Reviewed by
Eiji Kitamura - Developer Relations Team
強烈なインパクト: オーストラリアのポップカルチャー サイト GOAT を AMP 化した理由
2019年10月23日水曜日
この記事は
Leo Postovoit
による The AMP Blog の記事 "
Powerful impact: Why we AMPized the Australian pop culture site – GOAT
" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
NOVA Entertainment
はオーストラリアでも特に有名なメディア ブランドで、過去 19 年間にわたってラジオ、メディア、ローカル コンテンツに携わってきました。その NOVA がポップカルチャーやニュース、エンターテイメント向けのモバイル ファースト プラットフォームとして構築したのが
GOAT
です。
GOAT は、プログレッシブを重視した WordPress ビルドの開発によって恩恵を受けた最初の NOVA のサイトです。GOAT の編集者たちの目標の 1 つは、アクセスしやすく便利で高速なフォーマットによってコンテンツを届けることです。パフォーマンスとユーザビリティは最優先事項です。ここでは、GOAT の技術革新において AMP と PWA がどのようなインパクトをもたらしたのかについて説明します。
課題
GOAT ウェブサイトには、パフォーマンスとユーザビリティに関する問題が発生していました。ユーザー エクスペリエンスを改善して多くの端末との互換性を向上させるための最優先事項は、サイトのパフォーマンスを向上させることでした。サイトがコンテンツやアセットをレンダリングする際に遅延が生じ、ユーザーやオンサイト体験、共有体験の妨げになっていました。これは驚くべきことではありません。サイトへのエンゲージメントのレベルにパフォーマンスがどれほど重要かは、複数の調査結果が一貫して示しています。
今年東京で開催された技術カンファレンスの
講演
の冒頭で、Google 社員の
Jeany Halliman
は、Google がメディアサイトの訪問者を対象に「サイトを見る際に一番嫌なこと」を尋ねた調査について触れました。
「広告業界出身の私は、いつも（訪問者が嫌うのは）広告だと思っていました。しかし、ユーザーの大半は、遅いウェブサイトと答えたのです」 – Jeany Halliman
この回答と、ページのスピードが直帰率に与える影響を細かく観測した結果には、明らかに相関性があります。しかし、過大な広告戦略が注目され、多くのメディアサイトがそれに対する「反動」を受けていることを考えれば、多くの方にとって、スピードがページの広告よりも上位に来ていることは驚きだったはずです。
チャンス
NOVA は、WordPress エンジニアリング エコシステムのリーダー的存在であり、Google と連携して公式の
AMP Plugin for WordPress
のメンテナンスを行っている
XWP
に連絡しました。XWP は、Rolling Stone、News Corp Australia、Rogers などの大手パブリッシャーや、Cloudinary、Google、BigCommerce、Automattic などの技術パートナー向けに美しく複雑なソリューションを開発していることで知られ、ウェブを進化させることを重視して仕事に取り組んでいます。
NOVA のステークホルダーが示した主要な目標は、パフォーマンス、拡張性、ユーザビリティでした。そのため、XWP にとっては、向かうべき道がプログレッシブ AMP によるアプローチであることは明白でした。
一方で、AMP ファースト戦略に移行するにあたって最も重要な目的は明らかでした。ユーザーが繰り返し利用し、喜んで共有してくれる高速な体験を作成するには、CI/CD、自動テスト、高可用性ホスティングを含む開発のベスト プラクティスを駆使して確実に拡張性や安定性を実現することも重要です。GOAT サイトは、コードの品質が高く、最新の WordPress の実装に関する留意点を踏まえて構築されているので、早いだけでなく、長く使えるものとして作られています。
解決策
AMP やその他のパフォーマンス改善策に精通している XWP は、NOVA が GOAT サイトで達成したい目標を実現するため、さまざまな実装を検討しました。最も適していたのは、1 つのコードベースで開発を効率化できる AMP ファースト戦略でした。
そこからさらに一歩進めた GOAT は、
PWA 機能プラグイン
（これも XWP と Google が連携して開発しています）のすばらしい事例とも言えるでしょう。このプラグインは、Service Worker を活用してオフライン モードや通知などの追加機能を提供します。また、この定義済みソリューションでは、AMP と PWA のメリットを今までになく簡単に組み合わせることができる
amp-install-serviceworker
コンポーネントが活用されています。
現在含まれている PWA 機能の範囲は限定的ですが、長期的な目標として、PC やモバイル端末へのインストール機能、さらに充実したオフライン モードやプリフェッチ ページ、ネイティブのプッシュ通知などを追加したいと考えています。これらの機能は、ウェブのあちこちに見られる強力な PWA と同様のものです。
広告の組み込み
広告の読み込みが適切に設定されていない場合、ページのパフォーマンスが低下する原因となる可能性があります。GOAT のようなメディア重視のサイトでは、特にその傾向が顕著です。AMP を使うということは、XWP が GOAT の広告スタックを実装する際に、AMP 標準に準拠したアプローチを採用しなければならないということです。 完全に AMP 対応されていない広告プロバイダを利用するために多少の妥協は必要になりましたが、結果的には、広告収入を頼りにするメディアサイトとしてかなり高いパフォーマンスを実現しました。これは 2 つの長所を兼ね備えています。すなわち、優れたユーザー エクスペリエンスを実現でき、
広告の読み込みも次善の方法で最適化されているので、パフォーマンスの低下につながることはありません
。
結果
ここまで説明してきたように、GOAT は NOVA のサイトで初めて統合編集ワークフローとパフォーマンスを重視したテーマビルドを実稼働させたものです。これは PWA サイトであると同時に、すべてのテンプレートがネイティブ AMP として構築されています。パフォーマンス面での成果は明らかです。
複数のプロパティの編集操作を統合しています。
モバイルの Google Pagespeed Insights スコアは 7 から 77 に上昇しました。
WebPageTest 3G テスト:
実装前
/
実装後
。ポイント: レンダリング開始時間（Start Render）が 1.5 秒短縮されました。操作が可能になるまでの時間は、43 秒からわずか 10 秒になりました。
Lighthouse テスト:
実装前
/
実装後
。最初のコンテンツ描画（First Contentful Paint）が 5.8 秒から 2.5 秒になりました（3.3 秒短縮）。パフォーマンス スコアは 7 から 65 に上昇しました。最初の CPU アイドル時間（First CPU Idle）は 16.2 秒から 5.9 秒に短縮されました。
GTmetrix:
実装前
/
実装後
。PageSpeed スコアは D（63%）から B（82%）に上昇しました。
AMP の活用を始める
GOAT サイトの AMP ファースト戦略で達成した結果をもとに、AMP を活用して現在のビジネスの課題を解決する方法について、さらに学習することをお勧めします。
AMP の詳細については、
amp.dev
にあるプロジェクトのホームページをご覧ください。
自分のサイトの互換性を評価し、AMP によってパフォーマンスとユーザー エクスペリエンスの恩恵を得られるかを確認してみたい方は、
AMPized.com
（WordPress サイトで AMP のメリットを実現する XWP のサービス）をご覧ください。
執筆者: XWP ストラテジスト、
Leo Postovoit
Reviewed by Chiko Shimizu - Developer Relations Team
amp-script: AMP ❤️ JS
2019年10月18日金曜日
この記事は
Naina Raisinghani
による The AMP Blog の記事 "
amp-script: AMP ❤️ JS
" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
今年の AMP Conf では、<amp-script> のデベロッパー プレビューを紹介しました。本日は、
<amp-script>
の一般公開についてお知らせします。カスタム JavaScript は、AMP コンポーネントによって別の Worker スレッドで実行されます。そのため、超高速な AMP ページはそのままに、カスタム JavaScript を追加できるようになります。
<amp-script> を使うと、既存の AMP コンポーネントでは実現できなかったユースケースに対応できます。また、AMP ページと非 AMP ページでコードを共有することもできます。JavaScript フレームワークを使うことも可能です。次にあげるのは、<amp-script> チームが構築してきたいくつかのサンプルです。
Vue を使った Todo MVC
パスワード チェッカー
D3.js を使ったニュース記事のデータ視覚化
次のセクションに移動する前に検証が必要になる複数ページフォーム
（下のイメージ）
セクション移動時に検証を行う複数ページフォームの例
上の例を見て興味を持った方は、<amp-script> を試してみてください。なお、AMP のパフォーマンスを保証するために、いくつか制約がある点に注意が必要です。
コンテンツのジャンプ:
通常の <amp-script> では、意図しないコンテンツのジャンプを回避するため、ユーザーのジェスチャーが発生しないとページのコンテンツを変更することはできません。
ページ読み込み:
<amp-script> はユーザーの操作なしにページのコンテンツを変更することはできないので、ページの読み込み時にコンテンツを変更することもできません。
スクリプトのサイズ:
1 つの <amp-script> で使うスクリプトは、150 kB 以下である必要があります。なお、お気に入りの JS フレームワークを使うことはできますが、150 K の制限内に収まっている必要があります。
API のサポート:
Web Worker ですべての API がサポートされているとは限りません。WorkerDOM には、
許可されている API のリスト
が掲載されています。また、いくつかの DOM のメソッドやプロパティはまだ実装されていません。リスト全体は、
WorkerDOM の互換性
で公開されています。追加してほしい API がある方は、
問題
として送信してください、
<amp-script> は、React、Preact、Angular、Vue.js、jQuery、D3.js など、皆さんが既に利用しているかもしれないフレームワークに対応しています。
この点は、AMP を使っているデベロッパーから寄せられた最も重要な要望でした。AMP Project は、スピードという AMP の価値提案を維持しつつ、この要望に対処できたことをうれしく思っています。<amp-script> の動作の詳細については、
こちら
をご覧ください。また、
この
ガイドに従って <amp-script> を試してみてください。このすばらしい手法を使うと、これまでは不可能だったたくさんのユースケースを実現できるようになります。
<amp-script> の使用に関する問題や機能リクエストがありましたら、遠慮なく
お知らせください
。
投稿者:
Naina Raisinghani
（Google AMP Project、プロダクト マネージャー）
Reviewed by Chiko Shimizu - Developer Relations Team
ジェスチャー ナビゲーションの裏話
2019年10月18日金曜日
この記事は Allen Huang and Rohan Shah (Product Managers on Android UI) による Android Developers Blog の記事 "
Gesture Navigation: A Backstory
" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Android Q の最大の変更点の 1 つが、新しくなったジェスチャー ナビゲーションです。新しいシステム ナビゲーション モードでは、画面の左端または右端から内側にスワイプすると前の画面に戻ることができ、画面の下部から上にスワイプするとホーム画面に戻ることができます。また、画面の下隅から斜めにスワイプするとデバイス アシスタントが起動します。
システム ナビゲーションをジェスチャー モデルに移行したことで、ナビゲーション ボタンを非表示にしてアプリの画面領域を拡げ、より臨場感あふれるエクスペリエンスを実現できるようになりました。
今回は、ナビゲーション デザインの過程でどのような課題に直面し、難しい選択を迫られたときどのような理由で決断したかなど、新しいシステム ナビゲーションにまつわる裏話を披露します。ジェスチャーのデザインに関して少々マニアックな部分にまで踏み込みますが、デベロッパー並びに OEM パートナーの皆様とユーザーの利便性のバランスをどう取るかについて、Google がいかに頭を悩ませたかをご理解いただけたらと思っています。アプリをこれらの変更に対応させる方法については、Medium の記事シリーズ「
エッジ ツー エッジへの対応
」で詳しく解説しておりますのでぜひご覧ください。
ジェスチャーに移行した理由
アプリ デベロッパーやパートナーの皆様にとっての Android の魅力の 1 つは、スマートフォンでまったく新しい革新的な手法を試すことができる点ではないでしょうか。
モバイル デバイスのジェスチャー機能は
2009 年
には登場していましたが、ジェスチャー ナビゲーションのパターンが急激に増えたのはここ 3 年ほどのことです。
この流れをリードしたのが、たとえば
Fluid NG
や
XDA
のような、独創的なアイデアに挑戦してきた革新的な Android パートナーや Android アプリです。
Google が調査したところ、ジェスチャーはユーザーにとってさまざまなメリットがあることがわかりました。
ジェスチャーは、スマートフォンを操作する方法としてよりスピーディーで、自然で、人間工学的に優れている
ジェスチャーはより意図的である（ソフトウェア ボタンは、スマートフォンを手に取るとき偶然タップしてしまうことがある）
ジェスチャーを採用することで、アプリ コンテンツに上書き表示するシステム ナビゲーションを最小限に抑えることができ、より臨場感あふれるエクスペリエンスを実現できる（大画面化と狭額縁化が進む中、「ホーム」ボタン、「戻る」ボタン、ナビゲーション バーなどを画面に表示する必要がない）
しかし、良いことばかりではありません。ジェスチャー モードにはさまざまな問題もあります。
ジェスチャーは、すべてのユーザーが快適に利用できるとは限らない
ジェスチャーは、習得がより難しく、ある程度の調整も必要になる
ジェスチャーは、アプリのナビゲーション パターンと競合する可能性がある
しかし、何よりも私たちが問題だと感じたのは、Android スマートフォンでもブランドや機種が違えばジェスチャーが異なるという「断片化」が生じており、特に Android デベロッパーの皆様がこの点に大きな懸念を抱かれていることでした。
そこで Google では、ここ 1 年ほどかけて Samsung、Xiaomi、HMD Global、OPPO、OnePlus、LG、Motorola などのパートナーと協力し、将来的にジェスチャー ナビゲーションを標準化していくことを決めました。一貫性のあるユーザー エクスペリエンスとデベロッパー エクスペリエンスを提供するため、Android Q 以降の新しいデバイスでは、Q のジェスチャーをデフォルトのジェスチャー ナビゲーションにします。
ただし、すべてのユーザーがジャスチャーを快適に利用できるとは限りません。ジェスチャーのような細かな動きが得意でない方々のために、すべての Android デバイスで引き続き 3 ボタン ナビゲーションをオプション機能として提供することにしています。
今回これらのジェスチャーを採用した理由
Google ではまず徹底的な調査を行いました。ユーザーはどういう形でスマートフォンを握っているか、指が届く範囲はどのあたりか、最もよく使うのはスマートフォンのどの部分か、などです。これらの調査結果をもとに、ジェスチャー モデルのプロトタイプを数多く作成し、望ましさ、使用速度、人間工学性などさまざまな側面にわたってテストを実施しました。最終的なデザインは、ユーザーがすぐに習得できるか、ユーザーが短期間で慣れるか、ユーザーがどう感じたかなどを基準に決定しました。
「戻る」ボタンは、Android の初期から引き継がれている特徴的なナビゲーション要素です。どのような操作方法が「正解か」という議論はあるものの、「戻る」ボタンのおかげで多くのユーザーが Android を、操作しやすい、習得しやすいと感じてくれたようです。実際のところ、「戻る」ボタンは非常によく利用されており、使用回数は「ホーム」ボタンより 50% も多くなっています。今回のデザインにあたっては、この「戻る」ボタンを人間工学性と信頼性に優れ直感的に行えるジェスチャーにすることを目標の 1 つとし、使用頻度がそれほど高くないナビゲーション（ドロワー、「最近」など）よりも優先することにしました。
また、最も重要な 2 つのジェスチャー（「戻る」と「ホーム」）は、下に示した到達範囲の図に基づいて、親指が最も快適に届く領域で操作できるようにデザインしました。
スマートフォン画面のヒートマップを見ると、ユーザーが片手でスマートフォンを持った状態で快適に行えるジェスチャーがわかります。
ジェスチャー モデルのプロトタイプを数多く作成したことはすでに述べましたが、これらを試してもらい、ユーザーの評価とジェスチャー操作にかかった時間を比較しました。以下は、最終的な Q モデルと他のナビゲーション モードを比較したテスト結果のグラフです。
各ナビゲーション モードの人間工学性と片手操作性についてのユーザー評価の比較（値が大きいほど良い）
各ナビゲーション モードでの「戻る」と「ホーム」の操作にかかった平均時間の比較（値が小さいほど良い）
各ナビゲーション モードでの「最近」操作にかかった平均時間の比較（値が小さいほど良い）
「ホーム」と「戻る」の操作にかかった平均時間は、Q モデルが他のどのモデルよりも短く、ボタンを使った操作よりも速いことがわかります。一方、「最近」の操作は他のモデルに比べ少し時間がかかっていますが、これは「最近」の使用頻度が「ホーム」の半分程度であるため優先度を下げたことによるものです。
定性的に見ると、ユーザーは Q モデルの片手操作性を高く評価していますが、人間工学性の面では依然としてボタンのほうが評価が高くなっています。
アプリドロワーとその他のアプリスワイプ
最終的には、操作性と使用頻度のバランスを考慮し、サイドスワイプを「戻る」ジェスチャーとして採用しました。しかし、特にジェスチャーがアプリに及ぼす影響を考えると、難しい決断を強いられる場面もありました。
たとえば、Google アプリによって異なりますが、アプリ
ナビゲーション ドロワー
をスワイプ操作で開いているユーザーは 3～7% 存在します（残りのユーザーは 3 本線のメニューをタップして開いています）。このドロワーのスワイプ ジェスチャーが「戻る」ジェスチャーに置き換えられたため、一部のユーザーは 3 本線のメニューを使った操作に慣れる必要があります。非常に難しい決断でしたが、「戻る」操作の使用頻度の高さを考慮し、ユーザーにとって最も便利になるように最適化したつもりです。
ユーザーの行動を変えずにすむよう、ドロワー ジェスチャーと「戻る」ジェスチャーをうまく識別できる方法がないか試行錯誤しました。しかし、どの方法を採用した場合でも、前の画面に戻ろうとしたユーザーが誤ってドロワーを引き出してしまうことがあり、「戻る」ジェスチャーの信頼性に疑念が生じてしまうと判断しました。
ドロワーに限らず、ジェスチャーは人々にとって大きな変更であり、慣れるまでに平均で 1～3 日かかりました。特に、カルーセルを左右にスワイプするのが苦手だったユーザーは、「戻る」ジェスチャーに慣れるのにも苦労したようです。
定性的な調査の結果によると、1～3 日で新しい操作に慣れたユーザーは、2 つのジェスチャーをしっかり区別し、スムーズに操作できるようになりました。3 ボタン ナビゲーションに戻すオプションも残されていますが、大部分のユーザーが戻したくないと回答しました。
他の調査では、ユーザーが新しいシステム ナビゲーションに切り替える際には、それに慣れるための明確な調整段階があることもわかりました。Q モデルの場合、最初の 1～3 日は「戻る」ジェスチャーの使用回数は少ないのですが、その後は 3 ボタン システムや Android P ナビゲーションと同じぐらいの頻度で利用されるようになりました。
デベロッパーの皆様にご対応いただきたいこと
Google としては、このようなジェスチャー ナビゲーションによって、Android でのユーザー エクスペリエンスの標準化を進めていきたいと考えています。今回採用したジェスチャー モデルはほとんどのユーザーにとって最適なものと考えていますが、これらが既存のアプリのジェスチャーと競合する場合は、デベロッパーの皆様にアプリの操作方法を調整していただく必要がございます。皆様のご負担を少しでも軽減できるよう、十分な情報提供を心掛けてまいります。
新しいジェスチャー ナビゲーションへの対応は、次に示す 3 つステップで進めることができます。
エッジ ツー エッジ
に対応します。これにより、アプリのコンテンツを画面いっぱいに表示できるようになります。
システム ユーザー インターフェース（ナビゲーション バーなど）との
視覚的な重なりを処理
します。
システム ジェスチャーとの競合を解消します。
これらのステップについては、Medium の記事シリーズ「エッジ ツー エッジへの対応」で詳しく解説しています。シリーズ最後の記事では、これまでに多く見られたいくつかのシナリオを紹介し、アプリをエッジ ツー エッジ対応にするための最適な方法を提案します。
新しいジェスチャー ナビゲーションについて、ご意見、ご感想などございましたらぜひお寄せください。Android Q のジェスチャー ナビゲーションはもちろん、Android の日々の改善に役立てさせていただきます。
Posted by
Yuichi Araki - Developer Relations Team
11 月 1 日（金）第 4 回 Google Cloud INSIDE Digital を開催します
2019年10月17日木曜日
Google Cloud は、インターネットサービス業界で活躍するインフラエンジニア、サーバーアプリケーションエンジニア、テクニカルリーダーの皆様に向けて、"Google Cloud INSIDE Digital" を開催します。
業界をリードする方々や、深い専門知識をもつ Google 社員をスピーカーに迎え、注目インターネットサービスの開発の裏側や、Google Cloud Platform（GCP） を中心としたテクノロジーアップデートをお届けします。この Google Cloud INSIDE Digital をきっかけに、新しいサービスやプロダクトが生まれるような会へ、参加者の皆様と共に育てて行きたいと考えています。
今回のテーマは「ここでしか聞けない AI 、機械学習サービスの活用例」。様々なアプリケーション、サービスに AI が搭載されると言われる時代において、他企業の取り組みが気になる方も多いのではないでしょうか。今回は、GCP の AI、機械学習サービスの最新動向と、先進的な企業における AI 、機械学習の活用例についてご紹介します。
開催概要
名 称 : Google Cloud INSIDE Digital
日 時 : 2019 年 11 月 1 日（金） 19 : 00 - 22 : 00
会 場 : グーグル・クラウド・ジャパン合同会社
〒106‐6108 東京都港区六本木 6-11-10 六本木ヒルズ森タワー
プログラム
18:30
受付開始
18:30 ～
開場
19:00 ～ 19:05
オープニング
19:05 ～ 19:25
Google Cloud と機械学習が切り拓く、IT 開発の新しい潮流
佐藤 一憲
Google デベロッパー アドボケイト
19:25 ～ 19:45
広告会社のクリエイター、エンジニア、Google AI でなにができるか？ ”そっくりとりっぷ” 誕生ストーリー
林 智彦 氏 博報堂 グローバル統合ソリューション局 グローバル・インタラクティブ・ディレクター
19:45 ～ 19:55
休憩
19:55 ～ 20:15
AI 技術集団による GCP サービス化事例
山本 大祐 氏
株式会社オプティム 経営企画本部 ディレクター
20:15 ～ 20:35
ショッピングサイトにおける商品画像への Could Vision API の活用
木村 慎太郎 氏
20:35 ～ 20:55
株式会社エニグモ サービスエンジニアリング本部 リードエンジニア
言葉を AI であつかうために
最首 英裕 氏
株式会社グルーヴノーツ 代表取締役社長
20:55 ～ 21:00
クロージング
21:00 ～ 22:00
懇親会
主 催： グーグル・クラウド・ジャパン合同会社
定 員：200 名
参加費：無料 （事前登録制）
参加申し込み
https://goo.gle/2lCQWGk
上記リンクからお申し込みください。
※ 競合他社様、パートナー企業様からのお申し込みはお断りさせていただくことがございます。
※ 報道関係者のご参加はお断りさせていただきます。
※ ビジネス向けのイベントとなっております。学生の方のご参加はご遠慮ください。
※ お申し込み多数の場合は抽選を行います。参加いただける方には、後日、ご登録されたメールアドレスに参加のご案内をお送りします。
Posted by
Takuo Suzuki - Developer Relations Team
ラベル
.app
1
.dev
1
#11WeeksOfAndroid
13
#11WeeksOfAndroid Android TV
1
#Android11
3
#DevFest16
1
#DevFest17
1
#DevFest18
1
#DevFest19
1
#DevFest20
1
#DevFest21
1
#DevFest22
1
#DevFest23
1
#hack4jp
3
11 weeks of Android
2
A MESSAGE FROM OUR CEO
1
A/B Testing
1
A4A
4
Accelerator
6
Accessibility
1
accuracy
1
Actions on Google
16
Activation Atlas
1
address validation API
1
Addy Osmani
1
ADK
2
AdMob
32
Ads
73
Ads API
143
ads query language
2
ads scripts
2
ads search
1
advanced markers
1
Advanced Protection Program
3
AdWords API
25
adwords scripts
2
aerial view api
1
Agency
1
AI
22
AI Agent Summit
1
AIY
3
AIY Vision Kit
2
ALPN
1
AMP
120
AMP Cache
9
AMP Camp
2
AMP CSS
1
AMP Extension
1
AMP Fest
1
AMP for Email
4
AMP Optimizer
1
AMP Packager
1
AMP Playground
1
AMP Plugin
1
AMP SSR
1
AMP Story
4
AMP Toolbox
1
amp-bind
1
amp.dev
1
AMPHTML Ads
1
Analytics
9
Andorid
13
Android
403
Android 10
1
Android 11
20
Android 11 Compatibility
1
Android 11 final release
1
Android 11 meetups
1
Android 9
1
android api
1
Android App Bundle
1
Android App Development
23
Android Architecture
1
Android Architecture Components
1
Android Auto
1
Android Design Support Library
1
Android Developer
14
Android Developer Story
4
Android Developers
13
Android Enterprise
6
Android for cars
2
Android Go
1
Android Jetpack
6
Android N
18
Android O
14
Android Open Source Project
1
Android P
7
Android Pay
1
android privacy
1
Android Q
13
Android Ready SE Alliance
1
android security
6
Android Security Year in Review
1
Android StrongBox
1
Android Studio
47
Android Studio 4.1
1
android study jam
1
Android Support Library
6
Android Things
15
Android Tools
2
Android TV
11
Android Vitals
4
Android Wear
29
android11
6
androidmarket
3
androidstudio
1
AndroidX
6
Angular
2
Angular 2
2
AngularJS
2
Announcements
2
Anthos
2
antmicro
1
AoG
1
aosp
1
API
28
APIExpert
45
apk
2
APM
1
app
3
App Action
1
App Bundle
2
app check
1
app engine
24
App Indexing
7
App Invites
6
App Maker
2
App modernization
1
AppCompat
2
Apps Flutter eBay
1
Apps Script
12
AppSheet
1
aprilfool
4
AR
3
Architecture Components
7
ARCore
3
ArtTech
1
asset-based extensions
2
assets
1
Associate Android Developer Certificate
1
Attribution Reporting
1
Audio
7
Auth Code
1
Authentication
9
AuthSub
2
Autofill
5
AutoML
1
Autotrack
2
award
1
Awareness API
1
basemap
1
basic-card
1
Beacons
6
bento
2
BERT
1
Best Practices
1
beta
4
Better Ads Standards
3
BigQuery
10
Billing
1
Biometrics
1
BLE
4
Blink
1
Blockly
1
blogger
1
BodyPix
1
bootcamp
1
Brillo
1
Brotli
2
Budou
1
budoux
1
Buildbetterapps
2
Business and Leadership
1
C++
1
Calendar
3
call ads
1
campaign
2
campaignsharedset
1
Campus
1
Canvas
1
Cardboard
4
Career
1
Case Studies
1
Case Study
3
CCPA
1
CDS 2020
3
CDS Recap 2020
3
Certificate
8
changestatus
1
chrome
261
chrome 98
1
Chrome Apps
1
Chrome Custom Tab
4
Chrome Dev Summit
5
chrome extension
14
Chrome for Android
2
Chrome for iOS
3
Chrome OS
10
Chrome Root Program
1
Chrome Root Store
1
Chrome Tech Talk Night
4
chrome103
1
chrome104
1
chrome108
1
chrome90
1
Chromebook
5
Chromecast
7
chromewebstore
9
Chromium
20
CLI
1
ClientLogin
3
Closure Compiler
1
Cloud
29
Cloud AI Platform
2
Cloud Firestore
5
Cloud Functions
9
Cloud IoT Device SDK
1
cloud messaging
1
Cloud ML Summit
1
Cloud Next
19
Cloud OnAir
5
Cloud OnBoard
4
Cloud PubSub
1
Cloud Run
1
Cloud Storage
1
Cloud Study Jams
3
Cloud Summit
1
Cloud Test Lab
2
Cloudflare
1
CNN
1
Coalition for Better Ads
2
CocoaPods
1
code review
1
codejam
5
codelab
5
Codepen
1
Colaboratory
1
Common Criteria
1
Community
7
compatibility
1
Compose
1
compose camp
1
compute engine
3
consent
1
Contests
1
Context
1
controls
1
Conversation API
1
conversations
2
conversion
1
Cookie
10
Coral
3
core web vitals
1
COVID-19
2
Crash Reporting
2
Crashlytics
3
cryptography
1
Custom Element
1
Custom Model
1
CWV
2
dark theme
1
Dart
2
data retention
1
DataCenter
1
datacloudsummit
1
Daydream
4
deck.gl
2
Deep Learning
4
Delegation
1
Demo Party
1
Design Patterns
1
Design Sprint
3
DesignBytes
1
Designer
1
DevArt
3
DevBytes
6
Developer
15
Developer Console
4
Developer Library
1
Developer Preview
6
Developer Relations
3
Developer Review
1
Developer Student Club
1
DEVELOPERS
1
Developers Story
4
DevFest
12
DevFestX
3
DevOps
1
devtools
4
Dialogflow
1
Differential privacy
2
Digital Asset Links
1
Digital Goods API
1
directions api
1
DirectShare
1
Discover
1
distance matrix api
1
DNS-over-HTTPS
4
Domain
1
Doodle
1
DoubleClick
4
Doze モード
1
drive
2
DSA
1
DSC
1
DX
1
Dynamic Links
3
EarlGrey
1
Easter Egg
1
ECMAScript 2015
1
Eddystone
4
Edge
1
egypt
1
encoder
1
Encryption
1
English
2
environment api
1
Envoy
1
error
1
ES2015
1
ES2016
1
ES6
2
ES7
1
eta
1
Event
7
events
3
Explore
1
extensions
1
external
1
Featured
25
Feed
2
feed-based extensions
3
feeds
1
FIDO
7
filter
1
final release
1
Firebase
123
Firebase Admin SDK
6
Firebase Analytics
10
Firebase Auth
4
Firebase Cloud Messaging
10
Firebase Crashlytics
2
Firebase Database
5
firebase for games
1
Firebase Libraries
1
Firebase Notifications
1
Firebase Performance
3
Firebase Remote Config
6
firebase summit
1
Flash
1
FLEDGE
1
FLoC
2
Flutter
8
Flutter App Development
1
flutter3
1
font
3
fraud
1
G Suite
19
game
43
Game Developers Conference 2018
1
Game Developers Conference 2019
1
Game Development
1
gaming
1
gaql
8
Gboard
2
gc_datacloud
1
GCCN
1
GCP
17
GCPUG
1
GDC
1
GDD11JP
56
GDD2010JP
23
GDE
2
GDG
23
GDG Cloud
1
gdgoc
2
gdsc
5
Gemini
6
Gemma
2
generative AI
4
Geo
55
Get Inspired
1
Gingerbread
1
GLIDE
5
global foundries
1
Gmail
6
Gmail API
3
Go
1
Go Checksum Database
1
golang
5
goo.gl
1
Google
8
Google account
1
Google Analytics
4
Google API
2
Google Apps
14
Google Apps Script
4
Google Assistant
13
Google Assistant SDK
2
Google Binary Transparency
1
Google Cast
8
Google Chat
3
Google Cloud
50
Google Cloud Day
10
google cloud innovators
2
Google Cloud INSIDE Digital
2
Google Cloud INSIDE Games & Apps
9
Google Cloud INSIDE Media
1
Google Cloud INSIDE Retail
3
Google Cloud Messaging
11
google cloud next
4
google cloud next tokyo
12
Google Cloud Platform
16
Google Code-in
1
Google Dev Library
1
Google Developer Experts
2
google developer groups
1
google developer student clubs
1
Google Developers Academy
1
Google Developers live
5
Google Developers Summit
2
Google Drive
6
Google Earth
1
Google Fit
2
Google for Games
3
Google for Mobile
2
Google for Startups
8
Google for Work
1
Google I/O
27
Google I/O 2024
3
Google Identity Services
6
Google Impact Challenge
1
Google Maps
72
Google Maps Platform
92
Google Meet
1
Google ML Summit
2
Google Open Source Peer Bonus
1
Google Pay
6
Google Photo
1
Google Play
148
Google Play App Safety
1
Google Play Billing
1
Google Play Console
15
Google Play developer distribution agreement
1
Google Play Developer Policies
2
Google Play Game Services
10
Google Play Instant
1
Google Play Services
23
Google Play Store
1
Google Play アプリ署名
1
Google Plus
14
Google Search
8
Google Sheets API
3
Google Sign-In
17
Google Slides API
5
Google Summer of Code
1
Google Tag Manager
1
Google Tensor
1
Google Trust Services
3
Google マップ
4
google_ads_api_v6
1
Google+
2
Googleapps
10
GoogleCloud
5
GoogleCloudDay
5
GoogleCloudInside
1
googlecloudlearn
1
googlecloudnext
2
GoogleGames
1
GoogleI/O
31
GoogleLabs
1
GooglePlay
3
GoogleTV
1
GPS
1
Gradle
1
Growth Academy
1
gRPC
2
GTUG
5
GWT
2
hack4jp
2
hackathon
7
handson
1
Hangouts Chat
3
hardware
2
Hosting
3
hotel
1
How-To Guide
1
HTML5
17
HTML5Rocks
1
HTTP/2
5
HTTPS
19
I/O Extended
8
ID Token
1
Identity
18
identity check
2
Identity Toolkit
1
IGF2010
4
IGF2020
2
Ignite
4
Imagen 2
1
IME
12
Indie Game
7
Indie Games Festival
7
Indie Games Festival 2018
2
Indie Games Festival 2019
12
Indie Games Festival 2020
7
Industry Trends
1
Inevitable ja Night
30
Influence
1
innovators hive
2
Insights
1
Instagram
1
Instant Apps
6
intern
2
Invites
1
IO19
3
iOS
22
IoT
7
IPv6
1
Issue Tracker
2
IWD
1
Japanese
6
Japanese Developer
1
Japanese Input
1
java
1
JavaScript
13
Jetpack
5
Jetpack Compose
6
Journeys
1
K-12
1
Kaggle
1
Key Transparency
1
Knowledge Graph
1
Kotlin
25
Kotlin Android Extensions
1
kotlin api
1
Kotlin Beginners
3
Kotlin Vocabulary
2
Kubernetes
4
l10n
8
latest
18
latest news
1
launch
1
LaunchPad
2
Learn
2
lifull
1
Lighthouse
1
LINE
1
Local AI
1
Location
1
Lollipop
10
Machine Learning
32
MAD Skills
2
MADSkills
2
Maker Faire Tokyo
1
maps compose
1
maps embed api
1
Maps JavaScript API
6
maps on air
1
maps sdk
2
maps transportation
1
Marshmallow
10
Material
1
Material Design
31
MDL
2
MDN
1
MediaPipe
1
Messaging
1
metrics
1
MIDI
2
migration
1
mikan
1
Mixed Contents
4
ML
3
ML Kit
12
mlops
1
Mobile
16
Mobile Bootcamp
4
mobile optimized maps
1
Mobile Sites certification
1
Mobile Vision
4
mod_pagespeed
1
Model Maker
1
monetization
2
monetize
3
Mozc
15
Music
1
NativeDriver
2
NativeScript
1
Navigation
1
NBU
1
ndk
3
Nearby
5
News
1
Next Extended
1
Next Tokyo
4
Nexus
2
Nexus S
1
NFC
1
NIST
1
Node.js
3
notifications
2
Noto CJK
1
Now in Android
13
NPAPI
2
NPN
1
oauth
17
officehour
1
One Tap
2
online security
2
open silicon
3
open source
10
OpenAI
1
opencensus
1
opencloudsummit
1
OpenGL
4
OpenID
3
OpenID Connect
4
OpenSocial
1
opensource
20
OpenTitan
2
Optimization
1
OSV
1
p-max
3
Page Experience
1
passkey
3
Password Manager
4
Payment
8
Payment Handler API
1
Payment Request API
2
PDF
1
PEM
33
people
2
People API
3
Performance
16
Performance budget
1
performance max
2
Performance Monitoring
1
performance report
1
permissions
1
personalization
1
PersonFinder
1
Phishing
2
phone
1
photorealistic 3d tiles
1
Physical Web
3
Pi
1
Pixel
5
Place Picker
1
placements
1
places api
1
places SDK
1
Platform Stability
1
Play Billing
2
Play Billing Library
2
Play Console
2
Player Analytics
4
Playtime 2017
1
Policy
8
policy compliance
2
policy violations
2
polylines
1
Polymer
7
pricing
1
privacy
15
Privacy Sandbox
22
Progressive Web Apps
14
project hosting
1
Promise
2
Promo code
1
Protocol Buffers
1
PRPL
1
publicdata
1
Push API
1
Push Notification
6
PWA
4
Python
3
query builder
8
query validator
1
QUIC
2
quick builder
1
quick start widget
1
QWIKLABS
3
RAIL
1
raspberry pi
1
React
1
React Native
2
reactive programming
1
Realtime Database
9
Recap Live Japan 2019
3
reCaptcha
1
Redux
1
release
7
Remote Config
4
Remote Display API
1
Reporting API
1
Requirements
1
Resonance Audio
1
resource type
1
Rewarded Video Ads
2
RKP
1
rmf
2
routes api
3
RSS
1
Run on OS Login
1
Runtime Permission
1
Rust
2
Safe Browsing
4
safety
1
Sample Code
2
Santa Tracker
1
SBOM
1
schedule
1
schema
2
schema.org
1
Scorecards
1
script
2
SDG
1
sdk
1
search central
1
secur
1
Secure Element
1
security
97
selfie
1
Service Worker
4
SHA-1
1
Sigstore
4
silicon
4
Site Isolation
1
sketchup
1
skywater
1
SLSA
1
smart displays
1
smart home
1
smart shopping campaign
1
SmartLock for Passwords
5
social
4
Social Good
1
Social Media
1
software development
1
solution challenge
2
Solve
1
SPDY
3
speak2tweet
1
speaker
1
Spectre
2
speedometer
1
Spreadsheet
3
ssc
1
ssd
1
SSR
1
stable release
1
startup
7
Storage
3
store sales direct
1
story
2
streetview
3
Study Jams
12
subscriptions
5
sunset
10
Swift
2
SwiftShader
1
Symantec
1
tag
1
tapple
1
Task
4
Team Drive
1
techtalk
13
TensorFlow
43
TensorFlow Federated
1
TensorFlow Lite
8
TensorFlow Object Detection API
1
TensorFlow Probability
2
TensorFlow.js
4
test
4
Test Lab
6
TF Certificate
2
TFX
1
The Fast and the Curious
13
Titan M2
1
Titan Security Key
1
TLS
4
Topics
1
ToS
1
trace
1
Transliteration
1
Transparency
1
Trust
1
Trusted Web Activity
1
Trusty OS
1
TrustZone
1
Twitter
1
UA-CH
1
Udacity
20
Unity
3
update
1
usecase
1
User Agent string
2
UX
5
v10
2
v10.1
1
v11
1
v13
1
v15
1
v19
1
v3
1
v4
1
v5
1
v6.1
1
v7
2
V8
5
v9
1
valuetrack
1
Verifiable Design
1
vertex ai
1
Vision AI
1
VP9
1
VR
11
Vulkan
2
wafer
1
Watch Face
2
wave
2
Wear OS
3
Weave
1
Web
38
Web Animations
1
Web Components
9
Web Manifest
2
Web Packaging
3
Web Stories
3
Web Story
3
Web Vitals
7
web.dev
1
WebAssembly
6
WebAuthn
1
WebGL
5
Webhook
1
WebM
1
WebMusic
5
WebRTC
1
WebView
1
Windows
1
Women in Gaming
1
Women Techmakers
1
Women Techmakers Scholars Program
1
WomenDeveloperAcademy
1
Wordpress
2
workmanager
1
WTM
8
Xcode
1
YouTube
18
YouTube API
1
youtube select
1
インタビュー
1
コードサンプル
1
サプライ チェーン
1
プライバシー
1
機械学習
3
言論の自由
1
節電
3
定期購入
1
東日本大震災
9
日本語入力
41
ブログ アーカイブ
2026
4月
3月
2月
2025
8月
7月
6月
5月
4月
3月
2月
1月
2024
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2023
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2022
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2021
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2020
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2019
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2018
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2017
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2016
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2015
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
2014
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2013
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2012
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2011
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2010
12月
11月
Feed
Follow @googledevjp
"プロダクトに関するご意見は
プロダクトフォーラム
にお願いします"
