[go: up one dir, main page]

 この記事は Google Play プロダクト マーケティング マネージャー、Lloyd Hightowerによる Google for Developers の記事 " Announcing the Winners of the Gemini API Developer Competition!" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


5 月の  I/O で、Google は世界中の開発者のみなさんに Gemini API を活用した革新的なアプリの開発を呼びかけました。世界中の何千もの開発者の皆さんがこの呼びかけに応え、既存のアプリに AI を搭載した機能を追加し、可能性の限界を広げる AI のアプリを開発しました。

そして、みなさんが待ち望んでいた瞬間が訪れました:

Gemini API デベロッパー コンテストの受賞者を紹介します!日本からは 2 名の方が選出されました。

総合的なベスト アプリ : Jayu


AI 搭載のパーソナルアシスタント「Jayu」は、Gemini API とクリエイティブな開発の融合による可能性を実証しています。この革新的なアプリは、ウェブブラウザ、コードエディタ、音楽ストリーミング、ゲームなど、さまざまなアプリと統合されています。Jayu は、視覚情報を解釈することによって、アプリのインターフェースと直接対話してリアルタイムで翻訳する能力を持ち、Gemini API の力とその能力を最大限に引き出すクリエイターの卓越したスキルを同時に示します。Google にとって、Jayu は単なる受賞アプリではなく、AI が生活に統合され、働く未来の一端を垣間見ることができます。

影響力の大きいアプリ & ユーザー評価の高いアプリ : Vite Vere (Real Lives)

Vite Vere は、認知障害を持つ人びとが日常的なタスクをこなすためのパーソナライズされたガイダンスを提供することで、より自立することを支援します。このアプリが Gemini の視覚的理解と巧みなプロンプトを使用して、ユーザーがタスクを完了できるよう段階的な指示を提供することで、自立とスキル開発を促進している点に感銘を受けました。

最もクリエイティブなアプリ : Outdraw AI (日本) 


Outdraw は、創造性と AI のユニークな融合により、AI ならではのゲーム体験を可能にしました。このゲームは、ユーザーは人間には認識できて、AI の視覚理解では認識できない画像を描くという挑戦をユーザーに与えるゲームです。このアプリは、AI をコラボレーションパートナーから挑戦的な対戦相手に変えることで、クリエイティブな取り組みにおける AI の役割を再定義します。これは、AI の最も創造的な使用例の 1 つでした。

最も役立つアプリ & Flutter の最適な用途 : Prospera

Prospera は、革新的な Flutter アプリで、Gemini API を活用してリアルタイムの AI セールスコーチを構築しています。セールス会話の分析と即時のフィードバックやパフォーマンス レポートを提供することで、Prospera は 営業担当者がスキルを向上させることを可能にします。このアプリは、実用的なビジネス課題に対処し、プロとしての成長を促進する Gemini モデルの汎用性を示しています。Prospera の詳細と、アプリの選出理由については、Flutter ブログ (英語) をご覧ください。

ベスト Android アプリ : Gaze Link


Gaze Link は、重度の運動障害と言語障害を発症した筋萎縮性側索硬化症(ALS)の患者の力を引き出す可能性を秘めており、私たちに感銘を与えました。この Android アプリは、眼球追跡技術とGemini API を使用して、介護者の質問を理解し、患者から生成された単一単語に基づいて完全な文章の応答を正確に予測および生成します。Gaze Link の詳細については、Android Developer ブログ (英語) をご覧ください。

Firebase のベスト ユース : Trippy


Trippy は、Firebase と Gemini API を巧みに活用して、パーソナライズされた旅行計画体験を作り出すことで注目を集めました。このアプリは、Gemini の自然言語理解とレコメンド機能を活用して、ユーザーの好みをもとに目的地、アクティビティ、旅程を提案します。Trippy は、AI がどのように旅行計画を強化し、世界を探検するのをよりアクセスしやすく楽しいものにするかを示しています。Trippy の詳細については、Firebase ブログ (英語) をご覧ください。

ベスト ウェブ アプリ : Viddyscribe


ViddyScribe は、視覚障害者の方々がよりアクセスしやすくなるよう、動画に自動的に音声説明を追加するウェブ アプリです。このアプリは、Gemini モデルを使用して文脈的に正確な説明を生成し、視聴体験を妨げることなく動画にシームレスに統合します。ViddyScribe の詳細については、Chrome Developers ブログをご覧ください。

ベスト ゲームアプリ : Pen Apple


Pen Apple は、Gemini Flash モデル を巧みに活用して、ゲームプレイのインタラクションを迅速に解釈して実行するオンライン デッキ構築ゲームです。このゲームは、Gemini の自然言語処理能力を使用して、カードの効果を直接カード名から解釈します。これにより、最小限の開発努力で複雑で創造的なカードが可能になります。私たちは特に、Gemini API がゲームの背景設定、敵、ステージ、さらにはゲームの仕組みに統合される新しいカードの作成にも使用されている点にも感銘を受けました。

ARCore のベスト ユース: Everies (日本)

Everies は、Gemini API と ARCore を活用して、身の周りの物に命を吹き込みます。Gemini の視覚理解と高度なプロンプトを使用して、Everies は物ごとにユニークなスクリプトを作成し、ARCore を使用して顔の特徴を重ね合わせることで、革新的で楽しい方法で物に命を吹き込みます。

Gemini API で未来を構築する

これらのアプリは、さまざまな分野で画期的な問題を解決するための Gemini API の計り知れないな可能性を示しています。Google は、開発者の皆さんが Gemini の能力を活用して、今後さらにインパクトのある革新的なアプリを開発することを期待しています。Gemini を活用した開発を始めるには、Google AI Studio をご覧ください。

Reviewed by Tamao Imura - Developer Marketing Manager, Google Play













この記事は Yoshi Yamaguchi、Santiago Díaz、Maud Nalpas、Eiji Kitamura による Google Security Blog の記事 "Uncovering potential threats to your web application by leveraging security reports" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

新たなウェブ標準である Reporting API は、本番ウェブサイトにアクセスするブラウザで発生する問題をレポートする汎用的な仕組みを提供します。受け取るレポートでは、世界中のユーザーのブラウザで発生するセキュリティ違反やまもなく非推奨になる API などの問題が詳しく説明されています。

多くの場合は、HTTP ヘッダーでエンドポイント URL を指定するだけでレポートを収集できます。するとブラウザは、皆さんにとって関心のある問題が含まれたレポートをエンドポイントに自動転送し始めます。ただし、レポートの処理や分析はそれほど簡単ではありません。たとえば、エンドポイントには大量のレポートが送られてくる可能性がありますが、そのすべてが根本的な問題の特定に役立つわけではない場合があります。そのような状況では、問題を抽出して修正するのは非常に困難かもしれません。

このブログ投稿では、Google セキュリティ チームがどのように Reporting API を使って潜在的な問題を検出し、実際の問題を特定しているかを紹介します。また、Google と同じようなアプローチで簡単にレポートの処理や対策ができるように、オープンソースのソリューションも紹介します。


Reporting API の仕組み

本番環境のユーザーのブラウザでしか発生しないエラーもあります。もちろん、皆さんはユーザーのブラウザにアクセスすることはできません。こういったエラーは、ローカルで、あるいは開発中に見かけることはありません。実際のユーザーやネットワーク、デバイスがどのような状態になっているかわからないからです。Reporting API を使えば、ブラウザを直接利用してこういったエラーをモニタリングできます。つまり、ブラウザがエラーをキャッチし、エラーレポートを生成して、指定したエンドポイントに送信してくれます。

レポートの生成と送信の仕組み。

Reporting API でモニタリングできるエラーには、次のようなものがあります。

モニタリングできるすべてのエラータイプについては、ユースケースとレポートタイプをご覧ください。

Reporting API は、HTTP レスポンス ヘッダーで有効化と設定を行います。つまり、ブラウザがレポートを送信するエンドポイントと、モニタリングするエラータイプを HTTP レスポンス ヘッダーで宣言します。ブラウザは、レポートのリストをペイロードとする POST リクエストによって、レポートをエンドポイントに送信します。

設定の例 :

# CSP 違反レポート、Document-Policy 違反レポート、非推奨レポートを受け取る設定の例
Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default"
# CSP 違反と Document-Policy 違反を `main-endpoint` に送信する
Content-Security-Policy: script-src 'self'; object-src 'none'; report-to main-endpoint; Document-Policy: document-write=?0; report-to=main-endpoint; # 非推奨レポートは自動生成され、明示的なエンドポイントは必要ない。常に `default` エンドポイントに送信される

注 : "report-only" モードをサポートするポリシーもあります。このポリシーでは、レポートは送信されますが、実際の制限は適用されません。これは、ポリシーが効果的に機能しているかどうかを判断する際に役立ちます。

Chrome ユーザーは、DevTools の [Application] パネルから、ブラウザが生成するレポートを確認できます。

DevTools の [Application] パネルに表示されるレポートの例。

レポートのエンドポイントのデモでは、生成されたさまざまな違反がサーバーでどのように受信されるかを確認できます。

違反レポートの例

2024 年 3 月時点で、Chrome は Reporting API をサポートしており、Safari は一部をサポートしています。詳細については、ブラウザ サポートの表をご覧ください。


Google のアプローチ

Google は、セキュリティを大規模に向上できるという恩恵を受けています。Content Security PolicyTrusted TypesFetch MetadataCross-Origin Opener Policy といったウェブ プラットフォームによる対策は、さまざまな Google プロダクトや無数の個々のサービスからあらゆる脆弱性を排除するために役立ちます。この点は、こちらのブログ投稿で詳しく説明しています。


