Google Identity は、データの保護において Google を信頼してくださっている Google アカウント ユーザーに充実した機能を提供すべく、日々努力を重ねています。同時に、ユーザーにすばらしい体験を提供するアプリを作るデベロッパー コミュニティにも貢献したいと考えています。Google とデベロッパーとの連携により、ユーザーは次の 3 つの重要な方法でデータの共有を管理できるようになっています。

  1. 誰が自分のアカウント データにアクセスできるかを決定する際に、ユーザーは対象を細かく制御できます。
  2. ユーザーが Google アカウントのデータをアプリと共有することにした場合、簡単かつ安全な操作で共有できます。
  3. 具体的にどんなデータをアプリと共有しているかを、ユーザーに明らかにします。

    現在行っていること 以上の内容を実現するため、ユーザーが簡単にアプリとデータを共有できるようにする OAuth の同意操作についてお知らせします。この操作は、一度に 1 つのスコープしかリクエストできない段階的な認証を使っているアプリで、同意コンバージョン操作を改善するものでもあります。ユーザーは、この種のリクエストに対して、1 回のタップで簡単に共有できるようになります。
    サンプルアプリがアカウント情報にアクセスする際のこれまでの画面と新しい画面のスクリーンショットの比較
    これまでの画面                                           新しい画面

    簡単な復習 OAuth の同意フローに対して行ってきた作業の全体像が把握できるように、これまでの改善内容を簡単にまとめておきましょう。

    2019 年の中頃に、    同意画面を大幅に改訂し、アプリと共有するアカウント データをユーザーが細かく制御できるようにしました。このフローでは、アプリが複数の Google リソースへのアクセスをリクエストすると、ユーザーには 1 つのスコープにつき 1 つの画面が表示されていました。

    2021 年 7 月には、ユーザーが共有するデータを細かく制御できる機能は維持したまま、複数の権限リクエストを 1 つの画面にまとめました。今回の変更は、この操作の改善の延長線上にあります。
    サンプルアプリがアクセスできる内容を選択する画面のスクリーンショット
    Identity チームは、今後もフィードバックを集め、Google Identity サービスやアカウント データの共有に関する全般的なユーザー エクスペリエンスをさらに向上させたいと考えています。

    デベロッパーが行うべきこと
    アプリで必要になる変更は何もありません。ただし、段階的な認証を使って、アプリが必要とするときに一度に 1 つずつリソースをリクエストすることをお勧めします。そうすることで、アカウント データをリクエストする必要性がユーザーに伝わりやすくなるので、同意コンバージョン率が増加するはずです。    段階的な認証の詳細は、デベロッパー ガイドでご確認ください。

    一度に複数のリソースが必要なアプリで一部しか同意されなかった場合は、問題が起きないように処理し、    OAuth 2.0 ポリシーに従って適切に機能を縮退してください。

    関連コンテンツ
    • Google OAuth と API で Google アカウントの権限を細かく制御する
    • Project Strobe: データの保護、サードパーティ API の改善、コンシューマ Google+ の提供終了
      Reviewed by       Eiji Kitamura - Developer Relations Team


日程: 第 1 週のチャレンジは、今週月曜日 2020 年 7 月 6 日に公開されています。

 チャレンジ概要: 第 1 週は、Flutter の特に基本的な構成要素の 1 つである Stack ウィジェットから始まる予定です。Stack を使うと、描画順にウィジェットを重ねることができます。グラデーションの上にテキストを重ねる、素敵なカスタム デザインを作るなど、シンプルなシナリオで利用できます。

次に示す埋め込みの CodePen では、Stack ウィジェットを使って 3 パネルビューを作成しました。[Run Pen] をクリックして、実際のアプリをご覧ください。さらに [Flutter] をクリックすると、アプリの実装コードを確認できます。




チャレンジに参加しましょう！


