note を捨てて個人ブログをやれという提案
「捨てる」とは言い過ぎかもれないが，note で記事を売って暮らす方々が note から離れるのは難しい一方で，「お手紙」を貰った note 運営が彼らを切り捨てるのは至極かんたんである．それはすなわち「内容証明」だったり「開示請求」だったり「お願い」だったりするかもしれないが，一個人ならまだしも私企業として法的根拠のある文書をただしく丁重に処理・管理するのは骨が折れる．こういう事態に直面したプラットフォーマーは，その矜持にかけてユーザに対して真摯に奉仕しクレーマーに毅然とした対応を取るのか，あるいはコストを天秤にかけて "臭いものに蓋をする" 精神で要求を飲んだ上で懸念となったユーザをBANするか，どちらかを選ぶことになろう．
前提
令和時代も４年目となった２０２２年，「ただしく在る」だけでもそれこそ膨大なコストがかかるし，少しでも「ただしくない」姿を見せた日には瞬く間に社会的な「人権」を貪り食われるようになった．それも，姿が見えない有象無象の集まりによって．
単なる個々人が偶発的に同じ方向にエネルギーを向けた結果としてそうなってしまった…のなら致し方ないと納得しようもあろう．多くの個々人は「ただしく在るべき」という圧力もなく，ときには「ただしくない」ことも行なってきただろうが，集団として同じ方向を向いて同様に行動することでその扱いが透明化されてきた．ちょうど雀や鰯，シマウマやヌーなどが群れるのと同様に，時折は運の悪い個体が犠牲となりながらも他の個体群は生き延びるあの仕組みが機能している．これはすなわち，ただしく在ろうとして実際にただしく在ることができてそこから恩恵を受けているような「強者」に対して，そうなれなかった「弱者」の集団が無意識的に防衛機制を働かせた結果起きている事象といえよう．
本稿では，防衛機制の正体や詳細，その克服の方法について述べない．また，集団の無意識的防衛機制を扇動している「害人」についても言及しない．それは確かにあるし，確かに居るのだが，それに触れて解説することで彼らのエネルギーの矛先を向けられるリスクをあえて負う必要はないと考える．代わりに，そのエネルギーを向けられてしまっても被害を最小限に抑えるための方法，すなわち「個人ブログをやれ」という提案をする．
個人ブログをやれ
パソコンやケータイを持つのも珍しかった時代からすでに四半世紀が経つ２０２２年，老若男女誰しもが片手の指先でテキストを認め，全世界的に発信できるようになった．できるといっても，独力ではなく「プラットフォーマーの提供する大船にフリーライドする形で」である．
Note / Twitter / Facebook / はてな / LINE / etc. が俺の居場所だ！と宣言して憚らない新世代人類も増えてきているように思うが，「お気持ち」最優先の集団的私刑トラップがそこかしこに設置された魔女裁判復古時代において，明日あるいは今すぐにでもその場所にアクセスできなくなるかもしれないリスクは高まり続けている．
これは直ちにフリーライドをやめよと主張するものではない．むしろ複数箇所に居場所を持ちリスクを分散させることは推奨したい．が，それら以外にも「本当に自分の制御下にある安寧の場所」を持つべきだ．言論の自由的な意味でのシェルターと言えるかもしれない．これを持たないまま，プラットフォーマーの"胸先三寸"でいつだって口をふさがれてしまうかもしれない息苦しさに怯えるべきではない．自分だけが自分の責任で管理する個人ブログの復興こそが，キャンセルをキャンセルで対抗するような血みどろの時代を生き抜く術であると私は確信している．
じゃあどうすれば？
極力プラットフォーマーに依存せずに個人的な発信の場を確保するには，以下の方法が考えられる．
自宅にサーバを設置する
レンタルサーバを借りる
……多くの人々にとってブログ等で情報発信を行なう動機とは〈写真や文字を通じて（気軽に）情報を見て/聞いてほしい〉程度のものであると思われるが，キャンセルのリスク回避志向を加味しても，上記の手続きを踏むのは「割りに合わない」と感じる方が大多数だろう．ここからさらに快適なコンテンツ作成環境も整えねばならないわけだから，敢えてこの茨の道を進むのは極少数派であろうと予想できる．構造的に致し方ないことだが，「自分はキャンセルされない」という正常性バイアスを信じて現状維持を継続することになる．
が，ここからが本稿のキモである．（１）サーバを借りる必要がなく（２）プラットフォーマーの干渉を受けず（３）コンテンツ作成環境も整えやすい という三拍子揃った第三の選択肢を用意することができたらどうだろうか？それこそが GitHub Pages である．
GitHub Pages が全てを解決に近づける
Pages とは，〈2018年に Microsoft が買収した世界的な "設計図共有サイト" であるギットハブ〉もとい GitHub が提供しているサービスの一つであり，GitHub 上のリポジトリから HTML / CSS / JavaScript のファイルを直接取得してウェブサイトを公開する静的サイトホスティングサービスである．
「静的サイトホスティング」と云われてもようわからんと思われる方のために解説すると，Twitter や note のようにテキストデータを預けるのでなく，テキスト含めたページコンテンツをどのように表示するかを決める 〈Web ページを構成するデータ群〉を丸ごと任せるサービスである．つまり，ずっと自由度が高く通報・BAN等の拘束も受けにくい（≒受けない）が，その分だけ自分の責任・負担が大きくなる仕組みだ．
とはいえ，自前でサーバを維持・管理するよりもずっと気軽に使えるだろう．こうしたホスティングサービスは他にもいくつもの同様なものがあるが，その中でなぜ GitHub Pages を使うべきなのか，以下に説明する．
(1) サーバを借りる必要がない
いわゆる PaaS と呼ばれるクラウドサービスであるため，いちいちサーバ管理を意識する必要がない．「ビルド」したデータを「デプロイ」して Pages に置くだけで，あとは放っておいてなんの問題もない．
また他のサービスと異なり，Pages を使うためには GitHub のアカウント作成が必要となるだけで，支払い情報の入力は必須ではない．これは GitHub の基本サービスがほとんど無償で利用することができ，Pages もそこに含まれているからだ．かたやクレカ情報を渡す必要がある GCP / AWS でサーバを借りるのとは，いくら無料枠があるからと云っても，心理的ハードルの高さが全く異なると言えよう．
(2) 干渉されにくいプラットフォーム
GitHub が提供するサービスの主たる使途としては「ソースコードの共有」「Issue や PR を通じた継続的な改善」「開発者同士のコラボレーション」が挙げられる．インターネットを通じて，これらの営為を国境や言語を問わず，世界中から誰でも誰とでも行なうことができるようになった．このような経緯もあり，GitHub は全世界の多くの人々から「公的なインフラ」であると見做されている．そのため，高い倫理観と重い責任を自覚することが期待されており，おいそれと強権的 Evil プラットフォーマー仕草を仕出かすことはないと考えられる．
つまり，それが第三者の権利を明確に侵害しているものでない限り，GitHub が積極的に削除したり閲覧できないようにしたりといった危険はない．もちろん，検索しても表示されないとかいつまで経ってもアカウントが凍結されたままということもない．GitHub が重きを置くのはあくまでソースコードの共有という「公共の利益」であって，ユーザの主観的なお気持ちは考慮されない．ここが他のソーシャルなプラットフォーマーたちとは一線を画す点である．
(3) コンテンツ作成環境
いままでは知識と経験がある一部の人々だけが，ここまで述べてきた GitHub の提供する恩恵に預かることができていた．裏を返せば，素人にはほとんど何も与えられていなかった（これは IT に関わる技術者であれば皆が持つ残念でもないし当然の価値観ではある）．しかし誰しもが GitHub Pages で個人ブログをやるには，どうにかしてこのギャップを乗り越えねばならない……
「お手紙」に関する危機意識を抱いてから早いもので一ヶ月が経とうとしているが，この度ようやくこの問題を解決しうるアプローチを提供する目処がついた．それは，新進気鋭の静的文書ジェネレータである Docusaurus を使う方法である．探せば他にもいくらかアプローチはあろうが，もっともこれが良いと考える理由も次で説明しよう．
具体的な方法
上記リポジトリのREADMEに具体的なやり方は書いてある．かいつまんで説明すると
エディタを用意する（VSCode を推奨）
Node.js v16.x の実行環境を整える
上記リポジトリを `git clone` してエディタから開く
`yarn install` を実行して，必要なパッケージを揃える
`yarn dev` を実行すると新たにタブが開く→それでプレビューしつつ，文書を書く
`yarn build` してローカルで問題が出ないことを確認する
`gh-pages.yml` を自分の環境に合わせて修正する
リポジトリを GitHub に push する（このとき，自動的にGitHub Pages でデプロイまで行われる）
という流れである．エディタと Node.js 実行環境さえ用意できれば，あとは記法に従って文書を作成するだけで良い．GitHub Pages にデプロイする煩雑な設定やアプリケーションの構築は，すでに整えられているからだ．もちろん，多少は自分好みにカスタマイズできるような遊びは残してあるし，もっと知識が身につけば，公式のドキュメントを参考にしつつ自分流に拡張する余地さえある．
採用したフレームワークは，Docusaurus というFacebook もとい Meta 社の OSS チームが開発している静的サイトジェネレータ (Static Site Generator) である．SSG に対応したフレームワークは，有名どころでは Next.js , Gatsby.js などが挙げられるが，これらは広く汎用的に使われることに重きをおいており，あまりにも自由度が高い．そのため，なんでも自分で作る必要があるのだが，それを実現するにはあまりにも工数がかかりすぎてしまう．
一方で Docusaurus は，〈数多の OSS プロジェクトたちが時間をかけずにドキュメントを作成できること〉を目標に作られている．はじめから雛形が提供されており，特にこだわりがなければ，一片のコードさえ理解せずとも文書さえ書けば自分だけのサイトが手に入るような仕組みとなっている．
また，文書作成の記法においては GFM を採用している．すなわち，GitHub が採用している Markdown 記法と同様の文法でもって文書をつくることができる．note 等の WYSIWYG エディタに慣れきった諸兄にはこれを機に Markdown による文書構造化手法を学んで貰う必要はあるが，そこはご容赦いただきたい．
オリジナルであるバニラ版の Docusaurus と異なる部分もある．具体的には，バニラ版で実装されていなかったソーシャルメディアボタンを設置していたり，前後に空白行を挟んだ URL 行を認識して埋め込みウィジェットに書き換えたりといった改善点が挙げられる．つまり，本家では弱点であったシェア機能を補ってあり，ドキュメントではなくブログとして使いやすくしてある．
まとめ
最近になっても深刻に脅かされつつあるインターネット言論空間を守るため，個人ブログをやれという提起を行なった．サーバを導入・維持・管理するのが難しいという事情を勘案し，GitHub Pages を使って問題が解決できないか検討した．その結果，「コンテンツ作成環境」さえあれば良さそうという結論に至り，それを実現するためのリポジトリを作成・公開した．最後に，具体的なアプローチを概説した．
本稿が，何者にも脅かされない自由なインターネット言論空間の保障に資するものになることを願っている．
この記事が気に入ったらサポートをしてみませんか？