どうもこんばんはー！マイクでーす。
今日も「zenncast」お聴きいただきありがとうございます。

今日は、2025年11月25日、火曜日。
平日のど真ん中ですが、みなさんいかがお過ごしでしょうか。
この番組では、毎回、Zennで話題になっているトレンド記事をピックアップして、ゆるっと、でもしっかりご紹介していきます。

さて今日はですね、Zennで話題のトレンド記事を、ぜんぶで5本、ご紹介していこうと思います。
AI開発、Flutterの最新事情、ドキュメント戦略、そしてちょっと未来っぽいIDEのお話に、製造業×AIという、かなり濃いラインナップになってます。

それでは、今日紹介する内容、さっそく1本目からいきましょう。

まず1本目。
タイトルは「仕様書駆動開発で一番いいAIモデル&エージェント検証 11/23版」。

これね、「仕様書を書かせるAI」と「実装をさせるAI」、どっちにどれを使うのがいいの？っていう、めちゃ実践的な検証記事なんです。
筆者の方は、約4万行クラスのゲームを個人開発されていて、そのプロジェクトを題材に、3つのモデル、gpt-5.1系のcodex、Claude Sonnet、Gemini 3.0 Proを比較しています。

まずは、同じプロンプトで3つのAIに「仕様書」を書かせるフェーズ。読みやすさや抜け漏れのなさでいくと、第一印象は「Claudeが一番よくて、次がGemini、最後にCodex」という評価だったそうです。Claudeはとにかく丁寧で包括的、Geminiはややあっさり、Codexは日本語と英語が混ざって読みにくい、と。
ところがですね、この「よさそうに見えた仕様書」を元に、実際にcodexにコード実装させてみると、結果がひっくり返るんです。

より良かったのは、読みやすかったClaude仕様ではなく、「プロジェクトのベストプラクティスに沿った設計」が多かったGemini仕様書のほう。Claudeは仕様が細かすぎて、一部の誤った方針までがっつり固定されてしまい、コード側のAIが柔軟に判断できなくなっていた。一方、Geminiの仕様は、肝になる方針は押さえつつ、実装側に任せる余白があって、結果としていいコードにつながった、という分析です。

さらに、「同じ仕様書から実装させる力」はどうかというと、ここはgpt-5.1-codex-maxに軍配。Gemini 3.0 Proは、不要な変更を入れたり、余計なコードを足したりして、リファクタリングコストが高くつく印象だったそうです。
ベンチマーク的にも、SWE-BenchなどではGemini 3.0はClaudeやGPT-5.1に一歩劣る数字が出ているので、「自分の環境・このタスクに限っての結論」と前置きしつつも、筆者は「仕様書を書くのはGemini、実装を任せるのはgpt-5.1-codex」が最適解、とまとめています。
読みやすさだけじゃなくて、「その仕様がAI実装時にどう効いてくるか」まで見ないといけない、っていうのがすごく示唆的ですよね。仕様書駆動でAIを組み合わせて使いたい人には、かなり実戦的な内容になってます。

。。.。。.。.

続いて2本目。
タイトルは「【Flutter】Riverpod 3 への移行ガイド」。

Flutter使いの方、特にRiverpodヘビーユーザーには必読の内容です。
この記事は、Riverpod 2.xから3.xに移行するときにハマりがちなポイントと、その回避策を網羅的にまとめたガイドになっています。

まず大きな変更点として挙がっているのが、AsyncValueの`valueOrNull`が廃止されて`value`に一本化されたところ。今まで「エラーが起きたらnullじゃない状態を見て…」みたいなチェックをしていたコードが、3.xだと挙動が変わってちょっと混乱しがちなんですね。このあたりの「初回エラーでもnullを返す」っていう仕様をちゃんと理解しておかないと、バグの温床になるよ、という注意が書かれています。

次に大きいのが、Refサブクラス、いわゆる`xxxRef`がなくなって、全部`Ref`に統一された点。型を見て「これはStateNotifierRefね」みたいに判断していた人は、ここで一気に設計を見直す必要が出てきます。
さらに、Provider生成に失敗したとき、デフォルトで「自動リトライ」が入るようになったのも要注意ポイント。便利なんですが、グローバル設定や個別設定、テストでの扱いをちゃんと意識しないと、「なぜかテストだけ挙動が違う」ってことになりかねない、と。

