[go: nahoru, domu]

この記事は Devin Chasanoff による Google Ads Developer Blog の記事 "The Query Builder Blog Series: Part 8 - Conclusion" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

このブログシリーズでは、新しく改善されたインタラクティブ Google 広告クエリビルダー ツールの構築過程についてお伝えしてきました。ここまでシリーズ全体をお読みいただいたことで、Google Ads Query Language（GAQL）の詳細や意図についてご理解いただけましたでしょうか。パート 8 では、これまでの道のりと、その学習内容をまとめます。

ユーザー インターフェースの作成ResourceService、SelectionService、ValidationService があれば、あとはユーザー インターフェースを構成するコンポーネントを作成するだけです。場合によっては、これらのサービスから直接データを取得します。それ以外の場合（選択可否、選択状況、クエリの有効性のトラッキングなど）は、サービスをサブスクライブし、コンポーネントが常にアプリケーションの最新状態を反映するようにします。

まとめこのブログシリーズでは、GAQL を理解するうえで役立つ部分に重点を置いて、クエリビルダー アプリケーションに不可欠な部分について説明してきました。各回の投稿で学んだことをまとめます。


パート 1 - 事前準備

パート 2 - リソース スキーマの設計
  • アプリケーションのスキーマの概要

パート 3 - リソース スキーマの作成
  • GoogleAdsFieldService を使ってフィールドのメタデータを取得する方法
  • GAQL でのフィールドの同時使用可否
  • REST ディスカバリー API

パート 4 - リソース サービスの作成
  • GAQL クエリの構造
  • GAQL クエリに登場する可能性があるフィールドの種類
  • フィールドのプロパティとそれぞれの GAQL 句との対応

パート 5 - フィールドの選択可否の決定
  • フィールドの同時選択性と、フィールドの選択可否の決定方法

パート 6 - フィールドの選択と選択解除
  • GAQL クエリの構造
  • フィールドの選択可否に関する追加の詳細情報
  • Angular での Observable の利用

パート 7 - クエリの検証
  • GAQL クエリ検証のさまざまな側面
追記Google Ads Query Language について学んできたことに加えて、Angular アプリケーションの記述についても皆さんのヒントになることを願っています。私が Angular を使ったのは今回が初めてですが、複雑なアプリケーションをすばやく構築できるフレームワークであることがわかりました。Angular サービスと依存関係の注入と Observable を併用すると、アプリ全体で状態を効率的に管理できます。


このシリーズを通して、Google Ads API での GAQL クエリの構築方法についての理解が深まれば幸いです。ご質問やさらにサポートが必要なことがありましたら、フォーラムまたは googleadsapi-support@google.com にご連絡ください。


- Devin Chasanoff（Google Ads API チーム）
Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team

この記事は Mike Cloonan による Google Ads Developer Blog の記事 "Updating Default Reporting Versions in Google Ads Scripts" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

今後、Google 広告スクリプトで search リクエストと、Google Ads Query Language を使う report リクエストを対象に、デフォルトのレポート バージョンの更新方法を変更します。これまでは、最大数か月にわたって新しいバージョンが利用できない期間がありましたが、今後は新しいレポート機能がリリースされたまもなくアクセスできるようになります。この変更は、v201809 の AdWords API ベースのレポートを使い続けている方には影響しません。

今後は最新バージョンの Google Ads API のリリースから 2 週間以内に、デフォルトのレポート バージョンを更新し、最新バージョンが使えるようになります。たとえば、v8 がリリースされるとその 2 週間以内に、GAQL を使う report 呼び出しと、すべての search 呼び出しについて、デフォルトのレポート バージョンを更新し、v8 を使うようにします。

スクリプトに悪影響が生じる可能性があり特定のバージョンに固定したい場合、手動でバージョンを指定することもできます。これはデフォルトよりも優先されるので、次のバージョンの準備が整うまでアップデートを延期できます。延期する場合、Google Ads API のバージョンが提供終了になるタイミングに注意してください。新しいバージョンにアップデートしないと、スクリプトが失敗します。API のバージョンを設定する例を次に示します。

report の場合 :
var report = AdsApp.report(query, {apiVersion: 'v7'});
search の場合 :
var results = AdsApp.search(query, {apiVersion: 'v7'});
このリリースの一環として、デフォルト（現在は v5）を v7 にアップデートします。v6 と v7 で行われたレポートのアップグレードの全一覧は、Google Ads API リリースノート ページで確認できます。

質問がある方は、サポートを得られるようにフォーラムに投稿してください。

- Google 広告スクリプト チーム、Mike Cloonan
Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team

この記事は Pierrick Voulet による Google Ads Developer Blog の記事 "Sunsetting the KEYWORD_MATCH_TYPE recommendation type" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


2021 年 7 月 21 日に、種類が KEYWORD_MATCH_TYPE であるすべての既存の最適化案が削除され、この種類の最適化案が生成されなくなります。


変更点

すべてのバージョンの Google Ads API と Google 広告スクリプトの search で、KEYWORD_MATCH_TYPE 最適化案が返されなくなります。


すべてのバージョンの Google Ads API で、KEYWORD_MATCH_TYPE 最適化案を適用または拒否するリクエストを送信すると、すべて RequestError.RESOURCE_NOT_FOUND エラーが発生して失敗します。


変更に伴い、何をする必要がありますか？

2021 年 7 月 20 日までに、上記の変更によってコードやアプリケーションに問題が起こらないようにしてください。

その後、フィールド Recommendation.keyword_match_type_recommendation やタイプ KeywordMatchTypeRecommendation を参照しているコードがある場合は、できるだけ早いうちに削除してください。これらは非推奨となり、今後のバージョンで削除されます。

ご質問やさらにサポートが必要なことがありましたら、フォーラムまたは googleadsapi-support@google.com にご連絡ください。


 Pierrick Voulet （Google Ads API チーム）

この記事は Thanet Knack Praneenararat による Google Ads Developer Blog の記事 "Announcing v8 of the Google Ads API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google Ads API の v8 リリースをお知らせします。v8 の機能を使うには、クライアント ライブラリとクライアントのコードをアップグレードする必要があります。更新版のクライアント ライブラリとコードサンプルも公開されました。互換性を伴わない変更の詳細については、移行ガイドをご覧ください。

   

主な機能は以下のとおりです。

  • クロスアカウント入札戦略を追加しました。これにより、管理者が所有する入札戦略をクライアント アカウントにアタッチできるようになります。さらに、新しいリソース AccessibleBiddingStrategy も追加されます。これは、現在の顧客がアクセスできるすべての入札戦略の読み取り専用のビューを提供します（顧客が所有するポートフォリオ戦略と、顧客に共有されているクロスアカウント入札戦略を含みます）。
  • CustomerClient.applied_labels を使って管理者アカウントが管理するラベルを取得できるようになります。
  • CallOnlyAdInfo が CallAdInfo に置き換えられ、この広告タイプの機能が強化されます。たとえば、CallAdInfo.path1 フィールドや CallAdInfo.path2 フィールドを使って、広告に表示される URL の後ろにテキストを追加する機能が含まれます。
  • 販売したアイテムの追加情報と合わせてコンバージョンをアップロードできるように、ClickConversion で cart_data がサポートされます。
  • TransactionAttribute と UserAttribute にいくつかの項目が追加され、UserDataService や OfflineUserDataJobService を使ってユーザーデータをアップロードする際に、販売したアイテムやユーザーの購入履歴の詳細情報を関連付けられるようになります。
  • スマート キャンペーンのサポートを追加しました。これにより、スマート キャンペーン タイプの作成、監視、管理が可能になります。スマート キャンペーンは高度に自動化された効率的なキャンペーンで、最低限の継続的な管理で最大限の成果を出せるように設計されています。詳しくは、開発ガイドをご覧ください。
さらに詳しく知りたい方へ 以下のリソースが役立ちます。 ご質問やさらにサポートが必要なことがありましたら、フォーラムからご連絡ください。


Thanet Knack Praneenararat（Google Ads API チーム）

この記事は Google Maps Platform チームによる Google Cloud Blog の記事 "Improved accessibility in the Maps JavaScript API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


Google Maps Platform JavaScript チームが行っている、Maps JavaScript API のユーザー補助機能の改善に重点を置いた最近の機能変更をいくつかご紹介します。当チームは 2020 年に、すぐに使えるユーザー補助機能と、デベロッパーがユーザー補助エクスペリエンスを作成するために利用できるフックを増やす新たな取り組みを開始しました。

Google は、Maps JavaScript の UI と API のユーザー補助機能の改善に継続的に取り組んでおり、まだまだできることがあると認識しております。お客様にはこうした新機能を毎週の最新バージョンでお試しいただき、変更点に関するフィードバックの提供と新しいバグの報告にご協力いただけますと幸いです。それらを参考に、最も影響の大きい領域に優先順位を付けさせていただきます。みなさんのウェブサイトに影響を与える既存のバグに +1 し、新しいバグレポートをご提出ください。ユーザー補助機能は、さまざまなユーザーやコミュニティに多様な影響を与える複雑なトピックです。お客様のフィードバックは、Google Maps Platform の機能を誰でも利用できるようにする取り組みの指針として活用されます。


2020 年最初の機能変更は、特に根本的な問題に焦点を絞っていました。タブの順序の最適化、キーボードの有効化とスクリーン リーダーの対話的な機能、スクリーン リーダーに関する説明の追加、各マップコントロールのカラー コントラストの強調を図りました。機能変更の前後での違いをご覧ください。