セキュリティ ポリシーを大規模に導入する場合、エンジニアリング上の課題の 1 つとなるのが、新しい制限に準拠しておらず、制限が適用された場合に動作しなくなるコードを特定することです。この問題を解決するためによく使われる 4 つのステップがあります。
  1. ポリシーを report-only モード でロールアウトします(CSP report-only モードの例)。こうすると、ブラウザはクライアント側のコードを通常どおり実行するよう指示しつつ、ポリシーが適用された場合に違反となるイベントの情報を収集します。この情報は、レポートのエンドポイントに送信される違反レポートに集約されます。
  2. 違反レポートをトリアージし、ポリシーに準拠していないコードの場所にリンクします。たとえば、危険な API を使っていたり、ユーザーデータとコードが混在するパターンを使っていたりするため、セキュリティ ポリシーに準拠していないコードベースがあるかもしれません。
  3. 特定したコードをリファクタリングして準拠させます。たとえば、危険な API を安全なバージョンに置き換えたり、ユーザー入力をコードと混在させないようにしたりします。こうしたリファクタリングにより、危険なコーディング パターンが減り、コードベースのセキュリティ態勢が向上します。
  4. すべてのコードを特定し、リファクタリングが終わった段階で、report-only モード からポリシーを削除し、完全に適用します。通常のロールアウトでは、手順 1~3 を繰り返し、すべての違反レポートを確実にトリアージします。



Reporting API では、1 つのレポート エンドポイントと、複数のセキュリティ機能を表現する 1 つのスキーマを使ってこのサイクルを実行できます。そのため、ブラウザ、コードパス、ユーザータイプを問わずに、さまざまな機能のレポートを一元的に収集できます。

注 : ポリシーで禁止されているアクションを行おうとすると、違反レポートが生成されます。たとえば、あるページに CSP を設定しているにもかかわらず、CSP で許可されていないスクリプトを読み込もうとする場合です。Reporting API で生成されるレポートのほとんどは違反レポートですが、それがすべてではありません。その他のタイプには、非推奨レポートやクラッシュ レポートなどがあります。詳細については、ユースケースとレポートタイプをご覧ください。

残念ながら、違反レポートのストリームにはノイズが紛れ込むことがよくあります。その場合、準拠していないコードを見つけることが難しくなる可能性があります。たとえば、多くのブラウザ拡張機能、マルウェア、ウィルス対策ソフトウェア、開発ツールのユーザーは、DOM にサードパーティのコードを挿入したり、禁止された API を使ったりしています。挿入されるコードがポリシーに準拠していない場合、コードベースにリンクされていない対策不可能な違反レポートになる可能性があります。そのため、レポートのトリアージが困難になり、すべてのコードを確実に準拠させてから新しいポリシーを適用するのが難しくなります。

Google は長年にわたり、違反レポートを収集して活用し、それをまとめて 根本原因に集約するための多くの技術を開発してきました ここでは、デベロッパーが違反レポートのノイズを除外できる技術の中から、特に役立つ技術の概要を紹介します。


根本原因に注目する

ブラウザのタブが使われている間に、ポリシーに準拠していないコードが何度も実行されることはよくあります。それが発生するたびに、新しい違反レポートが作成され、キューイングされて、レポートのエンドポイントに送信されます。これが起きると、冗長な情報を含む大量のレポートができてしまいます。そこで、違反レポートをクラスタにグループ化することで、個々の違反を意識することなく、根本原因について考えることができます。根本原因の方が理解しやすいので、有効なリファクタリング方法を探す時間を短縮できます。

例を通して、違反がどのようにグループ化されるのかを確認してみましょう。たとえば、インライン JavaScript イベント ハンドラの使用を禁止する report-only の CSP が導入されているとします。違反レポートは、該当するハンドラのすべてのインスタンスについて作成され、次のフィールドが設定されます。

  • blockedURL フィールドには、inline が設定されます。これは違反の種類を表します。
  • scriptSample フィールドには、フィールド内のイベント ハンドラの内容の最初の数バイトが設定されます。
  • documentURL フィールドには、現在のブラウザタブの URL が設定されます。

ほとんどの場合、この 3 つのフィールドで、特定の URL のインライン ハンドラを一意に識別できます。他のフィールドの値が異なる場合でも同様です。こういったことがよく起こるのは、トークンやタイムスタンプなどのランダムな値をページをまたいで使う場合です。前述のようなフィールドの値は、アプリケーションやフレームワークによって微妙に異なる場合があるため、レポート値をあいまい一致させることができれば、手間を省きつつ、違反をクラスタにグループ化して対策につなげることができます。必要に応じて、URL フィールドに既知のプレフィックスがある違反をグループ化することができます。たとえば、URL が chrome-extensionmoz-extensionsafari-extension で始まるすべての違反をグループ化すると、根本原因がコードベース以外のブラウザ拡張機能である違反を、高い信頼性で特定できます。

独自のグループ化戦略を策定すれば、トリアージが必要な違反報告の数を大幅に減らし、根本原因に注目することができます。通常は、関心のある種類の違反を一意に識別するフィールドを選び、そのフィールドを使って、特に重要な根本原因に優先順位をつけられるようにする必要があります。

 

環境情報を活用する

対策不可能な違反レポートと対策可能な違反レポートを区別するもう 1 つの方法が、環境情報です。このデータは、レポートのエンドポイントへのリクエストには含まれますが、違反レポート自体には含まれません。環境情報からクライアント設定におけるノイズ源を判別できる可能性があるので、トリアージに役立つかもしれません。

  • ユーザー エージェントまたはユーザー エージェント クライアント ヒント : ユーザー エージェントは、対策不可能な違反の大きな兆候です。たとえば、クローラ、ボット、一部のモバイルアプリなどは、サポート対象のブラウザ エンジンとは動作が異なり、カスタムのユーザー エージェントを使っているので、他では起きない違反が発生する可能性があります。それ以外にも、特定のブラウザでのみ発生する違反や、ナイトリー ビルドによる変更や新バージョンのブラウザによって発生する違反もあります。ユーザー エージェント情報がなければ、こういった違反を調査することは非常に困難になります。
  • 信頼できるユーザー : エンドポイントが違反の発生したドキュメントと same-site である場合、Reporting API がレポート エンドポイントに対して行うリクエストに利用可能な Cookie が添付されます。Cookie を取得すると、違反が起きたユーザーの種類を特定する際に役立ちます。対策すべき違反の多くは、会社の従業員やウェブサイト管理者など、信頼できるユーザーによるものであり、これらのユーザーが侵略的な拡張機能をインストールしたり、マルウェアに感染していたりすることはないでしょう。レポート エンドポイントから認証情報を取得できない場合は、まず信頼できるユーザーを対象に report-only ポリシーを設定してみましょう。そうすることで、対策すべき違反の基準を明確にしてから、ポリシーを一般公開することができます。
  • ユニーク ユーザー数 : 一般原則として、典型的な機能やコードパスのユーザーからは、ほぼ同じ違反が生成されるといえます。そのため、少数のユーザーでしか発生していない違反は除外候補とすることができます。つまり、アプリケーションのコードではなく、ユーザーの特定の設定が問題である可能性があるということです。「ユーザー数をカウントする」方法の 1 つは、違反を報告したユニーク IP アドレス数を記録することです。近似カウント アルゴリズムは使いやすく、特定の IP アドレスを追跡せずにこの情報を収集できます。たとえば、HyperLogLog アルゴリズムは、わずか数バイトで、信頼度高く、集合内のおおまかな一意の要素数を数えることができます。

違反をソースコードにマッピングする(高度な内容)

違反のタイプによっては、source_file フィールドまたはそれと同等のフィールドが含まれます。このフィールドは、違反の原因となった JavaScript ファイルを表し、通常は行番号と列番号が付いています。これらの 3 ビットデータは高品質の信号であり、リファクタリングが必要なコードの行を直接指すことができます。

ただし、コンパイルや最小化のために、ブラウザがフェッチしたソースファイルがコードベースに直接マッピングできなくなることもよくあります。その場合は、JavaScript ソースマップを使って、デプロイされたファイルとオーサリングされたファイルの間で行番号と列番号をマッピングするとよいでしょう。すると、違反レポートがソースコードの行に直接変換されるので、非常に対策しやすいレポート グループと根本原因が生成されます。

 

独自のソリューションを確立する

Reporting API は、セキュリティ違反、非推奨の API 呼び出し、ブラウザの介入などのブラウザ側イベントを、イベントごとに指定されたエンドポイントに送信します。ただし、前のセクションで説明したように、そのレポートから実際の問題を抽出するには、データ処理システムが必要です。


幸いなことに、さまざまな方法で必要なアーキテクチャを設定できるようになっており、オープンソースのプロダクトもあります。必要なシステムの基本的な要素は次のとおりです。
  • API エンドポイント : HTTP リクエストを受け取り、JSON 形式でレポートを処理するウェブサーバー
  • ストレージ : 受け取ったレポートやパイプラインで処理したレポートを格納するストレージ サーバー
  • データ パイプライン : ノイズを除去し、必要なメタデータを抽出して集約するパイプライン
  • データ視覚化ツール : 処理したレポートから知見を得るためのツール

以上の各コンポーネントのソリューションは、パブリック クラウド プラットフォーム、SaaS サービス、オープンソース ソフトウェアとして利用できます。詳細については、代替ソリューションのセクションをご覧ください。また、次のセクションでは、サンプル アプリケーションの概要を説明します。

 

