Orange's Blog

Netlifyで独自ドメインに移行したらSERVFAIL — 委任は正しく、DNSゾーンが無かった

Mon, 21 Sep 2026 00:00:00 GMT

import MyComment from "@components/misc/MyComment.astro";

この記事が扱う症状

以下に心当たりがある人向けです。

レジストラでネームサーバーを変更したのに、ドメインが引けない
dig が status: SERVFAIL を返す
権威サーバーに直接聞くと status: REFUSED が返る
なのにレジストリの委任は正しい4本が入っている
レジストラで保存したはずのカスタムネームサーバーが、いつの間にか標準に戻っている
Netlify で primary domain を設定したのに、*.netlify.app が 200 を返し続ける
Search Console でサイトマップを送信すると「サイトマップアドレスが無効です」

結論から言うと、SERVFAIL の原因は Netlify 側に DNS ゾーンが作られていなかったことでした。ネームサーバーは正しく向いていて、向いた先が空っぽだった。

やろうとしたこと

Netlify の *.netlify.app サブドメインで運用していたこのブログを、独自ドメインに移すだけの作業です。

<MyComment> このブログではまだnetlifyのサブドメインですが、ちゃんとドメイン買ったほうがいいかな。 </MyComment>

ドメインは Squarespace（旧 Google Domains）で .dev を取得。DNS は Netlify DNS に任せる構成にしました。手順としては「レジストラでネームサーバーを Netlify のものに変える」だけのはずでした。

実際には4回ハマりました。順番に書きます。

症状1: 委任は通っているのに SERVFAIL

ネームサーバーを dns1〜4.p02.nsone.net に設定して保存。しばらく待ってから引いてみると、何も返ってきません。

$ dig A orangevaper.dev @1.1.1.1
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 38097

「まだ伝播していないのだろう」と思いがちな場面ですが、SERVFAIL は伝播待ちの顔ではありません。委任先が見つからないなら NXDOMAIN、委任が未反映ならそもそも古い応答が返ります。SERVFAIL は「委任先に聞きに行ったが、まともな答えが得られなかった」という意味です。

そこで、公開リゾルバを信用せずにレジストリへ直接聞きます。.dev の TLD サーバーに +norecurse で問い合わせると、レジストリに登録されている委任そのものが見えます。

$ dig NS orangevaper.dev @ns-tld1.charlestonroadregistry.com +norecurse

;; AUTHORITY SECTION:
orangevaper.dev.	10800	IN	NS	dns1.p02.nsone.net.
orangevaper.dev.	10800	IN	NS	dns2.p02.nsone.net.
orangevaper.dev.	10800	IN	NS	dns3.p02.nsone.net.
orangevaper.dev.	10800	IN	NS	dns4.p02.nsone.net.

委任は正しく通っています。レジストラ側の設定は問題なし。

では向き先はどうか。権威サーバーに直接聞きます。

$ for ns in dns1.p02.nsone.net dns2.p02.nsone.net dns3.p02.nsone.net dns4.p02.nsone.net
      dig SOA orangevaper.dev @$ns +norecurse
  end

dns1.p02.nsone.net     status: REFUSED
dns2.p02.nsone.net     status: REFUSED
dns3.p02.nsone.net     status: REFUSED
dns4.p02.nsone.net     status: REFUSED

4本とも REFUSED。

REFUSED が意味すること

ここが分かれ目でした。3つのステータスは別物です。

ステータス	意味
`NXDOMAIN`	そのゾーンは持っているが、その名前は存在しない
`SERVFAIL`	問い合わせの過程で失敗した（DNSSEC 不整合、上流が無応答、など）
`REFUSED`	そのゾーン自体をホストしていない。答える立場にない

つまり NS1 は「orangevaper.dev なんて知らない」と言っています。ネームサーバーは向いているのに、向いた先にゾーンが存在しない。だから公開リゾルバは委任をたどった先で門前払いされ、SERVFAIL を返していたわけです。

原因は単純でした。Netlify で DNS ゾーンを作っていなかった。

Netlify は「サイトにカスタムドメインを追加する」のと「Netlify DNS のゾーンを作る」が別の操作です。前者だけやってネームサーバーを向けても、NS1 側には何も無い。

<MyComment> ここのことですかね </MyComment>

Domain management の Add a domain → Add a domain you already own でドメインを追加したあと、別途 Set up Netlify DNS を実行する必要があります。この2段構えが分かりにくい。

ちなみにこの時点で Netlify の画面は「update your DNS records at your registrar」（レジストラで DNS レコードを更新してください）と案内してきます。これは Netlify DNS を使わず、レジストラの DNS に A レコードと CNAME を手で足す前提の案内です。ネームサーバーをすでに NS1 に向けてしまっている場合、この案内どおりに動くと迷子になります。

症状2: 払い出されるネームサーバーはゾーンごとに違う

ゾーンを作ると、Netlify が4本のネームサーバーを表示します。ここで表示されたのは:

dns1.p04.nsone.net
dns2.p04.nsone.net
dns3.p04.nsone.net
dns4.p04.nsone.net

p02 ではなく p04 でした。

NS1 のネームサーバーは pXX の部分がゾーンごとに割り当てられます。ドキュメントや他人のブログ記事に載っている値をそのままコピペすると、存在しないゾーンを指すことになる。症状1で見た REFUSED は、まさにこれが重なっていた可能性もあります。

ゾーンを作ったあと p04 に直接聞くと、ちゃんと答えが返ってきました。

$ dig A orangevaper.dev @dns1.p04.nsone.net +norecurse +short
52.74.6.109
13.215.239.219

ゾーンは存在し、Netlify の A レコードも入っている。あとはレジストラ側を p02 から p04 に直すだけです。

症状3: 保存したはずのネームサーバーが標準に戻る

p04 に入れ替えてもらって、確認します。

<MyComment> p04に入れ替えました、確認お願いします </MyComment>

$ dig NS orangevaper.dev @ns-tld1.charlestonroadregistry.com +norecurse

orangevaper.dev.	10800	IN	NS	nsd1.squarespacedns.com.
orangevaper.dev.	10800	IN	NS	nsd2.squarespacedns.com.
orangevaper.dev.	10800	IN	NS	nsd3.squarespacedns.com.
orangevaper.dev.	10800	IN	NS	nsd4.squarespacedns.com.

p04 どころか p02 ですらなく、Squarespace の標準ネームサーバーに戻っていました。

さらに厄介なことに、この状態では名前解決が成功します。ただし返ってくるのは Squarespace のパーキング用 IP で、www は ext-sq.squarespace.com を向いている。「ドメインは生きているが、まったく別のところを指している」という、SERVFAIL より気づきにくい状態です。

原因はレジストラの UI でした。ネームサーバーの設定画面には「Squarespace のネームサーバーを使う」と「カスタムネームサーバー」の切り替えがあり、カスタム側を明示的に選んだ状態で保存しないと標準に差し戻される。保存直後の画面では入力した値が見えているので、成功したように錯覚します。

入れ直してもらって、今度は通りました。

<MyComment> ちょっと手間取ったからｗどうでしょうか </MyComment>

$ dig NS orangevaper.dev @ns-tld1.charlestonroadregistry.com +norecurse
orangevaper.dev.	10800	IN	NS	dns1.p04.nsone.net.
（以下 dns2〜4）

$ dig +short A orangevaper.dev @8.8.8.8
52.74.6.109
13.215.239.219

証明書も自動で発行され、https:// で開けるようになりました。.dev は HSTS preload 済みで HTTPS 必須なので、証明書が出るまでは「繋がらない」ように見える点も覚えておくと焦らずに済みます。

症状4: primary domain を設定しても netlify.app は 301 されない

ここは私が説明を間違えたところです。

Netlify で「primary domain を独自ドメインに設定すれば、旧 *.netlify.app からは自動で 301 が張られる」と思っていました。実際に設定してもらって確認すると:

$ curl -sSI "https://oranges-blog.netlify.app/?cb=12345"
HTTP/2 200
age: 0
cache-control: public,max-age=0,must-revalidate
server: Netlify

200 が返り続けます。 しかも age: 0。CDN のキャッシュではなく origin から直接返ってきている、つまり仕様としてそうなっている。

紛らわしいのは、www → apex の 301 はちゃんと効くことです。

https://www.orangevaper.dev/       -> 301  https://orangevaper.dev/
https://oranges-blog.netlify.app/  -> 200

答えは Netlify の管理画面自身が書いていました。

Your project is always accessible at a netlify.app subdomain

always。primary domain を何に設定しようと、netlify.app サブドメインは常に生き続けて内容を返します。これを放置すると、新旧2つの URL で同じ内容が配信される＝重複コンテンツです。

対策は netlify.toml に自分で書きます。

[[redirects]]
  from = "https://oranges-blog.netlify.app/*"
  to = "https://orangevaper.dev/:splat"
  status = 301
  force = true

force = true が要ります。これが無いと、同じパスに静的ファイルが存在する場合はそちらが優先されてリダイレクトが効きません。今回はまさに全パスにファイルが存在するので、付けないと何も起きません。

なお from にドメインを含むフルURLを書けるのは Netlify の仕様です。deploy-preview-N--oranges-blog.netlify.app はホストが違うので、デプロイプレビューには影響しません。

反映後:

oranges-blog.netlify.app/                    -> 301  orangevaper.dev/
oranges-blog.netlify.app/posts/<slug>/       -> 301  orangevaper.dev/posts/<slug>/
oranges-blog.netlify.app/rss.xml             -> 301  orangevaper.dev/rss.xml

パスもクエリも保持されます。RSS も転送されるので、旧 URL で購読していた人もそのまま追従します。

テーマが canonical を出していないと逃げ場がない

このブログが使っている Fuwari テーマは <link rel="canonical"> を出力していませんでした。canonical があれば「正規 URL はこっち」と伝えて重複を緩和できますが、それが無い以上、301 が唯一の防御になります。

移行前に自分のテーマが canonical を出しているか確認しておくと、判断が早くなります。

$ grep -o 'rel=canonical[^>]*' dist/index.html
（何も出なければ未出力）

ビルド後の HTML が minify されていると属性のクォートが落ちるので、rel="canonical" で grep すると空振りします。これで一度「出ていない」と誤判定しかけました。

症状5: ドメインプロパティのサイトマップは完全URLが要る

最後は Search Console です。独自ドメインは Search Console 的にはまったく別のサイトなので、新規にプロパティを追加します。

サブドメインもプロトコルもまとめて扱えるドメインプロパティを選びました。所有権の確認は apex の TXT レコードです。

$ dig +short TXT orangevaper.dev @8.8.8.8
"google-site-verification=..."

Netlify DNS 側で TXT を足すとき、Name は @ を入れます（空欄だと必須エラー、ドメイン名を入れると orangevaper.dev.orangevaper.dev になって通りません）。

<MyComment> サイトマップですが、送信してないかも！ </MyComment>

所有権が通ったあと、サイトマップを送信しようとすると弾かれました。

サイトマップ アドレスが無効です

入力したのは sitemap-index.xml。URL プレフィックスプロパティなら、入力欄の左にドメインが固定表示されていて相対パスで通ります。しかしドメインプロパティには固定のプレフィックスが無い（サブドメインもプロトコルも全部含むため）ので、完全な URL が必要です。

https://orangevaper.dev/sitemap-index.xml

これで通りました。送信直後は「取得できませんでした」「検出されたページ数 0」と表示されますが、Google がまだ取りに来ていないだけです。

診断の型: dig を上から降りる

今回のハマりは全部、どの段で崩れているかを切り分けるだけで原因が一意に決まりました。上から順に3段です。

# 1. レジストリに直接（委任そのものを見る。リゾルバのキャッシュを一切挟まない）
dig NS example.dev @ns-tld1.charlestonroadregistry.com +norecurse

# 2. 権威サーバーに直接（ゾーンが存在するか）
dig SOA example.dev @dns1.p04.nsone.net +norecurse

# 3. 公開リゾルバ（実際の利用者から見える姿）
dig A example.dev @1.1.1.1

どこで崩れたか	原因
1 が期待と違う	レジストラの設定が反映されていない（保存できていない・標準に戻された）
1 は正しいが 2 が REFUSED	委任先にゾーンが無い。DNS ホスティング側でゾーン未作成、または NS の割り当てセット違い
1・2 は正しいが 3 が古い	本当に伝播待ち。待てば直る

+norecurse を付けるのが要点です。これが無いと問い合わせ先が勝手に再帰して、自分のキャッシュ越しの答えを返してくることがあります。

.dev 以外の TLD なら、その TLD の権威サーバーを使います（dig NS dev. のように引けば分かります）。

教訓

1. 「保存した」は「反映された」ではない。 レジストラの管理画面は、保存に失敗しても入力値を表示し続けることがあります。信用すべきはレジストリの応答だけです。設定したら dig でレジストリに直接聞く。これを最初からやっていれば、症状3は5分で気づけました。

2. REFUSED・SERVFAIL・NXDOMAIN は別物として読む。 まとめて「引けない」で片付けると伝播待ちに見えてしまい、何時間でも待てます。REFUSED は「ゾーンが無い」という、待っても絶対に直らない種類のエラーです。

3. 管理画面の文言は仕様の宣言として読む。 「Your project is always accessible at a netlify.app subdomain」は、親切な補足ではなく動作の定義でした。期待した挙動が起きないときは、画面に書いてある英語を読み直すのが近道です。

ドメイン移行の手順記事はたくさんありますが、今回踏んだ4つはどれも手順どおりに進めた結果として出てくるものでした。手順が正しいことと、期待どおりに動くことは別です。

Ghosttyのcustom-shaderで文字が読めない — minimum-contrastが効かない理由と、背景だけに効かせるグリフマスク

Fri, 18 Sep 2026 00:00:00 GMT

import MyComment from "@components/misc/MyComment.astro";

この記事が扱う症状

以下に心当たりがある人向けです。

Ghostty に custom-shader を設定したら、背景は綺麗になったが文字が読めない
文字が微妙に波打つ、にじんで見える（water.glsl 系のシェーダー）
黒背景が灰色や緑に持ち上がって、コントラストが落ちる（noise.glsl / mnoise.glsl 系）
minimum-contrast を上げても何も変わらない
dev.to の記事どおりに noise.glsl を取ろうとすると 404 が返る
config に Transparency 14 や Blur ON と書いてあって、起動時にエラーになる

結論を先に書きます。custom-shader はポストプロセスです。 描画済みのターミナル画面が iChannel0 として渡ってくるので、minimum-contrast のようなターミナル側の設定はシェーダーより前に評価され、届きません。可読性を戻すならシェーダー側で、エフェクトを背景ピクセルにだけ乗せるのが正解です。

前座: iTerm2のUI表記が混ざったconfig

そもそもの発端は、起動のたびに config のエラーが出ることでした。原因は2行です。

Transparency 14
Blur ON

iTerm2 の設定画面の表記を、メモのつもりで書き写して行頭の # を忘れたものでした。Ghostty の config は key = value 形式しか受け付けず、Transparency も Blur も存在しないキーなので、そのまま読み込みエラーになります。透明度とブラーの実体は直後の background-opacity / background-blur が担っていたので、この2行はコメント化するだけで済みました。

+validate-config が exit 0 で通るか、で確認できます。ここまでは前座です。

