どうもー、おはようございます。マイクです。「zenncast」朝の部、始まりました。
今日は二千二十六年九月五日、土曜日の朝七時をちょっと回ったところです。皆さんいかがお過ごしでしょうか。

この番組では、Zennに上がっている技術系の記事の中から、今ホットなトレンド記事をピックアップして、ゆるっと、でも中身はしっかりめにご紹介していきます。通勤中の方も、お家で支度してる方も、耳だけ貸してもらえればオッケーです。

さあ、今日は記事を五本ご紹介していきます。ボリュームたっぷりなので、コーヒー片手にお付き合いください。

まず一つ目。
大量データを扱う在庫計画の画面で、六十六万セル規模の表を、とにかく「スクロールしても快適」に動かすために、TanStack Virtual を導入した実践レポートです。

この在庫計画の画面、縦方向はページ全体のスクロール、横方向はカード内でのスクロール、というちょっとトリッキーな構成なんですね。そこで、縦と横、それぞれの軸を別々のフックで仮想スクロールさせる、つまり「二軸それぞれでバーチャルスクロールをかける」という設計にしています。

記事のポイントとして面白いのは、「初期表示を速くする」だけじゃなくて、「スクロール中の一フレームあたりの計算量」をどれだけ減らせるか、ここにかなりこだわっているところです。ブラウザって、スクロールしながらも頑張って描画を更新しているので、一コマ一コマの処理が重いと、すぐカクカクしちゃうんですよね。

一方で大変だったのが、ヘッダーの `sticky` とスクロール枠の関係です。本来なら CSS だけでなんとかしたいところなんですが、今回はスクロール領域が複雑で、ヘッダーの位置を自前で計算しないといけなくなった。そこで React の state の中に、ResizeObserver で計測した位置情報を入れて更新していたら、再描画と監視がぐるぐる回り続けてしまって、結果としてブラウザのタブが固まる、という悲劇が起きたそうです。

これをどう解決したかというと、計測結果を React の state に載せるのをやめて、CSS カスタムプロパティ、いわゆるカスタム変数に直接書き込む方式に切り替えた。つまり、レイアウトの数値は CSS 側に押し出して、React の再レンダリングループから切り離したわけですね。これで無限ループ問題は解消できたと振り返っています。

さらに「仮想スクロールの盲点」として挙げているのが、仮想化って DOM ノードの数は減らせるけれど、「データそのもの」の数は減らない、という点です。六十六万セル分の値が、JavaScript のオブジェクトとしてそのまま全部メモリに乗っていると、ガベージコレクション、いわゆる GC がめちゃくちゃ重くなる。そこで、セルごとにオブジェクトを持つのをやめて、`Float64Array` といった型付き配列にデータをまとめ込むことで、オブジェクトの個数を数桁単位でガッと減らし、メモリ使用量と GC の負荷を大きく改善した、という工夫も紹介されています。

最終的なまとめとして、この方は「ヘッドレスで描画を自前実装すること」「`sticky` の基準やレイアウト計測を自分で管理すること」「保持するデータ量や構造をきちんと設計すること」など、仮想化を前提にすると、開発者が面倒を見る範囲は確かに広がる、それこそが難しさの正体なんだ、と語っています。それでも、大規模な表をヌルヌル動かせる効果は本当に大きくて、大量描画に悩んでいるプロジェクトでは、TanStack Virtual のような仮想スクロールは有力な選択肢になる、と締めくくっています。フロントエンドで表が重くて泣いてる人には刺さる内容ですね。

。。。。

続いて二つ目。
テストの見積もりの話です。「テスト見積もりって、経験とか勘でやりがちだけど、本当は『テストボリューム × 生産性』という、二つの掛け算でちゃんと数式化できるよ」という内容になっています。

まず「テストボリューム」側。機能テストの場合は「テストオブジェクト × テスト観点」、シナリオテストの場合は「業務フロー、つまりシナリオ × ステップ数」で整理して、全部で何ケースあるのか、何ステップあるのかを出していく、というやり方です。
例えば機能テストなら、「ユーザー管理」「請求処理」みたいなテストオブジェクトごとに、「正常系」「異常系」「境界値」などの観点を掛け合わせてケースを洗い出していくイメージですね。シナリオテストなら、「新規申込のフロー」「キャンセルから再申込までのフロー」みたいな業務シナリオごとに、画面遷移や入力、確認などのステップを数えていく。

次に「生産性」。これは「一時間あたりに何ケース、何ステップこなせるか」という数字で表します。ただ、この生産性は、仕様がどれだけ明確かとか、テスターのドメイン知識の深さ、エビデンスをどこまで取るか、といった要素で大きく変わってきます。そこでこの記事では、「自社の過去の実績データから、生産性の係数をちゃんと出そう」と提案しています。

この「テストボリューム」と「生産性」を組み合わせることで、テスト設計、レビュー、実行といったそれぞれの工程に対して、工数やスケジュールを定量的に算出できるようになる。これによって、「だいたい何百ケースくらいですかね〜」みたいな、ふわっとした見積もりから卒業しよう、というメッセージです。

