本日（元記事公開当時）、Sigstore コミュニティは、コミュニティが運営する無償の認証局と透過ログサービスの一般向け提供版についてお知らせします。さらに、Sigstore の 2 つの基本プロジェクトである Fulcio ã¨ Rekor ã§、API が安定版となった v1.0 リリースを公開します。Google も、こういったオープンソース コミュニティの節目を祝福しています。🎉

Sigstore は、オープンソース ソフトウェアの署名、検証、保護のための標準です。最近のサイバーセキュリティに関する米国大統領令など、ソフトウェア サプライチェーンのセキュリティに対する業界の注目度が高まる中、ソフトウェアの出所を把握して信頼する機能はこれまでになく重要になっています。Sigstore は、ソフトウェアのデジタル署名の複雑な部分を簡素化、自動化することで、この機能をこれまで以上に使いやすくて信頼性が高いものにします。

Sigstore プロジェクトは、2020 年に Red Hat と Google のオープンソース コラボレーションとして始まりました。そして、ベンダーに依存せずにコミュニティが運営と設計を行うプロジェクトに成長し、Open Source Security Foundation（OpenSSF）の一員にもなりました。この取り組みは、さまざまなパッケージ マネージャーやエコシステムにも広がり続けています。Python や Kubernetes などのオープンソース プロジェクトの新リリースをダウンロードすれば、それが Sigstore で署名されていることがわかります。

Google は Sigstore コミュニティのメンバーとして、積極的な貢献を行っています。アップストリーム コード以外にも、次のようないくつかの形で貢献しています。

  • Sigstore のコアサービスは、Google がサポートするオープンソース テクノロジーで構築されています。この貢献には、Go、gRPC、Trillian、Certificate Transparency ãªã©ãŒå«ã¾ã‚Œã¾ã™。
  • Google は、今年の SigstoreCon ã®ãƒ€ã‚¤ãƒ¤ãƒ¢ãƒ³ãƒ‰ スポンサーです。

私たちは、Sigstore の開発や運営を支える大きなオープンソース コミュニティの一部です。新しい採用者や貢献者は大歓迎です。Sigstore を使ってみたい方は、プロジェクトのドキュメントでソフトウェアの署名と検証のプロセスについてご確認ください。貢献したい方は、Sigstore GitHub 組織に複数の個人リポジトリがあるので、簡単なタスクを示す目印として、「good first issue」ラベルをご利用ください。プロジェクトには Slack コミュニティ（こちらの招待を利用できます）があり、コミュニティ ミーティングも定期的に開催しています。


Posted by Eiji Kitamura - Developer Relations Team

ステップアップ認証とは

決済処理を行う際に、ユーザーの操作や一定のリスクシグナルに基づいて追加の認証手段を義務づける手法をステップアップ認証（略して「ステップアップ」）と言います。例として、ユーザーを 3D セキュアにリダイレクトして取引の認証を行うことが挙げられます。これにより、詐欺や支払拒否の可能性を下げることができます。次の図は、取引にステップアップが必要な場合に処理内容を決定するおおまかなフローを示しています。

取引のおおまかなフローを示した図
図 1: ステップアップが必要な場合は、取引を認可に送る前にリスクエンジンを起動する

状況により、取引の際に Google Pay API は次のどちらかの応答を返します。

  • 追加でステップアップや認証を行うことなく処理できる承認済みのペイロード。たとえば、ユーザーが決済用のカードを Google Wallet ã«è¿½åŠ ã™ã‚‹å ´åˆ。この場合、発行銀行によるユーザーの本人確認が完了している。
  • 3D セキュアなどの追加の認証手段が必要なクレジットカード番号（PAN）。たとえば、Chrome の自動入力に保存してある決済カードで購入する場合。

allowedAuthMethods ãƒ‘ラメータを使うと、Google Pay の取引で使えるようにしたい認証手段を指定できます。

"allowedAuthMethods": [
    "CRYPTOGRAM_3DS",
    "PAN_ONLY"
]


この例では、両方のタイプの決済シートを表示するように Google Pay にリクエストしています。たとえば、決済時にユーザーが決済シートから PAN_ONLY ã‚«ãƒ¼ãƒ‰（トークン化されておらず、非接触に対応していないカード）を選択すると、ステップアップが必要になります。実例を 2 つ挙げましょう。


最初のシナリオでは、Google Wallet に追加してあるカードが Google Pay シートに表示されています。カードのイメージと発行銀行の名前も表示されています。決済時にユーザーがこのカードを選択した場合、CRYPTOGRAM_3DS èªè¨¼æ‰‹æ®µã«è©²å½“するので、ステップアップは不要です。

一方、2 つ目のシナリオのシートには、通常のカード ネットワークのアイコンが表示されています。これは PAN_ONLY èªè¨¼æ‰‹æ®µã‚’表しているので、ステップアップが必要です。

PAN_ONLY vs. CRYPTOGRAM_3DS

両方の決済形態を認めるかどうかは、皆さんの判断です。CRYPTOGRAM_3DS ã®å ´åˆ、Google Pay API は cryptogram ã‚‚返します。また、ネットワークによっては、eciIndicator ã‚‚返します。認可を続けるうえで、これらのプロパティを活用してください。

PAN_ONLY

