「Facebook messenger」を含む日記 RSS

はてなキーワード: Facebook messengerとは

2022-09-14

結局10代はLINEをどういう目的で使っているのか?

今の高校生にとって『LINE』は「年上と連絡を取るため仕方なく入れるアプリ」らしい

https://togetter.com/li/1943706

seri @seriserimisa

高校生にとって、LINEは「年上と連絡を取るために仕方なくいれるアプリ」らしい。うちらでいうfacebook messenger みたいなものか。

2022-09-11 00:07:44

aa @aa60006342

1日前

10代が一番利用率高いし主語がでかい案件 https://www.moba-ken.jp/project/service/20220516.html

はてブ

https://b.hatena.ne.jp/entry/s/togetter.com/li/1943706

odenboy トゥゲッターコメント欄でこのタイトルデマを示すデータが投下されてる。ちゃんデータを見ることが大事だと学べるゴミみたいなまとめ。

2022/09/13

cmplstofB id:odenboy デマだと息まいているところ悪いが,件のデータあくまで「利用」についての調査から,そのアプリを誰と,何に使っているか,そしてその利用をどう思っているかなんてことは分からないぞ。

2022/09/13

LINE利用率8割超え:10~50代まで8~9割が利用

https://www.moba-ken.jp/project/service/20220516.html

年代LINE利用率は

10代 94.0%

20代 91.4%

30代 88.7%

40代 81.5%

50代 80.6%

60代 76.4%

70代 69.0%

このデータを見る限り10代の利用理由が年上と連絡をとるために仕方なくだという可能性を考えるのは無理だと思うんだけど

cmplstofBはどういうシナリオで「10代が仕方なく使ってる」「年上の世代になるほど利用率が下がる」が両立する現実的レベル可能性があると考えているんだろう

10代にとっての年上のLINE相手なんて親・教師くらいしかいないが10代の94%の子達の多くが親・教師と連絡をとるためにLINEを使ってるなら

30代40代が利用率90%を割っていくものなのだろうか?

現実的レベル可能性を考えられるシナリオが無いのなら「高校生が年上と連絡するために仕方なく使っている」というのがデマになるのは避けられないと思うが

2021-07-04

スマホを眺めていても得るものなんてないよね。いや、自分の使い方が悪いんだろうけどさ。

TwitterFacebookみたいなSNSなんて害悪だし、2chまとめサイトとかtogetterも結局それらの派生から同じ。なんも得るものなんてない。

だけどLINEFacebook messengerで連絡を取ることも多いし、親からの連絡もそれに含まれから断ち切るわけには行かないんだよね。

からLINEとMessengerと通話、それとおサイフケータイが使えるだけの小さい端末を買ってそれをメイン端末にしようと思ってる。

2019-06-25

🌚なぜ🥬LINEを使っているのですか? 

なぜ 🍏WhatsApp や 📘Facebook Messenger を使わないのですか?

2019-02-03

マジでLINEかいうクソボケサービス使うな

複数台のスマホで使えないとかそんなSMSサービス他にある?

無いよ!

今それで苦しんでるんだけどおかしいだろ!

日本人はみんなLINEだ。あと台湾とか、タイも使ってるんだったかな。

なぜFacebook Messengerを使わない。

無料GIFで楽しく画像会話出来るのに。

世界で最も使われてるSMSなのに。

使い勝手LINEの比じゃないのに。

Facebookevilだの言われたって、純粋LINEの方がゴミじゃん。

あーあ、FacebookテレビCM打ってくれれば一瞬で駆逐できると思うんだけどなあ。

日本人CMに弱い。

2018-11-29

欧米流行しているWebサービス

日本国内でもメジャーだったりマイナーだったり

サンフランシスコ20年働いてます

Facebook

SNS定番はやはりコレ

Delete Facebook運動炎上してもFacebook Messengerを含めてデファクトスタンダード地位はなかなか陥落しない

Twitter

Twitter流行しているのは日本だけではない

Twitter黎明期ではAPI自由度が高く、TwitterはそんなAPIを利用するIT系エンジニアと協力して育ってきたという歴史がある

そのため今でもIT系エンジニアが利用している傾向にあり、海外IT系エンジニアを講演などへ招待する際Twitterを経由するのがデファクトスタンダード

