Google I/O 2021 での WebGL を利用したマップ機能のベータ版リリースの発表に備え、Google Maps Platform チームは、2012 年からの Google Cloud パートナーである Ubilabs と協力して、3D レンダリングを地図に導入すると実現できることをデベロッパーに紹介するためのデモを作成しました。最初のデモ「Google Maps Platform WebGL-powered Maps Features（Google Maps Platform WebGL を利用したマップ機能）」は、各 WebGL 機能とそれらを効果的に使用する方法をデベロッパー向けに詳しく紹介しています。

デベロッパー向けのデモでは、WebGL を利用したマップ機能の活用方法を Google Maps Platform デベロッパーに紹介しています。

2 番目のデモ「Travel with Next Generation Maps（次世代マップを活用した旅行）」では、架空の旅行アプリを例にして、Google Maps Platform の新しい 3D 機能でマッピング エクスペリエンスがどのように変容するかを全体像として見ることができます。

Ubilabs と開発した旅行デモでは、WebGL を利用したマッピング エクスペリエンスの効果をビジネス ユーザーに紹介しました。

WebGL を利用した新しいマップ機能の紹介

このプロジェクトに携わった Ubilabs のソフトウェア エンジニアである Martin Schuhfuss 氏は、2019 年の Google I/O で Google Maps Platform エンジニアリング リードの Travis McPhail と話したことを覚えています。その内容は、Google Maps Platform チームが一部の API で検討している変更と、ベクトル地図や 3D コンテンツをサポートするための取り組みについてでした。そして 2021 年。Schuhfuss 氏は Google I/O 2021 向けに Google Maps Platform の新しい WebGL 機能を紹介するデモの作成に向けて、Google Maps Platform チームとの打ち合わせに参加することになりました。信頼できる Google Cloud パートナーとして、Ubilabs はそれら機能の初期ユーザーに任命されていました。初期段階にある機能の常として、開発プロセスが進行する中、デバッグや初期ドキュメントの作成が必要になる可能性がありました。

Ubilabs の共同創業者かつ開発責任者であり、Google Maps Platform の Google Developer Expert である Martin Kleppe 氏も、プロジェクト マネージャーやデザイナー、その他 3 名のデベロッパーとともにプロジェクトに取り組みました。

Schuhfuss 氏は次のように語っています。「私たちはインターネットでの地図のユースケース、特に 3D のシーンで興味深いものを探しました。小規模なテスト版を作成し、自分たちに何ができるかを試していました。しかし、当時はドキュメントすら存在しませんでした。」

Ubilabs はデモのうち 1 つをデベロッパー向けとし、新しい機能について順を追って説明するとともに、コードサンプルを盛り込んで使用方法を紹介することにしました。2 番目のデモである旅行アプリは、航空便での移動、タクシー乗車、ホテルの検索、旅先での食事という場面に当てはめて新しい機能を紹介しています。Schuhfuss 氏は、WebGL ベータ版機能の初期ユーザーとして学んだすべてを効果的に要約した、ユーザー向けのデモ案内文を作成しました。そのテキストの大半は、機能を初めて試す他のユーザー向けにドキュメントにまとめられました。

Schuhfuss 氏は次のように語っています。「各機能について、できるようになったこと、そしてそれがどのように表示されるのかを示すのに最適な Google Maps Platform の使い方は何か。チーム内で自問を繰り返しました。そして、ある都市を訪れる旅の過程を、初めから終わりまで表現する旅行デモを作成することにしました。」

デベロッパーは真上から見下ろした、北が上になった 2D の地図表示に慣れています。そのため、Schuhfuss 氏は、どんな場面でも 3 次元機能を利用してカメラを動かし、地図に情報を追加できる仕組みの紹介に力を入れました。たとえば、以下のスクリーンショットでは、地図にシンプルな傾斜と回転を追加するだけで、エクスペリエンス全体がいかに変化するかがわかります。

この例では、デベロッパーに新しい傾斜と回転の機能が示されています。

Kleppe 氏は次のように説明します。「WebGL 機能の基盤をなすテクノロジーは、GPU による高速レンダリング サービスを使用します。ユーザーはマシンのグラフィック カードを使って建物を 3D レンダリングし、3D オブジェクトを空間に配置できます。以前は追加のレイヤとして地図上にデータを表示できるだけでしたが、現在では新たなレベルの制御が可能になりました。これにより、街の景色を見るような没入型エクスペリエンスを実現できます。」

