JICS2014レポート(6) 1/15後編 ジェネラルパネル
ジェネラルパネル
- 「グローバルクラウド時代のアイデンティティとデータの所在」
- 参加者
- モデレータ: 藤井さん
- パネリスト
- 舘野さん: さくらインターネット
- 玉川さん: アマゾン
- 宮内さん: 弁護士
ここ5年でクラウドを取りまく環境はどう変わったか
- 玉川さん
- 舘野さん
- 宮内さん
Consumerization of IT
- BYOD、エンプラとコンシューマの垣根、Google Apps、端末もアプリもグローバル
- 玉川さん: AWSの理由…コンシューマ寄り
- アマゾンはeコマースだが、多くのお客様に来てもらえるように機能を早く作りたい → サーバーをすぐ入手したいという社内ニーズがあった
- 作ったら便利だった → 公開
- 社内ネットから使いたいと要望
- アマゾンのサーバーとAWSのサーバーどちらが多いか?
- 誤解: 本屋をやっていて、余ったサーバー資源を売っている
- amazon.comの全サーバー量(7千億企業だったころ)のサーバー数を毎日追加している
- 舘野さん
- public/privateクラウドは安全かどうか
- 宮内さん: まずこの表には安全性が書かれていない(会場笑)
- 海外に出して大丈夫なのか? NSAとパトリオットactとか
- 現実には心配ではない。海外の業者に強制執行は大変。EUからもって来るのも大変
- 国内だと{なくなっちゃう,もらしちゃう}のが心配
- 実際に発生した(firstserver)
- 起こったときに保障とれるのか
- 被害額を算定できない
- お金をもらうよりもデータを返してほしいという問題も
- 藤井さん: それってクラウド特有の問題なのか?
- 玉川さん: あずけている方が楽
- 耐侵入とか → 第3者認証を示せる
- アプリ、プラットフォーム → これはお客様にやっていただく
- デフォルト暗号化がトレンド。http → httpsの流れと似ている
- 玉川さん: あずけている方が楽
- 舘野さん: SaaS, BaaSだとデータ置場の所在をコントロールできない場合もある。IaaSだとコントロールできる。
クラウド時代のIDとは
- IDの囲い込みの流れ → 今後のID
- 宮内さん: ID連携: 認証の連携 + データの連携
- 玉川さん: 利用者側が知識をつけていかないとリスクが高い
- 宮内さん
JICS2014レポート(5) 1/15中編 基調講演、エンプラトラック
- 基調講演
- エンタープライズトラック
基調講演
パーソナルデータ利活用の最前線
- 牧野さん @tomoe @ twitter
- twitterのデータ提供と活用について
- twのデータをパーソナルデータとして活用してもらうために
- tw
- アクティブユーザー 2.3億人
- 日本は世界でもかなりtwを使っている。ユーザー数は米国に次いで2番目に多い
- 5億ツイート/日
- モバイルからのアクセス 75%以上
- 140文字という制限はSMS利用を想定していた
- アクティブユーザー 2.3億人
- twからのデータ提供を考えた場合のtweetデータの特徴
- Real Time
- Public
- Conversational
- テキストベースなので解析しやすい
- 情報利用とプライバシー保護
- 公開APIでの無料利用
- 検索で取得できるtw数の制限
- 全データから1%までしか取得できない
- 全ての日本語ツイートデータ提供
- NTT dataが再販パートナー
- コンシューマ向けのデータ利用
- Y!とNTT Dataがリアルタイムサーチを提供
- 活用事例
- インプレッション指数
- 投稿数 = unique user数
- インプレッション数: そのツイートを何人が見たか
「楽天のデータサイエンスによるEC革命〜おもてなしと興奮をデザインする〜」
- 北川さん @ 楽天
- 楽天の紹介
- Rakuten Diversity
- 感情価値をどうビジネス上で表現するのか、どう顧客のベネフィットに変えていくのか
- Rakuten Global Expansion
- 日本発の感情価値、「おもてなし」などをいかに世界に発信していくか
- B to B to C
- ネットモールとしての成り立ち
- 共通IDによってなしとげられること
- 店舗さんのempowerment
- 「おもてなし」のプラットフォームを作る
- ものを売る・買うことそのもののサービス向上
- Shopping Entertainment
- 日本のEC率 4% (イギリスは10%くらい)
- 感情価値による購売
- 便利さは買い続ける理由ではあるが買い始める理由ではない
- 感情価値は買い始める理由になる
- 感情価値による購売
- 楽天市場、店舗さん、お客さんによる感情価値のエンパワー
エンタープライズトラック
14:40- #enterprise
Developing Modern Identity and Access Solutions
- Vittorio Bertocci @ Microsoft
- MSのIDaaS (Azure Active Directory Service) について
- Agenda
- Identity workloads in the cloud era
- An example of Identity as a Service offering: Windows Azure AD
- Developing for an IDaaS platform
Identity workloads in the cloud era
- ディレクトリはオンプレで使うために作られた。いまでもほとんどの使い方はそうだ
- オンプレのディレクトリの回りにリソースやアプリを配置していく。もちろんユーザーもオンプレで活用していた。管理者にとってはパラダイスであった。
- 管理者にとってはパラダイスであった。すべてをコントロールできた
- 境界が進化し、パブリッククラウドができると様変わりしてしまった
- 会社バウンダリの外に活用したいリソースを設けるようになった
- 2つの問題が出てきた
- 境界の外にあるものの認証
- firewall背後のdirectoryへのアプリからのクエリ
- 影のITの出現: クレジットカードでIT部門の許可なくサービスを購入できるようになった
- BYODの台頭によって、オンプレで管理できるリソースは縮小した。 デバイスはドメインに参加しないので、本当に必要なところはアクセスできない。モバイルデバイスなので置き忘れによるトラブルも発生。管理者は怒り心頭
- 従来のディレクトリに問題があるわけではないが、リソースは増える、デバイスが使えるアプリは増える。そして従来のperimeterは消えつつある
- パブリッククラウでも活用できるIDaaSがこれを解決する。Active Directoryをなくすのではなく、機能拡張することにした。新たにクラウド上で展開可能
An example of Identity as a Service offering: Windows Azure AD
- Windows Azure AD
- 従来のオンプレディレクトリがあり、user, group, 証明書などがある。クラウドの先にWindows Azure ADがある
- クラウドに常駐するアプリからオンプレディレクトリにはクエリがかけられないので、クラウド上にディレクトリをコピーする
- クラウドはテナント構成になっており、your tenant, your domainと呼ぶ
- dir sync: 定期的にコピーを同期する。Office 365において一部差分をコピーするために長年使っているもの
- デフォルトでユーザー、グループをコピーするが、クレデンシャルは知らない。認証する場合にはオンプレのディレクトリにリダイレクトする。ここでID連携技術を使う
- クレデンシャルをクラウド上に置くことも可能。もちろん生パスワードをコピーするのではなく、ハッシュをコピーする
- 中小企業や分散拠点であれば、クラウド上のディレクトリだけで完結することも可能
- ユーザーによるIDaaSの活用
- エントリポイントはWindows Azure Management Portal
- AzureはPaaSである。そのひとつであるADにナビゲーションする
- マルチテナントサービスのうち、特定のUIから入ることも可能
- まずアドミンとして入る。左下のほうにあるActive Directoryを選ぶ
- user, group, applicationがリストされる。アプリは自作のものも3rd partyのものもある
- アプリ追加の方法は2つ、ひとつめは自社開発のもの、もうひとつはプリインテグレートされている3rd-partyアプリ(500以上ある、salesforce, dropboxなど)
- ポータルからはSSOでアプリを使うことができる。twitterとか。ユーザーはSSOが使え、管理者はクレデンシャルを管理する必要がない
- Graph APIもサポートしている。従来のLDAPに相当する役割を持つ。RESTful APIになっていて、オブジェクトにアクセスすることができる
- Developer視点での開発
- 認証エンドポイントも提供している: SSOにはSAML, WS-federation、WEB APIやプログラムにはOAuth、WEB Service+WEB SSOとしてOpenID Connect
- IDaaSシステムを介したアプリ開発
- 従来のIDシステムと同様にパラメータを設定する。アプリが何であるかを使用プロトコルのパラメータ、暗号化方式などを記述する
- 従来型よりも使いやすくなっている。オンプレでは管理者が独自の判断でディレクトリに合わせたパラメータを指定していた。今後はconsistentな方法で設定ができる
- 従来型ディレクトリは管理者のみがアクセスするように設計されていた。しかしAzure ADではプログラムベースになっているため、delegation前提で設定されている。アプリから見て統一的なアクセスが可能
- ADに対するアプリを開発する方法は2つある。ディレクトリに対してアプリ記述を提供する方法。マネジメントポータルを使う方法と、Visual Studioを使って記述する方法
- 大事なことはアプリがオープンプロトコルのどれかを話すこと。ここだけ守ればプラットフォームに依存せずに開発できる
- SDKが提供されているので、例えば認証プロトコルで何が起こっているかを知らずにアプリに認証機能を作ることができる
- Web Sign Onでは、SAMLまたはWS-Federationを活用する。Azure ADのメリットとして多要素認証やレポーティングなどをすぐ使える
Developing for an IDaaS platform
まとめ
- IDaaSでハーモニー
パネル・ディスカッション
- そろそろ「社員IDでログインできます」始めてみませんか?
- 〜 サービス・プロバイダーの立場から考える「エンタープライズ・アイデンティティ」活用の課題と今後
- パネリスト
- 工藤さん: ASPやSaaSが出てきたので、ログインも個別に持っていたものから、企業IDやコンシューマIDを使うようになってきた
- ユーザー企業において今後利用するもののヒントになるだろう
- 2001〜2002年にSAMLやLiberty Alliance製品が出てきた
- 2008年のスライドでは社外サービスを使うにあたって社外IDを使う、社外ユーザーへのサービス提供のようなことを言っていた
- 2013年のITRさんの発表: フェデレーション市場が増加。クラウドサービスの連携が牽引力となっている
- 応用はさらに進んでいる。昨日のPat Pattersonのsalesforceの発表では、SFがCRMユーザー管理まで引き受けるというところまで進んでいる
- SAMLはまだまだ使われている。SAMLでいいというのはベースラインとしてある。しかし広い形で使われているとはいえない。特定のサービスでのみ使われている。それでいいのか
- 関根さん
- 浅賀さん
- 河野さん
お題
- 工藤さん: 10年前からID連携はあったが、ここに来て対応が進んだ理由とは
- 関根さん: オンプレに置いた社内での連携というのはこれまでもあった。クラウドになってからのニーズが2〜3年前から。googleなどクラウドサービスの台頭が効いている。salesforce, google appsなどからのそのままのIDでのSSOをしたいお客様が多かった。なぜSAMLかというのは→ OIDCも対応していきたい(よく聞きとれなかった)
- 工藤さん: SAML使いたいというよりはすでにログインしているIDが使いたいという要望なんでしょうか
- 浅賀さん: お客様としてはID連携ができると知らない人もいる。競合ができるからやらざるを得ないというモチベーション。RFPに入ったりはしていない
- 河野さん: 競合がID連携しているかどうかは知らない。お客様要望により対応しているのが現状
- 工藤さん: 始めてみてこういう話があった、ようなエピソードは?
- 工藤さん: ID連携は部署単位のほうが多い?
- 関根さん: ID連携というと全社レベルの方が多い。部署単位だとSSOだけあればいいということが多い。5〜10のクラウドサービスを使っている場合に、自社IDでSSOしたいという要望につながることが多い。ユーザーとしてはSSOの利便性になるが、情シスからは管理コストが重要になってくる。パスワード更新なども1人×サービス数で効いてくる
- 河野さん: コールセンターコストではID忘れの問合せが減った。社員番号を忘れる人は少ない
- 工藤さん: SAML対応した結果、ここがいい、ここが悪い?
- 浅賀さん: IdPアラアンスだと他社とやりやすいということがある。仕様の細かい部分で合わないことがあった。Azure ADとはうまくつながらない
- 浅賀さん・関根さん: 他のサービス、アライアンス連携ではSAMLはだいたいサポートしているので組みやすい。そのままで行かないケースが多い
- 工藤さん: 自社でSAML環境を構築して使ってくださいということはあるか
- 河野さん: 見積りを作ったこともあったが、コストに見合わなかった
- 工藤さん: 何千、何万もお客様がいるところではうまくいっている印象がある。
- 工藤さん: お客様にこういう仕様でやってくださいと言うとSAMLの知識が必要になると思うがどうか
- 工藤さん: 統制できない他社サービス、どういう使い分け?
- 河野さん: Y!さんと直接連携するわけではない。社内で使っているIDをいただいて会員IDとのセットで扱うというような使い方
- 工藤さん: Y!で悪いことをしてアカウントを止められちゃったなど、統制不能な場合はどう考えている?
- 河野さん: 他社で使えなくなったというような情報がこっちに来るわけでもないので難しい
- 工藤さん: 契約関係のないサービスとうまくやるのは難しい
- 工藤さん: コンシューマIDの受け入れはビジネス的には大きい?
- 関根さん: 少人数になればなるほど、管理可能かどうかより利便性を優先することが多い
- 工藤さん: 認証と認可とは別だが、認可を使うということは?
- 浅賀さん: 権限管理が同一ではないので逆に難しい
- 工藤さん: プロビジョニングは?
- 浅賀さん: ほとんどはアカウントの自動生成までを使っていただいている感じ
- 河野さん: 役員だけはサービスレベルを上げるということは対応している。人事情報を取り込んで設定するような仕組がある
- 工藤さん: SCIMなどの標準化は?
- 河野さん: 標準化よりはお客様のご都合に合わせることが多い。
- 工藤さん: サービスから使ってくださいと言わないとユーザー企業さんに詳しい人がいるわけでもないから難しいと思うがどうか。CSVでこういう風にカンマで区切ってくださいとか
- 浅賀さん: ITスキルの高くないお客様も多いので、カンタンでないと使ってもらえない。プロビジョニング、フェデレーションをなんのためにやるのかということを機能として見せる、ハードルを下げるしかけが必要
- 工藤さん: google market placeに乗るなどのやり方はあるのではないか
- 工藤さん: ビジネス的な位置づけはあるか
- 河野さん: うちは福利厚生なので、入っていただいた後、利用していただかないといけない。利用率を上げるための最大のハードルはログインするところ。社員番号で手軽にログインできるのが付加価値
- 工藤さん: IDaaSのようなユーザー企業自体でID管理を持たずにsalesforceやAzure ADを使っている場合、どういうインパクトがあるか
- 工藤さん: 最後にエンタープライズアイデンティティの活用としてはOIDFとしてもWGを作っている。ID連携やプロビジョニングのAPIが標準化されようとしている。なかなか日本からの参加が少ない中で活動している
Cross 2014メモ(2) 機械学習パネル、次世代Webセッション
もくじ
機械学習(後編)
参加者
- 福島さん @fukkyy
- 油井さん @myui
- 村上さん @junichi_m
- 小宮さん @komiya_atsushi
- 平手さん
- 田島さん
- 比戸さん
自己紹介・事例紹介続き
- 福島さん @ グノシー
- 比戸 @ PFI Preferred Infrastructure
パネルディスカッション
- 後半の流れ
- 導入と展望
- 精度で人間に勝てるのか
- 役立つケースとそうでないケース
- 支える技術やツールは何が有望か
- どのように導入を進めていけばいいか
機械学習導入の展望: どこから導入が進むのか
- 田島さん: 間違えてもおこられないところ。広告やリコメンデーションは多少間違えてもおこられない。広告の審査にも使っているが、薬事法に反した広告が出てはまずい。最終的には人間の判断になるが、その前段として使うと、問題の切り出しが難しい。間違ってもいいかどうかは導入のポイントのひとつ
- 平手さん: 人手で不可能とあきらめている大規模なデータでの発見などから始まっている印象がある
- 小宮さん: マーケティングでは機械学習は手段のひとつ。Webマーケティングにおいては利益追求のためのリコメンドなど。リアルマーケティングでは在庫管理などで使うことが多そう
- 村上さん: セキュリティーについては間違えてもいいという点で同意できる。機械学習の誤判定はセキュリティーにおいてはクリティカル。すぐ人間をリプレースできるという話ではない。人に対する説明が求められるので、専門家のヘルプや専門家の教育などに使える
- 油井さん: 別の軸もある。機械学習でどれだけ質のよい文例データが集められるかという面もある。CTR/CVRなど直接レベニューに効いてくるところから導入が進むだろう
- 福島さん: ようするにもうかるところ、精度が上がることが売上に直結するところで進むと思う。タスクの切りやすさ、男女予測やスパムフィルタは問題が明確であり、人手がかからないし意志決定者が問題を理解しやすい。そういう部分は進めやすい
- 福島さん: そうでない部分では、例えば広告システムでは意志決定者が理解できない部分では導入が進まない。なぜこうなるのかを広告主に説明できないと困る。人間の解釈可能なモデルが面白い
- 福島さん: やらないとわからないし、やってダメでしたも受け入れられる人が経営者にいるかどうかもポイント。仮説が感覚と合っていると使われやすいだろう
- 比戸さん: 自社サービスを社内で評価するときはやってダメでしたならいい。しかし、お金をもらって分析した結果、データに価値がありませんでしたをちゃんと報告できるかと言うと難しい。これで何%くらい出そうですかと聞かれてもやってみないで答えるのは無理
- 比戸さん: 投資対効果について
- 平手さん: ダメなものはダメだとして直さないといけない。変な画像を出してしまうとサービスの質の印象が下がってしまう。
- 田島さん: ROA的に見合いそうなところをさがしている。審査にしてもどうしても人間が見ないといけないところは難しい。機械でなんとかなるかどうかパートナーと相談するような感じ
機械学習は人間に精度で勝てるのか
- お題
- 専門家の経験とカン vs 過去データからの学習、あるいは両方を使う
- データ前処理の中に専門家の経験を生かすのはどこまで有効?
- 精度は高いが解釈できないもの vs 精度はそこそこだが解釈しやすいもの
- 田島さん: ブラックボックスでもいいから精度高くというのはなかなかない。なんでこんなの出ちゃったの、というのが現場で一番問題になる。対策打てないとどうしようもない。解釈可能なものが使いやすい
- 比戸さん: 人間が見るものを機械学習で絞り込んでおくのかな、と思いましたが、そうではないと
- 平手さん: 機械学習の結果と専門家によるマーケティングで一致する部分があるよね、という事例もあった。人間ではできなかったところを機械学習が切り拓く
- 小宮さん: 利益追求が大事。技術のほうはどうでもいい。精度は重要とはいえほどほどであって、その上で利益最大化できるのがうれしい。このリコメンドがなんでされたのか、適切なのか判断できることが精度よりも大切
- 比戸さん: CTRなど金額の大小によって誤判定のインパクトからリコメンドの活用度合を変えたりということはある? 小宮さん: ありますね
- 村上さん: 機械学習でうまくいかなかったときに、究極的にはそれを人間が正解かどうか判断できる、という前提に立っている。間違った結果を専門家が見たときに正解がどれか判断できる。セキュリティーは何に対するかで考える。人間がいなくてもうまくできますという世界になった場合、機械学習のことがわかる人がセキュリティーの専門家になるのだろう。うまくいかないときの説明可能性が大事
- 油井さん: 将棋・チェスでコンピュータが勝てるのは、いいデータがあるから。専門家の経験はデータ可が可能で、そこは対立軸ではないと思う
- 福島さん: 機械学習で勝つパターンは、トレーニングデータがいいとき。将棋やチェスは勝ちの条件が明確、かついいデータがたまっている。そういうとき人間は勝てないと思う。もうプロ棋士が負けたりしている。一方難しいのは価値判断が明確に決まらない部分
- 福島さん: モデルの解釈性で問題になるのは失敗時の説明もあるが、モデルのパラメータがチューニングにおいて、教科書的には特徴量の抽出のハイパーパラメータをやるが、実際には外れたデータが来たときにどうするかが困る
- 比戸さん: 論文レベルではデータ固定でアルゴリズムのチューニング勝負だったでしょうけど 福島さん: 企業してからはモデルを変えるよりも特徴量を変えた方がうまく効くということに気づいた。人がどういう記事が好きかどうかは曖昧なので
- 比戸さん: アカデミックな評価と実用の評価とは基準が違う。一方で新しい手法はアカデミアから来る。論文ではよさそうなのに使ってみたらダメダメということがある。これから機械学習をやってみようという人はどのように学んだらよいか
- 田島さん: 機械学習は1回でポンといいモノが入るわけではない。KPIを決めておく。売上なのかクリックなのか。それができないとプロジェクトが迷走してしまう。やりながらKPIが上がっていく、上げることを楽しむのが大事
- 油井さん: どういったアルゴリズムを適用したかなやんだとき、複数の手法で予測した結果を統合するアンサンブル学習という手法がある。データサイエンティストのコンペティションサイトで、上位の人の結果をマージしたらうまくいったという例がある。安定した結果を得られる
役立つケースとそうでないケースの違いとは
- 比戸さん: うまくいかなかった事例、他社事例でこれいい、これひどい、などあるか
- 田島さん: KPI設定の失敗は細かくいろいろある。失敗した例としては国によってマーケット規模を推定するようなこと。為替がががっと変わってモデルがダメになってしまったことがある。時間軸が短く、確実に構造が同じだよね、というところで生かせると思う
- 平手さん: よい学習データが得られるところがいいというのはある。これを抽出したい、に対してこういうのではない、ということがよくわかっているのがよい。不正検知は、こういうパターンはダメだったというのはよく上がってくるが、うまくいった例は上がってこないので難しい。正例・不例の用意が重要
- 小宮さん: 機械学習は手段という観点をくり返しますが、機械学習のアウトプットをそのまま顧客に渡すのではなく、ドメイン知識で解釈したものを出すべき
- 小宮さん: これはひどいの例: 冷蔵庫の商品ページで別の冷蔵庫を出すのはおかしい。一家に冷蔵庫は2台必要ない。冷蔵庫を買った人には同じメーカーの電子レンジをすすめるようなフィルタを入れるのがよいと思う
- 小宮さん: 購売ログではなく閲覧ログを元にリコメンドしてしまうとそういう変な例になってしまうと思われる
- 村上さん: 正常なソフトと不正なものを分離するという仕事をしているが、それは不可能なんではないかという考え方もある。ソフトウエア全体の中にマルウエアがあるとしても、その集団が全体から見ると小さい集合。それをうまく切るのはできないと考えることがたまにあります。データの性質や偏りによっては機械学習が適用できない場合もありそう
- 村上さん: ノイズのようなデータやリアルな未知のデータもある。うまくいくデータとのギャップを考える
- 油井さん: 学習データをもっとくれくれと言って集めてきても、特徴がいっぱいあってもノイズをうまく除去してくれるとは限らない。劇的な変化に対して過去のデータからの学習が予測に役立たないことがある。特徴選択というトピックで扱われる問題
- 福島さん: 問題の設定がうまくない場合もある。100個の中にスパムが1個あるときに「全部スパムではない」と答えると精度が高いと評価されてしまう。そういうミスは結構ハマりやすい
- 福島さん: リコメンドエンジンも「好きな物」がたくさんないとうまくいかない。不動産リコメンドエンジンも不動産は営業が集めてくるので、十分な数が集まらず失敗する
ツール、ソフトウエア
- 比戸さん: RとかSciPyを使っている人も、機械学習を使うといいかもしれない
次世代Webセッション プロトコル編
パネリスト
プロトコル編
- 何がおこっているのか、どこへ向かっていくのか
- Jxckさん: 去年からの1年間でプロトコルにどんなアップデートがあったのか
- Jxckさん: PRISMがプロトコルの見直しにどんな影響が
- 林さん: TLS前提になるのはあると思う。元々はOSがやるべき機能をアプリでやってると思う。layer violationについて保守的だった人達も先へ目が向いたと思う
- 吉野さん: QUICでも暗号化ができるように考えて設計している
- Jxckさん: SSLの必要性が高まっていると?
- Jxckさん: upgradeだとまだ通らないことがあるのかな?
- 吉野さん: chromiumチームが実験して、80番ポートが何をされるかわからないという話が残っている
- Jxckさん: 証明書もいろいろ攻撃されてますよね
- Jxckさん: SSL前提になるとCAと証明書の重要性がまた上がってくる?
- 林さん: CA局ビジネスがこれ以上進んで、CA局に責任が全部行ってしまうのはインターネットとしてはどうよと様子を見ている。だから日和見暗号が出てきている
- Jxckさん: 暗号化がWSSでできてdeflateが拡張でできるとして、あとはマルチプレクス?
- 吉野さん: HTTP/2.0にみんな取られちゃってWS over SPDYにする方向
- 辻川さん: SPDY上でWSをどう効率的にやるか。データフレーム内に全部隠蔽する方法がひとつ(jettyの人、ぼく)。フレームレイヤにヒントを入れる方法(グーグルの人)
- Jxckさん: deflateもできたし、HTTP/2.0を待ちつつWSをSPDYに乗せていく方向? 吉野さん: そう Jxckさん: そうするとまた同じ問題にぶつかってWS over QUICになると?
- Jxckさん: XHR2だとバイナリに行くんですかね
- 吉野さん: バイナリもひとつだけどstream使えるようにしたい。ダラダラと入力をたれ流したり
- Jxckさん: いま一番大きい問題は? 吉野さん: 技術的というよりみんなでコンセンサスを得るところ Jxckさん: 標準化作業ですか
- 辻川さん: HTTP/1.1にしても、ラストコールが起こるとみんな意見を言い始めて、そうするとみんな読んで意見言うので話が進まない
- 林さん: HTTP/1.1が早く終わって番号ついてくれないとHTTP/2からreferできなくて困るんだけど。あきらめてさっさと通せという圧力が最近やっと通ったので、同時に出たりしかねない
- 辻川さん: ヘッダ圧縮(HPACK)をどうするか細かい仕様がなかなか決まらない。ラストコールになると意見が出る
- Jxckさん: 最近はフレームの話よりセキュリティーやプロキシの話が多いんですか
- 辻川さん: フレームのpriorityが31bitくらいの整数だが、どう意味づけするかは完全に実装依存。server-clientが1対1なら問題ないが、プロキシが間に入るとpriority levelingが難しくなる。いまグーグルの人が重みつきなんとかという文書を書いているところ
- Jxckさん: 去年なんとなく話題になったのはWebRTC。IETFでも話が多かった?
- 林さん: 毎回2コマずつ、つまり1週間に4時間ずつWebRTCの話がある。1個だけ絶対に実装しないといけないコーデックを決めましょう戦争というのがあって、投票がようやく終わったはず。VP8になるかH264になるか、両方になるか
- 林さん: でも実装はみんなできてて相互接続できてるからいいじゃんという感じ。実装が先に出ていて、標準化が後という感じだと思う。少しずつインプリの調整をして、いつのまにかできてるって
- Jxckさん: それ以外のプロトコルには問題ない? 林さん: ほとんど見えている。もうスマートフォンでもちゃんとつながる状況。残る問題はカメラ使ってるときにindicationどうするとか周辺の問題
- Jxckさん: 個人で遊ぶにはNAT越えとか難しい仕様があったり 辻川さん: NAT越えはフォールバックがいくつもあって、とりあえずつながるのは面白い
- Jxckさん: NATがあるとみんななえるというか、WebRTCではNATが一番難しいんですかね
- 林さん: TURNサーバ用意したりとか、サービス提供者は考えること多いけど、ユーザー視点ではちゃんと考えられているプロトコルだと思う
- Jxckさん: WebRTCはP2Pという、今までと違うところから話が入ってきている。彼らがIETFで2時間話しているのはコーデックばっかり?
- Jxckさん: プロトコルについてはカーネルに手を入れないとできないことも出てきていると思うけど、round trip数とか輻輳制御とか
- 吉野さん: layeringは維持した方がいいって教科書的に言うけど、こわしたくなる。いろいろやってみるのがいいと思う
- 辻川さん: 流れとしてはいい
- Jxckさん: カーネルに全部入れるよりUDPに全部入れてオレオレでやったほうがいいよね、と言うとQUICはわかりやすい。オレ達のやりたいことを入れていくとQUICになるってことですかね
- Jxckさん: レイヤを見直さないといけない、そういう時期に来ている、QUICはそのひとつと考えられるわけですかね。QUICでぶっこわせそうですか
- Jxckさん: Google内ではQUIC通ってるんですか 吉野さん: まだだけど人は割いている
- Jxckさん: TCPが3way handshakeしてるからUDPで全部やってTLSやってWS通せばいいじゃんっていくと、カーネルに何か通してもらうとかしなくてもいいじゃん、って話かと思うんですが、それでみなさんいいんでしょうかね
- 辻川さん: Windowsとかモバイルとかどうなんでしょうか…
- Jxckさん: Google, Facebook, twitterとか、それがないとどうにもならない人達が使えばいいものであって、全員がHTTP2を使うべきとは作ってる方も考えていないんじゃないか
- 辻川さん: HTTP2はサーバーとクライアントが対応してくれればWebアプリはサーバーpushとか使わなければそのまま動く。QUICよりはHTTP2の方がみんなに使われるのではないかと思う
- Jxckさん: 本当に大きなトラフィックを流す人達でなくても、ちゃんと動けば使えると 辻川さん: 使うぞと思わなくても使えていると
- Jxckさん: DevOpsというチャンネルができたと思うけど読んでます? 林さん: 本当に流量がない
- 林さん: ログの記録とか何も決まっていないのに何をMLに流すのかという
- Jxckさん: 運用仕用はこなれてない中でゴリゴリやるのかな
- 林さん: 今年はやるんじゃないですかね
- Jxckさん: 来週IETFありますよね 林さん: 来週はHTTP2 Interimです。IETFは来月末。IETFではメインは暗号。多くのプロトコルでTLSを使うためのutlというWGができる。そこはもり上がっている
- 辻川さん: priorityの話はまだやらないと思う。プロキシのユースケースでうまくいかない
- 辻川さん: 今のHTTP2はSPDYを前提にしているが、はるかにうまく考えられている。SPDYは各種オプションをサーバ/クライアント間で送るが、同期の仕組がない。HTTP2では必ずACKを返すようになっていて、エラーハンドリングが厳密になる
- Jxckさん: 細かいところはともかく、動かすだけ考えるなら、そろうところはそろったなという感じ 辻川さん: そうですね。最初はfirefoxで動かなくて、ヘッダ圧縮のバグでメタメタになったりしていた。数をこなすうちよくなってきた
- Jxckさん: interopなんかで確認しながらじゃないと作れないですよね 辻川さん: ひとつのページを2度3度見てもダメで、違うページを次々見ていかないとバグが発現しなかったりして大変
- Jxckさん: 単体では日本はすごくそろっている → 林さん: クライアント/サーバー/ライブラリ全部自分で作っている辻川さんに日本語で質問できるのが、われわれ日本人にとってはうれしい
- Jxckさん: 2014どうなりますかね
- 吉野さん: WSマルチプレクスの上でAPIが使えるようになってほしい。WS APIにもっと日の目を見せてあげたい
- 辻川さん: 今年は去年に引き続きHTTP2をやっていこうと思う。HTTP1についてはわからない。WSも自前のドライバに入れていく。QUICは待ち
- 林さん: WSはブラウザ上にソケットが増えるということでブラウザの舞台が増えるということ。いいプラットフォームができて違ったプロトコル世界が見えるようになると楽しいなと思う
- Jxckさん: 実装担当と政治担当という感じで
- Jxckさん: まじめにネットワーク見始めたのは去年。QUICのねらいもわかるようになった。HTTP2も標準プロトコルとして最終的にはみんなが使えるようになるとしても、最初はHTTP1とあまりにも違うのでとまどう部分があると思う。ブログに書いたりします
次世代Webセッション アーキテクチャ編
アーキテクチャ編
- 何がおこっているのか、どこへ向かっていくのか
- Jxckさん: 前半をふまえると、TLS前提のWebを求めている人達がある程度はいるらしいとわかった。どうですか?
- Jxckさん: TLS前提のWebとなるとどう変わりますか 藤原さん: SSLは重いのでCPUがムダ、台数が増えるということはある。知らないうちに混在ページ作られちゃってギャーとか。画像だけHTTPだったり
- Jxckさん: クッキーの取り回しとかどうですか 竹馬さん: いろんなものができない前提でできているので、レイヤーができてしまうのはフロントからしても難しい。やるなら全部HTTPS化のほうがうれしい
- 田中さん: ブログやっているとSSLが増えることの影響はある。リファラに検索ワードが書き込まれなくなる。ブログへどんな導線で来たかわからなくなる。ブラウザによってリファラの飛び方の仕様も違う。ブログには外部リソースを貼る人も多くて、世の中TLS前提で進められると困る面もある
- Jxckさん: フルHTTPSはつらい? 田中さん: 何かヘッダを出すとHTTPコンテンツ入れられるんだったらいい Jxckさん: いっそ全世界がHTTPSになればいいと 田中さん: それならリファラも飛ぶし
- 藤原さん: telnetで通らなくなるとか、素人が手を出せる領域じゃなくなってくる、あたりがちょっとさびしいような
- Jxckさん: HTTPレイヤを誰もが書くわけではないので、辻川さんのような人が書いてくれるのならいいと 藤原さん: 難しいところはまかせて、その上で仕事ができるようになれば
- Jxckさん: 運用の話がまだ入ってないという点については? 藤原さん: SSLはセッションが重い。TCP張るよりSSLネゴシエーションも重いしセッションIDのマッピングとか大変
- 竹馬さん: リクエストを並行して投げたときにどれくらい失敗するのかとか。1秒が1.5秒になるのはいいが、0.1秒のものが0.5秒になるのはつらい。webゲームで顔しか表示されない、ようなネットが細くなったときの対応とか求められるのはつらい
- Jxckさん: 仕様を作ってる人達が最初に考えるのはモバイルでは1本のセッションを大事に使うという部分だろう。SSLはまた別の理由で入ってくるとは思うが、HTTP2は高速化をねらっているはずだが
- 藤原さん: WSあまり使ってないですね。数年前にサファリがプロキシ通すとクラッシュするとかあって採用できなかった
- 田中さん: はてなではWSを実際に使っている場所はない。モバイルになって必要性が増してきていて、実験したことはある。iOSアプリにSPDYのせて3G回線上でレイテンシの改善具合を見たことはある。結構使える。LINEがTLSなしでSPDYオレオレ実装していたり、ネイティブアプリでは高速なレスポンスができるようになってきた
- Jxckさん: 運用しているところはgoogleくらいしかなく、ノウハウが出てこない
- 田中さん: 今年後半では使えるようになるかな
- Jxckさん: LINEが辻川さんのライブラリ使っているというように、モバイルだと変わってくるのか
- 藤原さん: モバイルの方が環境決めうちできるのでやりやすい。先進的なことをやろうとするとネイティブでガッチリ組まないといけないのはつらい。リアルタイムが本質のものは使う必要があるだろうが、APIたたくだけのアプリならいらない
- 藤原さん: ゲームがコンソールのようなリアルタイム性を要求するようになってきたことも効いている
- 竹馬さん: ネイティブゲームだと変わってくるかというと、HTML5だといままでネイティブだったものがAPIとして出てきているので、emscriptenのようなガッツリのものが出てくる。ソーシャルゲームがリッチになってきた結果、ゲーム業界が参入してきた。Webもコンシューマゲームのようなリッチなものを作っていた人でないとリッチなものは戦えなくなるのではないか
- 竹馬さん: Webって初期化のレイヤが多い。永続化していって速くするというような、モバイルで回線が細いときの工夫がいろいろ必要になるだろう
- Jxckさん: シングルページとWebの対象ではブログがいい例だと思うが 田中さん: ツールはAngularJSで作ってみましたというのはある。スタティックなページとツールっぽいリッチなページと2分化していくのではないか
- Jxckさん: シングルページで遷移しなくなることによってJS初期化のレイヤがなくなってステート管理が大変などあると思う。運用からは結構変わるのか
- 藤原さん: 遷移しないとJSで通信するという部分が増える。ネイティブと同じでユーザーのアクションがなくても通信が発生する。リトライコードの書き方をしくじると、ブラウザ内でずっとバックグラウンドで動くことがある。堅牢に作らないとみんなが不幸に
- 藤原さん: ステータスが取れないので503を返してても無視してリトライされる場合もある
- Jxckさん: Webを作る上でここが変わったとか
- 竹馬さん: JS回りのエコシステムが充実した。去年と今年でJSでテスト回している人が増えた。ようやく開発がモダンになってきたと感じる
- 竹馬さん: IEとかAndroidブラウザとかJSのイケてないところに引っぱられていて、AltJSが流行る背景にもなっている。静的型付け言語でやっていた人にいきなりJSやれというのも無理。そのへんが変わっていくだろう
- 田中さん: JSに加えて、DevOps的な進化もある。上と下がすごく進化した。サーバーサイドアプリのレイヤーは相対的には進化しなかった Jxckさん: JSONだけ返せばいいから進化しなくてよかった
- 田中さん: シングルページだとパフォーマンス管理も難しい。サーバーで時間測ればよかったのが、クライアント側の処理が増えるとどのへんが遅いとか気づきにくくなる。Firefoxだけ遅いみたいになると方法を確立しないといけないな
- Jxckさん: ISUCONでシングルページを速くするとかなった場合にどうやって測るか 藤原さん: クライアントで何をしてから何をするまでの時間を測るような仕組を作らないとサーバー側で知り得ない
- 竹馬さん: JQueryを使っていることもあり、一度作ったDOMは使い回すとして、自分でやる分にはキャッシュ作ったりなどできるが、サーバー側のレンダリング処理の延長上でならない部分がある
- 藤原さん: 去年はWebの世界をあまり見ていなかったが、ゲームがリッチになってきて、Webやってた人が延長でやりたくなる部分、そうやると大変という部分がある Jxckさん: ゲーム部分はドキュメントベースの人が装飾でやっていると大変と
- Jxckさん: Angularなどはみんなゲームがやりたくてデータbinding入れたわけではないと思うけど 藤原さん: JSでリッチにしようと思うと職人芸。とは言えWebでやりたいという感じはある。いまは容易にできない。もう少しJSとかブラウザ型で性能が出るようになるといい
- 竹馬さん: 高速化というのは結局UXのためにどれだけ20msの中でやるかという部分であって、ユーザーに影響出ないようにインタラクティブにする以上、ゲームじゃなくても教育ソフトなどでも問題になる部分
- Jxckさん: ゲームでなくても職人芸的な部分を持っていたからできたという部分があると
- 田中さん: はてなにはそんなヘビーな部分はないが、すみずみまで知っている人がいて、安心感を持ってできている。まだしばらくは年単位で職人芸が残っていくのではないか。新しいのが出てくることを期待
- 竹馬さん: デザイナーとペアになってこれ重いですかとやっている。最低限速度を満たさないといけない部分は何msを取らないといけない。ユーザーに間を取らせるためのアニメーション遷移などはあきらめて職人芸でやるのもありかな、と
- 藤原さん: ロングpollしてるやつにリクエストが来るまでの時間を測ったり、リアルタイム通信でいかに速く返すかは少し入れたりした
- Jxckさん: いまのISUCONで勝つような人達はバックエンドのチューニングができる人達。フロントについては測定ができないのでISUCONで扱えないというような 竹馬さん: 職人芸というか定量的には測れないだろう
- 竹馬さん: 確実にボトルネックになるような部分があって、タイマーで更新されるべき部分をちゃんとできるか見るとか。モダンなブラウザは60FPSでやってると思うが1/60秒以上遅れるとユーザーは気づいてしまう
- Jxckさん: セキュリティー的にはJSで行くと抜かれちゃうという穴ができてしまうとか、そういう事例はありますか
- 田中さん: いまのところはそういうインシデントはありませんね
- Jxckさん: ダイアリーがブログになったときに問題が出ませんでしたか? 田中さん: ドメイン構造の変化によってクッキーのセキュリティーなど気を使った部分はあるが、HTML5だからどうということではない
- 藤原さん: フロントでいろいろやるようになった分、フロントで処理した数字をサーバーに送るようになって、その数字が正しいかチェックが必要になった。いわゆるゲームのチート対策
- 藤原さん: ゲームでランキングやるとチートが発生しやすい
- 竹馬さん: サーバーとクライアントで別々にバリデーションを持っているのがつらい。nodeを使って同じにできるとうれしいが今の枠組では難しい。walmatみたいにフロントサーバーを置くようなアーキテクチャが出てくるのではないか
- 藤原さん: nodeの運用については、メモリーリークがある。デーモン作るスキルのない人でもやるとできちゃうから問題。リクエスト単位で死んでもよければ多少リークしてもいいが、nodeはそういう用途では使わないので、逆に時々再起動とか残念な感じ
- Jxckさん: なんでもゲームの話になっちゃいますね。次世代Webでもゲームが求められているのかなw
- Jxckさん: シングルページのようなゲームのノウハウが必要なくらいクライアントリッチなものが書けるようになった。全部SSLとか言ってんじゃねーよ的な話が出ましたが、今年はどうなってほしいですか
- 藤原さん: HTTP2はなかなか実装が出てくれない一方、素人では作れないとなると、待つしかない。結局ビッグプレーヤーしか使えない。AWSさんがそういうレイヤを置いてくれれば使えるが、それだとつまんない#cross2014a
- 竹馬さん: MVC,MVVMとか2014年もライブラリがボンボン出ると思う。いままでのクライアントがflashでやってたような、デスクトップのフレームワークに近くなってリアルタイムJSに振られるのでは
- 田中さん: ゲームが一番のユーザーになるのかなと。PCの性能アップのときもそうだった。WSとか極めて高いリアルタイム性はゲームの方が需要が多いので、そこが牽引役になって進めてくれるとありがたい
- 田中さん: permalinkの扱いがどんどん雑になっている。その中でどうやってはてなブックマークなどでpermalink扱うにはどうするかは考えていかないと
- Jxckさん: 去年リアルタイムと言ってた部分が今日はまるまるゲームに置きかわったような気がして、Web上でもゲームの存在感強いな、と思いました。データバインドの話として去年はangularとbackboneの話がありましたがまだまだ結着はつかないですね
- Jxckさん: 「オレの考える次世代Web」についてみなさんブログに書いてください。そこまでがこのセッションです
Cross 2014メモ(1) 現場に聞くパネル
2014/01/17にベルサール新宿グランド行われた、Cross 2014に行ってきました。当日取ったメモを公開します。間違いや発言意図と違うなどありましたらご指摘お願いします。
現場に聞く！テスト/CI/DevOps、実際のところどうなの
参加者
- 直也さん @naoya_ito
- 石橋さん @iandeth
- KAIZENプラットフォーム 調整さんを作った人
- 調整さん知名度高い
- 舘野さん @hotchpotch
- secondlife クックパッド 環境回りの整備
- 伏井さん @hakobe
- はてな アプリケーションエンジニア
テーマ
- CI/DevOps
- gist:naoya/8451019
Github, プルリク
- 直也さん: github+プルリク開発のブログ記事を書いたときは、決して「最新の」とは言わなかったが、いろんな反論があった。「そんなツールあるのか」「そんなのあたりまえ」など
- 舘野さん: コードレビューはツールも使っていたが、ツールの生産性が低く、コードレビューのコストが高すぎた。2012年頭くらいからgithubを使った業務フローを考えてみた。プルリク→マージ→CIをやってみようという感じ
- 舘野さん: 入社して1年くらいはgithubがなく、review boardを使ったりしていたが、コストが高かったのであまりやっていなかった。テストはあった
- 伏井さん: はてな入社当時、テストはあったがあまり定着していなかった
- 直也さん: はてなダイヤリーではじめてテストを書いたが、それはちょっと変えるとこわれるからという。はてなダイアリーの大規模改修のときにがんばって書いたが、手元で流すだけで20分かかって大変だった
- 舘野さん: buildbotなどのCIツールはあったが自分達でやるメリットがあまりわからなかった。書いて2分後にデプロイしたり。あまりバグることもなく、テストの重要性・メリットがわからなかった
- 伏井さん: はてなブックマークの機能が増えてきたときに、t/以下にテストを全部持っていったり。あんちぽさんが整備してテストやるようになった。ある時期CIがもり上がったときにテストも書こうということになった
- 直也さん: Webアプリだと「ビルド」という概念がなかったので、「夜間にビルドがこわれないか保証する」という当時のCIの解説はひびかなかった。自分達と関係ないことだと思っていた
- 石橋さん: コンソールに緑のラインが出ないとテストした気にならないから、Jenkinsとかだとテストしてる気にならなかった
- 石橋さん: 開発が1人から2〜3人になったときに自動化した。開発チームがさらに大きくなるとCIとかなしではやっていられなくなった
- 直也さん: CIがあたりまえと思う人と、やらない人のギャップが大きくなっている気がする
- 舘野さん: やってみないとわからない面がある。文章で読んでもメリットがわからない。
- 直也さん: 講演会でgithubは21世紀の革命だと言ってもポカーンってなることもあった
- 伏井さん: gheができがよくてあれ使ってはじめて役に立つ、みたいな感じ
テスト考2014 by えじまさん
- 直也さん: テスト考2014について。テストを書きすぎると自分の足を撃ってるようなこともあるよね、という話。ユニットテスト書きすぎるとリファクタしにくい、テストが必要というのはいいコードでないなどの指摘
- 直也さん: yoshioriさんは自分のためのテストと守りのためのテストは違うよねというようなことを言っていた
- 伏井さん: ひとでくんの意見: DHHがあまりテストを書きすぎるのは意味がないよと言っている → テストは書かなくていいんだという言い訳を与えるのはよくない
- 伏井さん: はてなではコードの寿命がすごく長い。10年とか。その間に担当の人も移りかわっていったりする。自分の意図が伝わるように、他の人がこわさないようにテストを書いておくという文化
- 直也さん: ひとでくんは執拗にテストを書くくらいでいい、と言っている。はてな座談会ではテストをテキトーに書いてレビューに出すとひとでくんがおこると言われている
- 伏井さん: C0カバレージ(すべての行を過去することを保証)くらいはちゃんとしようという基準にしている。本当に問題のあるコードはリリースしたくない。C0は自動で調べるツールがあるので1日に一度くらい流している
- 石橋さん: C0を100%にするのとテストをたくさん書くのでどれくらい大変になるの? 伏井さん: C0はそんなに大変ではない 直也さん:入力をモックとか使ってやらないといけないよね、それも大変ではない? 伏井さん: やればいい
- 伏井さん: C0を重視というわけではないが、C0くらいはカンタンだからやろうよねと 舘野さん: C0は重視していなくても、テストがちゃんと意図したテストをしているかどうか判断するのにC0は役立つ
- 舘野さん: 社の基準としてはテストを書きましょうとしていて、C0全部とは言っていない。コードレビューとテストで言うと、C0はちっとも本質ではない。実装に対して適切なテストを書いているかどうかの方が大事。テストのリファクタリング、テストの構造化はテストが伝えやすいかわかりやすいかをレビューで見るようにしている
- 伏井さん: はてなでは開発チームごとにツールも違ったりしている。テストをどれくらい書きましょうという考え方もチームごとに違う。C0も一つの基準としてありますよねという程度。このくらいがいいという雰囲気を都度判断している
- 石橋さん: KAIZENはテストの基準はない。モデル、コントローラも書いてる
- 舘野さん: webだとend-to-endのテストがカンタンになっているので、それとビジネスロジックのユニットテストを書いている 石橋さん: 同意。end-to-endが重要
- 伏井さん: はてなブログではcasper.jsを使っている
- 直也さん: end-to-endテストって昔のseleniumの印象があって、すぐこわれる。すごい大変。いまはカンタンに書けるしheadlessになっているしすごくよくなった
- 舘野さん: Rubyではcapybaraで抽象化されていて、バックエンドは切りかえられるようになっている
- 石橋さん: 宣言的に書けるのがいい
- 伏井さん: casper.jsだとボタンクリックの後の変化をsleepで待つなどを明示する必要がない
- 直也さん: コントローラとかどうすんの?
- 伏井さん: JSとかあまり関係ないところはPerlで。編集画面などはcasper.jsを使ってなどという感じ
- 石橋さん: end-to-endはなかなかできていない。KAIZENの特殊なのは、いろんな環境でこのJS貼ってくださいということがあって、クロスブラウザもやっつけられていない
- 直也さん: browser stackなどもあっていろいろできる
- 直也さん: テストはみなさんやっていると。ところがstack overflowは面白いこと書いてて、テストはほとんどしないがユーザーが報告してくれる、と言っている。このアプローチもなかなかいいよね
- 伏井さん: そのへんはバランス。テストでそこそこやって、条件が特殊な部分は組み合わせ爆発とかあるからやらないとか
- 直也さん: えじまさんの議論は立場が違うところで話している面もある。開発チームが2〜3人のところと20人以上でレガシーもあるようなところだと大変。自社サービスかお客さんからお金をもらっているかによっても違う
- 直也さん: テスト書きすぎ問題もいろんな反論が来て「3か月で終わりのプロジェクトでそんなにテスト書いても仕様ないだがう」というのもあった。話のコンテキストが違う
- 石橋さん: マネージメントから倍のコストかかったじゃないか、テストなんかやめろと言われ、戦ったとき、数字で勝ったことはない。頭を下げてやったところ、メンテコストが倍まで行かなくてもよくなって認められた例はあった
テストの環境整備
- 舘野さん: クックパッドには開発基盤グループがあってテスト環境の整備などをやっている 石橋さん: それいいよね
- 舘野さん: テストがどんどんやれることによってユーザーに価値を届けることができる。テストそのものでなく速度を上げるとか、Jenkins回ったあとにステージングに自動で上げて本番環境同等のテストができるとか
- 直也さん: 普通の会社だと顧客要望に応えるのが優先でCIサーバー立てたりという作業がどうしても後回しになってしまう。クックパッドのように組織だってやっているのいうのはひとつのやり方
- 伏井さん: はてなでは、これはぜったいイイと思ったら実装していいという文化がある
- 伏井さん: CIでテストが落ちるとIRCで「【悲報】○○ブランチのテストが落ちました」が来たりする。そういうものがイイと思ったら作っていいという文化
- 直也さん: テストを書かせてくださいと説得してしまうと、次にCIやりたいと思うとまた説得しなくちゃいけない。クックパッドのアプローチはいいと思う 舘野さん: 会社のミッションから立てているのでやりやすい
- 直也さん: 「テストから見えてくるグーグルのソフトウェア開発」という本に、developer productivityと書いたらテストが定着したという話があった。開発者生産性向上という言葉で考えるといいと思う
- 舘野さん: 最初にこのままではダメになると思って1人で一気に書いたりしたこともあった。そこから開発者の間にもテストっていいんだということが啓蒙できたと思う
- 直也さん: 「うちの会議テストやってなくて無理っすよ」という会社もあるけど、ここらへんの会社でもここ2〜3年のことだと思うと、できないことではないんだと思う
- 直也さん: 最近はツールがよくなっている。ぼくらはコードレビューとか10年前からやっていてもなかなか定着しなかった面がある。いまはいいツールもあるのでやりやすくなっているはず
情報共有
- 直也さん: 情報共有どうしてますか? はてなははてなグループってのがあって、業務中にブログ書きながら仕事する。社長も書いてる。メールでやりとりすることはほとんどない。誰が何をやっているか検索するとすぐわかる
- 舘野さん: クックパット入社時はそういうものがなかった。wikiはあったけどこういう風には書いていなかった 直也さん: それでgrouppadってのを作ったんだよね 舘野さん: めっちゃ使われてますよ
- 舘野さん: WEB+DB vol77に書いている。コミュニケーションが増えちゃってよくないんじゃないのという声が最初はあったが、すごくよくなった
- 直也さん: こういうのはすごく大事だと思う。wikiにみんな書くんだけど、いつ誰が何を書いたのか伝わってこない。ブログだとアンテナみたいのがついている。社内勉強会で月に1回だと「あそこはJenkins入れたみたいだぞ」が1か月遅れちゃう
- 直也さん: gree groupも作った
- 石橋さん: 日報ブームがある。ひとりが書き始めるとみんながやりはじめる 伏井さん: こういうのがあると社内で認められて承認欲求も満たされる。社内ホッテントリもいい 舘野さん・直也さん: うちにもあるよ!
- 直也さん: CIやるぞテスト書くぞでもいいんだけど、エンジニア間の透明性が十分ないと、局所最適になってしまう
JICS2014レポート(4) 1/15前編
- 「ソーシャルメディア/モバイルとアイデンティティ」寺田さん
- 「デジタルマーケティングとアイデンティティ」平川さん
- 「ビッグデータとIdentifier(識別子)」佐藤さん
- 「プライバシーとアイデンティティ」崎村さん
「ソーシャルメディア/モバイルとアイデンティティ」
- 寺田さん @ オプト
- オプト: 広告代理店
- モバイルコンテンツフォーラム: 業界団体
- ソーシャルメディアとモバイルが変えたもの
- 購売行動の変化: ソーシャルでAIDMAがAISASになった
- AIDMA: attention, interest, desire, memory, action
- → AISAS: attention, interest, search, action, share
- 検索するときは価値の比較、口コミのチェックもする
- 共有される: 製品のいいところ、悪いところなど口コミ情報
- ZMOT: 店舗に行く前に意志決定がされてしまっている
- zero moment of truth
- first moment of truth → 店舗に行くこと
- showrooming: 店舗で見てネットで買う
- O2O: online to offline、クーポンや位置情報から店舗に誘導
- オムニチャネルという考え方
- 顧客接点が増えてくる → 個々の顧客の行動を把握する必要
- シングルチャネル: 単一接点
- マルチチャネル: 店舗、ネット、カタログが分離されている
- クロスチャネル: 一元化される
- オムニチャネル: シームレスに。チャネル横断の顧客管理
- 顧客接点が増えてくる → 個々の顧客の行動を把握する必要
- 3つのLife: Real Life, WEB Life, Social Networking Life
- モバイルファーストの台頭
- ソーシャルコネクト
- 各所に散在する利用者情報
- サーバーがあちこちに
- 端末内にも情報が
- 自分自信が適正に扱っているだけではすまない
- 連携先が適正に扱っているかも把握
- パーソナルデータ利活用の原則
- 2013/8 総務省 研究会報告書
- Privacy by Design
- 自社もだが、ID連携先が問題: 契約だけ良ければいいのか
「デジタルマーケティングとアイデンティティ」
- 平川さん @ 電通
- マーケティングのパーソナル化とは
- 変化するマーケティング環境への対応
- 購入プロセスのシームレス化
- オムニチャネル化
- すべてがトラッキング可能になる
- O2Oの流れ
- IDデータマネジメント
- 情報提供の入口を消費者がベネフィットを持って同意するのが原則
- デフォルトで取るのはもはやあぶない
- マスセグメントとして処理した上で、顧客にとってパーソナルに見えるようにメッセージを工夫。本当の意味でのone-to-oneではない。タイミングが重要
- メールアドレスは利用
- 情報提供の入口を消費者がベネフィットを持って同意するのが原則
- デジタルマーケティングの運用フロー
- マスセグメントとして統計知を得る → セル分割の更新
- ビッグデータ×アイデンティティ
- 電通: 「ヒト」の動きを見てきた
- メーカー: 「モノ」の動きを扱ってきた
- 「と」でカンタンにつながるものではない
- 丁寧な情報入手、顧客主導の情報開示を入れていく
- 具体的にはどんなデータが
- ビッグデータ時代のマーケティング分析
- セグメントオファーとフィードバック
- ソーシャルCRM
- 優良顧客のお友達は優良な潜在顧客
- インフルエンサーから同意を得てID化
- 「いいね!」を集める時代の終焉
- まとめ
「ビッグデータとIdentifier(識別子)」
- 佐藤一郎さん @ NII
- 人のIDよりモノのIDで仕事をすることが多い
- IDとは
- identify document (身分証明書)
- identity (個人特定、パーソナルデータ)
- identifier
モノのID、特に商品のID
- JANコード: バーコードになっている
- 国番号、企業コード、アイテム番号、チェックディジット
- 国際的なとり決め
- 国番号(日本は49)より下は各国が決めてよい
- 日本では企業コードより下は各企業が決めてよい
- チェックディジット
- JANコードは13桁だが、本当は12桁でよい
- → バーコードという読み取りシステムを前提としたcheck digitも含まれている
- → ID(識別子)は読み取り技術と独立とは限らない
- 商品コードは世界共通
- 各国によって使えるプリフィクス範囲が異なる
- 先に手を挙げた国が広い空間を得ている
- 商品バーコードが生まれた理由
- 誰が発明したのかよくわからない状況
- レジ待ちの時間短縮のため
- 1970年代のアメリカ、巨大スーパーで普及
- 各スーパー内で番号をつければ十分だった
- → スーパーごとに番号をつけるのはムダ → メーカでつけるように → 標準化
- IDと商品
- レジ待ちを短くする → 商品DBは各スーパーで待っている
IDで見えてくること
- POSシステムから見ると
- IDのついた商品パッケージを買っているにすぎない
- もっと言うとIDを買っているにすぎない
- 商品コードは誰が管理するのか
- JANコードでは流通システム開発センターが企業番号を割り当て
- POSが広く使われる時代
- 商品IDのない商品は流通できない(事実上存在しないのと同じ)
- 流通データを持っているのは小売 → 商品情報を登録してくれなければ売れない(存在しないのと同じ)
- プライベートブランド商品とJANコード
- 書籍には2つのバードコード
- 上: ISBN
- 下: 販売情報
- 価格情報が入っている → 再販制度があるから
- 一般的に返品可能な業種は在庫管理を含めIT化が遅れている
- カフカ事件
- 某出版社の文庫本で、相違な書籍に同じISBN番号をつけてしまった
- 書店や図書館などは翻訳できない大事件
「プライバシーとアイデンティティ」
- 崎村さん @ OIDF
プライバシーって何?
-
- privacyとdata protectionの混乱
- 語源からのアプローチ
- private + -cy
- privatus(ラテン語) 他から分離して、自身に帰属させた
- publicus(公共の)、communis(共同体の)と対義
- プライバシーがよくわからないのは、文化によって公共・共同体の考え方が違うから
- 個人情報とプライバシーの混乱
- 文献からのアプローチ
- 「Right to be let alone」
- 個人の不可侵の権利
- プロッサーの4類型
- レッシグのプライバシー定義論
- 自分に属する情報は自分がどう使うか決めてよい〜情報流通の自由
- 自己決定の権利
- 自分が出したいところに出すのも権利 → identity連携
アイデンティティって何?
- エンティティと属性
- 自己像(identity)
- どの属性をどのコンテキストに見せるかを自己決定
- 友達と上司とで見せる自己像を変えたい
- コンテキストを越えて自己の望まない形で属性が出てしまうと「プライバシー侵害」
- アイデンティティ連携
- 属性の集合から、どの部分集合をサービスに提供するかを同意する
- もう一つのポピュラーなモデル「バレたら炎上モデル」
- ひそかに or だまして集めて勝手に使う
- お客に正直なことを言ったら同意してもらえない
- お客の利益にならないことをやろうとするから
- 後から何に使うかわからない、後から同意をもらえない
- お客に正直なことを言ったら同意してもらえない
- ひそかに or だまして集めて勝手に使う
- 「ブレーキは速く走るためにある」
- 米国「消費者プライバシー憲章」PIA
- PIAの標準化作業中
- プライバシートラストフレームワーク
- ルールと強制手段
- PTFの現状
- ID trust framework
- 属性の質品
- privacy trust framework
- パーソナルデータの扱い方
- ID trust framework
- 明示的同意?
- そもそも同意の向きが逆
- 個人が企業に対してパーソナルデータ提供をライセンス、同意するのは企業の側、となるべきでは?
- 個人によるプライバシー侵害
- ケースとしては多いだろう
- 見なかったことにするプライバシー(大人の対応)が重要になる
- MAC Address, BT Address、取れてしまったとき、見なかったことにして捨てる
- 個人をリスペクトせよ! そうすればそんなに大きな間違いはおきない
JICS2014レポート(3) 1/14後編
事例から学ぶID漏洩防止
根岸征史さん @ IIJ
- 「情報漏洩事例から見えてくるユーザによるパスワード利用の実態と課題」
- パスワード
- 何十年もずーっと使われている。ずっと変わっていない
- ユーザー視点 → 根岸さん
- 攻撃者視点 → 辻さん
- サイト運営者視点 → 徳丸さん
- 情報漏洩事例(国内) 2013年
- Y! 2200万件
- OCN 400万件
- NAVER 200万件
- 海外
- Adobeの例
- 2013年10月
- 「お客様のIDは攻撃を受けたデータベースに含まれていたものの、パスワードは影響を受けなかった」→うのみにしてはダメ
- ヒント情報も漏洩している → ちゃんと書け
- 9.3Gバイトのテキストファイルに1億5千万
- メールアドレス、3DES
- ECBモード → saltがない。誰と誰のパスワードが同じかわかってしまっていた
- パスワードのヒントも平文で保存されていた
- ヒントにそのまま書いてる人もいる「1〜6」とか
- Adobeのパスワードトップ10
- 123456が190万人とかとても信じられないものが並んでいる
- トップ10だけで全体の2%くらい。これが実態です
- JPドメインのIDに限ると、少し良くなる。数字の並びが多いのが日本の特徴
- Gawker, LinkedInなどを持ってきても傾向は同じ
- IDを入れると漏洩したか調べてくれるサービス
- 2013年意識調査
- 使い回している8割
- 強いパスワード3割くらい
- まとめると
- 現実として弱いパスワードが使われている
- 現実としてパスワードが使い回されている
- 弱いパスワードの例
- 他人にかんたんに推測される
- telepassword
- 総当たりで破られる
- GRC Brute Force Search Space Calculator
- 探索空間の広さを教えてくれる
- 過去に漏洩したものを使っている
- 2億4千万件の漏洩したパスワードを売っている
- 他人にかんたんに推測される
- どういう世界が理想?
- パスワードがダメだ
- パスワードだけじゃダメ → 2要素
- 使い回しできなければいいんだ → ID連携
- ユーザーの責任だ
- ユーザーがんばる/がんばらない × サイトがんばる/がんばらない
- 両方がんばらない方法: OSやブラウザががんばる?
- 論点
辻伸弘さん @ NTTデータ先端技術
- 「パスワードの破られ方入門」
- tsujileaks.com/ntsuji.pdf
- 自己紹介 @ntsuji
- 元侵入テスター → 攻撃側視点
- 普段はanonymousあたりの観察をしたり
- はじめに
- 定期変更なんてイヤだ!
- 攻撃手法いろいろ
- brute force攻撃
- 辞書攻撃、置きかえ(1→!、a→@など)
- reverse攻撃: 弱いパスワードを固定して多数のIDを試す
- リスト型攻撃: ID、パスワードの対をリストにして、使い回しを試す
- どこから入手する? → 盗む or 買う
- ツールあれこれ
- medusa, キングギドラ(?), ncrack
- デフォルトID/パスワード対のリスト
- routerpasswords.com など
- packetstorm, johntheripperなど
- 流行としては…
- 攻撃の流行りすたり
- 最近は→リスト型
- Adobeの漏洩では「adobe123」はリストにのっていない辞書にある単語のパスワード
- 高いリスト買わなくても、辞書攻撃でいけるのでは?
- 流行はあるものの、流行だけが危ないわけではない
- 辻さん: 攻撃者はとっても有利。ぼくらが「どうすんねん」と言ってる間にどんどん弱いところをついてくる。こういう状況がずっと続いている
- さいごに
- 対リスト型攻撃 → 使い回しをやめる
- 対brute forse → 質の高いパスワードをつける
- 自分を母親が使えるような技術を採用したい
徳丸浩さん @ HASHコンサルティング
- 「サイト運営者はパスワードリスト攻撃にどこまで責任があるのか」
- パスワードリスト攻撃とは
- 脆弱なサイトを攻撃して入手したパスワードリストで脆弱性のないサイトに入力してみると、一定の確率で入れる
- 社会実験をしてみる人が多数出てきて迷惑しているw
- 脆弱なサイトを攻撃して入手したパスワードリストで脆弱性のないサイトに入力してみると、一定の確率で入れる
- 背景にあるのはネットの「格差社会」
- 2005年ごろはほとんどのサイトが均等にぼろぼろだった
- 2008年ごろから、よくできてるサイトが目立ちはじめた(格差)
- 格差を利用して弱いところから抜いて強いところを攻めるようになってきた
- ユーザー間にも格差がある
- アカウントロック
- ログインID毎にパスワード間違いを記録し、連続してN回間違えた場合、X分アカウントを無効にする
- パスワード認証の保護機能の基本
- しかしジョーアカウント、githubへの弱いパスワード攻撃などには有効でない
- githubへの弱いパスワード攻撃
- ゆっくりと、異なるIPアドレスから5回だけ試し、もう来ない
- → 検出・ブロックが困難
- IPアドレス単位での認証ロックあるいは監視
- 2段階認証 & リスクベース認証
- サイト側負担が大きい
- ログイン履歴確認
- 防御はできないが気づきがあるかも
- パスワードの辞書チェック
- パスワード変更時に弱いものをはじく
- tw, g, fb, githubが使っている → これらのサイトはIDが公開だから?
- パスワード変更時に弱いものをはじく
- 辞書、リスト、フィッシング、MITBに対する防御は、利用者の責任管あるものをサイト側が救済しようとしている
- 本当にやらないといけないことは何か?
- 長いパスワードをつけられるようにしておく
- 1文字のパスワードをつけられたら、それは脆弱性? → ユーザー責任じゃねーの
- 本当にやらないといけないことは何か?
- パスワードリスト攻撃の登場人物
- おもらししたサイト
- 攻撃されたサイト
- 攻撃者
- 不正ログインされた利用者
- 1番目 → 攻撃者
- 2番目 → おもらししたサイト → わからないので出てこない
- ハッシュ、ソルト、ストレッチで守る責務がある
- 3番目 → 利用者: 使い回しをしていた責任
- 一番悪くないのは攻撃されたサイト。正直守りようがない
- でも利用者にも言い分が「ぼくパスワード認証使いたいとは言ってないもん!」
- まとめ
- パスワード認証のタテマエとして管理は利用者の責任という考え方がある
- でもそれ無理だよね。そもそもパスワード認証したいとか頼んでないし…
- サイト運営者の努力だけでは守り切れない面がある
パネル
- 楠さん Y! ID本部長
- 就任2日目で大規模な漏洩事件が
- 「パスワード認証」50年残っているIT技術はなかなかない
- 1965年passwdファイル公開の vulnerability 報告。来年が50周年
- 主旨
- 答を出すパネルではない
- インターネットにターゲット
- パスワードとはそもそも何か?
- 合言葉、クレデンシャル
- メリット・デメリット
- 意識と記憶が正常なら安定して出力可能
- 概ね人体(=本人)のみで完結
- 任意の使い分けが可能
- 記録・複製・伝搬が可能(=残念ながら自分の意志とは別に)
- 変更時は相手との同期が必要
- 根: 本音とタテマエのところで、使い回すのは悪いが、現実そういう人はいる。一方、パスワードはここ数年ではなくならない。そういう人を救うには極端な例でもいいからどういう方法があるか出してみてはいいのでは?
- 徳: 成立してはいなくてもそこそこ攻撃を受けているサイトさんで、ユーザーがITに強くない → 1回パスワードリセットしてみては? → それ攻撃を受けたみたいだからイヤだ → 全国一済パスワードリセットデーをやってみてはどうか(無理っぽい)
- 根: リセットしてもまた同じのつけるんじゃないかな
- 根: ユーザーにパスワードつけさせるのが悪いのでは?
- 徳: それはアリ
- 徳: パスワードを表示するので回りに見られる人がいないことを確認して表示ボタンを押せ → 根: 覚えられないですよね!
- 楠: パスワードどころかIDも忘れる人もいる。サイトの都合でやれ○文字だ、使い回すなと言われても困る
- 楠: ユーザーにとってパスワードや暗証番号っていつから使っているのか。コンシューマにとってのパスワードはいつから?
- 林: ダイヤル式鍵前が4桁
- 楠: 4桁をこえるとパスワードとは呼ばないのでは? 住基パスワードリセットに30分かかって終わらない事件もあった
- 楠: 4桁PINとパスワードは違うものとは認識していないのでは
- 根: トークンをみんなに配ってとか大変。パスワードマネージャは?
- 徳: トークンハンドリングを人手でやってるのがおかしいというのはそのとおり
- 楠: 銀行カードの番号は奥さんにも教えてる。しかしY!のパスワードは教えない
- 林: パスワードマネージャで言うと、googleにはパスワードっぽいところにランダム文字列を入力する機能をもっている
- 楠: パスワードマネージャは可逆暗号なのでドキドキする。キーチェーンもiCloudなのかローカルなのかわからないので、うっかりワイプしてしまうリスクがある
- 楠: ヨメさんに知られるのがイヤなだけで米政府に知られる分にはいい
- 徳: これがダメとか言い出すとどれもダメなんで
- 楠: 魂を売るのか問題になる
- 楠: 相矛盾している神話がある。使い回すな、定期変更しろ、同じの使うな、とか。無理ゲーを強いられている
- 辻: 毎回リセットしてる「なんちゃってワンタイムパスワード」をしてるとはいる「パスワードを覚えられない人はこちら」
- 毎回リセットは覚えられない人がいるほどはめんどくさくない
- 楠: パスワードリセットできない人は時々いる。「自分の誕生日を忘れました」という人がいる。ウソの情報でアカウント作って、後でリカバリーできなくなる
- 楠: Evernoteが何で全件リセットできたかというと、到達可能なメアドが割と新しかったということ
- 徳: ひみつの質問はなんとかなんないですか?
- 楠: もう少しかかります。しかしこれもトレードオフ
- 根: 事業者ごとの判断も難しい。ここまでやっとけばOKというのを作っておかないと、事業者コストがどんどん上がる。結局損をするのはユーザー
- 楠: 生体認証はリカバリできないので、パスワードを最後の手段として残してある。一番弱いものを使わざるを得ないのが難しい
- 辻: 攻撃側はローリスクでハイリターンが欲しいので、弱いところを狙うよね
- 林: インターネットで一番弱いところがあると全部弱くなってしまうというのはショックで、みんなで歩調を合わせていかないと。これは国をまたいで攻撃が来ちゃうので、議論を進めていきたい
- 根岸さん: 他から漏洩したときに自分も対処しないといけないので難しい。今後ウォッチし続けないといけないとすると、どうします?
- 楠さん: やや緊急避難的に今回は対応しました。同様のことがしょっちゅう起こってもらっては困る
- 楠: パスワードリスト攻撃、できることはある
- 辻: 本当は攻撃したやつが教えてくれたら一番セキュアだが、それは無理
- 辻: パスワードのつけ方とか、学校の教科書にはとてもいいことが書いてある。草の根的に「今日お母さんに教えてね」ってやらないと、我々では限界
- 根: みんなでやっていかないといけない部分がある
- 徳: カンタンログインはたたきつぶす立場なのですが、UI的にはよくできている。パスワードなくしたというのが大きいと思う。カンタンログインは技術的に残念なところがあったが、良くしていけばいい。アプリ認証が万全というわけではないが普及していけばいいと思う
- 根: ID連携に乗ったらみんな幸せなのか。懐疑的なんですが
- 楠さん: ID連携みんなしたいのか。事業の根幹であるユーザーリストを預けてこっちがお金を払うとかあり得ないでしょ。twやfbがうまくいったのは書き込みしたいから。そういうはっきりした価値を示さないとフェデレーションは進まない。事業者都合やユーザーがパスワード覚えたくないだろうというだけで押そうとすると、MS Passportの失敗から学んでいないだろうと思う
- 辻: どうでもいいところだけ連携するのはどう?
- 林: そういう目的でgmailアカウント取っている人はいる。意識的にせよ無意識的にせよやっている人はいる
- 徳: 自前のパスワードつけるところには税金をかけるのはどうか
- 楠: 海外にサーバー置くだけではないか
- 林: 日本のIDって価値が上がっていると思いませんか? 日本語フィッシングメールの日本語がだんだん良くなっていますよね
- 楠: 言語バリアに守られていたが、そのコストを無視するようなメリットがフィッシングに出てきたということだろう
- 根: 格差ということにはドキッとした。これだけの対策ができるのは大手だけだよなあ、救わなきゃいけないユーザーもできてない人達なので
- 楠さん: bitcoinマイナーのASICを使うと10^18 hash/sec行けてしまう。そのへんの危機感が共有されていない
- 根岸さん: 攻撃側、解析側の能力向上がサイト運営者に伝わっていない感がある
- 徳: 徳丸本でストレッチを書いたけど、レビューアにも抵抗があったようだ。書いといてよかったー
- 根: いまはストレッチ5000、1万なんてのが普通なんですが、そういうことがわかっていない
- 楠: パスワードマネージャが流行ったとたんにPMのふりしたマルウェアが出たりすると手に負えない
- 根: PM使うとひとつのパスワードで全部やられちゃう。そういうリスクが評価できるのか。専門家しかできないだろ
- 徳: (Y!さんの)ひみつの質問と答に関する確約をいただけたのが個人的にうれしい。リセットが安全になればパスワード管理の手間が助かるなあと
- 辻: 「パスワード覚えられない人はこちら」を生みだせたのが今日の収穫w 使えない人が追いてけぼりを食ってしまうものだけは、なくしていきたい。それがITかな、セキュリティーかな、と思っている
- 根: 普段は専門家としての立場から見ているけど、パスワードというのが使いにくい世間になってきている。うまい落としどころをさがしていく、答はないけどみんなでさぐっていくのが大事と思った
- 楠: おととしの秋くらいから兆候があった。十数年やってきたパスワード管理のバランスが変わってきてしまった。過去からの経緯でこうなっているが、道具がそろっているのに惰性で続けてきたことが怪しくなってきている。これまでぼくらはわかっていながら何をやってこなかったかをよく振り返ってみたい
ジェネラルパネル: ビッグデータの可能性と現実
- 参加者
- モデレータ: 佐々木さん
- パネリスト
- 喜蓮川さん: NII所長
- 板倉さん: 弁護士
- 吉井さん: SBテレコム
- 喜蓮川さん
- 吉井さん
- 板倉さん
- 半導体でかつて勝っていた → 負けた
- Social Machines
- 佐々木さん: 何を突破すれば次のステップに進めるのか。今後のビジネスの突破口は?
- 喜蓮川さん: 人間の行動と IoTをfusionする
- 佐々木さん: チャネルになっていればいいが、レイヤーだとどのレイヤーかわからない
- 喜蓮川さん: データは国の財産だ。なにかというと「cool」に行ってしまう風潮はどうかと思う
- 佐々木さん: コンテンツより流通構造が重要なはず
- 吉井さん: bigdataやりたいが社内でも止めたがる
- 名寄せしたい ← やめなはれ
- privacy commissioner を置いてほしい
- こういう使い方をしたいですよ、と見せると、OKとかNGとか言ってほしい
- 気持ち悪さだけで話してほしくない
- 佐々木さん: 顔認識カメラ実験 → 法的には問題ないのにキモチワルさで怒る人が多い
- 板倉さん: 個人情報保護法でもそうだが、合意は無敵。一方で小さい字で書いて押させる流れは自爆的
- 本人にリーチできるんだから、ちゃんと説明し、後からこんなことしてたとは知らなかったと言わせないようにする透明性が必要
- わかんない、言わないでやった → キモチワルイの元
- クリックさせればいい、ではなく、わかってもらうことが大事。UIデザインも重要
- 佐々木さん: 医療学会では症例が出てみんなで学ぶ・共有することが求められている
- 個人情報は削除するが、共有が前提である。一方で難病になるほど名寄せされやすく、共有が必要なのに難しくなる
- 喜蓮川さん: オープンガバメント、オープンデータ
- 「この人には開示する」をどうコントロールするかという問題。
- 枠組をちゃんとつくるのが、少なくともヘルスケアには大事
- 板倉さん: 日本は相当厳密な手続きで開示している。医療は別途法律をとりまとめるとして話が進まないままになっている
- 包括して検討するには、やはりケースを持ってきてもらうしかない
- 喜蓮川さん: IDとか公開していいものはもっとあるはずだ
- 名寄せしないことにはビジネスは進まないよね
- 吉井さん: 公共権という考え方がある。
- 佐々木さん: BT LEではペアリングなしでつながる。iPhone持って店に入るとすぐわかるようになる
- 佐々木さん: プライバシー法制度の問題とキモチワルさの問題、これは構造的になんとかなるのではないか
- 喜蓮川さん: マナー、は拘束力がないので、やってもしょーがないという許容範囲を考えたい
- しかしPasmoの乗車履歴のような情報は、人が殺められる可能性まである。これは規制したい
- 自分が言ったことで起こりますというと、誰もせめられない
- こういう世の中になったんですよ、説明していくしかない
- → 教育の問題として考えるべき
- 吉井さん: 技術的に言うと日本人の平均的なプログラミング能力は高くない
- その教育によってITの仕組みや名寄せのタイミングなどが理解できるようになるだろう
- 板倉さん: バカッターはデータ保護法制で救うべき範囲ではない
- 喜蓮川さん: 教科情報が大学入試にとりあげられていない
- 「大学入試に出ない科目をどうして勉強するのか」と言われるとぐぅ…となってしまう
JICS2014レポート(2) 1/14中編
13:00-14:00 基調講演
レイヤー化する世界とID 佐々木 俊尚さん
- 「安心社会から信頼社会へ」山岸俊男
- 一般的信頼 vs ヤクザ的コミットメント
- 米: 信頼する
- 日: ムラ型、信頼しない
- ヤクザ的社展 → 一般的信頼への移行?
- 一般的信頼 vs ヤクザ的コミットメント
- 「ケンとメリーのスカイライン」「青春の殺人者」の'70年代的世界観
- グラノベッター「転職」
- strong ties / weak ties 理論
- どちらが自分が社会生性年送る上で重要か
- weak tiesから転職などの情報が入ってくる
- 当時の皮膚感覚とは逆の主張だった
- 知らないところの人のほうが情報を持っている
- 訳者の渡辺さんいわく
- '80年代の日本ではstrong tiesから就職情報が入ってきていた(コネ入社など)
- 現在はweakの方が強くなってきているだろう
- 米国は一般的信頼社会、weak ties型と言われてきた。でも、そうでもない面もある
- 「On the Road」 一般的信頼の時代('50年代)
- → '70〜'80年に劇的に低下
- メディアの発達により、猟奇的殺人者の報道がなされるようになった
- → 気ちがいヒッチハイカー、よそ者に警戒するようになった
- 「On the Road」 一般的信頼の時代('50年代)
- 2000年代からまた変わった
- 日本におけるシェアハウスの流行
- 「総透明社会」と到来
- 当事者性
- 情報発信に対する態度: 発信者 → 反応者 → 観察者; そして無関心者
- インターネット: 誰も観客にはなれない発信
- cf: 観察者を意識した発信
- 参加しなければ得られるものもない
- 個人として考えるべきこと
- 「他者」を受け入れること ┓
- 「透明」を受け入れること ┣ が必要だよね
- そして寛容であること ┛
ID連携の必要性とセキュリティ 谷脇 康彦さん
- 情報共有の重要性
- 「情報をつなぎ合わせる」ことの重要性
- 「世界最先端IT国家創造宣言」 2013/6
- Big dataの4分類
- オープンデータ: machine readableにする
- 知のデジタル化: 農業クラウド…老農夫のノウハウ、経験と勘の記録
- センサー等のM2M: 車のプローブ → 信号間隔の調整
- パーソナルデータ
- → これら4者の活用、デザイン思考、異分野活用との組み合わせが重要
- 東北メディカルメガバンク計画
- 電子カルテ
- 医療データ ←(連携)→ 介護データ
- パーソナルデータの利活用
- プライバシー保護との調和
- 適切なバランス ┓→ 国際的調和
- すでに蓄積されたデータは海外にもある ┛
- プライバシー保護との調和
- パーソナルデータの利活用 制度見直し方針: 2013/12
- 提案: 実質的識別性
- 一律ではない、個人主体の許可、制御する権利
- 2014/6までにとりまとめ → 2015国会提出を目標とする
- 提案: 実質的識別性
- 匿名化技術の活用とルール
- 再識別を避けるには?
- マイナンバー
- サイバーセキュリティー
- まとめ