タブの順序は標準的ではなく、スペースバーでボタンがアクティブになりませんでした。

タブの順序は左から右、上から下に並べられ、スペースバーでボタンがアクティブになり選択でき、色のコントラストが上がって視認性が増しています。

また、デベロッパーがマップに追加するマーカーについても詳しく調べました。マーカーは、img ロールか、インタラクティブな場合（クリック イベント リスナーが登録されている場合など）は button ロールにデフォルト設定されました。インタラクティブなマーカーもキーボードで矢印キーを繰り返し押して操作できます。デベロッパーがマーカーにタイトルを指定すると、このテキストはユーザー補助ラベルにも使用されます。こうした改善は最適化されていないマーカーにのみ適用されm。詳細については、新しい「マーカーを利用可能にする（Make a marker accessible）」ガイドと「マーカーのユーザー補助機能（Marker Accessibility）」コードサンプルをご覧ください。


ユーザー補助のラベルとロールが適用された、キーボードの矢印キーで操作できるマーカー。

マップで特に使用される UI コンポーネントは InfoWindow です。改善点の中で特筆すべきなのは、InfoWindow が開いたり閉じたりした際に、InfoWindow から出入りするタブ選択を自動的に管理する機能です。デフォルトではこれまで多くのユーザーから寄せられたフィードバックを元に、open() が自動的にフォーカスを移動するかどうかを決定します。デベロッパーの皆様は、InfoWindow を開く際に shouldFocus オプションを使用して明示的に選択することをおすすめします。

const infoWindow = new google.maps.InfoWindow({

    content: "Hello Accessibility!",

});

infoWindow.open({

    anchor: marker,

    shouldFocus: true,

});

 

InfoWindow を開くと、最初のフォーカス可能な要素（デベロッパー指定のコンテンツか、組み込みの閉じるボタン）が開きます。閉じると、フォーカスが復元されます。

Maps JavaScript API は 2005 年以降、パンやズームなどのマップ操作のキーボード コントロールをサポートしていますが、ユーザーがキーボード ショートカットを見つけるのは困難でした。今月、UI に新しいキーボード ショートカットのダイアログを追加し、使用できるショートカットをユーザーが見つけやすくしました。こうしたキーボード ショートカットは、マップ自体にフォーカスがあるときに有効になります。

マップ上の「キーボード ショートカット」ボタンをアクティブにすると、使用可能なショートカットのダイアログが表示されます。

今後導入予定の機能


ウェブでは毎日、世界中の何百万人ものユーザーが Maps JavaScript API によって提供される Google basemap を利用しています。Google の目標は、万人向けのマップを作成できるようにするために必要なツールをデベロッパーに提供することです。


Google は、Maps JavaScript の UI と API のユーザー補助機能の改善に継続的に取り組んでおり、まだまだできることがあると認識しております。今回の変更は、その手始めにすぎません。これらの新機能をぜひお試しになり、フィードバックをご提供ください。また、リリースノート ページでは、Maps JavaScript API の新しい機能の追加状況をご確認いただけます。さらに、既存のバグを検索してウェブサイトに影響するバグに +1 する、これまでに修正されたバグを確認する、フィードバックや発生した問題を記載した新しいバグレポートを送信するなどの方法で、Google Maps Platform の改善にご協力いただけますと幸いです。


Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やフィードバックはページ右上の「お問い合わせ」より承っております。

この記事は Devin Chasanoff による Google Ads Developer Blog の記事 "The Query Builder Blog Series: Part 7 - Query Validation" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


このブログシリーズでは、新しく改善されたインタラクティブ Google 広告クエリビルダー ツールの構築過程についてお伝えしています。シリーズのパート 6 では、クエリのフィールドの選択と選択解除の方法について説明しました。パート 7 では、ユーザーの選択に基づいてクエリを検証する方法について説明します。

背景
パート 5 ではフィールドの同時選択可否について説明し、パート 6 でも選択可否について少し触れました。それでも、クエリビルダーを使って無効な Google Ads Query Language（GAQL）文字列を作ることは可能です。それを対処するため、パート 6 で SelectionService に Observable をサブスクライブする ValidationService を作成します。Observable がトリガーされるたびに、一連の検証テストを実行してエラー メッセージの一覧を生成します。ValidationService には、別の Observable を作成し、検証が行われるたびに通知を受けるようにします。こうすることで、クエリにエラーが含まれている場合、ユーザーに通知できるようになります。ユーザーが何も選択していない場合は、アプリケーションが初期状態であることを示しているため、エラーは表示されません。





以下を確認する検証テストをします。
  • SELECT 句にフィールドが含まれている
  • コア日付の選択が有効である
  • click_view の日付フィルタが有効である
  • change_event と change_status の日付フィルタが有効である
  • change_event と change_status の LIMIT が有効である

SELECT 句にフィールドが含まれている有効な GAQL クエリには、SELECT 句に少なくとも 1 つの有効なフィールドが含まれている必要があります。選択されたのが SELECT 以外の句で、SELECT 句が空だった場合、エラーを生成します。

コア日付の選択が有効であるクエリのいずれかの句にコア日付セグメント（segments.date、segments.week、segments.month、segments.quarter、segments.year）がある場合、WHERE 句のフィルタ条件を組み合わせたときに、少なくとも 1 日の日付範囲を表すようなコア日付セグメントの有限な日付範囲ができなければなりません。クエリにコア日付セグメントが存在しない場合、エラーは生成されません。


それ以外の場合は、WHERE 句のコア日付セグメントによるフィルタを組み合わせたときに、有限の範囲になることを確認します。言い換えるなら、WHERE segments.date > ‘2021-01-01’ などのフィルタが 1 つしかない場合は、日付の範囲が閉じられていないので、失敗します。この場合はエラーが生成されます。ただし、WHERE segments.date > ‘2021-01-01’ AND segments.date < ‘2021-02-01’、WHERE segments.date = ‘2021-01-01’、WHERE segments.date DURING LAST_7_DAYS といったフィルタは有効です。この 3 つの例には開始日と終了日があるので、エラーは生成されません。


最後に、コア日付セグメントによるフィルタが有限の範囲になる場合、それを組み合わせたときに少なくとも 1 日の範囲になることをチェックします。たとえば、フィルタ条件 WHERE segments.date = ‘2021-01-01’ AND segments.date BETWEEN ‘2021-02-01’ AND ‘2021-03-01’ を含むクエリは、両方のフィルタ条件を満たす日付が存在しないので、失敗します。この場合はエラーが生成されます。ただし、フィルタ条件 WHERE segments.date BETWEEN ‘2021-01-01’ AND ‘2021-01-31’ AND segments.date >= ‘2021-01-15’ AND segments.date < ‘2021-03-01’ は有効です。すべてのフィルタ条件を満たす日付範囲は ‘2021-01-15’ - ‘2021-01-31’ なので、エラーは生成されません。

click_view の日付フィルタが有効であるclick_view が FROM 句のメインリソースである場合、他の選択内容にかかわらず、WHERE 句に直近 90 日間の 1 日を指定する日付フィルタが存在しなければなりません。
change_event と change_status の日付フィルタが有効であるFROM 句のリソースが change_event または change_status である場合、「コア日付の選択が有効である」ルールと同じように、WHERE 句のフィルタ条件で有効な日付範囲が指定されている必要があります。ただし、この条件はクエリに日付フィールドがあるかどうか関係なく適用されます。さらに、コア日付セグメントではこのフィルタ条件は生成されません。FROM 句のメインリソースが change_event または change_status である場合、利用できるコア日付セグメントはないからです（パート 4 参照）。FROM 句のリソースが change_event である場合、Google Ads API サーバーで change_event.change_date_time フィールドのフィルタに対して日付の評価が行われます。FROM 句のリソースが change_status である場合、Google Ads API サーバーで change_status.last_change_date_time フィールドに対して日付の評価が行われます。
change_event と change_status の LIMIT が有効であるFROM 句のリソースが change_event または change_status である場合、クエリに有効な LIMIT、すなわち正の整数が含まれている必要があります。
まとめこれで、GAQL クエリのエラーをチェックする ValidationService ができました。ValidationService では、GAQL 文字列が変更されるたびにこのチェックをし、エラーリストを生成して、Observable からイベントを発行します。エラーリストが空でない場合、この Observable をサブスクライブするコンポーネントでエラーアイコンを表示します。この投稿では、GAQL クエリ検証のさまざまな側面について説明しました。


Google Ads API での GAQL クエリの構築について理解が深まれば幸いです。ご質問やさらにサポートが必要なことがありましたら、フォーラムまたは googleadsapi-support@google.com にご連絡ください。


- Devin Chasanoff（Google Ads API チーム）

この記事は Nadine Wang による Google Ads Developer Blog の記事 "Upgrade to the Google Ads API from the AdWords API by April 27, 2022" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

  現在 AdWords API を使っているデベロッパーは、2022 年 4 月 27 日までに Google Ads API にアップグレードする必要があります。この日をもって AdWords API の提供が終了し、AdWords API へのリクエストが失敗するようになります。Google Ads API v7 で AdWords API と同等な機能が実現され、すべてのデベロッパーがアップグレードできるようになりました。ただし、機能移行ガイドの冒頭に記載されているように、一部の例外を除きます。

Google Ads API では、推奨事項、アセット管理、新しい広告タイプなどのツールの新機能やアップデートが公開されるペースが速くなります。さらに、キーワード プランナー、変更履歴、課金などの既存機能も改善されています。そのため、キャンペーンを管理できる機能が増えて、全体的な生産性が向上します。


