Hugoで個人ブログにすべてのアウトプットを統合することにした

noteに書いてきた記事を、Hugoで作った個人ブログへ移行しました。 Codexを使った移行作業では、324件分の内容を287本の記事へ整理しています。

移行が終わった画面には、過去の文章が年代をまたいで並んでいました。技術の話、海外で働く話、個人開発、資格、学生時代の迷いまで、一つのサイトから読めます。

そこで、保管場所を移しただけではもったいないと思いました。

これからのアウトプットも、Hugoへ集めることにします。

AIが読める形で文章を置いておきたい
#

検索エンジンだけでなく、生成AIを通して情報を探す機会が増えました。書いた文章が読者へ届くまでのあいだに、AIによる検索、要約、引用が入る場面も増えていくはずです。

ただし、インターネットへ公開すれば、どのAIにも必ず読まれるわけではありません。クロールの可否、ページの構造、サービス側の仕様に左右されます。

自分で管理するHugoサイトなら、その読み取りを助ける情報を自分で整えられます。現在のブログでは、各記事に次の情報を出力しています。

これらは、AIからの引用を保証する仕組みではありません。記事のタイトル、要約、著者、公開日、本文の関係を、HTML本文以外からも判別できるようにする仕組みです。

少なくとも、読まれ方を外部サービスへ任せきりにせず、自分で改善できます。

過去の記事が増えると、投稿画面の使いやすさだけでは足りなくなります。読者が関連記事へ移れるか、同じテーマをまとめられるか、古い記事を現在の考えとつなげられるかが気になり始めます。

Hugoでは、記事ファイルとテンプレートを手元で管理できます。

変更したい場所があれば、リポジトリの設定とテンプレートを直せます。仕様が変わるのを待つ必要はありません。

もちろん、自由には保守が伴います。ビルドが失敗すれば原因を調べ、リンクや構造化データも自分で検査する必要があります。それでも、文章が増えるほど、自分で構造を選べる価値のほうが大きくなりました。

今回の記事も、Codexへ依頼して作っています。

Codexは、リポジトリにある記事、タグの一覧、画像の扱い、文章の規範、デプロイ手順を読めます。そのうえで記事ファイルを作り、Hugoをビルドし、生成されたHTMLとJSON-LDを検査し、mainブランチへpushします。

このブログでは、pushを起点にCloudflare Workersが自動デプロイします。私が考えたことを伝えると、記事の作成から公開確認まで同じ作業環境で進みます。

執筆をすべて自動化したいわけではありません。何を書くか、どの経験を残すか、どこまで断定するかは私が決めます。 Codexには、過去記事の調査、構成、推敲、ファイル操作、機械的な検証を任せます。

この分担なら、管理画面を開き、書式を整え、画像を登録し、公開ボタンを押すまでの操作を毎回繰り返さずに済みます。書くために使える時間が増えます。

移行した記事には、その時々の判断が残っています。同じテーマでも、学生時代と社会人になってからでは考えが違います。個人開発を始めた頃の記事と、利用者が増えた後の記事でも、見えている問題は変わりました。

これまでは、新しい記事を書くたびに過去の記憶を頼り、関連する文章を探していました。記事が一つのリポジトリへ集まると、Codexが本文を検索し、現在のテーマに関係する過去記事を見つけられます。

過去の文章を正しかったことにする必要はありません。当時はそう考えていたが、経験を経て判断が変わった、と書けます。その変化まで含めて、一人の人間が時間をかけて作ったナラティブになります。

生成AIが過去記事を参照できる環境は、文章を似せるためのものではありません。以前の主張とのつながりや矛盾を見つけ、現在の判断を具体的にするためのものです。

noteやSNSには、そこにいる読者へ届きやすい利点があります。今後まったく使わなくなるとは考えていません。

一方で、文章の原本は自分のドメインへ置きます。必要に応じて外部サービスへ紹介文を書き、個人ブログの記事へつなげます。

この形なら、外部サービスの特徴を生かしながら、記事のURL、構造、画像、メタデータは自分で管理できます。過去の記事も、これから書く記事も、同じ場所で参照できます。

今回の移行が終わった時点で、ブログには312本の記事がありました。移行方法の記事が313本目、この文章が314本目です。どちらもCodexへの依頼から公開まで進めています。

Hugoへ統合する理由を説明する文章そのものが、新しい運用の最初の実例になりました。