そういえば、春のアップデートでこのブログに３代目以降の伝統だった「イヤーカラー」を復活させました。
イヤーカラー（年カラー）とは簡単に言えば西暦ごとに色を１つ決めるというものです。
このブログでは各年の個別記事の記事番号と、その記事へのリンクを着色するのに使っています。
このブログはベースデザインがモノクロなので、アクセントカラーとしても機能するようになっています。

年カラー自体は３代目以前からも自分の中にあった概念で、
古くは「マイベストゲームランキング 2006」でも使用していた記憶があります。
基本的には翌年初頭くらいにその年を象徴する個人的カラーを決め、各種デザインなどで使うという感じですね。
特に2003年から2010年までは順に橙、黄緑、青、青紫、黄、赤紫、赤、灰と決まっていて、
これは当時を過ごした自分がその年に抱く抽象的なイメージを総合して決めたものです。
この８年間が特に象徴的な年カラーで、逆に言えばそれ以外の年カラーはほとんど後付けでしかありません。
しかし思い出補正とは恐ろしいもので、
たとえばいま2005年について思い出そうとすると「青色」というイメージは絶対に拭えないほど、
当時決めた年カラーは自分の中で常識的な概念として定着しています。青以外は考えられません。
2011年以降もできるだけその年の抽象的なイメージを踏まえて決めるようにしていますが、
2003〜2010年のイメージが強すぎて、それぞれの各下１桁と共通している色にイメージが引っ張られてしまいますね。
たとえば2023年は橙色です。これは2023年が「橙色っぽい」という感じもしなくもないんですが、
おそらく無意識下で「３＝橙」という数と色の暗黙的な結びつきに影響されているのではないかと思います。

同じく春のアップデートでカラースキームを整理したピクチャレ大会でも色イメージは大切にしています。
こっちはピクミンシリーズのナンバリングタイトルを取り扱っているわけですが、
１作目から順番に青、赤、緑、黄というイメージカラーを昔から使っています。
このうち３作目はパッケージデザインの雰囲気から、４作目は新色ピクミンの花の色を由来としていますが、
１〜２作目については後付けであり特に根拠はありません。
しかしこれもそれなりの歴史があるためいまさら変えるつもりもなく、
自分の中では『ピクミン２』＝赤というイメージは完全に定着してしまっています。
ランキングの１位＝黄、２位＝緑、３位＝青というカラーイメージも同様で、開設当初からある大切な設定です。
これこそがwebサイトのアイデンティティと言えるかもしれない。

webデザインにおいて、色は軽率に扱ってはならない重要な要素だと思っています。
自分が作るサイトは基本的に色数を絞っていますが、それはそれだけ色１色が与える影響力を重視しているからです。
色数を多くすればするほどその影響力は打ち消しあってしまうので、色数を増やすのは本当に難しい。
色についてのノウハウは５年ほど前に色彩検定を取ることである程度学んだつもりですが、
webデザインを今後も続けるなら折に触れて学び直したい分野ではあります。

今回の実家帰省は「ぽこポケをガッツリ遊ぶこと」「２つのwebサイトで2026年春のアプデをリリースすること」
を目標にしているわけですが、その後者について思うことを書き残しておきます。

今回のリリースは個人的にChatGPT Codexを本格的に使うようになってから初めての大規模改修になりました。
１ファイル単位、関数単位でweb開発にChatGPTを活用することはすでに一昨年からスタートしており、
そこではまだ開発主体は自分という意識があったと思います。
しかし複数ファイルを横断的に分析してそのまま改修してくれるCodexでは、すでに人間は蚊帳の外。
開発主体はもはやAIであり、自分はそれを指示している人間でしかありません。
そうすると、当然Codexが回収した部分のコード内部は人間には掌握できないという問題が発生してきます。
「AI以前」はすべて人力で書いてきたので理屈ではコードの全容は理解できていたはずなのですが、
Codexが手を加えれば加えるほどそういう部分は少なくなってきている現実があります。

