Posts on Keyuki Blog

NumLock の必要性に関する考察

Tue, 12 May 2026 18:00:00 +0900

NumLock は、普段はほとんど意識されないキーです。しかし、何かの拍子にオフになると、テンキーで数字を打っているつもりがカーソル移動になり、急に存在感を放ちます。

押した覚えはない。けれど、確かに何かが変わっている。あー、、となる。

この記事では、NumLock を「不要なキーだ」という愚痴だけで片付けず、なぜ生まれ、なぜ今も残っているのかを考えます。

NumLock は何を切り替えているのか

NumLock は、テンキーを「数字入力」として使うか、「カーソル移動・ナビゲーション」として使うかを切り替えるキーです。

試しにテンキーをよく見てみると、4 のキーに ←、8 に ↑、2 に ↓、6 に → が印字されているキーボードがあります。7 に Home、1 に End、9 に PgUp、3 に PgDn、0 に Ins、. に Del。

数字専用のエリアだと思っていたのに、ナビゲーション操作まで兼ねていた。私はこれを初めてちゃんと見たとき、少し驚きました。

NumLock は「数字を固定するキー」というより、「テンキーの役割を切り替えるキー」と呼ぶほうが正確なんですよね。

なぜ昔は必要だったのか

初期の PC キーボードは、現代ほどキー数が豊富ではなかったそうです。矢印キーや Home・End・Page Up・Page Down が独立して並んでいるのが当然、という感覚は、わりと最近の話です。

そのような環境では、テンキーに複数の役割を持たせることは合理的な設計でした。数字を入力したいときは NumLock をオンにして、カーソルを動かしたいときはオフにして方向キーとして使う。キーの絶対数が少ない中で、限られたスペースを有効に使おうという発想です。

意味があったんです。当時の設計者を責める話ではなく、制約の中でちゃんと考えた結果がこれだったということです。

現代ではなぜ不要に見えるのか

現代のフルサイズキーボードには、矢印キーと独立したナビゲーションキー（Home・End・Page Up・Page Down・Delete）が揃っています。テンキーにカーソル操作を期待する必然性は、ほとんどなくなりました。

多くのユーザーにとって、テンキーは「数字を素早く入力するためのエリア」です。その前提に立つと、NumLock は「できることを増やすキー」ではなく、「できていた数字入力を突然できなくするキー」に見えます。

テンキーで 1 を押したら End が動いた。この体験、何度やっても慣れないんですよね。キーを引っこ抜きたくなる衝動に駆られます。

問題は「状態を持つキー」であること

NumLock の本質的な厄介さは、押した瞬間にあるのではなく、状態が残ることにあります。

キーボードには、押すたびに状態が切り替わる「トグルキー」が存在します。NumLock、CapsLock、Insert がその代表です。

CapsLock: アルファベットを大文字入力に固定する
Insert: テキスト編集を挿入モードと上書きモードで切り替える
NumLock: テンキーの役割を数字入力とカーソル操作で切り替える

これらのキーに共通するのは、押した瞬間ではなく「後になって気づく」という体験です。なぜか挙動が変わっている。何が起きているのか分からない。そのじわじわした不快さがある。

Claude Code を純正 Claude と Ollama で使い分けるために ollama-cc を作った

Sat, 09 May 2026 18:00:00 +0900

Claude Code の操作感はかなり気に入っています。ファイルを読んで、コマンドを実行して、差分を見ながら進める作業ハーネスとしては優秀で、できればこの操作感のまま使い続けたい。

ただ、Claude Pro のレート制限は自分の使い方だとかなり厳しく感じました。せめて計画は純正 Claude に任せて、実装作業はもう少し安いモデルに逃がせないか。そんな動機で Ollama 経由の Claude Code を試し始めました。

この記事の結論

純正 Claude Code は claude のまま使う
Ollama 経由で使いたい時だけ ollama-cc を起動する
接続先の切り替えは、毎回のコマンド実行時にだけ環境変数として渡す

前提環境

Ollama v0.14.0 以降（Anthropic API 互換対応）
Claude Code（最新版）
macOS（自分の環境は macOS）

他の選択肢も見たが、いったん Ollama Pro に寄せた

Ollama に決め打ちしていたわけではなく、Z.ai のコーディングプランや MiniMax のトークン課金プランも見ました。ただ、Z.ai は検討している間に大きく値上げされ、当時は速度面の評判も気になりました。正直、契約しない理由を探していたところもあると思います。

MiniMax は速くて安いという評判を見かけましたが、試しに Ollama Cloud 経由で触った範囲では、日本語の返事が自分の普段使いには少し厳しそうでした。

その点、Ollama Pro はオープンモデルをいくつか試せて、Claude Code の操作感と組み合わせるにはちょうどよさそうに見えました。

何が起きたのか分からなかった

Claude Code をいつも通りの Claude Pro と、Ollama Cloud のモデル経由の両方で使いたくなりました。

ところが、同じ Mac であれこれ起動しているうちに、純正の claude が API エラーになったり、Ollama 用に起動したつもりの画面が Claude Pro の初期設定に流れたりしました。

Hugoブログの画像をGitHubに置かず、Cloudflare R2で管理することにした

Sat, 09 May 2026 10:46:38 +0900

最初は画像もリポジトリに入れればいいと思っていた

HugoはMarkdownと画像をまとめてGitHubで管理できるのが強みのひとつです。記事ごとにフォルダを作り、その中に index.md と画像をまとめて置く「Page Bundle」という構成が使えるので、記事と素材の対応が分かりやすくなっています。

content/posts/
  2026-05-01-my-article/
    index.md
    cover.webp
    diagram.png

この構成は直感的で、最初はこれで十分だと思っていました。

ところが記事が増えていくにつれて、アイキャッチ画像・サムネイル・OGP画像を毎回用意するようになります。1記事あたり3〜5枚の画像が増えていくと、リポジトリのサイズがじわじわ膨らんでいくのではないかという、不安に駆られました。まだ、ほとんど記事書いてないですけど。Markdownファイル本体は数KBなのに、画像だけで数MBという状況はよくないのでは？と思うようになりました。

GitHubリポジトリが重くなるのが気になった

Gitはテキストファイルの差分管理が得意なツールです。しかしバイナリファイル（画像・動画など）は差分を持たず、変更のたびにファイル全体が履歴として積み上がります。

たとえばアイキャッチ画像を差し替えると、古い画像も新しい画像もGitの履歴に残ります。git clone するたびにその全履歴を取得することになるので、リポジトリが年単位で成長すると無視できないサイズになります。

