この記事は Eric Bahna による Android Developers Blog の記事 "Expanding the reach of your Android Auto apps" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

昨年 12 月、Google Play ストアで新しい Android Auto アプリをクローズド テストに公開できる機能を開放しました。続いて 2021 年 1 月 28 日より、Google Play ストアで、ナビゲーション、駐車場、充電スポットのアプリをオープン テストトラックに公開し、アプリのユーザーを増やせるようになりました。

オープンテストでは、アプリをダウンロードできるユーザー数に制限はなく、メールアドレスの一覧を管理する必要もありません。このオープンテストは、正式にアプリをリリースするまでの重要なマイルストーンです。アプリを実際の車ですべてのユーザーに使ってもらうことに一歩近づきますので、ぜひ Android for Cars App Library を使い、Play Console でオープン テストトラックを選択してアプリを公開してください。　　

Android Auto アプリに関する今後の予定についてお知らせします。

現在、このライブラリを Android Jetpack に追加する作業を進めています。これにより、他の Jetpack API との整合性が向上し、新機能が見つけやすくなります。Jetpack ライブラリが利用できるようになると、既存のライブラリからのアプリ移行が簡単になり、名前空間を変更していくつかの API 呼び出しを調整するだけの作業で完了します。Jetpack でライブラリを安定させた後は、その新しいアプリを Google Play ストアの本番環境トラックに公開できるように準備を進めればよいのです。

Jetpack ライブラリを待たずとも、オープン テストトラックに公開することはできるようになっています。以下の手順で公開してみましょう。

1. デベロッパー ガイドとアプリ品質ガイドラインを参考に、アプリのエクスペリエンスを設計する。
   
   
2. 今からユーザーのフィードバックを受けられるように、現在のベータ版ライブラリを使って開発する。
   
   
3. Desktop Head Unit を使ってテストする。
   
   
4. Google Play ストアに公開する（現在はオープン テストトラックまで）。

多くのデベロッパーの皆さんが開発した自動車向けアプリを、実車でテストすることを楽しみにしています。

この記事は Justin Schuh - Chrome エンジニアリング、ディレクターによる Chromium Blog の記事 "Privacy Sandbox in 2021: Testing a more private web" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。（同時期に公開されたこちらの記事にも類似の内容が掲載されていることをあらかじめご了承ください）
サードパーティ Cookie を段階的に廃止し、それに代わる、もとよりプライバシーが維持されるブラウザの新機能を導入する計画についてお知らせしたのは 1 年前のことでした。それ以来、W3C をはじめとした幅広いウェブ コミュニティと密接に連携しながら、オープンウェブの活力と持続可能性も保ちつつプライバシーを保護する新技術の設計と実装を進めてきました。

これまでに、Chrome などが 30 種類以上の提案を行っています。その中には、サードパーティ Cookie を廃止するために鍵となると考えられる提案も数多く含まれています。初期のテストでも期待できる結果が出ています（後述）。

エコシステムのパートナーや業界のフォーラムに積極的に参加していただきつつ、基盤技術のテストを続けられることをうれしく思っています。これらの活動はすべて、ともにウェブを前進させることが目的です。以下に掲載するのは、1 月と 10 月のお知らせ以降に発生した重要な更新情報です。

初期の結果とテスト可能な新提案

現在、5 種類のプライバシー サンドボックス提案がテスト可能であるか、まもなくテスト可能になります。これらは、詐欺を検知する、最適なコンテンツを提供する、企業が所有するドメインや関連ドメインをファーストパーティ扱いにする、広告を測定する、デフォルトでプライバシーが保護される形でブラウザ情報をリクエストするといった重要な領域に関連する内容です。実際、Federated Learning of Cohorts（FloC）アルゴリズムの初期のテストでは、プライバシーが保護される新しい広告ソリューションが Cookie ベースのアプローチと同じくらい効果的になり得ることが示されています。ユーザー、サイト運営者、広告主は、ウェブの将来にとって欠かせない存在ですが、この結果はこの 3 者すべてにとって朗報です。この作業を進めることができることが楽しみです。

もう 1 つの重要な領域はユーザー向けのコントロールです。中でも、ユーザーがコンテンツを自分に合わせて調整するか（しないか）を選びたい、そしてプライベートな情報をプライベートに保ちたいと考えるであろうことは明白です。4 月にリリースされる Chrome 90 には、プライバシー サンドボックス向けのコントロール（まずは単純なオンとオフ）を初めて追加する予定です。また、今後の Chrome リリースでは、オリジン トライアルの段階に入る提案の増加に合わせてコントロールを拡張し、エンドユーザーや業界からのフィードバックを受け取れるようにしたいと考えています。すべてのトライアルに関する更新情報は、こちらでご覧ください。