つまりCodexによる改修が進めば進むほど、もはやコードはAIでしか書けないものに変わっていきます。
これにより、ひと昔前なら人力でコードを読んでささっと修正していたような軽微な作業でさえ、
いまや何がどうなっているのか分からないのでAIに委託せざるを得ないということになるわけです。
確かに新機能の追加などの大掛かりな改修についてはAIは圧倒的なパフォーマンスを発揮しますが、
サイトの細かいメンテについてはその「細かさ」を言語化するのにも手間がかかったり、
またGPT5.4現在においても一発で正確に理解してくれるともかぎらず何往復も必要だったりするため、
むしろ効率は大幅に悪化したとさえ思っています。

この状況を改善に持っていきたいのなら、AIが生成したコードを人間が把握する必要があるでしょう。
しかもそれを、コードの大幅な改変が発生するたびにしなければならない。
しかしそれはロースキルであればあるほどタイパが悪く、なかなか現実的ではないという事情もあります。
こうなると結局、AIが従来より非効率と知りつつもAIに開発を依存せざるを得ないという状況になってくるわけです。

このことから、少なくとも元々人力で作ったwebアプリをCodexに任せて開発するということは、
成果を先取りする代わりにメンテナンス性を犠牲にする、「成果の借金」のような側面があるのではないかと感じました。
その意味での借金が後々重しになるようなプロジェクトにおいては、AIの利用は必ずしも正義ではないのでしょう。
AIの登場で浮かれていてもうプログラミングの勉強は必要ないと思っていた自分ですが、
むしろAIが登場したからこそ基礎スキルの重要性が増したと言えるのかもしれません。

週の始めから取り掛かり始めたwebサイト改修計画、
実家帰省前半３日を使ってようやくリリースまで漕ぎ着けました。
例のAPIが遅すぎる問題に着手したのがそもそもの始まりでしたがそれ自体は作業量としては１割程度で、
あとは芋づる式に引き出された諸々の改善を実現するのに費やしました。
具体的には、今回はピクチャレ大会のナレッジベースのリニューアルを重点的にしました。
画像アップロード機能にメスを入れられるのはだいぶ先かなと思っていましたが、
ChatGPTくんのアシストのおかげで想定より２シーズン早い実装です。

今回実感としてあるのは、web制作にしろ何にしろ「問題」が発生していると着手しやすいということですね。
つまり、特に問題の発生していないサービスの改善を施すような作業よりも、
ユーザーに不利益を及ぼすような問題が発生していて、それを修復する作業の方が着手しやすい。
当たり前なことを言っていますが、これはモチベーションの出所がまるで変わってきます。
改善はあくまでも自分がやりたいからやるのであって、他者に需要があるかどうかは別の話です。
修復は少なくとも「不利益を被る状態」から「そうでない状態」に持っていくという意味では、
明確に他者に利益のあることをするという点で責任感が生まれやすいです。
それは同時に「ユーザーに不利益を強いるサービス提供者」という不名誉を払拭したいという動機も生じさせます。
後者の方がモチベーションを保ちやすいのは当然のことですが、
それはこういう心理的構造の違いからなのではないかと。
これは、ある程度サービスが完成してからなかなか改修モチベが上がりにくくなっていることにも関係してきます。
これは最近何度か書いているとおり、既存サービスのモチベが上がらない原因と見ています。

あと今回は「修復」に必要なツールとしてLaravel Telescopeというツールを導入したのですが、
こういう未知のツールとの出会いも少なからずモチベーションを高めますね。
その入り口はやはりというかChatGPT。
昨今の各種作業の鍵は間違いなくChatGPTが握っていると思います。
この巨大なツールをいかに使いこなすかで作業モチベも大きく変わってくる。
先日も書いたように、Unityのような一見するとChatGPTと連携しにくいようなツールは着手しにくい一方、
CLI（コマンドライン）ベースのツールはかなり心強い印象があります。
ほんの数年前までCLIなんてそれだけで苦手意識があったものですけどね。

