ブログを再構築した話

アイスブレイク（？）

ブログの更新は久々ですね。前回が7ヶ月前なので……7ヶ月前？！　やばい、衝撃がすぎる。卒業してからもう7ヶ月ですか……

はじめに

最後の更新から今日まであれこれ起伏ある人生でありましたが、それはそれで今度ブログにするとして、今回のテーマは「バイブコーディングによるブログサイトの置き換え」です。

もともと以前のブログサイトには、静的サイトジェネレータ（SSG）のAstroを使用していました。正確には、AstroをベースにしたAstroPaperというブログ用テンプレートですね。

これをプチ改良、色調などを変更して使用しており、概ね性能や機能、ブログ執筆体験には満足していましたが、いくつか看過できない不満点がありました。その不満からの解放を目指して、今回は置き換えを行ったわけです。

不満その1: テーマやライブラリのアプデへの対応

不満その1、Astro、及びAstroPaperのアプデに対して自分のブログを追随させることの煩雑さです。アップデートが活発であること自体は、コミュニティや開発元が精力的・活発であることを示し、これ自体は喜ばしいことなので文句はありません。とはいえ持続的にブログを維持運営していくうえで、AstroPaperのアプデの手順をCIなどで自動化できないのがかなり辛かったわけです。

例えば、ブログに登録できるパラメータの問題があります。単にブログのmarkdownを新しいテンプレートに押し込めればいいわけでもなく、バージョンによっては特定のパラメータ（タグ、下書きフラグ）があったりなかったり、同じ機能があっても名前が違ったり。

また、細かい色の調整などを施していたので、新しいバージョンで適切に再現するのはなおさら面倒な手順を踏む必要がありました。このバージョンではこのCSSファイルに、次のバージョンでは別のコンフィグファイルに、あっちへこっちへ移り変わる設定内容を都度都度書き換えるのは非常に面倒です。

精々数カ月に一度の作業ではありますが、これを今後永久かつ定期的に行っていくのはなかなか骨が折れると言うのが、不満の1つ目です。

不満その2: CMSとの連携が難しい

不満その2、CMSとの接続が面倒であることです。 CMS（Contents Manegement System）は、ブログの記事や、あるいはブログ全体を管理するためのシステムであり、管理画面やAPIを介してデータを操作することができるすぐれものです。有名どころだとWordPressなどでしょうか。 PCとテキストエディタを用意しなくても、Webブラウザの投稿フォームに書き込んで公開ボタンを押せばいいのはシンプルでわかりやすくスッキリしています。

こういったシステムを使おうと言った場合、AstroPaperを使いながら導入しよう、というと、毎バージョンごとにCMSとの連携を書き直したりする必要が出てきます。それに、データを訳のわからない企業に預けてしまうのも怖いし、それが海外の企業・CMSであるなら尚更です。そういった観点から、個人的に、使うのであればmicroCMS一択だと思っているのですが……結局先頭の面倒くささの問題に立ち返ってくる。

不満その3: ソースコードを弄ることへの緊張感

これまで僕は、ブログの見た目や機能を実装してあるソースコードの中にある、特定のフォルダの中に自分のブログ記事を保存してきました。これ、案外「フォルダどこだっけ」とか、「あれ、これいじっていいファイル？」とかいう疑問が常々浮かんでしまうんですよね。あとは、不意な操作で消しちゃいけないファイルを消してしまったり。ソースコードとブログ記事が一体化しているのは、特段大きな問題点ではなくとも、常に弱い緊張感を書き手に与えてきていました。

こうした不満から、「だったら自作してしまえばむしろ自分の都合で色々弄くれるのでいい」と思い切ってリプレイスに取り組み始めた、というのがことの経緯です。

リプレイスに際して

ブログサイトのリプレイスとはすなわち、フルスクラッチ、0からの再開発ということになります。実はすでに、サークルサイト・自己紹介サイトを実装・公開していますが、今回はこれと同じ配色・デザインを採用しました。余談ですが、こういう「複数サイトで共通の自分のデザイン」というものに憧れもあったので、完成した今結構テンションが上がっていますね。

