[go: nahoru, domu]

この記事は Developer Advocate の Alex Muramoto による Google Cloud Blog の記事 "Behind the scenes: WebGL-powered Maps demos for Google I/O" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

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 

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

今年 5 月に、User-Agent 文字列削減計画についての最新情報 をお知らせし、適宜詳細をお伝えすることを約束しました。この度、削減版の User-Agent ヘッダー(とそれに関連する JS インターフェース)を オリジン トライアル(オリジンを指定して実験的機能を先行利用できるオプトイン機能)でテスト できるようになったので、現時点で想定しているスケジュールについてお知らせします。以下は元のブログ投稿の繰り返しになりますが、各フェーズが始まる Chrome の想定バージョンを記載しているので、準備のためにご活用ください。
Chromium スケジュール ダッシュボード は、それぞれの Chrome バージョンに関連する日付や、Canary 版からベータ版、安定版リリースに至る進捗を理解するうえで役に立ちます。
注 : エンジニアリングの想定期限に関する一般的な注意事項は、ここでも当てはまります。つまり、不測の事態により、遅延が発生する可能性があります。ただし、遅延が発生した場合でも、フェーズ間のスケジュールを縮めることはいたしません。

ロールアウト計画案

以下の変更は、7 つのフェーズに分け、オリジン トライアルのフィードバックを待ちながら、時間をかけて徐々にロールアウトする予定です。

削減の準備

フェーズ 1: Chrome 92 から(2021 年 7 月 20 日)
推奨される対応(CTA): サイトの使用方法を監査し、移行が必要になる可能性がある箇所を把握してください。
M92 より、navigator.userAgentnavigator.appVersionnavigator.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.userAgentnavigator.appVersionnavigator.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

この記事は Google Cloud、デベロッパー アドボケート、Wesley Chun(@wescpy)による Google Developers Blog の記事 "Containerizing Google App Engine apps for Cloud Run" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Google App Engine ヘッダー

任意の移行

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.yamlappengine_config.pylib フォルダなどの 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.txtDockerfile

次のステップ