この認証手段は、ユーザーの Google アカウントの決済カードに紐付けられています。返される決済データには、PAN と有効期限年月が含まれます。

CRYPTOGRAM_3DS

この認証手段は、発行者が提供する Android デバイス トークンとして保存されているカードに紐付けられています。返される決済データには、デバイスで生成された暗号文が含まれます。

Google Pay の取引でステップアップを使うべきタイミング

loadPaymentData ãƒ¡ã‚½ãƒƒãƒ‰ã‚’呼び出すと、Google Pay API は暗号化した決済トークン (paymentData.paymentMethodData.tokenizationData.token) ã‚’返します。復号化した paymentMethodDetails ã‚ªãƒ–ジェクトには assuranceDetails ãƒ—ロパティが含まれています。これは次のような形式になっています。

"assuranceDetails": {
    "cardHolderAuthenticated": true,
    "accountVerified": true
}

cardHolderAuthenticated ã¨ accountVerified ã®å€¤ã«ã‚ˆã£ã¦、ステップアップ認証が必要になる場合があります。次の表に、考えられるシナリオと、取引にステップアップ認証を使うことを Google が推奨しているかどうかを示します。

cardHolderAuthenticated

accountVerified

ステップアップが必要

true

true

いいえ

false

true

はい

cardHolderAuthenticated ã¨ accountVerified ã®ä¸¡æ–¹ãŒ true を返した場合のみ、ステップアップを省略できます。

次のステップ

まだ assuranceDetails ã‚’使っていない方は、利用を検討し、必要に応じて取引のステップアップを行ってください。また、欧州経済領域（EEA）で決済処理を行う場合は、強力な顧客認証（SCA）ガイドもご覧ください。Twitter で @GooglePayDevs ã‚’フォローすると、今後の最新情報を受け取ることができます。質問がある方は、ツイートに #AskGooglePayDevs を含めて、@GooglePayDevs をメンションしてください。


Posted by Eiji Kitamura - Developer Relations Team

「テクノロジーは猛スピードで変化するので、どこからどのように始めたらよいのかわからなくなってしまうことがあります。注目すべきことは何なのか。それを見つけ出すのが難しいのです。この難題に切り込むため、デベロッパーの皆さんに明確な方向性を示したいと思っています」

Chrome リードの Paul Kinlan が、Chrome ツールやそのヒント、そして開発を始める方法について直接お話しします。


Chrome デベロッパー コミュニティにはインスピレーションあふれるエキスパートがたくさんいます。その 1 人が、Google 社員として Chrome およびウェブ プラットフォーム デベロッパー リレーションズ チームのリードを担当している Paul Kinlan ã§ã™。気に入っている Chrome ツールやインスピレーションを受けた Chrome デベロッパーについて、Paul の話を聞きましょう。

自己紹介をお願いします。

「Paul Kinlan です。Chrome およびウェブ プラットフォーム デベロッパー リレーションズ チームを率いています。たいへん幸運なことに、ウェブに情熱を傾け、今後もウェブを繁栄させ続けることにキャリアのすべてを注いでいるたくさんの方々と一緒に仕事をしています。興味がある方は、ぜひ私のサイト paul.kinlan.me ã‚’フォローしてください」

子どものころの話を聞かせてください。

「イギリスのウィラルで育ちました。イングランド北西部にある半島で、一部はウェールズに属しています。父親が家でコンピュータを修理している様子など、幼いころからコンピュータに囲まれていた記憶があります（モニターの後ろのコンデンサに触るなと何度怒られたかわかりません... でも、楽しそうに見えました）。

また、コンピュータのクラブに通ってデモやクラッキングの場面を見たり（人からゲームを「借りた」こともあったかもしれません）、学校で自分と同じようにゲームやコンピュータが好きな友だちを探したりしていました」

この業界に入ったのはどうしてですか？特に、なぜウェブ テクノロジーに興味を持ったのでしょうか？

「子どものころ、父は私にプログラミングを教えようとしましたが、よく理解できませんでした。しかし 12 歳くらいのころ、初めてストリート ファイターのアーケード ゲームを見て、ピンときたのです。そして、ループの考え方、ジョイスティックの読み取り方、画面の表示の仕方などを理解しました。

同じころ、祖父が宝くじの番号を苦労して選んでいるのを見て、ソフトウェアで手助けできないかと思いました。QBasic を起動してマニュアルを読み、試してみました。ただ、アメリカでは colour のスペルが違うことも知らなかったので、投げ出しそうになりました...（そこでやめていたら、どんな人生になっていたかと思います）

その数年後に、ウェブが登場しました。少しいじってみて、ちょっとした Perl と HTML で簡単なサイトやアプリケーションを作れることに気づきました。夢中になり、事業を始めて、さらにその先に進みました。今はこの Chrome チームで、私が手にしたのと同じようなチャンスをデベロッパーの皆さんに提供したいと考えています」

デベロッパーが直面している課題には、どのようなものがあると思いますか？

「情報が多すぎることです。テクノロジーは猛スピードで変化するので、どこからどのように始めたらよいのか、わからなくなってしまうことがあります。注目すべきことは何なのか。それを見つけ出すのが難しいのです。この難題に切り込むため、デベロッパーの皆さんに明確な方向性を示したいと思っています」

Chrome やウェブについて詳しく学ぶうえで、特に便利なおすすめの学習リソースは何でしょう？全員が知っておくべきライブラリや Codelab はありますか？

