#
733
2026/5/24
今日のトレンド

Claude Code改善とAIセキュリティ

どうも、おはようございます。マイクです。FMラジオ「zenncast」朝7時台、今日もよろしくお願いします。
今日は2026年5月25日、月曜日。月曜の朝いかがお過ごしでしょうか。
この番組では、技術メディアZennで話題になっているトレンド記事を、ゆるっと、でも中身はしっかりめにご紹介していきます。

今日は全部で5本、ご紹介していきます。AIエージェント、セキュリティ、新しいデータフォーマットなど、わりと攻めたラインナップです。ぜひコーヒー片手にお付き合いください。

まず1本目。「Claude Codeのスキルが毎日勝手に改善されていく仕組みを作った」という記事です。
これ、タイトルからしてワクワクするんですが、要するに「AIの開発用スキルを、自分で自分を改善する仕組みに乗せた」という話です。
作者の方は、Claude Code向けの `dev-workflow` というスキルを作っているんですが、使っているうちに「ここ、イマイチだったな」とか「また同じ指示を繰り返しちゃったな」という“失敗の痕跡”を、会話ログから自動で拾い上げます。その「うまくいかなかったシグナル」をもとにGitHub Issueを自動で起票して、さらに別のスキルがそのIssueを読んで、スキルの仕様書にあたるSKILL.mdを直して、Pull Requestまで自動で作ってくれる。
この一連の流れを、Routinesで毎日1回まわすことで、「昨日までの失敗から、今日のスキルがちょっと賢くなってる」状態を作っています。しかも、品質を担保するために「本当に意図通り直せてる?」「ベストプラクティスになってる?」「変な情報混じってない?」みたいな3つのチェックポイントも用意していて、最後は人間がサクッとレビューしてマージする形。
13日で40件以上の自動修正が、特にトラブルなくmainに入っているそうで、「AIの改善サイクルそのものをAIにやらせると、こんなに開発がラクになるのか」という実例になっています。Routines運用ならではのハマりどころ、途中停止とかツール権限の扱いなんかも書かれていて、エージェントを本番運用したい人にはかなり実践的な内容でした。

。 。 。 。

続いて2本目。「AIコーディングエージェントの本当の攻撃面は設定ファイルだった」という記事です。
AIエージェントまわりのセキュリティって、「モデルが変な指示を飲み込む」とか、そっちに意識が行きがちですけど、この記事では「一番危ないのは設定ファイルだよ」とバッサリ指摘しています。
TrustFallという事例では、悪意あるリポジトリの中に `.mcp.json` とか `.claude/settings.json` を仕込んでおくだけで、開いた瞬間にMCPサーバが自動起動して、リモートコード実行とか認証情報の窃取までできてしまう。もう1つ、AWS Kiroのケースでは、間接プロンプトインジェクションを使って `.vscode/settings.json` の `trustedCommands` を勝手に書き換えられて、確認なしで任意コマンドを実行できる状態になっていたと。
共通して狙われているのは、「何をしてよいか」を決めている設定項目です。hooks、permissions、MCPのallowlist、sandboxフラグ、trustedCommands…。怖いのは、プロジェクトを開いた瞬間に効き始めるので、レビュー前に権限が有効になってしまうことなんですよね。
対策としては「エージェントをコンテナやサンドボックス内で動かす」「設定変更を監視する」が重要だけど、人間が全部目で追うのは現実的じゃない。そこで著者は、設定の変更を監視して危険度をスコアリングし、ログを飛ばすAI-SPMエージェント「Sigil」をRustで作ってOSSとして公開しています。ブロックはせずに、「今このエージェントは何ができる状態なのか」を見える化して、他の防御策と組み合わせる設計。
AIコーディングエージェントを使うときは、「コマンド実行」そのものより、それを許可している設定ファイル管理が本丸だよ、というメッセージが印象的でした。

。 。 。 。

3本目。「Dockerを手放したら、Agent開発が身軽になった」という記事です。
Agent系の開発をしている人、なかなか刺さる内容だと思います。筆者は、最初Docker ComposeでDB、ベクタDB、トレーシング、ストレージ…と周辺インフラをどんどん足していって、「気づいたらインフラ管理ばっかりやってるぞ」と。ほんとは見たいのはAgent Runtimeや推論構造なのに、コンテナとログの面倒を見る時間が増えてしまっていた。
そこで思い切って、QdrantをやめてTavilyに寄せたり、Langfuseもクラウド利用に切り替えたりして、「エージェント本体じゃない責務」を外部サービスに出していきます。ingestionやembedding、observability backendの運用から解放されることで、FISI、つまり「小さく作って現実に当てていくサイクル」がかなり軽くなったそうです。
さらに興味深いのが、「自律しすぎないAgent」が欲しくなった、という話。PR確認やドキュメント更新、トレース確認を全部自動で完遂するエージェントではなく、「判断材料を返してくれるエージェント」がちょうど良いのでは、という仮説に行きつきます。人間が最後の判断をする前提で、「ここを見ればいいよ」と材料を出してくれる存在ですね。
この記事の結論は、「強いモデルを使うかどうか」よりも、「何を自分で抱え、何を外に出すのか」という境界設計のほうが本質的だ、というものです。推論・状態・責務・判断、この4つの境界をどう切り分けるかが、Agent設計のキモだよという話で、エージェント開発に疲れ気味の人には、ちょっと肩の力が抜ける内容になっています。

