どうも、zenncastパーソナリティのマイクです。
2026年1月10日、土曜日の朝7時を回りました。みなさんおはようございます。
この番組では、Zennで話題になっているトレンド記事を、ラジオ感覚でゆるっと、でも内容はガッツリめにお届けしていきます。今日も最新の技術ネタを、一緒にキャッチアップしていきましょう。

今日はお便りはお休みということで、そのぶんしっかり記事紹介に時間を使っていきますね。

さて、今日ご紹介する記事は全部で5本です。
AI、セキュリティ、GitHub Actions、コーディングエージェントの運用テクニック、そして複数のLLMを同時に使いこなすためのツールまで、かなり盛りだくさんのラインナップになっています。

まず1本目。
タイトルは「Attention再入門 is all you need」。
もうタイトルからして「Transformerのおさらい行くぞ」という感じなんですが、この内容がかなり本格的です。
Transformerの心臓部であるAttention機構を、Q・K・Vの基本から、最近の効率化テクニックまで一気に整理してくれています。

Attentionって、全トークン同士を見合うので計算量もメモリもO(n²)で重い、っていうのが宿命なんですよね。そこをどうやって実用レベルにしているか、という話がめちゃくちゃ丁寧にまとまってます。
たとえばGPUのメモリアクセスを工夫して実効性能をドカンと上げる「FlashAttention」、構造を工夫してそもそもの計算を間引いちゃう「Sparse Attention」（Longformer、BigBird、NSA）、「Linear Attention」（Performer, Linear Transformer）なんかが出てきます。

さらに、自己回帰生成でどんどん膨れあがるKVキャッシュの扱いも重要で、ヘッドを共有しちゃうMQA / GQA、低ランク圧縮でうまく情報を詰め込むMLA、そしてPagedAttentionや量子化によるメモリ節約などなど、「最近よく聞くけどちゃんと整理できてない」ワードが一気に頭に入る構成になっています。

長文コンテキストの話も面白くて、Ring AttentionやStriped AttentionみたいなマルチGPUでの並列化の工夫、それからRoPEを拡張するLongRoPEやYaRNで「学習時より長いコンテキストをどう扱うか」というTest Time Scalingの鍵になる部分も解説されています。
最後はMamba系SSMとAttentionを組み合わせたハイブリッドモデルの潮流まで触れていて、「理論」と「ハードウェア最適化」の両方をちゃんと押さえたい人には、かなりありがたい“再入門”記事です。
最近のLLMの裏側を俯瞰したいエンジニアさんは、通勤前にでもざっと目を通しておく価値があると思いますよ。

。。。。

続いて2本目。
タイトルは「LLMアプリケーションのセキュリティ実践：脆弱性の発見からガードレール実装まで」。
これは、生成AIをプロダクションで使い始めているチームには、もはや必読レベルの内容です。

まず、OWASP LLM Top 10 として整理されている、LLM特有の脆弱性が紹介されています。プロンプトインジェクション、機密情報漏洩、システムプロンプトの漏洩、ハルシネーション…名前だけ聞いたことあるものも、実際どう危ないのかが具体例付きで解説されています。
たとえば「シボレー1ドル販売事件」みたいに、LLMの出力をうっかり“約束”として扱ってしまったケースや、Samsungの機密コード流出、エア・カナダの裁判、日本で問題になったフェイク動画など、「実際に起きた事故」を軸に話が進むので、他人事ではなくリアルに感じられます。

対策として面白いのが、Garak、PyRIT、Promptfooといったツールを使ったレッドチーミング。わざと攻撃プロンプトを流し込んで、どこまで壊せるかを自動テストしていくイメージですね。
記事では、サンプルの社内チャットボット「AskBot」をわざと脆弱な状態にして、Promptfooで試験。給与情報やAPIキーが漏れてしまう状態から、段階的に対策を入れていきます。

対策は三層構えです。
(1) そもそもシステムプロンプトに秘密を書かない設計に変える。
(2) 正規表現ベースで入力・出力のガードレールを敷く。
(3) NeMo Guardrails の Colang を使って、対話フローそのものを制御する。
この結果、同じテストなのに「合格率が50%から100%に上がった」という、かなりわかりやすい成果が示されています。

ポイントは、「LLMに頑張ってもらう」だけの確率的な防御じゃなくて、システム設計のレベルで分離して、ガードレールで決定論的なチェックを入れていくこと。
DevSecOpsの一環として、継続的にレッドチーミングを回していくべき、という結論も含めて、「うちのAIチャットボット、このままで大丈夫…？」と不安な人には、すぐに参考にできる内容になっています。

。。。。

3本目。
タイトルは「GitHub Actions のシークレットは簡単に見れる」。
これ、タイトルからしてイヤな予感しかしないんですが（笑）、読んでおいたほうがいいやつです。

GitHub Actions って、シークレットをマスクしてくれる安心感ありますよね。ただ、そのマスク仕様が「ログに出てくる文字列がシークレット値と完全一致したときだけ隠す」というルールに依存しているんです。
ということは、逆に言えば「完全一致しなければマスクされない」。ここが大きな落とし穴だと。

