おはようございます。マイクです。今日もzenncastの時間がやってまいりました。
今日は2025年12月28日、日曜日の朝7時。朝の準備をしながら聴いてくださっている方も、夜勤明けでほっと一息ついている方も、どうぞ最後までお付き合いください。
このzenncastでは、エンジニアのみなさんに向けて、Zennのトレンド記事をゆるっと、でも中身はしっかりめにご紹介していきます。

今日は全部で5本の記事をご紹介していきます。セキュリティからAI、開発プロセス、メモツールまで、けっこうバラエティ豊かなラインナップなので、どこか一つは「これ自分のことだ…」ってなる話があると思いますよ。

ではさっそく、1本目からいきましょう。
1つ目は「【60億円流出】GitHub Token流出から始まったAPI改ざんとその対策」という記事です。タイトルからして胃がキュッとなるやつですね。
ステーキングプロバイダーで実際に起きた、60億円規模の資産流出インシデントを、続報ベースでかなり丁寧に分解してくれています。ポイントは「一発の致命的なゼロデイ」じゃなくて、「ごくありがちなGitHub Access Token漏洩」から、じわじわ侵入されていったこと。
流れとしては、まず漏れたトークンでIaCリポジトリにアクセスされて、ブランチの作成・削除をトリガーにCIを悪用。そこからCI環境にあるAWSやGCPのクレデンシャルを盗られて、本番Kubernetesに侵入され、実行中コンテナにペイロードを注入。iptablesやeBPFでネットワークを書き換えてAPIレスポンスを改ざんし、ユーザーに「普通のトランザクション」に見えるように細工した上で、実は資産引き出し権限を奪うトランザクションに署名させていた、というかなりえげつないシナリオです。
この記事がいいのは、「怖かったですね」で終わらず、対策を三層構造で整理しているところ。まずはSecret scanningやpre-commitでの漏洩予防、ログマスキングやRunnerの隔離、2FA/SSOなど「そもそも漏らさない」レイヤー。次に、GitHub Environmentsや承認ルール、権限最小化、OIDCを使った長期シークレット撤廃など、「漏れても一気に全部はやられないようにする」レイヤー。そして最後に、GitHub監査ログやKubernetesランタイム監視、EDR、インシデント対応計画での「検知と対応」。
どれか一個やって安心、じゃなくて、複数の網をかけていくことが大事だよね、という話が実例付きでまとまっているので、「うちのCI/CD、大丈夫かな…？」って気になってる方は、チームでの見直しのたたき台にかなり良さそうです。.

続いて2つ目の記事。「『手作り RAG システム』で RAG の仕組みを学び直す」という内容です。
最近はVertex AI Searchみたいなマネージドサービスが充実してきて、「とりあえずつなげば動く」時代になってきましたけど、この筆者はあえてPythonとGemini APIだけで、小さなRAGシステムを自作しながら、仕組みをちゃんと体で理解し直そう、というアプローチを取っています。
面白いのが、「細かくチャンク分割して全部ベクトル化する」従来スタイルから一歩引いて、Gemini 2.5のロングコンテキストを活かして、PDFをファイル単位で参照する設計にしているところ。その際、PDFの本文そのものをベクトル化しないで、「この文書は誰向けで、何の目的で、どんなキーワードで検索されそうか」といった要約テキストをLLMで作り、そのサマリーを埋め込みに使うんですね。ユーザーの質問側も同様に、検索用クエリを別で生成して埋め込みにする。
題材としては新宿区の「くらしのガイド」PDFを使っていて、(1) PDFを取得してCloud Storageに置くところから、(2) Gemini 2.5 Flashでサマリーを作り、(3) gemini-embedding-001で埋め込みを作成、(4) コサイン類似度で上位3件を選んで、そのPDFをURIのままプロンプトに渡して回答を生成する、という流れをステップバイステップで追っています。さらに、ユーザープロファイルと過去の質問履歴をプロンプトに混ぜることで、「引っ越してきたばかりなんですね」とか、状況に応じた案内をしてくれるパーソナライズもやっている。
最後は、本番運用で考えるべきポイントも整理されていて、Vector SearchやVertex AI Searchでのスケール、ベクトル生成の自動化、認証と権限制御、個人情報保護、ネットワーク境界の守り方、品質評価、コスト・レイテンシの最適化、根拠提示UIなど、実務でそのままチェックリストにできそうな観点がズラッと並びます。「結局、マネージド使うにしても、中身のロジックを理解してるとチューニング力が違うよね」というメッセージが刺さる記事でした。.