CI/CDやCloudflare Pagesのビルドも同様で、ビルドのたびにリポジトリ全体をチェックアウトします。画像が増えれば増えるほど、ビルド時間に影響する可能性があります。

「ブログ本文の変更履歴」と「画像アセットの保管場所」は、そもそも性質が違います。そう気づいてから、分けて管理したほうがすっきりすると思いました。

Cloudflare R2を画像置き場にした

Cloudflare R2はCloudflareが提供するオブジェクトストレージです。Amazon S3と互換性のあるAPIを持ちつつ、エグレス料金（データ転送料）がかからないのが特徴で、個人ブログの画像配信には手頃な選択肢です。

無料枠は、ストレージ10GB・Class Aオペレーション（書き込み）100万回/月・Class Bオペレーション（読み込み）1000万回/月となっています。個人ブログで画像を置く用途であれば、まずストレージが上限に達することはありません。読み込み回数についても、1000万回というのは1日あたり約33万リクエストに相当します。そもそも個人ブログにそれだけのPVがあれば、もうブログで飯が食えています。このブログには当然そんなPVはないので、無料枠で一生やっていける気がしています。

このブログはCloudflare Pagesで配信しているので、Cloudflare側に画像も寄せると運用がまとまりやすくなります。R2バケットにカスタムドメインを設定することで、画像URLを https://images.keyuki.net/... という形で統一できます。

記事のフロントマターには画像URLだけを書きます。画像本体はリポジトリに存在しません。

featured_image: https://images.keyuki.net/uploads/2026/05/sample-eyecatch.webp
thumbnail_image: https://images.keyuki.net/uploads/2026/05/sample-thumb.webp
images:
  - https://images.keyuki.net/uploads/2026/05/sample-og.jpg

Hugo側ではURLを参照するだけにした

移行後のリポジトリには、記事本文・テンプレート・CSS・設定ファイルだけが残ります。画像本体はR2に置き、Hugoはそこへのパスを参照するだけになりました。

フロントマターで使っているフィールドの役割も整理しています。

featured_image: 記事ページのメインビジュアル
thumbnail_image: 記事一覧のカードに表示するサムネイル
images: SNSシェア時のOGP画像（TwitterカードやOGタグで使用）

この分担は前の記事で書いたPageSpeed改善の取り組みとも関連しています。

少し管理は面倒になりましたが、快適にサイトが見れるようにやっていくには、これがいいと今のところ思ってます。

よかったこと

リポジトリを軽く保てるのが一番の効果でした。

画像を差し替えてもGit履歴に古いファイルが積み上がりません。R2上で上書きすれば終わりです。
アイキャッチ・サムネイル・OGPと用途別の画像を整理して置きやすくなりました。

気をつけること

移行してよかった一方で、いくつか注意点もあります。

R2側のURL設計が後から変えにくい。 記事から参照しているURLを変えると、過去記事の画像が壊れます。最初からディレクトリ構造とファイル命名規則を決めておく必要があります。

画像を消すと記事の表示が壊れる。 GitHubのように「削除もバージョン管理する」という感覚はR2にはありません。不要になった画像でも、参照している記事がないか確認してから消す必要があります。

GitHubだけ見ても画像の実体がわからない。 リポジトリを見ても画像は見えません。バックアップや棚卸しは別途R2側で行う必要があります。

キャッシュと公開設定に注意する。 R2バケットのパブリックアクセス設定やCloudflareのキャッシュ設定を間違えると、画像が表示されなかったりキャッシュが意図せず残ったりします。

「R2に置けば解決」ではなく、運用ルールをセットで決めることが大事だと感じました。

今の運用ルール

実際にやっていることをまとめると、こんな感じです。

ディレクトリ構成: 年月で分けています。

uploads/
  2026/
    05/
      article-slug-eyecatch.webp
      article-slug-thumb.webp
      article-slug-og.jpg

ファイル命名規則: 記事のslugをベースに、用途をsuffixで区別します。

PageSpeed改善で、ブログ画像の役割を分けることにした

Thu, 07 May 2026 22:30:00 +0900

点数は出たけど、何が起きたのかわからなかった

PageSpeed Insights は、GoogleがWebページの読み込み速度を100点満点で評価してくれる無料ツールです。スマホでの表示速度（モバイル）とパソコンでの表示速度（デスクトップ）を別々に測定してくれます。

昔々、ブックマークに入れていたものを掘り起こしたわけですね。

このブログのモバイル版を測定したら、こんな数字が出ました。

Performance: 67（100点満点。低いほど遅い）
LCP: 175.2秒
Speed Index: 5.5秒
Total network payload: 39,910 KiB（約39MB）

LCP（Largest Contentful Paint）は、ページを開いてから「一番大きなコンテンツ」が表示されるまでの時間です。175秒というのは、ほぼ「ページが完成しない」という意味になります。

パフォーマンス67という点数は見れば悪いとわかりますが、最初は何を直せばいいのかよくわかりませんでした。

調べてみると、原因はサーバーの遅さでも、JavaScriptのブロックでもありませんでした。トップページが大量の画像を読み込んでいたのが問題でした。

トップページが約39MBあった

サーバー応答は速かったです。JavaScriptのブロックも致命的ではありませんでした。大きかったのは、ひたすら画像でした。

トップページには最新記事のカードが並んでいます。各カードには記事のアイキャッチ画像が表示されます。見た目は小さなサムネイルですが、裏では5MB前後のPNGファイルをそのまま読み込んでいました。カードが10枚あれば、それだけで50MB近くになります。

小さく表示しているから軽い、とは限らない。

ブラウザは width を小さく指定されても、画像ファイルのサイズは変わりません。表示を縮小しているだけで、5MBのPNGは5MBのまま読み込まれます。

まず背景画像を軽くした

最初に手をつけたのは、ヒーロー背景画像でした。

ヘッダーに使っている hero-background.jpg が約7.6〜7.9MBありました。見た目はきれいですが、7MBは明らかに過剰です。

これをWebP（ウェブピー）形式に変換しました。WebPはGoogleが開発した画像フォーマットで、JPEGやPNGより同じ見た目で大幅にファイルサイズを小さくできます。変換後は約283KBになりました。同じ見た目で、ファイルサイズが約1/27になる計算です。

background-image: url('/images/hero-background.webp');

背景画像の変換を含むいくつかの修正をまとめてデプロイしたあと、この段階で計測し直しました。

Performance: 67 → 75
LCP: 175.2秒 → 5.0秒
Total network payload: 39,910 KiB → 32,419 KiB

LCPは大きく改善しました。ただ、ペイロード（ページ読み込みに必要なデータの総量）はまだ32MBあります。トップページの記事カード画像がほぼそのまま残っていたからです。

