2026/06/10(水)今日のサーバー整備の話と、サイト改築を始めた話。

今日のサーバー整備

nginxの共通設定にgzipの設定を入れて転送量を削減した。

この設定を入れただけ。

    gzip on;
    gzip_types
        text/plain
        text/css
        text/javascript
        text/xml
        application/javascript
        application/json
        application/xml
        application/rss+xml
        application/atom+xml
        application/font-woff
        application/octet-stream
        image/gif
        image/png
        image/jpeg
        image/gif
        image/webp
        image/svg+xml;

nginxとApacheのリバースプロキシについて色々確かめた。

nginxからApacheにリバースプロキシしてる時、nginxを前段のTLS終端、Apacheを後段にしているときにApacheの中でリダイレクトが走るとhttpsが壊れることがある現象を確認した。

これはディレクトリに対しhttps://example.com/hogeのようにアクセスするとhttp://example.com/hoge/に301リダイレクトがかかるのだが、どうもこの時にスキーマが引き継がれずHTTPになってしまうようだ。初めからhttp://example.com/hoge/としてアクセスすれば問題ない。

またこの現象が起きると証明書があるのにエラー表示になることも確認しているが、サブ機やスマホでは起きないようにも見えるので、この端末の証明書が何かしら変になっている可能性がある。キャッシュクリアしてもhttp降格が起きると再発するので、原因はよくわかっていない。GPT-5.5に聞いたもののハルシネーションしか得られず、ググってもnginx→Apacheの情報はほとんど得られなかった。多分ニッチな構成なのだろう。

さくらのレンタルサーバーもnginxからApacheに繋いでいるので、これをどうやっているかが知れれば改善の手掛かりになりそうだが、知る術がないので何ともだ。まさか聞くわけにもいかないし…。

そういえばさくらのレンタルサーバーではSNI SSL[1]が使われていると聞くので、これを使えば上手くいくのかもしれない。

SSL/TLS接続のはじめに、クライアントはSSL/TLSのサーバから(サーバとCAの)証明書を受け取り、証明書の改ざんされていないことなどを確認する。サーバ証明書にはホスト名が書かれており、それが今接続しようとしているホスト名と一致することをクライアントは確認する。そうでない場合、なりすましや中間者攻撃の恐れがあるため、クライアントはユーザに警告をする。ユーザの責任で証明書を信用し、警告を迂回することができるアプリケーションも存在する。

というかWikipediaに上記の記述があったので、これのせいかもしれない。問題が起きているドメインはlycolia.infoで、元々さくら側で証明書を設定していたのでHTTPに落ちたときにその証明書が引っかかってエラーになっているとかはあるのかも?

さくらのドメインであるsakura.ne.jpを踏むとhttpでもhttpsに転送されるのと、ひょっとしたら類似の現象が起きているのかも…?いや、わからないが…。

サイト構成の変更をし始めた

このサイトの構成がイケてないなという思いが強くなったのでやることにした。

まずlycolia.infoが単なるLPに成り下がっていることが勿体なかったので、このドメインの傘下にコンテンツを増やすことにした。

一つ目はtool.lycolia.infoのドメインを廃止して、lycolia.info/tool/にぶら下げた。これはそもそもドメインを分割してやるようなサイトではなかったし、コンテンツの一部でいいと思ったからだ。

二つ目はこのブログにあったリンク集をlycolia.info/link/にぶら下げた。そもそも、本質的にサイトトップではない、このブログにリンク集があることに長らく違和感があったので丁度よかった。また移設に伴い紹介コメントも多少変更しているほか、元々のリンクが間違っていたなどもあったので、そのあたりも修正している。

そして今後は自己紹介などもブログから剝がして移動したいと思っている。ただ今のところすべてサーバー内からのHTML手打ちで、厳しさを感じるので、将来的にはCMSにしたいとも思った。

少なくとも今今は自宅サーバーである以上、家の中にいれば直にファイルをいじれるので問題はない。出先で書き換えたくなった時に困るくらいだ(一応頑張れば出先からもいじれなくはないが…)

サイト構成の変遷

本日リアルタイムでサイトを書き換えていて本番Hot Module Replacementみたいなことになっていた風景の一部を残しておく。

