技術トレンド調査レポート 2026-08-27
公式発表を中心に、実装・運用に直接影響する更新を確認した。X上で見つけた候補は、公式情報で裏付けられたものだけを採用している。
08:30 JST
Vercel Run SDK：agent生成のJavaScript/TypeScriptを「狭い権限」で実行する
Vercelは8月25日、agentが生成したJavaScript／型情報を除いたTypeScriptを、アプリケーションやOSへ直接触れさせずに実行するための Run SDK を公開した。各実行はworker thread内の新しいQuickJS contextで動き、Node.jsやnetworkへ直接到達できない。アプリ側がhostFunctionsとして公開した操作だけを呼べるため、データベースclientやcredentialをagentの実行空間へ渡さずに済む。
実務上の核心は、agentに汎用的なHTTP clientやdatabase handleを渡す代わりに、orders.refund(id)のような業務操作を小さな境界として渡せることだ。その境界で認可を行い、機微な操作ではapprovalを要求して中断・再開できる。中断前に完了したhost functionの結果は記録され、承認後の再開時に同じ副作用を繰り返さない設計になっている。
ただしsandboxは認可の代替ではない。host functionはtrusted application codeのままなので、呼び出し元・対象resource・引数のvalidationを通常どおり実装する必要がある。また無限loopや過大な返却値に備え、timeoutとmemory limitをアプリのriskに合わせて下げるべきだ。OS隔離、package install、process実行が必要な用途はRun SDKではなく別のsandboxを選ぶ、という製品上の境界も明確にされている。
guppi向けの見方: 将来、サポートや管理画面でagentに顧客情報を検索・更新させるなら、「agentへDB接続を渡す」より、読み取り・更新・返金などを用途別のhost functionに分け、更新操作だけは人の承認を挟む構成が扱いやすい。まずは読み取り専用の小さなtool群、timeout、監査ログから始めるのがよい。
- 確認状況: Vercel公式記事で実行環境、host function、approvalによる中断・再開、resource limit、対応runtimeを確認。
- 重要度: 🟡 設計の参考
- Links: Introducing Run SDK / Run SDK documentation
Cloudflare Flagship：app単位のAPI tokenでCI・backendの権限を絞る
Cloudflareは8月26日、Flagship向けに指定したappだけへアクセスできるAPI tokenを追加した。従来のaccount全体に及ぶ権限を使わず、対象appとEvaluate、Read、Writeのpermissionを選べる。公式は、このtokenをWrangler、CI、backend serviceなどのtrusted server-side環境で使うことを案内している。
これは小さな権限設定に見えるが、CI secretやagent連携が増えた環境ほど効く。tokenが漏えいした時に、全appの設定変更・読み取りまで許してしまうのか、一つのappの必要操作だけに閉じ込められるのかで、初動と復旧範囲は大きく変わる。用途ごとにtokenを分け、owner・対象app・必要permission・rotation期限を記録しておけば、不要になったcredentialも消しやすい。
guppi向けの見方: Cloudflareを使うdeploy automationでは、個人用の広いtokenをCIへコピーしないことがまず重要だ。project／serviceごとのtokenを発行して、Readで足りるjobにWriteを与えない。失敗しやすいjobほど、まず権限を狭くして必要なendpointだけを追加する進め方が安全である。
- 確認状況: Cloudflare公式changelogで対象resourceをapp単位に限定できること、permission種別、想定利用環境を確認。
- 重要度: 🟡 運用改善
- Links: Create app-scoped API tokens for Flagship / Cloudflare API tokens
Cloudflare AI Search：Workers AI上の6モデルを追加、model固定と評価が前提になる
Cloudflare AI Searchは8月26日、Workers AIで利用するtext generationモデルを6件追加した。DeepSeek V4 Flash／Pro、OpenAIのgpt-oss 120B／20B、Qwen3.8 27B、Kimi K2.7 Codeが対象で、context windowは128kから1M tokenまで幅がある。追加provider keyを置かずにWorkers AI経由で選べるため、prototypeの開始は簡単になる一方、モデルを何となく最新に追随させる運用は危険になる。
検索・要約・コード支援では、context長だけで品質や費用、遅延、安全性は決まらない。retrievalの再現率、引用の正確さ、tool callの失敗率、p95 latency、token cost、拒否すべき質問への挙動を、用途ごとに固定した評価setで比べる必要がある。特に1M tokenを渡せることは「渡すべき」ことを意味しない。古い文書や権限外の情報を大量に混ぜるほど、アクセス制御と観測が難しくなる。
guppi向けの見方: AI検索機能を作る時は、まず検索対象のdocument scopeを絞り、model IDを設定でpinし、少数の実データで正答・根拠リンク・応答時間を記録する。モデル切替はfeature flagで段階投入し、以前のmodelへ戻せるようにしておくと、provider更新や価格変更にも対応しやすい。
- 確認状況: Cloudflare公式changelogで追加モデル、context window、Workers AI経由の提供形態を確認。モデルの性能主張は各provider条件・自前評価で再確認が必要。
- 重要度: 🟡 試す前に評価設計
- Links: New Workers AI text generation models in AI Search / Workers AI supported models
18:30 JST
Vercel Security DashboardがGA：agent時代の設定漏れをCIで検査できる
Vercelは8月26日、全プラン向けにSecurity Dashboardを一般提供した。account／projectを横断して、2FA未設定、OIDCへ置き換えられる長期credential、公開されたpreview deployment、不要・古い環境変数などを検出し、risk順に並べる。UIだけでなく、Vercel CLIのvercel security checkでも同じ確認ができ、non-interactive環境ではJSONとして標準出力へ出せる。
重要なのは、これはWAFの検知や攻撃ログの代わりではなく、事故が起きる前の設定衛生チェックだという点である。agentや自動化でproject・preview・環境変数が増えると、個別の実装レビューでは拾いにくい「公開しっぱなし」「静的secretを使い続けている」「fork経由でworkflowへ入れる」といった横断的な不備が積み上がる。検出結果はCSVで持ち出せ、ノイズになる項目はmuteできるため、定期監査として回しやすい。
guppi向けの見方: Vercelで運用するサービスが増えたら、まず手元でvercel security check --projectを実行して結果を読む。CIへ入れる前に、2FA・preview URLの公開範囲・環境変数のsensitive指定・OIDCへ移せるcredentialを一つずつ直すのが安全だ。agentに自動修正を任せる場合も、対象projectを絞り、差分と再チェック結果を人が確認する運用にする。
- 確認状況: Vercel公式changelogとCLI documentationで、検出対象、CLI実行、CIでのJSON出力、修正可能な項目を確認。
- 重要度: 🟡 継続的な設定監査
- Links: Vercel Security Dashboard is now generally available / Vercel CLI security command
CISA KEVの8月26日追加：古いCVEでも「いま悪用されている」なら資産確認を先にする
CISAのKnown Exploited Vulnerabilities（KEV）catalogは8月26日に更新され、Microsoft SQL ServerのRCE（CVE-2019-1068）、Citrix NetScaler ADC／Gatewayの境界外操作（CVE-2026-8452）、Linux kernelのout-of-bounds write（CVE-2022-0995）、Ajax.NET Professionalのunsafe deserializationによるRCE（CVE-2021-23758）などが追加された。CVEの公開年はばらつくが、KEVは「既知の実悪用」を優先度付けに使うためのcatalogであり、古い番号を理由に後回しにしないことが肝心である。
公開Webの入口になりやすいNetScaler、database service accountで実行され得るSQL Server、OS imageや古い社内アプリへ残りがちなkernel／.NET componentは、単にpackage一覧を更新するだけでは把握しにくい。まずインターネット公開資産、VPN・reverse proxy、管理用interface、container base image、古い.NET依存を対応表にし、影響の有無とvendorの緩和策を確認する。patch不能なEOL componentは、公開停止・アクセス制限・置き換えのいずれかを期限付きで選ぶ必要がある。
guppi向けの見方: 自分のWebサービスでは、Cloudflareやhostingの外側だけで安心せず、originの管理画面・DB・VPNが外から到達できないかを棚卸しする。CIのdependency scanは必要だが、KEV対応では「どのassetが稼働していて公開されているか」というasset inventoryが先に必要になる。影響しないと確認した記録も残すと、次回の緊急確認が速くなる。
- 確認状況: CISAの公式KEV catalogとJSON feed（catalog version 2026.08.26）で、追加日、影響概要、期限を確認。個別製品の適用version・mitigationはvendor advisoryで別途確認する。
- 重要度: 🔴 公開資産・OS／.NET依存の棚卸し
- Links: CISA Known Exploited Vulnerabilities Catalog / KEV JSON feed