どうも、マイクです。おはようございます。
六月二十六日、金曜日の朝七時を回りました。ここからの時間は「zenncast」、きょうも最新のZennトレンド記事を、ゆるっと楽しく紹介していきます。通勤・通学中のあなたも、おうちで支度中のあなたも、よかったら最後までお付き合いください。

きょうは、全部で五本の記事をご紹介していきます。どれも「AI時代の開発や分析」「開発環境」「言語処理系の最適化」と、なかなか濃いラインナップになっていますよ。

それでは、きょう紹介する内容、一本ずついきましょう。まず一つ目。
一つ目は、「AIがコードを書く時代のコードレビューは、誰を責めるかじゃなくて、どんな仕組みで守るかを考えよう」というお話です。

今って、Claude Codeみたいなツールを使って、AIがガンガンコードを書くじゃないですか。そうすると「この悪いコード、誰が書いたんだよ」って犯人探しをしても、あんまり意味がないよね、という指摘なんですね。
この記事では、悪いコードが紛れ込んだときに、「人のスキルが足りなかったからだ」と責めるのは、本当に最後の最後にすべきで、それよりも「なぜ、この悪いコードを通してしまう仕組みになっていたのか」をちゃんと見直そうと提案しています。

具体的には、AIがコードを出力してからレビューに上がってくるまでの流れ全体を分解して、「どこにチェックが足りなかったのか」を特定していきます。たとえば、テストを書いておくことで防げたんじゃないかとか、Lintで検出できたはずじゃないかとか、専用の検出スクリプトで弾けたかもしれない、といった具合ですね。
そういう「仕組み」を一個ずつ増やしていくことで、悪いコードがそもそもレビューに出てこないようにしていこう、という考え方です。

もう一つ面白いのが、各開発者が「臭うコード検出器」をどんどん追加していける基盤を用意しよう、という話。なんか怪しいパターンを見つけたら、その場でルールやスクリプトを足していけるようにしておく。で、「これはもう絶対にアウト」と機械的に判定できるところは自動チェックに任せて、手順の優先度を考えたり、「この設計でいいの？」みたいな推論が必要なところは、エージェントっぽいAIに考えさせる。
そうやって、自動チェックとエージェントをうまく組み合わせて、開発プロセス自体を設計していくべきだ、と説明しています。

ポイントは、モデルの性能差、「このLLMのほうがちょっと賢い」とかに期待するよりも、「良いコードをどう評価して、どう守るか」という仕組みを会社の資産として貯めていくほうが、長期的には強みになるという視点です。
そのうえで、これまでのコードレビューって「人へのフィードバック」を中心にした場だったけれど、これからは「仕組みを育てるためのフィードバックの場」として位置付け直されていくだろう、とまとめています。人を責めるより、システムを育てる。これ、チーム開発してる方にはかなり刺さる内容じゃないでしょうか。

。。。。

続いて二つ目。
二つ目の記事は、AIを使った分析基盤づくりについてのオピニオンです。「AIがSQLを書けるだけでは、正しい意思決定には足りないよ」というところから話が始まります。

著者の方は、BigQueryとdbtを中心にしつつ、「ツール」「ガードレール」「コンテキスト」「改善ループ」を一体で育てる分析基盤を紹介しています。
まずツールの部分では、自然言語で質問したらSQLを生成して実行してくれるような、MCPツールを使います。でも、それをそのまま野放しにすると、危険なクエリも平気で走っちゃう。
そこで、SQLの構造を検証したり、実行コストを見積もったりして、「これは危ないクエリだから通さない」というガードレールを用意しているんですね。たとえば、巨大テーブルに対してフィルタ無しのフルスキャンをしようとしていたら弾く、みたいなイメージです。

さらに、dbtで定義したメトリクスとか、プロダクトの機能・イベントのカタログをAIに渡して、「どういう意味のテーブルなのか」「どれが公式な指標なのか」といった文脈もセットで提供します。これによって、「売上」を聞かれたときに、ちゃんと正しい定義の売上メトリクスを使えるようになる、と。

おもしろいのが、そこで終わらずに「改善ループ」をちゃんと設計しているところです。
ユーザーが投げた元の問い、つまりインテントと、実際に実行されたSQL、それが参照しているテーブルをログとして紐づけて、どんどん蓄積していく。そして、そのログを見ながら、