01月下旬の例のビルドエラーで死んだプログラミングモチベがやっと復活したため、
ここ数日動き回って年初来のタスクだったこのブログの動線改善アップデートを終わらせました。
具体的にはトップページから直近100本まで辿れるようにしたのと、記事ページの前後記事表示の改善です。
まぁこれで最低最小限の体裁は整えたのではないかと……。まだまだやるべきことはありますけどね。

なお、ビルドについては原因は半分までわかっているものの根本解決はまだです。
開発環境のコンテナ外、つまりOSのローカル環境そのものでyarn buildを実行すると通るので、
ローカル環境とコンテナ環境の差異に原因があると思われます。
これはいろいろなプラグインのバージョンなどを調べていくことになりそうですが、
案外Dockerfileをあれこれいじっているうちに直りそうな予感もしています。
まぁ、いずれにしろNext.jsなど動かすソフトウェアというよりは土台に原因がありそうではある。

開発環境はビルドが通るので本番相当のwebアプリを動かすことができていますが、
本番環境（Ubuntu）は本番環境でコンテナ外でやろうとするとさまざまなエラーが出るし、
他のサイトと共存している部分でもあるのでやはりコンテナ内でビルドできる必要はありそう。
まぁ、これは見た目上の支障は無いので今後の課題とさせてください……。
ビルドできるに越したことはないのは確かなのでさっさと解決したいところではありますけどね。
後述のこともあるのでこれはこれから着手するかもしれません。

緊急度の高かった動線改善がひとまずできたということで、
次はいよいよ春に向けて特設サイト側に着手したい……と思っていました。
これのリミットを春に置いたのはテーマとするゲームのアニバーサリーがそこにあるからなのですが、
コミュニティでみんなの都合を聞いてみると年度末〜GW前後は忙しい人が多そうな気配。
また先日のプチトラブルの件はいちおう表面的にことなきは得たのですが、
自分の内情としてはきわめて心外であり納得感に欠けることに変わりはなく、
それもあってコミュニティのために頑張ろうというモチベーションがかなり損なわれている状況です。
正直、これだけマイナスファクターが揃っていてプラスの材料が皆無という状況で、
いまの自分がモチベを絞り出して頑張れる気はしません。
そのため、このプロジェクトについてはいったん凍結が妥当だと思っています。

そういうわけで、現状はいったんタスクがリセットされて順番待ちが解消したという認識です。
先述の通り本家ブログの見た目改善の続きをやってもいいのですが、
こういう機会はあまり無いので他にやるべきことは無いのかしっかり吟味していきたいところですね。
特にいまはプログラミング系のモチベがそこそこある状態なので、このエネルギーを使わないのはもったいない。
やりたいと思いつつずっと保留している新本家サイトリメイクなんかはすぐに浮かぶ案です。
これもまあまあ有望ではある気がする。

年初の抱負≒年間計画で、web制作分野では本家ブログ→ピクチャレ大会→新本家サイト復活、
という順番で進めていくという旨の方針を書きました（#07686 / 2025年01月01日）。
その最初の本家ブログ、すなわちこのサイトのアップデート計画についてですが……
本日、ほぼ白紙に戻すことを決めました。
白紙とはどこまでを指すのかというと、アップデートのみならず四代目移転計画そのものまでです。
つまり、改めて４代目本家ブログを最初から作る決心をしました。

現行のこのブログはwebサイトとして未完成の状態で使い勝手が良いとは言えません。
なので、それを少しでも解消すべく、

• ２ペイン構成にして動線を増やし、ページ間移動を少しでも楽にすること
• ISRを採用してキャッシュを生成し表示を高速化すること