シェーダー背景を入れたら、文字が読めなくなった

config が直ったので、ついでにフラグメントシェーダーを背景にすることにしました。出典は hackr-sh/ghostty-shaders です。

ここで最初のつまずき。紹介記事にある noise.glsl は、今このリポジトリに存在しません。 mnoise.glsl にリネームされています（中身は simplex noise で、記事のスクショにあるオーロラ状の層はこれです）。raw の URL を叩いても 404 なので、記事のとおりに進めると最初のダウンロードで止まります。

mnoise.glsl と water.glsl を取ってきて、config に追記しました。

custom-shader = shaders/mnoise.glsl
custom-shader = shaders/water.glsl
custom-shader-animation = true

⌘⇧, （reload_config）でリロード。オーロラと水面のリップルが両方出て、背景は狙いどおりになりました。そして文字が読めなくなりました。

雰囲気は最高です。ただ、左のファイルツリーもコメント行も、緑がかった帯に溶けかけています。これで一日コードを読む気にはなれません。

最初の処方は、外れだった

真っ先に出した処方は minimum-contrast = 1.1 でした。背景色に対して文字色を自動で持ち上げてくれる設定で、名前からして今回の症状にぴったりに見えます。

入れて、リロードして、何も変わりませんでした。

理由はシェーダーの立ち位置にあります。custom-shader はポストプロセス、つまりターミナルの描画がすべて終わったあとの画面を1枚の画像として受け取り、加工して出力します。シェーダーの中の iChannel0 がその画面です。

vec4 src = texture(iChannel0, uv);   // ← 描画済みのターミナル画面

一方 minimum-contrast は、Ghostty が文字を描く段階で文字色と背景色を比較して働きます。シェーダーが後から背景を明るくした分は、その比較に入っていません。 設定としては正しく効いているのに、効かせたい場所に届いていない。

設定値が正しいのに現象が直らないときは、たいていこのパターンです。

真犯人は、シェーダーの合成方法だった

登場人物を見直すと、犯人はシェーダーの最後の1行にいました。2本のシェーダーが、別々のやり方で可読性を削っていたのです。

mnoise.glsl — 加算合成

fragColor = vec4(ghosttyCol.rgb + mix(col4, fcol, ...), ghosttyCol.a);
//                              ^ 加算

ターミナルの色に足し算しています。黒背景が灰緑に持ち上がり、暗い文字色との差が潰れる。背景が明るくなるのではなく、画面全体が持ち上がるのがポイントです。

water.glsl — UVずらし

vec2 tc = vec2(cos(c)-0.75,sin(c)-0.75)*0.04;
uv = clamp(uv + tc,0.0,1.0);
fragColor = texture(iChannel0, uv);   // ← ずらした座標で画面をサンプリング

こちらは色ではなくサンプリング座標そのものをずらしています。水面感の正体はこれですが、iChannel0 には文字も入っているので、グリフごと歪みます。 文字がゆらいで見えたのはこのせいでした。

当座の処置として、mnoise.glsl の加算量に STRENGTH = 0.35 を掛け、water.glsl の *0.04 を *0.01 に下げました。これで読めるようにはなります。ただ、どちらも「効きすぎているエフェクトを薄める」だけの対症療法で、文字に手が及んでいる構造は変わっていません。

本命: グリフマスク

そこで、2本を捨てて1本書き直しました。方針はひとつだけです。

輝度でグリフを判定し、エフェクトを背景ピクセルにだけ乗せる。

vec4 src = texture(iChannel0, uv);

// 輝度でグリフを判定する。bg = 1.0 が背景、0.0 が文字。
float lum = dot(src.rgb, vec3(0.299, 0.587, 0.114));
float bg  = 1.0 - smoothstep(GLYPH_LO, GLYPH_HI, lum);

...

// bg を掛けているので、文字の上にはプール色が乗らない
fragColor = vec4(src.rgb + pool * bg, src.a);

dot(src.rgb, vec3(0.299, 0.587, 0.114)) は輝度（明るさ）を出す定番の式です。暗ければ背景、明るければ文字。smoothstep で境界をなだらかにしているので、アンチエイリアスの効いた文字の縁でも段差になりません。あとは bg を掛けるだけで、エフェクトは文字を避けて背景にだけ乗ります。

加えて UV ずらしを完全に廃止しました。これで歪みの経路も消えます。「背景が持ち上がる」「グリフが波打つ」という2つの劣化要因が、両方なくなりました。

背景側は水中の雰囲気を作る4要素で構成しています。コースティクス（水面から差し込む光の網）、水の色、深さによる減光、周辺減光。定数を頭にまとめて出してあるので、見た目はそこだけで振れます。

const float SPEED            = 0.45;  // 水面の揺れる速さ
const float CAUSTIC_STRENGTH = 0.40;  // 光の網の濃さ
const float CAUSTIC_SHARP    = 10.0;  // 網の細さ
const float TINT_STRENGTH    = 0.35;  // 水の色の濃さ
const float DEPTH_STRENGTH   = 0.45;  // 下にいくほど暗くなる量
const float VIGNETTE         = 0.55;  // 周辺減光の強さ
const float GLYPH_LO         = 0.10;  // これ以下の輝度を背景とみなす
const float GLYPH_HI         = 0.30;  // これ以上の輝度を文字とみなす

同じ「水の中」なのに、文字が背景から浮き上がっています。リロードして画面を見た本人の第一声が、この方式の説明として一番正確でした。

<MyComment> これは逆に、文字を浮き出して背景でプールを演出したんですね。<br /> プール底面でテキストが揺れているのもいいけど、可読性優先でいいですね。 </MyComment>

そのとおりです。文字は Ghostty が描いたものがそのまま残り、背景だけが水になる。シェーダーで可読性を確保するのではなく、シェーダーを可読性の外に置く、という考え方です。

GLYPH_LO / GLYPH_HI はカラースキームを変えたときだけ触る値です。明るい背景のテーマを使っているなら、判定を反転させる必要があります。

ついでに分かったこと: 透過している限り、鮮やかな色は出せない

仕上げに色を詰めているとき、こんな注文が出ました。

車の中のアンビエントに使われるような彩度の青がいいかな

やってみて、出ませんでした。WATER_TINT を青主軸に振り、輝度を保ったまま彩度を上げる SATURATION ノブまで足しても、べったりした青になるだけで「ほぼ黒地に鮮やかな青が浮く」感じにならない。

理由は透過です。background-opacity = 0.85 にしているので、シェーダーの出力はアルファ 0.85 のまま OS に渡され、デスクトップとの合成はシェーダーより後で行われます。

最終画素 = 0.85 × シェーダー出力 + 0.15 × 壁紙

壁紙の明るい部分が 15% 混ざる。これは明度を上げるだけでなく、彩度も薄めます。 シェーダー側でいくら彩度を上げても、この 15% が白っぽさを混ぜ返してくる。背景に別の絵が透けている限り、原理的に「ほぼ黒地に鮮やかな色」は出せません。

狙った色にならないどころか、SATURATION が光の網まで青く染めてしまい、水面感の正体だった明暗差まで消えました。彩度版は結局そのまま破棄しました。元の青緑（vec3(0.06, 0.30, 0.42)）は緑が乗っているぶん「水を通した光」に見えていて、そちらのほうが素直に綺麗だった、というオチです。

なお、この手の試行錯誤はコミットせずに作業ツリーだけで試すと、git checkout -- shaders/pool.glsl 一発で気に入っていた状態に戻れます。見た目の調整はコミット粒度を細かくするより、この使い方のほうが合っていました。

教訓

設定が効かないときは、その設定が評価される「順番」を見る。 minimum-contrast は正しく動いていました。ただ、シェーダーが背景を明るくするより前に仕事を終えていた。値を上げ下げして粘るのではなく、パイプラインのどこに挟まっているかを確認するのが早道です。

ポストプロセスのシェーダーは、文字と背景を区別しない。 iChannel0 に入ってくるのは合成済みの1枚の画像で、そこに「ここは文字」という情報はありません。素直に書けば文字ごと加工されます。区別したいなら輝度なりで自分で判定するしかなく、逆に言えば判定さえすれば区別できます。

個人ブログのシェーダー紹介記事は、リンク先のリネームまで面倒を見てくれない。 noise.glsl → mnoise.glsl のように、上流が動いている前提で読んだほうがいい。記事を疑う前に、まず今のリポジトリのファイル一覧を見るのが確実です。

LazyVimのsgでgrepできない — 設定は正しく、足りないのはrg / fd / fzfの3本だった

Fri, 18 Sep 2026 00:00:00 GMT

この記事が扱う症状

以下に心当たりがある人向けです。

LazyVim で <leader>sg（Grep (Root Dir)）を押しても何も起きない
<leader>ff のファイル検索も期待どおりに動かない
fzf-lua が「fzf が無い」という趣旨のエラーを出す
シェルで which rg を叩くと反応が返ってくるのに、nvim からは検索できない
確認すると fzf not found や executable("fzf") = 0 になっている
キーマップを調べると正しく割り当たっているので余計に分からない

結論を先に書きます。原因は設定ではなく、外部バイナリの不在です。 LazyVim の検索まわりは Lua プラグインを入れただけでは動かず、rg（ripgrep）・fd・fzf の 3 本が実体として必要です。

brew install ripgrep fd fzf

インストール後は nvim を再起動してください。理由は後述します。

キーマップは生きていた

<leader>sg で grep したいのにできない、というところから始まりました。まず疑ったのは自分の設定です。~/.config/nvim を見ても、キーマップを潰すような記述はありません。

nvim 自身に聞くのが早いので、割り当てを直接出しました。

nvim --headless -c 'lua local m = vim.fn.maparg("<leader>sg", "n", false, true); print(m.lhs, m.desc)' -c 'qa'

<Space>sg	Grep (Root Dir)

設定は正しく入っていました。 <Space>sg が "Grep (Root Dir)" に割り当たっている。つまりキーを押せば LazyVim の grep が呼ばれているはずで、なのに画面には何も出ない。

ここが分かりにくいところです。LazyVim のキーマップはプラグインが読み込まれている限り常に存在します。押しても無反応なとき、キーマップが死んでいるのか、呼ばれた先で失敗しているのかは、キーマップ側を見ても区別がつきません。

登場人物を数える

呼ばれた先で失敗しているなら、失敗しうるのは検索の実体です。nvim から見た外部コマンドの状態を出します。

nvim --headless -c 'lua print("rg", vim.fn.executable("rg"), "fd", vim.fn.executable("fd"))' -c 'qa'

rg 0	fd 0

executable() は「そのコマンドが実行可能か」を 1 / 0 で返します。両方 0。ripgrep も fd も入っていませんでした。

`which rg` は当てにならなかった

ここで一度混乱しました。シェルで which rg や command -v rg を叩くと、反応が返ってくるのです。入っているように見える。

正体はこれでした。

rg () {
	local _cc_bin="${CLAUDE_CODE_EXECPATH:-}"
	...
}

Claude Code がシェルに定義している関数で、実体のバイナリではありません。関数はそのシェルの中にしか存在しないので、nvim から見れば無いのと同じです。だから executable("rg") は 0 のまま。

シェルで見えるのに nvim で動かないときは、シェルに聞かず nvim に聞くのが確実です。ターミナルのプロンプトで確認した結果は、nvim の中の話の証拠になりません。

1回目の修理は、必要だったが足りなかった

ripgrep と fd を入れました。

brew install ripgrep fd

🍺  /opt/homebrew/Cellar/ripgrep/15.2.0
🍺  /opt/homebrew/Cellar/fd/10.5.0

nvim から見ても rg: 1 / fd: 1 に変わりました。設定ファイルは一切触っていないので、再起動すれば効くはずです。

それでも grep はできませんでした。

真犯人は3本目のバイナリ

決め手は調査ではなく、本人の一言でした。

leader sgでgrepできません。fzfがないだとかエラーが表示されます。

エラーが出ていること、そこに fzf と書いてあること。この 2 つが分かった時点で残りは早かったです。

LazyVim はどの picker を使うかを切り替えられます。設定と、実際に選ばれた結果を並べて出します。

nvim --headless -c 'lua print(vim.g.lazyvim_picker, LazyVim.pick.picker.name)' -c 'qa'

auto	fzf

左が設定値、右が解決結果です。auto のままだと、インストール済みのプラグインから fzf-lua が選ばれていました。 そして fzf-lua は、名前のとおり fzf のラッパーです。

which fzf

fzf not found

fzf バイナリだけ入っていませんでした。 ripgrep と fd は 1 回目で入れたのに、3 本目が残っていた。fzf-lua は Lua プラグインだけでは動かず、fzf コマンド本体を呼びます。プラグインは lazy-lock.json に載っていて、更新もされていて、それでも動かない。

3 本それぞれの役割はこうなっています。

バイナリ	効くところ
`rg`（ripgrep）	`<leader>sg` の grep。中身の検索
`fd`	`<leader>ff` のファイル検索
`fzf`	picker が fzf-lua のときの絞り込み UI そのもの

直し方

brew install fzf

🍺  /opt/homebrew/Cellar/fzf/0.74.4

nvim から見えるか確認します。

nvim --headless -c 'lua print("rg", vim.fn.executable("rg"), "fd", vim.fn.executable("fd"), "fzf", vim.fn.executable("fzf"))' -c 'qa'

rg 1	fd 1	fzf 1

3 本とも 1 になりました。ここまで来たら <leader>sg が動きます。

再起動が要る

インストール前から開いていた nvim では効きません。 fzf-lua はバイナリを起動時に探しますし、executable() の結果もセッション内でキャッシュされます。:Lazy reload では足りないので、:qa で閉じて開き直すのが確実です。

brew の caveat は無視してよい

fzf を入れると Homebrew がこう言ってきます。

To use fzf in Vim, add the following line to your .vimrc:
  set rtp+=/opt/homebrew/opt/fzf

これは Vim 本体から fzf を使う場合の話で、fzf-lua には要りません。fzf-lua は $PATH にあるバイナリを直接呼ぶだけなので、~/.vimrc に何か足す必要はないです。

どうしても fzf を入れたくないなら

picker を変える手もあります。telescope.nvim も snacks.nvim も LazyVim には最初から入っているので、lua/config/options.lua に 1 行足すだけで切り替わります。

vim.g.lazyvim_picker = "telescope"

ただし telescope の grep も結局 ripgrep を呼ぶので、rg は必要です。避けられるのは fzf だけです。

教訓

「設定が効かない」ときは、設定より先に依存バイナリを疑う。 LazyVim のキーマップはプラグインが読まれていれば常に存在します。押して無反応でも、それはキーマップが壊れている証拠にはなりません。設定ファイルを読み返すより、executable() を叩くほうが早いです。

which は環境によって嘘をつく。 シェル関数、エイリアス、シェル固有の仕組みは、そのシェルの中にしかありません。判定は、それを使う当人に聞く。nvim の中の話なら nvim に聞く。

1 つ直して直らなくても、その修理が無駄だったとは限らない。 ripgrep と fd は実際に必要で、入れたのは正解でした。足りないものが 1 つとは限らないだけです。「直したのに直らない」と思ったら、さっきの修理を疑う前に、同じ種類の不足がまだ残っていないかを数えたほうが早いことがあります。

