おはようございます。マイクです。FMラジオ風テック番組「zenncast」、本日も始まりました。今日は2026年5月28日、木曜日の朝7時を回ったところです。この時間は、Zennで今トレンドになっている技術記事を、ラジオ感覚でゆるっと紹介していきます。

今日はですね、全部で5本の記事をご紹介していきます。それぞれテーマもバラバラで、AIエージェントの挙動から、Webセキュリティ、サプライチェーン攻撃対策、KubernetesでのMinecraft運用、そして社内ナレッジとAIの付き合い方まで、結構盛りだくさんです。コーヒー片手に、通勤・通学のお供に、ながら聞きでどうぞ。

まず1本目。「Codex が SKILL.md を 220 行で打ち切っていた話」という記事です。タイトルからして、ちょっとイヤ〜な予感がしますよね。著者の方は、Quaereというエージェントスキルのセットを、Codex CLIの上で評価していたんですが、そのログを細かく見ていくうちに、「あれ？SKILL.md、最後まで読まれてないぞ？」という事実に気づきます。本来441行あるスキル定義に対して、Codexは自分で`s...`みたいなコマンドを組み立てて、なぜか220行までしか読まない。しかも41タスク中、39タスクで「最深行がきっちり220行」でピタッと揃っている。怖いですねえ。で、これがハードの上限とかCLIの仕様ではなくて、「ファイル読み取りツールがない状態で、モデル自身が慣れでそういうコマンドを出しているっぽい」というのがミソなんですね。一方で、Claude Codeとか、SKILL専用のツールをちゃんと持っている環境だと、この問題は起きない。仕様としては「SKILL.mdは最大500行までOK、本文は全部ロードすること」となっているのに、gpt-5.5 + Codex CLIだと、モデルの学習上の暗黙知みたいなものから「まあSKILL.mdは220行くらいでしょ」と勝手に打ち切っちゃう。その結果、後半に書いてあるアンチパターンとか、ストップ条件、他スキルへのハンドオフの記述が、物理的に読まれてない可能性が高い。評価結果も、実は「後半のルールを知らないエージェント」の成績になっちゃってるんですね。仕様的には、ちゃんとツールを用意するか、モデル側を直すのが筋なんですが、現実的なワークアラウンドとしては、「重要なことは200行以内に全部詰めろ」「細かい例や参照は別ファイルに逃がせ」という、ちょっと切ないけど実務的な工夫が必要だよ、というお話でした。エージェントにスキルを書いてる人は、「221行目以降、読まれてないかもしれない」という前提で設計した方がよさそうです。….

続いて2本目。「『JWT を localStorage に置くな』はなぜ言われるのか、Cookie 回帰までの時系列整理」という記事です。これはもう、Webフロント周りにいる人は一度は聞いたことがあるフレーズですよね。「JWTをlocalStorageに入れちゃダメ」「いやでもSPAだから」「BFF入れよう」みたいな、ここ10年くらいのドタバタを、ちゃんと時系列で整理してくれています。大きな流れとしては、(1) 昔ながらのCookieベースセッション、(2) SPAブームとともに広まった「JWT＋localStorage＋Bearer」、(3) そこからのBFF登場によるトークンの隔離、(4) 結果的に「Cookieセッション回帰」と見える今、という4ステップで説明してくれています。ポイントは、「なぜlocalStorageに入れたのか」「なぜやめたのか」。SPA化、外部IdP、サードパーティCookie規制、マイクロサービス側の『ステートレスでいてほしい』という要求、いろんな事情が重なって、「とにかくブラウザにJWTを持たせて投げさせればいいじゃん」という流れになった。ところが、XSSでトークン抜かれやすいし、一度配ったJWTを即時無効化しづらい。「ステートレス最高！」と言ってたら、運用で詰む。そこでBFFが出てきて、「ブラウザとの境界はHttpOnly Cookieでいいじゃん」「JWTはサーバー側のBFF〜API間だけで回そう」という構成が増えていく。React Server ComponentsとかServer Actionsみたいな「サーバー主役」のフレームワークも、これを後押ししている。で、「JWTが悪者になったわけじゃなくて、ブラウザに長期的に持たせる必要はなくなった」というのが、いわゆる「Cookie回帰」の本質だよ、という整理です。「ブラウザ境界はCookie、サーバー間はJWT」というレイヤー分担の絵を、歴史と一緒に理解したい人には、とても読みやすい記事になってます。….