サンプル アプリケーション : Reporting API プロセッサ

ブラウザからレポートを受け取る方法と、受け取ったレポートを処理する方法を理解できるように、小さなサンプル アプリケーションを作成しました。このアプリケーションで、ブラウザが送信したレポートからウェブ アプリケーションのセキュリティ問題を抽出するために必要なプロセスを示します。具体的には、以下のプロセスになります。

  • レポートのストレージへの保存
  • ノイズ リダクションとデータ集約
  • 処理済みのレポートデータの可視化
このサンプルでは、Google Cloud を使っていますが、各コンポーネントはお好みのテクノロジーに置き換えることができます。サンプル アプリケーションの概要を次の図に示します。



緑色のボックスは、独自に実装する必要があるコンポーネントです。 フォワーダ(forwarder) はシンプルなウェブサーバーであり、JSON 形式のレポートを受け取り、それを Bigtable 用のスキーマに変換します。 ビームコレクタ(beam-collector) はシンプルな Apache Beam パイプラインであり、ノイズの多いレポートをフィルタリングし、関連するレポートを集約して、CSV ファイルとして保存します。この 2 つのコンポーネントは、Reporting API からのレポートを有効利用するうえで重要な役割を果たしています。


実際に試す

これは実際に実行できるサンプル アプリケーションなので、すべてのコンポーネントを Google Cloud プロジェクトにデプロイし、自分で仕組みを確認することができます。サンプル システムを設定するための詳細な前提条件と手順は、README.md ファイルに記載されています。

 

代替ソリューション

ここで共有したオープンソース ソリューション以外にも、Reporting API を簡単に使えるようにするツールがいくつも用意されています。次のようなものがあります。

  • Sentry や Datadog などのアプリケーション エラー モニタリング プラットフォーム

代替案を選択する際は、価格だけでなく、次の点を考慮するようにしましょう。
  • アプリケーションの URL をサードパーティのレポート収集ツールに渡しても構わないでしょうか?ブラウザが URL から機密情報を取り除いたとしても、機密情報はこのように漏洩する可能性があります。アプリケーションにとってリスクが高すぎると思われる場合は、独自のレポート エンドポイントを運用してください。
  • 収集ツールは、必要なすべてのレポートタイプをサポートしていますか?たとえば、すべてのレポート エンドポイント ソリューションが COOP/COEP 違反レポートをサポートしているわけではありません。

まとめ

この記事では、ウェブ デベロッパーが Reporting API を使ってクライアント側の問題を収集する方法と、収集したレポートから実際の問題を抽出する際の課題について説明しました。また、その課題を解決するために Google がどのようにレポートをフィルタリングして処理しているかを説明し、同様のソリューションを実現する際に利用できるオープンソース プロジェクトを紹介しました。この情報が役立ち、Reporting API を活用するデベロッパーが増え、結果としてウェブサイトの安全性と持続可能性が向上することを願っています。


学習リソース



Reviewed by Eiji Kitamura - Developer Relations Team

Google の Chrome / Developer Relations チームでは、内容によって様々なチャネルから情報発信を行っています。ウェブ開発者の皆さんに少しでもお役に立つよう、Google 公式のウェブ開発者向けリソースをまとめました。

Chromium BlogChrome に関する公式の開発者向け情報を発信しています。英語になりますが、同じ内容は翻訳して Google Developers Japan Blog からも日本語で発信しています。

web.dev標準化を前提としたウェブ API を中心に、Chrome に限定されないウェブ開発のベストプラクティスを紹介しています。現在英語が中心ですが、ローカライズできるよう開発を進めています。
  • web.dev/blog: ブログ形式で最新情報を発信しています。
  • web.dev/newsletter: 購読することでメールで最新情報をお届けします。(現在英語のみ)

Chrome DevelopersChrome DevTools や Extension など、Chrome 独自機能の解説や API リファレンスを掲載しています。

Google Chrome Developers - YouTube channelChrome チームによる開発者向け情報の動画配信。API の使い方解説やイベントの映像配信など。

Chrome StatusAPI の開発状況、チャネルごとのリリース時期、機能の使用状況統計情報など、Chrome の開発状況を確認することができます。

Chromium Bug TrackerChromium のバグトラッカー。Chrome でバグを見つけた場合はこちらからレポートしてください。

Twitter公式
  • @ChromiumDev: Chrome Developers - Chrome 関連の開発者向け情報を主に英語で発信
  • @googledevjp: Google Devs Japan - Chrome に限らない Google の開発者向け情報を日本語で発信
社員個人アカウント
  • @agektmr: Eiji Kitamura / えーじ - Developer Advocate
  • @sisidovski: Shunya Shishido - Web Ecosystem Consultant
  • @uskay: Yusuke Utsunomiya - Web Ecosystem Consultant
  • @chikoski: chikoski - Developer Advocate
  • @piropiroanna: きらきら☆あんなたん - Web Ecosystem Consultant
  • @KenjiBaheux: Kenji Baheux - Chrome Product Manager




5 月 18 日から 20 日(日本時間 5 月 19 日から 21 日)に Google I/O 2021 がオンラインで開催されます。

これにあわせて、Google I/O 2021 で発表される内容から、特に日本のデベロッパーの皆さまにお届けしたい話題をご紹介する「I/O Extended for Web developers 2021」を 6 月 8 日に開催します。

当日は、日本の Google 関係者がモデレーターとして、動画の解説、リアルタイムでお寄せいただく質問に回答する場も設けています。

無料のオープンウェビナーとなっておりますので、皆さまお誘い合わせの上、ぜひご参加ください。(事前登録必須です)

開催概要
  • 日時 : 2021 年 6 月 8 日 15:00 〜 17:00
  • 形式 : ウェビナー
タイムテーブル:
  • 15:00 〜 15:05 オープニングのご挨拶

  • 15:00 〜 15:35 Web Vitals の最新情報:(Annie Sullivan & Elizabeth Sweeny)
    • このセッションでは、ツールを活用し、Web Vitals を測定および最適化する方法に関する最新のリサーチ結果を共有致します。
      [ナビゲーター] えーじ & 宍戸俊哉

  • 15:35 〜 16:05 Web のプライバシー強化に向けた準備:(Maud Nalpas)
    • ユーザーはさらなるプライバシーの強化を求めており、Web エコシステムはこの要望に応えるよう進化し、プライバシーはデフォルトになりつつあります。 Web のプライバシー強化に対応するうえで、Web サイトにどのような準備が必要でしょうか。ここでは、何がどのような理由で変わりつつあるか、サードパーティ Cookie の段階的廃止に備える方法、役立つツール、試してみるべき新しい API、ユーザーが使用できる Chrome のコントロールなど、デベロッパーに必要な情報を順番に説明します。
      [ナビゲーター] えーじ & 宍戸俊哉

  • 16:05 〜 16:35 オプトインとしてのセキュリティからデフォルトのセキュリティへ: (えーじ & Camille Lamy)
    • Spectre は、Web のセキュリティ環境に大きな影響を与えました。このセッションでは、Web サイトの安全性と機能性を維持するためのセキュリティ ヘッダーに関するベスト プラクティスについて、お話をさせて頂きます。また、今後予定されている重要な変更や新しいデフォルトについても紹介します。
      [ナビゲーター] えーじ & 宍戸俊哉

  • 16:35 〜 16:55 Q & A
    • イベント配信画面右側に表示されている「質問入力ツールの Slido」を通して随時送っていただいた質問から、「いいね」が多いものを優先して回答させていただきます。
      ※自然検索に関する質問は取り上げない可能性があります。具体的な質問がある場合は #Google検索オフィスアワーやヘルプ コミュニティをご活用ください。

  • 16:55 〜 17:00 クロージングのご挨拶

※登壇者、内容は変更される場合がありますので、最新情報は Web サイトでご確認ください

参加申し込み

こちらの Web サイトからお申し込みください。ライブ配信やアーカイブの再生・閲覧、当日のQ&A で取り上げるご質問は Web サイトからのみ可能です。当日でも参加登録は可能ですが、事前に登録を完了いただくと、スムーズです。なるべく登録をお済ませの上お待ち下さい。

*参加登録は、参加者(視聴者)お一人ごとにお願いいたします
*参加者人数には制限を設けておりません。
*プログラムの内容は予告なく変更になることがございます


皆さまのご参加をお待ちしております。


Posted by Tamao Imura - Developer Marketing Manager, Platforms and Ecosystems

この記事は The AMP Blog の記事 "Contributions to Web Platform Interoperability (First Half of 2020)" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


ウェブ デベロッパーは、ウェブの相互運用性の問題と重要な機能の実装不足という課題に直面し続けています。オープンソース プロジェクトである AMP Project は、デベロッパーを代表してこういった問題の解決に貢献しています。 ここ数年、ブラウザ間で高度な予測可能性と相互運用性を実現するために、Igalia と連携して作業を行っています。 私たちが望む標準や相互運用性のレベルを実現するには、長いプロセスが必要になるかもしれません。 新機能を軌道に乗せるには試験運用が必要になることが多く、その過程では軌道修正も必要です。最終的に多くの実装やユーザーがその領域に集まり、実に面白いことを行ったり周辺部に問題が見つかったりする中で、相互運用性の対応を続けることになります。
AMP と Igalia は、このプロセスの全段階で重要な役割を果たし、前進させるサポートができたことをうれしく思っています。 以下では、今年の上半期に行ってきたことについて説明します。