これが元々の状態。

改築途中の状態、なんか色々アレなことに…。

そして一旦本日の作業が終わった状態。また明日以降ちょいちょい直していくと思う。

移設したリンク集

移設前 移設後

見た目的には大きく変わり映えしないどころか、まともにスタイルを当ててないので殺風景だが、その辺りは追々どうにかしていこうと思う。

これでも一応レスポンシブデザイン、しかもモバイルファーストで作っているのでスマホで見たときの見やすさは向上している。

何せフルスクラッチでHTMLを手書きして、置換ではなく手作業で移設を行ったので移設するだけで時間が溶けてしまったので、今日はこんなところといった感じだ。


  1. Server Name Indication SSL

2026/06/09(火)TTRSSの最新版が使えなかったのでFreshRSSを試してみたけどイマイチだったログ

さくらのレンタルサーバーにTiny Tiny RSSを建てるでも紹介したTTRSSだが、現在の最新版だとレンタルサーバーでの利用は恐らくできなくなっている。

そこで代わりとなるフィードリーダーを探したところ、FreshRSSが軽量でよさそうだったので、今回自宅サーバーに導入してみたログを書く。

※さくらのレンタルサーバーへの導入もできると思うが、試していない。

確認環境

nginxからApache2へリバプロしている構成。

Env Ver
OS Ubuntu 24.04.4 LTS
nginx 1.26.1
Apache2 2.4.58
PHP 8.3.31

導入手順

私のサーバーでの導入ログなので一般化しづらい内容だが、要点が理解できればさくらのレンタルサーバーにも設置できるはずだ。

  1. FreshRSS本体の入手と設置
    cd /var/www/path/to
    wget https://github.com/FreshRSS/FreshRSS/archive/refs/tags/1.29.1.zip
    unzip 1.29.1.zip
    mv FreshRSS-1.29.1 feed_reader
    sudo chown -R www-data:www-data feed_reader/
    sudo mysql -u root
    
  2. ユーザーとDBの作成
    CREATE USER 'freshrss'@'localhost' IDENTIFIED BY 'パスワード';
    CREATE DATABASE freshrss CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
    GRANT ALL PRIVILEGES ON freshrss.* TO 'freshrss'@'localhost';
    exit
    
  3. nginxにリバプロ追加、apacheにvhost設定追加、ddnsスクリプト追加、DNS反映
  4. https://freshrss.example.com/など、設置したURLにアクセスする
  5. 非常に親切なウィザードが出てくるので、一般的なPHPスクリプトのインストールと同様に進める
  6. インストールが完了するとログイン画面に遷移するのでログインする
    • 遷移しなかった場合何かが間違っているので最初から全部やり直したほうがいい
  7. ログインするとメイン画面が表示されるので、左上の「購読フィードの管理」からフィードを登録する。TTRSSから乗り換える場合は事前にOPMLをエクスポートしておくと移行がスムーズだ
  8. フィードを登録し終えたら「フィードを更新」を押すとフィードが更新される。TTRSSではコマンドを蹴る必要があるのでこれは便利だ
  9. これでフィードが出てくればOK
  10. 最後に定期的にフィードを読ませるためにCRONを設定する
    10 * * * * www-data php -f /var/www/path/to/FreshRSS/app/actualize_script.php > /tmp/FreshRSS.log > /dev/null
    

FreshRSSを使ってみての感想

TTRSSと比べるとかなりシンプルというのが一つ目の感想だ。フィードリーダーとしての機能しかなく、GoogleReaderのクローンとして作られたTTRSSと比べると非常にシンプルだと思った。

正規表現によるフィルタといった高度な機能はなく、画面も今どきのスタイリッシュな感じに見えた。悪く言えばスカスカというか。

結論としてはTTRSSの方が好みだったので、私は古いTTRSSを使い続けることにした。

あとがき

TTRSSのGitHubを見た感じ、去年の10月9日にはLAMPスタック、いわゆるCGIとしての動作を打ち切っていたようだ。今使えている場合は問題ないと思う。