さらに面白いのが、「ここに AI をどう効かせるか」という話。
具体的には、
一つ目が、仕様書からのテストオブジェクト抽出。仕様書を食わせて、「どんな機能のかたまりがあるか」を AI に整理してもらう。
二つ目が、オブジェクトごとの観点マッピング。さっき言った「正常系」「異常系」みたいな観点を、漏れなく付けていくところを AI に手伝わせる。
三つ目が、自社の生産性係数の算出。過去のテスト実績データから、「この条件のときは一時間あたり何ケースくらい進んでたか」を統計的に出す、という部分です。

そして、アジャイル開発のように「仕様書がちゃんとない」状況でもどうするか、という話も触れています。そこでは、ストーリーポイントあたりのテスト密度、つまり「一ストーリーポイントあたり、どれくらいテストが発生するか」という考え方を使うことで、仕様書に頼らずテスト工数を見積もれる、と提案しているんですね。
テスト計画でいつもモヤモヤする方には、かなり実務よりのヒントになる記事です。

。。。。

三つ目。
これは Claude Code を使っていて、「コメントを書きすぎちゃう問題」にどう向き合ったか、というお話です。コメント多すぎて、後から自分でも読むのがしんどい、あれですね。

この記事の筆者はまず、「コードから復元できない情報だけコメントに書く」といったルールを、`.claude/rules/` や `~/.claude/CLAUDE.md` に定義したんですが、それだけではコメント量はほとんど減らなかった、と正直に報告しています。
つまり、「ルールは作ったけど、実際の現場では守られない」という、あるあるパターンにハマってしまったわけです。

そこで次の一手として、普段使っている `/pr` スキルの中に、新しい手順を組み込みました。具体的には、「`git diff | grep` で、差分の中から追加されたコメント行だけを抽出してくる」「それを一覧にして、あらかじめ用意した表に沿って、一行ずつ『残す』『消す』を判定していく」というフローです。
この「後処理」のステップを追加した結果、プルリクエスト一件あたりのコメント行数や、四行以上続くような、長いコメントの固まりの数が、はっきりと減ったそうです。

なぜうまくいったのか、というところも考察されています。
事前にルールを覚えておく方式だと、「コメントを書こうとしている瞬間」に、そのルールを思い出せない。人間も AI も、そこまで律儀じゃないですもんね。
一方で、手順として「PR の最後に必ず実行する後処理」に組み込むと、機械的に抽出されたコメント行に対して、「この行はルール上、残すべきか、消すべきか」を淡々と判定するだけになる。つまり、人間や AI の記憶に頼らず、プロセスで制御できるようになる、というわけです。

ただし万能ではなくて、「旧実装はこうだった」とか、「この仕様はプロダクトオーナーと相談したほうがいい」といった、主観的な判断が必要なコメントは、手順にしたところでどうしても残りやすい、という弱点も指摘しています。
それでも、「ルールを書くだけ」から一歩進んで、「ツールチェーンやワークフローの中に、ルールを実行させる手順を組み込む」という発想は、他の場面にも応用できそうですよね。

。。。。

四つ目の記事。
ここからは AI エージェントをガッツリ使った事例です。
ループエンジニアリング、具体的には ralph-loop と Claude Code を組み合わせて、四十枚近い業務システムの管理画面 UI を、ほぼ丸ごと一日で作り直した、という体験談です。

もともとの画面は、React JSON Schema Form でサクッと作られていた、雑多な感じの UI だったそうなんですね。これを、ちゃんとしたデザインシステムに沿った React コンポーネント実装に移行しよう、というプロジェクト。普通に人間だけでやると、なかなかヘビーな作業です。

最初は、Main、Test、Backend の三つのエージェント構成で進めてみたんですが、指示がだんだん薄まっていったり、テストのところで詰まったりして、タスクが中途半端な状態で止まってしまう、という問題が起こりました。AI に丸投げしておけば勝手に終わる、というほど甘くはなかった、と。

そこで導入したのが ralph-loop です。
「キュー表」「手順書」「保留事項」「画面ごとの仕様テンプレ」という四つの要素を用意しておいて、キューに積まれたタスクが空になるまで、同じ手順をぐるぐる回し続ける、という構造にした。いわゆる「ループエンジニアリング」です。

このときの工夫として、完了条件をかなり厳密に設定しています。例えば「テスト用のチェックリストの全行がテスト済みになっていること」みたいな形で、「ここまでできていたら完了」と言い切れる基準をはっきりさせた。一方で、「判断が必要なところに出会ったら、自分で暫定案を選んで、blockers に記録する」「同じ場所で二回連続して失敗したら、その画面は保留に回す」といった、ちゃんとした逃げ道も用意したんですね。
これによって、エージェントが「わからないから止まる」ではなく、「わからないけど、とりあえずこうして、メモして進む」という動きをできるようになったと。

