この記事は Google Maps Platform Product Manager の Nicholas DeMeuse による Google Cloud Blog の記事 "Address Validation API is now generally available" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

住所は、人や場所を見つけたり、商品を配達したり、場合によっては銀行口座を開設するために必要なものです。住所に誤字や脱字があると、その住所の特定が難しくなることがあります。住所は日々何気なく利用されるものなので、単純でわかりやすいものだと考えられがちです。しかし実際には、それぞれの国や地域の標準に合わせて修正や形式設定が行われていない住所情報は、ユーザー エクスペリエンスの低下、配達の失敗、費用のかかる大規模なカスタマー サポートにつながる可能性があります。

上述の状況を踏まえ、このたび Address Validation の一般提供リリースを発表することになりました（注 : この新しい API を使用することで、アカウントの登録や決済を円滑に行えるようになり、ユーザー エクスペリエンスが向上します。加えて、無効な住所が業務に与える影響が軽減されて日常業務の時間と費用を節約できます）。

Address Validation の仕組み

Address Validation では、開発者が住所の欠落している部分や未確認の部分を特定して、不正確な住所を検出できます。Google Maps Platform のプレイスデータやローカライズされた住所形式に関する情報を基に、API が入力を標準化し、誤字の修正、町名の補完、地域固有の適切な形式設定などを行います。

Address Validation はさらに、住所の各構成要素とその正確性確認レベルに加えて、Plus Code、ジオコード、場所 ID など、処理済みの住所に関する有用なメタデータを返します。一部の地域では、Address Validation は住宅用住所と商業用住所を区別することもできます。これは、営業時間中に荷物を配達する上で重要です。さらに、Address Validation は、郵便サービスデータなど、複数のソースのデータを集約します。例えば米国では、Address Validation API は 米国においては USPS® から CASS CertifiedTM を取得しており、デベロッパーは米国郵政公社のデータと照合できるように構成されます。

よくある住所の間違いにこの API がどのように対応するかを、デモで確認することができます（注 : デモはサービス提供地域のみで動きます。現在、日本はサービス提供地域に含まれておりません）。

決済と注文確認時の Address Validation の代表的な使用例

Address Validation を使用するメリット

Address Validation は、業界を問わずさまざまなユースケースにメリットをもたらします。いくつか例を挙げてみましょう。

• 小売・ e コマース企業は、買い物客が決済をより円滑に進められるよう、住所を簡単かつ確実に修正できる方法を提供できます。これにより、配達の失敗やミスのほか、注文のキャンセルやチャージバックなど、複雑で費用のかかる作業を減らすことができます。

• 運送、物流企業は、注文受領時に住所の配達可能状況を評価し、部屋番号などの住所の構成要素をより正確に特定して、荷物が正しい目的地に届くようにすることができます。ドライバーは時間を節約できるだけでなく、配達にまつわる課題をより正確に予測できます。

• 金融サービス企業は、住所証明書類を使用して、新しい口座所有者を認証できます。口座開設時に顧客の住所が存在するかどうかを確認することで、不正な登録を検出できる可能性があります。

Google Maps Platform は、Address Validation をはじめ、ジオコーディングや Place Autocomplete などのプロダクトによって、より包括的な住所と配達先の検証が可能なサービスとなります。

Address Validation を実装済みのお客様は、その優れた成果を実感されています。オンライン注文エンジン Slerp を使用すると、ホスピタリティ ブランド企業は自社の Web サイトから顧客と直接取引できます。クリック＆コレクト、オンデマンド配達、全国配送など、さまざまな注文形態に対応する Slerp のビジネスにとって、住所は非常に重要です。

「Address Validation は、不正確な住所のどの構成要素に問題があるかを特定し、解決することで、オペレーション チームの作業効率を向上させることができます。エラーについては、より詳細な情報を入手しています。たとえば、ライン 1 やライン 2 に問題がある場合、オペレーション チームはそれに応じて修正できます。」 

Slerp シニア ソフトウェア エンジニア、Pedro Dias

Address Validation を使用すると、現実世界に関する Google Maps Platform の情報によって、住所が可能な限り正確であることを確認できるため、差別化されたエクスペリエンスの構築や、アプリ、サービス、ビジネス プロセスの運用効率の向上に集中的に取り組むことができます。Address Validation の詳細や開始方法については、Web サイト、デモ、チュートリアル ドキュメントをご覧ください。

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

1Google Maps Platform は、United States Postal Service® の非独占的なライセンシーです。 2United States Postal Service®、USPS®、CASS™、CASS Certified™ の各商標は米国郵政公社が所有し、許諾を得て使用しています。

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

この記事は  Google Maps Platform Product Manager の Mohit Moondra による Google Cloud Blog の記事 "Navigate more sustainably and optimize for fuel savings with eco-friendly routing" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

環境に優しいルート選択の開発者向けプレビュー版が公開されました。燃費を向上することで、車両の燃料使用量、エネルギー使用量と CO2 排出量を削減できます。また、ウェブとモバイルの両方に、環境に優しいルート選択を有効にするオプションが追加されます。

環境に優しいルート選択は Routes API の新機能です。環境に優しいルート選択を有効にすると、選択したエンジンの種類とリアルタイムの交通状況や道路状況などの情報を合わせることで、環境に優しいルートを選定できます。Routes API は通常、燃料やエネルギー効率を考慮しない、ルートを返しますが、今回、このデフォルト ルートに加えて、車のエンジンの種類に応じた、燃費やエネルギー効率の最も良いルートを示す環境に優しいルートも表示されるようになりました。

環境に優しいルート選択を有効した際の選択可能な オプションを示したサンプル

Google Maps Platform による燃料効率の推定方法

Routes API は、米国エネルギー省の国立再生可能エネルギー研究所の知見と欧州環境機関のデータを用いて、燃料効率とエネルギー効率を推定します。この計算では、燃料消費量、エネルギー使用量、CO2 排出量に影響する次のような要因が考慮されます。

• エンジンの種類（ガソリン、ディーゼル、ハイブリッド、電気）ごとの、各地域の代表的な自動車の平均燃料消費量またはエネルギー消費量

• ルート上での坂の勾配

• 少し進んでは止まるパターンの交通状況

• 道路の種類（一般道路や高速道路など）

Routes API は、到着時間への影響を最小限に抑えて、最も燃料消費やエネルギー効率の良いルートを返します。燃料やエネルギーの節約量が少ない場合や、運転時間が大幅に増加する場合は、API はルート間の相対的な燃料やエネルギーの節約量を示すため、ドライバーはどのルートを取るべきかを判断できます。

環境に優しいルート選択と燃料節約量の見積もりの例を表示するサンプル