まず、チームは小規模なデモを作成し、次にそれらをクリックして詳細を見られる大規模なデモに組み込みました。意図したとおりに機能しないものがあると、Ubilabs はトラブルシューティングを試み、Google Maps Platform エンジニア チームと協力して問題を修正しました。あるケースでは、Schuhfuss 氏が 3 つの異なるオブジェクトをあるシーンに追加すると、3 番目のオブジェクトは常に数秒後に消え、2 番目のオブジェクトはさらに数秒後に消えました。Ubilabs は、この問題に関するフィードバックを Google Maps Platform エンジニア チームと共有しました。同チームは次のリリースで問題を解決し、このサービスをユーザー向けに改善できました。

Schuhfuss 氏は次のように述べています。「私はデバッグに時間をかけ、起きている現象を把握しようとしました。建物の背後に隠れるようにレンダリングするものをオクルージョン（手前にある物体が背後にある物体を隠す状態）できるようにするには、WebGL コンテキストを共有する必要があります。WebGL はグラフィック カードと通信でき、小さな状態の変化の影響を受けやすいインターフェースです。」

Schuhfuss 氏は、緯度と経度による座標の把握と算出とは別に、かなりシンプルな Three.js 機能が残りの開発に必要であることがわかりました。同チームは Google Maps Platform チームと定期的に連絡を取り、進捗状況を確認し合いし、技術的な問題や更新に対処しました。

Google I/O のインタラクティブなデモ

Ubilabs は各デモの締めくくりに、デベロッパーが WebGL 機能で作成できるものとして、目を引く機能を紹介しました。

「旅行デモの最後のページは一番のお気に入りです」と Schuhfuss 氏は言います。氏は Google I/O の数日前にそのページを完全に再構築しました。「私が気に入っているのは、カメラを回転させたときのテキストラベルの動作と、建物が隠れるとテキストの下に小さなステムが表示されることです。」

ロンドンの観光スポットのテキストラベルが各場所の上に表示され、地図を回転させると、小さなステムが各建物をはっきりと指し示すように表示されます。

デベロッパー向けのデモの最後のページでは、ユーザーに「地図を再定義する」ことを推奨しており、埋め込みの動画や花火が表示されます。

Schuhfuss 氏は次のように語ります。「次に気に入っているのは花火です。動画を埋め込むことができ、どこかに表示したくて港にビデオウォールを構築しました。開発の途中では、リック・アストリーの曲も再生されていたようです。」

WebGL 機能を使用すると、動画を地図に埋め込んだり、花火などの機能を地図に追加したりできます。

「通りが表示された基本地図と、ビジネス情報を描画するレイヤ、ルートを計算するための追加 API など、さまざまなデータソースを組み合わせることができます。さらに、その上に独自の情報を配置できます。API のデータセットだけではありません。自分のデータを世界の抽象的なビューにいつでも自由に統合できます。」

さらに、Schuhfuss 氏は、slack ワークスペースの Three.js コミュニティも運営しており、オンラインで驚きの声が多数寄せられたことに加えて、「ユーザーによるこうした機能のユースケースを見るのを本当に楽しみにしています。」とも述べています。

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



Posted by 丸山 智康 (Tomoyasu Maruyama) - Developer Relations Engineer 

削減の準備

フェーズ 1: Chrome 92 から（2021 年 7 月 20 日）
推奨される対応（CTA）: サイトの使用方法を監査し、移行が必要になる可能性がある箇所を把握してください。
M92 より、navigator.userAgent、navigator.appVersion、navigator.platform へのアクセスに関する警告を DevTools に表示します。


フェーズ 2: Chrome 95 から Chrome 100
CTA: Chrome 101 がリリースされるまでの間、サイトをオリジン トライアルに登録し、フィードバックを提供してください。
みなさんからテストとフィードバックにご協力いただけるよう、サイトを削減版の UA 文字列の最終形にオプトインできるオリジン トライアルを開始します。これは少なくとも 6 か月間継続します。 
オリジン トライアル パートナーやコミュニティからのフィードバックを評価し、そのフィードバックに基づき、計画のフェーズ 3 から 7 を進めます。その間に、エコシステムが適応するための十分な時間をとります。もしくは、フィードバックに応じて、最善策について再検討します。