しかし、Androidアプリも2025-11-01でサポートが終わり、既にAPKの配布すらされていないため、Androidアプリは時期に使えなくなるかもしれない。

自宅サーバーに入れるにもDockerベースの運用が基本になり、直接起動は厄介そうな気配を感じた。軽い気持ちでチャレンジしたらサーバーのメモリを食いつぶし、まともに操作できなくなった。しかしこんな状態でもPrometheusとNode Exporterは仕事をしてて偉いなぁと思うのだった。

個人的にTTRSSはレンタルサーバーで動く軽量さがありつつも、正規表現によるフィルタでアフィリエイト記事を弾いたり、便利なAndroidアプリがあったり、UIも使いやすかったり、中々重宝していたが、同時に以前からAndroidアプリが優勝から無償になったり、配布場所が変わったり、更新が放置されたり、本体にも破壊的変更が入ったりで、非常に変革の多い体制を危ぶんでいた。

そして今回の出来事を見るに、個人的にレンタルサーバーで使っていた人や、Dockerが嫌な人にとっては厳しい状況になったと思った。とはいえ、今すぐに使えなくなるわけではないので、今運用している人はそのままでいいと思った。

私は結果としてFreshRSSでは満足できなかったのでTTRSSに戻ることにした。なおバージョンを確認しようとしたら「Tiny Tiny RSS vUNKNOWN (Unsupported) © 2005-2026 Andrew Dolgov」とあったので、どうも私が使っているもののバージョンは不明だった。

さくらのレンタルサーバーにTiny Tiny RSSを建てるにはコミットハッシュを書いていたので、おそらくこれをそのまま使い続けているのだと思う。

2026/06/08(月)FluentBitでSystemdのログをLokiに送ってGrafanaで見れるようにし、ついでに設定をYAMLにした

更新日:
投稿日:

本記事は自宅サーバーに雑に監視を入れた時にやったこと先日の自宅サーバー移転に対し追加対応をしたの続きである。

今回はSystemdのログをFluentBitで拾ってLokiに送ってGrafanaで見れるようにしたログ。

AWSやDockerなどを使った情報は散見したが、バイナリをネイティブ環境で動かしている情報や、複数のデーモンのログを収集する方法が見当たらなかったのでちょっと苦労した。GPT-5.5も正確なことを言わないので真面目にリファレンスを読んだりググったりして何とかした。LLM頼みも限度があるね。

確認環境

Env Ver
OS Ubuntu 24.04.4 LTS
Fluent Bit 5.0.6
Loki 3.5.9
Grafana 12.1.1

設定内容

今回は前回までのconfig設定をYAML設定に全面移行した。基本的にはデフォルトのconfigファイル+私が使っているI/Oの移植である。Lokiの待ち受けポートが9100であると仮定して進める。

各設定については公式マニュアルを参照のこと。

service:
  flush: 1
  log_level: 'info'
  parsers_file: 'parsers.conf'
  plugins_file: 'plugins.conf'
storage:
  metrics: 'on'
pipeline:
  inputs:
    - name: 'systemd'
      tag: 'systemd'
      db: '/var/lib/fluent-bit/systemd.db'
      systemd_filter:
        - '_SYSTEMD_UNIT=adiary.service'
        - '_SYSTEMD_UNIT=mastodon-web.service'
        - '_SYSTEMD_UNIT=mastodon-sidekiq.service'
        - '_SYSTEMD_UNIT=mastodon-streaming@5001.service'
    - name: 'tail'
      tag: 'nginx.access'
      path: '/var/log/nginx/access.log'
      parser: 'json'
      db: '/var/lib/fluent-bit/nginx-access.db'
      refresh_interval: 5
    - name: 'tail'
      tag: 'nginx.error'
      path: '/var/log/nginx/error.log'
      db: '/var/lib/fluent-bit/nginx-error.db'
      refresh_interval: 5
    - name: 'tail'
      tag: 'apache.access'
      path: '/var/log/apache2/access.log'
      parser: 'apache2_vhost'
      db: '/var/lib/fluent-bit/apache_access.db'
      refresh_interval: 5
    - name: 'tail'
      tag: 'apache.error'
      path: '/var/log/apache2/error.log'
      db: '/var/lib/fluent-bit/apache_error.db'
      refresh_interval: 5
  outputs:
    - name: 'loki'
      match: 'systemd'
      host: '::1'
      port: 9100
      labels: 'job=systemd'
    - name: 'loki'
      match: 'nginx.*'
      host: '::1'
      port: 9100
      labels: 'job=nginx, log_type=$TAG[1]'
    - name: 'loki'
      match: 'apache.*'
      host: '::1'
      port: 9100
      labels: 'job=apache, log_type=$TAG[1]'