の２点をマストとする更新計画を年初に立てました。
特に後者については、実は現行のブログはいわゆる開発環境をそのまま本番として稼働しているため、
ちゃんとビルドを通して静的なHTMLを生成することはwebサイトとしての絶対条件でした。
開発環境をそのまま本番運用するなど本来であれば論外も論外です。
ページビューがピクチャレ大会の16分の１しかない本家ブログだからこそできる芸当かと。
ともあれ、さすがにアプデするからにはちゃんとビルドして本番相当環境を用意してあげたい。
……ところが、そのビルドがまったく通らないんですよね……。
この２日間、昨今の自分にしては珍しいくらい作業に集中してビルドの不具合に立ち向かったのですが、
ChatGPTのみならずweb検索も駆使してあの手この手を試してもダメだったのと、
ビルドする程度のタスクでここまで苦戦するほどスパゲッティ化しているようでは
今後ますますメンテナンス性が悪くなっていくのは必至ということで、ゼロベースからの再構築を決心した次第です。

一方、有望視されていた新本家サイトの復刻について。
これはそもそも2015年以降、web制作という活動自体がピクミン活動に強く依存するようになったため、
ピクミン活動が衰退すると必然的にweb制作もやらなくなってしまうという問題点を抱えているという事情から、
中小規模の活動をwebサイトとして残すためのプラットフォームを作りたい、という思いつきが発端でした。
しかし実際に「中小規模の活動」たる『原神』にのめり込んでみて分かったのですが、
とてもじゃないがwebサイトを書いているような余裕は無いし、そもそも需要も皆無なんですよね。
中途半端なサイトを作るくらいなら絵の練習をした方がまだ有望のような気がする。
なにより、中小規模の活動の足跡という方向性は本家ブログのそれと重複しています。

そこで、ゼロベースから作り直すついでに新本家サイト復活という当初の計画も吸収してしまい、
それに相当する機能を盛り込んだ上で本家ブログをアップデートする計画をいま立てています。
具体的には、タグごとにキーワードについて書くページを追加する予定です。
要は公開パーソナルWikiのような機能を盛り込むことによって
中小規模の活動をブログ記事以外の方法でも書けるようにし、自分専用のナレッジベースとするわけです。
2014年の３代目移転当初も実は同じような構想がありましたが、WordPressがWikiに向いてなさすぎて頓挫しました。
Obdisian管理のいまならまあまあ現実的にできそうだし、
維持管理自体も１つずつの活動にそこまでのめり込まなくてもやっていけそう。
これを08月31日までに今度こそ作る、というのが現時点での目標です。

そうなるとブログ関係は本腰入れてやる必要があるので、先にピクチャレ大会をという話になるわけで。
来月はそっちに注力できたらなと思っています。
なんだかんだでこのビルドエラー騒ぎで中旬以降低迷していたweb開発モチベも復活しました。
次に低迷するまでにピクチャレ大会の方へしっかりバトンを渡していきたいところです。

年始のクリエイティブ作業フィーバーはいよいよピクチャレ大会開発にも飛び火し、
直近で作りたかった機能を一通り実装できるところまでいきました。なかなかの達成感。
ただし、リリースのためには最低でも総合ランキングの読み込みが遅すぎる件を解決したく、
これがブースト状態のいまですらなかなか着手し難いほど闇が深いので困っています。

このサイトの開発に使っているフレームワークはフロントエンドがNext.js、バックエンドがLaravelで、
どちらにもキャッシュの仕組みがあります。
総合ランキングが全ユーザーの各記録について処理する都合上とんでもなく重くなってしまうので、
これまではキャッシュの活用によって高速化を図っていました。
しかし、どうもキャッシュしてもなお重いんですね。

キャッシュの種類には、ページを静的（Static）なHTMLに変換してサーバーに保存しておく方法、
バックエンドへのリクエスト結果を専用サーバーに保存しておく方法、
フロントエンドへの出力結果をエンドユーザーのストレージに保存する方法などがあります。
基本的にピクチャレ大会の開発方針としては、ページをHTML変換する方法を主流として使ってきました。
これはユーザーも任意のタイミングでキャッシュを削除できるようなボタンの実装も可能なため、
ランキングというデータの形態にマッチしているのではないかと考えたからです。