より効率的なルートは、ドライバーの効率向上、移動時間の短縮、燃料消費の低減を意味します。例えば、配送会社やライドシェアリング会社は、環境に優しいルートを利用して、1 回の移動、複数回の移動、あるいは保有する車両全体の推定燃料消費量と節約量を測定し、業績向上につなげることができます。環境に優しいルート選択は、Google マップ上で利用可能な場所であればどこでも利用でき、その範囲は今後も拡大していく予定です。環境に優しいルート選択と Routes API を始める場合は、こちらのドキュメントをご覧ください。

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

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

この記事は Peter Zierhoffer – Antmicro による Open Source Blog の記事 "Co-simulating ML with Springbok using Renode" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

機械学習のソフトウェア ライブラリやモデルの世界は急速に進化しています。遅延、電力、セキュリティといった懸案に対処しつつ、増加を続けるメモリと計算能力の需要を満たすには、実行予定のワークロードと合わせて繰り返し試行しながらハードウェアを開発する必要があります。

RISC-V ISA は、オープンなアーキテクチャに基づき、カスタム命令をサポートし、柔軟なベクトル拡張機能を備えているので、このような協調設計にまたとない機能を提供します。また、RISC-V によるオープン ハードウェア エコシステムの活性化で、研究やイノベーションが推進され、チップ製造自体を改善する方法が生まれているため、この手法を活用してソフトウェアのニーズを今まで以上に満たせるようになっています。Google の OpenMPW Shuttle などの取り組みから、ML に特化したさらに充実したオープンなソリューションを生み出すためには、オープンでソフトウェア的なハードウェア開発のアプローチが鍵となります。

HW/SW 協調設計フローによる RISC-V ベースの ML アクセラレータ

この数か月、Google Research は Antmicro と連携して、効率的なハードウェアとソフトウェアの協働設計のひな形となるチップ プロジェクトを進めてきました。安全な ML ソリューションを開発するために、Google Research チームは Antmicro のサポートを受け、Antmicro のオープンソース シミュレーション フレームワークである Renode を使ってチップ開発前の高速な ML 開発フローを完全なオープンソースで開発しました。

昨年、Antmicro はこの協力関係を活用し、RISC-V ベクトル拡張機能の Renode サポートを実装しました。この拡張機能は、Springbok というコードネームを持つ Google チームの RISC-V ベースの ML アクセラレータに使われており、今回の開発はその結果をベースに行われています。プロジェクトの一環として、デベロッパー体験をさらに向上させるため、Antmicro は土台となる SoC のサポートの改善もしました。さらに、OS に対応したデバッグ、パフォーマンスの最適化、ペイロードのプロファイリング、パフォーマンス測定機能など、たくさんのユーザー指向機能にも取り組んでいます。

Springbok は、Google の AmbiML プロジェクトの一部です。このプロジェクトは、プライバシーとセキュリティを中心としたオープンソース ML 開発エコシステムの作成を目的としています。Google Research チームは、RISC-V ベクトル拡張機能を活用して、標準的でありながら柔軟な方法で ML ペイロードに欠かせない行列の積和演算を並列化しました。さらに、Renode のおかげで、情報に基づいた選択によって RISC-V の柔軟性を活用する厳密な方法を決めることができます。これは、Renode が生成したデータと、ハードウェアの構成や機能を数日ではなく数分で試すことができるテキストベースの設定機能を使い、現実的な反復処理でスピード、複雑さ、特殊性のトレードオフを分析することによってできます。

ML ソフトウェア側のエコシステムの中心にあるのは、IREE です。これは、LLVM MLIR をベースに、ML コンパイラと制約の強いデバイス向けのランタイムをオープンソースで開発する Google のリサーチ プロジェクトです。

IREE を使うと、TensorFlow や TensorFlow Lite などの一般的な ML フレームワークからモデルを読み込み、中間表現（MLIR）に変換できます。その後、それをグラフレベルで最適化し、LLVM コンパイル フローによって特定のターゲットに最適なランタイムにコンパイルします。IREE では、対象デバイスにモデルをデプロイする API が C と Python プログラミング言語の両方で提供されています。また、モデルの読み込み、テンソル管理、推論の起動を行えるよう、TFLite と同じ変換を提供する TFLite C API も用意されています。

こういったランタイムを使うと、対象デバイスや Renode などのシミュレーション環境で、モデルのデプロイやテスト、デバッグ、ベンチマーク、実行が可能になります。

Spring 2022 RISC-V Week でのフローのデモ

パリで開催された Spring 2022 RISC-V Week は、ここ数年で初めてとなるオープン ハードウェアの大規模カンファレンスでした。これに向けて、最初のバージョンの AmbiML ベアメタル ML フローがオープンソースとしてリリースされました。これには、インタラクティブに実行する機能とサンプル CI の両方が含まれています。サンプル CI は Antmicro の GitHub Renode Action を使っており、こういったワークフローをコミットごとに自動テストできることを示しています。現在、Google Cloud パートナーである Antmicro は、Google Cloud と連携して、このようなシナリオでの大規模な CI のテストやデプロイに Renode を利用できるようにする作業を行っています。

パリのイベントでは、Antmicro と Google はソフトウェア協調開発フローを発表し、1 つのコアで AmbiML Springbok ペイロードを実行し、別のコアで Zephyr を実行するという混在マルチコア ソリューションのデモをしました。

発表したシナリオでは、Springbok コアがメイン CPU から ML 計算をオフロードする装置となって MobileNetv1 ネットワークの推論をし、RISC-V カスタム命令を通じてアプリケーションのコアに作業結果を報告しました。Renode では、カスタム命令の追加や変更は簡単に行えます。Python や C# を使って 1 行で記述することも、RTL で協調シミュレーションもできます。

ML デベロッパーやチップ設計者は、Renode をソリューションのテストや実行に活用できます。それだけでなく、ソフトウェアが実際に何を行っているかを詳しく知るために利用することもできます。Antmicro と Google は、パリのデモの一環として、実行した命令数や特定のオペコードの使用頻度を数える方法を紹介しました。こういった機能は、ソリューションのパフォーマンスを評価するために活用でき、実行指標分析や実行関数ロギング、そして最近開発された実行トレース生成と合わせれば、ML エミュレーション環境の詳しい挙動を把握できます。

このような機能が、Renode のさまざまなハードウェアやソフトウェアの協調開発ソリューションに加わります。そのようなソリューションの例として、Antmicro と Microchip が共同開発している RTL 協調シミュレーションや、Verilator 対応のカスタム命令のサポートなどが挙げられます。後者は、RISC-V Custom Function Units を担当している別の ML に特化した Google のチームとの共同開発によるもので、EU が資金提供する VEDLIoT プロジェクトでも使われています。

今後の計画

この取り組みは、ソフトウェアやハードウェアのコンポーネントや、安全な ML 開発のための協調設計エコシステムをサポートするツールをリリースするために、Antmicro が進めている Google Research チームとの幅広い活動の始まりでしかありません。Renode や RISC-V、協調開発を今後の ML 中心のプロダクト開発に役立てられると思った方は、ぜひご自分で AmbiML フローを試してみてください。