エコシステム全体を巻き込む

たいへんうれしいことに、Salesforce、White Ops、Yahoo! JAPAN などの企業が、Trust Tokens、First Party Sets、Conversion Measurement などの初期ソリューションのテストを始めています（または、その準備を進めています）。実際、パブリックな Chrome の試験運用機能にはすべてのデベロッパーがアクセスでき、web.dev には最新のガイドが掲載されているので、ぜひテストを行ってフィードバックを共有してください。このような形で参加していただくことで、さまざまな API が予想どおりに動作することを実際の環境で確認できます。そのため、参加するエコシステムが多ければ多いほどありがたいのです。

よりよいものを、ともに

ウェブのすばらしい点の 1 つは、全員による全員のためのものであることです。これは現存するプラットフォームの中でも格別な点であり、間違いなく讃えるべきことです。また、ウェブへの新技術の導入には複雑さとトレードオフがつきまとうので、力を合わせて慎重に対応しなければなりません。そのため、W3C などの業界のフォーラムを巻き込み続けて、プライバシー規制団体や、イギリス競争市場庁などの独立した機関と積極的な議論を重ねながら、オンライン プライバシーや業界、そして世界全体のための最適なアプローチを模索し、構築しようとしています。

現在のプラットフォームをこれまで構築し、これからも構築し続けるのは、ユーザー、プログラマー、広告主、コンテンツ制作者の皆さん（そして、その他多くの方々）です。ウェブのプライバシー強化のため、ぜひ力を合わせてまいりましょう。


Reviewed by Eiji Kitamura - Developer Relations Team

この記事はデベロッパー リレーションズ エンジニア、André Bandarra、プロダクト マネージャー、Chirag Desai による Chromium Blog の記事 "Better content sharing with Custom Tabs" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
カスタムタブは Chrome が導入したブラウザ機能で、現在では Android のほとんどの主要ブラウザでサポートされています。WebView を使わなくても、アプリでウェブ エクスペリエンスを細かく制御し、ネイティブ アプリとウェブ コンテンツの間のシームレスな画面遷移を実現できます。ブラウザを使っているときと同じように、ユーザーはカスタムタブに表示されたコンテンツを共有したいと考えることがよくあります。

カスタムタブはデフォルトで共有機能を提供しておらず、多くのアプリはユーザーがコンテンツを共有する方法をまったく提供していません。そのため、ユーザーはブラウザのオーバーフロー メニューから共有アクションを探さなければならず、ユーザー エクスペリエンスが低下します。この操作を行うと、ユーザーはアプリの外に移動してブラウザでリンクを開くことになるので、アプリのエンゲージメントも下がります。

Chrome 88 では、特定の状況で自動的にデフォルトの共有アクションを追加する実験を行っています。たとえば、アプリが独自のアクション ボタンを指定していない場合、トップバーにこのボタンを表示します。サイトで独自のトップバー アクション ボタンが指定されている場合は、デフォルトの共有アクションはオーバーフロー メニューに追加されます。

注意事項: これは Chrome の動作の変更です。他のブラウザにも同様の機能が追加されることを期待しています。

アプリで共有アイコンを表示しないようにする方法

Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Justin Schuh - Engineering Director, Marshall Vale - Product Manager による developer.chrome.com の記事 "Progress update on the Privacy Sandbox initiative" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

プライバシー サンドボックスの取り組みは、一連のプライバシー保護 API を提案することで、サードパーティ Cookie などのトラッキング メカニズムのないオープンウェブに貢献するビジネスモデルをサポートします。この取り組みは 2019 年に始まり、Chrome では昨年の 1 月と 10 月に最新の進捗状況を共有しました。

1 年間のインキュベーション期間を経た 2021 年はテストの 1 年間となり、ウェブのエコシステムが関与する機会が継続的に発生するでしょう。この投稿では、Privacy Sandbox API とその提案の状況について、最新情報をお届けします。

主なユースケースの進捗状況

サイトへの関連広告の表示

サイト運営者や広告主は、広告を含め、関連性が高くユーザーが興味を持つコンテンツを提供したいと考えています。現在のウェブでは、どのようなサイトやページにアクセスしたかを観察することでユーザーの興味を測ることが多く、これにはサードパーティ Cookie やデバイスのフィンガープリンティングなど、透過性が低く好ましくない仕組みが使われます。

