おはようございます！ zenncast、MCのマイクです。今日は10月13日、火曜日。朝7時になりました。みなさん、いかがお過ごしでしょうか。今日もZennでトレンドになっている記事から、開発のヒントになる話題をお届けします。
今日ご紹介する記事は5本です。AIレビューからブロックチェーン、データベース、画面づくり、そしてライブラリ更新の自動化まで、幅広く見ていきましょう！
....
まず1本目は、レビューでしか伝わらなかった開発ルールを、AIレビューでも参照できるようにした取り組みです。
実装を終えてPRを出してから、「ここはこう書くルールなんです」と指摘される。そんなやり取りが続くと、作る側にもレビューする側にも負担になりますよね。この記事の筆者は、過去のレビューで受けた指摘を整理し、40個のルールとしてまとめました。そして、それをAIレビューで参照できる形にしたんです。
導入後の結果を見ると、PRあたりのコメント数は変わりませんでした。一方で、指摘なしで承認される割合は、64.5パーセントから71.2パーセントに増えています。コメントの総数だけでは見えない変化があった、ということですね。
筆者が価値を感じているのは、開発ルールを実装前に知れるようになったことです。レビューで初めて教わるのではなく、書き始める前から確認できる。これは安心感につながりそうです。
今後は、開発中にもAIで問題を見つけやすくし、さらにPRを小さく分けることで、手戻りを減らしていく方針だそうです。AIを使って指摘するだけでなく、そもそも指摘される前にルールを共有する。この視点、チームの開発でも参考になりそうですね。
....
続いて2本目は、Mac上でBesuのネットワークを構築し、スマートコントラクトの動作や、ノード停止後の復旧を確かめる記事です。
まずDockerやNode.jsなどを用意し、besu-dev-quickstartを使って、バリデータ4台とRPC用ノード1台、合わせて5台のノードを構築します。Apple Siliconの環境ではChainlensを無効にすること、そして起動前にBesuのバージョンを確認することが注意点として挙げられています。
構築したら、Hardhatでスマートコントラクトを配置して、ERC-20トークンの発行や送金を試します。さらにcurlを使って、全5ノードで値や残高、ブロックハッシュが一致しているか確認できます。動かすだけではなく、各ノードが同じ状態を共有していることまでチェックするわけですね。
そして、この検証で特に注目したいのが、停止と復旧の挙動です。バリデータは1台停止しても処理が続きますが、2台停止すると止まります。ただし、必要な台数を戻せば、その瞬間に復旧するというわけではありません。実測では、1台を戻してから処理が再開するまで、約315秒かかったそうです。
復旧には、3台のバリデータで合意の試行回数がそろい、さらに、その回の提案担当が動いている必要があります。単に台数が足りていればよい、という話ではないんですね。
公式では、全バリデータの再起動が最速の復旧方法とされています。運用する際は、何台まで停止できるかだけでなく、止まったあとにどう戻すか、その手順まで決めておくことが大切です。障害への備えは、復旧まで含めて考えたいですね。
....
3本目は、PostgreSQLでOR条件を大量に並べたとき、クエリの実行前に大きな負荷がかかる、というお話です。
データベースはSQLを実行する前に、どう処理するかを決めるplanningを行います。この記事の検証では、ORで並べる条件が増えると、planningのメモリ使用量は条件数に比例して増え、時間は条件数の二乗に近い増え方をしていました。
実際の処理に入る前の段階で、時間もメモリも使ってしまうんですね。ログでbindが遅い場合は、このplanningを疑うのがポイントです。値をSQLとは別に渡す形にしていても、条件の数が多いままなら、負荷は減りません。
ここで、メモリの設定としてwork_memを変えればよいのでは、と思うかもしれません。ただ、work_memが対象にしているのは、実行時の並べ替えなどに使うメモリです。planningのメモリ使用量を、この設定で抑えることはできません。
記事で示されている対策は、倉庫ごとに商品IDを配列にまとめ、ANYを使って、検討する条件の数そのものを減らすことです。商品1万6千個の検証では、planningにかかる時間が56秒から4ミリ秒になりました。これは、かなり大きな変化ですね。
INでも同じように条件をまとめられますが、ANYには、件数が変わってもSQLの形を保てる利点があります。また、配列を1個の値として渡すので、渡せる変数の数の上限も避けやすくなります。
クエリが遅いときは、実行の仕方だけでなく、実行方法を考える段階にも目を向ける。覚えておきたい切り分けのポイントです。
....
続いて4本目は、AIで画面案を作りながら、デザインから外れた実装を自動で止める仕組みを整える、という記事です。
最初にAIへ複数の画面案を出してもらい、主な画面を並べて選びます。ただし、生成された画像は、そのまま仕様になるわけではありません。余白や文字サイズを測り、デザインファイルに写してから実装へ進めます。見た目の案と、実装に必要な情報を、きちんと分けて扱うんですね。
管理する場所も整理されています。見た目はデザインファイル、色や文字サイズの値はコード、部品の動きはStorybookで管理します。値を書き写した文書は持たず、デザインとコードの食い違いは同期テストで見つける方針です。
さらに、デザインから外れた実装を、自動で止める仕組みを入れます。lintで未定義の色を検出したり、共通部品を使わない実装を見つけたりして、文字の読みやすさも検査します。画面の画像も比較しますが、その差が意図した変更なのかどうかは、人が確認します。
AIによる画面評価も、人が判断するための材料にとどめます。そして、繰り返し出てくる指摘は、注意書きを残すだけで終わらせず、lintやテストに追加していくそうです。
もちろん、この仕組みで品質が完全に保証されるわけではなく、効果の計測もこれからとのこと。AIに画面を作ってもらうだけでなく、守ってほしいルールを検査できる形にする。そこまで含めて考えているのが、印象的な取り組みですね。
....
最後、5本目は、Renovateが作るライブラリ更新のPRを、GitHub Actions上のClaude Codeに確認させる仕組みです。
AIがリリースノートとコードを比べて影響を確認し、その判定から自動マージまでつなげます。ただし、どんな更新でも自動で取り込むわけではありません。
minor更新は、AIが承認し、テストや型チェックなども通過したことを条件に、自動マージします。一方で、major更新や、互換性を壊す変更が入りやすい更新は、人がマージする運用です。更新の種類に応じて、任せる範囲を分けているんですね。
権限の設計にも注意が払われています。AIが確認する処理と、その結果を反映する処理は分けて、AIには読み取り権限だけを渡します。ファイルの変更やコマンド実行は禁止し、リリースノートなどの資料に悪意ある指示が紛れている場合への対策を取っています。
また、独自の修正を当てたライブラリなどは、人の確認に回します。変更内容が同じなら前回の判定を再利用して、無駄なレビューを減らす工夫もあります。
そして、自動マージは既定で無効です。まずは判定の根拠を人が確認し、信頼できると判断してから有効にする運用が勧められています。便利だからすぐ全面的に任せるのではなく、判断の中身を確かめながら進める。この慎重さも、大事なポイントですね。
....
さて、今日は5本の記事をご紹介しました。
開発ルールを40個に整理してAIレビューで共有する取り組み、Besuのノード停止と復旧の検証、PostgreSQLの大量のOR条件によるplanning負荷、AIを使った画面づくりと自動検査、そしてRenovateとClaude Codeによるライブラリ更新の確認と自動マージでした。
詳しい内容はショーノートに書いてありますので、気になった話題をぜひチェックしてみてくださいね。
zenncastでは、みなさんから番組の感想を募集しています。「この話が参考になった」「こんなテーマも聞いてみたい」など、気軽にお寄せください。この番組はSpotifyやApple Podcast、YouTubeなどで毎日配信しています。気に入ったら、登録や高評価をつけてもらえるとうれしいです！
それでは、次回もみなさんにお会いできるのを楽しみにしています。お相手はマイクでした。今日も、よい一日をお過ごしください！