どうもー、おはようございます。マイクです。
時刻は朝7時、2025年12月1日、月曜日。今日も「zenncast」スタートしていきましょう。

この番組では、Zennで話題になっているトレンド記事をピックアップして、通勤・通学のおともにちょうどいい感じでゆるっと紹介していきます。技術ネタ中心ですが、できるだけ噛み砕いてお届けするので、コーヒー片手にラジオ感覚で聞いてみてください。

さて今日は、全部で5本の記事を紹介していきます。
SQLのテストから、ドメインモデリング、AIを使った画面テスト、自戒を込めたSELECT * の話、そしてHonoだけで作るミニマルSPAまで、かなりバラエティ豊かです。それぞれ濃い目なので、気になったやつがあったらあとでショーノートから原文もぜひチェックしてみてください。

ではまず1本目。
タイトルは「超高速SQL単体テスト rawsql-ts/pg-testkit」。
これはNode.jsからPostgreSQLを使ってる人に刺さりそうな記事です。普通、SQLのテストって「本物のDBを立てて、マイグレーション流して、テストデータ入れて、終わったら掃除して……」って、準備と後始末がとにかくだるいんですよね。この記事のライブラリは、その辺をまるっとすっ飛ばす「ZeroTableDependency」、略してZTDという発想が面白くて、本物のPostgreSQLは使うんだけど、実テーブルは一切読まない・書かないというスタイルをとります。どうやるかというと、物理テーブルと同じ名前のCTEを定義してSQLの実行を“かぶせる”「CTE Shadowing」と、INSERT/UPDATE/DELETEみたいなCUD系のクエリを「結果を返すSELECT」に変換してしまう「Result Select Query」というテクニックで、DBを汚さずにロジックだけ検証できるようにしているんですね。pg.Client.queryをフックする疑似クライアントをかませるので、既存コードへの手入れも最小限。fixturesやDDLファイルから影テーブルを用意してあげれば、超高速でSQLロジックやリポジトリ層が回せる、と。ストアドプロシージャやトリガー、パフォーマンステストには向かないけれど、「とにかくSQLの条件とJOINが合ってるかだけ素早く確かめたい」みたいなニーズにはどハマりしそうです。筆者は、ZTDみたいなアプローチが進むと「ORMって、AIにとってはむしろ余計な抽象化になるかも」という話もしていて、SQLファーストな開発スタイルの未来をチラ見せしてくれています。

。。。。

続いて2本目。
タイトルは「永続化と切り離した＂純粋＂ドメインモデリング入門 - ステート、イベント、Deciderで始めるイミュータブルモデルの実装」。
これはDDDとかイベントソーシングが好きな人はニヤニヤしながら読める内容だと思います。よくあるパターンとして、ドメインモデルがDBのテーブル構造とかORMの制約に引きずられて、「変更に弱い」「テストしづらい」「ロジックがあちこち散らばる」という問題が出がちですよね。この記事では、それを思い切って切り離して、「Always Valid Domain Model」、つまり永続化のことなんか一切知らない、常に正しい状態だけを扱う純粋なモデルを目指そう、という話が展開されます。キーワードはState、Event、そしてDecider。Deciderの中では「validate（どのイベントが起こりうるかの判断）」と「evolve（起きたイベントを反映してStateを進化させる）」を、はっきり分けるのがポイントです。これによって、副作用を排除したイミュータブルな関数の世界でドメインロジックを完結できるので、テストもしやすいし、あとから「なぜこの状態になったのか」をイベントの履歴で追いやすくなります。記事ではC#とSekiban DCBを使った銀行口座ドメインの例が出てきて、イベントを洗い出すところから、ステート定義、イベントごとのValidate/Evolve、計算ロジックの純粋関数化、最後にProjectorやコマンドハンドラーで外界とつなぐ、という一連の流れが丁寧に説明されています。イベントソーシングがなくてもこの発想は使えるけれど、イベントソーシングを採用すると、そのままイベントを保存してリプレイできるので、より自然にフィットするよ、というまとめになっていました。

。。。。

3本目の記事。
タイトルは「Android/PCに映る全てのモノをAI自動テストするツールを開発した話」。
これは聞いただけでワクワクするやつですね。いわゆるE2Eテストなんですが、「DOM取れる前提」みたいな世界を飛び出して、ゲーム画面とか、UI要素を簡単には取れないものも含めて、「画面に映っているものを人間と同じように見て、操作してテストする」っていうアプローチです。やっていることはかなり本格的で、まずテストケースとしては「手順」と「期待結果」だけを与える。するとPlan AIがその情報をもとに「次にどこをどう操作するか」という行動計画を立てます。Vision AIが画面キャプチャを画像認識して、ボタンやテキストの位置を見つけ出し、ADBやwin32apiを使ってtapやクリックなどの操作を実際に行う。そしてAssertion AIが、各ステップごとにPass／Warn／Failを判定し、統合AIがそれを見て次のアクションを調整していく、という多層構造になっています。パフォーマンス面では、画像を横方向に分割して並列に処理したり、内部グリッドIDを使って座標の精度を上げたりと、かなり実践的な工夫が紹介されていました。一方で、AI推論のコストが上がるとか、認識に時間がかかるなどの課題もあって、実運用に向けたチューニングはまだこれからという印象です。面白かったのは、画面情報や仕様を「AIが誤解しないようにJSONで構造化して渡す」というノウハウの部分で、もはや「AIにとって読みやすい仕様書の書き方」が大事なスキルになりつつあるんだな、と感じさせられる内容でした。今後は実際のテスト業務での検証を経て、OSS化も検討しているそうです。

