portal shit!

『漫画村が消え、漫画BANKは閉鎖。海賊版対策は進んだ。だが、状況は悪化している | 海賊版サイトの現在地 Vol.1（前編） - コミックナタリー コラム』へのコメント

この記事に対して73件のコメントがあります。注目されているコメントは「なーにがビジネスモデルを変えろだよ。自分がタダで読みたいだけのくせに。サブスクリプション中心に転換したら市場が縮小した音楽業界の例がすでにある。その転換も前提として違法サイトを潰すことが必要だが」、「正直漫画って高いんだよね。それでも買ってるのはそのコンテンツを応援したいから。その気持ちを頼りにビジネス展開継続するのは不味いんじゃないかなとこの記事を読んで思った」、「日本の漫画は比較的安いんだけどな。デフレの世界にいるとコスパ悪いなんていいだすやつがいる。」、「ビジネスモデルは変化しつつありますよ。ジャンプラやマガポケ使ったことないんですか？ いくら利便性を追求しても、無料サイトがあればそっち見ますよね。ビジネスモデル変えろ派はどういう目線の擁護なんですか？」などです。

b.hatena.ne.jp

はてブコメント、漫画は高いという意見に対して「貧乏すぎでは？」「買いすぎでは？」「考えを改めた方がよい」「どうせタダで読みたいだけだろ」というコメント付いているけど、漫画にいくら払えるかは人それぞれだし、そもそも無料で読みたいという意見は大勢ではない（広告入ってて良いので無料で読みたいというコメントは一つだった）。漫画は安い派の意見の方が一方的に見える。

単位時間あたりの費用で漫画が他の娯楽より高いのは事実だと思う。漫画はコミックが一冊 600 円くらいするが、一冊 15 分くらいで読み終わってしまう。 1 分あたりのコストは 600 ÷ 15 = 40 円だ。映画は 2000 円払って 120 分楽しめる。分単位のコストは 2000 ÷ 120 = 16 円だ。漫画と同じくらいの金額で買える文庫本の小説なら読むのに 3 、 4 時間くらいかかるし、 1 分あたりのコストは 3 円。一冊 1500 円の単行本でも 8 円。漫画の 40 円は高すぎる。今年はうっかり一巻無料キャンペーンに釣られて空母いぶきを読み始めて続きが気になってしまい、全巻買ってしまって 1 万円くらい使ってしまった。漫画は娯楽としての経済効率が悪過ぎる。

動画配信以前、セルビデオは一本一万円くらいしたし、セル DVD も 4000 円くらいが相場で高すぎた。なのでレンタルが主流だったし、光学ディスクのレンタル屋だった Netflix が配信会社に進化した。漫画は昔はレンタルあったし今も細々と存在してるけど多分最も利用されてるのは漫画喫茶だと思う。

漫画は速く沢山読めて沢山読まないと話が完結しない特性があるから漫喫にベストマッチだと思う。時間課金なので速く読める人ほどお得。漫画は嵩張るからレンタルして家に持ち帰りまた返しにくるのは面倒だけど、漫喫ならその場で手に取ってすぐ読める。買うと保管場所に困る問題も解決されている。

少し調べた限り、漫画喫茶は著作権者にお金を払っていない（少なくとも法的には払う義務がない）ようだった。

漫画喫茶や古本屋の著作権はどうなってますか？ - ■マンガ喫茶で読まれている書籍、雑誌については著作権法で規定されている貸与権（著作者... - Yahoo!知恵袋

漫画喫茶や古本屋の著作権はどうなってますか？ ■マンガ喫茶で読まれている書籍、雑誌については著作権法で規定されている貸与権（著作者が第三者に著作物を貸与する独占権利）が発生しないと解釈されているので、著作権料が発生する事は無いと思われます。（現状、マンガ喫茶が著作者（作者、出版社）に著作権料を支払っているという事実はありません。）https://www.hou-nattoku.com/quiz/0379.ph...

detail.chiebukuro.yahoo.co.jp

漫画喫茶と貸与権 - 法律論点集

問題 漫画喫茶は、来店した顧客に漫画を貸すという役務を行うが、これに対して著作権法の貸与権（著作権法26条の３）は及ぶか。 議論 通説 漫画喫茶のように店内で読ませる場合は、漫画本の占有は顧客ではなく...

w.atwiki.jp

無料法律相談や法律事務所・弁護士検索ができるLegalus(リーガラス)

LEGALUS（リーガラス）は法律を身近に・手軽にご利用頂くための法律情報提供サイトです。幅広い条件から法律事務所・弁護士を探せます。また、弁護士の先生は業務支援ツールとしてもお使いいただけます。

legalus.jp

長らく著作物には貸与権が認められていて、音楽や映画はレンタルされる度に著作権者に収益が発生していたが、書籍は貸与権の対象外だったようだ。 2005 年に貸与権が書籍に対しても認められるようになり、貸本屋（レンタルコミック含む）は著作権料を支払わなければならなくなったようだ。