ただ、ややこしいことに総合ランキングではAPIを保存する方法も併用しています。
あまりにもバックエンドの処理が重すぎるからですね。
そしてさらに厄介なことに、「ページ」単位でキャッシュする設定をしてはいるものの、
その子要素であるコンポーネント内部でまたサーバーへのリクエストを行っているという構造の都合上、
そのコンポーネントに関してはキャッシュが効いていないことが判明。
しかも、このコンポーネントこそがランキング本体で一番処理が重い部分です。

総合ランキングは移転プロジェクト初期に作った部分ということもあってやや難解で、
なぜページのバックエンド処理部分（getStaticProps）でAPIを実行していないのか謎ですが、
いずれにしろかなり抜本的に構造を変えないと解決できなさそうです。
実家帰省も明日で最終日、明日でこれが解決できればいいんですが……。
まあ、力尽きたらそのときは本家ブログ改修の方に戻ることにしています。とにかくやることはたくさんある。

そしていま一番大事なのは、このモチベーションを東京に戻ってからも維持すること。
去年も思い返せば年始の実家帰省中は開発作業がとても捗っていました。
が、終電逃しのトラブルやら年度末繁忙期やら生活の基礎が揺らいだことで崩れてしまい、
結果的には東京に戻ってからはむしろクリエイティブな作業が普段より遠ざかっていました。
今年は同じ轍を踏まないようにしたいところ。
その上で、この年始に幕を切った
①ピクチャレ大会開発、②本家ブログ開発、③ゲーム開発チュートリアル、④お絵描きチュートリアル
の４点については少しずつでもいいので歩みを止めないようにしていけたらなと。
そして①②の2025年最初のアプデはなるべく早くクリアしてしまいたい。

半分以上AIにお任せでしかも短期間の突貫工事で作ったためいまのところメンテナンス性が最悪のこのブログ。
なんでそこまで可読性が低いのか、なんとなく原因が分かりました。
それは自分がNext.jsの最新版で変更された仕様の内実をまるっきり勘違いしていたことによります。

同じNext.jsで作ったピクチャレ大会はNext.js ver.13を使って作りました。
当時はプロジェクト作成時のフォルダ構造を「Pages Router」か「App Router」か選択できたのですが、
前者は従来からあるシステムであるのに対して後者は最近できたばかりの最新システム。
前者の方がネットに落ちているノウハウの量も多いだろうと思いPages Routerを選択しました。
しかしその後、公式がApp Routerを全面的に推奨するようになり、
たった１年余りでPages Routerは古いものというような風潮に。
そこで４代目本家ブログの制作にあたってはApp RouterとTypescriptを採用することにしました。
当時はルーティングのフォルダが「pages」か「app」の違いだろうというくらいにしか考えておらず、
しかもAIにほとんどお任せなのでそんな浅い知識でも動いてしまったんですね。

実際にはこれらのシステムの違いは
もはや違うフレームワークと言っても過言ではないほど変更箇所が多く、もっとも大きな違いは
App Routerはページ用のスクリプトが原則すべてサーバーサイドレンダリング（SSR）になるという点です。
SSRとは、サーバーで諸々の変数を処理してからHTMLを出力してクライアントに渡す方式です。
一方、クライアントのブラウザで諸々の処理を行う方式をクライアントサイドレンダリング（CSR）と言います。
Pages Routerでは専用の関数によってそれぞれの役割が明確に分かれていて、
まずgetServerSideProps関数でサーバーサイド処理を実行してその戻り値を取得し、
それに基づいてクライアントサイドで処理する部分を書くというやり方ができました。
これはPHPにおけるwebアプリの書き方にもよく似ていて直感的で分かりやすいです。