ただし近年のTwitterの動きによりDelete TwitterしてしまったためコアなIT系エンジニアとは連絡付かないことがある

こういう人はGNU SocialかMastodonかDiaspora*かFriendicaに居る

Instagram

欧米10代に評価され一気にユーザが増えたSNS

まりにも一気に流行しすぎる上に、Facebook傘下となってしまたことにより10からはオジサンバサンばかりと言われる始末

10代はTikTokへ移行してしまった

TikTok

前述のInstagramがオジサンバサンに乗っ取られてしまったため10代が移行したサービス

TikTokのノリは流石のキラキラ系のオジサンバサンもキツいのかInstagramほどオジサンバサンの参戦は少ない

ただ"つぶやき"先がTikTokかと言えばそうではないようだ

Youtube

日本ではニコニコ動画が人気であったときに、ゆっくりと普及していったYoutube

Youtubeクリエイターのための収益サービスを展開したことにより日本でもニコニコ動画駆逐した

動画投稿者のことを当初欧米ではYoutube CreatorやVideo Creator、Videographerなどと表現されていたが、Youtube自身CMの影響により最近欧米でもYoutuberという表現を見るようになるという和製英語逆輸入パターンが起きてる

YoutubeブランディングとしてYoutuberという語は丁度良かったものと思われる

Youtube TV

Youtube地上波TV放送CATVが観れるサービス

欧米特に北米ではCATVが強すぎるのでWebからも観れることが多い

日本ではNHK問題とかあって何だか色々面倒くさい

Twitch

ゲーム向け動画共有サービス

日本では何でもかんでも動画Youtubeとなっているが欧米ではゲーム動画と言えばTwitch

特にチャット/コメント欄Youtubeよりも見やすく、ゲーム親和性が高いので評価されている

ただ近年は厳密に住み分けされているか?と言われるとそうではなく、Youtubeのみで活動しているゲーマーTwitchのみで活動しているゲーマー比較するとTwitchの方が多いかな?という程度

Reddit

欧米定番電子掲示板サービス

ただ2ちゃんねる(5ちゃんねる)と同様にユーザ高齢化が進んており、若年層も居るといえば居るがメインのユーザ層かと言えば絶対にそんなことはない

Slashdot

Redditよりも高齢化が進んでる電子掲示板サービス

日本スラド民と似たようなもの10代はほとんど見ないしスラドに常駐している10代の将来を心配したくなる

流行しているか微妙だが関連の流れで紹介

Disqus

コメント欄のないWebページやブログコメント欄を追加できるサービス

サービス性質としてはコメントがメインの文化のため日本はてなブックマークに近い

Disqusを設置する管理者側が有料プランに加入していないと広告が表示されてしまうため紛らわしい面もある

Pocket

正しくソーシャルブックマークサービス

あとで読む」など有用機能も高評価されている理由

Pinterest

デザイナーファッショニスタには定番スクラップサービス

日本でもアンテナ高い人は使っている印象はあるが、日本支部女性スタッフが知らなかったりすることがよくあるのでまだまだ日本では普及しきっていない印象を勝手に持ってる

日本ではInstagramあたりでデザインファッション流行を掴むことが多いらしいが欧米ではPinterestのほうが利用されている(Instagramはそういう用途でのノイズが多い)

ただPinterestが普及しているからと言って欧米人がオシャレかと言えば察する必要がある(サンフランシスコ住民IT系ブランドTシャツ好きすぎ問題)

WhatsApp

欧米では実はインスタントメッセンジャーサービスが乱立しており、送り先ユーザによって常駐しているインスタントメッセンジャーが違うというのはありがち

WhatsAppFacebook Messengerでなければコッチで連絡付くだろうというポジション

利用者比較的若年な傾向はあるが、絶対的にそうとは言い切れない

SnapChat

ポストWhatsAppか?と言われていたものののWhatsAppを超えることなく失速した感のあるチャットサービス

それでもTikTokに行かなかった10代はSnapChatを利用している傾向にある

Slack

ビジネス向けチャット

職場Slackを導入していてくれたらコチラで連絡を取るということも少なくはない

チームメンバーと気軽にやり取りできると高い評価を受けリモートワークの普及に貢献したが、気付いてみたら24時間働けますか?状態になってしまった