ただし漫画喫茶に関しては、文化庁が店舗内での閲覧は「貸与」に値しないとの見解を示したことから、貸与権の対象となっておらず、漫画喫茶には著作権料を払う義務がない状況のようだ。

出版物貸与権管理センター - Wikipedia

ja.wikipedia.org

こうやってみると漫画の著作権者たちの真の敵は漫画喫茶ではないかと思う。 2021 年 3 月期の決算で、業界一位の快活CLUBは漫画喫茶部門で 484 億 9900 万円の売上があるようだ。

ネットカフェ・漫画喫茶業界 市場規模･動向や企業情報 | NIKKEI COMPASS - 日本経済新聞

【NIKKEI COMPASS】ネットカフェ・漫画喫茶業界の主な市場動向や市場規模をご紹介します。レジャー・レジャー施設分野のネットカフェ・漫画喫茶業界で特徴的なシェアなど企業の情報もご覧になれます。

www.nikkei.com

漫画のサブスクリプションサービスを始めることで、現状漫画喫茶に流れているお金の大部分を漫画家・出版社は回収できるだろう。コロナ禍なのだし、漫画喫茶に行かずにサブスクリプションで手軽に読めるようになれば利用したいという人はかなりいそうだ。

サブスクリプションを始めるにしても、新作はサブスクリプションでは読めないような設計にすることで買い切り型のモデルへの悪影響は軽減できると思われる。動画配信もコロナ禍前は上映と同時配信みたいのはなかったが、漫画でも同じようなことができるはずだ。サブスクリプションで読めるのは旧作中心で配信期間も限定すれば、はてブコメント欄でマウンティングしてるような漫画愛好家は新刊発売後に購入して読みそうだし、サブスクリプションで気に入っていつでも読めるようにしたいと思った人も買い切り版を購入するだろう。

いい具合に制度設計できれば今より漫画家・出版社側の利益が減ることはないだろうし、読者の裾野を広げるという意味でも、手頃な価格で漫画を読めるサブスクリプションサービスができて欲しい。未来の漫画業界のためにも漫画のサブスクリプションは必要なのではないかと思う。

ドラマや映画の字幕がめっちゃ短くなるように訳されて本当のニュアンスが伝わらない問題、誰も問題と思ってないかもしれないけど問題だと思う。英語勉強したいと思ってドラマ見ても、日本語字幕は尺に合うようにめっちゃ超訳されてて参考にならない。

例えば Homeland シーズン 1 のエピソード 3 で、「Well, Mom, it'd be a lot less phony if you weren't fucking his good friend Mike （お母さんがお父さんの親友のマイクとやってないならインチキじゃないのにね）」と言ってるのが「マイクとやってるくせに」と訳されるの、結構意味合いが変わってくる。

字幕の訳、うまい訳だなと思うこともあるけど、セリフの通りの翻訳でないと物語を正しく理解できないことはあると思う。「この登場人物は支離滅裂気味にしゃべるな」と思ってたら実は字幕の訳の都合上大幅に情報量が削減されてたということはあると思う。

Basecamp が始めたメールサービスの HEY に登録した。去年のリリース時にお試ししていたのだけど、踏ん切りが付かなくてお金を払わなかった。ただ、ソフトウェアにお金を払うことに対していろいろ思うところがあって、良いと思うものにはお金を払おうと思って HEY に登録してみることにした。

脱受信トレイ（ Inbox ）のお気楽なメール管理

意識高く金を払って気分が良いというだけでなく、 HEY 自体がよくできてて、これまでと違ったメール体験を提供してくれる。 HEY 以前にメインで使っていた Spark も悪くはないのだが、やはり古典的なメールソフトの概念と、 Google が発明した Gmail の「受信トレイ（ Inbox ）」と「アーカイブ」の概念を引きずっている。とにかく全部のメールに目を通してアーカイブしていく作業に疲れてしまった。

HEY は最初のオンボーディングチュートリアルで使い方を学びつつ最低限の振り分け設定を行え、 15 通くらいメールの仕分けをするとその後大体いい感じにメールが振り分けられるようになる。 Imbox 、 The Feed 、 Paper Trail という三つの箱があって、重要なメールやまだ仕分けルール付けがされていないものは Imbox に、メールマガジンなどマーケティング的なメールは The Feed に、購入時のレシート的なメールは Paper Trail に、という風にメールを仕分けて使うことが想定されている。仕分け処理をやるとメールアドレスに紐付いて設定が保存され、以後そのメールアドレスからのメールは設定した仕分け先に入るようになる。一々受信トレイに来たものをアーカイブする必要はないし、受信トレイをすっ飛ばしていきなりアーカイブに放り込んでお得情報メールを見逃すということもない。 The Feed を余裕があるときに見ればよい。メールマガジンはチラシのようなものなのだということに HEY を使って初めて気がついた。