そして、エラーメッセージを読めるのは画面の前にいる人だけです。 今回いちばん効いた情報は「fzf がないというエラーが出ている」という一言でした。ログを掘るより早かったです。

Claude Codeのログを数えたら、新しいMacの環境構築で自分は1,014文字しか打っていなかった

Wed, 16 Sep 2026 00:00:00 GMT

ブログのネタを探して、自分のログを掘った

新しい MacBook Pro が届いた日、開発環境のセットアップをほとんど AI に任せました。ghostty を入れて、fish に切り替えて、Neovim が壊れて、直して。

雑に進めたので記録を残していません。後になって「あのやり取り自体が記事になったのに」と悔やんでいたのですが、ログは残っていました。 それも完全な形で。

そして掘り出したログを数えてみたら、自分が思っていたのとだいぶ違う数字が出てきました。

ログはどこにあるか

Claude Code は会話を JSONL で保存しています。

~/.claude/projects/<作業ディレクトリのパスをハイフンにしたもの>/<uuid>.jsonl

ホームディレクトリで作業していたなら ~/.claude/projects/-Users-<username>/ です。1セッションが1ファイル。日付で探すならこう。

find ~/.claude/projects -name "*.jsonl" -newermt "2026-09-14" ! -newermt "2026-09-15"

中身は1行1イベントの JSON です。自分の発言、AI の応答、実行したコマンド、その実行結果まで全部入っています。1セッションで 1.4MB ありました。

そのままでは読めないので、発言とコマンドだけ抜き出すスクリプトを書いて整形しました。

数えた結果

9/14 の2セッション、合計3時間弱。結果がこれです。


自分の発言	32回 / 1,014文字
AI のツール実行	69回

原稿用紙2枚半です。この2枚半で、新品の Mac に Homebrew が入り、ghostty と fish と Neovim と lazygit が入り、デフォルトシェルが変わり、壊れたビルド環境が直っています。

全部載せます

片方のセッション（13発言・392文字）は、全文を貼れてしまう短さでした。

 1. [スクショ] このような感じでnvimがlazyvimを使えてないかもしれないです。
    まず、nvim .じゃなくて、vim .とエイリアスを設定してください。
 2. [スクショ] この問題を解決できますか？
 3. え、どういうことですか？
 4. さっき、ダウンロードしたかもしれない
 5. はい、実行してください
 6. 削除した、確認して
 7. OKだと思います。エラーが出なくなりました。
 8. confyUIをインストールしたいです。shell版がいいです。
    起動したらそのurlを貼り付けるとブラウザでみれるというやつ。
    インストール場所がどこがいいかがわかってないです。
 9. fishようの z をインストールして下さい。
10. macのキーボードを押しっぱなしで再入力のスピードアップを設定したいです。
11. いいえ、単にスピードが遅いので、カーソルの上下度か。
12. 最速の一つ手前に設定してもらえますか？
13. 今のままだとスピードが変わらなくないですか

「confyUI」と打ち間違えていますし、11番は文章になっていません。それでも通じています。

事件は72文字で決着していた

この13発言のうち、3番から7番までの5つ。合計72文字。

3. え、どういうことですか？          (12文字)
4. さっき、ダウンロードしたかもしれない  (18文字)
5. はい、実行してください            (11文字)
6. 削除した、確認して                (9文字)
7. OKだと思います。エラーが出なくなりました。 (22文字)

この72文字の裏で何が起きていたかというと、Neovim の tree-sitter がビルドできない問題の原因究明です。真犯人は Command Line Tools に紛れ込んでいた次期OS向けのベータSDKで、そのせいで Mac 上の C コンパイルが全滅していました（詳細は別記事に書きました）。

自力なら半日は溶けていた種類の問題です。それが72文字。

ただし、4番だけは自分にしか出せなかった

面白いのはここです。

さっき、ダウンロードしたかもしれない

18文字。この一言が無ければ解決していません。

原因の在り処まではAIが調べ切りましたが、「なぜ次期OSのSDKがこのマシンに居るのか」はインストール履歴を追っても出てきませんでした。新品の Mac が来て浮かれて、あちこちから何か入れたという記憶は、本人の頭の中にしかない。

1,014文字のうち、本当に自分にしか打てなかったのは、たぶんこの18文字だけです。残りは「はい、実行してください」でした。

何が残って、何が消えるか

ログを掘っていて気づいたことがもう一つあります。

テキストは完全に残ります。 発言もコマンドもその実行結果も。一方で、貼り付けたスクリーンショットは消えます。 画像は ~/.claude/image-cache/<セッションID>/ に置かれますが、古いセッションのものは残っていませんでした。

9/14 に貼った4枚のターミナル画面は、もうありません。「no changes made」という一見失敗に見える出力をAIが「成功しています」と読み解いた場面など、画で見せたかったものが失われています。

スクショを記事に使う可能性があるなら、貼る前に自分で保存しておく必要があります。 これは今回の一番実用的な教訓でした。

で、自分は何をしていたのか

数字を見た直後は、正直ちょっと笑ってしまいました。1,014文字。「はい、実行してください」の人。

ただ、書き出してみると見え方が変わります。32回の発言のうち、判断を求められて答えているものが大半でした。消していいか、進めていいか、直ったかどうか。AIが自分で決められないことが、きれいに自分のところへ回ってきている。

そして一番効いた18文字は、調べれば分かることではなく、自分しか知らないことでした。

役割分担としては、たぶん正しい。打鍵数が少ないことを恥じる必要はないのだと思います。ただ、それを記録に残しておかないと後から何も語れなくなるというのが、今回いちばん身に沁みたところでした。ログを漁って気づけたのは運が良かっただけです。

あなたの ~/.claude/projects/ にも、たぶん同じものが眠っています。一度数えてみると面白いですよ。

tree-sitterのビルドが失敗する — 犯人はLazyVimではなくmacOSのベータSDKだった

Mon, 14 Sep 2026 00:00:00 GMT

この記事が扱う症状

以下のいずれかに心当たりがある人向けです。

Neovim / LazyVim で tree-sitter のパーサーがビルドできない
nvim の画面に Error during "tree-sitter build" と出る
ビルドを手で再現すると ld: tapi error: malformed file が出る
libSystem.B.tbd:4:20: error: unknown architecture が出る
xcrun --show-sdk-path が、使っている macOS より新しいバージョンの SDK を返す

結論だけ先に書くと、Command Line Tools に次期OS向けのベータSDKが紛れ込んでいるのが原因です。消せば直ります。

新しいMacで、いきなり詰まった

新しい MacBook Pro が届いた日のことです。会社で使っている dotfiles を持ち込んで、Homebrew で nvim を入れ、~/.config/nvim に設定を置いて起動しました。

LazyVim がプラグインを取りに行き、tree-sitter のパーサーをビルドし始めた、そこで止まりました。yaml のパーサーがビルドできない。

新しいマシンで設定を移したばかりです。真っ先に疑うのは自分の設定でしょう。dotfiles の移し方を間違えたか、nvim のバージョンが違うか、LazyVim が新しい nvim に追いついていないか。実際、私も最初はそう思いました。

結論から書くと、全部ハズレでした。

エラーの中身

パーサーのビルドを手で再現してみると、こう出ました。

ld: tapi error: malformed file
/Library/Developer/CommandLineTools/SDKs/MacOSX27.0.sdk/usr/lib/libSystem.B.tbd:4:20: error: unknown architecture
clang: error: linker command failed with exit code 1

ここに nvim も LazyVim も tree-sitter も出てきません。出てくるのは ld、つまりリンカです。C のコードを繋いで実行可能な形にする、コンパイラの最終工程。そこが転んでいる。

ということは、これは nvim の問題ではなく、このMacでCのコンパイルが通らないという問題です。tree-sitter はたまたま C をコンパイルするから巻き込まれただけで、被害者にすぎません。

真犯人

SDK の置き場を覗いて、犯人が見つかりました。

$ ls /Library/Developer/CommandLineTools/SDKs/
MacOSX15.4.sdk
MacOSX26.5.sdk
MacOSX27.0.sdk     ← ???

SDK というのは、macOS 向けにコンパイルするための部品一式です。ヘッダファイルとライブラリの定義が入っていて、OS のバージョンごとに置かれます。

このマシンの macOS は 26.6.2。なのに 27.0 の SDK が居ます。まだ世に出ていないバージョンです。日付を見ると 8/31 でした。

問題はここからです。xcrun は一番バージョンの高い SDK を自動的に選びます。

$ xcrun --show-sdk-path
/Library/Developer/CommandLineTools/SDKs/MacOSX27.0.sdk

27.0 が一つ居るだけで、このマシンの C コンパイルは全部そっちを向く。ところが Command Line Tools 本体のバージョンは 26.6.0 で、その中のリンカは 27.0 の .tbd ファイル（ライブラリの定義を書いたテキスト形式のファイル）を解釈できません。それが tapi error: malformed file と unknown architecture の正体でした。

未来の部品に、現在の工具を当てていた。 噛み合うはずがありません。

決め手は、ログに残っていない情報だった

面白かったのはこの後です。

原因は分かった。しかし「なぜ次期OSのSDKがここに居るのか」は、マシンを調べても分かりませんでした。インストール履歴を追っても決定的なことは出てこない。

決め手になったのは、私の記憶でした。

さっき、ダウンロードしたかもしれない

新しい Mac が来て浮かれて、あちこちから色々入れていたのです。そのどれかがベータの Command Line Tools を連れてきていた。

これ、どれだけログを漁っても出てこない情報です。「そういえばさっき何か入れた気がする」は、本人の頭の中にしかない。エラーメッセージの読解は外注できても、これだけは外注できません。

直し方

ベータSDKを消して、シンボリックリンクも一緒に片付けます。

sudo rm -rf /Library/Developer/CommandLineTools/SDKs/MacOSX27.0.sdk \
            /Library/Developer/CommandLineTools/SDKs/MacOSX27.sdk

消した後、xcrun が正気に戻りました。

$ xcrun --show-sdk-path
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
$ xcrun --show-sdk-version
26.5

この状態で tree-sitter のビルドを流すと、あっさり通りました。LazyVim 側は何も触っていません。

教訓

エラーメッセージに出てくる登場人物を見る。 今回 ld と SDK は出てきましたが、nvim も lazy.nvim も一度も出てきませんでした。それなのに「LazyVim が壊れた」と思い込んでいた。出てこないものを疑って時間を溶かすのは、よくある失敗です。

新しいMacほど、環境が汚れていないとは限らない。 むしろ届いた初日にあれこれ入れるので、身に覚えのないものが紛れ込むのはこのタイミングです。

xcrun --show-sdk-path は、Macでビルドが謎に転んだ時の最初の一手として覚えておく価値があります。 一行で「今どの部品を使おうとしているか」が分かります。

ちなみにこの切り分け、全部で10分ほどでした。自力でやっていたら、まず LazyVim の設定を疑い、nvim を入れ直し、Homebrew を疑い、半日は溶かしていたと思います。

Astro と Next.js 比較：パフォーマンスの違いとそのメカニズム

Tue, 22 Apr 2025 00:00:00 GMT

Astro と Next.js 比較：パフォーマンスの違いとそのメカニズム

はじめに

モダンウェブ開発において、パフォーマンスは非常に重要な要素です。特に E コマースサイトでは、わずか 100 ミリ秒の読み込み時間の違いがコンバージョン率に影響するとされています。この記事では、最新のフレームワークである Astro と一般的に使用されている Next.js のパフォーマンスの違いを解説します。

ハイドレーションの仕組みとその影響

Next.js のハイドレーションモデル

Next.js では、サーバーサイドレンダリング（SSR）によって HTML が生成されクライアントに送信されますが、その後クライアント側で「ハイドレーション」と呼ばれるプロセスが発生します。

このハイドレーションプロセスは以下のように機能します：

サーバーから初期 HTML が送信される
クライアント側で JavaScript がロードされる
ReactDOM.hydrate() が実行され、document.getElementById('__next') などで DOM 要素を特定
React のコンポーネントツリーが再構築され、イベントリスナーが取り付けられる

重要なポイント: Next.js では、ページ全体が一括でハイドレーションされます。つまり、静的なコンテンツ部分も含めて全てのコンポーネントが JavaScript によって管理される状態になります。これが初期表示速度に影響を与える主な原因です。

Astro のアイランドアーキテクチャ

一方、Astro は「アイランドアーキテクチャ」と呼ばれる新しいアプローチを採用しています。これは以下のような特徴を持ちます：

ページの大部分は純粋な静的 HTML として配信（JavaScript なし）
インタラクティブな要素（「アイランド」）のみが選択的にハイドレーションされる
client:load、client:visible などのディレクティブを使用して、いつ/どのようにコンポーネントをハイドレーションするか細かく制御できる

例えば、以下のようなコードでは：

<header>静的なヘッダー部分</header>

<ProductSlider client:load />

<footer>静的なフッター部分</footer>

ProductSlider コンポーネントだけが JavaScript によってハイドレーションされ、ヘッダーとフッターは純粋な HTML のままです。

パフォーマンスの違い

JavaScript ペイロードの削減

Astro のアプローチでは、必要最小限の JavaScript だけがクライアントに送信されます。これにより：

ダウンロードする JavaScript の量が大幅に削減される
パースと実行にかかる時間が短縮される
特にモバイルデバイスでの読み込み時間が改善される

インタラクティブになるまでの時間

Next.js では、ページ全体のハイドレーションが完了するまで完全にインタラクティブにはなりません。一方、Astro では：

静的コンテンツはすぐに表示され操作可能
インタラクティブな要素のみが必要に応じてハイドレーションされる
client:visible などのディレクティブを使用すれば、画面に表示されたときだけハイドレーションを行うことも可能

実装の違い

Next.js のアプローチ

Next.js では、全てのページコンポーネントは基本的に React コンポーネントとして実装されます。サーバーサイドレンダリングにより初期 HTML が生成されますが、クライアント側での完全なハイドレーションが前提となります。

// Next.jsの例
export default function ProductPage({ product }) {
  return (
    <div>
      <Header />
      <ProductDetails product={product} />
      <RelatedProducts products={product.related} />
      <Footer />
    </div>
  );
}

この場合、静的な要素（ヘッダーやフッターなど）も含めて全体が JavaScript でハイドレーションされます。

Astro のアプローチ

Astro では、基本的に.astroファイルは静的 HTML として出力され、必要な部分のみをインタラクティブにすることができます。

---
// .astroファイルのフロントマター部分
import Header from '../components/Header.astro';
import Footer from '../components/Footer.astro';
import ProductDetails from '../components/ProductDetails.jsx';
import RelatedProducts from '../components/RelatedProducts.jsx';

const { product } = Astro.props;
---

<Header />
<ProductDetails client:load product={product} />
<RelatedProducts client:visible products={product.related} />
<Footer />

この例では：

ヘッダーとフッターは純粋な静的 HTML として出力される
商品詳細はページ読み込み時にハイドレーションされる
関連商品は画面に表示されたときにのみハイドレーションされる

まとめ

Astro のアイランドアーキテクチャは、特に初期表示速度が重要な E コマースサイトなどで大きなメリットをもたらす可能性があります。必要な部分だけをインタラクティブにすることで、JavaScript のオーバーヘッドを最小限に抑え、ユーザー体験を向上させることができます。