3 月の Chrome リリース 89 で、Federated Learning of Cohorts API（FLoC）のオリジン トライアルを開始する予定です。FLoC は、同じような閲覧パターンを持つ人々を大きな集団に分類し、「大勢」の中の個人やブラウザの閲覧履歴を隠すことで、関連性の高いコンテンツや広告をユーザーに届ける新しい仕組みを提案します。現在 Google 広告は、FLoC アルゴリズムのテストから得た最新情報を共有しています。このテストによって、関連性の高い興味ベースの広告を提供するという点で、提案された API がサードパーティ Cookie と同様の効果を持つ可能性があることが示されました。

ファーストパーティ オーディエンスの形成

標準化コミュニティで盛んな議論を呼んだユースケースの 1 つが、どうすれば企業はオーディエンスを形成できるか、そしてどうすれば再マーケティングによって以前のユーザーをウェブサイトに呼び戻せるか、ということでした。昨年には、このユースケースに対応しつつ、他の提案と同じプライバシー保護を提供できる TURTLEDOVE が Chrome に導入されました。ウェブサイトは、入札や広告表示に関する情報を含む Interest Group を保存するようブラウザに依頼します。そして、この Interest Group に基づいて広告購入候補者によるオンデバイス入札が行われることになります。

Chrome の新しい FLEDGE（First "Locally-Executed Decision over Groups" Experiment）提案は、寄せられた多くの提案に含まれる新しいコンセプトを組み込んで TURTLEDOVE を拡張したものです。FLEDGE には、オンデバイス入札アルゴリズムで追加情報を利用する仕組みが含まれています。この追加情報は、この目的に限定して設計された、新しい信頼できるサーバーから提供されます。新しい信頼できるサーバーが利用できるようになる前に初期段階の実験をサポートするため、私たちは "Bring Your Own Server" モデルを提案しています。また、この最初の実験は、2021 年中に行いたいと考えています。

広告の効果の測定

マーケティング担当者が広告キャンペーンを行う場合、各広告を見たユーザー数と、それによって購入や登録などの行動に結びついたのかを理解することが重要です。

2020 年 9 月に、パブリック Chrome オリジン トライアルでテストを行うために、Event Conversion Measurement API を公開しました。これを使うと、マーケティング担当者はサードパーティ Cookie を使わずにコンバージョンを測定できます。ブラウザは、クリックとコンバージョンを記録し、匿名レポートを共有します。このテクノロジーは、将来的に「ビュースルー コンバージョン」（ユーザーが広告を見た後、時間をおいて行動する場合）もサポートする予定です。

マーケティング担当者が特定の広告キャンペーンの対象範囲を理解できるように、2020 年 4 月に Aggregate Measurement API を公開しました。この API は、複数のサイトにわたってユニーク ユーザーが広告を見た回数を測定する場合に役立ちます。
ここでも、個人の特定に利用される可能性があるデータが公開されることはありません。この仕組みは、ある集計しきい値を超えた場合に一度だけデータを報告することで実現します。Aggregate Measurement API は、今年の前半に公開してパブリック オリジン トライアルとしてテストすることを計画しています。

詐欺の防止

サイトやサイト運営者は、実際のユーザーと、スパム作成者や詐欺師、ボットを確実に見分けられなければなりません。昨年 7 月には、Trust Tokens API をテスト用に公開しました。この機能は、詐欺に対抗するため、ユーザーの身元を特定することなくユーザーの正当性を評価します。Chrome 89 では、新しいタイプの Trust Token 発行者をサポートするために、オリジン トライアルを導入します。これにより、ユーザーのプライバシーを守りつつ、モバイル デバイスによる詐欺の検出機能を向上させることができます。

Cookie のセキュリティ改善

2020 年には、現在のウェブ テクノロジーの安全性も向上しました。Chrome と Edge が SameSite Cookie ポリシーを採用し、近日中に Firefox も採用する予定です。このポリシーにより、デベロッパーがサイト間アクセスを必要とすることを明示しない限り、Cookie はファーストパーティとして扱われます。これは Android の Webview にも導入されており、Android S 以降をターゲットとしたアプリでは、"SameSite=Lax" がデフォルトの扱いとなる予定です。

今月の Chrome 88 リリースの新機能として、このポリシーを強化します。具体的には、接続の安全性のダウングレードを含むいくつかの形態のクロスサイト攻撃を防ぐため、SameSite の定義を変更します。これにより、同じホストのドメインの安全なバージョンと安全でないバージョン（https://site.example と http://site.example など）は、お互いにサードパーティと見なされるようになります。

