GW に Bun ・ Hono ・ Astro を並べた僕の素振り記録

本番に繋げない約束が触る勇気をくれた

気になっている技術がある。
でも、案件で使えるかどうか分からない。
学習コストを考えると、後回しにしてしまう。

——そんな経験、ありませんか？

今年の GW、僕は一つの約束をしてから、3 つの技術を並べて触りました。

「本番に繋げなくていい」

その一言が、ずっと積み上がっていた「いつか触る」の棚を崩してくれました。

知っているが触っていないが積み上がっていた

みなさんの技術リストに、知っているが、ちゃんと触ったことがないものはありますか？

僕にはあります。
しかも、けっこうな量で。

Bun。
Hono の RPC モード。
Astro v3 の Content Collections。

どれも気になっているレベルでは常にありました。
Hono にいたっては記事を何本も書いているのに、RPC モードだけはずっと「次の機会に」のままになっていた。

なぜ触れないのか、自分に問いかけてみると答えは同じでした。

フリーランスの判断軸で技術選択をしているのが、逆に足枷になっていたのです。

今年の GW 創作合宿で個人開発を進めながら、ふと気づいた。

「合宿の空き時間で "触るだけ" をやればいい」

素振り。
本番に繋げない、一発でマスターしなくていい。
ただ手を動かすだけの時間。

——その言葉が浮かんだとき、不思議と気持ちが軽くなりました。

学習が義務になった瞬間、 手が止まる

少し前に「毎日やらなきゃに疲れた僕が、ルーティンを組み直した話」を書きました。

ルーティンが義務に変換されると、続けるほど息苦しくなる——という話です。

技術学習も、同じパターンに落ちていました。

Bun を学ぶと決めた瞬間に、脳が「習得するまでやり切らなければならない」に翻訳してしまう。

入口が高くなる。
始めるのが怖くなる。
また後回しにする。

——気になる技術の棚が積み上がっていくのに、手を伸ばせない状態が続いていました。

Go 言語を選んだ理由の記事で書いたことがあります。

「翼を増やす感覚」
——今すぐ案件に使わなくても、知っておくことで引き出しが増える。

頭で分かっていても、学習という言葉にセットされた義務感が、最初の一歩をためらわせていたのです。

本番に繋げない約束が入口を変えた

転機は、GW の創作合宿 3 日目の夜でした。

tsurilog の仕様を一つ固めたあと、少し時間が余った。
Obsidian を開いて「やりたいことリスト」を眺めると、

「Bun を試す」
「Hono の RPC を触る」
「Astro の型推論をちゃんと見る」

が並んでいました。

「今じゃなくていい」と思う癖が出かかったとき、あるフレーズが浮かんだのです。

「素振りでいい。」

野球でも剣道でも、素振りは本番を想定しない。
フォームを確認する。感触を覚える。それだけでいい。

今日触っただけで前進という感覚は、創作合宿の前進の定義を変える体験で身についていました。

この連休中、個人開発で何度も完成じゃなく前進を繰り返してきた。
技術学習も同じ定義でいいんだと気づいた瞬間、3 つのターミナルウィンドウを並べていました。

【素振りで気づいたこと】 3 技術のファーストインプレッション

3 時間ほど、3 つを並べて触った記録を正直に書きます。

【Bun】 速さは感情だった

bun install を実行したとき、正直に言うと笑ってしまいました。

node_modules の解決が終わる前にコーヒーを淹れる動作が成立しないような速さでした（笑）

以前「環境構築で一日が溶けるのが怖かった」と書きました。
Node.js のバージョン確認から始まって、PostgreSQL のインストール、接続文字列の調査——そんな月曜が何度もあった。

Bun の速さは、その記憶と対比されて、体感を超えた感情として刺さりました。

一方で、tsurilog の package.json を npm → bun に切り替えようとしたとき、Supabase JS クライアントの一部 API が期待通りに動かなかった。

30 分近くデバッグして、「移行コストはゼロじゃない」を体で確認しました。

でも、それが分かったことが収穫です。
「本番に持ち込む前に、詰まりポイントを知れた」
——これが素振りの意味でした。

【Hono RPC モード】 型が契約から配達になった

以前「Next.js × Hono の責務分担を整理した記録」で、型の食い違いによる深夜デバッグを書きました。

API のレスポンスに createdAt を追加した。
フロントは created_at を期待していた。
型として残っていないから、ランタイムで発覚する。

「言った言わない」を防ぐには、型を契約として明文化するしかない——その結論に至って以来、型契約の書き方は整えてきました。

でも RPC モードの hc() を触った瞬間、感覚が変わりました。

型をどちらかが定義して、もう一方が使うのではなく、型ごとクライアントに渡す。

フロントが API の型を問い合わせる必要がなくなる。
型は契約から配達になった感覚。

「これがあれば、あの深夜デバッグの半分は起きなかった」

そんな思いが湧いてきて、素振りのつもりが 1 時間以上触っていました（汗）

【Astro v3 Content Collections】 文章が型を持つコンテンツになった

自分のブログをすでに Astro で運用しています。
「書くことに集中したい、フレームワークの重さを脱ぎ捨てたい」というブログ記事に書いた通りの動機で選んでいます。

ただ、Content Collections への移行は「動いているものを壊すのが怖い」という理由でずっと後回しにしていました。

今回、defineCollection でスキーマを書き直してみた瞬間—— Markdown の frontmatter が型安全になる。

「ただの文章ファイルが、型を持つコンテンツになった」感覚がありました。

書くことと作ることがつながる瞬間。
Astro が好きな理由が、また一つ増えた気がします。

詰まりポイントも正直に書くと、既存 frontmatter のキー名と新スキーマのキーが 10 箇所近くずれていて、型エラーが大量に出ました。

これは移行の作業量が事前に見えたという意味で収穫でした。
本番移行をいきなり始めていたら、深夜に後悔していたはずです。

素振りという入口設計

3 技術を触ってみて、気づいたことをまとめます。

学習が止まるのは、意志が弱いからじゃない。
入口の設計が間違っていた。

「学ぶ → マスターする」という一本道が前提になっているから、入口が高くなる。
「触る → 感触を覚える」という素振りの定義に変えるだけで、入口が地面の高さになる。

フリーランスとして技術を選ぶとき、本番で使えるかという軸は大切です。
その軸だけで判断していると、「試したことがない技術を試したことがないから選べない」というループに落ちる。

素振りは、そのループを一時的に外す設計です。

本番に繋げない約束をする。
3 時間だけ触る。
詰まっても責めない。
「知らなかった」が「知っている」になっただけで前進。

この定義を先に持っておくと、「気になるが触れない技術の棚」が少しずつ崩れていきます。

3 技術それぞれの次の一手と詰まりポイント整理

ここからは、今回の素振りで見えた「ファーストステップ・詰まりポイント・次の一手」を整理します。

同じ技術が気になっている方の参考になれば嬉しいです。