削減のロールアウト

フェーズ 3: Chrome 100
CTA: 必要に応じて、デプリケーション トライアル（オリジンを指定してサポートの終了を延期できるオプトイン機能）またはエンタープライズ ポリシーにサイトを登録してください。
サイトを移行する時間がさらに必要な場合などのために、デプリケーション トライアルとエンタープライズ ポリシーを開始します。

フェーズ 4: Chrome 101
CTA: サイトで削減版の Chrome バージョン番号との互換性を確保してください。確保できない場合は、UA Client Hints に移行します。
Chrome の MINOR.BUILD.PATCH バージョン番号を削減します （"0.0.0"）。これがロールアウトされると、デスクトップとモバイルのオペレーティング システムで、デプリケーション トライアルをオプトインしていないすべてのページの読み込みに、削減版の UA 文字列が適用されます。

フェーズ 5: Chrome 107
CTA: サイトで削減版のデスクトップ UA 文字列と関連する JS API との互換性を確保してください。確保できない場合は、UA Client Hints に移行します。
削減版のデスクトップ UA 文字列と関連する JS API（navigator.userAgent、navigator.appVersion、navigator.platform）のロールアウトを開始します。これがロールアウトされると、デスクトップのオペレーティング システムで、デプリケーション トライアルをオプトインしていないすべてのページの読み込みに、削減版の UA 文字列が適用されます。


フェーズ 6: Chrome 110
CTA: サイトで削減版のモバイル UA 文字列と関連する JS API との互換性を確保してください。確保できない場合は、UA Client Hints に移行します。
削減版の Android モバイル（とタブレット）の UA 文字列と関連する JS API のロールアウトを開始します。これがロールアウトされると、Android で、デプリケーション トライアルをオプトインしていないすべてのページの読み込みに、削減版の UA 文字列が適用されます。


削減の完了

フェーズ 7: Chrome 113
デプリケーション トライアルが終了し、すべてのページの読み込みに、削減版の UA 文字列と関連する JS API が適用されます。
詳細や、各フェーズでの User-Agent 文字列の例については、削減版の User-Agent 文字列に関する最新情報ページをご覧ください。重大な遅延や変更が発生した場合は、このページでもお知らせします。


※この投稿は米国時間 2021 年 9 月 15 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud Next（2021 年 10 月 12～14 日）の開催まであと 1 か月を切りました。この無料のフラッグシップ イベントで皆様にお会いできるのを心待ちにしております。イベントの全カタログを公開いたしましたので、ご自身にぴったりのコンテンツをお探しください。エキスパートによるライブ Q＆A をはじめ、ブレイクアウト セッション、没入型のデモ、Google Cloud の実際のユースケースをご覧いただけます。今年は、カスタム再生リストを作成して、視聴するセッションをパーソナライズすることや、見逃さないようにリマインダーやカレンダー通知を設定することもできます。

Next '21 に参加して、クラウドの現在と未来に関する情報を入手しましょう。業界をリードするデータや分析から、最適化、モダナイゼーション、セキュリティ、サステナビリティまで、Google Cloud をさらにオープンかつ高速で、柔軟性と信頼性の高いものにするために、Google が世界最大のプライベート ネットワークをどのように拡張しているかをご覧ください。11 のトラックにわたる 130 以上のセッションは、トラックやカテゴリなどでフィルタしたり、お気に入りのセッションをブックマークして後から視聴したりすることができます。