実際のウェブサイトが複数のドメインや国コードドメイン（.com、co.uk、.de など）にまたがる場合があることは認識しています。Chrome 89 では、オリジン トライアルとして First Party Sets を導入する予定です。これにより、ドメイン所有者は関連するウェブドメインのグループが同じ組織に所属するものであることを明示的に宣言できるようになります。この宣言を行うと、対象のドメインはお互いに「同じパーティ」として扱われます。そのため、たとえばショッピング サイトが複数のドメインをまたぐ場合でも、ユーザーはログイン状態を維持できるようになります。トライアルへの登録はこちらから行ってください。

隠れたトラッキングの防止

さらに、既存の迷惑なトラッキング技術を防ぎ、問題にならない回避策を提供するため、Chrome の変更も進めています。

• 今後数週間のうちに、新しい User-Agent Client Hints（UA-CH）API の Chrome 安定版ロールアウトを終える予定です。これは、デフォルトでユーザーのブラウザに関する情報をすべて取得するのではなく、デベロッパーが特定の情報をリクエストできるようにするものです。将来的に Chrome は従来の User-Agent 文字列で提供する情報を制限する予定なので、デベロッパーには UA-CH API への移行を始めることを推奨します。現在の User-Agent 情報は、フィンガープリンティングに使われる可能性があります。

• 先週、Gnatcatcher を導入しました。これは、ユーザーのグループが同じプライベート化サーバーを通してトラフィックを送信できるようにする提案で、サイトのホストから IP アドレスを効果的に隠蔽します。また、Gnatcatcher は、不正利用の防止などの正当な目的で IP アドレスへのアクセスが必要なサイトには、認証や監査を行った上で、アクセスを保証します。

• 昨年 10 月にお知らせしたように、ユーザーがキャッシュの仕組みを使ってアクセスしたサイトを別のサイトから確認できる機能は、近日中にクローズする予定です。これによって元のリクエストを行ったサイトのみがキャッシュされたリソースにアクセスできることが保証され、クロスサイト トラッキングや検索攻撃などのセキュリティ攻撃のリスクを減らすことができます。この変更は、3 月の Chrome 89 からすべての Chrome ユーザーにロールアウトされる予定です。

関連情報

• プライバシー サンドボックスの詳細
• プライバシー サンドボックス
• プライバシー サンドボックスの取り組みに参加する方法
• 2021 年のプライバシー サンドボックス: ウェブのプライバシー強化のテスト

Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Florina Muntenescu による Android Developers - Medium の記事 "WorkManager — Kotlin APIs" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


WorkManager — Kotlin API

WorkManager は、非同期タスクのスケジュールを簡単に設定するための一連の API を提供します。これにより、アプリが閉じられた場合やデバイスが再起動した場合にも実行されることが期待されるタスクを即時実行または遅延実行できます。また、WorkManager は Kotlin ユーザーに最大級のコルーチンのサポートを提供します。この投稿では、WorkManager Codelab の内容に基づいて、WorkManager とコルーチンの基本について説明します。では早速始めましょう。

WorkManager の基本

ユーザーが特定の画面から離れたり、アプリがバックグラウンド状態になったり、デバイスが再起動したりしても実行を続ける必要があるタスクには、WorkManager ライブラリを使うことが推奨されています。一般的には、以下のようなタスクが考えられます。

• ログのアップロード、データのレポーティング
• 画像へのフィルタの適用、画像の保存
• ローカルデータとネットワークの定期的な同期

ユーザーが画面などの特定のスコープを離れたときに即時実行したタスクが終了する可能性がある場合は、直接 Kotlin コルーチンを使うことを推奨します。

WorkManager Codelab では、画像をぼかしてその結果をディスクに保存します。これを実現するために必要なことを確認しましょう。

まず、work-runtime-ktx 依存性を追加しました。

implementation "androidx.work:work-runtime-ktx:$work_version"

そして、独自の Worker クラスを実装します。ここに、バックグラウンドで実行する実際の作業に必要なコードを含めます。Worker クラスを拡張し、doWork() メソッドをオーバーライドします。これは一番重要なクラスなので、のちほど詳しく説明します。最初の実装は次のようになります。

次に、作業のリクエストを作成します。今回の場合は、作業を一度だけ行いたいので、OneTimeWorkRequest.Builder を使います。入力として、ぼかしたい画像の Uri を設定します。