PARSER: apache2_vhost

前回の記事で作った以下のパーサーを利用している。

[PARSER]
    Name        apache2_vhost
    Format      regex
                ^(?<host>[^ ]*) [^ ]* (?<user>[^ ]*) \[(?<time>[^\]]*)\] "(?<method>\S+)(?: +(?<path>[^\"]*?)(?: +\S*)?)?" (?<code>[^ ]*) (?<size>[^ ]*)(?: "(?<referer>[^\"]*)" "(?<agent>[^\"]*)")?$
    Regex       ^(?<vhost>[^:]+):(?<port>\d+) (?<remote_host>[^ ]*) [^ ]* (?<user>[^ ]*) \[(?<time>[^\]]*)\] "(?<method>\S+)(?: +(?<path>[^\"]*?)(?: +\S*)?)?" (?<code>[^ ]*) (?<size>[^ ]*) "(?<referer>[^\"]*)" "(?<agent>[^\"]*)"$
    Time_Key    time
    Time_Format %d/%b/%Y:%H:%M:%S %z
    Time_Keep   On

また前回の記事で作成したapache_errorというパーサーについては役に立たなかったので使わなくなった。標準で付いてるapache_errorも使えないし、apache2もイマイチ使えないので公式のパーサーは当てにしないほうがいいのかもしれない。

なおパーサーは旧config形式で記述している。これはとてもじゃないが書き換えてられないボリュームだったのとYAMLに対応させようとするとエスケープがだるそうだったからだ。config形式は今年でサポート外になるようだが、既存の設定のプリセットはすべてconfig形式でしか存在しないため、何とも先行きが心配だ。

サービスの修正

設定を.confで読んでいるので、ここを.yamlに変えてやる。

 [Unit]
 Description=Fluent Bit
 Documentation=https://docs.fluentbit.io/manual/
 Requires=network.target
 After=network.target

 [Service]
 Type=simple
 EnvironmentFile=-/etc/sysconfig/fluent-bit
 EnvironmentFile=-/etc/default/fluent-bit
+ExecStart=/opt/fluent-bit/bin/fluent-bit -c /etc/fluent-bit/fluent-bit.yaml
-ExecStart=/opt/fluent-bit/bin/fluent-bit -c //etc/fluent-bit/fluent-bit.conf
 Restart=always

 [Install]
 WantedBy=multi-user.target

インストールした当時は何故YAMLで書いても読んでくれないのか悩んでいたが、こんなところで指定されていた。しかも何故かパスが二重スラッシュになっていたので、そこも直しておいた。

FluentBitが上手く動いてなさそうなときのデバッグ方法

以下のコマンドを流すと動いているかどうかが分かる。なんかログが取れてなさそうだったり、Lokiに届いてなさそうなときに使える。

/opt/fluent-bit/bin/fluent-bit -i systemd \
           -p systemd_filter=_SYSTEMD_UNIT=mastodon-web.service \
           -p tag='host.*' \
           -o stdout

あとがき

なんか最近のソフトウェアのマニュアルって論理的に書かれすぎてて具体的にどう設定したらいいのかよくわからなくて困る。もう少し具体的な設定例とか書いてくれてもいいと思うんだ。

YAML configuration files are the standard configuration format as of Fluent Bit v3.2. They use the .yaml file extension.

Classic configuration files will be deprecated at the end of 2026. They use the .conf file extension.

しかしconfigは今年末でサポート外になるという話があるのにGitHubのリポジトリの設定ファイルは全部configで、果たしてこんなので大丈夫なのか…とIssueを眺めていたら、そもそも開発側もYAMLの仕様を余り解ってないような空気を感じたので、これは今年中は厳しいのではないか?という感じがした。