欧米では過労働が絶賛社会問題化進行中。欧米日本に追い付いてきた。

Discord

主に欧米ゲーマー需要を満たすゲーマー向けチャット

Slack互換APIなどIT系需要も満たし人気

友人グループ間のボイスチャットでは最早デファクトスタンダード

SMS

Webサービスかと言われれば悩むが、詳しい人なら現在SMSは大きな括りで言えばWebサービスだと知っているはず

欧米でなぜここまでインスタントメッセンジャーが乱立しているか?といえばSMS存在があったか

電話番号を知っておりどうにも連絡付かない場合SMSを使うのがド定番

Hangout(Hangout Chats)

Googleインスタントメッセンジャーサービス

Gsuite(Google Documents)ユーザを中心に使われており定番と言えば定番と言えるポジション

Gsuite(Google Documents)

教育

欧米教育現場ではGsuite無双表現しても良いくらGoogleシェアを持っている

Microsoftもそこそこシェアを持っているがGoogle比較したら数段落ちる

Apple教育現場でのシェアゼロと言っても良い。Appleが悪いのではなくGoogleが普及しすぎてAppleが不便になっちゃってるだけ

学生学校宿題を友人間シェアし、共同編集宿題を進めるなど、10年前では考えられない宿題ハックが流行している(共同研究表現するとアリっちゃアリかな?)

ビジネス

ビジネス現場では主にスタートアップMicrosoft Office代替として利用されている

Gsuiteを導入している企業では非常に細かなオフィススイート機能を使う際はiWorkやLibreOffeceなどを使う傾向にある

当のMicrosoftAzureなどのサーバサイドサービスビジネスの主軸を移しつつあるので、そこまでMicrosoft Officeでの収益は期待していないように思われる

JIRA

プロジェクト管理ツール

大手からスタートアップまでプロジェクト管理ツールはたいていコレ

欧米ではMicrosoft OfficeよりもむしろJIRAのほうがヘイトを集めているような気がしなくもない

Evernote

Gsuite(Google Documents)と比較すると厳しい面が捨てきれないオンラインノートサービス

Evernoteのコンセプトが自身スタイルに合えば非常に有用サービスなのだが、大半の機能は他のWebサービス代替できてしまうため立ち位置微妙

ちなみにこのエントリの下書きはEvernoteで書かれている

Dropbox

クラウドストレージサービス

Evernoteが苦戦する理由がGsuite(Google Documents)とこのDropboxにあり、共同編集スクラップブック的な用途はこの2つのサービス代替出来てしま

UNIX/Linuxへ対しても公式的にサポートしているというのもDropboxの優位性

Foursquare/Swarm

位置共有サービス

自身位置地域施設レビューを共有するためのサービス

ポイントや進捗などのゲーム性がある点が評価理由

Google Map

最早説明必要がない地図サービス

Foursquare/Swarmのような位置共有やレビュー機能も強化され、待ち合わせや情報収集に関しても隙がなくなった

Waze

Google出資しているドライビングナビゲーションサービス

サンフランシスコ道路渋滞する原因の1つ

Spotify

音楽聴き放題サービスSpotify絶対ポジション

ただYoutube Musicが登場したことによりSpotifyの充実したプレイリストという優位性が少なくなったので注目されている

個人的にもYoutube Musicに移行しても良いかな?と検討中

Nest

ホームマネジメントサービス

ハードウェアも売っているのでWebサービスか?と言われると微妙だが、ホームマネジメントではNestが圧倒的シェアを持つ

Google傘下であり、Amazonもここ最近は頑張っているが、インターホンや空調管理などのハードウェアは結局NestなのでGoogleは上手いことやったなという印象

Apple教育と同じようにこの分野ではゼロと言っても間違いない

Adobe CC

圧倒的コストパフォーマンスを持つクリエイティブサービス

ここまでAppleがボロクソだったがAdobe CCのためにiPadが手放せないという人も多い

一時期クリエイティブ系のWindows移行が進んでいたが、Adobe CCのお陰でクリエイティブ用途Apple延命された

Amazon

説明する必要がない通販サービス

電子書籍分野でもKindleトップシェアとして君臨

Steam

ゲームストアプラットフォーム

ゲームデベロッパーの中にはSteam依存を下げようとする動きがあるものの、やはりユーザ数として魅力が高く、その地位は揺らぎにくい

