新しいブログを開設しました

2026年7月12日

わたしろぐからブログを移転して、わたしろぐ2になりました。新しいブログを作るに至った経緯や技術選定について。

自前のブログに回帰するに至った経緯

またブログでも書くか～

就職を機にブログを書かなくなり、そのまま5年ほどが経っていました。仕事以外でプログラムを書く頻度が減り、また業務関連の知見は社内向けのドキュメントとしてまとめて満足していたので、個人のブログに書くようなことがあまりないと感じていたためです。また、入社前後の時期はQiitaに技術記事を書いていたのですが、Zennやnoteの台頭でQiitaの勢いが落ちたことで、記事執筆から足が遠のいたようにも思います。

最近は少し気が変わりつつあり、まとまった文章を置いておく場所がほしいと思う機会が少しずつ増えてきています。

入社6年目ともなると、業務にも慣れ、ある程度の仕事をこなせるようになってきました。しかし、コードやドキュメントといった有形の資産を再利用することで効率を担保している部分は確実に存在します。要するに、毎回新しく何かを作るより、以前書いた設計やコードをコピペして新しいものを作ったほうが速いということです。

そうなると感じるのが、もし会社を辞めたとして、現状と同じものが作れるのか、という疑問です。幸いなことに仕事には満足していて、向こう数年での転職は考えていないのですが、定年まで一つの会社で勤め上げるような業界ではないし、5年後や10年後にどうなっているかはわかりません。そこで、業務で得た知見を一般的に使える形で抽出し、会社を辞めた後もアクセスできるようにしておくことには一定の価値があると思うようになりました。もっとも、最近はAIにコーディングを任せられるようになってきていて、何を作るべきかがわかっていればその都度コードを生成できるので、古い資産のコピペにどれほどの価値が残るかわからなくなってきたところでもありますが。

なぜ自前のブログか

そういうわけで、たまには記事を書くようにしたい、というモチベーションは戻りつつあります。ただ、技術記事を書くだけならQiitaでいつでも書けるし、なぜ今自前でブログを構えるのかという話です。

理由のひとつとして、技術記事以外も書きたいという話はあります。エンジニアお気持ちポエムの類を書き散らして気持ちよくなってみるというのも楽しそうですし、旧ブログで書いていたようなゲームの感想なども書ける場所があると嬉しいです。技術ブログ専門のプラットフォームで自分語りをするのは気が引けますが、自前のブログでなら何を書いてもよいでしょう。

一方で、ブログであれば何でも良いというなら、簡単に書き始められるブログサービスもいくつかあります。技術記事はQiitaかZennで書いてポエムはnoteに書くとか、はてなブログを開設するという手もあります。なぜそうしないのでしょうか。

はてなブログは個人的に昔から好感を持っていないのでいったん置くとして、なんかソーシャルっぽい感じとか「いいね」の数とかを気にしなくてよいほうが嬉しいと感じるようになってきました。評価が可視化されるとどうしても意識してしまうので、伸びる記事を書きたい、という気持ちが出てきて、気軽に記事を書くためのハードルが上がってしまうからです。もともと筆が遅いうえに長文の記事を書きがちという傾向はあるのですが、もっと短くて簡潔な記事も書いていきたいので、執筆までのハードルを下げていきたいわけです。

6年前に「ライセンスをつけないとどうなるの？」という記事を書いたところ、ありがたいことに1,000を越えるいいねを頂くことができました。これぐらい数字が盛れたことで満足したし、これを越えようとすると相当気合いを入れないといけないわけですが、どちらかというと今は気合いの入っていない記事を書きたいので、このレースからは降りようと思っています。あと、今の技術ブログは何につけてもAIで、AI以外のことを書いても伸びる気はしないし、そもそも技術ブログ自体が相当下火になっている気がしますね。

それで結局、いいねの数やシェアされた数などが表示されなくて心地良い自前のブログに戻ってきたというわけです。旧ブログの更新を再開するのではなく新しくブログを作り直したのは、単純に技術的な興味に加えて、旧ブログは古すぎて手をつける気が起きなかったためです。いまだにHTTPS対応していないというとんでもない問題を抱えているのに加えて、たしかに自動デプロイのためのCIが組まれているのですが、構築したのは10年以上前で、なんとGitHub Actionsが存在すらしていなかったころの代物です。なんとか手を入れれば刷新はできるだろうと思うものの気が重く、今時の技術スタックを使えば最初から作ったほうがモチベーションも上がるしモダンなワークフローが組めそうなので、新規で立ち上げることにしました。旧ブログのHTTPS対応や記事の移転などは頑張ればできそうですが、古いほうのリポジトリを触りたくないので結局手をつけないだろうと思います。

新ブログを支える技術

新しいブログは https://github.com/Tatamo/blog2 のリポジトリ上に構築することにしました。

Docusaurus

旧ブログはHugoを用いて作られていましたが、今回はDocusaurusを採用しました。どちらも静的サイトジェネレータですが、前者はGoのテンプレートを用いて、後者はReactベースで組むことができます。記事そのものをMarkdownで書くことはかわりないのですが、DocusaurusはMDXを公式にサポートしており、ReactコンポーネントをMarkdownの中に配置することができます。旧ブログでも記事の中にJavaScriptを書くことが稀にありましたが、HTMLタグを直接記述することになって大変だったので、ここの体験が良くなることは明確なメリットとして期待しています。

Docusaurusを触ってみて感じたのは、典型的な、とにかくeasyな類のプロダクトであるということです。つまり、out of the boxの状態で非常にうまく機能し、セットアップからデプロイまで短期間で完了させることができます。一方でeasyさに振ったプロダクトにありがちな傾向として、決してsimpleなプロダクトというわけではなく、敷かれたレールから少しでも外れようとすると途端にコストが跳ね上がる構造になっているように感じられました。

