どうも、マイクです。おはようございます。
時刻は朝七時を少しまわったところ、二千二十六年七月二十二日、水曜日。
ここからの時間は「zenncast」、きょうも最新のテックな話題を、ゆるっと楽しくお届けしていきます。
きょうは、Zennで話題になっているトレンド記事をピックアップしてご紹介していきますよ。
通勤・通学中のあなたも、自宅で支度中のあなたも、コーヒー片手にゆるっとお付き合いください。
きょう紹介する記事は、ぜんぶで五本です。
バックエンドの検索設計、仕様ドリフトを防ぐツール、Reactの新しいフック、フロントエンドのOpenTelemetry、それからAIを活用したコードレビューのTipsまで、わりと盛りだくさんでいきます。
ではさっそく、一つ目からいきましょう。
まず一つ目は、「検索画面のUIを決める初期の会議に、バックエンドエンジニアはもっとちゃんと顔を出したほうがいいよ」というお話です。
検索って、画面側だけ見ていると「キーワード入れて検索ボタン押すだけでしょ？」って思いがちなんですけど、実はどんな検索を許すかで、裏側の検索速度とかインデックス設計の苦しみ具合が、ガラッと変わってきます。
よくあるのが、「あいまい検索でお願いします」とか「ざっくり検索できればOKです」といった、なんとなくの合意のままUIが決まってしまうパターン。
ところがバックエンド的には、「完全一致なのか、前方一致なのか、後方一致なのか、部分一致なのか」で、性能がまったく違うんですよね。
完全一致とか前方一致は、インデックスが効きやすくてまだ軽いんですが、後方一致と部分一致は、そのままだとインデックスが効きづらくて、データ件数が増えるほどめちゃくちゃ重くなります。
なので、会議の段階で、「本当に部分一致が必要なのか？」「前方一致で事足りないか？」みたいなところを、業務上の要件とデータ量を踏まえて、ちゃんと詰めておきましょう、という提案です。
それから、ページネーションの話もおもしろくて。
よくある「一ページ、二ページ、三ページ…とページ番号でポチポチ飛べるUI」って、裏側ではデータベースのオフセットという仕組みを使うことが多いんですね。
そうすると、後ろのページに行けば行くほど、実はどんどん遅くなっていく。
一方で、「次へ」だけで進む、いわゆるカーソル型のページネーションにすると、処理はぐっと速くなるんですが、こんどはページジャンプがしづらくなるというトレードオフがあります。
さらに、「全体で何件ヒットしました」とか「全百二十三件中の一〜二十件を表示中です」といった総件数の表示も、正確な件数を数えようとすると、これまた高コストになりがちなんですよね。
そこで、「おおよそ何件以上あります」といった概算表示にして、ユーザー体験をそこまで損なわずに、システムの負荷を抑えるという選択肢もあるんじゃないか、と述べています。
そして最後に、並び替え。
画面上だと、「このカラムも並べ替えられたら便利だよね」「これもソート付けましょうか」と、ぽんぽん増やしがちなんですが、バックエンドから見ると「ソート一個増えるごとに、インデックス設計のパターンが増える」わけです。
場合によっては、性能差が桁違いになるくらい影響が出るので、「ほんとうに必要な並び替えだけに絞る」というのが、ユーザーも開発者もハッピーになるポイントだよ、と強調している記事でした。
検索画面って、プロダクトの顔の一つなので、UIだけでなく、裏側の現実も含めてチームで話し合って決めていきたいですね。
「検索の要件定義ミーティングには、バックエンドを必ず呼ぼう」っていう合言葉、覚えておくとよさそうです。
。。。。
つづいて二つ目の記事です。
テーマは「仕様駆動開発で起きがちな、仕様とドキュメントとコードとテストのズレを、どうやって機械的に検出するか？」という話。
仕様駆動で開発していると、きれいな四層構造を思い描くじゃないですか。
上から「仕様書」、それをもとにした「設計・ドキュメント」、それを反映した「コード」、さらにそれを検証する「テスト」。
ところが、開発を続けていくうちに、どこか一つだけが書き換わってしまって、そのまま放置される「ドリフト」と呼ばれる状態がよく起きます。
筆者の方は、このドリフトをちゃんと検出してくれるツールを探したんですが、
ジャバスクリプトやタイプスクリプトで動いて、AIに頼らず決定的にズレを検出できて、なおかつ仕様・ドキュメント・コード・テスト、この四つを一体として扱えるものが、どうも見当たらなかったと。
そこで自作したのが、仕様のIDを起点にしたCLIツールです。
たとえば「FRゼロゼロ一」のような仕様IDを、仕様書、コードコメント、テスト名、それからリンクなどに埋め込んでおいて、そのテキストの内容をハッシュにして記録しておく。
あとでどこか一箇所だけ変わると、そのハッシュがずれるので、「あ、ここだけ片側が書き換わってるぞ」と決定的に検出できる、というアイデアですね。
これによって、「なんとなく雰囲気で整合してそう」に見える状態ではなく、「厳密に同じものとして扱う」ことができるようになります。
名前が出てくるのが「artgraph」というツールで、これはTypeScriptの構文解析を使って、関数レベルのシンボルを拾い上げ、依存関係をグラフ構造で管理するようになっています。
このグラフを使うことで、「この仕様IDに紐づいたコードの影響範囲はどこか」とか、「どの仕様IDがまだコードやテストでカバーされていないか」「どのIDがどこからも参照されていない“孤立したID”なのか」といったものを、機械的にあぶり出せるようにしているんですね。
さらにおもしろいのが、Claude Code みたいなAIエージェントと組み合わせる話です。
AIエージェントが「ここ変えたらどう？」とコード変更を提案したタイミングで、このツールのチェックを自動で走らせる。
もし仕様とのズレが発生していたら、その結果をエージェント自身に返して、「自分でそのズレに気づいて、直させる」というワークフローを提案しています。
AIを「賢いペアプロ相手」としてだけでなく、「仕様の番人とセットで動くエージェント」にする、という発想が新鮮でした。
「仕様と実装がだんだんズレていく問題」に悩んでいるチームは、多いと思うので、こういう「決定的に検出するアプローチ」、チェックしてみる価値ありそうです。
。。。。
三つ目は、フロントエンド界隈、React十九の新機能「useActionState」の記事です。
このフックのキモは、非同期処理やサーバー通信を含むステートの更新を扱うときに、「dispatchされたアクションを自動で順番待ち、つまりキューイングしてくれる」というところ。
なにがうれしいかというと、「処理の順番がめちゃくちゃ大事な操作」を、安全に一つずつ直列で実行できるようになるんですね。
たとえば、ECサイトのカートで「カートに追加」ボタンを連打されたとき。
今までは、「二重送信防止でボタンを無効化する」とか「処理中フラグを自分で管理してごちゃごちゃする」といった工夫が必要でした。
useActionStateを使うと、「Add to cart」が押されるたびに、そのアクションが裏でキューに積まれ、内部的には一つずつ順番に処理されていきます。
ユーザーがボタンを連打しても、API呼び出しが競合せず、順番通りに処理されるので、「いつの間にか最後に押したやつだけ反映されてた」みたいな事故が起きにくいんですね。
さらに、useOptimisticと組み合わせると、体験がグッとよくなります。
ユーザーが「Add to cart」を連打したタイミングでは、画面上では楽観的更新で、すぐにカートに追加されたように見せておきます。
その裏側で、本当のAPIリクエストはキューに積まれて、順番に実行されていく。
で、「Order Now」、つまり「今すぐ注文」を押したときには、まだ完了していない「カート追加」の処理も含めて、すべてのキューが終わってから、注文処理が実行されるようにできるわけです。
これによって、「いま処理中だから、全部終わるまでボタンは押さないでね」という、ユーザーに我慢を強いるUIから卒業できます。
ボタンを無効化して待たせるのではなく、「押したいときに押してもらってOK。その代わり、裏側ではReactが順番をきれいに整理してくれる」という感じ。
筆者は、こうした「ユーザーの操作を妨げないUX」を、わりと自然なコードで実現できるのが、useActionStateの大きな魅力だと述べています。
React十九系を触りはじめている方や、「ボタン連打まわりの不具合にいつも悩まされているんだよな」という方には、かなり刺さる内容だと思います。
。。。。
四つ目は、観測・モニタリングの世界から、「OpenTelemetryをフロントエンドに本格的に持ち込もう」という動きについての記事です。
OpenTelemetryって、もともとはバックエンドのトレースやメトリクス、ログを標準的な形式で集めるための仕組みとして広まってきましたが、最近はブラウザ専用のSDKが、独立したプロジェクトとしてどんどん開発されてきています。
これによって、クリックなどのユーザー操作、Core Web Vitalsといったパフォーマンス指標、ナビゲーションやリソースのタイミング、さらにはコンソールログや未処理エラーといった、「ブラウザならでは」の情報を、イベントとして収集できるようになりつつあるんですね。
まだ「experimental」、つまり実験的な段階ではあるんですが、これを既存のFetchのスパン計測なんかと組み合わせると、Grafanaのスタック、具体的にはLokiやTempoといったツール、それからOpenTelemetry Collectorにまとめて送ることで、バックエンドとまったく同じ基盤の上で、フロントのログやトレースも見られるようになります。
「ユーザーのクリックから、ブラウザ内の処理、API呼び出し、バックエンドの処理まで、ぜんぶ一つのタイムラインで追える」という世界観ですね。
一方で、課題もちゃんとあります。
たとえば、ミニファイされたJavaScriptのスタックトレースを、ソースマップを使って元のコードに復元する処理は、OpenTelemetry標準の機能だけではまかなえません。
それから、rrwebを使ったSession Replay、つまり「ユーザーの画面を録画して、あとから再生できる」ような機能も、標準仕様には含まれていません。
なので、いま市販されているRUM、リアルユーザーモニタリング系のSaaSを、「はい、じゃあOpenTelemetryだけに全面移行しましょう」とするには、まだ設計や実装のハードルが残っていると。
記事では、「いまは全部乗せを目指す時期じゃなくて、『どのテレメトリをOpenTelemetry側に寄せていくか』を見極めながら、開発の動向を追っていくフェーズだ」と整理しています。
とはいえ、「バックエンドもフロントも、同じ観測基盤で見たいよね」という願いに、一歩ずつ近づいているのは間違いないので、フロントエンド・SREどちらの立場から見ても、注目しておきたい流れだなと感じました。
。。。。
そして五つ目、最後の記事は、ちょっと実践的なTips系。
テーマは、「自社のプルリクエストレビュー履歴をAIに読ませて、“そのチームならでは”のレビュー基準を、レビュー規約として掘り起こそう」というアイデアです。
一般的なAIコードレビューって便利なんですが、「この会社、このチーム特有の、命名のクセ」とか、「どこからをブロッカー扱いにするか」といった、暗黙の文化までは、なかなか拾いきれないんですよね。
そこで筆者が紹介しているのが、「自分たちのPRレビューの履歴を集めてAIに読ませ、そのチームの“レビューの言語”を抽出して、明文化してしまおう」という方法です。
手順としては、まずGitHubのAPIを使って、プルリクエストのレビューコメントを収集します。
その際には、ボットのコメントや「LGTMだけ」といった短いものは除外して、実際に指摘や議論が行われているコメントに絞り込みます。
つぎに、コメントの長さや、疑問形の割合、カテゴリ別の件数なんかを集計して、「うちのチームは、設計についての指摘が多いのか、命名なのか、パフォーマンスなのか」といった傾向を可視化する。
さらに、その本文をAIに読ませて、「何度も何度も繰り返し出てきている指摘パターンは何か？」を抽出し、それを件数付きのMarkdown形式の「レビュー規約」に蒸留していく、という流れです。
こうしてできあがった「自社オリジナルのレビューポリシー」を、こんどはAIエージェントに組み込んでいきます。
記事では、実際のレビューを、「規約チェック」「バグ検出」「git履歴確認」「過去PRとの突き合わせ」といった役割ごとにAIエージェントを分けて、それぞれにdiffや規約を渡し、コメント案と信頼度スコアを出させる、という構成にしていました。
最後に、「Judge役」のAIが出てきて、そのコメントたちをまとめて受け取り、重複している指摘や、明らかに誤検知っぽいものをしぼってから、最終的なPRコメントとして投稿させる、というイメージです。
CodeRabbitのような汎用ツールと比べると、自作のレビュアーは、「カバー範囲が広い」「誤検知が少ない」といった強みがある一方で、「修正コード付きの具体的な提案は少なめ」「処理はどうしても重くなりがち」という特性があるそうです。
なので、両方をうまく組み合わせて、「まずは速くて具体的な指摘を汎用ツールに出してもらう → つぎに自作の深いレビューで漏れを拾う → 最後に人間が設計やビジネスへの影響を見る」という分担が有効だとまとめています。
「AIでレビューを効率化したいけど、ちゃんとチームの文化も反映させたい」という人には、かなり実践的で参考になる内容でした。
。。。。
というわけで、きょうのzenncastでは、
検索画面のUIとバックエンド設計の関係、
仕様ドリフトを仕様IDとハッシュで検出するCLIツール、
React十九のuseActionStateによるアクションのキューイング、
フロントエンドに広がりつつあるOpenTelemetry、
そして、自社PRレビュー履歴をAIに読ませて作るレビュー規約と、AIレビュアーの役割分担、
この五本を駆け足でご紹介しました。
気になった記事があれば、番組のショーノートに詳しい情報を載せておきますので、あとでゆっくりチェックしてみてください。
この番組「zenncast」では、皆さんからの感想や質問、「こんなテーマを取り上げてほしい」といったリクエストもお待ちしています。
開発でのちょっとした悩みごとや、「最近こういうツール使ってるよ」といった話も、ラジオネームを添えて送ってもらえるとうれしいです。
それでは、そろそろお時間です。
お相手はマイクでした。きょうも良い一日をお過ごしください。
また次回のzenncastでお会いしましょう。