毎日、Google Cloud CEO の Thomas Kurian や Google Cloud 技術インフラストラクチャ部門シニア バイス プレジデント Urs Hölzle などの業界リーダーによるライブ配信と基調講演をご覧いただけます。一部のセッションをご紹介します。

  • Data cloud: Simply transform with a universal data platform
    貴社のエンタープライズ データは、データベース、データレイク、データ ウェアハウス、複数のクラウドに分散していませんか？すべて統合して、より迅速にイノベーションを実現し、カスタマー エクスペリエンスを向上させましょう。BigQuery、Cloud Spanner、Looker、Vertex AI を活用して会社のデータを統合するためのベスト プラクティスをご紹介します。

  • Developer platform state of the union: Google Workspace
    Google Workspace のデベロッパーが、アドオン、Google Chat アプリ、API、Google Meet のインテグレーションといった、一連の生産性向上ツールやコラボレーション ツールで利用できる最新の技術機能をご紹介します。

  • Data analytics strategy and roadmap: Turn data into differentiating feature
    データを使用して、より大きな価値を顧客に提供したいとお考えですか？意思決定インテリジェンスをビジネス プロセスに適用する方法を学びましょう。他の組織がどのように Google Cloud データ分析ソリューションを使用して、データをアクションに変換しているかご紹介します。

  • What's new and what's next with infrastructure for AI and ML
    今年人工知能（AI）と機械学習（ML）が遂げた進化について説明します。また、Cloud GPU や目的に特化した Cloud TPU などのハードウェア アクセラレータの最新イノベーションを使用してワークロードを強化する方法をご紹介します。

  • Transform your business operations with no-code apps
    誰でもアプリを作れると言ったら信じられますか？「コーディングの経験がまったくない」と自称するプロダクト マネージャーの Paula Bell 氏が AppSheet を使用して、電力会社 Kentucky Power の現場作業のやり方に革命をもたらすミッション クリティカルなアプリを作成した方法をご紹介します。また、AppSheet を使用して AI と ML をアプリに追加する方法もご説明します。

Google Cloud の Twitter で、クラウドのエキスパートやエグゼクティブが作成した個人的な再生リストを紹介していますのでぜひチェックしてください。また、再生リスト作成ツールを使って、ご自身で作成した再生リストを知り合いや同僚と共有しましょう。

情報を入手し、刺激を受けて、専門知識を広げるために、ぜひご参加ください。今すぐ登録して、あなただけの Next '21 を計画しましょう。


Posted by イベントおよび戦略的イニシアチブ担当ディレクター Matt Kaufman

Google は、 スタートアップを対象としたオンライン アクセラレーター プログラム「Google for Startups Accelerator Class 4 」を実施します。2021 年 9 月 16 日（木）より参加スタートアップの応募を開始し、2022 年 2 月 よりプログラムを開始いたします。詳細なスケジュールについては プログラムのウェブサイトをご確認ください。

Google for Startups Accelerator では、SDGsに沿った持続可能な産業化の促進、AIやIoTなどの技術を活用することで、経済発展と社会的課題の解決を実現するスタートアップを支援しています。

過去に日本のアクセラレーター プログラムに参加した Eco-Pork は、養豚とテクノロジーを繋ぐことで、養豚生産者の労働生産性の向上と共に、透明性の高い安心な食糧供給を統合的に支援しています。 また、同じく過去の ヨーロッパのアクセラレーターに参加した mDoc は、慢性疾患のある人々がアプリを通じて治療を受けられるように支援することで、医療と健康の分野に取り組んでいます。

このプログラムは、すでに商品またはサービスを市場に投入し、市場的価値が見込まれ、スケールする将来性があるスタートアップを対象に、これからの成長に備えるためのサポートを提供します。テクノロジーを活用した社会、経済、環境といった様々な分野の問題解決への取り組みを加速し、ひいては、スタートアップの成長が日本経済のさらなる活性化につながることを期待しています。

ぜひご応募ください。

Google for Startups Accelerator 活用の利点

  • Google 社員 および外部によるメンター制度 : Google Cloud、Google Ads  チームをはじめとする、さまざまなチームのエキスパートからのアドバイスや Google のテクノロジーや製品、サービス、さらに人的ネットワークを活用する機会を提供します。ベスト プラクティスの共有に加え、企業や製品に関する大枠の戦略策定サポートも提供しています。
  • トレーニング プログラム : 参加企業は機械学習や人材獲得・育成、製品開発管理に関する各種トレーニングを受講できます。機械学習など技術の活用を中心としたものからリーダーシップ トレーニングに至るまで、スタートアップが必要とするサポートを幅広く提供します。
  • スタートアップ エコシステム（コミュニティ）交流の機会：異業種のスタートアップや VC、エンジニアコミュニティ等との交流を通じ、人的ネットワークの拡大にも貢献します。

Google がスタートアップを支援する理由：

Google はテクノロジーが社会をより良くしていくと考えています。私たちは社会の大きな課題を解決するためのアイデアを持つスタートアップをテクノロジーの力で支援したいと考えています。