このリプレイスに際しては、もしかすると僕のブログをブックマークに入れてくださっている方がいる可能性に鑑みてルーティングは変えないようには注意を払いました。つまり、各記事のURLが変更されないようにした、ということです。それから、ブログとしての構成も正直大きくは変わっていないというか、変えないように、とはいえ見た目は自分のサイトとしてきちんと修正し、自分の欲しい機能を盛り込みました。

大きく変わったところといえば、皆さんの見る見た目には全く関係の無いことですが、ブログ記事の投稿にmicroCMSを導入したことにあります。実際のところ、これまでのスタイル（GitLab Pages毎回ブランチを切ってマージリクエストを出してビルドする方式）はちょっと面倒ではありました。普通に出先でブログの書き足しとか調整できないのもちょっと苦しいですし。それが、CMSを使ってブログを投稿すると、git管理との連携が面倒くさくはなるけれどそれ以上に「リポジトリをいじらなくていい」というのは嬉しいポイントです。事実この記事も、microCMSを使って投稿しました。正直、ソースコード全体を操作できる状態の中でブログを書くのって微妙にフォルダ構造とか分かりづらかったりしたし、そういう意味でも良かったです。

バイブコーディングする時の苦しみと悦び

実を言うと、これまでもサイトを刷新しようと何度も思い立ってはいるのですが、今回に至るまでそこまでの体力がなかったのでちょっと尻込みしていました。設計まではなんとなくすぐにパッとできるんですが、やっぱり実装の細々とした諸問題に立ち向かっている間に日々の生活や様々なことに押し流されて途中で計画が立ち消えることが多かったのです。それが、この間から導入し始めたClaude Codeとバイブコーディングによって、実装のコストがかなり下がりましたので取り組めるようになった。

というわけで、このブログサイトのリプレイスに際して、Claude Codeを用いたバイブコーディングを行ったわけです。開発し始めて数時間、最初の方（ざっくりとした雛形）はうまく作ってくれるし、どんどんやりたいことが形になっていくのが快感でどんどん進んでいきました。「一般的なブログのページ構成に則って雛形を作ってください。」と打つだけで、普段苦労して書いていた諸々のコードがあっという間に完成！やったぁ、この調子だ！

と、そのまま最後まで完成すればよかったんですが、後半に行くにつれて、「実装が完了しました！」といいつつ全く変化無し……とか、「修正できました！」といいつつ適当な変数をいじっただけで実際の挙動には全く変化無し……とか……。生成AIの粗がボロボロと出て、開発開始して翌日にはもうスピードは鈍化。とてもじゃないけど最初の快適さはなく、自力で実装したほうが早いと額に血管を浮かべながら手書きした部分もあります。修正や機能追加について、特に、webアプリ・webサイトの通例実装でなく「独自にこういった細かい機能を実装したい」という用途にはかなり回りくどくなってしまいました。調べてみるとどうやらこういった現象はバイブコーディングにはつきものらしく、デグレーションと命名されているようです。

なんにせよ、自分で全て実装するよりも（多分）早く完成したわけであり、これまで重い腰になって取り組んですらいなかったわけですから、その点については良かったと思います。それから、Claude Code及びClaude Sonnetのアプデにより、ちょっとずつ性能の向上もあるから、今後は今よりもいい開発体験ができそうな予感もしているので、今後も適切に生成AIを開発に使っていこうと思います。

複雑な気持ち

さて、もともと、自分の実装力をつける意味でも、AIなんぞに負けてたまるかという意地の部分でも生成AIをコーディングに使用することに抵抗感がいくらかありました。それに、イラストや小説の分野などではやっぱり著作権などの問題も大きいし、全体としていいイメージが無いですからね。

一方で実際に触ってみると、正直これがあるとないとじゃアプリ開発の速度が段違い、無い頃を考えられないぐらいになってしまいました。なにはともあれ、今の自分に必要なwebサイト、アプリケーションなどを今順次実装を進めています。現時点での生成AIの功罪を考えると複雑だが、今はこの便利さを享受して置きたいと思います。

ではでは。

おあとがよろしいようで。