たとえば、環境変数にセットしたシークレットを、文字列を分割してログに出せば、部分文字列はマスクされません。結果として、ログを見てつなげれば元のシークレットが復元できてしまう。
さらに厄介なのが、JSONみたいな構造化データをシークレットに入れる場合。登録したときの文字列と、ログに出力されるときのフォーマットが微妙に変わると、それはもう「完全一致じゃない」のでマスクが効かなくなります。逆に、マスクされる形に合わせて登録すると、今度はJSONとしてパースできなくなる、というジレンマも指摘されています。

ここに、悪意のあるコードやサードパーティ製アクションが絡むと、「あ、これシークレットって簡単に抜けるじゃん」という話になってしまう。
記事では、「シークレットを分割して扱うようなコードを書かない」「サードパーティアクションや外部コラボレーターの権限に気をつける」といった、現実的な運用上の注意点がまとめられています。

GitHub Actions は本当に便利なんですけど、「シークレットは自動で完全防御してくれる」と思い込むと危ない。
CIを触っているエンジニアの方は、一度この記事を読んで、うちのワークフロー大丈夫かな？という棚卸しをしてみるといいかもしれません。

。。。。

4本目。
タイトルは「複数のコーディングエージェントでSkillsを共有する（Claude Code / Codex対応）」。
これは、Claude Code や OpenAI Codex みたいなコード生成エージェントを、複数使っている人には「おお、それだ！」ってなる運用テクニックです。

発想としては、「プロジェクトごとのお作法・方針を書いたガイド（Skills）を、エージェントごとじゃなくて、プロジェクト側で一元管理しよう」というもの。
具体的には、プロジェクト直下に `.agent/skills/` を作って、そこに SKILL.md をモジュールごとに分けて置いておく。それを、`.claude/skills/` とか `.codex/skills/` からシンボリックリンクで参照する構成にします。

こうすると、あるルール変更があっても `.agent/skills/` の中身を直すだけで、Claude Code も Codex も、VSCode や Cursor にぶら下がっているエージェントたちも、同じ方針を読むようになる。
しかも、必要なときだけ特定の SKILL.md を読み込ませればいいので、巨大なAGENTS.mdを毎回コンテキストに突っ込まなくてよくなります。コンテキストの節約にもなるし、指示もモジュール化されて整理される。

記事ではさらに、AGENTS.md や CLAUDE.md もシンボリックリンクで共通化して、すでに長くなってしまった指示は、エージェント自身に「いい感じに分割して Skills 化して」とお願いしちゃう、というユニークなテクも出てきます。
「エージェントの設定ファイルが散らかっててカオス…」という人には、設定・ナレッジを“プロジェクトの資産”として中央管理する、いい設計パターンの参考になりそうです。

。。。。

そして5本目。
タイトルは「Claude・GPT・Geminiを同時に使いこなすoh-my-opencodeがすごい（どれか1つでもOK）」。
これは、マルチLLM時代の“開発環境の形”を、かなり先取りしている感じのツールです。

oh-my-opencodeは、Claude Code のOSS版である OpenCode を「Ubuntuっぽくディストリビューション化しちゃおう」というノリのプラグインで、AIコーディング体験をぐっと底上げしてくれます。
一番面白いのが、マルチエージェントのオーケストレーション。
Sisyphus という統括役のエージェントをトップに置いて、その下に設計・デバッグ専門の Oracle、フロントエンドUI/UX担当、Librarian（調査・リファレンス担当）、Document Writer（ドキュメント担当）など、役割分担されたエージェントが並びます。

それぞれのエージェントが、「手元にあるサブスク」に応じて、Claude / GPT / Gemini の最適なモデルで動くよう自動設定されるのがポイント。
「Claudeしか契約してない」とか「GPTとGeminiだけ」みたいな構成でも、その範囲でベストな布陣を組んでくれます。インストールも対話式で、既存のAPIキーを入れていけばいいだけなので、追加コストは基本ナシ。

出てくるコードも、冗長さが少なくて、シニアエンジニアが書いたような自然さ、という評価。LSP連携しているので、リネームや型エラーの事前チェックも安全にできるし、複数エージェントを並列実行したり、`ultrawork` モードで一気に作業を進めたり、TODOを自動管理してくれたりと、「でかいリファクタリング」や「未知の巨大コードベース」の攻略に強い設計になっています。

そのぶん、OpenCode 前提だったり、機能豊富すぎて最初は学習コストもあるんですが、「慣れたら開発体験が別次元になる」と筆者は評価しています。
「ClaudeもGPTもGeminiもあるんだけど、ちゃんと活かしきれてないな…」という人や、「AIを軸にした新しい開発ワークフロー」を模索しているチームには、かなり刺さる内容だと思います。

。。。。

というわけで、今日は
・Attentionの再入門と最新効率化テクニックの総ざらい
・LLMアプリのセキュリティとガードレール実装の実践例
・GitHub Actions のシークレットマスク仕様の落とし穴
・複数コーディングエージェントでのSkills一元管理テク
・Claude・GPT・Geminiを束ねるoh-my-opencodeのマルチエージェント環境
この5本を駆け足でご紹介しました。

気になった記事があれば、詳しい内容や元記事へのリンクは、番組のショーノートにまとめてありますので、ぜひそちらからチェックしてみてください。
zenncastでは、番組の感想や、「このテーマを深掘りしてほしい！」といったリクエストもお待ちしています。あなたの開発現場での悩みや気づきが、次回のトピックになるかもしれません。

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