GitHub の iree-rv32-springbok リポジトリにアクセスし、ローカルにクローンして、README.md の手順に従ってください。

Renode は公式リポジトリからも取得できます。すぐに実行できるデモを試すことも、Renode のドキュメントを確認して Verilator 協調シミュレーションなどの ML アクセラレーション開発に役立つ機能について学ぶこともできます。

Posted by Johan Euphrosine and Takuo Suzuki - Developer Relations Team

Google は 11 月 25 日 （金）に、機械学習の分野で優れた活躍をする女性をフィーチャーするイベント「Google Cloud Women in ML」を開催いたします。

女性の目線によるデータのビジネス活用も重要になってくる可能性が高く、女性データサイエンティストのさらなる活躍が期待されます。データサイエンスに関わる女性技術者からいろいろな分野の話を聞き、技術者同士のネットワーキングを深めたいと考えております。

データサイエンスに関わるよりすぐりの女性スピーカーを集めてのイベントとなりますので、ぜひ Women in ML にご参加ください。

《イベント 詳細の確認、お申し込み》https://goo.gle/3tpWRO8

《開催概要》

• 名 称 :「Women in ML」

• 会 期 : 2022 年 11 月 25 日（木）15 : 00 - 18 : 20

• 会 場 : ハイブリッド開催

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

《プログラム》❏ AI / データ分析 の分野で活躍する女性エンジニアによるパネル ディスカッション

葛木 美紀 , Google Cloud AI Consultant

曲沼 宏美 , 株式会社インテージ DX 部 データサイエンティスト データエンジニア

福島 ゆかり , 株式会社電通デジタル PF 部門ソリューション戦略部 Senior Consultant

浦田 純子 , Google Cloud Software Engineer

野上 和加奈 , 株式会社ソウゾウ 機械学習チーム ソフトウェアエンジニア

栗原 理央 , 株式会社ブレインパッド アナリティクス本部 リード機械学習エンジニア

❏ Vertex AI 入門 ～ 実践

浦田 純子 , Google Cloud Software Engineer

❏ Vertex AI Forecast - AutoML ではじめる需要予測

栗原 理央 , 株式会社ブレインパッド アナリティクス本部 リード機械学習エンジニア

❏ 機械学習認定資格「TensorFlow Developer Certificate」のススメ

Fran Marmousez（フラン マーモセズ）, Google Cloud Conversational AI Engineer - Strategic Cloud Engineer

❏ Vertex AI ではじめる「大規模言語モデル」

葛木 美紀 , Google Cloud AI Consultant

この記事は Ethan Mahintorabi, Johan Euphrosine, Aaron Cunningham による Google Open Source Blog の記事 "Google funds open source silicon manufacturing shuttles for GlobalFoundries PDK" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google が GlobalFoundries PDK のオープンソース チップ製造シャトルの資金を提供

オープンソース PDK を使って自分だけのチップを無償で開発

2022 年 8 月に GlobalFoundries 180nm MCU テクノロジー プラットフォーム向けの Process Design Kit（PDK）を Apache 2.0 ライセンスで公開しました。このオープンソース PDK は、GlobalFoundries テクノロジーとの連携の成果で、以下の標準セルを含めることによって、オープンソース チップ設計者に大量生産、手頃な価格、さまざまな電圧オプションといった新たな可能性を提供します。

• デジタル標準セルライブラリ（7 トラックと 9 トラック）
• 低（3.3V）、中（5V、6V）、高（10V）の電圧オプション
• SRAM マクロ（64x8、128x8、256x8、512x8）
• I/O とプリミティブ（レジスタ、キャパシタ、トランジスタ、eFuse）セルライブラリ

GlobalFoundries が Google のオープンソース チップに関する取り組みに参加したことはすでにお知らせしましたが、これより私たちは、今後行われる GF180MCU PDK の一連の無償 OpenMPW シャトルランに資金提供します。

このシャトルでは、同じ Caravel ハーネスを使い、OpenLane 自動設計フローをベースとした既存の OpenMPW シャトルのインフラストラクチャを活用します。プロジェクトの提出には Efabless プラットフォームを利用します。

それぞれのシャトルランでは、以下の条件に基づいて 40 のプロジェクトを選びます。

• 設計仕様がオープンソース ライセンスで公開されていること。
• 設計仕様と GF180MCU PDK からプロジェクトを再現できること。
• シャトルの締め切りまでにプロジェクトを提出すること（早めに提出されたプロジェクトは、選ばれる可能性が高くなります）。
• プロジェクトが製造前のチェックに合格すること。

初回のシャトル GF-MPW-0 はテストシャトルで、2022 年 10 月 31 日から 2022 年 12 月 5 日まで提出を受け付ける予定です。これは、オープンソース チップ ツールチェーンによる新しい PDK と Caravel ハーネスの組み合わせをコミュニティとともに検証する方法として活用されます。以降のシャトルでは、プロジェクトの提出期間が長くなり、テストが改善されます。

オープンソース PDK 間の移植性を確認する方法として、次の手順に従って、このシャトルに以前の OpenMPW シャトル プロジェクトを再提出することをお勧めします。

• developers.google.com/silicon にアクセスします。
• [Create a new Project] リンクを開きます。
• 指示に従って、プロジェクトを最新版の caravel_user_project テンプレートに組み込みます。
• コマンドを実行する前に、環境変数 PDK=gf180mcuC をワークスペースにエクスポートして、適切な種類の GF180MCU PDK（5LM_1TM_9K）を選択するようにします。
• 製造に向けて、Efabless プラットフォームでプロジェクトを提出します。

設計者の皆さんがこのプログラムを活用し、以前に OpenMPW シャトルに提出した既存プロジェクトを移植したり、GF180MCU PDK をターゲットとした新しいプロジェクトを設計したりしてくれることを楽しみにしています。そうすれば、ともにオープンソース チップ エコシステムの探求と発展を進めることを期待しています。

Posted by Johan Euphrosine and Takuo Suzuki - Developer Relations Team

この記事は Ethan Mahintorabi, Johan Euphrosine, Aaron Cunningham による Google Open Source Blog の記事 "Google and NIST partner on nanotechnology development platform" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google と米国国立標準技術研究所（NIST）が、米国の大学向けのナノテクノロジー研究開発用オープンソース テスト基盤の共同研究開発について合意したことをお知らせします。米国商務省の機関である NIST は、既存の平坦化ウェハーの設計を、SkyWater Technologies のオープンソース 130nm プロセス（SKY130）によって米国内で製造できるオープンソース フレームワークに移行することから始める予定です。物理ウエハーとソースコードは、今後数か月のうちに入手できるようになります。NIST と Google、そしてオープンソース コミュニティは力を合わせて設計を進め、米国のメーカーによる生産に向けた技術移管を含め、基礎科学と応用科学の両面で研究を促進する予定です。