Next.js は SPA（シングルページアプリケーション）としての柔軟性が高く、全体を JavaScript で制御したい場合に適していますが、そのトレードオフとして初期表示のパフォーマンスが犠牲になる可能性があります。

両者のアプローチを理解し、プロジェクトの要件に合わせて適切な技術を選択することが重要です。特にパフォーマンスが重視されるプロジェクトでは、Astro のアイランドアーキテクチャは検討する価値のある選択肢と言えるでしょう。

LazyVimプラグイン更新レポート - 2025年4月版

Wed, 09 Apr 2025 00:00:00 GMT

LazyVim プラグイン更新レポート - 2025 年 4 月版

今回は LazyVim で<leader> l（Log コマンド）を実行して表示される最新の更新内容を基に、重要な変更点や新機能について AI でまとめました。その内容のメモになります。こういったメモは後から自分でも見返すと勉強になるので、今後もシリーズ化していくと思います。

更新されたプラグインの役割

まず、今回更新されたプラグインがどのような役割を持っているのか簡単に説明します：

blink.cmp: コード補完エンジン - 入力中にコード候補を表示し選択できる
nvim-lspconfig: 言語サーバープロトコル(LSP)設定 - コード解析、補完、定義ジャンプなどの機能を提供
nvim-treesitter: 構文解析ツール - 高度なシンタックスハイライトやコード構造の理解を可能に
fzf & fzf-lua: ファジーファインダー - ファイル/テキスト検索を高速に行える
neo-tree.nvim: ファイルエクスプローラ - ファイルシステムの閲覧と操作
mini.pairs: 自動ペアリング - 括弧やクォートを自動で閉じる
mini.ai: テキストオブジェクト拡張 - コード構造に基づいたテキスト選択の強化
mini.icons: アイコン表示 - ファイルタイプなどに応じたアイコンの提供
gitsigns.nvim: Git 変更表示 - 行の変更状態をエディタ内に表示

更新の概要

今回の更新では、合計 48 個のプラグインのうち、15 個が更新され、9 個がクリーンアップされました。特に注目すべき変更がいくつかあります。

Breaking Changes

Breaking Changes のカウントが 3 から 4 に増加しました。主な変更点は以下の通りです：

mini.icons, mini.ai, mini.pairsなどの mini シリーズプラグインが Neovim 0.9 未満のサポートを非推奨に
nvim-lspconfigが Neovim 0.10 以上を必須に
blink.cmpのいくつかの API が変更

主要プラグインの更新内容

blink.cmp (v1.1.1)

補完エンジンの「blink.cmp」には多くの改善が加えられました：

バージョン 1.1.1 へのアップデート
メニュー描画時のハイライト優先度のサポート
ゴーストテキスト表示時のタブでのメニュー表示機能
マルチバイト文字のメニュー位置の修正
トリガー文字に関する複数の修正

nvim-lspconfig

言語サーバープロトコル設定プラグインの更新：

Neovim 0.10 以上が必要になりました
複数の非推奨関数の廃止予告
新しい LSP サーバーのサポート追加：bqls, rpmspec, just など
Svelte 5 へ移行するためのコマンドを追加

nvim-treesitter

構文解析プラグインの更新：

新しいパーサー（caddy, javadoc）の追加
Python, Svelte, DHall など複数の言語のハイライト機能の改善
YAML ファイルでの Taskfile の Bash 挿入サポート

fzf & fzf-lua

ファジーファインダーの更新：

fzf が 0.61.1 にアップデート
新しいフラグと機能の追加
fzf-lua が複数のプロファイルをサポート
バッファ範囲検索機能の追加

neo-tree.nvim

ファイルエクスプローラの更新：

大きなディレクトリからのすべてのファイル読み込みの修正
ファジーファインダーの閉じるコマンドの追加
ウィンドウ幅の復元機能の修正

mini.pairs

マルチバイト文字のペアサポートが追加
コード最適化と修正

全体的な改善

パフォーマンス：いくつかのプラグインで処理速度の向上が見られます
バグ修正：多くの小さなバグが修正されています
互換性：Neovim 0.10 および 0.11 との互換性が向上

更新後の注意点

Neovim のバージョン確認：一部のプラグインは Neovim 0.10 以上を要求するようになりました
設定の見直し：Breaking Changes がある場合、関連する設定の見直しが必要かもしれません
新機能の活用：追加された機能を積極的に活用することで、編集効率が向上します

まとめ

今回の更新では、多くのバグ修正と機能追加がありました。特に blink.cmp の改善と nvim-treesitter の新しいパーサー追加は、日常的な編集作業を快適にしてくれるでしょう。LazyVim とそのプラグインは着実に進化を続けており、定期的な更新を行うことで、最新の機能を活用することができます。

現在私が使っている Neovim のバージョンは NVIM v0.10.5-dev-19+gc5eeb1b9ee で、更新されたすべてのプラグインと互換性があります。バージョン 0.10 以上を要求するようになった nvim-lspconfig も問題なく動作しています。

定期的に <leader> l でログを確認し、更新を行うことをおすすめします。これにより、最新の機能改善とバグ修正を常に利用できるようになります。

Astroのデプロイ方法比較ガイド

Tue, 25 Mar 2025 00:00:00 GMT

Astro のデプロイ方法比較ガイド

Astro は高速で軽量な Web フレームワークとして人気を集めていますが、作成したサイトを公開するためのデプロイ方法はいくつかあります。この記事では、主要なデプロイプラットフォームについて、それぞれの特徴と設定方法を解説します。

Vercel へのデプロイ

:::tip Vercel は特に SSR をサポートする Astro サイトに最適なプラットフォームの一つです。 :::

特徴

設定不要ですぐにデプロイが可能
SSR、SSG、ISR など多様なレンダリング戦略をサポート
プレビュー環境とプロダクション環境の分離
アナリティクスと環境変数の管理
グローバル CDN による高速化

設定方法

Vercel アカウントを作成し、ログインします
GitHub リポジトリと連携します
「Import Project」からリポジトリを選択します
フレームワークプリセットとして「Astro」を選択します

# または、Vercel CLIを使用する場合
npm i -g vercel
vercel login
vercel

astro.config.mjs の設定

import { defineConfig } from "astro/config";
import vercel from "@astrojs/vercel/serverless";

export default defineConfig({
  output: "server",
  adapter: vercel(),
});

カスタムドメインの設定

Vercel ダッシュボードから「Domains」セクションに移動し、カスタムドメインを追加します。DNS の設定を行えば、数分で SSL 証明書が自動発行され、サイトにアクセスできるようになります。

Netlify へのデプロイ

:::note Netlify は特に静的サイトの場合、非常に簡単にデプロイできるプラットフォームです。 :::

特徴

ドラッグ＆ドロップでデプロイが可能
継続的デプロイメント
フォーム処理機能
サーバーレス関数のサポート
エッジ関数によるパフォーマンス最適化

設定方法

Netlify アカウントを作成し、ログインします
「New site from Git」をクリックします
GitHub リポジトリと連携します
ビルド設定:
- Build command: npm run build
- Publish directory: dist

# または、Netlify CLIを使用する場合
npm install -g netlify-cli
netlify login
netlify init
netlify deploy --prod

astro.config.mjs の設定

import { defineConfig } from "astro/config";
import netlify from "@astrojs/netlify/functions";

export default defineConfig({
  output: "server", // SSRの場合
  adapter: netlify(),
});

netlify.toml ファイルの作成

[build]
  command = "npm run build"
  publish = "dist"

[dev]
  command = "npm run dev"
  port = 3000

[[redirects]]
  from = "/*"
  to = "/index.html"
  status = 200

GitHub Pages へのデプロイ

:::important GitHub Pages は特に個人ブログやドキュメントサイトに適しています。 :::

特徴

無料で利用可能
GitHub リポジトリと直接連携
カスタムドメインと SSL のサポート
GitHub Actions による自動デプロイ

設定方法

GitHub リポジトリを作成します
.github/workflows/deploy.ymlファイルを作成します

name: Deploy to GitHub Pages

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: 18
      - name: Install dependencies
        run: npm ci
      - name: Build website
        run: npm run build
      - name: Deploy to GitHub Pages
        uses: peaceiris/actions-gh-pages@v3
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          publish_dir: ./dist

astro.config.mjs の設定

import { defineConfig } from "astro/config";

export default defineConfig({
  site: "https://yourusername.github.io",
  base: "/your-repo-name",
});

カスタムドメインの設定

リポジトリの「Settings」タブに移動します
「Pages」セクションでカスタムドメインを入力します
DNS プロバイダーで CNAME レコードを設定します
リポジトリにCNAMEファイルを作成し、ドメイン名を記載します

Cloudflare Pages へのデプロイ

:::tip Cloudflare Pages はグローバルなエッジネットワークを活用したい場合に最適です。 :::

特徴

グローバル CDN による高速配信
無制限の帯域幅
自動ビルドとデプロイ
環境変数とシークレットの管理
Web アナリティクスの統合

設定方法

Cloudflare アカウントを作成し、ログインします
「Pages」タブに移動し、「Create a project」をクリックします
GitHub リポジトリと連携します
ビルド設定:
- Framework preset: Astro
- Build command: npm run build
- Build output directory: dist

astro.config.mjs の設定

import { defineConfig } from "astro/config";
import cloudflare from "@astrojs/cloudflare";

export default defineConfig({
  output: "server", // SSRの場合
  adapter: cloudflare(),
});

Deno Deploy へのデプロイ

:::note Deno Deploy は特に TypeScript ベースのプロジェクトに適したプラットフォームです。 :::

特徴

TypeScript ネイティブサポート
グローバルエッジネットワーク
迅速なデプロイと更新
GitHub 連携
無料枠が比較的大きい

設定方法

Deno Deploy アカウントを作成し、ログインします
新しいプロジェクトを作成します
GitHub リポジトリと連携します
デプロイ設定を行います

astro.config.mjs の設定

import { defineConfig } from "astro/config";
import deno from "@astrojs/deno";

export default defineConfig({
  output: "server",
  adapter: deno(),
});

従来のホスティングサービスへのデプロイ

:::caution 従来のホスティングサービスでは、SSR の機能が制限される場合があります。 :::

設定方法

Astro プロジェクトをビルドします

npm run build

生成されたdistディレクトリの内容を FTP などでアップロードします
サーバー側で必要な設定を行います（.htaccess など）

.htaccess の設定例

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /index.html [L,QSA]

デプロイ方法の比較表

プラットフォーム	無料プラン	SSR サポート	自動デプロイ	カスタムドメイン	CDN	特徴
Vercel	✅	✅	✅	✅	✅	開発者体験に優れた総合的なプラットフォーム
Netlify	✅	✅	✅	✅	✅	フォーム処理やサーバーレス関数が簡単に利用可能
GitHub Pages	✅	❌	✅	✅	✅	無料で利用できる静的サイトホスティング
Cloudflare Pages	✅	✅	✅	✅	✅	グローバル CDN とセキュリティ機能が強力
Deno Deploy	✅	✅	✅	✅	✅	TypeScript ネイティブで高速なエッジ実行環境
従来のホスティング	有料	△	❌	✅	△	既存のインフラを活用できる柔軟性

まとめ

Astro プロジェクトのデプロイ方法は、プロジェクトの規模や必要な機能によって最適なものが異なります。静的サイトであれば GitHub Pages や Netlify が手軽で、SSR や ISR などの動的機能を活用したい場合は Vercel や Cloudflare Pages が適しています。また、特殊な要件がある場合は従来のホスティングサービスも選択肢になります。

:::tip[最終アドバイス] 初めての Astro プロジェクトなら、まずは Vercel や Netlify を試してみることをおすすめします。どちらもゼロコンフィグでデプロイでき、開発体験が優れています。 :::

::github{repo="withastro/astro"}

以上のガイドが、あなたの Astro プロジェクトを最適な方法でデプロイする助けになれば幸いです。質問やフィードバックがあれば、コメントセクションでお待ちしています。

Neovimのインストール方法とLazyVim導入ガイド

Tue, 25 Mar 2025 00:00:00 GMT

Neovim のインストール方法と LazyVim 導入ガイド

Neovim は、従来の Vim を現代的に再設計したテキストエディタで、拡張性が高く、プラグインでカスタマイズしやすいことが特徴です。この記事では、各 OS 別のインストール方法から基本的な設定、プラグインの導入方法までを解説します。

Neovim とは

:::note Neovim は、Vim の機能を継承しつつ、非同期処理、組み込みターミナル、Lua による API 拡張などの新機能を追加した次世代エディタです。 :::

Vim との主な違いは以下のとおりです：

Lua スクリプトによる API 拡張
非同期 I/O 処理によるパフォーマンス向上
組み込みターミナル
LSP（Language Server Protocol）のネイティブサポート
より良いデフォルト設定

OS 別インストール方法

Linux

Ubuntu の場合

# APTからインストール
sudo apt update
sudo apt install neovim

# 最新版を使いたい場合はPPAを追加
sudo add-apt-repository ppa:neovim-ppa/unstable
sudo apt update
sudo apt install neovim

Arch Linux の場合

sudo pacman -S neovim

Fedora の場合

sudo dnf install neovim

macOS

macOS では Homebrew を使ったインストールが最も簡単です。

# Homebrewがない場合はインストール
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

# Neovimのインストール
brew install neovim

Windows

Windows では複数のインストール方法があります。

Chocolatey を使う方法

# PowerShellを管理者権限で実行
choco install neovim

Scoop を使う方法

# Scoopがない場合はインストール
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser
irm get.scoop.sh | iex

# Neovimのインストール
scoop install neovim

WSL2 を使っている場合

WSL2 を使用している場合は、Linux 環境内で Neovim をインストールするのがおすすめです。

# Ubuntuの場合
sudo apt update
sudo apt install neovim

公式サイトからのダウンロード

Neovim 公式ダウンロードページから Windows 用の zip ファイルをダウンロードし、展開して使うこともできます。

LazyVim の導入

Neovim の設定は複雑になりがちですが、LazyVim を使うことで簡単に VSCode のような高機能な IDE 環境を構築できます。LazyVim は多数のプラグインが事前設定された「ディストリビューション」で、すぐに使える開発環境を提供します。

そして HHKB の無刻印キーボードの特殊でありますが効率的な配列と Neovim+lazyVim のキーボードだけで行う操作感が、画面から目を反らすことのない最高で究極の開発体験を得ることができるのです！

LazyVim のインストール

LazyVim をインストールする前に、まず Neovim の設定ディレクトリのバックアップを取っておくことをおすすめします。

# Linux/macOS
# 既存の設定がある場合はバックアップ
[ -d ~/.config/nvim ] && mv ~/.config/nvim ~/.config/nvim.bak
[ -d ~/.local/share/nvim ] && mv ~/.local/share/nvim ~/.local/share/nvim.bak
[ -d ~/.local/state/nvim ] && mv ~/.local/state/nvim ~/.local/state/nvim.bak
[ -d ~/.cache/nvim ] && mv ~/.cache/nvim ~/.cache/nvim.bak

# Windows (PowerShell)
# 既存の設定がある場合はバックアップ
if (Test-Path $env:LOCALAPPDATA\nvim) { Rename-Item -Path $env:LOCALAPPDATA\nvim -NewName nvim.bak }
if (Test-Path $env:LOCALAPPDATA\nvim-data) { Rename-Item -Path $env:LOCALAPPDATA\nvim-data -NewName nvim-data.bak }

