WordPressで運営していた技術ブログ「OJapp Tips」を、自作の静的ブログエンジンへ移行しました。名前は OJapp Blog Kit です。
記事をMarkdownで書き、ビルドして公開する。仕組みだけ聞くと、特別新しいものではありません。でも、自分で作って使い始めると、ブログの運営に対する考え方がかなり変わりました。
もともと欲しかったのは、多機能なCMSではありません。記事を書くことに集中できて、公開したものが自分のサイトに積み上がっていく環境でした。
WordPressを離れたくなった理由
Tipsでは、PWAやホーム画面の挙動を実機で試した結果を記事にしてきました。検証して、スクリーンショットを撮って、コードを整理して、文章にする。そこまでは楽しいんです。
面倒になってきたのは、その後の作業でした。管理画面を開いて、HTMLを貼り付けて、表示を確認して、テーマやプラグインとの兼ね合いを考える。記事そのものより、公開するための手順が気になることが増えてきました。
例えば、本文の見出しとテーマ側のタイトルの扱い、広告の挿入位置、記事ごとの表示調整。ひとつひとつは小さな話でも、記事が増えると無視できません。
しかもTipsは、凝った編集画面が必要なメディアではありません。中心にあるのは文章とコード、たまに画像や表です。だったら、もっと単純な仕組みで運営したいと思いました。
目指したのは「自分のZennやQiita」
ZennやQiitaのようにMarkdownで記事を書ける体験は、開発者にとってかなり快適です。コードブロックも扱いやすく、書くことに集中できます。
ただ、自分が書き続ける場所は、自分のドメインに置きたい。記事が増えるほど検索流入やリンク、サイトとしての価値が積み上がっていくなら、その蓄積を自分で管理したいんです。
そこで考えたのが、Markdownで書ける手軽さと、自前サイトとしての自由さを両立するブログエンジンでした。
OJapp Blog Kitは、この考えを形にしたものです。大規模なCMSを作るつもりはありませんでした。必要なものを小さく揃えて、自分が気持ちよく使えるところまで仕上げる。その方が、今の自分には合っています。
Blog Kitの仕組みはかなりシンプル
記事の本文はMarkdownファイルとして保存します。タイトルやURL、カテゴリー、要約などは articles.json で管理します。サイト全体の名前や説明、色などは site.json にまとめています。
大まかな構成はこんな感じです。
content/ Markdown記事
public/images/ 記事画像
articles.json 記事ごとの設定
site.json サイト全体の設定
scripts/ ビルド処理
dist/ 生成された公開用ファイルNode.jsでビルドすると、記事ごとのHTMLや関連ファイルが dist/ に生成されます。公開するのはその静的ファイルです。
npm install
npm run build実際の運用では、VS Codeで記事を編集し、GitHubやCloudflare Pagesを使って公開しています。Tipsの本番サイトはCloudflare Pagesで動かしています。
この構成にして気に入っているのは、記事が普通のファイルとして手元に残ることです。エディターで開けるし、検索も置換もできる。管理画面を経由しなくても、ブログの中身を扱えます。
AIで記事を作る時代だから、Markdownがちょうどいい
最近は記事の下書きや翻訳、要約をAIと一緒に作る機会が増えました。そこで、ブラウザーの編集画面に一段ずつ入力する流れが、少し遠回りに感じるようになりました。
Markdownなら、記事そのものをファイルとして受け取れます。日本語版と英語版を別ファイルにして、メタ情報も一緒に管理できます。書き直したいところはVS Codeで直接直せばいい。
もちろん、AIが書いた文章をそのまま公開するつもりはありません。Tipsで残したいのは、自分で試した結果と、そこから考えたことです。AIには文章の整理や翻訳を手伝ってもらい、技術的な判断や実験結果の責任は自分で持つ。この分担が今の運用にしっくりきています。
記事の冒頭には短い紹介文を置き、別に「1分で答えがわかる要約」も用意しています。これは単なる抜粋ではありません。本文を読む時間がない人にも、結論を先に届けたいからです。
実際の移行は、思ったより地味な作業だった
新しいエンジンを作るのは楽しい。でも、既存記事を移す作業は別です。
Tipsには日本語と英語の記事があり、移行時には200本を超える記事を扱いました。本文を移すだけでなく、URLや翻訳の対応、画像、メタ情報、内部リンクまで確認する必要があります。
表示が崩れた箇所を直し、目次の文字がHTMLエンティティのまま表示される問題にも遭遇しました。" のような文字列が見出しに出てくると、さすがに笑えません。原因を追って、目次側で適切にデコードするよう修正しました。
デプロイでも少し苦労しました。Wranglerが途中で静かに終了して、ファイルがアップロードされないことがありました。一時ファイルの削除や設定ファイルの切り分けを試したあと、正常に公開できる状態に戻せました。ただし、どの操作が決定打だったかまでは断定できていません。
こういう細かい問題も含めて、自作の運用です。便利な完成品を選ぶより手間がかかる場面はありますが、仕組みが自分の手元にあるので、原因を調べて直していけます。
表示速度だけでなく、運営の軽さが大きい
静的サイトにしたことで、公開ページはビルド済みのHTMLとして配信されます。アクセスのたびにWordPressのPHPで記事を組み立てる必要がありません。
Tipsの移行後にはLighthouseでも高いスコアを確認できました。ただ、今回いちばん実感しているのはベンチマークの数字よりも、普段の運営で触るものが減ったことです。
記事を書いて、メタ情報を設定して、ビルドする。基本の流れが見えるので、作業中に迷いにくい。CSSを変更したければファイルを開けばいいし、サイト全体のデザインも自分で管理できます。
その代わり、記事を公開するにはビルドやデプロイが必要です。変更しただけで即座に本番へ反映される仕組みではありません。この工程も含めて、自分の運用に合わせて設計しています。
Blog Kitは、ブログを自分の場所に戻すための道具
ブログを作っていると、つい機能を増やしたくなります。管理画面、エディター、分析、予約投稿……思いつくものを全部入れ始めたら、また別のCMSになってしまいます。
OJapp Blog Kitでは、そこを意識して絞りました。記事を書くこと、必要な情報を管理すること、静的ページとして公開すること。この流れをなるべく短くするのが目的です。
そして、もうひとつ大切なのが、自分のサイトに記事を残せること。記事のURLもデザインも、運営方法も自分で決められる。長く書き続けるなら、ここには大きな価値があると思っています。
今回のTips移行は、Blog Kitにとって最初の本格的な運用テストにもなりました。作って終わりではなく、実際に200本以上の記事を載せ、問題を直しながら使っています。
記事を書く以外の作業を、できるだけ小さくする。
OJapp Blog Kitは、そのために作ったブログエンジンです。これからTipsの記事を書くときも、余計な管理作業に時間を取られるより、PWAの実験や新しい発見に時間を使っていきたいと思います。 OJapp Blog Kitは、GitHubにてMITライセンス（オープンソース）で公開しています。