この合意は、半導体テクノロジーを身近なものにするという Google の目標を推し進め、半導体メーカーから学術研究者に前例のないリソースが提供されるようになるため、半導体やナノデバイスの物理特性についての研究が強化されます。研究には、化学的性質、欠点、電気特性、高周波操作、スイッチング動作などが含まれ、規模の経済によって総コストを減らすことができます。最も重要なのは、アクセスの拡大によって研究者がメーカーのリソースを活用して新しいテクノロジーを開発できるようになり、技術移管プロセスが進むことです。大学はすでに業界と密接に関連するプラットフォームを使っているので、そこから大量生産にシームレスに移行できます。これにより、技術移管の「死の谷」を超えて技術を実用化する科学者の能力が増大します。

ナノテクノロジー研究では、通常はチップの製造に使われるシリコン ウエハーを独自の方法で活用しています。ウエハーをマイクロチップのパッケージにするのではなく、平坦化されたスムーズな表面を、ナノスケール構造の構築やテストを行うための優れた基板として使います。これは、大量生産への移行をテストする際にも、同じように役立ちます。

SKY130 オープンソース PDK を使ったフルウエハーの写真

このプラットフォームのウエハーには、単純なトランジスタ配列に基づいたパラメトリック検定構造（プローブ ステーションでプローブ可能なもの）から、ユーザーが合成デジタル回路を使って操作できる数千の複雑な測定に至るまで、たくさんの種類の測定構造が含まれています。重要なのは、大学がこのウエハーを 200 mm フォーム ファクタで利用できるようになることです。また、表面の粗さが 1 ナノメートル未満の中規模生産平坦化ウエハーも利用できます。精密な製造を行うためには、滑らかで平らな表面が極めて重要です。

このウエハーには大学のナノ加工設備でよく使われているフォトリソグラフィと電子ビームの位置合わせマークがあるため、NIST の研究者たちも、大学の研究者がメーカーのチップを直接簡単に使えることを保証しています。また、表面に金属パッドがついているため、表面から半導体トランジスタにアクセスできます。

NIST の科学者たちは、このナノテクノロジー アクセラレータ プラットフォームによって、さまざまなテクノロジーに科学的調査が広がることを期待しています。たとえば、メモリデバイス（抵抗スイッチ、磁気トンネル接合、フラッシュ メモリ）、人工知能、プラズモニクス、半導体バイオエレクトロニクス、薄膜トランジスタ、さらに量子情報科学といったテクノロジーが挙げられます。

Google の OpenMPW プログラムの開発ダイの写真、NIST とミシガン大学が開発したナノテクノロジー アクセラレータ用のもの

このプログラムでは、Google のこれまでの貢献や、GDSFactory や OpenFASOC オープンソース プロジェクトのサポートによる成果も活用しています。これらのプロジェクトは、重要な測定デバイスの作成を自動化し、その作成時間を月単位から日単位に短縮するものです。2023 年に予定されているフルウエハーのテープアウトに先がけて、ミシガン大学、カーネギー メロン大学、メリーランド大学、ジョージ・ワシントン大学、ブラウン大学のパートナーと共同作業を行っている NIST の科学者たちは、Google の OpenMPW プログラムを活用して、ナノテクノロジー アクセラレータに搭載予定の予備回路の開発とテストを進めています。予備テストによって、プログラムの目的を達成しつつ、開発中の回路が科学コミュニティに最も役立つようになります。

最新の研究の鍵となる要素は、再現性です。これは、別の機関の研究者がお互いの実験を繰り返し、それを改善できることを指します。オープンソース フレームワークに移行することで、研究者が再現可能な結果を共有しやすくなり、今後のシミュレーションに役立つオープンソース データセットが生まれ、科学コミュニティで最先端のナノテクノロジーや半導体の製造法が進化します。

NIST と Google は、最初のウエハーの生産と提供を米国の一流大学に向けて行う予定です。プログラム後には、米国の科学者はこのウエハーを Skywater から直接購入できるようになります。使用許諾要件はないので、何の制約もなく自由に研究を行えます。ウエハーは、完全なマスクセットの費用やゼロから集積回路を設計する費用の数百分の 1 の価格なので、科学者はこの産業技術をはるかに簡単に入手して使用できるようになります。長期的に見れば、最近発表した SKY90FD オープンソース PDK で将来のプラットフォームを NIST と共同開発することで、この R＆D エコシステムはさらに拡大します。

この研究の取り組みを始めるため、NIST は 2022 年 9 月 20～21 日より、集積回路の測定についてのワークショップである "NIST Integrated Circuits for Metrology Workshop" を開催しました。これはオンラインで開催され、初日にはいくつかのプレゼンテーションとパネル ディスカッションが行われました。2 日目には、研究者、科学者、エンジニアによるワーキング グループが、オープンソース チップ テクノロジーを使い、モノリシック集積化のパラメトリック検定構造の作成に焦点を当てた作業をしました。イベントのウェブサイトにアクセスすると、このプログラムの詳細を確認できます。

Posted by Johan Euphrosine and Takuo Suzuki - Developer Relations Team

この記事は Arnar Birgisson による Google Security Blog の記事 "Security of Passkeys in the Google Password Manager" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

この度、デベロッパーの皆さんが Android と Chrome でパスキーのサポートをテストできるようになったことをお知らせします。この機能は今年中に一般提供版になる見込みです。この投稿では、Google Password Manager に保存されたパスキーの安全がどのように保たれているかについて詳しく説明します。簡単な概要については、Android デベロッパー ブログの投稿をご覧ください。

パスキーはパスワードに代わるもので、安全性とセキュリティが向上しています。また、テキスト メッセージ、アプリベースのワンタイム コード、プッシュベースの承認など、従来の 2 要素認証方式も不要になります。パスキーは公開鍵暗号を使うので、サービス プロバイダからデータが漏洩しても、パスキーで保護されたアカウントが侵害されることはありません。また、業界標準の API とプロトコルを使うので、フィッシング攻撃の対象にもなりません。

パスキーは、業界全体の努力の成果で、FIDO Alliance と W3C Web Authentication ワーキング グループが作成した安全な認証標準、さまざまなプラットフォームの一般的な用語やユーザー エクスペリエンス、デバイスの紛失時の復元性、デベロッパー向けの一般的な統合パスといった要素を組み合わせたものです。パスキーは Android をはじめとする業界の主要なクライアント OS プラットフォームでサポートされます。

