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

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

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

この記事は 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™ の各商標は米国郵政公社が所有し、許諾を得て使用しています。


この記事は  Google Maps Platform Product Manager の Mohit Moondra による Google Cloud Blog の記事 "Navigate more sustainably and optimize for fuel savings with eco-friendly routing" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 ...
この記事は  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" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 ...
この記事は 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 が生成したデータと、ハードウェアの構成や機能を数日ではなく数分で試すことができるテキストベースの設定機能を使い、現実的な反復処理でスピード、複雑さ、特殊性のトレードオフを分析することによってできます。

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

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 は公式リポジトリからも取得できます。すぐに実行できるデモを試すことも、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

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" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 ...
この記事は 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

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

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

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

この記事は 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" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 ...
この記事は 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 拡張機能をリクエストできます。