「私の意見ですが、https://web.dev/learn ã¯ã™ã°ã‚‰ã—いリソースだと思います。ウェブ開発の中核原理が説明されており、私たちは、優れたウェブ開発の手法について、このリソースに最新ガイドを常に反映しようとしています。

私のような人は多くないと思いますが、私自身はプログラミングのリファレンス資料に没頭していたことがあります（そしてじっくりと考えました）。これも始め方の 1 つだと思います。また、MDN（Mozilla Developer Network）と glitch.com ã‚„ GitHub ãªã©ã®ã‚µã‚¤ãƒˆã‚’組み合わせれば、何のソフトもインストールせずに、短時間で考え方を学んだり試したりできます。デベロッパーになるには本当にすばらしい時代です」

デベロッパーや技術者が Chrome やウェブを使って開発する手法のうち、特に驚いたものや刺激を受けたものは何ですか？

「おもしろい質問ですね！ 

今とてもスリリングなのは、ウェブと ML が交差する部分です。これまでできるとは思っていなかったようなことをするサイトやアプリが開発されており、URL を開くだけでアクセスしてもらうことができるのです」 

「Corridor Crew（視覚エフェクト技術者集団） ã«æ³¨ç›®ã—ていました。彼らには、動画から人を抜き出し、背景を別の動画に置き換え、その人を上に重ね直すという難題がありました。その最速のソリューションは、ブラウザと ML を使って構築されました。🤯

同時に、ウェブでは絶対にできないと思われていたようなアプリをウェブ化している人たちを応援しています。たとえば、Photoshop や Audacity などです。今や、フル機能の動画エディタをウェブで作ることができます。ブラウザさえ使えれば、誰でも動画を制作できるのです。すばらしいことですね。

ウェブでは、リンクをクリックするだけで、たくさんのことができます。その多くは、できるとは思っていなかったことです。毎日のように何かを見て刺激を受けています。だからウェブが好きなのです」

Chrome やウェブのテクノロジーの具体的なユースケースで、特におもしろいと思ったものは何でしょう？

「個人的には、Fugu（ディープ ハードウェア）の API セットに夢中になっています。あらゆる種類の業務を初めて完全にウェブ化するものだからです。

新しい範囲を扱う CSS や UI 関連の API ã«ã‚‚期待しています。これまで複雑だったことを、信じられないほど簡単にしてくれるからです。ウェブは主に視覚によるメディアですが、品質に関する認識は他のプラットフォーム（Android や iOS のアプリなど）よりも遅れています。こういった新しいプリミティブや概念によって、高度で滑らかなユーザー インターフェースが実現できるようになり、デベロッパーやデザイナーの作業も少なくなるはずです」

Chrome やウェブの開発を成功させる秘訣は何ですか？

「段階によりますが、すでに確立されているサイトであれば、ウェブに関する主な指標などを利用してユーザー エクスペリエンスの改善方法を探るとよいでしょう。

開発を始めたばかりであれば、ただ始めるだけです。ブラウザでプロトタイプを作り、驚くほど短時間で実用的なものを提供できるようにするツールはたくさんあります。これまではフルスタック（ホスティングからフロントエンドまで）について考える必要がありましたが、そのような心配は少なくなっています」

Chrome やウェブのコミュニティが次に期待すべきことは何でしょう？どんな未来像が描けるでしょうか？

「何を話しても正解にはならないと思います。😀 ただ、こういった質問は好きなので、話してみることにしましょう.... あるブラウザに機能がリリースされ、Blink、WebKit、Gecko ã§ã‚‚れなく利用できるようになるには、3 年から 5 年ほどかかるようです。この点を考慮すると、近い将来は今とそう変わらないものの、（互換性の意味で）均等になるのではないかと思います。Interop 202X ãªã©ã®ãƒ—ロジェクトによって、どんな環境でも動作するサイトが作りやすくなっています。

ただ、さらに遠い未来については.... 何年か前に、「ヘッドレス ウェブ」という考え方についてお話ししたことがあります。つまり、Siri や Google アシスタントのようなサービスやアシスタントがウェブページを深く理解し、（読み上げるだけでなく）さまざまな操作ができるようになる可能性が高いと考えています。

同時に、たくさんの他のプラットフォームによって、ウェブが意味するものの定義が変わりつつあります。Facebook や WeChat などは、それ自体がブラウザでプラットフォームなので、いつでもそのプラットフォームに戻ることができます。世界がモバイル化する中、この数年間でオンラインにやってきた何十億という人々（そしてこれからも、何十億という人々がオンラインにやってきます）に目を向けてみましょう。そういった人々は、私たちが知るような形でブラウザを使うでしょうか。それとも、そういった「代替ブラウザ」プラットフォームを使うでしょうか...

確かなのは、ウェブのエクスペリエンスを誰にとっても優れたものにし続けなければならないことです」

現在、ウェブや Chrome が重視しているものは何ですか？その理由は何でしょう？