イメージのデフォルト アスペクト比

以前のブログ投稿では、WebKit で Intrinsic Size 属性を実装する実験について触れました。これは標準化の議論に向けた貴重な原型となりましたが、最終的には別のアプローチに切り替えることで意見が一致しました。この新たなアプローチでは、新しい属性を作らずに同じユースケースに対処します。考え方は非常にシンプルで、指定されたイメージの幅と高さの属性を使ってデフォルトのアスペクト比を決めます。“width: 100%; height: auto;” などの追加の CSS を使えば、ブラウザはイメージがダウンロードされるのを待たなくても、最終的なサイズを計算できます。これにより、ユーザー エクスペリエンスを低下させる再レイアウトの発生を回避できます。この機能は FirefoxChromium で実装されており、WebKit でも同様の作業を行いました。実装にあたって、Safari Tech Preview と最新の iOS 14 ベータ版でデフォルトでオンになっているフラグを使用しました。

スクロール

スクロール機能を強化する作業も続けています。WebKit では、スムーズなスクロールを実現する scroll-behavior から着手しました。以前のパッチにより、この機能はデフォルトで無効になっている試験運用版フラグ “CSSOM View Smooth Scrolling” で導入および保護されています。現在、スムーズなスクロールにはプラットフォームに依存しない汎用実装があり、これはウェブプロセスのタイマーによって制御されています。また、ネイティブ iOS UI インターフェースを使った効率的なスクロールを実現するための作業を続けています。
オーバースクロールとオーバースクロールのカスタマイズ(特に scrollend イベント)に関する作業にも着手しました。scrollend イベントは、名前からもわかるように、スクロールが終わったときに発行されます。ただし、相互運用性が十分ではなく、追加のテストが必要でした。そこで、ウェブ プラットフォームのテストにプログラムによるスクロールユーザーのスクロールを追加しました。これには、スクロールバー、ドラッグによる選択、キーボードによるスクロールなどが含まれます。これらの実装が完了し、現在、プログラムによるスクロールと Mac でのユーザーのスクロールで scrollend をサポートする WebKit パッチに取り組んでいます。

Chrome 側では、デフォルトでない書き込みモードでの標準スクロール値の作業を続けています。これは、スクロール API と書き込みモードでの動作に関する一連の興味深い挑戦です。以前は、書き込みモードでの動作には完全な相互運用性はなく、しっかりとした定義もされていませんでした。 相互運用性を実現するには変更が必要で、その変更が安全であるという確約が必要でした。 現在の変更は、ランタイム フラグ “CSSOM View Scroll Coordinates” で実装および保護されています。Google のエンジニアのサポートを受けつつ、デフォルトで有効にできるほど安全かどうかを判断するために、ユーザーデータを収集しようとしています。

もう 1 つの軽微な相互運用性に関する修正は、フレームの scrolling 属性が “noscroll” または “off” の値を確実に認識できるようにすることでした。Firefox は既に対応していましたが、現在は ChromiumWebKit も対応しました。

IntersectionObserver と ResizeObserver

以前のブログ投稿で触れたように、WebKit で IntersectionObserver(iOS 12.2 で有効化)と ResizeObserver(iOS 14 ベータ版で有効化)の実装を進めました。今年は、これらの便利なデベロッパー API に対して機能強化を行いました。

ユーザーから、内部 iframe のルートの監視が難しいという報告があったため、root パラメータとして明示的なドキュメントを受け取るように仕様が変更されました。これは Chromium で実装され、同じ変更を WebKitFirefox でも実装しました。この機能は、現在 Safari Tech Preview、iOS 14 ベータ版、Firefox 75 で利用できます。

さらに、デフォルトでないズームレベルで ResizeObserver のサイズ計算が正しくないというバグが報告されています。これは、特に Twitter のフィードでバグを引き起こしていました。4 月にパッチを作成し、最新の Safari Tech Preview と iOS 14 ベータ版で修正が利用できるようになっています。

リソース読み込み

私たちが関わってきたもう 1 つの取り組みは、リソースの読み込みを管理してパフォーマンスを向上させる方法を効率的にブラウザに伝えることができるように、制作者に制御や機能を提供することです。

遅延読み込みに関するこの作業は 2019 年に始まり仕様とともにかなり成熟しています。
そのため、WebKit の遅延イメージ読み込みの実装は、関連する WPT テストを通過し、Firefox と Chrome の実装に匹敵する機能になっています。しかし、予想どおりかもしれませんが、利用方法や実装ノートを比較したところ、遅延イメージ読み込みを始めるべきタイミングの判断が十分明確に定義されていないことがわかっています。 リリースでこの機能を有効化する前に、この点を改善する作業が必要です。関連作業であるフレームの遅延読み込みについては、仕様が定まっていないため、まだ作業を開始していません。

さらに、stale-while-revalidate の実装も追加しました。stale-while-revalidate Cache-Control ディレクティブを使うと、ブラウザが新しいバージョンをチェックする間に古いアセットを提供できる猶予期間を指定できます。これは、たとえばフォントなど、ある程度の古さを許容できる必須ではないリソースに便利です。この機能は、最近の WebKit トランクで有効になりましたが、最新の iOS 14 ベータ版ではまだ無効になっています。

キャッシュ パーティショニング メカニズムを考慮して WebKit のプリフェッチを改善するための貢献も行われました。この作業を有効化できるようになるには、さらにいくつかのパッチが必要になります。また、さらに細かい仕様確定(事前ナビゲーションなど)が必要になる可能性もあります。加えて、さまざまな通常のフェッチの改善も行われ、フェッチ WPT スコアが改善されました。次に例を示します。

次のステップ

スクロールやリソース読み込みの改善には、まだたくさんやるべきことがあります。scrollend イベント、オーバースクロールの動作とスクロールの動作、遅延読み込み、stale-while-revalidate、プリフェッチなどの機能には、今後も注力を続けてまいります。

イメージのアスペクト比計算に関する作業の続きとして、さらに汎用的な CSS aspect-ratio プロパティについて検討する予定です。ウェブ デベロッパーが自分のサイトで優れたユーザー エクスペリエンスを提供するうえでは、Web Vitals プロジェクトで提供されたようなパフォーマンス指標も欠かせません。そのため、Safari でのサポートについて積極的に調査したいと考えています。

私たちは、プラットフォームの改善作業に夢中です。協力し合いながら、あらゆる人にとってのウェブの常識を改善できることをうれしく思っています。

Reviewed by Chiko Shimizu - Developer Relations Team

この記事は ウェブ エコシステムのカラオケ隊長、Dion Almaer による Chromium Blog の記事 "web.dev LIVE: A digital event over three days and three time zones" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。




先週、私のカレンダーは、多くの皆さんが Google I/O に集まってくるだろうというアラートを常に表示していました。それを見ると、今は直接集まることはできないという悲しい気持ちになります。この厳しい時期、ウェブ デベロッパーの皆さんは、必要なことに集中する、重要な情報を利用できるようにする、オンラインでの取引を可能にする、在宅での仕事や教育を可能にするといったことに貢献しています。ウェブ デベロッパーが果たしている役割にはとても感銘を受けます。皆さんに称賛を送ります。

私たちも、そのお手伝いをしたいと考えています。

そこで、3 日間のデジタル イベント web.dev LIVE を計画しています。ウェブ デベロッパーの皆さんが自宅から気軽に参加して、プラットフォームの最新アップデートについて話を聞いたり、最新のウェブ技術を学んだり、他のデベロッパーと交流したりできるイベントです。COVID 関連の作業の最前線に立ってコミュニティを前進させているデベロッパーも集まります。

このイベントは、6 月 30 日から 7 月 2 日にかけて行われ、web.dev/live から 3 時間の短いコンテンツ(英語)がストリーミングされます。

皆さんのタイムゾーンに合わせてお届け

デジタルのみのイベントを計画するのは、おもしろい挑戦です。物理的に集まることはできなくても、皆さんのソファやキッチン、裏庭のハンモックなどにすばらしいコンテンツを直接お届けできます。デジタル イベントは、物理的な制約を超えるチャンスでもあります。会場の広さという制限はなくなり、ボタンをクリックするだけで、文字通り世界中の誰もが「参加」できます。(私たちは、ウェブ コミュニティの一員として、これを実現できたことを日々誇りに思っています!)

実際にすべての地域を対象にしたイベントになるように、私たちは 3 つのタイムゾーンに「出張」します。そのため、皆さんが活動している時間帯にリアルタイムで質問にお答えすることができます。毎日その日だけのコンテンツがあるので、3 日間すべてに参加することもできます。後ほどオンデマンドでご覧いただくこともできますが、どのタイムゾーンのデベロッパーも、少なくとも 1 回は直接質問に回答してもらえる機会があります。

ライブイベントの開催時間

  • 一日目:日本標準時間  7 月 1 日 午前 1 時 - 4 時(アメリカ大陸のデベロッパーに最適)
  • 二日目:日本標準時間  7 月 1 日 午後 9 時 - 12 時(ヨーロッパおよびアフリカのデベロッパーに最適)
  • 三日目:日本標準時間 7 月 2 日 午後 4 時半 - 7 時半(アジアおよびオーストラリアのデベロッパーに最適)
このイベントを、Google カレンダーに設定するリンクはこちらです。(英語でインビテーションが届きます)

たくさんのすばらしいコンテンツやお楽しみを準備していますので、イベント関連のお知らせを受け取れるように、ぜひ web.dev/live でサインアップしてください。