しかしApp Routerは全部サーバーサイドで処理するので、そういった従来の書き方が通用しないことになります。
ここで問題になるのが、ページを表示してからボタン押下などに連動して値を変更したいような場合。
そういう処理はクライアントサイドでしか処理できません。
そこで、App Routerではそういう部分はコンポーネント（部品）化して個別に処理することになります。
コンポーネントもデフォルトではSSRですが、
先頭行に"use client";とつけることで特別にクライアントで処理してくれます。
ファイル単位で処理を分けろということですね。
Pages RouterではコンポーネントはSSRできなかったので、そこは進歩した点です。
まあいずれにしろ、Pages Routerを知っているからと言ってApp Routerを使いこなせるわけではなく、
むしろフレームワークとしてイチから学習し直さなければならないレベルで変化点が多いです。
素直にPages Routerで開発するべきだったのかもしれない。

そんなことも理解せずに開発を無理やり進めた結果、
あらゆるページで動的な仕組みを導入できないサイトが完成してしまったというわけです。
そして後々useStateを利用する仕組みを導入しようとしたときに壁にぶち当たり半ば挫折していたわけですが、
その原因はApp Router移行時による仕様変更であると今回ハッキリと分かりました。
とにかく締め切りに追われて見切り発車で進めるとこうなってしまうという教訓ですね。

今回を機にApp Routerの仕様もだいぶ理解できたので、
４代目ブログのフロントエンドはいずれ根本的に作り直すかもしれません。
まあ動的な機能も必要ないテキストサイトなので支障ないと言ってしまえばそれまでなのですが、
そう言ったこととは無関係にとにかく動線も安定性も最悪なので……。
それにApp Routerの仕様を知ったことでにわかにプログラミングしたい欲の復活も感じています。
やはりこういうのは技術に触れることが一番大事なのかもしれない。

そういえば忘れないうちに書いておかねばならない話題がありました。
それは今月初頭のブログ移転に伴う開発作業の反省。
「あまりにも突貫工事だった」という通り一遍な感想的なものは何度か書いていますが、
一方でこれを野放しにすると今後の開発スタイルに悪影響を与えそうな反省点が１つあります。
それはあまりにもAIに頼りすぎたことでメンテナンス性が悪くなったということ。
直感的には、設計から大枠を作るところはまだ人間がやった方がいいのではないかと思っています。
より実践的な関数なんかはプログラムを直に書くよりプロンプトを書いた方が絶対早いですが……。

今回はほぼ２日で本来４ヶ月かかる年間計画のひとつだった４代目本家ブログのフロント部分を完成させました。
確かにこのスピード感は全面的にAIを頼った結果できたことであって、
下手にこだわって人力開発していたらとっくに破綻していたと思います。
そういう意味ではやむを得ない部分もあった、
というのは言い訳でそもそも別作業に時間をかけすぎていたのが諸悪の根源であることは言わずもがな。

そもそも今回は大枠の部分からして自分がイチから考え設計したものではありません。
正確にはそれはAIに任せたのではなく、
フレームワーク開発元であるVerselが提供しているサンプルが元になっています。
初期段階でこのサンプルの中で自分が気に入らない部分は軒並み変えていたつもりでしたが、
構造そのものは（時間が無かったので）変えられなかったんですね。
それで、サンプルの改造はほどほどに中身の実装に取り掛かってしまった。
この改造する部分の実装はAIが書いた割合が多いです。

