どうも、マイクです。おはようございます。
九月二十二日、火曜日の朝七時を回りました。ここからの時間は「zenncast」、きょうもZennで話題になっているトレンド記事を、ラジオ感覚でゆるっとご紹介していきます。
きょう紹介する記事は、ぜんぶで五本です。
Goのデプロイから、AIエージェントによる開発フロー自動化、拡張性の高いプラグイン仕組み、そしてLLMのコストと精度の話、最後はCIを高速化するTipsまで、技術好きにはたまらないラインナップでお届けします。
ではさっそく、一つ目からいきましょう。....
一つ目は、VercelでのGoデプロイ方法を分かりやすく紹介している記事です。
以前のVercelでGoを動かそうとすると、ちょっとクセがあって、エイピアイフォルダの中にインデックスドットジーオーを置いて、ファイルごとに関数を書いて、それをベースに、ヴァーセルドットジェイソンでルーティングをがっつり定義してあげる必要があったんですね。フレームワークというより「Vercel流の作法」に合わせていく感じ。
ところが今は、かなりシンプルになりました。プロジェクトの直下に、ゴーモッドとメインドットジーオーを置いて、ふつうのGoサーバーを書くだけで、そのままVercel上で動かせるようになった、というのがこの記事のポイントです。
やることは三つだけ。
まず、Vercelの無料プラン、いわゆるホビープランのアカウントを用意して、CLIを入れます。
次に、メインドットジーオーに、エイチティーティーピー・リスン・アンド・サーブで立ち上がる、教科書どおりの典型的なサーバーを書いてあげます。
最後に、ヴァーセルドットジェイソンに「フレームワークはGoですよ」という指定を、一行、フレームワーク・コロン・ゴーと書くだけ。
記事の中では、実際にヴァーセル・プロッドというコマンドで本番デプロイまで走らせて、そのあとカールでエンドポイントを叩いて、Hello Worldがちゃんと返ってくるところまで確認しています。
クレジットカードも不要で、サクっとGoサーバーを外に公開したい人にとっては、「とりあえずVercelで上げてみるか」と気軽に試せる、かなり手軽な選択肢になったよ、というまとめになっていました。
個人開発でバックエンドをちょっと試したい、という人にはかなり相性よさそうですね。
....
続いて二つ目。こちらは、日々の開発フローそのものを「AIエージェントのスキル」としてまとめてしまって、イシューの取得から実装、レビュー、プルリク作成までを、ほぼ自動で進行させる仕組みを作った、というお話です。
起点になるのは、GitHubのIssueです。
専用のスキルとして、トゥデイズ・ワークというコマンドを呼ぶと、そこから一気に、
ブランチ作成、実装計画の立案、実装、動作確認、critとCodexによるクロスレビュー、プルリクエストの作成とコメント投稿、さらに作業ログの整理まで、Claude Codeが主導して進めてくれます。
開発者側はどうするかというと、すべてを自分でハンドリングするのではなくて、途中でAIから飛んでくる質問への回答とか、critレビューに対するフィードバックなど、「ここは人間の判断が必要だよね」というポイントだけに関わればよくて、それ以外の段取りや、Codexみたいな外部ツールへの依頼は、全部スキルにまかせてしまうイメージです。
これによって、従来の「自分がAIに一つ一つ指示を出す側」から、「AIが全体の工程を理解して、先回りして進めてくれる側」にガラッと役割が変わった、と筆者は感じたそうです。作業の負荷もかなり減ったとのこと。
今後の展開としては、本番障害対応とか、大規模リファクタリングなど、「パターン化しやすいけど、やることは多い」タイプの開発業務にも、このスキル化の考え方を広げていけそうだ、という考察も紹介されています。
単発でコードを書いてもらうんじゃなくて、「一日分の仕事」を丸ごと一つのスキルにする、という発想が面白いですね。
....
三つ目の記事は、Claude Modsという新しいプラグイン仕組みの解説です。
これは、Claude Codeの機能や画面表示を、タイプスクリプトの関数で直接拡張できる、かなりパワフルな仕組みになっています。
従来のhooksは、外部コマンドを叩いて、その標準入力と標準出力をやりとりするスタイルだったので、扱えるのはテキスト入出力が基本でした。それに対して、今回のFunction Hooksは、Claude Codeのエンジンと同じメモリ空間でコードが動くので、ツールの追加、UIの描画、状態管理といった、本体レベルの挙動まで、柔軟に差し替えられるようになっています。
実装のスタイルとしては、モッズの中でレジスター・オンという関数に処理を登録してあげて、イベントごとに「このときはこういう動きをする」というのを紐づけていきます。
さらに、ネクストという関数を使うことで、前処理・後処理を挟んだり、元の結果を書き換えたり、「この条件ならここで止める」といった早期拒否をしたりと、かなり細かい制御が可能です。
もう一つの特徴が、権限と安全性の設計です。
組織ポリシー、プロジェクト単位の設定、ユーザーごとのModなどが、五層のチェーン構造で重なるようになっていて、どのレイヤーが何を上書きできるのか、ちゃんと分かれている。これによって、セキュリティやガバナンスを保ちながら拡張していけるようになっています。
面白いのは、標準機能までこのModsでできているところです。
たとえば、ディフを取るためのスラッシュ・ディフコマンドや、エージェンツ・ドット・エムディへの対応、組織保護用のセック・デフォルトといった公式機能も、すべて同じ仕組みの上に実装されていますし、コミュニティ製のブラウザ埋め込みModや、ゲーム的な遊び要素を追加するModなんかも、この枠組みで動いています。
つまり、「Claude Codeそのものの挙動を、標準機能と同じ土俵で書き換えられる」将来性の高い拡張基盤ですよ、というのがこの記事の結論です。
IDEに対して、ここまでフルスタックで手を入れられるのは、かなりワクワクしますね。
....
四つ目の記事は、BigQuery上で大量の分類タスクをやるときに、Gemini系モデルとJevを比べてみた検証の話です。
ここで登場するJevというのは、長文をダラダラ生成するタイプではなくて、「用意された選択肢から選ぶ」とか「スコアをつける」といった意思決定に特化した、小さめのモデルになっています。Vercel AI Gateway経由で使うと、入力トークンの単価がかなり安いのも特徴です。
検証タスクとしては、スタック・オーバーフローの質問文、二百件を対象にして、二十個のタグから一つを当てる、という分類を実施しています。
このタスクで、Jevと、ジェミニ二点五・フラッシュ・ライトを比べてみたところ、精度はほぼ同じで、Jevが八十六点五パーセント、Geminiが八十六点ゼロパーセント。ただしコスト面では、Jevの理論費用が約四十一パーセント安くて、レイテンシもだいたい二倍くらい速かった、という結果になりました。
一方で、最新のGemini三点一・プロも試していて、こちらはさらにわずかに精度が高いものの、Jevと比べるとおよそ六十一倍のコストになる、という試算になっています。
十万行とか、数百万行規模でBigQueryから叩くようなケースだと、このコスト差は現実的じゃないよね、という指摘です。
記事では、近いタグ候補だけを強いモデルに再判定させる二段階構成とか、プロンプトの工夫も試しているんですが、今回のようなシンプルな分類タスクでは、コストが増えた割に精度の改善があまり得られなかったそうです。
さらに、BigQueryからリモートファンクション経由で外部モデルを呼び出す際の落とし穴にも触れています。
たとえば、リミットの挙動のせいで、思っていたより多くの行に対してモデルが呼ばれてしまうケースがあったり、再試行が走ることで、同じ行に二重課金される可能性があったり。実運用では、まずは小さなサンプルでテストすることや、結果をキャッシュして再利用することが重要だよ、とまとめています。
筆者のメッセージとしては、「なんでもかんでも万能で重いモデル一発で処理する」のではなくて、「選択肢が決まっている小さい判定なら、用途を絞った安いモデルで十分」という設計のほうが、費用対効果としては良い場合が多そうだ、というものです。
今後、クラウド側に、こうした判断特化モデルが標準搭載される可能性もあるので、その前にJevを触って、どんな特徴や限界があるのか体感しておくと役に立つよ、という締め方になっていました。
....
そして五つ目、最後の記事です。こちらはTips系で、プルリクのCIの目的をシンプルに整理し直して、「ビルドと静的チェックが通ること」と「必要十分なテストが実行されること」に絞り込むことで、CIの時間を大きく削減した、という実践例です。
まず、プルリクCIでどのテストを走らせるか、というところを見直しています。
差分から変更されたGoパッケージを抽出して、ゴー・リストを使って依存関係のグラフを作ります。そのグラフから、「その変更に依存しているパッケージ」だけを対象にテストを実行するようにしました。
全パッケージのテストは、日次のCIに任せてしまって、プルリクのタイミングでは「影響があるところだけきちんと見る」という方針にしたわけですね。
次に、プルリクのステータスごとに、走らせるジョブを変えています。
プルリクがドラフト、つまりまだ作業中の状態のあいだは、重たいテストは走らせません。レビューやマージ直前のレディ状態になったタイミングで、フルテストを実行するように、GitHub Actionsの条件分岐を設定しています。
一方で、ビルド、フォーマット、リントなどの軽いジョブは、ドラフトでもしっかり回すようにして、フィードバックは早めに得られるようにしているのがポイントです。
最後に、データベースを使う結合テストの高速化です。
testcontainersでMySQLコンテナを起動しているのですが、従来はテストケースごとにコンテナを立ち上げていたところを、パッケージごとに一回だけ起動する形に変更しました。
シンク・ワンスを使って一度だけコンテナと共有データベース接続を用意して、各テストケースの前後でフィクスチャのクリーンアップを行うことで、テストの独立性を保ちながら、コンテナ起動を待つ時間を大幅に削減しています。
全体として、「どのタイミングで、どの範囲のテストが必要なのか」を丁寧に分解して、目的に合わない余分な処理をそぎ落としていった結果、開発スピードと品質の両立に近づけた、という内容でした。
CIが重くてつらいチームには、かなり参考になる工夫が詰まっています。
というわけで、きょうのzenncast、お届けしてきた内容を、最後に駆け足でおさらいしておきます。
まず一つ目は、VercelでのGoデプロイが、ゴーモッドとメインドットジーオーを置いて、フレームワークをGoに指定するだけで、無料プランから気軽にできるようになったよ、という話。
二つ目は、GitHubのIssueからトゥデイズ・ワークというスキルを呼び出すことで、ブランチ作成から実装、レビュー、プルリク作成まで、Claude Codeが一気通貫で進めてくれる、AIエージェント化の事例。
三つ目は、Claude Modsで、タイプスクリプトからClaude Codeの機能やUIを直接拡張できて、標準機能と同じ基盤でIDEの挙動を書き換えられる、というプラグイン基盤の話。
四つ目は、BigQueryでの大量分類において、JevがGemini系モデルとほぼ同じ精度を出しつつ、コストとレイテンシでかなり有利だった、用途特化モデルのコスパの良さ。
五つ目は、プルリクCIの目的を絞り込んで、差分に関係するパッケージだけテストしたり、ドラフトとレディでジョブを切り替えたり、testcontainersの起動回数を減らしたりして、CI時間を大きく削減したTipsでした。
気になった記事があれば、詳しい内容はショーノートにまとめてありますので、そちらから元の記事もチェックしてみてください。
この番組「zenncast」では、感想や「こんなテーマを取り上げてほしい」といったリクエストも、いつでもお待ちしています。あなたの開発の現場で役立ったTipsなんかも、ぜひ教えてください。
それでは、きょうも良い一日をお過ごしください。
お相手はマイクでした。また次回のzenncastでお会いしましょう。