Kotlin のヒント: 入力データを作成するために、workDataOf 関数を使うことができます。この関数は、データビルダーを作成し、キーと値のペアを格納してデータを作成します。

作業のスケジュールを設定して実行するには、WorkManager クラスを使います。その際に、実行するタスクと、タスクへの制約を指定できます。

Worker による作業の実行

Worker を使うと、WorkManager は自動的にバックグラウンド スレッドで Worker.doWork() を呼び出します。doWork() から返される Result は、WorkManager サービスに作業が成功したかどうかと、失敗した場合には作業を再試行すべきかどうかを通知します。

Worker.doWork() は同期呼び出しです。バックグラウンドの作業全体をブロックありで実行し、メソッドが終了するときには完了していることになります。doWork() で非同期 API を呼び出して Result を返すと、コールバックが正しく動作しない場合があります。

非同期作業を行いたい場合

もう少し複雑な例として、ぼかしをかけたすべてのファイルの Uri をデータベースに保存する場合を考えてみましょう。

これを実現するために、以下を作成しました。

• 単純な BlurredImage エンティティ
• 画像の挿入と取得を行う dao クラス
• データベース

実装はこちらをご覧ください。

Kotlin でデータベースへのデータの保存やネットワーク リクエストなどの非同期作業を行う必要がある場合は、CoroutineWorker の利用を推奨します。

CoroutineWorker を使うと、Kotlin コルーチンを使って非同期作業を行えます。

doWork() メソッドは suspend メソッドです。つまり、中断を伴う dao を簡単に呼び出すことができます。

デフォルトで、doWork() は Dispatchers.Default を使います。この動作は必要な Dispatcher でオーバーライドできます。今回は、既に Room が挿入作業を別の Dispatcher に移動させているので、これを行う必要はありません。詳しくは、Room Kotlin API の投稿をご覧ください。

ぜひ CoroutineWorker を使って、ユーザーがアプリを閉じても完了しなければならない非同期作業を実行してみてください。

WorkManager についてもっと詳しく知りたい方は、今後のシリーズで詳しく解説しますので、ご期待ください。それまでの間は、Codelab やドキュメントをご覧ください。

• WorkManager ドキュメント
• WorkManager を扱う Codelab
• 高度な WorkManager Codelab

Reviewed by Chiko Shimizu - Developer Relations team

この記事は Google Chrome、エンジニアリング ディレクター、Jochen Eisinger による Chromium Blog の記事 "Limiting Private API availability in Chromium" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Miguel Guevara による Android Developers Blog の記事 "How we’re helping developers with differential privacy" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google は、イノベーションとプライバシーは車の両輪だと考えています。その一環として2021 年 1 月、オンラインのユーザーの安全を確保するための私たちの取り組みについてブログでお知らせしました。その中では、差分プライバシー（ディファレンシャル・プライバシー / differential privacy ）などの先進的なプライバシー技術に言及しておりました。

毎年 1 月 28 日は、データ プライバシーの日です。そこで、それに合わせて、Google のプロダクトに差分プライバシー技術を適用し、この技術を世界のデベロッパーや企業に広めていこうという新しい取り組みをここに詳しく紹介させていただきます。この取り組みにより、個人情報を確実に保護しつつ、データや知見に広くアクセスできるようになります。 

差分プライバシーで中核プロダクトを強化する

差分プライバシーは高度な匿名化技術で、初めて Chrome に導入されたのは 7 年ほど前になります。そして現在では、Google マップや Google アシスタントなどのプロダクトに日々活用されています。昨年、世界が COVID-19 と闘う中、COVID-19 コミュニティ モビリティ レポート（英語）を公開しました。差分プライバシーを使っているこのレポートは、世界の公衆衛生当局、エコノミスト、政策立案者がコミュニティにとって重要な決定をする際に活用していますが、いかなる時点においても、個人を特定できる情報は利用できないことが保証されています。

Google Play Console では、今年中に差分プライバシーの手法を用いたアプリの新たな指標やベンチマークをデベロッパー向けに提供する予定です。この機能がリリースされると、デベロッパーは個人が特定または再特定できないことが保証される方法で、日々のアクティブ ユーザー数、アクティブ ユーザーあたりの収益など、アプリがどのくらいユーザーを惹きつけているかを表す指標に簡単にアクセスできるようになります。

このようなアプリの新たな指標に差分プライバシーを加えることで、デベロッパーに有用な知見を提供し、アプリの改善に役立ててもらうことができます。その一方で、ユーザーのプライバシーやデベロッパーの機密性が損なわれることはありません。今後は、差分プライバシーを使った指標を増やすことを計画しています。 