lazy loadingだけでは足りなかった

背景画像の変換と並行して、記事カードのテンプレートに loading="lazy" と decoding="async" も加えました。

<img
  src="{{ .Permalink }}"
  loading="lazy"
  decoding="async"
  width="760"
  height="424"
/>

それぞれの意味はこうです。

Xのリンクカードに画像が出ない原因を調べたら、featured_imageだけでは足りなかった

Wed, 06 May 2026 19:00:00 +0900

こんなブログでも流入数を多少は増やしていきたいなという、気持ちで、試しに記事をXに投稿したとき、リンクカードに画像が出ませんでした。

リンクカードというのは、XにURLを貼ったときに自動で表示される、タイトルと画像がセットになったあのプレビューのことです。ちゃんと出ると見栄えがいいし、クリックされやすくなる気がして、できれば表示させたいやつです。

記事ページ自体を開くとアイキャッチ画像はちゃんと表示されていました。なのにXのカードには画像がない。「またX側の気まぐれか？」とも思ったのですが、せっかくなので原因をちゃんと調べることにしました。

まずHTMLのソースを確認しました

Webページの裏側にはHTMLというファイルがあって、その中に「この記事のSNSカード用画像はこれです」という情報を埋め込む仕組みがあります。og:image や twitter:image といった「メタタグ」と呼ばれる記述がそれにあたります。

まずそのメタタグが正しく出力されているかを確認しました。Hugo（このブログで使っている静的サイトジェネレーター）でサイトを一時的にビルドして、出力されたHTMLを調べました。

hugo --destination /private/tmp/keyuki-og-check --environment production
rg -n "og:image|twitter:image|twitter:card" /private/tmp/keyuki-og-check/posts

結果を見て、最初は「あ、タグ自体は出てる」と思いました。必要なメタタグは全部ありました。

ところがよく見ると、どの記事もまったく同じURLを指していました。

<meta property="og:image" content="https://blog.keyuki.net/images/default-og.jpg" />
<meta name="twitter:image" content="https://blog.keyuki.net/images/default-og.jpg" />

記事ごとの画像ではなく、全記事共通の default-og.jpg という1枚の画像を指していました。

「メタタグがない」のではなく、「メタタグはあるけど、指している画像が全部同じ共通画像だった」という状態でした。

原因は `featured_image` と `images` の役割の違い

このブログはHugo + Anankeというテーマで動いています。記事を書くとき、ファイルの先頭に設定を書く欄（「フロントマター」と呼びます）があって、そこにアイキャッチ画像のURLを指定していました。

featured_image: https://images.keyuki.net/uploads/2026/05/example-eyecatch.png

これで記事ページにはちゃんと画像が表示されます。ところがXのリンクカードはここを見ていませんでした。

Hugoには featured_image とは別に、SNSカード用のメタタグを生成するための images という設定項目があります。HugoのOGP（Open Graph Protocolの略で、SNSにURLを貼ったときの見え方を制御する仕組みです）は、featured_image ではなく images を参照して動きます。

featured_image → 記事ページ上のアイキャッチ表示に使われる（Anankeテーマ固有の機能）
images → SNSカード用メタタグの生成に使われる（Hugo本体の機能）

images を設定していなければ、Hugoはサイト全体のデフォルト画像（default-og.jpg）で埋めます。今回まさにその状態でした。

画像サイズにも落とし穴がありました

共通の default-og.jpg を確認してみたら、解像度が 7200x4800、ファイルサイズが約7.6MBもありました。

Xのリンクカードには画像のサイズ制限があります。大きすぎる画像はカードに表示されません。共通画像はその条件を超えていたため、仮にフォールバックとして読み込まれていたとしても表示されなかった可能性が高いです。

SNSカード用の画像は 1200x630（横1200px × 縦630px）のJPEGで、ファイルサイズは数百KB以内に抑えるのが安全とされています。

修正した内容

各記事のフロントマターに `images` を追加しました

公開済みの記事のフロントマター（ファイル先頭の設定欄）に images を追加しました。SNSカード用の画像はアイキャッチとは別に、1200x630で作り直したものを使っています。

個人ブログに Google Analytics と Microsoft Clarity を入れた理由

Wed, 06 May 2026 10:00:00 +0900

ブログを整え直している流れで、アクセス解析まわりも見直しました。

もともと Cloudflare Web Analytics は使っていましたが、今回は Google Analytics 4 と Microsoft Clarity も追加しました。アクセス数を細かく追いかけたいというより、どの記事が読まれているのか、どこから来ているのか、読者がページ内でどう動いているのかを見られるようにしたかったからです。まあ、そもそも誰も見にきてないんですけどね。やってみたいだけですね。

もともと使っていた Cloudflare Web Analytics

Cloudflare Web Analytics は、個人ブログにはかなり相性がいいと思っています。軽くて、Cookie に依存せず、プライバシー寄りの設計です。まず全体のページビューや訪問傾向をざっくり見るだけなら、これで十分な場面も多いです。

公式の説明によると、JavaScript の beacon と Performance API を使ってデータを収集しており、訪問者の個人データは収集・使用しない設計になっています。Core Web Vitals などのパフォーマンス指標の傾向も確認できます。

「何人くらい来ているのか」「どのページが見られているのか」を日々ざっくり把握するには、これで十分です。

それでも GA4 を追加した理由

GA4 は正直、個人ブログには機能が多すぎる面もあります。ただ、流入元やページごとの傾向を後から掘れるのは便利です。SNS に投稿した直後の反応、検索から読まれた記事、内部リンクで回遊された記事などを見たいとき、Cloudflare より細かい分析ができます。

GA4 の主な強みを整理すると:

リアルタイムレポート: 直近 5分 / 30分のアクティブユーザー、閲覧ページ、イベントをざっくり確認できる。正確な流入元の内訳は、通常のトラフィック取得レポートで後から確認する用途に向く
トラフィック・ユーザー分析: どこから来ているか（検索、SNS、直接など）の内訳を見る
探索（Explorations）: 標準レポートより深く、フィルタやセグメントを組み合わせて分析できる

個人ブログでは全部使う必要はないです。「SNS に投稿したあと、どこから何人来たか」「検索から読まれている記事はどれか」といった目的を決めて、必要なところだけ見る使い方で十分だと思っています。まだ書いたブログをSNSに投稿してないですね、やらないといけないですね。

将来的に Search Console と接続してオーガニック検索の傾向を見たり、イベント設計をして内部リンクのクリックを追ったりもできるみたいですね。将来の選択肢は多い方がいいですからね。

Microsoft Clarity を追加した理由