アダルトゲームの開放タイミングなど時流の読みが上手い印象がある

Uber

配車サービス

日本でも展開しているが、本来Uber白タクになってしまうので日本ではほぼ別サービス

MyFitnessPal

定番フィットネスマネジメントサービス

特にカロリー計算有用飲食店商店を含む料理食材栄養情報が既に登録されており、自身健康管理が便利にできる

ちなみに日本情報もそこそこあり、情報に不足があればデータベースへ追加して拡充できる

その他の動き

VLOG

欧米では年齢関係なくVLOG(VideoLog)によって自身日常シェアするのが流行している

顔出しに抵抗のない文化を歩んできたこともあって、そういう点が日本とは大きく違う

その動きは動画自動編集ツールGoProなどのアクションカムドローン、先日発表されたDJI OSMO Pocketなどのハードウェア製品にも現れている

商業店や公共施設・公官庁政治家に至るまで積極的スタッフ・本人の日常的な動画作成し公開する動きもあり、ポジティブな印象形成に役立っていると思われる

例えば日本だと教師政治家休日に開いたホームパーティーの様子を動画で公開してしまうという肌感覚理解しにくいように思う

OS

WindowsなのかMacなのか、iOSなのかAndroidなのかはぶっちゃけ当人によるという感じになっている

IT業界ではMacbookのシェアが高いのは事実だが、クライアントMacWindowsなだけで実質Linux仕事しているという人も珍しくはない

CG業界ではWindowsが主流と言われてきたが、近年では研究だと当たり前ではあったが、(レンダリング用途に)Linuxが小さな企業にも台頭し始めていることもあり、状況によるところが大きい

例えば某超有名宇宙戦争モノの映画にもLinux活用されていたりしているところを見ると考えさせられるものがある

2016-10-17

How the Textsecure Protocol (Signal, WhatsApp, Facebook, Allo) Works

http://www.alexkyte.me/2016/10/how-textsecure-protocol-signal-whatsapp.html これエキサイト翻訳か?主語が全部theyという支離滅裂英語なんだが。

----

TextSecureの目標は「経路末端までのセキュリティ否認性、前方秘匿性、将来の秘匿性のすべて」を提供することである。具体的には、可能な限り短い時間だけ鍵情報を保持するメッセージストリームを二者の間に構築するということを目指す。将来に鍵の危殆化があっても、現在観測されたトラフィックを復号化できなくするのだ。

以下にSignal Protocolの批評分析を羅列してある。実装構造研究し、発見した欠陥を記述し、上述の目標がどれほど実現されているか評価するものである。まず仕組みの説明をしてから、より詳細な分析を続けることにする。

用語

TextSecureは、今ではSignalと呼ばれているアプリに与えられた名の一つだ。コード文書も一貫してTextSecureという名を使っている。一貫性を保つため、システム全体をTextSecureと呼ぶことにする。

ただ実際には数々の異なるものが含まれている:

構造

TextSecureは、非同期整合性に焦点を当ててOff-The-Recordというチャットプロトコルを改造したものだ。OTRが対話ハンドシェイク必要とする一方、TextSecureは不確定な遅延を認めない。メッセージを送れるようになるまでアプリを表示したままにしてハンドシェイク遂行しなければならないというのであれば、ユーザ体験はひどいことになる。

そうではなく、通常の鍵交換においてサーバが果たす役割の部分だけ、将来のクライアントが取得しに来るよう中央サーバに格納される。このサーバは、すべてを復号化できる鍵情報は預けておかない、信用なし経路となる。すべての暗号化は末端どうしだ。

暗号

TextSecureは暗号学の基礎のほんの一部を使うものである公開鍵暗号は楕円Diffie-Hellmanを通し、Curve25519を用いて実行される。AESがパディングなしカウンター(CTR)モードサイファーブロックチェーン(CBC)モードの双方で対称暗号に使われる。HMAC-SHA256がメッセージ認証に使われる。これらが信頼の基礎(TCB)である

ダブルラチェット:

TextSecureの暗号化エンジン中心部はAxolotlダブルラチェットアルゴリズムである。大まかに言うと、一方向にだけ回ることのできるラチェットが二つあり、一つは受信ラチェット、もう一つは送信ラチェットである。この構造により、鍵交換の前半を保管しておいて、後から非同期的に再生し完全なハンドシェイクを得ることが可能になっている。