次に、LazyVim の設定を直接クローンします：

# Linux/macOS
git clone https://github.com/LazyVim/starter ~/.config/nvim

# Windows (PowerShell)
git clone https://github.com/LazyVim/starter $env:LOCALAPPDATA\nvim

クローンした後、一度 Git ディレクトリを削除して、独自の設定リポジトリとして使えるようにします：

# Linux/macOS
rm -rf ~/.config/nvim/.git

# Windows (PowerShell)
Remove-Item -Recurse -Force $env:LOCALAPPDATA\nvim\.git

LazyVim の初回起動

Neovim を起動すると、LazyVim のセットアップが自動的に開始されます：

nvim

初回起動時は多数のプラグインがインストールされるため、少し時間がかかります。完了したら、:checkhealthコマンドを実行して、環境に問題がないか確認してください。

LazyVim のカスタマイズ

LazyVim は非常に簡単にカスタマイズできます。主な設定ファイルは以下の場所にあります：

~/.config/nvim/lua/config/options.lua: Neovim の基本設定
~/.config/nvim/lua/config/keymaps.lua: キーマッピング
~/.config/nvim/lua/config/lazy.lua: Lazy プラグインマネージャーの設定

プラグインの追加

プラグインを追加するには、~/.config/nvim/lua/pluginsディレクトリに新しいファイルを作成します。例えば、追加のカラースキームを導入する場合：

-- ~/.config/nvim/lua/plugins/colorscheme.lua
return {
  -- 追加のカラースキーム
  { "catppuccin/nvim", name = "catppuccin" },
  { "folke/tokyonight.nvim" },

  -- カラースキーム設定を上書き
  {
    "LazyVim/LazyVim",
    opts = {
      colorscheme = "catppuccin",
    },
  },
}

キーマッピングのカスタマイズ

キーマッピングはkeymaps.luaで変更できます：

-- ~/.config/nvim/lua/config/keymaps.lua
local keymap = vim.keymap.set

-- Escキーの代わりにjjを使用
keymap("i", "jj", "<ESC>", { desc = "Escape insert mode" })

-- ウィンドウ間の移動
keymap("n", "<C-h>", "<C-w>h", { desc = "Go to left window" })
keymap("n", "<C-j>", "<C-w>j", { desc = "Go to lower window" })
keymap("n", "<C-k>", "<C-w>k", { desc = "Go to upper window" })
keymap("n", "<C-l>", "<C-w>l", { desc = "Go to right window" })

基本設定のカスタマイズ

基本的な Neovim の設定はoptions.luaで変更できます：

-- ~/.config/nvim/lua/config/options.lua
vim.opt.shiftwidth = 2      -- インデントのスペース数
vim.opt.tabstop = 2         -- タブのスペース数
vim.opt.relativenumber = true -- 相対行番号を表示
vim.opt.wrap = true         -- 行の折り返しを有効に
vim.opt.scrolloff = 10      -- スクロール時に表示する前後の行数

LazyVim に含まれる主要プラグイン

:::tip LazyVim には多数の優れたプラグインが事前設定されており、すぐに使える状態になっています。 :::

コーディング支援

nvim-lspconfig: 言語サーバープロトコル設定
nvim-treesitter: 構文解析と高度なハイライト
nvim-cmp: 高機能コード補完
LuaSnip: スニペットエンジン
mason.nvim: LSP サーバー簡単インストール

UI 関連

neo-tree.nvim: ファイルエクスプローラー
telescope.nvim: ファイル検索・フィルタリング
which-key.nvim: キーバインドヘルプ
bufferline.nvim: バッファタブ表示
noice.nvim: コマンドライン UI 改善

Git 統合

gitsigns.nvim: Git 変更表示
vim-fugitive: Git 操作

カスタマイズすることも簡単です。

:::tip[最終アドバイス] LazyVim は強力な機能がデフォルトで多数含まれていますが、すべてを一度に覚える必要はありません。まずは基本的な操作から始めて、徐々に機能を探索していくのがおすすめです。:Lazyコマンドで現在インストールされているプラグインを確認し、:LazyExtrasで追加の拡張機能を導入できます。 :::

::github{repo="neovim/neovim"} ::github{repo="LazyVim/LazyVim"}

Neovim の世界を楽しんでください！LazyVim を使えば、プロのような開発環境がすぐに手に入ります。もし質問やトラブルがあれば、コメントセクションでお知らせください。

Windows 11 WSL2環境でのNode.jsとnpmのセットアップ方法

Mon, 24 Mar 2025 00:00:00 GMT

Windows 11 WSL2 環境での Node.js と npm のセットアップ方法

WSL2 (Windows Subsystem for Linux 2) と Ubuntu を利用した Windows 11 環境で Node.js と npm をセットアップする方法を解説します。Node.js は多くのフロントエンド開発ツールの基盤となる JavaScript ランタイムで、Astro を含む多くのフレームワークを使用するために必要です。

前提条件

この記事は以下の環境を前提としています：

Windows 11
WSL2 が有効化されている
Ubuntu がインストールされている
Windows Terminal

WSL2 や Ubuntu のインストールがまだの場合は、WSL2 と Ubuntu のインストール方法を参照してください。

Node.js のインストール方法

Node.js をインストールする方法はいくつかありますが、ここでは以下の 2 つの方法を紹介します：

NodeSource のリポジトリを使用する方法（推奨）
nvm（Node Version Manager）を使用する方法

それぞれの方法を詳しく解説します。

1. NodeSource リポジトリを使用したインストール

NodeSource が提供する公式リポジトリを使うと、最新バージョンの Node.js を簡単にインストールできます。

まず WSL2 の Ubuntu ターミナルを起動します。
必要なパッケージをインストールします：

sudo apt update
sudo apt install -y curl

NodeSource のセットアップスクリプトを実行します。ここでは最新の LTS（長期サポート）バージョンをインストールします：

curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -

注: 記事執筆時点（2025 年 3 月）では、Node.js 20.x が最新の LTS バージョンです。必要に応じて数字を変更してください。

Node.js をインストールします：

sudo apt install -y nodejs

インストールされたバージョンを確認します：

node -v
npm -v

2. nvm を使用したインストール

nvm を使うと、複数の Node.js バージョンを簡単に切り替えられるようになります。プロジェクトによって異なるバージョンが必要な場合に特に便利です。

まず nvm のインストールスクリプトをダウンロードして実行します：

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash

シェルを再起動するか、以下のコマンドで設定を読み込みます（Fish shell の場合は別の設定が必要です）：

export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"

nvm が正しくインストールされたか確認します：

nvm --version

最新の LTS バージョンの Node.js をインストールします：

nvm install --lts

インストールした Node.js を使用するように設定します：

nvm use --lts

バージョンを確認します：

node -v
npm -v

Fish shell で nvm を使用する場合

私は Fish shell を使用していますが、nvm はデフォルトでは Fish と互換性がありません。以下の方法で設定できます：

Fisher（Fish shell のプラグインマネージャー）をインストールします：

curl -sL https://raw.githubusercontent.com/jorgebucaran/fisher/main/functions/fisher.fish | source && fisher install jorgebucaran/fisher

Fish 用の nvm ラッパーをインストールします：

fisher install jorgebucaran/nvm.fish

Node.js をインストールします：

nvm install lts

Node.js を使用します：

nvm use lts

インストールされている Node.js のバージョンを確認します：

nvm list

この方法で、Fish shell 上でも nvm を問題なく使用できます。

npm の初期設定

Node.js をインストールすると、パッケージマネージャーの npm も一緒にインストールされます。以下の設定を行っておくと便利です：

グローバルパッケージのインストール先を変更する（オプション）：

mkdir -p ~/.npm-global
npm config set prefix '~/.npm-global'

PATH を設定する（~/.bashrc または~/.zshrc に追加）：

export PATH=~/.npm-global/bin:$PATH

Fish shell の場合は、~/.config/fish/config.fish に以下を追加します：

set -gx PATH $HOME/.npm-global/bin $PATH

npm をアップデートする：

npm install -g npm@latest

パッケージ管理ツールの選択

Node.js のパッケージ管理には、npm 以外にも以下のような選択肢があります：

yarn - Facebook が開発した代替パッケージマネージャー：

npm install -g yarn

pnpm - ディスク効率の良い代替パッケージマネージャー（私のお勧め）：

npm install -g pnpm

Astro プロジェクトでの動作確認

Node.js と npm が正しくインストールされたかを確認するために、簡単な Astro プロジェクトを作成してみましょう：

# npmを使用する場合
npm create astro@latest my-astro-project

# yarnを使用する場合
yarn create astro my-astro-project

# pnpmを使用する場合
pnpm create astro@latest my-astro-project

プロジェクトディレクトリに移動して開発サーバーを起動します：

cd my-astro-project
npm run dev

ブラウザでhttp://localhost:4321にアクセスして、Astro のスターターサイトが表示されることを確認しましょう。

トラブルシューティング

パーミッションエラーが発生する場合

npm を使ってグローバルパッケージをインストールする際に、パーミッションエラーが発生することがあります。その場合は以下の方法を試してください：

mkdir -p ~/.npm-global
npm config set prefix '~/.npm-global'

そして、シェルの設定ファイルに PATH を追加します。

nvm がコマンドとして認識されない場合

nvm をインストールした後にcommand not foundエラーが出る場合は、シェルの設定ファイルに以下の行が追加されているか確認してください：

Bash の場合（~/.bashrc）：

export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"

Fish の場合は、前述の nvm.fish プラグインが正しくインストールされているか確認し、fisher listコマンドで一覧に表示されていることを確認してください。もし表示されていなければ、再度fisher install jorgebucaran/nvm.fishを実行してみてください。

まとめ

これで Windows 11 の WSL2 環境に Node.js と npm が正しくインストールされ、Astro を含む様々な JavaScript プロジェクトの開発準備が整いました。Node.js のバージョン管理には nvm を使うことをお勧めします。特に複数のプロジェクトを扱う場合に便利です。

Node.js と npm の基本的な使い方については、Node.js の公式ドキュメントやnpm の公式ドキュメントを参照してください。

Windows 11 WSL2 ターミナルに Moralerspace Neon HWNF をインストールする方法

Fri, 21 Mar 2025 00:00:00 GMT

Windows 11 WSL2 ターミナルに Moralerspace Neon HWNF をインストールする方法

こんにちは！今回は Windows 11 の WSL2 環境で Moralerspace Neon HWNF フォントをインストールし、fish shell で使用する方法について解説します。Moralerspace Neon HWNF は、プログラミングに最適化された美しいフォントで、Windows Terminal での開発体験を大幅に向上させます。とはいえ、vscode のフォントとは少し見た目が違います。英数:日本語が 1:2 なので、少し英数文字が狭いかもしれません。私も最初狭いと感じたのですが直ぐになれましたｗ

Moralerspace Neon HWNF とは？

Moralerspace Neon HWNF は、プログラミング用に特化したフォントで、Nerd Font パッチが適用されています。主な特徴は以下の通りです：

セリフ（飾り）がないクリーンなデザイン
プログラミング用の記号やリガチャが最適化されている
Nerd Font アイコンが統合されている（開発アイコン、ファイルタイプアイコンなど）
長時間のコーディングでも目が疲れにくい設計

Windows へのインストール手順

1. Moralerspace Neon HWNF のダウンロード

まず、Moralerspace Neon HWNF フォントを Nerd Fonts の公式サイトからダウンロードします：

ウェブブラウザで moralerspace リリースページにアクセス
🆕 ダウンロードはこちらにアクセス
最新リリース（例：v1.1.0）から「MoralerspaceHWNF_v1.1.0.zip」を Windows へダウンロード
ダウンロードした ZIP ファイルを展開

2. Windows へのフォントインストール

ダウンロードしたフォントを Windows にインストールします：

ZIP ファイルを展開したフォルダを開く
「MoralerspaceNeonHWNF-Regular.ttf」などの .ttf ファイルを探す
インストールしたいフォントファイルを右クリックして「インストール」または「すべてのユーザーにインストール」を選択

3. Windows Terminal での設定

Windows Terminal でフォントを設定します：

Windows Terminal を起動
Ctrl + , キーを押して設定画面を開く
左側のサイドバーから「外観」を選択
「フォントフェイス」ドロップダウンから「Moralerspace Neon HWNF」を選択
フォントサイズを適切な値（例：12）に設定
「保存」をクリックして設定を適用

4. 設定ファイル（JSON）による詳細設定

より詳細な設定を行いたい場合は、JSON ファイルを直接編集します：

Windows Terminal の設定画面を開き、下部の「JSON ファイルを開く」をクリック
以下のようにプロファイルを編集：

{
  "profiles": {
    "defaults": {
      "font": {
        "face": "Moralerspace Neon HWNF"
      },
      "opacity": 80,
      "useAcrylic": true
    },
    "list": [
      {
        "guid": "{your-wsl-profile-guid}",
        "name": "Ubuntu",
        "source": "Windows.Terminal.Wsl",
        "font": {
          "face": "Moralerspace Neon HWNF",
          "size": 12
        }
      }
    ]
  }
}

fish shell での Nerd Font アイコンの表示確認

fish shell で Nerd Font アイコンが正しく表示されるか確認するために、以下のコマンドを試してみましょう：

# fish shellでの正しいNerd Fontアイコン表示方法
printf '%b' '\uE0B0 \uE0B1 \uF135 \uE235\n'

正しく設定されていれば、PowerLine の三角形アイコン、ロケットアイコン、歯車アイコンなどが表示されるはずです。

まとめ

この記事では、Windows 11 の WSL2 環境で Moralerspace Neon HWNF フォントをインストールして、fish shell で使用する方法を解説しました。このフォントを使用することで、Windows Terminal でのコーディング体験が視覚的に向上し、長時間の作業でも目の疲れを軽減できます。

fish shell の独自の構文に注意しながら、Nerd Font の特殊アイコンを活用することで、より情報量の多い、視覚的に美しいターミナル環境を構築できます。

参考リンク

Windows 11 WSL2環境でのGitインストールガイド

Tue, 18 Mar 2025 00:00:00 GMT

Windows 11 WSL2 環境での Git インストールガイド

こんにちは！今回は、Windows 11 の WSL2 環境で Git をインストールする方法について解説します。Neovim/LazyVim ユーザーの方で、Fish shell を使用している環境を前提としていますが、他のシェル環境でも応用可能です。個人的には、もし github を使用しなくてもローカルでコミットすると履歴管理になるのでおすすめです。

Git とは？

Git は、コードのバージョン管理を行うためのツールです。複数人での開発や、自分一人でも変更履歴を追跡できるため、現代のソフトウェア開発では欠かせないツールとなっています。

主な特徴:

変更履歴の管理
ブランチによる並行開発
リモートリポジトリとの連携
コードのバックアップ

WSL2 環境での Git インストール

WSL2（Windows Subsystem for Linux 2）環境では、Linux のパッケージマネージャーを使用して Git をインストールします。Ubuntu 環境を例に説明します。

パッケージリストの更新

まず、パッケージリストを最新の状態に更新します。

sudo apt update

Git のインストール

次に、Git をインストールします。

sudo apt install git

インストールが完了したら、バージョンを確認してみましょう。

git --version

以下のように出力されればインストール成功です。