1 つのパスキーで、オンライン サービスの 1 つの特定のユーザー アカウントを識別できます。1 人のユーザーは、サービスごとに異なるパスキーを持ちます。ユーザーのオペレーティング システムや現在のパスワード マネージャーのようなソフトウェアが、ユーザー フレンドリーな方法でパスキーを管理します。ユーザーから見れば、パスキーを使うのはパスワードを保存するのとまったく同じです。ただし、セキュリティは大幅に向上します。

パスキーは、主に暗号秘密鍵で構成されます。ほとんどの場合、この秘密鍵は、ノートパソコンやスマートフォンといったユーザーのデバイスのみに保存されます。パスキーを作成すると、対応する公開鍵のみがオンライン サービス側に保存されます。サービスはログイン時に、公開鍵を使って秘密鍵の署名を検証します。秘密鍵の署名は、ユーザーのデバイスからしか送信できません。さらに、ユーザーが秘密鍵の署名を送信するには、デバイスや認証情報ストアのロックを解除しなければなりません。そのため、盗まれたスマートフォンなどからログインすることはできません。

デバイスの紛失やアップグレードといった一般的な事象に対処するため、パスキーの重要な特徴として、同じ秘密鍵を複数のデバイスに保存できるようになっています。これは、プラットフォームが提供する同期やバックアップを通じて実現します。

Google Password Manager のパスキー

Android の Google Password Manager は、パスキーのバックアップと同期に対応しています。つまり、ユーザーが同じ Google アカウントを使って 2 台の Android デバイスをセットアップすると、一方で作られたパスキーが他方でも利用できるようになります。これは、スマートフォンとタブレットのようにユーザーが同時に複数のデバイスを持つ場合と、より一般的なケースとしてユーザーが古い Android スマートフォンを新しいものにアップグレードする場合の両方に適用されます。

Google Password Manager のパスキーは、常にエンドツーエンドで暗号化されます。パスキーをバックアップする場合、暗号化した秘密鍵のみアップロードされます。この暗号化は、ユーザーのデバイス上でしかアクセスできない暗号鍵を使って行います。この仕組みにより、Google 内部の悪意のある攻撃者など、Google 自体からもパスキーを保護できます。そういった攻撃者は秘密鍵にアクセスできないので、対応するオンライン アカウントにパスキーを使ってログインすることはできません。

さらに、パスキーの秘密鍵は、ハードウェアで保護された暗号鍵で暗号化した状態で、ユーザーのデバイスに保存されます。

パスキーを作成したり、Google Password Manager に保存されたパスキーを使用したりするには、画面ロックを設定する必要があります。そのため、ユーザーのデバイスに触れることができる人でも、パスキーを使うことはできません。また、この仕組みは、エンドツーエンドの暗号化やデバイスの紛失時の安全な復元を促すために必要なことでもあります。

アクセスの復元と新しいデバイスの追加

ユーザーが新しい Android デバイスを設定して古いデバイスからデータを転送すると、既存のエンドツーエンドの暗号化鍵も新しいデバイスに安全に転送されます。古いデバイスが紛失したり故障したりしている場合、安全なオンライン バックアップからエンドツーエンドの暗号化鍵を復元する必要があることがあります。

エンドツーエンドの暗号化鍵を復元するには、その鍵にアクセスできた別の既存デバイスのロック画面の PIN、パスワード、パターンのいずれかを入力する必要があります。なお、新しいデバイスでパスキーを復元するには、Google アカウントへのログインと既存デバイスの画面ロックの両方が必要です。

画面ロックの PIN やパターンは特に短いので、復元メカニズムには総当たり推測に対する保護が組み込まれています。既存デバイスの画面ロック情報の入力に数回連続して失敗すると、そのデバイスの画面ロックは利用できなくなります。この回数は常に 10 回以下ですが、安全を保証するため、その回数に達する前にブロックされることもあります。他の既存デバイスの画面ロックは、その後も利用できます。

登録されているすべての既存デバイスで最大試行回数に達した場合（悪意のある者が総当たり推測を行った場合など）でも、画面ロックを知っている既存デバイスを利用できれば、復元が可能です。既存デバイスにログインし、画面ロック PIN、パスワード、パターンを変更すると、復元の失敗回数はリセットされます。その後、既存デバイスの新しい画面ロックを入力すると、新しいデバイスでエンドツーエンドの暗号化鍵を復元できます。

画面ロックの PIN、パスワード、パターン自体は、Google も知ることはできません。Google がデバイスの画面ロックの入力が正しいことを検証するためのデータは、Google のサーバーの安全なハードウェア エンクレーブに保存され、Google などが読み取ることはできません。安全なハードウェアでは最大試行回数が 10 回以下に制限されます。これは内部からの攻撃にも適用されるため、画面ロック情報は Google からも保護されます。

デバイスから画面ロックを削除しても、最大 64 日間は、それまで設定されていた画面ロックを別のデバイスのエンドツーエンドの暗号化鍵の復元に利用できます。画面ロックが侵害されたことに気づいた場合、安全な選択肢は別の画面ロック（別の PIN など）を設定することです。これにより、それまでの画面ロックを復元に使うことはできなくなります。ユーザーがオンラインでデバイスにログインしている場合、この変更は即座に反映されます。

復元のユーザー エクスペリエンス

デバイスをセットアップする際にエンドツーエンドの暗号化鍵が転送されなかった場合、新しいデバイスでパスキーを初めて作成または使用するときに、復元処理が自動的に行われます。ほとんどの場合、新しいデバイスでこれが行われるのは一度だけです。

ユーザーから見ると、新しいデバイスで初めてパスキーを使うときは、まずエンドツーエンドの暗号化鍵の復元に必要な既存デバイスの画面ロックを尋ねられ、その後にパスキーの利用時に毎回必要になる現在のデバイスの画面ロックまたは生体認証を求められることになります。

パスキーとデバイス固有の秘密鍵

パスキーは、FIDO マルチデバイス認証情報の一例です。リライング パーティは、パスキーの復元性やユーザビリティというメリットを活用できますが、特定のデプロイ シナリオでは、従来の FIDO 認証情報が提供していたデバイスの固有性についての強いシグナルが必要になることがあります。Google はこの点を認識しています。

それに対処するため、Android のパスキーは、Device-bound Public Key WebAuthn 拡張機能（devicePubKey）提案をサポートしています。リライング パーティが、Android でパスキーを作成または使用するときにこの拡張機能を要求すると、その結果として 2 つの署名を受け取ります。1 つはパスキーの秘密鍵の署名で、この鍵は複数のデバイスに存在する可能性があります。もう 1 つは第 2 の秘密鍵の署名で、この鍵は現在のデバイスにしか存在しません。このデバイス固有の秘密鍵は、対象のパスキーに対して一意で、それに対応するデバイス固定の公開鍵のコピーがすべてのレスポンスに含まれます。

