どうも、マイクです。おはようございます。
九月じゅうににち、どようびの朝七時になりました。
ここからの時間は「zenncast」、きょうも元気にお届けしていきます。
この番組では、いまZennで話題になっているトレンド記事を、ラジオ感覚でゆるっと、でも中身はしっかりめに紹介していきます。通勤や通学の支度をしながら、「そんなネタ出てるんだ〜」くらいのテンションで聴いてもらえたらうれしいです。
さて、きょう紹介する記事は、全部でごほんです。
テスト時間の短縮テクから、NuxtからNextへのAI前提リプレイス、VRChat向けのガチなCシャープコンパイラ、GPTシックスアストラの新機能検証、そして最後はdbtとSnowflakeのタグ整理まで、なかなか幅広いラインナップになってます。
それじゃあさっそく、一つ目の記事からいきましょう。
まず一つ目は、テスト時間をどうやって削るか、その具体的な工夫をまとめた記事です。
ポイントは、「やみくもに速くしようとしないで、まず計測してボトルネックを見つけて、そこに集中して手を入れる」という考え方ですね。で、ここがおもしろいところなんですが、このボトルネック探しや改善の試行錯誤を、かなりの部分、AIに任せて自動でやらせているんです。
具体的には、まずCIで毎回出していたカバレッジレポート。これが実は誰もちゃんと見ていなくて、それなのに生成におよそ七分もかかっていたと。そこで、「本当に要るのか？」をチームで確認したうえで、思い切って無効化してしまったんですね。これだけでテスト時間がガッと短くなりました。
さらに、Prismaのクライアントをenumを取りたいだけなのに、巨大なクライアント全体を読み込んでしまっていて、初期化がとても重くなっていた問題。ここでは、enum専用に再エクスポートするモジュールを用意して、重い初期化処理を切り離しました。結果として、importにかかる時間をかなり削れた、という話です。
テストランナー側では、Vitestの実行モードをデフォルトのフォークスからスレッズに変えています。フォークスだと、そのたびにプロセス起動やプロセス間通信のコストがかかるんですが、スレッズにすることでそこを減らして、実時間もCPU時間も両方改善した、と。もちろん、モードを変えたあとに全テストがちゃんと通るかどうかは確認して、そのうえで採用しています。
あと大事なのが、統合テストと単体テストで、まったく同じ振る舞いを二重に検証しているケースがたくさん見つかったことです。「どのレイヤーで何を保証するか」という方針を見直しながら、「これは統合テストだけでいいよね」「これは単体テストで十分だよね」という形で、重複しているテストを順番に削っていっているそうです。
全体として、計測 → ボトルネック特定 → 集中改善、という王道の流れを、AIの力も借りて自動化しながら回している、というのが特徴的な内容でした。
。。.。。.。。.
続いて二つ目の記事です。
こちらは、Nuxt.jsからNext.jsへの技術リプレイスを題材にして、「AIコーディングを前提にした開発プロセス」と、その副作用としての「理解負債」について語っている記事です。AIコーディングにはClaude Codeを使っています。
著者たちはまず、「AIにも分かるように開発フローを定義する」という発想で環境を整えています。たとえば、ルールやプロジェクト概要をまとめたファイルを用意しておく。仕様や調査のドキュメントをしっかり残しておく。ESLintやPrettierの設定もきっちり決めておく。さらに、画面仕様書から実装、その実装と既存仕様、現行実装、UIの差分比較までを、一連の「ひとつのスキルセット」として定義しておくんですね。
こうすることで、開発フローそのものをAIがなぞれるようになっていて、NuxtからNextへの移植を、高速かつ精度高く進められるようにしているわけです。
このやり方によって、リグレッション、つまり思わぬ挙動の後退を防ぎやすくなったり、スケジュールを守りやすくなったり、特定の人にしかわからない、という属人化を抑えられたり、いろいろなメリットがあります。
一方で、著者が問題視しているのが「理解負債」です。
技術負債をそのまま丸ごと新システムに移植してしまったり、開発者が仕様やコードを深く理解していなくても、とりあえずAIに指示すれば開発が進んでしまう。短期的にはすごく便利なんですが、「あとからチームとしての理解が追いつかない」という負債が積み上がっていくよね、という指摘ですね。
じゃあどうするのか、というところで、いくつか対策も紹介されています。たとえば、現行システムを実際に触る時間を、スケジュールの中に意図的に確保する。モックデータを使ってAPIレスポンスのパターンを洗い出して、振る舞いをちゃんと把握する。複雑な実装は、mermaidやHTMLで図解して、見える形で理解を共有する。
さらに、移行元のファイルへのリンクコメントを必ず残して、「これどこから来たコードだっけ？」をすぐ追えるようにする。関連リポジトリを一か所に集約しておいて、AIに横断的な調査をやらせやすくする、という工夫も挙げています。
まとめとしては、「AIの力をフルに使ってスピードと品質を上げつつ、人間側の理解を地道に積み上げる仕組みも同時に回していくことが大事だよ」というメッセージになっています。リプレイス案件を抱えている人には、かなり刺さる内容じゃないでしょうか。
。。.。。.。。.
三つ目の記事にいきましょう。
これはVRChatのワールド開発向けのお話で、Cシャープ好きにはたまらないやつです。
VRChatでは、本来のCシャープではなく、「Cシャープ風言語」のUdonSharpを使う必要があって、ジェネリクスやasync・awaitが使えないなど、制約が多いことが大きな不満になっています。
この記事の筆者は、その不満を解消するために、なんとRustで「ほぼフル機能のCシャープをUdon向けにコンパイルできるMenSharp」というコンパイラを自作しています。自分の欲しい言語環境を自分で作る、というやつですね。
MenSharpは、UdonVMの制約でunsafeやファイル入出力など、一部は使えないものの、ジェネリクス、async・await、try・catch、LINQといった機能をサポートしています。これによって、UnityとCシャープを組み合わせて開発するときに近い感覚で、VRChat用のコードを書けるようになっているんですね。
パフォーマンス面でもかなりこだわっていて、アリーナアロケータを使ったメモリ管理や、エス・ストラーといった文字列の扱いを工夫することで、メモリ割り当てを減らしています。さらに、関数ごとの独立性を高めたり、エンティティ・コンポーネント・システム風の状態管理を取り入れたり、rayonによる並列化も行っていて、マイクロソフトのRoslynと比べて、最大およそじゅういち倍というコンパイル速度を出せている、という話です。
現時点では、「概ね実用的だけど、レアケースにはまだ穴がある」という段階とのことですが、対象としているCシャープの範囲も整理されています。.dllの中にある許可済み関数、標準ライブラリの実装、そしてユーザーコード、この三種類に収まるCシャープを扱う形ですね。
筆者としては、今後さらに実行速度の最適化を進めたり、LLVMバックエンドの検討も視野に入れつつ、ユーザーからのフィードバックをもらいながら、実用度を高めていきたいと述べています。VRChatのワールド開発をガチでやっている人には、かなりワクワクするプロジェクトだと思います。
。。.。。.。。.
では四つ目の記事です。
こちらは、GPTシックス・アストラの新機能である、asyncツールコーリングとmid-turn steering、この二つの挙動をかなり丁寧に検証した、いわゆるTips系の記事になっています。
まずasyncツールコーリングですが、これは「ツールの実行を待っているあいだも、モデルが文章生成を続けられる仕組み」です。ツールに依存しない部分の答えは先に返しておいて、ツールが重くて時間がかかっても、とりあえずユーザーに何かしらレスポンスが届くようにする、という考え方ですね。
ただし重要なのが、「ツールの結果を、今まさに出力中のレスポンスの途中に差し込むことはできない」という点です。ツールの結果を反映するのは、これまでどおり、次のリクエストになります。previous_response_idを指定して、「さっきの続きね」とお願いするかたちですね。
asyncを使うと、ツールが遅い場合でも、「ツールに依存しない部分」の返答が数秒で返ってきやすくなります。特にツールの遅延がじゅっ秒からろくじゅう秒以上みたいに大きいときには、ユーザーの「体感の待ち時間」をかなり減らせる。一方で、ツールが数秒で終わる程度なら、トータルの時間とかトークン費用は、同期モードのほうが有利になるケースもあって、「いつでもasyncが速い」わけではない、というのをちゃんとデータで示しています。
次にmid-turn steeringです。これはWebSocket専用の機能で、「モデルがレスポンスを生成している最中に、追加のユーザー指示を送り込める」というものです。ただしここにも制約があって、現在生成中の『出力アイテム』が終わるまで、その指示は反映されません。
つまり、すごく長い一メッセージを生成中にステアしても、その長文をいったん出し切ってから、次のレスポンスで書き直す、という形になるわけですね。
steerで送れるのはユーザーメッセージだけで、function_call_outputみたいなツールの結果は送れません。ツールの結果は、必ずレスポンスがいったん終わったあとに、あらためて別リクエストで渡す必要があります。
このasyncツールとsteeringを組み合わせると、だいたい「三段構成」になります。
まず、ツールに依存しない説明を一本書き切る。
その直後に、ステアの指示を反映した続きのレスポンスを返す。
そしてさらに、ツール結果を受け取ってから最終回答を出す。
こういう流れで、steerは出力アイテムの境目、ある程度安全な区切りで効いていると考えられる、という整理ですね。
実装方針としては、おおきく二つです。
ひとつめが、「ツールが重くて、ツールに依存しない部分が多いときにasyncを検討する」。なんでもかんでもasyncではなくて、ケースバイケースで選ぶ。
ふたつめが、「steeringを活かしたいなら、一つのメッセージを極端に長くしない」。短めの出力アイテムで区切って返すことで、「あ、指示変わったね」と方向転換しやすくする、という設計にしておくのがよい、というまとめになっています。
アプリ側でGPTシックス・アストラを使っていきたい人には、実装上のヒントが詰まった記事でした。
。。.。。.。。.
ラスト、五つ目の記事です。
これは、dbtとSnowflakeで登場する三種類のタグ、「dbtタグ」「Snowflake Query Tag」「Snowflake Object Tag」の違いと、どう使い分けるかを整理した内容になっています。
まずdbtタグ。これはdbtのモデルなどにつけるラベルで、たとえば実行頻度とか、レイヤーとかを表現するために使います。大事なのは、ノードセレクションで「この条件に当てはまるモデルだけ実行する」といった形で、実行対象を柔軟に絞り込める点です。
一方で、なんでもかんでもタグを付け始めると、表記ゆれが起きたり、付け漏れが出てきたりして、かえってカオスになる危険もあります。この記事では、タグの一覧をseedで管理しておいて、検査ツールを使って「運用ルールをちゃんと守れているか」をチェックする工夫が紹介されています。
次にSnowflake Query Tagです。これはセッションにひもづく文字列で、クエリ履歴にJSON形式のメタデータを埋め込むことができます。たとえば、「どのプロジェクトの、どのモデルが、どれくらいの頻度で実行されているか」といったことを、あとから監視・分析しやすくなるわけですね。
dbtのconfigや、既存のパッケージを使うことで、自動的にクエリへタグやコメントを付与することもできるので、「人手で毎回設定する」のではなく、パイプラインの中に組み込んでいこう、という話になっています。
最後がSnowflake Object Tagです。これはユーザーやテーブル、カラムなどのオブジェクトに、キーとバリューの形でタグをつける仕組みです。
たとえばBudgetやQuotaと組み合わせて、「この部門・この用途のオブジェクトは、このくらいまでのコストに抑えたい」といったコスト管理をしたり、「このテーブルは、どのリポジトリで管理されているのか」をタグで表して、オブジェクト管理をしやすくしたり。
さらに、ポリシーをタグ経由で適用する、属性ベースの権限管理にも使えます。「このタグが付いているデータは、このロールだけ読める」といった制御ですね。
まとめとしては、「クエリそのものの監視にはQuery Tagを使う。テーブルやカラムといったオブジェクトの統制にはObject Tagを使う」。こうやって役割を分けて考えると整理しやすいですよ、という内容になっています。dbtとSnowflakeを本番運用しているチームには、かなり実務的に役立つ記事だと思います。
。。.。。.。。.
というわけで、きょうのzenncast、紹介した記事をざっとおさらいしておきましょう。
まず一つ目は、テスト時間を削減するために、計測してボトルネックを見つけ、カバレッジレポートの無効化やPrismaまわりのimport改善、Vitestのモード変更、テストの重複削除などを、AIの力も借りながら進めていったお話。
二つ目は、NuxtからNextへのリプレイスを、AIコーディング前提のフローで高速に回しつつ、「理解負債」をどうケアしていくか、という問題提起とその工夫。
三つ目は、VRChatのUdon向けに、ほぼフル機能のCシャープをコンパイルできるMenSharpをRustで開発した、という熱量高めな技術記事。
四つ目は、GPTシックス・アストラのasyncツールコーリングとmid-turn steeringを詳しく検証して、どんなときにどう使うといいのかを整理したTips。
そして五つ目は、dbtタグ、Snowflake Query Tag、Snowflake Object Tag、この三つの違いと、クエリ監視とオブジェクト統制でどう使い分けるか、という整理の記事でした。
気になる記事があった方は、ぜひショーノートから元の記事をチェックしてみてください。ここでは話し切れなかった細かい部分や、図解なんかも含めて、より深く学べると思います。
この番組「zenncast」では、リスナーのみなさんからの感想や、「こんなテーマ取り上げてほしい！」というリクエストも募集中です。実際にやってみた話や、うちの現場だとこうしてるよ、みたいなフィードバックも大歓迎です。
それでは、きょうはこのへんでお別れです。
お相手はマイクでした。また次回のzenncastでお会いしましょう。
それではみなさん、良い一日を。