Gmail にも「メイン」、「ソーシャル」、「プロモーション」、「新着」、「フォーラム」というカテゴリー分けのような機能は存在するが、「これはここじゃないんだけどなぁ」と思うことがよくあるし、分類先を変えたいと思ったらフィルタールールを作って移動させないといけない。一々こんな仕分け作業をやってられない。一回メールの仕分けをしたら以後は自動的に同じルールを適用して欲しい。 HEY はそれをやってくれる。

Contacts という概念

HEY には独立した Contacts がある。 iPhone の Messages などメッセージアプリだと「誰とやりとりしたか」から履歴を辿れる。「友だちのノブヒデ君とやりとりしたメールを見返したい」と思うことはあると思う。メッセージアプリで普通にできることを、メールの場合はメールアドレスなどで検索するしかなかった。 HEY の場合は Contacts にアクセスして相手の名前を選ぶだけでよい。「誰とやりとりしたか」から目的のメールを探せるのが HEY のユニークなところだ。

Contacts は自分でいい感じに整理することもできる。例えば以下のキャプチャでは、 Apple の二つのメールアドレスがある。

Apple 社としてはメールを送る部門ごとにメールアドレスを使い分けているのだろうけど、こっちからしたらどっちも Apple なので統合してしまいたい。片方を開いて、サブのメールアドレスとしてもう一方のメールアドレスを登録する。

保存すると、「このメールアドレスはすでに Contacts に存在するけど統合する？」と聞かれる。

ここで "Yes, merge them" を押すと統合され、 Contacts 一覧からメールを辿るときにも統合して表示される。めっちゃ便利。

その他の便利な機能

そのほかにも、同じような要件で別々に届いたメールをスレッドとしてひとまとまりにしたり、メールを開封したかどうかを調べる解析用の gif 画像を読み込まないようにしたりなど、これまでのメールソフトにはない機能がある。まだまだ使いこなし切れてない。

HEY はガワか？

これまで Gmail のメールアドレスをいろんな場所で登録してきたのでいまも大半のメールは Gmail に届いている。各所を変更して回るのは大変だし、死ぬまで毎年 $99 を払える自信がないので Gmail から @hey.com のメールアドレスに転送するようにしている。なのでいまの自分の HEY の使い方はガワというかメールクライアントみたいな感じだ。メール本体は Gmail にあってそれを HEY のインターフェース越しに読んでいる。これならガワとして、つまりメールクライアントとしてサービスを提供してもらった方がユーザーは自分のメールアドレスを持ち込みで使えてスイッチングコストが発生せずうれしい気がするのだけど、 Basecamp はそうしないみたいだ。 HEY のマニフェエストの先頭に、メールクライアントではなくプラットフォームであることが宣言されている。

HEY — The HEY Way

We have very strong opinions about email.

hey.com

A platform, not a client

To make significant, meaningful upgrades to email, you need to build your own platform. That’s why HEY isn’t an app that sits on top of Gmail, Outlook, iCloud, Yahoo, etc. HEY is a full email service provider. You don’t use HEY to check your Gmail account, you use HEY to check your HEY account. It’s its own platform, and it’s all you’ll need.

真に意味のある変革を E メールにもたらすためには、独自のプラットフォームを構築する必要があるということだ。スレッドの統合や検索の性能向上（サーバーサイドとクライアントサイドが連携した一気通貫の検索システム）など、確かにただのガワでは実現できない部分があるのだろう。

そのほかにも The HEY Way のページには過去のメールを HEY に移行できない理由など、「割り切り」コンセプトの理由が書かれている。まるで "Getting Real" や "Rework" からの抜粋かのようだ。

HEY の残念な点

概ねにおいてよくできているのだけど、一部で使い勝手が良くない点がある。

Rebuild のエピソード 272 でヒロシマさんも言っていたけど、アプリがネイティブ実装ではなく HTML で作られているせいで、特に Mac のクライアントが Mac らしくない。一覧から詳細に遷移し、もう一度一覧に戻るときにもっさりする。 HTML を再レンダリングしているからだと思われる。個々の画面の表示は別に遅くないのだけど、総合的な体験としては良くなくて、ヒロシマさんが「速いけど遅い」と言っているのは言い得て妙だ。この辺は DHH の思想 が反映されているのだろう。

iOS 版アプリにタブがなくて移動しづらいというのもそう。 Mac であればショートカットキーで Imbox 、 The Feed 、 Paper Trail を行き来できるけど、タッチ UI ではショートカットキーが使えないので一々 HEY メニューを経由する必要がある。

総じて

不満な点がないわけではないが、 HEY がこれまでのメール体験を刷新するものであることは間違いない。インターネットを始めたばかりの頃、メールは届くととてもうれしかった。 『 You've Got Mail 』というトム・ハンクスとメグ・ライアンの映画もあったくらいだ。それがいまではメールは面倒なもの、しょうもないもの、スパムや広告だらけのものという印象を持たれるようになってしまった。その認識をひっくり返そうという試みは面白い。死ぬまで使い続けるかはわからないけど、とりあえず一年分の料金は払ったので活用してみようと思う。

