どうも、zenncastのお時間です。パーソナリティのマイクです。
今日は2026年2月25日、水曜日の朝7時台いかがお過ごしでしょうか。
この時間は、Zennに上がっているトレンド記事の中から、開発者のみなさんに刺さりそうなネタをピックアップしてご紹介していきます。
今日は全部で5本、ご紹介していきます。AIとテスト、FastAPIの高速化、小洒落たAIエージェント基盤、Geminiが急に動かなくなった話、そして日本語LLMから自前のEmbeddingを作るという、かなり濃いラインナップです。
それでは1本目いきましょう。
タイトルは「AIのテストコードは信用するな🙅♂️」。
AIにテストコードを書かせる、もうだいぶ当たり前になってきましたよね。ただこの記事の筆者は、「そのまま鵜呑みにするのは危ないよ」と強く警鐘を鳴らしています。AIはテストを量産するのはめちゃくちゃ得意なんですが、「どこで何を保証するテストにするのか」という設計がすごく苦手。結果として、同じ振る舞いをレイヤー違い・粒度違いで二重三重にテストしてしまって、偽陽性が増えたり、テストが壊れたときに原因が追いにくくなったりしがちなんですね。
さらに、カバレッジを稼ぐことに必死なプロンプトにしちゃうと、実装の細かいところにべったり依存したテストを量産してしまう。壊れたテストを“通す”ために、なんでもかんでもモックに逃げるロンドン派寄りのテストに偏ってしまって、リファクタリングに極端に弱いスイートになる、という指摘もあります。
対策として筆者が提案しているのは、AIに丸投げせず、まず「テスト設計の思想」をちゃんとプロンプトで指定すること。たとえば、「古典派テストで振る舞いを確認する」「要件からテストケースを導く」「CRUDは統合テスト中心で」といった方針を、AIが参照できる rules や skills としてテンプレート化しておく。そのうえで、実際のテストコードを書く“作業”はAIにやらせて、人間は「何をどこまでテストするか」を決める“創造”的な部分を担当する。
結論としては、今のところ「AIはテストの自動生成係、人間はテスト設計の責任者」という役割分担が現実解だろう、と。カバレッジ至上主義に流されず、必ず人間がレビューすることで、AIテストの落とし穴を避けようというお話でした。エンジニアのみなさん、テストレビューの時間、削らずにちゃんと取りましょうね。
。。。。
続いて2本目の記事です。
タイトルは「FastAPIのJSONレスポンスに型を書くだけでレスポンスが速くなるらしい」。
FastAPIユーザー、これはちょっと嬉しいニュースです。バージョン0.131.0で、エンドポイントの戻り値に Pydantic モデルの型ヒントを書いておくと、それだけでJSONレスポンスのシリアライズが速くなる、という検証記事になっています。
これまで多くの人がやっていたのは、`response_model=` を使ってPydanticのモデルを指定する方法でしたよね。ところが新しい仕組みでは、関数の戻り値の型、たとえば `def get_users() -> list[User]` のように書いておくと、Rust実装のPydantic v2が直接JSON化まで面倒を見てくれる。Python側で一度オブジェクトにしてから変換、というオーバーヘッドが減ることで、高速化されるというわけです。
筆者は、同じように1000件のユーザーを返す2つのエンドポイントを用意して、`response_model` 方式と戻り値型ヒント方式を比較しています。その結果、平均レイテンシでおよそ1割前後の高速化、最遅レイテンシも0.0937秒から0.0641秒あたりまで改善していて、ばらつきも少なくなっている。さすがに「2倍速い！」というほどではないけれど、何もしないで、ただ型ヒントの書き方を変えるだけでこの違いが出るなら、やらない理由はないよね、というトーンです。
面白いのは、「型をちゃんと書くと保守性が上がる」だけでなく、「性能まで上がっちゃう」というところ。FastAPIを使っている方は、0.131.0以降にアップデートして、`response_model` を素直な戻り値の型ヒントに寄せていくと、自然とこの恩恵を受けられますよ、という締めになっていました。
。。。。
さあ3本目。
タイトルは「Entire.ioのコンセプトは正しい。でも今はまだ早い (2026-02-23時点)」。
Entire というのは、元GitHub CEOが手がけている開発者向けプラットフォームで、「AIエージェントが行った作業のコンテキストを、そのままGitリポジトリに保存してしまおう」という、かなり攻めたコンセプトのサービスです。Checkpoints というCLIを通じて、エージェントのセッションとコード変更をリンクさせることで、「なんでこの変更が入ったの？」を後から辿れるようにしたり、行単位のアトリビューションを残したり、巻き戻しを簡単にしたり、という世界観を目指しています。
コンセプトとしてはめちゃくちゃ筋が良くて、筆者も「方向性は間違っていない」と評価しています。一方で、2026年2月時点の実装にはかなり厳しい問題が山積み。たとえば git config を壊してしまう致命的なバグ、アトリビューションが常に0%になる不具合、シークレット検知が甘いことで資格情報が漏洩しそうな怖さ、トランスクリプトが意図せず公開されるリスク、LFSやsquash mergeとの相性の悪さ、日本語プロンプトの文字化け、パフォーマンス低下などなど…。
そのため、今のところは「小さな個人リポジトリで、Sandbox的に試す」くらいにとどめたほうがよさそうだ、と筆者は判断しています。条件としては、英語プロンプト中心で、LFSもsquash mergeも使わない、そして本番や大規模チームのリポジトリには絶対に入れないこと。
とはいえ、開発スピードはものすごく速くて、数ヶ月で様変わりする可能性も高い。なので、「重要な問題に挑んでいる有望なプロジェクト。ただし今はまだ実験段階」という位置づけで、ウォッチしながら折を見て再評価しよう、という結論になっています。AIエージェントとGitの統合にワクワクしている方は、期待半分・慎重さ半分で眺めておくのが良さそうです。
。。。。
4本目いきましょう。
タイトルは「AntigravityのGemini3.1Proが使えなくなった？？？」。
これは実際に遭遇した人もいるかもしれません。筆者は月額課金でGeminiを使っていて、Antigravity上で Gemini 3 Pro を使っていたんですが、2026年2月23日にアプリを開いたところ、3 Pro が消えて 3.1 Pro だけが表示される状態に。ところが、その 3.1 Pro を選択すると「このバージョンでは利用できません。最新版にアップグレードしてください」というエラーメッセージが出てしまい、チャットが一切使えなくなってしまった、というトラブルシュート記事になっています。
原因はシンプルで、Antigravityのアプリ本体が古いままだったこと。自動アップデートがうまく動いておらず、新しいモデルに対応したバージョンが入っていなかったんですね。その結果、UI上には 3.1 Pro が見えてるのに、裏側のアプリが対応してなくてエラー、というややこしい状態になっていました。
解決策として筆者がやったのは、公式サイトから最新版、記事執筆時点だとバージョン1.18.4以降のインストーラーをダウンロードして、今の環境に“上書きインストール”すること。アンインストールは不要で、そのまま上から入れ直す形です。これでGemini 3.1 Pro が普通に使えるようになった、とのこと。
プロジェクトや会話履歴などのデータは基本的に残る想定ですが、どうしても不安な方は事前にバックアップを取っておくと安心です。結論としては、「Gemini 3.1 Pro を使いたいときは、Antigravity側もちゃんと最新版になっていることが必須。同じようなエラーが出たら、まずは手動アップデートを試してみてね」という、地味だけど助かるノウハウになっていました。
。。。。
そして最後、5本目の記事です。
タイトルは「NVIDIA-Nemotron-Nano-9B-v2-Japanese から Embedding モデルを作る」。
NVIDIA の Nemotron-Nano-9B-v2-Japanese、名前からして頼もしそうな日本語LLMですが、公式のEmbeddingモデルは用意されていないんですよね。そこで筆者は、「じゃあ自分でEmbeddingモデルを作ってしまおう」ということで、記事推薦用の特徴量生成を目的に、自作のEmbeddingを構築した手順をまとめています。
やっていることは、Embedding界隈の“王道パターン”を、Nemotronにきれいに当てはめた感じです。まずLMヘッドを外したバックボーンモデルから、最終層のhidden stateを取ってきて、attention_maskを使ったMean Poolingで固定長ベクトルに変換。文ペア A,B のコサイン類似度行列を使った対照学習で、バッチ内の他の文をネガティブサンプルとして扱うスタイルですね。
データセットは2段構えで、最初に mMARCO Japanese を5万件ほど使って検索タスク向けに事前学習。そのあと JSTS を使って、意味類似度をより細かくチューニングしています。学習にはLoRAを採用していて、AttentionとFFNの各Projection層にアダプタを挿しているので、フルファインチューニングよりも軽量に回せる構成です。
評価結果がかなり面白くて、JSTSの検証データに対して、Nemotronを2段階学習したモデルは、Spearman 0.832、Pearson 0.882というスコアを記録。これは、専用Embeddingとして人気の Qwen3-Embedding-8B の Spearman 0.837 / Pearson 0.879 にかなり肉薄する数字になっています。一方で、平均絶対誤差 MAE はQwen3系より高めで、スコアの絶対値をどれくらい信頼できるか、という点にはまだ改善の余地あり、という自己評価もされています。
それでも、「少ないデータとシンプルな学習レシピでも、日本語特化LLMをEmbeddingに転用することで、専用Embeddingモデルに迫る性能が出せる」という示唆はかなり強いですよね。今後は技術系語彙や英語混じりの文での性能検証も続けていくそうで、日本語情報検索やレコメンドに興味がある方には、かなり刺激的な内容になっていました。
。。。。
というわけで、今日のzenncastは、AIテストの落とし穴から、FastAPIのちょい足し高速化テク、Entire.ioという野心的なAIエージェント基盤の現状、AntigravityとGemini 3.1 Proのトラブルシュート、そしてNemotronを使った日本語Embedding自作の話まで、一気に5本お届けしてきました。
気になった記事があれば、この番組のショーノートに詳しい情報を載せておきますので、あとでぜひチェックしてみてください。そして番組の感想や、「こんなテーマを取り上げてほしい！」といったリクエストも、どしどしお待ちしています。あなたの一言が、次回のラインナップを変えるかもしれません。
それでは、そろそろお別れのお時間です。
お相手はマイクでした。次回のzenncastで、またお会いしましょう。お仕事、勉強、そして開発、今日も一日がんばっていきましょう。