ライフサイクル面では、`read`だけ使っていたViewModelや、`await ref.read(provider.future)`していた箇所が動かなくなるケースも紹介されています。ここは、`watch`に書き換えたり、`keepAlive: true`でライフサイクルを維持したり、一時的に`listen`を使って`readAsync`的な拡張で吸収する、といった実践的な対処法が丁寧に載っています。
StreamProviderまわりも地味に変わっていて、同値通知の抑制や`Stream<void>`非対応になったことから、イベントを「voidで投げる」のではなく、`bool`に変えたり、Notifier＋`updateShouldNotify`でイベントを扱う設計に変えたほうがいいよ、というアドバイスがされてます。

テスト周りでは、`ProviderContainer.test`が追加されたり、Future/StreamProviderのoverrideが復活したりと、嬉しい変更も多い一方で、「同じproviderを何度もoverrideするとエラーになる」といった罠も。`tester.container()`でテスト中のコンテナを取れるようになった話など、実務に直結するTipsがぎゅっと詰まってます。
全体として、「変更点をちゃんと理解して、設計とテスト戦略を少しアップデートすれば、Riverpod 3はかなり安定して使えるよ」という前向きなトーンの記事です。これから移行を考えているFlutterエンジニアの方、先に目を通しておくとだいぶ痛みが減りそうです。

。。.。。.。.

3本目。
タイトルは「AIファーストなドキュメント戦略 - DocCommentにユビキタス言語を書くだけのシンプルなアプローチ」。

これは、AI時代の「仕様書、どこに書く問題」に対する、かなり割り切った提案の記事です。
筆者はFlutter開発の現場で、「詳細なMarkdown仕様書を別途SDDとして維持する」スタイルをやめて、基本的に「コード直上のDocCommentに全部寄せる」という運用をしています。画面のUI番号、日本語の画面名、細かい仕様など、AIに伝えたい情報をガッツリdartdocに書いておく。プロジェクト全体の共通ルールだけ、軽くdocsディレクトリに置く、という割とミニマルな構成です。

ポイントは、「ユビキタス言語」をDocCommentに書く、という考え方。
ビジネス側が使っている言葉をそのままコメントに載せることで、AIに指示するときも同じ単語で話せるし、検索キーワードとしても強くなる。「売上集計サマリカード」とか「ポイント付与対象外の取引」といった、ビジネス寄りのフレーズをそのままコメントにしておくイメージですね。

さらに、このスタイルは「Agentic Search」との相性がいい、と。
DocCommentに固有の用語を書いておくことで、完全一致検索で「目的のコード」にAIがピンポイントでたどり着きやすくなる。OSSの学習データでも、「DocCommentと実装がペアになっている」コードは山ほどあるので、LLMはこの構造にすごく慣れている。だからこそ、「doc → 実装」を推測させるタスクでは、この形式が一番精度を出しやすいんじゃないか、という見立てが語られています。

もうひとつ大事なのが、「仕様と実装を同じ場所に置く」Colocationの発想。
人間もAIも、「別の場所にある仕様書」を探しに行くのがとにかく面倒、というのは共通していますよね。コードを開けば、その上に日本語で仕様が書いてある。これだけで、保守のときの負荷がかなり下がるし、AIに「この画面の挙動を変えて」と頼むときも、文脈を外さずに済む。
「AIファーストって、すごいツールを入れることより、こういうコメントの書き方から始まるんだよ」という、肩肘張らない提案が印象的な記事でした。今、自分のプロジェクトでコメントどうしようかな、と悩んでいる方には、ひとつの現実的な解として参考になると思います。

。。.。。.。.

4本目。
タイトルは「【Google Antigravity】話題のAI IDEを使って、家庭菜園シミュレータを1日で爆誕させた話」。

これは、Googleが出しているエージェント型の開発環境「Antigravity」を使って、家庭菜園用のWebアプリ「Garden Planner」をほぼ1日で作った、という開発日記です。
このAntigravity、ざっくりいうと「要件をしっかり書いて渡すと、AIエージェントがプロジェクト初期化から実装、エラー修正までまとめて面倒を見てくれるIDE」みたいな位置づけなんですね。

