Quantcast
Channel: Google Developers Japan
Viewing all 2207 articles
Browse latest View live

INEVITABLE ja night 開催レポート - テックカンファレンスから見るテクノロジーの不可避な流れ(前編)

$
0
0
Google Cloud に代表されるクラウド技術の進化が引き起こすその先の世界を、機械学習、VR / AR、IoT などの領域で活躍されている方々と一緒に議論するイベント「INEVITABLE ja night」。

2019 年 6 月 25 日に開催した第 9 回目は「デベロッパー カンファレンスから読み解くテクノロジーの不可避な流れ」がテーマでした。対談では、国内外のデベロッパー カンファレンスに数多く参加されている 及川卓也さん(Tably株式会社 代表取締役 Technology Enabler)をお迎えし、次々に登場する新しいテクノロジーがビジネスをどのように変えていくのか、その潮流について語っていただきました。


大型化するテックカンファレンス


小島:2019 年前半、海外では多くの IT 分野のカンファレンスが開催されました。Google 主催では、Cloud Next(サンフランシスコ)と Google I/O 、Facebook の F8、Apple の WWDC などがありました。プライベート カンファレンス以外ですと、SXSW、Game Developers Conference が 3 月に開催されました。この中で、今年、及川さんはどれに参加されましたか?

及川:Cloud Next と Google I/O、あとは F8 ですね。

小島:私は、Amazonの「re:MARS」という機械学習やロボティクスにフォーカスしたイベントに参加しました。今回初めての開催です。ここのところ特定のプラットフォーマーが多くのカンファレンスやるようになっていますよね。

及川:やはり、プラットフォーマーとしては、自分にロックインさせる、プラットフォーマーとしての支配力を高めたい思いがありますからね。しかし一方で、最近はそのプラットフォーマーに対しての風当たりが強いので、自社が保有する技術を公開して、自社だけではなく、本当の意味でのエコシステム、社会全体を良くしようという動きも出ています。議論の場を設けたり、自分たちのもっているノウハウや経験を公開する意味でカンファレンスも規模が大きくなっています。


小島:re:MARS は、Amazon が初めて開催したカンファレンスです。Amazon が実際にロボティクスや、機械学習、AI をどのように使っているかを知る良い機会となりました。Amazon GO の担当役員が公の場で話をするんですよ。こういうことをやらない会社だったので個人的には結構衝撃を受けました。(詳しくは、「火星(M・A・R・S)時代への不可避な流れを確信する -- Amazon re:MARS 2019 参戦記」)今、及川さんの話を聞いていて、デベロッパーに対して、自分たちが何をやっているかの話をすると、正しく世の中に伝わり、理解してもらえるのではないかと、ふと思いました。

及川:技術を駆使して作られた製品が、どのように世の中で使われているのかを理解する上で、その技術や製品を作っている人の顔が見えることは大事ではないかと思っています。すごい製品であることは理解していたとしても、誰が作っているかわからない、顔が見えないというのは・・・かつて、Amazon やマイクロソフトは営業やマーケティングの方は表に出てきていましたが、開発部隊が表に出てくることはあまりなかったと思います。そもそも人数が少なかったわけですが、それが最近になり公の場で話を聞く機会が増えてきました。利用者と同じ目線で話をすれば、それは人間同士、理解も深まるというものです。

小島::そういう人を見る場としてカンファレンスがあるというわけですね。

及川:エバンジェリストやアドボケイトという立場の方が最近いろいろな会社にいますよね。エバンジェリストというと先生に近くて、どちらかというと一方的に伝えるという立場ですね。しかし、後でお話しますが、そこはどちらかといえば双方向のコミュニケーションが大事になってきます。

小島:及川さんがツイートをするのは、この双方向のコミュニケーションを大事にされているからですね。

及川:海外のカンファレンスに参加する場合、多くは到着した翌日からの参加になるので、時差ボケもあって眠いんですよ。でも遠路はるばるやってきたのだから、寝てしまってはダメじゃ無いですか。そこで、眠気防止も兼ねてひたすらアウトプットし続けます。(「facebook 新サービス発表 f8まとめ (及川さんのツイート感謝!)」)。また、こうすると後で振り返るときに役に立つんですよね。このアウトプットを見ればすぐに思い出すこともできますしね。特に、F8 は日本からの参加者が少なかったので、結構いろいろな人に見てもらえましたね。



AI とプライバシーの不可避な流れ



小島:事前打合せで「プライバシーと AI 」が話題の一つにあがりました。及川さん、このお話をしていただけますか?

及川:F8 のキーノートでマーク ザッカーバーグが冒頭の 20 分ぐらいかけて、「Facebook はプライバシーを守ります。これが Facebook のネクストチャプターです」という、つまり企業姿勢を語りました。その後、開発プロセスをどう変えていくのか、個別のサービス、例えば、Messenger、WhatsApp、Instagram をどう進化させるかという話が続きました。

小島:結構具体的な話があったのですね。

及川:冒頭 20 分はポジショントークでしたが、その後は各製品の紹介の中にプライバシーの方針、「我々はこういうところでセキュリティーを強化しています」を語っていました。「サービスをこのように実装しています」とか「いつごろ展開予定です」とか、具体的な話でした。ここのところ、Facebook に対する風当たりが強いので真剣そのものでした。社長が出てきて 20 分喋ればどうにかなるだろうという感じではなく、事態を真摯に捉え、「我々はやり方をこう変えます」という中身を持って話しているという印象を強く感じました。

小島:F8 の後、Google I/O でしたね。

及川:Google I/O 初日の午前にキーノートがあり、登壇した スンダー ピチャイからもGoogle はプライバシーを重視しますという発言がありました。また、いくつかのセッションで、「People+AI」というガイドブックを紹介していました。Google がこれまで経験してきたものをベストプラクティスとしてをまとめたものです。ユーザーを中心とした AI 製品を開発する際に役立つ情報で、どういう風に製品作りを進めていけばいいかを整理して公開しています。

小島:Facebook と Google というプラットフォーマーの立ち位置の違いを反映している気がしますね。Facebook はサービス提供者そのもので、どのようにサービスを実装しているかに焦点を置いていますよね。一方、 Google は、自社のサービスを解放してその上に新しいサービスを作ってもらおうという立場なので、ガイドブックという形で知見を提供しているわけですね。

及川:Facebook の場合、取り組みの姿勢や取り組んでいるテーマに加えて、実際の技術についても触れています。例えば、フェイクニュース対策としてファクト チェックを強化しています。人を攻撃するような内容をいかに発見し、抑えるかという技術も開発しています。Google の場合、AI でいかに公正なものを追求していくかということをやっていて、技術的に細かいところは違いますが、目指しているところは Facebook と同じといえるでしょう。

ただ、小島さんが指摘された通り、Facebook はデベロッパー プラットフォームではないので、自分たちがやっていることを公開したとしても、せいぜいその成果はオープンソースでここ見てください、このライブラリ使えますよ、っていうことに過ぎません。一方、Google の場合にはガイドラインをプラットフォームの機能の一部として提供していくことができるので、そこはその立ち位置の違いはあるかなと思います。


小島:AI をテーマに取り上げると、その精度がどうなのか、学習するためにどの程度のデータがあればいいのか、どのモデリング手法を使えば良いのかといった、技術や手法が注目されがちですが、もうそこの議論ではなくて、それらを使って何をどう実装できるのか、そういうレベルですよね。さらに、できているものについては、現在の社会や利用者の期待値とどう折り合いをつけるのか、ここが AI の精度以上に求められていると感じています。

及川: とはいえ、実際には精度も非常に重要です。このガイドブックに関連するセッションは、結構多くあったのですが、過去、Google もいろいろな失敗もしていて、その失敗から学び、改善することをスピード感を持ってやってきました。決して失敗は悪いことではないんです。

小島:Amazon にも、Fail First という言葉があるくらいです。プラットフォーマーは、早く取り組むことで壁にも早くぶち当たる、そこからどう学んで、次に進むか、この一連の行動が非常に早いですよね。

及川:一つ面白い例があります。Google 翻訳をご存知の方は多いと思いますが、画面の左側に元言語があって、右側に翻訳した文が出てきます。あるトルコ語の文章を英語に翻訳した時に、”he is a doctor, she is a nurse”と出てきたんです。でも、これって実は誤りなんですよね。なぜかというと、トルコ語には第三人称単数に性別がないのです。

小島:つまり、原文からは he なのか she なのかは本当はわからないということですね。

及川:そうなんです。そもそも、性別不明なものを主語としているにも関わらず、doctor だったら男性で nurse だったら女性だ、というバイアスがかかってしまっているんです。これはアルゴリズムだけの問題ではもちろんありません。セッションの中で具体的に説明していましたが、機械学習のパイプライン中の、データセット、アノテーション、アルゴリズム、モデル作りの際のパラメータ設定など、すべてのステージでヒューマンバイアスが入り込むリスクがあるのです。

小島:だって、もともとバイアスかかったデータを食べていますから、そうなるってことですね。

及川:なので、こう言った場合、
男性医師を示すデータが多かったとしても、そこに性別を入れないためにはどうすればいいか?というところで彼らはテクニックを生み出したんです。そういったノウハウを公開してくれているんですね。