ツイッターの連続投稿機能、便利だけどおっさんの長文投稿を誘発してそう。本当だったらブログに書いて記事リンク貼った方がよいけど便利なのでつい使ってしまう。短文のブログを駆逐しただけでは飽きたらず連続投稿機能で普通のブログも殺しにきてそう。 pic.twitter.com/sJMlejMnEQ

— morygonzalez (@morygonzalez) December 10, 2020

Twitter のスレッド機能で、投稿前の下書き段階からスレッド状態で長い文章を推敲しながら書くことができることを最近知った。推敲して長い文章を書けるのならブログを書く必要がないのではないか。これを知って自分は、 Twitter はブログの息の根を止めようとしているのだなと感じた。

スレッドの誕生

スレッドは 2017 年にリリースされていた。

Just a moment...

blog.twitter.com

確かにこの頃から長文を連投で投稿する IT 社長みたいなのをよく目にするようになった気がする。「フロハ」とか「ガバリ」とか「making coffee」とか書いてた頃の Twitter とは異世界になってしまった。

リリースノートによると、ユーザーが自分のツイートにリプライを書いて長い文章を書いている使い方に着目し、それをしやすくする機能としてスレッドを開発したようだ。長い文章を書けるようになったことで、それまで誰とも競合せず独自の市場（ Jaiku など同種の競合はいたがプラットフォームが持つ強力なネットワーク効果で蹴散らしてしまった）にいた Twitter がブログの世界に進出してきたのだ。

ブログの衰退

トラックバック

ブログでのコミュニケーションはとても衰退してしまった。いまでは信じられないかも知れないが、昔はブログにコメント欄やトラックバック欄があった。コメントはともかくトラックバックって何だと思う人はいるかもしれない。むかしのブログでは、誰か他の人の記事を参照して記事を書いたときにトラックバックする、という文化が存在した。

例えば A さんがうどんについての記事を書いていたとする。その記事を参照しながら B さんがそばについての記事を書いた。このとき、 B さんの記事から A さんの記事に対してリンクを張ることは可能だが、先に作成された A さんの記事から B さんの記事にリンクを作成することはできない。 A さんは自分の記事が B さんから言及されていることに気づくこともできない。関連した話題や言及されていることに A さんおよび A さんのブログの読者が気づくことができないのだ。

この問題を解決するのがトラックバックという仕組みで、 B さんのそばの記事から A さんのうどんの記事に対してトラックバックを送ることで、 A さんの記事内に B さんの記事へのリンクが表示される。 A さんは自分のブログに言及されていることを知ることができるし、 A さんのブログの読者は関連記事として B さんが書いたそばについての記事があることを知ることができる。

トラックバックボム

この仕組みは節度のある人だけがブログをやっていた時期には良かったのだが、徐々に相手の記事に言及することなく、自分のサイトへの誘導のためにトラックバックを送信する不届き者が出てくるようになった。 A さんのうどんの記事に B さんのそばの記事がトラックバックを送るのはまだわかるとして、 C さんが書いたバイクについての記事からトラックバックが届くとなると、全く話題に関連性はないし、バイクの記事から A さんのブログにリンクすることもないだろう。

こういうネチケット違反をする人だけではなく、最終的にはアフィリエイト目的で相手のブログと全く関係ない記事なのにトラックバックを送信するスパマーによって悪用されるようになり、トラックバックという文化は廃れてしまった。

議論の場となる Twitter

トラックバックが死ぬことで、ブログ上で議論するということがしづらくなった。 A さんのうどん記事に対して B さんがそばこそ至高という記事を書き、トラックバックを送った上で議論を挑むことができたのが、トラックバックがないのでネットの端っこでかみつくだけか、 A さんのブログのコメント欄に登場して議論をふっかけるしかない。しかしコメント欄もトラックバックと同じように衰退した。スパムのせいだ。静的サイトジェネレーターで生成されるブログではトラックバックはもちろんのことコメント欄も存在しない。ブログは議論の場として機能しなくなってしまった。

Twitter が流行ったからブログが廃れたという意見はかつてよく目にした。しかし Twitter が流行ったからというより、コメントやトラックバックという文化がスパマーによって破壊されてしまい、 Twitter の手を借りるまでもなくブログは勝手に死んでいったのだ。 A さんのうどん記事について「そばこそ至高」と言いたい人は、 Twitter で言及するしかなくなってしまった。この流れを加速させて、そもそも A さんも Twitter でうどんの話をするようにしたくて、 Twitter はスレッドを機能化することにしたのだろう。

コンテンツとの出会いの場としての Twitter

多くの人にとって、コンテンツとの出会いの場がポータルサイトやまとめサイトから、個々人のタイムラインに変わりつつある。みんなで同じ記事を見るのではなく、それぞれの小さなサークルの中でコンテンツを共有し合う感じだ。

いま、記事がバズったときのナンバーワンの流入元は Twitter だ。以前だったらはてブだったけど、はてブでホッテントリに入るよりも SNS でバズることの方がアクセスが集まりやすい。