どこから始めればよいですか
新しいデベロッパー トークンを申請したデベロッパーは、Google Ads API のみにアクセスできます。新しい API ユーザーに役立つリソースは、次のとおりです。 既存の AdWords API デベロッパーは、アップグレードを開始する必要があります。以下に、着手点となるリソースを紹介します。

どこでサポートを受けることができますか
アップグレードの際に質問などございましたら、フォーラムまたは googleadsapi-support@google.com までご連絡ください。


Nadine Wang（Google Ads API チーム）

この記事は Mike Cloonan による Google Ads Developer Blog の記事 "Adding New Resource Types to ChangeStatus in Google Ads API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

現在、change_status レポートにいくつかの新しいリソースタイプを追加する作業を懸命に進めています。今後、shared_set や asset などを改善する予定です。これらのタイプは今後のバージョンの Google Ads API で完全にサポートされますが、そのために現在行っているインフラストラクチャの変更作業によって、既存のバージョンにも多少の影響が発生します。

新しいリソースタイプのサポートが追加されると、すべてのバージョンの API で新しい行を取得できるようになります。その際に、すでにリリースされているバージョンでは、resource_type が UNKNOWN として返却されます。具体的には、これまで CAMPAIGN などの既知の resource_type が返されていた行で、UNKNOWN リソースタイプが返される場合があります。これが発生するのは、これまで CAMPAIGN の変更と報告されていた変更が、実際には CAMPAIGN_ASSET の変更だった場合などです。今後のバージョンの API は CAMPAIGN_ASSET リソースタイプを認識しますが、既存のバージョンは認識しないので、UNKNOWN を使うしかありません。この行には、新しい resource_name も関連付けられ、アセットの ID が含まれるようになります。

その行の新しいリソース名には、変更の種類を表す識別子が含まれます。最新の識別子のリストは、ステータス変更ガイドをご覧ください。これを調べる必要があるのは、UNKNOWN リソースタイプが含まれる行だけです。これにより、今後の API バージョンでそのリソースタイプが完全にサポートされたときに返されるリソースタイプがわかります。

change_status レポートには、新しいリソースタイプを複数追加する予定なので、さまざまな新しいリソースタイプに対して UNKNOWN タイプが出現する可能性があります。これが表示されるのは、今後のリリースによって change_status レポートで新しいリソースタイプがサポートされるためなので、ご安心ください。

質問がある方は、サポートを受けることができるようにフォーラムに投稿してください。


- Google Ads API チーム、Mike Cloonan
Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team

この記事は Google Chrome、プロダクト マネージャー、Janice Wong による Chromium Blog の記事 "An experiment in helping users and web publishers create deeper connections on Chrome" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

 現在のユーザーは、メーリング リストの購読、通知、RSS など、多くの方法でお気に入りのウェブサイトの最新情報を得ています。これを 1 人で管理するのは大変なので、オープンな RSS ウェブ標準をベースに、簡単な操作で Chrome から直接お気に入りのサイトの最新情報を取得する方法を検討しています。Google のビジョンは、ユーザーがウェブ上のお気に入りのパブリッシャーやクリエイターと直接つながれるようにすることです。

今後数週間のうちに（元記事公開当時）、米国で Chrome Canary を使っている一部の Android ユーザーに、試験運用版のフォロー機能が表示されます。これは、フォローしているサイトの最新コンテンツを取得する機能です。この機能の目的は、ユーザーが Chrome のフォローボタンをタップすることで、大規模なパブリッシャーから小さな近所のブログまで、興味のあるウェブサイトをフォローできるようにすることです。ウェブサイトでコンテンツが公開されると、[New Tab] ページの新しい [Following] セクションから、フォローしているサイトの最新情報を確認できます。




この Chrome の試験運用機能では、サイトの RSS を最新に保つことで、ユーザーに最新のコンテンツを提供できます。この機能の試験運用を終えて Chrome で幅広く展開するかを評価する際には、ウェブ パブリッシャー向けに詳しいガイドをお伝えしたいと思います。

Chrome を通してユーザーとウェブ パブリッシャーの深い交流をサポートしたいので、パブリッシャー、ブロガー、クリエイター、そしてオープンウェブの住民（皆さんのことです！）からの試験運用に関するフィードバックをお待ちしています。Twitter の @WebCreators や、webcreators@google.com へのメールを通じて、最新情報を入手したり質問したりすることもできます。

この記事は Chromium Blog の記事 "Chrome 92: Web Apps as File Handlers, New JavaScript Features, and More" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2021 年 6 月 3 日の時点で Chrome 92 はベータ版です。

File Handling API

ウェブアプリでファイルの読み取りと書き込みができるようになったので、次の論理的なステップは、デベロッパーがファイルの作成や処理をするウェブアプリをファイル ハンドラとして宣言できるようにすることです。File Handling API は、まさにそれを行います。たとえば、テキスト エディタ PWA が自身をファイル ハンドラとして登録すると、オペレーティング システムのファイル マネージャーで .txt ファイルを右クリックし、この PWA に（常に、または 1 回だけ）.txt ファイルを開くように指示できます。つまり、ファイル マネージャーで（ダブル）クリックするだけで、PWA を利用できます。

Excalidraw のコンテキスト メニュー


これにより、PWA ユースケースのユーザー エクスペリエンスが改善され、これまでよりも OS のアプリに近くなります。次に例を示します。

  • テキスト エディタ、スプレッドシート アプリ、スライドショー作成ツールなどのオフィス アプリケーション
  • グラフィック エディタやドローイング ツール
  • ビデオゲームのレベルエディタ ツール

ファイル ハンドリングのオリジン トライアルは 92 で始まり、2021 年 8 月末ごろまで続く予定です。この機能の詳細については、ウェブ アプリケーションをファイル ハンドラにするをご覧ください。このリリースのその他のオリジン トライアルについては、以下のオリジン トライアルをご覧ください。

オリジン トライアル

このバージョンの Chrome には、以下のオリジン トライアルが導入されています。オリジン トライアルとして新機能を試せるようにすることで、ウェブ標準コミュニティにユーザビリティ、実用性、有効性についてのフィードバックを提供することができます。以下の項目を含め、現在 Chrome でサポートされているオリジン トライアルに登録するには、Chrome オリジン トライアル ダッシュボードをご覧ください。Chrome のオリジン トライアルの詳細については、ウェブ デベロッパーのためのオリジン トライアル ガイドをご覧ください。Microsoft Edge は、Chrome とは別に独自のオリジン トライアルをしています。詳細については、Microsoft Edge オリジン トライアル デベロッパー コンソールをご覧ください。

新しいオリジン トライアル

Shared Element Transitions

Shared Element Transitions を使うと、シングルページ アプリケーション（SPA）とマルチページ アプリケーション（MPA）の両方でシンプルな画面遷移を実現できます。デベロッパーはユーザー エージェントが提供する遷移効果の中から選ぶだけでよいので、最低限の作業でページの視覚的な洗練度が向上します。シングルページ アプリでは、この機能がない場合、アニメーションと DOM 操作を慎重に連動させなければ望む効果を実現できないので、画面遷移効果を実現するのは困難です。マルチページ アプリでは、ページが制御できるのは自身のビューだけなので、画面遷移効果を実現できない場合がほとんどです。今回のオリジン トライアルは、SPA のユースケースのみに対応します。

今回のリリースに追加されたその他の機能

アプリのショートカット機能の変更

ほとんどの Android ランチャーで、以前は 4 つまでアプリのショートカット機能を登録できましたが、今後は 3 つだけになります。サイト設定へのショートカットが Android ランチャーのアプリアイコンに追加され、アプリのショートカット機能のスロットが 1 つ減ることになります。詳しくは、アプリのショートカット機能でものごとをすばやく行うをご覧ください。

CSS

@font-face の size-adjust ディスクリプタ

@font-face に size-adjust ディスクリプタが追加され、特定のフォント フェイスで CSS の font-size や em などの派生指標に影響を与えることなく、グリフのサイズのスケーリングができるようになりました。CSS の font-size は、フォントを描画するボックスのスケール ファクタと見なされます。ボックス内のグリフのサイズはフォントによって異なりますが、size-adjust を使うと、さまざまな種類のフォントでサイズを合わせることができます。そのため、このディスクリプタを使ってフォールバック フォントとプライマリ ウェブフォントのマッチアップをすることで、Cumulative Layout Shift（ページのレイアウトのずれ）を減らすことができます。

命令的な slot 割り当て動作

命令的な slot 割り当てを使うと、マークアップで slot 属性を必要とせず、ノードからスロットへの割り当てをすることができます。これにより、入力条件や種類に応じた動的なスロット割り当て動作が可能になります。この機能は、もともとは Chrome 86 に導入されました。今回のリリースで API が調整され、他のブラウザとの相互運用性が向上しています。

JavaScript

このバージョンの Chrome には、V8 JavaScript エンジンのバージョン 9.2 が組み込まれます。具体的には、以下の変更点が含まれます。最新の機能リストをすべて確認したい方は、V8 リリースノートをご覧ください。

Intl.DateTimeFormat に dayPeriod を追加

Intl.DateTimeFormat() メソッドに dayPeriod オプション（ECMA402 2021 の一部）が追加され、呼び出し元が時間を「7 in the morning」、「11 in the morning」、「12 noon」、「1 in the afternoon」、「6 in the evening」、「10 at night」などの形式（または中国語で「清晨 7 時」、「上午 11 時」、「中午 12 時」、「下午 1 時」、「下午 6 時」、「晚上 10 時」）を指定できるようになりました。

