2026-06-15の技術動向：Zigネイティブフレームワーク、K8sストレージ更新、AIエージェントの監査問題、Valkey耐久性、Anthropicモデル停止

zero-native — ZigベースのクロスプラットフォームネイティブアプリフレームワークのOSS公開

Vercel Labsがzero-nativeをオープンソースで公開した。Zigで書かれたクロスプラットフォームのネイティブアプリフレームワークだ。

Electronを避け、OS標準のWebViewを使ってアプリを軽くする。フロントエンドはNext.jsでもReactでもSvelteでもいい。バックエンドをZigで書く。これだけ聞くとTauriのZig版みたいな立ち位置。

気になるのはZigを選んだ理由。Rustよりインクリメンタルコンパイルが速い。Roc言語の作者であるRichard Feldmanが、コンパイラをRustからZigにフルリライトしたときのコメントが引用されている。「Rustのコンパイルは遅い。Zigは速い。これだけが理由じゃないが、大きな理由だ」。フィードバックループが遅いと生産性も楽しさも削られる。この感覚、わかる。CIでビルドに5分かかるときのあの徒労感。

ZigはC ABIと直接相互運用できるのもポイント。

（C ABIとは、C言語で定義された関数呼び出しやデータ構造の標準的なバイナリ形式のことであり、多くの言語が共通言語として利用している）FFIバインディングを生成するビルドコストがいらない。

（FFI: Foreign Function Interface。異なる言語で書かれた関数を呼び出すための仕組み）システムヘッダをインクルードしてプラットフォームSDKを直接呼ぶ。シンプル。

セキュリティはケイパビリティベース。DenoやTauriと同じ方向で、フロントエンドが勝手にローカルファイルを読んだりネイティブAPIを叩いたりしない。Zigコードが明示的にコマンドを登録し、app.zonマニフェストで権限を付与する。

ただ懸念もある。OS標準WebViewに頼るということは、OS間でレンダリングが変わるということ。WebViewが見つからなかったりバージョンが古かったりするとアプリが起動しない。この問題、Tauriでも議論されてきた。回避策としてCEFでChromiumをバンドルする逃げ道は用意されている。でもそれ、結局Electronと同じ問題を抱えないか。

今はmacOSとLinuxだけ。Windowsとモバイルは作業中。Redditでも「Vercelの人たちがこれで何か作ったの？TauriやElectronと比べてどうなのか分からない」という声があった。実際のプロジェクトで使ってみないと何とも言えない。

自分のワークフローで考えると、社内ツールをElectronから移す候補としては気になる。メモリ使用量が減るならコンテナで詰めやすくなるし、CIのビルド時間も短くなる可能性がある。でも実験段階と明記されているので、今すぐ本番には乗せない。まずは手元で小さなツールを組んでみて、インクリメンタルビルドの速さを体感してみたい。

Kubernetes SIG Storage — ストレージ機能のGA・Beta昇格とデータ保護の強化

Kubernetes v1.36でストレージ周りがかなり動いてる。SIG Storageのスポットライト記事を読んでいて、いくつか気になる機能がGAやBetaに昇格していた。

VolumeGroupSnapshotがGAになった。複数のPersistentVolumeを同時にスナップショット取れる機能だ。データベースみたいにデータ用とログ用でボリュームを分けているワークロードでは、バラバラのタイミングでスナップショットを取ると整合性が保証されない。VolumeGroupSnapshotがあれば原子性の保証されたクラッシュ整合性スナップショットが取れる。うちでもStatefulSetでPostgreSQLを動かしていて、WAL用とデータ用でPVCを分けている構成がある。今はバックアップのタイミングを合わせるのにPgBackRestに頼っているけれど、インフラレイヤーで整合性が保証されるならバックアップ戦略の選択肢が増える。

CSI Changed Block Tracking（CBT）がBetaに。前回のスナップショット以降に変更のあったブロックだけを転送できる仕組み。フルバックアップを毎回取る必要がなくなるので、大容量のボリュームを扱っているチームは転送量と時間を大幅に削減できるはず。どのCSIドライバが対応しているかはまだ確認が必要。Betaということで、本番投入はもう少し待つべきか。

COSI（Container Object Storage Interface）も進んでいるらしい。

（COSIは、CSIがブロック/ファイルストレージを扱うのに対し、S3のようなオブジェクトストレージのプロビジョニングを標準化しようとする仕様）オブジェクトストレージのバケットをKubernetesから標準的なインターフェースでプロビジョニングできる仕組み。S3互換のバケットをTerraformで管理している今の構成とどう住み分けるのか、あるいは統合できるのか。アプリケーションからバケットのライフサイクルを制御できるのは確かに便利だ。

Kubernetesは元々ステートレスなワークロード向けだった。それがデータベースも載せるようになり、ストレージの要件がどんどん厳しくなっている。AIワークロードが当たり前になればデータ量はさらに膨らむ。SIG StorageがData Protection WGを出してデータ保護のギャップを埋めようとしているのは、その流れだろう。

ログは長い間、奇妙な場所にあった。出力はしている。でも誰も読まない。インシデントが起きてから初めてS3バケットやSIEMを掘り返す。そして必ず「必要なものをログ取ってなかった」に行き着く。

この記事が指摘するのは、その問題がAIエージェントの台頭で致命的になりつつあることだ。Gartnerの予測によれば、2028年にはエンタープライズソフトウェアの33%がagentic AIを含むようになる。2024年時点では1%未満だ。急激な移行だ。AIエージェントはすでにリソースのプロビジョニング、購入処理、アカウント設定の変更、データ削除を自律的に実行している。これらの操作が人間の介在なしに行われるとき、従来のログに何が記録されるのか。「何かが起きた」ことは残る。でも「誰が」「なぜ」「どの権限で」は抜け落ちる。

