どうもー、おはようございます。「zenncast」パーソナリティのマイクです。
今日は2026年4月1日、水曜日の朝7時をちょっと回ったところです。エイプリルフールだけど、この番組は基本まじめに、でも楽しくお届けしていきますよ。
さて今日も、技術情報共有プラットフォーム Zenn から、いまホットなトレンド記事をピックアップしてご紹介していきます。

今日は全部で5本の記事を紹介していきます。どれもサプライチェーン攻撃とかAIエージェントとか、いま知っておきたい話ばかりなので、通勤・通学のお供に耳だけ貸してもらえればOKです。

まず1本目。タイトルは「【緊急】axios がサプライチェーン攻撃 2026.03.31」。
JavaScript / TypeScript界隈でおなじみのHTTPクライアント、axiosがやられちゃったという、かなりショッキングな出来事をまとめた記事です。2026年3月31日、リードメンテナのnpmアカウントが乗っ取られて、axiosの1.14.1と0.30.4がマルウェア入りで公開されてしまいました。しかもCI/CDを通さず、npm CLIから手動で公開されていて、直前に用意されていた怪しい依存パッケージ plain-crypto-js@4.2.1 が追加されていた、という流れ。
ポイントは「axios本体は改変されていない」こと。実際に悪さをするのは plain-crypto-js の postinstall スクリプトで、これがインストール時に動いて、クロスプラットフォームなRAT、つまり遠隔操作のためのドロッパーとして動作します。C2サーバの sfrclak.com に接続して、OSごとのペイロードを取りに行って実行、そのあと痕跡を消す、というかなり本格的な攻撃。
記事では、axiosやplain-crypto-jsを使っていないか、特定ファイルやC2通信がないかをチェックして、怪しい場合はマシンをネットワークから隔離してシークレットを総入れ替え、lockfileとnode_modulesを消してから、安全なバージョンの1.14.0や0.30.3に固定してクリーンインストールしよう、という具体的な対応が書かれています。さらに、CI/CDではlockfile前提のインストールにすることや、postinstallを無効化する、依存関係の変更を監視する、といった事前防御の話もセットでまとまっていて、「自分のプロジェクト大丈夫かな？」ってチェックするのにすごく役立つ内容になっていました。

。。。。

続いて2本目。タイトルは「サプライチェーン攻撃から身を守るために最低限設定しておきたいこと」。
さっきのaxiosだけじゃなくて、2026年3月だけでもTrivyやLiteLLMなど、いろんな人気プロジェクトがサプライチェーン攻撃を受けていて、「うちには関係ないでしょ」とはもう言えないよね、という前提から始まる記事です。一方で、最近の攻撃の8割は公開から1週間以内に見つかって削除されていて、「設定さえちゃんとしとけば、けっこう防げるよ」という現実的な話になっているのがいいところ。
紹介されている対策は大きく5つ。まず1つめは、npm や pnpm、Bun、uv などで min-release-age 的なクールダウン期間を設けて、「出たばかりの新バージョンはしばらく入れない」ようにすること。DependabotやRenovateにも同じ思想を入れて、数日から1週間寝かせてからアップデートする運用にする、と。
2つめはCI/CDでのインストールを「ロックファイル絶対主義」にすること。npm ci や --frozen-lockfile / --locked を使って、lockfileにない新バージョンは一切入らないようにして、axiosみたいな依存は overrides / resolutions で安全版にピン留めしておく。
3つめはインストールスクリプトの無効化。npm の ignore-scripts や、pnpm v10、Bunの設定で postinstall などを原則止めておいて、本当に必要なやつだけ個別に許可する。さっきのplain-crypto-jsのようにpostinstallが入口になるパターンへの、かなり効き目のある防御ですね。
4つめはGitHub Actionsのpinning。タグじゃなくてコミットSHAで固定して、pinact みたいなツールで自動変換とクールダウンを入れる。
最後5つめが Dependency Review Action の導入で、脆弱な依存がPRに入ってきたらCIを落として、ブランチ保護とセットでマージをブロックする。
どれも「やろうと思えば今日からできる」レベルの話なのに、防御効果としてはかなり高くて、「会社やチームのデフォルト設定として一気に入れよう」という気持ちにさせてくれる記事でした。

。。。。

3本目。ここから少し毛色が変わって言語設計の話です。タイトルは「Goにはなぜ例外がないのか」。
Goを書いている方ならおなじみ、「値, error」という多値返却のスタイルですね。この記事では、「なんで他の言語みたいに例外を採用しなかったの？」という疑問に対して、設計思想から丁寧に説明しています。
Cみたいに戻り値1つにエラーを紛れ込ませる方式でもなく、C++やJavaScriptのようなthrow / try-catch 方式でもない。その背景にあるのが、「例外は関数を読まないと発生有無がわからない」「致命的なバグから単なる入力エラーまで、全部同じチャンネルで飛んでくる」「そしてtry-catchでまとめて握りつぶされがち」という反省なんですよね。
Goの多値返却だと、関数シグネチャを見た瞬間に「ここはエラーが起こりうるんだな」というのが明示されます。さらに、本当にプログラムを止めるべき致命的なものは panic / recover に閉じ込めて、ドメインエラーとははっきり線を引く。
記事がおもしろいのは、「エラーは値」という思想から生まれるパターンを具体例で紹介しているところです。たとえば errWriter のような構造体に一時的にエラーを溜めておいて、最後にまとめて返すとか、errors.Join で複数のエラーを合成するとか。いわゆる if err != nil の連打だけじゃなくて、もう少しエレガントに扱うためのテクニックが色々出てきます。
また、公式FAQでも触れられている、「例外を制御構造と結びつけると、普通のエラーまで例外扱いになってコードが複雑化する」という問題意識も紹介されていて、「Goってこういう思想で作られてるんだ」と改めて腑に落ちる内容でした。普段Goを書いている人も、他言語メインの人も、言語デザインの観点で読むと発見があると思います。

