おはようございます、マイクです。
今日は二千二十六年八月十五日、土曜日の朝七時をちょっと過ぎたところです。
ここからの時間は「zenncast」、きょうも最新のZennトレンド記事を、ゆるっと楽しく紹介していきます。
さて、きょうは最初に一通、お便りをご紹介しましょう。
ラジオネーム「watarukura」さん。
「毎日楽しみに聴いています。最近、バッククオートで括られた単語を読む際にバッククオート ほげほげ バッククオート と読まれるのが気になっています。」
watarukura さん、いつも聞いてくださってありがとうございます。
たしかに「バッククオート ほげほげ バッククオート」って、ラジオで読むと妙にノイズになりますよね。
技術記事だと、インラインコードをそのまま忠実に読もうとして、かえって聞き心地が悪くなる、あるあるです。
この番組では、バッククオートで囲まれたところは、できるだけ「コードっぽく」かつ「耳で分かるように」工夫して読んでいこうと思います。
たとえば変数名や関数名なら「…という変数」「…という関数」と日本語を足したり、記号が多いところは少し噛み砕いてお伝えしたり。
耳で聞いて理解できることを優先して、読まない方がよさそうな記号はスキップしつつやっていきますので、今後も気になったら遠慮なく送ってください。
さあ、きょう紹介する記事は、ぜんぶで五本です。
データ基盤、AIエージェント、JavaScriptのミニファイ、メール確認の新プロトコル、そして日本語TTSの新しいベンチマークまで、テック好きにはたまらないラインナップになっています。
それでは一つ目から、じっくり紹介していきましょう。
まず一つ目の記事は、Databricks の Declarative Automation Bundles、通称 DAB を使って、自動運転向けの大規模機械学習データセットを、めちゃくちゃ速く、しかも継続的に作っていくための、新しいデータ基盤の設計・運用方法を解説した、かなり実践的な技術記事です。ジャンル的にはティップス系ですね。
自動運転って、走行動画を山ほど集めて、それを画像に分割して学習データにする、という世界なんですが、この記事では、その「動画をあらかじめ全部画像にしておく」やり方をやめています。
代わりに、学習のときに、動画から高速に画像へ変換する「オンラインデコード」という方式に切り替えて、そのデータ形式を MosaicML の StreamingDataset、略して MDS に統一しています。
この切り替えによって、なんと五百時間分のデータセットの作成時間が、これまでの半日レベルから、六十分以下まで一気に短縮できた、というのがまず大きなポイントです。
基盤の上では、Databricks と Unity Catalog、それから Spark の Serverless 環境の上にパイプラインを構築しています。
ここで DAB を使って、ジョブ定義、実行環境、依存パッケージ、さらに開発・インテグレーション・本番といった環境ごとの差分まで、すべてコードとして管理するようにしているんですね。
そうすることで、一般的なソフトウェア開発と同じ感覚で、レビューして、テストして、CIとCDを回していける、っていうのが設計の思想になっています。
実装パターンとしては、「PipelineStep」という抽象クラスと、「InputLoader」、「PipelineRunner」という三つの役者に分けて設計していて、それぞれのステップは「必要な入力テーブル」と「副作用として出ていく出力」だけを宣言するようにしている。
このおかげで、機械学習エンジニアが新しい特徴量のステップを追加したり、変更したりするときも、安全に、影響範囲をコントロールしながら作業できる構造になっています。
CIまわりもかなりしっかりしていて、GitHub Actions から GitHub の OIDC を使って Databricks に認証し、タグをプッシュしたら本番環境に自動デプロイ。
メインブランチへのプッシュでは、Databricks 上で統合テストを実行します。ここでポイントなのが、本番と同じ Serverless 環境で、実データを使った比較テストが走ること。
スキーマが変わっちゃったとか、ロジック変更でおかしなデータになったとか、そういう不具合を本番投入前に検知できるようにしているわけです。
さらに、Serverless 特有のクセへの対策も細かく書かれています。
たとえば DataFrame をキャッシュできない、依存パッケージの解決が遅い、自動リトライを止められない、みたいな Serverless ならではの制約ですね。
これには、いったん Delta テーブルに一時書き出しして処理の系譜、いわゆるリネージをそこで区切る「マテリアライズ」というテクニックを使ったり、wheelhouse を事前にビルドしておいて、依存パッケージのインストール時間を短くしたり、ステータス管理用のテーブルを持っておいて、失敗したジョブの再実行をすぐに打ち切れるようにしたりと、現場目線の工夫が紹介されています。
パフォーマンスチューニングの話もあって、pyspark ではユーザ定義関数に頼りすぎず、applyInPandas を使ったり、集約時に min_by や max_by を使う、broadcast join や range_join のヒントを上手く使う、といったテクニックが挙がっています。
さらに Volumes の挙動と制約の話や、S三バケットへの書き込みは、FUSE 経由ではなく boto三 を使った方がいいケースなど、Databricks で大規模データパイプラインを運用していくうえで効いてくる、細かいノウハウもまとまっている一記事です。
大規模データ基盤づくりや、自動運転の ML パイプラインに興味がある方は、かなり刺さる内容だと思います。
。。。。
続いて二つ目の記事です。
こちらは「AIエージェントが自律的に開発タスクを回し続ける」、いわゆるループエンジニアリングを、Claude Code を使って実験した記録です。
筆者の方は、Cloud Logging に出てくるエラーログから、原因の調査、コードの修正、それにレビューまでを、できるだけ AI に任せる仕組みを作っています。
そのうえで「Maker–Checker 構成」という考え方を採用して、自己採点バイアスを防ぎながら、本物のバグを自動で検出・修正することができた、とまとめています。
構成としては、実装を担当するエージェントを Maker、検証を担当するエージェントを Checker として分けています。
Checker 側からは、ファイルの書き換え権限を完全に外していて、「直す」ことはさせず、「判定だけ」に徹させているのがポイントです。
さらに、pytest や mypy のような機械的なテストを、必ずゲートとして通すようにしていて、人間の感覚だけに頼らない安全装置を入れています。
検証用の題材として、ISBN のバリデーション付き書籍価格チェッカーを用意してテストしています。
ここでは、意図的に用意した異常系――たとえば ISBN の形式がおかしいとか、該当する本が存在しない、みたいなケースについては、正しく「これはバグではない、想定されたエラーだ」と判定できた一方で、全角数字を含む ISBN だけは、ちゃんと仕様違反として検出できました。
原因は、Python 標準ライブラリの isdigit という関数が、全角数字も通してしまう仕様だったこと。
ここに対して、半角数字だけを許可するチェック関数を新たに導入し、そのためのテストも追加する、というところまで、AI が自律的にやりきれた、というのが面白いところです。
この一連のプロセスのなかで分かったこととして、まず「ログに出ているエラーが、そもそも直すべきものかどうか」を最初に見極めるステップがすごく重要だ、という話があります。
なんでもかんでも直そうとするのではなく、仕様どおりの動きなのか、本当にバグなのか、をふるいにかけるフェーズですね。
それから、サブエージェント、つまり Checker 側に書き込み権限を与えないことで、役割分離がうまく効いてくる、という指摘もあります。
「直す側」と「評価する側」を分けることで、AI が自分でやった変更に甘くなりにくくなるわけです。
最後に、Checker が Maker と同じ手順を「ゼロからやり直す」フレッシュなコンテキストを持つこと。
これが結果の信頼性を大きく高めている、とまとめられています。
同じコンテキストを引きずらないことで、思い込みをリセットして検証できる、っていうことですね。
実際に AI に開発を回させてみたい方、ログ駆動でバグ修正を自動化したい方には、かなり参考になる実験レポートになっています。
。。。。
さあ、三つ目の記事です。
ここからは JavaScript の世界、変数マングルのお話です。
変数マングルというのは、JavaScript の変数名を短い名前に置き換えることで、コードサイズを小さくする処理のことですね。
この記事では、Oxc Minifier というツールで、どうやって「コードの意味を変えずに、変数名を最大限再利用しつつ短くしているか」という設計思想が解説されています。
まずやっているのは、各変数がどのスコープで有効か、つまり「生存区間」を計算することです。
この生存区間が重なっていない変数同士を、一つの「スロット」にまとめていきます。
同じ場所と同じ時間帯で同時に使われない変数なら、同じ短い名前にしても、プログラムの意味は変わらない、という考え方ですね。
次のステップとして、そのスロットごとの「登場回数」に応じて、よく使われるスロットには、より短い名前を割り振っていきます。
使う文字は、ユーティーエフエイトで一バイトの英数字と、アンダースコア、それからダラー記号に限っています。
さらに、ミニファイ後のコードの出現頻度にもとづいた順番で名前を生成することで、gzip などで圧縮したあとのサイズも小さくするよう工夫されています。
このスロット割り当ての問題は、変数を頂点として、生存区間が重なっているもの同士を辺で結んだグラフにして、そのグラフをどう色分けするか、という「彩色問題」として説明できます。
JavaScript ではスコープ構造がはっきりしているので、このグラフが「弦グラフ」と呼ばれる扱いやすい種類になります。
そのおかげで、浅いスコープから順に処理していく貪欲法、いわゆるグリーディーな手法でも、理論的に最小数のスロットに変数を詰め込める、ということが分かるんですね。
つまり、ただ適当に短い名前を振っているのではなく、
「使われ方をちゃんと解析して、生存期間がかぶらないようにギュッと詰めて、よく使うものには一番短い名前を与える」
そのうえで、圧縮後のサイズまで意識している、という、かなりアルゴリズム的に美しい設計になっている、という記事でした。
JavaScript のビルドや最適化が好きな方、またはコンパイラ実装に興味がある方には、読み応えのある内容だと思います。
。。。。
四つ目の記事にいきましょう。
ここでは、メールアドレス確認フローを、確認メールやコード入力なしで実現する、新しい仕組み「Email Verification Protocol」、略して EVP を解説しています。
今の多くのサービスでは、「メールアドレスを入力する → 確認メールが飛んでくる → そこにあるリンクを踏むか、コードをコピペする」という往復が必要ですよね。
EVP は、この「ユーザーがメールとサイトを行ったり来たりする」手間をなくしてしまおう、という仕組みです。
どうやるかというと、ブラウザが、メールプロバイダーから署名付きのトークンを直接取得して、そのトークンを、フォームを送信するときにサイト側へ渡す、という三者モデルになっています。
これによって、「このユーザーが、このメールアドレスを本当に持っている」ということを証明しつつ、トークンを発行する側、つまりメールプロバイダーには、「どのサイトにログインしようとしているのか」が知られないようになっている。
ユーザーの往復を消しつつ、プライバシーもしっかり守る設計です。
実装面では、サイト側がやることは意外とシンプルで、フォームに隠しフィールドを一つ追加して、そこにランダムなノンス、乱数の値を仕込むだけでよい、とされています。
あとは DNS の TXT レコード、JWT、HTTP 署名といった、既存の技術をうまく組み合わせて、セキュリティとプライバシーを担保します。
さらに、メールアドレスそのものがあちこちのサイトにばらまかれて、名寄せされてしまう問題を防ぐために、「Sign in with Apple」のような、プライベートメールアドレス機能も標準で含めています。
つまり、サービスごとに別々の中継アドレスを発行するようなイメージですね。
現時点では、Chrome と Edge、それから一部のメールプロバイダーでの実験段階で、まだ一般には広く使える状況ではありません。
そのため、非対応の環境向けには、従来どおりの確認メールベースのフローなど、フォールバックは必須とされています。
普及にはブラウザ、メールプロバイダー、そして Web サイトの三者すべてが対応する必要があるので、時間はかかるだろうと言われていますが、
「確認メールに依存しない、新しいメール確認の土台」になりうる技術として、今後の動向が気になるプロトコルです。
。。。。
そして最後、五つ目の記事です。
こちらはサービス紹介系の内容で、日本語の漢字読みをどれだけ正確にこなせるかを測る、ベンチマークのお話です。
もともと、日本語の漢字をどれだけ正しく読めるかを測るために、「常用漢字読みベンチマーク」という既存のデータセットがありました。
この記事の筆者たちがそれを精査したところ、およそ千三百文にのぼる誤り、不自然な例文、抜けなどが見つかったそうです。
そこで、それらを人手で大きく修正・補完して、常用漢字表ほぼすべての読みを、自然な文脈で評価できるようにした改良版ベンチマーク、「ジェイケーワイビー・パラキート」、JKYB–Parakeet が公開されました。
新しいベンチマークの特徴として、まず「読みのあいまいさ」や「複数の正解読み」がある場合も扱えるようになっています。
さらに、読み推定タスク、つまり漢字から読みを推定するタスクと、音声合成タスク、いわゆる TTS の両方を、公平に評価できる指標やスクリプトが整備されています。
これを使って、読み推定モデルや大規模言語モデル、あわせて二十八モデルと、日本語 TTS 四十一モデルを比較した結果、分かったことが二つあります。
一つ目は、大規模言語モデルは、漢字の読み能力がかなり高いということ。
そして二つ目は、多くの音声合成モデルは、熟字訓のような複雑な読みのパターンにまだ弱く、日本語 TTS における漢字読みは、いまだに未解決の課題である、という点です。
同時に、このベンチマーク上で、Parakeet 社の読み推定モデル「Parayomi」と、それを組み込んだ TTS モデル「Paratts バージョンワン」が、トップクラスの性能を示したことも報告されています。
今後は、同じレベルの読み精度を保ちつつ、感情表現を強化した「Paratts バージョンツー」の公開を予定している、ということで、日本語音声合成の進化にも期待が持てる内容になっています。
。。。。
というわけで、きょうの「zenncast」、駆け足でおさらいしていきましょう。
まず一つ目は、Databricks と DAB を使って、自動運転向けの大規模データセットを、オンラインデコードと MDS で高速に作り、Serverless の制約も乗りこなす、新しいデータ基盤の設計と運用ノウハウのお話。
二つ目は、Claude Code を使ったループエンジニアリングで、Maker–Checker 構成を取り入れながら、Cloud Logging のエラーから本物のバグを自動検出・自動修正していった実験レポート。
三つ目は、Oxc Minifier の変数マングルの仕組みとして、生存区間をもとにスロットを作り、頻度に応じて短い名前を振ることで、意味を変えずにコードを最小化する、アルゴリズムの解説。
四つ目は、Email Verification Protocol、EVP で、確認メールなしにメールアドレス確認を行いながら、プライバシーも守る、新しい三者モデルの提案。
そして五つ目は、常用漢字読みベンチマークを大幅に作り直した JKYB–Parakeet と、それを使った評価で、日本語 TTS における漢字読みがまだ課題であること、そして Parakeet 社の Parayomi と Paratts がトップ性能を出した、というサービス紹介でした。
気になった記事があった方は、この番組のショーノートに、元の記事への情報をまとめてありますので、あとでゆっくりチェックしてみてください。
「zenncast」では、番組の感想や、「こういう技術の話を取り上げてほしい」といったリクエストも、随時募集しています。
きょうの watarukura さんのように、「こういう読み方が気になる」といったフィードバックも、とても助かりますので、ぜひ気軽に送ってください。
それでは、そろそろお別れの時間です。
お相手はマイクでした。
次回の「zenncast」でまたお会いしましょう。
きょうも良い一日をお過ごしください。