「Chrome は今も、『高速、シンプル、安全なウェブ』というリリース時と同じ原則を重視しています。この観点で見れば、私たちの作業のほとんどはこの目的に沿ったものです。たとえば「ウェブに関する主な指標」では、サイトのユーザー エクスペリエンスが適切かどうかを判断できる一連の指標を見つけ出しました。これがウェブを根底から変化させると考えています。別の軸には、WASM などのテクノロジーがあります。これはネイティブ コード（C/C++ など）をブラウザのサンドボックスで安全かつ高速に実行できるようにする方法です。その速度も、インストールしたアプリケーションの速度に近づいています」

ウェブと Chrome によって、デベロッパーの可能性はどのように広がりますか？

「一言で言えば、ユニバーサル アクセスです。それを実現するのがリンクですが、リンクを誰もがアクセスできるオープンなものにし続けるには努力が必要です」

ほかに世界中の Google デベロッパー コミュニティにお話ししたいことはありますか？

「今、世界は混迷を深めています。人々の声を聞き、人々を支え、人々が立ち上がる手伝いをしましょう。私がそれを始めたとき、まわりのコミュニティはとても協力的で、自分が貢献する以上に助けてもらいました。ありがたいことに私はチャンスをもらいましたが、今は、あらゆる背景の人が同じチャンスを得られるようにすることに時間を使っています。同じことをしてくれる人がいるとうれしく思います」

 

DevFest を開催している近くの Google デベロッパー グループを探す

Google のウェブ テクノロジーや Google Chrome についてもっと知りたいと思った方、DevFest や Google デベロッパー グループ（GDG）に参加してみたいと思った方は、こちらから、お近くで DevFest を開催している GDG を探しましょう。


Posted by Eiji Kitamura - Developer Relations Team



パスキーがデバイスに保存されると、ログイン時の自動入力に表示されるので、安全にログインできるようになります。




デスクトップ デバイスでも、近くのモバイル デバイスのパスキーを利用できます。パスキーは業界標準に基づいて作られているので、Android デバイスでも iOS デバイスでも利用可能です。




この方法でログインしても、パスキーがモバイル デバイスの外に出ることはありません。サイトと交換されるのは安全に生成されたコードのみなので、パスワードとは違い、何も漏洩することはありません。

ユーザーがパスキーを細かく管理できるように、Windows と macOS の Chrome M108 以降では、Chrome 上でパスキーを管理できるようになっています。




パスキーに対応する

サイトでパスキーを動作させるには、デベロッパーが WebAuthn API を使ってサイトにパスキーのサポートを組み込む必要があります。私たちは、Apple や Microsoft をはじめとする同じ業界の企業、FIDO Alliance のメンバー、W3C と協力し、何年もかけて安全な認証標準の検討を進めています。

私たちの目的は、ウェブで可能な限りユーザーの安全を守ることです。そのため、パスキーがもたらす未来に期待を寄せています。Chrome がパスキーに対応したのは大きな節目ではありますが、これで作業が終わるわけではありません。このテクノロジーがさまざまなサイトで広く採用されるには、まだ時間が必要です。iOS と Chrome OS でパスキーを利用できるようにするための作業も進行中です。移行が進む今後も、パスワードは私たちの生活の一部であり続けるので、Google パスワード マネージャーを通じて通常のログインの安全性と利便性を強化する作業も続けてまいります。



Posted by Eiji Kitamura - Developer Relations Team

Rose Niousha さんは、学生がさまざまな新しい技術を追求できるコミュニティを作りたいと考えました。そして、多様性への情熱から、Google Developer Student Clubs ã®æ”¯éƒ¨ã‚’立ち上げる中で、Women Techmakers（WTM）プログラムの存在を知りました。

早稲田大学で情報理工学を専攻する Rose さんは、学校で学んだことを実際の企業の開発現場やインターンシップですぐに適用するのが難しいと感じている学生が多いことに気づきました。学業で学ぶことと、企業の開発で求められるスキルのギャップを埋めようと考えた Rose さんは、早稲田大学のキャンパスに Google Developer Student Club（GDSC）支部 ã‚’設立し、このギャップを埋める活動に取り組み始めました。彼女のリーダーシップは実を結び、GDSC Waseda はわずか 1 年で 170 名以上の現役メンバーが参加する日本最大の支部になりました。本投稿では、Rose さんがどのようにコミュニティで大きな成果をあげ、WTM アンバサダーになったのかを紹介します。

コミュニティでインクルージョンを重視する GDSC Waseda

Rose さんがこのコミュニティで最も重視したのが、ダイバーシティとインクルージョンです。 コアチームのメンバーを選ぶにあたって考えたのは、多様な視点を持てるようにすることと、さまざまな学歴を持つ人に参加してもらうことでした。また、他の専攻の学生も積極的に募集することで、コミュニティで疎外感を感じる人がいないようにしました。その結果、技術系を専攻する人も、そうでない人も参加するようになりました。技術 コミュニティでは珍しく、メンバーの内 47.8% が女性という男女同等の比率が実現しました。

2021-2022 GDSC Waseda コアチーム（日本、東京）

コアチーム結成後、Rose さんは、言語の壁を破ることでさらにインクルーシブなコミュニティを目指すことにしました。そこで、あらゆる背景を持つ学生たちがコミュニケーションを取り合えるようにするために、GDSC Waseda の主言語を英語にしました。早稲田大学は国際色豊かなので、学生が自信を持って英語で専門分野について議論できないという課題にも挑むことができました。また、学生同士の交流も活発になり、語学力の向上にもつながっています。