(注:前述の例についての Google 翻訳の結果

小島:データをちゃんと見るだけじゃなくて、バイアスを取り除くようなアプローチも結構必要だ、ということなんですね。


AI と機械学習の関係を正しく理解する


小島:海外カンファレンスでは AI が主要テーマであることは間違いありません。今回参加した、re:MARS も例外ではありません。そこで印象に残ったことがいくつかあります。一つは、AI と機械学習をはっきり区別して考えるべきだという点です。機械学習はモデルを作るテクノロジーであって、そのモデルをどう使ってインテリジェンスな振る舞いに実装するかが AI だということです。もう一つが AI が目指すところです。iRobot の CEO の説明が非常にわかりやすかったです。AI は必ずしもヒューマン インテリジェンスではなくて良いという主張です。自動的な振る舞い、レスポンシブな応答、複数のAIでの協調など、少しずつ複雑な振る舞いになっていくわけですが、これがインテリジェンスである必要はないということです。日本では、AI を議論するとどうしてもシンギュラリティーが話題となり、「人間の仕事が奪われてしまう」という方向に流れてしまいますが、そこではないということですね。

ところで、機械学習とAIに対するこの見方について、及川さんはどう思われますか?


及川:おっしゃるとおり、AI が機械学習とイコールというわけではありません。しかし、最近は、AI と機械学習がほぼ同じものとして語られてしまっているケースがあります。これは改めるべきです。先ほどのレイヤーで分ける方法でも、包含関係で分ける方法もあるでしょう。いずれにせよ、技術を話すときは区別したほうが良いでしょう。

小島:インテリジェンスな振る舞いを分けていくとわかりやすくて、AI を人間の置き換えで見てしまうと混乱するのですが、因数分解するとこんな感じでその機械学習とか AI とか見られるのかなと思いますこの辺も読み取っていくといいんじゃないでしょうかと思います。

注目のテクノロジー エリア


小島:では次に移りましょう。及川さんの視座を借りて、これは気にかけておいた方が良いというテクノロジーを聞いてみたいと思います。今日は冒頭で AI について話しました。他に気になっているものは何でしょうか?


及川:ID、FinTech に含まれるペイメント系が気になりますね。いずれもインフラといって良いものです。Apple ID や Apple Pay の動きは非常に気になっています。

小島:実体経済がデジタル化すると、あなたは誰ですかっていうことと、支払いはちゃんとできますかが絶対的に必要ですね。もはやデジタルの中で決済することが主流になりつつありますし。

及川:サイバーフィジカル システムという、リアルとネットの融合はいろいろなところで進んでいます。Apple IDしかり、Apple Pay しかり。デジタルの世界の中だけではありません。リアル店舗でも使えます。

小島:そうすると、Google アカウントと Google Pay がセットになっているのも同じような文脈ですね。これら 2 つが入ってこないとなかなか難しい。Amazon はもともと e コマースからスタートしているから ID と決済を紐づけています。

及川:ウェブの世界でも WebAuthn と Web Payments がありますね。

小島:ロボティクスはどうですか。

及川:Amazon はロボティックス・チャレンジを開催していて日本の大学や研究機関も数多く参加してますよね。産業界ではロボティックスが、今後ますます発展することは当然ですが、一方、コンシューマー向けのロボティクスはどうかというと、お掃除ロボット以外にこれといったものが出ておらず、日本人が好きなヒューマノイドみたいなものがいつ日本に普及するのか、そもそも普及する必要性あるのか、そういう印象です。

小島:確かに日本の工場ラインにあるロボットって非常に高機能・高性能ですよね。Single purpose ではすごく強いけれど、汎用目的ではまだ開発段階ですね。お掃除ロボットは日本から最初に出ても良かった気がするのですが、実際は iRobot が初めてですよね。コンシューマーで使われるテクノロジーはものすごいスピードで進化しています。re:MARS でも iRobot CEO がかなり深い話をして、お掃除ロボットの会社の CEO とは思えないほど技術の詳しい話をするんですよね。ああいうのはやっぱり人々の生活で民生で鍛えられてかなり進化が進んでいるなって感じがします。

及川:昨年の Google I/O では話題になっていたけれど、今年は耳にしなかったものも、気になるといえば気になりましたね。Android Things とかどうなってしまったのかなーって。

小島:それは懇親会のネタとしましょう(笑)

AI と組み合わせると面白いことは何か


小島:事前のお話で、AI と組み合わせて考えるべきことを 3 つほどあげていただきました。


  • VUI
  • エッジデバイス
  • アクセプタンス


3 つめは、テクノロジーというより、社会にどう受容されるかという話ですが、ユースケースとしてインパクトも大きいということで上げていただきました。これらについて、少しお話いただけますか?

及川:VUI は、Alexa や Google Home といったスマートスピーカーに関わるテクノロジーです。ただ、ここで言う VUI はもっと広範なものを意味しています。例えば、コンピューターの操作において、横長のディスプレイ、キーボード、マウスからはまだまだ離れられません。スマートフォンの登場によって多少変わりましたが、根本的なところは変わりはありません。

小島:ソフトウェアキーボードというものがありますね。

及川:本来、コミュニケーションの際に音声や映像が主体ですから、実はもっと便利になるべきだと思っています。

小島:ボイスユーザ インターフェースの部分がですか?

及川:そうです。音声認識技術やテキストから音声を合成する技術を見ると、そのパフォーマンスも品質もとんでもないレベルに達しています。マイクロソフトの de:code のキーノートで、HoloLens のデモがありました。ご覧になった方もいるかもしれません。HoloLens の開発者であるキップマン氏と彼のホログラムが我々には見えています。AI を使って、彼が話している英語を文字にし、リアルタイムで翻訳してTTS(テキスト・トゥー・スピーチ)の技術で日本語を喋らせるというデモを披露しました。リアルタイムでやったんですよ。

小島:あれ結構精度が良くてみんな驚いたみたいですね。

及川:とんでもなかったです、あれは、まさに「ほんやくコンニャク」でしたね。

小島:今、笑われた方は世代がわかりますね。

及川:ドラえもんなので、どの世代でも通じるはずですね。

そして、その次のエッジデバイスに関係するのですが、Facebook は Portal というデバイスを開発しています。Messenger や WhatsApp で友人や家族とおしゃべりできるというものです。スマートカメラが話者を特定して、トラッキングしズームにも対応します。開発中のものを実際に見たのですが、2 年前はクラウド側で処理を行っていたんですよね。

小島:だから、遅延がちょっとある。

及川:そうなんです。オブジェクト ディテクションをすると映像がガタガタなんです。これでは使いものになりません。そこで、エッジ側で処理をすることでようやく商品となりました。Google I/O のキーノートのステージでデモされた Google アシスタントもパフォーマンスが良いと評判ですが、これも同様にエッジ側で処理しているからですね。このエッジデバイス、オフラインで動くところが、音声や映像のリアルタイム処理につながっていくわけです。

小島:AI と VUI とエッジデバイス。これらを重ねたエリアにはさまざまなユースケースがあるわけですね。できることがすごく増えるわけだから、この上でいろんなサービスとかユースケースを組んでいくと、今までなかったものを提供できますね。

及川:製品デザインも変わるでしょう。特に映像ですね。今まで目に見える視覚情報が中心でしたが、ユーザー体験に音声が加わるので、Conversation designというものが必要になってきます。会話をどうスムーズに流すかということです。Google のデザインスプリントでも、このあたりのデザインについて触れていますね。

小島:技術だけでなく、デザイン手法もセットに提供されないといけないということですね。

及川:Conversation design では、人と機械の間でスムーズな会話を実現するにはどういうパターンがあるかを考えるわけですが、ここで会話が脱線したらどうなるかも含めて、全部のフローを考えるんですよ。例えば、小島さんと私が背中合わせ(つまりお互いを見ない状態)で何かをしようとしたときに、片方が質問を行い、他方はそれに答えて、また質問し、それに答えるというように、一方がロボットになりきって会話を進めて行くわけです。

小島:いわゆるチューリング テストみたいなものですよね。

及川:そうこうするうちに、すごいアシスタントができるわけですが、でもふと思ったんですよね。なぜ我々はこの努力を人間同士の会話に対してやらないのかと。Conversation design をうまく使えば、人と人とのコミュニケーションの質も上がるかもしれません。

小島:人と話しても通じないけれど、AI とだったらきちんとした会話になるということですね。一定の品質を持つモデルがもしできたとすれば、それをコピーして使えば良いので、いろいろなところでサービスの品質も向上しますね。

及川:それが、アクセプタンスです。人よりも機械の方が話しやすいことはありますね。

私は電話があまり得意ではないので、例えば、サービスセンターに電話をかけるのは嫌なんですよ。多少遅くても、メールやチャットの方が良いと思っています。電話が良いのか、あるいはメールやチャットが良いのか、人それぞれですが、選べるということが重要ですね。また、徐々に機械の方が好ましいことも増えてきています。きちんとデザインし、使ってもらえるようにすることが、新しいテクノロジーが社会に受容されていく上で必要です。

小島:アクセプタンスは、テクノロジーを使って何かを実装したときにすごく大事になるってことですよね。

及川:極端なこと言うと、AI によって予測精度がものすごく高くなったとしても、その高い予測精度をいきなり出したことで人を不安に陥れるのであればそれはやるべきではありません。

小島:Google Duplex も AI が会話しますって初めに宣言しないといけません。それが自然っていうことですね。サービス提供者はどうやってコンセンサスを利用者から得るかもしっかり考えるべきですね。


(後編に続く)


Posted by Takuo Suzuki - Developer Relations Team

INEVITABLE ja night 開催レポート - テックカンファレンスから見るテクノロジーの不可避な流れ(後編)

$
0
0
Google Cloud に代表されるクラウド技術の進化が引き起こすその先の世界を、機械学習、VR / AR、IoT などの領域で活躍されている方々と一緒に議論するイベント「INEVITABLE ja night」。

2019 年 6 月 25 日に開催した第 9 回目は「デベロッパーカンファレンスから読み解くテクノロジーの不可避な流れ」がテーマでした。対談では、国内外のデベロッパーカンファレンスに数多く参加されている 及川卓也さん(Tably 株式会社 代表取締役 Technology Enabler)をお迎えし、次々に登場する新しいテクノロジーがビジネスをどのように変えていくのか、その潮流について語っていただきました。後編では、海外と日本のカンファレンスの違いを中心に語っていただきました(前編はこちら)。



海外と日本のカンファレンスの違い


小島:ちょっと話題を変えて、海外と日本のカンファレンスの違いをお聞きしたいと思います。日本のカンファレンスの印象はいかがですか?海外のカンファレンスと比べて、日本のカンファレンスはここが大きく違うという点はどこにあるでしょうか?

及川:コミュニティに関連するものは結構出ているのですが、企業が主催するプライベートカンファレンスへの参加は少ないです。過去、マイクロソフトの開発者イベント「 de:code 」に参加したことはあります。コミュニティ系のものも企業主催のものも、私の印象としては、参加者が受け身に見えてしまうんですよね。

小島:セッションを聴きに来ている、表現はさておき、先生と生徒みたいな関係ってことですか?

及川:そうです。海外のカンファレンスでは、会場の中央付近にマイクスタンドがあって、質問をしたい人はそこに並んで、講演者が順番に質問を受けていくんです。ずらっと並ぶんですよね。例えば、40 分のセッションで 20 分で講演が終わると、残り 20 分間はずっと質疑応答ということはよくあることです。最近の Google I/O や Cloud Next では、会場で質問を受けるというよりは、オンラインで受けるシステムに変わっていますが。

しかし、日本では参加者が大勢の前で質問をすることは稀ですよね。また、講演者に挨拶にいったり名刺交換をする人はたくさんいますが、質問もコメントもしない方が多いじゃないですか。こういう点が受け身と感じているところです。

小島:受け身な姿勢だと、どんな点がまずいのでしょうか? de:code を例にすれば、本国(US)で発表されたことを日本語化してきちんと伝えているわけですよね。

及川:そもそもコンテンツというのは壇上から講演者が参加者に対して一方的に与えるものでは無くて、例えば、参加者からの質問もコンテンツを作る上で非常に重要なんです。その質問は質問者以外の人にとっても意味がある場合がありますからね。講演が終わって個別に質問する人は、これは自分だけが聞きたかったことだと思い込んでいるかもしれませんが、多く場合、他の人にも参考になるんです。つまり、コンテンツは主催者と参加者双方で作っていくものなんです。また、話す側からすると受け身の姿勢の方と積極的に参加しようとされている方では、こちらへの熱意が全然違いますよね。

小島:受け身姿勢の方にはなんかパワーが吸い取られている感じするんですよね。

及川:腕組みをして機嫌が悪そうな顔をして、講演者を睨んでいるような人っているじゃないですか。そういう方が相手だと、こちらもできるだけ早く終わりたいな、言いたいことだけ言ってさっさと終わりにしようという気持ちになってしまうわけです。

小島:聴衆者の振る舞いで、こちらの引き出しの使い方も変わるということですね。

及川:私も小島さんもこういう場で話をして緊張するタイプではないですが、でも緊張してる人はできるだけその緊張を緩和させてあげる方がいいんですよ。つまんない冗談でも笑う、これとても大事です。自分が同意できることに対しては積極的にうなずくことも大事ですね。

小島:うなずいてくれるとテンポがよくなるんですよね。

及川:話す側からはこうした反応が全て見えるので、話す内容を変えることもあります。講演に慣れている人は、どうもこれは通じていないなと思ったら説明を補足しますし、どうやらわかってるなと感じたら割愛もします。聴衆側が積極的に参加することで、そのセッションの内容は深まっていくと思うんですよ。日本のカンファレンスではそこが少し足りないかなという印象です。

小島:日本のカンファレンスのあり方と言うよりもオーディエンスの方がもうちょっと変わったほうがいい、もっと引き出せるものがあるんじゃないかということですね。

及川:それから、外資系企業の例ですけど、本国では参加費が有料、でも日本では無料というところが多いですよね。

小島:無料にすると、本社(US)から降りてくる目標値を達成しやすいということもあります。もちろん、有料化した方がいろいろな面で質は高くなるだろうという期待はあるのですが、二の足を踏んでしまうんですよね。

及川:その点は理解できるのですが、先程話した参加者が受け身になりがちというところに通じるものがあるのではないでしょうか。お金を払ったら元を取ろうと思いますよね。参加費を会社が払ったか、自腹かに関わらず、私だったら、払った分を絶対に取り戻してやろうと思うわけです。そこできちんと吸収しようとね。すると講演を聞く姿勢も変わってきます。すべてが無料という状況はどうかなあと思いますね。

小島:自分ゴト化するときに有料カンファレンスって実は大事なことかもしれないですね。質問しやすい雰囲気作りは参加者の人にその気持ちがないとなかなか成り立たないですよね。

及川:今の日本では、有料化が難しくなってきていますね。これに限らずコンテンツにお金を払う習慣がいつしか失われた気がします。

小島:テクノロジー知識のデフレ化が進んでいると。

及川:そう思います。経済回さないと。お金は払う。お金を払ったら取り戻しましょう。その分みんな稼げばいいんじゃないか、と思うところもあります。このままデフレが続くとコンテンツの質も下がるのではないかと危惧しています。

なぜカンファレンスに参加するのか



小島:どうしたら及川さんのように視座の高いテーブルの上から物が見えるようになるのでしょうか。ヒントをいただけますか。

及川:私の視座が高いかどうか、自分ではよくわからないので、使えるところだけ使ってもらえればよいのですが。

そもそも、国内外のカンファレンスに自らの足を運ぶ目的はコンテンツだけではありません。コンテンツだけなら、たとえば、Google I/O はライブ配信で見れますし、数時間後にはほぼすべてのセッションの動画が YouTube に上がっています。F8 も 1 週間後にはセッション動画が上がっていました。後から見られれば充分なんです。しかし、その場にいることが大切です。私と同じような方、もしくは私よりも若くて優秀な Google テクノロジを使うエンジニアがそこに集まって、そのコンテンツを聞いたときにどう反応しているか、 ここでみんなが熱狂しているとか。また逆に、会場全体がなんとなくつまらない雰囲気で、ステージから「今日は皆これあげるよー」の後、「おー」と会場が盛り上がったりすると、今日は自分としては興味をそそられる内容じゃなかったけれど、実はみんな同じことを思っていたんだとか、そういうことを知りたいわけです。その場にいなければ、わからないことはたくさんあります。

参加者の意見をそこで聞けるというのもありますね。このように、行かないとわからないところもあり、だから時間作って参加しようという気持ちになるのです。

小島:全員が参加できるわけではないので、参加したらやったほうが良いことは何でしょうか?

及川:参加した人は、ハッシュタグをつけてツイートすることですね。つまり、アウトプットです。人間はアウトプットしないと成長できないというのが私の信条です。

小島:そこは共感できます。たくさんインプットをもらった後、アウトプットしようかということになりがちですが、この状態では絶対にアウトプットはできないと思っています。まずは、アウトプットして、その反応を見てから、次のインプットを行い、またアウトプットする・・・この方が絶対良いですよね。

及川:マラソンにしても水泳にしても吐いてから吸うんですよね。吐かないと吸えないわけです。最初に何をするかはさておいて、アウトプットの場を作ってしまい、継続的にアウトプットしていくようにすると嫌でもインプットをすることになります。

小島:そうですね。僕はよく発表すると10 倍リターンありますよという話をします。アウトプットするというのは自己紹介のようなものですから、周りに認知されるわけです。後のネットワーキングが非常に楽になります。

個々の技術トレンドを知ることも重要ですが、もし、その場に行くことができるならば、そこでのインプットは必ずアウトプットするべきです。そしてまたインプットして、アウトプットする。この連鎖を続けることでいろいろな事が見えてきます。

及川:少なくとも、アウトプットしないとインプットできません。もし、アウトプット先が無い場合、インプットしたとしてもそのインプットの質は落ちると思うんですね。質問することを前提に人の話を聞くと、全然違うんですよ。質問しようと思っていたことが、先に解説されてしまっても良い。、そうしたら他の質問を考えるだけで、インプットの質があがると思います。

小島:ありがとうございます。少し時間もあるので、会場から質問をを受けたいと思います。

Q&A - どんなカンファレンスに参加しますか?



質問者:どういう基準で行くカンファレンスを決めていますか?

及川:門外漢のカンファレンスですと、やはりインプットもなかなか難しいですね。
そこで、少なくとも自分がある程度の活動している分野を選びます。キーとなるテーマを決めて、事前に理解した上で参加するかしないかを判断します。

小島:例えば、AI に興味を持ったときは、AI 軸でいくつかのカンファレンスで見ようとか、吸収しやすとか、アウトプットのしやすさという観点もありますよね。

及川:私の場合、Google のテクノロジーを長年見ているので、定点観測ができます。Cloud Next、Google I/O、年によっては Chrome Dev Summit にも参加します。そうすると同じ技術テーマであっても、内容がどう変わったかがわかります。「Google」という会社に絞っても良いですし、気になっている技術テーマがあれば、それを取り上げている企業イベントに参加するのもありです。テクノロジーではなくて、マーケット系のイベントでもあるでしょう。また、こうした興味・関心と少し違うところを狙って、カバレッジを広げていくことも大切です。

小島:わりと大きめの会社が初めて開催するイベントは狙い目です。イベントの企画、運営、稟議を通すことに関わってきた経験から申し上げると、初回というのが企画の趣旨、コンセプトに一番忠実で、しかも背伸びをするんですよね。持っているカード全部切ってしまうことが多いので、大変お得です。どうやらこの会社が何か新しいカンファレンスを開催するらしい、面白そうだと思ったら、ぜひ参加してみましょう。

Q&A - 面白かったコンテンツは?


質問者:これは面白かったというコンテンツを教えてください。私個人は、エストニアで行われたスタートアップイベントで、投資家が自らをアピールしそれを起業家が審査するというものが面白かったです。

小島:要は生徒が先生を審査するというものですね。私が面白いと思った最近のイベントは re:MARS です。この MARS を火星(MARS)にかけて、ステージでは『オデッセイ』(原題: The Martian)のマットデイモンが登場と思いきや、実はそこにはアイアンマンのロバート・ダウニー・Jr. が登場。お前はマット・デイモンの代役だと散々コケにされながらも、映画の中で、アイアンマンと相棒ジャービス(J.A.R.V.I.S)が会話しているように、ステージでは Alexa とロバート・ダウニー・Jr. が会話をはじめます。テックカンファレンスの文脈でその会話は続くわけですが、それすごく豪華だなと思いました。こうしたエンターテイメントは日本ではなかなか実現できないことです。アメリカの超一線級を連れてくるというのはなんか振り切っていていいなと思いました。

及川:ライブコーティングは面白いコンテンツですね。Google I/O でも、ここ数年やっています。たとえば、Firebase を使ったり、Android だったり、ウェブだったり。タイムキーパーもいて、解説しながらライブコーディングが進行し、しかも結構ガチに競い合っていて、迫力を感じます。


Q&A - 海外と日本のコンテンツの違いは?


質問者:海外と日本でコンテンツに違いはあるのでしょうか?お話にもあったように、日本は無料のカンファレンスが多くて、万人受けする当たり障りのないものが多いイメージがあります。

及川:Cloud Next Tokyo に参加したことが無いので、単純比較はできないですが、米国で開催された Cloud Next と似ているところも、違うところもありますね。開催規模も対象者も違いますからね。

また、講演者がその製品の開発者自身が喋るかどうかという点に違いがあります。日本法人の社員がその製品について十分に理解して話をしたとしても、そこは開発者ではないので内容に違いが出てくるのは仕方ないことかもしれません。なので、開発した当事者の話を聞けるというはとても貴重なことです。

たとえば、今年の Cloud Next Tokyo には、ウルス ヘルツルが来日します。彼は、Google の 8 番目の社員で「The Datacenter as a Computer」の著者の一人です。

なぜ、こういう人が来日するかといえば、マーケットが大きいからなんです。しかし、日本は少子化もあり今後マーケットは小さくなると言われています。今年は来日したけれど、来年は来るのか、いやそもそもイベントが中止になる可能性も否定できません。

そこで、参加者の皆さんは、イベントの主催者、運営者に対してフィードバックを行い、そのイベントの価値をきちんと示していかないと、次はアジアの他の国に行ってしまいます。先程申し上げたように、できるだけ皆さん積極的に参加して、そこできちっと価値を生み出して頂きたいと思います。

さらには、同時通訳無しで英語のコンテンツをそのまま利用できる状況ができれば、もっと良いセッションを組むことができます。運営側にとってもメリットがありますね。英語のコンテンツを聞けるようになるといいんじゃないかなと思いますね。

小島:あと、聴衆者のレベルにあわせたコンテンツの提供ですね。海外のカンファレンスでは初心者向けは 101、中級レベルだとこれこれ、というようにどのレベルの人向けかを明確にしています。ご質問にもあったように、日本では比較的ジェネラルな内容にする傾向があるようです。イベント主催者・運営者側により深い内容を求めることをみなさんが積極的に行っていけば、おのずと変わってくるんじゃないでしょうか。カンファレンスは参加者とともに育てていけば、いろいろなことが変わると思います。

ということで、時間がいっぱいいっぱいになってしまいましたので以上で終了となります。ありがとうございました!



Posted by Takuo Suzuki - Developer Relations Team

Google Cloud Summit in 大阪 開催のご案内と、コンテンツのご紹介

$
0
0



来たる 2019 年 9 月 25 日 (水) に、クラウドの最先端を体験できる地域特化型イベント Google Cloud Summit ’19 を、昨年に引き続き大阪で開催いたします。Google Cloud Summit は、これまで世界 20 か所以上の国と地域で開催されているグローバル イベントです。

基調講演、ブレイクアウトセッション

午前中に開催する基調講演では、海外からの Google スピーカーも来日し、Google Cloud の最新技術やメッセージをお伝えします。

午後に開催するブレイクアウト セッションでは、データ分析や機械学習、セキュリティなど、Google Cloud Platform (GCP) や G Suite の活用を紹介する15 のセッションをお届けします。実際に Google Cloud 製品を活用されている関西の企業様に事例をご紹介いただくセッションもご用意しております。特に以下に紹介した 2 セッションは、GCP 関連のおすすめセッションです。

◆ GCP の基礎を学びたい方 ◆
17:30–18:10  Track 2-5
GCP ではじめよう!クラウドネイティブアプリの作り方
クラウドの利用が一般的になりつつある昨今、アプリケーション自体もクラウドが提供するサービスを最大限活用できるモデルにシフトすることで、より変化に強くアジリティの高いシステムを作ることが可能になりました。本セッションでは GCP が提供する Google Kubernetes Engine や Cloud Run 等を利用してどのようにクラウドネイティブアプリを構築するのかデモを交えながら説明します。

◆ GCP の深い技術の活用に興味のある方 ◆
16:20–17:00 Track 3-4
BigQuery ML と AutoML Tables ではじめるスケーラブル データサイエンス
企業のデータの大部分は構造化されたテーブルに格納されており、これらは最もミッション クリティカルなビジネス上の課題に取り組むために不可欠なものです。このセッションでは、機械学習や AI のリソースが限られた環境でも、BigQuery ML と AutoML を活用して ML モデルを高速かつ自動的に構築および展開する方法を学びます。

その他もセッションページにて、ぜひ詳細をご確認ください。なお、各セッションは定員に達し次第、登録を締め切らせていただきます。気になるセッションがございましたら、お早めにご登録ください。

Expo

展示エリア EXPO では、最新のクラウド技術を体験できる Google Cloud のデモブースと、クラウドを使って独自のサービスを展開するスポンサー企業様のブース、合わせて 20 ブースをご用意しています。
こちらでは、Google Cloud Summit ’19 in 大阪 にて初お披露目されるものを含めた、3 ブースをピックアップしてご紹介します。

Factory Line Analytics
< 初公開 > 工場の生産ラインに見立てたデモです。生産ラインでの AI を使った効率化がどのよう行われているかをお見せすると共に GCP を活用すると、ML モデルを簡単に開発できたり、セキュリティを高められることを、学ぶことができます。

SAP on GCP
Google Cloud が完全仮想インフラストラクチャを使用して、どのように SAP を実行できるかを学ぶことができます。

Data Warehouse リアルタイム データ分析プラットフォーム
リアルタイムなデータ分析プラットフォームのデモをご紹介します。POS データの取り込みからデータ加工・監視までのシステム全体像と、店舗別・商品別の売上情報の可視化をご覧いただけます。また、BigQuery GIS による地理情報を使った分析や、BigQuery ML を活用して特定商品のクーポンをどの地域に配布することが効果的か?という機械学習の予測モデルを、BigQuery でどのように作成できるかご紹介します。


その他にも、Google Cloud の技術エキスパートに直接会って話すことができる Ask the Expert ブースや、入門レベル〜中級レベルまで、G Suite / GCP を分かりやすくご紹介するオープンステージ セッション、実際に GCP Console を使って、Google Cloud のサービスを体験できるハンズオンラボなどもあります。イベント登録をされている方であれば、どなたでも参加可能です。ぜひお気軽にお越しください。


IT の専門家、技術者、専門知識の量や関心のある分野を問わず、すべての方にとって価値のあるイベントになっています。Google Cloud Summit '19 に参加し、クラウドについて語り合いましょう。

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

イベント概要
イベント名: Google Summit ‘19 in 大阪
ウェブサイト:https://inthecloud.withgoogle.com/summit-osa-19/home.html
日程: 2019 年 9 月 25 日(水)
時間:開場 8:30  基調講演 9:30 〜 11:30 / セッション 12:50 〜 18:10
(**時間は変更になることがございます)

お問い合わせ先:
Google Cloud Summit in 大阪 運営事務局
SummitOsaka_info@google.com

Posted by Takuo Suzuki - Developer Relations Team

デフォルトで信頼できる Chrome 拡張機能

$
0
0
この記事は Chrome 拡張機能プロダクト マネージャー、James Wagner による Chromium Blog の記事 "Trustworthy Chrome Extensions, by default" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

実にすばらしいことに、私たちが Chrome 拡張機能システムをリリースしてから 10 年近くが経とうとしています。デベロッパー コミュニティの懸命な努力とイノベーションのおかげで、現在 Chrome ウェブストアには 18 万以上の拡張機能が公開されています。また、PC で Chrome を使っているユーザーの半数近くが、積極的に拡張機能を使って Chrome やウェブの体験をカスタマイズしています。

拡張機能チームの 2 つのミッションは、個々のユーザーのニーズや興味に合わせて Chrome の機能をカスタマイズできるようにすることと、デベロッパーが高機能で使いやすい拡張機能を作れるようにすることです。しかし最も重要なのは、インストールする拡張機能が安全でプライバシーを尊重し、パフォーマンスに優れていると、ユーザーが信頼できるようにすることです。ユーザーは常に、拡張機能の動作とアクセスするデータの範囲について、完全に把握できる必要があります。

ここしばらくの間にも、拡張機能のセキュリティ向上に向けてたくさんの対策を講じています。たとえば、プロセス外 iframeをリリースし、インライン インストールを廃止し、機械学習を利用して悪意のある拡張機能を検知およびブロックする機能を大幅に強化しました。今後はデフォルトですべての Chrome 拡張機能を信頼できるようにするために、さらに抜本的な変革を行う必要があります。

本日は、近日中に変更される点と、今後の計画についてお知らせします。

ユーザーによるホスト パーミッションの制御

Chrome 70 より、サイトのカスタムリストに対する拡張機能のホストアクセスを制限できます。具体的には、拡張機能が現在のページへのアクセス権を得るために、クリックが必要になるように設定できます。



ホスト パーミッションは、強力で独創的な拡張機能に幅広く利用されています。しかし、この機能は拡張機能がウェブサイトのデータを自動で読み取って変更することを許すので、悪意によるもの、意図しないものの両方において、さまざまな誤用につながっています。私たちのねらいは、拡張機能がいつサイトのデータにアクセスできるかについて、ユーザーの透明性と制御を向上させることです。今後のマイルストーンでも、ユーザビリティを改善しつつ、この目標を目指してユーザー エクスペリエンスの最適化を続けてまいります。自分の拡張機能でホスト パーミッションをリクエストしている方は、移行ガイドを確認し、できるだけ早くテストを始めることをお勧めします。

拡張機能のレビュー プロセスの変更

強力なパーミッションをリクエストする拡張機能に対しては、今後、追加コンプライアンス レビューを導入する予定です。また、リモートコードを実行する拡張機能については、継続的なモニタリングを通して緻密な監視を行います。レビュー時間をできるだけ短縮するには、拡張機能のパーミッションのスコープをできる限り狭くし、すべてのコードを拡張機能のパッケージに直接含める必要があります。

新しいコード リーダビリティ要件

本日より、Chrome ウェブストアは、コードが難読化された拡張機能を許可しなくなります。これには、拡張機能のパッケージ内のコードだけでなく、ウェブから取得されるすべての外部コードや外部リソースも含まれます。このポリシーは、提出されるすべての新しい拡張機能に即座に適用されます。コードが難読化されている既存の拡張機能は、今後 90 日間は引き続きアップデートを提出できます。ただし、ポリシーに準拠していない拡張機能は、1 月初旬に Chrome ウェブストアから削除されます。

現在、Chrome ウェブストアからブロックされた悪意のある拡張機能やポリシーに違反している拡張機能のうち、70% 以上に難読化されたコードが含まれています。同時に、難読化は主にコードの機能を隠すために使われるので、レビュー プロセスにかかる手間が大幅に増加します。前述のレビュー プロセスの変更を考慮し、コードの難読化は許可されなくなります。

また、JavaScript コードは常にユーザーのローカルマシン上で実行されるので、難読化を行ったとしても、本気を出したリバース エンジニアから独自のコードを守るには不十分です。さらに、難読化技術には、実行が遅くなる、ファイルのサイズやメモリ使用量が増加するなど、パフォーマンス的に大きな代償が伴います。

一方で、一般的なコード圧縮を行うと、コードのサイズが小さくなるので、通常はコードの実行速度が向上します。レビューもはるかに簡単です。そのため、以下の手法によるコード圧縮は引き続き許可されます。
  • 空白、改行、コードのコメント、ブロック区切り記号の削除
  • 変数名や関数名の短縮
  • JavaScript ファイル数の削減
コードを難読化した拡張機能をストアで公開している方は、改訂されたコンテンツ ポリシーと Google Developers に推奨されるコード圧縮技術を確認し、2019 年 1 月 1 日までにポリシーに準拠したバージョンを提出してください。

2 段階認証の必須化

2019 年には、Chrome ウェブストアのデベロッパー アカウントに 2 段階認証が義務付けられる予定です。拡張機能が人気になると、アカウントを乗っ取って拡張機能を盗み取ろうとする攻撃者が現れるかもしれません。2 段階認証を使うと、スマートフォンや物理セキュリティ キーによる第 2 の認証ステップが必須になるので、セキュリティが一段と向上します。できるだけ早く登録することを強くお勧めします。

さらにアカウントのセキュリティを強化したい方は、高度な保護機能プログラムの利用を検討してください。高度な保護機能は、Google の従業員と同じレベルのセキュリティを提供します。物理セキュリティ キーが必要になるので、フィッシング攻撃に対して特に強固な保護を実現します。

今後の予定: Manifest v3

2019 年には、拡張機能マニフェストの次のバージョンを導入する予定です。Manifest v3 では他にも、セキュリティ、プライバシー、パフォーマンス保証を強化することを目的としたプラットフォームの変更が行われる予定です。私たちは、すべてのデベロッパーを成功に導きたいと考えています。Manifest v3 では、安全でパフォーマンスのよい拡張機能を書くことは簡単で、安全でない、パフォーマンスが悪い拡張機能を書くのは難しくなければなりません。
Manifest v3 の主な目的は、以下のとおりです。
  • スコープを狭めた宣言的 API により、重要な機能を維持しつつ、不要に幅広いアクセス権を与えることなくパフォーマンスのよい実装をブラウザで実現できるようにする
  • 他にも使いやすい仕組みを導入し、ユーザーが拡張機能に付与したパーミッションを制御できるようにする
  • 新しいタイプのバックグラウンド プロセスとして Service Worker をサポートするなど、ウェブの新機能に合わせた最新機能を導入する
Manifest v3 への移行はできる限りスムーズに行いたいと考えており、そのためのロールアウト計画を慎重に検討中です。詳細については、近日中にお知らせします。

拡張機能によっては、本日お知らせした変更に対応するために、皆さんの作業が必要になるかもしれません。しかし、その結果は総合的に、すべてのユーザーやデベロッパーのために、そして長期的な Chrome 拡張機能エコシステムの健全性のために、労力を払う価値があります。私たちも、皆さんとともにこれらの変更点に対応してまいります。また、皆さんからのフィードバックもお待ちしています。質問やコメントがある方は、Chromium 拡張機能フォーラムからご連絡ください。

Reviewed by Eiji Kitamura - Developer Relations Team

Google 広告スクリプトが価格表示オプションをサポート

$
0
0
この記事は Tina Nguyen による Google Ads Developer Blog の記事 "Google Ads scripts now supports price extensions" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

本日より、Google 広告スクリプトで価格表示オプションがサポートされます。

価格表示オプションを使うと、ビジネスで提供する商品や価格に関する詳細情報をテキスト広告に追加できます。価格表示オプションは、アカウント、広告グループ、キャンペーンのレベルでサポートされます。

価格表示オプションの実装方法は、AdsApp.Extensionsドキュメントに記載されています。または、この表示オプション タイプを使ったサンプルコードを確認してください。

質問や懸念事項がある方は、遠慮なく Google 広告スクリプト フォーラムからご連絡ください。


Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team

集中配信の提供終了について

$
0
0
この記事は Adam Ohren による Google Ads Developer Blog の記事 "Sunsetting accelerated budget delivery" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

2019 年 10 月 1 日から、検索キャンペーン、ショッピング キャンペーン、共有予算では集中配信を利用できなくなります。これは、すべてのバージョンの AdWords API、Google Ads API、Google 広告スクリプトの予算に影響します。

Google 広告は、上記のタイプのすべての予算で ACCELERATED配信方法設定を無視するようになります。これらの予算を使用するキャンペーンは、自動的に標準配信を使用するように切り替わります。

: API またはスクリプトを使って作成した新しい予算は、デフォルトで共有されます。そのため、新しく作成した予算は STANDARDの動作となります。明示的に ACCELERATED配信の予算を作成するには、以下のすべての条件を満たす必要があります。
  • 予算の isExplicitlyShared項目が falseに設定されている
  • 予算の配信方法が ACCELERATEDに設定されている
  • 検索キャンペーンやショッピング キャンペーンに関連付けられていない
影響を受ける項目とメソッド

Google Ads APIcampaign_budget.delivery_method
AdWords APIBudget.BudgetDeliveryMethod
Google 広告スクリプトBudget.setDeliveryMethod()
Budget.getDeliveryMethod()

ACCELERATED配信方法が設定された API アプリケーションおよびスクリプトは動作し続け、予算に ACCELERATED項目を設定しようとしてもエラーは返されません。ただし、この設定は共有予算または検索キャンペーンやショッピング キャンペーンにアタッチされた予算に対しては何の効果もなく、既定の STANDARD配信となります。影響を受ける予算に対して AdWords API を実行した場合、Getまたは mutateのレスポンスは予算が STANDARDであることを示します。

影響を受ける予算およびキャンペーンのタイプでは、将来のバージョンの API やスクリプトから ACCELERATED配信方法が削除される可能性があります。今後の変更の詳細に関しては、別の投稿でお知らせします。

この変更に関して質問がある方は、遠慮なく AdWords API および Google Ads API フォーラムGoogle 広告スクリプト フォーラムからお知らせください。


Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team

Google Developer Groups(GDG)というコミュニティをご存知ですか?

$
0
0


GDGは、Google のテクノロジーに興味をもつデベロッパーの集まりです。Android、Chrome、Drive、Cloud などのプラットフォームから Google Cast API、Maps API などの製品 API まで幅広い内容を扱っています。

GDG は世界各地にあり、日本にも各地にチャプター(支部)があります。現在、日本には 10 のコミュニティがあり、定期的に集まって勉強会をしています。

「普段、一緒に勉強する仲間が欲しい」と思ったことがある方は、ぜひお近くの GDG チャプターを探してみてください。こちらのサイトから検索することができます。


詳しくはこちら → https://goo.gle/2XfrMPK
最寄りのチャプターを探すにはこちら→ https://goo.gle/2LnOIow


GDG は、海外で行われるイベントのライブ ビューイングをすることもあれば、デモやハンズオン、テックトーク、コードラボをすることもあり、内容や規模はそれぞれの GDG で異なります。

どの活動にも共通して言えるのは、GDG はデベロッパーと技術的なコンテンツに焦点を置いているということですが、技術力がなくても、GDG のコミュニティ活動に参加することができます。あくまでも主体は、コミュニティ活動となります。


GGD オーガナイザー インタビュー #1


今回、GDG の活動を紹介するために、現在日本で GDG として活動しているオーガナイザーやコミュニティのメンバーの方々に、インタビューにご協力いただきました。

第一回目は、今年 4 月に立ち上がった GDG Fukushima のメインオーガナイザーである清水俊之介さんです。

なお、このインタビューはシリーズ形式で、これから他の地域のオーガナイザーの方々の声も順にお届けしていきますので、次回以降も楽しみにお待ちいただければと思います。

それでは、清水さんとのインタビューをどうぞお楽しみください。





Q: 自己紹介をお願いします。
GDG Fukushima のオーガナイザーをしている清水俊之介です。3 年前くらいに株式会社 dottを立ち上げて、普段はそこの CTO として働いています。現在は主に企業さん向けのシステムを開発したり、そこに機械学習を持ち込むための実証実験などをやったりしています。

Q: GDG の活動に参加しようと思ったきっかけは何ですか?
僕は元々イタリアで絵画修復を学んでいたこともあって、自己紹介のときに「 Google に魂を売った絵画修復士」と言っているんですが、前提としてそれくらい Google のファンです。 
例えば TensorFlow や Angular など、レベルの高い技術をオープンにしてくれているアティテュードが好きで、仕事をしていてその恩恵を感じない日はないくらい、個人的にも会社としても利用しています。 
もともと東京で仕事をしていて、東京には GDG のような開発者コミュニティがあって、さまざまな最新情報を Google や GDE(Google Developer Experts) の方々から直接学べるようなチャンスがたくさんありました。当時 Google にいらしゃった及川卓也さんと Hack for Japan の活動でもご一緒させてもらったんですが、その中で見せて頂いた Google i/o のような世界は、皆さんが思うよりも僕には衝撃的なものだったんです。そのちょっと前まではコツコツと版画を洗ったりしていたわけなので(笑)。 
住む場所を福島の郡山市に移して、周りを見渡すと、そういった機会が大都市と比べると、少なすぎるなと感じました。
なので今まで僕がしてきてもらったように、今度はそれをこの福島で僕がやる番が回ってきたのかなと思って、GCPUG から始まって、2019 年の 4 月から GDG Fukushima を立ち上げました。共同オーガナイザーの中園はもともと仙台で GCPUG をやっていたり、GDG 石巻のトミーが dott に入ったことも背中を押してくれたと思います。

Q: GDG の活動に参加してみて、いかがですか?何か変わったことはありますか?何か面白いエピソードがあれば教えてください。
自分の中では面白いというか、驚いたような話なんですけど、GDG オーガナイザーの方々にはまだあまり面識がなくて、以前から知っていた GDG 石巻の 2 人くらいしか知らないなぁ、緊張するなぁと思っていたんですね。それで実際にオーガナイザーのコミュニケーション グループに入ってみると、会社のあるプロジェクトでご一緒している GDG Tokyo の方がいらっしゃって。ついこの間仕事上で会話したばかりだったので、ええ??まじで?って感じになっちゃいました(笑)。 
僕はメインのプロジェクト メンバーではなかったんですが、優秀な方だと聞いていたので腑に落ちたというか。同じコミュニティにいるというだけで、安心感とか信頼できる相手として身近に感じられるのは、こういう活動ならではの経験だと思います。
Q: コミュニティ活動をしていて、良かった点は何ですか?
今年に入って Google の佐藤一憲さんや GDE の足立さんあんざいさんに郡山に来て頂きました。Google などで開催されるイベントでは何百人も人が集まり、登壇される方々と直接話ができる機会はそんなに多くはないじゃないですか。郡山で開催しているイベントは参加者が今は多くて 30 人を超える程度。だから懇親会で来場してくれた人が直接その分野のエキスパートとディスカッションをしているのを見て、価値のあるイベントができたなぁと嬉しくなりました。 
他にも GCPUG 時代からほぼ毎回参加してくれている、同じシェアオフィスで働いているデザイン会社の営業の方で、イベントに参加するまではまったく Google テクノロジーに興味というか、そもそも興味が出るほどの情報に触れることがなかった方がいらっしゃるんですが、今では HTML や CSS を自ら学んでいたり、スマホを家族ともども Pixel にして AI Assistant を活用していたり、Google の最新情報について質問をしてくれたりするようになりました。ゼロから初めていろいろな技術に興味を持ってもらえる人と出会えるのも、コミュニティをやっていく醍醐味だと感じます。

Q: これから、GDG Fukushima として、どういったことをしていきたいですか?

まだ郡山市でしか開催できていないので、会津若松市には会津大学があったり、福島市には福島大学もあるわけで、そういう場所でも GDG のイベントを開催して、若い世代の方々に Google の先端技術に触れられる機会をどんどん作れたらいいなと思っています。 
それと GDG Fukushima はジェンダーの多様性はもちろん、世代の多様性も大切にしたいと思っています。実際に 2019 年 5 月に行った I/O Extended では、参加者により親近感を持ってもらえるように、登壇者のジェンダーや世代、話す内容のバランスを調整しました。子連れでも参加できる別部屋を用意したり。実際にはあまり利用してくれる人はいなかったんですけど、来場者アンケートの中に「今後自分に子供ができても参加できそう」というポジティブなことが書かれていて、自分たちのアティテュードを提示していくことの大切さを実感しました。 
開発者かどうかとか、世代や性別などまったく気にせず参加できるようなコミュニティに少しでも近づけていきたいなと思っています。 
11/17(日)には東北の GDG 共催で「DevFest 東北 2019」を、福島県郡山市で開催する予定です。 
今年の世界共通の DevFest のテーマも普段から我々が力を入れている「Diversity & Inclusion」なので、エンジニアでもそうでない人も、世代や性別、特性などを超えて楽しめるイベントにしたいなと思ってますので、皆さんぜひお越しください。

清水さん、どうもありがとうございました。

いかがでしたか? Google のデベロッパーリレーションズ チームは今後も、コミュニティの皆さんとともに、日本のデベロッパーの皆さまに役立つ情報をたくさん提供していきたいと考えています。

お住まいの地域に GDG がない、GDG のコミュニティ活動を新たに始めてみたいという方がいましたら、こちらのページよりぜひご応募ください。

皆さまからのご応募を心よりお待ちしております。

Posted by Takuo Suzuki - Developer Relations Team

管理者アカウント階層をまたぐお支払いアカウントの使用を制限

$
0
0
この記事は Thanet Knack Praneenararat による Google Ads Developer Blog の記事 "Restricting Payments account usage across manager account hierarchies" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

2019 年 9 月 9 日に、管理者アカウント階層をまたいで同じ Google Ads API お支払いアカウント(AdWords API では請求先アカウント)を使えないようにする変更をロールアウトします。Google Ads API のお支払い情報の設定の作成や更新ができるのは、Google 広告管理者アカウント階層に属する有効なお支払いアカウントだけです。

影響範囲
認証された Google 広告クライアント アカウントで、以下の影響が発生します。
そのため、これらの API を呼び出した際に返される結果が以前より少なくなる可能性があります。

行うべきこと

Google Ads API

新しいお支払い情報の設定を作成または更新する場合、PaymentsAccountService.ListPaymentsAccounts()が返す有効なお支払いアカウントを選択する必要があります。この処理で 無効なお支払いアカウントを使うと、INVALID_PAYMENTS_ACCOUNTエラーがスローされます。

AdWords API

新しい予算オーダーを作成する場合、有効なbillingAccountIdBudgetOrderService.getBillingAccounts()が返す有効な請求先アカウントの ID)を指定する必要があります。この処理で 無効な billingAccountId を使うと、BudgetOrderError.INVALID_BILLING_ACCOUNTエラーがスローされます。

