この記事は 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













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

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 Policy、Trusted Types、Fetch Metadata、Cross-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-extension、moz-extension、safari-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 を簡単に使えるようにするツールがいくつも用意されています。次のようなものがあります。

  • report-uri や uriports などのレポート収集サービス
  • Sentry や Datadog などのアプリケーション エラー モニタリング プラットフォーム

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

まとめ

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


学習リソース



Reviewed by Eiji Kitamura - Developer Relations Team


Chromium Blog

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

web.dev

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

Chrome Developers

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

Google Chrome Developers - YouTube channel

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

Chrome Status

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

Chromium Bug Tracker

Chromium のバグトラッカー。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
先週、私のカレンダーは、多くの皆さんが 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

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

私たちは 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