これによって Intl.DateTimeFormat() が拡張され、C++ や Java で ICU や ICU4J を呼び出して実行できる既存の操作と同じことを実現できるようになります。この機能がなければ、デベロッパーはサーバーで四半期をフォーマットするか、時間帯のパターンと時間の対応表をサーバーからクライアントに送信することによって、このタスクをする必要があります。

Array、String、TypedArray の相対インデックス メソッド

Array.prototype、String.prototype、TypedArray のプロトタイプに at() という新しいメソッドを追加し、負のインデックスによる相対インデックスを利用できるようにします。次に例を示します。

let arr = [1,2,3,4];
arr.at(-1); // Returns 4

ICU LocaleMatcher を使用する Intl BestFitMatcher

ICU LocaleMatcher に BestFitMatcher 抽象オペレーションが実装され、ロケールデータとの照合が向上します。

デスクトップ プラットフォームの SharedArrayBuffer がクロスオリジン分離環境のみに制限

デスクトップ プラットフォームの SharedArrayBuffer がクロスオリジン分離環境のみに制限されます。これにより、動作が最新の Android や Firefox と一致します。クロスオリジン分離されたページでは、オプトインされていないクロスオリジン リソースの読み込みとクロスオリジンのウィンドウとの通信がブロックされます。そのため、ページは安全な環境と見なされます。SharedArrayBuffer を使えるのは、クロスオリジン分離をオプトインしたページのみになります。導入されるオプションの詳細については、Android 版の Chrome 88 とデスクトップ版の Chrome 92 における SharedArrayBuffer のアップデートをご覧ください。

Media Session API: ビデオ会議のアクション

Media Session API に "togglemicrophone"、"togglecamera"、"hangup" アクションが追加されました。これにより、ビデオ会議サイトのデベロッパーが、ブラウザのインターフェースでこれらのアクションを扱えるようになります。たとえば、ユーザーがビデオ通話をピクチャー イン ピクチャー ウィンドウにした場合、ミュート / ミュート解除、カメラのオン / オフ、通話終了のボタンをブラウザに表示できます。ユーザーがこれらをクリックすると、ウェブサイトは Media Session API を通して処理できます。詳細については、最新記事の該当セクションを参照するか、デモをお試しください。

Resource Timing に Tainted Origin フラグを適用

Chrome は、フェッチしたリソースが Timing Allow Origin チェックを通過するかどうかを計算する際に、Tainted Origin フラグを考慮するようになります。Timing Allow Origin チェックは、ページで使われるリソースに関する詳細タイミング情報を受け取れるかどうかを判断するために Resource Timing で使用されます。オリジンをまたぐ複数のリダイレクトがある場合、Tainted Origin フラグがこのチェックに影響します。その場合、ヘッダーを '*' にする必要があります。つまり、具体的なオリジンであってはいけません。

リソースが（リダイレクトによって）2 つのオリジンにまたがる場合、このチェックを通過するために Timing-Allow-Origin: * を使用する必要があります。たとえば、オリジン A のページがオリジン B のリソースをフェッチし、オリジン B のリソースからオリジン C のリソースにリダイレクトされる場合、Tainted Origin フラグが設定され、最終的なリソースが詳細なタイミング情報を受け取るには、Timing-Allow-Origin: * が必要になります。

Web Bluetooth のメーカーデータ フィルタ

Web Bluetooth API で、ベンダー ID やプロダクト ID などのメーカーデータによるフィルタが可能になります。これまでも、近くにある Bluetooth デバイスで、アドバタイズされる名前やサービスに一致するものをブラウザのピッカーで選択することはできました。しかし、近くにある Bluetooth デバイスを、アドバタイズされるメーカー固有のデータで絞り込むことはできませんでした。メーカーのデータは、options.filters の新しいプロパティで指定し、Bluetooth.requestDevice() に渡します。詳細については、JavaScript で Bluetooth デバイスと通信するを参照するか、デモをお試しください。

サポートの終了と機能の削除

このバージョンの Chrome では、以下のサポートの終了と機能の削除が行われます。現在サポートが終了している機能と以前に削除された機能のリストは、ChromeStatus.com をご覧ください。

Standardized Payment Method Identifier の支払いハンドラ

この機能は、ウェブベースの支払いハンドラが URL のない paymentrequest イベントを受け取れるようにするものですが、 "basic-card" や "tokenized-card" などの Standardized Payment Method Identifier が削除されました。


Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Chrome チーム、Mike Taylor、Jade Kessler による Chromium Blog の記事 "Update on User-Agent String Reduction in Chrome" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

1 年ほど前に、User-Agent 文字列で公開される情報の粒度を徐々に削減する計画についてお知らせしました。この文字列は、デフォルトで HTTP リクエストのたびに送信されています。その直後、COVID-19 パンデミックの初期段階でウェブのエコシステムに移行の負荷をかけないよう、この取り組みを一時的に停止することを決めました。それ以降は、多大な時間を費やしてエコシステムから貴重なフィードバックを集め、これに代わるコンテンツのネゴシエーションと検出用の仕組みとして提唱している User-Agent Client Hints API（UA-CH）への人間工学的な改善を提案したり、ウェブの互換性の修正をしました。

現在、UA-CH はデフォルトで Chrome に搭載されています（M89 以降）。また、最初のリクエストでヒントが必要になるユースケースに対処するため、両方の Client Hints Reliability の仕組み（Critical-CH と ACCEPT_CH）のロールアウトも始めました。今後予定されている User-Agent 文字列削減の変更の厳密な日程やマイルストーンはまだお知らせできませんが、この領域の取り組みを再開する準備はできています。

とは言うものの、エコシステムやデベロッパーがユースケースをテストし、フィードバックを送り、適切な場合は UA-CH に移行する十分な時間を確保できる形で作業を進めることが重要だと感じています。そのため、2021 年中は、Chrome の安定版チャンネルで User-Agent 文字列の変更は行わない予定です。この投稿の目的は、皆さんが適切な対応計画を立てられるように、早い段階で私たちの考えやロードマップを公開することです。

変更点とその手法

User-Agent ヘッダー フィールドで公開される情報の粒度を段階的に引き下げることを計画しています。navigator.userAgent、navigator.appVersion、navigator.platform JS API についても同様です。

すべての対応が終わっても、User-Agent 文字列だけでブラウザのメジャー バージョンとプラットフォーム名は確実に取得でき、デスクトップかモバイルか（またはタブレットか）も判別できます。さらに高度なユースケースでは、User Agent Client Hints API に移行する必要があります。

注 : 現時点では、Android WebView や Chrome for iOS の User-Agent 文字列を変更する計画はありませんが、変更の有無やその時期については、あらためてお知らせします。

現在の計画の概要は、以下のとおりです。

  • M92 より、DevTools の [Issues] タブに、navigator.userAgent、navigator.appVersion、navigator.platform の取得に関するサポートの終了のお知らせを表示する予定です。
  • 今後数週間のうちに、完全に削減された User-Agent を実験的に受け取るオリジン トライアルについてお知らせする予定です。サイトでオプトインとテストをする十分な時間を確保し、私たちが目指す最終状態の実現可能性や整合性に関するフィードバックを提供していただけるように、オリジン トライアルは少なくとも 6 か月は継続する予定です。
  • オリジン トライアル パートナーやコミュニティからのフィードバックを評価し、そのフィードバックに基づき、計画のフェーズ 3 から 7（詳細は次のセクションを参照）を進めます。その間に、エコシステムが適応するための十分な時間をとります。もしくは、フィードバックに応じて、最善策について再検討します。
  • 複雑なユースケースで移行にさらに時間が必要なサイトのために、（「逆オリジン トライアル」によって）現在の User-Agent の動作を少なくとも 6 か月は延長できる機能を提供する予定です。
ロールアウト計画案

以上の変更は、7 つのフェーズに分けて、オリジン トライアルのフィードバックを待ちながら、ゆっくりと段階的にロールアウトする予定です。フェーズ 1 以降のスケジュールとマイルストーンの案については、近日中に最新情報をお知らせします。

削減の準備

フェーズ 1: M92 より、navigator.userAgent、navigator.appVersion、navigator.platform へのアクセスに関する警告を DevTools に表示します。

フェーズ 2: オリジン トライアルを開始し、サイトが最終形まで削減した UA 文字列でテストやフィードバックできる期間を、少なくとも 6 か月間継続します。

削減のロールアウト

フェーズ 3: 移行にさらに時間を要するサイトなどのために、逆オリジン トライアルを開始して、少なくとも 6 か月間継続します。

フェーズ 4: Chrome の MINOR.BUILD.PATCH バージョン番号を削減します（ "0.0.0" ）。これがロールアウトされると、デスクトップとモバイル OS で、逆オリジン トライアルをオプトインしていないすべてのページの読み込みに、削減版の UA 文字列が適用されます。

フェーズ 5: 削減版のデスクトップ UA 文字列と関連する JS API（navigator.userAgent、navigator.appVersion、navigator.platform）のロールアウトを開始します。これがロールアウトされると、デスクトップ OS で、逆オリジン トライアルをオプトインしていないすべてのページの読み込みに、削減版の UA 文字列が適用されます。

フェーズ 6: 削減版の Android モバイル（とタブレット）の UA 文字列と関連する JS API のロールアウトを開始します。これがロールアウトされると、Android で、逆オリジン トライアルをオプトインしていないすべてのページの読み込みに、削減版の UA 文字列が適用されます。

削減の完了