その結果何が起きたのかというと、機能追加がまともにできないという事態に。
先日のアプデで過去記事一覧をタブで切り替えるだけのボタンを作ろうとしたところ、
構造上の問題でまったく実装できず諦めることになりました。
Next.jsでは、ユーザーの操作に応じて動的に変数の中身を書き換えるためにuseStateという関数が用意されています。
昔のweb屋さんにわかりやすい例で言うとjQueryのようなものですね。
jQueryのようなものなので、これは当然ユーザーのブラウザ上で動作させなければなりません。
そこでコードを明示的にブラウザで動かすためファイルの先頭にuse client;という命令文を書くのですが、
サンプルを改造した元のプログラムは基本的に全部サーバーサイドで処理する設計になっていたため、
これを追加した瞬間に大量のエラーが出てきました。
辿っていくとかなり根本的なところから直さなければならないことが判明し、諦めたという次第です。

同じNext.jsでピクチャレ大会を設計したときはサーバーサイドの処理とクライアントサイドの処理を完全に分離し、
なんならサーバーサイド自体は別コンテナで管理するいわゆる疎結合の設計にしたため、
こういう問題は起こりようがありませんでした。
今回はその辺を曖昧にしたまま内部実装に取り掛かってしまったことで起きたトラブルです。
というか、リリースしてからこんなことが起きていること自体結構やばい。

このままだと本家ブログのフロントエンドがいじればいじるほど壊れて最後には破綻してしまうため、
ピクチャレ大会のような設計にするためにいずれ改めて大改造をすることになると思います。
とはいえブログの仕組み自体はごくシンプルなのでそれほど工数もかからないと思いますけどね。
まあ、とりあえずAI開発時代のいまも基本設計だけはちゃんとしようという教訓でした。
AIが複雑な処理は全部書いてくれるとはいえAIに任せれば勝手に完成品が出てくるのではなく、
あくまでも人間側にもスキルが求められるということは常に戒めておきたいところです。

かつて、webサイトにおいて日本語フォントはユーザーが使うwebブラウザの設定に従うのが普通でしたが、
いまやかなり簡単に日本語フォントを変更することができるようになっています。
自分はGoogle Fontsを利用していますが、独自フォントを適用するのもそんなに難しくなさそう。

今回の本家ブログ移転時、当然フォントについても吟味しました。
99％記事を読むために作るサイトなので、フォント選びはブログ作りにおいてかなり重要な要素と言えます。
しかしこれが思っていたよりかなり難しい。
タイトル等に使う場合、Google Fontsで１文ずつ表示されたサンプルを見比べて良さげなフォントを選べば、
実際に表示されたときに感じる印象も選んだときのそれと大差ないのが普通です。
しかし、長文を前提とする運用の場合は必ずしもそうではありません。
どうしても文字数が多いぶんごちゃつくので、フォントの細かなところまで気になってしまいます。
開設時点の本番環境では「Zen Maru Gothic」という角丸系のゴシック体を採用しましたが、
現在はこれでは長文を読むのに耐えられないということで再び選び直しているところ。

「読みやすさ」だけで言えばもしかしたら日本語に関しては明朝体の方が読みやすいのかもしれませんが、
この手のフォント選びはサイトイメージにも直結してくるため、
明朝体ではお堅いイメージが強すぎるという嫌いもあります。
イメージと読みやすさはおそらく完璧に両立させるのは難しいので、あとはバランスの取り方の問題。
PC版とスマホ版でも見え方がだいぶ違ってくると思うので、とにかく環境ごとに試行錯誤する必要がありそう。

まあ、変に奇をてらわずシステムフォントにするのが無難という考えもありますが……。
本家ブログ最大のライバルは事実上の管理システムでもあるObsidianで、
正直現時点ではリーディングツールとしてもObsidianの方が読みやすく記事間遷移も快適です。
本家ブログは、webという突出したカスタマイズ性を活かして、
いかにしてObsidianを超えられるかどうかが今後の課題です。
そこで変に挫折してしまうと「やっぱり非公開運営でいいか……」となってしまいそうなのが怖い。
まあでも、やっぱり公開運営の方が言葉の選び方等々ちょっとしたところで心構えの変化を感じるし、
こっちの方が良い文章を書けそうではあります。