Google for Startups Accelerator が求めるチーム

  • 技術およびビジネスのチームが確立している。
  • すでに商品またはサービスを市場に投入し、市場的価値が見込まれ、スケールする将来性がある。
  • 売上または資本金を持つ（6 ヶ月以上の運転資金）。
  • 知識を共有し、Campus コミュニティおよび、より幅広いスタートアップ エコシステムの成長に貢献する意思がある。
  • 将来の展開と影響力に関して、高い可能性を持つ。
  • 経営チームは英語でのコミュニケーションが可能である。
  • Google アカウントを持っている。

募集概要

  • 対象 : スタートアップ 
  • 形態 : オンライン
  • 募集開始 : 2021 年 9 月 16 日（木）
  • 募集締め切り : 2021 年 11 月 12 日（金）18 時
  • 参加企業の発表 : 2022 年 1 月上旬頃を予定
  • プログラム実施期間 : 2022 年 2 月 下旬〜2022 年 5 月末（予定）
  • 応募条件や審査など詳細はウェブサイトをご参照ください。


Posted by Reisa Matsuda and Takuo Suzuki - Developer Relations Team

任意の移行

Serverless Expeditions がお送りする動画ミニシリーズ Serverless Migration Station は、Google Cloud で実行しているアプリケーションを最新化し、サーバーレス コンピューティング プラットフォームに移行するデベロッパーをサポートすることを目的としています。これまでのエピソードでは、従来の古い App Engine（標準環境）サービスを、Cloud Datastore などの Google Cloud の新しい同等なスタンドアロン機能に移行する方法を紹介しました。今回のエピソードは、App Engine から完全に移行し、アプリをコンテナ化して Cloud Run で実行するという点で少し異なります。

ここ 10 年ほどで、業界がアプリケーションのデプロイ メカニズムとしてコンテナ化に向かっていることに、疑問の余地はほとんどありません。しかし、初期の App Engine デベロッパーは、のちに柔軟な環境が利用できるようになるまで、Docker やコンテナを使うことはできませんでした。現在のデベロッパーは、ますますオープンになっている Google Cloud からさまざまな選択肢を選択できます。Google は App Engine の長期サポートを表明しており、ユーザーにとってアプリのコンテナ化は必須ではないので、この移行は任意です。そのため、主にアプリのデプロイ戦略にコンテナ化を追加し、明示的に Cloud Run への移行を考えているデベロッパー向けの内容になります。

アプリのコンテナ化について考えている方のために、動画ではその主な理由について説明しています。開発言語やバイナリの利用など、従来のサーバーレスの制約を受けることはありません（柔軟性）。コード、依存関係、コンテナのビルドとデプロイの手順が変わらなければ、同じイメージを確実に再作成できます（再現性）。必要に応じて、アプリケーションを他の場所にデプロイしたり、動作していた以前のイメージにロールバックしたりすることができます（再利用性）。さらに、アプリをホストする場所には、さまざまな選択肢があります（移植性）。

移行とコンテナ化

従来の App Engine サービスは、バンドルされた一連の独自 API を通して利用します。ご想像どおり、このサービスは Cloud Run では利用できません。そのため、アプリをコンテナ化して Cloud Run で実行するには、その準備が整っている必要があります。これは、Google Cloud の同等なスタンドアロン機能か、他のサードパーティの代替機能に移行された状態を指します。たとえば、最近のエピソードでは、Datastore にアクセスするために、App Engine の ndb を Cloud NDB に移行する方法について説明しています。

このような移行の動画を公開し始めたのは最近のことですが、デベロッパーはすでにコードサンプルや Codelab チュートリアルにアクセスできるようになっており、さまざまな移行が行われています。今回の動画では、従来のサービスから切り離され、Cloud Run でコンテナ化する準備が整った Python 2 と 3 のサンプルアプリを紹介します。Datastore にアクセスする Python 2 App Engine アプリでは Cloud NDB を、Python 3 ユーザーは Cloud Datastore を使うことになるでしょう。これが移行の開始点になります。

