どうも〜おはようございます、マイクです！
FMラジオ風テック番組「zenncast」、2026年5月31日、日曜日の朝7時を回りました。
この番組では、エンジニアのみなさんの朝コーヒーのお供に、Zennで話題のトレンド記事をわかりやすくご紹介していきます。今日はどんな知見と出会えるのか、一緒にワクワクしていきましょう。

さてさて、きょうはお便りコーナーはお休みで、そのぶんたっぷりと記事紹介に時間を使っていきたいと思います。
今日ご紹介する記事はぜんぶで5本。LLMのKVキャッシュの本質的な話から、Claude Codeの新機能、モデル選びのリアルな使用感、Copilot CLIのコンテキスト整理術、そして最後はAWS Secrets Managerのちょっと怖い落とし穴まで、幅広く押さえていきます。

まず1本目。タイトルは「MLエンジニアのための本質から理解するLLM推論 KV cache編」。
LLMを触っていると「なんでKVキャッシュってKeyとValueだけで、Queryはキャッシュしないんだっけ？」って、一度は疑問に思ったこと、ありますよね。この質問に、数式と図を使って、かなり本質から説明してくれている記事です。
Self Attentionでは、入力XからQ, K, Vをそれぞれ線形変換で作って、QとKでスコアを計算して、softmaxを通して重みを出して、その重みでVを混ぜ合わせて出力を出す、という流れなんですが……。
ポイントは、生成時に位置m+1のトークンを計算するときに、本当に必要なのは「いまのトークンのQuery」と「過去を含むKeyとValue」だけだということ。KeyとValueは、「過去のどのトークンをどれくらい参照するか」と「そこからどんな情報を取り出すか」を決めるので、過去分も全部必要。一方でQueryは、「その瞬間の問い合わせ」にしか使われない、一時的なプローブなんですね。
だからこそ、「将来のステップで再利用されないQueryをキャッシュせず、Key/Valueだけ持っておくのが合理的だよね」という結論にきれいにつながっていきます。
なんとなく「そういうもん」として受け入れていたKVキャッシュの設計が、「なるほど、構造上そうならざるを得ないのか」と腑に落ちる内容。生成最適化や独自実装を考えているMLエンジニアには、すごく良い整理になりそうです。

。。。。

続いて2本目。タイトルは「Claude Code の Dynamic Workflows を触ってみた: マルチエージェント並列オーケストレーションの概念と体験」。
これ、ヘヴィなコードベースを触る人にはかなり刺さる内容でした。Claude Code v2.1.154でリサーチプレビューとして出てきた「Dynamic Workflows」という機能の実体験レポートです。
Dynamic Workflowsって何者かというと、Claude本人が「オーケストレーション用スクリプト」を動的に組み立てて、1セッションの中で数十〜数百のサブエージェントを並列に走らせちゃう仕組み。で、その結果を敵対的レビューと独立検証でしつこくチェックしながら、最終的に1つの答えにまとめてくれる、というかなりゴリゴリな機能です。
実例として、BunのZig→Rust移植、約75万行を11日で終わらせて、テスト成功率99.8%まで持っていった、という話が出てきますが、これもこのDynamic Workflowsが裏で動いていたと。
特徴としては、「並列処理」「独立検証」「進捗の永続化」「敵対的レビュー」の4本柱で、いわゆるエージェントチームより、もっと大規模で自動化寄りの世界観。起動は、直接お願いするか、`/effort` で「ultracode(xhigh + workflows)」みたいに頼む感じで、MaxやTeam、Enterprise向け。ただし、トークン消費はかなり重いです。
著者は、社内のClaude Codeプラグイン用リポジトリの棚卸しに使っていて、40エージェント・約3.3Mトークン・40分ほどで、プラグインごとの抜け漏れを洗い出しつつ、反証フェーズで4割くらいの「誤検知」をちゃんと除外できたとレポートしています。
おもしろいのは、エージェント同士が会話するんじゃなくて、Claudeが計画・Audit・Verifyをパイプライン的に回していく構造になっているところ。メインセッションのコンテキスト消費が少ないのに、大きなことができるのが特徴です。
総評としては、大規模マイグレーションやコードベース丸ごとの調査、セキュリティ監査みたいな「でかくて横断的で、検証がしんどいタスク」にはめちゃくちゃ向くけど、日常の小さなタスクにはオーバーキル、というバランス。自分のプロジェクトで「ここぞ」という場面を想像しながら読むと、結構ワクワクします。

。。。。

3本目。タイトルは「Cursor: GPT 5.5 が優秀でコスパ最強」。
こちらは、いろんなモデルを試した筆者の「実務での肌感」がそのまま綴られた記事です。テーマは、「賢さだけじゃなくて、自分の仕事やスタイルにフィットするモデルを選ぼう」という話。
著者はここ1ヶ月、Cursor上ではほぼGPT-5.5だけを使っていて、その中でもMediumでほとんどの業務が足りているといいます。特に評価しているのが、「複数リポジトリにまたがった既存コードのバグ発見能力」と、「速さ」と「安さ」。つまり、一発で正解にたどり着ける確率が高くて、テンポよく仕事が進む、というわけですね。
一方で、Claude Opus 4.7のHigh/Maxは、トークン消費が重いわりに、正解にたどり着くまでの道のりが長く感じられて、コスト面も含めてあまり魅力を感じていない、と率直に書かれています。Geminiについても、現時点では「わざわざ使う理由がない」と辛口評価。
おもしろいのは、GitHub issueベースのコード修正ベンチマークでは、「GPT-5.5がOpus 4.7を圧倒している」とまでは見えなかった、という点。つまり、ベンチマーク上のスコアと、実際に日々の開発で感じる「頼もしさ」にはギャップがある、と。
ここはリスナーのみなさんも、結構共感ポイント多いんじゃないかなと思います。スペック表やスコアより、「自分のフローに自然にハマるか」「ストレスが減るか」でモデルを選んでみる。記事をきっかけに、自分なりの“相棒モデル”の見直しをしてみるのも面白そうです。