フェーズ 7: 逆オリジン トライアルが終了し、すべてのページの読み込みに、削減版の UA 文字列と関連する JS API が適用されます。

詳細や、各フェーズでの User-Agent 文字列の例については、削減版の User-Agent 文字列に関する最新情報ページをご覧ください。

デベロッパーが準備すべきことは何ですか？

この計画は下位互換性を考慮しています。User-Agent 文字列の変更は慎重に行われるべきですが、ロールアウトが行われても、デベロッパーへの影響は最低限に留まると考えています（既存のパーサーは期待どおりに動作するはずです）。

サイトやサービス、ライブラリ、アプリケーションで、Chrome のマイナー バージョン、OS のバージョン番号、Android デバイスのモデルなどの User-Agent 文字列に含まれる一部の情報を使っている場合は、User Agent Client Hints API を使うように移行する必要があります。

これらの情報が必要ない場合は、変更は不要で、これまでどおり動作するはずです。

これを行う理由は何ですか？

User Agent Client Hints の説明に記載しているとおり、User-Agent 文字列には 2 つの理由で問題があります。1 つ目は、HTTP リクエストのたびに、ブラウザに関する多くの情報が何もしなくても公開されることです。この情報は、フィンガープリンティングに使われる可能性があります。2 つ目は、時間とともに長く複雑になり、エラーが起こりやすい文字列の解析が必要になることです。User Agent Client Hints API は、デベロッパーにもユーザーにも優しい形で、この 2 つの問題を解決できると考えています。

他のブラウザはどうなりますか？

ある意味、Chrome はこの点で追いつきつつあります。UA 文字列で macOS のバージョン番号を制限したのは Safari が最初で、Firefox もそれに続きました。Firefox は、Windows のバージョン番号も 10 に制限しています。

さらに詳しく


Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Devin Chasanoff による Google Ads Developer Blog の記事 "The Query Builder Blog Series: Part 6 - Selecting and Deselecting Fields" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

このブログシリーズでは、新しく改善されたインタラクティブ Google 広告クエリビルダー ツールの構築過程についてお伝えしています。シリーズのパート 5 では、フィールドが選択可能かどうかを判断する方法について説明しました。パート 6 では、SelectionService を使って Google Ads Query Language（GAQL）文字列にフィールドを追加する方法について説明します。

GAQL 文字列の状態どのフィールドが選択されているかを追跡するには、GAQL 文字列の状態を追跡する必要があります。これは、以下のインターフェース定義で表される selectedFields というインスタンス変数で行います。


interface SelectedFields {
  select: string[];
  where: Array<{field: string, context: string}>;
  orderBy: Array<{field: string, context?: string}>;
  limit?: string;
  params?: string;
}



select フィールドは、フィールド名の配列を保持します。where フィールドは、オブジェクトの配列を保持します。それぞれのオブジェクトには、field 名と context 文字列が含まれています。context は、フィールドに適用するフィルタ条件（つまり、演算子とオペランド）です。たとえば、WHERE 句にフィルタ条件 ad_group.id = 1234567890 を追加した場合、field は ad_group.id、context は = 1234567890 になります。同様に、orderBy フィールドも field 名と省略可能な context 文字列を含む配列を保持します。context は、ASC または DESC でソート順を示しますが、省略も可能です（デフォルトは ASC）。limit フィールドは LIMIT の整数を文字列で表現したもので、省略可能です。最後の params フィールドは PARAMETERS 句の文字列値を表します。これも省略可能です。現在のところ、この句で利用できる選択肢は 1 つだけなので、配列にする必要はありません、
フィールドの選択ユーザーのクエリの状態を追跡するデータ構造が完成したので、任意の句のフィールドを選択するメソッドを実装できるようになります。


selectField(field: string, clause: string, context?: string): void {
    ...
}

clause が SELECT の場合、指定されたフィールドを selectedFields の select 配列に追加します。ユーザーが SELECT 句にフィールドを追加する場合、context は指定しません。


clause が WHERE である場合は、context 文字列として演算子とオペランドを含むフィルタ条件を提供する必要があるので、3 つのパラメータのすべてが必要です。ユーザーがチェックボックスをクリックして WHERE 句にフィールドを追加すると、ダイアログが開き、まずは演算子を、続いてオペランドを指定します。ユーザーが選択できる演算子のリストは、選択するフィールドの data_type に応じてあらかじめ指定されています。また、オペランドを入力するためにユーザーに表示するコンポーネントは、選択した演算子に応じて変わります。ユーザーがフィルタ条件を追加すると、演算子とオペランドを結合して 1 つの文字列にすることで context 文字列を作成します。





clause が ORDER BY である場合、context は省略可能です。ユーザーが ORDER BY 句のフィールドを選択すると、context なしで selectField を呼び出し、context がない状態で selectedFields の orderBy 配列にフィールドを追加します。また、フィールド名の下にラジオボタンを表示し、ASC か DESC でソート順を指定できるようにしています。ユーザーがいずれかの項目をクリックすると、orderBy 配列のそれぞれのフィールドのエントリを更新し、context にソート順を追加します。




clause が LIMIT か PARAMETERS である場合は、field パラメータで指定された文字列を使って selectedFields の limit エントリまたは params エントリを更新します。limit は正の整数である必要があるので、関連する UI コンポーネントで検証をします。現在利用できるパラメータは include_drafts だけで、このデフォルト値は false です。そのため、PARAMETERS の UI コンポーネントでは、'include_drafts=true' という選択肢が 1 つだけあるチェックボックスをユーザーに表示します。ユーザーがチェックボックスをクリックすると、field パラメータとして文字列 include_drafts=true を selectField に渡します。
SELECT での存在フィールドを選択するロジックは単純ですが、パート 5 ではあえて触れなかった選択可否に関するルールが 2 つあります。WHERE 句または ORDER BY 句にフィールドを挿入する場合、そのフィールドは SELECT 句に存在しなければなりません。

ルール 1: 「コア日付セグメント」（segments.date、segments.week、segments.month、segments.quarter、segments.year）を除き、すべてのセグメントとセグメント化リソースは、SELECT 句に存在しなければ WHERE 句に挿入することはできません。

ルール 2: すべてのセグメント、セグメント化リソース、指標、属性付きリソースのフィールドは、SELECT 句に存在しなければ ORDER BY 句に挿入することはできません。言い換えるなら、最初に SELECT 句に挿入することなく ORDER BY 句に配置できるのは、FROM 句のリソースのフィールドだけです。

このような場合は、ユーザーが 1 回の手順で、指定された句だけでなく SELECT 句にもフィールドを追加できるダイアログを表示します。





フィールドの選択解除フィールドを選択解除できるように、SelectionService に deselectField というメソッドを実装します。


deselectField(field: string, clause: string): void {
    …
}




フィールドの選択解除は、フィールドの選択と同様です。念のため、最初にそのフィールドが選択されているかどうかをチェックします。続いて、clause が SELECT、WHERE、ORDER BY のいずれかである場合は、selectedFields の対応する配列のエントリから選択解除されたフィールドを削除します。前述のルールにより、WHERE や ORDER BY に追加される前に SELECT に存在していなければならないフィールドが SELECT から削除されると、そのフィールドが SELECT から 1 回の操作で自動的に削除されます。句が LIMIT や PARAMETERS である場合は、selectedFields のそれぞれのエントリを undefined に更新します。
出力の更新selectedFields 変数、selectField メソッド、deselectField メソッドがそろったので、クエリ文字列の状態を追跡できます。アプリケーション全体で変化を追跡できるように、SelectionService で Observable を作成し、selectField か deselectField が呼び出されるたびに next を呼び出します。これにより、GAQL クエリの状態を認識したいコンポーネントで Observable をサブスクライブできるようになります。
まとめSelectionService を更新し、フィールドの選択と選択解除ができるようになりました。今回の投稿では、以下について説明しました。
  • GAQL クエリと句の構造
  • フィールドの選択可否に関する追加の詳細情報
  • Angular での Observable の利用
Google Ads API での GAOL クエリの構築について理解が深まれば幸いです。ご質問やさらにサポートが必要なことがありましたら、フォーラムまたは googleadsapi-support@google.com にご連絡ください。


- Devin Chasanoff（Google Ads API チーム）

この記事はデベロッパー リレーションズ、プログラム マネージャー、Sebastian Trzcinski-Clément による Google Developers Blog の記事 "A new open source content library from Google" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

世界中のデベロッパーが絶え間なくオープンソースのツールやチュートリアルを作成していますが、それを見つけてもらうのは至難の業です。多くの場合、公開されたコンテンツは、GitHub から Medium まで、さまざまなサイトに広がっています。そこで、Google のテクノロジーに関連する優れたプロジェクトを 1 か所にまとめた場所を作ることにしました。それが Developer Library です。

Developer Library をスクロールする様子を示した GIF

このプラットフォームでは、ブログ投稿や、簡単な操作で使えるオープンソース ツールを紹介しています。コンテンツは、プロダクトの種類によって、Machine Learning、Flutter、Firebase、Angular、Cloud、Android に分類されています。分類は今後さらに追加される予定です。

Developer Library ならではの特徴は、取り上げられているすべてのサイトが正確さと妥当性の観点で Google のエキスパート チームによって細かく検証されている点です。つまり、このサイトにコンテンツが掲載されているということは、Google が承認したということです。

このサイトのコンテンツの幅広さをお見せするため、公開されているコンテンツや作成したデベロッパーの動画インタビューの一部を以下に紹介します。

