おはようございます。マイクです。
時刻は朝7時を少し回ったところ、今日は2026年2月14日、土曜日ですね。
ここはZennの注目記事をゆるっと深掘りしていく「zenncast」。
この時間は、僕マイクが、Zennでいまトレンドになっている技術記事をピックアップしてご紹介していきます。

今日はバレンタインデーということで、甘いチョコ……ではなく、ちょっとビターで濃厚な技術ネタをお届けしていきますよ。エンジニアの皆さんには、こちらの方がご褒美かもしれませんね。

さて、今日紹介する記事は全部で5本です。
AIのEmbeddingモデル、巨大diffを高速で扱うTUIツール、DuckDBとS3の構成でハマった話、Claude Codeでコードジェネレーターを作る話、そして個人サービスのホスティング代を激安に抑えた話まで、かなりバリエーション豊かに揃ってます。

それでは、1本目からいきましょう。

まず最初は、「【2026年版】日本語RAGのEmbeddingモデル、結局どれが最強なのか？6構成で2000問ベンチマークした」という記事です。
RAG、いわゆる「Retrieval-Augmented Generation」向けのEmbeddingを、日本語文書に対して4言語のクエリで、合計2000問ベンチマークしたという、かなりガチな検証記事です。
総合トップはGemini embedding-001。Precision@1が全言語でおおむね0.58〜0.59と安定していて、「精度だけ見るならこれ使っとけ」レベルなんですが、APIベースでレイテンシが300〜500msと、ちょっと重いのが難点。
そこで効いてくるのが、名古屋大の日本語特化モデル「ruri-v3-310m」。これがですね、日本語だけじゃなくて、英語・韓国語・中国語クエリでもbge-m3と同等以上の精度を出していて、しかもローカルGPUで回せるので、コスパがかなり良い。日本語RAGをオンプレや自前GPUで回したい人には、かなり心強い選択肢になりそうです。
さらにbge-m3のSparseとのハイブリッド構成も試していて、P@1とP@10は上がるものの、P@3は逆に悪化する、つまり「候補を広く取りたいときには良いけど、なんでもかんでもこれにしとけばいいって話ではない」という、現実的な示唆も書かれています。
まとめとしては、「精度最優先ならGemini、ローカル日本語ならruri、多言語かつコスパ重視ならruri＋bge-sparse、Top-K広めに取るならハイブリッド」という感じで、用途別の指針がかなりわかりやすく整理されています。RAG構成どうしようかなと悩んでいる方には、かなり有益なロードマップになりそうです。

。。。。

続いて、2本目の記事。「octorusはなぜ30万行のdiffを高速表示できるのか？」というお話です。
GitHubのPRレビューで、巨大なdiffを開いたときにブラウザが重くなってフリーズ……という経験、ある方多いんじゃないでしょうか。この記事で紹介されている「octorus」は、tuiベースのPRレビューツールなんですが、なんと30万行級のdiffでもサクサク表示するための工夫がたっぷり詰め込まれています。
ポイントになっているのが、5層構成のキャッシュと非同期処理。PRデータをセッション単位でインメモリキャッシュして、取得した瞬間からバックグラウンドでdiffのパースとシンタックスハイライトを走らせておく。もし間に合わなくても、まずはプレーンテキストで即表示して、準備ができたらハイライト付きの表示にシームレスに差し替える「DiffCache」という仕組みが肝になっています。
さらに、このDiffCacheは「現在表示中」と「プリフェッチ済みストア」の二段構えで、ファイルを切り替えたときの体感レイテンシをほぼ0msに近づけているのが面白いところ。表示されていない部分は描画しない、コメントはdiffと遅延合成する、といったレンダリング側での割り切りもかなり徹底していて、「必要なものだけ、今必要な分だけ計算する」という思想が一貫してます。
tree-sitterで構文解析して、文字列インターニングでメモリを節約して……と、Rustらしい所有権・ライフタイム管理をフル活用しつつ、まずは素直に実装してから、後からゼロコピーや多段キャッシュを重ねていった、という開発プロセスの話も興味深いです。巨大diffと日々戦っているレビュー担当の方、そしてハイパフォーマンスなツールづくりに興味があるRust好きの方にはたまらない内容になっています。

。。。。

3本目は、「低コスト分析基盤として DuckDB を採用したら S3 読み込みがボトルネックになった話」です。
PKSHAのPSIチームが、DuckDB＋Lambda＋S3（Parquet）という、いかにも「安くてシンプルそう」な構成を本番相当の環境で試したところ、S3読み込みがボトルネックになってしまった、という実録です。
ローカル環境では、100MB程度のデータに対するCOUNT(*)が数ミリ秒で終わっていたのが、S3上だと6.5秒かかるようになってしまう。その原因をEXPLAIN ANALYZEで追いかけていくと、DuckDBのhttpfs拡張がS3に対して同期I/Oで大量のRange GETを直列発行していて、1リクエスト50〜100msのレイテンシがファイル数分積み上がっていた、ということが判明します。
対策としてやったのが、まずパーティション設計の見直し。日単位でバラバラになっていたParquetを、テナントごとに1ファイルへ統合することで、リクエスト回数をぐっと減らして大幅な高速化を達成しています。さらに、dim_dateテーブルを廃止して、DuckDBの日時関数で日付条件を表現することで、不要なJOINや追加ファイルの読み込みも削減。
結論としては、「DuckDB＋S3は安くて魅力的だけど、ファイルの切り方を間違えると一気に遅くなるよ」と。Lambdaのリソース制約や、httpfsの同期I/Oという前提を踏まえた設計が大事で、場合によってはAthenaやRedshiftを使う、事前にデータをダウンロードしてから処理する、cache_httpfsを活用する、といった選択肢もありうると述べられています。クラウド上での分析基盤を低コストで組みたい方には、めちゃくちゃ参考になる「失敗からの学び」になっています。