いつものように、質問がある方はお気軽に Google Ads API フォーラムに投稿してください。


Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team

ようこそ、Android 10!

$
0
0
この記事は  Android 製品管理担当シニア ディレクター、Stephanie Cuthbertson による Android Developers Blog の記事 "Welcoming Android 10!" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

1 年以上の開発と先行ユーザーによる何か月ものテストを経て、世界に Android 10 をお披露目する準備が整いました!
Android 10 ロゴ
Android 10 は、3 つの重要なテーマを中核に据えて構築されています。まず、Android 10 は高度な機械学習に加え、折りたたみ式画面や 5G 対応スマートフォンといった最新端末のサポートにより、モバイルの革新の最先端を形成しています。次に、Android 10 はプライバシーとセキュリティを中心に据えており、ユーザーの保護、透明性、制御を強化する 50 近くの機能が導入されています。最後に、個人や家族がテクノロジーとの適度なバランスを見つけられるように、Android 10 ではユーザーのデジタル ウェルビーイング制御が拡張されています。

今月、Android 10 のソースコードを Android オープンソース プロジェクト(AOSP)にリリースし、幅広いエコシステムに公開しました。また、世界中の 3 世代すべての Pixel 端末に対して公式に Android 10 のロールアウトを開始しました。ベータ版プログラムの対象端末も含め、多くのパートナー端末に年末までにアップデートを配信する予定です。
今年のベータ版期間中の皆さんのサポートに感謝いたします。26 種類のベータ版端末で 20 万人以上に早期リリースをテストしていただきました。報告された問題は、重複を除いて 2 万件となっています。その土台になったのは、皆さんからのご意見が寄せられた多くの記事やディスカッション、アンケート、対面による会話、そして本日のリリースまでにアプリの互換性を確保するために皆さんが取り組んでくださった作業です。Android がこのようなすばらしいプラットフォームになっているのは、皆さんのサポートと注力があってこそです。今回の Android リリースが今まで以上に興奮の渦を巻き起こしているのは、OEM パートナーと皆さんのおかげです。実際、Android 10 はこれまでのリリースの中で最も多くの端末で使用できるようになる予定です。このような情熱的なコミュニティに支えられている Android は幸せ者です!