ひとまず私はキー名がkebab-caseからcamelCaseになってもすぐ対応できるようにメインの設定だけYAMLにしておいたが、Parserを直すのはエスケープが面倒などもあると思うので、なかなか大変だと思う。

あと個人的に不思議に思った部分としてoutputslabelsが配列ではなく、文字列だというところだ。

pipeline:
  outputs:
    - name: loki
      match: '*'
      labels: job=fluentbit, mystream=$sub['stream']

何でここは配列にしなかったのだろうか?

実際に以下の記述でラベルが機能しているので、おそらくこの構文がFluentBitのDSLとして機能していて、真面目に配列すると改修が大変とか、そういうのがあるのかもしれないなとは思った。

    - name: loki
      match: 'apache.*'
      host: '::1'
      port: 9100
      labels: 'job=apache, log_type=$TAG[1]'

ちなみに一番ハマったのはブログ執筆用に作っていたLokiのポートを書き換えたメモを基に作業していて、未来永劫FluentBitがLokiに疎通しなかったことである。

2026/06/08(月)駄文同盟の最初から現在までの登録状況を軽く調べてみた

更新日:
投稿日:

本記事は古のサイト探究~駄文同盟のID上位100サイトを巡り、今までのネット人生や自サイトの過去を振り返ってみるの続きの様なものだ。

今回は駄文同盟登録にしている全サイトを機械的に調査した結果を出していく。前回は全手動だったのできめ細やかな結果を出せたが、今回は機械集計なので大まかな傾向を書いてゆく。

調査方法としては以下のコマンドでスクレイピングしたものを正規表現で成形し、エクセルで集計している。

for i in $(seq 1 20457)
do
  dates=$(curl "http://www.dabun-doumei.com/data/${i}.html" | iconv -f SJIS -t UTF-8 | grep -e "登録日:" -e "更新日:")
  echo "No.${i} $dates" | tee -a "dabun-doumei-dates.txt"
done

年毎の登録件数

このグラフはその年ごとの駄文同盟への登録件数をグラフにしたものだ。

その年に初めて見つかった登録サイトと、その年最後の登録サイトの件数をカウントしているため、駄文同盟の登録を解除したサイトも件数に含まれている。

逆に年と年の継ぎ目に登録解除したサイトがあると、そこは空白になってしまう。結果として55件の空白サイトがあった。

基本的に2004~2008年あたりがピークといった感じで、2009年からは登録件数が大きく減っている。2004年も少ないのだが、2004/10/20がID:1の登録日であるため、開設直後かつ、年末まで二ヶ月半しかなかったことを考えるとこれは仕方ないだろう。

2010年からは割合にして7.19%と、前年の10.18%から一気に減少し、2014年まで減少が続く。2015年は前年比0.74ポイント増えていて、何があったのかちょっと気になる。

2017年に入ると登録数が200を切り、低位に推移していくものの、横ばいが続く。しかし2022年から減少傾向に転じ、2024年には3桁を割り込み、遂に80件にまで落ち込んでしまう。

駄文同盟自体の知名度が落ちていることや、既にメンテナスもされていないことも多分にあると思うが、駄文同盟の登録件数ベースで見るとも何とも悲しい数字だ。しかし今年は既に25件あるため、もう少し横ばいで推移する可能性もある。

とはいえ、この時代に個人サイトを新規に起こしたとして、従来のように駄文同盟や、それに類するサイトに登録する人も多くはないだろうから、時代の流れとして致し方ない部分もあるのだとは思う。

登録状況

このグラフは現在の駄文同盟の登録状況をグラフにしたもので、内訳としては以下の通り。

  • 更新あり=現在有効な登録があり、最低でも一度は登録を更新している(登録日時と更新日時に差異がある)
  • 登録解除=登録が解除されている(IDが消滅している)
  • 更新なし=現在有効な登録があるが、一度も登録更新されていない

つまり実に過半数のサイトが登録を解除しており、残ったサイトは全体の44.66%しかないことが分かる。その中で駄文同盟の登録後に一度でもサイト情報を更新したサイトの割合は76.97%だ。77%に丸めて考えると大半のサイトは何かしら一度は更新していることになる。