学生の教育、活性化、つながりに貢献するプログラムを開催

GDSC Waseda では、講演やハンズオン形式のプログラミング ワークショップなど、年間 30 イベントを超える活動が行われ、学生たちはそれを通して Flutter、Google Cloud Platform、Firebase などのツールを実践的に学んでいます。

Flutter ã‚»ãƒƒã‚·ãƒ§ãƒ³ã§ã¯、ネイティブにコンパイルできるモバイルアプリの作り方を学ぶだけでなく、毎年開催されている GDSC Solution Challenge ã¸æå‡ºã§ãã‚‹ã‚¢ãƒ—リ開発にも挑戦しました。Firebase ã‚»ãƒƒã‚·ãƒ§ãƒ³ã§ã¯、ユーザー データベースを扱うバックエンド チームをサポートする方法や、NoSQL データベースの基本を学びました。新しく学んだ技術を導入することで、プロジェクトのスケーラビリティやデータ セキュリティを向上することができました。

GDSC Waseda は他の企業とも連携し、学生たちがコーディングやプログラミング、チーム マネジメント、デザイン思考といったさまざまな領域を体験できるようにしています。こういった体験は、学生がインターンシップ先を見つける際に役立っています。また、IT 業界の実践的な側面について知見を得られるため、文系を専攻している学生が IT 企業で UX/UI デザインや PM といった役割のインターンシップを確保する機会にも繋がっています。

GDSC Waseda のイベント参加者（日本、東京）


リーダーシップの発揮 : 日本から GDSC Solution Challenge に初挑戦

Rose さんは、GDSC リードとして、メンバーが GDSC Solution Challenge に参加することを積極的に促しました。彼女は Solution Challenge への提出を最終目標ではなく、出発点として見ていました。この積極的な姿勢が功を奏し、GDSC Waseda から 4 チームがプロジェクトを提出しました。そして、機械学習を使ったモバイル安全アプリ mimi4me ãƒãƒ¼ãƒ ãŒ、日本で初めて世界トップ 50 å…¥ã‚Šã‚’果たすことになりました。受賞後、mimi4me チームはこのソリューションをさらに拡大し続け、アプリを Google Play で近日公開する予定です。


Mini Solution Challenge の受賞チームに証書を手渡す Rose Niousha さん（日本、東京）

また、GDSC Waseda は Solution Challenge 後に Mini Solution Challenge ã¨ã„うイベントを開催しました。すべてのチームが提出したソリューションについてプレゼンし、イベント参加者が気に入ったプロジェクトに投票しました。

そして、GDSC Waseda の別の学生チームは、GDSC の経験を活かし、GDSC Keio（慶應義塾大学）の学生と合同で e コマースのスタートアップ企業を設立しました。

これまでの成果を振り返る

Rose さんは、Google 関係のネットワークや LinkedIn などのツールを通して IT 業界で活躍しているたくさんの女性たちと交流するようになりました。国際女性デー（IWD）月間には、何週間も前からイベントの企画をし、何度も講演者と打ち合わせをしながら準備を進めました。IT 業界で活躍している現役女性エンジニアによる有益なセッションを通して、GDSC Waseda に参加し、IT 分野に興味を持つ女子学生が増加しました。現在、GDSC Waseda は、メンバーの男女比が同等の多様なコミュニティを持つことを誇りに思っています。

Rose さんは次のように語っています。「GDSC リードという役割に就くことで、信じられないようなチャンスが生まれました。私の活動の大きな目標の 1 つは、この GDSC コミュニティを通して IT 業界でのジェンダーの壁を打ち破ることでした。そこで、国際女性デー（IWD）月間に積極的にイベントを開催しました」


Rose Niousha さんと、Google デベロッパー コミュニティ プログラムのグローバル責任者を務める Erica Hanson（米国、ニューヨーク州ニューヨーク シティ）

WTM アンバサダーとしてインクルーシブな未来を築く

Rose さんは、Google ジャパンでコミュニティ マネージャーを務める Reisa Matsuda と協力し、多様で包括的なコミュニティを構築するという彼女の情熱を育みました。その過程で、Women Techmakers（WTM）プログラムについての話を聞き、このプログラムが提供するさまざまなメリットを活用することを勧められました。助言や指導を受けた Rose さんは、GDSC リードになって間もなく、アンバサダーとして Women Techmakers（WTM）にも参加しました。


GDSC リード卒業式での Reisa Matsuda と Rose さん

技術勉強会やイベントで活躍する女性スピーカーを育成するためのプログラム、Women Developer Academy（WDA）を修了した Rose さんは、WTM Tokyo が開催した今年の国際女性デーイベントでパネリストとして登壇することになりました。講演では、WDA プログラムでの体験や、WTM の IWD 2022「Progress, not Perfection」キャンペーンに関連する Rose さんのエピソードが共有されました。


Rose Niousha さんと、Google Women Techmakers の責任者 Caitlin Morrissey（米国、カリフォルニア州マウンテン ビュー）

Rose さんは、WTM プログラムの一環として、2022 å¹´ 5 月 11 日にショアラインから Google I/O にオフラインで現地参加しました。コロナ禍に活動していた Rose さんにとって、これが初めて参加した対面式 Google デベロッパー イベントでした。