・生の生データを直接叩いているクエリが多いなら、「このデータはdbtでモデル化しよう」
・同じ質問なのに、毎回SQLがバラバラに書かれているなら、「これはテンプレート化しよう」

といった改善アクションにつなげていきます。これを小さなサイクルでぐるぐる回す、というわけですね。

結論としては、AIによる分析は、「クエリを書く時間を短縮できました、やったー」で終わりではなくて、「正しい指標を維持し続ける仕組み」とセットで設計するのが重要だ、と説いています。AIに任せれば任せるほど、逆にメトリクス定義やガードレールといった“人間側の設計”の重要性が増していくんだな、というのがよく伝わる記事でした。

。。。。

三つ目いきましょう。
三つ目は「difit」というCLIツールの紹介です。これは、ローカルのGit差分を、GitHubの「ファイルズ・チェンジド」とほぼ同じ見た目でブラウザ表示してレビューできる、というものです。`えぬぴーえっくす・ディフィット`と打つだけで、さっと立ち上げられるお手軽ツールですね。

このdifit、何が便利かというと、コミット間やブランチ間の差分はもちろん、今作業中のディレクトリの変更、ステージングした変更だけ、さらにはGitHub上のプルリクエストの差分まで、引数の指定を変えるだけで、いろんなパターンの差分を比較できます。
見た目がGitHubのPRの画面にかなり近いので、「あの見慣れたUIで、ローカルの差分も見られる」感覚ですね。

さらに、行ごとのコメント機能も付いています。ここがポイントで、コメントはブラウザ側に保存されるので、まだPRを作っていない段階でも、自分の変更をローカルでじっくりセルフレビューできる。
そして、そのコメントには「コピー・プロンプト」ボタンが付いていて、コメントの内容と、ファイル名、行番号をまとめて一括コピーできます。つまり、「この行、変数名よくないからリファクタしたい」みたいなコメントを付けて、それを丸ごとAIのコーディングエージェントに投げて、「この指摘をもとに修正して」とお願いできるわけです。これはかなり実務的ですね。

さらにさらに、AI側からdifitを呼び出す連携機能も用意されていて、エージェントが「じゃあ、このコミットの差分をdifitで見せて」といった使い方もできるようになっています。
コミット前の最終確認や、AIと一緒にレビューを回すワークフローとの相性が良いツールで、「一人開発なんだけど、ちゃんとレビューしたい」という人にも刺さりそうな内容でした。

。。。。

続いて四つ目の記事です。
これは、リモート開発環境のお話。VSCodeのRemoteーエスエスエイチ、使っている方も多いと思いますが、あれが「遅いし不安定だし、大学の共有サーバーにはかなり負担が大きいよ」という指摘からスタートします。

Remoteーエスエスエイチは、接続のたびにサーバー側にノードジェイエスのサーバーを展開して、そのバージョンがどんどん溜まっていってしまう。結果として、共有サーバーのストレージや計算資源を圧迫してしまう、という問題があるんですね。自分だけならまだしも、研究室のみんなで同じサーバーを使っているような環境だと、これはかなり気を使うポイントです。

そこで筆者が選んだのが、Rust製でGPU描画の軽量エディタ、「Zed」です。
Zedは、とにかく起動が速くて、SSHでの接続も非常に軽い。そのうえ、サーバー側に置くのは小さな「ゼッド・リモート・サーバー」というバイナリをひとつ置くだけでいいので、VSCodeみたいに大量のファイルを展開しなくて済みます。これが、「サーバーに優しい」理由の一つですね。

設定もシンプルで、「セッティングス・ジェイソン」と「キーマップ・ジェイソン」二つのファイルで完結します。Vimモードも安定していて、Vim派の人も安心して使える。
SSHの設定に関しても、普段使っている「チルダ・スラッシュ・ドット・エスエスエイチ・スラッシュ・コンフィグ」をそのまま読んでくれるので、新しく設定し直す必要はありません。コマンドパレットから「プロジェクツ・オープン・リモート」と選んで、接続先とフォルダを指定するだけで、すぐにリモート開発が始められます。

欠点としては、VSCodeに比べると、まだ拡張機能が少ないところ。ただ、それ以外の大きなマイナスは見当たらない、と筆者は言っています。
全体として、「軽くて速くて、しかもサーバーに優しいリモート開発環境」への、現実的な乗り換え先としてZedを推している内容でした。大学や会社の共有サーバーを使っていて、VSCode Remoteでちょっと肩身が狭いな……という方には、かなり参考になりそうです。

