どうも、zenncastパーソナリティのマイクです。
時刻は朝7時をちょっと回ったところ、2026年5月3日、日曜日の朝ですね。みなさん、いかがお過ごしでしょうか。洗濯回してる人も、これから寝る人も、お仕事向かってる人も、耳だけちょっと貸してください。
このzenncastでは、Zennで今トレンドになっている技術記事をピックアップして、エンジニアのみなさんと一緒にゆるっとキャッチアップしていく番組です。

今日はお便りコーナーはお休みです。そのぶん、記事紹介をガッツリいきたいと思います。

さてさて、きょう紹介する記事は全部で5本です。セキュリティ事件の解説から、AIによるセキュリティ診断、MCPの効率化、RailsとDDDの話、そしてNeovimアップデートの注意点まで、かなりバラエティ豊かです。順番にいってみましょう。

まず1本目。
タイトルは「マネーフォワードのGitHub不正アクセス事件をエンジニア視点で読み解く — なぜソースコードに本番カード情報と認証キーが入っていたのか」。
2026年5月に起きた、マネーフォワードのGitHub認証情報の漏えい事件を、感情論じゃなくて技術・運用の観点から丁寧に分解している記事です。
今回のインシデントでは、GitHubの認証情報が抜かれて、リポジトリのコピーからコード内に含まれていた「ビジネスカード」370件分の氏名とカード番号の下4桁、それから各種認証キーやパスワードが流出した可能性があると。幸い、本番DBやカード番号の全桁までは出ていないけれど、「ソースコードの中に本番のカード情報やシークレットが入っていた」という設計・運用自体がかなり重い問題だよね、という話になっています。
なんでそんなことが起きたのか、記事ではテスト用フィクスチャとか、トラブル調査用の本番データダンプを安易に流用しちゃったパターンなどを挙げていて、「やりがちだけど、本当は絶対やっちゃいけない線」を丁寧に指摘しています。
さらに、GitHubの認証情報の漏えい経路って、マルウェア、誤ってどこかにコミット、サードパーティからの連鎖、フィッシング……と、とにかくパターンが多くて「ゼロにする」のが難しい。だからこそ、「もし抜かれても、ソース以外は何も出ない状態」を目指すべきだと。
具体的には、gitleaksやTruffleHogみたいなシークレットスキャンをCIやpre-commitに組み込んだり、GitHubのSecret Scanningを使ったり、過去の履歴を含めて棚卸しして不要なキーをローテーション・削除したり。本番データをテストに持ち込まないためのマスキングや、専用のシークレット管理サービスへの移行、PATを減らしてOIDCやGitHub Appを使う、といった実践的な対策がいろいろ紹介されています。
初動対応としては、鍵を一括で無効化してローテーション、連携口座の一時停止、即日公表など「ここは評価できる」としつつ、今後は本番データが混ざった理由や鍵の種別、再発防止策をもっと透明に説明してほしい、という提言で締めくくられていました。自分たちの環境にもそのまま刺さる話なので、セキュリティ担当だけじゃなく全エンジニアが読んでおきたい内容ですね。

。。。。