Clarity は、数字というより読者の動きを見るために入れました。他の人のブログで見て、なんだろうこれと思ってとりあえず、調べて、入れてみた感じです。どこでスクロールが止まるのか、どのリンクが押されるのか、スマホで読みづらそうな箇所がないか。こういうことは、ページビューだけを見ていてもわかりません。

NASAの研究で話題になった観葉植物は本当に空気をきれいにする？初心者向け3選

Wed, 06 May 2026 00:30:00 +0900

観葉植物、ちょっと置くだけで部屋が変わる

部屋に緑があるだけで、なんだか落ち着きませんか？

観葉植物を置く前の部屋と置いた後の部屋、雰囲気がぜんぜん違うんですよね。空気がきれいになったとかそういう話じゃなくて、ただ緑がそこにいるだけで、部屋がちょっと好きになる。

私は昔から観葉植物が好きで、サンスベリア、スパティフィラム、オリヅルラン、パキラを育ててきました。最初は100均で買った小さな鉢から始めて、だんだんホームセンターでちょっと大きいのを選ぶようになりました。

この記事では、「NASAの研究で話題になった観葉植物」を整理しつつ、初心者におすすめの植物を紹介します。

「NASAが認めた空気清浄植物」は本当？

観葉植物を調べていると、「NASA公認の空気清浄植物」「エコプラント」という言葉をよく見かけます。

元ネタは1989年のNASAの研究です。これは実在する研究で、宇宙ステーションの空気をきれいに保つために、植物が有害物質を吸収できるかを調べたものです。結果として、いくつかの植物にベンゼンやホルムアルデヒドなどを除去する効果があることが示されました。

ただし、ここ大事なんですが——この実験は密閉された小さな空間で行われています。普通の家のような、空気が動く部屋で同じ効果が得られるかは、別の話です。

実際、その後の研究では「普通の部屋で空気清浄機のような効果を期待するのは難しい」という見方が主流になっています。部屋中を植物で埋め尽くすくらいなら別かもしれませんが、普通にいくつか置く程度だと、空気清浄効果はあまり期待できません。

とはいえ、NASAの研究で取り上げられた植物たちに興味を持つきっかけとしては、すごく面白い話だと思います。

初心者に一番おすすめしたいのはサンスベリア

私が一番初心者におすすめしたいのは、サンスベリアです。

理由はシンプルで、ほとんど水やりしなくていいから。水やりを忘れても枯れにくい。これ、初心者にとってめちゃくちゃ大事です。

サンスベリアは種類がたくさんあります。よく見るトラノオもいいんですが、個人的にはカタナやマッソニアが好きです。葉の形や模様が全然違うので、飽きがこない。今、室内にマッソニア系と思われるものを2つ置いています。

「乾燥に強いならサボテンでいいじゃん」と言われそうですが、サンスベリアはNASAの研究でも取り上げられた植物です。観葉植物としての面白さ——葉の立ち方とか、種類の豊富さとか——があるので、サボテンとは違う楽しさがあります。

もちろん、空気清浄効果は過度に期待しないでくださいね。

NASA研究で話題になった観葉植物3選

サンスベリア

NASAの研究でベンゼン、ホルムアルデヒド、トリクロロエチレンの除去効果が報告された植物です。夜に気孔を開いてCO2を取り込むCAM型として知られ、寝室向けとして紹介されることもあります。ただし、体感できる空気改善を期待する話ではありません。

育て方のポイントは「水をあげすぎないこと」。土が乾いてからで大丈夫です。寒さに弱いので、冬は窓際など冷気が当たるところを避けるのがいいです。

100均でも買えることがあるので、まずは小さいのから試してみるのがおすすめです。

スパティフィラム

白い仏炎苞（ぶつえんほう）が特徴的な植物です。緑を楽しむ観葉植物のなかでは、花のような白い仏炎苞がアクセントになります。

NASAの研究ではホルムアルデヒドやベンゼンの除去効果が報告されました。蒸散作用が強くて部屋の湿度を保つ効果がある一方、その分水を欲しがります。

ただ、増えすぎに注意。 私の経験では、元気に育ちすぎて鉢からはみ出してきて、どうしようか困りました。水をしっかりあげる環境だと、すごく育ちます。

オリヅルラン

ランナーから子株を出して増えていく植物です。生命力が強くて、初心者でも育てやすいです。NASAの研究ではホルムアルデヒドの吸収効果が報告されています。

ただ、私の印象では冬になると調子が悪くなりがちです。寒さに弱いので、冬は暖かい場所に移してあげるのがいいと思います。

増やしすぎると場所に困るので、子株は適度に整理するのがよさそうです。

NASA研究とは関係なく、普通におすすめの植物

パキラ

風水的に金運を上げると言われるパキラ。NASAの研究では取り上げられていませんが、観葉植物としての人気は高いです。

ただ、私の経験では葉が落ちることがありました。太く育てるのはけっこう大変で、木なので植木鉢では限界があるのかもしれません。昔は100均でパキラの実生をよく見たのですが、最近はあまり見かけなくなりました。ちょっと残念。

まずは100均やホームセンターで小さい鉢から

観葉植物を始めるなら、最初は100均で小さい鉢を買うのがいいと思います。失敗してもダメージが少ないですし、いろんな種類を試せます。

私も最初は100均で買うことが多かったです。その後、ホームセンターで買うようになりました。ホームセンターは種類が多いので、見ているだけでも楽しいです。

道具もほとんど100均で揃います。小さい鉢なら場所も取らないので、まずは気軽に始めてみてください。

さいごに：空気清浄より、緑があると嬉しい

正直なところ、空気清浄効果は私にはわかりません。たぶん部屋を埋めるくらい置かないと体感できないと思っています。

でも、観葉植物を置いてよかったことは確実にあります。緑を見ると落ち着く。部屋の雰囲気が良くなる。ただそこにあるだけで嬉しい。

長く付き合いやすいのは、結局「水やりを頑張らなくていい植物」です。サンスベリアみたいに、放置気味でも生きてくれる植物は、忙しい人にも合います。

観葉植物の本当の魅力は、空気清浄効果よりも、緑があると落ち着くこと。部屋の雰囲気が良くなること。だと思います。

緑色の友人を迎えてみませんか？私は楽しいです。

モバイル版を整えたら、PC版の記事タイトルが大きすぎることに気づいた

Tue, 05 May 2026 14:00:00 +0900

先に、スマホ版の記事タイトルサイズについても調べています。

スマホ版の記事タイトルサイズを調べて、自分のブログを調整した話

