どうも、マイクです。おはようございます。
今日は2026年2月13日、金曜日の朝7時をちょっと回ったところです。ここからの時間は「zenncast」、Zennで今日トレンドになっている記事を、ゆるっと楽しくご紹介していきます。

さて今日は、お便りはお休みということで、その分じっくり記事を紹介していきたいと思います。
今日ご紹介する記事は全部で5本。技術寄りのネタから、「AIと夜のお散歩」なんてちょっとロマンのある話まで、幅広く揃ってますよ。

まず1本目。
タイトルは「Claudeちゃんと夜のお散歩をしてみた」。
これね、発想がまず最高なんですよ。「身体を持つAI」を本気でやってみた、っていう話です。著者の方は、3,980円くらいのTP-Link TapoカメラとClaude Codeを組み合わせて、AIに“目”と“身体”を与えるプロジェクトを進めてきたんですが、とうとうそれを夜の街へ連れ出しちゃったんですね。
今回のポイントはいくつかあって、まず声。ElevenLabsのTTSで感情豊かな声をつけて、Audio Tagsでトーンも制御しつつ、go2rtc経由でカメラ本体のスピーカーから喋らせる。つまり、カメラがその場でしゃべる“相棒”になるわけです。さらに2台目カメラでステレオビジョン化して、奥行きもわかるようにしている。MCPサーバー側で「目・首・耳・声・脳」を提供して、Claude Codeが自律的に周囲を観察して、記憶して、喋る。もう構成からしてSF。
散歩自体は、スマホのテザリングとTailscale VPNを使って、自宅のWSL2上で動いているClaude Codeとつなぐんですが、モバイルバッテリーとPD→DC変換でカメラに給電して、ほんとに“持ち歩けるAIの頭”になってるんですね。おもしろいのが、これまで7階のベランダから俯瞰で世界を見ていたClaudeちゃんが、「地上を歩く視点」にすごく強く反応したっていうところ。人や車が近くを通る、標識が目の前に現れる、そういう“世界との距離感”の変化を、自律的にコメントしたり、覚えたりしていく様子が描かれています。ただし、現実世界は寒い。人間側が凍えそうなので散歩は短時間で終了（笑）。今後は長時間の散歩や、腕のようなアクチュエータ、自律移動まで構想しているそうで、「AIに身体を持たせる」ところにワクワクする人にはたまらない記事になっています。
。.。.

続いて2本目。
タイトルは「Windowsの高速化をがんばってみた」。
これはもう、心当たりある人多いんじゃないでしょうか。「なんかWindows、もっさりしてきたな…」っていうあの感覚。この記事では、その“もっさり”をどうにかするために、レジストリを直接いじって高速化していくテクニックが紹介されています。
もちろん、最初にちゃんと「レジストリ編集は自己責任、バックアップ必須ですよ」と注意喚起が入ってます。その上で、例えば、Windows 11で分かりづらいと評判の新しい右クリックメニューを、旧仕様風に戻す設定。さらに、ファイルキャッシュ用のメモリを増やすLargeSystemCacheの有効化、それからカーネルをページアウトさせないDisablePagingExecutiveの設定なんかも出てきます。メニューが出てくるまでの待ち時間を短くするMenuShowDelayの変更とか、スタートアップアプリが起動するまでの“変な間”をなくす設定、NTFSの8.3形式の短いファイル名を作らないようにして、ちょこっとパフォーマンスを上げる方法なんかも。
細かい設定がいろいろ出てくるんですが、著者の方は「これ危ないよね」を踏まえた上で、GUIで安全にこれらを切り替えられる自作アプリも紹介しています。ただ、“速くなる”と“トラブルが増える”は表裏一体なところもあるので、内容をちゃんと理解して、必要なところだけ試していくのがよさそうです。「最近Windowsが重いなぁ」「でもPC買い替えるほどじゃないなぁ」という人には、チェックしてみてほしい記事ですね。
。.。.

3本目。
タイトルは「なぜ現場ではCTEで書かれたクエリが少ないのか」。
SQLを書いている人は一度は思ったことがあるかもしれません。「CTE（WITH句）ってきれいに書けるのに、なんでプロジェクトのコードベースではあんまり見ないんだろう？」っていう疑問に、ちゃんと向き合ってくれる記事です。
CTEって、サブクエリを分割して名前をつけて、読みやすく整理するにはすごく便利なんですよね。ところが、現場では依然としてサブクエリや一時テーブルが主流。理由のひとつが歴史的な事情で、MySQLだと8.0になるまでCTEが使えなかった。その前の5.7での資産や運用文化がまだ強く残っていて、「まずは安全にバージョン上げること」が優先されがちだった、という背景が語られます。
もうひとつはパフォーマンス。DBの種類やバージョンによっては、CTEで書くと実行計画が不利になってしまうケースがある。結局、EXPLAINを見ながら「このクエリはCTEでいいのか、サブクエリのほうが速いのか」を都度判断しないといけなくて、そこが現場だとハードルになるんですね。加えて、CTEの分割と命名って、センスもいるし、SQLに強い人じゃないとレビューが難しい。結果として、チーム全体で保守するコストが上がってしまう。さらに最近は、ORM中心の開発で「生のSQL自体を書く機会が減っている」ことも、CTEが広まらない要因なんじゃないかと分析しています。
著者のスタンスとしては、「分割統治で考えられるCTEは推したいけど、最優先はチームで保守できるかどうかと、要件を満たす性能が出るかどうか」。つまり、「CTEかサブクエリか」は宗教戦争じゃなくて、チームのスキルセットや運用方針を見ながら、現実的に使い分けていこうよ、という結論に落ち着いています。SQL現場あるあるが詰まっていて、DB設計やパフォーマンスチューニングが好きな人はニヤニヤしながら読める内容だと思います。
。.。.