続いて2本目。
タイトルは「【検出率100%】セキュリティ診断、Claude Codeに全部やらせる時代が来た」。
AIを使ったセキュリティ診断を、かなり本気でワークフローに落とし込んだ話です。著者の方が、自分で育ててきた「AIセキュリティ診断スキル」を、開発ライフサイクルに沿って3つに分解してOSSとして公開しています。
1つ目は、プルリクの差分をチェックする `/security-review`。これは変更差分だけを見て、信頼度0.8以上の問題だけ報告することで、偽陽性をがっつり下げる設計。2つ目は、リリース前に全体を見直す `/full-scan`。言語やフレームワークに依存せず、コード全体とライブラリのCVEをスキャンします。もし一部だけしかスキャンしてない場合は、「ここはまだ見てないよ」と明示してくれるのもポイント。3つ目は、デプロイ後の動的テスト用 `/security-scan`。ここまで役割を分けることで、「いつ・何を・どこまで」AIに診てもらうかがクリアになってます。
導入も、`gh skill install` 一行でOK、月0.8〜1.2ドルくらいのコストということで、既存のSAST/DASTツールやコンサルに頼むのと比べると、かなり安い。
すごいのが、テストハーネスを自作して、難度バラバラなフィクスチャを大量に流し込んで評価した結果、RecallもFalse Positiveも全カテゴリで100%だった、というところ。ただ、ここをちゃんと冷静に見ていて、「とはいえOWASP Top 10の全部をカバーできるわけじゃなくて、だいたい65〜70%くらい。ビジネスロジックのバグは、やっぱり人間のペンテストが必要」と正直に書いてあります。
メッセージとしては、「AIでカバーできるところは徹底的に自動化して、人間はビジネスロジックとか設計の判断みたいな、本質的なところに集中しよう」という提案ですね。AIの導入ってどうしても「置き換え」か「怖い」かの議論になりがちなんですけど、こうやってワークフローに組み込んでいく具体例は、かなり参考になると思います。

。。。。

3本目。
タイトルは「自作MCPサーバーのトークン消費を9割削減するTips ── MCPの退避パターン」。
MCP、最近触ってる人も多いと思いますが、「トークン食い過ぎ問題」に真正面から向き合った記事です。
自作のMCPサーバーって、ツールの引数や実行結果がそのままLLMとの会話コンテキストに乗るので、大きなファイルや大量のクエリ結果を扱うと、あっという間にトークン上限やレスポンス上限にぶつかっちゃうんですよね。この記事で紹介されている解決策はすごくシンプルで、「大きなデータをMCPの通信から外して、KeyとかURLだけを渡す」という“退避パターン”です。
具体例として、Sandbox MCPではソースコードをそのまま送るのをやめて、自前GitサーバーのリポジトリURLだけをMCP経由で返すように変更。実体のコードは普通にgit pushで反映する形にした、と。
もう一つはDB Graph MCP。これも、クエリ結果が多くなりそうなときには、自動でSpreadsheetにエクスポートしてしまって、そのURLとメタ情報だけをMCPに返すモードを実装。誤って「全件取得」しちゃっても、会話コンテキストがパンクしないようになっています。
こうした工夫を積み重ねた結果、全ツール合算でトークン使用量が70〜90%削減できた、というのがタイトルの「9割削減」の正体です。
さらに面白いのが、MCPの認証にGoogle WorkspaceのOAuthを使うパターン。これによって、ユーザーの権限でDriveとかSheetsを退避先として使えるので、別途サービスアカウントを管理する手間も減らせる。ただし、Spreadsheetの中身を読むには、別途Workspace操作用のMCPが必要なので、「DB Graph MCP → Spreadsheet出力 → Workspace MCPで読む」という構成がいいよ、という実戦的なノウハウも書かれていました。
大きいデータは外部に置いてKeyだけやり取りする、って、インフラの世界だと当たり前の設計なんですが、MCPでもちゃんとやると、コストも安定性も一気に良くなるよ、という話ですね。

。。。。

4本目の記事。
タイトルは「5年間のRails開発者がDDDに出会って考えが変わった話」。
これは、Railsで5年間開発してきたエンジニアが、Python＋FastAPIでDDDとクリーンアーキテクチャを経験して、「あれ、回りくどいと思ってたけど、これ結構いいぞ」と考えが変わっていくストーリーです。
Railsだと、どうしてもActiveRecordが中心になって、コントローラからサービス、モデルまで、レイヤー全体がDBに強く依存しがちですよね。スキーマの変更とビジネスルールの変更が同時に波及して、「どこからどこまでがビジネスの話で、どこからがインフラの都合なのか」が曖昧になりがち。さらに、Serviceオブジェクトにロジックがどんどん集まっていって、「とりあえずServiceに置いとくか」みたいな肥大化もありがちです。
それに対してDDDでは、Domainを中心に据えて依存関係を逆転させることで、「ビジネスの変更」と「永続化の変更」をレイヤーで分離できます。EntityやUseCase、Repositoryといったパーツごとに責務が明確で、「このロジックはどこに置くのが正しいんだっけ？」という迷いが減る。
さらに、Domain層がDB非依存なのでテストが爆速になる、というのも重要なポイント。DBを立ち上げなくてもビジネスルールを検証できるから、CIの時間も短くなった、と書かれています。
興味深いのが、「AI時代」の話。コードを書くコストよりも、「このコードは正しいのか？」を判断するコストの方が大きくなってきている中で、レイヤー分離がしっかりしていると、AIが生成したコードの意図を理解したりレビューしたりする判断コストが下がる、という指摘です。
とはいえ、「Railsがダメ、DDDが最強」という話ではなくて、Railsは立ち上がりの速さや学習コストの低さにすごく強みがある。一方でDDDやクリーンアーキテクチャを知っていると、プロジェクトごとに「今はどっち寄りがいいかな？」と選べるようになる。その選択肢を増やしてくれる記事になっていました。