。。。。

4本目。タイトルは「Copilot CLI のコンテキスト管理メモ」。
Copilot CLIを長時間使っていると、「なんか最近、反応が重いし、話がやたら脱線するな…？」っていう瞬間、ありますよね。この記事は、その原因になりがちな「コンテキストの膨張」をどうコントロールするか、という実践的なメモ集です。
まずは `/context` コマンドで、System Prompt、Tools、Messagesなどの利用状況を可視化してから整理するのがおすすめ、と。カスタム指示は「常に読ませておくもの」は最低限にして、長い手順やチェックリストはスキル化して、必要なタイミングで段階的に読み込ませる構成にします。
さらに、自動で起動してほしくないスキルには `disable-model-invocation: true` を付けておいて、必要なときだけスラッシュコマンドで呼ぶ。使うツールやMCPも、`--available-tools` や `--disable-builtin-mcps` で絞って、固定コストを抑えると。
コード調査は、全部をLLMに投げる前にLSPで定義ジャンプや参照検索を駆使して、まず人間側で範囲をしぼる。大きな変更は、いきなり手を動かす前にPlanモードで方針・範囲・やらないことを揃える。
独立した調査はサブエージェントや `/fleet` で別コンテキストに切り出して、長いコマンド出力は `rtk` みたいなツールであらかじめフィルタしてから渡す、といった具体的テクニックも紹介されています。
セッション管理のところでは、継続するときは `/compact`、タスクを切り替えるときは `/clear` 系、本題と関係ない質問は `/ask`、別案の検討は `/fork` と、コマンドの使い分けを丁寧に解説。自動要約でログが落ちる可能性があるから、重要ログはファイル退避しようね、という注意もあります。
全部を一度にやる必要はなくて、「カスタム指示のスリム化」「大きな変更前のPlanモード」「サブエージェント活用」「`/chronicle cost-tips`でトークン利用を振り返る」だけでも、長めの作業がかなり進めやすくなるよ、と締めくくられていました。Copilot CLIと長時間付き合う人には、効くノウハウが多いと思います。

。。。。

そしてラスト、5本目。タイトルは「【AWS Secrets Manager】末尾が \"ハイフン＋6文字\" のシークレット名には気をつけろ！！」。
これはインフラ周りを触っている方には、ぜひ頭の片隅に置いておいてほしい注意喚起系の記事です。
AWS Secrets Managerで、シークレット名の末尾が「ハイフン＋6文字」になっていると、部分ARN（つまりシークレット名だけ）で参照したときに、「リソースが見つからない」エラーが起きることがある、という話。
なぜかというと、Secrets Managerが内部的にARNを探すとき、その「末尾ハイフン＋6文字」を「AWSが自動で付けるランダムサフィックス」と勘違いしてしまうケースがあるからなんですね。たとえば、`app/cookie-secret` というシークレットがあると、本当は `app/cookie-secret` を探してほしいのに、「あ、これはサフィックス付きね」と解釈して、`app/cookie` みたいな別名のシークレットを探しにいってしまう。それで「そんなシークレットないよ」と怒られてしまう、というわけです。
対策はシンプルで、2つ。1つは、`fromSecretCompleteArn` のように、「自動サフィックスを含めたフルARNで指定する」こと。もう1つは、そもそも命名ルールで「末尾がハイフン＋ちょうど6文字」になるパターンを避けること。たとえば、`-secret-value` にするとか、アンダースコアに変えて `_secret` にするとかですね。
CIで命名ルールをチェックするようにしておけば、うっかりこの罠にはまりにくくなるので、チーム開発ではとくに有効です。「なんで本番だけシークレット取れないんだ…？」みたいな、嫌なデバッグから自分を守るためにも、覚えておきたいTipsでした。

。。。。

というわけで、きょうのzenncastは、全部で5本の記事をご紹介しました。
まずは、LLM推論で「なぜKVだけキャッシュしてQueryはしないのか」を数式からスッキリ整理してくれたKV cacheの記事。
そして、Claude CodeのDynamic Workflowsで、大規模並列オーケストレーションの実態と、どんなタスクに向いているかを教えてくれたレポート。
3本目は、Cursor上のGPT-5.5 Mediumを「コスパ最強の実務相棒」として評価しつつ、ベンチマークとのギャップにも触れたモデル選びの話。
4本目では、Copilot CLIのコンテキストをどう整理すると長時間作業がラクになるか、具体的なコマンドや運用の工夫がまとめられていました。
そして最後は、AWS Secrets Managerで「末尾ハイフン＋6文字」という、ちょっとした命名が大きな落とし穴になるかも、という警告記事でした。

気になった記事があれば、このあとぜひショーノートから、元の記事もチェックしてみてください。今日の原稿では触れられなかった図や具体例もたっぷりあるので、理解がぐっと深まると思います。

この番組「zenncast」では、みなさんからの感想や、「こんなテーマを扱ってほしい！」といったリクエストも大歓迎です。
開発の現場での気づきや、AIツールとの付き合い方の工夫など、短いメモでもぜんぜんOKなので、ぜひ気軽に送ってください。

それでは、そろそろお時間です。
日曜日の朝、ここまでのお相手はマイクでした。次回のzenncastでまたお会いしましょう。
今日も良い一日を！お仕事の方も、お休みの方も、無理せず、楽しくいきましょう。