またまた久しぶりのブログ更新となる。前回更新したのが去年の年末だから、今年書くのは初めてだ。

ブログを気軽に更新する仕組みを構築

しかし、ブログが途切れがちになるのも、今回である程度は緩和されるかもしれない。というのも、ブログを気軽に更新する仕組みをついに構築したからだ。前から構想はあったがなかなかアイデアがまとまらず着手もできていなかったが、最近になってまたブログを更新したいという気持ちが高まってきていろいろと考えているうちにそれなりに使いやすそうな仕組みを思いついたので実装するに至った。

気軽に、とは具体的には iPhone で書けるようにしたいと思った。毎日のように Mac は使っているのだが、Mac だといざ書こうとしてもなんだかめんどくさいなと思ってしまうことが多い。もっと気軽に書くなら、iPhone でも気軽に書けるような仕組みが欲しかった。

ファイル名を先に決めるのが億劫

あと、iPhone でも Mac でもちょっと書くのに障害に感じていたのが、先にファイルを作成しないといけないことだった。このブログを GitHub に移行してしばらく経つが、GitHub のリポジトリで管理するということは、ブログ記事がファイルとして管理されるということになる。そしてそれはつまり、ファイルを先に作って、そこに記事の内容を書いていくことになる。

何がめんどくさいかというと、ファイル名を先に決めなければならないということだ。もちろん最終的には決めるんだけど、書き始める前はどんな内容になるかをはっきり決めないことがある。書いているうちに、どんどん膨らんでいって当初予定していたタイトルと異なることもあれば、書きたいことはぼんやりと頭の中にあるんだけど、具体的に何を書くかは決まっておらず、書き始める中で徐々に定まっていくこともある。

そういうときはタイトルが曖昧だから、ファイル名も決めづらい。このブログでは Jekyll という静的サイトジェネレーターを使用しているが、Jekyll では yyyy-mm-dd-slug.md のようにファイル名の中に URL で使われる文字列が含まれる。そしてこれは自分のブログでは内容を要約するような命名になっているから、ブログをひとしきり書き終えないとこれがはっきりしないことが多い。

だけどファイル名を先に決めてファイルを作成しないと書き始められないというのが億劫に感じていた。

ファイルに直接執筆することの限界

もちろんこれの解決策はいくつかあるにはある。あとでファイル名を変えることを前提として、2025-06-16-foo.md みたいに適当に作成してしまう方法が挙げられるが、ファイル名を変更するとファイルに対する履歴がそこで途切れてしまう。だからなんだという話ではあるのだが、完璧主義な自分は履歴をあとで見たときに途切れてしまうのが気持ち悪いと感じてしまう。プルリクにしてマージする際にコミット履歴をスカッシュする方法も考えたが、せっかく複数のコミット履歴として残っているならそれが一つにまとまってしまうのもなんか微妙だなと感じた。

それから、いったんドラフトということで適当なファイルをローカルに作って、ある程度出来上がったらリポジトリ上にファイルを作ってコピペする、という方法もあるが、これは iPhone だといまいちやりづらい。メモアプリにいったん書くのでもいいが、GitHub にメモらしきものも含めほとんどを記録していることもあってメモアプリを使っていない。それにメモアプリだとあとから消すのがめんどくさい。

そして最大の欠点が、画像がアップロードできないということだ。GitHub はあくまでソースコードを管理・公開する場所だし、VS Code などのエディタも画像をアップロードできるようには当然作られていない。いったん画像をリポジトリにアップロードしてからその URL をコピーして参照する、という方法になるが iPhone でそれを手動でやるのはなかなかめんどくさい。

というわけでこのやり方はいろいろと問題があるので不採用となった。

GitHub Issues を活用

そこで、日記でも採用している、issue を使ったやり方で更新できるようにした。具体的には Issue Recorder という、自分で作った GitHub Actions を使うことにした。

これはもともと日記を issue で書いてそれをファイル化するために作った。日記は一日単位で分かれているから一日に何回も書きたいことがある場合にファイルだと更新がめんどくさいから、ということで issue を使うという方法を思いついた。

ブログだとエントリーごとの記事（ファイル）になるのであまり issue を使うという発想には至らなかったのだが、ブログだって日記と同じような仕組みでうまいことできるんじゃないかと思って環境を作ってみた。なのでこの記事は issue にコメントとして書いたものをブログ記事として公開している。ちなみにこれがその最初の記事となるので、まだ動作確認はできていない。無事にファイル化されてデプロイされるとよいのだが。