「あまりの規模に驚きました。イベントの最初には、Google の CEO、Sundar Pichai のインスピレーションあふれるトークがありました。さまざまな講演を聞いたり、ネットワーキングし、充実した時間を過ごすことができました。カリフォルニアで多くのすばらしい学生や業界のプロと出会い、ユニークなアイデアを自分の GDSC 支部に持ち帰ることができました」と Rose さんは述べています。

 

お近くの Google Developer Student Club にご参加ください

Google Developer Student Club（GDSC）は、Rose さんのように Google のテクノロジーに関心のある学生向けのコミュニティです。GDSC は 112 か国に 1,800 以上の支部を持ち、技術ソリューションの構築を通じてコミュニティを支える Rose さんのような学生エンジニアをサポートすることを目的としています。Google Developer Student Club コミュニティに参加希望の学生の方は、こちらからお近くの支部をお探しください。または、プログラムのページにアクセスして、ご自分の地域に支部を作る方法をご覧ください。

※ GDSC Japan 公式ウェブサイトはこちらからご覧いただけます

Women Techmakers の詳細

Google の Women Techmakers ãƒ—ログラムは、テクノロジー業界の女性たちに就業サポートやコミュニティ、学習資金を提供しています。Women Techmakers アンバサダーは、コミュニティに影響を与え、すべての女性がテック業界で活躍できる世界を作ることに情熱を燃やすグローバル リーダーです。


Posted by Reisa Matsuda - Developer Relations Team

私たちが直面している身近な課題の 1 つ 1 つは、新しいソリューションを見つけるチャンスでもあります。Google が毎年開催している Solution Challenge ã‚³ãƒ³ãƒ†ã‚¹ãƒˆã§ã¯、世界の Google Developer Student Clubs（GDSC）コミュニティが Google のテクノロジーを使って実社会の問題を解決することに挑戦しています。

今年の Solution Challenge の参加者は、人の雇用、経済成長、気候変動対策を推進することを目指す国連の 17 の持続可能な開発目標を実現することに取り組みました。

2022 ソリューション チャレンジ受賞者

Global Top 50 の準決勝進出者と、Top 10 の決勝進出者がこちらに発表されました。Demo Day では、決勝進出者が Google と世界中のデベロッパーに向けてプレゼンテーションを行い、その様子が YouTube でライブ中継されました。

Demo Day では、審査員によるプロジェクトの審査や質問を経て、3 組のグランプリ受賞者が選ばれました。こちらから Demo Day イベントのアーカイブ動画をご覧いただけます。

ここでは、10 組の決勝進出者とそのすばらしいソリューションを紹介します。

トップ 10 プロジェクト

. . .

BloodCall - ギリシャ、ヘロコピポ大学（アテネ）

国連の対応する持続可能な目標 : #3: 健康と福祉の促進

BloodCall は誰でも簡単に献血を行えるようにするソリューションで、Android、Firebase、Google Maps SDK を活用しています。この仕組みを構築したのは、Athanasios Bimpas さん、Georgios Kitsakis さん、Stefanos Togias さんです。

「このアイデアは、2 つの気づきに基づいています。1 つ目は、特にギリシャにおいて、献血したい人は非常に多いにもかかわらず、情報が不十分なことです。2 つ目は、多くの人が SNS で自分や家族が献血を必要としていることを発信していることです。そこから、大きなニーズが存在すると考えました」

Blossom - カナダ、ウォータールー大学

国連の対応する持続可能な目標 : #3: 健康と福祉の促進、#4: 公正な教育、#5: ジェンダー平等と女性の能力強化、#10: 不平等の是正

Blossom は月経に関する正確な情報を若い女性に提供する統合ソリューションで、Android、Firebase、Flutter、Google Cloud Platform を活用しています。この仕組みを構築したのは、Aditi Sandhu さん、Het Patel さん、Mehak Dhaliwal さん、Jinal Rajawat さんです。

「女性生殖器系について家族と話しづらいのは理解しています。そのため、早い時期からそのような会話を始めることができるように、若者向けのアプリを開発したいと思いました。Blossom なら、自分のデバイスで安心して学ぶことができます。自分の体についての知識が増えれば、それだけで自分に自信がもてるようになり、目標 5 のジェンダー平等と女性や女児の能力強化を図ることができるのです」

Gateway - ベトナム、ホア・セン大学

国連の対応する持続可能な目標 : #3: 健康と福祉の促進、#11: 持続可能な都市、#17: パートナーシップ

Gateway は、オープンな COVID-19 デジタル チェックイン システムです。モバイル アプリと連携し、Bluetooth 接続プロトコルで組み込みシステムと通信するオープンソースの IoT ソリューションを通過してチェックインを行います。Angular、Firebase、Flutter、Google Cloud Platform、TensorFlow、プログレッシブ ウェブアプリを使ってユーザーと COVID-19 デジタル チェックイン システムをつないでいます。この仕組みを構築したのは、Cao Nguyen Vo Dang さん、Duy Truong Hoang さん、Khuong Nguyen Dang さん、Nguyễn Mạnh Hùng さんです。

「私たちのコミュニティでは、COVID 関連の技術サポートが十分でなく、未だに問題が起き続けています。ワクチン接種結果の登録は手動（紙）で行わなければなりません。企業やコミュニティにとって、最大の課題は『オフラインに戻る』ことです。混雑している場所では、接触者追跡ソリューションは完全に過負荷状態になっています。オープンソースの自動チェックイン ゲートウェイを作り、より直感的にシステムを使えるようにすることで、混雑を改善したいと考えています」