Developer Library の更なる成長のために、皆さんにご協力いただける方法が 2 つあります。

1 つ目として、Developer Library で公開したい優れたコンテンツをお持ちの方は、こちらからレビューの申請をしてください。

2 つ目として、フィードバックも歓迎しています。Developer Library サイトに追加や変更の希望がある方は、こちらの簡単なフィードバック フォームに入力するか、GitHub で Issue を送信してください。

皆さんの作品を楽しみにしています。


Reviewed by Eiji Kitamura - Developer Relations Team


Google は 多くの女性のエンジニアが勉強会やイベントでスピーカーとして活躍できるためのプログラム「Women Developer Academy」 を 7 月 17 日（土）より開催します。

Women Developer Academy は、技術勉強会やイベントで活躍する女性スピーカーを育成するためのプログラムで、オンライン ワークショップを通じて、登壇・講演を向上させるスキルやリソースを提供します。

本プログラムでは、ワークショップを通じて、プレゼンテーションスキルを向上させ、自信とネットワークを構築しようとしている IT 専門家（ソフトウェア エンジニア、データ サイエンティスト、開発者など）に向けてこの 3 週間プログラムはデザインされています。またいくつかのトピックに焦点を当てた週次ワークショップ（詳細は以下）が開催されます。新しいスキルを習得するだけでなく、似たような悩みを抱える他の女性デベロッパーに出会い、つながり、コミュニティ ネットワークを通じて、登壇機会を見つけることができます。（多くの女性が登壇枠に出ていない理由は、技術的なスキルが不足しているからではありません！）

Google は Women Developer Academy を通じて、技術勉強会やイベントの登壇者の多様性を支援していきたいと考えています。

みなさまからの応募をお待ちしております。


プログラム内容Week 1 - July 17 （1 週目のセッションは韓国地域の参加者と一緒に英語で行われます）
  • Session 1 : WDA プログラムの紹介、WTM＆GDE プログラムの概要
  • Session 2 : Workshop: 適切なテーマの選び方
  • Session 3 : 登壇する自信がない ... 自信をつけるには
Week 2 - July 24（日本語セッション）
  • Session 1 : 優れた技術プレゼンテーションの構築法
  • Session 2 : Machine Learning Workshop
Week 3 - July 31（日本語セッション）
  • Session 1 : Google Developer Expert (GDE) について
  • Session 2 : 女性 GDE 活躍事例
※ 参加者数が限られているため、なるべくすべてのセッションに参加できる方のみご登録をお願いいたします。

タイムライン
  • 6 月 21 日 : 応募登録開始
  • 7 月 10 日 : 登録締切
  • 7 月 8 日 ～ : 参加確認メールを送信
  • 7 月 17 日 ～ 31 日 : Women Developer Academy 開催

参加対象
  • 次の技術のいずれかの知識、情熱と経験がある方 : Android, Google Cloud, Tensorflow, Machine Learning, Flutter, Firebase, Kotlin, Go, Web Technologies, Google Workspace
  • 公の場で演説した経験がほとんどない方
  • イベントやセミナーで登壇したい方
  • デベロッパー コミュニティで積極的に発言し、開発者会議やミートアップにスピーカーとして参加したいという意志がある方
  • 7 月に行われるすべてのセッションに（オンライン）参加し、プログラムの要件に専念することができる方
  • 日本に在住している女性の開発者
  • 登録してくださったすべての方がプログラムに参加できるわけではありません。上記要件を満たしている方に、プログラム詳細をメールにて個別ご連絡いたします。
以下のプログラム要件にご留意ください
  • コンテンツへのアクセスのために使用できる個人 Gmail や Gsuite アカウント
  • デスクトップ コンピュータまたはラップトップ
  • ウェブカメラとマイク（内蔵または外付け）



Google for Startups は、成長段階にある日本の有望なスタートアップを対象に 8 週間のオンライン プログラム「Growth Academy 2021」を開催します。Google の社員や外部のアドバイザーが、メンタリング セッション、ワークショップなどを通じてスタートアップの成長を支援します。

2021 年 6 月 25 日に参加スタートアップの応募を締め切り、2021 年 9 月 よりプログラムを開始いたします。詳細なスケジュールについては プログラムのウェブサイトをご確認ください。

スタートアップの創業者が直面する課題は、顧客の拡大から、収益力の向上、組織の拡大、資金調達の準備まで多岐にわたります。本プログラムは、Google のノウハウを結集して問題の解決と成長の加速を支援し、スタートアップを次のステージへと導くサポートをします。また、同じ課題を持つスタートアップ同士が学び合えるようにネットワーキングの場を提供します。

昨年は 6 社の素晴らしいスタートアップにご参加いただきました。
2021 年も、革新的で Google のノウハウを活用して急成長を目指すスタートアップの皆さまの応募をお待ちしております。


プログラムのハイライト
  • 戦略と OKR の設定 : 戦略の最適化と具体的な目標（OKR）の設定
  • マーケット インサイト : Google のアナリストより、成長が見込まれる領域やターゲットを特定するためのインサイトの共有とディスカッション
  • ブランディング : オーディエンスに訴求する価値とストーリーテリングの改善
  • UI / UX : ウェブサイトやアプリのユーザー エクスペリエンスの改善と最適化方法
  • 広告メディア プランニング : ターゲット オーディエンスに効率的かつ効果的にリーチする方法、パフォーマンスを測定する方法の共有
  • Founders Lab : ビジネスを成長させるための組織づくりとして、創業者向けリーダーシップ ワークショップ


Growth Academy 2021 が求めるチーム
  • デジタル マーケティングを活用し、ビジネスの急速な成長と拡大が見込める野心的なスタートアップであること（業界は問いません）
  • マーケットに公開済みのプロダクトとサービスを持っていること
  • それぞれのプログラムにおいて意思決定者（CEO や CMO 専用のプログラムを含む）が参加できること
  • Google アカウントをお持ちで日本語に堪能なチームであること（英語は必要はありません）

募集概要
  • 対象 : マーケットに公開済みのプロダクトとサービスを持っており、成長段階にある有望なスタートアップ（アイディア段階、シード段階で、まだプロダクトがない、またはテスト中のスタートアップは募集対象外となります）
  • 形態 : オンライン
  • 募集締め切り : 2021 年 6 月 25 日（金）
  • 選考期間 : 2021 年 6 月 29 日（火）～ 2021 年 7 月 20 日（火）
  • 参加企業の発表 : 2021 年 7 月 29 日（木）
  • プログラム期間 : 2021 年 9 月 6 日（月）～ 2021 年 10 月 29 日（金）

詳細や応募条件はウェブサイトをご参照ください。


Posted by Yuri Uehara - Marketing Manager, Google for Startups


この記事は Nadine Wang による Google Ads Developer Blog の記事 "Announcing v7 of the Google Ads API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

この度、Google Ads API の v7 リリースをお知らせします。V7 の機能を使うには、クライアント ライブラリとクライアントのコードをアップグレードする必要があります。更新版のクライアント ライブラリとコードサンプルは、来週公開されます。互換性を伴わない変更の詳細については、移行ガイドをご覧ください。

主な機能は以下のとおりです。
  • 以下の新しいアセットをテスト アカウントで利用できます。
    • コールアウト アセット
    • 構造化スニペット アセット
    • サイトリンク アセット
  • すでに追加されているプロモーション アセットが本番環境とテスト アカウントで利用できます。
  • Google Ads API で、Apple の SKAdNetwork のレポートがサポートされます。この機能を使うと、iOS アプリで発生する SKAdNetwork コンバージョンの数や、それらのコンバージョンの SKAdNetwork コンバージョン値を広告主が照会できます。
  • キーワード プラニングが以下をサポートします。
    • アノテーション データを使った不必要なキーワードの除外
    • 検索ボリュームでのカスタム日付範囲の選択
    • 生成されたキーワード アイデアとキーワード プランのキーワードに対する指標の集計のリクエスト
  • フィルタ処理と選択を簡単にするため、ad_group_ad_label と ad_group_criterion_label ラベルを追加しました。
  • 入札戦略とキャンペーン シミュレーションの管理ができるようになります。
  • リソース超過エラーを更新し、超過した制限の種類や、その制限で許可されているリソースの数などの詳細情報を含めるようにしました。
  • 限界投資収益率キャンペーン推奨予算を利用できるようになります。キャンペーンの投資収益率が上昇することが予想される場合に、キャンペーンの予算を調整することが提案されます。
詳細やその他の機能については、リリースノートをご覧ください。


さらに詳しく知りたい方へ 以下のリソースが役立ちます。 ご質問やさらにサポートが必要なことがありましたら、フォーラムからご連絡ください。


Google Ads API チーム、Nadine Wang

この記事は Chrome プロダクト マネージャー、Thomas Nattestad による Chromium Blog の記事 "Chrome is up to 23% faster in M91 and saves over 17 years of CPU time daily" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

2008 年に Chrome がリリースされてから、スピードは高パフォーマンスのブラウザを提供するための 4 つの基本原則の 1 つであり続けています。ほぼすべてのウェブページで使われている JavaScript を最大限のスピードで実行するために欠かせないのが、V8 JavaScript コンパイラです。パフォーマンスの探求シリーズの次の投稿では、パフォーマンスが最大 23% 向上した V8 エンジンの改善方法について共有します。

