Local blog for Japanese speaking developers
Google for Startups Accelerator Tokyo Class 2 のプログラム参加企業が決定しました
2020年2月17日月曜日
2019 年 11 月 19 日より募集を開始していました、AI や機械学習を活用したスタートアップを対象に実施する 3 か月集中型のプログラム
Google for Startups Accelerator
の参加企業が下記の 9 社に決定しました。
参加企業一覧
Baobab
: 学習データ ( アノテーション ) 作成サービスを提供
チャネルトーク
: CX 用のチャットツールと実店舗のアナリティクスサービスを提供
KARAKURI
: 顧客対応やカスタマーサポートのオートメーションサービスを提供
LeapMind
: 組込み Deep Learning 導入に向けたサービスを提供
LPIXEL
: AI 医療画像診断の支援技術を提供
RevComm
: 電話営業や顧客対応を人工知能で可視化して、生産性向上を実現するクラウド IP 電話を提供
Selan
: 子どものお迎えと英語教育を同時に解決するサービスを提供
Singular Perturbations
: 最適なパトロール経路/安全な経路の策定および警備人員計画、犯罪要因分析などの犯罪リスクヘッジソリューションを提供
SORA
: ホテルの予約や市場データを元に料金設定業務を最適化し、収益創出の仕組み化を促進するサービスを提供
今後の流れ
今後 3 ヶ月に渡って、今回参加が決定したスタートアップを対象に、これからの成長に備えるためのツールを提供します。AI や機械学習の活用を主な要素とすることで、テクノロジーを活用した社会、経済、環境への取り組みに対する支援を加速し、ひいては、スタートアップの成長が日本経済のさらなる活性化につながることを期待しています。
INEVITABLE ja night 開催レポート - エッジデバイスの不可避な流れ
2020年2月12日水曜日
2019 年 12 月 17 日に開催した第 11 回目は、「エッジデバイスの不可避な流れ」がテーマでした。恒例の対談セッションのレポートです。パネル進行スライドは
こちら
からご覧いただけます。
スピーカー :
小泉 耕二 氏 株式会社アールジーン 代表取締役 IoTNEWS 代表
聞き手 :
小島 英揮 氏、Still Day One 合同会社 代表社員 パラレルマーケター・エバンジェリスト
エッジデバイスの流れを追いかける
小島 : 今日は小泉さんとエッジデバイスの動向を深く切り込んで行こうと思います。
小泉 : IoTNEWS の小泉です。木曜日朝の J-WAVE Morning Radio で、記事解説を担当しています。別所哲也さんの番組なので聞かれたことがある方もいらっしゃるかもしれませんね。また、木曜日の夜はフジテレビの Live News α にコメンテーターとして出演しています。
小島 : IoTNEWS についてもう少し教えていただけますか。
小泉 : IoTNEWS というと IoT に関連する技術情報がメインのコンテンツというイメージを持たれる方が多いのですが、私自身はビジネス コンサルティングの出身でどちらかというとビジネスの中でのデジタル活用をどのように行うべきかという観点で情報をお届けしています。したがって、事例やデータ活用の方法を中心にできるだけ事業に役立つことを探して、発信していくことを心がけています。
小島 : コンサルタントの方がメディアに関わるキャリアパスというのはあまり無い気がするのですが。
小泉 : コンサルタントは、基本的に 2 次情報で仕事をしていることが多いんですよ。例えば、調査会社のレポートや海外事例を参考にしながら何かを組み立てるという仕事です。したがって、コンサルタントが自ら現場に行くことは意外に少ないと思います。一方、私自身は自分でその実態を見ないと気が済まない性格なんです。
以前、日本が中国に負けているぞ、これはまずいぞという記事が新聞などで結構話題になりましたが、何がどの程度問題なのかを、そうした記事では踏み込んでいませんでした。雰囲気を伝える報道はあれど、具体的なことには触れていないわけです。実際に深センに行った方がそこで見たこと、聞いたことをすぐにブログにアップというのがもう当たり前になっていて、こうしたブログの方がよっぽど詳しい情報なわけです。
自分が知らないことはまだまだたくさんありますからね。とにかく、行って聞いて、返していく、事業会社さんであればその事業について勉強をさせていただき、そこで得たことをきちんと伝えるようにしています。
小島 : Inevitable ja night は今日が 11 回目、足掛け 2 年ほどになります。今日はエッジデバイスがテーマですが、まずは、細かいところにをいきなり入らずに、技術を俯瞰していただき、皆さんに理解してもらうこと、そして、自分ごととして考えていただけるような内容にしたいと思います。
エッジデバイスとは？
小島 : では、最初にエッジデバイスが何か、言葉の定義から入りましょう。これは、IoTNEWS さんでの定義を引用させていただいたものです。
【エッジデバイス】
エッジデバイスとは、別々のネットワーク間同士で通信をし、データの効果や統合、同期などをシームレスに仲介する機器のことをいう。
ルーターやスイッチのように LAN 環境におけるデータ交換や切り替えをしたりするものから、多数のネットワークのそれぞれのゲートウェイを接続するものまで幅広い製品が存在している。
出典 :
IoTNEWS
小泉 : 自動車もある種のエッジデバイス（実際にはエッジデバイスの集合体）と捉えることができます。クラウドとは対極の概念ですね。
小島 : この定義からすると、個々の端末、デバイスに処理系があるイメージですね。一方、IoT はそこには処理だったりインテリジェンスが必ずしもあるわけではないですよね。
小泉 : そうですね。温度センサーや光センサーといった、データを取得するものは IoT と呼んでいます。
小島 : ということは、IoT はデータを送るために通信が関与しているわけですね。一方、エッジデバイスはそれ自体が独立して何かを処理するもの、こんなイメージでしょうか？
小泉 : そういう見方も確かにありますが、実際にはさまざまな機能のものがあります。例えば、お湯を沸かすポットには、単純に温度を上げるための簡単なチップが埋め込まれています。しかし、自動車には高性能なチップが搭載されているわけじゃないですか。ですから、単純なものから複雑なものまで、これらを総称してエッジデバイスと呼んだほうがいいかもしれません。
小島 : では、エッジデバイスで具体的にはどんなものがあるでしょう？ TPU がエッジデバイスというのは衝撃的ですよね。
小泉 : ここ数年は曲がる基板が話題です。たとえば、ゴルフクラブのグリップにぐるぐると巻きつけるタイプのものがあります。クラブを振る速度を測るわけです。また、腕時計のバンドの部分に埋め込むというものもあります。物理的にデバイスを小さくする方向もありますが、これらのように一定の大きさを保ちつつ曲げることができる素材もあります。
したがって、コンピュータの処理能力で分類することもありますが、物理的にどういう性質を持っているかという分類もありますね。
小島 : カメラとの融合もありますね。撮影した情報をそのデバイスで処理してすぐに何かを制御するというものです。
小泉 : はい。さらに、自動運転の技術の一部の機能を切り出して使うこともありますね。無人搬送車（AGV）は決められた軌道を通るものですが、これまではビニールテープなどを床に貼るなどして軌道を最初に示しておく必要がありました。しかし、最近はロボット自身がセンシングして自ら移動経路を決めることが可能です。これも、エッジデバイスの進化に寄るところが大きいですね。
小島 : 別な観点ではいかがでしょうか？ 情報システムの歴史を振り返ると、ホストから始まって、クライアント サーバーの分散時代に移り、クラウドで再び集約し、そしてまた分散へと集中と分散を繰り返していますよね。
小泉 : そうですね。行ったり来たりしています。処理もそうですが、データを一箇所に集めるべきか、分散管理すべきかという議論は良くあります。
ある工場でのお話ですが、データを一箇所に集約してどうするのという議論がありました。いろいろなデータを一箇所で集中的に管理するのは良さそうな感じもするのですが、最近ではエッジ側が保持するデータ量もそこそこになってきていて、それをすべて一箇所で管理することが現実的では無くなってきています。クラウドがすべてという流れも変わってきているのではないでしょうか。
エッジデバイスが求められる理由
小島 : 次に、エッジデバイスが求められる背景を整理したいと思います。次の図は、上段がエッジデバイスに対するニーズ、下段がユースケースを列挙したものです。
遅延が起きては困る状況、通信環境が整備できない状況、つまりオフラインの状況については詳しい説明は不要かもしれませんね。プライバシーやセキュリティに関しては、外部にデータを出せない、クラウドにはデータを上げずにエッジ側だけで処理したいというニーズはありますよね。これらは、クラウドを推進する際に良く出てくる話題でもありますね。
小泉 : センサーデータをクラウドに上げること無く、エッジ側で処理できたら良いというケースはたくさんありますよね。
小島 : 下段はユースケースですが、これも良く出てくる AI と VR/AR（xR）。体験っていうのはすごい大事ですからね。
小泉 : そうですね。工場の中でタブレットをパイプの上にかざすと、センサーで取得した温度情報がタブレットのパイプの画像の上に表示されるという事例があります。パイプの内部の温度はただいま 20 ℃ ですといった感じです。VR の例ですね。
小島 : パイプの温度情報を単に表示するだけでなく、タブレット側で何か処理することもありますよね。
小泉 : カメラがその典型的な例かもしれません。カメラで撮影したものをすべてクラウドに上げるのではなくて、必要なものだけを選択して上げる。この選択という処理はエッジ側で行われるわけです。
小島 : そして、自動運転。自動運転ができるようになると、そこから技術が切り出されて、使われるようになりますよね。（ロボット）掃除機もそうですよね。
ところで、今後、エッジデバイスはどんどん進化していくと、それを使うための環境も合わせて整備するべきという意見もあります。いかがでしょうか？技術の進化と環境の整備が伴わなければ、社会実装が難しいですよね。
小泉 : はい。さらに言えば、コストも考慮すべきです。スマートシティというコンセプトはとても素晴らしいのですが、では街中にセンサーをつけて、アクチュエータを整備してとなったら、膨大な費用がかかります。
小島 : そして、利用者のコンセンサスを取ることも大切ですね。
先日、中国の杭州市に行く機会がありました。アリババの本社がある街です。そこに、顔認証だけでものが購入できる自動販売機がありました。驚きましたね。ご存知のように、中国ではバーコード決済がかなり普及しています。しかし、もうスマートフォンをかざすこともなく、顔認証で決済が行われる時代になっているわけです。
アリペイを利用する際、本人確認のため顔データを提出するのでその顔データを使っているそうです。利用者からすると便利になるなら顔データを出すことに何ら抵抗は無いわけです。ちなみに、決済のみならず、新幹線の駅への入場も顔パスでした。（顔認証ができない外国人は別の列）
気になるカメラソリューション
小泉 : カメラを使ったソリューションをいくつかご紹介したいと思います。
小島 : 生徒の状態管理というのはどのようなものなのでしょうか？
小泉 : これは、中国の展示会に出展されていたもので、授業中に居眠りをしている学生をチェックするというサービスです。
最近、一番気になっているのが工場での利用です。たとえば、工場のラインにカメラを設置し、定点観測する。ライン上を流れるものを撮影し、画像認識を経てその認識結果をロボットアームに伝えて、アームが正確に物体を掴む。対象物が多少傾いていたとしてもアームが調整してその物体を正しく掴むことができるというものです。
また、インテルが最近発表したテニスボールぐらいの大きさのカメラには加速度センサーが備わっています。先ほどの例では、カメラを工場内に固定して定点観測するのですが、こちらは逆でカメラそのものが移動し、動いている対象物を認識してロボットに伝えることができます。
小島 : つまり、カメラと物体との相対的な距離をリアルタイムで測ることができるというわけですね。とても複雑な処理ができそうですね。
小泉 : これまでは、カメラは固定されていて俯瞰した状況を撮影して、その情報を元にロボットアームが動くというものだったのですが、このカメラはアームそのものにカメラをつけることもできます。
小島 : その次の倉庫の例は？
小泉 : 倉庫に高性能なカメラを設置して、ものや人の動きを把握しようというものです。たとえば、棚にある荷物をピッキングするソリューションがあります。さらに、逆に荷物を棚のどこに収めるかを目的としたソリューションも求められています。むしろこちらの方は技術的に難しくて、荷物を間違った場所に置いてしまうことがあります。倉庫に設置したカメラがその間違いを認識できればこの問題も解決できます。加えて、いちいちクラウドにデータを上げなくても良ければ、もっと良い解決策と言えますね。
小島 : 中国でバーコード決済が広まった理由の一つは、バーコードさえ表示しておけば決済ができる、つまり導入にコストがあまりかからなかったからです。しかし、今後、顔認証で決済することになると、そのためのデバイスが大量に必要になります。その結果、誰もが手に入れられるようなコストになれば、そこで新しいユースケースができて、フィードバックがあり、さらに別なユースケースができる、そういうことが繰り返されることになります。今の中国が持つ社会実装力の高さがなせる技と言っても良いかもしれません。
ロボットアームのリアルタイム制御
小泉 : ロボットアームの分野でも面白い事例があります。1 台の産業用 PC（IPC）で複数のロボットアームを統合制御するというソリューションです（詳しくは
こちら
の記事をご覧ください）。リアルタイム OS を搭載した IPC にはロボットコントローラが実装されていて、高速ネットワーク（EtherCAT）に接続された複数のロボットアームの協調動作を制御します。ロボットアーム単体でもかなり複雑な動作をしますが、このロボットアームが複数台で協調することで、より高度で複雑な作業をすることが可能になります。
小島 : 海外のカンファレンスで、お掃除ロボットメーカーの幹部が話していたことを思い出しました。人間がロボットに対して「掃除しておいて」というと、まずは部屋の上方の埃を落として、それから床を掃除して、最後は窓を開けて換気をして・・・と一連の作業をその環境にあわせてやってくれるというものでした。
小泉 : なるほど、今日は、外は雨が降っていて窓は開けられないから、埃は落とさずに床掃除だけをしておこうとか、環境にあわせて制御が行われるということですね。
小島 : 単純なシーケンス制御だとイレギュラーなことが起きた時の対応は難しいですが、協調による制御ができれば、人間にとってかなり心地良い結果をもたらしてくれますよね。
小泉 : 指示されたことを忠実に行うだけでなく、状況をきちんと把握して、適切な判断をしながら作業を進めていくということが、このエッジデバイスの世界でも急速に進んでいくと思います。
5G 時代におけるエッジデバイス
小島 : 5G が普及したら、もっと広域で同じような複雑な制御ができそうですね。
小泉 : 5G で世の中すべてが繋がったら確かに実現はできるでしょう。しかしながら、基地局からそのデバイスまでを 5G で接続できたとしても、そのデバイスの先が本当に高速で通信できるのか、また、高速通信に耐えられるコンピュータ リソースなのかということも考える必要があります。従来に比べて良くなりそうというのは間違いないでしょうが、それが保証できるというのは時期尚早だと思います。
小島 : 5G には多数同時接続という特徴もありますよね。
小泉 : 高速通信よりも同時に多くのデバイスと接続できるという特徴の方が IoT にとって喜ばしいことですね。スマートシティを実現することを考えた際に、街中の至るところに設置される大量のデバイス、センサーを超高速で、遅延を抑えて通信できるわけですからね。
小島 : 接続先がインテリジェントな形で協調すれば、さらにいろいろなことができそうですね。
小泉 : 5G で多くのデバイスを接続すれば、クラウド側のコンピュータ リソースとエッジデバイス側のコンピュータ リソースが溶け合うというか融合するというか、どちらでも処理が可能になって、相互にカバーできる状態になります。
小島 : クラウドとエッジデバイスが 1 つの大きなコンピュータ リソースになるということでしょうか。
小泉 : そうです。たとえば、3 つのエッジデバイスが接続されているとしましょう。そのうちの 1 つが機能不全になったとしても、隣のデバイスが代わりに動くというそんな形が考えられます。自動運転カーのコンピュータの動作が、運転中におかしくなった場合、そのコンピュータを停止しようというのは自然な対応です。しかし、コンピュータを停止することはすなわち誰かがその代わりに車を制御しなければなりません。では、いきなり自動から手動運転に切り替えてしまうというのもちょっと乱暴な話で、運転手に負担をかけることになり逆に危険を伴うかもしれません。しかし、隣のレーンを走っている自動車がその異常を検知して、その車の制御を代行することができれば、手動運転の必要は無くなります。
エッジデバイス単体の性能や安全性を高めることは重要ですが、そうではなくて周辺の複数のデバイスと協調することで、自分がダメだった時に他に委ねるとか、あるいは 1 台ではできない大量のデータ処理を複数のコンピュータ リソースと協調して行うとか、そういうことが実際にできる時が近づいていると思います。
小島 : クラウドではコンテナ技術によって可搬性を高める方向の流れがありますが、エッジデバイスでも同様な動きはあるのでしょうか。
小泉 : コンテナ技術を使った機器もどんどん増えています。これが進化すれば、いずれは、ロボットアームのようなところでもコンテナ技術が使われるようになるでしょう。同じプログラムをクラウド側のリソースとエッジ側のリソースのいずれかで動かすこともできるわけです。さらにクラウドとデバイスが 5G で接続されていれば、状況に応じて、すぐに切り替えることも可能でしょう。たとえば、アームが 2 本あった時に、一方のアームの処理の負荷が高いと判断したら、すぐに他方のアームに切り替えて処理を継続するということもできます。
小島 : エッジデバイスというと決められた処理を粛々とこなすものという印象があったのですが、今の話が現実になると、いいようにやってくれる感がさらに高まりますね。協調とかオーケストレーションの世界が楽しみですね。
では最後に、エッジデバイスの今後について、小泉さんはどのように見ていますか？
小泉 : 先ほどもお話ししたように、デバイス単体が自律的に何かをするというよりも、複数のデバイスが協調することで想像以上に面白い動きをするんじゃないでしょうか。もともとプログラムのとおりに動くいわゆるシーケンス処理を得意としており、今後はデバイスに搭載されるコンピュータ リソースも増えるのでますます賢くなることは確かです。ただ、搭載できるリソースも無限ではないですから、無理やりリソースを詰め込むのではなくて、複数のデバイスで協調することで、さらに賢くしていこうという方向に向かっていると思います。
小島 : わかりました。今日はありがとうございました。
新しい Cookie 分類への AMP サイトでの対応
2020年2月10日月曜日
この記事は
Katharina Familia Almonte
による The AMP Blog の記事 "
Cookie classification on AMP
" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
投稿者: Google の AMP Project グローバル プロダクト リーダー、Katharina Familia Almonte
昨年、ウェブ全体のプライバシーとセキュリティを改善する継続的な作業の一環として、Chrome に Cookie 分類スキームを導入する計画について
お知らせしました
。この計画は、2020 年 2 月の Chrome 80 で実現される見込みです。Mozilla は、Firefox でクロスサイト Cookie の SameSite=None; Secure 要件を
実装する予定
で、新しい Cookie 分類モデルのサポートを確約しています。Microsoft は、Microsoft Edge 80 でまずは試験運用版としてこのモデルの実装を始める計画を
発表しました
。
AMP チームはユーザーのプライバシー保護に注力しています。このブログ投稿では、まもなく行われるブラウザの変更に伴い、AMP による優れたユーザー エクスペリエンスを維持しつつ、透明性とユーザーの選択肢を増加させる方法について説明します。Chrome 80 が 2 月にリリースされるので、このブログ投稿は Chrome の変更点に特化して紹介します。
Chrome の新しい Cookie 設定の説明
Chrome の新しいモデルはデフォルトで安全で、特に指定がない限り、すべての Cookie が外部アクセスから保護されるべきだという前提に立っています。デベロッパーは、クロスサイト アクセス用の Cookie を新しい Cookie 設定である SameSite=None を使って明示しなければなりません。また、クロスサイト Cookie が HTTPS 接続でのみ利用されるように、Secure 属性も追加で指定する必要があります。SameSite 値が宣言されていない Cookie は SameSite=Lax として扱われます。外部アクセスは、SameSite=None; Secure 設定のある Cookie のみが可能になります。ただし、これらが安全な接続からアクセスされることが条件です。新しいモデルの詳細については、
こちらのデベロッパー ブログ投稿
をお読みください。
影響範囲
AMP Cache でレンダリングされる AMP ページでファースト パーティ Cookie にアクセスする必要がある場合は、まもなく行われるブラウザの変更によるユーザー エクスペリエンスへの影響の有無について慎重に評価することをおすすめします。たとえば、AMP Cache からオリジン ドメインへの移動、有料コンテンツ、ログイン状態、測定、ショッピング カート機能などにファースト パーティ Cookie を利用している場合、問題になる可能性があります。利用できるソリューションは 2 種類ありますが、最適なソリューションは各サイトの具体的なユースケースによって異なり、時間とともに変化する可能性もあります。
Cookie にクロスサイト アクセスを指定する
Chrome の Cookie 分類に伴う変更によって影響を受ける AMP サイト運営者が利用できるソリューションの 1 つは、AMP ページのファースト パーティ Cookie に SameSite=None; Secure を設定することです。これにより、この Cookie がクロスサイト アクセス用のファースト パーティ Cookie であることが明示されるので、ユーザー エクスペリエンスが損なわれることはなくなります。
Set-Cookie: widget_session=abc123; SameSite=None; Secure
このアプローチによるメリットは、実装が簡単なことです。しかし、将来的に複数のサイトが利用する Cookie とは別に 1 つのサイトのみが利用する Cookie を細かく管理できる機能がブラウザで提供されることになった場合、この Cookie はクロスサイト アクセスであることが明示されているので、キャッシュされた AMP ページでユーザーがファースト パーティ Cookie をクリアするリスクが高まります。
Signed Exchange による対応
別の方法として、サイト運営者は Signed Exchange を利用して AMP Cache でレンダリングされる AMP ページでファースト パーティ Cookie がファースト パーティ Cookie として扱われる状態を実現できます。Signed Exchange は、ページの URL と元のサイト運営者のドメインを関連付けることができる新技術です。これは、ページが AMP Cache 経由で配信される場合でも、スピードのメリットを損なうことなく利用できます（
ブログ投稿
と
ガイド
をご覧ください）。ここでの Signed Exchange によるメリットは、ブラウザが外部アクセス用として明示されていない Cookie をブロックするようになっても、AMP Cache でレンダリングされるページでファースト パーティ Cookie を明示する必要がないことです。しかし、本投稿の執筆時点で、トップ ストーリー カルーセルは Signed Exchange をサポートしていないため、今のところすべてのユースケースに対処することはできません。
まとめ
以上の内容をまとめます。2 月に、新しい Cookie 設定 SameSite=None; Secure が Chrome に導入される予定です。ファースト パーティ Cookie を利用する必要がある AMP Cache ページで最適なユーザー エクスペリエンスを保証するために、サイト運営者の皆さんには、新しい設定を使ってクロスサイト アクセス用の Cookie であることを明示するか、Signed Exchange を実装することをおすすめします。ブラウザは新しい Cookie 分類モデルの採用を始めています。ユーザーが細かなプライバシー管理を行えるようにしつつ、優れたユーザー エクスペリエンスを維持するために、このブログ投稿を役立てていただけると幸いです。Chrome の SameSite Cookie の利用方法やテスト方法の詳細については、
web.dev のガイド
や
Chromium の SameSite 最新情報
に掲載されているヒントをご覧ください。
Reviewed by
Chiko Shimizu - Developer Relations team
2020 年 2 月の SameSite Cookie の変更: 知っておくべきこと
2020年2月7日金曜日
この記事は Chrome およびウェブ プラットフォーム パートナーシップ、Barb Smith による Chromium Blog の記事 "
SameSite Cookie Changes in February 2020: What You Need to Know
" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
今月の Chrome 80 安定版のリリースより、Chrome はデフォルトで安全な新しい Cookie 分類システムを強制するようになります。これにより、SameSite 値を宣言していない Cookie は
SameSite=Lax
の Cookie として扱われます。サードパーティ コンテキストで利用できるのは
SameSite=None; Secure
が設定されている Cookie のみになり、それも安全な接続が使われている場合に限られます。
この変更は、2019 年 5 月に初めて
発表され
、それに合わせて
デベロッパー ガイド
が公開されました。また、2019 年 10 月に
リマインダー
と追加情報をお知らせしました。ロールアウトが迫っているため、次の動画と情報を確認して今後の変更について認識し、対応していただくようお願いいたします。
リリースのタイミング:
Chrome 80 の安定版リリースは、2 月 4 日から始まりました。Chrome 80 は、2 月中に一部のユーザーに対して新しい Cookie 分類システムを強制するようになり、対象は徐々に拡大されます。ロールアウトのタイミングや手順に関する最新情報は、
SameSite 最新情報ページ
をご覧ください。 ブラウザがアップデートされたかどうかを確認するには、
こちらのページ
にアクセスしてください。すべての列が緑色になっている場合、ブラウザに新しいデフォルトが適用されています。
デベロッパー ツールのコンソールの警告:
必要な設定が行われていないクロスサイト Cookie がページに含まれている場合、デベロッパー ツールのコンソールに警告が表示されます。自分のサイトを参照しているときにデベロッパー ツールに次のような警告が表示される場合、サイトの機能を実現している Cookie が適切に設定されていない可能性があります。次に、Chrome 80 のデベロッパー ツールの警告を示します。以前のバージョンの Chrome（77 以降）でも同様の警告が表示されます。
例外となるのは、サービスが冗長な Cookie のペアを発行しており、一方の Cookie に新しい設定、もう一方の Cookie に互換性のないクライアント用の以前の設定が含まれている場合です。この場合、サービスが意図したとおりに動作するにもかかわらず、以前の Cookie によって警告が表示されることがあります。このアプローチについては、
こちら
に記載があります。
Google の Cookie:
一部の Google のサービスでは、上記のアプローチを採用し、新しい設定の Cookie と 以前の設定の Cookie を発行しています。そのため、Google のサービスは意図した通りに動作するにもかかわらず、Google の Cookie に関する警告がデベロッパー ツールのコンソールに表示される場合があります。
移行による一時的な影響
:
クロスサイト Cookie のプロバイダが Chrome 80 リリースの直前に Cookie をアップデートした場合、Chrome 80 を使っている既知のユーザーや復帰したユーザーが一時的に未知のユーザーや新しいユーザーに見える可能性があります。これは、ユーザーの Cookie が新しい設定に更新されると、元通りになります。それよりも前にあらかじめ Cookie を更新していたプロバイダは、ユーザーが新しい設定の Cookie を受け取れる時間が長くなるため、この影響を受けにくくなります。
ログインフローに関する一時的な対処法:
認証の過程でウェブサイトとサードパーティ プロバイダの間で Cookie が渡される場合、ユーザーのログイン操作に影響を与えないようにするため、Chrome には「Lax + POST」として知られている一時的な対処法が導入されています。これにより 2 分間、トップレベルのクロスサイト POST リクエストに SameSite 設定を指定していない Cookie を利用できます。トップレベルのクロスサイト POST リクエストは、ログインフローによく使われます（これにより、トップレベルのクロスサイト GET リクエストの動作が変更されることはありません。トップレベルのクロスサイト GET リクエストでは、SameSite が「Lax」の Cookie が送信されますが、「Strict」の Cookie は送信されません）。この対処法は、新しいモデルに関する
Chromium トラッカー
で説明されています。サードパーティ ログイン サービスを使用または提供している方には、ただちにログインフローをテストすることを強くおすすめします。
エンタープライズ ポリシー:
ログインなどのサービスや社内アプリケーションが Chrome 80 の変更に対応できない場合、企業の管理者は
特別なポリシー
を実装し、Chrome ブラウザを一時的に以前の動きに戻す必要があるかもしれません。
テストとトラブルシューティング:
新しいモデルでサイトやサービスがどのように動作するかを確認するには、Chrome 76 以降で [SameSite by default cookies] および [Cookies without SameSite must be secure] 試験運用版フラグを有効にしてテストすることを強くおすすめします（フラグは、chrome://flags から有効にすることができます）。新しいモデルは Chrome 80 に徐々にロールアウトされるので、テストを行う場合は、Chrome 80 でフラグを有効にして新しいデフォルト設定がブラウザに確実に反映されるようにする必要があります。
また、Chrome 80 で想定しない動作が発生した場合、[SameSite by default cookies] および [Cookies without SameSite must be secure] フラグを無効にすることで、それが新しいモデルによるものかどうかを切り分けることができます。フラグを無効にしても問題が発生する場合は、問題の原因は Cookie の変更ではない可能性が高いでしょう。その他のテストやデバッグのヒントは、
こちら
に掲載されています。
その他のリソース:
SameSite 最新情報
SameSite に関するよくある質問（Lax + POST 対処法を含む）
web.dev: SameSite Cookie の説明
web.dev: SameSite Cookie レシピ
テストとデバッグのヒント
互換性のない既知のクライアント
と
互換性のないクライアントへの対応
企業管理者向けのガイド
言語、ライブラリ、フレームワークのガイド
AMP サイト運営者向けガイド
Stack Overflow に質問を投稿
Cookie の SameSite=Lax デフォルト化に関する Chromium トラッカー
安全でない SameSite=None Cookie の拒否に関する Chromium トラッカー
Reviewed by
Eiji Kitamura - Developer Relations Team
Chrome アプリの先へ向かうために
2020年2月7日金曜日
この記事は Chrome プラットフォーム チーム テクニカル ディレクター、Anthony Laforge による Chromium Blog の記事 "
Moving Forward from Chrome Apps
" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
2013 年に Chrome アプリが
リリース
されてから、ウェブ プラットフォームは大幅な進化を遂げました。私たちは、コミュニティのメンバーとして他のブラウザと連携し、プラットフォームに高度な新機能を導入するために
注力
し続けています。この取り組みについては、昨年 11 月の Chrome Developer Summit でもお知らせしました。
モダンブラウザの
進化
により、ウェブは広範なユースケースに応えることができる好位置に押し上げられました。
Figma
などの企業や
Google Earth
などの私たちのプロダクトの成功はその証拠です。ウェブはオープン プラットフォームでこそ最上級の体験を
提供できる
と、私たちは確信しています。
この継続的な進化を踏まえ、
以前のお知らせ
からさらに発展させて、以下のように、すべてのオペレーティング システムで、Chrome アプリのサポートの段階的廃止に着手します。
2020 年 3 月
: Chrome ウェブストアで
新規
Chrome アプリの登録を終了します。デベロッパーによる既存 Chrome アプリのアップデートは 2022 年 6 月まで可能です。
2020 年 6 月
: Windows、Mac、Linux で Chrome アプリのサポートが終了します。Chrome Enterprise および Chrome Education Upgrade のユーザーは、サポートを 2020 年 12 月まで延長するポリシーにアクセスできます。
2020 年 12 月
: Windows、Mac、Linux で Chrome アプリのサポートが終了します。
2021 年 6 月:
NaCl、PNaCl、PPAPI API のサポートが終了します。
2021 年 6 月
: Chrome OS で Chrome アプリのサポートが終了します。Chrome Enterprise および Chrome Education Upgrade のユーザーは、サポートを 2022 年 6 月まで延長するポリシーにアクセスできます。
2022 年 6 月
: Chrome OS で、すべてのユーザーに対する Chrome アプリのサポートが終了します。
この変更は、Chrome 拡張機能のサポートには影響しません。Google は、すべての既存プラットフォームで Chrome 拡張機能に対するサポートと注力を継続します。堅牢な拡張機能エコシステムを育むことは Chrome のミッションにとって重要です。私たちは、すべてのユーザーのために、ブラウズ体験をカスタマイズできる便利な拡張機能プラットフォームを提供することを約束します。
さらに詳しい情報（例: タイムライン、推奨事項、よくある質問など）は、
Chrome アプリ移行サイト
をご覧ください。このページは、プロセスが進展するにつれて最新状態に更新されます。
Chrome チームを代表して、Chrome アプリを使ってすばらしい体験を構築してくださったデベロッパー コミュニティの皆さんに感謝します。オープンなウェブ標準（例: PWA）を活用してすべてのモダンブラウザで実現される同じような体験にご期待ください。
Reviewed by
Eiji Kitamura - Developer Relations Team
iPhone と Advanced Protection Program で Google アカウントを保護する
2020年2月6日木曜日
この記事は Google Cloud プロダクト マネージャー、Christiaan Brand、Google ソフトウェア エンジニア、Kaiyu Yan による Google Online Security Blog の記事 "
Have an iPhone? Use it to protect your Google Account with the Advanced Protection Program
" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
オンラインの攻撃者がユーザー名とパスワードをだまし取ろうとするフィッシングは、アカウントが侵害される主な原因の 1 つです。先日、私たちは The Harris Poll と連携し、米国在住の 500 名の高リスク ユーザー（政治家やそのスタッフ、ジャーナリスト、企業の重役、活動家、オンライン インフルエンサー）への調査を行ったところ、回答者のうち 74% がフィッシングのターゲットになったことがある、またはフィッシング攻撃の被害に遭ったことがあると答えました。
Gmail は毎日 1 億件以上のフィッシング メールを自動的にブロックし、政府から支援を受けた攻撃者に狙われている人々に警告しています。しかし、
Advanced Protection Program
に登録すれば、Google アカウントのセキュリティをさらに強化できます。攻撃者は、皆さんの個人用または仕事用の Google アカウントやデータにアクセスするために進化し続ける手法を使っています。Advanced Protection Program は、それらの手法に対して自動的に保護する Google 最強のセキュリティ保護機能です。
フィッシング攻撃に対して最強の保護を提供するセキュリティ キーは、Advanced Protection Program の重要な機能です。以前は物理セキュリティ キーを個別に購入して持ち運ぶ必要がありましたが、昨年にはセキュリティ キーが
Android スマートフォン
に組み込まれるようになりました。そして本日（元記事公開当時）より、iPhone でセキュリティ キーを有効化し、Google アカウントを保護できるようになります。
iPhone で Google の Smart Lock アプリを使ってセキュリティ キーを有効化
セキュリティ キーは、公開鍵暗号化を使って ID とログインページの URL を検証するので、たとえ攻撃者がユーザー名やパスワードを知っていたとしても、皆さんのアカウントにアクセスすることはできません。ログインの検証を試みるその他の 2 要素認証（2FA）手法とは異なり、セキュリティ キーには
FIDO 標準
が使われています。FIDO 標準は、自動ボット、大量フィッシング攻撃、標的型フィッシング攻撃に対する
最強の
保護を提供します。セキュリティ キーの詳細については、
Cloud Next ‘19 のプレゼンテーション
をご覧ください。
iPhone で Google の Smart Lock アプリを使って Google アカウントへのログインを承認
iPhone で、Google の
Smart Lock アプリ
を使ってセキュリティ キーを有効化できます。Android スマートフォンには、この機能が組み込まれています。スマートフォンのセキュリティ キーは、Bluetooth を使って Chrome OS、iOS、macOS、Windows 10 の各端末でのログインを検証しますが、端末をペア設定する必要はありません。これにより、スマートフォンの便利さを維持したまま、ほぼあらゆる端末で Google アカウントが保護されます。
利用を開始するには
早速個人や仕事の Google アカウントを保護したい方は、以下の簡単な手順に従ってください。
スマートフォンのセキュリティ キーを
有効化
（Android 7 以上または iOS 10 以上）
Advanced Protection Program に
登録
Google アカウントにログインする際に、スマートフォンとログインしようとしている端末で Bluetooth がオンになっていることを確認
また、アカウントにバックアップのセキュリティ キーを登録し、それを安全な場所で保管することを強くおすすめします。こうすることにより、スマートフォンを紛失したときもアカウントにログインできるようになります。Google の
Titan Security Key
を搭載したセキュリティ キーは、Google を含むさまざまなベンダーから入手できます。
Google Cloud ユーザーの方は、企業向けの Advanced Protection Program の詳細について、
G Suite Updates ブログ
を参照してください。
皆さんのポケットの中にある強固なアカウントのセキュリティに、乾杯。
Reviewed by
Eiji Kitamura - Developer Relations Team
ウェブのプライバシー強化: サードパーティ Cookie 廃止への道
2020年1月23日木曜日
この記事 Justin Schuh - Chrome エンジニアリング ディレクターによる Chromium Blog の記事 "
Building a more private web: A path towards making third party cookies obsolete
" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
8 月に、一連のオープンな標準を作成してウェブのプライバシーを抜本的に強化する新しい取り組み（プライバシー サンドボックスと呼ばれています）について
お知らせしました
。このオープンソースによる取り組みの目的は、パブリッシャーをサポートしつつ、ユーザーのためにウェブのプライバシーとセキュリティを強化することです。本日（元記事公開当時）は、この計画の最新情報をお知らせするとともに、ウェブ ブラウジングのプライバシー強化に向けてご協力をお願いします。
初めてウェブ コミュニティにお話しした後の継続的なフィードバックから、私たちはプライバシー サンドボックスのようなプライバシーを保護するオープン標準メカニズムは、広告によってサポートされる健全なウェブを維持できること、そして将来的にサードパーティ Cookie が使われなくなることを確信しています。このアプローチがユーザー、パブリッシャー、広告主のニーズに対処でき、回避策を防ぐことができるツールを開発できたら、Chrome でのサードパーティ Cookie のサポートを段階的に廃止する予定です。私たちは、この計画を 2 年以内に行うことを目指しています。しかし、これは私たちだけでは実現できません。そのため、この案を推進するエコシステムが必要です。最初のオリジン トライアルは、今年中に開始する予定です。まずは、コンバージョンの測定から始め、続いてパーソナライゼーションに対応したいと考えています。
ユーザーは、透明性や個人データの使用方法に関する選択と制御など、プライバシーの強化を求めています。ウェブのエコシステムが、この高まる要求を満たすように進化しなければならないのは明らかです。ブラウザの中には、サードパーティの Cookie をブロックすることでこの懸念に対応しているものもあります。しかし私たちは、それが意図しない形でユーザーとウェブのエコシステムの両方に悪影響を与える結果になると考えています。広告によってサポートされている多くのウェブサイトのビジネスモデルを過小評価し、Cookie に対して洗練されていない
アプローチをとることになれば、フィンガープリンティング（プライバシーの侵害につながる可能性がある Cookie に代わる方法）などの不透明な技術の使用が増加し、実際にはユーザーのプライバシーや制御が減少することになります。コミュニティとしての私たちは、それよりもよい方法を実現できるはずです。そして、それを実現しなければなりません。
幸運にも、W3C などのフォーラムには、プライバシー サンドボックスの土台となるメカニズムは重要なユースケースに相当するもので、それが正しい方向に向かっているという肯定的なフィードバックが寄せられています。このフィードバックや、標準化に参加している他の団体からの関連提案から、私たちはこの領域のソリューションは問題なく適用できると確信しています。また、標準コミュニティと連携し、代替手段を作って
Flash
や
NPAPI を段階的に廃止した
経験は、私たちが協力して複雑な課題を解決できることを証明しています。
また、現在のウェブ技術の安全性とプライバシーをさらに強化するための作業も続ける予定です。以前にもお知らせしたように、Chrome は SameSite ラベルを含まない Cookie をファーストパーティ専用として扱い、サードパーティ用のラベルが付いた Cookie には HTTPS を必須とすることで、2 月から安全でないクロスサイト トラッキングを制限します。これにより、サードパーティ Cookie がさらに安全になり、ユーザーはブラウザ Cookie を厳密に制御できるようになります。同時に、隠されたトラッキングや回避策を検出して軽減する技術を開発しており、このような詐欺的でプライバシーの侵害につながる技術を阻止する新しいフィンガープリンティング対抗策をリリースします。この対策は、今年中に導入したいと考えています。
私たちは、ブラウザ、パブリッシャー、デベロッパー、広告主がこういった新技術を試してさまざまな状況で問題なく動作するかテストし、広告の選択や測定、サービス拒否攻撃（DoS）の防止、スパムや詐欺への対策、フェデレーション認証などのサポート実装を開発する機会を持てるように、エコシステム全体で積極的に連携しています。
皆さんとともに信頼性が高く持続可能なウェブを作ることを楽しみにしています。そのためには、皆さんの継続的な関与が必要です。
ウェブ標準コミュニティ
の提案が皆さんのニーズに合致するように、ぜひ GitHub から
フィードバック
をお送りください。ニーズを満たしていない場合は、GitHub や
メール
で W3C グループに問題を送ってください。ウェブでビジネスをしている方は、技術ベンダーがこのプロセスに関与していることを確認し、皆さんの利益を代表するトレード グループとフィードバックを共有してください。
ウェブ ブラウジングのプライバシーを強化する取り組みの進展については、今後も投稿を通してお知らせいたします。
Reviewed by
Eiji Kitamura - Developer Relations Team
ラベル
.app
1
.dev
1
#DevFest16
1
#DevFest17
1
#DevFest18
1
#DevFest19
1
#hack4jp
3
A/B Testing
1
A4A
4
Accelerator
1
Actions on Google
16
Activation Atlas
1
Addy Osmani
1
ADK
2
AdMob
31
Ads
50
Ads API
43
Advanced Protection Program
1
AdWords API
11
Agency
1
AI
11
AIY
3
AIY Vision Kit
2
ALPN
1
AMP
90
AMP Cache
6
AMP Extension
1
AMP for Email
4
AMP SSR
1
AMP Story
3
AMP Toolbox
1
amp-bind
1
AMPHTML Ads
1
Analytics
9
Andorid
12
Android
348
Android Auto
1
Android Design Support Library
1
Android Developer Story
4
Android Developers
4
Android Enterprise
5
Android Go
1
Android Jetpack
3
Android N
18
Android O
13
Android P
7
Android Pay
1
Android Q
13
Android Security Year in Review
1
Android Studio
38
Android Support Library
6
Android Things
15
Android TV
10
Android Vitals
3
Android Wear
29
androidmarket
3
AndroidX
5
Angular
2
Angular 2
2
AngularJS
2
Anthos
1
AoG
1
API
25
APIExpert
45
apk
2
APM
1
app
3
App Action
1
app engine
23
App Indexing
7
App Invites
6
App Maker
2
AppCompat
2
Apps Script
11
aprilfool
4
AR
2
Architecture Components
7
ARCore
1
ArtTech
1
Associate Android Developer Certificate
1
Audio
7
Auth Code
1
Authentication
8
AuthSub
2
Autofill
1
AutoML
1
Autotrack
2
award
1
Awareness API
1
Beacons
6
Better Ads Standards
1
BigQuery
9
Billing
1
BLE
4
Blink
1
Blockly
1
blogger
1
BodyPix
1
Brillo
1
Brotli
2
Budou
1
Calendar
3
Canvas
1
Cardboard
4
Career
1
Case Study
1
CCPA
1
Certificate
2
chrome
140
Chrome Custom Tab
2
Chrome Dev Summit
3
chrome extension
11
Chrome for Android
2
Chrome for iOS
2
Chrome OS
6
Chrome Tech Talk Night
4
Chromebook
4
Chromecast
7
chromewebstore
7
Chromium
5
CLI
1
ClientLogin
3
Closure Compiler
1
Cloud
21
Cloud Firestore
5
Cloud Functions
9
Cloud IoT Device SDK
1
Cloud Next
8
Cloud OnBoard
3
Cloud PubSub
1
Cloud Storage
1
Cloud Study Jams
3
Cloud Summit
1
Cloud Test Lab
2
Cloudflare
1
CNN
1
Coalition for Better Ads
1
CocoaPods
1
code review
1
codejam
5
codelab
4
Colaboratory
1
Community
4
compute engine
3
Context
1
Cookie
6
Coral
2
Crash Reporting
2
Crashlytics
2
Dart
2
DataCenter
1
Daydream
4
Deep Learning
4
Demo Party
1
Design Sprint
3
DesignBytes
1
DevArt
3
DevBytes
6
Developer
14
Developer Console
4
Developer Preview
6
Developer Relations
2
DevFest
9
DevFestX
3
DevOps
1
devtools
4
Dialogflow
1
Differential privacy
1
DirectShare
1
DNS-over-HTTPS
2
Domain
1
Doodle
1
DoubleClick
4
Doze モード
1
drive
2
Dynamic Links
3
EarlGrey
1
Easter Egg
1
ECMAScript 2015
1
Eddystone
4
Edge
1
egypt
1
Encryption
1
English
2
ES2015
1
ES2016
1
ES6
2
ES7
1
Event
1
Featured
2
FIDO
2
Firebase
118
Firebase Admin SDK
6
Firebase Analytics
10
Firebase Auth
4
Firebase Cloud Messaging
10
Firebase Crashlytics
2
Firebase Database
5
Firebase Libraries
1
Firebase Notifications
1
Firebase Performance
3
Firebase Remote Config
5
Flash
1
Flutter
6
font
3
fraud
1
G Suite
19
game
39
Game Developers Conference 2018
1
Game Developers Conference 2019
1
Gboard
1
GCP
13
GCPUG
1
GDD11JP
56
GDD2010JP
23
GDE
2
GDG
19
GDG Cloud
1
Geo
54
Gingerbread
1
GLIDE
5
Gmail
4
Gmail API
2
Go
1
golang
5
goo.gl
1
Google
6
Google Analytics
3
Google API
1
Google Apps
14
Google Apps Script
4
Google Assistant
10
Google Assistant SDK
2
Google Cast
8
Google Cloud
26
Google Cloud INSIDE Digital
1
Google Cloud INSIDE Games & Apps
6
Google Cloud INSIDE Retail
1
Google Cloud Messaging
11
Google Cloud Platform
11
Google Code-in
1
Google Developer Experts
2
Google Developers Academy
1
Google Developers live
5
Google Developers Summit
2
Google Drive
6
Google Earth
1
Google Fit
2
Google for Mobile
2
Google for Startups
2
Google for Work
1
Google I/O
17
Google Impact Challenge
1
Google Maps
62
Google Maps Platform
21
Google ML Summit
1
Google Pay
2
Google Photo
1
Google Play
110
Google Play Console
9
Google Play Game Services
9
Google Play Instant
1
Google Play Services
23
Google Plus
14
Google Search
7
Google Sheets API
3
Google Sign-In
12
Google Slides API
5
Google Summer of Code
1
Google Tag Manager
1
Google Trust Services
1
Google マップ
4
Google+
2
Googleapps
10
GoogleGames
1
GoogleI/O
28
GoogleLabs
1
GooglePlay
1
GoogleTV
1
Gradle
1
gRPC
2
GTUG
5
GWT
2
hack4jp
2
hackathon
7
Hangouts Chat
2
Hosting
3
HTML5
17
HTML5Rocks
1
HTTP/2
5
HTTPS
13
I/O Extended
4
ID Token
1
Identity
15
Identity Toolkit
1
IGF2010
2
Ignite
4
IME
11
Indie Game
2
Indie Games Festival
2
Indie Games Festival 2018
2
Indie Games Festival 2019
12
Indie Games Festival 2020
2
Inevitable ja Night
28
Instagram
1
Instant Apps
6
intern
2
Invites
1
IO19
3
iOS
20
IoT
7
IPv6
1
Issue Tracker
2
Japanese Input
1
JavaScript
10
Jetpack
1
K-12
1
Key Transparency
1
Knowledge Graph
1
Kotlin
10
Kubernetes
2
l10n
8
LaunchPad
2
Lighthouse
1
LINE
1
Local AI
1
Lollipop
10
Machine Learning
22
Maker Faire Tokyo
1
Marshmallow
10
Material
1
Material Design
30
MDL
1
MDN
1
metrics
1
MIDI
2
ML Kit
11
Mobile
14
Mobile Bootcamp
4
Mobile Sites certification
1
Mobile Vision
4
mod_pagespeed
1
monetize
3
Mozc
15
Music
1
NativeDriver
2
NativeScript
1
NBU
1
ndk
3
Nearby
5
Next Extended
1
Next Tokyo
3
Nexus
2
Nexus S
1
NFC
1
Node.js
3
Noto CJK
1
NPAPI
2
NPN
1
oauth
11
OpenAI
1
opencensus
1
OpenGL
4
OpenID
3
OpenID Connect
4
OpenSocial
1
opensource
18
OpenTitan
1
Optimization
1
Payment
4
PEM
33
People API
2
Performance
13
Performance budget
1
PersonFinder
1
Physical Web
3
Pi
1
Place Picker
1
Play Billing Library
2
Player Analytics
4
Playtime 2017
1
Policy
4
Polymer
7
privacy
6
Progressive Web Apps
14
project hosting
1
Promise
1
Promo code
1
Protocol Buffers
1
PRPL
1
publicdata
1
Push API
1
Push Notification
4
PWA
3
Python
2
QUIC
1
QWIKLABS
3
RAIL
1
React
1
React Native
2
Realtime Database
9
Recap Live Japan 2019
3
reCaptcha
1
Redux
1
Remote Config
3
Remote Display API
1
Resonance Audio
1
Rewarded Video Ads
2
Runtime Permission
1
Safe Browsing
2
Sample Code
2
Santa Tracker
1
schema.org
1
secur
1
security
58
Service Worker
4
SHA-1
1
sketchup
1
SmartLock for Passwords
4
social
4
Social Good
1
Social Media
1
software development
1
SPDY
3
speak2tweet
1
Spreadsheet
3
SSR
1
startup
6
Storage
2
story
1
streetview
3
Study Jams
7
Swift
2
SwiftShader
1
Symantec
1
Task
4
Team Drive
1
techtalk
12
TensorFlow
27
TensorFlow Federated
1
TensorFlow Lite
4
TensorFlow Object Detection API
1
TensorFlow Probability
2
TensorFlow.js
1
test
4
Test Lab
6
TFX
1
ToS
1
trace
1
Transliteration
1
Twitter
1
Udacity
20
Unity
3
UX
4
V8
2
VP9
1
VR
11
Vulkan
2
Watch Face
2
wave
2
Wear OS
2
Weave
1
Web
31
Web Animations
1
Web Components
6
Web Manifest
1
Web Packaging
3
WebAssembly
4
WebGL
1
WebMusic
5
WebView
1
Women Techmakers Scholars Program
1
WTM
5
Xcode
1
YouTube
17
YouTube API
1
インタビュー
1
コードサンプル
1
プライバシー
1
機械学習
2
言論の自由
1
節電
3
東日本大震災
9
日本語入力
41
ブログ アーカイブ
2020
2
1
2019
12
11
10
9
8
7
6
5
4
3
2
1
2018
12
11
10
9
8
7
6
5
4
3
2
1
2017
12
11
10
9
8
7
6
5
4
3
2
1
2016
12
11
10
9
8
7
6
5
4
3
2
1
2015
12
11
10
9
8
7
6
5
4
3
2
2014
12
11
10
9
8
7
6
5
4
3
2
1
2013
12
11
10
9
8
7
6
5
4
3
2
1
2012
12
11
10
9
8
7
6
5
4
3
2
1
2011
12
11
10
9
8
7
6
5
4
3
2
1
2010
12
11
Feed
Follow @googledevjp
"プロダクトに関するご意見は
プロダクトフォーラム
にお願いします"