Android 10 での開発を始めたい方は、developer.android.com/10にアクセスしてみてください。

Android 10 の新機能

以下では、Android 10 の機能とその使い方について紹介します。さらに詳しく知りたい方は、Keyword ブログもご覧ください!

イノベーションと新たな体験

Android 10 では、ハードウェアやソフトウェアにおける最新イノベーションを活用して、ユーザーにすばらしいアプリ体験を提供できます。
折りたたみ式画面 - Android 10 では、堅牢なマルチウィンドウ サポートを土台として、アプリ ウィンドウ間のマルチタスクが拡張されています。画面の継続性機能によって、端末をたたんだり開いたりしてもアプリの状態が維持されます。折りたたみ式画面向けにアプリを最適化する詳しい方法については、デベロッパー ガイドをご覧ください。

5G ネットワークは、一貫して高速かつ低遅延なネットワークを提供します。Android 10 はプラットフォームで 5G をサポートしており、皆さんがこの機能を利用できるように既存の APIも拡張しています。ネットワーク接続 API を使うと、端末が高帯域幅接続を利用できるかどうかを検知したり、接続が従量制かどうかを確認したりできます。これらの機能を使えば、アプリやゲームで 5G ユーザーに合わせた高度で迫力ある体験を提供できます。
ライブ字幕は、どんなアプリを使っていても、動画やポッドキャスト、音声メッセージなど、ユーザーの端末で再生されているメディアに自動的に字幕を付けます。ML 会話モデルはスマートフォン上で直接実行されるので、端末から外部に音声ストリームが送信されることはありません。デベロッパーの皆さんがライブ字幕を使うかどうかは任意ですが、1 回のタップでコンテンツのアクセス可能性を広げ、アプリやゲームの対象ユーザーを拡大することができます。ライブ字幕は今秋に Pixel 端末で利用できるようになります。また、Android 10 を実行している端末で広く利用できるように、パートナーと連携して作業を進めています。

通知のスマート リプライ - Android 10 は、オンデバイス ML を使って、通知内で状況に応じたアクションを提案します。たとえば、スマート リプライでメッセージに返信したり、通知内の住所からマップを開いたりできます。この機能はユーザーのプライバシーを念頭に置いて構築されており、すべての ML 処理が端末内で行われます。この機能はすぐにアプリで利用できます。自分で提案を生成したい場合は、オプトアウトすることも可能です。
スマート リプライ通知を表示するモバイル端末
スマート リプライが通知のコンテンツに応じたアクションを提案
ダークテーマ - Android 10 には、システム全体を対象としたダークテーマが追加されています。これは、明るさを抑えて電池を節約したい場合に理想的です。アプリ用にカスタムのダークテーマを作成したり、現在のテーマから動的にダークテーマを作成させることもできます。詳しくは、デベロッパー ガイドをご覧ください。
ダークテーマの To Do リスト
Google Keep のダークテーマ
ジェスチャー ナビゲーション - Android 10 には、完全ジェスチャー ナビゲーション モードが導入されています。ナビゲーション バー領域をなくしてアプリで全画面を使えるので、魅力的で没入感の高い体験を提供できます。早速アプリの最適化に着手しましょう
ジェスチャーで全画面のマップを閉じ、30 分後の Layla とのディナーを表示する様子を示した gif
ジェスチャー ナビゲーションを使うと、アプリでコンテンツの全画面表示が可能

ユーザーのプライバシー

プラットフォームの保護の強化からプライバシーを念頭において設計された新機能まで、プライバシーは Android 10 で特に重視されているものの 1 つです。Android 10 では、プライバシーを守りつつユーザーの制御を向上させるため、これまでのリリースをベースに幅広い変更が行われています。具体的には、システム UI の改善、パーミッションの厳格化、アプリが利用できるデータの制限などがあげられます。このような機能をアプリでサポートする詳しい方法については、Android 10 デベロッパー サイトをご覧ください。
ユーザーによる位置データの制御向上 - 新しいパーミッション オプションにより、ユーザーによる位置データの制御が向上し、アプリが実際に使用中(フォアグラウンドで動作)の場合のみ位置情報へのアクセスを許可できるようになります。ほとんどのアプリはこのレベルのアクセスで十分です。ユーザーの透明性と制御も大きく向上することになります。位置情報の詳しい変更点については、デベロッパー ガイドまたはブログ投稿をご覧ください。
通知の表示: App 1 に端末の位置情報へのアクセスを許可する
ネットワーク スキャンでの位置データの保護 - ネットワークをスキャンする大半の API は、既に低精度の位置情報パーミッションが必須となっています。Android 10 では、これらの API で高精度の位置情報パーミッションが必須となり、API の保護が強化されています。

端末のトラッキングの防止 - トラッキングに使用でき、リセットできない端末の識別子には、アプリからアクセスできなくなりました。これには、端末の IMEI、シリアル番号などの識別子が含まれます。デフォルトでは、Wi-Fi ネットワークに接続する際に端末の MAC アドレスも乱数化されます。皆さんの使用例に適した識別子を選ぶには、ベスト プラクティスこちらに掲載されている情報をご覧ください。

外部ストレージ上のユーザーデータの保護 - Android 10 では、外部ストレージのファイルやその中のアプリデータに対するユーザーの制御を向上させるため、多くの変更が行われています。アプリはファイルをプライベートなサンドボックスに格納できますが、共有メディア ファイルにアクセスする場合は MediaStore の使用が必須になります。新しいダウンロード接続で共有ファイルにアクセスする場合は、システムのファイル ピッカーを使用する必要があります。詳細については、こちらを参照してください。

不要な割り込みのブロック - Android 10 は、バックグラウンドから予期せずにフォアグラウンドに割り込み、別のアプリからフォーカスを奪うアプリの起動を防ぎます。詳細については、こちらを参照してください。

セキュリティ

Android では、常に継続的なセキュリティ改善を評価しています。私たちはこの取り組みを「測定可能なセキュリティ」と呼んでいます。継続的な改善を測定する方法の 1 つが、Gartner’s May 2019 Mobile OSs and Device Security: A Comparison of Platformsレポート(サブスクリプションが必要です)などのサードパーティ アナリストによるリサーチです。Android は 30 のカテゴリのうち 26 で最高のスコアを獲得し、認証からネットワーク セキュリティ、不正なソフトウェアからの保護まで、複数の点で首位に立っています。私たちの長期的なセキュリティの取り組みについては、測定可能なセキュリティによる定量化もご覧ください。ただし、セキュリティにゴールはありません。Android 10 では、さらに機能を追加し、高度な暗号化、プラットフォームの強化、認証によってユーザーのセキュリティを向上させています。

ストレージの暗号化 - Android 10 が搭載された状態でリリースされ、互換性のあるすべての端末で、ユーザーデータの暗号化が必須になります。これを効率的に行うため、Android 10 には新しい暗号化モード Adiantumが含まれています。

TLS 1.3 のデフォルト化 - Android 10 ではデフォルトで TLS 1.3が有効になっています。これは TLS 標準のメジャー リビジョンで、パフォーマンスの向上とセキュリティの強化が行われています。

プラットフォームの強化 - Android 10 では、プラットフォームにおいてセキュリティが重要な領域がいくつか強化されていますBiometricPromptフレームワークもアップデートされ、暗黙的な認証と明示的な認証の両方で顔と指紋による確実な認証がサポートされています。Android 10 のセキュリティ アップデートの詳細は、こちらをご覧ください