はてブは一人にブックマークされただけではあまりアクセスが来ることはなく、矢継ぎ早に数人からブックマークされてホッテントリに入らないとバズれない。しかもホッテントリに入ったところではてブからのアクセスは精々 1 日で途絶えてしまう。みんなで一つのホッテントリを見てるので次々に新しい話題が出てきて、一つの記事がはてブのネットワーク内にとどまれる時間が短い。

一方で Twitter は、一人がシェアしてくれただけで割とアクセスがあり、フォロワーが沢山いるインフルエンサーによってシェアされるとあっという間に大量の流入をもたらしてくれる。しかもユーザーはそれぞれバラバラのタイムラインを見ているので、バズったときにネットワーク上にコンテンツが滞留する時間が長い。 Twitter 自体がタイムラインを単純な時系列順にせず複雑化させているし、一つの記事を別々の人がシェアすることや、リツイートの仕組みによって何度も人の目に触れさせることが可能になっている。おかげで一度バズると一週間くらいは流入を提供してくれる。

スレッドの最大の狙いは外部への離脱の抑制のはずで、これまでブログ記事や動画など、外部のコンテンツを参照する側だった Twitter が、スレッドによって長くまとまった分量のコンテンツをプラットフォーム内に持てるようになり、外に対してトラフィックを流すのではなく、プラットフォーム内にユーザーのアテンションをとどめておけるようになった。コンテンツとの出会いも消費も Twitter 内部で完結させたい、というのが Twitter の意図なはずだ。

タイムラインの滞在時間を最大化し、一つでも多くの広告を見てもらうことが Twitter のビジネスモデルにとって重要なはずだから、スレッドによるブログ殺しでバズの矛先を外部のブログではなく Twitter の内部とし、一人たりとも Twitter の外に逃したくないのだろう。

かつて日常について呟く場所だった Twitter が、日常についての短い文章に加え、長めの論説調の文章も有するメディアに変容しようとしているのだろう。プレースホルダーが "What are you doing?" から "What's happening?" に変わったのと同じ事情がそこにはある。

日常の出来事をブログに書く意義

こんにち、日記のような軽いブログ記事を見かける頻度がとんと落ちている。昔はもっとみんなライトにブログを書いていた。しかしそういうライトなブログは Twitter や Instagram などの SNS に飲み込まれてしまった。いまブログといえば、ある程度の分量のある熱のこもった記事か（暇な素人による社会時評とか）、芸能人のアメブロか、アフィリエイトか、プロが書いた商業的な記事しかない。普通の個人が書いた軽い記事を公開しづらい雰囲気が醸成されつつある。

ヒトデさんが年末にこういう記事を書いていた。

アウトプットの品質を下げておくと気軽に書けるようになる - hitode909の日記

12月であるし、アドベントカレンダーが回っていたりして、よくできた興味深いブログの記事を目にすることが多い。 よくできた記事ばかり見ていると、自分もちゃんとしたものを出さなければ、となってしまうことがありそう。しかしちょっと待ってほしい。 ブログ記事、といっても、プロの編集の手が入ったお金のかかった記事、一人で頑張って書いた大作、チョロっと書いて出てきた日記まで様々なものがある。 100文字くらいで終わっているものもあれば10万文字くらい書かれているものもあるので、文量に1000倍の差がある。 映像の世界で1000倍の差を出そうとすると、2時間すなわち7000秒の映画と、スマホで撮った7秒の動…

blog.sushi.money

#100DaysToOffload もこの考え方に通じるところがある。難しく考えずに、気軽にアウトプットすればよい。

100 Days To Offload

Can you publish 100 posts on your blog in a year?

100daystooffload.com

この感覚はとても重要で、いま我々は努めて軽いブログ記事を書くようにしないと、商業メディアや Twitter に飲み込まれて個人の簡便な意思表明がしづらい流れが固定化されてしまう。その日食べたもののことでも、その日見たテレビのことでも、その日読んだ本のことでも、その日遊んだゲームのことでも、何でもいいから SNS 以外の場所にも書くことが大事なのだ。 #100DaysToOffload のハッシュタグを付けて Twitter に何かを投稿するのは一見矛盾しているようで、 Twitter に過集中しつつあるインターネットのアテンションを再び個人ブログに取り戻そうという取り組みでもある。

なので皆さん、スレッドのご利用はほどほどにして、ブログを書きましょう

Apple TV+ で『テヘラン』を見てる。イスラエルのモサド工作員がイランのテヘランに潜入して作戦に失敗し、イスラエルに戻れなくなったというスパイドラマ。

テヘランを視聴 - Apple TV

モサドのハッカーであり工作員であるタマルは、イランの原子炉を爆破しようと偽名を使ってテヘランに潜入する。しかし任務は失敗。タマルは新たな作戦を考えなければならなくなるが、それは彼女にとって大切な人々を危険に巻き込むものとなる。

tv.apple.com