3つ目の記事は、ちょっと未来っぽい話題。「Visual Studio 2026 で GitHub Copilot 用の設計ドキュメントを整備するときの注意点」という内容です。
Copilotでコード生成させるときに、設計方針を何も伝えないと、プロジェクトがだんだんカオスになっていく、というのはもう多くの方が実感されていると思います。この記事では、`.github/copilot-instructions.md`でざっくりした方針を書きつつ、もっと詳しいAI向けの設計ドキュメントは別フォルダーで管理するやり方を前提にしています。
問題になるのが、Visual Studio 2026のAgent modeの仕様。VS Codeと違って、ソリューションエクスプローラーに出ていないファイルは基本読めないんですね。じゃあ、「フォルダービューに切り替えればいいんじゃ？」とか「設計ドキュメントも全部ソリューションに追加すれば？」という案が出るんですが、運用が重くなる、誤操作が増えるなど、現場的にはつらい。
そこで筆者が検証した結果、「`.github/instructions/**/*.instructions.md`」というCopilotのカスタムインストラクション用のパス配下に置いたファイルなら、ソリューションに表示されていなくてもちゃんと参照してくれる、ということが分かったと。つまり、VS 2026の世界では、「AIに読ませたい設計書は`.github/instructions/`以下に`*.instructions.md`として整理しておく」のが一番現実的な落としどころじゃない？という結論になっています。
将来的には、VS Codeみたいにリポジトリ内の任意ファイルをAgent modeが読んでくれるのが理想だけど、現時点ではこのディレクトリ戦略で、設計ドキュメントをAIにきちんと届けつつ、開発者の運用負担も抑えられそうだ、という実践的なノウハウ記事でした。.

4つ目の記事は、「天下一レビュープロセス大会 2025」という、タイトルからして楽しそうなやつです。
これは、アルダグラムさんのサービスKANNAで試験導入している、「AI中心のコードレビュープロセス」を紹介している記事なんですが、やっていることがかなり攻めています。まず開発者は、ローカルでClaude Codeのスラッシュコマンド、`/r`とか`/re`を使って、自分の差分をAIにレビューしてもらう。それを踏まえてPRを作ると、Slackのワークフロー経由で、Devin → Claude → 最後に人間レビュアー、という多段レビューが自動で回る仕組みになっているんですね。
このとき重要なのが、AIに渡す「コンテキスト」。リポジトリ内のdocs配下に、ドメイン別、エンドポイント別、ライブラリ別といったMarkdownドキュメントを整備しておいて、AIがそれを「コンテキストキャッシュ」として参照できるようにしている。さらに、Railsベストプラクティスに特化したサブエージェントを定義して、スラッシュコマンドやGitHub Actionsから呼び分けることで、「ここの設計、Rails的にどう？」みたいな、けっこう深いところまでAIに見てもらっているのが特徴です。
結果として、人間レビュアーの負担が体感で9割くらい減っているという話で、「AIを入れたからレビューが雑になる」ではなく、「AIがインラインコメントをガンガン書いてくれることで、人間は本当に重要な判断だけに集中できる」方向に振り切っているのが面白いところ。
もちろん課題も挙げていて、特定モデルへの単一依存リスクだったり、ドキュメント更新時には人間のレビューが欠かせないよね、という話もきちんと押さえています。最後は、「こういうレビューの工夫を各社持ち寄る『天下一レビュープロセス大会』やりませんか？」と呼びかけていて、聞いているあなたのチームでも、「うち流のAIレビュー」考えてみたくなる、そんな記事になっています。.

そして5つ目、最後の記事はガラッと雰囲気が変わって、「Obsidianを使ってみた所感と、実際に試して分かったこと」というお話です。
著者はもともとMarkdownで仕様や調査メモ、タスクを整理しつつ、生成AIと組み合わせて開発している方なんですが、「MDファイルの管理どうする問題」にぶつかって、Obsidianを試してみたという経緯です。
良かった点として挙げられているのは、まず起動が速いこと。そしてローカル完結で、普通のファイル構造がそのまま見える安心感。同期処理がないぶん軽快で、MarkdownだからAIとも相性がいいし、プラグインも充実している、と。エンジニア目線だと「分かる、これ大事」というポイントが抑えられています。
一方で、モバイル同期周りはちょっとクセがあったようで、iCloud上の特定階層に置かないとVaultを認識してくれなかったりと、「気軽に同期」というイメージとはややギャップがあるとのこと。Gitでの管理も試したものの、モバイルからのcloneやPATの扱い、Privateリポジトリでの403など、実際に運用しようとするとハードルが多かったと振り返っています。
現時点での落としどころとしては、「ローカルで完結するメモや開発系はObsidian」「チームでの共有や整理が前提の情報はNotion」という、ツールの使い分けに落ち着いたそうです。全部を一つのツールに押し込もうとせず、「用途ごとに気持ちよく使えるツールを組み合わせる」という発想は、多くのエンジニアにとって現実的なバランス感覚なんじゃないかなと思います。

というわけで、今日は
・GitHubトークン漏洩から始まった60億円規模のAPI改ざんインシデントと、その多層防御の考え方
・Gemini APIで手作りするRAGシステムと、サマリー重視の現代的な検索設計
・Visual Studio 2026でCopilotに設計ドキュメントをちゃんと読ませるためのパス運用
・DevinやClaudeを組み合わせた、AI中心の多段コードレビュー・プロセス
・Obsidianを実際に使ってみて分かった、メモツールの現実的な使い分け
この5本をご紹介しました。

気になった記事があれば、ぜひショーノートから元の記事も読んでみてください。細かい設定や、ここでは触れきれなかったテクニックもたくさん載っています。
zenncastでは、番組の感想や、「こんなテーマ取り上げてほしい」といったリクエストも大歓迎です。あなたの現場での工夫や、ちょっとした悩みなんかも、ぜひ共有してもらえるとうれしいです。

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