GetWage - インド、G.H. ライゾニ工科大学（ナーグプル）

国連の対応する持続可能な目標 : #1: 貧困の撲滅、#4: 公正な教育、#8: 人間らしい雇用と経済成長

GetWage は、地方経済で失業や欠員に悩む人々を助けるため、日雇いの仕事を簡単に検索・募集できるツールです。この仕組みは、Firebase、Flutter、Google Cloud Platform、TensorFlow を活用しており、Aaliya Ali さん、Aniket Singh さん、Neenad Sahasrabuddhe さん、Shivam さんが構築しました。

「コロナ禍において、一番大きな打撃を受けたのが日雇い労働者です。ラクナウ（インド北部の都市）のデータから、コロナ前はほとんどの労働者が月に平均約 21 日働いていましたが、ロックダウン後はそれが 9 日に落ち込んだことがわかりました。プネーの町では、月の平均労働日数は 12 日から 2 日まで落ち込みました。このような状況から、雇用者と労働者を繋げたり、労働者の教育を通じて、困っている人々を助けたいと思いました」

Isak - 韓国、順天郷大学校

国連の対応する持続可能な目標 : #3: 健康と福祉の促進、#12: 責任ある消費と生産

Isak は、ジョギングとゴミ拾いを組み合わせることで、ゴミ拾いの効果を高めることを目指すアプリです。この仕組みは、Firebase、Flutter、Google Cloud Platform、TensorFlow を活用しており、Choo Chang Woo さん、Jang Hyeon Wook さん、Jeong Hyeong Lee さん、JeongWoo Han さんが構築しました。

「コロナ禍により家にいる時間が増えたことで、宅配注文が増え、使い捨てのゴミが指数関数的に増加しました。私たちのチームは、ゴミの削減と運動の両方の問題に取り組むことにしました。ジョギングをしながらゴミ拾いをすれば、健康と環境の両方に貢献でき、機能を追加すれば、ユーザーの興味を引いて参加を促すことができると考えました」

SaveONE life - ケニア、タイタ タヴェタ大学

国連の対応する持続可能な目標 : #1: 貧困の撲滅、#2: 飢餓の撲滅、#4: 公正な教育、#10: 不平等の是正

SaveONE life は、生活必需品、食品、衣類、教育関係の品物などを必要としているケニアの孤児院を探し、そこに寄付できるようにする仕組みです。Android、アシスタント / Actions on Google、Firebase、Google Cloud Platform、Google マップを利用しており、David Kinyanjui さん、Nasubo Imelda さん、Wycliff Njenga さんが構築しました。

「キャンパスのそばにある孤児院に行って院長の話を聞いたとき、食品に困っていることを知りました。子どもの学費を含め、十分な食品や水、衣類、教材がなく、栄養失調になっている子どももいます。主な利用目的として考えたのは、キャンパスの周辺にいる人々に、孤児院の場所や寄付の方法とタイミングについてよく知ってもらうことです」

SIGNify - カナダ、トロント大学（ミシサガ）

国連の対応する持続可能な目標 : #10: 不平等の是正、#4: 公正な教育

SIGNify は、すべての人が視覚的に手話を簡単に理解できるようにするインターフェースを提供します。Android、Firebase、Flutter、Google Cloud Platform、TensorFlow を利用しており、Kavya Mehta さん、Milind Vishnoi さん、Mitesh Ghimire さん、Wentao Zhou さんが構築しました。

「世界中の約 7,000 万人の耳が不自由な人が、手話を使ったコミュニケーションを行っています。しかし、手話を理解できる人がいなければ、コミュニケーションに支障をきたします。そのため、耳の不自由な人の 4 人に 1 人が差別を理由に職を離れるという事態になっています。手話を理解できなければ、耳の不自由な人が持つ知識や能力を学ぶ機会を失ってしまいます。手話を学び、職場で耳の不自由な人を雇うことで、権利の平等を推進し、障がいのある人の雇用機会を増やすことができます」

Starvelp - トルコ、イズミル経済大学

国連の対応する持続可能な目標 : #2: 飢餓の撲滅

Starvelp は、食品廃棄と飢餓の問題に取り組みます。Firebase、Flutter、Google Cloud Platform を利用しており、Akash Srivastava さんと Selin Doğa Orhan さんが構築しました。

「現在、非常に多くの人々が栄養不良に陥っています。自分や家族の食料が得られずに苦しんでいる人が多いのは、厳しい経済状況に関係しています。多くの国にたくさんのスラム地域があり、農業に従事するたくさんの人が十分な食料を得ることができずにいます。人々が毎年その影響を受けており、栄養不良により、さまざまな病気にかかっているというニュースを見るのは、大変衝撃的なことです。」

Xtrinsic - ドイツ、アルベルト・ルートヴィヒ大学フライブルク工学部

国連の対応する持続可能な目標 : #3: 健康と福祉の促進