git version 2.34.1 (または、それ以降のバージョン)

Git の初期設定

Git をインストールしたら、基本的な設定を行います。

ユーザー情報の設定

Git を使用する前に、ユーザー名とメールアドレスを設定する必要があります。これは、コミット履歴に記録される情報です。

git config --global user.name "あなたの名前"
git config --global user.email "あなたのメールアドレス"

エディタの設定

コミットメッセージなどを編集する際に使用するエディタを設定します。Neovim を使用している場合は以下のようにします。

git config --global core.editor "nvim"

設定の確認

現在の設定を確認するには、以下のコマンドを使用します。

git config --list

Fish shell での Git 設定

Fish shell を使用している場合、bash や zsh とは少し設定方法が異なります。以下では、Fish 用の Git 設定を行います。

Fish 用の Git エイリアス設定

Fish の設定ファイル（通常は~/.config/fish/config.fish）に、Git のエイリアスを追加すると便利です。

# ~/.config/fish/config.fish に追加
alias g="git"
alias ga="git add"
alias gc="git commit"
alias gco="git checkout"
alias gs="git status"
alias gd="git diff"
alias gl="git log"

Fish 用の Git プロンプト

Fish shell で Git の状態をプロンプトに表示するには、以下のようにします。

# ~/.config/fish/config.fish に追加
if type -q fisher
    fisher install jorgebucaran/fish-git-util
end

これにはFisherというプラグインマネージャーが必要です。まだインストールしていない場合は、以下のコマンドでインストールできます。

curl -sL https://git.io/fisher | source && fisher install jorgebucaran/fisher

Git の基本的な使い方

Git の基本的なコマンドを紹介します。

リポジトリの初期化

新しい Git リポジトリを作成するには、以下のコマンドを使用します。

git init

ファイルの追跡

変更したファイルをステージングエリアに追加します。

git add ファイル名

すべての変更ファイルを追加する場合:

git add .

コミット

ステージングエリアの変更をコミットします。

git commit -m "コミットメッセージ"

リモートリポジトリの追加

GitHub などのリモートリポジトリを追加するには:

git remote add origin https://github.com/ユーザー名/リポジトリ名.git

プッシュ

ローカルの変更をリモートリポジトリにプッシュします。

git push -u origin main

誤ったコミットを修正する方法

開発中に「あ、このコミットはまずかった！」と思うことは誰にでもあります。Git にはそんなときのための機能がいくつか用意されています。

git revert：コミットを打ち消す

git revertは、過去のコミットを打ち消す新しいコミットを作成します。歴史を書き換えるのではなく、「打ち消しコミット」を作るため、チーム開発でも安全に使えます。

# 直前のコミットを打ち消す
git revert HEAD

# 特定のコミットを打ち消す
git revert コミットID

例えば、誤ってパスワードをコミットしてしまった場合などに活用できます。

git reset：コミット履歴を書き換える

注意: git resetはコミット履歴を書き換えるため、プッシュ済みのコミットには使用しないでください。

# 直前のコミットを取り消し、変更はステージング状態に戻す
git reset --soft HEAD^

# 直前のコミットを取り消し、変更は作業ディレクトリに戻す
git reset --mixed HEAD^

# 直前のコミットを完全に取り消し、変更も削除する
git reset --hard HEAD^

コミットメッセージの修正

直前のコミットメッセージを修正するのは簡単です。

git commit --amend -m "新しいコミットメッセージ"

これは実際には新しいコミットを作成し、直前のコミットを置き換えます。

まとめ

この記事では、Windows 11 の WSL2 環境で Git をインストールし、基本設定を行う方法を解説しました。Git は開発ワークフローの重要な部分であり、効率的な開発に欠かせないツールです。

次回は、LazyGit の導入と使い方について解説する予定です。LazyGit は、Neovim との統合が優れており、コマンドラインから Git を操作するよりも直感的にバージョン管理ができるようになります。

ご質問やご意見があれば、コメント欄にお寄せください！

参考リンク

Windows 11 WSL2環境でのFish shellセットアップガイド

Tue, 18 Mar 2025 00:00:00 GMT

Windows 11 WSL2 環境での Fish shell セットアップガイド

こんにちは！今回は、Windows 11 の WSL2 環境に Fish shell をインストールし、効率的な開発環境を構築する方法について解説します。Neovim/LazyVim ユーザーの方にも最適な設定方法をご紹介します。

Fish shell とは？

Fish (Friendly Interactive SHell) は、使いやすさと美しさを重視して設計されたコマンドラインシェルです。Bash や Zsh と比較して、以下のような特徴があります：

シンタックスハイライト（コマンドやパスが色分けされる）
自動補完機能が高度（過去のコマンド履歴やマニュアルから学習する）
直感的な構文（複雑なシェルスクリプトを書きやすい）
Web ベースの設定インターフェース
プラグインシステムが整備されている

WSL2 環境への Fish shell インストール

前提条件

Windows 11 がインストールされていること
WSL2 が有効化されていること
Ubuntu（または他の Linux ディストリビューション）が WSL2 にインストールされていること

Fish shell のインストール

Ubuntu 環境で Fish をインストールする方法を紹介します。

1. パッケージリストの更新

まず、パッケージリストを最新の状態に更新します。

sudo apt update

2. Fish shell のインストール

次に、Fish shell をインストールします。

sudo apt install fish

3. インストールの確認

Fish がインストールされたことを確認します。

fish --version

以下のように出力されればインストール成功です。

fish, version 3.1.2 (または、それ以降のバージョン)

4. Fish shell を起動する

インストールが完了したら、以下のコマンドで Fish を起動できます。

fish

Fish shell をデフォルトシェルに設定

Fish shell を毎回ログイン時に自動的に起動するように設定しましょう。

1. インストールされているシェルのリストを確認

cat /etc/shells

出力に /usr/bin/fish が含まれていることを確認します。

2. デフォルトシェルを変更

chsh -s /usr/bin/fish

パスワードを求められるので入力します。次回ログイン時から Fish がデフォルトシェルとして使用されます。

Fish shell の基本設定

Fish shell の設定ファイルは ~/.config/fish/config.fish にあります。このファイルがない場合は作成します。

mkdir -p ~/.config/fish
touch ~/.config/fish/config.fish

基本的な設定例

以下は、開発環境に便利な基本設定の例です。これを config.fish に追加してください。

# Fish起動時のウェルカムメッセージを非表示にする
set fish_greeting

# エディタの設定（Neovimを使用）
set -gx EDITOR nvim

# PATH設定
set -gx PATH $HOME/.local/bin $PATH

# エイリアス設定
alias ll="ls -la"
alias g="git"
alias vim="nvim"

# ディレクトリ移動したら自動でlsする関数
function cd
    builtin cd $argv
    ls
end

# プロンプトの設定（シンプルなテーマ）
function fish_prompt
    set_color cyan
    echo -n (whoami)
    set_color normal
    echo -n '@'
    set_color green
    echo -n (hostname)
    set_color normal
    echo -n ':'
    set_color blue
    echo -n (prompt_pwd)
    set_color yellow
    echo -n (fish_git_prompt)
    set_color normal
    echo -n '> '
end

Fisher（プラグインマネージャー）のインストール

Fish には「Fisher」というプラグインマネージャーがあります。これを使用することで、様々な便利な機能を追加できます。

1. Fisher のインストール

curl -sL https://git.io/fisher | source && fisher install jorgebucaran/fisher

2. おすすめのプラグイン

Fisher を使用して、以下のおすすめプラグインをインストールしましょう。

z - 高速ディレクトリ移動

過去に訪れたディレクトリに素早く移動できるようになります。

fisher install jethrokuan/z

使い方：z ディレクトリ名の一部 で、そのディレクトリに移動できます。例：z dev

nvm.fish - Node.js バージョン管理

Node.js のバージョン管理を行うためのプラグインです。

fisher install jorgebucaran/nvm.fish

使い方：

# Node.jsの最新バージョンをインストール
nvm install latest

# 特定のバージョンをインストール
nvm install 16.14.0

# インストールされているバージョンを一覧表示
nvm list

fish-git-util - Git の状態をプロンプトに表示

Git リポジトリの状態をプロンプトに表示するプラグインです。

fisher install jorgebucaran/fish-git-util

この設定により、Git リポジトリ内にいる場合、ブランチ名や変更状態などが表示されます。

Neovim/LazyVim との連携

Fish shell と Neovim/LazyVim を連携させるための設定を紹介します。

1. Fish の設定ファイルに Neovim 関連の設定を追加

~/.config/fish/config.fish に以下を追加します。

# Neovim関連の設定
set -gx XDG_CONFIG_HOME $HOME/.config
set -gx XDG_DATA_HOME $HOME/.local/share
set -gx XDG_CACHE_HOME $HOME/.cache

# LazyVim用の環境変数
set -gx LAZYVIM_CONFIG_DIR $XDG_CONFIG_HOME/nvim

2. Neovim を起動するエイリアスの設定

便利なエイリアスを追加します。

# Neovimエイリアス
alias vi="nvim"
alias nv="nvim"
alias lvim="nvim" # LazyVimを使用する場合

# 設定ファイルを素早く編集するためのエイリアス
alias fishconfig="nvim ~/.config/fish/config.fish"
alias nvimconfig="nvim ~/.config/nvim/init.lua"

ターミナルの見た目をカスタマイズ

Fish shell の見た目をカスタマイズして、より使いやすくしましょう。

1. カラーテーマの設定

Fish shell には、Web UI で設定を変更できる機能があります。以下のコマンドで起動します。

fish_config

ブラウザが開き、カラーテーマや機能のカスタマイズができます。

2. シンタックスハイライトのカスタマイズ

シンタックスハイライトの色をカスタマイズするには、config.fish に以下を追加します。

# シンタックスハイライトの設定
set fish_color_command green --bold
set fish_color_param normal
set fish_color_quote yellow
set fish_color_error red --bold

3. Fish プロンプトのカスタマイズ（Starship 使用）

より高度なプロンプトをカスタマイズしたい場合は、Starship というツールがおすすめです。

まず、Starship をインストールします。

curl -sS https://starship.rs/install.sh | sh

次に、config.fish に以下を追加します。

# Starshipの初期化
starship init fish | source

さらに、~/.config/starship.toml ファイルを作成してカスタマイズできます。

# ~/.config/starship.toml
[character]
success_symbol = "[➜](bold green)"
error_symbol = "[✗](bold red)"

[git_branch]
symbol = "🌱 "
style = "bold purple"

[nodejs]
symbol = "⬢ "
style = "bold green"

[directory]
style = "bold blue"

トラブルシューティング

1. Fish shell が起動しない場合

Bash に戻して設定を確認します。

exec bash

そして、Fish がインストールされていることを確認します。

which fish

2. 設定ファイルに問題がある場合

設定ファイルに構文エラーがある場合、Fish shell は起動時にエラーを表示します。一度設定ファイルを移動してから Fish を起動し、問題を特定しましょう。

mv ~/.config/fish/config.fish ~/.config/fish/config.fish.bak
fish

3. プラグインの問題

プラグインに問題がある場合は、一時的にプラグインを無効化して確認します。

mv ~/.config/fish/fish_plugins ~/.config/fish/fish_plugins.bak
fisher update

まとめ

この記事では、Windows 11 の WSL2 環境に Fish shell をインストールし、効率的な開発環境を構築する方法について解説しました。Fish shell は直感的な操作と美しい表示で、開発作業をより快適にしてくれます。

特に Neovim/LazyVim ユーザーの方は、今回紹介した設定を活用することで、より効率的なコーディング環境を構築できるでしょう。

ぜひ自分好みにカスタマイズして、最高の開発環境を作り上げてください！

参考リンク

Windows Terminalのカスタマイズ方法

Tue, 18 Mar 2025 00:00:00 GMT

Windows Terminal のカスタマイズ方法

こんにちは！今回は Windows Terminal の外観と機能をカスタマイズして、より快適な開発環境を構築する方法を解説します。特にプログラミングに適したフォント設定やカラーテーマの適用方法について詳しく見ていきましょう。

Windows Terminal とは

Windows Terminal は、Microsoft が開発した最新のターミナルアプリケーションで、コマンドプロンプト、PowerShell、WSL（Windows Subsystem for Linux）など、様々なシェル環境を一つのアプリケーションで管理できます。タブ機能、分割ウィンドウ、Unicode 対応、GPU アクセラレーションなど、多くの機能を備えています。

インストール方法

Windows Terminal は、Microsoft Store から簡単にインストールできます。

Microsoft Store を開く
「Windows Terminal」を検索
インストールボタンをクリック

もしくは、以下のリンクから直接アクセスできます： Windows Terminal - Microsoft Store

基本的な設定方法

Windows Terminal の設定は、GUI ベースの設定画面または JSON ファイルを編集することで行えます。

設定画面を開く方法

Windows Terminal を起動
タイトルバーの下矢印をクリック →「設定」を選択

または、Ctrl + , のショートカットを使用して設定画面を開くこともできます。

プログラミングに最適なフォント設定

プログラミングを快適に行うためには、適切なフォントを選ぶことが重要です。プログラミング用フォントは、以下の特徴を持つものが理想的です：

等幅（モノスペース）
数字の「0」と大文字の「O」の区別がつきやすい
記号が見やすい
リガチャ（合字）対応（オプション）

フォントのインストール方法

プログラミングフォントは、多くの場合、公式サイトまたは GitHub からダウンロードできます。

Moralerspace Neon HWNF の設定

詳しくはWindows 11 WSL2 ターミナルに Moralerspace Neon HWNF をインストールする方法にて説明しています。

カラーテーマの設定

プログラミングを長時間行う場合、目に優しいカラーテーマを選ぶことも重要です。Windows Terminal には、いくつかの組み込みテーマがあります。

Tango Dark テーマの設定

画像に表示されている Tango Dark は、目に優しく、コードの視認性が高いテーマです。

Windows Terminal の設定画面を開く
左側のサイドバーから「外観」を選択
「配色」の項目で「Tango Dark」を選択

その他のおすすめテーマ

One Half Dark - バランスの取れた暗いテーマ
Solarized Dark - 目の疲れを軽減する暗いテーマ
Tokyo Night - 青と紫をベースにした美しいテーマ

カスタムテーマの作成

独自のカラーテーマを作成することもできます。設定 JSON ファイルのschemesセクションに新しいテーマを追加します：

"schemes": [
    {
        "name": "MyCustomTheme",
        "background": "#0C0C0C",
        "foreground": "#CCCCCC",
        "cursorColor": "#FFFFFF",
        "black": "#0C0C0C",
        "blue": "#0037DA",
        "cyan": "#3A96DD",
        "green": "#13A10E",
        "purple": "#881798",
        "red": "#C50F1F",
        "white": "#CCCCCC",
        "yellow": "#C19C00",
        "brightBlack": "#767676",
        "brightBlue": "#3B78FF",
        "brightCyan": "#61D6D6",
        "brightGreen": "#16C60C",
        "brightPurple": "#B4009E",
        "brightRed": "#E74856",
        "brightWhite": "#F2F2F2",
        "brightYellow": "#F9F1A5"
    }
]

ターミナルの背景透過設定

背景を半透明にすることで、ターミナル使用中に背後のウィンドウを確認できるようになります。