デベロッパーの皆さんに移行手順を説明するため、動作するアプリ(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

この記事はプロダクト ソリューション エンジニア、Brian Daugherty による Google Developers Blog の記事 "Discontinuing Google Sign-In JavaScript Platform Library for web" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google は、ウェブでユーザーの個人情報を守るために、アプリやサービスへのログインをデフォルトで安全なものにする取り組みを続けています。先日は、その実現に向けて、Identity API ファミリーの新たな一員である Google Identity Services についてお知らせしました。これは、複数の ID サービスを 1 つのソフトウェア開発キット(SDK)にまとめたものです。今回は、ログイン方法を減らし、ユーザー エクスペリエンスをシンプルにする取り組みの一環として、ウェブアプリ向けに提供していた JavaScript ベースの Google プラットフォーム ライブラリのサポートを 2023 年 3 月 31 日をもって完全に終了することをお知らせします。

影響範囲

  • サポートの終了によって影響を受けるかどうかを評価してください。
  • 2023 年 3 月 31 日までに移行を完了してください。それ以降は、Google プラットフォーム ライブラリがダウンロードできなくなります。切り替えをする方のために、Sign In With Google 移行ガイドを提供しています。

影響の有無

サポートの終了は、Google Sign-in JavaScript ライブラリを使っているウェブアプリにのみ影響します。現在のウェブページで Google プラットフォーム ライブラリ(apis.google.com/js/platform.js)を読み込んでいる場合は、影響を受けるので、新しい Sign In With Google クライアント ライブラリに移行する必要があります。

アプリやプラットフォームでは、Google プラットフォーム ライブラリを使ってユーザーのログイン認証のみのフロー、データ共有のための認可フロー(ユーザーのカレンダーや写真の共有など)、またはその両方を同時にサポートできます。今回の移行は、認証フローと認可フローの両方が対象になります。

アプリやプラットフォームでは、Google が提供する複数の認証方法と認可方法を使うこともできます。以下は、今回のサポートの終了のお知らせには影響されません

  • Android や iOS のネイティブ アプリ SDK
  • Google の OAuth2 または OpenID サービスを直接呼び出しているアプリやプラットフォーム

変更点とメリット

ユーザーのログインを改善するという継続的な取り組みの一環として、Sign In With Google 用の新たな JavaScript ライブラリをリリースしました。これまでの認証や認可の機能に加えて、ユーザーの視認性や信頼性を向上させ、ログインの手間を減らすことができる新たなユーザー エクスペリエンスも提供します。

新しい JavaScript ライブラリへの移行にはたくさんのメリットがありますが、その一部を紹介します。

  • 少ない手間でユーザーのログインや登録が可能
  • ウェブ全体で一貫性のあるログイン操作をユーザーに提供可能
  • HTML や JavaScript を使用した安全なログイン方法をサイトに追加可能

ユーザーには次のように表示されます。

パーソナライズされたボタンと 1 タップ プロンプトの表示イメージ

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

サポートの利用方法

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


Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Chromium Blog の記事 "Chrome 94 Beta: WebCodecs, WebGPU, Scheduling, and More" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

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

WebCodecs

既存のメディア API(HTMLMediaElementMedia Source ExtensionsWebAudioMediaRecorderWebRTC)は高レベルで、特定の用途に特化しています。低レベルのコーデック API は、遅延の影響を受けやすいゲームのストリーミング、クライアント側のエフェクトやコード変換、ポリフィル対応のメディア コンテナのサポートなど、新たな用途に適しています。JavaScript や WebAssembly によるコーデック実装のように、ネットワークや CPU のコストが増加することはありません。

WebCodecs API は、すでにブラウザに組み込まれているメディア コンポーネントをプログラマーが利用できるようにすることで、このような不足を解消します。具体的には、次のような内容です。

  • 動画やオーディオのデコーダ
  • 動画やオーディオのエンコーダ
  • 未加工動画フレーム
  • イメージ デコーダ

この機能は Chrome 93 でオリジン トライアルを終えており、現在はデフォルトで有効です。詳しくは、WebCodecs による動画処理をご覧ください。

WebGPU

WebGPU API は、ウェブ用の WebGL と WebGL2 グラフィックス API の後継です。「GPU コンピュート」などの最新機能や、GPU ハードウェアへの低オーバヘッド アクセス、パフォーマンスや予測可能性の向上などが導入されています。既存の WebGL インターフェースはイメージの描画用に設計されたもので、かなりの労力をかけなければ他の用途の計算は行えませんでしたが、その点が改善されています。

WebGPU は、Direct3D 12、Metal、Vulkan といった最新のコンピュータ グラフィックス機能を公開し、グラフィックス プロセッシング ユニット(GPU)で行われるレンダリングや計算の操作をします。以前のテクノロジーと比べた場合の WebGPU の利点は以下のとおりです。

  • リソース管理、作業準備、GPU への送信を分割
  • OS の API と同じように動作するパイプライン状態
  • グラフィックス ドライバがレンダリング前に必要な準備をするためのバインディング グループ

この機能は、Chrome 99 での導入を目指して、Chrome 94 からオリジン トライアルが始まります。詳しくは、WebGPU で最新の GPU 機能にアクセスするをご覧ください。

Scheduling API: scheduler.postTask() による優先順位付け

ユーザーの操作に的確に応答し、時間が経っても応答性が低下しないウェブアプリを構築するのは困難です。応答性を阻害する主な原因の 1 つがスクリプトです。インクリメンタル サーチ機能について考えてみてください。この機能を搭載したアプリは、ユーザーの入力に追いつきつつ、結果をフェッチして表示する必要があります。その際、アニメーションなど、ページで起きていることは考慮されませんが、アニメーションはスムーズにレンダリングする必要があります。

通常この問題には、メインスレッドの作業を分割してスケジュールすることで対処できます。具体的には、適切なタイミングで作業を非同期的に実行します。しかし、このアプローチ自体にも問題があります。たとえば、デベロッパーがどのように優先度を設定しようと、メインスレッドでは時間の奪い合いが生じています。メインスレッドはデベロッパーが設定した優先度を認識しないだけでなく、fetch() 操作やガベージ コレクションといったブラウザのタスクも行っているからです。

scheduler.postTask() メソッドを使うと、デベロッパーが OS のブラウザのスケジューラで 3 段階の優先度(user-blocking、user-visible、background)を指定してタスク(JavaScript のコールバック)をスケジュールできるようになるので、このスケジュールのジレンマを解消できます。また、動的にタスクをキャンセルしたり、優先度を変更したりできる TaskController インターフェースも公開されます。

この機能は Chrome 93 でオリジン トライアルを終えており、現在の Chrome ではデフォルトで有効です。その他の新しいオリジン トライアルや完了したオリジン トライアルの一覧については、以下のオリジン トライアルのセクションをご覧ください。

オリジン トライアル

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

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

ナビゲーションの Early Hints

Chrome では、新しい HTTP ステータス コードである 103 Early Hints のテストが行われています。これは、早い段階でサブリソースをプリロードするためのものです。
<link rel=preload> などの link ヘッダーを含む 103 レスポンスを受け取ると、Chromium は最終的なレスポンスを受け取る前に、指定されたリソースのプリロード(またはプリコネクトやプリフェッチ、あるいはそのすべて)を試みます。ウェブ デベロッパーはこの方法を使って、アプリやサイト、ページを最適化できます。

完了したオリジン トライアル

Chrome で以前にオリジン トライアルが行われていた以下の機能は、現在デフォルトで有効化されています。

描画キャンバスのカラー マネジメント

このアップデートにより、CanvasRenderingContext2D オブジェクトと ImageData オブジェクトのデフォルトのカラースペースが sRGB であることが正式に明文化されます。そのため、CanvasRenderingContext2D インターフェースが完全にカラー マネジメントされる(すべての入力が描画キャンバスのカラースペースに変換される)ことが明確になります。これまでは、上記の動作は慣習上のものであり、明文化はされていませんでした。今回のアップデートで、以下の点が変更されます。

  • CanvasRenderingContext2D オブジェクトや ImageData オブジェクトを作成する際に、sRGB 以外のカラースペースを指定するパラメータが追加されます。
  • そのパラメータで利用できる Display P3 カラースペースのサポートが追加されます。

現在、CanvasRenderingContext2D で表示されるコンテンツは、sRGB カラースペースに限定されていますが、このカラースペースには最新のディスプレイやカメラほどの機能はありません。今回の機能で、Display P3 カラースペースを使用する CanvasRenderingContext2D オブジェクトを作成できるようになります。さらに、CanvasRenderingContext2D の色の動作に関して、いくつかの曖昧だった点が明確になります。

VirtualKeyboard API

VirtualKeyboard インターフェースには、仮想キーボードの表示や非表示のタイミングをコントロールするメソッドやプロパティが含まれています。また、仮想キーボードがページのコンテンツを遮ると、仮想キーボードのサイズを含むイベントが発行されます。仮想キーボードは画面に表示されるキーボードで、ハードウェア キーボードが利用できない場合の入力に使います。

ハードウェア キーボードとは異なり、仮想キーボードは想定される入力に合わせて形状を変えることができます。デベロッパーは、inputmode 属性によって仮想キーボードの表示形状をコントロールできますが、仮想キーボードの表示や非表示のタイミングのコントロールには制限がありました。

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

CSS

transform-style: preserve-3d と perspective プロパティが仕様に準拠

transform-style: preserve-3d と perspective プロパティが仕様に準拠します。preserve-3d プロパティを使うと、子要素を親の 3D シーンに追加できます。また、perspective プロパティは子要素に透視変換を適用します。この変更が行われる前の Chromium は、両方の効果を DOM ツリーではなく内包するブロック階層に基づいて適用し、変換関連のプロパティがない要素にも効果を拡張できるようになっていました。

flex-basis がキーワード 'content' と 'min/max/fit-content' を反映

Chrome は、flex-basis プロパティと flex 省略記法の値として、キーワード contentmin-contentmax-contentfit-contentサポートしますcontent キーワードを使うと、flex-basis と優先されるサイズ プロパティ(width または height)の両方が auto である場合のように、flex のベースサイズがデフォルトのサイズ計算ルールを使用します。flex-basisauto の場合、メインの軸の長さとして指定された widthheight は、すべて無視されます。その他のキーワードは通常と同じで、flex のベースサイズを細かく指定できます。

これまでは、レスポンシブ レイアウトでコンテナに対して display:flex を追加または削除する場合、個々の項目で値を追加または削除しなければならない場合がありました。content の導入により、それが不要になることもあります。

scrollbar-gutter

scrollbar-gutter プロパティは、スクロールバーのガター(スクロールバーを表示するために予約されている領域)の有無をコントロールします。これにより、コンテンツが増加した場合にレイアウトが変わることを防ぎつつ、スクロールが不要な場合に余分な領域が表示されないようにすることができます。

スクロールバーの有無自体は、overflow プロパティによって決まる点に注意してください。従来型のスクロールバーを使うかオーバーレイ スクロールバーを使うかを決めるのは、ユーザー エージェントです。デベロッパーは、このプロパティを使うことで、ブラウザが提供するスクロールバーとレイアウトとの相互作用を細かくコントロールできます。

MediaStreamTrack Insertable Streams(別名 Breakout Box)

この API を使うと、MediaStreamTracks によってローメディアを操作できます。操作できるのは、カメラやマイク、画面キャプチャ、コーデックのデコーダ部分などの出力や、コーデックのデコーダ部分への入力などです。WebCodecs インターフェースを使ってローメディアのフレームを表現し、ストリームを使って公開します。この仕組みは、WebRTC Insertable Streams が RTCPeerConnection からエンコード済みデータを公開する方法と同様です。サンプルのユースケースとして、おかしな帽子物体のリアルタイム検出や注釈付けがあります。

navigator.plugins と navigator.mimeTypes が固定のリストを返却

Flash が削除されたことで、navigator.plugins と navigator.mimeTypes から何かを返す必要はなくなりました。この API は、主に以下の目的で使われていました。

  • Flash プレイヤー サポートの確認
  • フィンガープリンティング

この API を使って PDF ビューアのサポートを確認しているサイトもあります。今回の変更により、この配列は PDF ビューア プラグインの標準リストを含む固定のリストを返すようになります。

これによって API が削除または変更されることはありません。2 つの既存 API で固定の配列が返されるようになるだけです。

JavaScript

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

Self Profiling API

Chrome がウェブ公開サンプリング プロファイラをサポートし、クライアント JavaScript の実行時間を計測できるようになります。実際のユーザーから JavaScript のプロファイルを収集すると、パフォーマンスの低下が観測された場合のデバッグに役立てることができます。面倒な手動インストルメンテーションをする必要はありません。

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

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

サードパーティ コンテキストでの WebSQL のサポート終了と削除

サードパーティ コンテキストでの WebSQL が非推奨となります。この機能の削除は、Chrome 97 で行われる予定です。Web SQL Database 標準が最初に提案されたのは 2009 年 4 月で、2010 年 11 月に検討が中止されました。Gecko はこの機能を実装しておらず、WebKit では 2019 年に非推奨となりました。W3C は、代替手段として Web StorageIndexed Database を推奨しています。

デベロッパーは、WebSQL 自体が非推奨であり、利用率が十分低くなった際に削除される予定であることを想定する必要があります。

サブリソースのプライベート ネットワーク リクエストをセキュア コンテキストに制限

サブリソースのプライベート ネットワーク リクエストは、セキュア コンテキストからのみ開始できます。プライベート ネットワーク リクエストとは、パブリック ネットワークで開始され、プライベート ネットワークを対象とするリクエストです。これには、インターネットから イントラネット へのリクエストや、イントラネット ループバックなどが含まれます。

今回の対応は、プライベート ネットワーク アクセスの完全実装に向けた最初の一歩です。ローカル ネットワーク内やユーザーのデバイス上で実行されているサーバーは、ウェブに充実した機能を公開しますが、これは危険な場合もあります。プライベート ネットワーク アクセスで提唱されている一連の変更は、サーバーに外部エンティティとの通信をオプトインさせることで、このようなサーバーへのリクエストによる影響を制限します。

このオプトインが意味を持つためには、クライアントのオリジンが認証されていることをサーバーが確認できなければなりません。これを実現するため、セキュア コンテキストのみに外部リクエストの実行を許可します。


Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Andrew Burke による Google Ads Developer Blog の記事 "Feed-based Extensions Migration Reminder and Opt Out Instructions" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

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

最初の自動移行は、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 日です。


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



この記事は Google Cloud プロダクト マネージャー、Christiaan Brand による Google Online Security Blog の記事 "Simplifying Titan Security Key options for our users" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

この度、Google ストアの Titan セキュリティ キーのラインナップの変更についてお知らせします。この変更によって、これまでよりもシンプルになり、適切なセキュリティ キーを簡単に選べるようになります。今後は、USB-A バージョンと USB-C バージョンの 2 種類の Titan セキュリティ キーのみを提供します。どちらのキーにも近距離無線通信(NFC)機能が搭載されているので、ほとんどのモバイル デバイスで利用でき、モバイル デバイスに接続したキーをタップするだけで安全にログインできます。

Google は 2018 年に、認証情報のフィッシングに対する直接的な防御として Titan セキュリティ キーを導入しました。フィッシングとは、攻撃者がユーザーを欺いてユーザー名とパスワードを入力させることを指します。これは、オンライン アカウントを侵害する方法の中でも、特に簡単で成功率の高い方法であり続けています。Titan セキュリティ キーと高度な保護機能プログラムによる業界トップクラスの自動保護の組み合わせは、Google アカウントを安全に保つために特に効果的な方法の 1 つです。


新しい Titan セキュリティ キー オプションの紹介 現在、NFC 機能はさまざまな Android スマートフォンや iPhone でサポートされているので、Bluetooth Titan セキュリティ キーは終了し、今後は、より簡単で広く使われている NFC 機能に注力します。ただし、Bluetooth Titan セキュリティ キーを使っている既存ユーザーのために、これらのキーは引き続き Bluetooth でも動作し、ほとんどの最新モバイル デバイスでは NFC キーとして利用することもできます。既存の Bluetooth Titan セキュリティ キーに適用されている保証は、利用規約に応じて今後も継続されます。すべての Titan セキュリティ キーには、Google が制作したファームウェアを搭載したハードウェア セキュア エレメント チップが組み込まれているので、キーの整合性を検証できます。

USB-A ポートを搭載したコンピュータをお持ちの方には、USB-A + NFC セキュリティ キーをお勧めします。

USB-C ポートを搭載したコンピュータをお持ちの方には、USB-C + NFC セキュリティ キーをお勧めします。


USB-C コネクタを搭載した iPad をお持ちの方は、USB-C Titan セキュリティ キーを利用できます。Lightning コネクタを搭載した iPad をお持ちの方には、USB-A Titan セキュリティ キーと Apple Lightning アダプタをお勧めします。


Titan セキュリティ キーは、Google ストアで購入できます。USB-A + NFC キー(USB-A to USB-C アダプタ付き)は 30 ドル、USB-C + NFC キーは 35 ドルで販売しています。
セキュリティ キーがフィッシング対策にどう役立つかを詳しく知りたい方は、Titan セキュリティ キー プロダクト ページをご覧ください。

Reviewed by Eiji Kitamura - Developer Relations Team