直近で更新があった時期

これは直近五年間で駄文同盟の登録情報を更新したサイトの件数を出している。

駄文同盟では一回も更新しなくても登録日=更新日であるため、5年以内に登録したサイトが必然的に含まれており、そこは除外していない。

頭のパーセンテージはIDの最大値に対して出しているため、あまり意味がないものになっているが、意外と更新しているサイトが多いことが伺えた。

集計データ

今回も前回同様、Google Spreadsheetに集計データをまとめている。また同様に以下に表も貼ろうと思ったが二万行以上あるため、今回は断念した。

2026/06/06(土)個人サイトWebオンリー めぐる市を見てきて

更新日:
投稿日:

本日ピクリエ[1]で開催されており、当サイトも参加している個人サイトWebオンリー めぐる市を見てきた感想。

このイベントでは参加サークルが一次創作、二次創作、その他に分類されているが、この記事ではその他ジャンルについての語りになる。

また本記事で行った調査は私が目で見た限りなので、漏れや誤りがある可能性もある。あくまで個人の感想であって、何かを批判したりするものではないことを先に断っておく。

トップページへの流入が凄く増えた

トップページというのはlycolia.infoのことだが、ここへのアクセスが爆発的に増えた。

ただピクリエはリファラを吐かないようで、実際にどの程度がピクリエなのかはわからない。さっきUTMパラメータ付きのURLを用意したが、開場が10時だったのに、書き換えたのが20時ごろの話なので、時すでにお寿司という感じはしている。

出オチした

Anubisを雑に設置したが、結果微妙だったので撤去した話でも少し触れているが、私はこの日このイベントがあることを知っており、サイトを生かしておかないとならないはずだったのに、会期中にAnubisの画面が出したいがために8時くらいからAnubisの導入試験を行っており、結果的に10時~13時半までサイトが断続的にダウンしていた。

一番アクセスが集中する時間にサーバーダウンを伴うメンテナンスをするとは愚の骨頂で、本末転倒である。

自分が想像していた「その他」サイトはそこまで多くなかった

サークル分類が一次創作、二次創作、その他とある以上、個人的には「その他」には日記や技術、DIY、写真などいわゆるサブカル系ではないものを期待していたが、その期待にそぐうのは半数の22サークル中11サークルだと感じた。個人的な感覚としては、小説や同人誌の頒布が中心のサイトは「創作寄り」に見えたため、自分が期待していた「その他」とは少し違って見えた感じだ。

とはいえ、ジャンル分けには各サークルなりの事情や判断があると思うので、外から見ただけであれこれ言うものでもない。

サイト制作の手段が変わってきている

上の図は今回その他ジャンルで公開されていた22サークルで使われていた技術を調べたものだ。1サイトに複数技術が入っているところもあるため、合計は22にならない。

やはりWordPressが最多で、根強い人気を感じる。またWordPressについてはSangoテーマを使っているサイトがないのも驚いた。

Sangoテーマは国産のWordPressテーマで、有償だが、その完成度ゆえに結構人気が高いテーマだと思っているので、これは意外だった。流行りすぎてて独自性を出しづらいのもあるかもしれないし、特に収益性を重視したブログとの親和性がいいため、非営利のサイトだと相性があまりよくないかもしれないなと思った。

しかし驚いたのは次点以降だ。てがろぐが次点に入ってきていて、Astroも勢いがある。まさかこの令和の世に個人開発のCGIがここまで流行るとは思わなかったし、Astroのような今どきの静的サイト生成系ツールが、こういった界隈でも普通に使われているのはかなり意外だった。

それとDokuWikiを使って創作サイトをやっている人がいるのも驚いた。見た目はどっからどう見ても良くできた小説サイトの体裁で、どこをどう見てもWikiに見えなかったからだ。

HTML手書きと思われるサイトも結構あり、こちらも未だに根強い人気がありそうだと感じた。シンプルイズベストというか、HTML手書きはCMSのように画一的な表現から解き放たれ、自由自在な構成が作れるのが魅力だと思う。

