どうもおはようございます。マイクです。
今日も始まりました「ぜんきゃすと zenncast」。
二千二十六年七月二十九日、水曜日の朝七時台、お付き合いよろしくお願いします。
この番組では、技術記事の投稿プラットフォーム「Zenn」に掲載されている記事の中から、いまホットなトレンド記事をピックアップして、ラジオ感覚でゆるっと、でも内容はしっかりめにご紹介していきます。
さて、きょうはリスナーのみなさんからのお便りはお休みということで、そのぶんガッツリと記事紹介に時間を使っていきたいと思います。
きょうご紹介する記事は、ぜんぶで五本です。
超大規模モデルを一台に載せちゃった話から、AI 時代のコードレビューのやり方、エージェント設定の同期ツール、非同期処理での「一個しかないやつ」を守る設計の話、そして Snowflake での個人情報マスキングまで。なかなか濃いラインナップになってます。
ではさっそく、一本目いってみましょう。
一つ目は、Kimi-K3 っていう超大規模な MoE 型のオープンウェイトモデルを、NVIDIA の B三百 GPU を八枚積んだ一ノードにデプロイして、初日にベンチマークしてみた、っていうレポートです。
この Kimi-K3、総パラメータは二・八兆という、とんでもない規模なんですけど、ポイントはここからで、MXFPフォーマット、具体的にはエムエックスエフピー四ビット前提で学習された「量子化済みウェイト」を使っているおかげで、モデル全体のサイズが約一・六テラバイトに収まっているんですね。
その結果、B三百を八枚積んだ一台のノードで、そのまま動かせるような設計になっている、というのが大きな特徴になっています。
推論の仕組みのところでは、SGLang というフレームワークの DCP 機能を使っていて、KV キャッシュをハイブリッド構成、つまり KDA と MLA を組み合わせたかたちで GPU 間に分散しています。これによって、実効コンテキスト長、扱えるトークン長が約五十二万トークンまで確保できた、という報告です。
一方で、メモリ配分のパラメータとして `mamba-full-memory-ratio` をちょっと欲張って大きくしすぎたな、という反省も書かれています。ただ、その状態でも同時リクエストが三十件くらいまではスループットがきれいに伸びていって、速度としては GLM ファイブ・ツーと同じクラスのパフォーマンスは出ている、という評価になっています。
面白いところとして、Aスター探索、Aアスタ―経路探索の可視化ツールを「一発実装してみて」とモデルに投げてテストしているんですけれども、ちゃんと要件を満たしたコードを出してくれるだけじゃなくて、ショートカットキーを用意してくれたり、ユーザーインターフェースのちょっとした工夫みたいな、「お、そこまでやってくれるの？」という気の利いた追加も見られたそうです。
なので、単にベンチマークのスコアが出ているというだけじゃなくて、コーディングエージェントとして実際に使ったときの「体感品質」としてもかなり高く評価されています。
著者としては、二・八テラ級のモデルが B三百八枚の単一ノードで、しかも実用的な速度で動いたというのを、大きな成果だと位置づけています。その一方で、モデルの起動に約一時間半かかること、それからワークロードに合わせたメモリ配分のチューニングが運用上の鍵になる、といった現実的なポイントもちゃんと押さえていて、「やってみて終わり」ではなく、この先どう運用していくか、というところまで見据えた記事になっています。
巨大モデルをオンプレや専用ノードで回したい人には、かなり参考になる内容ですね。
。。，。
続いて二本目は、AI でのコード生成量が爆発しているいま、もう人間が diff を全部読むのは現実的じゃないよね、というところからスタートする記事です。
筆者は「だったらコミットを小さくしよう」とか「コミット回数を減らそう」という方向には行かずに、発想を逆にして、「読まなくても、壊れたら必ず赤く止まる仕組みを、とにかく徹底的に積み上げる」という方針を取っています。その結果として、人手によるコードレビューをほぼやめた、という話になっています。
具体的には、まず CLAUDE ドットエムディーみたいなファイルを用意して、開発ルールやお作法を明文化してリポジトリに含めたり、技術スタックをちゃんと揃えて、規約やコーディングスタイルを「どのプロジェクトでも共通にする」ということをしています。
静的解析のところでは、ESLint や型チェックを、とにかく人間だったら嫌がるレベルまで厳しくしていて、どうしても例外を認める場合には、かならず理由と期限を書く、つまり「ここはいつまで特例でゆるくしているのか」が見えるようにする運用にしているそうです。
設計のほうでは、関数をできるだけ pure、純粋関数寄りにして、外部状態に依存しないようにすることで、静かに壊れるバグを潰しています。加えて、網羅的なテストを書くことで、「動いているように見えるけど、ある条件だと壊れる」といったケースも拾っていきます。さらに、重複コードやデッドコードのスキャン、そして三つの OS 向けの CI を回すことで、環境による取りこぼしも減らしていく、という構えです。
おもしろいのは、コードを書く AI モデルとは別に、CI 上で動く「自動レビューモデル」を用意しているところです。つまり、書く担当のモデルと、レビュー担当のモデルを分けておいて、CI の中で複数のボットがレビューして、その指摘を人間が仕分ける、という運用にしているんですね。
こうすることで、実質的なレビューの大部分は機械に任せてしまって、人間は本当に判断が必要なところだけを見るようにしていきます。
その結果として、筆者の仕事は、かつてのように「コードを読む」ことではなく、プロダクト全体を「見る」ことにシフトしたと言っています。
最終的な結論としては、品質確保の中心は、個々人の注意力とか、頑張って目を通すことではなく、「壊れたら必ず赤を出す仕掛けを、どれだけ密に、どれだけ網羅的に敷き詰められるか」にあるんだ、というメッセージになっていて、AI 時代の開発プロセスを考えるうえで、かなり示唆に富んだ内容です。
。。，。
三本目は、Claude Code と Codex で同じプロジェクトを扱うときの「設定ファイルがズレていく問題」を扱った記事です。
AGENTS ドットエムディーとか SKILLS、それから MCP の設定なんかが、それぞれのエディタやツールごとに別々に更新されていって、いつの間にか内容が合わなくなっている、っていう経験をした人も多いと思います。
既存のツールだと、そのあたりの同期は、単純にコピーするとか、シンボリックリンクを作る、といったレベルにとどまっていて、「差分をどうマージするか」とか、「項目ごとに同期する・しないを細かく制御する」といったことまではカバーしきれていません。
そこで筆者は、Claude Code と Codex の設定ファイルを自動で同期する CLI ツール「エージェンツ・シンク」と、バックグラウンドで常駐するスクリプトを自作しています。
やっていることはけっこう凝っていて、まず形式が同じ設定ファイルについては、思い切ってシンボリックリンクで一元管理します。逆に、MCP の設定や hooks みたいに、ツールごとにフォーマットが違うものについては、一度「中立的な共通フォーマット」に変換したうえで比較して、「どこが違うのか」を見てから、必要な部分だけを相手側の書式に変換して反映する、というやり方をとっています。
さらに、「全部を同期する」のではなくて、「MCP だけ共有して、スキルの説明文はモデルごとに変えたい」といった、モデル最適化のための細かい指定もできるようになっています。
初回のセットアップも、フォルダを丸ごと AI に渡して、「これ導入して」とお願いすると、対話的にガイドしてくれて、どの差分をどう扱うか、自動同期をオンにするかどうか、といったところまで、ひと通り案内してくれるような作りになっているそうです。
要するに、「エージェントまわりの設定ファイルを、複数ツール間でちゃんと整合性をとったまま育てていけるようにする」ための仕組みで、Claude と Codex の両方を本格的に使っている人にはありがたいユーティリティになっています。
。。，。
四本目は、非同期コードで「マイク」とか「デバイス」みたいに、一つしかない実体を扱うときの話です。
こういうリソースって、「今どんな状態か」を読むのはすぐできるのに、停止とか再開みたいな状態変更は、どうしても await をまたぐ非同期処理になりがちですよね。そうすると、チェックした時点では「止まってます」とか「空いてます」といった正しい状態だったのに、処理が終わるころには別のリクエストが割り込んでいて、状況が変わってしまっている、ということが起きます。
特に、OS からの同期的なコールバックが、非同期処理をポンと投げっぱなしで動かしてしまうような実装だと、「停止」と「再開」のリクエストが、await のすき間ですれ違ったり、互いに割り込んだりして、「二重停止」とか「二重取得」になってクラッシュする、というパターンが出てきます。
この記事では、こういった問題を mutex、排他制御の考え方で整理し直していて、対策を二つに分けて説明しています。
一つめは「諦める」方式です。これは、いま状態変更の処理中かどうかを示すフラグを、同期的にサッと立ててしまって、そのフラグが立っているあいだに来た新しい呼び出しは、即座にやめてしまう、というパターンです。
ボタンの連打とか、定期的な同期みたいに、「何回か落ちても別に困らない呼び出し」に向いていますね。
もう一つは「待つ」方式です。こちらは Future の then などを使って、非同期処理を一列に並べてしまいます。前の処理が完全に終わるまでは、次の処理を始めない。で、自分の番が回ってきたときに、あらためて状態を読み直してから実行する。
こうすることで、同じリソースに対する操作は、結果的に一回ずつしか行われなくなります。この「待ち行列」は、守りたいリソースごとに持つようにしておいて、必要であれば「順番が来たけれど、本当にまだやるべきか？」をフラグなどで再確認してから実行する、という構成にします。
記事全体としては、「いまの状態はこうだから大丈夫なはず」という前提に頼るのではなくて、「実際に操作するときに、必ず排他を取るか、列に並ばせる」ことが大事だよ、というメッセージになっていて、非同期プログラミングでありがちなハマりどころを、具体的に整理してくれています。
。。，。
そして五本目は、Snowflake 上で、フリーテキストに含まれた個人情報、いわゆる PII を守るためのマスキング構成についての記事です。
ここで紹介されているのは、AI_REDACT という機能を使った「保存時の AI マスキング」と、その上に正規表現ベースのマスキングポリシーを重ねる、二層構成のアプローチです。
AI_REDACT は、Snowflake Cortex が提供する大規模言語モデルを使った PII の検出機能で、日本語を含む自然文のテキストの意味を読んだうえで、氏名・住所・電話番号といった個人情報を見つけてくれます。見つけた部分は、たとえばカギ括弧に入ったネームとかアドレスといったラベルに置き換えてくれます。
こういう「文脈的な個人情報」に強いのが AI_REDACT の得意分野です。
一方で、銀行口座番号や郵便番号、ID といった「桁数や形式が決まっている数字」に関しては、正規表現ベースのマスキングポリシーのほうがシンプルで強力です。
記事では、この二つを組み合わせて、「まず AI_REDACT で文章の意味を読んで、名前や住所をラベリングし、その上にルールベースのマスキングをかける」という構成を提案しています。
ただし、AI_REDACT はトークン数に応じた従量課金になっているので、「どれくらいのコストがかかるか」を事前に見積もることが大事になります。そこで登場するのが `AI_COUNT_TOKENS` で、この関数で、テキストをどれくらいモデルに食べさせることになるのかを計測して、コスト感をつかむわけですね。
さらに、なるべくコストを抑えるために、「モデルに渡すテキスト量を極力減らす」工夫がいろいろ紹介されています。具体的には、同じデータが重複している行をあらかじめ除外したり、すでにマスク済みの行はスキップしたり、JSON など、そもそも PII を含んでいないペイロードは対象から外したり、といったものです。場合によっては、一つの長いテキストを、意味を保ったまま適切な長さに分割してから投げる、といったテクニックもあります。
こういった工夫を積み重ねることで、「AI ベースの検出の強み」と「ルールベースのマスキングの強み」を両立させつつ、コストも現実的な範囲に抑えよう、というのがこの記事の狙いになっています。Snowflake 上でフリーテキストのログや問い合わせ履歴を扱っている方には、かなり実践的な内容ですね。
。。，。
というわけで、きょうの「ぜんきゃすと zenncast」は、
一つ目に、二・八兆パラメータの Kimi-K3 を B三百八枚の一ノードで動かして、MXFP四ビットの量子化と SGLang の DCP で実効コンテキスト五十二万トークンを確保した、というデプロイ＆ベンチマークの話。
二つ目に、AI 時代のコード生成爆発に対して、「読まなくても壊れたら必ず赤く止まる仕組み」を積み上げて、人手コードレビューをほぼ卒業したワークフローの話。
三つ目に、Claude Code と Codex 間でエージェント設定がズレていく問題を、「agents-sync」という CLI で中立フォーマットを介しながら自動同期する仕組みの話。
四つ目に、非同期コードで「一つしかないリソース」を守るために、「諦める」と「待つ」という二つの設計パターンで、状態変更を直列化してクラッシュを防ぐ話。
そして五つ目に、Snowflake の AI_REDACT と正規表現マスキングポリシーを二層構成で組み合わせて、日本語テキストに含まれる PII を守りつつ、トークン課金のコストも抑える設計の話。
この五本をお届けしました。
それぞれの詳しい内容や、実際のコマンド、設定例なんかは、番組のショーノートに元記事へのリンクと一緒にまとめておきますので、気になった方はぜひそちらから、じっくり読み込んでみてください。
この番組「ぜんきゃすと zenncast」では、感想や質問、取り上げてほしいテーマなんかも、いつでも募集しています。「この回が役に立ったよ」とか、「こういうネタも聞きたい」といった声をもらえると、マイクもすごく励みになります。
それでは、そろそろお別れの時間です。
きょうも聞いてくれてありがとうございました。次回の配信でまたお会いしましょう。
お相手はマイクでした。いってらっしゃい。