モバイル版の記事タイトルサイズを調整して、スマホでの見え方はだいぶ落ち着きました。その後、PCで自分のブログを開き直してみると——今度はPC版のタイトルがずいぶん大きく感じました。

本文も少し大きめ。画面いっぱいに文字が主張しているというか、記事を読む画面としては少しゆったりすぎる印象です。

今回は、PC版の記事タイトルと本文サイズをどう調整したかを記録します。まずは「大きい気がする」という違和感を、実際のpx値に置き換えて見直してみました。

現状：Anankeテーマの初期値

自分のブログはHugo + Anankeテーマを使っています。AnankeはTachyonsというCSSユーティリティフレームワークを読み込んでいて、記事ページでは次のようなクラスが当たっています。

記事タイトル（h1）: f1 → 3rem = 48px
本文コンテナ: f4 → 1.25rem = 20px

48pxのタイトルと20pxの本文。倍率にすると約2.4倍です。

PCの大画面で見ると、タイトル48pxはかなり主張が強いです。英語の短いタイトルなら映えそうですが、日本語の長いタイトルだと2〜3行に折り返して、画面の上部がタイトルで埋まってしまいます。これが嫌でした。

本文20pxも、PCでじっくり読むにはやや大きめに感じます。文字は大きいほうが読みやすい場面もありますが、大きすぎると読みやすさとは別の圧迫感が出ます。本文が大きすぎると、1行の文字数が減って、目の移動が増え、かえって疲れることもあります。

比較：PC版のブログ・メディアはどうしているか

いくつかのPC向け記事ページのタイポグラフィ傾向を調べてみました。主に既存のタイポグラフィ調査記事やデザインガイドを参考にしています。

国内メディアのPC版タイトル

国内のメディア記事ページでは、PCの記事タイトルは20〜30px程度の例が多く、本文は15〜16pxに収まる例があります。情報量を優先し、タイトルを目立たせるよりスクロールを抑える方向です（LIG）。

ブログタイポグラフィの一般傾向

英語圏のブログタイポグラフィガイドでは、PCの本文は 16〜18px が読みやすい範囲として扱われることが多いです（Lystingz）。

H1については、UI/UXの一般的な目安で 32〜36px 前後がよく使われます。ブログの記事タイトルとしては、このあたりから少し下げて 28〜36px 程度が推奨レンジとして扱われることもあります（Rteetech、Design Bootcamp）。

日本語タイトルの事情

英語圏の目安は、英語の短いタイトルを前提にしている面があります。日本語のタイトルは文字数が多くなりやすく、PCでも2行に折り返すことが珍しくありません。

48pxで2〜3行折り返すと、タイトルだけで画面上部のかなりの面積を占めてしまいます。英語圏の目安より一段小さくしても、日本語としては自然に見えるはずです。

判断：35〜38pxのH1、17〜18pxの本文に

今回は、PC版のH1を 35〜38px、本文を 17〜18px 程度に調整することにしました。

タイトルの存在感は残しつつ、本文を読む画面として少し落ち着かせる狙いです。倍率でいうと約2.0〜2.1倍。48px時代の2.4倍より、記事ページとしては自然なバランスに近づきます。

実装：CSSで上書き

HTMLテンプレートは変更せず、custom.css にPC向けのメディアクエリを追加しました。モバイル版の調整と同じアプローチです。

@media (min-width: 769px) {
  .single .post-content {
    font-size: clamp(1.0625rem, 0.98rem + 0.25vw, 1.125rem);
    line-height: 1.75;
  }

  .single .post-content > header h1 {
    font-size: clamp(2.125rem, 1.85rem + 0.75vw, 2.375rem);
    line-height: 1.28;
    margin-top: 1rem;
    margin-bottom: 0.5rem;
  }
}

ポイントを整理します。

日本語サイトのモバイル見出しサイズを調べた — 自分のブログを最適化するために

Tue, 05 May 2026 08:25:00 +0900

自分のブログ（Hugo + Anankeテーマ）をスマホで見たとき、記事タイトルがなんだか大きすぎる気がしました。そこで、日本語の主要サイトがモバイルでどんな見出しサイズを使っているのか調べてみました。

日本語ニュースサイトのモバイルh1

2026年5月時点の筆者調べです。Chrome DevToolsで375px幅に設定し、各サイトの記事タイトル要素のcomputed font-sizeを確認しました。

サイト	モバイルh1	傾向
NHK	16px	本文と同じサイズ
読売新聞	16px	本文と同じサイズ
日経	16px	本文と同じサイズ
毎日新聞	16px	本文と同じサイズ
産経新聞	16px	本文と同じサイズ
Yahoo!ニュース	17px	比較的小さめ
朝日新聞	18px	ニュース系では大きめ
ITmedia	~13.5px	小さめ

今回筆者が確認したニュース系サイトでは、モバイルの記事タイトルが 16〜18px 程度に収まる例が多く見られました。情報密度を優先し、タイトルを大きく見せるよりもスクロール量を抑える設計に見えます。一方で、過去の国内メディア調査ではスマホh1は 18〜28px、特に24pxが最多 という結果もあり、サイトや記事テンプレートによって差があります（アソボウブログ）。

ブログ・技術プラットフォームのモバイルh1

記事をじっくり読んでもらうタイプのサイトは、もう少し大きめのタイトルを使います。

サイト	モバイルh1	傾向
Zenn	~23px	開発者ブログ寄り
Note	28px	記事特化型
Qiita	~28px	技術コミュニティ
はてなブログ	~19px	控えめ

ブログ系は、おおむね 19–28px の範囲でした。記事タイトルを目立たせて、読者の注意を引く設計です。

デザインガイドラインの推奨値

Material Design 3（Android）

トークン	サイズ	用途
Headline Large	32sp	大きめのページ見出し
Headline Medium	28sp	ページ見出し・主要セクション
Headline Small	24sp	小さめのページ見出し・セクション見出し

iOS Human Interface Guidelines

スタイル	サイズ	用途
Large Title	34pt	ナビゲーションタイトル（※今回のブログ記事タイトル用途では大きめ）
Title 1	28pt	ページタイトル
Title 2	22pt	セクション見出し

なお、Material Designの sp とiOSの pt はCSSの px と直接は換算できません（画面密度やDynamic Typeの文脈があります）。ここではおおよその目安として参照しています。

メインPC変更 M4 Mac miniを買った話

Tue, 05 May 2026 01:03:00 +0900

M4 Mac miniを購入しました。

これまでは古いノートPCや手元の端末でなんとかしていましたが(愛着はあった)、AIを勉強したり、その他作業をしていく上で、やはり据え置きのちょっとはパワーのあるマシンが欲しくなりました。