流石にadiaryは私のサイトしかなかった。知ってた。

最後になるが外部ホストというのはレンタルブログやWix、Notionなどの外部サービスを使ったものの事だ。これも手軽なことから一定数見られた。こちらはサービス側の制約も手伝ってか、レイアウトの独自性が高いものは少なかったように思う。

個人サイト制作勢にX(旧Twitter)やMisskey.ioは不人気?

この図は各サイトやピクリエ上の紹介リンクにあったSNSのうち、マイクロブログに入るものを集めたものだが、トップはBlueskyで、X(旧Twitter)は次点だった。Misskeyもあったものの、Misskey.ioを使っているところはなかった。またMastodonは一番少なかった。なおFedibirdはMastodonとして集計している。

それでもFediverseとしてカウントすれば7件になるわけで、個人サイト勢の中ではXからの離脱、或いはそもそもXをやらなかった人が多かったのかもしれない。

Misskey.ioがいなかったのは、今回の「その他」ジャンルの個人サイト勢とは、利用者層が重ならなかったのではないかと思っている。というのも、あそこは男性向け成人イラスト周りの要素が強く、今回の参加者層に一致する要素が少なかったのではないかと思っている。

SNSらしきリンクが見当たらない管理人さんも3名ほどいらっしゃったので、SNSより自分のサイトに注力したいとか、そういうのもあるかもしれない。

あとがき

全体的にみると驚きが多く、Astroのようなテックなものが目立ったり、WordPressに押されて一時は影が薄くなっていた国産CMS文化が、てがろぐによって、また存在感を取り戻しつつあるように見えたところは非常に興味深く感じた。

AstroはCMSではないものの、サイト構築手段として見た場合に、Koibumi Astro Blogという日本語由来の名前を持つテーマが結構使われているようで、これも面白いなと思った。ただし国産とまでは言い切れなさそうなので、Koibumiという名前の響きと、テーマそのもののデザインの両方が評価されて使われているのかもしれないと感じた。

WordPressが主流になる前はtDiarySerene Bach(旧Sb)、Blogn、BlognPlusといった国産CMSが結構流行っていた記憶があるので、こういう景色を見ていると、その当時を彷彿とさせるものがあった。というか、tDiaryもSerene Bachも開発が続いているし、Serene Bachについては見た感じかなりモダンな感じになっているようなので、過去形にしたのはちょっと失礼な物言いだった。

しかしまぁ、うちのような何をやっているのかちっともわからないところはなかったので、どこもテーマがちゃんとあって凄いなぁと思うのであった。多分このサイトにテーマが生まれることは一生ないだろうが、まぁそれはそれでいいと思っている。

このサイトにテーマがないことなんて24年前からずっとそうで、一時期は何かコンテンツを置こうとしたし、MMOをプレイしていた時はそれが中心だったが、もうプレイしてないし、核がないのでどうしようもない。

結局のところ私は、過去あの時どうしていたかを書き留めたり、便利なWebツールを作ったりして、それが偶然誰かの役に立てさえすればいいと思っているのだ。

何故なら私自身がネットで検索した時に出会った記事やツールに助けられたことが多くあり、どんな事であろうと誰かの役に立つかもしれないと思っているからだ。例えば地方の豆腐屋のパッケージ写真が置いてあるだけの記事でさえ、複数のサイトに別の時系列で存在していれば、その豆腐の原材料やパッケージのマイナーチェンジが読み解けたりする。そんな誰のためになるかも分からない、需要があるかどうかも謎なものを、私は公開しているのである。

勿論、公開していればネットがある限り記事を見れるため、出先で「その話なら過去にこういうのを書きました」とか紹介したり、或いは調べ物をするときに自分の経験をベースに調べたりできて便利なのもある。

つまるところ、私のサイトははなから他人に向けて発信していないということだ。それでも読んでくれている人がいるのは嬉しい。ただ嬉しさのためにやっている訳ではないので、今後も他人のための記事を書くつもりはないし、私は私による私のための私のサイト作りをこれからもしていくのだろう。

でもそれでいいのだ。何故ならここは私の個人サイトだからね。


  1. オンライン同人イベントプラットフォーム