規制側の圧力も変わっている。EUのNIS2指令（2022/2555）は重要インフラにおける監査証跡のハードルを上げた。SECの開示ルールも変更された。監査人はもうログポリシーのスクリーンショットでは受け付けない。クエリ可能で、タイムスタンプ付きで、特定イベントと紐づいたログそのものを求める。企業の調達プロセスも同様で、セキュリティレビューの質問票が長くなり、法務チームがベンダー評価の段階で監査ログのサンプルを要求する。ログを出力できない製品は、2年前なら勝てた商談を落とし始めている。

Verizonの2026年DBIRが分析した22,000件以上の確認済み侵害データを見ると、脆弱性の悪用が初認アクセスの31%を占め、19年の歴史で初めて認証情報の悪用を上回った。サードパーティの関与は前年比60%増で48%に達している。パッチ適用の平均期間は8ヶ月。このスピード感の中で、ログが「事後検証」か「推測」の違いを生む。

自分のワークフローに戻る。Kubernetesクラスタでマイクロサービスを運用しているが、ログは主にコンテナの標準出力をFluentdで集約し、Datadogに送っている。人間のオペレーターがkubectlで操作した記録はaudit logとして取っている。しかしGitHub CopilotやClaudeがコード生成に関与した場合、その「判断の文脈」はどこにも残らない。AIエージェントが自律的にリソースを操作する世界では、「何が起きたか」だけでなく「誰が承認し、スコープ内だったか」まで含む監査証跡が必要になる。ログと監査証跡の差は、インシデントの前に立たされたときに初めて現実のものになる。

AWSがElastiCache for Valkeyに耐久性機能を追加した。

（Valkeyは、Redisのライセンス変更を受けてコミュニティによってフォークされたオープンソースのインメモリデータストア）これまでElastiCacheは「キャッシュ」として使うのが前提だった。障害時のデータ保持は保証されず、データが消えたらソースから再構築するのが正しい使い方。それがValkey 9.0から同期・非同期の耐久性オプションを選べるようになった。

同期書き込みは最低2つのAZにレプリケーション完了してからACKを返す。データ損失を最小限に抑える代わり、書き込みレイテンシーは上がる。非同期書き込みはレプリケーション前にACKを返すのでレイテンシーは低いまま。ただし最大10秒のデータ損失リスクがある。10秒を超えるとプライマリノードが書き込みを一時的に拒否する。CloudWatchのDurabilityLagメトリクスで遅延を監視できる。

へえ、と思ったのは用途の例に「AI agent memory」「RAG knowledge bases」が挙がっていたこと。最近のAI関連のワークロードで、低レイテンシーの読み書きとある程度の永続性を両立させたい需要が増えているのは間違いない。うちのプロジェクトでもセッションストアにRedis系を使っているが、障害時のデータ損失が許容できないケースはある。

気になるのはMemoryDBとの棲み分け。Redditでも「MemoryDBの代わりになるのか」という声が出ている。同じRedis互換で低レイテンシー＋耐久性を謳うなら、どこが違うのか。料金体系やスループットの特性で使い分けるんだろうか。このあたりはまだ情報が足りない。

Corey Quinnの「キャッシュとプライマリデータストアを混同するな」という警告はもっとも。耐久性オプションがついたからといって、何でもElastiCacheに突っ込むのは危険。SLAの前提をちゃんと理解して選ぶべき。

金曜の夜、Anthropicが最新フラッグシップモデルのFable 5とMythos 5を突然無効化した。米政府がFable 5の特定ジェイルブレイクを把握し、輸出規制命令を出したためだ。この命令は米国内の外国人も含む全対象者に適用される。結果として、Anthropicは全ユーザー向けにモデルを停止せざるを得なかった。

ジェイルブレイクの詳細は不明。Anthropic側は「軽微な脆弱性」で「他の公開モデルと同程度」だと主張している。一方でFable 5のモデルカードには「公開された汎用ジェイルブレイクが見つかった場合は迅速に防御を更新する」と書かれている。今回は汎用ではなく特定の問題らしい。

ここで話がややこしくなる。Amazonの研究者がFable 5のジェイルブレイクを発見し、Amazon CEOのAndy Jassyが財務長官のScott Bessentを含む米政府高官に報告した。サイバー攻撃支援に悪用可能な経路だった。政府はAnthropic CEOのDario Amodeiに対し、ガードレール改善かモデル停止を求めた。Darioは拒否した。

大統領科学技術諮問委員会共同議長のDavid Sacksがこの件に言及。「信頼できるパートナーと米政府が重大と判断しているのに、軽微と言い張るのはAI安全企業を名乗るAnthropicと矛盾する」と指摘。実際、AnthropicはMythos 5の公開リスクを理由に安全主義を標榜してきた。その企業が消費者向けモデルの提供継続を安全より優先したと批判されている。

自分のワークフローで考えると、Claudeを日常的に使っている身としてはモデル突然停止は困る。Fable 5が安全プロンプトを検知するとOpus 4.8にフォールバックしていたという報告も気になる。本番でAPI使っているチームは、この手の停止に備えたフォールバック先を常に確保しておく必要がある。

輸出規制でAIモデルを止めるという前例ができた。次はOpenAIやGoogleも同じ基準に晒される可能性がある。非決定的なモデルである以上、別のジェイルブレイクが出るのは時間の問題か。修正版が出て規制が解除されるまでは、この状況が続く。

参照記事

記録日: 2026-06-15