2 つのパスキーの署名に同じデバイス固有の公開鍵が含まれていれば、それは署名が同じデバイスで生成されたことを示す強いシグナルになります。一方で、初めて目にするデバイス固有の公開鍵が含まれていれば、それはパスキーが新しいデバイスに同期されたことを示している可能性があります。

Android のデバイス固有の秘密鍵は、Android Keystore API を通じてデバイスの高信頼実行環境（TEE）で生成されます。これにより、デバイス固有の秘密鍵が別のデバイスに漏洩しないように、ハードウェアレベルで保護されます。デバイス固有の秘密鍵はバックアップされないので、デバイスを出荷時の設定にリセットしたり、以前のバックアップから復元したりすると、デバイス固有の鍵ペアは違うものになります。

デバイス固有の鍵ペアは、オンデマンドで作成され、保存されます。つまり、パスキーが作成されたときに devicePubKey がリクエストされていなくても、リライング パーティは既存のパスキーから署名を取得する際に devicePubKey 拡張機能をリクエストできます。

Posted by Eiji Kitamura - Developer Relations Team

この記事は Chrome Developers Blog の記事 "Chrome 108 beta" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

特に記載のない限り、下記の変更は Android、ChromeOS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2022 年 10 月 27 日の時点で Chrome 108 はベータ版です。PC 向けの最新版は Google.com で、Android では Google Play ストアでダウンロードできます。

# CSS

Chrome 108 には、たくさんの新しい CSS 機能が含まれています。

# 置換要素の CSS overflow

Chrome で、content-box の外側に描画する置換要素に対して、既存の overflow プロパティを使えるようにする変更のロールアウトが始まります。これを object-view-box と組み合わせると、CSS シャドウのように、正しい ink-overflow 動作に対応したカスタムのグローやシャドウを適用したイメージを作成できます。

これは互換性を破る変更になる可能性があります。詳細は、置換要素の overflow の変更をご覧ください。

# 小、大、動的、論理ビューポート単位

小（svw、svh、svi、svb、svmin、svmax）、大（lvw、lvh、lvi、lvb、lvmin、lvmax）、動的（dvw、dvh、dvi、dvb、dvmin、dvmax）、論理（vi、vb）単位がサポートされます。

# CSS break-after、break-before、break-inside のサポート

印刷時の CSS の改ページ プロパティ break-before、break-after、break-inside で、avoid 値がサポートされます。この値を使うと、適用対象の要素の前、後、内部で改ページを防ぐことをブラウザに指示できます。たとえば、次の CSS を使うと、図が複数ページにまたがるのを防ぐことができます。

figure {
    break-inside: avoid;
}

この機能は、Chrome 108 で LayoutNG の印刷がサポートされたため、追加されました。

# 最後のベースライン項目への位置合わせ

この機能は、flex または grid レイアウト内の項目の位置を、最初ではなく、最後のベースラインに合わせます。これは、以下のプロパティを使って行います。

• align-items: last baseline;
• justify-items: last baseline;
• align-self: last baseline;
• justify-self: last baseline;

# ContentVisibilityAutoStateChanged イベント

content-visibility: auto の要素で、なんらかの属性によって要素とユーザーとの関連性が発生し、レンダリング状態が変更されたときに発行されるイベントです。

このユースケースとして、ユーザー エージェントが content-visibility が設定されたサブツリーのレンダリングを終了または開始したときに、レンダリングの終了または開始のタイミングをデベロッパーが細かく制御することが挙げられます。たとえば、ユーザー エージェントがレンダリングしないサブツリーで、React による更新を停止したい場合です。同じように、ユーザー エージェントが要素をレンダリングしないときに、他のスクリプトによる更新（キャンバスの更新など）を停止したい場合もあります。

# ウェブ API

# Federated Credentials Management（旧称 WebID）

Federated Credential Management API を使うと、ブラウザのプライバシー改善との互換性を維持しつつ、ユーザーが ID 連携を使ってウェブサイトにログインできるようになります。

# ワーカーの Media Source Extensions

Media Source Extensions（MSE）API を DedicatedWorker コンテキストから利用できるようにします。これにより、メイン Window コンテキストで HTMLMediaElement が再生用にメディアをバッファリングする操作のパフォーマンスが向上します。DedicatedWorker コンテキストで MediaSource オブジェクトを作成すると、アプリケーションはそこから MediaSourceHandle を取得してそのハンドルをメインスレッドに送り、HTMLMediaElement に接続して利用できます。そうすると、MediaSource オブジェクトを作成したコンテキストからメディアをバッファリングできます。

# Sec-CH-Prefers-Reduced-Motion ユーザー プリファレンス メディア機能 Client Hints ヘッダー

ユーザー プリファレンス メディア機能 Client Hints ヘッダーは、Media Queries Level 5 として定義されているユーザー プリファレンス メディア機能に関連する一連の HTTP Client Hints ヘッダーを定義します。このヘッダーを Critical Client Hints として使うと、CSS のインライン化などに関してサーバーが適切な選択をできるようになり、Sec-CH-Prefers-Reduced-Motion がユーザーの prefers-reduced-motion プリファレンスを反映します。

# WebTransport BYOB リーダー

WebTransport で BYOB（bring-your-own-buffer）リーダーをサポートし、デベロッパーが準備したバッファへの読み込みができるようにします。BYOB リーダーを使うと、バッファのコピーを最低限にとどめ、メモリの割り当てを減らすことができます。

# 権限ポリシー オリジンのワイルドカード

権限ポリシー仕様は、デベロッパーがさまざまなブラウザの機能や API を選択して有効化や無効化を行えるようにする仕組みを定義します。この仕組みによって、明示的に列挙したオリジン（https://foo.com/ など）でのみ機能を有効化できるようになります。数百個あるサブドメインのいずれか 1 つにホストされているオリジン経由でコンテンツを提供するような CDN の設計の場合、この仕組みは十分に柔軟なものではありません。

そのため、この機能により、権限ポリシーでワイルドカードがサポートされます。たとえば、SCHEME://*.HOST:PORT（https://*.foo.com/ など）のような構造です。この場合、有効なオリジンは SCHEME://HOST:PORT（https://foo.com/など）から構築されます。HOST は登録可能なドメインである必要があります。つまり、https://*.bar.foo.com/ は有効ですが、https://*.com/ は有効ではありません（すべてのドメインでこの機能を使いたい場合は、単純に * に委譲してください）。

# File System Access API の AccessHandles の同期メソッド

File System Access API の FileSystemSyncAccessHandle の非同期メソッド flush()、getSize()、truncate() が更新され、同期メソッドになります。現在の FileSystemSyncAccessHandle には、同期メソッドと非同期メソッドが混在しており、パフォーマンスやユーザビリティの妨げになっています。C/C++ を Wasm に移植するアプリケーションでは、特にそれが顕著です。今回のアップデートにより、API の使用方法に整合性がもたらされ、Wasm ベースのライブラリのパフォーマンスが向上します。

