Google Cloud Next では、最新のオープンソース データ可視化ライブラリ deck.gl（バージョン 8.6）をご紹介しました。このリリースでは、ロケーション インテリジェンス プラットフォーム CARTO、vis.gl Technical Steering Committee（TSC）、Google Maps Platform と Google Cloud のチームとの密接な連携により、Maps JavaScript API の WebGL Overlay View 機能と deck.gl の緊密な統合を実現しました。この統合により、2D と 3D といった形式でデータを美しく可視化し、さまざまな知見を得ることができる deck.gl の機能を活用して、新たなレベルのデータ マッピング エクスペリエンスを作り出せます。
この新しい可視化機能は、地理空間情報を使用する、あらゆるユースケースでご活用いただけます。CARTO チームは、deck.gl と Maps JavaScript API の統合による優れた機能を示すために、テキサス州で電気トラックの可能性を示す各種データソースを可視化したサンプルアプリを作成しました。このサンプルアプリでは、WebGL を利用したマップ機能ツールと deck.gl によって、CARTO がテキサス州の面積と人口の規模を、完全にインタラクティブな地図として可視化した様子がわかります。
deck.gl は、これまで Maps JavaScript API のラスター ベースマップをサポートしてきました。今回の新しいリリースでは、インターリーブ モードでのベクター ベースマップもサポートされるようになります。deck.gl によって Google のベクター地図とデータレイヤを組み合わせることができるようになるため、ラベルや 3D などのコンテンツを損ねることなく深度とオクルージョン（手前にある物体が背後にある物体を隠す状態）を確保した完璧なレンダリングを行う、ピクセル パーフェクトな可視化を実現できます。
具体的な仕組みとしては、同じ WebGL レンダリング コンテキストをベクター ベースマップと deck.gl が共有することで、地図上にレンダリングされる描画のパフォーマンスと柔軟性が向上します。つまり、deck.gl によって地図上にレンダリングされて可視化されるのではなく、地図の一部としてレンダリングされるようになりました。この WebGL コンテキストの共有は容易ではないため、Google Maps Platform チームと CARTO チームが協力して両社のライブラリを進化させ、サポートを提供しています。
例を見てみましょう。
以下のコードでは、オープンソース ライブラリの loaders.gl を使用して CSV ファイルからデータを読み込み、deck.gl の可視化レイヤである Hexagon Layer と Google Maps Platform 用のオーバーレイを作成して、最終的に地図に追加しています。
deck.gl には、可視化表現の作成と既存の可視化の利用に使用できる柔軟性の高いフレームワークが用意されています。参考として、deck.gl ウェブサイトにある例と CARTO のデモギャラリーをご覧ください。
柔軟性の高い deck.gl により、CARTO のテキサス州のデモのように優れた可視化を実現できます。主な可視化表現の種類をいくつかご紹介します。
Hexagon Layer は、集計データを可視化する際に便利です。人口などのプロパティを使用して、六角形の色や高さを定義できます。次の例では、テキサス州の人口がいくつかの大都市に集中していることがわかります。
送電線の可視化のように、大規模なデータセットを可視化する場合は、データをタイルにして徐々に読み込む必要があります。deck.gl では、MVTLayer、TileLayer、Tile3DLayer など、さまざまな既製レイヤが用意されています。
この地図では、約 70 MB に上る送電線の公開データセットを可視化しています。この可視化では、deck.gl の CartoLayer を使用して、データを 512 KB 未満の小さなベクタータイルにして読み込みます。
地図作成機能に加え、アニメーション機能によって、さらに充実した可視化機能とシームレスなユーザー エクスペリエンスが実現しました。以下の例は、テキサス州の再生可能エネルギー源を示しています。
ルートのアニメーション化は、deck.gl の可視化の中でも特によく使用されています。インターリーブのサポートにより、建物など Google Maps Platform の機能をすべて損ねることなくルートを描画できます。
こちらからコードをご確認いただけます。
まず、deck.gl と Google Maps Platform のデモをご覧のうえ、deck.gl のウェブサイトで、レイヤのカスタマイズ方法や独自レイヤの作成方法の詳細をご確認ください。また、テキサス州のデモのソースコードも自由にご利用いただけます。
deck.gl と Google Maps Platform を活用して、優れた視覚化を実現していただければ幸いです。CARTO の詳細情報、無料アカウントの作成方法、BigQuery のデータをオーバーレイする方法については、CARTO のウェブサイトをご覧ください。
Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やフィードバックはページ右上の「お問い合わせ」より承っております。
DevFest は、Google Developer Group（GDG）コミュニティによって世界各地で開かれるデベロッパー向けイベントです。参加者は Android、Firebase、Google Cloud Platform、TensorFlow、Web などの Google のデベロッパー テクノロジーに関する技術情報、知識やアイデアを共有できます。
■ DevFest Kyoto 2021（Flutter テスト講座） 日時 : 2021 年 10 月 23 日（土） 13:30～17:00 場所 : Youtube Live 参加費 : 無料 定員 : オンライン 視聴枠（人数制限なし） オンライン LT 発表枠参加（6 名） 申込サイト : こちら 主催 : GDG Kyoto 内容 : Flutter 開発でテストができるようになる視点や技術基礎と経験談をご紹介
■ DevFest Shikoku 2021
日時 : 2021 年 11 月 7 日（日） 13:00～ 場所 : Google Meet 参加費 : 無料 定員 : オンライン 視聴枠 オンライン LT 発表枠参加（8 名） 申込サイト : こちら 主催 : GDG Shikoku 内容 : FIDO などの Web 上での認証コードをコードラボを通して学習 Google Analytics のデータを集計して可視化するハンズオン
■ DevFest Tokyo 2021 日時 : 2021 年 12 月 11 日（土） 場所 : Youtube Live 参加費 : 無料 定員 : 人数制限なし 申込サイト : こちら 主催 : GDG Tokyo 内容 : 技術テーマは絞らずに幅広くセッションを予定中
Google Cloud Japan は 10 月 20 日 （水）21 時より Google Cloud オフィスアワーを開催いたします。
Google Cloud オフィスアワーは、Google Cloud の最新情報をお届けする場です。また、みなさまからの質問に Google Cloud エンジニアが直接お答えします。当日は YouTube Live で放送します。参加登録不要でご視聴いただけますので、ぜひお気軽にご参加ください。
10 月開催のセッションでは、モダンなアプリケーション開発について紹介します。今回は Next で発表されたアップモダナイゼーションに関する最新情報と、最近リリースされた、デプロイのためのマネージド サービス Cloud Deploy について解説します。
ご視聴はこちら
ご質問投稿はこちら
名 称 Google Cloud オフィスアワー
日 程 2021 年 10 月 20 日（水）21 時～22 時
対 象 開発エンジニア、インフラエンジニア、運用エンジニア
参加費 無料、事前登録不要
ご視聴 URL
Google Cloud Japan は 10 月 20 日 （水）、10 月 27 日 （水）の 2 週にわたって Google Cloud App Modernization OnAir を開催いたします。
Google Cloud App Modernization OnAir では、Google Cloud のエンジニアが、モダンなアプリケーション開発で利用可能な Google Cloud のサービスや、コンテナ、Kubernetes を利用した開発手法、マイクロサービス アーキテクチャの採用、CI/CD パイプラインの構築、DevOps の実践方法、SRE の考え方、アプリケーション セキュリティ、デザインパターンなどをご紹介いたします。
すでに Google Cloud についてご存知のお客様、これから利用を検討しているお客様、ぜひご視聴ください。
この Google Cloud App Modernization OnAir は、一度ご登録いただくと、2 週間分のセッションを追加登録なしでご視聴いただけます。配信当日はライブでの Q＆A も行いますので、ぜひご参加ください。
また、参加ご登録者の中から抽選で 10 名様に Google Cloud T シャツをプレゼントいたします。（全配信終了後に送付いたします）
参加登録 受付中
名 称 App Modernization OnAir
日 程 毎週 水曜日（2 週連続開催） 2021 年 10 月 20 日（水）、10 月 27 日 （水）
参加費 無料（事前登録制）
登 録 https://goo.gle/gcamblog
GCCN (Google Cloud Community News) は Google Cloud に関連したコミュニティの情報をまとめた Web サイトです。
GCCN に対するフィードバックやコミュニティ支援が必要な場合、こちらのフォームからお問い合わせください。
セキュリティは、いたちごっこのようなものです。攻撃者が新しい手法を生み出せば、ブラウザは一歩先を行くために新たな防御策を講じ続けなければなりません。そのため、Chrome は、サンドボックスとサイト分離をベースとした今までにない強固なマルチプロセス アーキテクチャを構築してきました。これらは、ファジングとともに、現在も私たちの主要な防衛線であり続けています。しかし、それも限界に近づきつつあり、この戦略だけに頼って実際に出回っている攻撃に対処することはできなくなっています。
昨年、Google は、重大なセキュリティ バグの 70% 超がメモリの安全性の問題であることを明らかにしました。つまり、C 言語や C++ 言語のポインタのミスによって、メモリが誤解釈されてしまうのです。
メモリの安全性は、世界のソフトウェア エンジニアリング コミュニティが真剣に受け止める必要がある問題です。しかし、これは同時にチャンスでもあります。なぜなら、多くのバグに同じような根本原因があるということは、1 つの対策で相当のバグを撲滅できる可能性があるからです。
Chrome では、このチャンスを活かすため、大まかに次の 3 つの方法を検討しています。
「コンパイル時にチェック」とは、Chrome が皆さんのデバイスにインストールされる前の、ビルドプロセスの段階で安全性を保証することを指します。「実行時」とは、Chrome が皆さんのデバイスで実行されている間にチェックを行うことを指します。
実行時チェックには、パフォーマンスのコストが伴います。ポインタが正しいかどうかをチェックする操作は、メモリや CPU 時間にとっては微少なコストです。しかし、ポインタの数は膨大なので、そのコストは積み重なります。莫大な数のユーザーを持つ Chrome にとって、パフォーマンスは重要です。ユーザーの多くはメモリの少ない低電力モバイル デバイスを使っているため、こういったチェックが増加すれば、ウェブが遅くなってしまいます。
つまり、選択肢 1、コンパイル時に C++ を安全にする方法を選ぶのが理想です。しかし、この言語はそのような設計にはなっていません。この領域で Google が取り組んできたことを詳しく知りたい方は、借用の問題 : C++ の Borrow-Checker の難しさをご覧ください。
そのため、ほとんどは選択肢 2 と 3、つまり C++ の安全性を向上させる（ただし遅くなる）か、別の言語を利用する方法をとらざるをえません。Chrome のセキュリティでは、この両方のアプローチを試しています。
C++ の安全性ソリューションに向けた主な取り組みには、MiraclePtr や ABSL/STL 強化モードなどがあります。どちらも、悪用できるセキュリティ バグの大半を解消することを目指していますが、ある程度のパフォーマンス低下も想定されます。たとえば MiraclePtr は、参照されているメモリを隔離することで解放後の使用に関するバグを防ぎますが、多くのモバイル デバイスではメモリはとても貴重なため、隔離用の領域を割り当てるのは難しくなっています。それでも、MiraclePtr は、ブラウザのプロセスで解放後の使用に関するバグを 50% 以上解消できる可能性を秘めています。今のところ、これは Chrome のセキュリティにとって大きなメリットです。
それと並行して、将来的に Chrome の一部でメモリ安全な言語を使えないかを検討しています。その第一候補は、Mozilla にいる私たちの友人が開発した Rust です。Rust は（ほとんどが）コンパイル時に安全です。つまり、Rust コンパイラは、コードが皆さんのデバイスにインストールされる前にポインタのミスを見つけます。そのため、パフォーマンスが低下することはありません。しかし、C++ と Rust を十分に連携して使えるかどうかという未解決の問題が残されています。また、たとえ明日から Rust で新しい大型コンポーネントを書き始めたとしても、セキュリティ脆弱性の大部分を解消できるのは、おそらく何年も後になるはずです。さらに、既存のコンポーネントの一部を Rust で書けるほど言語の境界を十分にクリーンにできるかという問題もあります。この点は、まだ明らかではありません。Google は、Chromium ソースコード ツリーのユーザーが触れることのない限られた部分で、Rust の実験を始めています。しかし、製品版の Chrome にはまだ含まれておらず、試験運用版のフェーズにとどまっています。
以上の理由から、Google は両方の戦略を並行して追求しています。C++ の安全性向上、Chrome での新しい言語の試行というこの領域の最新情報にぜひご注目ください。
特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2021 年 9 月 23 日の時点で Chrome 95 はベータ版です。
このバージョンの Chrome には、以下のオリジン トライアルが導入されています。オリジン トライアルとして新機能を試せるようにすることで、ウェブ標準コミュニティにユーザビリティ、実用性、有効性についてのフィードバックを提供することができます。以下の項目を含め、現在 Chrome でサポートされているオリジン トライアルに登録するには、Chrome オリジン トライアル ダッシュボードをご覧ください。Chrome のオリジン トライアルの詳細については、ウェブ デベロッパーのためのオリジン トライアル ガイドをご覧ください。Microsoft Edge は、Chrome とは別に独自のオリジン トライアルを行っています。詳細については、Microsoft Edge オリジン トライアル デベロッパー コンソールをご覧ください。
私たちの最終的な目的は、File System Access API のオリジン プライベートなファイル システムと Storage Foundation API を統合し、ブラウザからファイルベースのストレージにアクセスする際のエントリ ポイントの数を減らすことです。その目的に向かう最初の一歩となるのが、新たに提案されたアクセス ハンドルです。この新機能は、ファイルのコンテンツに対してインプレースで排他的な書き込みアクセスを提供できる点で、既存の機能とは異なります。この変更は、フラッシュされていない更新を整合性のとれた形で読み取る機能や、専用ワーカーで同期的に同じ処理をする機能とともに、パフォーマンスを大幅に向上し新たなユースケースの可能性を開くものとなります。このオリジン トライアルに参加したい方は、Chrome オリジン トライアルのエントリをご覧ください。アクセス ハンドラの詳細については、File System Access API: ローカル ファイルへのアクセスを簡素化するに追加されている情報をご覧ください。
Chrome では、HTTP リクエストでユーザー エージェント文字列によって公開される情報量の削減を試行しています。navigator.userAgent、navigator.appVersion、navigator.platform についても、同様の削減をします。ユーザー エージェント文字列は、パッシブなユーザー フィンガープリンティングに使われる可能性があります。このオリジン トライアルに参加したい方は、Chrome オリジン トライアルのエントリをご覧ください。
navigator.userAgent
navigator.appVersion
navigator.platform
Chrome で以前にオリジン トライアルが行われていた以下の機能は、現在デフォルトで有効化されています。
Secure Payment Confirmation は、Web Authentication API を利用して、ウェブで支払いをする際の認証操作を拡張します。この機能によって、上記の API に新しい 'payment' 拡張機能が追加され、銀行などのリライング パーティが PublicKeyCredential の作成にオプトインできるようになります。販売元は、Payment Request API によるオンライン決済の一部として、支払い方法 'secure-payment-confirmation' を使ってこの認証情報を照会できます。
PublicKeyCredential
'secure-payment-confirmation'
この機能により、プラットフォーム認証機能によるスムーズで一貫性のある認証操作を実現できます。欧州連合をはじめとする多くの地域では、ユーザーの銀行による強力な認証がオンライン決済の要件になりつつあります。この機能提案により、ユーザー エクスペリエンスが向上し、既存のソリューションよりもセキュリティが強化されます。
WebAssembly が例外ハンドリングをサポートするようになりました。例外ハンドリングを利用すると、コードで例外がスローされたときに制御フローを抜けることができます。例外は、WebAssembly モジュールの既知の例外でも、インポートされて呼び出された関数がスローした未知の例外でも構いません。
現在、ウェブ デベロッパーは PerformanceObserver.observe() を呼び出す際に buffered オプションを使って、サイトについての過去や未来のパフォーマンス エントリをリスニングできます。ただし、過去のエントリは保存する必要があり、バッファサイズには限界があります。droppedEntriesCount パラメータを使うと、ストレージが一杯であるため失われたエントリがあるかどうかを知ることができます。
PerformanceObserver.observe()
droppedEntriesCount
droppedEntriesCount プロパティは、PerformanceObserver コンストラクタに渡されるコールバックの 3 つ目のパラメータとして指定されるオプションのうちの 1 つです。ここから、バッファが一杯になったことで破棄されたエントリの数がわかります。
PerformanceObserver
EyeDropper API は、ブラウザによるスポイト機能を提供します。これは、カスタムのカラー選択ツールを作るときに利用できます。ウェブ向けのクリエイティブ アプリケーションでは、画面上のピクセルの色をサンプルとして取得できる機能があれば、その恩恵を受けることができます。この機能は、PowerPoint などの多くの OS のアプリケーションに搭載されていますが、ウェブでは実現できません。 一部のブラウザの <input type=color> 要素にはスポイト機能が組み込まれていましたが、通常、スポイト機能は <input> 要素が呼び出すカスタマイズできないポップアップを通してしか利用できないので、これをウェブ アプリケーションのカスタムのカラー選択ツールに組み込むには制限がありました。
<input type=color>
<input>
Windows の Chrome で Sec-CH-UA-Platform-Version の値を更新し、サイトが有意義な Windows プラットフォームの変更を識別できる程度の情報を提供します。これにより、サイトは、オペレーティング システムのバージョンに固有のバイナリ実行ファイルやヘルプ コンテンツを提供できます。現在のユーザー エージェント文字列と既存の Sec-CH-UA-Platform-Version 実装では、Windows コンポーネントのメジャー バージョンとマイナー バージョンが提供されています。しかし、Windows 10 時点で、重要なリリースが行われても通常はどちらの数値も増加しないようになっています。なお、Windows 11 ではどちらの数値も増加しません。数値と Windows リリースとの対応表は、UA Client-Hint のリポジトリの Issue 220 で確認できます。
Sec-CH-UA-Platform-Version
この関数は、ウィンドウとワーカーで利用できます。デベロッパーがこの関数を使うと、キャッチされない JavaScript 例外と同じように、コンソールやグローバルの「error」イベント ハンドラにエラーを報告できます。これは主に、カスタムのイベント ディスパッチ ライブラリやコールバック操作ライブラリで便利です。 この機能により、ライブラリ デベロッパーはブラウザと同じように例外を報告できるようになります。これは、コールバックの実行をカスタム制御する必要がある場合に便利です。
URLPattern は新しいウェブ API で、与えられたパターン文字列と URL をマッチングする機能をオペレーティング システムでサポートします。JavaScript で直接使うことも、サービス ワーカーのスコープなどの別のウェブ プラットフォーム API にパターンを渡して使うこともできます。URL とのマッチングは、ウェブプラットフォーム機能と JavaScript アプリケーションの両方で頻繁に必要になります。利用例として、ウェブ プラットフォームのサービス ワーカーのスコープや、JavaScript フレームワークでの URL ルーティングなどが挙げられます。これまでのウェブ プラットフォーム機能では、それぞれが独自の URL マッチング メカニズムを作成していました。JavaScript では、path-to-regexp などのライブラリを利用していました。
このバージョンの Chrome では、以下のサポートの終了と機能の削除が行われます。現在サポートが終了している機能と以前に削除された機能のリストは、ChromeStatus.com をご覧ください。
Chrome で、FTP URL のサポートを削除します。ブラウザからの FTP の利用率は低く、既存の FTP クライアント機能の改善に注力するのは現実的ではありません。また、影響するすべてのプラットフォームで、機能の豊富な FTP クライアントが利用できます。 Google Chrome 72 以降では、FTP によるドキュメント サブリソースのフェッチと、トップレベル FTP リソースのレンダリングのサポートが削除されています。現在、FTP URL を開くと、リソースの種類によって、ディレクトリ一覧またはダウンロードが表示されます。Google Chrome 74 以降のバグにより、HTTP プロキシを経由した FTP URL へのアクセスがサポートされなくなっています。FTP のプロキシ サポートは、Google Chrome 76 で完全に削除されました。Chrome 86 では、FTP のサポートがプレリリース チャンネル（カナリア版とベータ版）で無効になり、安定版のユーザーの 1% でも試験的に無効化されましたが、コマンドラインから再有効化できました。Chrome 87 では 50% のユーザーで無効になりましたが、ここでもコマンドラインから有効化できました。Chrome 88 以降ではデプリケーション トライアルでのみ利用でき、現在は無効になっています。
数値で終了し、有効な IPv4 アドレスではないホスト名のほとんどは、有効なホスト名として扱われ、DNS のルックアップが行われます（たとえば、http://foo.127.1/ など）。Public Suffix List 仕様によると、この URL のホスト名の eTLD+1 は 127.1 です。これが URL として指定されると、http://127.1/ は URL 仕様によって http://127.0.0.1/ にマッピングされます。これは潜在的に危険です。127.0.0.0.1 も、ユーザーを混乱させるために使われる可能性があります。今後、こういったホスト名を含む URL は、拒否されるようになります。
http://foo.127.1/
127.1
http://127.1/
http://127.0.0.1/
127.0.0.0.1
Chrome では、エージェント クラスタが長期的にオリジンにスコープできるように、クロスオリジンでありながら同一サイト環境であるサイト間での WebAssembly モジュールの共有が非推奨となります。
セキュリティ キーを操作するための Chrome の以前の U2F API が非推奨となり、Chrome 95 でデプリケーション トライアル（オリジンを指定してサポートの終了を延期できるオプトイン機能）が開始されます。この API はデフォルトで有効なまま残されますが、トライアルに参加したサイトでは、トライアル トークンによって鍵が無効化されます。U2F セキュリティ鍵自体は非推奨ではなく、今後も動作し続けます。
影響を受けるサイトは、Web Authentication API に移行する必要があります。もともと U2F API で登録された認証情報は、Web Authentication 経由でチャレンジできます。U2F API でサポートされる USB セキュリティ キーも、Web Authentication API のサポート対象です。
U2F は Chrome オリジナルのセキュリティ キー API で、フィッシングに強い 2 要素認証システムを構築するため、サイトから USB セキュリティ キーに公開鍵認証情報を登録し、チャレンジできるようにします。U2F はオープンなウェブ標準になることはなく、Web Authentication API（Chrome 67 でリリース）に取り込まれました。Chrome は FIDO U2F JavaScript API を直接サポートすることはありませんでしたが、同等の機能を持つ chrome.runtime.sendMessage() メソッドを提供する Cryptotoken と呼ばれるコンポーネント拡張機能を公開しました。U2F と Cryptotoken はメンテナンス モードに入っており、サイトにはここ 2 年間にわたって Web Authentication API への移行が推奨されてきました。
chrome.runtime.sendMessage()
以下のスケジュールは、現時点でのサポート終了と削除の予定です。
2021 年 8 月 31 日の時点で安定版です。googleLegacyAppIdSupport 拡張機能のサポートが追加されました。
2021 年 9 月 23 日の時点でベータ版です。次の変更が実装されました。
2022 年 1 月初旬にベータ版、2 月に安定版となる予定です。デプリケーション トライアルは継続しますが、動作は逆転します。すなわち、デフォルトで API が無効化されますが、トライアル参加者は継続利用することもできます。
Web Stories は、新しいユーザーにアプローチしたり、ユーザーをウェブサイトに呼び戻したりするうえで、有効な手段です。クリエイターやパブリッシャーにとっては、CTA を活用して Web Stories とウェブサイトをつなぐ方法が一般的になっています。そこで、読者のエクスペリエンスをさらに向上させるため、CTA をアップグレードし、一貫性の高い UX を構築しつつ、カスタマイズ性を高める機能を追加しました。
刷新されたコンポーネントを使うと、読者はリンク形式で追加コンテンツに簡単にアクセスできます。読者は、「上にスワイプ」ジェスチャーをするか、行動喚起要素をタップすることで、このコンテンツを表示できます。アタッチメントを開くプロンプトは、そのコンポーネントを使っているすべてのページの最下部に自動的に追加されます。
多くの作成ツールが、すでに <amp-story-page-outlink> のサポートをロールアウトしています。自分で Web Stories を作成している方向けに、読者のエクスペリエンスを向上するために行った主な変更を紹介しましょう。
1. Web Stories のページにプライマリ CTA UI を導入しました。この UI を使うと、任意の外部リンク（<amp-story-page-outlink>）や、ページ アタッチメント（<amp-story-page-attachment>）を開くことができます。
2. 加えて、ストーリーのブランディングに合うすばらしいテーマを簡単に作れるようにしました。クリエイターは、CTA をカスタマイズできるようになっています（色、アイコンなど）。
3. 今後、<amp-story-cta-layer> の機能を置き換える予定ですが、古いストーリーを変更する必要はありません。スタイルをカスタマイズした要素は削除され、amp-story-page-outlink 要素に置き換えられるので、<amp-story-cta-layer> を使っている既存のストーリーは、すべて異なる外観になります。クリエイターやパブリッシャーは、何もしなくてもこの追加のメリットが得られます。
<amp-story-cta-layer>
AMP ストーリー ページ アウトリンクを使うと、1 タップで外部リンクに移動できます。ユーザーが CTA ボタンを押すと、URL が開きます。これまで、この機能は amp-story-page-attachment で処理されていましたが、クリエイターの操作がわかりやすくなるように機能を分離しました。
新しいデザインや API、実装の例は、デモストーリーでご覧ください。
Web Stories を読むのが好きな方も、自分で作成してみたい方も、作成ツールを作っている方も、ぜひアイデアや提案を Web Stories ワーキング グループと共有してください。Github や Slack を通して、私たちに連絡することもできます。また、デベロッパー プレビュー メールグループにもご登録ください。
11 月 9 日（火）から 4 日間にわたり Google Cloud ML Summit を開催いたします。あらゆるアプリケーション、サービスで、AI を活用し新たな価値を創造することが重要な時代になってきています。このイベントでは、データ サイエンティスト、アプリケーション開発者向けに、最新の Google Cloud AI や、機械学習サービスの活用例などをご紹介いたします。
最終日の 12 日（金）には Google Cloud ML Summit で取り上げられる内容に合わせたハンズオンを Qwiklabs を用いてエンジニアの解説付きで開催いたします。
ご登録いただいた方から抽選で 100 名様に Google Cloud オリジナルのサニタイザー ケースをプレゼントいたします。ぜひ、この機会にご登録ください。
お申込み受付中
名 称 Google Cloud ML Summit
対 象 データ サイエンティスト、アプリケーション開発者
登 録 https://goo.gle/ML_gcbg
■ SUBARU Lab でのアイサイト開発における Google Cloud の活用 大久保 淑実 氏 株式会社ＳＵＢＡＲＵ
■ Google を支えるベクトル近傍検索技術と Vertex Matching Engine 佐藤 一憲 Google デベロッパーアドボケイト