面白いのは、ループを重ねるうちに、エージェント自身がチェックリストを更新したり、「次はここを気をつけよう」と自分の失敗を反映して、作業手順を改善していく様子が見られた、という点です。まさに、AI が自分のプロセスをチューニングしながら回っていく、という感じですね。

筆者のまとめとしては、「要件がはっきりしていて、作業量だけがとにかく多いタイプの仕事」、例えば「旧画面を元に新画面を実装する」みたいな案件では、ralph-loop ＋ Claude Code による、ちょっと大きめのタスクの一括実行が非常に有効だ、と評価しています。一方で、銀行の基幹系みたいな、「一つの判断ミスが絶対に許されない」重要システムでは、AI に細かな判断を任せるのはまだ怖いので、向きにくいよね、という冷静な指摘もされていました。AI にどこまで任せるかの線引き、考えさせられますね。

。。。。

そして最後、五つ目の記事。
こちらは Moonshot AI による Kimi Kスリーの学習パイプラインについて、かなり技術寄りに解説している内容です。全体として、奇抜なことをするというよりは、堅実な技術を積み上げて、「長時間・高難度なエージェントタスク」に特化した強いモデルを作っていった、という話になっています。

まずベースとして、既存の Kツー系モデルの SFT、いわゆる教師あり微調整の成果を引き継ぎつつ、その上に、エージェントタスク向けの強化学習環境とタスク合成を、かなり徹底的に作り込んでいます。

学習の流れは、おおまかに三段階。
まず SFT、それからオンラインの強化学習、最後に MOPD、いわゆる OPD 系の手法、という三つのステージで進めます。この中で、「三つのドメイン × 三つの推論エフォート」、合計九つの教師モデルを作って、それらを統合する、という構成になっているのが特徴です。ドメインごと、かつ「どれくらい時間やステップをかけて考えるか」のレベルごとに教師を用意しているイメージですね。

さらに、SFT 段階から、MXFPフォー / MXFPエイト という量子化対応のフォーマットを通しで入れていくことで、モデルを小さな精度落ちで効率よく動かせるようにしている。そして、XTML という、エージェント向けのチャット形式を導入することで、複雑な「行動の軌跡」を表現しやすくしているのもポイントです。どんな指示が来て、どんなツールを呼び出して、どう判断して次に進んだか、といった履歴を、モデルが扱いやすい形で残せるようにしているわけですね。

強化学習の部分では、パーシャルロールアウト、つまりエピソード全体ではなく一部だけを展開することで、ロングテイルな、めちゃくちゃ長いタスクの扱いを安定させています。同時に、高オフポリシーな状況でも破綻しにくいような正則化を入れて、学習の安定性を確保している。

タスク合成もかなり凝っていて、知識グラフを起点に新しいタスクを組み立てたり、カーネル最適化、ビジュアル推論、パーソナルアシスタント、自律実行、Web 開発など、多様な「検証可能なタスク」をサンドボックス環境内に構築しています。つまり、「ちゃんと正解がチェックできるタスク」を大量に自前で作って、そこでエージェントを鍛えていく、という方針です。

そして避けて通れない「報酬ハッキング」への対策。これについては、「起きないように祈る」のではなく、「起きたら潰す」を前提とした運用で、設計段階から仕組みに組み込んでいる、というのも興味深いところでした。

記事の最後では、Moonshot が RL をどう捉えているか、という話にまで踏み込んでいます。単に「エージェントにタスクを解かせる」だけではなく、「エージェントに、訓練用の環境や新しいタスク自体を作らせて、その環境の中でさらにエージェントを訓練する」という、環境の生産能力そのものをスケールさせる方向性を狙っている、とまとめています。
つまり、「エージェントが、エージェントを鍛えるための世界を作る」という二重構造をどう大きくしていくか、という視点ですね。かなり先を見据えた取り組みだと感じました。

。。。。

というわけで、今日は五本まとめてご紹介しました。
六十六万セルの表を TanStack Virtual と型付き配列でヌルヌル動かした話。
テスト見積もりを「テストボリューム × 生産性」で数式化して、AI も活用しようという話。
Claude Code でコメントを書きすぎないように、ルールではなく「後処理の手順」に落とし込んだ話。
ralph-loop と Claude Code を使って、四十画面近い管理画面を一日で作り直したループエンジニアリングの話。
そして、Kimi Kスリーの学習パイプラインから見える、Moonshot のエージェント指向の RL 戦略の話。
気になるものがあった方は、ショーノートから元記事もぜひチェックしてみてください。

この番組「zenncast」では、皆さんからの感想や質問も大歓迎です。「こんなテーマを取り上げてほしい」「この記事も面白かったよ」なんていうメッセージも、どしどし送ってください。番組づくりの参考にさせてもらいます。

それでは、そろそろお別れの時間です。
お相手はマイクでした。また次回の「zenncast」でお会いしましょう。
今日も良い一日をお過ごしください。