どうもマイクです。おはようございます。
七月三十日、木曜日の朝七時を回りました。今日も zenncast、元気にお届けしていきます。
この時間は、テック系の話題を中心に、Zennで今トレンドになっている記事をゆるっと紹介していきますよ。
今日は五本、気になる記事をピックアップしてきました。
TypeScript と Vue の最新ツールから、三ディーモデリングと AI の実験、GitHub と Claude Code の連携、MCP を使った自作エーピーアイのハブ基盤、そして NVIDIA の DGX 上での LLM 比較まで、幅広くご紹介していきます。
それではさっそく、一つ目の記事からいきましょう。
まず一つ目は、TypeScript セブン時代の Vue.js 向けツールチェーン「Vize」を、実際の社内プロダクトに導入して検証してみた、という記事です。
この Vize っていうのが、ラストで書かれた Vue.js 専用の統合ツールで、コンパイルに加えて、Lint、型チェック、フォーマット、そしてエディタ連携まで、全部を共通の基盤で面倒見てくれる、というのが売りになっています。
導入の仕方もけっこうシンプルで、既存の `vue-tsc` と `oxlint + eslint` の部分を、それぞれ `vize check` と `vize lint` に差し替えるだけ。さらに、Vite の公式 Vue プラグインを、Vize 製のプラグインに置き換える、という形で入れていったそうです。
つまり、「プロジェクト全部作り直し」みたいな大掛かりな移行じゃなくて、今使っているツールの入口だけ差し替える感じで始められた、というのがポイントですね。
気になる結果なんですが、型チェックは最大で約八倍、Lint に至っては七十倍以上も高速化した、というインパクトのある数字が出ています。ビルドも、劇的ではないものの、わずかに速くなったとのこと。
スピードだけじゃなくて、品質面でもメリットがあって、たとえば HTML の不正なネスト、props のシャドーイング、クロスサイトスクリプティング、いわゆる XSS の温床になりそうな箇所や、アクセシビリティに関わる問題など、これまでのツールチェーンでは見逃されていたような不具合も、Vize を通すことで検出できたそうです。
とはいえ、Vize 自体はまだ「実運用前の検証フェーズ」という位置づけで、型チェックの厳密さがどこまで担保されるのかとか、大規模プロジェクトでの挙動がどうなるのか、といったあたりは、今後もしっかり検証が必要だとまとめています。
TypeScript セブンで、コンパイラまわりがどんどん高速化している流れの中で、その波に Vue.js のエコシステムがどう追随していくのか。その有力な選択肢のひとつとして Vize が浮上してきていて、今後かなり期待できそうだよね、という内容でした。
。 。 。 。
続いて二つ目の記事です。
こちらは、GPT ファイブ点シックスに Blender MCP を使わせて、三ディーモデルを作らせてみる、という試行錯誤を通じて、AI による三ディーモデリングの限界と、そこをどう工夫で乗りこなすか、という話をまとめたものです。
まず面白い指摘として、AI に何も工夫をしないで Blender を触らせると、キューブとか円柱をちょっと並べただけの「積み木モデル」で満足してしまう、という問題が紹介されています。
AI の側は、「コマンドを実行できた」「操作がエラーなく通った」ということと、「見た目として正しい形になっている」ということを、けっこう混同してしまうんですね。だから、形の出来はイマイチなのに、「やった、できた！」と判断してしまう。
そこで筆者が取ったアプローチが、作る役と評価する役をきっちり分けた、マルチエージェント構成です。
具体的には、AGENTS ドットエムディーというドキュメントで役割分担を書き出したり、「Skill」と呼んでいるコマンド群を整理したり、品質チェックリストを用意して、一定のチェックポイントごとに状態を確認して、ダメならロールバックする、という仕組みを組み合わせています。
その結果として、単にオブジェクトを置くだけじゃなくて、参照画像に近づけるための改善を自動で繰り返したり、作ったモデルをエフビーエックス形式でエクスポートしたあと、もう一度インポートして検証するといったところまで、自動でこなせるようになったそうです。
とはいえ、人間の目から見ると、「主軸がずっと四角柱のまま」みたいな、造形上の違和感はまだかなり残っていて、「おおむね形にはなっているけど、ディテールが甘い」という段階にとどまっている、という評価でした。
筆者はここで、「マルチエージェント化は魔法の杖ではない」とまとめています。
大事なのは、検査側のエージェントに渡すチェックリストの中身を、「何を必ず見るべきか」という観点で、どんどん具体的に書き足していくこと。
そうやって検査項目を蓄積していくことで、最初は積み木レベルだったモデルが、「多少マシ」なレベルにまでは押し上げられる。そのための道具として、マルチエージェント構成はかなり有望だ、という結論になっています。
三ディーモデリングは、まだ完全自動は難しいけれど、「人間がチェックリストを設計し、AI はそれに従って地道に作業する」という形で、うまく分業していく未来が見えてきた、という内容でした。
。 。 。 。
さて三つ目、ここからはちょっと実用寄りの Tips 系の記事です。
テーマは、Claude Code の「Routines」という機能を使って、GitHub のプルリクエストをきっかけに、自動で AI コードレビューを走らせる、という話になっています。
まず仕組みとしては、GitHub の「プルリクエストがオープンされた」というイベント、いわゆる pull アンダースコア request ドット opened をトリガーにして、Claude Code Routines を起動します。
そうすると、あらかじめ設定しておいたレビュー用のスキルを使って、AI がそのプルリクのコードをざっとレビューしてくれて、結果をそのままプルリクのスレッド上にコメントとして残してくれる、という流れです。
さらに、Author フィルターというのを使うと、「自分が出したプルリクだけを対象にする」といった絞り込みもできるので、チーム全体に影響を与えず、まずは自分のレビュー補助として試せるのもポイントですね。
設定の要点が四つ、整理されています。
ひとつ目は、対象となるリポジトリと実行環境をきちんと選ぶこと。
ふたつ目は、Instructions のところで、自作したレビュー用コマンド、つまりスキルを明示的に指定しておくこと。ここを曖昧にすると、AI がどのスキルを使えばいいのか迷ってしまうので注意が必要です。
みっつ目は、トリガーを「プルリクエストが Opened」か、「Ready for Review」に設定すること。ドラフトから本番レビューへの切り替えタイミングに合わせるなら、Ready for Review のほうがよさそう、という話も出ています。
よっつ目は、不要な外部連携、Connector を外しておくこと。これで、余計なところにアクセスしない、シンプルな構成にできます。
Routines 自体は、Claude Code の通常利用と同じサブスクリプション枠を使うので、GitHub Actions や、専用のコードレビューサービスみたいに、追加の課金を気にせず試せるのも大きなメリットです。
しかも、実装に使っているセッションとは別の「クリーンな環境」でレビューが走るので、ローカル環境の細かい作業履歴に引きずられにくい、という利点もあります。
一方で、AI レビューは確率的な性質があるので、毎回同じコードでも指摘内容にブレが出たりします。
そのため、ローカル側のスキルで「採点基準」をはっきり決めておいて、一定の点数を満たしたレビューだけをプルリクに投稿する、といった運用が勧められています。
プルリクオープンをトリガーにしておけば、「レビューを手動で実行し忘れた」というヒューマンエラーも減らせるので、日々の開発フローにうまく溶け込ませられそうだ、という Tips 集でした。
。 。 。 。
四つ目の記事にいきましょう。
ここでは「Super MCP」という個人向けの基盤が紹介されています。これは、ChatGPT から複数の自作エーピーアイを、一つの共通 MCP サーバー経由でまとめて扱えるようにするための仕組みです。
やり方としては、Web のコンソールから、各エーピーアイの URL や OpenAPI の定義、それから認証情報なんかを登録していきます。
すると、Super MCP がその OpenAPI の各 operation を内部コマンドに変換してくれて、クライアント側からは、固定のふたつの MCP ツール、list アンダースコア commands と call アンダースコア command だけを使えば、任意のエーピーアイを呼び出せるようになる、という設計になっています。
つまり、「新しいエーピーアイを足すたびに MCP 用の endpoint を増やす」みたいな面倒を避けて、ひとつの MCP サーバーの中で全部まとめて面倒を見る、という思想ですね。
認証まわりの設計もきちんと分かれていて、「ChatGPT から Super MCP まで」と、「Super MCP から各エーピーアイまで」で、二種類のオーオースを使い分けています。
後者、つまり Super MCP から先のトークンやエーピーアイキーは、エーイーエス二五六 GCM で暗号化して保存しているので、登録したキーをそのまま平文で抱えないようにしているのもポイントです。
こうすることで、エーピーアイごとに MCP endpoint やオーオース実装を重複させることなく、新しい自作エーピーアイを短いサイクルで追加しやすくなっている、というわけですね。
ただし、これはあくまで「開発者モード専用」のツールとして位置づけられています。
一般公開アプリとして外に出すには、安全面や権限設定の細かさに課題があって、現時点では提供していない、と著者は説明しています。
運用の方針としては、読み取り専用のデータは、スプレッドシートとの同期に切り替えて扱いつつ、Super MCP は「書き込みを伴う自作エーピーアイを集約する、実験用のハブ」として使っていく、というスタンスが語られていました。
自分で小さなエーピーアイをたくさん作っている開発者にとっては、「全部をひとつの MCP からまとめて叩ける」っていうのは、けっこう夢のある構成ですよね。
。 。 。 。
そして最後、五つ目の記事です。
こちらは NVIDIA の DGX Spark 上で、二種類の Gemma フォー モデルを比較して、ソフトウェア開発の相棒としてどちらが良いかを検証した、という内容になっています。
評価には NeMo Evaluator というツールが使われていて、ベンチマークとしては、Python のコード補完を評価する HumanEval と、算数と論理問題の能力を測る GSM エイトケー、このふたつで性能を見比べています。
その結果、精度の面では、両方のモデルがほぼ同等で、コーディング力と推論力については、実用上ほとんど差がない、という結論になりました。
一方で、パフォーマンス、つまりスピードの面では、はっきり差が出ています。
Gemma フォー、二十六ビーモデルの A フォービー NVFP フォー、という構成のモデルは、三十一ビーモデルに比べて、およそ四倍のトークン処理速度を出していて、体感としても圧倒的に応答が速い、という結果が出ています。
同じくらいの精度なら、日常的な開発作業では、レスポンスの速さはかなり重要ですよね。
こうした結果を踏まえて、記事では「DGX Spark を使った開発用途では、インタラクティブな対話や、普段のコーディング支援を重視するなら、二十六ビーモデルが最適」という結論になっています。
逆に、「精度を限界まで追い込みたい」「とにかく一問あたりの正解率を最大化したい」という、少し特殊なニーズがある場合だけ、三十一ビーモデルも選択肢に入ってくる、という位置づけですね。
実際の現場で「どのモデルを日常使いにするか」という判断に、かなり参考になりそうな内容でした。
。 。 。 。
というわけで、今日の zenncast は、全部で五本の記事をご紹介しました。
ざっとおさらいすると──
ラスト製の Vue.js 向け統合ツール「Vize」を実プロダクトで試して、型チェックが最大八倍、Lint が七十倍以上速くなった、という TypeScript セブン時代のツールチェーンの話。
それから、GPT に Blender MCP を触らせて三ディーモデルを作る中で、マルチエージェント構成とチェックリストで、「積み木レベル」から「多少マシ」なモデルへ押し上げていく工夫の話。
三本目は、Claude Code Routines でプルリクオープンをトリガーに自動 AI コードレビューを走らせる設定のコツと、採点基準をはっきり決めて運用する、という Tips。
四本目は、複数の自作エーピーアイを一つの MCP サーバーでまとめて扱う「Super MCP」の設計と、書き込み系エーピーアイの実験用ハブとしての使い道。
そして最後に、NVIDIA DGX Spark 上で二種類の Gemma フォーモデルを比較して、日常の開発相棒としては、四倍速い二十六ビーモデルがベスト、という評価結果でした。
気になった記事があった方は、ぜひショーノートから元の記事もチェックしてみてください。今日ご紹介した内容の詳細や、ここでは触れきれなかったサンプル、グラフなんかも載っています。
この番組 zenncast では、感想や質問、「こんなテーマを取り上げてほしい」といったリクエストもいつでも募集しています。
普段どんなふうにツールを使っているか、今日の話を聞いて試してみたことなども、ぜひ教えてください。
それでは、そろそろお時間です。
お相手はマイクでした。また次回お会いしましょう。
良い一日をお過ごしください。