どうも、マイクです。おはようございます。
2025年11月30日、日曜日の朝7時になりました。
ここからの時間は「zenncast」、Zennのトレンド記事をゆるっと楽しく紹介していきます。コーヒー片手に、あるいはお布団の中で、そのまま耳だけ貸してもらえればうれしいです。

今日はリスナーのみなさんからのお便りはお休み、ということで、そのぶんガッツリとZennの記事を紹介していきたいと思います。

今日ご紹介する記事は、全部で5本です。
AIエージェントの実践ネタから、大規模モデルのインフラ構築、そしてAIを前提にした開発フローの話まで、かなり濃いラインナップになっていますよ。

まず1本目。タイトルは「Claude Code スキル・サブエージェント攻略ガイド」。
これは、Claude Codeを触っている人が一度はつまずきがちな、「スキル」と「サブエージェント」をどうやったら“ちゃんと動かせるか”を、かなり実践的に検証してくれているガイドです。
ポイントになっているのが、「SKILL.md をちゃんと書いていても、それだけじゃスキルは発動しない」というところ。実はSkillツール自体がデフォルトだと権限拒否されているので、コマンドで `--allowed-tools "Skill"` を付けるか、`.claude/settings.json` で許可してあげないと、そもそもスキルが効いてくれないんですね。
さらに、スキルは「常に勝手に効く暗黙のコンテキスト」ではなくて、「必要なときに呼び出されて初めて意味が出る」ものだ、という整理もされています。ここ勘違いしがちですよね。
一方でサブエージェントは、権限設定なしでも動いてくれるんですが、descriptionの文章に対して単純なマッチで発動しているので、そのままだと発動率が低い。そこで効いてくるのが「CLAUDE.md」。ここに「どんな発話のときに、どのエージェントやスキルを使うべきか」を、かなり具体的に書いておくと、システムプロンプトとして働いて、発動率がグッと上がるよ、という話です。
最終的なおすすめ構成としては、「ルールと起動条件は CLAUDE.md」、「具体的なタスクの中身はサブエージェント」、「複数エージェントで共有する知識はスキル」という役割分担に落ち着いた、というまとめになっています。Claude Codeを本格的にワークフローに組み込みたい人には、かなり効くノウハウなんじゃないかなと思いました。
。 。 。 。

続いて2本目。タイトルは「Go + クリーンアーキテクチャで AI エージェント基盤を再設計した話【前編】」。
これは、既存のバックエンドがGoで統一されているチームが、「LangChainみたいなフレームワークにガッツリ依存するのはつらいよね」という課題感から、Goで自前のAIエージェント基盤を作り直した、というストーリーです。
ポイントは、モデルやメモリ、ツール、エージェント、ストリーミングといった“変化の激しい部分”を、クリーンアーキテクチャに沿ってきれいに抽象化しているところ。`pkg/ai` というディレクトリに、Model、Memory、Tool、Agent、Streamingといったコアな概念を集約して、逆にOpenAI依存のコードは `pkg/ai/openai` に隔離する設計になっています。
以前は `/api/ai/chat` みたいな“1枚岩エンドポイント”の中に、OpenAI SDKの呼び出しからツール実装、SSEの扱いまで全部ベタっと書かれていて、テストも拡張もつらい構成だったそうなんですね。そこを、ModelFactoryやMemoryインターフェース、ToolRegistry、ReactAgentといったパーツに分解して、アプリケーション層は「これらを組み合わせるだけ」、プレゼンテーション層は「HTTPやSSEに専念」という役割分担にしています。
結果として、モデルの切り替えやツールの追加、メモリ実装の差し替え、ストリーミング方式の変更がかなりやりやすくなって、AIエージェント自体を1つのユニットとしてテストしやすい土台ができた、というわけです。後編ではDBやAPI設計、WorkflowやPlanner-Executor構成への拡張まで掘っていく予定とのことで、プロダクションでAIエージェントを運用している人には、続きもかなり気になる内容ですね。
。 。 。 。

3本目。タイトルは「2台のDGX Sparkを相互接続して無事にvLLMを動作させるまでのメモ」。
これはかなりハードウェア寄りの内容で、NVIDIAのDGX Sparkを2台、QSFP112ケーブルで直結して、vLLMで gpt-oss-120b をマルチノード・Tensor Parallelismで動かすまでの、リアルなメモがまとまっています。
まず物理接続のところで、「同じ位置のポート同士をつなぐとトラブルが減るよ」といった、地味だけど重要なポイントが書かれていて、その上で論理接続では、公式が推奨するリンクローカルIPではなく、netplanで固定IPを振って再起動時にIPが変わらないようにする、という運用寄りの工夫が紹介されています。
vLLMクラスタの構築では、`run_cluster.sh` を修正して、headノードのIPを明示的に指定したり、相互接続用インターフェースを UCX / NCCL / GLOO などの環境変数にきちんと指定することで、ノード間通信のエラーを防ぐ、といったハマりどころが共有されています。
さらに、gpt-ossを使うには vLLM 0.10.2 以上が必要なので、NGCの最新イメージ、例えば「25.11-py3」を使いましょう、というバージョン周りの注意点も。rayクラスタの状態確認では、ランダムなサフィックスが付いた“実際のコンテナ名”で `ray status` を叩く必要があるとか、`--tensor-parallel-size 2` で2台にまたいでモデルを分散するとか、かなり現場感のある情報がまとまっています。
初回起動時には約196GBのモデルダウンロードが走るので、そこは腰を据えて待つ必要があるものの、一度上がってしまえば、OpenAI互換APIとして利用できるところまで確認されている、というのが心強いですね。発売直後で情報が少ないDGX Sparkについて、実用的な手順を共有してくれている貴重な記事です。
。 。 。 。