これは互換性を破る変更になる可能性があります。詳しくは、互換性を破る変更 : AccessHandles の同期メソッドをご覧ください。

# WebAuthn Conditional UI

WebAuthn の Conditional UI は、Windows 11 22H2 以降、macOS、Android P 以降でサポートされます。デスクトップ プラットフォームの WebAuthn UI も更新されています。

# 可変 COLRv1 フォントとフォント特徴検出

# COLRv1 可変フォントのサポート

COLRv1 カラーベクトル フォントは Chrome 98 以降でサポートされていますが、この初期リリースでは、COLRv1 テーブルの静的機能のみがサポートされていました。COLRv1 仕様は、可変軸パラメータを変化してフォントのグラデーションや変換に関するプロパティを変更できる OpenType バリエーションとの統合を定義します。今回の第 2 ステップでは、COLRv1 のこのようなバリエーションをサポートします。

# font-tech() と font-format() 条件による CSS @supports の拡張

font-tech() と font-format() を CSS の @supports と組み合わせて使うことで、サポートされているフォント テクノロジーやフォーマットの検出と、コンテンツのプログレッシブ エンハンスメントが可能になります。次の例では、COLRv1 フォントがサポートされているかどうかを確認しています。

@supports font-tech(color-COLRv1) {

}

# @font-face src: 記述子での tech() 関数のサポート

CSS Fonts Level 4 は、フォント リソースの選択やフィルタリングの追加手段を提供します。tech() 関数はすでに導入されており、これを使うと、それぞれのフォントの blob の動作に必要なフォント テクノロジーのリストを渡すことができます。ユーザー エージェントは、これに基づいて最初の適切なリソースを選択します。

# Android 版 Chrome

# Android OSK がデフォルトで表示されるビューポートをリサイズ

デフォルトで、Android 画面キーボード（OSK）は、最初の包含ブロックではなく、表示されるビューポートをリサイズします。この動作は、新しい interactive-widget meta-viewport キーを使ってオプトアウトできます。

# オリジン トライアル

今回の Chrome のリリースには、2 つの新しいオリジン トライアルが含まれています。

# canmakepayment イベントの販売者 ID

canmakepayment Service Worker イベントは、ユーザーがインストールされている決済アプリにカードを保存しているかどうかを販売者に知らせます。また、決済アプリのオリジンの Service Worker に、販売者のオリジンと任意のデータを渡します。このクロスオリジン通信は、JavaScript で PaymentRequest を作成したときに発生します。その際にユーザーの操作は必要なく、ユーザー インターフェースは表示されません。"canmakepayment" イベントから ID フィールドを削除するデベロッパー トライアルは、chrome://flags/#clear-identity-in-can-make-payment から有効化できます。このフラグを有効にすると、"canmakepayment" イベント（と Android の IS_READY_TO_PAY インテント）の ID フィールドが空になります。

詳しくは、Payment Handler API の CanMakePayment イベントの動作の更新をご覧ください。

# NotRestoredReason API の戻る / 進むのキャッシュ

NotRestoredReason API は、PerformanceNavigationTiming API を通して、ページが BFcache から提供されない理由のリストをフレームツリー構造で報告します。

BFcache からのページがブロックされる理由はさまざまで、仕様の要件やブラウザ固有の実装などに起因します。デベロッパーは、pageshow ハンドラ永続化パラメータと PerformanceNavigationTiming.type(back-forward) を使って、自分のサイトの BFCache のヒット率を収集できます。この API を使うと、サイトの履歴操作で BFCache が使われない理由に関する情報を収集できるので、それぞれの理由に基づいて対策し、ページを BFCache に対応させることができます。

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

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

# サポートの終了

今回の Chrome のリリースでは、1 つの機能のサポートが終了します。

# window.defaultStatus と window.defaultstatus のサポート終了と削除

この 2 つは非標準 API で、すべてのブラウザで実装されているわけではありません。また、ブラウザの動作には影響しません。これらを削除することで、潜在的なフィンガープリンティングのシグナルを取り除きます。

これらは当初、ブラウザ ウィンドウの下に表示されていた「ステータスバー」のテキストの変更や制御に使われていました。しかし実際には、Chrome のステータスバーに対しては何の効果もなく、標準化された属性でもありません。バージョン 23 以降の Gecko はこの属性をサポートしていません。WebKit では、引き続きこの属性がサポートされています。関連する window.status 属性 は 標準化されていますが、同じようにウインドウのステータスバーには何の影響も与えません。

# 削除

今回の Chrome のリリースでは、4 つの機能が削除されます。

# ImageDecoderInit.premultiplyAlpha の削除

この機能の主なユースケースには目に見える効果は何もありませんが、実装が最適でない方法に制限される可能性があります。詳しい説明は、こちらの問題をご覧ください。これは、WebCodecs 仕様作成者との合意と、利用率の低さ（M106 の使用カウンターによると、ページ読み込みの 0.000000339%～0.00000687%）に基づく対応です。

# navigateEvent.restoreScroll() の削除

restoreScroll() は、navigateEvent.scroll() に置き換えられています。scroll() は、トラバースではないナビゲーションでデベロッパーがスクロールのタイミングを制御できることを除き、同じ動作になります（scroll() は、スクロールが復元でない場合に動作します。そのため、この動作の変更に伴い、名前が変わります）。

# navigateEvent.transitionWhile() の削除

デベロッパーから報告された設計上の欠陥により、transitionWhile() が navigateEvent.intercept() に置き換えられます。intercept() は transitionWhile() とほぼ同じように動作しますが、必須の Promise パラメータではなく、Promise を返すハンドラ関数（省略可能）を受け取ります。これにより、ブラウザがハンドラを実行するタイミングを制御できるようになります。こちらの方が transitionWhile() よりタイミングが遅く、直感的です。

# WebRTC mediaConstraint の googIPv6 の削除

"googIPv6: false" を使うと、次の例のようにして WebRTC の IPv6 サポートを無効化できます。

new RTCPeerConnection({}, {mandatory:{googIPv6:false}});

IPv6 は何年にもわたってデフォルトで有効化されており、無効化は望ましくありません。これは、仕様には存在しない以前の API です。

Posted by Eiji Kitamura - Developer Relations Team

DevFest は、Google Developer Group（GDG）コミュニティによって世界各地で開かれるデベロッパー向けイベントです。参加者は Android、Firebase、Google Cloud Platform、TensorFlow、Web などの Google のデベロッパー テクノロジーに関する技術情報、知識やアイデアを共有できます。

それぞれの DevFest は、主催するコミュニティとその地域のニーズに沿ったユニークな内容となり、日本では下記のイベントが現時点では企画がされています。情報は追加、更新されていきますので、ブログ記事やツイッターをご確認ください。