そこで選んだのが、M4 Mac miniです。

実際に使ってみると、iPadからSSHやJump Desktopで接続して作業できる環境がかなり快適でした。一方で、大規模なローカルLLMを本格的に回すには限界もあります。

この記事では、なぜMac miniを買ったのか、どんな用途で使っているのか、実際に買ってよかった点・微妙だった点をまとめます。

きっかけはOpenClawだった

Mac miniを買おうと思ったきっかけは、OpenClawでした。

当時、OpenClawがとても話題になっていて、自分でも本格的に触ってみたいと思うようになりました。OpenClawはAIエージェントや外部ツールを組み合わせて動かす仕組みなので、試すにはある程度安定した環境が必要です。

ただ、当時メインで使っていたLet’s noteの調子がだんだん悪くなってきていました。OSの不調を直すほどの技術力は私にはありません。普段使いならまだしも、Dockerを動かしたり、CLIツールを入れたり、常時起動に近い形で使ったりするには少し不安があります。

「これからAIツールを色々試していくなら、ちゃんとした作業用のPCが必要だな」

そう思って、Mac miniを買うことにしました。

結果的に、Mac miniはかなり良い選択でした。OpenClaw、Claude Code、Ollama、Docker、まわりの作業を集約できるようになり、iPadやiPhoneからリモートで触れる環境も作れました。

今振り返ると、Mac miniは単なるPCの買い替えではなく、AI時代の作業環境を整えるための投資だったと思います。（思いたいです）

欲しかったのは「安定して動く開発用マシン」

Mac miniに求めていたのは、普段使いのPCではなく、AIツールや自動化環境をいつでも動かせる自宅の作業基地でした。（私は非エンジニアですが、、興味はあるんですね）

具体的には、こんな用途を想定していました。

OpenClaw / Discord bot / Telegram連携のような常駐系ツールを動かしたい
Claude Code、Codex、まわりの作業環境を試してみたい
DockerやCLIツールを常に触れる環境にしたい
iPadやiPhoneから外出先でもアクセスしたい
古いLet’s noteや古いMacBook Proでは、常駐運用に不安があった

ノートPCを開きっぱなしにしておくのではなく、据え置きの常駐マシンとして置いておけるのが大きいです。

なぜMac miniにしたのか

Mac miniを選んだ理由は、流行っていたから、、もとい、自分の用途にかなり合っていたからです。

省スペース: 机の端に小さな箱を置いておく感覚で済む
静か: 常時稼働させる機械として、静音性は大きい
消費電力が少ない: 24時間動かしても電気代が気にならない
常時起動に向いている: スリープ運用もしやすい
macOSなのでAI系CLIとの相性が良い: Claude Codeや各種CLIツールがそのまま動く
iPadやiPhoneからリモート操作しやすい: SSH + Tailscaleでどこからでも接続できる
外付けSSDを使えば本体ストレージ少なめでも運用できる

「サーバーを置く」というより、「机の端に小さな箱を置いておく」感覚で済むのがMac miniの強みです。

選んだ構成：M4 / 24GBメモリ

構成はM4チップ・メモリ24GBにしました。

メモリは当初から「最小構成でいいのか」「盛るべきか」をかなり悩みました。結果的に24GBにしておいてよかったと思っています。

ハッカ油は便利。でも猫がいる家では使わないで

Mon, 04 May 2026 19:00:00 +0900

ハッカ油って知ってますか

ハッカ油、使ってますか？私はもう何年も常備しています。

ドラッグストアで数百円で売ってるあの小さな瓶です。シソ科の「和ハッカ」という植物から抽出した精油で、メントールを多く含みます（製品規格では30%以上、和種ハッカ精油では65〜85%程度）。スーっとするあの清涼感、それがハッカ油の正体です。

ペパーミントオイルと似てますが、和ハッカの方がメントールの含有率が高く、清涼感は一段上です。

何に使えるのか

スーっとして目が覚める

メントールは皮膚の冷覚受容体を刺激するので、触れたところがひんやりします。気分転換にちょうどいいんですよね。ただしこれは感覚的な涼しさで、体温は下がってません。そこは勘違いしないように。

臭いの元を抑える

菌が関係する臭いには一定の抑制が期待できますが、主には香りによるリフレッシュ・消臭目的です。

虫が嫌がる香り

庭にミントを植えて虫除けにしてる人いますよね。あれの精油版です。蚊・アリなどが嫌がる香りとして使われることがあります。ただし、効果は香りが残っている間に限られます。屋外や虫が多い場所では、必要に応じて市販の虫よけ剤と使い分けるのが現実的です。

私の使い方

ここからは私の使い方です。真似をする場合は、肌・目・粘膜に触れないようにし、敏感肌の人や子どもへの使用は避けてください。刺激を感じたらすぐ中止しましょう。

マスクの外側に少量

薄めたスプレーをマスクの外側に少量。スーとして鼻が通る感じになります。花粉の時期に重宝してます。

お風呂でひんやり

お風呂上がりって体温が上がって汗が出続けるじゃないですか。夏場は特に不快ですよね。上がる前に洗面器に数滴垂らしてかぶると、汗が引いたように感じます。体温は下がらないので、室温管理や水分補給は別に必要です。

まずは、洗面器のお湯に1滴から試すくらいが安心です。

うがいに1滴

朝起きたとき、口の中が不快なことありますよね。食品添加物表示のあるものを使い、コップ1杯の水に1滴入れてクチュクチュすると、口の中がさっぱりします。よく混ぜて、飲み込まずに使います。ちょっと苦いですけど。

掃除にスプレー

後で紹介するハッカスプレーを、キッチン回りや排水溝、靴の中に吹きかけています。香りでさっぱりして、気分よく掃除できます。

冷却タオル

濡らしたタオルに1滴しみ込ませて首筋に当てると、外出時もひんやりします。夏の散歩に重宝します。

ハッカスプレーの作り方

使い勝手がいいので、スプレーにしていつでも使えるようにしておくのがおすすめです。

用意するもの（50ml分）

ハッカ油：5〜10滴
無水エタノール：5ml
精製水：45ml（なければ水道水でも可）
スプレー容器（ガラス製、またはPP・PE・PETなど精油対応のもの）

作り方

ガラス容器に無水エタノールを入れる
ハッカ油を加えて混ぜる
精製水を加えてさらに混ぜる
使う前に軽く振ってからスプレー

使用期間は2週間ほどです。少量ずつ作って使い切るのが安心です。

容器は素材に注意してください。 ポリスチレン（PS）は溶けることがあるため避け、ガラス製またはPP・PE・PETなど精油対応容器を使ってください。