。。。。

4本目。
タイトルは「SELECT * がデータモデルの保守性を下げる話」。
SQLを書いているみなさん、耳が痛い人も多いかもしれません。「SELECT * 禁止」はよく聞くけど、実際そこまで問題か？と思っていた筆者が、dbtのIncrementalモデル運用でガッツリ痛い目を見た、というエピソードから話が始まります。具体的には、staging層のテーブルに想定外の型を持つ新カラムが追加されたとき、itm層でSELECT * を使っていたせいで、その新カラムが何のチェックもなく素通りしてしまった。その結果、誤ったデータが増分として蓄積されていき、最終的にはテーブル全体のfull-refreshが必要になって、大きなコストになってしまった、というお話です。この経験を踏まえて、SELECT * の問題点として「上流の全カラムへの暗黙的な依存」「テーブル間のインターフェースとしての契約が不明瞭」「必要ないカラムまで読んでしまうことでパフォーマンスやコストが悪化」という3つが整理されています。一方で、何でもかんでもダメというわけではなくて、Ad-hoc分析やPoCのような、使い捨て前提・探索フェーズではSELECT * もアリだよね、というバランス感覚も忘れていません。ただし、本番運用されるモデリング層、特にdbtのような環境では、「SELECT * 禁止・カラム明示」をコーディング規約に入れておくことがものすごく大事だ、と。数秒かけて列名を書き出す手間よりも、長期運用での安心感の方が圧倒的に価値が高い、という結論で、データ基盤に関わる人には刺さる内容になっています。

。。。。

そして最後、5本目。
タイトルは「Hono "だけ" で作るミニマルな SPA」。
普段はNext.jsをメインで使っている筆者が、「小さいアプリにNextはちょっと重いな……」というモヤモヤから、Honoだけでフロントもバックも完結させるミニマル構成に挑戦した記事です。Honoは軽量で、Web標準に寄せた作りが特徴のフレームワークですが、そのHonoに用意されているクライアントコンポーネント機能を使うことで、ReactなしでもJSX＋Stateを扱えるSPAが作れちゃうよ、というのがポイントになっています。実際の記事では、Geminiのモデル名を入力してレスポンスを確認できる、シンプルな検証用アプリを題材にしていて、ディレクトリ構成も最小限、依存も「hono」「@hono/node-server」「@google/genai」くらいに絞った、とてもスリムなセットアップが紹介されています。Next.jsだとどうしても依存やファイルがどんどん増えていって、「学習コストの高いフレームワークに寄りかかったまま」になりがちですが、Honoだけで組むことで、サーバーとクライアント間のデータ受け渡しを自分の手で設計する経験値が積めるのが良かった、という振り返りも印象的でした。今後は、高機能をあまり求めない小規模なアプリではこのHonoパターンを積極的に使っていきたいし、HonoXが成熟してきたら、Next.jsの代替になりうるんじゃないか、という期待感も語られています。フロントエンド界隈で「とにかく軽く、シンプルに行きたい」人には、かなりそそられる内容ですね。

。。。。

というわけで、今日は5本の記事を駆け足でお届けしてきました。
おさらいすると、

本物のPostgreSQLを汚さずにSQLロジックを高速テストする「rawsql-ts/pg-testkit」の話。
永続化から切り離した、State・Event・Deciderによる純粋なドメインモデリングのお話。
Android/PCの画面に映るもの全部をAIで操作してE2Eテストしちゃう、野心的なツール開発記。
SELECT * が長期運用の保守性を下げる、という実体験ベースの反省とベストプラクティス。
そして、Hono“だけ”でミニマルSPAを作ってみた、という軽量フルスタック構成の実践記。

気になった記事があったら、詳しい内容はショーノートにリンクを載せておくので、ぜひ原文も読んでみてください。

この「zenncast」では、番組の感想や、「こんなテーマを取り上げてほしい」「この技術が熱いから掘ってほしい」といったリクエストも大歓迎です。あなたの現場でのモヤモヤや気づきなんかも、どしどし送ってください。

それでは、そろそろお別れの時間です。
今日も一日、ゆるく楽しく、いいコードといいアウトプットが書けますように。
お相手はマイクでした。また次回の「zenncast」でお会いしましょう。ではでは。