カメラとメディア

写真のダイナミック デプス - アプリがダイナミック デプス イメージをリクエストできるようになります。このイメージは、JPEG、深度に関連する要素が格納された XMP メタデータ、深度と信頼度のマップで構成され、これらが同じファイルに埋め込まれます。ダイナミック デプスを使うと、アプリで特殊なぼかしやぼけのオプションを提供できます。ダイナミック デプスはエコシステムのためのオープンな形式です。私たちは、Android 10 以降を実行している端末でこの機能を利用できるようにするため、パートナーと連携して作業を進めています。
背景にテラスの家具が映った毛むくじゃらな犬の横顔のイメージ背景にぼかしたテラスの家具が映った毛むくじゃらな犬の横顔のイメージグレースケールでぼかした毛むくじゃらな犬の横顔のイメージ
ダイナミック デプス イメージを使うと、アプリで特殊なぼかしやぼけのオプションを提供できる

オーディオ再生のキャプチャ - オーディオを再生するすべてのアプリは、別のアプリにオーディオ ストリームをキャプチャさせることができるようになります。これには、新しいオーディオ再生キャプチャ APIを使用します。この API を使って、字幕やサブタイトルを付けるだけでなく、ゲームのライブストリーミングなどのよく使われるユースケースをサポートすることもできます。この新機能はプライバシーや著作権保護を考慮して構築しているので、アプリが別のアプリのオーディオをキャプチャする機能には制限があります。詳しくは、ブログ投稿をご覧ください。

新しいオーディオと動画のコーデック - Android 10 には、オープンソースの動画コーデック AV1のサポートが追加されています。これを使うと、メディア プロバイダは低い帯域幅で高画質の動画コンテンツを Android 端末にストリーミングできます。また、Android 10 は、Opusを使ったオーディオ エンコードもサポートしています。このオープンでロイヤリティ フリーなコーデックは、会話や音楽のストリーミングや、ハイ ダイナミック レンジ動画用の HDR10+(対応端末の場合)に合わせて最適化されています。

ネイティブ MIDI API - C++ でオーディオ処理を行うアプリのために、Android 10 は NDK 経由で MIDI 端末と通信できるネイティブ MIDI APIを導入しています。この API を使うと、非ブロック読み取りを使ってオーディオ コールバック内から MIDI データを取得し、MIDI メッセージを低遅延で処理できます。サンプルアプリとこちらのソースコードで試してみてください。

すべての場所に Vulkan を - Vulkan 1.1は、Android 10 以降を実行するすべての 64 ビット端末で必須要件に、すべての 32 ビット端末で推奨要件になります。エコシステムでは、既にすさまじい勢いで Vulkan サポートが進んでいます。Android N 以降を実行している端末では、半分以上が Vulkan 1.0.3 以降をサポートしています。Android 10 の新しい要件によって、来年はさらに採用が進むことを期待しています。

ネットワーク接続

ピアツーピア接続とインターネット接続の改善 - Wi-Fi スタックをリファクタリングし、プライバシーとパフォーマンスを改善しました。さらに、IoT 端末の管理やインターネット接続の提案などの一般的なユースケースを改善し、位置情報のパーミッションが不要になりました。ネットワーク接続 APIを使うと、ローカル Wi-Fi 経由で IoT 端末を簡単に管理し、設定、ダウンロード、印刷などのピアツーピア機能を利用できます。アプリでネットワーク提案 APIを使うと、インターネット接続用として、好みの Wi-Fi ネットワークをユーザーに表示することができます。

Wi-Fi パフォーマンス モード - アプリは高パフォーマンス モードおよび低遅延モードを有効化することで、アダプティブ Wi-Fi をリクエストできるようになりました。リアルタイム方式のゲームや音声通話など、ユーザー エクスペリエンスにとって低遅延が重要な場合、この機能が非常に役立ちます。プラットフォームが端末のファームウェアと連動し、最低消費電力で要件を満たすように動作します。

Android の土台

ART の最適化 - ART ランタイムの改善により、デベロッパーの皆さんが何もしなくても、アプリの起動が早くなり、消費するメモリの量が減り、動作もスムーズになります。また、Google Play が提供する ART プロファイルによって、アプリが実行される前にアプリの一部が事前コンパイルされるようになります。実行時には、世代別ガベージ コレクションによって時間や CPU の面でガベージ コレクションの効率が上がり、ジャンクが減ってローエンド端末でもアプリの動作が快適になります。
Play のプロファイルによる起動時間の改善の棒グラフ
このグラフは、あるアプリを Play プロファイルを使ってテストした際の起動時間の改善率を表している
Neural Networks API 1.2 - さまざまなパフォーマンス最適化と合わせて、ARGMAX、ARGMIN、量子化 LSTM など、60 個の新命令を追加しました。これは、物体検知やイメージ セグメンテーションなど、数多くのモデルを高速化する土台となります。現在、NNAPI 1.2 のサポートを最適化してリリースするために、ハードウェア ベンダーや TensorFlowなどの人気のある機械学習フレームワークと協力して作業を進めています。

高速なアップデート、最新のコード

Android 10 では、端末メーカーや Qualcomm などの半導体パートナーと密接に連携し、新しいプラットフォームを今まで以上に高速に端末にお届けできるようにしています。Project Trebleは重要な役割を果たしており、8 種類の Pixel 端末とともにパートナー 18 社の端末を今年のベータ版プログラムに含める際に役立ちました。これは、昨年の倍以上の数になります。これらの端末は、年末までに公式の Android 10 アップデートを受信する予定です。また、他の新しいフラグシップの発売やアップデートに向けて、何社かのパートナーと作業を進めています。Android 10 には既に大きな勢いがついていますが、今後数か月で、これまでのどの Android リリースも超える数の端末がこの新バージョンを受信する予定です。
また、Android 10 は Project Mainline(正式には、Google Play システムアップデートと呼ばれています)をサポートする最初のリリースになります。

この新しいテクノロジーは、Android ユーザーを保護し、Google Play から直接端末に重要なコードの変更を提供して最新の状態に保ちます。Google Play システムアップデートを使うと、Android 10 以降を実行しているすべての端末で、端末メーカーによる完全なシステムアップデートを行わずに特定の内部コンポーネントを更新できます。一般向けの端末を対象とした最初のアップデートは、今後数か月間のうちにリリースする予定です。

この Android 10 のアップデートにより、多くの端末でプラットフォーム実装の整合性が促進され、時間とともに統一性が向上し、開発やテストの費用を削減できることが期待されます。

Android 10 リリースに向けたアプリの準備

Android 10 が一般公開リリースを迎え、端末にはまもなくアップデートが配信されます。すべての Android デベロッパーは、ユーザーが Android 10 にスムーズに移行できるように、できる限り早く現在のアプリをアップデートして互換性を確保してください。
そのための方法を以下に示します。
アプリをテストして Android の新バージョンに対応する準備をすることは、エコシステム全体が迅速にプラットフォームをアップデートするために不可欠です。そのため、できる限りこの作業の優先度を上げていただくようお願いいたします。

Android 10 の機能と API を使用してアプリを強化する

準備ができたら、Android 10 に移行し、使用できる新しい機能や APIについて学習してください。最初に着手すべき重要な機能は、以下のとおりです。
以下の項目は、すべてのアプリで推奨します。
  • ダークテーマ: ダークテーマを追加するか Force Darkを有効にして、システム全体でダークテーマを有効にしているユーザーに一貫性のある体験を提供します。
  • ジェスチャー ナビゲーション: アプリを全画面に対応させてジェスチャー ナビゲーションをサポートし、システムのナビゲーション ジェスチャーをカスタム ジェスチャーで補えるようにします。
  • 折りたたみ式画面向けの最適化: 折りたたみ式画面向けの最適化を行い、最新のイノベーションあふれる端末でシームレスな体験を提供します。
該当するアプリでは、以下の項目にも対応することをお勧めします。
  • 通知のインタラクティブ性の向上: メッセージを含む通知を送っている場合は、通知でスマート リプライを有効にして即座にアクションを実行できるようにすることで、ユーザーのエンゲージメントを向上させます。
  • バイオメトリックの強化: バイオメトリック認証を利用している場合は、BiometricPromptに移行してください。これは、最新端末で指紋認証をサポートする際に推奨されている方法です。
  • オーディオ再生のキャプチャ: アプリで字幕生成やゲームの録画をサポートするには、オーディオ再生のキャプチャを有効にします。これは、多くのユーザーを獲得し、広くアプリにアクセスしてもらう絶好の手段です。
  • コーデックの改善: メディア アプリでは、動画のストリーミングに AV1を、ハイ ダイナミック レンジ動画に HDR10+を試してみてください。会話や音楽のストリーミングには Opusエンコーディングを、ミュージシャンの方ならネイティブ MIDI APIを使うことができます。
  • ネットワーク API の改善: アプリを使って Wi-Fi 経由で IoT 端末を管理しているなら、新しいネットワーク接続 APIを使って設定、ダウンロード、印刷などの機能を試すことができます。
すべての新機能と変更点を確認したい方は、Android 10 デベロッパー サイトをご覧ください。
開発を始めるには、Android Studio 3.5以降に公式 API 29 SDK とツールをダウンロードします。その後、こちらの手順に従って環境を設定します。

お手元の端末へ!

3 世代の Pixel スマートフォンには、本日より Android 10 のロールアウトが開始されます。対象となるのは、Pixel 3(および 3a)、Pixel 2、そしてオリジナルの Pixel です。すべての Pixel 端末は来週中にアップデートを受信します。今年のベータ版プログラムに登録されている端末も含まれます。Pixel 端末をお持ちの方は、まもなく届く公式の OTA(無線)アップデートをお待ちください。
いつものように、Pixel 端末用のシステム イメージもこちらで公開しています。手動でダウンロードして更新する際に使用できます。最新の Android Emulator システム イメージは、Android Studio の SDK Manager から入手できます。Treble 対応の端末で幅広くテストしたい場合は、こちらから Generic System Image(GSI)を入手できます。
Android 10 のソースを探している方は、Android オープンソース プロジェクトの Android 10 ブランチの下にあるリポジトリにあります。こちらをご覧ください。

次のステップ

Android ベータ版の Issue Tracker と Feedback アプリは近日中にクローズしますが、フィードバックは引き続きお寄せください。AOSP Issue Tracker で Android 10 に対して新しく問題を送信できます。
今年の Android ベータ版プログラムに参加してくださった、たくさんのデベロッパーと先行ユーザーの皆さん、本当にどうもありがとうございました。皆さんから送られたすばらしいフィードバックやたくさんの問題は、ユーザーやデベロッパーにとってすばらしい Android 10 プラットフォームを生み出すために役立ちました。
Android 10 に対応した皆さんのアプリを楽しみにしています。

Reviewed by Yuichi Araki - Developer Relations Team

Room 収納術: メソッド一つで事前データ入りのデータベースを実現

$
0
0
この記事は Florina Muntenescu (Android Developer Advocate) による Medium Blog の記事 "Packing the Room: Pre-populate your database with this one method" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。



APK 内にパッケージされたデータ、またはサーバーからダウンロードしたデータのいずれかを、データベースに事前に取り込む必要があるとします。SQLite と Room のどちらでこの作業を行う場合でも、データベースを開く、スキーマを検証する、データベース ファイルをロックしてスレッドの同期を処理する、すべてのコンテンツをコピーする、データベースを閉じる、といった複数の処理を行う必要があります。

Room 2.2(現在ベータ版)より、あらかじめパッケージ化されたデータベースの場所に応じて、RoomDatabase.Builder#createFromAsset() または createFromFile() という 1 つのメソッドを呼び出すことで、データベースに事前にデータを取り込むことができます。本稿では、こうしたメソッドの使用方法、あらかじめパッケージ化されたデータを扱う際のヒント、およびマイグレーションが含まれる場合に何が起こるかについて説明します。

createFromAsset()

あらかじめパッケージ化されたデータベースがアプリの assets/ フォルダに含まれている場合は、createFromAsset() を使用し、アセットのパスをパラメータとして指定します。たとえば、データベースが assets/database/myapp.db にある場合は、“database/myapp.db” と指定します。

Room.databaseBuilder(appContext, TestDatabase.class, “Sample.db”)
   .createFromAsset(“database/myapp.db”)
   .build()

createFromFile()

データベースが assets/ フォルダに含まれていない場合、つまりサーバーからデータベースをダウンロードしてディスクに保存する場合は、createFromFile() を使用して File を指定します。

Room.databaseBuilder(appContext, TestDatabase.class, “Sample.db”)
   .createFromFile(File(“mypath”))
   .build()
🚫インメモリ データベースでは、createFromAsset または createFromFile によるデータベースへのデータの事前取り込みをサポートしていません。この処理を行おうとすると RoomDatabase.build() メソッドは IllegalArgumentException をスローします。

ファイルのアクセス権

Room は指定されたデータベースを開くのではなく、コピーします。そのため、File を使用する場合は、Room でファイルをコピーできるよう、読み取り権限があることを確認してください。

データベースの検証

Room では、データベースを別のバージョンにマイグレーションする際にデータベースの妥当性を保証します。そのために、アセットとファイルのどちらからデータベースを作成する場合も、同じ検証チェックを適用します。同様に、Room はデータのコピー元とコピー先のデータベースのスキーマが一致することを保証します。
💡 Room では、@Database アノテーションの exportSchema パラメータを使ってデータベース スキーマの書き出しが可能となっています。そのため、あらかじめパッケージ化されたデータベースを作成する際は、そこに定義されているスキーマを使用します。

マイグレーション

一般に、データベースのスキーマが変わる際、デベロッパーは@RoomDatabase アノテーション内のデータベースのバージョンを増分し、マイグレーションの実装または破壊的なマイグレーションの有効化のいずれかを行います。Room は、デバイスにすでにインストールされているバージョンと、アプリに定義されている最新バージョンを調べます。

たとえば、デバイス上のデータベースのバージョンが 2 で、@RoomDatabase に定義されているアプリのデータベース のバージョンが 4 であるとします。以下では、そのバージョンの組み合わせに対して、あらかじめパッケージ化されたデータベースがさらに追加された場合に、それぞれのシナリオで何が起きるかを説明します。

1. 破壊的なマイグレーションが有効になっていて、あらかじめパッケージ化されたデータベースのバージョンがアプリに定義されているバージョンよりも古い場合、データベースは削除され、データはコピーされません。

例: あらかじめパッケージ化されたデータベースのバージョンが 3 で、破壊的なマイグレーションが有効になっている場合、データベースは削除され、データはコピーされません。

2. 破壊的なマイグレーションが有効になっていて、あらかじめパッケージ化されたデータベースのバージョンがアプリに定義されているものと同じバージョンである場合、データベースは削除され、あらかじめパッケージ化されたデータベースからデータがコピーされます。

例: あらかじめパッケージ化されたデータベースのバージョンが 4(アプリのデータベースのバージョンと同じ)で、破壊的なマイグレーションが有効になっている場合、データベースは削除され、あらかじめパッケージ化されたデータベースからデータがコピーされます。

3. マイグレーションが実装されていて、@RoomDatabase アノテーションに指定されているバージョンよりもあらかじめパッケージ化されたデータベースのバージョンのほうが古い場合、Room はデータをコピーしてマイグレーションを実行します。