ちなみにこのブログを書いているときは半角91文字を目安に改行しているのですが、
md変換の都合でその改行文字は反映されず、
サイトに表示されるときはパラグラフごとにまとまった表示となります。
これももしかしたら読みやすさにかなり影響を与えているのかも。
ただ、スマホ表示時はパラグラフでまとまっていた方が読みやすいんですよね。
WordPress時代はbrbrbrというプラグインで無理やり改行を書いたまま反映させていましたが、
今回もPC版に関しては似たような施策が必要かも。

今週は改めて日曜日の重要性を噛み締めるような一週間だったと思います。
実は一昨日の金曜日は有休を取りました。
と言うのも朝起きたらピクチャレ大会絡みの問い合わせが来ていて、どうもアカウントの作成ができないと。
寝ぼけ眼で本番環境でアカウント作成をしようとしてみると、確かにできない。
これはもしあらゆるユーザーの新規登録が同様にできないのであれば由々しき事態です。
いつからかずっとアカウント作成ができなくなっていた可能性は否定できない。
そうだとするとお詫び声明を出さざるを得ない大変な失態で、当然ながら早急に直す必要があります。

しかし今週末は別件でイベント準備のための開発作業をしなければならないため、
少なくとも土曜日は動けない。とすると今日の退勤後90分のリミットしか残されていませんが、
当然ながら90分で解決できる保証も無い。かといって日曜まで後回しにするのも……。
一方、仕事の方はまったく忙しくなく出勤人数も少ないプレミアムフライデー。
自分がこの日予定していたタスクも全然大したものではないので比較的暇なことが分かりきっていました。
まあ、強いて言えばこちらも後回しにできないこの日消化すべきタスクがあったのですが……。
別の人にお願いすればできなくはないし、内容も引き継ぎ資料作成済みでめちゃくちゃ簡単です。
さすがにここまで条件が揃っていれば仕事よりもプライベートを優先すべきだろうという結論に至りました。

有休を１日消費して欠勤連絡を済ませ、一時は完全フリーになった平日の朝09時。
このときの開放感はなかなかのものでしたが、まだアカウント作成問題を解決できていないので安心はできません。
その後、朝食→カフェ→帰宅して昼寝→昼食→カフェと作業場を２店舗ハシゴして４時間ほど作業した結果、
「すべてのユーザーが登録できなくなっているわけではない」という結論に至りました。
少なくともコードに起因する不具合ではなく、直近で新規ユーザーの登録実績はあるようです。
ただ、タイムスタンプのやり方が特殊なためそのデコードに一手間かかったのと、
結局登録できなくなっている特定ユーザー関連の不具合は完全には解消できていないため、
緊急タスクから格下げにはなりましたが以前として直近の大きなタスクにはなりそうです。

まぁ、とりあえず致命的な不具合でないことが分かってひと安心。
土曜日は無事にイベント前必達のタスクも消化して、イベント自体も無事に終了。
ひとまず今週やるべきことを全部終わらせた上で迎えた日曜日の開放感は、これまたなかなかのものでした。
なんというか、日曜日って本来こういうものなんだろうなと。
いままでは計画のバランス感覚が悪かったのもあって365日24時間タスクに追われているような気分だった上に、
休日は目覚めたら夕方付近ということも珍しくないような悪質な不眠症に悩まされていたこともあり、
いわば休日を休日らしく迎えるということが体感的に皆無でした。
計画のバランス感覚（願望ベースのタスクをスキル面から正直に向き合って「できる」タスクに昇華しつつ、
自己実現の歩みも進めるというようなイメージ）も、生活リズムの正常化もごく最近実現したことであり、
その果実としての一週間のメリハリを実感したのは本当に今週が初めてだったんじゃなかろうか。
それこそ先日の三連休もリリースに追われていてこんな感覚は皆無でしたしね。

まぁ、突発的な有休取得によって若干ブーストがかかった感じはしますが、
明らかにQOLの高さを実感しているのでどうにかこれを維持したいところです。