。。。。

4本目はAIとセキュリティ運用の組み合わせの話。タイトルは「Ubieにおける一年間のセキュリティ分析AIエージェントの運用」。
医療テックのUbieさんが、セキュリティアラート対応の負荷を下げるために、自社で1年以上まわしてきたAIエージェント「Warren」の事例を紹介しています。
このWarren、Claude系のモデルにBigQuery、EDR、Slack、GitHubなどの情報源へのアクセス権を与えていて、いろんなログを一気にクロス解析して、「これは誤検知っぽい」「これはちゃんと人間が見るべき」といった判断をかなり高速・高精度でやってくれる存在。人間側はその結果を確認して、必要なら追加調査というスタイルにできるので、いわゆるアラート疲れが軽減される、というのが導入の狙いです。
面白いのは、単に「AIにやらせました」ではなくて、AI特有のクセへの対処が詳しく書かれているところ。たとえば、AIが「上司に怒られない答え」を忖度してしまったり、最初に立てた仮説に固執してしまったりするのを防ぐために、リスク評価のスタンスや推論ルールをシステムプロンプト側でかなり細かく規定しているそうです。社内のコンテキストやログの構造、よくある検索パターンなんかも全部プロンプトに落として、「この会社での正しい振る舞い」を叩き込んでいるイメージですね。
一方で、False Positiveのパターン管理、過去事例の記憶の仕方、モデル利用コスト、本当にステルスな攻撃への対応など、まだまだ課題も残っていると正直に書かれていて、「魔法の杖ではないけど、運用を変えるだけのポテンシャルはある」というバランス感が伝わってきます。
最後は、生成AIでセキュリティ運用や脅威モデリングをもっと民主化していこう、という呼びかけで締められていて、「自分たちの組織でも小さく真似してみようかな」と背中を押してくれる記事でした。

。。。。

ラスト、5本目。タイトルは「完全自律のコーディングパイプラインを作った」。
最近よく聞く「自律型コーディングエージェント」を、巨大企業の専用ソリューションじゃなくて、手元の環境で再現してみた、というチャレンジングな内容です。中心に据えているのは Claude Code をはじめとした既存のツール群と、自作のCLI「Rigg」。これを組み合わせて、「小さなワークフロー」と、それらを制御する親エージェントの二層構造を作っています。
YAMLで「このステージではコード生成して、formatして、testして、typecheckして…」という小さなワークフローを定義しておいて、それを親エージェントが、「どのステージをいつ走らせるか」「どこでループさせるか」「どのタイミングで人間にレビューを頼むか」といった意図決定のレイヤーからコントロールするイメージですね。
ポイントは、自然言語プロンプトだけに頼らないところ。「必ずtypecheckを通す」「静的解析のfindingsがゼロになるまで止めない」みたいなルールを、ワークフローとして強制しているので、モデルが気まぐれでステップを飛ばしたりしづらくなっています。また、ステージごとにコンテキストを明示的に分けて、依存関係も管理することで、「1回は上手く行ったけど、次はなぜか壊れた」みたいな不安定さを減らしている。
さらに、このパイプラインではUXデザインから計画、実装、レビュー、リファクタまで、5つのステージを基本フル自動で回す設計になっていて、そのためにRiggが「エージェント＋shellコマンド」のマルチステップをYAML一つで扱えるようにしています。
著者が強調しているのは、「一番むずかしいのはツール作りじゃなくて、自分たちのコードベースにとってちょうどいいワークフロー設計だ」という点。実運用の中で「このチェックいらないね」「ここはもっと厳しくしよう」といった調整を延々と続けていく必要があると語られていて、「AIで開発自動化」という夢を、かなり現実的な目線で捉え直してくれる記事になっていました。

。。。。

というわけで今日は、
1本目「axiosのサプライチェーン攻撃の緊急レポート」、
2本目「サプライチェーン攻撃から守るための、最低限の設定集」、
3本目「Goに例外がない理由と、エラーを値として扱う設計思想」、
4本目「Ubieにおけるセキュリティ分析AIエージェント『Warren』の一年運用」、
5本目「完全自律のコーディングパイプラインをローカルで構築した事例」
この5本を駆け足でご紹介しました。

気になった記事があれば、詳しい内容やキーワードは番組のショーノートにまとめておくので、あとでゆっくりチェックしてみてください。
「zenncast」では、番組の感想や、こんなテーマを取り上げてほしいといったリクエストも大歓迎です。仕事の愚痴でも、推し言語の自慢でもOKなので、ぜひ気軽に送ってください。

それでは、そろそろお別れの時間です。
今日も一日、無理しすぎず、ほどよくがんばっていきましょう。
お相手はマイクでした。また次回の「zenncast」でお会いしましょう。ではではー。