どうも、マイクです。おはようございます。
2026年4月28日、火曜日の朝7時をまわりました。「zenncast」今日も元気にお届けしていきます。
この時間は、Zennで今トレンドになっている記事をピックアップして、みなさんと一緒にチェックしていきます。

今日はお便りコーナーはお休みで、そのぶんガッツリと記事を紹介していきますよ。
さて今日は、全部で5本の記事をご紹介します。技術寄りのディープな話から、AIエージェント、セキュリティ、そしてAIとの付き合い方まで、かなり濃いラインナップになっています。

まず1本目。タイトルは「Matz の Ruby AOT コンパイラ Spinel を試してみました」。
RubyKaigi 2026 で発表された、Matz本人が作っている実験的なRubyのAOTコンパイラ「Spinel」を実際に触ってみたレポート記事です。Spinelは、PrismでRubyのコードをパースしてASTにして、そこから型推論をしてCを出して、最終的にネイティブバイナリにしてしまうという、かなりチャレンジングなコンパイラ。しかもself-hosting構成というロマンたっぷりなやつですね。
ただ、Railsをそのまま高速化、みたいな用途ではなくて、Rubyのサブセットで書いた小さなCLIとかヘルパーツール向き、というポジション。筆者の方は、RubyKaigi 2026のスケジュールを素材にした「セッションプランナCLI」をSpinelでビルドして、CRubyで動かした結果と、Spinelが吐き出したバイナリの出力がちゃんと一致するところまで確認しています。
面白いのが、「コンパイラが追いかけやすいRuby」をかなり意識して書いている点で、Hashの乱用や `nil` とオブジェクトの混在、メタプロを避けて、クラスと配列、インデックス管理で素直に表現していくスタイルに寄せているんですね。その一方で、Prismのパス推定が外れてハマったり、self-hostのブートストラップに失敗したり、生成されたCコードの型が崩れてSEGVしたりと、開発版ならではの“沼ポイント”も具体的に書かれています。
制約としては `eval` や `send`、スレッドがまだ使えないなど、READMEにある縛りも整理されていて、「今の段階だと小さなCLIとかCIのヘルパー、AI Coding Agentから呼び出すバイナリに向いていそう」という現実的な見立てもいい感じです。
そしてラストが熱くて、「MatzがAIをフル活用して、数週間、数回の総作り直しでここまで仕上げてきた」という事実にめちゃくちゃ衝撃を受けたと。強い開発者がAIを武器にすると、低レイヤの開発の探索速度が一気に上がるんだな、という好例として語られています。Ruby好き、コンパイラ好き、そしてAI×開発の未来が気になる人は要チェックの一本です。。。。

続いて2本目。タイトルは「AIエージェントにユーザーを演じさせて業務をテストする」。
これはビズリーチのAI Product Studioがやっている「Agentic UAT」という取り組みの紹介記事です。UAT、いわゆるユーザー受け入れテストを、AIエージェントに“ユーザー役を演じさせて”自動でやらせてみる、というコンセプトですね。
従来の単体テスト、結合テスト、E2Eテストって、基本的には実装者の視点で「想定した手順どおりならちゃんと動くか」を見るものですけど、UATは「エンドユーザーが業務として、迷わずちゃんと使えるか」という視点。そのUATをAIにやらせてしまおう、というのが面白いところです。
仕組みとしては、まず業務フローを定義して、それをもとに複数のペルソナを持ったAIエージェントを起動します。彼らには、ソースコードも仕様書も見せないで、「ブラウザ操作だけOK」「与えるのは業務ゴールだけ」という制約をかける。で、そこからUIをポチポチさせて、ちゃんと業務が完遂できるのか、どこで迷うのか、どんなエラーに出会うのか、という行動ログを記録して、Critical／Major／Minorでレポート化してくれるんですね。
実験のなかでは、E2Eテストでは検出できなかった「そもそもステータス変更UIが見つからない」といった、“使ってみないと気づかない”系の問題を自動で拾えたという報告もあります。ただしこの記事、すごくバランス感覚がよくて、「じゃあ人間のUATやユーザビリティテストが要らなくなるのか？」というと、全然そんなことはないと。美的なところ、ちょっとした使いにくさ、業界特有の“暗黙の了解”みたいなものは、AIだけでは判定が難しい。
なので、Agentic UATはAI駆動開発における「縦のガードレール」のひとつとして、PR前とかマイルストーン時の早期検証に差し込む補完的な存在、という位置づけをしています。今後は、誤操作のリスクを検知するみたいな方向にも広げていきたい、という話もあって、「AIにユーザーを演じさせる」という発想が、プロダクト品質の担保にどう効いてくるか、かなりワクワクする内容でした。。。。