受信ラチェットメッセージが受信されるときに使われるが、そこには次の鍵交換のための新しい材料が含まれていなければならない。この材料が後ほど暗号化メッセージ認証に使う対称鍵の生成に用いられる。

送信ハッシュラチェットは前回の整合性ある共有秘密から生成された鍵ストリームを使って新たな鍵セットを生成する。このラチェットは、受信ラチェットが進んで共有秘密が変化するとリセットされる。

ここで注目すべきは、メッセージ送信するために送信者が待つ必要は一切ないということだ。いつでも送信第一歩を踏み出すことができ、その一歩は必ず有限の時間で終わる。メッセージはすべて異なる対称鍵で暗号化されるが、これにより、ある時点の鍵は、どちら側のデバイスのものであっても、過去送信されたメッセージを復号化するためには使えないことになる。(ただし後で一つ警告がある。)

プロトコル

フェーズ1: TextSecure登録

登録は、クライアントに言って、連絡用の電話番号サーバに教えてもらうことから始まる。また同時に、トークン通話SMSどちらで受け取りたいか希望登録してもらう。このトークンが持ち主の証明となり、TextSecureで情報登録できるようにしてくれる。

クライアントメッセージ認証暗号化の対称鍵('signaling'鍵)、および長期公開鍵を送る。

また、複数のプレ鍵も送信する。これはクライアントが受信者になる時の鍵交換の半分、クライアント側部分の使い捨てコピーである。こうして保管されているプレ鍵のおかげで、将来の送信者はクライアントの応答を待つ必要もなく鍵交換を完了でき、こうして遅延を劇的に減らすことができる。クライアントは「最後の手段のプレ鍵」もアップロードするが、これは最後に使われ、受信者が新しいプレ鍵を追加するまでのセッションでずっと共有され続ける。

他のクライアントからも使われるプレ鍵に頼ることについてSignalが警告をしないというのは、筆者の意見では、理想と程遠い。

クライアントは次にGoogle Cloud Messagingに登録して、登録IDをTextSecureに出す。このTextSecureへの登録には、クライアントSMSを受け取りたいかデータだけにしたいか情報も含まれる。

フェーズ2: 鍵の比較

TextSecureはクライアントどうしがお互いの長期鍵のフィンガープリント比較して本人確認できるようになっている。鍵をQRコードとして表示して便利に検証できるようにする機能も含まれている。

フェーズ3.1: 最初メッセージ送信

送信者は、まず相手のプレ鍵を要求し、プレ鍵インデックス、プレ鍵、登録ID、長期公開鍵をもらう。これらを使い、HKDFという鍵派生アルゴリズムを通して共有秘密を取り決める。この秘密情報ルート鍵と呼ぶ。

このメッセージだけの一時鍵ペアが生成される。ルート鍵を使ってHKDFで新しいルート鍵とつなぎ鍵を派生させる。このつなぎ鍵は、暗号化MACの鍵を生成するのに使われる。

最後AESカウンター初期化される。カウンターは二つある: ctrとpctrだ。ctrカウンターメッセージ送信ごとに増える一方で、pctrカウンターは、最後既読メッセージの番号を保持する。これにより、受信者側にバラバラの順番で届いたメッセージを正しく並べ直すことができる。

これらを使って相手メッセージ暗号化し、それをSignalサーバに送る。このメッセージには、相手が鍵交換ハンドシェイク完了できるだけの必要情報が含められている。

SignalサーバGoogle Cloud Messenger登録IDが件の電話番号に合っているかチェックし、メッセージを'signaling'鍵で暗号化してからクラウドサーバに送る。この遠回しな方法により、Google Cloud Messengerがメッセージ送信元を知らずにいることが保障される。

フェーズ3.2: メッセージ受信

信者はプレ鍵インデックスを受け取り、送信者がどのプレ鍵を使ったかをそれで調べる。そして送られてきた情報を使ってハンドシェイク完了したり送信者と同じルート鍵を持ったりする。送られてきたメッセージを復号化するために使う鍵は、このルート鍵が生成する。

フェーズ4: 追伸メッセージ送信