CodePenチャレンジのページを確認して最新のチャレンジ内容を確認してください。チャレンジで作成したFlutter Pen や、皆さんがこれまでに Flutter Pen を使った作品もぜひ #FlutterPen ハッシュタグを使って共有してください。


Reviewed by Takuo Suzuki - Developer Relations Team and Hidenori Fujii - Google Play Developer Marketing APAC



デベロッパーは、既存のスマートホーム プラットフォームをベースに、この SDK を使って Google Home スマート スピーカーや Nest スマート ディスプレイによるローカル実行パスを構築できます。それにより、スマート端末とアシスタントとの密接な統合が実現します。スマート スピーカーやスマート ディスプレイ上で JavaScript を動作させることで、新しいスマート端末や既存のスマート端末を制御するビジネス ロジックを実行できるので、遅延を減らし、高い信頼性を実現して、ユーザーにメリットをもたらすことができます。

動作の仕組み

SDK には、2 つの新しいインテント IDENTIFY と REACHABLE_DEVICES が導入されています。ローカル ホーム プラットフォームは、mDNS、UDP、UPnP を使ってユーザーのホーム ネットワークをスキャンし、アシスタントに接続されているスマート端末を検出します。そして、IDENTIFY を呼び出し、端末 ID がおなじみの Smart Home API の SYNC インテントから返される端末 ID と一致することを検証します。検出した端末がハブまたはブリッジだった場合は、REACHABLE_DEVICES が呼び出され、ハブはローカル通信のプロキシ端末として扱われます。Google Home から端末へのローカル実行パスが確立すると、ホームグラフの端末プロパティが更新されます。



図 2: それぞれの実行パスに使われるインテント


ユーザーがローカル実行パスを持つスマートホームの Action を呼び出すと、アシスタントはデベロッパーのクラウド フルフィルメントではなく、Google Nest 端末に EXECUTE インテントを送ります。デベロッパーの JavaScript アプリが起動し、そのアプリが Local Home SDK を呼び出し、TCP、UDP ソケット、HTTP/HTTPS リクエストのいずれかを使ってスマート端末に制御コマンドを送ります。クラウドではなくローカル実行をデフォルトにすることで、ユーザーのリクエストに迅速に対応できます。ローカル実行が失敗した場合、実行リクエストはクラウドパスに送られます。この冗長性により、リクエストが失敗する可能性を最低限に抑えることができるので、全体的なユーザー エクスペリエンスが向上します。

他にも、Local Home プラットフォームには次のような機能があります。
  • 2 段階認証を有効化することなく、Wi-Fi 対応の端末タイプと端末特性をすべてサポート
  • ユーザーがアクションを行わなくても、すべての端末で Local Home を利用可能
  • 検出プロトコルとホストする JavaScript アプリの URL を Actions コンソールから簡単に設定

図 3: Actions コンソールの Local Home 設定ツール


JavaScript アプリは端末上でテストできるので、デベロッパーは Chrome Developer Console などのおなじみのツールを使ってデバッグできます。また、Local Home SDK は既存のスマートホーム フレームワークと連携して動作するので、新しいアプリはスマートホーム用テストスイートを使って自己検証することもできます。

使ってみる

Local Home プラットフォームの詳細については、API リファレンスをご覧ください。また、デベロッパー ガイドやサンプルを参考にして、ローカル実行を試してみてください。スマート端末を Google アシスタントに接続する方法など、汎用的な情報については、スマートホームのドキュメントにアクセスするか、今年の Google I/O でお話ししたスマートホーム向けのローカル テクノロジーについて確認してください。
フィードバックは、バグトラッカーから送ることができます。または、/r/GoogleAssistantDev からコミュニティにお知らせいただいても構いません。ディスカッションを整理するために、投稿には local-home-sdk タグを付けてください。

[1] 米国内でのみ販売される製品も含まれています

Reviewed by Yoshifumi Yamaguchi - Developer Relations Team, Johan Euphrosine - Developer Relations team