■ GAS による業務改善勉強会

    日時 : 2022 年 11 月 2 日（水） 18:00～20:00
    場所 : ハイブリッド（現地＆ Zoom）
    参加費 : 無料
    定員 :  オンライン参加枠（50 名）
　　　　現地参加枠（10 名）
　　　　オンライン LT 登壇枠（6 名）

    申込サイト : こちら
    主催 : GDG Osaka
    内容 : Google Apps Script

■ DevFest Nagoya 2022

    日時 : 2022 年 11 月 14 日（月） 18:00～
    場所 : オフライン
    参加費 : 無料
    定員 : 一般参加（12 名）
    　　   LT 参加（8 名）
    申込サイト : こちら
    主催 : GDG Nagoya
    内容 : LT のテーマは『2022 年、私ががんばった何か』

■ DevFest Tokyo & Android Dev Summit Japan 2022
    日時 : 2022 年 12 月 16 日（金）
    場所 : ハイブリッド（会場＆ Youtube Live）
    参加費 : 無料
    定員 : オンラインは人数制限なし
    申込サイト : こちら
    主催 : GDG Tokyo、Android Dev Summit と共催
    内容 : Android, Chrome, ML など幅広くセッションを予定中

■ DevFest Kyoto ＆ Shikoku 2022
    日時 : 2022 年 12 月 25 日（日）
    場所 : オフライン
　　　　＞四国 : e-とぴあ・かがわ クラスルームB
　　　　＞京都：キャンパスプラザ京都
    参加費 : 無料
    定員 : 一般参加（24 名）
    　　   Androidデバイス貸出枠（6 名）
    申込サイト : 京都はこちら、四国はこちら
    主催 : GDG Kyoto, GDG Shikoku, WTM Kyoto,
　　　　GDSC 放送大学, GDSC Kagawa Junior College
    内容 : 今年は、四国と京都の会場を中継でつなぎながら、
　            ARCoreのCodelabsを用いたハンズオンを開催します！
                はじめての方も是非お気軽にご参加ください。

※ リンクがない箇所は、情報が入り次第更新していきます。

皆さまのご参加を心よりお待ちしております。

Posted by Reisa Matsuda and Takuo Suzuki - Developer Relations Team

この記事は Diego Zavala, Christiaan Brand, Ali Naddaf, Ken Buchanan による Android Developers Blog/Android Developers - Medium の記事 " Bringing passkeys to Android & Chrome " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

2022 年 10 月 12日より Android と Chrome でパスキーが利用可能に

2022 年 10 月 12日より、Google は Android と Chrome の両方でパスキーのサポートを開始しました。

パスキーはフィッシングによって侵害される可能性があるパスワードなどの認証要素に代わるもので、安全性が大幅に向上します。パスキーは再利用できず、サーバーの侵害によって漏洩することもないため、ユーザーはフィッシング攻撃から保護されます。また、業界標準 (英語) に基づいて作られており、オペレーティング システムやブラウザのエコシステムに依存せずに動作し、ウェブサイトでもアプリでも利用できます。

パスキーはパスワードの自動入力という既存の仕組みに基づいているので、おなじみの UX パターンに従います。エンドユーザーは、保存してあるパスワードを使うときと同じ操作でパスキーを利用できます。つまり、指紋などの既存のデバイスの画面ロック解除キーを提示するだけです。ユーザーのスマートフォンやコンピュータに保存されたパスキーは、クラウドを通してバックアップと同期されるので、デバイスを紛失してもロックアウトされることはありません。さらに、スマートフォンに保存されているパスキーを使って、そばにある別のデバイスからアプリやウェブサイトにログインすることもできます。

10 月 12 日のサポート開始により、パスキーに関する作業が大きな節目を迎え、次の 2 つの主な機能が実現できるようになったことをお知らせします。

1. ユーザーは、Android デバイスでパスキーを作成して使用できます。パスキーは、Google Password Manager (英語)  を通して安全に同期されます。
2. デベロッパーは、Android などのサポート対象プラットフォームで、Chrome の WebAuthn API を使ってエンドユーザー向けのサイトをパスキーに対応させる (英語) ことができます。

さっそく試してみたいデベロッパーの皆さんは、Google Play 開発者サービスのベータ版 (英語) に登録し、Chrome Beta を使ってみてください。どちらの機能も、今年中に安定版チャンネルで一般公開版として利用できるようになる予定です。

2022 年の次のマイルストーンとして、ネイティブ Android アプリ向けの API を提供する予定です。ウェブ API を使って作成したパスキーは、同じドメインを使うアプリでシームレスに利用できます。その逆も同様です。ネイティブ API を使うと、パスキーと保存したパスワードのどちらかを選ぶ仕組みを統一的に扱うアプリを作ることができます。パスワードとパスキーの両方でおなじみのシームレスな UX を使えるので、ユーザーやデベロッパーは徐々にパスキーに移行しやすくなります。

 

Android デバイスでパスキーを使ってウェブサイトにログインする

エンドユーザーは、わずか 2 ステップでパスキーを作成できます。（1）パスキーのアカウント情報を確認し、（2）プロンプトに従って指紋や顔などの画面ロック解除キーを提示します。

 

ログイン操作も同じように簡単です。（1）ログインに使うアカウントを選択し、（2）プロンプトに従って指紋や顔などの画面ロック解除キーを提示します。

Android デバイスのパスキーを使ってそばにあるコンピュータからウェブサイトにログインする

スマートフォンに保存したパスキーは、そばにあるデバイスからログインする際に使うこともできます。たとえば、Android ユーザーは Mac の Safari からパスキー対応のウェブサイトにログインできます。同じように、パスキーは Chrome でもサポートされているので、たとえば Windows の Chrome ユーザーが iOS デバイスに保存されているパスキーを使ってログインすることもできます。

パスキーは業界標準に基づいて作られているので、Windows、macOS、iOS、ChromeOS など、プラットフォームやブラウザが違っても、同じユーザー エクスペリエンスを提供できます。

パスワードのない未来に向けて私たちができること

私たちは、Apple や Microsoft などの同じ業界の企業、FIDO Alliance (英語) のメンバー、W3C (英語) と協力し、何年もかけて (英語) 安全な認証標準の検討を進めています。W3C WebAuthn (英語) や FIDO 標準は、制定時よりサポートしています。

今回重要な節目ではありますが、これでこの取り組みが終わるわけではありません。Google は、パスワードや新たに導入されたパスキーを保存する場所をユーザーが自由に選べる世界に向けて、これからも注力し続けます。来年には、Android に変更を加え、サードパーティのパスワードマネージャーがパスキーをサポートできるようにする予定なので、今後の最新情報にご注目ください。

Reviewed by Eiji Kitamura - Developer Relations Team, Mari Kawanishi - Developer Marketing Manager, Google Play