そしてこの Issue Recorder には、issue に添付した画像を自動的にファイルとしてリポジトリに保存するオプションがあるので、画像のアップロードもちょちょいのパーだ。Issue になら画像をアップロードできるので、iOS 用の GitHub アプリからでも問題なく投稿できる。

ブログを更新したい欲が再燃した背景

しずかなインターネットの catnose さん の記事を見て、やっぱりこうやって定期的に近況や出来事を共有するのっていいよなーと改めて思ったのが、またブログを更新したくなった理由だ。

しずかなインターネットはブログとは少し違うが、似た性質のものだと思っている。そんななか、catnose さんが書くエントリーは、多少長いものもあるが基本的に数段落で終わる簡素なものが多い。一文で終わるエントリーもある。それを見て「こんなに短くていいんだ」という衝撃を受けた。それは短すぎるという批判ではなく、むしろこれくらい気軽にブログも書いていいよね、という、完璧を求める自分への許しのような衝撃だ。これくらいの長さのエントリーでもいいなら、もう少しコンスタントに書けるかもしれない、という期待が持てたのも再開する理由かもしれない。まあすでにこのエントリーはかなり長くなってしまっている気がするが。

あとは、ふだん自分が思ったことや、その日の出来事は基本的に日記にバーっと書いているが、その中で、たまにいいことが書けたりする。日記ってとにかく雑多でいろいろ書くから、せっかくいいことが書けてもそれが他のことと混ざって埋もれてしまったりする。たとえば今日は暑いなと思ったら「今日は暑い」と書いたり冷房をつけたら「冷房をつけた」と書いたりする。記録として。でもそういうつぶやきのようなものと、個人的に衝撃を受けた出来事や気づきなどが混ざっていて、それがそこだけにしか書かれていないのはもったいないよなと最近よく思うようになった。

それに、日記は、その日から 3 年後に公開されるようになっているが、せっかくいいこと書いてもこれが 3 年間は誰の目にも触れないのか、というのもなんだか寂しい気もする。

だからいいことが書けたらその部分だけでもブログに転記したいなという気持ちが高まってきた。

GitHub Issues には “Reference in new issue” という機能があって、コメントの内容を別の新しい issue として作成できる。これを使えば、日記でいいことが書けたら、そのコメントをブログ投稿用のリポジトリの issue に転記すれば簡単にブログエントリーが公開できるようになる。ブログ記事として書く予定のないものがエントリーになるのはものぐさな自分にとってはかなりありがたい。

広告収益化構想は諦める

短すぎるコンテンツは、Google AdSense の審査が通らないという欠点もあるが、数年前に何度も挑戦して結局審査は通らなかったという過去があるので、もう広告収益のことは考えないとことにする。雇われで働きたくないという気持ちがあるので、広告なり、それこそ catnose さんのように個人でプロダクトを作って収益化を目指すなりして独立するというのが、個人的に理想的な働き方だとは思っているのだが、それをここに適用する必要もないかな。どうせこれで食っていけるようなエントリーは書けないだろうし、広告収益で稼ぐ市場はレッドオーシャンだ。

それに、広告をつけるとなると、書けるコンテンツが制限される。広告がつかなくなるような記事が書けなくなる。年々その基準も厳しくなっているらしいし。個人的には、このブログも自分が世間に対して思っているアンチテーゼであったり、物議を醸すような話題についても言及したいと思っているから、そのような制限がついてしまうのは本意ではない。対して稼げる見込みもないところで厳格な制限がついてしまうくらいなら、いっそのこと広告のような端金は受け取らないほうが清々するというものだ。

他のプラットフォームには乗っからない

catnose さんの作るサービスはどれもデザインが秀逸でおしゃれだ。それにある程度人が使っているプラットフォームに乗っかったほうが、見てもらえる可能性も高くなるというもの。だから、しずかなインターネットで心機一転、新しくブログのように書いていくことも検討はしたのだが、やはりブログのような、書いたものが思い出や記録になるようなものは、どこかのプラットフォームに乗っかるのではなく自分でしっかりと管理して運営していきたいという気持ちが昔からある。