相手が返信する前に、もとの送信から続きのメッセージを送りたい場合は、新しいつなぎ鍵を生成して、これを使って新しい暗号化およびメッセージ認証の鍵を得る。

フェーズ5: 返信の送信

信者が返事を出したい時は、まず新しい一時鍵ペアを選ぶ。送信者の一時公開鍵自分の一時秘密鍵を使って、新しい共有秘密を生成する。これを使って新しいつなぎ鍵を得て、そこから新しい暗号化認証の鍵を得る。これを使ってメッセージ暗号化し、さきほどの新しい一時公開鍵と一緒に送信する。

既知の問題

鍵の提出

TextSecureは、サーバクライアント間の共有秘密、いわば機械生成パスワードを使って、新しいプレ鍵のアップロード認証する。これは送信メッセージ認証にも使われる。このパスワードを漏らしてしまうと、それだけでメッセージ送信も鍵アップもそのユーザなりすましてできてしまうことになる。エキスポート機能があった頃はTextSecureクライアントを別のスマホに移行することができたが、この機能は削除された。エキスポート情報には機械生成パスワードが含まれていたからだ。この平文バックアップデバイスSDカードに置かれていたので、他のアプリから読むことができたのだ。

この機能はそれ以来削除されたままだ。なくて困る人がいるとしても、これはユーザビリティ問題ではなく、現実問題であり、それに対する後ろ向きな対策なのである

未知の鍵共有 (UKS) 攻撃

この攻撃は偽配送一種だ。攻撃者がUKS攻撃を実行すると、ある送信者が攻撃者に向けて送ったつもりのメッセージが、攻撃から別の人(標的)へのメッセージとして送信される。

これは能力のある攻撃者にとっては簡単にできる。TextSecureサーバ上にある自分公開鍵を、標的の公開鍵に変えればいい。これは自分電話番号を再登録すればできる。送信者はQRコードを使って、相手フィンガープリントが合っていることを検証できるが、これが本当に標的の鍵のフィンガープリントになるのである

それから、今度は送信者のアカウントを再登録して、その検証SMS確認通話送信者に到達しないよう横取りしなければならない。これは太っ腹に権限を与えられた人には造作もないことだ。こうして、送信者として認証し、既知の署名つきメッセージ送信できるようになる。

この攻撃はTextSecureでは解決されていない。プレ鍵の署名は追加したが、まだ暗号学的にIDと関連付けられているわけではないので、奪われて再生される危険がある。

できることがあるとすれば、送信者と受信者の双方がメッセージ暗号化された本文内で言及されるようにすることなどだ。

目標達成率

TextSecureはその構造のおかげで前方秘匿性を獲得している。前方秘匿性(forward secrecy)は、もし長期公開鍵安全なままであれば、ある時点の対称鍵が漏れても、そのセキュリティ突破限定的時間範囲しか有効でないとする。新しいラチェットのそれぞれに公開鍵必要であることから、これは達成されている。

完全前方秘匿性(perfect forward secrecy)は、クライアントの持つある時点の鍵が奪取されても、それ以前に送信したメッセージの復号化が不可能である性質定義されている。このことはTextSecureのwire protocolにより施行されるが、少々ことば遊びに入ってくる。というのも鍵はデバイスにのみ格納されているので、アプリ上の他の鍵にアクセスすることなく鍵が暴露されることはありそうにない。長期鍵だけではメッセージを復号化できず、ラチェットステート対応する一時鍵が必要になるが、これはそのスマホから引き出すことができるので、送信したものの返信されていない(前回のラチェット使用した)メッセージを復号化できる。これは技術的に言えば「以前の」メッセージ暴露である

否認性(アリバイ)はさらあやふやだ。ある特定メッセージについて、それはだれにでも作成できたのだと言うことは可能だが、その一方で、プレ鍵は公開されているので、TextSecureの中央集中構造が脅威をもたらす。TextSecureサーバ認証メッセージ転送をするものだが、それを記録することもできる。内容は末端どうしで暗号化されているとはいえ、メタデータは違う。

Sources

Analysis Whitepaper:

http://ieeexplore.ieee.org/document/7467371/

Marlinspike, Moxie (30 March 2016). "Signal on the outside, Signal on the inside". Open Whisper Systems. Retrieved 31 March 2016. https://whispersystems.org/blog/signal-inside-and-out/