高速なブラウザを提供するうえで重要な要素は、JavaScript を高速に実行することです。Chrome では、この作業を V8 エンジンが行っており、毎日 78 年分以上に相当する JavaScript コードが実行されています。M91 Chrome では、新しい Sparkplug コンパイラとショート ビルトイン呼び出しがリリースされ、最大 23% の高速化が実現し、毎日 17 年分以上に相当するユーザーの CPU 時間を節約できています。Sparkplug は新しい JavaScript コンパイラで、短時間で実行を開始する必要性と、コードが最大限のパフォーマンスを発揮するための最適化との間にあったギャップを埋めるものです。ショート ビルトイン呼び出しでは、生成したコードをメモリに格納する場所を最適化することで、関数を呼び出す際の間接ジャンプを回避します。
 
Sparkplug V8 エンジンには複数のコンパイラがあり、JavaScript 実行のさまざまなフェーズでトレードオフを使い分けることができます。3 年前に、Ignition と Turbofan で構成される新しい 2 層コンパイラ システムを導入しました。Ignition はバイトコード インタプリタで、できる限り遅延なく JavaScript の実行を開始する役割を担います。Turbofan は最適化をするコンパイラで、JavaScript の実行中に収集される情報に基づいて高パフォーマンスなマシンコードを生成します。そのため、起動は Ignition のバイトコード コンパイラよりも遅くなります。Sparkplug は Ignition と Turbofan のバランスをとったもので、ネイティブのマシンコードを生成しますが、JavaScript コードの実行中に集める情報には依存しません。そのため、すぐに実行を開始できるうえに、比較的高速なコードを生成できます。この新しいエンジンに使われている技術の詳細については、V8 ブログ投稿をご覧ください。



ショート ビルトイン ショート ビルトインは、V8 エンジンが生成したコードをメモリに格納する場所を最適化する仕組みです。V8 が JavaScript から CPU 固有のコードを生成すると、そのコードはメモリに配置されます。多くの場合、この生成されたコードはビルトイン関数を呼び出します。ビルトイン関数は、2 つの変数の加算などの基本的な演算から JavaScript 標準ライブラリの本格的な関数まで、あらゆる一般的なルーチンを処理する小さなコード スニペットです。CPU によっては、生成されたコードから離れた場所にある関数を呼び出すと、CPU 内部の最適化（分岐予測ロジックなど）が失敗する場合があります。これを防ぐには、生成されたコードと同じメモリ領域にビルトイン関数をコピーします。この変更は、新しい Apple M1 チップで特に大きな効果を発揮します。この機能によるさまざまなプラットフォームへの影響の詳細については、V8 ブログ投稿をご覧ください。
今後もさまざまなパフォーマンスの改善についてお知らせしますので、ご期待ください。

すべての統計情報の出典 : Speedometer 2.0

Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Devin Chasanoff による Google Ads Developer Blog の記事 "The Query Builder Blog Series: Part 5 - Determining Field Selectability" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

このブログシリーズでは、新しく改善されたインタラクティブ Google 広告クエリビルダー ツールの構築過程についてお伝えしています。シリーズのパート 4 では、ResourceService を作成し、アプリ内のユーザーのロケーションによって決まる FROM 句のリソースをもとにして関連フィールドを表示する方法について説明しました。パート 5 では、Google Ads Query Language（GAQL）クエリ文字列でフィールドが選択できるかどうかを決定する方法について説明します。


背景と目的フィールドが選択できるかどうか、すなわち、GAQL 文字列の句を追加できるかどうかは、1）FROM 句におけるメインリソースの固有のプロパティとそのフィールドのプロパティ、2）GAQL クエリ文字列の現在の状態、という 2 つによって決まります。ユーザーに選択可能なフィールドとして表示されるのは固有のプロパティだけなので、項目（1）にはパート 4 で作成した ResourceService で対処できます。

項目（2）に対処するために、SelectionService という新しいサービスを作成します。このサービスの役割は、選択可否の判断、フィールドの選択、フィールドの選択解除などです。この投稿では、フィールドの選択可否の判断について説明します。SelectionService によるフィールドの選択と選択解除の方法については、シリーズのパート 6 で説明します。
フィールドの同時利用性すべてのフィールドを同時に利用できるとは限りません。2 つのフィールドを同時に利用できる場合、両方のフィールドが 1 つの GAQL 文字列内に共存できます。2 つのフィールドを同時に利用できない場合は、2 つのフィールドのどちらかのみを GAQL 文字列のいずれかの句に含めることができます。そのため、評価対象のフィールドとは同時に利用できないフィールドが GAQL 文字列内にある場合、評価対象のフィールドは選択不可となります。UI はそれを反映し、対応するエラー メッセージをユーザーに表示します。





実装
incompatibleSelected というインスタンス変数で、メインリソースの各フィールドについて、同時に選択できないフィールドのうち現在選択されているものを追跡します。この変数は、それぞれのフィールドを、同時に選択できないフィールドのうち現在選択されているものの一覧を表す Set にマッピングします。

interface IncompatibleSelected: {[key: string]: Set<string>}


この incompatibleSelected を初期化して、ResourceService で求めたリソースのすべてのフィールドがマップのキーになるように、また各エントリの値が空の Set になるようにします。

フィールドが選択されると、incompatibleSelected の Set（選択されたフィールドと同時に選択できないフィールドの集合）に、選択されたフィールドを追加します。たとえば、FROM 句のリソースが ad_group であるとします。segments.ad_destination_type は、metrics.absolute_top_impression_percentage や metrics.active_view_cpm などとは同時に選択できません。次の表は、これらのフィールド間の同時選択性の関係を示しています。

フィールド 同時に選択できないフィールド
segments.ad_destination_type [metrics.absolute_top_impression_percentage, metrics.active_view_cpm, …]
metrics.absolute_top_impression_percentage [segments.ad_destination_type, …]
metrics.active_view_cpm [segments.ad_destination_type, …]
segments.ad_destination_type が選択されると、incompatibleSelected マップの metrics.absolute_top_impression_percentage と metrics.active_view_cpm のエントリに segments.ad_destination_type を追加します。

クエリのいずれかの句に segments.ad_destination_type を追加したときの incompatibleSelected フィールドの一部を抜粋すると、次のようになります。

incompatibleSelected = {
  …
  'segments.ad_destination_type': {},
  'metrics.absolute_top_impression_percentage': {'segments.ad_destination_type'}
  'metrics.active_view_cpm': {'segments.ad_destination_type'}
  ...
}


フィールドの選択を解除するたびに、最初にそのフィールドがクエリのいずれかの句に含まれているかをチェックする必要があります（詳しくはパート 6 で説明します）。含まれている場合は、incompatibleSelected を更新すべきではないからです。たとえば、segments.ad_destination_type が SELECT 句と ORDER BY 句で選択されており、ORDER BY でのみ選択解除された場合、まだ segments.ad_destination_type がクエリに含まれているので、incompatibleSelected マップを変更してはいけません。ただし、選択解除されたフィールドがどの句にも含まれていない場合は、Set（選択解除されたフィールドとは同時に選択できないフィールドの集合）からそのフィールドを削除できます。

先ほどの例で、SELECT 句から segments.ad_destination_type を削除すると、このフィールドはクエリに存在しなくなります。そのため、incompatibleSelected マップの metrics.absolute_top_impression_percentage と metrics.active_view_cpm のエントリからこのフィールドを削除します。この時点で、incompatibleSelected マップのすべてのエントリは空の Set となります。


このデータ構造があれば、フィールド名をパラメータとして受け取る isSelectable というメソッドを作ることができます。isSelectable は、incompatibleSelected でそのフィールドに対応する Set が空であれば true を、そうでなければ false を返します。


  isSelectable(field: string): boolean {
    return this.incompatibleSelected[field]?.size === 0;
  }

まとめ以上で、フィールドが選択可能かどうかを判断する SelectionService のロジックを実装できました。ユーザーにフィールドを表示する際には、isSelectable(field) を呼び出すだけで、UI に表示するものを決めることができます。今回の投稿では、フィールドの同時選択性と、フィールドが選択できるかどうかに関する内容を説明しました。パート 6 では、このセクションの内容をもとに、フィールドの選択や選択解除が行われたときに、SelectionService で GAQL クエリ文字列の状態を追跡する方法について説明します。

Google Ads API での GAOL クエリの構築についての理解が深まれば幸いです。ご質問やさらにサポートが必要なことがありましたら、フォーラムまたは googleadsapi-support@google.com にご連絡ください。


- Devin Chasanoff（Google Ads API チーム）

この記事は Fan Wang による Google Ads Developer Blog の記事 "AdWords API and Scripts: Deprecation of Automatic Placements in the Placement Performance Report" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


データ保持ポリシーの変更により、2021 年 6 月 10 日以降、AdWords API と Google 広告スクリプトの Placement Performance Report で、自動プレースメントが除外されました。その後の Placement Performance Report には、広告グループのレベルで管理と除外されるプレースメントのデータのみが含まれます。


変更点Placement Performance Report のスキーマ（属性、セグメント、指標）は変わりませんが、管理と除外されるプレースメントのデータのみが利用できます。明示的にターゲットが指定されていない自動プレースメントのデータは、このレポートから削除されます。このレポートからの自動プレースメント データ（WHERE Id = 0）に対するクエリは、空の結果を返します。


影響を受ける方 現在 AdWords API または Google 広告スクリプトを使って Placement Performance Report にアクセスし、自動プレースメントのレポートを取得しているすべてのデベロッパーが影響を受けます。


必要な対応AdWords API と Google 広告スクリプト アプリケーションのレポートのクエリを確認し、自動プレースメント レポートの代わりに Automatic Placement Performance Report を使うように変更してください。