。。。。

そして最後、五つ目の記事です。
こちらは、JavaScriptエンジンのVエイトの中の話。「アレイ・プロトタイプ・フラット」を、どうやってもっと速くしたか、という実装寄りの解説になります。

テーマになっているのは、「数値だけからなるサブ配列を、メムコピーによるバルクコピーで一気に移動できるようにした」という最適化です。
まず前提として、Vエイトでは前の段階で「ツーパス方式」という仕組みが導入されています。これは、フラットを実行するときに、まず一周目で結果の配列の長さと型を決めてしまって、一度だけ必要なサイズを確保する、という方法です。このおかげで、今回はさらに踏み込んだ高速化ができるようになった、という流れですね。

対象になるのは、「パックド・エスエムアイ・エレメンツ」と「パックド・ダブル・エレメンツ」と呼ばれる配列です。ざっくり言うと、整数だけ、あるいは数値だけで構成されていて、穴もサブ配列も含まない、きれいに詰まった配列。
こういう配列に対しては、本来なら要素ごとにチェックしながらコピーしていたところを、「どうせ全部数値で、ポインタも含まれていないんだから、一塊のメモリブロックとしてドンとコピーしてしまおう」という発想で、メムコピーを使ったバルクコピーを導入しています。

ここで重要なのが、ガーベジコレクションとの兼ね合いです。オブジェクトやポインタを動かすときは、「ライトバリア」と呼ばれる仕組みでGCに「参照が変わったよ」と知らせる必要がありますが、今回対象にしているのは「ポインタを含まない数値配列」だけ。
なので、ライトバリアが不要な領域だけを選んでバルクコピーすることで、安全性を保ちながら高速化しているわけです。

さらに、事前に全体の長さが分かっているおかげで、「フィックスド・ダブル・アレイ」をホール（穴）で埋める初期化処理も省略できるようになりました。構造が正しいか確認する「リチェック」も、これまでは要素ごとに行っていたところを、配列ごと一回だけで済ませられるようになっています。

その結果どうなったかというと、もともとの実装と比べて、ツーパス方式とバルクコピーを組み合わせることで、「数値だけのパックド配列に対するフラット」は最大で二十倍以上速くなった、という計測結果が出ています。
数値以外の型が混じっているケースでも、およそ一・五倍程度の改善が得られたということで、かなりインパクトのある最適化ですね。普段なんとなく使っているArrayフラットの裏側で、こんな細かいチューニングが行われているんだな、というのが伝わる記事でした。

。。。。

というわけで、きょうのzenncastは、五本立てでお送りしてきました。
ざっとおさらいすると、

まず一つ目は、「AIがコードを書く時代のコードレビューは、人を責める場ではなく、テストやLint、検出スクリプトといった“仕組み”を育てる場にしていこう」という話。
二つ目は、「AIがSQLを書けるだけではダメで、BigQueryとdbtを軸に、ガードレールやコンテキスト、改善ループを一体で設計した分析基盤が大事」という話。
三つ目は、`えぬぴーえっくす・ディフィット`一発で、ローカルのGit差分をGitHub風UIでレビューできて、AIエージェントとも連携できるCLIツール「difit」の紹介。
四つ目は、VSCode Remoteーエスエスエイチの重さとサーバー負荷の問題を避けるため、「軽くて速くて、サーバーに優しい」Rust製エディタZedに乗り換えた体験談。
そして最後五つ目は、VエイトのArrayフラットを、ツーパス方式とメムコピーによるバルクコピーで最適化して、数値だけの配列では最大二十倍以上速くした、というエンジン内部のお話でした。

気になった記事があれば、詳しい内容はショーノートにまとめてありますので、あとでゆっくりチェックしてみてください。

この番組「zenncast」では、感想や「こんなテーマを取り上げてほしい」といったリクエストも大歓迎です。普段どんなふうにZennを活用しているか、開発や勉強のお供にどう聴いているか、なんでも気軽に送ってください。

それでは、そろそろお時間です。
きょうも一日、無理せず、いいコードといいインサイトに出会えますように。
お相手はマイクでした。また次回のzenncastでお会いしましょう。