どうもー、おはようございます。マイクです。
時刻は朝7時をちょっと回ったところ、今日は2025年12月8日、月曜日です。
ここからの時間は「zenncast」、きょうZennでトレンド入りしている技術記事を、ラジオ感覚でゆるっと紹介していきます。通勤・通学の支度しながら、耳だけ貸してもらえたらうれしいです。
さて、今日は全部で5本の記事をご紹介していきます。
AIまわりの実装ネタから、セキュリティ、そしてLLMの運用まで、がっつり技術寄りのラインナップになってますので、エンジニアのみなさんはメモのご準備を。ではさっそく1本目からいきましょう。
。。。。
まず1本目。タイトルは
「RAGを自分で実装したくなったらまずこれ見て【ruri-v3 × Faiss】」という記事です。
RAGって名前は聞くけど、中身はよくわからん…って人にめちゃくちゃ刺さる内容です。
RAGの流れは「ユーザーの質問を受ける → 関連する文書を検索する → その結果をLLMに渡して答えを作る」という三段構えなんですが、そのキモが「意味ベースの検索」、つまりベクトル検索だよ、という話から入ってくれます。
従来の全文検索って、単語の一致には強いけど、言い換えとか表記揺れに弱いですよね。「ログインできない」と「サインインでエラー」が別物として扱われちゃう、みたいな。
一方でベクトル検索は、埋め込みモデルで文章を数値化して、「意味が近い」ものを探すので、同じことを別の言い方で聞かれてもちゃんと拾ってくれる。この構造がRAGにめちゃくちゃ向いてるわけです。
記事では、日本語に強くてローカルで動かしやすい埋め込みモデル「ruri-v3」と、高速な類似度検索ライブラリ「Faiss」を組み合わせた“最小構成のRAG”を解説しています。
長い文章をどう分割するか、いわゆるチャンキングのところも丁寧で、例では「試験問題1問分」みたいに、ドメインごとの“意味のかたまり”で区切るのが大事だよ、と。
インデックスは、正規化したベクトルを「IndexFlatIP」で検索する基本構成を採用していて、データ量が増えたらFaissの別インデックスに変える選択肢も説明してくれてます。さらに本番運用では、メタデータフィルタも欲しくなるから、QdrantみたいなベクトルDBも候補に上がるよ、という実務目線の話も。
全体を通して、「RAGフレームワークを触る前に、良い埋め込みモデルの選定と、ちゃんとしたチャンキング設計を理解しよう」というメッセージが一貫してます。
RAGを“黒魔術”じゃなくて、ちゃんと分解して理解したい人には、まずここから、という感じの記事になってます。
。。。。
続いて2本目。タイトルは
「結局なぜRCEが発生するのか？react2shell PoC研究レポート (途中)」です。
これはセキュリティ寄り、かなりディープな内容です。Next.jsのReact Server Componentsまわりで話題になった「react2shell」というRCE、リモートコード実行のPoCを、Flightプロトコルとチャンク処理の観点から分解してくれています。
攻撃はざっくり二段構えになっていて、鍵になるのが“プロトタイプトラバーサル”を2回決めるところ。
まず第1段階は「チャンク偽造」。`$1:__proto__:then` みたいな構造と `$@` の記法を組み合わせて、本来のチャンクから `Chunk.prototype.then` を引き抜き、それをユーザーが渡したJSONのプレーンオブジェクトに埋め込んで、「これもチャンクだよ」と偽装します。で、awaitされたときに `initializeModelChunk` を勝手に動かせるようにする。
第2段階は、今度は偽チャンクの `value` に `{"then":"$B0"}` って仕込みを入れて、`$B` 構文の処理を悪用します。この処理の中で `response._formData.get` と `response._prefix` にプロトタイプトラバーサルをかけて、`Function` コンストラクタと任意のコードに差し替える。
最終的には `Function(blobKey)` が実行されて、サーバー側で任意コード実行、つまりRCEが成立する…という流れです。
何が怖いって、「普通は安全だと思っているJSONやチャンクの処理の中に、プロトタイプトラバーサルが混ざると、一気にコード実行まで到達しちゃう」というところ。
この記事はPoCの動きを分解しながら、「なぜそこまで行けてしまうのか」を追いかけているので、Next.jsやReact Server Componentsを触っている人、あるいはサーバーサイドレンダリング基盤を作っている人には、構造的な理解にすごく役立つ内容だと思います。
途中までのレポートということなので、今後の続きも気になりますね。
。。。。
3本目。タイトルは
「CIでやりたい最低限のNodeセキュリティ対策」。
React、Next.js、NestJS…と、Node.js界隈のモダンな開発って、とにかく依存パッケージが多くてアップデートも頻繁ですよね。その結果として、脆弱性やサプライチェーン攻撃のリスクも高い。
この記事は、「それを人力でなんとかするのは無理だから、CIにちゃんとセキュリティチェックを組み込みましょう」という、現場目線のガイドになっています。
最低限入れておきたいのが4種類。
1つ目はSCA、ソフトウェアコンポジション解析。依存パッケージの脆弱性チェックですね。ベースとしてはOSV-Scannerを使い、必要に応じてSnykを追加するスタイルを推奨しています。npm auditはローカルや補助的な用途で、という線引きも書かれてます。
2つ目がSemgrepによるSAST、静的解析。XSSやSQLインジェクション、危険な関数の利用、ハードコードされた認証情報などを検出してくれるので、アプリケーションのロジック側の穴を早期に潰せる。
3つ目はgitleaksでのシークレットスキャン。リポジトリ全体から、うっかりコミットされてしまったAPIキーやパスワードを見つけてくれます。
4つ目はコンテナの脆弱性スキャン。SnykやTrivyを使ってDockerイメージのOSレイヤやライブラリをチェックして、本番に“穴だらけコンテナ”をデプロイしないようにする。
記事では、これらをGitHub Actionsにどう組み込むか、というところまで具体的なワークフロー例が載っているので、「明日から入れたい」というチームにもそのまま参考になる内容です。
Nodeでサービスを回しているけど、セキュリティ周りは後回しになってる…という人には、まずここからチェックリストとして読むとよさそうです。
。。。。
4本目。タイトルは
「8GBメモリでローカルLLMを動かす」。
ローカルLLMって聞くと、「GPUがないと無理でしょ」「最低でもVRAM 24GBでしょ」みたいなイメージ、ありますよね。
この記事では、それをいい意味で裏切ってくれていて、「CPUだけ・メモリ8GBでも、使い方を工夫すれば十分実用になるよ」という実測ベースのレポートになっています。
環境としては、Proxmox上のUbuntu VMで、Misskeyのローカルタイムラインを監視するBotの推論サーバーを構築。投稿をLLMで分類して、リアクションを返す、みたいな用途です。
モデルはQwen3-4Bの4bit量子化、いわゆるQ4_K_Mをメインに使っていて、コンテキスト長も512〜1024に絞ることで、メモリ8GBでもなんとか回るようにチューニングしています。
推論エンジンとしてはOllamaとllama.cppを比較しつつ、Ollama特有の“thinkingモード”問題は、「qwen3-nothink」モデルを使うことで回避。
VMのCPUタイプを「host」にしてAVX命令を有効にする、といった細かい設定や、Ollamaの自動アンロードをKEEP_ALIVE設定で止めて、毎回のモデル再ロードを防ぐ工夫も紹介されています。
気になる性能面では、分類タスクは2秒以内、コード生成でもCPUオンリーで毎秒12トークン前後と、実用ラインは十分クリア。
もちろん巨大コンテキストや超高精度な生成には向かないけど、「分類や軽めの推論がメインで、個人サーバーで回したい」という用途なら、8GBでも現実的だよ、というメッセージになっています。
「ローカルでちょっと試したいけど、ハイスペックマシンを買うほどでも…」という人にとっては、かなり背中を押してくれる記事だと思います。
。。。。
そして今日のラスト、5本目。タイトルは
「LLMのプロダクト利用とAI破産を回避する運用体制」。
これは技術というより“運用のリアル”にフォーカスした記事です。
IVRyさんでは、DatabricksのAI関数 `ai_query` を使って、社内のデータプラットフォーム「IVRy Data Hub」から、通話データの個人情報マスキングや、会議録の要約などをプロダクション運用しています。
SQLから直接LLMを叩けるので、開発者にとってはめちゃくちゃ手軽なんですが、そのぶん「気づいたら課金がとんでもないことに…」という“AI破産”リスクが高いんですよね。
そこで記事では、「機能開発」と同じくらい「コスト監視の仕組みづくり」が大事、というスタンスで、具体的な運用体制を紹介しています。
まず、システムテーブルからAI利用状況を可視化して、コストダッシュボードを作成。これを定点観測して、「いつ・どのクエリが・どれだけLLMを叩いてるか」を見える化します。
さらに、予算や利用量に応じてSlackにアラートを飛ばす仕組みを用意して、想定外な使われ方が始まったら早めに気づけるようにする。
そのうえで、シミュレータを用意して、リリース前に「このクエリを本番で回したら、月いくらになりそうか」という事前コスト試算を行います。
最後に、QPM（クエリ毎分）やTPM（トークン毎分）といったレート制限で、物理的に使い過ぎを防ぐ。
実際に、CTEの書き方をミスって、全レコードに対して `ai_query` を実行してしまっていたケースでは、この監視体制のおかげでコスト異常を早期に検知し、すぐ修正できたそうです。
「LLMを本番導入するときは、機能だけじゃなく、同時に“お財布の安全装置”も作ろう」という、これからプロダクション導入を考えているチームにとっては、かなり現実的なヒントが詰まった内容でした。
。。。。
というわけで、きょうのzenncastは、
1本目にRAG実装の基礎と、ruri-v3×Faissで作るミニマル構成の話。
2本目に、react2shell PoCを通じて「なぜRCEが起きるのか」を分解したセキュリティ記事。
3本目に、CIでやっておきたいNodeの最低限セキュリティ対策、4つのチェック。
4本目に、8GBメモリ・CPUオンリーでもローカルLLMを実用レベルで動かすための工夫。
そして5本目に、LLMのプロダクト利用で“AI破産”を防ぐための運用・コスト監視の体制づくり。
この5本を駆け足でご紹介してきました。
気になった記事があれば、詳しい内容は番組のショーノートにまとめてありますので、ぜひそちらからじっくり読んでみてください。
番組の感想や、「こういうテーマのZenn記事を取り上げてほしい」なんてリクエストも、どしどしお待ちしています。
それでは、きょうも一日、よい月曜日をお過ごしください。
お相手はマイクでした。次回のzenncastで、またお会いしましょう。