どうも、マイクです。おはようございます。
4月6日、月曜日の朝7時になりました。「zenncast」今日も元気に始めていきましょう。
この番組では、エンジニアの皆さんの朝のお供に、Zennで話題になっているトレンド記事をゆるっと、でも中身はしっかりめにご紹介していきます。

今日はお便りコーナーはお休みで、そのぶん記事紹介たっぷりめでいきたいと思います。

さて、今日ご紹介する記事は全部で5本です。
AIエージェントの並列処理、ローカルLLM、インフラIaC、Reactアーキテクチャ、RAG最適化と、かなり技術寄りで濃いラインナップになってますよ。

まず1本目。
タイトルは「GitHub Copilot CLI の /fleet が面白い」。
これはGitHub Copilot CLIに入っている「/fleet」っていう機能のお話です。ざっくり言うと、「大きなタスクをAIが自動で細かい仕事に分解して、複数のサブエージェントで並列に片付けていく仕組み」。それぞれのサブエージェントは独立したコンテキストを持ってるんだけど、同じファイルシステムは共有している、というちょっと面白い構造になっています。ただしファイルロックがないので、「同じファイルを複数のトラックに触らせない」っていう設計が超重要。記事では、この /fleet を活かすための「仕事の切り方」がかなり具体的に整理されています。たとえば、成果物を最初からできるだけ具体的に言語化しておくこと、ディレクトリやファイル境界できちんとタスクを分けること、依存関係はプロンプトにちゃんと書いておくこと、さらに検証条件や制約も提示しておくこと。逆に、曖昧な依頼とか、どうしても直列にしか進められないタスクには向いていない、と。plan modeやautopilotと組み合わせて、PRのプレフライトチェックや、設計班と実装班をAIで分ける運用、モノレポ全体の横断チェック、ドキュメント専用エージェントなど、実用的なユースケースも紹介されています。サブエージェントごとに別モデルとしてリクエストが飛ぶので、プレミアムリクエストの消費が増える可能性がある点もちゃんと触れられていて、「賢く並列化しつつ、コストもモニタリングする」という現実的な視点がいい感じの記事です。

。。。。

続いて2本目。
タイトルは「DGX SparkでGemma 4 31Bをローカル動作させ、OpenClawから使う」。
これはかなり筋肉質な記事ですね。Googleのオープンウェイトモデル、Gemma 4 31B instructをNVIDIAのDGX Spark上で動かして、自作のOpenClawサンドボックス「suisou」を経由してDiscordから使う、という構成です。モデルのホスティングにはllama.cppのサーバーモードを使っていて、GGUFの量子化モデルを用意して、`q8_0`でKVキャッシュも量子化しつつ、256Kコンテキスト、reasoning budget 8192、というかなり攻めた設定で起動しているようです。その上で、suisou側ではmitmproxyベースのルーター設定をいじって、`host.docker.internal`向けのHTTPを許可し、OpenClawの設定ファイルからはbaseUrlをllama.cppサーバーに向ける。contextWindowやmaxTokens、さらに`reasoning: true`みたいなオプションも指定して、DiscordからローカルLLMに指示を飛ばせるようにしています。面白いのが、Discord経由でGemma 4に「llama.cppのGemma 4対応状況をレポートして」と頼んだら、それっぽいレポートを返してきたものの、指定したパスには実際には何もファイルができていなかった、という話。つまり、表面上はもっともらしいけれど、挙動の信頼性にはまだ注意が必要だよね、という教訓つきです。性能面では、「悪くはないけど、パラメータ数の割に遅く感じる」という評価で、同じDGX Spark上だとnemotron-2-cascadeの方が精度と速度のバランスが良い印象とのこと。とはいえ、DGX Sparkとsuisouを組み合わせることで、外部サービスに一切依存せず、完全ローカルでOpenClawエージェントを運用できる、というのはセキュリティ的にも大きな価値がある、というまとめになっています。クラウド依存を減らしたいチームや、機密データを扱う現場には参考になりそうな構成です。

。。。。

3本目。
タイトルは「脱CDKしてTerraformに移行すべきn個の理由(または私はなぜCDKをやめたか)」。
インフラエンジニアの方は耳が痛いか、心強いか、どちらかの話かもしれません。筆者は、AWS CDKよりTerraformを推す立場で、運用目線で両者を比較しています。CDKはTypeScriptなどの汎用言語からCloudFormationテンプレートを生成するツールなので、抽象度は高いんですが、`cdk diff`で比較できるのはあくまでCFnテンプレート同士。実際のリソースとのドリフト検知や、差分の可視化という点では弱い、と指摘しています。一方でTerraformは、`plan`が常に「実際のクラウド上のリソース」と「stateファイル」を比較する仕組みになっているので、ドリフトの検出や解消がしやすい。さらに、HCLの表現力があえて制約されているおかげで、「未来の自分やチームが読むときにも、あまりトリッキーにならないコードになりやすい」という長期保守のしやすさもメリットとして挙げられています。マルチクラウドやSaaSの一元管理、ポリシー連携、リソース単位の操作性などもTerraformの強み。ただし、state管理のめんどくささや、providerアップグレードのしんどさ、巨大モジュールが硬直化していく問題、そしてAWSの高レベル抽象はCDKほどリッチじゃない、といったデメリットもちゃんと並べられていて、単なるアンチCDK記事ではないのが良いところです。結論としては、「AWS限定・小規模チーム・短命プロダクト・シンプル構成」みたいな条件ならCDKも十分アリだけれど、それ以外、多くのパターンではTerraformを推奨。脱CDKのやり方としては、Terraformの`import`機能を使って段階的に移行するという現実的なルートも解説されています。いまCDKで運用していて、モヤモヤしている人には刺さりそうな内容ですね。