3本目。タイトルは「春休みなので脆弱性報告したらCVEついた話 (CVE-2026-32309)」。
著者は就活中の学生さんで、OSSへのコントリビュートの代わりに「非公開でできる貢献」として、脆弱性報告にチャレンジした体験談です。対象になったのはCryptomatorというツールで、見事にCVE-2026-32309を獲得したお話。
具体的には、Hub経由で鍵を取得する処理を読んでいったところ、vaultメタデータに書かれたHubエンドポイントURLに対して、スキームやオリジン、それらの整合性チェックがまったく入っていなかった。しかもHTTPスキームも“正規”として許可されていた、という問題が見つかります。その結果、悪意のあるvaultをユーザーに開かせると、OAuthの認可やbearer token、デバイス登録、APIアクセスといったセンシティブな処理が、攻撃者が用意したHTTPエンドポイントや別オリジンに誘導されてしまう可能性があった、と。設計レベルでの大きな穴ですね。
修正としては、`hub+http` スキームの削除とHTTPSの強制、さらには各エンドポイントの同一オリジンチェックなどが行われて、バージョン1.19.1で対応が入ったそうです。記事の中では、報告時に工夫したこと、たとえば影響範囲をちゃんと洗い出して整理することとか、再現手順をできるだけ簡潔にまとめることとか、そのあたりが丁寧に書かれています。
結果として、開発側も迅速に対応してくれて、「自分の報告がちゃんと取り扱われて、現実のプロダクトをより安全にした」という成功体験につながった、と振り返っていて、読んでいてこちらも嬉しくなる内容です。セキュリティに興味がある人、英語での実務コミュニケーションに挑戦したい人には、かなり勇気をもらえる記事ですね。著者は、これをきっかけに今後もセキュリティと英語の勉強を続けていきたい、と締めくくっています。。。。

4本目。タイトルは「CAMPFIRE 22.5万人情報漏えい — GitHub不正アクセスから何を学ぶか」。
これはちょっと重たい話題ですが、とても大事な内容です。クラウドファンディングのCAMPFIREで、最大22万5846人分の個人情報が漏えいした可能性がある、というインシデントの解説と教訓をまとめた記事になっています。
きっかけは4月2日に発生したGitHubアカウントの不正アクセス。そこからソースコードに含まれていた認証情報が悪用されて、顧客情報管理システムやDBにまで侵害が広がったと見られています。対象となった情報には、プロジェクト実行者の氏名・住所・口座情報、支援者の住所・口座情報、一部ユーザーの氏名などが含まれていて、クレジットカード情報は含まれていないものの、かなり重い事案です。
ポイントとして語られているのが、初報から約3週間で「被害想定人数が大きく膨らんだ」というところ。これは、インシデント初動の見立てがどれだけ不確かで、甘く見積もると危ないか、という教訓になっています。背景には、Classic PAT（Personal Access Token）の権限が広すぎること、それからリポジトリの中にインフラ設計資料、DBマイグレーション、CIの設定、過去コミットに紛れた秘密情報など、インフラの“地図と鍵束”が全部入りしている状況がある、と。つまり「ソースコードを見られた」というのは、もはや「インフラ全体を丸裸にされた」に近い意味を持ってしまうわけですね。
この記事では具体的な対策もかなり細かく書かれていて、Classic PATの廃止とFine-grained PATやGitHub Appsへの移行、OIDC連携でクラウドの長期キーをなくすこと、Secret Scanningやプッシュ保護の有効化、2FAやSSO、IP制限の徹底、サードパーティ連携の棚卸しなどがズラッと挙がっています。そして何より、「ソースコード閲覧」が起きたと判明した瞬間に、“DB侵害前提”で24時間以内にトークンの総ローテーションと監査ログの洗い出しをやるべき、という強いメッセージも。
CAMPFIREは過去にも情報漏えいを起こしていて、「対策をやっている」と「対策をやり切れている」のギャップ、それから段階的な情報公開がかえって利用者の不安を大きくしてしまうリスクなどにも触れています。開発者だけでなく、プロダクトマネージャーや経営層も、一度は読んでおきたい内容だと思いました。。。。