。。。。

そして5本目。
タイトルは「Neovim 0.11 -> 0.12へアップデートする際の勘所とnvim-treesitterの扱い」。
Neovimユーザーにはめちゃくちゃ重要なやつです。0.11系から0.12系に上げるときに、特にnvim-treesitterまわりでハマりポイントがあるよ、という注意喚起ですね。
まず前提として、nvim-treesitterは、tree-sitterのparserとqueryのインストール・管理をするプラグインです。シンタックスハイライトとか構文ベースの折り畳みって、ソースコードをparserが木構造にして、それをqueryがどう解釈するかで決まっているんですね。
0.11までは、`require("nvim-treesitter.configs").setup` を前提に、ハイライトや折り畳みをnvim-treesitter経由で設定するスタイルが主流でした。それが0.12系では、ハイライトやfoldといった機能はNeovim本体側のTreesitter API――たとえば `vim.treesitter.start()` とか `vim.treesitter.foldexpr()`――を直接使う方針に変わってきています。つまり、nvim-treesitterの役割は「parserとqueryの管理」にキュッと縮小された形になっているわけです。
この変化に伴って、従来の設定のままだとエラーが頻発する可能性があります。「なんか0.12に上げたらtreesitterまわりで落ちるぞ？」みたいな現象ですね。さらに、parserやqueryのビルドには、tree-sitterのCLIが必要になったので、そこも環境構築のポイントとして押さえておく必要があります。
そしてもうひとつ衝撃だったのが、nvim-treesitterのGitHubリポジトリがアーカイブされた件。ただし記事では、「Neovim 0.12系ではtreesitter機能がかなり本体に移行しているので、現状そこまで慌てる必要はない」という落ち着いた見立ても紹介されています。
要するに、「0.12へ上げるときは、nvim-treesitterに全部おんぶにだっこ、という前提から、本体のTreesitter APIを使う構成に頭を切り替えましょう」というガイド記事になっていました。Neovim勢の方は、アップデート前に一度読んでおくと、朝からconfigと格闘する時間をかなり減らせると思います。

。。。。

というわけで、きょうのzenncastでは、
マネーフォワードのGitHub不正アクセス事件をエンジニア視点で解きほぐしたセキュリティ記事、
Claude Codeを使ってAIにセキュリティ診断をやらせるための3つのスキル設計、
自作MCPサーバーのトークン消費を9割削減する“退避パターン”、
Rails開発者がDDDとクリーンアーキテクチャに出会って考え方が変わった話、
そしてNeovim 0.11から0.12へのアップデートで気をつけたいnvim-treesitterまわりの勘所、
この5本を駆け足でご紹介しました。

気になった記事があれば、概要やキーワードはショーノートにまとめておきますので、あとでゆっくり原文もチェックしてみてください。
番組の感想や、「こんなテーマ取り上げてほしい」といったリクエストも大歓迎です。あなたの開発環境の話や、最近ハマった技術ネタなんかも、ぜひ教えてください。

それでは、そろそろお時間です。
きょうも聞いてくれてありがとうございました。次回のzenncastで、またお会いしましょう。
パーソナリティのマイクでした。ではでは、良い一日をお過ごしください。