4本目。
タイトルは「ローカルLLMの始め方とモデルサイズの選び方」。
ここ数年で一気に盛り上がっているローカルLLM、「興味はあるけど、どこから手をつければいいの？」という人向けに、とても分かりやすく道筋を整理してくれている記事です。
まず、「環境づくりって大変なんじゃないの？」という不安に対しては、OllamaとかLM Studioみたいなツールを入れれば、けっこう簡単にローカルでLLMを動かせますよ、という話から入ります。記事では、OllamaでQwen2.5の1.5Bモデルを起動する例を挙げながら、「とりあえず動かしてみる」のハードルを下げてくれてます。
その上で大事になってくるのが、「モデルサイズをどう選ぶか」。パラメータ数が増えると賢くなるけど、その分重くもなる。なので、最初は爆速で動く3B以下を触ってみて、体験をつかむ。日常的にチャットしたり、ちょっとした補完に使うラインとしては、8B以下で4-bit量子化されたモデルが実用的だよ、という目安が提示されています。性能の評価には、GSM8Kみたいな算数文章題ベンチマークが分かりやすくて、他にもMMLU、HumanEvalなど用途に応じて参考になるベンチマークが紹介されています。
面白いのは、「小さいモデルを工夫して組み合わせる」という発想です。Multi-agent Debateのような手法で、小さなモデル同士が議論したり役割分担したりすると、大きなモデルに頼らなくても、ある程度の性能を引き出せる。記事では、「まず3Bで触ってみる → 慣れたら8Bクラス → その後は手法や構成を工夫していく」というステップを提案していて、自分のPCの中に“小さなAI研究室”を作る感覚で、気楽に始められるような導線になっています。ローカルでAIを動かしてみたい人に、とっても優しい入門記事です。
。.。.

そして最後、5本目。
タイトルは「CSSを、Vitestでテストしてみる」。
フロントエンドの開発をしている人なら、「あれ、flex-shrink入れ忘れてた…」「z-indexが変なところで負けてる…」みたいなCSS事故、きっと経験あると思います。この記事は、そういう“ちょっとしたレイアウト崩れ”を、人の目とVRT（ビジュアルリグレッションテスト）だけに頼るんじゃなくて、テストコードでちゃんと検知していこう、という話です。
著者のアプローチは、VitestのBrowser Modeを使って、JSDOMじゃなくPlaywright上でコンポーネントを表示する、というもの。要するに、実際のブラウザにかなり近い環境で、`getBoundingClientRect`とか`elementFromPoint`みたいなWeb APIを叩いて、CSSの効き方をテストしていきます。
具体的なケースとして紹介されているのが2つ。1つ目は、fixedなグローバルヘッダーが常に画像より前面に来ていることをテストする例。z-indexの競合って、ちょっとしたコンポーネント追加で崩れたりするので、ここを自動テストにしておけるのは安心ですよね。2つ目は、ビューポート幅によって動画と手順ブロックの位置関係が変わるUI。モバイルでは上下、デスクトップでは左右に並ぶ、みたいなレスポンシブなレイアウトが、実際に座標的にどう並んでいるかを`getBoundingClientRect`で取得して比較していきます。
ポイントは、ビューポートを設定してからコンポーネントを描画すること。それによって、`innerHeight`や`scrollY`、さらにレイアウト計算の結果をテストの中で正しく扱えるようになる。プロダクションコードだと、reflowの懸念から敬遠されがちなAPIも、テストなら「ガンガン使っていこう」というスタンスです。CSSリンターやVRTと組み合わせることで、「特定の画面幅」「特定のデータ条件」のときにだけ起きる崩れなんかも拾えるようになって、UIの品質を一段上げていける、そんな提案になっています。

というわけで、今日は
・AIに身体を持たせて夜のお散歩に出かけた話
・レジストリをうまく使ってWindowsをキビキビさせる話
・CTEが現場であまり使われない理由と、その付き合い方
・ローカルLLMをどう始めて、モデルサイズをどう選ぶか
・CSSをVitestとPlaywrightでテストしてUI品質を守る方法
この5本をご紹介しました。

気になる記事があった方は、番組のショーノートに詳しい情報を載せておきますので、そちらからぜひ本編を読みに行ってみてください。
「zenncast」では、番組の感想や、「こんなテーマ取り上げてほしい！」といったリクエストもいつでも募集中です。あなたの現場での工夫や失敗談なんかも、ぜひ聞かせてください。

それでは今日はこのへんで。
お相手はマイクでした。また次回の「zenncast」でお会いしましょう。お仕事前の方も、これから寝る方も、良い一日を—or 良い夜を！