HOMELAND 見てても思ったけどイラン関係のゴタゴタは基本的に全部モサドが悪い気がする。イスラエルが作ってる番組でもあまり良くは描かれない。少なくとも『テヘラン』を見る限りではイランの革命防衛隊よりもモサドの方がやり方が汚い。

イラン人の俳優が良くて、 HOMELAND にも出てるナヴィド・ネガーバンとショーン・トーブがいい味を出してる。ナヴィド・ネガーバンもショーン・トーブも HOMELAND では果てしない悪者という感じで描かれていたが、『テヘラン』では理性的なキャラクターとして登場する。 HOMELAND では見られなかった渋いおっさんの色気を感じる。主人公の女性スパイのビジュアルはあまり好きになれなくて、イラン系のイスラエル人ということなので HOMELAND に出てたナザニン・ボニアディなんかだともっと良かった気がする。イランの人々は男女ともに美形が多い気がする¹。日本在住のイラン人女優サヘル・ローズも美人だと思う。

『テヘラン』のドラマ自体はテヘランではなくアテネで撮影されたみたい²だけど、テヘランという街にめっちゃ興味出てきた。街の遠景に雪の積もった山が出てくるシーンが何度かあって、中東といえば暑いところというイメージなんだけど、きっと寒くて乾燥して日本とは全然違う気候の国なんだろうと思う。イランといえば北朝鮮並みに閉ざされた国という印象があるが、ヨーロッパとの関係は悪くなさそうだし、日本とイランの関係も悪いわけではないはずなので、パスポートにイラン入国のスタンプが押されてその後のアメリカ入国時の審査がきびしくなることを覚悟すれば旅行できないわけではなさそう。死ぬまでに一度旅行してみたい。

"Your Computer Isn't Yours" という記事が先週バズってた。

sneak.berlin

概略を説明すると、 Catalina の頃から Apple が Mac ユーザーのアプリ起動ログを勝手に収集していたが、 Big Sur の公開日にログ集約サーバーがダウンしてしまい、そのせいで Mac を使えなくなる人が続出して問題が発覚したというもの。 Rebuild の Episode 288 で触れられているので興味がある人は聞いて下さい。

この記事については日本語の翻訳もあってはてブで 500 ブックマークくらいついていたが、どうも機械翻訳されただけのようだったし、一部訳が違うのではと思われるところがあったので自分でも訳してみた。訳を原著者の Jeffrey Paul 氏にメールで送ったので恐らくそのうち本家に日本語訳が追加されると思う。

2020-11-25 9:16 追記

日本語訳追加してもらいました。

sneak.berlin

起きていることをまとめると以下のような感じだ。

1. Apple は Mac ユーザーのアプリ起動データを IP 付きで Apple のサーバーに集めている（ログ送信）
   • 各アプリの署名有効期限チェックやマルウェア対策のためということになっている
   • Mac から Apple への通信は暗号化されていない
     • ISP や CDN （ Akamai ）、ネットワークを盗聴している他人が内容を確認可能
   • この通信はユーザーが自分の意思で無効化できない（「Mac解析を共有」をオフにしても送信される）
2. Mac （特に Big Sur でしか動かない Apple Silicon Mac ）を使いたければ利用ログ送信を甘受するしかない
   • Big Sur から、上述のログ送信や Apple 製のアプリは VPN やファイヤウォールを無視するようになった
   • OS の挙動を変更しようとすると Mac が起動しなくなる
3. iCloud Backup は iMessage の秘密鍵も一緒にバックアップするので Apple がメッセージの内容を読むことができる
   • 自分自身が iCloud Backup 利用していなくても、メッセージの送信相手が iCloud Backup を使っていると自分が送ったメッセージが iCloud 上に保存される
4. Apple はプライバシー保護を売りにしながらユーザープライバシーをなおざりにしている
   • iMessages/iCloud Backup のバックドアを放置している
   • 過去にアプリ開発者には HTTPS を強制しながら自分たちは OCSP の通信を平文で行っている
   • ログ送信の件について対応を発表したが、対応時期を明確にしていない

その結果、以下のような状況に陥ることが懸念されている。

• Apple が集めている情報は NSA や FBI に筒抜けになる
  • Apple はアメリカ軍の諜報機関や FBI にユーザーログデータなどの閲覧を令状なしで認める協定を結んでいる
  • iCloud Photo や iMessage の内容を Apple だけでなく軍や FBI も見られるようになっている
• ユーザー保護を隠れ蓑に Apple が力を増大させる
  • マルウェアから守る、を大義名分にして、ユーザーがどのアプリを動かせるかを Apple がコントロールできる可能性がある
  • 原理的には Apple が気に入らないアプリを起動できなくしてしまうことが可能

モバイルアプリの利用状況の収集は多分いろんなアプリがやっている。 Mac で Apple が集めている程度以上の情報を集めているアプリも多いだろう（位置情報を取得しているアプリなど）。なので最初この件については過剰に反応しすぎなのではないかと思っていたが、よくよく考えてみると自分の感覚の方が麻痺していたのかもしれない。アプリの利用履歴を IP アドレス付きで送るということは、どこで何をしているかがアプリ開発者に筒抜けだ。そしてそのログを公権力が自由に閲覧可能だとしたらいい気持ちはしない。