そしてラスト5本目。タイトルは「Claude Codeと作ったAIオーケストレータを、私はなぜ使わなくなったのか」。
これはAIエージェントとの付き合い方、運用のリアルを振り返った記事です。筆者の方は、ClaudeとCodexを役割分担して使うために、「dark-part-time-job」という汎用オーケストレータを自作して、実戦投入までしていました。tmux上で“監督者”と複数の“worker”を立ち上げて、セッションやgit worktreeを分けながら、タスクをYAML化して、レポートまで自動生成する、というかなり本格的な仕組みです。
これによって、あちこちで起きがちなコンテキストの混線や、「このタスクどこまで進んでたっけ？」みたいな見通しの悪さは、かなり解消されたそうなんですね。ただ、並列化や役割分担をどんどん進めていくほど、「仕組みそのものの保守」が新しいボトルネックになってきた。具体的には、tmuxセッションの起動やキュー管理、レポートの競合解消、どんどん巨大化していくプロンプトの管理など、運用側の負担が増えていく。さらに、最初に設計したプロンプトが、時間とともにどんどん陳腐化していく問題も出てきます。
そこに追い打ちをかけるように、Claude Code側でAgent Teamsとかsubagent／skillsといった機能が出てきて、さらにOpenAI側からはClaude Code→Codexを呼び出せる仕掛けが整っていく。気づけば、「自作オーケストレータで頑張っていたことの多くが、ツール側にどんどん組み込まれていった」という状況になったわけです。
この経験から筆者が学んだのは、「外側に大きな司令塔システムを構えるより、人間が把握できるサイズで、LLMとスクリプトの境界や状態管理、レビューの設計をちゃんと切り分けておいたほうが、現実的で運用しやすい」ということ。dark-part-time-job自体は“役目を終えた”けれど、AIエージェント運用の知見をたくさんくれた、すごく価値のある実験だった、と前向きに振り返っています。
AIのワークフローを自動化したくて、つい“壮大な仕組み”を作りたくなる方、多いと思うんですが、「どこまでをシステムに任せて、どこからを人間の目で見るか」という境界設計のヒントになる記事だと思います。

というわけで、今日は5本ご紹介しました。
1本目は、MatzのRuby AOTコンパイラSpinelを実際に動かしてみた体験記。
2本目は、AIエージェントにユーザーを演じさせる「Agentic UAT」で業務テストをする話。
3本目は、学生さんがCryptomatorの脆弱性を報告してCVEを獲得した体験談。
4本目は、CAMPFIREの情報漏えいからGitHub不正アクセス時に何をすべきかを学ぶ記事。
そして5本目は、自作AIオーケストレータを卒業して見えてきた、AIとの付き合い方の教訓でした。

気になった記事があれば、詳しい内容は番組のショーノートにまとめてありますので、そちらからぜひ原文も読んでみてください。
「zenncast」では、番組の感想や、取り上げてほしいテーマ、Zennで見つけたおすすめ記事など、みなさんからのメッセージもお待ちしています。

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