Posted by Alexander Kyte at 11:47 PM

2016-07-16

断言はしないが、チャットボットも関連ビジネスも機会はあるよ

はじめに





先日、はてな匿名記事で大きくバズってる記事があったので、拝見したが、何とも言い難い気持ちになった。

匿名記事なので、あえて私についての説明を加える必要はないかと思うが、某記事と近い立ち位置であることはご理解頂きたい。

チャットボットに関する議論方向性が見えないのは、チャットボットというワードによって、様々なものを一緒くたにしてしまっているかである

現状は、切り分けると実に多様である

チャットUIのものの「チャット」なのか、Facebook MessengerLINEなどのプラットフォーム依存の「チャット」なのか。

人工知能を用いた「ボット」なのか、単純に応答を返す「ボット」なのか。

今回は、プラットフォーム依存の「チャット」、単純に応答を返す「ボット」という意味でのチャットボット実用性についてお話したい。

そもそも、昨今のチャットボットブームというのは、Facebook MessengerLINEなどがプラットフォームを公開したことに依るもので、そこに新規性があるはずで、今しなければいけない議論はここにある気がしている。



チャットボットユーザーフィットするか



よく言われるのが、ユーザーは使うのかどうか、という話であるが、プラットフォームがβ版の最中で、今これを議論するのは時期尚早である

だが、在米時代Uberボットを使ってみたり、在中時代WeChatで色々とボットを試してみると、これがかなり便利なのである

私はそもそも電話が嫌いであるし、ウェブアプリを横断するのも面倒くさい。

その中で友人などとメッセージをやり取りし、そこからアプリを動かずに予約をしたり、企業に問い合わせたり、というのは手間が省けて実に良い体験であった。

では日本ではどうだろう。

ここは、まだユースケースが出ていないことが問題である

だが、若者世代含め、チャットアプリ生活の大きなパイを占める時代においては、当然求められても納得出来る。

であるからして、予約や定期的に購買するECデリバリーサービスメディア諸々、チャットだけで完結するようなユースケースは必ず出てくると思う。

そういったケースが増えていくと、「これはなんでチャットで出来ないんだ」という時代が来てもおかしくはない。

いろんなものネット可能になった時に、「なんで今の時代ネットで出来ないんだ」と思われたと同様に、だ。

チャットじゃなきゃダメなんですか?」ではなく、「チャットじゃダメなんですか?」という問が来る日もそう遠くはないかもしれない。

課題



一方で、課題は山積みである

今回、人工知能型ではないものに重点を置いたのは、人工知能型には課題が多すぎるからである

自然言語処理も精度は高くないし、無論、感情を読むなどはまだ先の話になるだろう。

そして、まるで人間ですよ、というものに対し、ユーザーが対人コミュニケーションを望むのは間違いない。

人間に話しているのに、およそ意味不明な回答が来たらユーザー離脱するだろう。

一方で、そもそも人間ではなくただのシステムだと認識していたらどうだろう。

今は、ユーザー企業も、雑談人間らしさはさておき、ちゃんと言ったことをこなすコマンド型のボットに期待すべきだ。

いわば、アプリチャットUIにして、コモディティ化しているプラットフォームで公開する、ということだ。

今までユーザーアプリに対して人間らしさ、などというものは微塵も期待していないはずで、そのようなボット像を目指すべきではないかと考える。

また、ユーザーに広く使われるためには、チャットボットと言えども、UXは非常に大切である

この点においては、プラットフォーム解決しようと頑張っている。

FacebookがQuick Replyという機能実装したことから見えるのは、

⑴そもそもユーザー発言に揺れが出ないように、最初から選択肢を用意しよう

ユーザーテキストタイプする手間を省いてタップだけで済むUIにしよう

ということであり、チャットボットが広く使われる上でのUIを見越していると思われる。

その上で、企業側も前述のようにプラットフォームが用意したUIいかにフル活用して、いかユーザーが使いやすものを作れるか、が非常に重要だと考える。





最後



多様なものが混合しているワード漠然差して、「これはない」というのは暴論だろう。

1VCさんが、この領域絶対ない、というのは新規投資スクリーニング有用だと思うが、それならば実名にし、そのVCではチャットボットサービスには投資しません。