3本目。「サプライチェーン攻撃対策の『実効』を継続検証するGitHub監査基盤を内製した話」です。これはセキュリティ運用の“泥臭い本質”をちゃんと書いてくれている記事ですね。スマートラウンドさんが、pnpm/uvのminimumReleaseAgeとか、Takumi Guard、GitHub ActionsのSHA pinningといった、いわゆるサプライチェーン対策をたくさん入れてきた。でも、「設定してある＝ちゃんと効いている」とは限らない。新しいリポジトリが増えたり、サブツリーを取り込んだり、パッケージマネージャのバージョンがバラけたりすると、「あれ、このリポだけminimumReleaseAge効いてないじゃん」「このworkflowだけSHAじゃなくてbranch参照になってるじゃん」みたいな、設定ドリフトがどうしても出てくる。そこで、「設定されていること」じゃなくて「実際に効いていること」を継続的に監査するために、GitHubの状態をPythonでチェックする基盤を自前で作った、という話です。orgやrepo、workflow、GitHub Apps、PATごとに「1ファイル1チェック」で実装して、結果はIssueとしてupsert、Slackにも通知、例外はYAMLでgit管理、期限が切れた例外は自動で再評価──といった感じで、ガバナンスを仕組みに落とし込んでいる。既存のghqrやGitHub Advanced Securityがなぜ刺さらなかったか、という話も丁寧で、「スナップショットで終わってしまう」「運用ルールを表現しきれない」「Takumi Guardが本当にデフォルトregistryとして効いているか、みたいな文脈判定が難しい」といった理由が挙がっています。おもしろいのが、監査対象を「Layer A」と「Layer B」に分けているところ。Layer Aは機械判定できるルール群、Layer Bは外部コラボレーターやApp、PATの棚卸しのように、人が定期的に見直す領域。その上で、例外には「理由・承認PR・有効期限」を必須にして、期限なしはNG、期限切れたら自動で再通知して「永遠の例外」を防ぐ。こうすることで、設定のドリフトをすぐ検知できるし、「昔決めたからそのまま」が減る。しかも、新しいチェックも「1ファイル追加してPR出すだけ」で増やせる拡張性がある。ADRで意思決定も残していて、「セキュリティの運用・ガバナンスをきちんと設計する」とはこういうことか、というのが伝わってくる記事でした。自社でも似た課題を感じているチームには、かなり参考になると思います。….

4本目。「KubernetesでMinecraftサーバーを運用すると何が難しいのか」。これはインフラ好きとマイクラ好きの両方に刺さるやつですね。Docker ComposeでMinecraftサーバーを立ててそのまま運用していると、「とりあえず立つからいいや」で済んでしまうんですが、Kubernetesに載せようとすると、いきなりいろんな問題が表に出てくる。Podの再作成タイミングと初期化処理、PVC上にあるworldデータや設定との整合性、優雅なシャットダウン、リソース配布の仕組み…などなど。記事ではまず、「installフェーズ」と「runtimeフェーズ」をきちんと分けることの大事さが語られます。サーバーjarの取得やworld展開などはinstallフェーズの責務で、ここで矛盾があったら無理に自動修復しようとせず、fail-fastする。中途半端に直そうとすると、逆にworldを壊したりするリスクがありますからね。ランタイムでは、RCONとpreStop hookを使って、プレイヤーに通知しつつ安全にサーバーを止める。terminationGracePeriodを長めに取って、ちゃんとsaveしてからPodを落とす。readinessも「プロセスが起動したか」ではなく、「サーバーとして安定して遊べる状態か」を見るようにする。さらに、pluginsやconfigはS3やMinIOから同期して、削除を伴う「remove-extra」は明示的にopt-inしない限りやらない、といった“安全側デフォルト”を意識した設計になっています。こうした思想を形にしたのが、著者の方が作っているDocker image「alexandergg-0520/minecraft-server」。KubernetesやGitOpsでの運用に向けて、ライフサイクルの明示性、PVC保護、S3/MinIO連携、RCON終了などにフォーカスしていて、一般的な「とりあえず手軽に立てられます」系のイメージとは目的が違うよ、という位置づけです。Kubernetes上でゲームサーバーを真面目に運用したい人には、「何が難しいのか」「どこを気をつけるべきか」が具体的にわかる内容でした。….