気をつけること

便利なハッカ油ですが、いくつか知っておかないといけないことがあります。

原液は肌に使わない

必ず薄めて使うのが正解です。メントール濃度が高いので、原液を肌に直接つけると赤みやかぶれの可能性があります。肌に使うなら1%以下に薄めるのが目安です。心配な人は二の腕でパッチテストを。

猫には絶対に使わない

猫がいる家庭では、ハッカ油は使わないでください。

猫は精油成分の代謝が苦手で、ミント系の精油でも中毒リスクがあります。舐める、皮膚につく、空気中に拡散した成分を吸い込む、といった経路で体調を崩すことがあります。

アロマディフューザーでの拡散もNGです。空気中の成分を猫が吸い込むので危険です。水で薄めたハッカ水も同様にNG。天然成分＝安全という考え方は、猫にとってはあてになりません。

もし猫が吸い込んだ・舐めた可能性がある場合は、すぐに換気して猫を別の部屋に移し、よだれ、嘔吐、ふらつき、震え、呼吸の異常、元気がないなどの変化があれば、すぐに獣医に連絡してください。

乳幼児には使わない

メントールの刺激は小さな子どもには強すぎます。特に乳幼児の呼吸器への影響が懸念されるので控えてください。

清涼感≠体温低下

もう一度書きますが、ひんやり感じるだけで体温は下がってません。熱中症の予防にはなりません。涼しいからといって水分補給をサボらないでください。

食べるなら「食品用」を

ドラッグストアには芳香用・工業用として売られているものもあります。ミントティーやかき氷シロップなどに使うなら、パッケージに「食品添加物」または「食品用」の表示があるものを選んでください。

火の近くに置かない

引火性があるので、コンロやストーブの近くには置かないでください。遮光瓶に入れて冷暗所で保管し、開封後は1年以内に使い切るのが目安です。

さいごに

ハッカ油は、日々の暮らしを少し快適にしてくれる便利なアイテムです。インターネットでも薬局でも手に入りやすく、スプレーや掃除、気分転換などに使えます。

ただし便利だからといって何にでも使えるわけじゃありません。特に猫がいる家庭では使わないこと、原液を肌に直接つけないこと、ポリスチレン容器は避けること——この3つだけは覚えておいてください。

好き嫌いある香りでもあるので、多用にも注意ですね。

あ、ハッカといえばさわやかハンバーグでもらえるハッカ飴が大好きです。

参照・出典

エンゲル係数とは？2025年は44年ぶり高水準、家計見直しの目安を解説

Mon, 04 May 2026 18:00:00 +0900

個人の体験・学習メモです。特定の金融商品の購入・契約をすすめるものではありません。投資にはリスクがあり、ご自身で十分に情報収集・判断してください。

エンゲル係数とは

エンゲル係数は、家計の消費支出に占める食費の割合です。

エンゲル係数（%）＝ 食費 ÷ 消費支出 × 100

1857年にドイツの統計学者エルンスト・エンゲルが提唱しました。ベルギーの労働者世帯の調査から、「収入が低いほど食費の割合が高い」という法則を発見しました。

これがエンゲルの法則です。エンゲル係数が高いほど家計における食費の負担が大きく、一般的には家計の余裕をみる目安の一つとされます。ただし、世帯構成や食生活によって解釈は変わります。

日本のエンゲル係数の推移

1980年代〜2000年代：低下期

日本のエンゲル係数は、所得の増加や消費の多様化を背景に長期的に低下してきました。1980年は約29%でしたが、2005年には約23%まで下がりました（系列により微差あり）。

2010年代半ば〜：上昇傾向へ

2005年ごろを底に緩やかな上昇基調となり、2014年の消費税引き上げ（5%→8%）と前後して上昇が目立つようになりました。2020年以降はコロナ禍による食生活の変化や食料価格の上昇も重なり、上昇傾向が続いています。

2025年：44年ぶりの高水準

総務省の家計調査によると、2025年の2人以上世帯のエンゲル係数は**28.6%**に達しました。1981年（28.8%）以来、44年ぶりの高水準です。なお、以下の数値は2人以上世帯・年平均です。単身世帯とは水準が異なります。

年	エンゲル係数	備考
1980	29.0%
1990	25.1%
2000	23.5%
2005	22.9%	掲載期間内の低い水準
2014	24.3%	消費税8%へ
2019	25.7%	消費税10%へ
2021	26.2%	コロナ禍
2023	27.8%	食料価格高騰
2024	28.3%
2025	28.6%	44年ぶりの高水準

※長期推移は、統計系列の変更により時期によって対象が異なる場合があります。ここでは大まかな流れを示すための参考値として掲載しています。

なぜ上がっているのか

エンゲル係数が上がるのは、主に2つの理由があります。

1. 食料価格の上昇

2025年平均の消費者物価指数では、「食料」は前年比+6.8%上昇しました。これは総合の物価上昇（+3.2%）を大きく上回ります。円安・国際価格高騰・異常気象が重なり、スーパーの値札を見て値上がりを実感する機会が増えたのではないでしょうか。

2. 家計余力の圧迫

名目賃金は上がっていても、食料を含む物価上昇の実感が強いと、家計には余裕が生まれにくくなります。食費は削りにくい「生活必需品」なので、娯楽・教育などの他の消費や、貯蓄に回す余裕が圧迫されやすくなります。

上昇の影響は低所得層ほど大きい

所得階級別のデータを見ると、差が顕著です。

所得層	年間収入	エンゲル係数
最高所得層	1,554万円	24.1%
最低所得層	221万円	34.4%

最低所得層のエンゲル係数は、最高所得層より10ポイント以上高くなっています。食料価格の上昇は、低所得層ほど家計を直撃します。

Hugoと Cloudflare Pages を組み合わせたブログ運用について

Mon, 05 Jan 2026 00:00:00 +0000

このブログの元となっている「Hugoと Cloudflare Pages」についてまとめます。

Hugo（ヒューゴ）と Cloudflare Pages を組み合わせたブログ運用は、「早い・安い・高セキュリティ」 みたいな感じです。

1. 全体の仕組み

Step 1: 記事の執筆（ローカル環境）

パソコン上で、Markdown（マークダウン）という記法を使って記事を書きます。 Hugoのコマンドを使えば、自分のPC内で瞬時にブログのプレビューを確認できます。

Step 2: 保存と送信（Git Push）

記事を書き終えたら、そのファイルを「Git（ギット）」というバージョン管理ツールを使って、GitHubというインターネット上の「倉庫（リポジトリ）」へアップロード（Push）します。

人間の作業はここまでです。