「自分には無理」と思ったあなた！GSoC 経験者で Google 東京 R&D センターで働いているソフトウェア エンジニアの体験談（2012 年、2011 年、2010 年）をご覧のうえ、日本語で GSoC 関係者や経験者に質問したい方はぜひ GSoC メーリングリスト（日本語） をご利用ください。経験者曰く、GSoC に参加するのに必要なのはコードを書く情熱とほんのちょっとの勇気です。

さあ、プロジェクト一覧を見て、開発者に問い合わせてみましょう。

応募期間: 日本時間 2014 年 3 月 11 日（火）04:00 〜 3 月 22 日（土）04:00
（UTC 協定世界時 2014 年 10 月 10 日（月）19:00 〜 3 月 21 日（金）19:00）

皆様の参加をお待ちしております。


2012 年の Google Summer of Code プログラムには、1,212 名の学生の皆さんが参加することになりました。学生の皆さんの、コミュニティでの活動が始まります。まずは、メンターと知り合いになり、ドキュメントを読み、IRC チャネル（ハッシュタグは #gsoc）でハングアウトを行い、5 月末に実際にコーディングを行う前に、コミュニティに慣れ親しみましょう。

今年の Google Summer of Code では 180 もの組織が参加しています。これらの組織やスケジュールについてもっと知りたい場合には、Google Summer of Code のプログラムサイトをご覧ください。

今回、参加される学生の皆さん、おめでとうございます。刺激的で実りの多いプログラムとなることを楽しみにしています。


Google Summer of Code 2012 （以下 GSoC） の学生申し込みが始まりました。プログラミングが好きな学生のみなさん、5,000 ドルを得るチャンスです。GSoC は 2005 年に始まった、学生とオープンソースコミュニティを結びつける奨学プログラムです。GSoC ではオープンソースコミュニティが学生の皆さんにやってもらいたいプロジェクトのアイデアを用意します。学生のみなさんはこれらのプロジェクトアイデアを元に自分がやりたいことを提案します。もちろん自分独自のアイデアを提案することも可能です。プロジェクト案が採択されたら、メンターとともにプロジェクトの完遂を目指します。メンターはプロジェクトを進めるにあたって適宜アドバイスを提供します。プロジェクトを終えることができれば 5,000 ドルを手にすることができます。そして何より、あなたが書いたコードが世界中で使われるのです。こんなにエキサイティングなことはありませんよね？

私は 2008 年に学生として参加し、2009 年にはメンターとして参加しました。オープンソースコミュニティに本格的に関わるのが初めてだった自分にとって、このときの経験は得難いものになりました。コードをレビューしてもらうことでソフトウェアのデザイン方法やイディオムなどを、自分で勉強するよりもはるかに速いスピードで学ぶことができました。コードをレビューする立場になった時も、問題に対するさまざまなアプローチがあることを知るよい機会になりました。オープンソース活動をしていない学生にとって、他人と協力してコードを書く機会はさほど多くありませんし、人が書いたコードをレビューすることもめったにないでしょう。GSoC はそのような機会を与えてくれる場でもあります。

GSoC に興味はあるけれど応募を躊躇してしまうこともあるかもしれません。私自身がそうであったように、英語でのコミュニケーションに不安を覚えたり、達成できそうなプロジェクトアイデアを見つけられなかったり。過去のエントリ記事にある体験談（2011 年、2010 年）をぜひご覧ください。過去の参加者も同じような不安を抱えていました。GSoC に参加するのに必要なのはコードを書く情熱とほんのちょっとの勇気です。

GSoC 2012 では現在、各オープンソースコニュニティがプロジェクトアイデア公開し、学生の皆さんの応募を待っている段階です。オープンソースコミュティの一覧からプロジェクトアイデアを探してみてください。学生の応募締め切りは 4/6 19:00 （UTC）です。みなさまの応募をお待ちしています。