最近いろいろ触っていたので、一度整理しておきます。
2026年5月後半から6月中旬くらいまでの話です。
ブログを直したり、昔の記事を増やしたり、記事編集ツールを作ったり、ブラウザゲームを動かしたり、小さい実験をいくつか進めたりしていました。
こうして並べるとそれなりにやっているんですが、放っておくとすぐ忘れます。
なので、現時点の棚卸しです。
ブログ側をかなり触った
まず ryus.dev です。
このサイトは今、Go で書いた静的サイトジェネレータで Markdown を HTML にしています。
最初は「自分のブログだし、静的に吐ければいいか」くらいだったんですが、記事を増やし始めると、生成まわりをちゃんと持っておきたくなりました。
最近は、過去にやっていた開発を GitHub の履歴から拾って、薄かった記事を加筆していました。
ブログには書いていなかったけど、実際には private repo でいろいろ作っていた時期があります。
そのままだとタイムライン上では何もしていないように見える。
でも実際には、EC、Cloudflare Workers、OpenAI API、Hono、管理画面、AI エージェント、ゲーム、分析ツールなどを触っていました。
なので、コミットや README に残っている範囲で、記事として自然に残せるものを埋めています。
ここで気をつけたのは、実在のリポジトリ名や固有事情をそのまま出しすぎないことです。
個人の実験ならまだいいんですが、仕事やクライアントワークに近いものは、具体名よりも「その時に何を考えたか」を残した方が安全です。
記事編集ツールも作った
もうひとつ大きかったのが、記事編集ツールです。
Markdown を直接編集してもいいんですが、過去記事をまとめて読み直すと、行ごとにコメントしたり、あとから校正指示を入れたりしたくなります。
そこで Redfine Editor というローカル用の編集画面を作りました。
やりたいことは単純で、
- 記事をブラウザで読む
- 気になる行にコメントする
- 自由記述で校正方針を書く
- AI に直してもらう
- 最後に Markdown へ反映する
という流れです。
最初から完璧な CMS にしたいわけではありません。
むしろ、Markdown ファイルはそのまま置いておいて、編集の補助だけを別画面に逃がしたい。
これくらいの距離感がちょうど良さそうでした。
AI 校正も、記事本文だけ投げるより、行コメントや自由記述の指示を一緒に渡せる方が使いやすいです。
「ここは当時の温度感を残したい」
「このへんは具体名をぼかしたい」
「これは説明しすぎない」
みたいな指示を、記事ごとに残せるのが良いです。
ブラウザゲームも進めた
ブログ以外では、ブラウザゲームも触っていました。
もともと仕様メモだけあったものを、実際に遊べる形まで持っていく作業です。
Vite、Preact、TypeScript で作って、テストも足しました。
こういうゲーム系の実装は、普通の業務アプリと違って、動いた後に「楽しいか」が残ります。
ロジックとしては成立していても、操作がよく分からないとか、進んでいる感じが薄いとか、見た目にワクワクしないとか、そういうところで一気に弱くなる。
なので最近は、コアの動作を作ったあとに、UX や進捗フィードバックの課題をタスクとして残すようにしました。
ここは今までより少し見方が変わったところです。
昔なら「とりあえず動いた」で終わっていたと思います。
今は、動いたあとに、
- 何をすればいいか分かるか
- 進んでいる感覚があるか
- 失敗した時に納得できるか
- もう一回やりたいと思えるか
くらいまでは見たいです。
とはいえ、最初から全部作ると重い。
まず動かして、気になるところを backlog に落とす。
この順番が良さそうでした。
小さい実験置き場も増えている
あと、実験置き場もかなり使っています。
AI エージェントをブラウザから操作する小さいハブを作ったり、Shopify まわりのテーマやアプリ構成を試したり、株の銘柄選定っぽいものを AI に考えさせたりしていました。
このへんは、ひとつひとつを記事にするほど固まっていないものも多いです。
でも、あとから見ると、
「この時期は Codex app-server をどう使うかを見ていた」
「Shopify のテーマとアプリを分けて考えようとしていた」
「AI に判断を任せる時、どこまで根拠を出させるかを気にしていた」
みたいな流れが見えます。
小さい実験は散らかりやすいですが、散らかったままでも残しておくと、あとで別の実装につながることがあります。
このブログ自体も、そういう断片をあとから拾う場所にしたいです。
運用寄りの作業もしていた
アクセス解析まわりでは、訪問者数のレポートを出すコマンドを整えたりしました。
こういう作業は派手ではないですが、あとでかなり効きます。
数字を見たい時に毎回コードを読んで実行方法を思い出すのはしんどい。
コマンドとして残しておくと、次に見たい時にすぐ使えます。
CLI やビルドツール系の実験でも、設定ファイルを省略できるようにしたり、テストを直したり、アセットの扱いを見直したりしていました。
どれも単体では小さいです。
でも、小さいツールほど「毎回ちょっと面倒」を減らしておくと使いやすくなります。
おわり
こうして見ると、最近は新しいものをひとつ作るというより、作るための周辺を整えていた感じがあります。
ブログを書くためにブログを直す。
記事を直すために編集ツールを作る。
ゲームを作るために、遊びやすさの課題を見えるようにする。
AI を使うために、指示や結果の受け渡しを考える。
まあ、遠回りといえば遠回りです。
でもこの形にしておくと、あとで記事にも実装にも戻りやすそうです。
ひとまず 2026-06-15 時点では、ここまで。