  |
はてなキーワード: プラットフォームとは
水商売、風俗嬢をしていた人の服装はどうしてあんなにも独特なんだろうか。
色は全体的に白・赤・ピンク・黒でまとめている。
20代前半をターゲットにした薄手のシフォン感のある化学繊維の服を
歳をとってからも平気で着続ける。
淡い色で描かれた花柄、丈の短めのジャケット、ミニスカートが大好き。
靴はミュールや、前方のソールから厚底のプラットフォームと呼ばれるヒールが多い。
総じてかかとはつぶれている。
髪の毛の色は明るく、化粧は黒っぽい。
先日、朴とつな知り合いに恋人ができたというので写真を見せてもらったところ、
まさにこのタイプだった。
カクヨムに投稿してるけど、やっぱりなろうの方が流入は多い。UI は洗練されてて使いやすいと感じるんだけど、やっぱり利用者がいないとね。
ニコニコのグローバルメニューからカクヨムにリンクが貼られるようになったり時報スペースで流れたりして、ニコニコユーザーが流入した結果、ランキングに異世界モノや俺tueeモノが増えたりしていて、結局なろうとの差別化に失敗している印象。オフィシャルプラットフォームとしての強みもあんまり活かせてないかな。二次創作はランキングで見かけないし。
作者として不満なのは読者との距離が遠すぎる事。なろうのようにダイレクトな感想がない時点で、フィードバック不足は否めない。スターだと物足りないし、レビューというのは第三者に向けたものだよね。返信もできないし。かといって外部の SNS でつながるのも迂遠だし、面倒だと感じる読者が多いはず。
結果として承認欲求はあまり満たせない。この状況で飽きっぽい中高生が連載を続けるのは無理だと思う。せっかくニコニコと連携してるんだし、いっそ段落ごとにコメント付けられるぐらいのレベルでも良いと思うんだけどなぁ。
このあたりは正統派じゃん。
でも、最近ってネタに走ってるじゃん。ガチでやったら外れ的な。
ホラーってやっぱ時間かけないと作り切れないジャンルなんかなあ。なんで良質のホラーって最近出てこないんだろう。
てか、映画だけじゃなくて、小説とかでも最近は正統派の怖いジャンルが出てきてない。角川ホラーとかでも、昔ほど良作出てないように思う。
う～ん『メルキオールの惨劇』とか、『ナイトヘッド』とか、かなりレベル高いホラーが１０年くらい前はパンパン出てたのになあ。
なんつーか。ホラーってパクリは面白くないジャンルなんだな。落ちが読めちゃうから。
ホラーが怖い理由って、不安定な感覚が怖いって感じるんだけどさあ。その不安定さがなくなっちゃうんだよねパクリで落ちが読めてしまうと。
だから難しいのかねえ。今までにない設定や読めない落ちやジャンルが求められるから。
例えば、『震える舌』って破傷風にかかった子供の看病っていうそんなのがホラーになるのかよってジャンルでホラーにしたり。
でも今は、もうスタートから、雪山だの、ストーカーだの。まったく不安定さがない、安パイ中の安パイで勝負しても何も面白くない。
これが難しいんかなあ。
最近のホラーはいいところもまああるよ。雰囲気とかね。雰囲気イケメンじゃねーけど、雰囲気ホラー的な感じ。
雰囲気はいいんだよ。『さあ、地獄へ落ちよう』も雰囲気はよかったんだけどねえ。でも、斬新さゼロ。
う～ん、時代もあるんだろうねえ。昔は固定電話とかしかなかったり、そういう規制があったけど。
今なら、ネットでいいじゃんとか。ケータイかけろよとかで、実感ゼロになっちゃうものなあ。
今見たら松本清張の『点と線』とかもトリック意味不明だしなあ。
ゲームとかもどうなんだろう。『かまいたちの夜』とか、『首がない子の話』とか、『ホームタウン』とか、かなり怖かった。
でも、今のホラーゲームってどうなんだろう。ゲームならゲームでの怖さとかさあ。そういうのを感じるゲームが少ない。
anond:20160426124418 と anond:20160426145507 の続きだゾ。てか長えよ
(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認証プロキシの SaaS アプリを筆者は作った。好評だったが、これはもちろん本来あるべきでない欠陥のexploitのはず。)
(略: 個人ユーザ向けのAPI設計ばかりで、雇用者や上司がアカウントを管理するという観点がない。SAMLでは普通にできるのに、OAuthとなるとセキュリティ的に云々と言って拒むサービスばかり。別のUIで既にできてることをAPIにしても意味がない。これまでできなかったことをAPIで可能にするのではなく、単なるシングルサインオンでよければ他にある。実際Googleは個人向けにはOAuthを活用しているが、Google Apps for BusinessはOAuth以外のシステムを使っている。)
(略: 主要な設計ミスは、外部サービスすべてを同等に疑うところ。管理者が各サービスの信用性を判断して権限を調節できるようにしないところ。これまでどれほど多くの製品がOAuthの面倒さのために失敗してきたことか。)
ここまでで「普通の実装における」OAuth がまったくおかしいということはわかりましたが、OAuth が実際うまくいくのはどういうときでしょうか。
初期の OAuth 規格および概念におおよそ付き従っているシステムは一般的に言って、新しい規格ベースのよりもセキュアで、マシです。OAuth 1.0 の実装がすべてセキュアだというのではありませんが、たいてい問題は少ないです。こうしたシステムは通常、次のふたつのアプローチのどちらかに従っています:
とはいえ、このように設計されている OAuth ベースのシステムはごくごく希少で、しかも一般的にこうしたシステムは、他のところで使われている OAuth とは似ても似つかぬものです。OAuth 1.0 規格の方に寄って頑張っていますが、公式には 1.0 は非推奨ですから、こうしたアプローチを使っているシステムはそのうち「アップデート」されて OAuth 2.0 の概念や追加機能すべてを加えて再構築され、セキュリティやユーザビリティをだめにしてしまうことになります。これこそ筆者があらゆる OAuth ベースのものを見逃したくない理由です。もっと古く、もっと機能的な形式の OAuth を使っていても、システムに「改善」が必要だという素敵な考えを管理者のだれかが閃いて台無しにしてしまうからです。ご迷惑をおかけしてすみませんと言うぐらいなら、まったく別のものを使うほうが良いですよね。
他に手はないかと探すとき、人々はよく他の「フレームワーク」にはどんなものがあるかを知ろうとします。しかし、考え抜かれたセキュアな設計を実現するためには必ずしもフレームワークが必要というわけではありません。現状、OAuth とはどのようなものかについての意見はサービスごとに異なっていますので、承認の具体的な動作の仕組みもまったく一定ではありません。そんな中でフレームワークを探しまわるのは、簡単にできることをいたずらに複雑化しているだけのことが多いです。唯一ほんとうに難しい要素、しっかりした規格の必要な要素は、使用する鍵パラメータの改竄を防ぐため変数に署名する方法だけであり、この点に関して、ほとんどの OAuth ベースの実装は一切何もしてくれません。
ウェブサービスの最大手である Amazon は、世界中の企業にサービスを提供する一流プロバイダで、合計 30% 以上という途方もない市場シェアは他者を圧倒しています。Amazon のアプローチは、自分でアプリの認証情報を生成できるコントロールパネルへのアクセスを、すべてのアカウントおよびアカウント管理者に提供することです。この認証情報で、どの Amazon サービスで作業できるか、そのサービスでどの操作を実行できるか、どの権限で作業しなければいけないかを指定できます。この認証情報は必要に応じて「アカウントホルダ」の人が破棄することもできます。
Amazon の API における認証や承認技術には、本質的に制限が多く潜在的に危険性のあるリダイレクトを一切必要としません。Amazon のプロトコルで認証情報は、直接送ることは一切なく、データの署名に使うのであって、これでブラウザを通してパラメータを送る必要のあるときにも改竄不可能にすることができるのです。
Amazon の設計はアカウントの利用状況を API の利用まで適切に把握できますし、API の認証も承認もすべて Amazon 側からスタートし、その際のアプリ認証情報も「Amazon の」コントロールパネルから生成されます。この認証情報はその後、いかなるトークン交換システムも使わず直接 API プロセスで使われます。この設計なら「普通の実装における」OAuth が達成している真のセキュリティ目標をすべて達成し、かつ前述したセキュリティ上およびユーザビリティ上の問題をすべて回避しています。
ひとつ言及せざるをえない短所は、Amazon の権限システムが幾分わかりにくく、あまりユーザに優しくないということです。ただし、このことは何故かほとんどのコントロールパネルにも言えることで、いずれにせよ UI 設計の問題であって、承認プロセス自体の失点ではありません。さらに、Amazon のコントロールパネルはかなりキビキビ使えて、それ自体の API でも使えます。この点たとえば Google の場合のように、筆者の知る限りメタ API もなく、何をするにも何十もの手順が必要なのとは大違いです。
Amazon の認証および承認メソッドは他のサービスプロバイダにも幾つかコピーされています。Google 自身も企業向け製品の一部でこれを利用できるようにしています。Google 自身、純粋な OAuth 設計は企業サービスに向いていないことを認めており、企業サービスには JSON Web Tokens (JWT) の利用を推奨しています。
JWT はサービス間の SSO や API 利用を可能にする規格です。多くの点で JWT は SAML に似ていますが、SAML はややこしくて、XML Security (名前と違って、まったくセキュアではない) の上に構築され、API 利用に向いていないのに比べ、JWT は SAML の主要な目標を、単純かつ使いやすい方法で一切の面倒なく達成しています。HMAC 実装をひとつ用意し、JSON の構築と解析の方法を知っておけば JWT は使えます。既製品をお求めでしたら、膨大な JWT ライブラリが既に存在していますよ。
ただ Google の場合、典型的な JWT 利用法よりも高度で、HMAC のかわりに、もっと高度ですがこの分野では人気の低い RSA デジタル署名を利用するよう要求しています。Google のコントロールパネルではアカウント管理者が自分の企業サービス用に新しい鍵ペアを生成でき、API ログインを署名するために使う秘密鍵をダウンロードできます。こちらのほうが HMAC よりセキュリティは高いですが、Google はプロセス全体を本当に無駄に複雑化しています。コントロールパネルをしょっちゅう完全に再設計して、前と同じことをしたいのに使い方が違っていて混乱する点は言うまでもありません。JWT 利用の実例が必要なら他をあたるようお勧めします。
他に使われている技術は、サードパーティがどんな権限を必要としているかをある種の XML や JSON ファイルで定義してウェブサイトに送信できるようにするサービスのものです。ユーザがあるページを自分のアカウントで訪問し、ファイルの URL (あるいは中身) をそこに貼り付けると、その外部サービスあるいはアプリが求めている権限の一覧やそこに含まれる説明などが表示されるようになっています。それを見て認可したいと思うユーザは、認証情報を生成してそのサードパーティのアプリあるいはサービスに貼り付けます。ユーザは後で無効にしたくなったら認証情報を破棄することができます。これも、開発者におかしな負担を強いることなく、すべてのアカウントに API サービスがあり、権限管理を備え、サービス自体からフローが始まる、実にセキュアな設計です。
承認管理のためにサービス側から提供してもらう必要が本当にあるのは、適切な役職 (管理者やアカウント所有者など) を持つユーザが自分に割り当てられた権限や (望むなら) 期限を持つ認証情報を API 利用のために生成できる何らかのパネルだけです。こうした認証情報はその後、お好みのセキュアな認証システムを通して利用することができます。たとえば HTTP Basic Authentication over HTTPS のような単純なもの、これは事実上どの HTTP ライブラリにも入っていますし、HTTP Digest Authentication、これはもっとセキュアでありながらほとんどの良質なライブラリでサポートされていますし、その他 HMAC, RSA, 楕円関数など認証情報をネットに通す必要のない暗号学的テクノロジーを活用した認証プログラムに基づくものなら何でも使えます。特に HMAC は、承認や認証を実装するほとんどすべての人 (Amazon や、一部の OAuth 実装も含む) によって既に使われています。
こういった種々の実績あるテクニックは、セキュアなプラットフォームを作るために CSRF 対策など複数のフレームワーク同士の相性を勉強する必要があるという重荷を軽くしてくれますし、一般的に、既存アーキテクチャにワンタッチで装着できるようなモジュール化の実装が可能です。ユーザやアプリの認証情報が盗まれる可能性をなくしてくれます。ややこしい CSPRNG を常に使用する必要もありません。このようなシステムは OAuth の生まれるずっと前から存在しており、現在でも一般的です。OAuth は、ユーザの認証情報を要求したり他に弱点があったりするような一部の劣悪な設計のシステムよりはセキュリティが良いかもしれませんが、既にある真の設計を置き換えるものではありません。OAuth が解決すると主張する問題点は実のところ、既存の良く設計されたシステムには存在していませんし、「普通の実装における」OAuth は実のところ、解決すると主張する問題の多くを招き入れるばかりか、最初は存在していなかった問題まで生じさせています。宣伝文句と違って、OAuth にすれば自然と驚くほどセキュアになるというわけではなく、むしろ数々の短所や実装の困難さを考えれば、他の考え抜かれた選択肢のほうがはるかに優れています。
これからサービス設計をして API アクセスを提供することになっている方はどうか、ご自分が実現しようとなさっているのが何なのかを本当に考えてください。他の人がやっていることをコピーするだけで済ませたり宣伝を丸呑みしたりしないでください。どうしてもコピーしなければいけないなら、Amazon (これが最善です) や Rackspace, IBM SoftLayer, Linode, VULTR, Zoho, Zoom ほか、API の素直で健全な認証システムを構築する方法について現時点で多少なりとも理解のあるところをコピーするようにしてください。
2016 年 4月 Insane Coder
プレビューまでは全文見えるんだけどな。すまんやで。しかもまだ続く anond:20160426150324
おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリのバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。Google が OAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントをウェブブラウザベースのアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフローを標準的なブラウザ用のエンドポイントにコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
前掲のセキュリティ文書は、アプリの認証情報 (client_id と client_secret) を盗んだ人ができる悪行にいくつか言及しています。以下に、この攻撃と組み合わせることで (これまで筆者の知る限り公表されていない) 危険行為を実行可能にする問題をいくつか取り上げます。さらに皆様の独創性にかかれば、「秘密」のはずのものを盗んだ人が悪用できる方法は他にも発見できるはずです。
トークンベースの認証は多くの開発者にとって新しい概念です。そのため誤解も多く、EVS のようなものを設計する開発者の中にも、ただ何かの設計ガイドライン (たとえば OAuth) に従って API の動作を決めれば、あるいは他のプラットフォームのしていることをコピーすれば、自分のプラットフォームも自動的にセキュアになるはずだと考える人が少なくありません。しかし何かをセキュアにするには、その要素ひとつひとつを余さずセキュアにする必要があり、それらの組み合わせすべてをセキュアにする必要があり、全体の枠組みもセキュアにする必要があります。思い出してください、全体のセキュリティ強度はその弱点の強度に等しいのですから、何らかの大まかなフレームワークを固守することだけに頼りきって、その通りに使う限り何をやってもセキュアだ、などと安心するわけにはいきません。OAuth ベースのフレームワークそれ自体は、その内部要素のセキュリティを確保することに関しては殆ど何もしてくれません (ある種の要素で、あからさまにセキュリティを害するものだけは別)。
トークンベースのシステムで少しでもセキュリティらしさを出すには、最低でもトークン生成に暗号学的にセキュアな擬似乱数生成器 (CSPRNG) を使う必要がありますが、この話題はあまりよく理解されていません。さらに悪いことに、一般的なスクリプト言語の適切な CSPRNG 用 API は非常に少なく、しかしそうしたスクリプト言語が、人気ある最新サービスの多くを設計する際の基礎となっていることが多いのです。
もし生成されるトークンが予測可能であれば、攻撃者はトークンを推測するだけで別のユーザになりきって悪意ある行為をすることができてしまいます。筆者は、fortune 500 クラスの大企業による OAuth ベースなサービスが一種の単調増加 ID (おそらくデータベースのフィールド？) をそのままトークンに使っているのを見たことがあります。他にも、生成されるトークンがすべて単調関数の出力のようなサービスもありました。よく調べてみると、それは現在時刻に基づく非常に単純なアルゴリズムでした。こうしたシステムでは、まず自分としてログインし、現在のトークン ID を見て、その後の ID を予測すれば、続く任意のユーザになりかわってトークン交換その他の操作にそれを使うことができるでしょう。他のテクニックと組み合わせれば、もっと標的を絞った攻撃も可能です。
このクラスの攻撃は前述のセキュリティ文書で「4.5.3. オンライン推測による新規トークン取得の脅威」や「4.6.3. アクセストークン推測の脅威」に分類されています。この問題には解決策があるとはいえ、現時点でこの間違いを犯しているサービスの膨大さと、この間違いの犯しやすさを考えると、任意の OAuth ベースなサービスが外部レビューでセキュリティを証明してもらえる可能性はあまり高くありません。
本欄の主眼ではありませんが、乱数に対する攻撃の中には、セキュリティを固めた CSPRNG を使っていないと OAuth ベースのサーバを完全に破壊してしまえるものもあります。こうした問題は他のシステムでも非常に困ったものではありますが、動作のすべてが乱数のやりとりの上に成り立っている普通の OAuth 実装では、より一層この問題が際立ちます。こうしたトークンは EVS のサーバ側で生成され、「普通の実装における」OAuth がよくやる使い方ではサーバの信頼性を奪い、関連するトークンすべての予測可能性を高めていきます。最新の攻撃手法を防げるセキュリティ強化 CSPRNG が用意できないのであれば、もっとハードルの低い別のプロトコルに乗り換えたほうが良いでしょう。
一方、一部の OAuth ベースの実装は乱数の必要性をクライアント側に移すような構造になっていることも注目しましょう。色んな意味で、これは問題を別の場所に移しただけではありますが、サーバ側のアタックサーフィスを減らすのは事実です。これによって、少なくとも情報強者な利用者は、信頼できるサービスをセキュアに使うことが可能になります。ただし情報弱者は脆弱なまま放置ですが。今回の例に当てはめてみると、この種のセットアップでは AFCP の開発者が頑張って EVS をセキュアに使えるようにすることと、EVS 自体が陥落する危険を回避することは可能ですが、ABC や XYZ が EVS をセキュアに利用するかどうかは別問題です。
本論に入る前に指摘しておきたいのですが、CSRF 攻撃はその名前に反して、外部サイトからスタートする必要はありません。CSRF 攻撃というのは、自サイトへのリンクをユーザが貼れる、掲示板やメッセージングソフトのようなサイト自体からでもスタート可能なのです。
色々な手法で CSRF に立ち向かうべく設計された数々のテクニックやフレームワークがあります。これらのシステムの多くは、OAuth ベースのものと統合すると使いものにならなくなったり、サイトを攻撃にさらしかねない行為を促すことがあります。
CSRF を防止するひとつの仕組みとして、ブラウザから送られる referer (原文ママ) が外部サイトを指していないことを確認するというものがあります。多くの OAuth 実装はユーザを特定の外部サイトから連れてくるよう要求しますから、この防御策は執行できません。OAuth サーバがリダイレクトする膨大なサードパーティのドメイン、また関係する URL やドメインの完全なリストは明文化されていないうえに折々で変更があるため、EVS のドメインとページ全体をホワイトリストにするのは不可能です。
また、EVS の提供者が寝返って AFCP を攻撃しようとする可能性がないかどうかも検討する必要があります。OAuth の背後にある原則のひとつは OAuth ベースのサービス側が利用者を信用しないことです、しかし同時に、利用者側には CSRF 回避策を見なかったことにしてサービス側を完全に信用することを要求しています。理想の認証システムというものがあるとすれば、一方通行ではなく相互レベルの不信を確立するでしょうに。
転送元と転送先のどちらかだけの、部分的なホワイトリストというのも難しいことがあります。使っている CSRF 対策フレームワークによりますが、機能のオンオフに中間がなく、特定のページや転送元だけを無効にすることができないかもしれないので、その場合 EVS 利用者は CSRF 対策フレームワークを一切使用できなくなります。
OAuth は CSRF 攻撃を防ぐ CSRF トークンを指定するようにと、オプショナルな state パラメータを定義しています。しかしながら、OAuth ベースのサービスは一般的に state の長さや文字種を制限し、要求どおりそのままで返さないことがあるようです。そこで、おかしな互換性問題が起こるため、多くの OAuth ベースサービス利用者はリダイレクトのエンドポイントにおける CSRF 防御をすべてオフにせざるをえない状況に追いこまれています。これは「10.14. コード・インジェクションと入力バリデーション」に分類されています。state パラメータの別の懸念は、EVS 側で state にアクセスのある人はだれでも、リクエストを改竄して、それ以外はまったく有効なままのパラメータを付けて AFCP にブラウザを送り返すことができるという点です。
OAuth ベース API の利用者は、自分のアプリやサービスを登録する際にひとつか複数の URI をカッチリ決めておくよう求められるという制限も課せられています。これは redirect_uri に使えるホワイトリスト URI です。この仕組みにひそむ重大なユーザビリティ問題は後述するのでひとまず措くとして、この制限のせいで開発者は、state パラメータや他の潜在的に危険の伴うアイディアで姑息な工夫をこらし、泥沼に沈んでいくはめになっています。多くの OAuth ベースなサーバは、ホワイトリスト URI をひとつしか許可していなかったり redirect_uri との完全一致のみ有効でパラメータの追加を認めなかったりしています。このせいで開発者たちは CSRF 対策フレームワークの利用をやめたり、あらゆる危険なものを state パラメータに詰めこもうとし始めたり、浅薄なシステムを自前で作り出したりしています。その結果、redirect_uri と state の組み合わせによってはユーザを不適切なページに誘導する危険性が出てきます。これは「10.15. オープン・リダイレクト」に分類されます。
こうしたリダイレクトの問題は、パラメータをしっかり認証していないせいで、それ自体が悪用可能なのですが、これを前述の「OAuth サービスへの偽装」問題と組み合わせるとユーザに大惨事をもたらしかねません。盗んだ client_id と client_secret を使えば、悪いやつらは AFCP とまったく同じ情報で認証できるので、本物の AFCP にも見ぬけないようなリダイレクトを作ることができます。また、悪意あるユーザも、本来自分の持っていない AFCP 内の権限を取得するような state パラメータの利用方法や改竄方法を見つけることができるかもしれません。その際には、おそらく盗んだ認証情報も使うことでしょう。概して、「普通の実装における」OAuth の低品質な設計のせいで、また特定の分野に関する教育レベルが低い外部開発者の直面する問題のせいで、OAuth ベースの利用者に対する攻撃はしばしば、本来あるべき状態よりもずっと容易になっています。
ここで読む意義のあるものとして、さらに「3.5. リダイレクト URI」「3.6. state パラメータ」「4.4.1.8. redirect-uri に対する CSRF 攻撃の脅威」があります。
セキュリティに関して言えば、「普通の実装における」OAuth の仕事ぶりはとてもひどいです。OAuth が目指していると思われるセキュリティ目標の多くは、達成されていません。さらに、OAuth ベースなサービスの中には、種々の攻撃に対して無防備でいることを利用者に公然と要求するものがあります。サービスをセキュアに使える場合も、そのことが知られているとは限らず (サービス側の、トークン生成手法といった重要なセキュリティ詳細が明文化されていないうえにクローズドソースなため)、OAuth は今なお多くの低品質なプログラミング習慣を招いています。OAuth は外部の開発者を守る点でほとんど何もしませんが、そうした開発者が使っている各種フレームワークの方はといえば、こちらも真のセキュリティを提供していなかったり、厳しい自制と注意がなければセキュアに使えなかったりする代物です。
この記事についていえば、個人的に蔓延していると思った問題の一部を取り上げたものに過ぎません。この中には、極度に低質な、一切 OAuth の規格で義務付けられていない慣習を、他所で OAuth に使っているのを見たまま開発者がコピーした結果というものもあります。
OAuth ベースのサービス開発者もその利用者側の開発者も、OAuth ベースのプラットフォームを実装したり利用したりするためには、ここでリンクした文書をすべて読んで理解する必要があります。挙げられている 50 クラスの攻撃も、各クラスの深刻度も完全に把握する必要がありますし、そのうえで「実装の仕様書やセキュリティ・ガイドラインには漏れがないとは限らない」ことにも留意すべきです。この記事は公式文書にない問題をいくつか取り上げているとはいえ、OAuth セキュリティ問題の表面をなでているに過ぎないことも覚えておくべきです。ここに混ざって、公式 OAuth 提案に加えられる変更点はどれもまったく新たなセキュリティ問題を引き起こすものですが、残念ながら変更はよくあることなのです。そこで各々が、乱数生成やセキュリティ調査技術といった OAuth 以外のセキュリティ関連分野も理解していなければ、OAuth でそれなりのレベルのセキュリティを実現することはできません。
真のセキュリティをお探しの方には、よそを探すようお勧めします。最後の章で OAuth の代わりになる選択肢をいくつか取り上げます。
(略: ふつうの実装では、サービス側がプラグを引き抜くようにして自由に利用者を出禁にできる。ビジネス的にもまずいし、悪意あるユーザが API 利用者を騙って出禁になるとアプリへの DoS になる。)
(略: サービス側からは API 利用者という大きすぎる単位でしか見えないので、たとえばビデオカメラのアプリ単位で利用帯域などを制限せざるを得ないが、そうするとそのビデオカメラは、一部ヘビーユーザのせいで他のユーザが締め出される事態になる。OAuth 以外のサービスならふつうユーザ単位。対策としてユーザに開発者アカウントを取得してもらうのも面倒すぎる。ていうか手動プロセスを挟んでたり。)
(略: ふつうの実装は SaaS モデルしか見ていないので、URI を持たない AFCP のような社内ソフトや、ビデオカメラのようなデスクトップアプリには使えない。アプリが cURL 的なもので API を叩こうとしても、JavaScript が必要だと言い張るサービスもある。グローバル企業が地域別にドメインを分けていたら URI が足りない。客ひとりひとりにサブドメインを与える製品だと URI が足りない。足りるとしても追加・更新がメタ API で簡単にできない。ひとつの URI ですべてのリクエストをこなすのはセキュリティ問題もあり、ロードバランス等の必要性も出るし、社内ソフトやデスクトップアプリに余計なウェブサイトへの依存性を加えることになる。httpサーバをlocalhostで立てるとかアホか。)
(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認
扱う情報って文言、写真、動画、通話、アプリ連動くらいでしょ？
表示のさせ方が違うだけでやってること同じじゃん
いやプラットフォームの違いがユーザーの好みとすり合ってるかどうかで違うっていうのは分かるよ？
でも多少の好みにさえ目をつぶれば全部同じツールで代用すること可能じゃないの？
なんでさして扱う情報に大差がないのに特色ありますみたいなキャンペーンをこぞってするわけ？
ツイッターで貼った画像をフェイスブックにも貼ったり、ツイプリを画像掲示板に貼ったり
無駄でしょこれ
こんなん一つにまとめることは技術的に可能でしょ
なんで囲い込もう、囲い込もうとするわけ？壁を作ろうとするの？その構想になんの意味があるの？
答えは金だろ、やっすい野望だなオイ
結局やってることは現実世界がネットにフィールド移して既得権益の争い続けてるだけじゃん
何もやってること変わらないのにカッコつけんなよ
ダサすぎるわ
誰が偉人だのなんだのもてはやされてても
これらのサービスを統括できるだけのプラットフォーム用意できないというだけで無能だろ
何度も言うけど万能包丁1つ作り出せないのにカッコつけんなよ
そんなことでビジネスにつなげようとするなよ
ユーザー2の次じゃねーか
色々選んで状況に合わせて使い分けないといけないこの手間、この手間の方が無駄で仕方ない
というわけで増田で全部完結できるようにして
OAuth ディスの記事を酒の勢いで訳してみたゾ。前半はつまらないから、「章のまとめ」か、それ以降だけ読むといいゾ。なぜか後半が切れてた。こっちだけでいいゾ anond:20160426145507 anond:20160426150324
http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html
認証 (authentication: 本人確認) と承認 (authorization: 権限付与) のシステムを設計し、API を規定し、複数の異なるシステムを統合するために用いられる提案をまとめたものです。
OAuth には色々な種類があり、version 1.1a や 2、その各部の上に他の規格を乗せたものなどが存在します。世の中に出回っている数々の実装によって、具体的な利用状況は大きく異なります。
前にも OAuth について書いたことがあり、たくさんの反響をいただきました。前回の記事に対する批判の一部を避けるため、今回の記事について先に断っておきたいのですが、この記事は OAuth の使われる典型的な場面に焦点を当てており、論じられる点のほとんどは、何らかの方法で OAuth を利用する大手サービスのほとんどすべてに当てはまるということです。
言いかえると、OAuth を用いているあらゆるプラットフォームが壊れているとは限りません。OAuth にはバリエーションが多いうえに、2.0 だけに限っても 76 ページに渡るパターンがありますので、OAuth に基づいた何かに適合していながらもセキュアであり、使っても問題ないものは存在しうると言えます。ですから、あなたのお気に入りの OAuth 実装や設計が、ここで論じられる問題の一部または全部を免れていることもありえます。確率は低いですが。
また、OAuth を使っているものの中には規格を誤用しているものがあるとか、OAuth はその使い方を強制しているわけではないとか言う人もいるかもしれません。どちらにせよ、ここでは特定の OAuth ベースの規格について述べるのではなく、現状で大手が OAuth をどう利用しているかについてを、それが規格に適っているかどうかに関わりなく論じるつもりです。こうすることで、多くの読者に影響を与えることになるでしょう。危険な方法で OAuth を使っているサービスの利用者であっても、また自ら OAuth ベースのサービスを管理していて、他のみんなが作っているのを真似てプラットフォームを作ろうと思っている人だとしても関係があるのです。
この記事は長くなりますし、言ってみればほとんどの章はそれ自体でひとつの記事として十分なほどの話題を扱いますので、大まかな流れをご説明しておきましょう。
この記事は、現在 OAuth 業界でおこなわれていることを調査した結果のまとめです。OAuth を使う製品のすべてにこの記事のあらゆる点が当てはまるというのではなく、危険だったり無価値だったりするサービスの背後に見つかった慣例や根本原因を紹介する記事です。
この前書きのあとは、まず OAuth のセキュリティ欠陥を分析することから始めるつもりです。こうした欠陥の中には、セキュリティのコミュニティでよく知られていて、書籍などですでに分析されている一般原則が当てはまるものもあります。しかしこの記事では書籍化されていないケースも扱いますし、有名な欠陥についても、平均的な開発者および責任者に理解しやすく、対策の必要性がはっきりするように工夫するつもりです。
その後は、OAuth の主要素が一般的に言ってどのように実装されており、そうした普通の実装がどのようにサービスを使いものにならなくするのか、すなわちそのサービスで達成できることを極度に、不適切に、かつ意図に反して低下させてしまうのかを分析します。ごく一部のケースでは回避策の足がかりになるかもしれないテクニックについて論じますが、そういうのを実装する馬鹿らしさにも注目します。こうした記述の中では繰り返し何度も、OAuth を使う人たちがどれほど自分と自分のビジネスにとって損なことをしているのかが説明されます。
最後に、OAuth が適切に使われうる数少ない場面と、すでに利用されている OAuth の代替品を簡単に取り上げます。代替技術に関する調査の結果を提供するつもりですが、その中には Amazon のような大企業がセキュアで使いやすく信頼性の高い API を実現するために何をしているかの報告も含まれるでしょう。
いま普通に使われているかたちにおける OAuth の欠陥の幾つかを悪用すれば、大手サービスに対して強力な攻撃を仕掛けることができます。OAuth に対する攻撃は何も新しいものではありません。IBM や Oracle を含め、懸念した IETF メンバーが OAuth ベースのサービスに対する攻撃を 50 クラスも記述した 71 ページもの文書を 3 年以上前に出したように、また筆者も前回の記事でこうした点のいくつかを議論したようにです。それにも関わらず、OAuth ベースのシステムの主要なセキュリティ欠陥は非常に蔓延しています。
筆者は、いくつかの大手企業の役員や開発者に、そこの OAuth ベースシステムが抱えるセキュリティ欠陥を指摘したことがあります (そのうちのひとつは 4 年前のことです) が、全員、自社システムを修正するために一切何もしませんでした。まるで、OAuth の人気度からして、他の現実的な解決策をひとつも聞いたことがなく、それゆえに OAuth が最もセキュアな選択肢に違いないと決めてかかっているようです。どうも、OAuth のコア原則に対する攻撃のデモを文書化した情報も、聞いたことがないか、肩をすくめて無視するかしているようです。そこで、この情報をもっと広く拡散することによって、影響のある人たちの尻を蹴りとばしてあげたい、そしてサービスを設計あるいは管理している人たちにモーニングコールの役割を果たしてあげたいと願っています。
というわけで、OAuth ベースの何かを提供あるいは利用するご自分のサービスを調べて、こうした欠陥の一部あるいは全部が存在することに気づいたなら、どうぞ責任をもってこの情報を取り扱ってください。ご自分のサービスを適切にアップデートしたり、関係する問題に対応するようビジネスパートナーに適切な圧力をかけたりしてください。
ここで言及されている情報やリンクされている情報は今のところ既存のサービスに悪用できるかもしれませんが、どうぞ責任ある行動をとり、他人のものを破壊するのではなく改善することを目指してください。この記事は、自社サービスを不適切に実装している人たちへのモーニングコールのつもりで、その改善を促すために書いているのであり、悪用したがっているハッカーたちのハウツーもののつもりではないのです。
この記事では、ふたつのシナリオに注目して、その場面でどのように OAuth が組み合わされているのか、そしてなぜうまくいかないのかを検討します。記事を通して何度もこれらのシナリオに戻ってきますので、頭に入れておくことは大事です。
まず、Exciting Video Service (略して EVS) というサービスを思い描いてみましょう。ユーザが動画をアップロードしたり友人と共有したりできて、完全公開にしたりアクセス制限を設定したりできるようになっています。また EVS は動画のアップロードや削除、およびだれが視聴できるかの権限管理に OAuth ベースの API を提供しています。
ただ、例としてこの想像上のサービスに焦点をあてますが、論じられる問題はあらゆるサービスにも当てはまります。ファイルであろうと文書ストレージであろうと、カレンダー管理やオンライン会議、ディスカッション・グループ、はたまたリソース管理であろうと OAuth ベース API を提供する他のいかなるものであろうとです。また、筆者は本当にどの特定の動画サービスのことも言っていないということを覚えておいてください。問題点の一部あるいは全部は、OAuth を使っている既存の動画サービスに当てはまるかもしれませんが、EVS がそのサービスのことを指すわけではありません。どれが当てはまるかは読者への練習問題ということにしてもいいですね。
ひとつめのシナリオとして、ビデオカメラの製造会社を想定しましょう。そのビデオカメラには、録画した内容を EVS にアップロードする機能のあるソフトウェアを付属させたいと思っています。つまり、ユーザがビデオカメラを自分のコンピュータに接続して、その独自ソフトウェアを開き、ビデオカメラからアップロードしたい動画を選んでしばらくすると、それが EVS にアップロードされているというものです。
ふたつめのシナリオとしては、ある中小企業が職員用に EVS で 50 アカウントを購入し、全職員が動画をアップロードして同じ部門の職員と共有できるようにする、ということにしましょう。この会社は A Friendly Custom Platform (AFCP) というソフトウェアで職員と所属部門の管理をしており、この AFCP サービスを EVS に統合したいと考えています。望んでいるのは、管理者が AFCP を使ってだれかを営業部門に配置したら、その職員が自動的に営業部門のメンバー所有の動画すべてに対するアクセス権を取得するということです。営業部門からいなくなった人には逆のことが起こるようにもしてほしいと思うはずです。
トークンベースの認証システム (OAuth のコア) が現在よく利用されている最大の理由のひとつには、「適切に実装されれば」サードパーティのアプリやサービスに各ユーザの認証情報 (パスワード等) を提供しなくて済むという点があります。サードパーティに個人ユーザの認証情報を渡すのは、以下の理由から望ましくありません:
上記の問題点は、OAuth だけでなくあらゆるトークンベースの認証システムでも回避できます。よく OAuth の強みとして挙げられていますが、独自というわけでは全然なくて、他にも同じ強みを実現しつつ OAuth の弱点のない選択肢はあるのです。
さて、確固とした土台に基づいてはいるものの、「普通の実装における」OAuth は、上記の問題を回避しようとして以下のような手順に沿ってシステムに情報を提供します:
このトークンはユーザの認証情報ではありませんから、そしてひとりのユーザとひとつのアプリの組み合わせだけに有効で、指定された権限しか持たず、あとから破棄されるようになっていますから、きちんと前述の問題点を回避しているように思えます。しかし実際には、ちゃんとした土台を核として持っているにも関わらず、OAuth の普通の実装で使われているこのフローは、上に挙げた問題すべてに対処しているとは言えません。
この設計はそもそも危険なスタート地点から始まっています。セキュアなプラットフォーム設計の第一原則は、危険な地点から始まったものは既にダメ、逆転不可能、ということです。手順 1 のせいで、EVS 自体ではなく EVS を利用するサービスから始まっているので、ユーザは最初の一歩からして中間者攻撃を受けたような状態にあります。これは、かかってきた電話に個人情報や口座番号などを教えるようなもので、自分の使っているサービスの者だと名乗っていますが、番号が本物かどうか分からなかったり非通知だったり、という場面のコンピュータ版だと言えます。最近はこういう詐欺がたくさんありますから具体例を挙げる必要はありませんね。要点は、接続を開始する相手が信用できなければ、その接続は一切信用できないということです。EVS 自体の側から手順を始めるのでない限り、上に挙げた目標をすべて実現する API 利用のためのセキュアな認証システムは設計不可能です。
(略: 手順 2 で、それっぽいページに誘導すれば認証情報を盗める)
(略: そうした詐欺を企業自体が後押ししているような風潮もある)
(略: スタンドアロンのアプリなら、ログインを詐称する必要すらない)
この種の攻撃は前述のセキュリティ文書で「4.1.4. 脆弱性を突かれたブラウザや組み込みブラウザを使ったエンドユーザ認証情報のフィッシング脅威」として分類されています。提案されている解決策は？
クライアントアプリがユーザに直接認証情報を求めることは避けるべきだ。加えて、エンドユーザはフィッシングや良い習慣について教育を受けることもできる。良い習慣は、たとえば信用できるクライアントにしかアクセスしないことだ。OAuth は悪意あるアプリに対していかなる防御策も提供していないので、エンドユーザはインストールするネイティブアプリすべての信頼性に自分で責任を負う。
さらに
クライアント開発者は、ユーザから直接に認証情報を集めるようなクライアントアプリを書くべきではなく、システムブラウザのような信用できるシステムコンポーネントにこの役目を移譲すべきだ。
基本的に言って、OAuth のセキュリティガイドラインは、OAuth を利用する開発者がユーザを攻撃しようとすべきではないとか、悪いことをしてはならないと言っています。外部の開発者が悪いことをしないことに頼るというのは、正気のサービス設計者が依拠するセキュリティモデルではありません。
私の知る主要な OAuth ベースのサービスはほぼすべて、ここに概説した手法で攻撃可能です。
OAuth こそセキュリティの新たな金字塔だとお考えの皆さん、目を覚ましてください！ 「普通の実装における」OAuth は、始まる前から負けていますよ。OAuth が存在するよりずっと前に実装された数多くのシステムはセキュアで、この問題を効率的に回避しています。残念なことに、あまりに多くのサービスが、せっかくセキュアだったのにインセキュアな OAuth モデルに移行してきました。だれかが開発者や管理者に「OAuth はもっとセキュア」「先取り思考」「将来への投資」とか何とか素敵な (しかし具体性の皆無な) バズワードを並べたてたからでしょう。ほとんどの場合、こうした変更は本当に既存の問題に対応しているのか、あるいは以前のシステムより幾らかでも良くしてくれるのかどうかをレビューすることさえなく実装されています。
OAuth ベースのサービス設計でよく見かける間違いは、ブラウザ用に、パラメータのひとつとして client_secret (あるいは同様のもの) を受け取るエンドポイントを提供することです。OAuth の client_id と client_secret パラメータは、基本的に言ってサードパーティのプラットフォーム固有の API ユーザ名とパスワードと等価ですから、EVS の API を利用する開発者だけにしか知られるべきではありません。パスワード同然のものなのですから、client_secret パラメータは「絶対に」ユーザのブラウザを通して送信すべきではありません (ヒント: パラメータ名の中に secret という言葉が入っているよ)。アプリやサービスのユーザがその client_id と client_secret を見つけることができる場合、そのユーザはそのサービスのふりをすることができ、潜在的には何かイケナイことができてしまうということになります。さらに注意すべき点として、client_secret パラメータを別の名前にするサービスもありますから、ご自分の関係するサービスをよくチェックして、他のパラメータも秘密にする必要があるのかどうかを調べてください。残念ながら、重要な変数が自分の素性をいつも表に出しているとは限らないため、この問題は意外と多く存在しています。加えて、client_id だけ使う認証フローを OAuth の上に乗せるサービスも出てくるでしょう。これには用心してください。特定の状況では、そういう client_id はまさしく client_secret 同然の働きをするのですから。
「普通の実装における」OAuth は、ウェブブラウザを使ってユーザを複数のウェブサイトに移動させるわけで、ひとつのサイトから別のサイトに client_id と client_secret (あるいは同様のもの) を送ってもらう必要があります。そうやって、たとえば AFCP と EVS の間でこれらをやりとりするわけですから、ユーザがブラウザの HTTP ログをモニタリングすれば、本当に見えてしまいます。これはアプリに組み込まれた独自ブラウザ各種でも、単に右クリックすれば何らかのネットワーク・ログ機能を持つ何らかの inspector にアクセスできてしまう場合などには可能です。
EVS と連携した AFCP にこの欠陥があると、AFCP に少しでもアクセス権限のある職員に本来の権限より多い権限を取得させてしまい、本来アクセスできないはずのところに許可が下りてしまう危険があります。別の例では、仮に Facebook が GMail 用の OAuth エンドポイントを利用しているとして、client_id と client_secret の両方がブラウザを通して送信される場合、Facebook のユーザは全員 GMail に対して Facebook そのもののふりをすることができてしまうということです。
この問題は、OAuth エンドポイントがユーザのウェブブラウザから平文で client_secret を送ってくることを期待するときにはいつも存在します。あるいはそうする必要があると誤解した API 利用者が、埋め込むべきでないところに secret を埋め込むときもです。この脆弱性が存在している可能性が高いのは、エンドポイントが client_secret (または同等品) と redirect_uri の両方を期待する (あるいはオプションとしてでも受け付ける) 場合です。redirect_uri パラメータは、今回のケースで言うと EVS がユーザをログインさせたあとでそのブラウザをどこに送るべきか指示するために使うよう設計されています。そうやって redirect_uri がエンドポイントへの転送に使われている場合、その処理はユーザのブラウザで実行されることが期待されているわけです。主要な OAuth 文書はどちらも、client_secret と redirect_uri の両方をこうした用途に使うようなケースを指示したり求めたりはしていません。
ざっと検索してみたところ、残念なことに、潜在的に違反の可能性があるそういった OAuth ベース API がたくさん見つかります。Google は OAuth の色々な利用方法を提案していますが、その中に、両方を一緒に使うことを広めるフローがひとつあります:
client_secret: 開発者コンソールで取得したクライアントパスワード (Android, iOS, Chrome アプリとして登録した場合のオプション)
Citrix もこんな間違いをしています:
(略: 以下、実際に脆弱だと確認したわけではないが、secret と redirect を併記しているサイトが列挙されている。)
Google で 2 分検索しただけでこのリストができました。皆様がもうちょっと労力をかければ、ずっと多く見つかることでしょう。ただし、上記リストは、こうしたサービスのどれかが脆弱だとか、誤用しやすすぎるということを直接に示すものではありません。色々な要素があり、たとえば Zendesk は特にこのケースでは redirect_uri パラメータをリダイレクトに使わないと明言していますし、アプリからエンドポイントを呼ぶときはフル機能版ブラウザではなく curl を使うべきだとさえ書いて、開発者が危険なことをするような誤解を極力避けようとしています。それでも、経験の浅い開発者はこうしたエンドポイントを独自ブラウザで読もうとするかもしれません。さらに、この組み合わせが世に出回っているというだけで開発者の警戒心が下がっていき、経験を積んだ OAuth ベースのサービス開発者でさえも似たような状況で潜在的にヤバイ誤用を気にせず適用するようになってきています。特に client_secret が別の名前になって、「秘密を守る」という概念が失われている場合はそうです。
サービスがこの点に関して壊れている指標となるのは、人気のある複数の OAuth ライブラリがこのサービスでうまく動かないときです。そういうサービスは一般的にいって独自の「SDK」を提供しており、サードパーティの開発者が選んだライブラリではこのフランケンシュタイン的な OAuth が使えないと苦情が来たときにはその SDK を使うよう指示します。こうしたカスタマイズは気付かれないまま進行することも多くあります。開発者の大多数は、SDK が提供されているなら、わざわざ手元のソフトで頑張らずに済ませたいと思うものですから。
この種の攻撃は前述のセキュリティ文書で「4.1.1. クライアントの機密情報を取得する脅威」に分類されています。しかしサーバがウェブブラウザを使用を要求し client_id と client_secret (または似た用途のもの) を同時に渡させるという具体的な攻撃パターンには一言も言及がありません。おそらく、その文書の執筆陣の予想では、こんな馬鹿げたサービスはだれも設計しないだろうし、その API を使う開発者もそれを独自のウェブブラウザや SDK で使ったりはしないだろうと思っていたのでしょう。こうした開発者は OAuth の規格からバラバラに取り出した要素をグチャグチャに混ぜて接着しておいて、自分のプラットフォームが OAuth 本来のセキュリティを保持していると思っています。そのツギハギのせいでどんな新しい問題が入り込むかもしれないのに、そこは一顧だにしません。残念ながら、これが近年の OAuth 業界によくあるやり方で、この既に猛威をふるっている問題は、パレードの参加者がどんどん増えて、人が使っている手法や、使っている「と思う」手法をコピーしていくことで、とどまるところを知らない連鎖になっています。
おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリのバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。Google が OAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントをウェブブラウザベースのアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフローを標準的なブラウザ用のエンドポイントにコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
http://anond.hatelabo.jp/20160422184218
↑これの続き。
-----------------------------------------
こういうことを書き捨てていくと老害がいなくなっただけだって思われるかもしれないんですけど、このセグメント問題ってのはサービス運営の側に立って考えるととても難しいものじゃないかって考えているんですよ。
これについてはきっと中の人も葛藤があるだろうなーってのは思います。なんだかんだ生え抜きの技術者がいるだろうし、自分の知っているユーザー層とは違うサービスになりつつあるという思いがある人はいるんじゃないかな、と想像します。でも、ビジネスとして、商売として考えるならば、敷居を下げて、大衆的な（むしろ衆愚的な）話題のコミュニティであっても、ライトユーザーに拡大できて、キチンと定額課金と広告料を取っていかなければならない。短期的に見れば、これはむしろ最重要課題です。
散々書きましたが、個人の思いを割りきって仕事人間の立場として考えるならば、はてなブログPROの月1,000円（2年契約でも600円）っていうモデルはよく踏み切ったなーって思ってるんです。ネット系ベンチャーのご多分に漏れず、マネタイズで苦労してたはずですからね。
自分でいじれる人にとっては、システムの機能だけ見ればこの有料サービスはほぼ魅力がないです。安いホスティングのレン鯖やクラウドにWordpressを入れたほうが安いし、写真なんてGoogle PhotoだってFlickrだって使えるのに。実際のところは、「好きなアフィリエイトが設定できる」「あれやこれやを堂々とやれる『市民権』を得られる」というメリットが大きいですよね。はてなのユーザコミュニティを活用できて、ブクマとスターが近くて、初心者でも扱える。つまり、あの界隈って、ネットサービスのビジネスモデルとしては私のような厄介なユーザーよりずっと適切なターゲットユーザーなんですよね。
でもね。でも。あくまでも「短期的」は「短期的」でしかないんですよ。
運営している人も絶対わかってると思うんですけど、サービスにはコアが必要なんですよ。ストーリーがあって、そこから生まれたコアユーザーがいて、インフルエンサーになって規模を大きくしていく。特に、はてなみたいなコミュニティは、ユーザーによって育てられてきたサービスでしょう。
古い考えかもしれませんが、ブランドっていうのは一朝一夕ではないんですよ。「ブランドは作れる」なんていう広告代理店の言葉もありますけど、勘違いしちゃいけないのは、その作るってのは買ってすぐできるっていうことではないっていうことですよね。理念があって、コアユーザーがいて、クチコミで広がっていくものでしょ？だから、仮にイメージの転換が急務だったとしても、ユーザー層がガラッと入れ替わっちゃうと、後が続かないんじゃないかなって思うんです。
私自身も仕事で広告出稿したりすることもあります。ECをやってるんで、検索流入や、導線や、コンバージョンも気になります。
だから、アフィリエイトを貼ってくれるようなブロガーさんとはお仕事的にはパートナーだったり、お客さんだったりとありがたい存在でもあります。誤解のないようにはっきりさせておきますと、私はアフィリエイト広告自体は（PV稼ぎのモラル問題とかは別として）全然否定していないです。PVが増えて嬉しい気持ちだってわかりますよ。自分だって嬉しいから。
でも、ネットコミュニティを扱ってきた人間の端くれとしてつくづく実感しているのは、人は思いのこもった言葉で動く、コピペじゃ人は動かない、ってことだったりもします。
本当に好きなものを好きだからとブログを書きたい人は、ポイントがつこうがつくまいが、アフィが貼れようが貼れまいが、とても面白い記事を書いてたくさんの人を連れてきます。上手い下手はありますが、全てではないです。逆に……って、書かなくてもこれは言わずもがな。
アフィで炎上芸をやって、PVガー流入ガーって言う人を見るとちょっと寂しくなります。それが社会の現実だからしゃーない、っていうのもわかるんですけど、世の中には本気で知ってもらいたいと思う情報を見てもらうためにタイトルを一文字変えるとかバナーをA/Bテストするとか、本気でサイトを便利にしたいと思ってボタンを1ピクセルずらすとか何ミリ秒レスポンスを早く返すとかやってる人がたくさんいるわけじゃないですか。どうせなら、そこに乗っかるコンテンツも良いものであって欲しいじゃないですか。
そんな業者やオタクの言うこと知るか、って言ってきた人もいるんだけど、でも、本気で自分が作ったサービスや、あるいは自分が書いた記事で便利に使ってもらいたい、喜んでもらいたいと思っている人間としても、あるいはユーザーとして本当に面白いコンテンツにめぐりあいたい、って思っている人間としても、皆にとってそれぞれ満足できる「界隈」があるといいな、って思うのです。データマイニングを駆使した個人別最適化によってコンテンツが出しわけられているのでも良いのですが、はてなのような個性のあるWebサービスは、できればユーザーが体験を共有できる「オープンなはてな村」であってほしいものです。
最近はじめてブログを書こうと思った学生だって、ITにそれほど強くなくて、お友達とブログを書きたい、ついでにお小遣いももらえたらラッキー、っていう純粋な気持ちでやっている主婦だって、古参から「最近の奴らは……」なんて言われて恐縮する必要なんてないと思うし、共存できると思うんですよ。
ただ、アフィリエイトだけが目的で確信的にやってる層は同じ「素敵ですね！ありがとうございます！」でも、なんとなくわかっちゃうんですよね。そういう記事ばかりが眼に入るようになると、正直ちょっとうんざりします。
また脱線しましたけど何を言いたいかっていうと、要するに、「長期的に見た場合」としては、コアユーザーとサービスの特色がキチンと育っていて、他のユーザーの共益を阻害しない、っていう状態じゃなきゃいけないんじゃないか、っていうことですね。
この特色付けにしても、はてなブログはもうちょっとうまくやれたんじゃないかなあ、って余計なお世話なことを思ったりするところはあります。もっとも、まったく小洒落ていて気が利いた広告戦略やマーケティングとかできるようなキラキラな会社じゃなくて、それとは真逆の非モテ野郎どもだった（勝手な想像）、っていうところがはてなの好きなイメージだったわけではあるのですが。
※ほら、何年か前に、2chで「Webサービスを擬人化したったwww」っていうネタ流行ったじゃないですか。hagexさんがまとめてたと思いますが。あれのね、はてなの擬人化イラスト、皮肉じゃなくてわりと悪くないんじゃね？って思ってたわけです。ミサワがドヤ顔してるやつ。少なくとも、mixiモバゲーがウェーイしてるのとかよりかずっといいですよ。
同じ大衆化の道を辿るにしても変なミニマリスト界隈とか、アフィ軍団とかに捕まるくらいなら、もっと有益なカルチャーを形成できる仕掛けってなんとかならなかったものかなあって。いや、外野が1秒で思いつくこんなことはいくらでも考えつく人がいるだろうし、プラットフォームとコンテンツの話は別だろとも思うし、既にブログMediaで提供されているみんなのごはんとか気に入って見てるんですけど、ジャンルはともかくとして、そういう書き手を集める営業はやっぱキラキラ系のところのほうが上手いんですかねぇ。
お前誰だよ、なんでそんな熱く語ってんだよ、と誰しもに思われると思うんですが、実際のところ私は自分用にブクマを使っていただけのユーザーですし、ブログサイトを作っていじる側が中心だった人間なもんで、自分自身が上げたコンテンツはそれほど無いです。すみません。
最近ちょっとだけはてなブログを個人用日記に使っていたんですけど、今改めてMTでもWPでもないブログポータルを使ってみたらどんな感じでどんなことを思うんだろう、ってことに興味を持ったためです。この文章は、その結果として書いています。
はてなブログ自体は便利で書きやすくてとっても気に入ってます。βテストの時はカテゴリすらなく本当にシンプルで大丈夫か？って思いましたが、特にGoogleフォトやTwitterなどの外部サービスからの貼り付けが気に入っています。確実にダイアリーより使いやすいです。今後もますますの発展をお祈り申し上げますです。
なんだかんだ書きましたけど、要するにですね、私は単なる無名ユーザーですけど、こういう熱心なファンもいるんですよってことなんです。今までたくさんの発見と感動をもらったことに本気で感謝してます。興味深い！参考になる！感謝！とかそういうのではなくて。
距離を置く、と書きましたが、自分の情報クリップの習慣として、はてブ⇒Evernote連携の流れが便利で染み付きまくっているので、引き続き淡々とブクマは利用させていただきたいと思います。今まったくお金を落としていないことに罪悪感すら感じていますので、お礼の気持ちを込めてちょっとスターでも買って、ホソボソやっていきたいなと思います。
古参物書きも、ギークも、ステキ主婦も、手斧軍団も、お小遣い稼ぎの人も、みんながワイワイ楽しくヒャッハーできるやさしい世界ができるといいですね。
草々んじゃーね。
まずは、大変遅ればせながらはてな上場おめでとうございます。2ヶ月遅れですが。
先にお断りしますと、この文章は長いです。12,000文字近くあります。そう言えば最近「長すぎて読めない」ってタグ見なくなりましたね。
元々は数日前に自分のブログに投稿したのですが、アイコンを見てもIDを見ても誰にも認識されていないであろう私がこんなことを書いているのも気持ち悪いような気がして、衝動的に消してしまいました。そんな文章ですが、せっかく書いたので思い返して増田に投下します。それでも交流のある僅かな方からは、「あ、あいつだ」とすぐバレると思いますが、全く構いません。
大げさな振りをしてしまいましたが、この、はてなの世界からゆるやかに距離を置こうと思いまして。
ハイコンテクストな話題で、関係者でも有名ユーザーでもない私が語るには随分と分不相応であろうことは承知しているのですが、私は人知れず長年このはてなという会社とそのサービスの利用者でした。たぶん、相当熱心なファンのほうだと思います。
しかしこのはてなという界隈、おそらく長年世間一般的には「俺ははてなが大好きなんだー！！」とはなかなか言い出しづらい雰囲気と言いますか、一部一種のギーク（ナードか？）臭さみたいなものから逃れられないセグメント感があったために、公の場であまりそれを声を大にして語る機会が無かったという状況があったような気はしています。
勝手な想像ですが、よく言われるとおり先日上場した株式会社はてなとしてはきっと、そういった閉鎖的なカルチャーからの脱却を図る必要があるのは事実なのであろうと考えています。
私は「はてな界隈」という自然発生的な、「インターネット好き」が作ったプラットフォームとコンシューマージェネレイテッドなコンテンツが組み合わさってできた若干マニアックな文化がとても好きで、かつてインターネットに期待していたワクワク感のようなものを自分の感性ともっとも近い形で目指している会社だなと思っていたので、はてなを好んで使っていた理由も、今これを書いている理由も、サービスが向かう方向性とのギャップが発生したということで仕方ないのかな、と考えてはいます。
回りくどい書き方ですが、つまり、ここ最近（数年）の急激な利用者層の変化、人気ブログやホッテントリに上がってくる記事とその使われ方の変化、新たな利用者層との精神的摩擦に疲れて消耗するのが嫌になった、ということです。
私は自分の楽しみのために自分が面白いこと書き、読むっていうスタンスで自分のスペースを使ってきたので特定のユーザー群を非難するのはその趣旨とズレるし、メタな「ブログ論」を書くつもりは無いんです。なのでわかりやすいバズワードは書きませんけど、要は、そういうことです。お察し。
ここまで書いておいてから自己ツッコミを入れますが、私がここでこんなことを書いていても、おそらくそれほどの価値は無いのでしょう。
私は長年使っているとは言いながらも、所謂「はてな村」と言われるような有名ユーザー層に所属するようなアカウントではないし、特別人に見られるコンテンツを上げていたわけでもコミュニケーションを取っていたわけでもないし、こんなことをグダグダ書いていても「知らない人。気持ち悪い。」で片付けられてしまうような気はします。
コンテンツもお金も落としてもいないアカウントですので、ある意味運営側の立場から見れば、「うるさいことだけごちゃごちゃ言って全くサービスに貢献しない面倒くさいアカウント」あるいは「フリーライダー」と言われても仕方がない気がします。
これは別に被害妄想を語っているわけではなくて、自分がサービスを利用して得たメリットと、お客さんとしての価値を第三者的に見た時、そういう風に判断されてしまっても仕方ないかな、と冷静に思っただけです。
最近、はてなブログやブクマを見ていて、「これは自分には合わないな」と思ってケチを付けたくなる機会が多くなってきたことと、でも、ケチを付ける発言力（あるいは権利）のバランスを天秤に掛けて、ああ、もう自分が楽しく見ていられる場所ではないのかな、と感じることが増えてきたことと、単なる1ユーザなのにそんなことを考えてしまうこと、考えさせられてしまうことが嫌になってきてしまったということがあって、こりゃ、私の居場所はもう無いのかもしれないな、と思いつつあるということです。
かつての掲示板サービス群から始まってブログランキングやら、SNSやら、インターネットのサービスではいろんなところでこのような文化の変遷みたいな場面は見てきたはずなのだけれども、思ったより自分の生活の大きな部分にはてブが入り込んで浸透していたことに自分でもかなり驚いていますね。
前提としてなぜ、こんなマイナーキャラの私がそこまで一、ネットサービスに入れ込んでいたのかについてちょっと語らせてください。長くてすみません。
私のはてな歴は12年くらいです。長かったらどうだというわけでは無いのですが、はてなを知ったのはまだ人力検索しか無かったころで、自分が実際にユーザーになったのは例の「日本人にはブログより日記」のちょっと後、「はてなダイアリーをはてなブログに名称変更」とかエイプリルフールネタでやっていたころです。最古参ではなくて、ブログブームの頃に「はてな界隈」を意識するようになったので第2世代くらい、ということになるのでしょうか。
その後アカウントが一回変わっていて今のIDは5、6年くらい前に取りなおしたものなので、おそらく古参ぽさは無いですね。
はてなには他社のサービスと比べてとりわけIT系ユーザーの比率が高いと思いますが、私もそうです。一貫してネット関連ですが完全な同業というわけではなく、何度か変遷を経て今は流通系事業会社のインターネット事業担当になったというキャリアです。
はてなのサービスを認識した時はちょうどMovableTypeの2.6あたりが日本でも流行りだした頃で、「Web日記がhtml無しでこんなに簡単にできるなんて！」「コメントとかトラバとかすげー！コミュニティ作れまくり！」とかっていう話題で日々興奮していたのを覚えています。90年代後半からネットは見ていたけれど、これからいよいよ「普通の人」にもオープンに普及していくんだなー、と夢描きながら仕事で、あるいはプライベートでどう活用しようか考えていたんですよ。「Web2.0」より2年前くらいのことですね。
その頃、ちょうどあるECサイトのコミュニティサービスの担当をしていたんですね。いろいろやりましたよ。掲示板サービスが炎上して閉鎖に追い込まれたり、画像著作権で揉めたり、ブログが使えるようになってからは、「ブログに商品の宣伝を書いてリンクを貼ってくれたら100ポイント！！」とかいう現代であればGoogle警察が1日でぶっ飛ばしにくるようなプロモキャンペーンもせっせこ考えては公開してました。更にその後はOpenPNEベースのmixiっぽいSNSをやったりとか。
今考えるとうわーっていう企画も多かったのですが、おおらかながら大真面目にやってたんですよ。まじめに、ライトユーザーに使ってもらうにはどうしたらいいかとか、コアユーザーがどう伝搬してくれるかとか考えてました。その頃は（ネット上のマーケティングにおいては）セグメントの乖離とかそういう問題も今ほどは研究されていなかったし、たぶん自分でもまだ十分理解できてなかったんですよね。私はそんな感じの人間です。
自分語り方面に脱線したので話を戻しますが、ブログブームちょい前の頃、世の中で出始めたブログのアカウントを片っ端から取っては試すということをやっていたんですよ。ココログ、はてダから始まって、livedoor、goo、Excite、Seesaa、Jugem、FC2、楽天、MSN、ドリコム、ウェブリブログ、ドブログ、Yahoo、ヤプログ、アメなんたら……
でですね、そのときにはてなの特異性に気付いたわけです。
なんだこりゃ、殺風景なサイトだなぁ、なんか研究室みたいだなぁ、システム屋くさいなぁ、ってのが当時の正直な印象です。まったく間違ってないと思いますが。
ダイアリー以外の他のブログサービスはだいたい大手キャリア系か、大手ポータル系か、大手ホスティング系のいずれかじゃないですか。実際仕事で関わることがあったのはそういった会社さん達だったわけだったんですけど、私個人的にはこのはてなダイアリーってやつにとても興味を持ったんですよね。
純粋にIT系オタク集団（失礼）がコミュニティで勝負するっていう構図のサービスがすごく面白いなって思いまして、当時から実際にIT系のギークな技術記事とか、濃厚なネットのいざこざとかそういうのがぐちゃぐちゃと集積されつつあって、うわぁ危険と思いながらもはてなだけは明確に識別して見に行く感じになってたんですよね。
人力検索もそうですが、アンテナとか、キーワードとか。私はネットコミュニティをやりたくてこの世界に入ってきた人間なので、人と人をつなげるサービス、というコンセプトに対して面白いことをやろうとしている人達がいるんだなーって思ってたんです。こんな殺風景な非コミュ論壇だらけのサイトなのに。なんだかそのギャップがまたすごく居心地が良くてね。よく閉鎖的って揶揄されるはてなですけど、私はそんな風に思ったことなかったな。
そう、私は村感というよりは、僻地の秘境だけどここは自由でオープンだ、っていうように感じていたんです。
今はなおさら顕著ですけど、その頃って既にインターネットサービスが外来の大手サービスに集約されつつあったじゃないですか。ブログにしたってMovableTypeもWordpressも外から来たものだし、MySpaceとか、Facebookもそうだし、その後の流れって周知のとおりって感じじゃないですか。強いて言えばmixi……はやっぱべつにいいや。
そんな中、日本のドメスティックな小さなネットベンチャーが純粋なコミュニケーションの仕組みだけで世界観を醸成して、しかも生き残るっていうことに夢を感じたんですよ。まあ、ドメスティックっていう部分について言えば、jkondoさんが渡米した時期とかあったなぁ、とかあるんですけども。
はっきり告白しますけど、私のような自分で新しいプラットフォームを開発するほどの実力が無い中途半端なネット屋にとって、超恥ずかしながら彼らはヒーローだったんですよ。jkondoさんやnaoyaさんは私とほぼ同い年ですけど、勝手に同世代のヒーローだと思ってたんですよ。
はてなブックマークでソーシャル・ブックマークという概念を身近に体験した時は「単なる『お気に入り』じゃなくて、興味を持ったものについて何時でも語り合える世界が作れるんだなあ」ってリアルに衝撃を受けたし、スターが登場した時は（FacebookやTwitterより前に）これ、シンプルだけどもしかして世界を幸せにする機能じゃね？って感動したりしましたよ。
だいたい、jkondoさんはすごいんですよ。私など勝てる要素が無いですよ。スプリントでもロングでもヒルクライムでも絶対勝てないですよ。山も強いし、みんな山手線一周1時間48分てできます？？サラッと書かれてたけど、メチャクチャ速いよ！！俺も何度もやってるけど、大真面目にやっても3時間切るのだって大変だよ。明治通りや中央通りはともかく、田端駒込あたりの裏路地とかどうしてたんでしょうね。メッチャ危ないよ！！つか、あの頃の自転車クラスタみんなどこ行っちゃったんでしょうね……
何の話でしたっけ。そうそう、趣味が合いそうな人達が集ってるっていう話でしたね。
私の文章は、テキストサイトからアルファブロガーあたりまでの文章にめちゃくちゃ影響を受けていると思います。ちょっと極端なことを書いたら「フロムダ先生の真似か」とツッコまれてドキッとしたり、写真クラスタの真似をしてやたらでかい写真を並べてみたり。最近は年に一回お正月だけに現れるmk2さんの文章を見ると涙が出そうになります。長文には慣れています。必死に調べないとついていけないような技術論議や、内蔵をさらけ出して書いたような、編集が入った本では読めないようなブログを読みたいし、そういう記事でみんなが共感していく世界が見たかったんです。
はてなブログの目次記法は便利だと思うんですけど、他所のニュースサイトに貼られた記事を引っ張って目次を並べていかがでしたか？なんていう記事を、私は単純に面白く読めないんですよ。「参考になりました！」じゃねーよ！！ならねーよ！！残念すぎるだろ！！なんて思ってたんですよ。
ここまでで既に5,000文字を超えてしまいましたが、話が飛んでしまったので一旦元に戻します。
つまり、そういった「自分の好きなものを好きと言う」「好きなものを選んで、好きなものを見て共感する」という、人の本能的なコミュニケーションの楽しみの源泉のようなものを、私は求めていたんだと思います。自分の背中に正直な、泥だらけのスニーカーで追い越すような体験を期待していたんです。
もちろん、どんな時代にだって人と人のコミュニケーションにはいろいろあって、変わらないものがたくさんあるんだとは思いますよ。パソ通の時代だって、BBSの時代だって、初期のブログにだって、「読みました。記念カキコ☆」はあったし、コメント欄で交流が繋がって新たな友達ができるという興奮だってあったし。
最近のはてなだって、今、その興奮を新たに体験して純粋に喜びを感じている人達がいるはずだしそれはもちろん喜ばしいことなんですけど、さすがにこの情報過多なご時世なので、ツールと場所の管理と運営をしっかりやっていかないと、純粋な喜びを埋もれさせず、コンテンツの品質を保つのは相当に厳しいなという実感はありますね。
一般化、大衆化、というものはだいたいそうで、単純に「この村も昔は良かったのに」っておじいさんが言っているっていうような話ではないと思うんですよ。
こんなことを話している私自身が既にネット上では「古い側」の人間になっているのかもしれませんが、個人的には、「はてな村」とかって言われている界隈にそれほどイライラするような内輪感を感じたことは無いんですよね。実際にひどい攻撃的な言葉が飛んできて嫌な思いをしたことだってありますし、慣れ合いとかってのは昔も今もあるわけなんですけど、だいたいは好きなことを好きなように書いた、っていうモチベーションによって書かれた記事は、面白ければ当たるし、面白くなければ流行らないわけじゃないですか。読む側だって気に入ったら読めばいいし、気に入らなかったらスルーすればいい。だいたい、広い世界で見ればごく一部のできごとだっていう側面もあったわけじゃないですか。
だから、一定の、嘘を嘘と見抜ける程度のネットリテラシーさえあれば、海水浴場の中に浮かぶ邪魔な漂着物があっても、農耕地が石だらけで荒地になっていても、単に避ければいいだけだって思ってたんです。
むしろ、良い記事にフォローが集まったり、ひどい記事はひどい記事でそれに集まった批判が有益だったり、そうやってやり取りを応酬する中で集合知として収斂されていくという光景は、みんなで海を掃除したり、畑を耕していくような感覚を覚えていつもネットの醍醐味であり爽快ですらありました。
……でもね。最近の例の動向はちょっと様相が違っていて、私のようなユーザーにとってはもうちょっと見ているのが厳しいな、というのが本音です。商業的なまとめサイトが場を汚染している、というような話であればユーザー側コミュニティによるチェックと自浄作用が働きます。はてブはうまいことそういう機能を果たしてきたと思うんですよね。
でも、ユーザー側のほうで「良いと思ったから良いと言った」というお気に入りによるキュレーション機能が働かず、返報性の原理によるコミュニケーションが中心の場になってしまったら、今のままのはてブでは、（コメントツールとしてはともかく）少なくとも情報ツールとしての価値は大きく毀損されます。これは、ユーザーのモラルもありますが、サービスの構造上の問題として避けられなかったことだと思うんですよね。
海や畑が全部「あれ」になったら、もうどうしようもないでしょう。もう去るしかない。
この問題についてはさんっざんぱらたくさんの人に書き尽くされているのでここでは書くつもりないんですけど、小遣い目的で面白くない記事が量産される、共有のヘッドラインが専有されて他のユーザーに影響を及ぼす、内容に関係なく相互フォローする、これらは本人の意識あるなしに関わらず、関係ない人から見たら無益です。
これについてルール違反がないのならば、サービス品質を維持するための運営／システム側の構造課題を疑ったほうが良いし、ユーザー側についても、一部の炎上チャリーンで喜ぶようなやつは単なるスパムなのでこれは単純な絶対悪ですよ。
別に、ネットの世界で今始まったことじゃないんですよ。むしろはてブは牧歌的で今まで性善説でよくやってこれたなっていうレベルじゃないかと思います。Twitterでも「相互フォロー推進委員会」とかあったなあ。一方的に何百人単位でフォローしてきて、ふぁぼりまくって、こっちが反応しないと砂をかけて去っていくようなのが……
ただそういう人達がごにょごにょ楽しくやってるだけならどうだっていいんですけど、今はホッテントリが明らかに使いづらくなっていたり、更には他のSNS経由でこの界隈の記事が流れてきて反応したらおかしなことになったり、実際にそういうことが発生しだしているんですよね。これが結構精神的にくるものがあるんですよね。
というわけで、そういう一団がこのサービスのほんの数%、もしかしたら0.数%の人達であり、ほとんどの普通の人は何も気にせず普通に自分の日記を書いているんだ、てことはわかっていても、でももう気持ち的にこの界隈と一緒の世界でブログを書くのは無理かもしれない。既に古参と言われる人達がかなり去っていっているし、生き残っている人達も読者層が急激に変わっていたりとかして、なんていうか、見ててつらい。
※最近、ある有名人気ブロガーのブログを読んでいて、半年前にも同じテーマで書かれたことがある記事がホッテントリに入っていたのを見たんですけど、ふとブコメを見てみたら、半年前の記事と反応のコメントが全然違くてびっくりしたことがあったんですよ。よく見ると、並んでいるアイコンがガラリと変わっていることに気づきました。読者層が急激に入れ替わっているんですね。
この人はムラ社会に寄る人では（読者から見たイメージでは）無いし、長い人とも新しい人ともバランスのいい関係を築けていてすごいなあ、と思っていたのですが、図らずも急激に「有名人」として新規層の神輿に乗せられているように見える状態になってしまって、一方で彼自身は広告収入で儲けているようなブロガーではないし、内心複雑な気持ちなんじゃないかな、とか勝手な心配をしていたりします。そういう人、何人かいますよね。余計なお世話すぎるとは思うのですが。
------------------
（コンテンツに思い入れがなければダメだという日本で商業的にもまかり通ってきた俗説を鑑みるに）、やっぱりひとつの創作にこだわりがあると全くダメで、こだわりがなければないほど商業性や一般性というクオリティに貢献できるので商業的には大変有意義な結果を出せるんじゃないかなと思う。GoogleとかAmazonも、多分自分のやってる「コンテンツ」に興味がなくて、プラットフォームとかどうすれば効率的かみたいなことに注力してるんじゃないかと思う。
日本の場合「自分で作ったもの」にこだわりすぎて身動きがとれない。また、プラットフォームを作ろうという人達も自分たちの作ったサービスの動き方にとらわれすぎている。自分の決めたことにとらわれすぎている。
そういうのは作家に任せておけばいいのであって、フォーマットだけ作ればいいんじゃないかなと。
アメコミのヒーローは社会情勢によって変革できるフォーマットをとっている。だからとてつもない時間を生きながらえている。そういう作品って日本にあるかなと考えたら、多分ない。長く居続けているのはサザエさんとアンパンマンくらいで、前者は何も語りはしない。語るけど、せいぜい時代錯誤なことか持っている機器の変化くらい。アンパンマンは設定が普遍性がなく、大人向けに落としこむことが出来ないので（全身タイツの超人/一般人と、頭がアンパンの人造人間の、どちらが感情移入できるかは明白）いついかなる時代の空気を落とし込めることは出来ない。社会性のある、そしてなおかつエンタテイメント性のある作品は作れない。作ったとしても、アンパンマンでは世界全体に届かない。
ドラゴンボールは孫悟空という人格破綻した存在と、世界を脅かす悪役が魅力的だから日本以外の国にも受けている。しかし、ドラゴンボールを鳥山明以外が作ったら受けるかと言ったらそんなことはない。それはドラゴンボールエボリューションでも明らかなことだと思う。ファンが作ったものが最高だというけれど、それは商業には成り得ないし、社会性は得られない。ドラゴンボールという作品自体、社会性は得られない、鳥山明の個人的な世界を描いた作品でしかない。日本の作品はそういうものしかないと思われる。
どんなにクールジャパンだとか政策として日本の作品を世界に輸出しようといっても、作られる物自体が社会性の乏しいものだとしたら一般性は得られないだろう。進撃の巨人も、バットマンやスーパーマンのように80年近く愛されはしない。
日本人が世界に向けて「売れる」作品を安定供給しようとするなら、すべての自主規制的なものを取っ払い、個人的で、誰にも想像し得なく、そして少数の心に突き刺さるインディペンデントな作品を大量に押し出していくしかないだろうなと思う。それは太宰治や夏目漱石、それよりももっと前の作者にしてもそうだと思う。日本は今のところ個人的なものしか作れない。ライトノベルもそうだし、内需しか見えてない。ポリティカル・コレクトネスがどうこうではなくて、作る人間の数メートル先しか見えてない。それは宮﨑駿もそうだと思う。
クールジャパン、あり得るけれどもそれが全世界、普遍性のあるものなんて幻想だ。普遍性がないからこそ求められてる。新堂えるが、トレヴァー・ブラウンが国外脱出した意味を考えるべき。自分のありようを考えるべき。どうしても日本人は、自分から、自分の周辺から抜け出せない。あるいは自分を外部化出来ない。
自分自身の理想が高すぎる気がするし、その割に就職先がFなんて時点で間違ってる気がするし。
どっちにも落ち度があるかなあって感じが。
＞オープンプラットフォームにしてほしいとか、COBOLは嫌だとか
これなんてFなら普通に避けられないようなとこだと思うがな。そう思ってなかったなら知らなさすぎ。
理由は簡単に言ってしまえば自分の目指すキャリアパスとのミスマッチ。
おそらく人事部の書類にも、今頃そんな感じのことが書かれているんだと思う。
なぜ好き好んでそんな会社に入社して、短期間で退職するはめになったのかを書こうと思う。
入社する前は大学の情報系学部に通い、大学院まで進学して専門分野の研究にそれなりに熱意をもって取り組んでいた。
それもあって、同じ分野の研究を企業として行なっている同社に入社しようと考えた。
内定の前後にいくつかの職種のマッチングを行う機会はあり、自分の希望についてはしっかりと主張したつもりだったけれど、
入社して1週間後に告げられた自分の配属先は、山奥の工場でメインフレームを主とするシステムの開発・保守を行う関連会社への出向だった。
当然この決定に対して人事に不服を申し立てたけれど、返ってくる答えはあらかじめ用意してあったような定型文と、「みんな我慢しているからお前も我慢しろ」というお説教だけ。
もちろん、規模の大きい会社だし、全員が希望通りの職種につけるとは思っていたわけではない。
でも、曲がりなりにも現代のIT企業に入社したつもりなのに、20代そこそこの新卒社員が化石みたいなプラットフォームの世話を押し付けられるなんて想像だにしていなかったし、
綺羅びやかな会社説明の資料の中にそんな説明を見た覚えもなかった。
もちろん決定は全く覆らなかったのだけど、その後も思いつくだけの人脈を辿って色々な人に相談して助言を貰い、
せめて担当業務はオープンプラットフォームにしてほしいとか、COBOLは嫌だとか、ついでに可能であれば山奥の工場に押し込まれるのも勘弁してほしいとか、
できる限り主張をしつつ、しばらくの間実際に働いてみてから身の振り方を決めることにした。
それからしばらくの間新入社員研修をこなし（富士通に限らず、いわゆる日本的な大企業は研修期間がやたらに長い）、
そろそろ本格的に業務に携わりたいと思っていた矢先、上司に告げられた自分の担当業務はほかでもない、あの20万人月案件だった。
例によって守秘義務があるので詳しくは書けないのだけれど、業務を行うツールはもちろんMicrosoft Excel。
自分の仕事は言われたとおりにExcelシートに入力し、マクロを実行して成果物となるファイルを吐き出すことだった。
このマクロの挙動はとても怪しいものだったのだけれど、どうやら自分はこのマクロの修正はおろか、ソースを見ることもできない身分らしい。
SIの現場で日々行なわれている業務内容については詳しく知っているわけではなかったけれど、自分のやっていることが著しく非効率的であることだけははっきりとわかった。
そもそも、具体的な配属先については希望とズレがあったにせよ、少なくとも自分は開発職として入社したはずで、SI業務がやりたくてこの会社に来たわけではない。
とどめに「君はオープンプラットフォームでの開発には多少覚えがあるらしいけど、メインフレームではそんなものは役に立たないから。」なんて台詞が飛んできた。
確かに、Excelシートへの入力作業に情報学の修士号なんていらないし、キャッシュコヒーレンシの話なんてオタクの気持ち悪い自分語りみたいなものでしょうね。
結局これが引き金になって、転職を決意した。
しばらくの間働いてみてそれから考えるなんて、とんでもなく愚かなことだとようやく気付いた。
ただ、短い期間ではあるけども世話になった上司と、開発職の社員をSI業務に割り当てざるを得ない状況については自分も一定の理解を示しているつもりだったので、
多少なりとも会社への影響を軽減できればと思い、転職するつもりである旨を早い段階で上司に明かした。結果としてこれが大きな間違いだった。
転職の旨を伝えた週の金曜日、自席に上司から電話があり、「働く気がないならすぐに辞めてもらう」といった調子で一方的に退職日を設定された。
流石にこれは法的にも問題がある行為だと思い、すぐに折り返し電話をかけて抗議し、翌週時間をとって直接話すことになった。
翌週直接話してみると、上司はケロッとした顔で「なんだ、働く気がないわけじゃないんだ、勘違いしてた。じゃあ退職日はいつにする？」なんて聞いてきた。
自分が抗議しなかったらどうするつもりだったんだろう。
幸い、書類上は見栄えのいい学歴と、知人からの紹介と、"多少覚えのある"スキルのおかげで転職には全く困らなかった。
そろそろ就職活動が本格的に始まる頃だけど、今の就活生には是非とも就職先は慎重に選んで、貴重な若い時間を無駄にすることがないようにしてもらいたい。
○朝食：なし
○昼食：おにぎり三つ
○調子
むきゅー！
○ブコメ返信
ロボットポンコッツを始め、クロスハンターとかメダロットとかのポケモンになれなかった銀メダリスト達が多くいましたね。
まあただ、これは辞めなければ勝ちみたいなもので、そもそもの続ける企業体力みたいなものの差でしかない気もします。
ちなみに、ボンボンは父親が重度のガノタだったため、プラモウォーズや、ときたコミカライズのために父親が買ってましたね。
oooooo4150さんが、どれだけのゲーム知識やパソコン知識を持っているかわからないので、
Microsoftが何のためにゲームを作るのか、そして今なぜWindows10を押し進めているのか、の理由を書きます。
もちろん例外は山ほどありますが、Windowsの多くのゲームはこの「DirectX」というライブラリが無いと動きません。
この「DirectX」を使うと、スーパープログラマがゴリゴリ機械語だのアセンブリだので描画を書かなくても、ライブラリを使って簡単お手軽に3Dゲームを作れます。
Quantum Breakのような大規模ゲームにおいては、如何に多くの人間が関われるか？ が重要なため、このような汎用的なライブラリを使って作業の標準化を行っています。
また、Quantum Breakでは「銃の弾道の軌跡」や「時間の巻き戻りや進みや停止によるエフェクト」などが非常に美しく、
「静止画」としての美しさよりも「ゲーム」としての美しさを優先しています。
その証拠に、現行世代機では解像度は劣っています。（720p30fps）
ただ、その分、ゲーム動作のエフェクトにとても力を入れていて、「時は力」を体現する見た目を見事に描画しています。
このエフェクトは、同時多発的にかつリアルタイムに描画されるため、非常に高度な技術が必要なのは、素人目にもわかると思います。
そのため、Quantum Breakは「DirectX12」という最新のライブラリ、
さらにそれに最適化された「Northlight Engine」というこのゲーム独自のエンジンも使っています。
この「DirectX12」は、最新のWindows10にしか対応していないため、Quantum BreakはWin7では遊べないのです。
じゃあ、今度は「DirectX12」はどうしてWin7に対応しないのか？
という疑問がわくかもしれません。
それは、Microsoftがそもそも何のためにゲームを売るのか、ゲームを売ることで何を成し遂げたいのか？ を説明しないといけません。
Microsoftが初代Xbox（旧箱）の時代から掲げているのが「リビング」です。
ココで言うリビングは、家族が揃っている部屋、程度の意味で、要するに「テレビがある部屋」みたいな意味です。
で、Microsoftは世界中の「テレビがある部屋」に、自社の製品を置いてもらいたいと思っています。
では、そのためにはどうすればよいのか？
いやいや、実はそれだけじゃ駄目です。
当然人間には金銭的な理由やスペース的な理由などで「他社製品」との比較をして、Microsoftの製品を置くかどうか決めるわけです。
そこで、Microsoftは「他社製品」に勝つ必要があるわけですね。
もちろん、プレステや任天堂より面白いゲームを作るのは大前提です。
けれど、歴史的事実としてSEGAは今ハード事業をしていませんし、ATARIもしていません。
SEGAが他社と比べて劣っていたわけでないことは、僕以外の誰かが詳しいので誰かに聞いてください。はてなには多分山ほどこの辺のゲーム事情に詳しい人がいるので。
また、リビングには「スティックPC」や「ApplTV」といった、ゲーム機以外の「他社製品」も参入してきています。
そんな状況でMicrosoftは、自社製品の要である「Windows」と未だ世界二位だか三位だかに甘んじている「Xbox」を融合させようと考えています。
つまり、仕事場や個人の部屋を制した「Windows」が「Xbox」が未だに制覇できていない、リビングに乗り込もうとしているのです。
さらには、モバイル端末機器の話とかも絡むのですが、省略します。
それの一端として、UWPアプリといって、Xboxでも、Windows10でも、Windows10Mobileでも、動くもの凄く汎用性のあるプラットフォームを作ろうとしています。
UWPアプリはAndroidやiOSでも動かす事ができる予定で、かの5pbさんが掲げた「1コード7プラットフォーム」は計らずとも現実の物になろうとしているのが、現状です。
（本題とは離れるので深くは触れませんが、自社製品だけでなく、他社製品であるAndroidやらiOSやらに向けても色々な施策があります。Xamarinとかでググってください）
このUWPアプリによって「あっ自分の部屋でやったゲームの続きを、そのままリビングでやろう」とか、その逆であるとか、
「電車の中でプレイしたゲームの続きを、リビングや自室の大きなテレビでやろう」みたいな動線を作ろうとしているんですね。
Quantum BreakはUWPアプリではないものの、Windows10版もXboxOne版もほぼ同じ体験ができ、セーブデータも共有できます。
メインストーリーは家族と一緒に楽しみ、やり込みは自室のパソコンで遊ぶ、なんて体験を提供しているわけです。
そして、こういう新たな施策は、ユーザー数がついてこないと意味がないんですよね。
良い”体験”を売るのは、今この世だからこそ評価されるんです。
Quantum Breakは30年後も評価されるゲームですが、Quantum Breakを取り巻くXboxOneやWindows10の体験は今でないと評価できないんです。
（任天堂のディスクシステムなんか典型的ですよね。あの時だから評価できる。今ならインターネットからダウンロードじゃない理由がないですもの）
そのために、Microsoftとしては「Windows10」の普及率を上げる必要があるんです。
なのでWin7は切り捨てないといけない、今更Win7に最新ゲームを対応したら、何時までたってもゲーマーはWindows10に移行してくれないんです。
だから、Windows10の無料アップデートをしつこくするんです。
（Win7でそのUWPアプリの構想はできないのかって？ この構想はモバイル端末、ゲーム機、PCなど様々なOSが一本化できるからこそ意味があるので、それはちょっと厳しいかもしれませんね。何よりMicrosoftは、iOSのAppSotreやスチームのような「販売する場」を作ろうとWindows8辺りから一生懸命なので、ソフトウェアのようなDL販売が主のものは、なおさらWin7では出せないんです）
長々と書きましたが、どうしてWin7で遊べないか理解していただけたでしょうか？
二行でまとめると、
「商売的にはWindows10を中心としてゲーム機やPCやモバイル端末を売りたいから」
って感じです。
とまあ、理屈を述べたところで、Windows10搭載のPCを買ったり、Win7をアップデートしたりすることの後押しにはならないと思います。
キラーインスティンクトのシーズン3はWindows10とXboxOneのクロスプラットフォームで盛り上がって行くし、
ギガンテックも多分出るし（フェイブルレジェンドのアレのせいで運営型ゲームは怖いけどね）
将来的にそこまで悪いハードだとは思わないので、是非とも、XboxOneやWindows10をよろしくお願いします。
スマホ向けボードゲーム「ポケモンコマスター」Android版が本日サービスイン。AIを活用してデュエルを勝ち抜こう
http://www.4gamer.net/games/336/G033671/20160412029/
大好きなポケモンのシリーズだけど、これはちょっとプレイするのを辞めておこうと思う。
理由は簡単で、月五万円上限一杯まで課金する自分を止められそうにないからです。
この日記で度々話題に出してるけど、ポケモンとガチャは相性が悪すぎると思う。
僕の愛する悪ポケたちをコンプしたいという欲を、抑えられる自信が全くないので、触らぬが吉ですね。
Kindleでサンプルを見てみたのだけど、EPUBみたいなちゃんとした電子書籍でなくpdfらしくまともに読めない。ページめくりが異常に遅いし、線引いたりできないし、汚いし、デバイスにあったサイズで読めないから読みにくい。
他にもいろんなプラットフォームで出てるみたいなんだけど、結城先生のページからはこのAmazonにしかリンク貼られてない。
Google Play Books版があるのに気づいて見てみたけど、こっちはAndroidではまあ快適に読めそう。しかしMacでなぜか開けない。自分はMacとAndroidで快適に読める電子書籍版を買いたいのだけど、存在しないようだ。pdfが手に入れば十分なんだけど。
サンプルを読んだ感じ内容はとても良さそうだけど、IT系の書籍がITをうまく使えてないのはかっこ悪いよね。なんとかしてくれないかなあ。
○朝食：なし
○昼食：おにぎり三つ
○調子
むきゅー！
同僚の咲の深堀さんに似てる人とは今日で一旦お別れです。
むきゅむきゅー。
半年ぐらいだったけど、結構仲良くできたので、はやく五月になって合流したいです。
ちなみに、いつの間にやら「バンビちゃん」という、あだ名を付けてもらいました。
人生で、あだ名をつけてもらったのは初めてなので、とっても嬉しかったです。
今後，Forzaシリーズの全作品がPCとXbox Oneの両対応でリリースされることが明らかに
http://www.4gamer.net/games/335/G033544/20160331101/
遊べるユーザーが増えるのは良いことだよね。
正直「任天堂のゲーム」と比較して「Xboxのゲーム」は知名度が無さすぎるから、
まずはこうしてハードを広くして、知ってもらうことが大切なのかなあ。
ただ、そうやって知ってもらって増えたユーザーが、Xboxを買うとは思えないし、
そもそも、日本じゃPCゲーやる人はゲームの知識が豊富な人が多そうだしね。
前向きに捉えるなら、Xboxってハードが撤退しても、Windows買えばシリーズを遊べるのかもね。
いやまあ、撤退しないのが一番なんだけどね。
フィル・スペンサー氏、PC版『Halo 5』リリース可能性に言及―プラットフォーム適正を考慮
http://www.gamespark.jp/article/2016/03/31/64805.html
で、まあ、Forzaがいくなら、Haloも将来的にはそうなるわなあ。
僕はパソコンの仕事してるわりに、ハードのこと詳しくないので、
家庭用ゲーム機がリリースされるなら、そっちを追っかけるつもりではいるけど、
XboxOneの次が、もし日本でリリースされない、ってことになれば、
腹くくってPCゲーに手を出さざるをえないのかなあ。
何度も言うけど、そんな撤退なんて日がこないことをただただ祈るよ。
Fateシリーズ初のスマホRPGはこうして作られた…『Fate/Grand Order』 ×「Unity」×「デザイン塾」を4月23日に開催 開発会社のオフィスも公開
http://social-creator.info/articles/159352
「勝てば官軍」だなあ。
セカンドライフ時代からヘッドマウントディプレイはあったし、違いは没入感とかその辺りなのだろうか
CGも進化してきたような感じはあるのだけど、リアルタイム描写となると、あんまり変わってないんじゃないか？
SAOほど現実と見間違うくらいならと思うのだけど、どうも違う感じがする。
個人でフォトリアルなCGを作るまでの効率化はまだ発展途上な感じはあって、
VR上で家を作ったり、街を作ったりというのは、まだ時間がかかりそう。
現実にあるものを3Dスキャンして原型作成→埋め込みというのもまだっぽい。
現実では失敗して問題がありそうなことも、VRならといっているが、没入感が強すぎると禁止にならんかと思う。
○朝食：なし
○調子
むきゅー。
ちょくちょくやる気がでないとか書いてたけど、どうやら作業してる人みんなその気持ちだったようで、
各地で文句が爆発していた。
「は？ なんの意味があるのそれ？」とか
「もうやらんでええんちゃう？」とか
「あのお、本気でこの作業やるつもりなんですか？ 頭大丈夫ですか？ 漢字読めますか？ ここ、ここに書いてある漢字読めます？ 読めるけど意味わからないですか？ 英語でいいましょうか？」とか
もちろん、僕も思っていたが、これ以上言われたら上司さんが可哀想だと思ったので、
とっととアリバイ作り的に終わらしてスケジュールに完了の印を書いておいた。
付き合って残業する気にもなれないので、さっさと定時ダッシュ。
［GDC 2016］プラットフォームの垣根を越えて対戦が楽しめる日も近い!? 「ID@Xbox」の新たな取り組みとして「Cross-Network Play」が発表
http://www.4gamer.net/games/990/G999025/20160315088/
プレイ人口が増えるのは文句無しに良いことなので、この試みは大賛成。
とは、ちょっと言いがたい面もあるんだよなあ。
まあそりゃ、RocketLeagueはパーティーゲームっていうと変だけど、
FF14みたいな大縄跳びMMOも人口が命だから、良いと思う。
けど、CODとかBFみたいな、競技性の強いゲームだと、若干気になるなあ。
気になるけど、僕自身はそういう競技性の強いゲームやらないから、どうでもいいや。
【GDC 2016】Twitch、ライブ配信とゲームの融合―視聴者と共に遊ぶ3作品を披露
http://www.gamespark.jp/article/2016/03/15/64411.html
おー、こりゃ面白そうだね。
ただ、僕自身が見てるゲーム実況は、ニコ生がほとんどなので、そこの人たちが移住しないと楽しめなさそうだ。
ゲーム実況のキモはゲーム自体よりも、配信者だと思っているので、中々難しそうだ。
マイクロソフトが『マインクラフト』で人工知能の学習能力を研究、今夏オープンソースで公開予定
http://www.inside-games.jp/article/2016/03/15/96883.html
最近、はてなでも話題の囲碁のAIが凄いみたいな話があるけど、
「勝ち負けの明確なルールがない」ゲームでのAIも見たいと思っていたので、
この記事は凄く興味深い。
「牛を効率よく肉にする仕組み」っていうルールを与えたときに、AIはどんな牧場を作るんだろう。
みたいなことを、観察して楽しみたいんだよね。
トイロジックの『グリモン』はちょっぴりダークで可愛い英語学習アプリだった
http://www.inside-games.jp/article/2016/03/15/96854.html
ドラクエが忙しそうだけど、ハピダも忘れないでね……
『Fate』の英霊たちが戦う新作ゲーム『Fate/EXTELLA（フェイト/エクステラ）』が発表
http://dengekionline.com/elem/000/001/237/1237086/
また聖杯戦争が始まるのかあ。
なんかもうかなりの回数こなしてる気分なんだよね。
駄肉ちゃんに出番があるといいなあ。
あんまりXboxOneプレイヤーにとってうれしい未来は無さそう。
まず第一にコレ。PCみたいにグラフィッククオリティ落としてフレームレート上げたり出来ないから一方的に狩られる可能性あり。
逆に解像度合わせるためにフレームレート落ちてるゲームとかだとフレームレートの差でどうしても反応が遅れる事態が発生する。
ちなみにここまではまだマシな状況。
コレ。宗教戦争に油を注ぐ結果にしかならん。特に前作とかがマルチで解像度やフレームレートに差があったりして
次回作でオンライン繋がった上に解像度やフレームレートが落ちたりすると、炎上間違いなし。
北米以外じゃ、パブリッシャーが他プラットフォームのクオリティ落としてまで拾いたがるほどユーザーベース多くないってのが
唯一の救いだな。
もちろん競合他社の製品と比べて売れてないって問題はあるにしろ、一番デカい理由は「MSがコンシューマを大して重要な客だと位置づけなくなった」ことだろう。
Windows10の対応でもそうだけど、もう一般消費者なんて企業向けサービスのβテスターなんだよね。
じゃあXboxOneは？っていうとそのWindows10の販促ツール程度の価値しかないってもうMS自体が認めちゃったようなもんだよね。
Forza6も機能限定版とはいえF2Pでリリースするし、次からはPCマルチって確か明言してたし、XboxOneを金掛けて保守する気が無い。
綺麗事を言えば「自社プラットフォームをやっと繋げる気になった」んだけど、まぁ今のMS見てりゃわかる通りコンシューマの位置付けがMSの中でどんどん下がってる。
OS市場は採算度外視の競合に押されて儲からなくなってきてるし、スマフォなんか競合のミカジメ料せしめて食い繋いでるレベルだし
まともに伸びてるのはB2B市場だけ。
まぁ、仕方ないな。
季節外れのインフルエンザだよ！
カクヨムは出版社の都合優先し過ぎの漁場設計だから上手く行ってないな。
（下読み素人にさせてピックアップ後のだけ編集者が読みたいとか、そういうね）
カクヨムは、Consumer Generated Media（消費者作成メディア、略してCGM）そのものなのよね。
勝手にピックアップ（下読み）が完了する、美味しいプラットフォーム。
カドカワにとっては、美味しい漁場ね。
という企画書になってるハズ。
Youtubeとかニコニコが曲がりなりにも回るのは、暴力的なまでに圧倒的多数の「視聴者」が居るから。
Twitterとか2chとかでTV番組のコメント拾うとソコソコ的確なデータが揃うのも同じ。
ということはだ、カクヨムの場合は「読者」中心に設計しないといけないはずだった。
が、ニコニコとかがあると、どうあっても「作者」寄りに設計するよな。
そこがマトモにシミュレートしてねえよなって感じる所。
まあ、「読み専」って単語そのものが既にして判ってねえ感満載なんだが、
繰り返しになるけど、評価者が中心に来ないとまずい。
誰も評価しなかったらどうなるか？
誰が使うんだそのメディア。
今のカクヨムは、その状況。
まあ、面白い作品があって埋もれてる状況って、もったいないよな。
そうすると、例えば以下の手法がある
どこまで読んだかの栞、傾向の似てる作品のレコメンド、読んだ作品数の貯金。
あらゆる読者向けサービスで使われている書影（表紙画像）って記憶にダイレクトに効いてくるので、
pixivと連携して書影コンテストを開催するくらいのことはやって充実させる気概が欲しい。
コレがあるだけで、チョット読んでみようかって人が増える。
カドカワに人材居ないなら、それこそ日替わり編集長とか頼めばええがな。
目が多ければ問題になることは少ないんだよね。つまり、評価者が少ないのが問題。
だったら、「参考になったレビュー」と「参考にならなかったレビュー」をさらに評価するのが手っ取り早い。
（興味深いとか面白おかしいみたいな、スラド方式もあるけど、いきなり導入は難しかろうな）
まあね。
でも、そのレビュー評価で作品選んでんだから実は同じなんだよね。
星の合計数が出てるってのがそれ。他の人の評価で選ぶなら、他人の評価を読んでるのと一緒。
AmazonとかAppleが星の合計数じゃなくて「★★★が何人です」ってやってんの意味あるんだよ。
★５と★１にピークがあるなら人を選ぶ作品だってわかるし、★５が多いなら読んで損はしない。
知らず知らずのうちに人は評価者に影響を受けてる。
ちゃんと評価されればね。
なんでかって言うと、無名の１万人の作品を読む暇人は基本的には存在しない。
ニコニコ動画に「人類には早すぎた動画ランキング」がある理由を思い出そう。
ログイン後に強制的に玉石混交の作品を読まされるとかじゃない限り、人はランキングに頼る。
チートは弾くべきだけど、やるべきことは「互助会への加入補助」になるんだよ。
互助会ってワードが強すぎると思うなら、クラスタの生成とか、ニッチなクラブ作りでも良い。
ハードSF好きとか、スーパー攻め様だけ読む人とか、ネットは広大なのでニッチの組閣は必ずできる。
（設計的には評価者だけの組織化を促すべきなんだろうけど、難しかろう）
今は、「読者」間の繋がりを作る方法が全く無い。
まあ、そのうち週刊カクヨムができてピックアップされたり、
今週の短編のお題が出されたり、
そういう風になっていくだろ。
もう俺の作品は日の目が見ることはないだろうが、そんなのはどうでもいい。
俺だけでなく多くの人が期待をこめて飛びこんだカクヨムをこのまま潰さないでくれ。
そして、これを見たＷＥＢ小説に少しばかり興味がある人、どうか頼む。
多くの耳目を集めて準備期間も取った今のカクヨムには、面白い作品がかなり埋もれている。
俺もいっぱい出会った。それをなんとか探し出して少しでも延命してやってくれ。
運営がなにかしらの一手を打つまで、そこまで生き残らせてくれ。
この増田に触発されて書いたのに、元増田ですら作品名書けてない現状が全て。
何言ってもステマ扱いされるようなコミュニティは健全じゃないよ。
クックパッドでも（アレだけ揉めながらも）つくれぽが人気なのは、
現時点でコミュニティ作りが全くないのは致命的。
何に焦ったか知らないけど、見切り発車しすぎじゃねーかな。
カドカワの編集者は毎日１時間読んで必ずレビュー書くぐらいしろって。