と言ってしまった方がコスト削減になるのではないだろうか。3割もの方がチャットボットサービスについて話し、毎回同じ議論をしているのだとすれば、それこそ無駄である

なんなら、事業内容を聞いて、「チャットボット」というワードが入れば「事業内容を変えなさい」と返すチャットボットでも作ってみてはいかがだろうか。

こういった機会は、毎回必ず様々な議論を生み出すが、全員の意見が一致しないからこそ、投資価値があり、それを見抜いたものが勝つ業界だと思っている。

から、是非ともチャットボットサービスを考えている皆さんは、ちゃんと自身サービス価値を見極めた上で、頑張ってほしい。

チャットボットが来るかどうかは分からないので断言はしない。

だが、その不確実さこそ、次なるサービスが生まれる絶好の機会ではないだろうか。

2015-10-27

Facebook写真を3人に共有したら友達を1人失った話

写真友達と共有したいときどうしてる?


たくさんあると思うけど、今回僕が使ったのはFacebook限定公開機能

共有したい友達選んで普通にタイムラインアップするやつ。

たった3人を公開範囲指定して写真をアップしたら、

Facebookじゃ拡散する(?)からやめろ!と

前代未聞の大喧嘩につながったという悲劇

とある会への参加

先日とあるAさんが主催する会があり、僕は友人Bとほか数人で参加した。

その会の最後でこんな感じのアナウンスが。誰も詳しくは覚えてない。

「この場で撮影した写真SNS投稿せずに、LINEとかで交換してください〜」

なるほど、不特定多数に公開しちゃダメなわけだ、と僕は解釈

この場にいる人であとで写真交換しなきゃなぁ、と。

翌日、身内メンバに写真を共有

そして翌日、写真を整理し...

参加した身内メンバーの共通連絡網であるFacebookに、公開範囲限定して写真をアップしてみた。

たったの3人への公開。

Facebookメッセージってたくさん立ち上がるとウザいし、タイムラインでも良いかな、とタイムライン上への送信。

(ちなみに一緒に参加した友人にLINE IDを知らない人もいるし、今までFacebookのみで連絡してきた仲間だ。)

謎のメッセージ

FBにアップしてから時間後...友人Bからメッセージが届く

B「SNSには上げないでって言ってたよ」

お、おう、確かに。公開範囲分かってないのかな?と思ったが…

B「限定公開なのは知ってるけど」

???

なるほど限定公開だろうがSNSを使って写真シェアするということが、そもそも嫌なのか。

最近Facebook使って仕事のやり取りすることが多いし、

この辺りのハードルが僕の中では低くなってたかもしれないなぁと思った矢先。

B「LINE投稿と言うか」(言うような言わないような)

B「FBが乗っ取られたらどうするか」(セキュリティの話はLINEにも言えちゃうっしょ)

B「Aさんの意図に反さないか」(Aさんその辺よくわかってると思うし、意図汲み取ろ?)

B「FB拡散する恐れがある」(いやそれお前+2名が余計なシェアとかしたらやん!)

B「LINEは一対一のコミュニケーションに特化してる」(それ、使い方によらないかな)

B「Facebook messengerなら良いと思う」(やってることあまり変わらないと思うんだけど)

※括弧内は最後まで伝わらなかったが僕の心の声

こんなメッセージが。

道徳セキュリティサービス性、全方位からとにかく投稿をやめさせたいらしい。

しかし結局何が言いたいのか分からない。

このままではこの時代に、ディスクデータを渡さなければならない…。

かれこれ2時間会話を続け…要はこの認識に差があったことが問題らしい。

B「"SNSへの投稿"の意味は、FacebooktwitterLINEタイムラインデータを流すこと」

B「LINEのトークやFacebookメッセージtwitterメッセージデータを相手に送ることとは違うと思う」

B「俺の見方をする人は一定数いると思う」

公開範囲とか、不特定多数への公開とかは全く関係がない「SNSへの投稿」という文字列に囚われた思考

DropboxもHangoutもLINEも「投稿」じゃないからOKということだそうだ。

しかも、同じ考えを持った人は(Bさんによれば)少なからずいるらしい。宗教かな?




今後はBさんとのSNSでの関わり方には気をつけないとな…と。

実際そんな人がたくさんいるのか知らないが、本当にあった怖い話

 
ログイン ユーザー登録
ようこそ ゲスト さん