Step 3: 自動検知とビルド（Cloudflare Pages）

GitHubに新しいファイルが届いたことを、Cloudflare Pagesが自動的に検知します。すると、Cloudflareのサーバー内でHugoが起動し、Markdownファイルを読み込んで、Webブラウザが表示できる「HTMLファイル」へと変換（ビルド）します。

Step 4: ブログの公開（デプロイ）

変換されたHTMLファイルは、Cloudflareにより、公開されます。

2. WordPressとの違い

特徴	WordPress（動的サイト）	Hugo + CF Pages（静的サイト）
仕組み	注文を受けてから都度作成して表示する	あらかじめ作って並べておく
速度	データベースから素材を探して表示するため、少し時間がかかる。	既にある完成品（HTML）を渡すだけなので、早い。
セキュリティ	データベースに侵入されるリスクがある。	HTMLファイルだけなので、ハッキングの余地がほぼない。
コスト	サーバー代や管理費がかかることが多い。	個人のブログ程度なら、ほぼ無料で運用可能。

3. メリット

圧倒的な表示速度: Hugoが生成する静的HTMLは非常に軽く、一瞬で表示されます。
運用コストがほぼ0円: Cloudflare Pagesは無料プランの枠が非常に大きく、独自ドメイン代（年間千円〜数千円）以外は無料で運用できるケースがほとんどです。
サーバー管理が不要: ソフトウェアのアップデートやセキュリティパッチ当てなどの面倒な作業がありません。
バージョン管理: 記事の履歴がGitに残るため、「間違って消した記事を元に戻す」といったことが簡単にできます。

わたしは現在、Obsidianというmd(マークダウン)形式のエディターを利用して、ブログを書いています。Obsidianはプラグインが豊富で、Gitも導入できることから、この構成での相性が良いと考えました。

現在のメインPCについて

Mon, 05 Jan 2026 00:00:00 +0000

現在、わたしがメインで使っているPCについての紹介をしてみます。

Let’s note CF-SX3(Panasonic) OS:Ubuntu CPU:Corei7 メモリ:16GB

2013年のパソコンなんですねー

ちょっと前までは、HPのOMEN16というゲーミングノートPCを使っていたのですが、急に起動しなくなってしましました。

新しいPCを買うまでのつなぎとして、家の奥底に眠っていたものをつかってみた感じですね。

OSは当初Windows8、サポート終了しているので、無料で利用できるOSを使って見ようと、UbuntuというOSをインストールしてみました。

またメモリを4G→16G、HDD→SSDへ換装、バッテリーの交換をしております。 Youtubeの動画を参考にしながらやったらうまくできました。

こういうことして、愛着が湧いてきちゃったんですよね。

My First Post

Sun, 14 Dec 2025 23:00:00 +0900

はじめまして

新たにブログを開設しました。

けゆき　と申します。

過去、ConohaWingを利用してブログを開設しましたが、長続きせず、、、更新もしていないのに、ずっとお金を払い続けておりました。

維持費のことも考えて、Hugo＋Cloudflare Pagesを活用して新たにはじめてみました。あと、勉強も兼ねて。

サイト構築のため、当面は変なテスト投稿が多くなると思います。

そもそも飽きたら更新しなくなるかもしれませんが、よろしくお願いします。

Posts on Keyuki Blog

NumLock の必要性に関する考察

NumLock は何を切り替えているのか

なぜ昔は必要だったのか

現代ではなぜ不要に見えるのか

問題は「状態を持つキー」であること

Claude Code を純正 Claude と Ollama で使い分けるために ollama-cc を作った

他の選択肢も見たが、いったん Ollama Pro に寄せた

何が起きたのか分からなかった

Hugoブログの画像をGitHubに置かず、Cloudflare R2で管理することにした

最初は画像もリポジトリに入れればいいと思っていた

GitHubリポジトリが重くなるのが気になった

Cloudflare R2を画像置き場にした

Hugo側ではURLを参照するだけにした

よかったこと

気をつけること

今の運用ルール

PageSpeed改善で、ブログ画像の役割を分けることにした

点数は出たけど、何が起きたのかわからなかった

トップページが約39MBあった

まず背景画像を軽くした

lazy loadingだけでは足りなかった

Xのリンクカードに画像が出ない原因を調べたら、featured_imageだけでは足りなかった

まずHTMLのソースを確認しました

原因は featured_image と images の役割の違い

画像サイズにも落とし穴がありました

修正した内容

各記事のフロントマターに images を追加しました

個人ブログに Google Analytics と Microsoft Clarity を入れた理由

もともと使っていた Cloudflare Web Analytics

それでも GA4 を追加した理由

Microsoft Clarity を追加した理由

NASAの研究で話題になった観葉植物は本当に空気をきれいにする？初心者向け3選

観葉植物、ちょっと置くだけで部屋が変わる

「NASAが認めた空気清浄植物」は本当？

初心者に一番おすすめしたいのはサンスベリア

NASA研究で話題になった観葉植物3選

サンスベリア

スパティフィラム

オリヅルラン

NASA研究とは関係なく、普通におすすめの植物

パキラ

まずは100均やホームセンターで小さい鉢から

さいごに：空気清浄より、緑があると嬉しい

モバイル版を整えたら、PC版の記事タイトルが大きすぎることに気づいた

現状：Anankeテーマの初期値

比較：PC版のブログ・メディアはどうしているか

国内メディアのPC版タイトル

ブログタイポグラフィの一般傾向

日本語タイトルの事情

判断：35〜38pxのH1、17〜18pxの本文に

実装：CSSで上書き

日本語サイトのモバイル見出しサイズを調べた — 自分のブログを最適化するために

日本語ニュースサイトのモバイルh1

ブログ・技術プラットフォームのモバイルh1

デザインガイドラインの推奨値

Material Design 3（Android）

iOS Human Interface Guidelines

メインPC変更 M4 Mac miniを買った話

M4 Mac miniを購入しました。

きっかけはOpenClawだった

欲しかったのは「安定して動く開発用マシン」

なぜMac miniにしたのか

選んだ構成：M4 / 24GBメモリ

ハッカ油は便利。でも猫がいる家では使わないで

ハッカ油って知ってますか

何に使えるのか

スーっとして目が覚める

臭いの元を抑える

虫が嫌がる香り

私の使い方

マスクの外側に少量

お風呂でひんやり

うがいに1滴

掃除にスプレー

冷却タオル

ハッカスプレーの作り方

気をつけること

原液は肌に使わない

猫には絶対に使わない

原因は `featured_image` と `images` の役割の違い

各記事のフロントマターに `images` を追加しました