。 。 。 。

4本目。「『同じJSONを256件送ると約73%小さくなる』— MessagePackの次を狙う Twilic を公開しました!」という記事です。
名前からしてすでに気になる「Twilic」。これはJSON相当の構造化データを、よりコンパクトに扱うための新しいバイナリフォーマットです。ポイントは、スキーマ無しでもMessagePackみたいにそのまま使えつつ、「同じ形のオブジェクトをいっぱい送ると、勝手に圧縮率が上がっていく」というところ。
内部では、shape、key、stringのインターニングをしていて、最大256件のBatch単位で送信できます。同じ構造のJSONを256件バッチで送ると、サイズが約73%削減できたというのがタイトルの数字ですね。さらに、前回との差分だけ送るPatchモードや、スキーマがある場合のBoundプロファイルも用意されていて、「1件だけ送るときはMessagePackと同じくらいのサイズ」「同じ形を大量送信するときはどんどん得する」という設計になっています。
実装もNode.js、Go、Rust、Zig向けにすでに用意されていて、Hono用ミドルウェアやベンチマーク、ブラウザ用のPlaygroundまで公開されているとのこと。想定している用途は、APIやWebSocket、バッチ連携など、とにかく「同じJSONの形を大量に飛ばす」場面です。一方で、単発のすごく小さいペイロードの置き換えとか、既存プロトコルを全部これにする、というのは目的ではないと明言されています。
仕様も公開されていて、マルチ実装とベンチ環境を揃えたうえで、コミュニティのフィードバックをもとにv2プロファイルを磨いていく方針。プロトコル好き、パフォーマンスチューニング好きな方には、読んでいてワクワクする記事だと思います。

。 。 。 。

ラスト5本目。「自分専用AIエージェントを作ってわかった、LLMとプログラムの責務分離」という記事です。
著者は「Agent-Sin」という個人用AIエージェントを作っていて、その中から見えてきた「LLMに何を任せて、何をプログラムに固定するか」という設計の話がまとまっています。
このエージェントでは、LLMはあくまで「会話とルーティング」を担当します。自然言語でユーザーの意図を理解して、「どのProgram Skillを使うべきか」を決める役ですね。一方で、Gmail整理や朝のブリーフィング、食事記録といった副作用を伴う処理は、Program Skill側にしっかり実装して、スキル内でも「ここは判断が必要だな」という部分だけLLMを呼び出す構造にしている。こうすると、結果のブレやコストをうまく抑えられると。
記憶の扱いも面白くて、人が読んで編集できるMarkdownのノート(プロフィール、日次ログ、トピックごとの知識)と、スキルごとのSQLite DBを分けています。Obsidianから普通のノートとして見られるので、「エージェントの記憶が完全なブラックボックスにならない」のがポイントです。
さらに、副作用のある操作は、構造化されたskill_call経由でしかできないようにしていて、その中でも `side_effect` が付いたスキルを呼んだときは、LLMの「口だけ出した発話」は履歴から捨てて、実際の実行結果だけを残すようにしている。これで「やったつもり」の虚偽を防ぐ工夫をしています。
マルチチャネルから同じエージェントと記憶を共有したり、スキル自体もBuild ModeでAIにコード生成させるなど、運用しながら育てていける設計も紹介されています。全体を通して、「LLMひとつで全部やらせる」のではなく、「LLM+プログラム」の責務分離を徹底することで、個人エージェントの安定性と信頼性がかなり上がる、というメッセージが印象的な記事でした。

。 。 。 。

というわけで、今日は5本ご紹介しました。
1本目は、Claude Codeのスキルを会話ログから毎日自動改善していく自己改善ループの話。
2本目は、AIコーディングエージェントの本当の攻撃面は設定ファイルだよ、というセキュリティの視点。
3本目は、Dockerを手放してAgent開発を身軽にした、境界設計の話。
4本目は、同じJSONを大量に送るとめちゃくちゃ小さくなる新フォーマット「Twilic」。
そして5本目が、自分専用エージェントから見えた、LLMとプログラムの責務分離のお話でした。

気になる記事があった方は、番組のショーノートに詳しい情報を載せておきますので、あとでゆっくりチェックしてみてください。
この「zenncast」では、番組の感想や取り上げてほしいテーマなど、皆さんからのお便りもお待ちしています。開発の悩みでも、読んでよかった技術記事の紹介でも大歓迎です。

それでは、そろそろお別れの時間です。
月曜の朝、今週も無理しすぎず、ぼちぼちやっていきましょう。お相手はマイクでした。
また次回の「zenncast」でお会いしましょう。では、いってらっしゃい。

Related episodes

内容の近いエピソードを推薦しています