技術メモ 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"
/>

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

メイン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にしておいてよかったと思っています。

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も導入できることから、この構成での相性が良いと考えました。