アプリと Apple の場合で決定的に異なるのは、アプリはそのアプリが起動している間（あるいはバックグラウンドでのログ送信を許可されている間）だけログを送信するが、 Mac に関して言うとずっーっと起動しっぱなしで使い続けるものなので、ログデータからユーザーの行動履歴・生活様式がわかってしまう。地図アプリで検索した場所の情報も送られていたということなので、 Jeffrey Paul 氏が書いているように、その人がこれから行く予定の場所もわかってしまう。

GDPR や様々なプライバシー保護は、アプリを作りサービスを運営する側としては正直厳しいなと思うところはあるけど、 Apple がアメリカ軍と結んでいる PRISM のような取り決めが存在すると、様々な個人情報が政府機関に流れてしまって、アメリカのサスペンスドラマのように個人の位置情報を携帯の使用履歴からいとも簡単に割り出せるようになってしまう。それはやはり恐ろしい世界だ。

プライバシーの侵害のみならず、プラットフォーマーである Apple の匙加減次第で、ユーザーが使えるアプリが決まるという状況も好ましくない。たびたび iOS の App Store で起こる Apple の恣意的な審査基準改変などはその一端だ。 Hey の件で Apple とやり合った DHH は痛烈に Apple を批判するとともに、かつて邪悪な Microsoft に対抗するための救いとも言えた Apple が以前の Microsoft 以上に邪悪になってしまったのが嘆かわしいと Twitter に書いていた。学生の頃、 Mac を広める活動をやって大学のクラスの半分の同級生のラップトップを Mac にしたというエピソードや、 Rails の開発でも Mac を激推ししたという話は胸熱だった。応援してきた Apple が Evil になってしまい、人一倍残念に思っているのだろう。

That's a formative experience! To have Apple be the escape pod from Microsoft and Windows. I spent so much effort in the early days evangelizing them because of that. Converted half my university class to Macs. Pushed it hard with Ruby on Rails. Team Apple through and through.

— DHH (@dhh) November 18, 2020

Apple はかつて "The computer for the rest of us" というコピーで Macintosh を宣伝していた。しかし今日、 Mac は彼らのコンピューターになってしまったのだ。

インデックスページをいじって各カテゴリーの最新記事 4 件を配置するようにしてみた。最近の個人サイト復興ブームでみなさんインデックスページを工夫されているのを見ていて真似したくなってやった。

昔ながらのブログだとインデックスページというのは最新の記事 10 件くらいが表示されていて、「次へ」を押すと古い記事が出てくるという構成になっている。以前のこのブログもそうだった。

しかし自分自身が他人のブログで「次へ」を押して次々に記事を読んでいくということをやった記憶がほとんどない。自分のブログでだって何か目的があって特定のキーワードで検索したあとに引っかかった記事を読むという感じなので、時系列に本文とセットで記事が 10 件ずつ表示される UI というのは意味をなしていないと思った。そもそもインデックスという名称なのに最近の記事数件しか表示していないのはおかしい。インデックスというからにはすべての記事の目次になるべきだ。

このブログはカテゴリーがあるので、サイトマップを作るとするとこんな感じになると思う。

+----------+        +------------+        +-----------+
|          |        |            |        |           |
|   Blog   +---+--->+  Category  +------->+   Entry   |
|          |   |    |            |        |           |
+----------+   |    +------------+        +-----------+
               |
               |
               |    +------------+        +-----------+
               |    |            |        |           |
               +--->+  Category  +---+--->+   Entry   |
                    |            |   |    |           |
                    +------------+   |    +-----------+
                                     |
                                     |
                                     |    +-----------+
                                     |    |           |
                                     +--->+   Entry   |
                                     |    |           |
                                     |    +-----------+
                                     |
                                     |
                                     |    +-----------+
                                     |    |           |
                                     +--->+   Entry   |
                                          |           |
                                          +-----------+

第一階層がインデックスページで、第二階層がカテゴリートップ、そして各記事がある。なのでインデックスページは二階層目の一覧ページになっているのが望ましいはずだ。しかし伝統的なブログはカテゴリーという記事をまとめる概念がありつつも、インデックスページから各記事ページへ直接遷移するのが主な導線だった。常に最新の記事が時系列順に並んでいるだけでは味気ないし、常連の読者ではないコンテキストを知らない訪問者には不親切だろう。

しかも SNS の隆盛で個人のブログのインデックスページが参照される機会というのはとんとなくなってしまった。個人が書いたブログ記事は SNS 経由で読まれ、個別記事だけが読まれる。インデックスページやトップページが読まれることはほとんどない。 SNS でシェアされている URL をクリックして個別記事を読んで、それ以上そのブログのほかの記事を読むことなく離脱してしまう。前後のコンテキストは無視して、一つのコンテンツだけがつまみ食いされてしまう。そんな流れにあらがいたいと思った。