Posted by Eiji Kitamura - Developer Relations Team

この記事は Jung von Matt のデベロッパー、Thorsten Harders、Sebil Satici による The AMP Blog の記事 "In search of the amp.dev search" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


amp.dev では、ケース スタディ、各コンポーネントの動作の詳細、ベスト プラクティスを説明したガイド、詳細なチュートリアル、実行可能なたくさんのコードサンプルなど、AMP を使った開発を簡単にするたくさんのリソースが提供されています。実際、あまりにたくさんのリソースがあるので、デベロッパーがすべての既存コンテンツをすばやく見つけて利用できるような方法が必要になりました。私たちは、それを実現するために、サイトですべてのコンテンツを直接検索できるようにしたいと考えました。本記事では、amp.dev の検索を実装した手順について、順を追って説明します。




TL;DR: 新しい amp.dev の検索は、<amp-lightbox><amp-list><amp-autocomplete><amp-mustache>、そしてもちろん、これらすべてをまとめる <amp-bind> を使って構築されています。また、Google カスタム検索を活用したカスタム API と、最後の検索クエリと検索結果をキャッシュするService Worker 機能を利用しています。

AMP コンポーネントを使った構築

amp.dev の検索機能の構築には、以下の 3 つの目標がありました。
  1. すべてのページで専用のレイヤーから検索できること
  2. AMP デベロッパー エクスペリエンスの中核をなす AMP コンポーネントの検索に最適化されていること
  3. 有効な AMP 機能を使って実装すること

検索レイヤーの表示と非表示(amp-lightbox を利用)

ウェブを見渡せば、さまざまな種類の検索機能を見つけることができます。シンプルな入力項目になっているものもあれば、素敵なアニメーションで展開されたり折りたたまれたりするものもあります。結果のページングを実現するためにページ読み込みを行ったり、結果を非同期的に表示したりするものもあります。また、検索キーワードの候補を自動で表示してくれるものもあれば、そうでないものもあります。amp.dev では、こういったアプローチから最善の方法を組み合わせることで、できる限りユーザーの邪魔にならず、それでいてすばやくアクセスできるソリューションを生み出したいと考えました。そこで、全画面レイヤーの中に検索機能全体をカプセル化して、以下を実現することにしました。
  • ユーザーにとって興味深い記事(例: 公開された新しいガイドやコンポーネント)の候補は、ユーザーがアクセスしているページにかかわらず表示する
  • ユーザーがページ内の他の要素によって惑わされることがないようにする
  • 別の結果ページを読み込むのではなく、検索結果をインラインですばやく表示する
これらのニーズを満たすために、<amp-lightbox> を引き続き利用することにしました。このコンポーネントは、検索レイヤーの表示と非表示を簡単にしてくれるだけでなく、AMP フロントエンドとの統合に役立つアクションやイベントも提供しています。

シームレスな操作の追加

ユーザー エクスペリエンスの観点から言えば、ユーザーが検索クエリの入力と結果の参照とをシームレスに行き来できることがとても重要です。ユーザーが検索レイヤーを開くと、自動的に入力項目にフォーカスが移動し、ユーザーは即座に入力を始めることができます。検索レイヤーを閉じると、キーボードを使っている人が以前と同じ位置で作業を続けられるように、フォーカスが検索トグルに戻ります。
この機能は、<amp-lightbox> のオープンおよびクローズ イベントと、グローバル フォーカス アクションを組み合わせて実装しました。
<amp-lightbox layout="nodisplay"
      on="lightboxOpen:searchInput.focus;
          lightboxClose:searchTriggerOpen.focus"
      scrollable>

検索結果の一覧表示(amp-list と amp-mustache を利用)

ページへの検索結果の表示には、<amp-list> コンポーネントを使っています。このコンポーネントには、既にページングと無限スクロールが組み込まれています。これらはまさに、検索結果を一覧表示する際に必要な機能です。  実際の検索はサーバーサイドで実装されており、API エンドポイント /search/do 経由でアクセスできます。その結果、次のような JSON オブジェクトが返されます。
{
  "result": {
    "pageCount": 10,
    "pages": [
      {
        "title": "Some title",
        "description": "Description",
        "url": "http://amp.dev/some/link"
      },
      ...
    ]
  },
  "nextUrl": "/search/do?q=amp&page=2"
}
<amp-list> の完全な検索 URL を更新するために、[src] 属性を入力クエリにバインドすることで、amp-bind を使っています。また、無限スクロールを実現するために load-more 属性を設定し、後続の検索が実行される際にクリーンな再読み込み操作を実現できるように、reset-on-refresh 属性を設定します。<amp-mustache> テンプレートでは、結果オブジェクトのデータを使って動的に一覧をレンダリングします。コードは次のようになります。
<amp-list id="searchList"
          src="/search/initial-items"
          [src]="query ? '/search/initial-items : '/search/do?q=' + 