例: あらかじめパッケージ化されたデータベースのバージョンが 3 であり、バージョン 2 から 3 へのマイグレーションとバージョン 3 から 4 へのマイグレーションが実装されている場合、まずバージョン 2 から 3 へのマイグレーションが実行され、データベースがコピーされた後、バージョン 3 から 4 へのマイグレーションが実行されます。(ソースはこちら

On device db version, @RoomDatabase version, Pre-packaged db version, Migrations, Data copied
2, 4, 3, destructive, No
2, 4, 4, destructive, Yes
2, 4, 3, implemented, Yes and migrations run
💡あらかじめパッケージ化データベースのバージョンと、@RoomDatabase アノテーションで宣言されている最新のバージョンを同じにすることをおすすめします。そうすることで、マイグレーションのケースに対処する必要がなくなります。
📖 Room でのマイグレーションについて詳しくはこちらのブログ投稿を、マイグレーションのテストについてはこちらをご覧ください。
Room データベースに対して、アプリに含まれているデータから、またはファイルから、簡単にデータを取り込めるようになりました。Room ではデータの整合性を保護するとともに、必要に応じてデベロッパーによるマイグレーションの実施を支援します。

Posted by Yuichi Araki - Developer Relations Team

Android エコシステムにおけるアクセシビリティの改善

$
0
0
この記事は Ian Stoba (Program Manager, Accessibility Engineering) による Android Developers Blog の記事 "Improving Accessibility in the Android Ecosystem" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


世界中で利用されている Android デバイスは数十億台に上り、Play ストアには数百万ものアプリが公開されています。このような巨大なエコシステムにおいては、隅々にまで変化を行き渡らせるのは至難の業のようにも思われます。しかし、今まさにその課題に取り組んでいるのが、Accessibility Developer Infrastructure チームです。

デベロッパーが APK や App Bundle をオープン トラックやクローズド トラックにアップロードすると、バージョンの異なる Android を搭載した多様なデバイスでテストが行われ、検出された問題をまとめたリリース前レポートが生成されます。

1 年前、業界のベスト プラクティスや Google 独自の経験に基づいて、このレポートにアクセシビリティに関する提案を追加しました。アクセシビリティのテストでは、障がいのある方にとって使いづらい部分がアプリにないかを確認します。たとえば、ボタンは押しやすい大きさになっているか、テキストと背景に十分なコントラストがあって読みやすいか、などをチェックします。

2018 年 7 月の導入以来、380 万を超えるアプリをテストし、1 億 7,100 万件以上のアクセシビリティの改善提案を行いました。それぞれの提案には、実装方法に関する詳しい情報も含まれています。リリース前レポートのアクセシビリティの提案は、スタートアップから大企業まで、あらゆる規模のデベロッパーの皆様にご活用いただけるものです。

その効果が、実際に目に見える形になってきています。今年の Google I/O では、アクセシビリティに関する直接相談の申し込み件数が 2018 年の 4 倍に達しました。相談セッションを担当した Google 社員からの報告では、デベロッパーの皆様からの質問は非常に具体的で、リリース前レポートの提案をベースとしたものが多かったようです。

質問の的が絞られていたことが実践的な提案に結びつきました。相談に来られたデベロッパーの皆様も気付かれていましたが、アクセシビリティを改善するのは、それが正しいことという理由だけではありません。アクセシビリティの拡充によって、アプリの潜在市場が拡がり、ビジネスの拡大につながるという面もあるのです。

リリース前レポートでのアクセシビリティのテストは、世界のデベロッパー コミュニティの認知を高めるための 1 つの取り組みにすぎません。Google では、Udacity と提携してウェブ アクセシビリティの無料オンライン コースを開設し、Play ストアに Android 用ユーザー補助検証ツールをリリースしています。

また、GitHub に iOS 用ユーザー補助検証ツールを公開し、iOS デベロッパーがアプリのアクセシビリティを簡単にテストできるようにしています。これらすべての取り組みが、Google の使命である「世界中の情報を整理し、世界中の人々がアクセスして使えるようにする」ことにつながっています。

アクセシビリティを考慮に入れた開発について詳しくは、Android デベロッパー向けのガイドGoogle デベロッパー ドキュメント スタイルガイドをご覧ください。

Posted by Yuichi Araki - Developer Relations Team

デベロッパーと組織が差分プライバシーを使用可能に

$
0
0
この記事は Miguel Guevara による Google Open Source Blog の記事 "Enabling Developers and Organizations to Use Differential privacy" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
元の記事は Google Developers Blogに投稿されました。

投稿者: プライバシーおよびデータ保護オフィス プロダクト マネージャー、Miguel Guevara

データから貴重な見識を得ることができれば、サービスを向上させて重要な疑問に答えることができます。その点は、都市計画家であろうと、中小企業の経営者であろうと、ソフトウェア デベロッパーであろうと変わりません。しかし、強力なプライバシー保護がなければ、市民や顧客、そしてユーザーの信頼を失う恐れがあります。


差分プライバシーによるデータ分析は合理的なアプローチです。この手法を使うと、組織は大多数のデータから学習できますが、その結果から個人データの識別や再特定を行うことはできません。この種の分析は、さまざまな目的のために多種多様な方法で実現できます。たとえば、医療分野の研究者なら、看護の状況の違いについて調べるために、さまざまな病院で患者の平均入院時間を比較したいと思うかもしれません。差分プライバシーは、このようなユースケースにおいて、プライバシーを保護しつつ確実に対処できる分析手段です。


本日、オープンソース版の差分プライバシー ライブラリをロールアウトしました。このライブラリは、いくつかの Google の中核プロダクトで使われているもので、デベロッパーの皆さんに簡単に活用いただけるように、ユーザーの貢献度の境界値自動計算など、ゼロから構築・実装が特に難しいような機能について集中的に対応しています。すべての組織やデベロッパーが自由に使うことができます。

テクノロジーの詳細解説

このオープンソース ライブラリは、デベロッパーのニーズに合わせて設計されています。私たちは、自由にアクセスできるだけでなく、簡単にデプロイできる便利なものにしたいと考えました。

このライブラリの主な機能は、次のとおりです。
  • 統計機能: このリリースでは、データ サイエンスでよく使われる一般的なオペレーションがサポートされています。このライブラリを使うと、カウント、合計、平均、中央値、パーセンタイルを計算できます。
  • 厳格なテスト:差分プライバシーを正しく理解するのは難しいことです。誤りを防ぐために、幅広いテストスイートに加え、拡張可能な「確率的差分プライバシー モデル チェッカー ライブラリ」も含めています。
  • すぐに使える:オープンソース リリースが実際に役に立つかどうかは、「私でも使えますか?」という質問に答えられるかどうかにかかっています。そのため、実際に使ってみるための汎用的なレシピとともに、PostgreSQLの拡張機能を含めています。私たちのアプローチの詳細は、本日公開したばかりの技術論文に書かれています。
  • モジュール式: このライブラリは、追加メカニズム、集計関数、プライバシー予算管理などの機能を追加して拡張できるように設計されています。
新しいプライバシー技術に向けた作業

私たちは、2014 年に Chrome を改善するために RAPPOR をリリースしました。それ以降、実用的な差分プライバシー技術についての研究や開発を進め、実世界での応用において先頭を走り続けてきました。

また、差分プライバシーの手法を使い、プロダクトに便利な機能を追加しました。たとえば Google マップでは、1 日のうちに店舗がどのくらい混雑するか、レストランの特定のメニューがどのくらい人気になっているかなどの機能を作成しました。さらに、Google Fi の改善も行っています。







今年は、Tensorflow PrivacyTensorflow FederatedPrivate Join and Computeなど、いくつかのオープンソース プライバシー技術についてお知らせしてきました。本日のリリースによって、拡大を続けるそのリストにさらにもう 1 つ、技術が加わることになります。このライブラリを一般公開できたことをうれしく思います。デベロッパーの皆さんが包括的なデータ プライバシー戦略を構築する際に利用していただけることを期待しています。医療、行政、ビジネスなどの分野で、これらのオープンソース ツールから、あらゆる人にとって有益な見識が生まれることを願っています。



謝辞
ソフトウェア エンジニア: Alain Forget、Bryant Gipson、Celia Zhang、Damien Desfontaines、Daniel Simmons-Marengo、Ian Pudney、Jin Fu、Michael Daub、Priyanka Sehgal、Royce Wilson、William Lam

Chrome Developers Japan ニュースレター にご登録ください

$
0
0

Chrome Tech Talk Night を始めて 7 年が経ちました。ウェブ デベロッパー様向けの情報提供や事例共有の場として長年活動してまいりましたが、先日開催した #14も多くの方にご参加いただき、実りあるイベントとなりました。ご参加いただいた皆様、登壇者の皆様、ありがとうございました。

今後 Chrome Japan チームは体制を強化し、皆様とのコミュニケーションを充実させることで、皆様の活動をより効果的に支援してまいります。つきましては「Chrome Developers Japan ニュースレター」の定期配信を開始します。登録希望の方はこちらのサイトよりご登録ください。

同僚やお知り合いの方で、Chrome Developers Japan ニュースレター にご興味をお持ちの方がいらっしゃいましたら、ぜひこのブログ記事をご紹介ください。

皆様のご登録をお待ちしております。

Posted by Eiji Kitamura - Developer Relations Team

新しい Google Play Console データでより的確な意思決定を

$
0
0
この記事は Tom Grinsted (Product Manager, Google Play) による Android Developers Blog の記事 "Make stronger decisions with new Google Play Console data" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

今年の Google I/O で、Google Play でのビジネス拡大に役立つさまざまな新機能を発表しました。今回の変更では、より明確で実用的なデータを提供することを通じて、ビジネスにおける的確な意思決定を支援するためのさまざまな改善を加えました。

アプリのパフォーマンスを改善してビジネスを拡大するには正しいデータが不可欠です。そこで、Google Play Console の主要な指標を刷新し、ユーザー別、デバイス別のインストールやアンインストールなど、最も基本的な指標をより正確に測定、分析できるようにしました。また、Play Console の [統計情報] ページを拡充し、データの推移を確認できるようになったほか、よりきめ細かな設定が可能になりました。近日中には、主要な指標についての Google Play ならではのベンチマークも利用できるようにする予定です。

[統計情報] ページで細かく設定し、ユーザーの獲得やチャーンを正確に把握できる。

指標が新しくなって正確性と包括性が増したことで、ユーザーの獲得やチャーンを詳しく把握できるようになりました。また、デベロッパーの皆様のビジネス拡大戦略に不可欠と判断し、新たにリピーターとデバイスに関するデータを含めることにしました。

新しいインストール方法(プリインストール、ピアツーピア共有など)にも対応し、ビジネスニーズに合わせて期間ごとに重複を排除して集計する機能も追加しました。これらの変更によって、これまでなら難しかった分析も可能になり、たとえば「先月アプリを再インストールしたユーザーの数」なども把握できるようになりました。

以下にその他の変更点をまとめます。

  • 指標の定義をより明確にして一貫性を高めました。
    • ユーザーかデバイスか、獲得数か減少数かを選択
    • 新規ユーザー、リピーター、または総ユーザーを指定
    • イベント(例: 誰がいつインストールしたか)やユニーク(例: インストールしたすべての人)を測定
  • [推移の分析] グラフには、選択した期間における所定の分割項目の最も大きな変化が自動的に表示されるため、指標の傾向に影響を与えた最大の要因を簡単に把握できます。
  • 保存済みレポートを使用すると、あらかじめ設定した指標を保存しておき、後で呼び出して簡単に分析できます。
  • おすすめのレポートでは、データをどのように組み合わせたらより有用な分析になるかをおすすめします。
  • 設定したすべてのデータは、インターフェース内から CSV としてダウンロードできます。

これらの更新に伴い、指標にもいくつかの変更が加えられ、古い指標名は廃止されることになりました。新しい指標と古い指標の対応は、こちらのクイック リファレンスで確認できます。また、[統計情報] ページの「レポートを保存」機能を使用すると、よく使用するレポート設定を保存して繰り返し使用できます。

[統計情報] ページの「レポートを保存」機能を使用すると、よく使用するレポート設定を保存して繰り返し使用できる。

その他の指標として、アクティブ ユーザーやアクティブなデバイスなども大きく変更されます。新たに定義された指標がより包括的になり、以前はカウントされていなかったデータも含まれることになったためです。

新しい指標の一部は、古い指標に対応しています。対応する古い指標がある場合は、すべての履歴データが自動的に引き継がれます。対応する古い指標がない場合は、リリース日以降のデータのみが生成されます。ユニーク デバイス数やユニーク ユーザー数についてですが、週単位の指標はリリースの 2 週間後から表示されます。また、月単位の指標は 1 か月分の全データが収集されてから表示されます。四半期単位の指標は 1 四半期分の全データが収集されてから表示されます。

多くの指標が変更されていますので、クイック リファレンスをブックマークし、新しい指標を使用するときに参照することをおすすめします。新しい指標を早く使いこなしたい方には、Google I/O のセッション「Google Play Console で意思決定する」や、Play アカデミーのトレーニングもおすすめです。

本日お知らせした Google Play Console の変更が、皆様のお役に立つことを願っております。ご意見、ご要望などございましたら引き続きお寄せください。Google Play Console の改善に役立てさせていただきます。

Posted by Yuichi Araki - Developer Relations Team


Android のモジュールのパスに関するちょっとしたヒント

$
0
0
この記事は Pietro Maggi (Android Developer Advocate) による Medium Blog の記事 "A Little Thing about Android Modules Paths" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


Android アプリのモジュール性を高める作業を進めていた私は、最終的に、以下のように 1 つのフォルダ内にグループ化されたオンデマンド機能のセットを含んだサンプルを作成しました。

実際には、アプリをどのようにモジュール化するかに応じて、わかりやすい名前を付けます

極めて標準的な設定です。オンデマンド モジュールがすべて「features」フォルダ内に含まれていて、わかりやすくなっています。
この一連のモジュールは、settings.gradle ファイルで以下のように読み込まれています。

include ':app'
include ':features:module1'
include ':features:module2'
include ':features:module3'
include ':features:module4'

このような設定は問題なく機能しますが、以下のように Android Studio の Android ビューに features という空のモジュールが表示されてしまうという「ちょっとした」問題があります。

デフォルトでは、Android Studio の Android ビューに空のモジュールが表示される

この状態でも問題はありませんが、この空のモジュールをなんとかプロジェクトから削除できないでしょうか。

削除できないのなら名前を変える

Google I/O のセッション「Android Studio: Tips and Tricks(Android Studio: ヒントとコツ)」において、Google のイヴァン ガブリロビッチが素晴らしいヒントをいくつか紹介していました。そのなかに、上記の問題を解決できそうな方法がありました。モジュールにカスタムのパスを設定するという方法です。


上記のケースでは、settings.gradle を以下のように設定します。
include ':app'

include ':module1'

include ':module2'

include ':module3'

include ':module4'
// 4 つの features モジュールにカスタムのパスを設定。

// こうすることで Android Studio に空の「features」モジュールが表示されなくなる。

project(":module1").projectDir=new File(rootDir, "features/module1")

project(":module2").projectDir=new File(rootDir, "features/module2")

project(":module3").projectDir=new File(rootDir, "features/module3")

project(":module4").projectDir=new File(rootDir, "features/module4")

これにより、Android Studio のレイアウトは以下のようになります。

空のモジュールが表示されなくなりました


まとめ

タイトルが示すとおり、これはちょっとしたヒントにすぎませんが、プロジェクト内の整理に役立つほか、Gradle のわずかな設定でプロジェクトがいかにすっきり整理できるかも示しています。
このアップデートは、オンデマンド モジュールのコードラボの最新版に含まれています。

リソース


Posted by Yuichi Araki - Developer Relations Team



SMS User Consent API を利用した SMS による確認の自動化

$
0
0
この記事は Sean McQuillan (Android Developer Advocate) による Medium Blog の記事 "Automatic SMS Verification with SMS User Consent" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


1 回限りのコードを使用した SMS による確認をアプリに実装する場合は、新しい SMS User Consent API を利用できます。

SMS による確認は一般に、アプリに 2要素目の認証方法を追加する場合に用いられます。「1234」または「481236」といった 1 回限りのコードを含んだ SMS メッセージがユーザーの電話番号に送信され、ユーザーがアプリにコードを入力することで、自分が SMS メッセージを受信したことを確認できます。
差出人: SMS
メッセージ: あなたの 1 回限りのコードは 1234 です。
しかし、率直にいって、1 回限りのコードを入力する作業が好きなユーザーはいません。面倒なうえ、エラーの原因になります。そのため、アプリの確認という目的を果たすだけでなく、そのエクスペリエンスをできるだけシームレスなものにすることが重要です。

SMS User Consent API を使用すると、ユーザーに対して、1 回限りのコードを含んだ 1 通の SMS メッセージの読み取り許可を求めるプロンプトをアプリから表示できます。その後、アプリでメッセージを解析したうえで、SMS による確認のフローを自動的に完了できます。

1 回限りのコードを含んだ 1 通のテキスト メッセージの読み取り許可をユーザーに求めます。

すでに SMS Retriever API を使用している場合、SMS User Consent API によって SMS Retriever API のサポートが終了したり、置き換えられたりすることはありません。SMS Retriever API をサポートするためにアプリがメッセージを変更できない場合もあることから、Google では 2 つ目の API を追加します。

SMS User Consent API を実装する前に SMS Retriever API をチェックして、ご自身のアプリで機能するかどうかを確認してください。使用できる場合、ユーザーがプロンプトをスキップできるため、利便性が向上します。

API の概要

本稿では、この API の使用に慣れるための基礎的な内容を説明します。実装例を含むこの API についての詳細は、ドキュメントをご覧ください。

SMS User Consent API は Google Play 開発者サービスの一部です。使用するには、以下のライブラリのバージョン 17.0.0 以降が必要になります。

implementation "com.google.android.gms:play-services-auth:17.0.0"

implementation "com.google.android.gms:play-services-auth-api-phone:17.1.0"

手順 1: SMS メッセージの待ち受けを開始する

SMS User Consent API は、最大 5 分間、1 回限りのコードを含んだ SMS メッセージの着信を待ち受けします。自身の開始前に送信されたメッセージにアクセスすることはありません。

SMS User Consent API は、1 回限りのコード(数字を 1 つ以上含んでいる 4~10 個の英数字)が含まれていないメッセージや、ユーザーの連絡先に登録されている差出人から届いたメッセージの場合には、プロンプトを表示することはありません。

1 回限りのコードを送信する電話番号がわかっている場合は、senderPhoneNumber を指定できます。電話番号がわからない場合は、null を指定するとすべての番号に一致します。
SMS User Consent API を開始するには、次のように SmsRetriever オブジェクトを使用します。

smsRetriever.startSmsUserConsent(

   senderPhoneNumber /* または null */)

手順 2: メッセージの読み取りに関する同意をリクエストする

アプリが 1 回限りのコードを含むメッセージを受信すると、ブロードキャストによって通知されます。この時点では、届いたメッセージの読み取りに関する同意は得られていません。代わりに、ユーザーの同意を求めるプロンプトの表示を開始できる Intent が提供されます。

BroadcastReceiver に渡された Intent を使って、SMS User Consent API のプロンプトを表示します。

BroadcastReceiver において、extras 内で Intent を使ってプロンプトを表示します。
このインテントを開始すると、1 通のメッセージを読み取る許可を求めるプロンプトがユーザーに表示されます。

ユーザーには、アプリに読み取りを許可するテキスト全文が表示されます。

val consentIntent = extras.getParcelable<Intent>(

   SmsRetriever.EXTRA_CONSENT_INTENT)

startActivityForResult(

   consentIntent,

   SMS_CONSENT_REQUEST)

手順 3: 1 回限りのコードを解析して SMS による確認を完了する

ユーザーが [許可] をタップしたら、実際にメッセージを読み取ります。onActivityResult 内で、次のように data から SMS メッセージの全文を取得できます。

val message = data.

   getStringExtra(

       SmsRetriever.EXTRA_SMS_MESSAGE)

その後、この SMS メッセージを解析して、1 回限りのコードをバックエンドに渡します。

詳細

SMS User Consent API を利用することで、ユーザーの利便性を向上させることができます。1 回限りのコードを自動的に解析することで、ユーザーは SMS による確認のフローを簡単に完了して、元の作業に戻ることが可能です。

コード全体を含む詳細については、以下のドキュメントをご覧ください。

Posted by Takeshi Hagikura - Developer Relations Team

GDG Kyushu をご紹介します。

$
0
0
前回の記事では、GDG Fukushima のメインオーガナイザーである清水俊之介さんをご紹介しました。今日は、GDG Kyushuの 共同オーガナイザーである前田恵里さんをご紹介します。

GDG のコミュニティ活動に参加されてから、どのような変化があったのか、恵里さんのストーリーをお聞きください。



GDG オーガナイザー インタビュー #2

Q: 自己紹介をお願いします。 
福岡で Web 系のエンジニアをしている前田恵里といいます。ものづくりが好きで、自分で小さなアプリを作ったり、ハッカソンに出たりして過ごしています。他のオーガナイザーに比べて技術力などはまだまだ劣ってるところが多いですが、少しでも良い方向に向かう人が増えればと思いコミュニティ活動をしています。

Q: GDG の活動に参加しようと思ったきっかけは何ですか? 
始めは Android の技術に興味があり、その関係で GDG のイベントに参加したり、お手伝いをさせてもらうことがあったのがきっかけです。その後、現在の GDG Kyushu のオーガナイザーの松岡さんに GDG のサブコミュニティである WTM (Women Techmakers) のコミュニティの立ち上げに興味はないか?とお声がけいただいて、WTM Kyushuの立ち上げと GDG Kyushu の活動に本格的に参加させてもらうことになりました。

Q: GDG の活動に参加してみて、いかがですか?何か変わったことはありますか?面白いエピソードがあれば教えてください。 
変わったこととしては、幅広い人との繋がりが持てたことだと思っています。
GDG は特定の技術のみでなく幅広いジャンルの人たちが集まれるようなコミュニティで、また、グローバルなコミュニティでもあるので、日本以外の方々とも繋がれるチャンスも多いコミュニティです。そのため、多くの刺激をもらえるコミュニティだと感じています。 
それと、私自身は英語がまったくできないのですが GDG の方々は優しい方が多く、Google I/O への参加などを通して、今まであまり興味を持っていなかった海外に惹かれるようになりました。

Q: コミュニティ活動をしていて、良かった点は何ですか? 
これは GDG Kyushu ではなく WTM Kyushu での話なんですが、女性国際デーに合わせたイベントを毎年春に、WTM では世界中でしており、今年は福岡でも行いました。その際に参加者の方何名かに LT をしていただいたのですが、その中で作りたいけど挫折してしまっていたサービスを 2 年前に WTM のイベントがきっかけで再度挑戦した、その後実際に作成することができ、自信と幸せを感じた、という内容の LT を行なってくださった方がいました。 
これは紛れものなく本人の努力の賜物だと思いますが、WTM のイベントがきっかけと言ってくださったのは嬉しかったですし、そういった方が増えるといいなと思える体験でした。私としても、その方に感謝しています。

Q: これから、GDG Kyushu として、どういったことをしていきたいですか? 
コミュニティを通して、少しでも良い方向に向かえる人が一人でも増えるようなコミュニティにしていきたいと思っています。同時に、福岡には多くのコミュニティがあるので、何かしら他のコミュニティさんと一緒にできれば良いなと考えています。




恵里さん、どうもありがとうございました。
GDG Kyushu の次回イベントは、11/2(土)に開催される DevFestです。3 日間に渡り、大分県別府市の温泉で開催されます。詳細とお申し込みは、こちらをご覧ください。


「一緒に勉強する仲間が欲しい」と思ったことがある方は、お近くの GDG コミュニティを探してみてください。


詳しくはこちら → https://goo.gle/2XfrMPK
最寄りのチャプターを探すにはこちら→ https://goo.gle/2LnOIow 



お住まいの地域に GDG がない、GDG のコミュニティ活動を新たに始めてみたいという方がいましたら、こちらのページよりぜひご応募ください。

皆さまからのご応募を心よりお待ちしております。


Posted by Takuo Suzuki - Developer Relations Team

AMP Toolbox 1.0 のお知らせ

$
0
0
この記事は Sebastian Benz による The AMP Blog の記事 "Announcing AMP Toolbox 1.0" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

少し前から存在していた AMP Toolboxが 1.0 のマイルストーンに到達しています。これを期に、きちんと紹介しておきましょう。一言で言えば、AMP Toolbox は AMP ページを簡単に公開するためのコマンドライン ツールと JS API の集合体です。それぞれのツールは個別にダウンロードして使用できます。
1.0 リリースには、2 つの大きなアップデートが含まれています。
  1. 1. AMP ドキュメント用の lint ツール: AMP Linterは、イメージの欠落や正しくないサイズのイメージ、CORS ヘッダーの欠落、無効なメタデータなどのエラーや疑わしい構造を報告します。
  2. 最適化された有効な AMP のサポート: AMP Optimizerが有効な AMP を生成するようになります。これにより、最適化された AMP ページをホストするのがとても簡単になります。詳細については、先日のブログ投稿をご覧ください。
しかし、もっとすばらしいことがあります!AMP Toolbox のその他の機能について、詳しく紹介しましょう。

AMP CLI

何より、AMP Toolbox に含まれているほとんどの機能はコマンドライン インターフェースから使うことができます。NPM からグローバルにインストールできます。
$ npm install @ampproject/toolbox-cli
$ amp help
または、NPM のビルトイン `npx` ツールを使って、都度コマンドを実行することもできます。
$ npx @ampproject/toolbox-cli help

AMP Linter

最新の toolbox-linterは、AMP ドキュメントのよくある間違いやベスト プラクティスをチェックしてくれます。
$ amp lint https://amp.dev

PASS 1x1 images are specified by <amp-pixel>
WARN All <amp-img> have reasonable width and height
> [https://blog.amp.dev/wp-content/uploads/2019/06/cf_hero.png]: actual ratio [1999/1140 = 1.75] does not match specified [16/9 = 1.77]
> [https://blog.amp.dev/wp-content/uploads/2018/10/img_20180926_163001-01.jpeg]: actual ratio [3680/2314 = 1.59] does not match specified [16/9 = 1.77]
PASS Videos are under 4MB
PASS <amp-video><source/></amp-video> syntax is used for video
PASS Endpoints are accessible from cache
PASS Endpoints are accessible from origin
FAIL <meta charset> is the first <meta> tag
> <meta charset> not the first <meta> tag
PASS Runtime is preloaded
次のようにすると、インストールせずに実行することもできます。
$ npx @ampproject/toolbox-cli lint https://amp.dev
サイトに SXGサポートを追加する場合、AMP Linter の SXG モードが非常に重宝します。
$ amp lint -f sxg https://amp.dev

PASS /amppkg/ is forwarded correctly
PASS application/signed-exchange content negotiation is correct
PASS dump-signedexchange -verify does not report errors
PASS vary header is correct

AMP Optimizer

AMP Optimizerは、AMP ページのレンダリング パフォーマンスをサーバーサイドで向上させるツールです。AMP Optimizer は AMP パフォーマンスのベスト プラクティスを実装しており、AMP のサーバーサイド レンダリングをサポートします。これらの最適化により、FCP 時間を最大 50% 短縮できます。
これを使ってみるには、CLI で次のように入力します。
$ amp optimize https://amp.dev
$ amp optimize file.html
なお、本番環境では、ビルドまたはレンダリング チェーンの一部として toolbox-optimizerを組み込む方がよいでしょう。また、Express ミドルウェア amp-optimizer-expressも利用できます。これは、AMP のサーバーサイド レンダリングをすぐに適用できるようにします。

AMP Cache URL

テストの際に、AMP ページがすべての AMP キャッシュで動作するかを確認しておくとよいでしょう。toolbox-cache-urlを使うと、オリジン URL を AMP Cache URL 形式に変換できます。
$ amp curls https://amp.dev

https://amp-dev.cdn.ampproject.org/c/s/amp.dev
https://amp-dev.amp.cloudflare.com/c/s/amp.dev
https://amp-dev.bing-amp.com/c/s/amp.dev
特定のキャッシュに対して使うには、次のようにします。
$ amp curls --cache=google https://amp.dev

https://amp-dev.cdn.ampproject.org/c/s/amp.dev

AMP Cache List

すべての公式 AMP Cache のリストを取得する API もあります。これはバックエンドで CORS を実装する際に便利です。
const Caches = require('@ampproject/toolbox-cache-list');

Caches.list().then(console.log);
場合によっては、AMP Cache の AMP ドキュメントをすばやく更新または削除しなければならないこともあるでしょう。CLI 版の AMP Update Cache APIを使うと、とても簡単に実現できます。
$ amp update-cache https://www.example.com/ --privateKey /path/to/private-key.pem
もちろん、toolbox-update-cacheパッケージに含まれる API 版も利用することもできます。

AMP CORS

CORS と言えば、amp-list や amp-state などの多くの AMP コンポーネントが CORS リクエストを使ってリモート エンドポイントを活用しています。AMP Toolbox には、AMP ページに必要なすべての CORS ヘッダーを自動的に追加する connect/express ミドルウェアが含まれています。express アプリケーションに toolbox-corsミドルウェアを追加しさえすれば、あとは CORS について何もしなくても AMP ページを提供できます。
const express = require('express');
const ampCors = require('@ampproject/toolbox-cors');

const app = express();

// That's it!
app.use(ampCors())

AMP 検証ルール

お気に入りのテキスト エディタで AMP 固有のコード補完を実現したい場合は、AMP の検証ルールを問い合わせる javascript ライブラリ amp-validator-rulesを確認してみてください。amp-img 要素のすべての有効な属性をリストするサンプルを次に示します。
import validatorRules from '@ampproject/toolbox-validator-rules';
 
validatorRules.fetch().then(rules => {
  // Get all website specific tag rules ...
  const tags = rules.getTagsForFormat('AMP');
  // ...find the definition of the amp-img tag...
  const ampImg = tags.find(e => e.tagName === 'AMP-IMG');
 
  const ampImgAttrs = ampImg.attrs
    // ...filter global, layout and amp-bind attributes...
    .filter(e => !e.name.startsWith('[') && !e.global && !e.layout)
    // ...extract the name...
    .map(e => e.name)
    // ...sort alphabetically...
    .sort();
 
  // ...and display result in the console.
  console.log(ampImgAttrs);
});

まとめ

AMP Toolbox は、コマンドラインや API でよく行われるタスクを簡単にすることを目指しています。足りない機能があると感じた方は、ぜひお知らせください

投稿者: Google デベロッパー アドボケート、Sebastian Benz

Reviewed by Chiko Shimizu - Developer Relations Team

オリジンで AMP を高速化する: AMP + SSR = ⚡

$
0
0
この記事は Sebastian Benz による The AMP Blog の記事 "Faster AMP on the origin: AMP + SSR = ⚡" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

AMP は、サーバーサイド レンダリング(SSR)と呼ばれるテクニックを正式にサポートするようになりました。AMP ページに SSR を適用すると、さらに読み込みを高速化できます。私たちのテストでは、一般的に使われている FCP 指標がなんと最大 50% も改善されました。しばらくの間、Google AMP Cache がこのテクニックを利用していましたが、今は独自のドメインでも SSR を利用できるようになっています。メインサイトで AMP を使っている場合、この最適化を追加することが特に重要です。AMP ページと非 AMP ページの両方を持つ「ペアード AMP セットアップ」と呼ばれる方法を使っている場合でも、このテクニックを利用すれば、AMP Cache を使えないユーザー(Twitter アプリを使っている場合など)に最適なパフォーマンスを提供できます。


SSRは、React や Vue.js など、クライアントサイドでページをレンダリングするフレームワークの first-contentful-paint 時間(FCP)を改善するテクニックです。クライアントサイド レンダリングの欠点は、ページのレンダリングに必要な Javascript をすべて最初にダウンロードしなければならないことです。これにより、ユーザーがページ上の実際のコンテンツを目にするまでの時間が長くなります。この点を改善するため、React と Vue.js はどちらも、ナビゲーション リクエストに応じてサーバー上で DOM を事前レンダリングできるようになっています。その後、クライアントサイドの Javascript がレンダリングを継続します。このプロセスは、(再)ハイドレーションと呼ばれます。その結果、ユーザーははるかに早くコンテンツを見られるようになります。


AMP SSR は、サーバー上で AMP ボイラープレート コードを取り除いてページ レイアウトをレンダリングすることによって動作します。AMP ボイラープレート コードが存在しているのは、ページの読み込み時にコンテンツの位置が突然変化しないようにするためです。AMP フレームワークがダウンロードされてページのレイアウトが確定するまでの間、ページのコンテンツは隠蔽されます。その結果、AMP ページでは他のクライアントサイド フレームワークと同じ問題が発生することになります。つまり、Javascript がダウンロードされるまでレンダリングがブロックされます。AMP SSR は、ボイラープレート コードを取り除くことで FCP 時間を 50% 短縮しています。SSR を適用したバージョンと適用しないバージョンとの AMP ファイルの差分を次に示します(詳しい説明は、公式ガイドをご覧ください)。





サーバーサイドでレンダリングされた AMP ページであることは、html 要素の transformed 属性からわかります。
<html amp transformed="self;v=1">
補足: AMP キャッシュは固有のフラグを設定します。たとえば、Google AMP Cache は次のフラグを追加します。
<html amp transformed="google;v=1">
この属性が設定されていると、検証ツールは SSR を適用した AMP を有効な AMP として扱います。SSR による AMP の最適化を行うと、AMP 仕様のルールが満たされなくなり、ドキュメントは無効になります。そのため、この状況を表す新しいフラグが必要になります。このフラグが存在し、最適化が行われている場合、ドキュメントは有効と見なされ、以降の処理が行えるようになります。
AMP SSR についてさらに詳しく知りたい方は、AMP チャンネルの説明動画AMP SSR ガイドをご覧ください。

AMP に SSR を適用する方法

SSR を適用した AMP を手で記述するのは無意味です。そうではなく、コンパイラのように、SSR を適用したバージョンに AMP ファイルを自動変換するツールを使います。この変換は、ユーザーがドキュメントをリクエストする前にあらかじめ行っておくのが理想的です。しかし、この処理はオンデマンドで実行することもできます(変換が何度も実行されることがないように、結果は確実にキャッシュするようにします)。
現在、AMP SSR に利用できるのは、以下の 2 つのツールです。
  1. AMP Optimizer: 最適化された AMP を生成する NodeJs ライブラリです。サイトで Expressを使っている場合、express ミドルウェアも確認してみてください。 
  2. AMP Packager: Go のコマンドライン ツールです。Signed Exchangeと合わせて利用できます。
補足: これらのツールは SSR を実行するだけでなく、AMP フレームワークのプリロードや head の並び替えなどの他の最適化も行います。

Next.js サポート

うれしいことに、最新の Next.js 9 リリースは AMP SSR をサポートしています。デフォルトで Next.js 9 は AMP ファーストなページとハイブリッド AMP ページで最適化された AMP をレンダリングします。Next.js は AMP ページの構築に適した選択肢です。

次のステップ

私たちの今後の計画には、2 つの大きなテーマがあります。
1. AMP フレームワーク(v0.js)をセルフホストできるようにします。そうです。cdn.ampproject.org から AMP をダウンロードする必要はなくなります。これには、次の 2 つのメリットがあります。
  • time-to-interactive が高速に: AMP フレームワークをダウンロードするために、cdn.ampproject.org に対してもう 1 つの HTTPS 接続を確立する必要がなくなります。
  • QA が簡単に:新しい AMP リリースへの切り替えタイミングを自由に制御できるようになります。
ただし、次の点に留意することが重要です。AMP キャッシュがキャッシュされた AMP ページを提供する際は、プライバシー上の理由により、AMP スクリプトの URL をキャッシュのオリジンと一致するように書き換えます。
2. WordPress 統合: 正式版 AMP wordpress プラグインの v1.3 は、AMP SSR をサポートする予定です。

AMP SSR は誰でも使えます

AMP ページを公開している方は、サーバーサイドでレンダリングした AMP ページを公開するようにしてください。AMP OptimizerGo 変換ツールの実行は、HTML や CSS の縮小と同じように日常的なビルド / レンダリング チェーンの一部にするとよいでしょう。レンダリング パフォーマンスの向上により、FCP 時間は大きく改善されます。しかし、さらに重要なのは、ユーザー エクスペリエンスが改善されることです。

投稿者: Google デベロッパー アドボケート、Sebastian Benz

 Reviewed by Chiko Shimizu - Developer Relations Team

モーショナル インテリジェンス: スマートなアニメーションを作成する

$
0
0
この記事はデベロッパー アドボケイト Nick Butcher による Android Developers - Medium の記事 "Motional Intelligence: Build smarter animations" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。



イラスト: Virginia Poltrack

今年の Google I/Oでは、Android アプリでスマートなアニメーションを記述するいくつかのテクニックについてお話ししました。特に詳しく説明したのが、リアクティブ アーキテクチャが使われている場合にアニメーションをうまく動作させる方法です。

要約すると

32 分の動画は見たくないという方もいるでしょう。そういう方のために、かいつまんで説明します。

#AnimationsMatter

私は、アプリのユーザビリティにとってアニメーションは重要だと考えています。アニメーションを使うと、状態の変化や遷移について説明したり、空間モデルを確立させたり、注目を集めたりすることができます。また、ユーザーはアプリについて理解しやすくなり、ナビゲーションにも役立ちます。



アプリのアニメーション フロー
👈アニメーションがあるとき、ないとき 👉

この例は、アプリの同じフローを示していますが、左側はアニメーションが有効になっており、右側は無効になっています。アニメーションがないと、何が変化したのか説明がないまま突然状態が変わることになるので、唐突な印象を与えます。
私がアニメーションは重要だと考えるのはそのためですが、一方で、最近のアプリのアーキテクチャの変化によって、アニメーションの実装が難しくなっているとも感じています。一般的には、ほとんどの状態管理機能をビューレイヤーの外に出してコントローラ(ViewModel など)に移し、コントローラが何らかの状態オブジェクト(ビューのレンダリングに必要になるアプリの現在の状態をカプセル化した UiModel など)を発行しています。データモデルで何かが変化すると(ネットワーク リクエストの応答やユーザーが開始したアクションの完了など)、更新された状態全体をカプセル化した新しい UI モデルが発行されます。



ViewModel が状態オブジェクトのストリームを発行する
ViewModel が状態オブジェクトのストリームを発行する

この記事では、このパターンやそのメリットについては特に取り上げません。これらを説明した優秀なリソースはたくさんあります。一方向データフロー(Uni-directional Data Flow)や MVI について検索するか、MvRxMobiusなどのライブラリを調べてみてください。ここで注目するのは、このストリームのもう一方の端、すなわちビューがモデルのストリームを監視し、それを UI にバインドする部分です。これは、ある新しい状態が与えられると、それを UI に対して完全にバインドする純粋な関数のように思えます。UI の現在の状態のことは考えたくありません。つまり、データを UI にバインドする操作はステートレスであるべきです。しかし、アニメーションはステートフルです。アニメーションとは、時間とともにある値から別の値に遷移させる操作だからです。この点が、本投稿で着目したい本質的な矛盾です。現在、この矛盾のために多くのアプリでアニメーションが削除され、実際にユーザビリティの低下につながっています。
……データを UI にバインドする操作はステートレスであるべきです。しかし、アニメーションはステートフルです

問題は何か

では、どうすればこのリアクティブな世界でアニメーションを維持できるのでしょうか。また、どのような課題に対処しなければならないのでしょうか。これについて具体的に考えてみましょう。ここでは、最小限の例として、ログイン画面を取り上げます。



ログインボタンと進捗インジケーターが表示、非表示されるときにフェードインまたはフェードアウトするログイン画面
ログインボタンと進捗インジケーターが表示、非表示されるときにフェードインまたはフェードアウトするログイン画面

ユーザーがログインを押すと、ログインボタンを隠して進捗インジケーターを表示しますが、その際にログインボタンをフェードアウト、進捗インジケーターをフェードインします。
この画面の状態オブジェクトと(静的)バインディングのロジックは、次のようになります。

この変更を アニメーションさせたい場合、最初に考えるのは次のようなコードでしょう。ここでは、alpha プロパティをアニメーションさせようとしています(フェードアウトの場合は、最後に visibility の値もセットします)。

しかし、これは予期しない結果になります。



リアクティブ アプリにアニメーションを追加する際に起きがちな問題
リアクティブ アプリにアニメーションを追加する際に起きがちな問題

ここでは、キーを押すたびに新しい UI モデルが発行されています。しかし、本来表示されるべきではない進捗インジケーターが表示されていることがわかるでしょう。また、送信ボタン(デモ用にアニメーション時間を長くしています)を押すと、ボタンと進捗インジケーターの両方が消えてしまうというおかしな状態になります。この原因は、アニメーションにエンドリスナーなどの副作用があり、それが正しく処理されない点にあります。
リアクティブの世界でアニメーションを記述する場合、アニメーションのコードはいくつかの特性に従わなければなりません。ここでは、その特性を以下のように分類します。
  • リエントラント
  • 連続
  • スムーズ

リエントラント

リエントラント(再入可能)とは、いつでもアニメーションの中断や再呼び出しが可能でなければならないということです。新しい状態オブジェクトがいつ発行されるかわからない場合、実行に新しい状態がバインドされることをすべてのアニメーションで考慮しなければなりません。そのためには、実行中のすべてのアニメーションをキャンセルまたは再ターゲットでき、副作用(リスナーなど)もクリーンアップできる必要があります。

連続

連続とは、アニメーションの対象となる値が突然変化してはいけないことを指します。この特性を説明するために、タッチしたり離したりすると、大きさと色がアニメーションするビューについて考えてみましょう。



タッチすると大きさと色がアニメーションする
タッチすると大きさと色がアニメーションする

アニメーションを最後まで実行すれば何の問題もありませんが、すばやくタップすると大きさや色が突然変化します。これは、バインディングのコードに、「フェードのアニメーションは必ず alpha が 0 の状態から始まる」などの誤った前提が含まれている結果です。

スムーズ

この特性について理解するために、イベントに応答して左上または右上にビューをアニメーションさせる例を考えてみましょう。



スムーズでないアニメーション
スムーズでないアニメーション

すばやく連続して 2 回右上に移動させようとすると、ビューは途中で一度止まってからゆっくりと目的地に向かい続けます。移動中に目的地を変えると、同じように一度止まってから突然方向を変えます。このような突然の停止や方向転換は不自然に見えます。現実の世界では、このように動作するものはないからです。スムーズなアニメーションを実現するには、こういったタイプの動作を避ける必要があります。

修正する

では、先ほどの可視性をバインドする関数に戻り、問題を修正してみましょう。まずは、連続性について見てみます。先ほどの alpha アニメーションは、常に初期値から最終値、たとえばフェードインの場合は 0 から 1 に変化するものでした。代わりに、初期値を省略して最終値のみを与えるようにします。


初期値を省略した場合、アニメーターは現在の値を読み取ってそこから開始します。これこそがまさに実現したいことです。これにより、アニメーションするプロパティの値が突然変わる事態を防ぐことができます。

次に、関数をリエントラントにしていつでも呼び出せるようにします。まず、少しばかり怠けて、不要な作業は行わないようにします。ビューが既に目標値になっている場合は、すぐに処理を終了します。


続いて、新しいアニメーションを始める前にキャンセルできるように、実行中にアニメーターとリスナーを保存する必要があります。論理的に考えれば、これを保存すべき場所はビュー自身ですが、View にはこれを行う便利な仕組みが既に備わっています。それが ViewPropertyAnimatorです。これは View.animate() を呼び出した際に返されるオブジェクトで、新しいアニメーションを開始した際に、あるプロパティに対して現在実行されているアニメーションがあれば、それを自動的にキャンセルしてくれるという優れものです。

ViewPropertyAnimator は withEndActionメソッドも提供しています。これは、アニメーションが正常に完了した場合のみ実行され、キャンセルされた場合には実行されません。これも私たちが望む動作そのものです。つまり、新しい目標値が入ってきてアニメーションがキャンセルされた場合でも、副作用(先ほどの可視性の変化など)は起こりません。ViewPropertyAnimator に切り替えることで、関数はリエントラントになります。


ViewPropertyAnimator は、同じプロパティに対して実行中のアニメーションがある場合、そのアニメーションをキャンセルしてから新しいアニメーションを開始すると説明しました。これはスムーズの特性と相反します。そのため、先ほど見たように、アニメーションが突然止まって別のアニメーション(同じ時間で距離が短いアニメーション)が始まることになり、アニメーションがスムーズでなくなる可能性があります。これに対処するため、ほとんどのデベロッパーにとっておなじみではないと思われるアニメーション ライブラリに着目します。

spring による補間

spring は、「dynamic-animation」Jetpack ライブラリの一部です。このライブラリの派手なサンプル アニメーションを見て、これは不要だと思った方は多いかもしれません。派手な効果は役立つこともありますが、常に必要または望まれるとは限りません。しかし、このような派手な動きは 無効にすることもでき、その場合でも物理モデルに基づいたアニメーション システムは使うことができます。このアニメーション システムには、汎用的なアニメーションに役立つたくさんの特性が備わっています。特に便利なのは、中断と再ターゲットです。

先ほどの例に戻りましょう。これを spring アニメーションを使って実装し直すと、スムーズさの問題が起こらなくなります。現在の速度を踏まえつつ、目的地を変えてアニメーションを開始し直してくれるので、スムーズなアニメーションを実現できます。



spring ベースのアニメーションでは、再ターゲットしても速度が維持される
spring ベースのアニメーションでは、再ターゲットしても速度が維持される

SpringAnimationの記述は、通常の Animator の記述とよく似ています。メリットの大半は、start() を呼び出す代わりに animateToFinalPositionメソッドを使用することで得られます。このメソッドは、まだ開始されていない場合はアニメーションを開始しますが、重要なのは、実行中のアニメーションがある場合、突然値を変えるのではなく、勢いを維持したまま新しい目的地に再ターゲットしてくれることです。

残念ながら、spring は View.animate のような便利な View API から使うことはできません(Jetpack のみの機能です)。しかし、次のような拡張関数を作成することはできます。

この拡張関数は、指定された ViewProperty平行移動、回転など)に対する spring を作成または取得し、ビューのタグに保存します。これを使えば、animateToFinalPosition メソッドを使って簡単に実行中のアニメーションを更新できます。可視性をバインドする関数でこれを使うと、次のようになります。


さらに、終了アクションを切り替えて、spring アニメーションのエンドリスナーを使う必要があります。完全なコードはこちらの gistから参照できます。アニメーションをある程度カスタマイズしたい場合もあるでしょう。通常のアニメーションでは時間や補間方法を指定しますが、spring はそれとは異なり、弾性(stiffness)や減衰率(damping ratio)を設定することでカスタマイズします。適切なデフォルト値を指定しつつ、関数の呼び出し元から簡単にカスタマイズできるように、拡張関数を変更してこれらのパラメータを受け取れるようにすることもできます。完全な実装はこちらをご覧ください。

以上で、可視性のバインドはリエントラント、連続、スムーズという特性を備えるようになりました。これを実現するのは大変だと思うかもしれませんが、実際に必要になるのはいくつかのバインド関数だけです。この関数は、アプリ全体で使い回すことができます。この spring テクニックを簡単に使用できるようにパッケージ化したライブラリはこちらです。

アイテム アニメーター

このタイプのアニメーションを使った別の例を見てみましょう。先ほどの原理を RecyclerView.ItemAnimatorに適用したものです。



DefaultItemAnimator と spring ベースの ItemAnimator
👈 DefaultItemAnimator と spring ベースの ItemAnimator 👉

この例は、シャッフル ボタンを押してアニメーションを実行している間にデータセットがアップデートされる状況をシミュレートしています。すばやく 2 回ボタンを押した場合、spring ベースのアニメーターのスムーズさはまったく違うことに注目してください。左側では、ボックスが止まってから方向が変わります。右側では、スムーズに方向が変わります。ほとんどのアプリは、ネットワークの複数の場所から情報を読み込んで RecyclerView に表示しているはずです。アニメーションにこのような柔軟性を持たせることで、アプリの洗練度が上がり、はるかにスムーズな体験を実現できるようになります。このタイプのアニメーターを Plaid サンプルに追加した際の PR はこちらです。

スマートなアニメーション

皆さんがリアクティブなアプリにアニメーションを記述する際に、この投稿で説明した原理が役立ち、ユーザビリティの改善につながることを期待しています。実は、この原理は次のような順位のリストで表現できます。



アニメーションのニーズ階層
@crafty によるアニメーションのニーズ階層

リエントラントであるということは、正確であるということです。この特性がないと、アニメーションが壊れる可能性があります。ViewPropertyAnimator を使うか、中断されたり再呼び出しされたりする可能性があることに注意してアニメーションのコードを書くようにします。

連続性とは唐突な変化を避けることで、ユーザー エクスペリエンスの向上につながります。これは、アニメーションのコードから誤った前提を削除し、アニメーション間の引き継ぎを簡単にすることで実現できます。

スムーズさは、ケーキ 🎂のアイシングのようなものです。アニメーションを自然に見せ、動的な変化や中断、再ターゲットに対応できるようにします。

アニメーションを使うと、アプリは楽しくなるだけでなく、わかりやすくもなります。私はそう確信しています。ぜひこのテクニックを習得し、うまくアプリに組み込めるようにしておきましょう。

Reviewed by Yuichi Araki - Developer Relations Team


Viewing all 2207 articles
Browse latest View live