例を挙げると、このブログ右側のサイドバーにはタグの一覧を配置して、タグごとの件数を表示しようと考えていました。旧ブログがそのようになっていたためです。しかし、これは素直な方法では実装できません。どうやら、タグやタグごとの記事数はブログプラグインのスコープ内で引き回される情報で、サイドバーはそのスコープの外にあるため取得できないようです。もちろん可能ではありますが、何かしらのハックを行わなければ実現しづらそうだったので諦めています。

レイアウトを拡張・変更するSwizzlingの仕組みも、使用するためにはテーマのコンポーネント構造がどうなっているかを知る必要があります。たとえばフッターに表示する内容を変えようとした場合、対応するフッターコンポーネントをラップするか、そのコンポーネントの実装をリポジトリ内にコピーしてきて独自の実装に書き換えなければなりません。これは端的に言って学習コストと保守性に劣る設計で、AIに任せて調整できる範囲ならいいと思いますが、自分でしっかりデザインを組みたいなら他のSSGを使ったほうがいいでしょう。

この記事を執筆したバージョン3.10時点ではメインテーマは1つだけ存在しており、用途がこれに適合するかどうかが、そのままDocusaurusの採用可否に結び付くといえます。またこのメインテーマはInfimaというDocusaurus以外で使われているところを見たことがない独自CSSフレームワークを採用しており、およそ必要とは思えない学習コストを支払わされるか、サポート状況の怪しいCSS-in-JSやSass/SCSSに切り替えるかの二択が生じることも忘れないほうが良さそうです。このブログは多少Docusaurusっぽさを脱色するように微調整しましたが、根本的にはシンプルなブログでしかないので、このぐらいならDocusaurusのメリットを享受できる範囲内かと思っています。

Docusaurusに非常によくマッチする用途としては、開発者向けのドキュメントやAPIリファレンスが挙げられそうです。 OpenAPIファイルからドキュメントを自動生成するプラグインもあり、用途には十分です。十分なクオリティがあり、デプロイも容易で、メンテナンスの必要が低いドキュメントサイトを簡単に立ち上げられるためベストマッチだと言えそうです。

考えることが少なく済むのであればメンテナンスコストも低く、npm install してから npm start するだけで開発用サーバーが立ち上がり、 npm run deploy でビルドからGitHub Pagesへのpushまで行ってくれるのは非常に快適です。まだ組んでいませんがGitHub Actionsでの自動デプロイも簡単にできそうな雰囲気なので、このあたりはnpmのエコシステムを活かせていて素晴らしい体験だと思います。

総じてDocusaurusは、公式に用意された設定を弄るだけの範囲であれば立ち上げが容易で、最初から一定のクオリティの見た目も担保されているので、考えることが少なくとても便利です。自分で何かを弄りたくなったら、本当は必要のない些細な変更であるか、Docusaurusを捨てるべきかのどちらかでしょう。 easyなプロダクトとはそういうものです。

Codespaces

gitとnpmとエディタの入った開発環境さえあれば、簡単に記事を執筆してDocusaurusでデプロイできるので快適な執筆体験が獲得できたかのように思われました。問題は、gitとnpmとエディタの入った開発環境が手元にないということです。普段使いのWindowsマシンにはろくな開発環境を用意しておらず、ブログを書くためだけにセットアップの手間をかける気にもなれません。そこで、Web上から記事の執筆が完結できるのが望ましいと考えました。

そういうわけでGitHub Codespacesを使うことにしました。他の選択肢としては、単にMarkdownを書くだけなのでテキストエディタで執筆する、GitベースのCMSを使う、という案がありました。 Codespacesを採用したのは、実際に開発サーバーを立ち上げてリアルタイムでプレビューができる点と構築の手間が少ない点でより適していると考えたためです。

リモートで実際に開発環境を立ち上げるというアプローチのため、ブログそのものの調整もCodespacesの中で完結させられるのも嬉しそうです。

懸念があるとすればCodespacesは従量課金であるという点ですが、GitHubの個人用アカウントでは月に60時間の無料枠を利用できます。執筆頻度を考えるとこれで十分だと予測しており、仮に無料枠を超えた場合でも、それほど熱心にブログを書いているなら許容できる範囲だと判断しました。

Codespacesの利用を始めるのは非常に簡単で、 devcontainer.json を定義してリポジトリに入れておくだけで、GitHubのWeb UI上からアクセスすることができます。普段VSCodeを使わないのでDev containersには詳しくありませんでしたが、Docusaurus自体の依存がシンプルなこともあり、AIに任せればコンテナの定義は簡単に用意できました。

これでWeb上でコードエディタが開いて執筆でき、リアルタイムでプレビューもできるので快適になりました。

所感

ブログの記事を書きたいかも、と思うことは直近で何度かあったものの、レガシーな旧ブログを触ることを考えると腰が上がらない状態が続いていました。 GitHubのブログのリポジトリページにアクセスすれば執筆を開始できるので、ハードルが下がってまた記事を書いていけたらと思っています。

Docusaurusを触ってみることができたのも楽しかったです。使う前は、ある程度整ったテンプレートが最初から用意されていて、それを自分好みにカスタマイズできるモダンなSSGなのかな、という印象を持っていました。実際は、そのテンプレートから外れたことはほとんどできない（厳密には、できなくはないがDocusaurusでやる理由がない）が、あらかじめ定義された用途に沿うものなら超高速で構築できるピーキーなSSGだというのが、使ってみての所感です。とはいえ今回のブログ構築はシンプルに済ませようと考えていたので、今回の用途としてはある程度マッチしていると考えており満足しています。

というか、Docusaurusと格闘してもらうところはすべてAIに任せたので不満がありません。良い時代になりました。