encodeURIComponent(query)"
          binding="no"
          items="."
          height="80vh"
          layout="fixed-height"
          load-more="auto"
          load-more-bookmark="nextUrl"
          reset-on-refresh
          single-item>
  <template type="amp-mustache">
    <div class="search-result-list">
      {{#result.pages}}
      <a href="{{url}}">
        <h4>{{title}}</h4>
        <p>{{description}}</p>
      </a>
      {{/result.pages}}
    </div>
  </template>
</amp-list>

重要な候補の表示(amp-autocomplete を利用)





アナリティクス データによると、amp.dev にアクセスするデベロッパーの目的で最も多いのは、AMP コンポーネントのドキュメントやサンプルを参照することです。そのため、これらのコンテンツをできる限り探しやすくしたいと考えました。<amp-autocomplete> は、AMP で自動候補表示をすぐに実現できるソリューションです。ここでの目的は、利用できるすべての AMP コンポーネントの候補を自動表示することです。静的データソースは /search/autosuggest エンドポイントで提供され、autocomplete コンポーネントは filter="substring" 指定を利用してクライアントサイドで候補を生成します。
<amp-autocomplete filter="substring"
                  min-characters="1"
                  on="select:AMP.setState({    query: event.value })"
                  submit-on-enter="false"
                  src="/search/autosuggest"
>
    <input placeholder="What are you looking for?">
</amp-autocomplete>

検索の実行(amp-form を利用)

ユーザーは、自動表示されたいずれかのオプションを選択するか、フォームを送信することによって検索を呼び出します。実際の検索リクエストを実行するために、URL パラメータとしてステート query を利用します。
<amp-list [src]="'/search/do?q=' + encodeURIComponent(query) + '&locale=en'">
フォームが送信されたときと autocomplete コンポーネントが select イベントを送信したときの両方の場合で、amp-autocompleteon アクションに基づいて query が更新されます(それによって amp-list がレンダリングされます)。
<form action-xhr="/search/echo"
      on="submit:
          AMP.setState({ query: queryInput }),
          searchResult.focus,
          searchList.changeToLayoutContainer"
      method="POST" target="_top">
  <amp-autocomplete filter="substring"
                    min-characters="1"
                    on="select:AMP.setState({ query: event.value })"
                    submit-on-enter="false"
                    src="/search/autosuggest"
  >
    <input id="searchInput"
           placeholder="What are you looking for?"
           on="input-throttled:AMP.setState({ queryInput: event.value })"
    >
    <button disabled [disabled]="!queryInput">Search</button>
  </amp-autocomplete>
</form>
フォームが送信されたときは、最初のエントリに対して直接キーボード ナビゲーションを開始できるように、検索結果コンテナにフォーカスを移します。さらに、コンテンツに応じてリストの高さを変えて縮小できるように、<amp-list>changeToLayoutContainer を呼び出します。この例では、フォームの submit イベントの結果は必要ないので、単純にエコー アクションに向けています。補足: 近日中にフォームを使わずに `amp-autocomplete` を利用できるようになる見込みなので、将来的にこれは不要になります。

Service Worker による以前の検索結果のキャッシュ

検索の最初のバージョンをリリースした後、かなり早い段階で関連機能リクエストを受け取りました。それは、ユーザーが別のページに移動したときでも、最後の検索クエリの結果を表示し続けるというものでした。
これを実現するために、AMP のワンライン Service Worker である amp-sw を利用しました。amp-sw は、キャッシュやオフライン ページといった基本的な PWA 機能を提供します。これを拡張することで、最後の検索クエリとそれに対応する検索結果を保存するようにしました。
検索を始めるとき、以前の検索クエリとその結果を表示します。そうでない場合は、候補記事の一覧を表示します。ページを読み込むときは、サーバー エンドポイント /search/latest-query を使って amp-state オブジェクトを初期化し、検索入力項目と検索結果を設定します。
// search.html
<amp-state id="query" src="/search/latest-query"></amp-state>

<amp-list src="/search/initial-items"
          [src]="query ? '/search/initial-items : '/search/do?q=' + encodeURIComponent(query)"
...
</amp-list>
ここでのポイントは、このサーバー エンドポイントが実在しないことです。魔法の処理を行っているのは Service Worker です。Service Worker はこのルートをインターセプトし、ネットワークから元々のレスポンスを読み込む代わりに、ユーザーが最後に検索をリクエストした際にキャッシュしておいた検索クエリと検索結果から新しいレスポンスを作成し、それをページに送り返します。
最後の検索クエリの保存は、リクエストする URL から正規表現を使って query パラメータを取得し、新しく作成したレスポンス オブジェクトをキャッシュに格納することで実現します。
検索リクエストに一致するエントリがキャッシュ内に存在するかどうかは、ルート ハンドラがチェックします。存在する場合は、キャッシュから即座に結果が返されます。そうでない場合、リクエストはサーバーに到達し、結果は以降の呼び出しに備えてキャッシュされます。
// serviceworker.js
async function searchDoRequestHandler(url, request) {
  const searchQuery = decodeURIComponent(url.search.match(/q=([^&]+)/)[1]);
  const cache = await caches.open(SEARCH_CACHE_NAME);


  cache.put(SEARCH_LATEST_QUERY_PATH, new Response(`"${searchQuery}"`));

  let response = await cache.match(request);
  if (response) return response;

  response = await fetch(request);
  if (response.status == 200) {
    cache.delete(request, {
      ignoreSearch: true,
    });
    cache.put(request, response.clone());
  }

  return response;
}
こうすることで、ユーザーが別のページで検索レイヤーを開いたときでも、自動的に以前の検索結果を受信でき、中断したところから作業を継続することができます。
ハンドラ関数は、次のようにして登録しています。
// serviceworker.js
self.addEventListener('fetch', (event) => {
  const requestUrl = new URL(event.request.url);
  if (requestUrl.pathname === '/search/do') {
    event.respondWith(searchDoRequestHandler(requestUrl, event.request));
  }
});
<amp-state><amp-list> といった AMP コンポーネントは、リモート エンドポイントからデータを読み込みます。Service Worker API の助けを借りてリクエストをインターセプトし、それを動的に変更するというのは、こういったコンポーネントが利用するデータをパーソナライズしたい場合に適した方法です。ユーザーの最後の検索クエリをキャッシュすることで検索のユーザー エクスペリエンスを高めるのも、その一例です。

まとめ

amp.dev の検索機能を実装することで、ユーザーが直感的かつ効率的にサイトのコンテンツへの正確なナビゲーションを行えるようにするという目標を達成できました。さらにユーザー エクスペリエンスを向上させるため、Service Worker の機能を使って以前の検索結果をキャッシュできるようにもしました。
すばらしいのは、JavaScript を 1 行も使わずにこの検索機能を組み込むことができた点です(Service Worker 部分は除きます)。AMP の既存コンポーネントのみで、候補の自動表示や無限スクロールなどの便利な機能を組み込むことができました。これらを使わずにこういった機能を実装するのは、かなり難しい作業になるはずです。


投稿者: Jung von Matt のデベロッパー、Thorsten Harders、Sebil Satici


Reviewed by Chiko Shimizu - Developer Relations Team

この記事は Jeffrey Jose による The AMP Blog の記事 "CCPA support in AMP" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

投稿者: Google の AMP Project プロダクト マネージャー、Jeffrey Jose


カリフォルニア消費者プライバシー法(CCPA)は、データ プライバシーに関する新しい法律で、カリフォルニア州の住民のさまざまな権利を保障するものです。この法律は、カリフォルニアでビジネスをしており、収益やデータ処理などに関する複数の基準のいずれかに当てはまる企業に適用されます。

AMP 同意フレームワークのアップデート
サイト運営者からのフィードバックに基づき、AMP 同意フレームワークをアップデートし、サイト運営者が CCPA に準拠するために必要と思われる同意を得られるようにしました。今回の新しいアップデートによって、サイト運営者は複数の同意プロンプトを含めて、ユーザーの場所に基づいて適切なプロンプトを呼び出せるようになります。

複数のサーフェスをまたぐ同意
複数のサーフェスでユーザーの同意を同期したいサイト運営者は、ユーザーの同意情報をサーバー側に保存し、checkConsentHref 属性を通してその情報を <amp-consent> に公開できます。最初にエンドポイントを確認し、その応答によってユーザーの同意プロンプトを表示するかどうかを決めるように AMP を設定することも可能です。さらに、取得済みのユーザー同意情報を、サーバーから、ページに設定されている広告やアナリティクスのベンダーに渡すこともできます。

AMP ストーリーのサポート
AMP ストーリーでは、サイト運営者がストーリー内に CCPA オプトアウト ページへのリンクを作成し、ユーザーの同意を集めることができます。
リファレンス ドキュメントサンプルコードを含む amp.dev もアップデートし、シナリオの例を紹介しています。

今後の予定
さらに簡単に開発できるように、<amp-geo> を拡張し、米国の州レベルでユーザーを検知できるようにすることを計画しています。いつものように、新しいアイデアをお持ちの方は、ぜひ Issue に投稿してください。ユーザー制御に基づく AMP 拡張機能の動作をカスタマイズしたいベンダーの方は、貢献ガイドラインに従って開始してください。

Reviewed by Chiko Shimizu - Developer Relations Team



AMP 用の Next.js

React サーバーサイド レンダリングによる AMP ページの構築が人気を博し、このユースケースをサポートする機能の追加は必然だったと実感しています。React で特によく使われているフレームワークである Next.js との統合も、そのためです。豆知識 : nextjs.org は完全に AMP で構築されています!

amp-script

今年、ゲームチェンジャーとなる <amp-script> がとうとう皆さんの画面にデビューしました。大きな期待を集めたこのコンポーネントによって、AMP ページにカスタム JavaScript を追加したり、AMP ページと非 AMP ページでコードを共有したり、以前はできなかったものを作成したりできるようになりました。


OpenJS Foundation が AMP を歓迎









OpenJS Foundation への参加決定を発表し、次のオープンガバナンス モデルを明らかにしました。OpenJS Foundation のミッションは私たちのミッションと一致します。この組織によってテクノロジー業界の多様な声が集まり、公正なウェブを作るという私たちの取り組みも推進されるでしょう。

AMP が皆さんの受信トレイに









Gmail で AMP for email がリリースされ、ユーザー ファーストな体験が皆さんの受信トレイでも実現しました。メールの送信者は、スムーズな体験やインタラクティブなコンテンツを作成し、エンゲージメントを向上できるようになりました。AMP for email の仕様には、Outlook や Yahoo Mail などの主要なメール プロバイダも関与しています。こういったパートナーとともにメールのエコシステムを変革できることを楽しみにしています。

新しいコンポーネントは Mail.ru でも利用でき、先行ユーザーはすでにすばらしい結果を残しています。インド最大のホスピタリティ企業である OYO は、AMP for email のテストでコンバージョンが 60% 上昇しました。

AMP Conf の成功に「アリガトウ」

毎年開催しており、今年で 3 回目となる #AMPConf が東京で開催され、500 名近くの方に会うことができました。プロダクトの発表に加え、デザインを刷新した amp.dev をお披露目しました。amp.dev は、コードサンプル、テンプレート、ドキュメントなどがすべて集約されたウェブサイトです。AMPConf2020 の準備はすでに始まっています。次のイベントはどこで開催されるか、注目です。

ニューヨークでの AMP Contributors Summit

10 月初旬には、毎年行われている #AMPCS2019 がニューヨークで開催され、AMP の新機能について約 100 名の貢献者と情報交換をしました。単なる会話にとどまらず、分科会も開催してプロジェクトの改善に取り組み、その過程で AMP にいくつかの驚きをもたらしました。

強力なコミュニティ

1,000 名近くの人が AMP にコードを寄贈し、あらゆる人のために高速でよりよいウェブをデザインすることに協力してくれています。すべての AMP プロジェクトのリポジトリを合わせると、今年だけで 341 名の貢献者が 18,300 回以上の寄贈をしています。








コードの向こうにいる人々

コミュニティは、AMP の進化に大きな役割を果たしています。知っていることを共有し、知らないことを学ぶ場所こそがコミュニティです。そこで、コミュニティのメンバーが AMP を利用してどのように実世界で違いを生んでいるかを理解するため、「コードの向こうにいる人々」シリーズを始めています。

19 回の新しい Roadshow を実施

今年、AMP は 19 回遠征し、世界中で Roadshow をしました。ヨハネスブルグからソウルまで、合わせて 1,600 名の皆さんが AMP を見に来てくださいました。

Roadshow は、デベロッパーが本格的な AMP ウェブサイトを自信を持って構築できるように企画されています。そのため、4 つの主要な柱であるデザイン、インタラクティブ性、DevOps、収益化について徹底的に取り上げ、一歩抜きんでるために必要なものすべてがそろうようになっています。

2020 年の開催場所については、AMP Roadshow ページをご覧ください。自分の住む場所が掲載されていない方は、ぜひお知らせください。私たちはいつも新しい場所を探しています。または、自分でイベントを開催することもできます。素材はすべて提供します。皆さんに必要なのは、来場することだけです!






2020 年のビジョン

今年はすばらしい 1 年でした。高速でユーザー ファーストなウェブをあらゆる人のために作成している皆さんの創造性と献身に感謝します。私たちは、AMP の今後に大きな期待を寄せています。新しい年も、皆さんとともにこの作業を続けてゆけることが楽しみです。AMP 関連のすべてのプロジェクトの最新情報を得て、2020 年の私たちのビジョンを見るには、ニュースレターに登録してください

投稿 : Alex Durán(Google の AMP プロジェクト マーケティング)

Reviewed by Chiko Shimizu - Developer Relations Team
この記事は Alex Durán による The AMP Blog の記事 "AMP 2019 Decoded: Thank You for an Incredible Year" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。






AMP にとって 2019 年は大きな当たり年でした。コミュニティは拡大を続け、ウェブサイト、 メール、ストーリー、広告の全体にわたってすばらしい体験を作り出しています。ここでは年初に戻って、ともに達成してきたすべてのマイルストーンを振り返ります。こちらの動画を見て、以下をお読みください。








AMP 用の Next.js

React サーバーサイド レンダリングによる AMP ページの構築が人気を博し、このユースケースをサポートする機能の追加は必然だったと実感しています。React で特によく使われているフレームワークである Next.js との統合も、そのためです。豆知識 : nextjs.org は完全に AMP で構築されています!

amp-script

今年、ゲームチェンジャーとなる <amp-script> がとうとう皆さんの画面にデビューしました。大きな期待を集めたこのコンポーネントによって、AMP ページにカスタム JavaScript を追加したり、AMP ページと非 AMP ページでコードを共有したり、以前はできなかったものを作成したりできるようになりました。


OpenJS Foundation が AMP を歓迎









OpenJS Foundation への参加決定を発表し、次のオープンガバナンス モデルを明らかにしました。OpenJS Foundation のミッションは私たちのミッションと一致します。この組織によってテクノロジー業界の多様な声が集まり、公正なウェブを作るという私たちの取り組みも推進されるでしょう。

AMP が皆さんの受信トレイに









Gmail で AMP for email がリリースされ、ユーザー ファーストな体験が皆さんの受信トレイでも実現しました。メールの送信者は、スムーズな体験やインタラクティブなコンテンツを作成し、エンゲージメントを向上できるようになりました。AMP for email の仕様には、Outlook や Yahoo Mail などの主要なメール プロバイダも関与しています。こういったパートナーとともにメールのエコシステムを変革できることを楽しみにしています。

新しいコンポーネントは Mail.ru でも利用でき、先行ユーザーはすでにすばらしい結果を残しています。インド最大のホスピタリティ企業である OYO は、AMP for email のテストでコンバージョンが 60% 上昇しました。

AMP Conf の成功に「アリガトウ」

毎年開催しており、今年で 3 回目となる #AMPConf が東京で開催され、500 名近くの方に会うことができました。プロダクトの発表に加え、デザインを刷新した amp.dev をお披露目しました。amp.dev は、コードサンプル、テンプレート、ドキュメントなどがすべて集約されたウェブサイトです。AMPConf2020 の準備はすでに始まっています。次のイベントはどこで開催されるか、注目です。

ニューヨークでの AMP Contributors Summit

10 月初旬には、毎年行われている #AMPCS2019 がニューヨークで開催され、AMP の新機能について約 100 名の貢献者と情報交換をしました。単なる会話にとどまらず、分科会も開催してプロジェクトの改善に取り組み、その過程で AMP にいくつかの驚きをもたらしました。

強力なコミュニティ

1,000 名近くの人が AMP にコードを寄贈し、あらゆる人のために高速でよりよいウェブをデザインすることに協力してくれています。すべての AMP プロジェクトのリポジトリを合わせると、今年だけで 341 名の貢献者が 18,300 回以上の寄贈をしています。








コードの向こうにいる人々

コミュニティは、AMP の進化に大きな役割を果たしています。知っていることを共有し、知らないことを学ぶ場所こそがコミュニティです。そこで、コミュニティのメンバーが AMP を利用してどのように実世界で違いを生んでいるかを理解するため、「コードの向こうにいる人々」シリーズを始めています。

19 回の新しい Roadshow を実施

今年、AMP は 19 回遠征し、世界中で Roadshow をしました。ヨハネスブルグからソウルまで、合わせて 1,600 名の皆さんが AMP を見に来てくださいました。

Roadshow は、デベロッパーが本格的な AMP ウェブサイトを自信を持って構築できるように企画されています。そのため、4 つの主要な柱であるデザイン、インタラクティブ性、DevOps、収益化について徹底的に取り上げ、一歩抜きんでるために必要なものすべてがそろうようになっています。

2020 年の開催場所については、AMP Roadshow ページをご覧ください。自分の住む場所が掲載されていない方は、ぜひお知らせください。私たちはいつも新しい場所を探しています。または、自分でイベントを開催することもできます。素材はすべて提供します。皆さんに必要なのは、来場することだけです!






2020 年のビジョン

今年はすばらしい 1 年でした。高速でユーザー ファーストなウェブをあらゆる人のために作成している皆さんの創造性と献身に感謝します。私たちは、AMP の今後に大きな期待を寄せています。新しい年も、皆さんとともにこの作業を続けてゆけることが楽しみです。AMP 関連のすべてのプロジェクトの最新情報を得て、2020 年の私たちのビジョンを見るには、ニュースレターに登録してください

投稿 : Alex Durán(Google の AMP プロジェクト マーケティング)

Reviewed by Chiko Shimizu - Developer Relations Team

この記事は Jung von Matt 開発ディレクター、Matthias Rohmer による The AMP Blog の記事 "Creating Delightful User Experiences Using AMP On Adobe Experience Manager" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

編集者のメモ: 以下のゲスト投稿は、Jung von Matt の開発ディレクター、Matthias Rohmer 氏によるものです

TL;DR: Jung von Matt は、Adobe Experience Manager で AMP を使用して、BMW によるすばらしいユーザー エクスペリエンスの実現をサポートしました。


クライアントのプロジェクトを実装する際、使用するテクノロジーを自由に選べるというのは、かなり珍しいことです。通常、エンタープライズ ソリューションを選んだクライアントは、その選択肢を補完しつつ、将来の成長を見込めるプロダクトやサービスを探します。

2017 年、BMW は自らのブランドのウェブサイト www.bmw.com を再構築するパートナー企業を探しているとき、先ほど述べた補完ソリューションを求めていました。ほぼすべての BMW のウェブサイトは Adobe Experience Manager(AEM)を使って構築されていたため、BMW が探していたのは、このようなハイエンド システムを扱えることに加え、AEM の機能を活用してメンテナンスしやすくパフォーマンスの高いウェブサイトを構築できるチームでした。

これは、BMW が既存のサイトで実現できなかった目標でした。既存サイトは、同じバックエンドを共有していながら、さまざまなフロントエンド フレームワークやライブラリが混在していました。私たちはプロセスのかなり早い段階で、このスタックに新しい空気を取り入れることを決めました。そして、全体を支えるフロントエンド テクノロジーとして、AMP を導入することを希望しました。私たちが頭を悩ませ始めたのはそこからです。最適な形で AMP と AEM を統合するには、どんな方法を使えばよいのでしょうか。ましてや、フロントエンド開発に関する前提事項があまりに多い CMS を使うのです。

AMP と AEM を統合する際に解決すべき問題群

いくつかのリサーチを経て、AEM から有効な AMP ページを生成するためには、主に 3 つの課題を解決しなければならないことがわかりました。
  • AMP では、ドキュメントの CSS をすべて `<head>` 内にインラインで記述しなければならないので、AEM のビルトイン ClientLib 機能を使わずに CSS を生成する方法を探す必要があります。
  • すべてのページを有効な AMP にするには、実際にページで使われる AMP コンポーネント用のリソースヒント(`<script async custom-element=”amp-carousel” src=”https://cdn.ampproject.org/v0/amp-carousel-0.2.js“></script>`)のみを生成するメカニズムが必要になります。
  • 戻ってくる訪問者のためにプログレッシブ エンハンスメント(中心的なコンテンツから徐々に表示する戦略)を可能にするには、AEM が AMP ページと非 AMP ページの両方を同時にレンダリングできる必要があります。

AMP で使えるように CSS をインライン化する

AEM には、ページのスタイルを扱うかなり効率化されたアプローチが搭載されています。それを実現する ClientLib メカニズムは、ページに必要なすべての CSS をカテゴリと呼ばれるものに基づいて組み合わせてくれます。このカテゴリに基づいて、テンプレートの `<link>` タグを AEM に生成させます。このタグは、すべてのスタイルを含む生成済みのスタイルシートを指すことになります。

AEM のビルトイン Rewriter パイプラインを活用すると、この `<link>` 要素を使ってスタイルシートを組み合わせ、通常の `<style amp-custom>` タグにすることができます。次のコードスニペット(かなり圧縮されています)を見ると、この変換がどのようなものになるか、大まかにわかっていただけるはずです。
StringBuilder styles = new StringBuilder();
boolean writeStyles = false;

public void startElement(String uri, String localName, String qName, Attributes atts) throws SAXException {
    if (localName.equalsIgnoreCase("link")) {
        // If the element currently in queue is a link tag inspect it
        String href = atts.getValue("href");
        String rel = atts.getValue("rel");

        if (rel.equalsIgnoreCase("stylesheet")) {
          String css = "";
          // TODO: Load the stylesheet from the JCR, store it with others loaded
          // so far and append to styles
        }

        return;
    }

    if (localName.equalsIgnoreCase("style")) {
        if (atts.getIndex("amp-custom")) {
          writeStyles = true;
          // TODO: Use this flag to emit all styles gathered in styles
          // in the transformer's characters method
        }

        return;
    }

    contentHandler.startElement(uri, localName, qName, atts);
}

必要なリソースヒントのみを追加する

AMP の有効性を保証するために解決しなければならないもう 1 つの課題は、先ほどの `<script>` 要素を実際に必要とされるページにのみ追加することでした。これは、プロジェクトに次のカスタム ノードタイプを導入することで解決しました。
    <ampJS
        jcr:primaryType="bmw:ampJSResource"
        bmw:ampCustomElementTag="[amp-video]"/>

すべての AEM コンポーネントにこのタイプの子要素を追加することで、依存先の AMP コンポーネントの情報を持たせます(上の例では amp-video)。ここでカスタム ノードタイプを使うメリットは、ページがレンダリングされる際に安全かつ迅速にノードに問い合わせることにより、必要な AMP コンポーネントを決めることができる点です。これは、次のようなコードになります。

final PageManager pageManager = resource.getResourceResolver().adaptTo(PageManager.class);
final String currentPage = pageManager.getContainingPage(resource).getPath() + "/jcr:content";

final String query = String.format("SELECT * FROM [bmw:ampResourceHint] AS s WHERE ISDESCENDANTNODE(s,'%s')", currentPage);

final Iterator<Resource> result = resource.getResourceResolver().findResources(query, Query.JCR_SQL2);

while (result.hasNext()) {
  Resource queryResource = result.next();
  final String type = queryResource.getParent().getResourceType();
  ValueMap properties = queryResource.adaptTo(ValueMap.class);

  String[] usedComponents = properties.get("bmw:usedAmpComponents", String[].class);
  if (usedComponents != null && usedComponents.length != 0) {
    // TODO: Store all used components somewhere for later rendering
  }
}
このロジック片は、`data-sly-use` 属性と `data-sly-repeat` を組み合わせることで、簡単に HTML テンプレートから呼び出すことができます。これにより、必要なすべてのリソースヒントをページの head に出力できます。

AMP と合わせて PWA を提供する

www.bmw.com では、ユーザーの画面にサイトをできるだけ早く表示されるようにしたいと考えました。これを実現するために、すべての初回訪問者が AMP 版のページを受け取るようにします。同時に、AMP だけでは提供できないものの、PWA(これも AMP がベースになっています)なら提供できる機能も実装したいと考えました。

つまり、このアプリケーションでは、同じドキュメントを 2 つのバージョンで提供できなければなりません。幸運にも、AEM ではこの機能を既に利用できます。そのためには、Sling セレクタを使います。

セレクタを作成するために必要なのは、並列する 2 つのテンプレートを実装することだけです。デフォルトで Sling エンジンが解決するものは、単に `html.html` と呼ばれています。もう 1 つには、セレクタの名前を付けます。今回のケースでは、`pwa.html` としました。これにより、すべての記事は brooklyn-beckham-car-photography.html から純粋な AMP 版としてアクセスするか、brooklyn-beckham-car-photography.pwa.html から PWA 機能でアクセスするかのどちらかになります。

この手法を用いることで、有効な AMP ページと PWA をそれぞれ独立して提供する方法を見つけました。しかし、どうすればユーザーはプログレッシブ ウェブアプリに到達できるのでしょうか。ここで、`amp-install-service-worker` が輝かしいデビューを飾ることになります。この AMP コンポーネントを使うと、ユーザーがいずれかの AMP キャッシュからいずれかのページを開いたときに、www.bmw.com が Service Worker をインストールします。それ以降、brooklyn-beckham-car-photography.html に向かうすべてのリクエストを brooklyn-beckham-car-photography.pwa.html に書き換えることができるようになります。これにより、気づかれることなくユーザー エクスペリエンスを向上させています。

私たちにとって、以上の 3 つが BMW の新しい国際マーケティング サイトを構築する上での主な課題でした。最終的には、既にクリエイティブな形で AEM と AMP に組み込まれている機能を使い、すべての課題を車輪の再発明を行うことなく解決できました。
AMP と Adobe は Bounteous とチームを組み、Adobe Experience Manager でさらに簡単に AMP サイトを構築できるようにしています。詳しく知りたい方や試してみたい方は、こちらをご覧ください。

執筆者: Jung von Matt 開発ディレクター、Matthias Rohmer

Reviewed by Chiko Shimizu - Developer Relations Team

この記事は Alex Durán による The AMP Blog の記事 "People Behind The Code: NDTV’s Rise To Global Heavyweight" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。




New Delhi Television Limited(NDTV)は、インドで最も人気の高いニュース ネットワークの 1 つです。容易にアクセスできるユーザー フレンドリーなデザインによりオンライン コンテンツを提供する先駆的存在でもあります。

スマートフォンの普及が進んでアクセスが容易になるにつれて、2015 年にインド各地でのモバイル利用は爆発的に増加しました。しかし、モバイルデータの速度は地域ごとに大きく異なっていました。NDTV の開発チームは、競争に勝つための手段として読み込み時間の速さの追求にいち早く着手し、早くから AMP を採用しました。





Vikas Kumar(NDTV)
私たちは NDTV 技術チームを率いる Vikas Kumar にお会いし、モバイル ファーストのアプローチに対して AMP の採用がどんな効果をもたらしたかについて話していただきました。


この会社の概要、そしてなぜ AMP を採用したのかについて教えていただけますか? 
NDTV は、元々 1988 年に国営ニュース チャンネルであるドゥールダルシャンのプロダクション ハウスとして発足しました。最終的には、ニュース、スポーツ、エンターテインメント、金融、テクノロジーなど、さまざまな専用コンテンツを提供する、独立した独自チャンネルを立ち上げることになりました。 





私たちは 1999 年に NDTV.com を立ち上げ、この 20 年間で世界のトップ 20 に入るニュース ウェブサイトとなるまでに拡大しました。コンテンツの品質、UX、そしてローカライゼーション(コンテンツは英語、ヒンディー語、タミール語、およびベンガル語で提供されています)に取り組んだ結果、現在では平均して月に 2 億人近いアクティブ ユーザーがいます。 





増加するオンライン オーディエンスにとってページ読み込み時間は非常に重要であることを私たちは認識しています。チームメンバーの 1 人が AMP についての記事を読み、デベロッパーたちと話をしました。後日、当社の Google アカウント マネージャからメールを受け取ったのですが、まさに運命の出会いという感じでした。

全体として、AMP の読み込み時間の速さや SERP でのプリキャッシュなどの最適化が、ユーザー エクスペリエンスの向上に役立ったと感じています。






AMP を統合する上で、何か困難はありましたか?
いいえ、ありませんでした。本当です。SEO は以前からデスクトップからモバイルに移行していましたし、モバイル インデックスのほうがデスクトップ検索よりも先行していましたので、これは正しい選択だという確信がありました。 

サードパーティのウィジェットを統合することや、サイトの既存のルック アンド フィールを維持できるかどうかについては、当初いくらかの不安がありました。しかし、どの問題も容易に解決方法を見出せました。たとえば、カスタム JavaScript を使用するウィジェットや要素のレンダリングには <amp-iframe> が大変便利です。


AMP は事業にどんな効果をもたらしましたか? 
当社のような広告収入で運営されているサイトの場合、表示回数の増加が収益増加を意味します。ページの読み込みの速さとユーザー エクスペリエンスの向上により、常連オーディエンスを確立することができ、サイト拡大に再投資できるだけの収入が得られました。





この業界では、たった 1 秒の違いが直帰率の低減や平均セッション時間の増加に大きな影響を及ぼします。AMP 実装により、First Meaningful Paint(FMP)の平均が 3 秒から 1 秒になりました。 

また AMP によって JavaScript が非同期になったおかげでレンダリングの妨げとならなくなり、読み込み時間の足手まといになっていたサードパーティの JavaScript も除去されました。高速そしてアジャイルが実現されました。 

競争での優位性は時間の経過と共に減少してきました。というのも、インドのほとんどのサイト運営者が AMP を採用し、プラットフォームを活用するようにもなっているからです。それでも、ターゲット オーディエンスとのチャンネルを確立する上で、AMP は当初から本当に役に立ってきました。 


AMP を検討している人にどんなアドバイスをしたいですか? 
利用可能な AMP コンポーネントのすべてについてしっかりと理解することです。それは、強力な初期サイト フレームワークの構築に役立ちます。 





また、AMP ページが有効かどうかを継続的に評価し、もし有効でないなら、時間を取ってその理由を調べるべきです。 AMP ウェブサイト には、期待し得るあらゆることに対応したリソースが揃っており、私たちは絶えずアクセスしています。 



実装が難しい AMP コンポーネントが何かありましたか?今後、試してみたいコンポーネントが何かありますか? 
<amp-live-list> については、使い始めるのにトリッキーな感じがしました。当サイトで選挙結果をリアルタイムでグラフィック表示しようとしたのですが、そこに含まれていたサードパーティの JavaScript が問題を引き起こしていました。
結局、問題をコミュニティに投稿しました。そこで他のデベロッパーの方に助けていただいたおかげで解決策を見出すことができて、本当によかったです。AMP はオープンソースであり、絶えず発展し続けているので、互いに協力し、助け合えるのはすばらしいことです。
最近立ち上がった <amp-web-push> を早くテストしてみたいですね。


AMP の今後について一番期待したいのはどんなことですか? 
AMP が OpenJS Foundation に参加しているといったニュースを聞くのは、それがサイト運営者やデベロッパーを念頭に置いて構築されており、オープン プラットフォームであるという確信につながります。 AMP ストーリーなどの新しいコンポーネントやエクスペリエンスを知ると、わくわくしてきますね。コード 1 行で AMP+ PWA なんて本当にすごいです。
Vikas と彼のチームはまさに AMP の達人です。そして皆さんも達人になれます。AMP の達人になるために必要なものはすべて amp.dev にありますので、ぜひチェックしてみてください。AMP スキルを向上させるには、こちらをご覧ください。

AMP を戦略の一部として使用してこられましたか?皆さんのストーリーについてぜひお知らせください。

AMP の使い方に関するニュース、特長、およびヒントについて常に最新情報を入手するには、当社のニュースレターをお申込みください。


投稿: Alex Durán(Google の AMP プロジェクト マーケティング)

Reviewed by Chiko Shimizu - Developer Relations Team