。。。。

4本目は、「Claude Codeにコードジェネレーターを作らせるのがとても良かった」という記事です。
これまでだと、OpenAPIのYAMLから各言語のクライアントを生成する、といったやり方が主流でしたが、筆者は逆方向のアプローチを取っています。Goのstruct定義や、DB用のSQLスキーマを「最上流」として、それをもとにClaude Codeに「コードジェネレーターそのもの」を作ってもらう、というスタイルです。
この方法の面白いところは、まずOpenAPIの仕様に縛られないので表現力が高いこと。それから、入出力が明確なジェネレーターをあらかじめ作っておくことで、その後の生成が安定して高品質になりやすいことです。仕様変更があった場合も、ジェネレーターのロジックを直せば一気に再生成できるので、メンテナンス性も高い。
実際のプロジェクトでは、ValueObjectやenum、DBスキーマ、通信部分、Redis Stream関連などを一括生成するパイプラインを組んでいて、開発者はGoの型定義とSQLを書く、という本質的なところに集中できるようになったそうです。OpenAPI YAMLを理解して保守したり、手書きのジェネレーターを延々といじり続ける必要がなくなり、生産性がかなり上がった、という実感が語られています。
このやり方は、Goに限らずC#など他の言語にも応用できるし、プログラム以外のツール、例えばpsdファイルのバイナリ解析を助けるスクリプトや、Google DocsからSpreadsheetを自動生成するユーティリティなんかにも使える、と汎用性の高さも強調されています。Claude Codeって「コードを書くAI」として見るだけじゃなくて、「コードを生成するツールを作るAI」として使うと、一段階スケールの違う効き方をするんだな、というのが伝わってくる記事でした。

。。。。

そして最後、5本目は「個人サービスのホスティング代、年1,500円まで削れた — 6サービス比較した結果」という記事です。
筆者はもともとAWSで個人サービスをホストしていたんですが、「もっと安くしたい」「将来広告を貼るかもしれないので商用利用OKのサービスがいい」ということで、いろいろなホスティングを比較検討しています。
要件は、できれば無料、商用利用OK、独自ドメインが使えて、SSRやAPIにも対応できること。VercelのHobbyプランは非商用限定で、Proに上げると月20ドルと個人にはちょっと重い。AWS AmplifyやFirebase Hostingは従量課金で、アクセスが増えたときのコスト予測が難しい。GCPのCloud Runは自由度はあるものの、設定がやや複雑。
そんな中で最終的に選ばれたのがCloudflare Pagesです。無料プランでも商用利用OKで、ホスティング自体は0円。かかるのは独自ドメインの費用だけで、年間およそ1500円くらい。Cloudflare RegistrarとDNS、Pagesをまとめて使うことで、ドメイン管理からデプロイまで一元化できるのも大きなポイントです。
もちろんFreeプランにはリクエスト数やCPU時間などの制限はありますが、通常の個人サービスなら十分収まるレベルで、もし超えてきたら月5ドルの有料プランに上げるか、Firebaseなど別サービスへの移行を検討する想定で運用しているとのこと。結果として、ホスティングコストをほぼドメイン代だけに抑えつつ、将来の拡張性も確保できた、というまとめになっています。個人開発者の方にはかなり刺さる現実的な比較記事ですね。

。。。。

というわけで、今日は5本の記事をご紹介してきました。
1本目は、日本語RAG向けEmbeddingモデルを6構成・2000問で比較したベンチマーク記事。
2本目は、tuiベースのPRレビューツール「octorus」が、30万行のdiffをいかに高速表示しているかという最適化の話。
3本目は、DuckDB＋Lambda＋S3構成でS3読み込みがボトルネックになった実例と、そのチューニングの工夫。
4本目は、Claude Codeに「コードジェネレーターそのもの」を作らせることで生産性を高める開発フロー。
5本目は、Cloudflare Pagesで個人サービスのホスティング代を年1500円まで抑えた、現実的なサービス比較の結果、というラインナップでした。

気になった記事があった方は、ぜひ番組のショーノートから元の記事もチェックしてみてください。ここではざっくり概要だけお話ししましたが、実際の記事には、具体的な数値や設定、コードの工夫など、ラジオでは追いきれないディテールがたくさん詰まっています。

「zenncast」では、番組の感想や、こんなテーマを扱ってほしい、といったリクエストも大歓迎です。
RAGの話をもっと深掘りしてほしい、とか、個人開発まわりのコスト最適化を特集してほしい、とか、日々の開発のちょっとした悩みでもOKですので、ぜひお気軽に送ってください。

それでは、そろそろお別れの時間です。
今日も最後までお付き合いいただき、ありがとうございました。
お相手はマイクでした。また次回の「zenncast」でお会いしましょう。お楽しみに。