Xtrinsic は、メンタルヘルスの研究と治療のためのアプリで、個人の習慣やニーズに合わせて周囲の環境を調整します。このアプリで目指したのは、ウェアラブル デバイスと TensorFlow を活用して日中や夜中のストレスを検出し、乗り切れるように行動を提案することです。Android、アシスタント / Actions on Google、Firebase、Flutter、Google Cloud Platform、TensorFlow、WearOS、DialogFlow、Google Health Services を利用しており、Alexander Monneret さん、Chikordili Fabian Okeke さん、Emma Rein さん、Vandysh Kateryna さんが構築しました。

「これを思いついたのは、私たち自身がメンタルヘルスの問題を経験したからです。チームのメンバーのうち 2 人が、最近起こったシリアとウクライナの戦争によって直接的な影響を受けました。そして、私たち全員がパンデミックの際にメンタル ヘルス不調を経験し、その困難を通じて難しい状況を克服し、前向きであり続ける方法を学びました。そのノウハウと Google のテクノロジーがあれば、状況を変え、世界をより良くできると信じています」

Zero-zone - 韓国、淑明女子大学校

国連の対応する持続可能な目標 : #4: 公正な教育、#10: 不平等の是正

Zero-zone は、耳が不自由な人々の積極的なコミュニケーションや、読唇術を練習するサポートを行います。活用しているツールは、Android、アシスタント / Actions on Google、Flutter、Google Cloud Platform、TensorFlow です。この仕組みを構築したのは、DoEun Kim さん、Hwi Min さん、Hyemin Song さん、Hyomin Kim さんです。

「韓国では、耳が不自由な人の約 39% が、特別な学校に通っても読唇術を学ぶのは難しいと感じています。このプロジェクトは、耳の不自由な人がいつでもどこでも読唇術を学び、積極的なコミュニケーションが取れるように、読唇術を上達させることを目指しています。このツールは、会話を実践したい耳の不自由なユーザーに平等な教育の機会を与えます。さらに、耳の不自由な人が積極的なコミュニケーションを取ることで、自信を持てます。」

Solution Challenge に参加したい方や、Google Developer Student Clubs （GDSC）についてもっと知りたいと思った方は、ぜひ下記リンクをご覧ください。


Posted by Reisa Matsuda and Takuo Suzuki - Developer Relations Team
Share on Twitter Share on Facebook

Google は、本日よりデジタルを通じて日本経済・社会の活性化に貢献するスタートアップを対象としたアクセラレーター プログラム「Google for Startups Accelerator Class 5」の募集を開始します。

Google for Startups Accelerator Class 5 では、Google の社員や外部のアドバイザーが、メンタリング セッション、ワークショップなどを通じてスタートアップの成長を支援します。 このプログラムは、デジタルを通じて日本経済・社会の活性化に貢献し、今後スケールする将来性があるスタートアップを対象にしています。

このプログラムは、すでに商品またはサービスを市場に投入し、市場的価値が見込まれ、スケールする将来性があるスタートアップを対象に、これからの成長に備えるためのサポートを提供します。テクノロジーを活用した社会、経済、環境といったさまざまな分野の問題解決への取り組みを加速し、ひいては、スタートアップの成長が日本経済のさらなる活性化につながることを期待しています。

ぜひご応募ください。


Google for Startups Accelerator 活用の利点


Google がスタートアップを支援する理由 :

Google はテクノロジーが社会をより良くしていくと考えています。私たちは社会の大きな課題を解決するためのアイデアを持つスタートアップをテクノロジーの力で支援したいと考えています。

Google for Startups Accelerator が求めるチーム

 ä¸‹è¨˜ã®ãƒ†ãƒ¼ãƒžã§æ´»èºã•ã‚Œã¦ã„るスタートアップを探しています！


募集概要


Posted by Reisa Matsuda and Takuo Suzuki - Developer Relations Team

Share on Twitter Share on Facebook

この記事は 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 は、業界を問わずさまざまなユースケースにメリットをもたらします。いくつか例を挙げてみましょう。

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
Share on Twitter Share on Facebook

環境に優しいルート選択の開発者向けプレビュー版が公開されました。燃費を向上することで、車両の燃料使用量、エネルギー使用量と 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
Share on Twitter Share on Facebook

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

Share on Twitter Share on Facebook

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



Share on Twitter Share on Facebook

このシャトルでは、同じ Caravel ハーネスを使い、OpenLane è‡ªå‹•è¨­è¨ˆãƒ•ãƒ­ãƒ¼ã‚’ベースとした既存の OpenMPW シャトルのインフラストラクチャを活用します。プロジェクトの提出には Efabless ãƒ—ラットフォームを利用します。

それぞれのシャトルランでは、以下の条件に基づいて 40 のプロジェクトを選びます。
初回のシャトル GF-MPW-0 ã¯ãƒ†ã‚¹ãƒˆã‚·ãƒ£ãƒˆãƒ«ã§、2022 å¹´ 10 月 31 日から 2022 å¹´ 12 月 5 日まで提出を受け付ける予定です。これは、オープンソース チップ ツールチェーンによる新しい PDK と Caravel ハーネスの組み合わせをコミュニティとともに検証する方法として活用されます。以降のシャトルでは、プロジェクトの提出期間が長くなり、テストが改善されます。

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



Posted by Johan Euphrosine and Takuo Suzuki - Developer Relations Team
Share on Twitter Share on Facebook

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
Share on Twitter Share on Facebook

この度、デベロッパーの皆さんが 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
Share on Twitter Share on Facebook