4本目。タイトルは「AIコードレビュー「棚卸し」のススメ」。
AIにコードレビューをさせてみると、「コメントはたくさん出るんだけど、そのままPRに流すとカオスになる……」っていう経験、あると思います。誤った指摘や、優先度の低いコメントも混ざってしまって、人間側が「これは直す／これはスルーする」という仕分けにすごく時間を取られるんですよね。
この記事では、その仕分け作業を“最初からAIにやらせてしまおう”という発想が紹介されています。具体的には、まずAIにレビューさせるんじゃなくて、「AIが出したレビューコメントを、別のAIが棚卸しする」というレイヤーを挟みます。そこで各コメントについて、妥当性と対応方針を整理して、「MUST_FIX」「SHOULD_CONSIDER」「CAN_IGNORE」といったカテゴリに分類した一覧を生成してもらう。人間はその棚卸し結果を見て、「じゃあMUSTだけ対応しよう」とか、「SHOULDの中からコレとコレだけ優先しよう」と判断する流れです。
GitHub CLIを使うところも工夫されていて、単純な `gh comment` ではなく、`gh api` とGraphQLを組み合わせて“未解決レビューコメント”だけを取得したり、PRのタイトル・本文・diffから目的やスコープを理解したうえで評価させるカスタムコマンドを用意している、という具体例も出てきます。
リサーチ・計画・実装をセッションごとに分けて、「AIレビューをさらにAIでレビューする」構造を作ることで、人間は“判断に集中できる状態”を作る。そのおかげで、AIを導入したせいで逆に増えがちなレビュー負荷を、きちんとコントロールしようというアプローチが読みどころです。
。 。 。 。

そして5本目。タイトルは「Cursor・MCPを活用した画面刷新プロジェクトにおける開発サイクルと教訓」。
これはPKSHAのAIヘルプデスクのチャット画面をリニューアルしたプロジェクトで、CursorとMCPをフル活用して、「タスク起票から仕様参照、実装、PR、QA」までを一気通貫でAIに組み込んだ、という事例です。
LinearやNotion、Figma、GitHub、そしてブラウザのDevToolsをMCPでつないで、QAEやデザイナーが書いたチケットを、そのままAIの入力として使えるようにしているのが特徴。これによって、ソフトウェアエンジニアの役割は「チケットを解釈して実装に落とし込む」から、「AIが出してきた案を評価して、難しいところだけ手を入れる」方向にシフトしていきます。
さらに、Slash Commandを使って、PRの概要生成やlint修正、レビューの補助などを半自動化。フィードバック→修正のループを高速で回せるようになって、PRの品質も上がった、という効果が出ているそうです。
一方で、AIがまだ苦手なポイントもはっきりしていて、ビジュアルの細かい比較やCSSの細かな表現、ドキュメントに書かれていない“暗黙の仕様”の理解などは、人間側の綿密な指示と判断が欠かせない、と振り返られています。
成功のカギとして挙げられているのが、「背景と完了条件をきちんと明記したチケットによる“入力設計”」、「AIが一次情報に直接アクセスできるMCPの設計」、そして「反復作業をテンプレート化してしまうこと」。AIを単に“アシスタント”として足すのではなく、フロー自体を“AI前提”に再設計することで、スピードと品質を同時に高められた、というのが大きな学びになっていました。

というわけで、今日のzenncastは、
Claude Codeのスキル・サブエージェント活用術、
GoとクリーンアーキテクチャでのAIエージェント基盤再設計、
2台のDGX SparkでvLLMを動かすための実践メモ、
AIコードレビューをさらにAIで棚卸しするワークフロー、
そしてCursorとMCPで画面刷新プロジェクトをAI前提に組み替えた事例、
この5本をご紹介しました。

気になった記事があれば、番組のショーノートからぜひ本文もチェックしてみてください。ここではだいぶ駆け足でお話ししたので、細かい設定例や図解、実際のコマンドなんかは、ぜひ元記事で追いかけてもらえればと思います。

zenncastでは、番組の感想や、「こんなテーマを取り上げてほしい！」というリクエストも募集しています。開発の現場でのちょっとした悩みや、AIとの付き合い方など、マイクに聞いてほしいことがあれば、気軽に送ってください。

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