ここで行うのは実行プラットフォームの切り替え「だけ」であるため、アプリケーション コード自体は変更しません。必要になる移行は、アプリの設定を App Engine から Cloud Run に変更することだけです。具体的には、app.yaml、appengine_config.py、lib フォルダなどの App Engine アーティファクトは、Cloud Run で使うことはないため、削除します。また、コンテナをビルドするため、Dockerfile を導入します。app.yaml ファイルでこれよりも複雑な設定が行われているアプリでは、Cloud Run で同等の機能を持つ service.yaml ファイルが必要になります。この場合、app.yaml を service.yaml に変換するツールを使うと便利です。ベスト プラクティスに従うなら、.dockerignore ファイルも追加します。

App Engine と Cloud Functions はアウトソーシングのようなもので、Google Cloud が自動的に gunicorn などのデフォルトの HTTP サーバーを提供します。Cloud Run では、ユーザーがコンテナ イメージを提供してサーバーにバンドルしなければならないので、もう少し自作度が高くなります。この場合、下のスクリーンショットのように、明示的に gunicorn が選択され、既存の requirements.txt に記載された必須パッケージ ファイルの最上部に追加されます。また、最後のステップとして gunicorn を起動してアプリのサービスを開始する Dockerfile も示しています。Python 2 の Dockerfile との唯一の違いは、a）Cloud Datastore ではなく Cloud NDB パッケージ（google-cloud-ndb）が必須である点と、b）Python 2 ベースイメージから始める点です。

Python 3 の requirements.txt と Dockerfile のイメージ

Python 3 の requirements.txt と Dockerfile

次のステップ

デベロッパーの皆さんに移行手順を説明するため、動作するアプリ（START）から始めて、必要なアップデートをし、最終的に動作するアプリ（FINISH）を完成させます。今回の移行では、Python 2 サンプルアプリの START は Module 2a のコードで、FINISH は Module 4a のコードになります。同じように、Python 3 アプリの START は Module 3b のコードで、FINISH は Module 4b のコードです。このようにすれば、移行がうまくいかなくても、いつでも START にロールバックしたり、自分のソリューションと FINISH を比較したりできます。自分のアプリケーションでこの移行を検討している方には、サンプルアプリで試してから、自分のアプリについて検討することをお勧めします。動画に加えて、順を追ってこのエクササイズについて説明する Codelab もあるので、ガイダンスとしてお使いください。

すべての移行モジュール、動画（公開されている場合）、Codelab チュートリアル、START と FINISH のコードなどは、移行リポジトリにあります。近いうちに、Java 8 などの以前のランタイムについても説明したいと考えているので、ご期待ください。Module 5 でも、引き続き App Engine から Cloud Run への移行について説明しますが、コンテナ、Docker、Dockerfile についての知識がなくても大丈夫です。開発ワークフローを最新化し、コンテナと CI/CD パイプライン作成などのベスト プラクティスを活用することは、常に単純とは限りません。このようなコンテンツが、その方向に進む皆さんのお役に立つことを願っています。


Reviewed by Eiji Kitamura - Developer Relations Team

詳細は、Google Identity Services のプロダクトのお知らせをご覧ください。

サポートの利用方法

詳しい情報は、デベロッパー サイトに掲載されています。技術サポートを受けたい方は、Stack Overflow で google-signin タグを確認してください。提案やフィードバックは、[email protected] にお送りください。


Reviewed by Eiji Kitamura - Developer Relations Team

Share on Twitter Share on Facebook

以前お知らせしたように、すべての広告表示オプションは新しいアセットベースの拡張機能（表示オプション） パラダイムに移行します。そのため、実装の拡張機能のサポートをアップデートして、既存のフィードベースの拡張機能をアセットベースの拡張機能に移行する必要があります。すべての重要な移行や提供終了の日程については、移行スケジュールをご覧ください。

最初の自動移行は、2021 年 10 月 20 日に始まり、数週間にかけて完了する予定です。移行にあたっては、自分で拡張機能を移行することも、自動移行に任せることも、クライアント アカウントをオプトアウトして自動移行の対象外にすることもできます。移行期間中に、クライアント アカウントのフィードベースのコールアウト、プロモーション、サイトリンク、構造化スニペットの拡張機能は、新しいアセットベースの拡張機能にコピーされます。その後、フィードベースの拡張機能の代わりに、新しいアセットベースの拡張機能が提供されます。


自動移行にはどのような影響がありますか？