これまで関連記事を記事下に表示するなどやってきたが、気に入っていくつか記事を読んで「ホーム」（ = インデックスページ）を訪れたユーザーがもう少しブログを深掘りしてみたくなるようにインデックスページを各カテゴリーの最新記事一覧とするようにしてみた。このブログは現在カテゴリーが 13 個あるので、それぞれから 4 件ずつ記事を取得すると 52 記事になる。全カテゴリーからまんべんなく 4 記事ずつ取得して表示するのは簡単なようで結構難しい。普通の SQL ではできない。 OR マッパーではまず無理だろう。

いろいろ調べてみた結果、 MySQL では GROUP_CONCAT というのが使えそうだった。以下のような SQL を書いた。

select entries.id
from entries
inner join (
  select
    category_id,
    GROUP_CONCAT(id order by created_at desc) as entry_ids,
    max(created_at) as last_created_at
  from entries
  where entries.draft = false
  group by category_id
) as grouped_entries
on grouped_entries.category_id = entries.category_id
and FIND_IN_SET(id, entry_ids) between 1 and 4
order by last_created_at desc, entries.id desc;

GROUP_CONCAT と FIND_IN_SET という関数を組み合わせることで、各カテゴリーから作成日の降順に記事を 4 件ずつ取得できた。このクエリでは記事 id のみ取得して、もう一回 DB に記事を取得するクエリを ActiveRecord で投げる。 ActiveRecord でクエリを組み立てるときは N+1 が起こらないように関連テーブルを JOIN する。

query = <<~SQL
  select entries.id
  from entries
  inner join (
    select
      category_id,
      group_concat(id order by created_at desc) as entry_ids,
      max(created_at) as last_created_at
    from entries
    where entries.draft = false
    group by category_id
  ) as grouped_entries
    on grouped_entries.category_id = entries.category_id
    and find_in_set(id, entry_ids) between 1 and 4
  inner join categories on categories.id = entries.category_id
  order by last_created_at desc, entries.id desc;
SQL
entry_ids = ActiveRecord::Base.connection.select_all(query).rows.flatten
entries = Entry.includes(:category, :user, :tags, :comments).where(id: entry_ids)

PostgreSQL のときに最初に取得した entry_ids の並び順通りに結果が受け取れるかは怪しいが、 MySQL の場合は一回目のクエリで取得した id 順に各レコードが ActiveRecord のクエリ結果として取得できた。あとはこれをカテゴリーごとにグルーピングして View でよろしくやれば良い。

なお各カテゴリーはカテゴリー内の最新の記事の作成日で降順ソートするようにしている。例えば現在のインデックスページの最下部には音楽カテゴリーがあるが、これは音楽についての記事を最後に書いたのが一年以上前だからだ。もしいま音楽の記事を書けば音楽カテゴリーがトップに浮上するようになっている。

見た目に関しては各カテゴリーの記事最新一件は大きなサイズで表示している。最も最近書かれた記事なのでより多く人の目に付いた方がよいだろうという考えだ。またすべての記事にサムネイルというか、アイキャッチ画像を表示するようにした。画像がない記事に関してはデフォルトのサイトアイコン画像を表示するようにしている。やっぱり視覚的に情報を捉えられるのは重要だ。画像がごちゃごちゃ表示されるのを嫌う人もいるかもしれないが、テキストだけでは人間の認知というのはどうしても追いつかない。

あわせて今回、インデックスページの冒頭部にこのサイトについての説明文を載せることにした。ながしまきょうさんや r7kamura さんがやっているののパクりだ。伝統的なブログのインデックスページは初めて訪れた人のことを無視しすぎていたと思う。そのブログ自体について説明するページがあるブログは少ない。最初の記事でブログを始めた経緯みたいなことが書かれたきり、そのブログは何なのか、誰が書いているのかが書かれることは希だ。きちんとブログについての説明ページと著者についての説明ページがあっても、左右のサイドバーやトップのナビゲーションの端っこに押し込まれて見られることはない。これではいけないだろう。というわけでインデックスページの一番目立つ位置にブログと自分自身の簡単な紹介を入れた。

ブログはなぜ衰退したかを考えてみると、 Facebook や Twitter の隆盛はあるにせよ、ブログ自体に初めて訪れた人に読まれるための工夫が欠けていたのだと思う。誰も自分のブログの継続率を計測したりコホート分析したりはしない。読者が前後の記事を読んでいることを前提に書かれた記事やサイト構成では初めて訪れた人はどうやっても離脱してしまう。特に書き手が芸能人でもない一般人の場合はなおさらだ。誰も RSS フィードを購読していないし、ほとんどの読者は初めて訪れる人なのだから、そういう人たちが読んでブログのテーマや著者の人となりが分かる構成にしていかなければならないのだと思う。でないと SNS でたまにバズったときだけ読んでもらえる、ソーシャルメディアの肥やしにしかならない。

この新しいインデックスページが正解なのかどうかは分からないが、ブログ衰退の流れにあらがっていきたい。