ご質問やさらにサポートが必要なことがありましたら、Google Ads API と AdWords API フォーラムまたは googleadsapi-support@google.com にご連絡ください。


Google Ads API チーム、Fan Wang


Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team


2021 年 7 月 6 日（火）と 7 月 13 日（火）、ゲーム、アプリ業界で活躍するインフラエンジニア、サーバーアプリケーションエンジニア、テクニカルリーダーを対象に「CLOUD ONAIR 業種別 チャンネル - Google Cloud INSIDE Games ＆ Apps」を開催します。

Google Cloud をご活用いただいているお客様が、実際に開発・運用しているからこそのリアル体験をご紹介します。


開催概要名 称 : Google Cloud INSIDE Games ＆ Apps: Online

会 期 : 2021 年 7 月 6 日（火）、7 月 13 日（火） 18 : 00 – 19 : 00

主 催 : グーグル・クラウド・ジャパン合同会社




プログラム2021 年 7 月 6 日（火）

バーチャル体験とリアル体験の融合を叶える「プロジェクトセカイ」の裏側
　　伊藤 寛起 氏、株式会社 Colorful Palette エンジニアリングマネージャー
　　高橋 信頼 氏、株式会社 Diarkis 代表取締役CEO
　　吉村 光平、Google Cloud シニア アカウント エグゼクティブ



2021 年 7 月 13 日（火）

これを見れば、まるっとわかる。Google Cloud Day: Digital '21 Recap for ゲーム業界で働くエンジニア
　　川原 雄太、Google Cloud カスタマー エンジニア

2021 年 | Google Cloud 最新情報アップデートをまとめてご紹介。
　　田丸 司、Google Cloud カスタマー エンジニア




詳細・参加申し込みこちらからお申し込みください。




※ 競合他社様、パートナー企業様からのお申し込みはお断りさせていただくことがございます。
※ 報道関係者のご参加はお断りさせていただきます。
※ ビジネス向けのイベントとなっております。学生の方のお申し込みはご遠慮ください。



この記事は Google Maps Platform チームによる Google Cloud Blog の記事 "Using New WebGL-powered Maps Features" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


Google I/O 2021 において、Google は傾きと回転、および WebGL Overlay View のベータ版リリースを発表しました。これにより、まったく新しい方法でマッピング エクスペリエンスの構築が可能になります。Overlay View は Maps JavaScript API に以前から存在する機能で、マップの上に透明なレイヤをレンダリングできます。開発者は何年にもわたり、マップの上に 2 次元の描画をするため Overlay View を使用してきましたが、Overlay View ではマップの上に実質的に浮かんでいる透明なレイヤにしかレンダリングできない状態でした。


WebGL Overlay View では、ベクターの基本地図のレンダリングに使用されるのと同じ WebGL レンダリングのライフサイクルにに直接働きかけて、利用できます。これにより、初めて 2 次元と 3 次元のオブジェクトを直接マップ上に高速にレンダリングできるようになったため、従来の Maps JavaScript API では不可能であったユーザー体験が構築可能になりました。


この記事では、Maps JavaScript API の新しい WebGL による機能の簡単な概要をご紹介します。これにより、次世代のマッピング エクスペリエンスを作成するために十分な知識が得られます。


WebGL とは


WebGL は低レベルのブラウザ API で、元は Mozilla Foundation により作られたものです。この API を使用すれば、スマートフォンやコンピュータなどのクライアント デバイスの GPU のレンダリング能力や処理能力を、ウェブアプリから利用できます。ブラウザ単独では、3D 空間のオブジェクトのレンダリングといった重い処理を実行することはできませんが、WebGL を使用すれば、そのような処理に特化して設計されたクライアント側の GPU で実行できます。


WebGL について詳しくは、WebGL の設計と保守をしている Khronos Group のドキュメントをご覧ください。


要件

WebGL Overlay View を使用するには、ベクターマップが有効な Map ID が必要です。また、マップ ID を作成するときは、傾きと回転を有効にすることを強くおすすめします。これを有効にしないと、マップはデフォルトの真上からのビューに限定されます。言い換えると、マップを 3 次元的に動かすことはできません。

マップ ID とベクターマップの詳しい使い方は、関連ドキュメントをご覧ください。


傾きと回転の設定

設定された傾きと回転でマップを読み込むには、マップを作成するときに「tilt」と「heading」プロパティの値を指定します。

const mapOptions = {

  mapId: "15431d2b469f209e",

  tilt: 0,

  heading: 0,

  zoom: 17,

  center: {

    lat: -33.86957547870852, 

    lng: 151.20832318199652

  }

}

const mapDiv = document.getElementById("map");

const map = new google.maps.Map(mapDiv, mapOptions);

tilt は度単位の整数または浮動小数点数で、値は 0 から 67.5 までです。0 度はデフォルトの真下に向いたビューを、67.5 は最大の傾斜角度を意味します。設定可能な tilt の最大値はズームレベルによっても異なります。

回転は heading プロパティで、0 から 360 度までの整数または浮動小数点数として設定します。0 と 360 は北の方向を意味します。

また、傾きと回転は実行時のいつでも、プログラムからマップ オブジェクトに対して「setTilt」と「setHeading」を直接呼び出して変更できます。この機能は、ユーザーの操作などのイベントに対応してマップの向きを変える場合に役立ちます。

map.setTilt(45);

map.setHeading(180);


さらに、ユーザーは Shift キーを押したまま、マウスでドラッグするか矢印キーを使用して、マップの傾きと回転を手動でコントロールできます。

傾きと回転の詳しい説明は、ドキュメントをご覧ください。


WebGL Overlay View をマップへ追加する
「google.maps.WebglOverlayView」のインスタンスを作成すると、WebGL Overlay View を Maps JavaScript API で使用できます。オーバーレイのインスタンスを作成したら、インスタンスの「setMap」を呼び出して、マップに適用します。

const webglOverlayView = new google.maps.WebglOverlayView;

webglOverlayView.setMap(map);


マップの WebGL レンダリング コンテキストにアクセスし、そこでレンダリングするオブジェクトを扱えるようにするため、WebGL Overlay View ではベクター基本地図の WebGL レンダリング コンテキストのライフサイクルにおいて 5 つの機能を提供します。

概要について簡単にご説明します。
  • 「onAdd」では、たとえばフェッチや最終的にオーバーレイに渡すための中間データ構造の作成など、前処理をします。これらの処理をすべてここで行うのは、マップのレンダリング速度が低下しないことを保証するためです。
  • 「onRemove」では、すべての中間オブジェクトを破棄します。できればより早い段階で破棄します。
  • 「onContextRestored」はマップがレンダリングされる前に呼び出され、WebGL の状態、たとえばシェーダー、GL バッファ オブジェクトなどの初期化、バインド、再初期化をします。
  • 「onDraw」では、マップの実際のレンダリングと、その関連する操作に指定された動作をします。シーンをレンダリングするための描画呼び出しは、できるだけ最小限にしてください。ここで多くの動作をすると、基本地図のレンダリングと、WebGL で行うすべての動作の速度が低下します。
  • 「onContextLost」では、既存の GL ステートに関連付けられているすべてのステートをクリーンアップします。この時点では WebGL コンテキストは破棄されているため、これらのステートは無意味になっています。
これらの操作を実装するには、ひとつの関数にこれらを設定し、WebGL のレンダリング コンテキストのライフサイクルにおいて、適切な時点で Maps JavaScript API により実行されるようにします。例 :

webglOverlayView.>

coordinateTransformer) => { //レンダリングを実行 }


WebGL Overlay View と、そのライフサイクル操作の使い方について詳しくは、ドキュメントをご覧ください。

カメラ アニメーションの作成
WebGL Overlay View のベータ版リリースには「moveCamera」を紹介しています。これは新しくい統合されたカメラ コントロール手法で、カメラの位置、傾き斜、回転、ズームを同時に設定できます。「setTilt」や「setHeading」と同様に、「moveCamera」は「Map」オブジェクトに対して直接呼び出されます。

アニメーションのループで「moveCamera」を連続的に呼び出すと、カメラの位置の間で滑らかなアニメーションを作成できます。たとえば、この例ではブラウザの「requestAnimationFrame」API を使用して、各フレームの傾き斜と回転を変化できます。

const cameraOptions = {

  tilt: 0,

  heading: 0

}

function animateCamera () {

  cameraOptions.tilt += 1;

  cameraOptions.heading += 1;

  map.moveCamera(cameraOptions);

}

requestAnimationFrame(animateCamera);


ズームや浮動小数点数のサポートも含め、これらの調整によって従来では不可能であったようなカメラのコントロールが可能になるだけでなく、高い精度でカメラ位置をコントロールできるようになります。

「moveCamera」について詳しくは、ドキュメントをご覧ください。

試してみる
WebGL による Maps JavaScript API の新しい機能は、Beta チャンネルから API を読み込んで、今すぐ試すことができます。すぐに開発を始められるよう、新しい Codelab、すべての詳細が記されたドキュメント、サンプルコード、より詳細なサンプルアプリを用意しています。また、機能ツアーやトラベルのデモで詳細をご確認いただけます。さらに、これらの機能の実装をお試しいただけます。


フィードバックやご質問は、Issue Tracker にお寄せください。頂いたバグレポート、新機能のリクエスト、フィードバックなどは、新しい WebGL ベースのマップ機能のテストと改善に役立てさせていただきます。

3D でのマップ構築の可能性を探求し、優れたマップの作成にお役立てください。

Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やフィードバックはページ右上の「お問い合わせ」より承っております。