今回のケースでは、Next.js、React、Zustand、@dnd-kitといった技術スタックを指定しつつ、「こういう画面構成で」「こういうUXで」「こういう型定義で」といった要件を、1つの長いプロンプトとして渡しています。するとAntigravity側が、依存パッケージの導入、型やコンポーネント、ストアの実装まで、どんどん自動生成してくれた、と。

とくに面白いのが、「コンパニオンプランツ」という機能。
家庭菜園で、隣り合う野菜の相性を判定して、マスの見た目を変える機能なんですが、これもプロンプトに書いておいた仕様どおりにしっかり実装されていたそうです。野菜のマスターデータもAIが自動生成し、途中で出た型エラーなんかも、エージェントが自律的に直してくれた、という体験が紹介されています。

筆者がそこから感じたのは、「実装を書く」という行為がどんどんAIの仕事になりつつある、ということ。
人間のエンジニアに求められるのは、ますます「要件を言語化する力」と「データ構造やドメインをちゃんと設計する力」になっていくんじゃないか、とまとめています。
「コードを書くスピード」より、「何を作るか」「どんな形のデータで持つか」を考える時間の価値が上がっていく。Antigravityは、その未来をちょっと先取りしたような開発体験を見せてくれるIDE、という印象です。フロントエンドやWebアプリ寄りの方にはワクワクする内容だと思います。

。。.。。.。.

そして最後、5本目。
タイトルは「AIを駆使して2D図面画像を2DCAD(ベクター)化する」。

これはガラッと変わって、製造業の現場のお話です。
機械図面の2D画像を、線や図形、寸法情報を認識した「2D CADのベクターデータ」に変換したい、というニーズに対して、生成AIと古典的な画像処理を組み合わせて挑んだ事例が紹介されています。

機械図面って、ぱっと見は線と円だけに見えるんですが、実はかなり難物でして。投影図が一部省略されていたり、会社独自のルールや記号があったり、線種もあいまいだったりして、機械的な解析がすごく難しい。既存のImage2CADやStarVectorといったツールも、汎用性や白黒図面での精度に課題があったそうです。

そこで著者は、まず生成AIを「物体検出」と「線種・形状分類」に使う、というアプローチを取ります。
投影図に写っている部品や領域をGeminiに検出させて、さらにNanobanana Proというモデルで線種ごとに色分け分類する。その結果をもとに、古典的な画像処理であるskeletonizeとDouglas-Peuckerアルゴリズムを使って線を抽出し、円についてはRANSACでフィッティングして、最終的にSVGとしてベクター化する、というワークフローを組み立てています。

現状の制約としては、「外形のみ」「円弧は簡略化」といった割り切りはあるものの、実際の図面で一定の精度を出せているとのこと。
メッセージとして強いのは、「この分野は、1つのAIモデルでなんとかしようとするより、複数のAIと従来技術を組み合わせるのが鍵だ」という点です。生成AIが得意なパターン認識とラベリングを前処理に使い、そのあと幾何処理やアルゴリズムで形をきちんと再現していく。このハイブリッドなやり方で、ようやく実務に耐えうる精度に近づいてきた、という感触が語られています。
記事の最後では、この領域で一緒に取り組む仲間も募集しているとのことで、製造業×AIに興味がある方には、かなり刺さる内容になっているんじゃないかなと思います。

。。.。。.。.

というわけで、今日は全部で5本の記事をご紹介しました。
仕様書とAIモデルの最適な組み合わせを探る話、FlutterのRiverpod 3への移行ガイド、DocComment中心のAIフレンドリーなドキュメント戦略、Google Antigravityで家庭菜園シミュレータを1日で作った話、そして2D図面をAIで2D CADにベクター化するチャレンジ。
どれも、「AI時代にどう開発していくか」「どう設計・仕様・ツールと向き合うか」という共通テーマが見えてきましたね。

気になった記事があれば、詳しい内容は番組のショーノートにまとめてありますので、そちらからぜひ本編も読んでみてください。
また、「zenncast」への感想や、取り上げてほしいテーマ・技術・Zennの記事なども、大歓迎で募集しています。マイク宛てに、ラジオネームを添えて送ってもらえると嬉しいです。

それでは今日はこのへんで。
お相手はマイクでした。
また次回の「zenncast」でお会いしましょう。おやすみなさーい。