OpenMined と連携し差分プライバシーを広める 

Google のプロダクトにおけるプライバシー保護技術は進化を続けていますが、デベロッパーがこの技術を利用できるようにすることも重要です。そこで、2019 年に差分プライバシー ライブラリをオープンソース化し、世界中のデベロッパーが自由にアクセスして簡単にデプロイして活用できるようになりました。それ以降、たくさんのデベロッパーや研究者、団体が Google の差分プライバシー アルゴリズムを利用して、プライバシーが保護される方法で責任をもってデータを使い、新しい問題の解決に取り組んでいます。そのような企業の 1 つに、フランスの新興医療企業 Arkhn があります。Arkhn は、差分プライバシーによって複数の部門にまたがる病院のデータを安全な方法で収集、照会、分析できるようになり、それを活用して人工知能で医療業界に革命を起こすというミッションを掲げています。

Arkhn のようなデベロッパーのチームに、高度な差分プライバシー ライブラリを広く提供するため、　2021 年 1 月 29 日（現地時間 1 月 28 日）、OpenMined との新たなパートナーシップを結びましたのでお知らせします。

OpenMined は、プライバシー保護技術を研究し、その活用法を世界中に広めることに注力しているオープンソース デベロッパー グループです。Google は、今後 OpenMined と協力し、差分プライバシー ライブラリの Python デベロッパー専用のバージョンを開発する予定です。Python デベロッパーは、Google の差分プライバシー対応インフラストラクチャと同じ仕組みを活用することで、ワールドクラスのプライバシーを備えた他にはない新しい方法でデータを扱うことができます。

昨年と同様、デベロッパーが既存の差分プライバシー ライブラリをさらに簡単に使えるようにする作業も継続します。たとえば今月には、Google で日々何千件ものクエリに利用されている、新しい差分プライバシーに対応した SQL データベース クエリ言語拡張機能をオープンソース化しました。アナリストがこのようなクエリを活用すれば、ビジネスに関する知見を得たりプロダクトのトレンドを確認したりできます。これは、プライバシーが守られたデータ分析を広め、世界中のデータ サイエンティストが個人のプライバシーを保護および尊重しつつ、強力な洞察を得られるようにするための一歩です。 

機械学習を進展させる連携的アプローチ

2 年前、TensorFlow Privacy（GitHub）をローンチしました。TensorFlow Privacy はオープンソース ライブラリです。これを使うと、デベロッパーがプライバシーに配慮した機械学習モデルを簡単にトレーニングでき、研究者は TensorFlow Privacy を使ってより安全なプライバシーを保証し、機械学習の水準を高めることができます。

昨年は、このライブラリを拡張して TensorFlow 2 をサポートするとともに、Keras モデル インターフェースと TensorFlow の既製 Estimator の両方をサポートしました。また、ウォータールー大学の研究者と連携してパフォーマンスを向上させています。これにより、新しいリリースでは一般的なワークロードのトレーニングが 4 倍以上高速になりました。

さらに、プライバシーを考慮した機械学習のトレーニングはコストが高くなってしまい、現実的ではない可能性があることがわかっています。そこで、機械学習モデルはどの程度プライベートなのかを理解するための調査を開始し、昨年、それに役立つ仮想攻撃ライブラリをオープンソース化しました。このライブラリを使うと、機械学習モデルの全体的なプライバシーの保護状況を確認できます。

その後は、プリンストン大学やシンガポール国立大学の研究者と連携。ライブラリのスコープを拡張して生成モデルや非ニューラル ネットワーク モデルをテストする新機能を追加しています。

先日、スタンフォード大学医学部の研究者がこの機能をいくつかのモデルで試しました。そのテストから、モデルの中でのプライバシーに関する動作が明らかになりました。その中には、それ以前はできなかったことも含まれています。 

また、差分プライバシーと堅牢性のトレードオフに関する新しい研究を発表しました。これは、AI 倫理の中核にあるもう 1 つの特性である、プライバシーと安全性に関わることです。

健全なオープンソース エコシステムを育み、広げていく一方で、Google 製品を使うユーザーをアルゴリズムによって保護するために、Google は高度なプライバシー保護を行う取り組みに投資をしております。私たちは、世界中のあらゆる人がトップレベルなプライバシー保護を享受すべきだと強く確信しています。そのためにさまざまな組織と協力してそのミッションを果たしてまいります。