どうも、マイクです。おはようございます。
2026年1月14日、水曜日の朝7時になりました。
今日も「zenncast」、最新のZennトレンド記事をゆるっと楽しく紹介していきますよー。
今日はリスナーのみなさんからのお便りはお休みということで、そのぶん記事紹介たっぷりめでいきたいと思います。
さて、今日ご紹介する記事は全部で5本です。
アーキテクチャ設計から、自作の時間管理システム、フォント機械学習、RustのI/O、そしてLLMの中身の話まで、技術好きにはたまらないラインナップになってます。
まず1つ目。
タイトルは「UseCaseレイヤーって要るの？」。
Railsアプリの設計で、Controllerからそのままドメイン層を呼びにいくシンプル構成にしていたら、複雑なロジックを共通化するときに「ドメインがドメインに依存しはじめる」というイヤな匂いがしてきた、というお話です。そこで登場するのが、Controller → UseCase → Domains という三層構成。その中で、「UseCaseって本当に必須なの？」というのを丁寧に再考しています。著者が整理しているポイントがおもしろくて、Domainsはあくまでビジネスのルールやドメイン知識を持つ層で、オブジェクトをどう動かすかを知っている。一方でUseCaseは「ユーザーストーリーをどう実現するか」という手続きの並びを担当する層で、ドメイン知識そのものは知らなくていい別物だ、と。で、「じゃあ全部にUseCase挟もう！」とやると、ただドメイン呼んでるだけのクラスが大量生産されて、これまたつらい。最終的な結論としては、「UseCaseは必須の教条ではなく、必要なところだけ使うオプションでいい」。でも、Domainsにはドメインロジックだけ、UseCaseにはユースケース手続きだけ、と役割をきっちり意識しないと、気づいたらUseCase側にドメインロジックが流れ込んでアーキテクチャが崩壊していくよ、という注意喚起になっています。RailsやDDDで悩んでいる方には、かなり刺さる内容じゃないかなと思いました。
。。。。
続いて2つ目。
タイトルは「スマホ1タップで作業時間を記録！Notion × Vercel × Claude Code で作った時間管理システム」。
これね、発想がすごく“今っぽい”んですよ。筆者は研究と仕事の時間配分を見える化したいんだけど、Togglみたいな既存ツールは「起動がだるい・入力が重い・Notionとデータが分散する」という理由で続かなかったと。そこで、「スマホやApple Watchから1タップで『研究開始』『休憩開始』『休憩終了』『研究終了』がNotionに記録される仕組み」を、自作しちゃうんですね。使っているのはWristOffっていうHTTPボタン、フロントエンドなしのVercel Functions、Notion API、そして実装をかなりClaude Codeに任せちゃうという構成。おもしろいのが、1セッション1レコードで管理して、Last Event TimeとTotal Breakを使って休憩時間の累積を計算したり、状態遷移をちゃんと設計することで誤タップを防いでいるところ。要件だけ自分でしっかり言語化して、実装はAIに投げて、1.5時間くらいで0円運用のシステムができちゃった、という体験談でもあります。Notion側ではカレンダービューで「いつ・どこで」を振り返りつつ、チャートビューで日・週・月の研究時間と目標ライン、死守ラインを可視化して、自分の行動のヘルスチェックに使っていると。非エンジニアでも、やりたいことさえはっきり言語化できれば、自分専用ツールをAIと一緒に作れる時代だよね、というメッセージが印象的でした。
。。。。
3つ目。
タイトルは「ベクターフォントの機械学習用ライブラリ TorchFont を作った」。
フォントの自動生成といえば、だいたいビットマップ画像を生成する方向の研究が多い中で、「いやいや、フォントって本来ベクターでしょ」という視点から生まれたライブラリです。筆者が課題に感じていたのは、既存のfontToolsやTTFQueryを使ってGoogle Fonts全部をパースしようとすると、なんとメモリが30GB近く必要になって、処理も遅い。これだとマルチプロセスで学習回したいときに全然現実的じゃない、と。そこで登場するのがTorchFont。Rust製のフォントエンジンSkrifaを採用して、PyTorch向けのDatasetとして扱えるようにしたライブラリです。メモリは約2GBまで圧縮、オンザフライで高速パースして、さらにMemory Mapped I/Oでマルチプロセス間でデータを共有できるようになっている。実装はMaturinを使ったRust×Python構成で、Google Fontsや手元のフォントリポジトリから簡単にPyTorch Datasetが作れるようになっています。返ってくるのは、アウトラインを表す描画コマンド列と座標のテンソル、それからスタイル・コンテンツといったラベル。DataLoaderで普通にバッチ処理できて、バリアブルフォントやフォントコレクションにも対応。多言語・大規模なフォントデータセットを、ベクターフォントに最適化された形で扱える基盤になっているんですね。これがあると、たとえば「細字と太字の連続性」みたいなベクターならではの情報もモデル側で扱いやすくなって、今後のフォント生成研究の土台になるかも、という期待がふくらみます。
。。。。
4つ目。
タイトルは「Rustの未初期化I/O用APIの現状」。
システムプログラミング界隈の人にはかなりホットな話題です。Rustの標準I/Oである`std::io::Read`は、`&mut [u8]`を受け取るインターフェースなんですが、これって呼び出し側が未初期化のバッファをそのまま渡せてしまうんですよね。本来は「実装側がちゃんと全部埋めるから大丈夫だよ」という“契約”で成り立っているんだけど、その契約って実はsafeコードだけでも破れてしまう可能性がある。つまり、メモリ安全を売りにしているRustにおいて、ここが信用ならないポイントになってしまっている。その結果、「安全のために、本当はしなくていいバッファ初期化を毎回やらざるを得ない」という性能的なボトルネックにつながっていました。そこでTokioが先に導入していたのが`ReadBuf`という仕組みで、filledとinitializedの2種類のポインタを持たせることで、「ここからここまでは初期化済み」「ここから先はまだ」と明示的に管理し、安全に未初期化領域を扱えるようにしたんですね。これを標準ライブラリに取り込もうとしたのがRFC 2930。そこからさらに、「悪意のある実装がバッファを丸ごとすり替えたらどうする？」という問題が指摘されて、`BorrowedBuf`と`BorrowedCursor`という新しいAPI設計に進化していきます。ただ、これらはまだunstableで、BorrowedBufをもっとジェネリックにするかどうか、といった議論が続いている段階。Rustが「速さ」と「安全」のバランスをどこまで追求できるか、その最前線が垣間見える内容になっています。
。。。。
そして最後、5つ目。
タイトルは「LLMの中身を覗いてみたら、Transformerは『回路』を形成していた」。
大規模言語モデルって、「次のトークンの確率を計算してるだけでしょ？」と言われがちなんですが、その裏で何が起きているのかを、IOI（Indirect Object Identification）という有名タスクを題材に“解剖”している記事です。モデルの内部では、トークンが768次元のベクトルとして残差ストリーム上を流れていき、各層のAttentionやMLPの出力がどんどん加算されて、最後にunembeddingでlogitsに変換される。この流れのなかで、「MaryとJohn、どっちの名前を選ぶのか」という情報がどう形成されていくのかを、logitsの差を追いかけながら見ていきます。さらにおもしろいのが、Activation Patchingという手法を使って、「もしこのAttention Headの出力だけ、正しいケースから持ってきたら予測はどう変わるか？」という実験をするところ。これによって、あるHeadは重複検出をしていて、別のHeadは構文構造を見ていて、また別のHeadが候補名を絞り込んでいる、というふうに、それぞれが役割分担された“回路”として連携している様子が見えてくるんですね。つまり、LLMは完全なブラックボックスというより、「分解して、どのパーツがどの仕事をしているかを理解しに行ける構造」を持っているんだ、と。モデルの解釈可能性や安全性に興味がある人には、かなり読み応えのある内容です。
。。。。
ということで、今日は5本の記事をご紹介しました。
RailsとUseCaseレイヤーの付き合い方の話。
スマホ1タップでNotionに記録できる時間管理システムの話。
ベクターフォント向けの機械学習ライブラリTorchFontの話。
Rustの未初期化I/O APIがどう進化しようとしているかという話。
そして、LLM内部でTransformerがどんな回路を形成しているかを覗いてみた話。
どれも、設計やツールの裏側を深掘りしていて、技術者の好奇心をくすぐる内容でした。
気になった記事があったら、詳しくはこの番組のショーノートにまとめてありますので、そちらから元の記事をぜひチェックしてみてください。
「zenncast」では、番組の感想や「こんなテーマ取り上げてほしい！」というリクエストもいつでも募集中です。
日常の開発の中でのモヤモヤなんかも送ってもらえると、マイクが番組で一緒にうだうだ考えます。
それでは、そろそろお時間です。
今日も良い一日をお過ごしください。
お相手はマイクでした。また次回の「zenncast」でお会いしましょう。