そして5本目。「社内の知見をAIが漏らさず拾う唯一の設計思想 ― Karpathy氏のLLM Wikiを実践して分かったこと」。これはRAGや社内検索に悩んでいる人に刺さりそうな記事です。「社内ドキュメントをそのままベクトルDBに入れて、RAG組んでみました。でも全然いい答え返ってこないんですけど…」というパターン、その主原因は「どんなふうに入れたか」にあるんじゃないか、という指摘から始まります。KarpathyさんのLLM Wikiや、PineconeのNexusが採っているのは、「そのままのドキュメントをrawとして保存」「取り込み時にLLMで“コンパイル”して、構造化されたWikiページやアーティファクトとして蓄積」「クエリ時には、そのコンパイル済みの層だけを見る」という、三層＋コンパイル型の設計です。記事ではこれを実践するにあたって、「1チャンク1概念」「だいたい200〜400トークン」「対象システムや時点を明示」「そのチャンクだけ読めば意味が通る自己完結性」を満たすように、LLMに自動でチャンクを作らせていくアプローチが紹介されています。散らかった約20万ファイルをこの方針で“コンパイル”していったところ、検索の体感精度がかなり上がった、という手応えがあるそうです。一方で、当然リスクもある。取り込み時のLLMが間違った理解をすると、その誤りが知識ベースに定着してしまう。トークンコストもかかるし、スケールすると運用も大変。そこでlintをかけたり、階層的な構造を意識したりといった工夫が必要になる。NaiveなRAG、もう少し頑張ったAdvanced RAG、LLM Wiki、Nexus──どれか一つが絶対解というわけではないけれど、「取り込み時に知識をコンパイルしておく」「情報に型・出典・構造を持たせて、段階的に開示する」という共通の設計思想が重要だ、と締めくくっています。大事なのは、いきなり複雑なものを作るのではなく、評価基盤を用意しつつ、必要最小限の複雑さから育てていくこと。社内ナレッジ検索の“沼”にはまっているチームに、かなり示唆を与えてくれる記事でした。

というわけで、今日のzenncastでは、全部で5本の記事をご紹介しました。振り返ると、1本目は「SKILL.mdを220行で打ち切っていたCodexの挙動」から、エージェントスキル設計の現実的な制約の話。2本目は、「JWTをlocalStorageに置くな」がどういう歴史で生まれて、いまなぜCookie回帰と言われているのかという整理。3本目は、サプライチェーン攻撃対策を「設定しただけで満足しない」ためのGitHub監査基盤づくり。4本目は、Kubernetes上のMinecraftサーバー運用で何が難しくなるのか、ライフサイクル設計のポイント。5本目は、社内知見をAIがちゃんと拾うための、LLM Wiki的な「コンパイルするRAG」の設計思想について、でした。

気になった記事があれば、詳しい内容は番組のショーノートにまとめてありますので、そちらから原文もチェックしてみてください。このzenncastでは、番組の感想や「こんなテーマ取り上げてほしい」なども大歓迎です。開発現場のモヤモヤや、最近読んで良かった技術記事のシェアなんかも、ぜひ送ってください。

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