Windows Terminal の設定画面を開く
左側のサイドバーから「外観」を選択
「背景の透過」を有効にする
スライダーで透過度を調整（20-30%が読みやすさと透過のバランスが良い）

タブとペインの設定

Windows Terminal は、複数のタブやペイン（分割ウィンドウ）を使用できます。

新しいタブを開くショートカット

Ctrl + Shift + T - 新しいタブを開く
Ctrl + Shift + 数字 - 指定した番号のプロファイルで新しいタブを開く

ペインの分割

Alt + Shift + D - 現在のペインを複製して分割
Alt + Shift + - - 水平方向に分割
Alt + Shift + + - 垂直方向に分割

コマンドパレットの活用

Windows Terminal には、様々なコマンドに素早くアクセスできるコマンドパレットが搭載されています。

Ctrl + Shift + P - コマンドパレットを開く

コマンドパレットからは、タブの操作や設定の変更など、ほぼすべての機能にアクセスできます。

起動時の設定

Windows Terminal の起動時の動作をカスタマイズできます。

デフォルトプロファイルの設定

Windows Terminal の設定画面を開く
左側のサイドバーから「起動」を選択
「既定のプロファイル」で Ubuntu など希望するプロファイルを選択

起動時にディレクトリを指定

特定のディレクトリで起動するように設定するには：

プロファイル設定を開く
「コマンドライン」の項目に以下のように入力：

wsl.exe ~ -d Ubuntu

これにより、Ubuntu のホームディレクトリで起動します。

アクセンスカラーの設定

タブの色やアクセントカラーをカスタマイズすることで、異なる環境を視覚的に区別しやすくなります。

プロファイル設定を開く
「外観」を選択
「タブの色」でカラーを選択

例えば、Ubuntu のタブはオレンジや PowerShell のタブは青にするなど、環境ごとに異なる色を設定すると便利です。

まとめ

Windows Terminal は、豊富なカスタマイズオプションを提供する優れたターミナルアプリケーションです。フォント設定、カラーテーマ、タブ管理など、様々な設定を調整することで、自分好みの快適な開発環境を構築できます。

特に、プログラミングには適切なフォントを選ぶことが重要です。Moralerspace Neon HWNF のようなプログラミング向けフォントを使用することで、長時間のコーディングも快適に行えるようになります。

ぜひ、この記事を参考に、自分だけの理想的なターミナル環境を構築してみてください！

参考リンク

Windows 11でWSL2とUbuntuをインストールする方法

Tue, 18 Mar 2025 00:00:00 GMT

Windows 11 で WSL2 と Ubuntu をインストールする方法

こんにちは！今回は Windows 11 に WSL2（Windows Subsystem for Linux 2）を有効化し、Ubuntu をインストールする方法を詳しく解説します。これにより、Windows マシン上で Linux 環境を利用した開発が可能になります。

WSL2 とは？

WSL2 は、Windows 上で Linux バイナリを実行するための Microsoft の技術です。第一世代の WSL と比較して、WSL2 は以下の特徴があります：

完全な Linux カーネルを使用
システムコールの互換性が大幅に向上
ファイルシステムのパフォーマンスが向上
Docker などのコンテナ技術との親和性が高い

つまり、WSL2 は Windows 上でより本格的な Linux 環境を提供してくれるのです。

インストール方法

WSL2 と Ubuntu のインストールには、主に 2 つの方法があります：

コマンドプロンプトまたは PowerShell を使用する方法（簡単な方法）
手動で各機能を有効化する方法（詳細な設定が必要な場合）

ここでは、まず簡単な方法から紹介します。

方法 1：単一コマンドでのインストール（推奨）

Windows 11 では、単一のコマンドで WSL2 と Ubuntu をインストールできます。

管理者権限で PowerShell を開きます（スタートメニューで「PowerShell」を右クリックし、「管理者として実行」を選択）
以下のコマンドを実行します：

wsl --install

このコマンドは以下の処理を自動的に行います：

仮想マシンプラットフォーム機能を有効化
WSL コンポーネントをインストール
WSL2 をデフォルトバージョンとして設定
Ubuntu の最新版をダウンロードしてインストール

コマンド実行後、システムの再起動が必要です。再起動後、Ubuntu が自動的に起動し、初期設定が始まります。

方法 2：手動でのインストール（詳細設定が必要な場合）

特定の Linux ディストリビューションを選択したい場合や、より詳細な設定を行いたい場合は、手動でインストールすることもできます。

1. WSL 機能を有効化する

管理者権限の PowerShell で以下のコマンドを実行します：

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart

2. 仮想マシンプラットフォームを有効化する

dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

3. システムを再起動する

上記のコマンドを実行した後、一度システムを再起動します。

4. WSL2 Linux カーネル更新パッケージをダウンロードしてインストールする

Microsoft Storeから「WSL 2 Linux カーネル更新パッケージ」をダウンロードしてインストールします。

あるいは、以下のリンクから直接ダウンロードすることもできます： WSL2 Linux カーネル更新パッケージ - x64 マシン用

5. WSL2 をデフォルトバージョンとして設定する

wsl --set-default-version 2

6. Ubuntu をインストールする

Microsoft Store を開き、「Ubuntu」を検索してインストールします。あるいは、PowerShell から以下のコマンドでインストールすることもできます：

wsl --install -d Ubuntu

特定のバージョンを指定する場合は以下のようにします：

# Ubuntu 22.04をインストールする場合
wsl --install -d Ubuntu-22.04

7. 利用可能な Linux ディストリビューションを確認する

他の Linux ディストリビューションをインストールしたい場合は、以下のコマンドで利用可能なディストリビューションを確認できます：

wsl --list --online

Ubuntu の初期設定

Ubuntu を初めて起動すると、ユーザーアカウントの設定が求められます。

Ubuntu を起動します（スタートメニューから「Ubuntu」を選択）
ユーザー名を入力します（任意の名前で OK）
パスワードを設定します（入力時にはパスワードは表示されませんが、正常に入力されています）
パスワードを再入力して確認します

これで基本的なセットアップは完了です。

パッケージを最新の状態に更新する

Ubuntu をインストールしたら、まずパッケージを最新の状態に更新することをお勧めします：

sudo apt update && sudo apt upgrade -y

このコマンドは、パッケージリストを更新（apt update）し、インストール済みのパッケージを最新バージョンにアップグレード（apt upgrade）します。-yオプションは、確認プロンプトに自動的に「はい」と答えます。

WSL2 の便利な機能と設定

1. Windows と Linux 間のファイルアクセス

WSL2 では、Windows と Linux 間でファイルを簡単に共有できます。

Windows から Ubuntu のファイルにアクセスする

エクスプローラーのアドレスバーに以下を入力します：

\\wsl$\Ubuntu

または、Ubuntu のホームディレクトリにアクセスするには：

\\wsl$\Ubuntu\home\あなたのユーザー名

Ubuntu から Windows のファイルにアクセスする

Windows のドライブは /mnt/ ディレクトリにマウントされています。例えば：

# Cドライブにアクセス
cd /mnt/c

# ユーザーフォルダにアクセス
cd /mnt/c/Users/あなたのWindowsユーザー名

2. メモリ使用量の設定

WSL2 は仮想マシンを使用しているため、メモリ使用量を制限することができます。ホームディレクトリに .wslconfig ファイルを作成します：

notepad "$env:USERPROFILE\.wslconfig"

以下の内容を記述します（例：メモリを 6GB、プロセッサを 4 コアに制限）：

[wsl2]
memory=6GB
processors=4

設定を反映させるには、WSL を再起動します：

wsl --shutdown

3. Ubuntu の起動と終了

起動方法

スタートメニューから「Ubuntu」を選択
PowerShell やコマンドプロンプトから wsl と入力
特定のディストリビューションを起動するには wsl -d Ubuntu

終了方法

Ubuntu シェルで exit と入力
すべての WSL インスタンスをシャットダウンするには、PowerShell から wsl --shutdown

トラブルシューティング

WSL のバージョン確認

現在インストールされている WSL のバージョンを確認するには：

wsl -l -v

出力の「VERSION」列が「2」であることを確認してください。

Ubuntu が WSL1 で動作している場合

Ubuntu が WSL1 で動作している場合は、以下のコマンドで WSL2 に変換できます：

wsl --set-version Ubuntu 2

WSL コマンドが見つからないエラー

「WSL コマンドが見つかりません」というエラーが表示される場合は、Windows 機能の「Windows Subsystem for Linux」が有効になっていない可能性があります。以下の手順で有効化してください：

コントロールパネル → プログラム → Windows の機能の有効化または無効化
「Windows Subsystem for Linux」にチェックを入れる
システムを再起動する

インストール中のエラー

インストール中に「WSL2 ではカーネルコンポーネントの更新が必要です」のようなエラーが表示される場合は、WSL2 Linux カーネル更新パッケージをインストールしていない可能性があります。前述のリンクからダウンロードしてインストールしてください。

WSL2 と Ubuntu を使った開発環境の構築

WSL2 と Ubuntu をインストールしたら、以下のような開発環境を構築することができます：

開発ツールのインストール：

sudo apt install build-essential git curl wget

プログラミング言語のインストール：

# Node.jsのインストール例
curl -fsSL https://deb.nodesource.com/setup_16.x | sudo -E bash -
sudo apt install -y nodejs

# Pythonのインストール例
sudo apt install python3 python3-pip

他の開発ツールのインストール：必要に応じて、開発に必要なツールをインストールしましょう。例えば、Neovim を使用する場合：
```
sudo apt install neovim
```

まとめ

この記事では、Windows 11 で WSL2 を有効化し、Ubuntu をインストールする方法を紹介しました。WSL2 を使うことで、Windows マシン上で本格的な Linux 環境を利用した開発が可能になります。

WSL2 と Ubuntu のインストールが完了したら、Fish shell のセットアップやGit のインストールなどの記事も参考にして、より効率的な開発環境を構築してみてください。

参考リンク

Termuxの基本的な使い方の備忘録

Thu, 13 Mar 2025 00:00:00 GMT

Termux の基本的な使い方の備忘録

スマホでプログラミングやサイト制作をしたいと思ったことはありませんか？実は Android スマホと Termux を使えば、外出先でも PC とほぼ同等の開発環境を構築できます。この記事では、Termux の基本的な使い方、特にタブ管理について解説します。

Termux とは

Termux は、Android デバイス上で動作するターミナルエミュレーターアプリです。Linux コマンドを実行でき、さまざまな開発ツールをインストールして利用できます。

インストール方法

F-Droid から Termux をインストールするのがおすすめです。Google Play ストアのバージョンは更新が止まっている場合があります。

F-Droid からのインストールリンク

基本的なタブ操作

Termux では複数のタブを開いて、並行して作業することができます。これがスマホでの開発において非常に重要です。

新規タブの作成

新しいタブを作成するには、以下の方法があります：

ショートカットを使う: Ctrl + Alt + t
長押しメニューから: 画面下部を長押しし、表示されるメニューから「New Session」を選択
ドロワーメニューから: 画面左端から右にスワイプしてメニューを表示し、「New Session」をタップ

タブ間の移動

開いているタブ間を移動するには：

キーボードショートカット: Ctrl + Alt + [1-9] (数字はタブの番号)
スワイプ: タブバーがある場合は左右にスワイプ
セッションリストから: 長押しメニューから「Sessions」を選択し、切り替えたいタブをタップ

タブの名前変更

タブに分かりやすい名前をつけると、複数タブでの作業が効率的になります：

長押しメニューを表示
「Rename Session」を選択
新しい名前を入力して「OK」をタップ

タブの閉じ方

作業が終わったタブを閉じるには：

そのタブで exit コマンドを実行
または長押しメニューから「Close Session」を選択

実践的なタブ活用例

スマホでウェブ開発をする場合の典型的なタブ構成例：

タブ 1: コードエディタ

# Neovim/LazyVimを起動するタブ
nvim src/pages/blog-post.md

タブ 2: 開発サーバー

# 別タブでAstroの開発サーバーを起動
cd my-astro-project
pnpm dev

タブ 3: Git 操作

# 変更をコミット・プッシュするためのタブ
git status
git add .
git commit -m "記事を追加"
git push

複数プロセスの管理

バックグラウンド実行

コマンドの末尾に & をつけると、バックグラウンドで実行できます：

pnpm dev &

その後、fg コマンドで前面に戻せます。

プロセスの一時停止と再開

実行中のプロセスを一時停止するには：

Ctrl + z でプロセスを一時停止
bg コマンドでバックグラウンドでの実行を再開
fg コマンドで前面での実行を再開

プロセス一覧の確認

ps

tmux との組み合わせ

Termux のタブ機能だけでは物足りない場合は、tmux を導入するとより高度な画面分割ができます：

# tmuxのインストール
pkg install tmux

# tmuxの起動
tmux

# 水平分割
Ctrl + b, "

# 垂直分割
Ctrl + b, %

# ペイン間の移動
Ctrl + b, 矢印キー

便利なキーボードショートカット

Termux でよく使うキーボードショートカット：

ショートカット	機能
`Ctrl + Alt + t`	新規タブ作成
`Ctrl + Alt + [1-9]`	タブ n 番へ移動
`Ctrl + Alt + c`	クリップボードへコピー
`Ctrl + Alt + v`	クリップボードから貼り付け
`Ctrl + Alt + +`	フォントサイズ拡大
`Ctrl + Alt + -`	フォントサイズ縮小
`Ctrl + d`	現在のタブを終了

トラブルシューティング

タブが応答しなくなった場合

他のタブに切り替える
ps -e | grep -i termux を実行して応答のないプロセス ID を特定
kill [プロセスID] で強制終了

キーボードが表示されない

画面をタップしてキーボードを呼び出す
それでも表示されない場合は、Termux アプリを再起動

その他の便利な設定

エイリアスの設定

頻繁に使うコマンドにはエイリアスを設定すると便利です：

# ~/.bashrcや~/.config/fish/config.fishに追加
alias dev='cd ~/my-project && pnpm dev'
alias gp='git pull'
alias gs='git status'

Nerd Font の導入

LazyVim など多くの現代的なツールでは Nerd Font が推奨されます：

# 準備中...
# Termuxでのフォント設定はやや複雑なため、別途詳細な手順を紹介します

まとめ

Termux は、スマホという限られた環境でも PC 並みの開発体験を提供してくれる素晴らしいツールです。タブ機能をうまく活用することで、複数の作業を並行して行えるようになります。カフェや移動中など、PC がない場所でも開発を続けられるのは大きなメリットです。

ぜひ Termux を使って、スマホでも快適な開発環境を構築してみてください！

LazyVim のインストール方法と使いかた

Sat, 13 Apr 2024 00:00:00 GMT

LazyVim のインストール方法と使いかた

LazyVim とは

LazyVim とは、モダンな Linux で使える Neovim エディターを拡張したもので、デフォルトで多くの便利な機能やキーバインドが設定されている開発者向けのエディターです。通常の Neovim では、使いやすくするために多くの設定コードを自分で書く必要がありますが、LazyVim はそれらの設定を最初から提供してくれます。言えば VSCode のような IDE 環境を LazyVim のインストールにより簡単に設定できるという代物です。個人的には Neovim を使うことによってカーソル移動がキーボードのみで行うのがスムーズなので大好きです。マウスを使用することが違うソフトを使うときのみになり、かなり効率的だと感じています。

