リリースされたばかりの Pixel 6 と Pixel 6 Pro は最も安全な Pixel スマートフォンであり、5 年間にわたるセキュリティ アップデートが適用されるほか、最もレイヤー数の多いハードウェア セキュリティを備えています。これらの新しい Pixel スマートフォンでは、レイヤー化されたセキュリティ アプローチを採用しており、Google Tensor SoC（System on a Chip）ハードウェアから Pixel で先行利用できる Android オペレーティング システムの新機能に至るまでのイノベーションを活用して、チップからデータセンターまでを網羅する Google セキュリティが適用された最初の Pixel スマートフォンを実現しました。また、複数の専属のセキュリティ チームが開発を担当して、透明性と外部検証を通じて Pixel のセキュリティを証明しています。
コアにセキュリティを提供
Google は、Google Tensor を使用して、ハードウェア セキュリティの最重要部にユーザーデータの保護と透明性を提供しています。Google Tensor のメイン プロセッサは Arm ベースであり、TrustZone™ テクノロジーを活用しています。TrustZone は、一般的な処理を安全に行うセキュリティ アーキテクチャの重要な要素ですが、Google Tensor に含まれているセキュリティ強化は、TrustZone の一歩先を進んでいます。
Google Tensor セキュリティ コアは、ユーザー プライバシーの保護に特化したカスタム設計のセキュリティ サブシステムです。このサブシステムは、アプリケーション プロセッサとは論理的かつ物理的に異なり、専用 CPU、ROM、OTP（1 回しか書き込めない）メモリ、暗号化エンジン、内部 SRAM、保護された DRAM で構成されます。Pixel 6 と Pixel 6 Pro の場合、セキュリティ コアの主要なユースケースには、実行時にユーザーデータ キーを保護したり、セキュアブートを強化したり、Titan M2TM と連携したりすることが含まれます。
ハードウェアの安全性は、OS が安全であるときにのみ確保されます。Google では、オープンソースの信頼できる実行環境である Trusty を使用しています。Trusty OS は、TrustZone と Google Tensor セキュリティ コアの両方で使用される安全な OS です。
Pixel 6 と Pixel 6 Pro では、Google がすべてを設計して開発した別個のセキュリティ チップである新しい Titan M2TM によってセキュリティが強化されています。この次世代チップを採用したことにより、Google は社内設計した RISC-V プロセッサに移行し、速度とメモリ容量を向上し、高度な攻撃に対する耐性をさらに強化しています。Titan M2TM は、独立した認定済みの評価ラボによって、脆弱性評価の最も厳格な標準である AVA_VAN.5 に照らしてテストされています。Titan M2™ は Android StrongBox をサポートします。Android StrongBox は、PIN とパスワードの保護に使用されるキーを安全に生成して格納し、Google Tensor セキュリティ コアと連携して、SoC で使用中のユーザーデータ キーを保護します。
システムが改善された Pixel 6 と Pixel 6 Pro は、Android 12 と、Pixel で先行利用や限定利用ができるたくさんの機能が搭載された状態で出荷されます。
強化されたコントロール
Google は、Android のリリースのたびに、データをコントロールしてデバイスを管理するより適切な方法をユーザーに提供することを目指しています。Pixel で使用される Android 12 以降では、新しいセキュリティ ハブを使用して、すべてのセキュリティ設定を 1 か所で管理することができます。つまり、デバイスの現在の構成を一元的に表示することにより、スマートフォン、アプリ、Google アカウント、パスワードを保護できるようにしています。また、セキュリティ ハブは、セキュリティを改善するための推奨事項を提供するため、ニーズに最適な設定を判定できるようになります。
Google はプライバシーのためにプライバシー ダッシュボードをリリースし、過去 24 時間以内に位置情報、マイク、カメラにアクセスしたアプリをシンプルで明確なタイムライン形式で表示できるようにしています。予想よりも多くのデータにアクセスしているアプリに気付いた場合、ダッシュボードには、それらのアプリのパーミッションをすぐに変更できるコントロールへのパスが表示されます。
さらに透明性を向上するため、アプリがカメラやマイクにアクセスしていることが、Pixel のステータスバーにある新しいインジケーターでわかるようになっています。アクセスを無効にしたい場合、プライバシーの新しい切り替え機能により、1 回タップするだけで、スマートフォンのアプリによるカメラやマイクへのアクセスをいつでもオフにすることができます。
Pixel 6 と Pixel 6 Pro には、セキュリティが低い 2G ネットワークにアクセスするデバイスの機能を削除する切り替え機能も含まれています。一部の状況では 2G ネットワークへのアクセスが必要になりますが、さらなる攻撃ベクトルが発生する可能性があります。この切り替え機能は、2G 接続が不要なときに、そのリスクを軽減することに役立ちます。
組み込みのセキュリティ
Google はすべてのプロダクトをデフォルトで安全にするために、オンラインの安全を維持することに他の誰よりも取り組んでいます。また、Pixel 6 と Pixel 6 Pro では、デフォルトで組み込まれている保護機能を強化しています。
画面に埋め込まれた光学指紋認証センサーは、バイオメトリック情報の安全を確保し、デバイスの外に流出することを防ぎます。Google の継続的なセキュリティ開発ライフサイクルの一環として、Pixel 6 と Pixel 6 Pro の指紋認証によるロック解除は、外部のセキュリティ エキスパートによって、Android 12 互換性定義ドキュメント（Compatibility Definition Document、CDD）で定義されているクラス 3 強度要件を満たす安全な生体認証ロック解除メカニズムとして検証されています。
フィッシングは強大な攻撃ベクトルであり続け、さまざまなデバイスを使用しているすべての人に影響を及ぼしています。
Pixel 6 と Pixel 6 Pro では、新しいフィッシング対策保護機能が導入されています。組み込みの保護機能は、通話、テキスト メッセージ、メール、アプリを通じて送信されるリンクからの潜在的な脅威を自動的にスキャンし、潜在的な問題がある場合は、ユーザーに通知します。
また、ユーザーは、Google Play プロテクト内のオンデバイス検出機能に加えられた機能強化により、悪意のあるアプリからより強固に保護されています。Google Play プロテクトは 2017 年にリリースされて以来、デバイスがオフラインのときでも、悪意のあるアプリを検出できるようにしてきました。Pixel 6 と Pixel 6 では、Google Play プロテクトでのマルウェア検出を強化する新しい機械学習モデルを使用しています。この検出機能は Pixel で実行され、フェデレーション アナリティクスと呼ばれるプライバシー保護テクノロジーを使用して、一般的に実行される悪意のあるアプリを検出します。これにより、すでに 1,000 億個のアプリを毎日分析して脅威を検出している Google Play プロテクトが改善され、30 億人を超えるユーザーにさらに強固な保護を提供します。
Pixel の多くのプライバシー保護機能は、残りのオペレーティング システムやアプリから分離されたオープンソースのサンドボックスである Private Compute Core 内で実行されます。Google のオープンソースの Private Compute Services は、これらの機能のネットワーク通信を管理し、プライバシーを保護すると同時に、フェデレーション ラーニング、フェデレーション アナリティクス、個人情報の取得を通じて機能を改善します。Private Compute Core ですでに実行されているいくつかの機能には、自動字幕起こし、この曲なに？、スマート リプライの提案などが含まれます。
Google Binary Transparency（GBT）は、Google のオープンで検証可能なセキュリティ インフラストラクチャに追加された最新機能であり、デバイスのソフトウェア整合性に新しいレイヤーを追加します。証明書の透過性によって導かれる原則を基に構築された GBT は、Pixel で実行できるソフトウェアを、認定された OS ソフトウェアのみに限定します。GBT は、システム イメージのハッシュを署名し、追加専用のログに格納することで機能します。このログは公開され、公開されたハッシュとデバイスにあるハッシュが同じであることを検証するために使用できます。これにより、ユーザーと研究者は初めて、OS の整合性を独立して検証できるようになりました。
スマートフォン以外への拡張
多層防御は、ハードウェアとソフトウェアのレイヤーだけの問題ではありません。セキュリティは厳密なプロセスです。Pixel 6 と Pixel 6 Pro では、設計やアーキテクチャの詳細なレビュー、セキュリティ上重要なコードのメモリ安全な書き換え、静的分析、ソースコードの公式検証、重要なコンポーネントのファジング、デバイスに侵入テストする外部のセキュリティ ラボなどが含まれたレッドチームを活用しています。また、Pixel は Android 脆弱性報奨金プログラムに含まれています。昨年、このプログラムでは 175 万ドルが支払われ、Google とセキュリティ リサーチ コミュニティの間に有益なフィードバック ループを構築したほか、最も重要であるユーザーの安全を引き続き確保できるようにしています。
ハードウェアとソフトウェアが組み合わされた、このセキュリティ システムを締めくくるのは Titan Backup Architecture です。このアーキテクチャにより、クラウドでの Pixel の安全な土台が確保されます。Android のバックアップ サービスと Google Cloud の Titan テクノロジーの組み合わせは 2018 年に発表され、クライアント以外は Google を含め誰もが知らないランダムに生成されたキーのみによって、バックアップされたアプリケーション データを復号化できるようにします。このエンドツーエンドのサービスはサードパーティのセキュリティ ラボによって別個に監査され、パスコードを明確に知らない限り、ユーザーのバックアップされたアプリケーション データに誰もアクセスできないことが検証されました。
ハードウェアやソフトウェアからデータセンターに至るまでのこのエンドツーエンドのセキュリティに加え、Pixel 6 と Pixel 6 Pro デバイスでは、米国で発表されてから 5 年以上の Android セキュリティ アップデートが保証されています。これは、業界にとって重要な取り組みであり、他のスマートフォン メーカーもこの取り組みを推進することを望んでいます。
Google は安全なチップセット、ソフトウェア、プロセスを連携させることにより、Pixel 6 と Pixel 6 Pro を最も安全な Pixel スマートフォンにすることができました。
理由と解説 : 悪意のある人物がデベロッパー アカウントにアクセスできる場合、既知の貢献者になりすまして悪意のあるコードを送信する可能性があります。貢献者には、commit を送るプラットフォームだけでなく、メールなどの貢献に関連するアカウントに対して、多要素認証（MFA）を使うことを推奨しましょう。可能であれば、MFA の方式でお勧めなのはセキュリティ キーです。
理由と解説 : セルフマージ（一方的な変更とも呼ばれます）には、1）貢献者のアカウントを乗っ取った攻撃者がプロジェクトに悪意のあるコードを注入する可能性がある、2）善意の貢献者が意図しないセキュリティ リスクを含む commit をマージする可能性がある、という 2 つのリスクがあります。悪意のあるコードの送信や意図しない脆弱性を回避するために役立つのが、身元が明らかで信頼できる別の人の目です。可能であれば、GitHub のブランチ保護設定などを使い、自動要件として設定しましょう。Allstar などのツールも、この要件の適用に役立ちます。これは、SLSA レベル 4 に対応します。
理由と解説 : 「多層防御」というセキュリティの考え方は、複数の異なる防御レイヤーを設けてシステムやシークレット * などの機密データを守ることを指します。シークレット マネージャー ツール（GCP ユーザーの Secret Manager や、HashiCorp Vault、CyberArk Conjur、Keywhiz など）を使うと、ソースコードにシークレットをハードコードする必要はなくなり、集中管理や機能の監査を実現できます。また、シークレットの漏洩を防ぐ認可レイヤーを導入することにもなります。
* 機密データを CI システムに保存する場合は、それが CI/CD のためだけに使われることや、パスワードや ID マネージャーに格納するほうが適したデータではないことを確認してください。
理由と解説 : デフォルトでプロジェクト リポジトリに対して「必要最低限のアクセス」を付与することで、意図しないアクセスと不正利用の両方から CI/CD システムを守ることができます。テストを行うことは重要ですが、デフォルトですべての commit と pull リクエストに対してレビュー前にテストを実行すると、CI/CD システムのコンピューティング リソースの意図しない不正利用につながる可能性があります。
理由と解説 : 手動でビルド手順を実行すると、意図しない構成ミスが紛れ込む可能性があります。しかし、ビルド スクリプト（ビルドやビルドの手順を定義した build.yaml などのファイル）を使えば、手動でビルドする必要はなくなります。加えて、悪意のある人物がビルドを改ざんしたり、レビューされていない変更を紛れ込ませたりする機会を減らすことにもなります。これは、SLSA レベル 1～4 に対応します。
理由と解説 : 1 つの決定的な手法でパッケージが「良い」か「悪い」かを判断することはできません。セキュリティ プロファイルや許容できるリスクは、プロジェクトごとに異なります。プロジェクトにとって依存関係が「安全」であるかどうかを判断するうえで役立つのは、依存関係やどのような変更が推移的に取り込まれるかの情報を集めることです。Open Source Insights（deps.dev）などのツールは、最初のレイヤーと推移的依存関係をマッピングしてくれます。一方の Scorecards は、セキュリティ ポリシー、MFA、ブランチ保護の使用有無など、複数のリスク評価指標に基づいてパッケージのスコアを算出します。
使っている依存関係を把握できたら、定期的に Open Source Vulnerabilities などの脆弱性スキャンツールを実行します。そうすることで、常に最新のリリースやパッチについての情報を得ることができます。多くの脆弱性スキャンツールは、アップグレードの自動適用にも対応しています。
理由と解説 : ビルドの出所（ビルドの来歴）とアーティファクトを表示すると、ビルドが改ざんされていないことや、正しいものであることをユーザーに示すことができます。来歴にはさまざまな要素があります。こういった要素を実現する 1 つの方法は、来歴を表示するために必要なデータを生成と認証するビルドサービスを利用することです。これは、SLSA レベル 2～4 に対応します。
理由と解説 : 来歴の生成やビルドの署名は、自分のプロジェクトで行うべきことであるだけでなく（SLSA レベル 2～4）、他者のアーティファクトを使うときも、同じ証明を求めるべきです。ロゴなどのブランドに基づく認定形態は偽造可能で、タイポスクワッティングによって正当性を偽装できます。署名などの偽造できない証明を求めるようにしてください。たとえば Sigstore は、OSS プロジェクトでビルドに署名したり、他者のビルドを検証したりする際に役立ちます。
特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2021 年 10 月 21 日の時点で Chrome 96 はベータ版です。
来年には、Chrome でバージョン 100 がリリースされます。つまり、Chrome のユーザー エージェント文字列で報告されるバージョン番号の桁が増えます。サイトオーナーが新しい文字列をテストしやすくするために、Chrome 96 では、Chrome のユーザー エージェント文字列として「100」が返されるようにするランタイム フラグが導入されています。chrome://flags/#force-major-version-to-100 と呼ばれるこの新しいフラグは、Chrome 96 以降で利用できます。
chrome://flags/#force-major-version-to-100
このバージョンの Chrome には、以下のオリジン トライアルが導入されています。オリジン トライアルとして新機能を試せるようにすることで、ウェブ標準コミュニティにユーザビリティ、実用性、有効性についてのフィードバックを提供することができます。以下の項目を含め、現在 Chrome でサポートされているオリジン トライアルに登録するには、Chrome オリジン トライアル ダッシュボードをご覧ください。Chrome のオリジン トライアルの詳細については、ウェブ デベロッパーのためのオリジン トライアル ガイドをご覧ください。Microsoft Edge は、Chrome とは別に独自のオリジン トライアルを行っています。詳細については、Microsoft Edge オリジン トライアル デベロッパー コンソールをご覧ください。
現在、他のウィンドウやタブをキャプチャするアプリケーションには、呼び出し元のアイテムやキャプチャするアイテムにフォーカスするかどうかをコントロールする方法がありません（ビデオ会議アプリのプレゼンテーション機能を思い浮かべてください）。Chrome 96 では、新しい focus() メソッドをサポートする FocusableMediaStreamTrack と呼ばれる MediaStreamTrack のサブクラスを使用して、このコントロールを可能にしました。次のコードをご覧ください。
focus()
FocusableMediaStreamTrack
MediaStreamTrack
stream = await navigator.mediaDevices.getDisplayMedia(); let [track] = stream.getVideoTracks();
このコードでは、以前は getVideoTracks() が MediaStreamTrack オブジェクトの配列を返していましたが、FocusableMediaStreamTrack オブジェクトを返すようになります（Chrome 97 では、返されるオブジェクトが BrowserCaptureMediaStreamTrack に変更される予定です。本記事の執筆時点で、Canary 版ではすでに新しいオブジェクトが返されるようになっています）。
getVideoTracks()
BrowserCaptureMediaStreamTrack
フォーカスするディスプレイ メディアを決定するには、このコードの次の行で "focus-captured-surface" を指定して track.focus() を呼び出し、新しくキャプチャするウィンドウやタブにフォーカスするか、"no-focus-change" を指定してこのメソッドを呼び出し、呼び出し元のウィンドウにフォーカスし続けます。Chrome 96 以降では、デモコードを試して、この機能の動作を確認できます。
"focus-captured-surface"
track.focus()
"no-focus-change"
Priority Hints では、デベロッパーが設定する "importance" 属性が導入され、計算されるリソースの優先度を変更することができます。サポートされる importance 属性の値は、"auto"、"low"、と "high" です。Priority Hints は、リソースの相対的な重要度をブラウザに示し、リソースが読み込まれる順序をより細かくコントロールできるようにします。ブラウザでは、リソースのタイプ、可視性、プリロードのステータスなど、多くの要素がリソースの優先度に影響を及ぼします。
"importance"
"auto"
"low"
"high"
プリフライト リクエストなしに、単純な Range ヘッダーを指定してリクエストを送信できるようになりました。CORS リクエストでは、プリフライト リクエストをトリガーせずに、Range ヘッダーを限定的な方法（1 つの有効な範囲のみ）で使用できます。
バックフォワード キャッシュにページが格納され、クロスサイト ナビゲーションをした後でも、以前にアクセスしたページへの即時ナビゲーションが可能になります。
Cross-Origin-Embedder-Policy には、クロスオリジン no-cors リクエストで認証情報（Cookie やクライアント証明書など）を省略できるようにする新しい credentialless オプションが追加されます。COEP:require-corp と同じように、クロスオリジン分離も有効化できます。
Cross-Origin-Embedder-Policy
no-cors
credentialless
COEP:require-corp
SharedArrayBuffer を使い続けたいサイトでは、クロスオリジン分離をオプトインする必要があります。COEP: require-corp を使用して、クロスオリジン分離のオプトインを大規模に導入することは難しく、すべてのサブリソースで明示的にオプトインしなければならなくなります。これが問題にならないサイトもありますが、ユーザーからコンテンツを収集するサイト（Google Earth、ソーシャル メディア全般、フォーラムなど）では、依存関係の問題が発生します。
COEP: require-corp
新しい autofill 疑似クラスを使用すると、自動入力されるフォーム要素のスタイルを設定できます。これは、:-webkit-autofill 疑似クラスの標準化として導入されており、WebKit ではすでにサポートされています。Firefox は、この標準バージョンをサポートします。
autofill
:-webkit-autofill
writing-mode、direction、background など、一部のプロパティは、body からビューポートに伝播されます。CSS コンテナクエリの無限ループを防ぐために、仕様と実装が変更され、HTML または BODY にレイアウトの封じ込めが適用される際にこれらのプロパティが伝播されなくなりました。
font-synthesis CSS プロパティは、フォント ファミリーにフェイスがない場合、ユーザー エージェントが斜体、太字、小型英大文字のフォント フェイスを合成できるようにするかどうかをコントロールします。
font-synthesis
MediaKeySession.closed プロパティは、enum を使用して、MediaKeySession オブジェクトが閉じられた理由を示すようになります。この closed プロパティは、セッションが閉じたときに解決される Promise を返します。以前は Promise が解決されるだけでしたが、文字列として解決されるようになり、閉じられた理由を示します。返される文字列は、"internal-error"、"closed-by-application"、"release-acknowledged"、"hardware-context-reset"、"resource-evicted" のいずれかです。
MediaKeySession.closed
MediaKeySession
"internal-error"
"closed-by-application"
"release-acknowledged"
"hardware-context-reset"
"resource-evicted"
Chrome では、DNS（ドメイン名サービス）から HTTPS レコードが利用できる場合は、常に HTTPS 経由でウェブサイトに接続します。
PerformanceEventTiming インターフェースに interactiveID と呼ばれる属性が含まれるようになりました。これは、ブラウザが生成する ID であり、複数の PerformanceEventTiming エントリが同じユーザー操作に対応する場合、これらのエントリをリンクできるようにします。現在、デベロッパーは Event Timing API を使用して、関心のあるイベントのパフォーマンス データを収集できます。ただし、同じユーザー操作に対応するイベントをリンクすることは困難です。たとえば、ユーザーがタップしたときなら、pointerdown、mousedown、pointerup、mouseup、click など、多くのイベントが生成されます。
PerformanceEventTiming
interactiveID
pointerdown
mousedown
pointerup
mouseup
click
Chrome は、 'prefers-contrast' と呼ばれる新しいメディアクエリをサポートします。そのため、ウェブ制作者は、オペレーティング システムで設定されたユーザーのコントラスト設定（具体的には、macOS のコントラストを強調したモードと Windows のハイ コントラスト モード）にウェブ コンテンツを合わせることができます。有効な選択肢は、'more'、'less'、'custom'、または 'no-preference' です。
'prefers-contrast'
'more'
'less'
'custom'
'no-preference'
ウェブアプリ マニフェストで任意の id フィールドがサポートされ、ウェブアプリをグローバルに特定できるようになりました。id フィールドがない場合、PWA は start_url にフォールバックします。現時点で、このフィールドはデスクトップのみでサポートされます。
id
start_url
ウェブ アプリケーションがインストール マニフェストを使用して、カスタム URL プロトコル / スキームのハンドラとして自身を登録できるようにします。多くの場合、オペレーティング システム アプリケーションは自身をプロトコル ハンドラとして登録して、見つけやすさと使用率を向上します。ウェブサイトは、すでに registerProtocolHandler() を介してスキームを処理するように登録できます。この新機能はもう一歩踏み込んで、カスタム スキーム リンクが呼び出されたときに、ウェブアプリを直接起動できるようにします。
registerProtocolHandler()
Chrome のコンテンツ セキュリティ ポリシーが強化され、WebAssembly との相互運用性が向上しています。wasm-unsafe-eval は、WebAssembly の実行をコントロールします（JavaScript の実行には影響しません）。また、script-src ポリシーに WebAssembly が含まれるようになりました。
wasm-unsafe-eval
script-src
WebAssembly モジュールで JavaScript オブジェクトや DOM オブジェクトへの参照を保持できるようになりました。具体的には、これらの参照は、引数として渡したり、ローカル変数やグローバル変数に格納したり、WebAssembly.Table オブジェクトに格納したりできます。
このバージョンの Chrome では、以下のサポートの終了と機能の削除が行われます。現在サポートが終了している機能と以前に削除された機能のリストは、ChromeStatus.com をご覧ください。
PaymentRequest API では、"basic-card" 支払い方法が非推奨となっています。その使用率は低いうえ、低下し続けています。この支払い方法の購入手続きまでの時間や購入完了率は、他の支払い方法を下回っています。デベロッパーは、代わりとして他の支払い方法に切り替えることができます。たとえば、Google Pay、Apple Pay、Samsung Pay などの支払い方法です。 削除までのタイムライン :
Google はテクノロジーが社会をより良くしていくと考えています。私たちは社会の大きな課題を解決するためのアイデアを持つスタートアップをテクノロジーの力で支援したいと考えています。そのため、Google では、Google for Startups Accelerator というスタートアップを支援するアクセラレータプログラムを日本でも継続的に行っております。
この度、Google for Startups Accelerator のプログラムにおいて、参加するスタートアップに対して技術的メンタリングを提供してくださるメンターを募集いたします。メンターの方にはスタートアップへのメンタリングを通じて、 テクノロジーを活用した社会、経済、環境といったさまざまな分野の問題解決への取り組みをともに解決し、ひいては、スタートアップの成長が日本経済のさらなる活性化につながることへの貢献を一緒に行っていければと考えています。
メンターとして参画してくださる方、ぜひこちらのフォームよりご応募ください。
canMakePayment()
false
Google Identity は、データの保護において Google を信頼してくださっている Google アカウント ユーザーに充実した機能を提供すべく、日々努力を重ねています。同時に、ユーザーにすばらしい体験を提供するアプリを作るデベロッパー コミュニティにも貢献したいと考えています。Google とデベロッパーとの連携により、ユーザーは次の 3 つの重要な方法でデータの共有を管理できるようになっています。
カスタマイズされた地図は、スムーズなエクスペリエンスを提供するうえでの鍵となり得るもので、ユーザーを惹き付け、ユーザーの関心を集めてくれます。自由度の高い地図は、不動産会社が地図上のスポット（POI）に微調整を加えて、購入者が住む場所を決める際の手助けになるときや、地図のスタイル設定をしている地域の薬局が、自分たちのロケーションを競合他社に比べて目立たせる場合でも同じであると考えます。だからこそ Google は、スポットの密度とフィルタリングの管理、ズームレベルのカスタマイズ、さらには業界別に最適化された地図のスタイルといった機能を通した能力の強化を重視してきました。ですが、お客様の地図を次のレベルに押し上げるためのサポートは、これにとどまりません。この度、2 つのアップデートを一般提供します。それは、新しい Maps SDK for Android と、Android と iOS 向け SDK のクラウドベースのマップスタイル設定機能の拡張です。この 2 つでネイティブ モバイル マップ エクスペリエンスを強化することで、すべてのプラットフォームにわたる一貫性のある最適化された地図の提供が簡単に実現できるようになります。また、現在 Google が取り組んでいる追加機能の一部についても紹介します。
世界中のデベロッパーは、ドライバーの配達のサポートや、小売業者が注文の配送先住所を視覚的に確認する際のサポートといった、重要性の高いエクスペリエンスの提供を Maps SDK for Android に依存しています。消費者がアプリに費やす時間は増加し続け、アプリの使用が日常的で欠かせないものになる中、消費者の高い期待に応えられるモバイル エクスペリエンスが、かつてないほど重要になってきています。
今回リリースした Maps SDK for Android のバージョン 18.0.0 では、新たなレンダラによって実現した、より充実した地図描画のエクスペリエンスをアプリユーザーに提供します。新しいレンダラによるタイル表示やレンダリング アーキテクチャの最適化を導入したことで、品質を落とさずに地図データのサイズを軽減できました。これにより、ネットワーク負荷、デバイス上の処理、メモリ消費量が削減され、よりスムーズで安定したエンドユーザー エクスペリエンスにつながります。また、地図のラベルに特化した改善も行いました。今回のアップデートによりラベルの柔軟性が増し、より正確に位置取りできるようになったことで、マーカー管理機能の未来が切り開かれました。さらに、操作の処理全体を強化したことで、アニメーションの向上や、よりスムーズなパンやズームを実現しました。
Maps SDK for Android は引き続き Google Play 開発者サービス SDK の一部として継続して提供されるため、バージョン 18.0.0 にアップグレードしたとしても、APK サイズを増加させることなくすべての改善点を活用することができます。
今年前半の Google I/O にて、Google は JavaScript 向けクラウドベースのマップスタイル設定の一般提供を発表しました。それ以来お客様は、より優れたカスタマイズ機能やクラウドで強化された効率的なデプロイのワークフローを利用して、ミュンヘンのインタラクティブな地図の作成から、Cadbury が主催した仮想イースター エッグ ハントなどの楽しいイベントまで、数多くのマッピング エクスペリエンスを提供しています。この度、クラウドベースのマップスタイル設定機能は、Maps SDK for Android（バージョン 18 以上）と Maps SDK for iOS（バージョン 5.0 以上）の一般提供バージョンでサポートされます。
クラウドベースのマップスタイル設定により地図のカスタマイズに必要なコードがクライアントからクラウドに移動することで、新機能を使用するための修正や、新しい構成のテストが簡単にできるようになります。このようにクライアント コードとカスタマイズ コードを分離したことで、すべての対応プラットフォームにわたる多数のアプリにおいて、単一ブランドの管理や最適化したスタイルの管理がより簡単に実現できるようになります。また、プラットフォームやインストール ベース全体でのマップスタイルの変更が、ボタンを押すだけで同時に公開できるようになります。クラウドベースのマップスタイル設定は、スポットのフィルタリングとスポット利用の促進、ズームレベルのカスタマイズ、ランドマーク、商業地域用スタイル設定などの、増え続ける新たな一連のカスタマイズ機能の基盤となるものです。
モバイル デベロッパーは、Google Cloud Console で MapID を作成することで、Dynamic Maps におけるクラウドベースのマップスタイル設定機能やシンプルなクロス プラットフォーム カスタマイズが活用できるようになり、Maps SDK for Android または Maps SDK for iOS 内で使用できるようになります。Maps SDK for Android または Maps SDK for iOS を介して Map ID を読み込んだ Dynamic Maps は、Maps JavaScript API（Dynamic Maps）と同じ SKU で請求され、同一の毎月 $200 分のクレジットの利用が可能となり、使用量に応じた料金が適用されます。デベロッパーは、新しい Maps SDK for Android にアップグレードした場合でも、これまでと同様に無料で引き続きクライアントのスタイル付き地図の利用が可能です。
Google は、差別化されたエクスペリエンスを提供し、ユーザーを惹き付けるうえで、地図のカスタマイズに関して多様なニーズがあることを理解しています。Google は、さらなるクラウドベースのマップスタイル設定機能の開発に取り組んでおり、ご要望に応じたサポートが提供できるように、マーカー機能、マップの要素、データドリブンのスタイル設定に力を入れています。Google は一連の新しいマーカー機能、簡単なピンのカスタマイズ、Marker Collision Management、パフォーマンスの最適化、カスタム マーカー要素などに取り組んでおり、これらはしっかりカスタマイズされ高度に最適化されたマーカー ドリブン エクスペリエンスの迅速なデプロイの実行を可能にするものです。また、より詳細な地図を求めている人向けに、詳細なストリート マップの可用性とカスタマイズをさらに多くの都市に拡大しています。さらに、新しい API を公開し、プログラムで地図要素のスタイル設定を簡単にする機能にも取り組んでいます。これにより、お客様のデータに基づいた Google の保有する行政界データを用いて、スタイル設定機能を応用した階級区分図を簡単に作成することが可能となります。
これは、Google がデベロッパー コミュニティ向けに構築しているサービスのほんの一部です。Google が追加機能の実現に向けて懸命に作業を進めている間に、詳細をウェブサイトでご覧いただき、デベロッパー向けドキュメントを確認し、カスタマイズとモバイル地図の強化をぜひスタートしてください。
Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やフィードバックはページ右上の「お問い合わせ」より承っております。
昨年、地図全体における自然特性の描写を強化したことで、Google マップの外観が進化しました。同時に、このスタイルは Google Maps Platform で Cloud ベースのマップスタイル設定を使用するユーザーのデフォルトの地図になりました。どんな場面でも最新の Google マップによるエクスペリエンスをご利用いただけるようにするため、11 月から API バージョンと SDK バージョンに同じ地図スタイルを展開します。また 2022 年 5 月までに、サポートされているすべての環境でこの地図スタイルをデフォルトとします。
唯一の変更点は、デフォルトのベースマップの自然地形の見え方です。新しく衛星から情報取得したカラー マッピング技術により、Google マップ アプリ、ウェブサイト、そして Google Maps Platform の Cloud ベースでスタイル設定された地図で、より詳細かつ色鮮やかな表示を実現できました。
Maps JavaScript API や Static Maps API に Cloud ベースのマップスタイル設定をすでに使用していて、2020 年 9 月以降にスタイルを作成した場合は、新しいデフォルト地図がすでに有効になっています。
Cloud ベースのマップスタイル設定を使用していない Maps JavaScript API や Static Maps API のお客様の場合、Maps JavaScript API の通常のバージョニング チャネルを通じて新しいデフォルトの基本地図に移行されます。対象は 2021 年 11 月のウィークリー チャネルのバージョン 3.47 以降で適用されます。
Maps Embed API を使用している場合、2021 年 11 月に新しいデフォルトの基本地図が有効になります。
カスタム JSON スタイルを使用しているモバイル SDK のお客様は、Cloud Console の地図スタイル エディタで JSON スタイルのインポート用ツールを使用することで、今回の新しいデフォルト地図での表示を視覚的にプレビューできます。
2022 年 5 月には、すべての環境とすべてのバージョンの SDK で、新しいベースマップがデフォルトでご利用いただけるようになります。対象となる Maps JavaScript、Static Maps、Android SDK と iOS SDK には、デフォルトで新しいベースマップが表示されます。
問題やバグを共有するには、公開されている Issue Tracker から Issue 203429433 宛に送信してください。また、Google Maps Platform API と各 SDK でのテスト方法の概要や、新しいスタイルがそれぞれデフォルトになる時期については、以下の表をご確認ください。
API
テスト方法
新しい地図スタイルがデフォルトになる時期
Maps Embed API
--
2021 年 11 月
Maps JavaScript API
Maps JS ウィークリー チャネル（2021 年 11 月）の v3.47、Cloud ベースのマップスタイル設定
2022 年 5 月
Static Maps API
Cloud ベースのマップのスタイル設定
Maps SDK for Android
プレビュー版のスタイル設定
すべての SDK バージョンで 2022 年 5 月
Maps SDK for iOS
12 月 9 日（木）詳細・お申し込みはこちら
Cloud Learn に参加しませんか？
このイベントは、Google Cloud を学びたい皆さまにご参加いただける、初開催の無料オンライン イベントです。あらゆるレベルの開発者や IT プロフェッショナル、データ エンジニアを主な対象とし、「なぜクラウドを学ぶのか」「エンジニアの未来とは」という視点でスキルアップやキャリア開発について考え、すぐにスタートできるよう支援いたします。
クラウド人材育成に関わる企業や組織のリーダーの皆さまにも有益となる情報や、ここでしか聞けないキャリア ストーリーを通して、エンジニアの働き方や学び方について紹介する基調講演にくわえ、ハンズオンやオンライン トレーニング、参加者限定キャンペーンを提供いたします。
名称 : Google Cloud Learn
日程 : 12 月 9 日（木）10:30 - 16:30
詳細・お申し込みはこちら
※ プログラムは変更になる可能性がございます。最新の情報は上記 Web ページにてご確認ください。
【お問い合わせ】
Google Cloud イベント運営事務局Email : g-cloud@event-info.com