アカウントが移行されると、フィードベースのコールアウト、プロモーション、サイトリンク、構造化スニペットの拡張機能について、新しいアセットのインスタンスが作成されます。新しいアセットは、コピー元のフィードベースの拡張機能と同じ広告グループ、キャンペーン、お客様にリンクされます。新しいアセットには新しい ID が付与され、過去の指標も含め、自動移行で作成されたアセットとオリジナルのフィードには、関連付けられません。その後のすべての拡張機能に関連する指標は、asset_field_type_view レポートからのみアクセスできます。さらに、以下のサービスで、アカウントに存在するコールアウト、プロモーション、サイトリンク、構造化スニペットの拡張機能に影響する CREATE リクエストや MUTATE リクエストは行えなくなります。

サービス API リファレンス
ExtensionFeedItemService Google Ads API
AdGroupExtensionSettingService AdWords API Google Ads API
CampaignExtensionSettingService AdWords API Google Ads API
CustomerExtensionSettingService AdWords API Google Ads API
FeedService AdWords API AdWords API
FeedItemService AdWords API Google Ads API
FeedMappingService AdWords API Google Ads API
AdGroupFeedService AdWords API Google Ads API
CampaignFeedService AdWords API Google Ads API
CustomerFeedService AdWords API Google Ads API
GoogleAdsService Google Ads API
BatchJobService AdWords API Google Ads API


自動移行に任せる場合は、コールアウト、プロモーション、サイトリンク、構造化スニペットの拡張機能に影響する上記のサービスへの MUTATE リクエストや CREATE リクエストがエラーを返すようになると、アカウントが移行されたことがわかります。


オプトアウトにはどのような影響がありますか？

お客様アカウントごとにオプトアウトをし、10 月の自動移行の対象から外すことができます。オプトアウトをしても、自動移行のタイミングが 2022 年 2 月 15 日から始まる 2 回目の自動移行まで延期されるだけです。オプトアウトをすると、10 月の自動移行の際に、そのアカウントでリソースの作成や変更は行われません。また、10 月の自動移行後に CREATE リクエストと MUTATE リクエストの発行を続けることができるのは、オプトアウトしたアカウントのみです。

2022 年 2 月 15 日の自動移行はオプトアウトできません。移行スケジュールに記載されているように、残されているフィードベースの拡張機能は 2022 年 2 月 15 日以降、すべて自動移行されます。この 2 回目の自動移行が終わると、フィードベースの拡張機能に影響する CREATE リクエストと MUTATE リクエストは、すべてエラーを返すようになります。

何をする必要がありますか？

可能な場合は、ご自身で拡張機能を移行することを強くお勧めします。 拡張機能を移行する際のガイダンスとして、拡張機能の移行ドキュメントに従ってください。自動移行の際に重複を避けるため、拡張機能をアセットにコピーでき次第、フィードベースの拡張機能を忘れずに削除してください。

自動移行に任せる場合、必要になる実装の更新は、アカウントが移行されたタイミングを検知し、その後にフィードではなくアセットを管理するように切り替えることだけです。


オプトアウトする場合、そのアカウントが自動移行によって変更されることはありません。既存の API 実装は、2022 年 2 月 15 日に始まる 2 回目の自動移行まで動作を続けます。オプトアウトするには、こちらのフォームに以下の内容を入力する必要があります。
  • オプトアウトのプロセスで問題が発生した場合に連絡がとれる連絡先メールアドレス
  • アカウントの管理に使用しているデベロッパー トークン
  • オプトアウトの効果の確認
  • オプトアウトしたいお客様 ID を 1 行につき 1 件記述したテキスト ファイルのアップロード。お客様 ID のリストを生成する必要がある場合は、各クライアント ライブラリの AccountManagement ディレクトリにある GetAccountHierarchy サンプルを利用することをお勧めします。このサンプルは、指定した管理者アカウントから到達可能なすべてのアカウントのリソースの名前を返します。
このフォームは、2021 年 8 月 30 日から送信可能です。デベロッパー トークンは、2021 年 7 月 16 日以降にお客様アカウントよりリクエストをしたことが必要がある点に注意してください。フォームの提出の締め切りは、2021 年 10 月 13 日です。


ご質問やさらにサポートが必要なことがありましたら、フォーラムまたは [email protected] にご連絡ください。

- Google Ads API チーム、Andrew Burke

Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team

Share on Twitter Share on Facebook