。。。。

4本目。
タイトルは「React の Container/Presentational × Hooks を関数型アーキテクチャで再設計する」。
Reactの設計パターンを、関数型アーキテクチャの観点からきっちり整理し直した記事です。よくあるContainer/Presentationalパターンを、Functional Core / Imperative Shellという考え方に対応させて、「副作用の境界」をはっきりさせよう、という主張になっています。具体的には、副作用のない純粋関数の塊を「関数型コア」としてまとめ、API呼び出しや状態管理など副作用を伴う部分をContainer、そしてUI描画だけに責務を絞ったコンポーネントをPresentationalとして分離する、という整理です。ロジックは関数型コアとしてファイル分割し、Hooksは「状態や副作用を伴う共通処理のカプセル化」に限定して使う。これによって、関数型コアとPresentationalはモックなしで高速な単体テストが書きやすくなり、Container部分だけに必要最低限の結合テストを当てるという、テスト戦略がかなりクリアになります。さらに、親Containerから子Containerを構成して、関心事を小さく閉じ込めていく設計や、高階関数やStrategyパターン的な組み立てで、たとえば「ソートとページネーション」のような協調が必要な機能を親側に集約するパターンも紹介されています。一方で、「これが唯一の正解です」という話ではなくて、テスト容易性をどこまで重視するか、チームメンバーのスキルセットやプロダクトの規模によっては、もっとHooks中心のシンプルな設計が合う場合もある、と柔らかくまとめているのも印象的です。関数型っぽいアプローチに興味があるReactエンジニアには、設計のリファレンスとして良さそうな記事になっています。

。。。。

そして5本目。
タイトルは「RAGの最適化手法が多すぎて迷子になったので、整理したら全体像が見えた」。
RAGやってる人「それな…」ってうなずきそうなタイトルですね。筆者はRAG関連の教材をいろいろ触る中で、最適化テクニックがあまりに多くて混乱した経験から、「結局どこをいじっている手法なのか」という観点で整理し直しています。軸は2つ。「検索に投げるクエリを賢くする」と「返ってきた結果を賢く絞る」。前者の「クエリを賢くする」側には、Multi Query、RAG-Fusion、Decomposition、Step Back、HyDEなど、ユーザーの質問を検索向きに言い換えたり、仮の回答を一度生成してから検索に使う、といった手法が並びます。後者の「結果を賢く絞る」側には、Re-ranking、ルーティング、混合検索などがあり、まずは粗めのベクトル検索で候補を集めてから、より高精度なモデルで再スコアリングしたり、SQLやWeb検索と使い分けたり、BM25と組み合わせて固有名詞や数字に強くする、といった工夫が紹介されています。さらに、RAPTOR、ColBERT、CRAG、Self-RAGなど、論文レベルの高度なアプローチも登場しますが、小規模な開発やプロトタイピングではさすがにオーバーキルになりがち、という冷静な評価です。結論としては、「基本RAGに、混合検索とRe-rankingとルーティングを足す」あたりを優先して採用するのがコスパ良さそう、という提案になっています。ポイントは、LLMを「なんでも答える黒魔術」ではなく、クエリ変換・評価・要約などを担う複数の部品としてパイプラインに組み込むこと。どこにLLMを差し込むかを意識すると、RAGの全体像がかなりスッキリ見えてくるよ、という内容でした。

というわけで、今日のzenncastでは、
GitHub Copilot CLIの/fleetでAIエージェントを並列に走らせる話、
DGX Spark上でGemma 4 31Bをllama.cpp経由でDiscordから触るローカルLLM構成、
CDKとTerraformを運用目線で比較して「脱CDK」をどう進めるか、
ReactのContainer/PresentationalとHooksを関数型アーキテクチャで再設計する話、
そしてRAGの最適化手法を2つの軸で整理して全体像を掴む、
この5本をご紹介しました。

気になる記事があった方は、詳しい内容やリンクはショーノートにまとめてありますので、そちらから元記事をぜひチェックしてみてください。
番組の感想や、「このテーマもっと深掘りしてほしい！」といったリクエストもいつでもお待ちしています。あなたの現場での工夫や失敗談なんかも、ぜひ教えてください。

それでは、そろそろお別れの時間です。
今日も良い一日をお過ごしください。
お相手はマイクでした。また次回の「zenncast」でお会いしましょう。