どうもー、おはようございます。マイクです。
「zenncast」第……何回目かはさておき、2026年4月7日、火曜日の朝7時になりました。
この番組では、Zennで話題になっているトレンド記事を、ゆるっと楽しく紹介していきます。通勤・通学のお供に、作業しながら耳だけ貸してもらえたらうれしいです。
今日はリスナーのみなさんからのお便り紹介はお休みで、そのぶんガッツリ記事を追いかけていきたいと思います。
さて、今日ご紹介する記事は全部で5本です。
AI開発まわりの最前線から、セキュリティ、そして最新LLMのベンチマークまで、かなり濃いラインナップになってますよ。
まず1本目。
タイトルは「GitHub Copilot は自ら学ぶ: Copilot Memory 入門」。
GitHub Copilotが、ただその場その場で提案するだけじゃなくて、「記憶」を持ち始めているよ、という話です。ポイントは、メモリがどこに保存されて、どの範囲で共有されるのか、っていう整理がすごく丁寧にまとまっているところですね。
ローカルとクラウド、それからユーザー単位・リポジトリ単位・セッション単位みたいに、スコープごとに分類してくれていて、とくにGitHubクラウド側に保存される「Copilot Memory」が主役になっています。
このCopilot Memory、例えばプロジェクトのコーディング規約とか、よく出てくる設計パターンなんかを、自動で学んでくれるんですね。で、ただ覚えるだけじゃなくて、「subject」「fact」「citations」「reason」という構造で整理して保存しておく。使うときには、そのcitations、つまり「この知識の根拠になったコード」をリアルタイムに確認して、古くなってたらちゃんと捨ててくれる。
しかも28日間使われなかったメモリは消えるけど、使い続けているものは延命されるという、けっこう賢いライフサイクル設計になってます。
面白いのは、Code Reviewとか、Coding Agent、CLIみたいな、複数のCopilotエージェント間で、この知識が共有されていく構想が見えているところですね。一方で、VS Code側にはローカルなユーザー／リポジトリ／セッションメモリ、CLIにはSQLiteのセッションストアがあって、「ちょっとした自分用メモ」「作業ログ」としても使えるよ、という整理も入ってます。
筆者はまず、「自分のリポジトリでCopilot Memoryが有効になっているか確認しよう」と呼びかけていて、これからの「AIがプロジェクトを覚えていく」世界の入り口を、すごくわかりやすく案内してくれている記事でした。
。。.。。.。。.。.
続いて2本目。
タイトルは「AIがコードを書くほど、要件定義は上に移動する――Spec・Context・Harness三層設計」。
これはね、「AIにコードを書かせる時代に、人間の仕事はどこに残るのか？」っていう問いに、かなり真面目に答えている記事です。
基本的なスタンスは、「自動化されるのはHOWであって、WHATとWHYはますます人間の仕事になる」というもの。要は、AIが手を動かしてくれるぶん、「何を作るのか」「なぜそう作るのか」をちゃんと定義する要件定義が、もっと重要になっていくよ、という話ですね。
そのうえで、記事では3つのキーワードを出しています。
1つめが「Context Engineering」。AIに渡す仕様や情報を、「文脈」としてどう設計するか。
2つめが「Harness Engineering」。要件定義から非機能チェック、テストまでを一連のガードレールとして設計して、AIの暴走を防ぐ仕組みづくり。
3つめが「Humans on the Loop」。人間はコードを1行1行レビューするんじゃなくて、ループ全体の設計者として関わり続ける、という考え方ですね。
記事では、EARSという要件記述の記法や、Spec Kitみたいな仕様駆動開発ツール、コンテキストの分割方法、それから決定論的なチェックとLLM品質ゲートの組み合わせなど、かなり具体的なテクニックにも触れています。
ただ、「なんでもかんでもSDDやハーネスで固めればいいわけじゃない」という限界もちゃんと書かれていて、非機能要件やビジネス判断、超小さいタスクなんかは、過剰なプロセスを敷かないほうがいいよね、というバランス感覚も大事にしている。
AIと一緒に開発を進めるうえで、「ワークフローを設計する人」としてのエンジニア像が、だんだん見えてくるような内容でした。
。。.。。.。。.。.
3本目は、かなりタイムリーなセキュリティの話題です。
タイトルは「【実験あり】axios攻撃は2行で防げる｜.npmrc設定とignore-scriptsの注意点」。
2026年3月末にあった、axiosのサプライチェーン攻撃を題材にしています。axios自体じゃなくて、その依存パッケージのpostinstallスクリプトにRATが仕込まれていた、というかなりいやらしい攻撃でした。しかも、axiosを直接使っていない人や、自動更新にしてた環境も、巻き込まれ得たという……。
この記事の面白いところは、「でも実は ~/.npmrc に2行、どちらか片方を仕込んでおけば防げたよ」という検証をしているところです。
1つは「ignore-scripts=true」。これを入れると、npm installのときにpostinstallスクリプトをそもそも実行しなくなる。
もう1つは「min-release-age=3」。公開から3日経ってないバージョンはインストール対象から外す、という設定です。今回の攻撃のように、数時間〜短時間で削除されるマルウェアにはかなり効くんですね。
もちろん、副作用もあって、ignore-scriptsを入れると、postinstallに依存している正規のパッケージが動かなくなることがあります。その場合は、信頼できるパッケージだけ個別にnpm rebuildしてあげる、という運用が必要になる。min-release-ageはnpm 11.10.0以降でしか使えないので、古いnpmを使っている場合はアップデート必須です。
さらに、package.jsonのキャレットを外して自動アップデートを抑えるとか、開発ツールの自動更新をなるべく切る、といった追加対策も紹介されています。ただし、長期潜伏型の攻撃とか、メンテナー本人が悪意を持ったケースには効かないので、「完璧な防御」ではなく、防御層を一つ増やしてリスクをかなり減らすための現実解として提案されています。
フロントエンド・Node界隈の方は、一度自分の .npmrc を見直してみるきっかけになりそうな記事でした。
。。.。。.。。.。.
4本目。
タイトルは「個人的GitHub Copilotの使い方メモ：VS Code・CLI・Cloud・Review・Spaces（2026/4時点）」。
これは、GitHub Copilotをかなりヘビーに使っている筆者が、自分なりの「ベストプラクティス」を全部書き出したようなメモです。
今のCopilotって、単なる補完やチャットにとどまらず、VS Code、CLI、クラウドエージェント、Code Review、Spacesまで含めたエコシステムになっているんですよね。その全体像を俯瞰しながら、「どう組み合わせて使うと一番お得か？」という視点で整理されています。
キーワードは「プレミアムリクエスト前提で、1回の依頼で最後まで進める」という使い方。細かい質問を連発するんじゃなくて、「ここからここまでまとめてやって」とタスクを塊で投げると、費用対効果も、結果の一貫性も高いよ、という話ですね。
VS Codeでは、エージェント／プラン／Askの使い分けや、ツール自動承認、セッション管理、Smart actions、ブラウザ連携など、実際の運用で効いてくるポイントを紹介。CLIは、とにかく速さを活かして、/research や /chronicle、/fleet、autopilotあたりをフル活用しているそうです。
クラウドエージェントは、GitHub上だけでブランチ作成からPRまで完結できるので、「ローカル触れないときに非同期で進める」みたいな使い方が便利。
チーム向けには、ノイズが減ったCopilot Code Reviewと、共有可能でアップデートし続けられるCopilot Spacesを推していて、Spaceの分割の仕方や、インストラクションの書き方の具体例も出てきます。
さらに踏み込んだ話として、カスタムインストラクションやSkills、カスタムエージェント、Hooks、MCPサーバーといった高度なカスタマイズの話も触れていて、自分のVS Code設定や自作スキルの例を挙げながら、「ここから先もっと広げていきたい」と締めています。
「Copilot、コード補完しか使ってないな〜」という人が読むと、「え、そんなことまでできるの？」と視野が広がる内容になっていました。
。。.。。.。。.。.
そしてラスト、5本目。
タイトルは「Gemma 4 vs Qwen 3.5 — DGX Spark × llama.cpp でMoEモデル対決ベンチマーク」。
こちらは、GoogleのMoEモデル「Gemma 4」と、Qwen 3.5-35B-A3Bを、DGX Spark上でllama.cppを使ってガチ対決させたベンチマーク記事です。
両方とも、「有効パラメータ3〜4Bで、帯域がボトルネックになりがちな環境でも軽快に動く大きめモデル」という位置づけ。Denseモデルじゃなくて、Gemma 4の26B-A4Bを持ってきているのがポイントですね。
速度系のベンチでは、llama-benchの結果として、Qwenのほうがトークン生成速度で約2.2倍高速。さらにMXFP4量子化のおかげで、VRAM使用量もGemma F16の半分以下ということで、パフォーマンスとメモリ効率はQwen優勢、という評価です。
一方、日本語の常識推論データセット「JCommonsenseQA」では、Gemma 4 F16が96.51％、Qwen 3.5 MXFP4が96.16％と、ほぼ誤差レベル。量子化したGemma（Q4_K_M）との比較でも精度差はごく小さくて、少なくとも知識系の5択問題では、量子化の悪影響はほとんど見られなかったそうです。
面白いのが、「Thinkingモード」の検証。両モデルとも、JCQに関してはThinkingをオンにするとむしろ精度が落ちて、レイテンシは大幅増。さらに、llama.cppの特定バージョンでは、Gemma 4のThinkingが `<unused49>` を連発するバグでほぼ使えない、という実務上の注意点も挙がっています。
マルチモーダルのテストでは、画像理解＋JSON構造化抽出＋PPE（保護具）検出みたいなタスクで比較していて、どちらもJSONのパース率は100％とかなり優秀。品質はほぼ互角で、速度はケースバイケースで一長一短という結果でした。
総合すると、日本語テキスト品質とVLMの信頼性はほぼ同レベル。速度・メモリ効率はQwen 3.5に軍配、一方で商用ライセンスの自由度はApache 2.0のGemma 4が優位、という整理になっています。
「どっちを採用するか」は、ワークロードとライセンス要件次第、という現場目線の結論が気持ちいい記事でした。
。。.。。.。。.。.
そろそろお別れの時間です。
今日は、Copilotの「記憶」の話から、AI時代の要件定義、npmのセキュリティ設定、Copilot実践テク、そしてGemma 4とQwen 3.5のMoE対決まで、一気に5本ご紹介しました。
気になった記事があれば、詳しい内容や元記事へのリンクは、この番組のショーノートにまとめておきますので、あとでゆっくりチェックしてみてください。
「zenncast」では、番組の感想や、こんなテーマを取り上げてほしい、といったリクエストもいつでも募集しています。あなたの開発現場での悩みや気づきなんかも、ぜひ共有してもらえるとうれしいです。
それでは、今日も良い一日をお過ごしください。
お相手はマイクでした。また次回の「zenncast」でお会いしましょう。ではでは。