それにどんな使い勝手なのかを確認するために、しずかなインターネットには、一つだけ記事を上げてみたのだが、やはりシンプルにするということを目的に作られているからか、マークダウンがあまり使えない。一部使えるがかなり制限されている。自分の苦手な WYSIWYG が採用されているのもちょっと合わないなと思った。特に画像に関しては URL を指定して貼り付けることができなかったので、別のプラットフォームに引っ越すときに画像の扱いがめんどくさそうだなというのもかなり個人的にはマイナスポイントだった。

個人が運営するサービスは、いつ終わるかわからない。だから、そんなところに大事なデータを依存したくないし、本格的に使いたいとも思えない。

別に catnose さんを否定しているわけではない。むしろ彼の作るサービスの秀逸さには感嘆するばかりである。でも、誰が何を作ろうと、やはりこの根本的な信念が揺るがない限りは、本腰を入れて利用する気にはなれない。

しずかなインターネット以外にも note などの巨大なプラットフォームもあるにはあるのだが、やはりそれもいつ終わるかわからないのであまり使いたいとは思わない。投稿用の API があれば、まだミラーとしてそっちにも公開するというのは悪くないと思うのだが、しずかなインターネットも note もそのエンドポイントは用意されていないんだよな。されていたとしてもマークダウンが使えないと書き方が制限されるのもなんか微妙だなと思う。やはりそこは個人のブログのほうが好きなようにカスタマイズできるのがいい。

ということで新しいプラットフォームへの移行はせずに、これまで通り GitHub Pages で公開を続けることにした。

乱数やハッシュ値は不採用

先ほど、ファイル名は yyyy-mm-dd-slug.md のようになると書いたが、もう一つの案として、slug の部分を乱数なりハッシュ値にすることも考えた。これはわりとあるメジャーな URL の命名だ。そしてこれなら自分で slug を考える必要がないので、先の問題も解決できる。なによりエントリーを書く上で手軽になるのがいい。

しかしこれもいろいろ考えた結果、最終的には却下した。GitHub Pages で公開するのもそうなのだが、リポジトリにファイルとして置かれている状態も大切にしたい。Pages に公開したときは URL に使われるだけなのでまあいいのだが、リポジトリ上ではファイル名として使われる。記事一覧をリポジトリ上で見たときに、乱数ばかりが並んでいると、そのファイルを開いてみるまで何の記事なのかがわからないという問題がある。

今後も GitHub Pages でホスティングして運営していくつもりではあるが、将来的に万が一 GitHub から移行しなければならないようなことがあったとき、git pull すればすべてを一括でダウンロードできるが、そのときにファイル名だけで記事の中身が判断つかないような仕様になっているのは微妙だなと思った。あくまでファイルとしての状態をマスターとしたい。

部分プライベート機能を活用して書きたいことを書きたいように書く

さっきも書いたとおり、Issue Recorder を使うので、画像の投稿なども問題なくできる。それから、部分プライベート機能も実装しているから、一部の文字をブログ上でマスキングすることができる。たとえば[^pvt_a8b0580]のように。

ブログは即時公開することを前提として書くから、他人に見せるような書き方をするよう一応心がけるつもりではあるが、その中にどうしても個人的な記録として個人情報や他人のプライバシーに関わる情報を残しておきたいことがある。たとえば友人とどこか遊びに行ったことをブログに書くときに、その友人が名前は公開しないでほしいと言ったら公開するわけにはいかない。でも個人的な記録としては誰と行ったかを記録しておきたいので、そういうときにこの部分プライベート機能が重宝する。もともとはこれも日記で使うことを想定しているが、ブログでも使えそうなので、書きたいことはとにかく何でも書く、それを公開するかどうかはそのときどきで決める、という運用にしていたほうが、書く際にあれこれ悩まなくて済むだろう。

完璧に書こうとしてはいけない

ようやく気軽にブログを書ける環境が作れて嬉しい。実はブログに書こうと思っていて結局めんどくさくてまだ書けていないという内容のものが直近でもあったりする。気軽に書ける環境が整った今、それを書くのもいい。

しかし、忘れてはならないのは、完璧にしっかり書こうと思わないことだ。完璧主義の自分がよく陥る思考ではあるが、どんなに気軽に書ける環境が整ったからといって、一つ一つの記事を真面目に書こうとしたら結局続かない。それこそ、今回のこの記事だって、正直今書くのに飽きているくらいだ。

