はじめに
6月も中盤に差し掛かり、開発現場のあちこちで「AIエージェントが実際に何かを操作している」という話を耳にするようになった。実験的な取り組みから、本番環境への実装へ。この移行が、今週の技術トレンドからも読み取れる。
一方で、古典的なツールにも深刻な問題が発覚した。FFmpegの脆弱性群は、長年使われてきたライブラリがどれだけのリスクを抱えているかを改めて突きつけている。
TypeScript、AIエージェント、AI安全性検証、そしてセキュリティ。今週もバラエティ豊かだが、それぞれが独立した話ではない気がしている。
TypeScriptのnever型：型システムの「底」を理解する
never型は、TypeScriptを書いているとエラーメッセージの中に時々現れる不思議な型だ。「なんとなく動いている」で済ませてきた人も多いかもしれないが、これを意図的に使いこなすと、コードの安全性が一段上がる。
neverの本質は「到達しえない状態」を型で表現することにある。例えば、ユニオン型の絞り込みを網羅的にチェックする「Exhaustive Check」に使うと、将来の型の追加に対して自動的にコンパイルエラーを発生させられる。
type Shape = 'circle' | 'square' | 'triangle';
function getArea(shape: Shape): number {
switch (shape) {
case 'circle': return Math.PI;
case 'square': return 1;
case 'triangle': return 0.5;
default:
const exhaustiveCheck: never = shape; // 新しいShapeが追加されたら型エラー
throw new Error(`Unknown shape: ${exhaustiveCheck}`);
}
}
条件型との組み合わせでは、型レベルでの「不可能な分岐」を排除できる。大規模なコードベースで型定義が積み重なってきた段階で、特にその恩恵を感じる場面が増える。
バックエンドAPIのレスポンス型管理やフロントエンドの状態管理で、neverを使った網羅チェックを入れておくと、チームメンバーが後から型を追加したときのミスが減る。型安全性は「書いた時点の保証」ではなく「変化への耐性」として考えるべきで、neverはその実装手段の一つだ。
AIエージェントがKubernetesクラスターを直接操作する時代
「AIエージェントが本番インフラを制御する」というのが、もはや未来の話ではなくなってきた。NVIDIA NIMとLangGraphを組み合わせて、オンプレミスのKubernetesクラスターをAIエージェントが操作する実装事例が報告されている。
2025〜2026年にかけて、AIエージェントは「実験的なデモ」から「インフラ操作が可能な実体」へと進化した。具体的には、kubectl相当のコマンドをエージェントが自律的に実行し、Pod状態の確認やスケーリング判断を行うケースが出てきている。
これが現場にもたらす変化は二つある。
一つは、SREやインフラエンジニアの役割変化。「自分でコマンドを打つ」から「エージェントの判断を承認・監視する」への移行が始まっている。Human-in-the-loopの設計が必須になり、「エージェントに何を許可するか」という設計力が問われるようになる。
もう一つは、セキュリティモデルの再考。エージェントがクラスターAPIに直接アクセスできる設計は、権限設計を誤ると致命的なインシデントに繋がる。LangGraphのようなオーケストレーションフレームワークでどこまで制御できるか、実装前にきちんと検証することが欠かせない。
Google AMS：AIの「内側」を直接検査する安全性検証
Googleが2026年4月末にオープンソース化したAMS（Activation Model Scanner）は、従来の「振る舞いテスト」とは根本的に異なるアプローチでAIモデルの安全性を検証するツールだ。
従来の安全性テストは「有害なプロンプトを入力して出力を確認する」行動ベースの手法が主流だった。AMSはそれとは違い、モデルの活性化空間（activation space）の幾何学的構造を直接測定することで、Safety Trainingが実際にモデルの重みに反映されているかを確認する。
実際に小規模モデル3つでテストしたところ、すべてが「CRITICAL」判定を受けたという報告もある。表面上は問題なく動いているように見えるモデルでも、内部構造レベルでは安全性の担保が不十分な可能性を示唆している。
AIを業務に組み込もうとしている企業にとって、このツールの意味は大きい。モデルの「信頼性」を評価する手段が、チャット履歴やベンチマークスコアだけでなく、モデルの内部構造の解析にまで広がっていく。医療・金融・法務など、高い信頼性が求められるドメインでのAI導入判断に、じわじわ影響してくるはずだ。
FFmpegに21個のゼロデイ：長年使われてきたライブラリの死角
FFmpegといえば、動画変換・ストリーミング・メディア処理のほぼあらゆる場所で使われているライブラリだ。そのFFmpegに、21個のゼロデイ脆弱性が発見されたというニュースが流れている。
FFmpegは世界中のWebサービス、放送システム、IoTデバイス、クラウドプラットフォームに組み込まれている。「自分たちは使っていない」と思っている組織でも、利用しているSaaSやOSSの依存関係にFFmpegが含まれているケースは珍しくない。
直近の対応として、まず自社サービスの依存ライブラリを確認することを勧めたい。npm ls、pip show、あるいはコンテナイメージのSBOM（Software Bill of Materials）を確認し、FFmpegのバージョンを把握しておく必要がある。
長年使われているライブラリほど、「まさかここに」という場所に潜んでいる。OSSの安全性は導入時だけでなく、継続的な追跡が必要だと改めて気づかされる出来事だ。
まとめ
今週のトレンドを振り返ると、一つの軸が見えてくる。「型安全性」「エージェントの信頼性」「AIの内部検証」「依存ライブラリのリスク」——どれも「信頼できるシステムをどう作り・維持するか」という問いへの答えだ。
AIが実際にインフラを動かす時代に入り、その信頼性をどう担保するかがエンジニアリングの核心になりつつある。TypeScriptのnever型が型システムの「穴をふさぐ」ように、安全性への投資は地味だが、後から気づいたときには手遅れになる類の問題だ。
来週も引き続き、技術の動向を追いかけていきたい。