LazyVim の特徴：

VSCode のような使い心地（ファイルツリー、検索機能など）
プラグイン管理が簡単
LSP（Language Server Protocol）によるコード補完やエラー検出
美しいテーマとアイコン
カスタマイズが容易

LazyVim のインストール方法

前提条件

Neovim 0.9.0 以上がインストールされていること
Git がインストールされていること
ターミナルで使用するフォントとして Nerd Font がインストールされていること（アイコン表示に必要）

インストール手順

まず、既存の Neovim 設定をバックアップします（既存ユーザーの場合）:

# Linux/macOS
mv ~/.config/nvim ~/.config/nvim.bak
mv ~/.local/share/nvim ~/.local/share/nvim.bak
mv ~/.local/state/nvim ~/.local/state/nvim.bak
mv ~/.cache/nvim ~/.cache/nvim.bak

LazyVim の設定をクローンします:

git clone https://github.com/LazyVim/starter ~/.config/nvim

一時ファイルを削除します（任意）:

rm -rf ~/.config/nvim/.git

Neovim を起動すると、必要なプラグインが自動的にインストールされます:

nvim

LazyVim の基本的な使い方

主要なキーバインド

基本操作

<Space> - リーダーキー（多くのコマンドの起点）
<Space>q - Neovim を終了
<Space>w - ファイルを保存
<Ctrl-s> - ファイルを保存（別の方法）

ファイル操作

<Space>e - ファイルエクスプローラーを開く/閉じる
<Space>ff - ファイル名で検索
<Space>fr - 最近開いたファイルを検索
<Space>sg - ファイル内容を Grep 検索（全文検索）

コード操作

K - カーソル位置の要素に関するドキュメントを表示（TypeScript の型情報など）
gd - 定義にジャンプ
gr - 参照を検索
<Space>ca - コードアクション（リファクタリングなど）
<Space>cf - コードをフォーマット

ウィンドウ操作

<Ctrl--> - 画面縮小
<Ctrl>= - 画面拡大
<Ctrl>0 - 画面サイズを 100%に戻す
<Space>| - 画面を垂直分割
<Space>- - 画面を水平分割
<Ctrl>h/j/k/l - ウィンドウ間を移動

タブとバッファ

<Space>bp - 前のバッファに移動
<Space>bn - 次のバッファに移動
<Space>bd - 現在のバッファを閉じる
<Tab> - 次のバッファに切り替え
<Shift-Tab> - 前のバッファに切り替え

ターミナル

<Space>ft - ターミナルをフローティングウィンドウで開く
<Space>tt - ターミナルを新しいタブで開く

プラグイン管理

LazyVim は Lazy.nvim をプラグイン管理に使用しています。プラグインの管理には以下のコマンドが便利です：

<Space>l - Lazy プラグインマネージャーを開く
<Space>pp - プラグインの確認
<Space>pu - プラグインの更新

LazyVim のカスタマイズ方法

LazyVim の設定は ~/.config/nvim/lua/ ディレクトリで管理されています。主な設定ファイルは：

~/.config/nvim/lua/config/options.lua - Neovim の基本設定
~/.config/nvim/lua/config/keymaps.lua - キーマップの設定
~/.config/nvim/lua/config/lazy.lua - プラグイン管理の設定
~/.config/nvim/lua/plugins/ - プラグイン固有の設定

新しいプラグインを追加するには、~/.config/nvim/lua/plugins/ ディレクトリに新しいファイルを作成します。

例えば、新しいカラースキームを追加する場合：

-- ~/.config/nvim/lua/plugins/colorscheme.lua
return {
  {
    "folke/tokyonight.nvim",
    lazy = false,
    priority = 1000,
    config = function()
      vim.cmd.colorscheme "tokyonight"
    end,
  },
}

トラブルシューティング

プラグインのインストールに失敗する場合：
- <Space>l でプラグインマネージャーを開き、エラーがあるプラグインを確認
- <Space>pu で手動更新を試みる
LSP（言語サーバー）が動作しない場合：
- :LspInfo コマンドで状態を確認
- 必要な言語サーバーがインストールされているか確認（:Mason で確認）
フォントの問題（アイコンが正しく表示されない）：
- Nerd Font がインストールされているか確認
- ターミナルの設定で Nerd Font を使用するよう設定

まとめ

LazyVim は Neovim の設定を簡単にするためのフレームワークで、すぐに使える豊富な機能とカスタマイズの自由度を提供します。VSCode のような使い心地でありながら、Vim/Neovim の効率的な編集能力を活かすことができます。

基本的なキーバインドを覚えることで、プログラミング作業の効率を大幅に向上させることができるでしょう。また、LazyVim は設定ファイルを自分で調整することで、自分好みの開発環境に育てていくことができます。

githubへのpush

Sat, 23 Sep 2023 00:00:00 GMT

github への push

github への push の方法をメモしておきます。てか、そんなにやることないので記事的にどうでしょうか。と思い始めました。このブログを github に push しているのですが、どうやってやったか詳細まで覚えてないので、調べながらメモしますｗ

github アカウントを作ってなかったら作成する

github を使うので github アカウントを作成。公式サイト（https://github.com/）にアクセスして「Sign up」からアカウントを作成できます。

初回だけ git にユーザー名とメールアドレスを設定

ローカルの git にユーザー名とメールアドレスを設定しておきます。コミットの履歴情報といったメタデータとして使われる。

git config --global user.name "YourGitHubUsername"
git config --global user.email "youremail@example.com"

設定の確認

git config --global --get user.name
git config --global --get user.email

github にリポジトリを作成

ログイン後 github でリポジトリを作成します。リポジトリを作成時に README を作成するかどうか聞かれるので、作成しないでおきます。

リモートリポジトリの URL をコピーする

リポジトリが作成されたら、緑色の「Code」ボタンをクリックして表示される URL をコピーします。これは後でローカルリポジトリとリンクさせるために使います。

Astro ブログの push

ローカルリポジトリの初期化

Astro プロジェクトのルートディレクトリに移動し、以下のコマンドで Git リポジトリを初期化します。

cd your-astro-blog
git init

最初のコミットを作成

コミットするファイルを指定（ステージング）します。

# すべてのファイルをステージングする場合
git add .

# 特定のファイルだけをステージングする場合
git add src/pages/your-new-post.md

ステージングしたファイルをコミットします。

git commit -m "初回コミット：Astroブログの設定とコンテンツ"

リモートリポジトリを設定

先ほどコピーした URL を使ってリモートリポジトリを設定します。

git remote add origin https://github.com/yourusername/your-repo-name.git

設定を確認するには：

git remote -v

ブランチ名を設定して初回プッシュ

最近の GitHub ではデフォルトブランチ名が「main」になっているので、それに合わせます。

# ブランチ名をmainに設定
git branch -M main

# 初回プッシュ
git push -u origin main

日常的な更新作業

記事を追加したり編集したりした後の通常のプッシュ手順：

変更したファイルをステージング

git add .

変更内容をコミット

git commit -m "記事の追加：GitHubへのプッシュ方法について"

GitHub にプッシュ

git push

トラブルシューティング

認証エラーが発生する場合

GitHub は 2021 年 8 月以降、パスワード認証をサポートしなくなりました。代わりに個人アクセストークン（PAT）か SSH 認証を使用する必要があります。

個人アクセストークンの設定方法

GitHub にログイン
右上のプロフィールアイコンから「Settings」を選択
左側のサイドバーで「Developer settings」をクリック
「Personal access tokens」→「Tokens (classic)」を選択
「Generate new token」をクリック
トークンに名前をつけ、適切な権限（repo 全体へのアクセスなど）を選択
トークンを生成してコピー
push 時にパスワードの代わりにこのトークンを使用

# プッシュ時にユーザー名とトークンを要求される
git push -u origin main

コンフリクトが発生した場合

リモートとローカルで同じファイルが異なる形で編集されると、コンフリクトが発生します。

まず最新の変更を取得

git pull

コンフリクトしたファイルを編集してコンフリクトを解決
解決したファイルをステージング

git add 解決したファイル

コミットしてプッシュ

git commit -m "コンフリクトを解決"
git push

Astro ブログの自動デプロイ設定

GitHub にプッシュした Astro ブログを自動的にデプロイするには、以下のようなサービスと連携すると便利です：

Netlify: GitHub リポジトリと連携して、push するたびに自動的にデプロイ
Vercel: 同様に GitHub と連携し、プレビューデプロイなども可能
GitHub Pages: GitHub Actions を使って自動デプロイを設定可能

例えば、Netlify での設定方法：

Netlify にサインアップ/ログイン
「New site from Git」をクリック
GitHub を選択してリポジトリを連携
ビルド設定（ビルドコマンドとパブリックディレクトリ）を指定：
- ビルドコマンド: npm run build
- パブリックディレクトリ: dist
「Deploy site」をクリック

これで GitHub にプッシュするたびに自動的にサイトが更新されます。

まとめ

GitHub へのプッシュは最初は少し手間がかかりますが、慣れれば簡単な作業です。Astro ブログのようなウェブサイトのソースコードを管理するのに最適な方法で、バージョン管理や自宅の PC や外出時のノートパソコンでの作業も可能になります。また、自動デプロイと組み合わせることで、記事を書いてプッシュするだけでウェブサイトを更新できる効率的なワークフローが実現できます。

HHKBキーボードのお話

Mon, 18 Sep 2023 00:00:00 GMT

HHKB キーボードのお話

今回は私が愛用しているキーボード HHKB Professional BT の紹介をしていこうかと思います。以下は気に入っている点。

コンパクト

テンキーがないのと、小さいサイズでコンパクトです。デザインもスッキリです。

US 配列

エンターキーが日本語キーボードと違い横に細長い形状です。スッキリしており好きです。

コーディングに最適

HHKB に限らず US キーボードも同様ですが、[]、{}、;: '' ""などセットの括弧の配列が便利なように近いキーに割り当てられています。他には HHKB 固有のものとしては特に矢印キーがありません。Fn キーと組み合わせてキーを移動しますが、離れた位置への右手の移動が少なくなり便利です。

タイピング効率がいい

キーボードの文字が便利に配置されており、なれるとキーボードからマウスへの手の移動が減り、入力作業がはかどります。 ESC が他の標準的なキーボードより近いし、|、\、BackSpace や Delete の位置が近くていいです。

気持ちいい打鍵感

スコスコ・トコトコという感じの打鍵音と、浅すぎないタイピングと押し心地が癖になります。HHKB 以外の例えばメカニカルキーボードのようなカチカチといったタイピングではない気持ちいいタイピングができます。ただし、最近のメカニカルキーボードやゲーミングキーボードよりは押し圧は確実に重いと思います。この点だけ好みが分かれるところですね。

無刻印が選べる

そのキーボード何も書いてないんですね！？と言われるためのキーボードですｗ。ノールックでタイピングというかキーボードを見ないでタッチタイピングができる方の特権かもしれないですが、アルファベットや記号の刻印がキーにないキーボードが選べます。キーボードに何か書いてあってもタイピングに慣れたらそんなにキーボードを見なくなるでしょ？その延長上です。

所有の喜び

まるでピアノの鍵盤のような、というか鍵盤ハーモニカのような捉え方もできます。鍵盤ハーモニカと言われるとそんなに高級感ないんですけど、そんな感じです。最近は色のついたキートップを限定数量で販売なんてのもあります。

これじゃないとだめになるｗ

自宅でも US 配列のメカニカルキーボードを使っていますが、HHKB の打鍵感には勝てません。ESC が Neovim のモード切替に必要だからで HHKB では打ちやすいというのもあります。

その他には括弧やコロン、セミコロン、カンマ、ダブルコーテーションがシフトで切り替えるだけなのと、右や左で対応しているなど、すごく便利です。

ゲーム用のキーボードも持っていて、それも US キーボードでいいんですが、やっぱり Neovim には HHKB です。

キーボードを見ないで使い、ゆったりとタイピングができ、リラックスして入力作業ができます。モニターの高さも高く設定することが可能です。

英数、日本語切り替え

英数と日本語の切り替えですが、Mac でも Windows でも HHKB キーボードの A キーの左の Caps Lock を Ctrl とし、Ctrl + Space で切り替えるようにしています。これにする利点は、自宅の Windows ではメカニカルキーボードを据え置きにしていることが多いのですが、同じ方法で切り替えることができるからです。

Orange's Blog

Netlifyで独自ドメインに移行したらSERVFAIL — 委任は正しく、DNSゾーンが無かった

この記事が扱う症状

やろうとしたこと

症状1: 委任は通っているのに SERVFAIL

REFUSED が意味すること

症状2: 払い出されるネームサーバーはゾーンごとに違う

症状3: 保存したはずのネームサーバーが標準に戻る

症状4: primary domain を設定しても netlify.app は 301 されない

テーマが canonical を出していないと逃げ場がない

症状5: ドメインプロパティのサイトマップは完全URLが要る

診断の型: dig を上から降りる

教訓

Ghosttyのcustom-shaderで文字が読めない — minimum-contrastが効かない理由と、背景だけに効かせるグリフマスク

この記事が扱う症状

前座: iTerm2のUI表記が混ざったconfig

シェーダー背景を入れたら、文字が読めなくなった

最初の処方は、外れだった

真犯人は、シェーダーの合成方法だった

本命: グリフマスク

ついでに分かったこと: 透過している限り、鮮やかな色は出せない

教訓

LazyVimのsgでgrepできない — 設定は正しく、足りないのはrg / fd / fzfの3本だった

この記事が扱う症状

キーマップは生きていた

登場人物を数える

which rg は当てにならなかった

1回目の修理は、必要だったが足りなかった

真犯人は3本目のバイナリ

直し方

再起動が要る

brew の caveat は無視してよい

どうしても fzf を入れたくないなら

教訓

Claude Codeのログを数えたら、新しいMacの環境構築で自分は1,014文字しか打っていなかった

ブログのネタを探して、自分のログを掘った

ログはどこにあるか

数えた結果

全部載せます

事件は72文字で決着していた

ただし、4番だけは自分にしか出せなかった

何が残って、何が消えるか

で、自分は何をしていたのか

tree-sitterのビルドが失敗する — 犯人はLazyVimではなくmacOSのベータSDKだった

この記事が扱う症状

新しいMacで、いきなり詰まった

エラーの中身

真犯人

決め手は、ログに残っていない情報だった

直し方

教訓

Astro と Next.js 比較：パフォーマンスの違いとそのメカニズム

Astro と Next.js 比較：パフォーマンスの違いとそのメカニズム

はじめに

ハイドレーションの仕組みとその影響

Next.js のハイドレーションモデル

Astro のアイランドアーキテクチャ

パフォーマンスの違い

JavaScript ペイロードの削減

インタラクティブになるまでの時間

実装の違い

Next.js のアプローチ

Astro のアプローチ

まとめ

LazyVimプラグイン更新レポート - 2025年4月版

LazyVim プラグイン更新レポート - 2025 年 4 月版

更新されたプラグインの役割

更新の概要

Breaking Changes

主要プラグインの更新内容

blink.cmp (v1.1.1)

nvim-lspconfig

nvim-treesitter

fzf & fzf-lua

neo-tree.nvim

mini.pairs

全体的な改善

更新後の注意点

まとめ

Astroのデプロイ方法比較ガイド

`which rg` は当てにならなかった