それこそ catnose さんのしずかなインターネットでの記事のように、短くてもいいから、インターネット上の誰かと共有できるように、そしてそれが自分への思い出として残るようにしたい。ちゃんと書こうとしてめんどくさくなって結局書かないと何も残らないことを忘れてはいけない。

ちなみに書きやすくなるコツとして、書きたい内容を見出しとして先に書いておいて、その見出しを埋めるように本文を書く、というのが一つ自分で思いついたテクニックとしてあるのだが、今このブログをさっき言った仕組みで issue で書いている中で、段落ごとにコメントを分ければいいんじゃないかと思った。一つのコメントが長くなりすぎるとあとから追記したいときにそれが書かれていたところを探すのが大変だったりするからね。コメントが別になっても段落が分かれるだけで一つのファイルとして連結されるから、書きやすさのために積極的にコメントを分けていったんほうがいいかもしれない。書いている途中でアプリが落ちて書き直しになるリスクも減るだろうし、見出しすらあとから書く際にも編集がしやすいだろう。

SNS への自動共有機能は実装しない

ちなみにブログが公開されたら Twitter などの各種 SNS に共有する自動化も実装しようかなと思ったけど、すべての記事を SNS で共有したいわけではない気もするのでそれはやらないでいいかな。それこそさっき言ったようなアンチテーゼや物議を醸す話題など一般的には理解されないような内容は、見たい人だけが見ればいいと思う。意識的にこのブログを見にこないと見れないものもあっていい。そしてそういうところにこそ、ニッチな情報やここだけの耳より話を置いておきたい。

ドラフトは非公開

ああそれと、この仕組みは別に公開リポジトリでもできるっちゃできるから、このブログ記事が公開されるのと同じリポジトリの issue を活用するというのも一瞬考えたりしたがそれはやめた。誰でも issue を作ったりコメントしたりできると悪用される危険性があるからだ。実際、日記ややることリストも同じ仕組みを利用しているがそういう理由で issue は非公開リポジトリで運用しているわけだし。

それに、いくらすぐに公開するとはいえ、執筆途中で内容が見られるのはちょっとやりづらいというか抵抗がある。だから非公開リポジトリとして作ることにした。

というか今気づいたけど、部分プライベート機能を使うこと前提なら、どのみちパブリックにはできないか。

デザイン

大学生のころにブログを運営していたころは、同じ大学の後輩も見ているという新鮮さがあって、デザインもそれなりにおしゃれに作り込んでいた。それまではあくまでネット上の関わりでしかなかったので。この当時は VPS を借りて自分でブログサービスをホスティングしていた。

だけど社会人になってその関係も希薄になり、仕事の同僚に自分からブログをやっていることを伝えるのは抵抗があるし、仕事とプライベートを分けたいからって理由でリアルな知り合いにはあまり見られることがなくなった。

それをきっかけに更新頻度も徐々に落ちてきた。そんななか、2021 年には Jekyll に移行した ことにより、またデザインを構築し直さなければならなくなった。しかし、自分への備忘録としてちょこちょこ書いていたりはしたけど、デザインを作り直すモチベーションが全然わかなかった。そのときの記録として記事を書くインセンティブがかろうじてある程度で、どうせ誰も見ていないからデザインなんかこだわったって仕方がない、自分の思い出として残っていればそれでいい、というふうにしか思っていなかった。

でも、これからコンスタントに更新することを考えだら、やっぱりデザインはおしゃれであるほうが自分としてもテンション上がるし、また書きたいと思うきっかけの一つがしずかなインターネットでデザインがおしゃれなので、自分のブログもそれを パクって 見習っていきたいと思っている。

正直まだデザインを抜本的に一新するモチベーションはそんなにないのだが、更新し続けているうちにその気持ちも変わってくるかもしれない。なにより、デザインを綺麗にしたいという気持ちはある。だから、ブログを書き続けて愛着が湧いていってデザインを作るきっかけになったらいいかなと思っている。

まとめ

なんか書きたいことはいろいろあった気がするけど、この仕組みを先に構築したくて、書こうとしてからそれなりに時間が経ってしまったので、考えも文章もまとまっていないな。だがそれでいい。ちゃんと書こうとしても続かなくなるだけだから。どうせ収益化もする予定ないし、行き当たりばったりで、書きたいときに書きたいように書けばいい。誰でも見られるようにするだけで、別に見せることを無理に意識することもないだろう。こんなブログを見たいというもの好きな人だけ届けばいい。そんな気持ちで。