この記事は Chris Banes による Android Developers - Medium の記事 "Jetpack Compose — Before and after" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
今年になってから、サンプル アプリTivi の UI を Jetpack Compose に徐々に移行していました。そして 2020 年 12 月第 2 週、移行作業の第一段階がほぼ完了しました。
今回のブログ投稿では、重要な指標の数値を振り返って比較し、Compose によって何が変わるのかを確認してみましょう。比較するのは、APK サイズ、ビルド速度、コードの行数です。
Compose の話題を進める前に、まずは簡単にアプリについて説明します。
Tivi はかなり細かくモジュール化されており、それぞれの UI の「画面」ごとに Gradle モジュール（ui-$NAME）があります。それぞれの画面は Fragment で実装され、メインアプリ モジュールでは AndroidX Navigation を使ってそれらを組み合わせています。
ナビゲーション グラフはディープリンク URI を使って実装されているので、ほとんどの Fragment はお互いのことを知りません。そのため、疎結合が保証されます。しかし、それよりも重要なことは、独立してコンパイルできるため、ビルドの並列化がしやすくなることでしょう。
Compose に移行する前の Tivi は、Android デベロッパーが利用できるありとあらゆるクールな UI を利用していました。一例をあげれば、データ バインディング、Epoxy、マテリアル デザイン コンポーネント、Insetter DBX、MotionLayout などです。しかし残念ながら、これらの大半ではアノテーション処理が使われているため、ビルドのコストがかかります。
先ほど、移行の「第一段階」を終えたばかりだと書きました。これはどういう意味でしょうか。2020 年 1 月にこの作業を始めたときから、アプリの見た目はほとんど変わっていません。
アプリがモジュール化されているということは、移行自体も部品単位になり、一度に 1 つの Fragment だけ移行できるということです。この 11 か月間はまさにそれを実践し、46 個のプル リクエストに対応しています。
最初に簡単な画面 Episode details を移行し、次に Show details、そして ‘Discover’、‘Search’、‘Followed shows’ と移行を進めました。最近追加された Compose の Paging3 サポートと合わせて、最後の画面となった ‘list’ グリッドを移行できました。
2020 年 12 月 10 日（日本時間 12 月 11 日）、アプリから AppCompat、マテリアル デザイン コンポーネント、その他の AndroidX ウィジェット ライブラリを削除する処理を始めました。これは、Tivi の UI が Compose ベースになったことを意味します。
Remove AppCompat + MDC by chrisbanes · Pull Request #737 · chrisbanes/tivi
アプリで Fragment と Navigation を使っている点は変わりませんが、論理的な次のステップは、Fragment から移行して直接新しい Navigation Compose コンポーネントを使うようになります。
この移行の過程は近日中に別のブログ記事で書きたいと思いますが、本投稿の最後の「まとめ」から、私自身の言葉を引用しておきます。
いろいろ考えなくても、Compose が Android の UI 開発の未来であることはわかります。
では、いくつかの指標を確認してみましょう。
以下のそれぞれの指標では、3 つのバージョンのアプリを比較します。
ユーザーが最も気にする指標は、APK サイズです。
以下の結果は、リソース圧縮を有効にし、R8 を使って最小化した release APK を APK Analyzer で測定したものです。
‘adjusted’（調整済み）の値と ‘Pre-Compose’ を比較すると、Compose を使った場合は APK サイズが 41%、メソッド数は 17% 削減されていることがわかります。
Compose を使った場合は、APK サイズが 41%、メソッド数は 17% 削減されていることがわかる
この数から、AppCompat や MDC などがアプリ内でどれほどの容量を占めているかがわかります。それだけではなく、レイアウト ファイルで使われる場合に備えてすべての View クラスを保持しなければならない場合には、最小化ツールはほとんど役に立たないこともわかります。
ソフトウェア プロジェクトを比較する場合、ソースの行数を数えても特に役立つ統計情報にはならないことは承知していますが、この比較によって、どのような変化が起きているのかは確実に把握できます。
このテストでは、cloc ツールで以下のコマンドを使い、すべてのビルドと生成されたファイル、設定ファイルを除外しました。
cloc . --exclude-dir=build,.idea,schemas
cloc ツールにはコメントを無視する機能が組み込まれているので（ただし、検証はしていません）、上記は実際の「コード」の結果です。当然ながら、XML の行数は大幅に少なくなり、76% 削減されています。レイアウト ファイル、スタイル、テーマなど、たくさんの XML ファイルとお別れできます。
同じように興味深いのは、Kotlin の合計行数も減っていることです。仮説としては、アプリ内のボイラープレートが減り、たくさんのビューヘルパーやユーティリティ コードを削除できたためだと考えられます。3,000 行近くを削除できたこちらの PR をご覧ください。
Remove a load of old code 🗑️ by chrisbanes · Pull Request #713 · chrisbanes/tivi
ビルド速度はデベロッパーの関心が非常に高い指標です。このプロセスを開始する前は、多くのアノテーション プロセッサを削除できることでビルド速度が向上するものと考えていましたが、どの程度かはよくわかりませんでした。
テストの設定
説明を続ける前に、以下の数値をどのようにして測定したのかを知っておくことが重要になります。ここでは、Chris Horner が異なる CPU でビルド速度を測定したときと同じ設定を使いました。
テストに使ったマシンは、192 GB の RAM と超高速な Xeon® Gold 6154 CPU を搭載した Lenovo P920 です。言うまでもなく、このマシンは一般的なデベロッパーの設定ではありません。そこで、現実に近いテストを行うため、CPU を最低クロック周波数に固定しました。
# Use performance governor to allow tweaking of max freq
sudo cpupower frequency-set -g performance
# Set max frequency to CPU minimum: 1.2GHz
sudo cpupower frequency-set -u 1.2GHz
その後、すべてのリモート アーティファクト キャッシュを準備するため、./gradlew assembleDebug を実行しました。
そして、テストを実行するため、次のコマンドをループで 5 回実行します。
./gradlew --profile \
--offline \
--rerun-tasks \
--max-workers=4 \
assembleDebug
厳密には --max-workers は必要ありませんが、この CPU では、デフォルトで Gradle が利用できる 64 個の「コア」のすべてが使われます。これを 4 に制限することで、通常のラップトップ CPU と比較しやすくします。
テスト結果は以下のとおりです。それぞれの結果プロファイル レポートの ‘Total Build Time’（合計ビルド時間）の値をご覧ください。
この結果にはかなり驚かされました。ほとんど数値が変わらなかったからです。予想では、多くのアノテーション プロセッサが削除されることで、‘Without view libs’（ビュー ライブラリなし）が大幅に速くなると思っていました。
結果の明細を見てみると、kapt の実行時間はすべて同じくらいでした。おそらくこれは、View Binding、Dagger/Hilt、Room の使用を継続しているためではないかと思います。
しかし、Kotlin コンパイラや Compose コンパイラ プラグインが行ってくれることを考えれば、ビルド時間が 5% 削減されたことに何も不満はありません。
これまでに説明してきた全ての結果に当てはまる注意点があります。
この 11 か月間、Tivi には何の機能も追加しませんでしたが、この点を厳密に制限したわけではありません。移行とはあまり関係のない部分で多くの変更を行っており、それが結果に影響した可能性もあります。
移行を行った 11 か月間で、多くの依存性が更新されました。ほとんどの依存性の更新はランタイム ライブラリの依存性だったので、APK サイズ指標に影響する可能性は低いはずです。
Gradle のアップデート（6.0.1 から 6.7.0）、Android Gradle Plugin のアップデート（3.6.0 から 4.2.0）、そして Kotlin のアップデート（1.3.61 から 1.4.20）などは、すべてビルド速度に大きな影響があります。
Compose は現在アルファ版なので、すべての成果物は開発中のスナップショットになります。来年 1.0 の安定版になったとき、これらのテストを再実行して違いが出るかを見るのが楽しみです。
結果と注意点を見る限り、リンゴ 🍎 とリンゴ 🍏 を比較しているわけではない（同じ条件で比較しているわけではない）ので、あまり多くの結論を出すべきではありません。これは、リンゴ 🍎 とそれよりも少し甘いナシ 🍐 を比べているようなものです。
果物の例はさておき、最大のポイントは Compose がほとんどのデベロッパー指標で良好な（または中立的な）影響を示していることです。この点と Compose でデベロッパーの生産性が大幅に向上することを踏まえれば、いろいろ考えなくても、Compose が Android の UI 開発の未来であることはわかります。
個人や小規模グループでゲームを開発するデベロッパーの情熱やイノベーションを称えるため、今年 3 年目となる Google Play | Indie Games Festival 2020 を開催しました。例年のようにファイナルイベントを公開対面形式で実施できないため、オンラインでの最終選考会をデベロッパーや、株式会社 Sisilala 安藤様を始めとする業界のさまざまな方からのご協力のもと開催することができました。
多くの取り組みが変更を余儀なくされる中でも、従来のイベントでは実現できなかった Top 20 全作品のプレゼンテーション枠の確保など、オンラインだからこそ実現できることに取り組みました。動画内では、Top 3 に入賞した合同会社リビルドゲームスの「METBOY!」様からイベントに対する感想も頂戴しています。
Google Play | Indie Gaes Festival 2020 の詳細をまとめた動画をご覧ください。
この記事は Nick Rout による Android Developers Blog の記事 "MAD Skills Material Design Components: Wrap-Up" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Modern Android Development（最先端の Android 開発）について取り上げる連載シリーズ MAD Skills の動画と記事の 3 番目のトピックが完結しました。今回は、マテリアル デザイン コンポーネント（MDC）についてご説明しました。このライブラリは、マテリアル コンポーネントを Android ウィジェットとして提供します。これを使うと、マテリアル テーマ、ダークテーマ、モーションなど、material.io で使われているデザイン パターンを簡単に実装できます。
説明した内容については、下記にまとめた各エピソードからご確認ください。これらの動画では、MDC についての最新の記事や、既存のサンプルアプリ、Codelab を詳しく説明しています。また、MCD チームのエンジニアによる Q&Aセッションも含まれています 。
最初のエピソードは、Nick Butcher が、なぜ私たちが MDC の利用を推奨するのかなど、今回の MAD Skills シリーズ全体の概要を説明しています。その後、マテリアル テーマ、ダークテーマ、モーションについて詳しく掘り下げていきます。また、MDC を Jetpack Compose と合わせて使う方法、MDC やテーマ、スタイルのベスト プラクティスを含むようにアップデートされた Android Studio のテンプレートについてもお話ししています。
エピソード 2 では、Nick Rout がマテリアル テーマについて説明し、Android で MDC を使ってこれを実装するチュートリアルについて解説しています。主な内容は、Theme.MaterialComponents.* アプリのテーマを設定し、material.io のツールを使用して色や種類、形状の属性を選択し、最終的にそれらをテーマに追加して、ウィジェットがどのように自動的に反応して UI を適応させるかを確認します。また、テーマカラー属性を解決する、イメージに図形を適用するなど、MDC が特定のシナリオ向けに提供している便利なユーティリティ クラスについても説明します。
Theme.MaterialComponents.*
Chris Banes が、Android アプリで MDC を使ってダークテーマを実装する方法を紹介しています。説明する内容は、Force Dark を使って短時間で変換しビューを除外する方法、デザインを選んでダークテーマを手動で作成する方法、`.DayNight` MDC アプリテーマ、`.PrimarySurface` MDC ウィジェット スタイル、そしてシステム UI を扱う方法などです。
エピソード 4 では、Nick Rout がマテリアルのモーション システムについて解説しています。また、既存の「Android でマテリアル モーションを使って美しい画面遷移を構築する」Codelab の手順を詳しくフォローしています。この Codelab では、Reply サンプルアプリを使って、コンテナ変換、共有軸、フェードスルー、フェードという遷移パターンを活用してスムーズでわかりやすいユーザー エクスペリエンスを実現する方法を紹介しています。また、Fragment（Navigation コンポーネントを含む）、Activity、View を使うシナリオについて説明しています。
エピソード 5 は、Android コミュニティから Google Developer Expert (GDE) の Zarah Dominguez さんが、MDC カタログアプリをウィジェットの機能や API の例として参考にしながら紹介してくれました。そのほか、異なる画面やフローにまたがる一貫したデザイン言語を確保するために、彼女が取り組んでいるアプリに「テーマショーケース」ページを構築することが、どのように有益であるかを説明しています。
最後のまとめとして、Chet Haase が MDC エンジニアリング チームの Dan Nizri と Connie Shi と一緒に Q&A セッションを行い、Twitter や YouTube で寄せられた皆さんからの質問に回答しました。このセッションでは MDC の起源、AppCompat との関係、今までの改善点について解説したほか、テーマやリソースを整理するためのベストプラクティス、さまざまなフォントやタイポグラフィ スタイルの使用方法、シェイプ テーミングなどについてお話しました。また、私たちはお気に入りの Material コンポーネントをすべて公開し、最後に、将来的に MDCと Jetpack Compose という Androidの次世代 UI ツールキットでは、デフォルトで Material Design が組み込まれる新しいコンポーネントが登場することについて議論しました。
このシリーズでは、MDC のデモとして、次の 2 つのサンプルアプリを使いました。
これらは、もう 1 つの Material Studies のサンプルアプリである Owl とともに、GitHub リポジトリの MDC サンプルで確認できます。
Reviewed by Takeshi Hagikura - Developer Relations Team and Hidenori Fujii - Google Play Developer Marketing APAC
数億人のユーザーが Chrome ウェブストアで公開されている 250,000 件以上の拡張機能を利用しています。拡張機能は、多くの人々がウェブを体験し、オンラインで作業する際に欠かせないものになっています。私たちは、拡張機能はデフォルトで信頼できるものでなければならないと考えています。そのため、この 1 年を通して拡張機能をあらゆる人にとって安全なものにする取り組みを行ってきました。
本日は、Chrome 拡張機能の Manifest V3 の計画的ロールアウトについて正式にお知らせします。Manifest V3 は拡張機能プラットフォームの新バージョンで、デフォルトで拡張機能の安全性、パフォーマンス、プライバシーを強化します。
Manifest V3 の導入と合わせて、リモートでホストされるコードを禁止します。この仕組みは、悪意のあるユーザーが Google のマルウェア検出ツールを回避する攻撃ベクトルとして使われることがあり、ユーザーのプライバシーやセキュリティに重大なリスクを与えています。
リモートでホストされるコードがなくなることで、Chrome ウェブストアの申請に対するレビューをより細かく、迅速に行えるようにもなります。そのため、デベロッパーはすばやくアップデートをユーザーに提供できます。
拡張機能チームは、信頼性の高い Chrome と信頼性の高い拡張機能はユーザーにとってすばらしいだけでなく、デベロッパーにとっても不可欠だと考えています。長期的に見れば、Manifest V3 は、拡張機能エコシステムが信頼できる場所であり続けるために役立つはずです。
すばらしいユーザー エクスペリエンスにはパフォーマンスが欠かせません。そのため、3 世代目となる拡張機能プラットフォームの検討に着手するにあたって、パフォーマンスが基本的な検討事項でした。これが明確に現れているのが、バックグラウンド ロジックと API 設計という 2 つの領域へのアプローチです。
まず、バックグラウンド ページを置き換えるものとして Service Worker を導入します。バックグラウンド ページは永続的なので、アクティブな状態がバックグラウンドで維持され、システム リソースを積極的に使っているかどうかにかかわらずリソースを消費します。それとは異なり、Service Worker は一時的です。つまり、Chrome は必要に応じて Service Worker を起動したり破棄したりできるので、全体的なシステム リソースの使用量を削減できます。
次に、拡張機能の API 全体を、宣言的なモデルに移行します。この効果は、セキュリティ面のメリットだけではありません。シリアル化やプロセス内通信が不要になるため、全般的なエンドユーザーのパフォーマンスを確実に保証できるようになります。これにより、拡張機能のほとんどのユーザーで全般的なパフォーマンスが向上し、プライバシーが保証されるようになります。
拡張機能がデータをどのように使い、どのように共有するかをユーザーが認識して制御できるように、拡張機能のモデルを移行します。つまり、オプション扱いのパーミッションを増やし、ユーザーがインストール時に機密性の高いパーミッションを許可しないこともできるようにします。拡張機能のデベロッパーは、長期的な視野を持ち、ユーザーがいつでもパーミッションをオプトインまたはオプトアウトすることを想定する必要があります。
ウェブ アクティビティに反応して処理する必要がある拡張機能では、ユーザーのプライバシーを保護しつつこのようなユースケースに対応できる新機能の検討と試行を続けています。たとえば、新しい declarativeNetRequest API は、拡張機能がプライバシーを保護しつつ、機密データにアクセスせずにネットワーク リクエストをブロックできる方法として設計されています。
declarativeNetRequest
広告ブロッカーを含めた拡張機能は、ユーザーの機密情報を含む可能性があるデータにアクセスすることなく、コア機能を提供し続ける必要があります。declarativeNetRequest API は、それを実現するために Chrome が行っていることの一例です。これにより、エコシステム内のたくさんの強力な拡張機能が、ユーザーのプライバシーを尊重しつつ、シームレスなユーザー エクスペリエンスを提供し続けることができるようになります。
Manifest V3 のドラフト提案を初めて Chromium デベロッパー コミュニティに共有したとき、たくさんの有用なフィードバックをいただきました。どうもありがとうございました。私たちは、プラットフォームの進化に向けて、広告ブロッカー、ショッピング拡張機能、生産性向上、デベロッパー ツールなど、多くの拡張機能のデベロッパーの皆さんと共同で作業を進めています。
このフィードバックは、Manifest V3 に関連する API サーフェスの機能や使いやすさの改善に活用されています。たとえば declarativeNetRequest には、複数の静的ルールセットやルール内の正規表現、宣言的なヘッダーの変更などのサポートを追加しました。
「Manifest V3 の導入後も広告ブロック拡張機能を確実に利用できるようにするため、Google の Chrome 拡張機能チームと当社のエンジニアリング チームの間で密接な協力関係が培われました。そのことをとてもうれしく思っています」 — eyeo（Adblock Plus）、テックリード、Sofia Lindberg 氏
ユーザーのプライバシーを保護しつつ、デベロッパーにとってさらに強力な V3 を実現できるように、フィードバックの反映や新機能の追加を継続する予定です。そのため、Manifest V3 のリリース後も、機能追加や試行は続きます。この検討に参加したい方は、chromium-extensions Google Group でコメントを追加するか、発言してください。
現在、Manifest V3 は Chrome 88 ベータ版で試験運用版として利用できます。今後のリリースでは、すばらしい機能がさらに導入される予定です。Chrome ウェブストアでは、Chrome 88 が安定版になる 1 月中旬より、Manifest V3 拡張機能を受け付ける予定です。Manifest V2 拡張機能のサポートが終了する厳密な日付は決まっていませんが、Manifest V3 が安定版チャンネルに到達してから、少なくとも 1 年の移行期間が設けられます。スケジュールについては、今後数か月でさらに詳しくお伝えする予定です。
アプリのデベロッパーは、広告や購入、サブスクリプションを通じて収益を獲得できる必要があります。収益化を成功させる第一歩は、アプリを見つけてもらうことです。
現在、Progressive Web App（PWA）を Google Play に掲載できるようになっていますが、加えて、Chromebook と Android デバイスの PWA で Google Play Payments が使えるようになったことをお知らせします。これにより、今までになく簡単に Google Play に登録し、PWA を多くのユーザーに提示してシンプルで安全な支払いを受けられるようになります。
Chromebook と Chrome OS は、リリースされたときから、ウェブを中心として構築されたデバイスがコンピューティングを簡単、高速、安全にできることを証明してきました。昨年には、Chrome OS に PWA のサポートが追加され、高品質なアプリ体験がモバイル以外にも拡大しました。これは明らかにユーザーの反響を呼び、昨年、Chromebook の販売台数は前年比（YOY）で 85% 増加し1、PWA のインストール数は 2 倍以上に増加しました2。
ローカル ファイル システムへの保存やデバイス通信など、ウェブアプリに追加されたさまざまな新機能によって、Chromebook ユーザーに最高の体験を提供できるチャンスが生まれました。
今後も、検索は新しいウェブアプリをすばやく簡単に探す方法であり続けます。しかし、多くの人は、1 か所でデバイスに最適なソフトウェアを見つけるためにアプリストアを訪れています。そこで、Chrome OS 版の Google Play で、Trusted Web Activity を使っている PWA を一覧表示できるようにしました。そのため、ユーザーは Play ストアでコレクションやおすすめを参照してウェブアプリを探すことができます。また、インストールすると、Chrome の機能を使って、おなじみの全画面アプリとして楽しむこともできます。
オンラインのイメージ、動画、GIF 編集プラットフォームである Kapwing などのブランドは、PWA のリリースによって大きな成果をあげています。
「PWA 化したウェブサイトをリリースしたあとの最初の 5 週間で、PWA を使って動画を作成したユーザーの数は 36% 増加しました。この利用数の増加はウェブサイト全体の利用数の増加を超えており、PWA をインストールしたクリエイターは維持率が高いことを示しています」 - Kapwing の CEO、Julia Enthoven 氏
アプリで支払いを受け取る場合、Google Play と Digital Goods API を使って簡単に処理できます。この機能は、Chrome OS 88 でフラグを設定することでテストでき、2021 年 3 月の Chrome OS 89 でリリースされる予定です。
この API を使うと、アプリ内で 1 クリックで支払いやサブスクリプションを提供でき、ユーザーにはおなじみの Google Play の課金フローが表示されます。クレジット情報や支払い情報を保存することもできます。
Chromebook の PWA には大きな反響が寄せられています。ユーザーは、Adobe Spark や Corel の Gravit Designer の高度なグラフィック、Clipchamp の使いやすい動画編集、YouTube TV のパワフルな視聴体験を楽しんでいます。このようなアプリは、Chrome OS 89 で Digital Goods API が利用できるようになり次第、Play ストアに登場します。皆さんと共有できるのが楽しみです。
デベロッパーの皆さんが大画面向けウェブアプリを生み出す道のりを見るのはすばらしいことです。このようなすばらしいウェブアプリを Google Play で公開できることが待ち遠しくてたまりません。ぜひ皆さんのアプリも公開してください！
出典: 1 The NPD Group, Inc.、U.S. Retail Tracking Service、2020 年 1-8 月のノートブック コンピュータ販売台数に基づく 2 2019 年 12 月から 2020 年 12 月の Chrome 利用状況指標
Google は最新の技術情報やツールを、ウェブサイトやブログ、メール、各種動画、オンラインや対面のイベントで広くデベロッパーの皆さまに提供しています。2020 年はオンラインでの情報発信を強化し、Android 11 Android Developers Japan Blog の開設や、Android 11 Meetups をはじめ、さまざまなイベントをオンライン開催に切り替えました。以前より、サービスの改善と技術力、スキルの向上に Google の最新技術を積極的にご活用頂いている株式会社 LIFULL は、昨年から本年にかけてマテリアル デザインを使ってアプリの UI/UX を刷新しました。大規模な改修の後にも関わらず、ユーザー レビューで高い評価を得るなど、ビジネス面でも良い結果を残すことができました。
株式会社 LIFULL の取り組みをまとめた動画をご覧ください。
Posted by Tamao Imura - Developer Marketing Manager, Platforms and Ecosystems
Google では今年 7 月から、Maps JavaScript API のドキュメントにて TypeScript のサンプルの公開を開始しました。これは、最先端をいくウェブ デベロッパーを支援することを目的としたものです。JavaScript デベロッパーを対象にした 2019 年の調査によると、およそ 60% の人が TypeScript を使用したことがあり、今後も使用するつもりであると回答しています。また、同言語を学ぶことに興味があると回答した人の割合は 20% を超えています。Google では、Google Maps Platform デベロッパーが開発を行いやすい環境の整備に努めています。TypeScript は人気が高まっているだけでなく、Google Maps Platform での開発時にコード検証ができて便利であるという点からも、Google ではこの言語をサポートすることを重視しています。
新しいサンプルコードを表示するには、任意のスニペットで TypeScript タブをクリックします。たとえば、JavaScript 用の Simple Map のサンプルは以下のとおりです。
ここに、TypeScript のタブが以下のように追加されました。
TypeScript と Google Maps Platform のガイドでは、使用可能なコンパイラ オプションやインストール手順など、基本的な情報を紹介しています。入門に最適な内容となっていますので、ぜひご活用ください。なお、サンプルコードの公開にあたっては、オープンソースの TypeScript コミュニティの成果および DefinitelyTyped で維持、公開されている型定義を大いに活用させていただきました。これらの型は、NPM で以下を実行してインストールできます。
npm i -D @types/googlemaps
もちろん、サーバー環境で Google Maps Platform の API を使用している Node.js デベロッパーのことも忘れていません。クライアント ライブラリの TypeScript 書き換えを今年すでに公開済みです。
Google Maps Platform の詳細については、ウェブサイトをご覧ください。ウェブサイトでは Google Maps Platform の詳細やニュースレターの購読などをご案内しています。
