概要 Fortinet は2026年4月4〜5日、エンドポイント管理製品 FortiClient EMS に存在する深刻な脆弱性 CVE-2026-35616 に対する緊急ホットフィックスを公開した。CVSS スコアは 9.1（Critical）で、未認証のリモート攻撃者が API の認証・認可保護を完全にバイパスし、任意のコードやコマンドを実行できる。watchTowr のハニーポットが記録した最初の悪用は2026年3月31日にさかのぼり、Fortinet も公式に「野放し状態での悪用（exploited in the wild）を確認済み」と認めている。発見者は Defused Cyber の Simo Kohonen および Nguyen Duc Anh で、「週初めにゼロデイとして悪用を観測した」と報告している。 脆弱性の技術的詳細 本脆弱性は CWE-284（不適切なアクセス制御）に分類される。攻撃者は細工したリクエストを送信するだけで FortiClient EMS の API 認証・認可保護を迂回でき、特権やユーザー操作を一切必要としない。悪用に成功した場合、エンドポイント管理インフラへの不正アクセスや、管理下にある端末データの侵害、さらには管理機能を通じた横断的な侵害につながるリスクがある。インターネットに直接公開されている EMS 環境は特に危険度が高い。 影響を受けるバージョンは FortiClient EMS 7.4.5 および 7.4.6 で、7.2 系ブランチは対象外とされている。 対応方法 Fortinet はバージョンごとに以下のホットフィックスを提供しており、「脆弱性を完全に防止するのに十分」と声明している。 対象バージョン ホットフィックス 7.4.5 7.4.5.2111 7.4.6 7.4.6.2170 恒久対応版として FortiClient EMS 7.4.7 への修正組み込みも予定されている。すでに悪用が確認されているため、対象バージョンを運用するすべての組織はホットフィックスの緊急適用を最優先とする必要がある。また、ネットワーク境界での EMS へのアクセス制限を合わせて検討することも推奨される。

概要 GoogleリサーチとRochester Institute of Technologyの研究者らは、AIモデルの評価に広く使用されているベンチマーク手法に根本的な問題があることを明らかにした。現行の標準的なアプローチでは、1テスト例あたりの評価者数が3〜5人程度に留まっているが、この数は統計的信頼性を担保するには不十分であり、人間の意見の多様性を系統的に過小評価していると指摘している。研究チームは、信頼性の高い評価を行うためには少なくとも10人の評価者が必要だと結論付けた。 研究では毒性検出、チャットボットの安全性、異文化間の不快コンテンツ評価など、人間の判断が特に重要な5つのデータセットを対象に分析を実施した。これらの領域では文化的・個人的背景による意見の相違が本質的な意味を持つにもかかわらず、多数決によって単一の「正解」に収束させる従来手法では、そうした多様性がノイズとして排除されてしまう。 技術的な詳細 研究が提示する最も重要な知見は、アノテーション予算の配分戦略にある。評価目的に応じて最適な配分方法が異なることが示されており、単純に評価者を増やすだけでは問題は解決しない。 精度指標（多数決による一致率）を測定する場合：テスト例の数を増やし、1例あたりの評価者数を少なくする方が効率的。追加の評価者による限界的な情報価値は低い。 人間の回答分布の多様性を捉える場合：テスト例を減らし、1例あたりの評価者数を大幅に増やす必要がある。分布を考慮した評価指標（総変動量など）は直感に反して、必要な総アノテーション数が最も少なくて済む。 研究チームは、合計1,000件程度のアノテーション予算でも、適切に配分すれば信頼性の高い結果が得られると述べている。問題はリソース不足ではなく、配分の設計にある。 業界への影響と今後の課題 この研究はAI分野で広く依拠されているベンチマークの根拠を揺るがす。安全性評価やモデル比較に用いられる既存の指標が信頼性を欠いている可能性があり、特に高リスク領域での実装判断に影響を及ぼしかねない。 研究者らは、人間の意見の相違をノイズではなく意味のあるシグナルとして捉える「分布考慮型評価指標」への移行を推奨している。AI評価の方法論を根本から見直すことで、より実態に即したモデル比較が可能になるとして、業界全体でのベンチマーク設計の改革を求めている。

概要 OracleのJava向けマイクロサービスフレームワークHelidonがバージョン4.4.0をリリースした。本リリースでは、LangChain4jを通じたエージェント型AIパターンのサポート、新しいJSON処理ライブラリの導入、Oracle Java Verified Portfolio（JVP）への認定対応、そしてOpenJDKのリリースサイクルとの連携強化という4つの大きな柱が盛り込まれている。 Helidon 4.xはJava 21以降の仮想スレッド（Project Loom）を全面的に活用したウェブサーバー「Helidon Níma」を基盤としており、4.2.0で導入されたHelidon Injectによる依存性注入モデルをさらに拡充し続けている。 AIエージェント統合と宣言的プログラミングモデルの拡張 4.4.0の目玉機能のひとつが、LangChain4jとの統合によるエージェント型AIサポートの強化だ。ワークフローのオーケストレーションや動的なエージェント管理が可能となり、開発者は設定ドリブンな宣言的スタイルでAIエージェントを定義できる。マルチエージェント構成といったパターンもHelidonアプリケーションに組み込みやすくなった。 宣言的プログラミングモデル（Helidon Declarative）にも7つの機能が追加された。メトリクス、トレーシング、セキュリティ、バリデーション、WebSocketサーバー、WebSocketクライアント、そしてWebServer CORS設定がアノテーションベースで扱えるようになり、コード量を削減しながら一貫した設定管理が行える。 新しいHelidon JSONライブラリとJVP認定 新たに導入されたHelidon JSONライブラリは、仮想スレッド向けに最適化されたJSON処理の実装だ。コンパイル時のコード生成とアノテーションプロセッサーを活用することで、実行時リフレクションを排除し、型安全な変換をオーバーヘッドなく実現している。軽量かつHelidonの仮想スレッドモデルとの親和性が高い点が特徴だ。 また、HelidonはOracleが新たに立ち上げた**Java Verified Portfolio（JVP）**に参加した。JVPはOracleが検証・推奨するJavaツール、フレームワーク、ライブラリの厳選リストだ。エンタープライズ用途でHelidonを採用する組織にとって、信頼性の担保となる認定だ。 OpenJDKリリースサイクルとの連携と今後の展望 Oracleは今後、HelidonのリリースをOpenJDKの6ヶ月サイクルに合わせる方針を発表した。2026年9月のJDK 27リリースに合わせて、HelidonもOpenJDKが採用する「tip and tail model」へ移行し、バージョン番号をJDKに揃える形（Helidon 27）となる見込みだ。これにより、最新のJava機能を迅速に取り込みながら、長期サポート版との整合性も維持しやすくなる。 AIワークロードへの対応とJavaエコシステムとの密な連携を強化したHelidon 4.4.0は、クラウドネイティブなJavaアプリケーションにAI機能を組み込もうとする開発チームにとって注目のリリースといえる。

概要 NVIDIAは2026年3月31日、カスタムAIチップ分野で競合するMarvell Technologyに対して20億ドル（約2,900億円）の戦略的投資を行うと発表した。同時に、NVLink Fusionを核としたAIデータセンター向けカスタムシリコンおよびシリコンフォトニクスの共同開発パートナーシップを締結した。表面上は競合関係にある2社が手を組む形となり、業界に大きな波紋を呼んでいる。 NVLink Fusionとは何か 今回の連携の核となるのがNVLink Fusion技術だ。これはNVIDIAのNVLinkインターコネクト標準を、サードパーティが開発したカスタムASIC（特定用途向け集積回路）と組み合わせて利用可能にするものである。NVIDIAのGPUだけでなく、他社設計のカスタムチップもNVLinkエコシステムに参加できるようになる。 Tom’s Hardwareはこの仕組みを「カスタムASICに対する事実上の税（tax on custom ASICs）」と評している。つまり、カスタムチップを利用するクラウド大手がAIインフラを構築する際も、NVLink Fusionを採用する限りNVIDIAのインターコネクト標準に依存し続けるという構造だ。 競合他社への「ソフトなエコシステム囲い込み」 皮肉なことに、MarvellはAmazon、Microsoftといったハイパースケーラーに対してカスタムAIチップ（TrainiumやMaiaなどNVIDIA競合製品のOEM設計を担う）を提供しており、これらの企業はまさにNVIDIA製品の代替を目指している。なお、GoogleのTPUについてはBroadcomが設計パートナーを務めている。 にもかかわらずNVIDIAがMarvellへ巨額投資を行った背景には、チップ競争ではなくインターコネクト標準の支配を通じて市場での優位性を維持する狙いがある。ハイパースケーラーが自社カスタムチップを採用しても、NVLink Fusionというデータセンターの「配管」部分を押さえることで、NVIDIAはエコシステム全体への影響力を保ち続けることができる。この手法は「ソフトなエコシステム囲い込み（soft ecosystem lock-in）」とも呼ばれており、競合他社の独自路線を間接的に抑制する効果を持つ。 今後の展望 NVIDIAはシリコンフォトニクスの共同開発も視野に入れており、超高速・低遅延のAIデータセンター向けインターコネクトの次世代標準を狙っている。カスタムチップの隆盛によってGPU市場シェアが脅かされる中、NVIDIAがハードウェア競争から「インフラ標準」の競争へと戦場をシフトしつつある動きは、AIインフラ業界の構造を大きく変える可能性がある。

概要 2026年4月初旬、セキュリティ研究者はnpmレジストリに公開された36個の悪意あるパッケージを発見した。これらはすべて strapi-plugin- という命名パターンを持ち、正規のStrapi CMSプラグインに見せかけていた。strapi-plugin-cron、strapi-plugin-database、strapi-plugin-server など実在しそうな名前を使い、すべてバージョン3.6.8として統一して公開されていた。4つのソックパペットアカウント（umarbek1233、kekylf12、tikeqemif26、umar_bektembiev1）が13時間という短期間のうちに一斉にアップロードしており、組織的な攻撃の痕跡が明白だった。SafeDepの動的分析パイプラインが strapi-plugin-events を最初に検出し、C2通信シグナルおよび秘密情報の探索行動が確認されたことで調査が始まった。 攻撃チェーンの技術的詳細 このサプライチェーン攻撃は npm install の実行時に postinstall.js スクリプトが自動的に起動することで始まる。SafeDepの分析によれば、8段階（他の調査では11段階）に及ぶ攻撃チェーンが展開される。 まず Redis RCEとして、CONFIG SET コマンドを悪用し、crontabエントリ、PHPウェブシェル（/app/public/uploads/shell.php）、SSHキーを注入する。続いてブロックデバイスへのアクセスを試みてraw diskを読み取り、Dockerコンテナ脱出を経てリバースシェル（ポート4444でbash、ポート8888でPython）を展開する。 情報窃取フェーズでは、.env ファイルやStrapi設定ファイル、PEM/keyファイルを収集し、Redisの完全ダンプとKubernetesシークレットを抽出する。また、ハードコードされた認証情報（user_strapi / 1QKtYPp18UsyU2ZwInVM）でPostgreSQLへの不正接続も試みる。最終的に /tmp/.node_gc.js への永続インプラントを書き込み、144.31.107.231:9999 のC2サーバーと通信を確立する。C2エンドポイントは /c2/<id>/（約5分間のC2コマンドポーリング）、/db/<id>/（データベース窃取）、/shell/（3秒間隔の永続シェルセッション）に分かれており、インプラントが残存している限り攻撃者は継続的なリモートアクセスを維持できる。 標的と攻撃者の意図 攻撃者が特定の企業を狙っていたことは、コード内に埋め込まれた手がかりから明らかだ。暗号資産決済プラットフォームであるGuardarianに関連するモジュール名や、HOT_WALLET、COLD_WALLET、MNEMONIC といったウォレット関連の文字列の探索が確認されている。また、永続インプラントの書き込み条件がホスト名「prod-strapi」に限定されていることから、攻撃者がターゲットの本番環境構成を事前に把握していた可能性が高い。Jenkins CI/CDパイプラインへの言及もあり、開発インフラ全体を侵害しようとする意図がうかがえる。 見分け方と推奨される対応策 正規のStrapiパッケージは @strapi/ スコープ付きで公開されているが、悪意あるパッケージはスコープなしで公開することで開発者の信頼を悪用していた。このタイポスクワッティングおよびブランドなりすましの手口は、依存関係を機械的にインストールする開発者にとって見分けにくい。 侵害が疑われる場合、/tmp/.node_gc.js、/tmp/vps_shell.sh、/app/public/uploads/shell.php の存在確認と削除、crontabにおける node_gc 参照の除去、IPアドレス 144.31.107.231 への通信遮断を直ちに行う必要がある。また、JWT シークレット、データベース認証情報、APIキーを含む全認証情報のローテーションが推奨される。予防策としては、npm audit や Snyk、Dependabot の導入、組織ポリシーによるスコープなしパッケージの拒否設定が有効だ。

概要 TigerFSは、PostgreSQLデータベースをディレクトリとしてマウントし、ls、cat、find、grepなどの標準Unixコマンドでデータを操作できる実験的なオープンソースファイルシステムだ。TigerData（旧Timescale）がMITライセンスのもとGitHub（timescale/tigerfs）で公開したこのツールは、APIやSDKを介さずにデータベースとやり取りできる新しいアプローチとして開発者の注目を集めている。AIエージェントがデータベースの状態を共有・管理する用途でも活用できる設計になっており、AI開発との親和性も意識されている。 2つの動作モード TigerFSは「ファイルファースト」と「データファースト」の2つのワークフローをサポートしている。ファイルファーストモードでは、開発者がファイルをディレクトリ構造（todo / doing / done など）で整理し、アトミックな書き込みと自動バージョニングによって並行アクセスや状態管理を実現する。AIエージェントが複数の状態を共有する際に特に有用なアプローチだ。 データファーストモードでは、既存のPostgreSQLデータベースをマウントして、Unixツールでデータを探索できる。ファイルシステムのパスにフィルタやソート条件を含めることでデータベースクエリに変換されるため、SQLを書かずにデータを取得・確認できるのが特徴だ。 技術的な詳細 LinuxではFUSE、macOSではNFS経由でマウントに対応しており、外部依存なしで動作する。各ファイルはデータベースの1行に対応し、ACID保証が維持される。あらゆるPostgreSQLインスタンスやマネージドサービスと連携可能で、既存のデータベース環境にそのまま組み込める点も評価されている。開発者コミュニティからはパフォーマンス特性や制限事項への関心が寄せられており、小規模データセットの管理や設定ファイル的な用途において有用との声も上がっている。 展望 TigerFSはまだ実験的なプロジェクトとして位置づけられているが、データベースへのアクセスを「ファイル操作」という直感的なインターフェースで統一するというコンセプトは、特にAIエージェントがファイルシステムを通じてデータを読み書きするユースケースで新たな可能性を示している。SQL不要のデータ探索を実現するこのアプローチが、今後どのような形で発展するか注目される。

概要 Cloudflareは2026年4月1日、Dynamic Worker Loaderのオープンベータ公開を発表した。これはWorkersがランタイム時に動的に指定されたコードで新しい隔離されたサンドボックスを生成できる機能であり、AIエージェントが生成したコードを安全に実行するための基盤として設計されている。コンテナと比べて起動速度は約100倍、メモリ効率は10〜100倍優れるとされており、高頻度・低レイテンシが求められるAIコーディングエージェントのコード実行環境として注目されている。 Cloudflareはこの取り組みを「Code Mode」というコンセプトとともに提唱している。従来のAIエージェントは目的達成のためにツール呼び出しを逐次繰り返すアーキテクチャが主流だったが、Code Modeでは「エージェントが型付きAPIに対してコードを書いて実行することでタスクを遂行すべき」という考え方をとる。実際にMCPサーバーをTypeScript APIに変換して検証したところ、従来のツール呼び出しパターンと比較してトークン使用量を81%削減できたと報告されている。 技術的な詳細 Dynamic WorkersはV8アイソレートを基盤としており、1件あたりの起動時間は数ミリ秒、メモリ使用量は数メガバイトに抑えられている。ローディングモードは2種類あり、load() はエージェント生成コードを1回限り実行するワンショット向け、get() はIDでWorkerをキャッシュして複数リクエストをウォームな状態で処理するケースに対応している。 API定義にはOpenAPI仕様ではなくTypeScriptインターフェースを採用している点も特徴的だ。チャットルームAPIの例では、TypeScriptで約15行で記述できる仕様がOpenAPI（YAML）では60行以上になる。LLMにとってのトークン効率と開発者の可読性を優先した設計判断とされている。 セキュリティは多層防御で構成される。Cap’n Web RPCブリッジによるセキュリティ境界の透過的な越境、送信HTTPリクエストをインターセプトして秘密情報へのエージェントの直接アクセスを防ぐクレデンシャルインジェクション、リクエストごとにアイソレートを破棄するエフェメラルなアイソレーション、そしてV8セキュリティパッチの数時間以内の自動適用、カスタムセカンドレイヤーサンドボックス、ハードウェアレベルのMemory Protection Keys（MPK）、学術研究者と共同開発したSpectre対策が組み合わされている。 エコシステムと事例 Cloudflareはあわせて関連ライブラリ3点を公開している。@cloudflare/codemode はDynamic Workersを通じてモデル生成コードをAIツールに対して実行するためのパッケージ、@cloudflare/worker-bundler はランタイムでのnpm依存関係の解決とバンドリングを担い、@cloudflare/shell はトランザクショナルなバッチ書き込みやSQLiteバッキング、R2永続ストレージを持つ仮想ファイルシステムを提供する。 本番採用事例としては、チャットベースのCRUDアプリ構築プラットフォームであるZiteが既にDynamic Workersをデプロイし、1日あたり数百万回の実行リクエストを処理していると報告されている。料金はベータ期間中は無料で、正式リリース後はユニークWorker1件あたり1日$0.002に標準のCPU・呼び出し料金が加算される見込みだ。言語サポートはJavaScriptが実質的な主軸で、PythonとWebAssemblyも技術的には動作するものの起動時間の観点から実用上は限定的とされている。 今後の展望 Cloudflareはこのソリューションを、エージェント実行環境をめぐるアーキテクチャ論争の文脈で明確に位置づけている。永続的なメモリを持つ長寿命エージェント環境を好む陣営に対し、Cloudflareはリクエストライフサイクルに合ったエフェメラルな実行レイヤーを推進する立場を取り、高ボリューム・ウェブ向けシステムへの適合を強調している。AIエージェントのインフラ競争が激化する中、V8アイソレートという既存技術資産を活用したCloudflareのアプローチが他プラットフォームにどのような影響を与えるか注目される。

概要 米国のテレヘルス大手Hims & Hers Healthは2026年4月、カスタマーサポートプラットフォームのZendeskへの不正アクセスによりデータが漏洩した可能性があると顧客に通知した。侵害は2026年2月4日から7日にかけて発生し、同社は2月5日に検知、3月3日に侵害を確認した後、4月2日に顧客への通知を行った。漏洩した可能性のあるデータはサポートチケットに含まれる氏名・連絡先情報などの個人情報に限定されており、医療記録や医師との通信は侵害されていないと強調している。 攻撃手法と攻撃者の帰属 BleepingComputerの報道により、今回の攻撃は悪名高いサイバー恐喝グループShinyHuntersによるものと判明した。攻撃者はOkta SSOアカウントの侵害を足がかりとして、Zendeskのインスタンスへの不正アクセスを実現し、複数の組織から数百万件に及ぶサポートチケットを窃取したとされる。Hims & Hersの被害はこのキャンペーンの一部に過ぎず、同一手法によりManoMano（2026年2月）やCrunchyroll（2026年3月）なども被害を受けており、Zendeskを利用する多数の企業が連続して標的とされていたことが明らかになっている。 影響範囲と同社の対応 Hims & Hersは影響を受けた顧客数や漏洩データの全容を公式には開示していないが、被害顧客に対して12か月間の無料クレジットモニタリングを提供するとともに、フィッシング攻撃への警戒強化と信用情報における不審な動きの監視を呼びかけている。今回の事例は、テレヘルス企業が保有する機微な情報を狙った攻撃の深刻さを改めて示しており、サードパーティのSaaSプラットフォームを経由したサプライチェーン型の侵害リスクへの対策が業界全体で急務となっている。

概要 Neovimは2026年3月29日、メジャーリリースとなるv0.12.0を公開した。今回の最大のハイライトは、外部ツールへの依存を不要にする組み込みパッケージマネージャー vim.pack の導入だ。これまでlazy.nvimやpacker.nvimといったサードパーティのプラグインマネージャーに頼っていた管理フローを、Neovim本体で完結できるようになった。コミュニティからの反応はGitHub上で525件以上のリアクションを集めるなど、非常に好評を博している。 LSP・補完の大幅強化 LSPまわりの改善も今回の目玉だ。補完候補にカラーシンボルのプレビューやインライン補完が追加されたほか、新しい対話型コマンド :lsp によってLSPクライアントを一元管理できるようになった。コードレンズが仮想行として表示されるよう変更されたことで視認性も向上した。さらに textDocument/diagnostic・ textDocument/documentColor・ワークスペース診断・動的登録など多数のLSP仕様への対応も追加されている。デフォルトキーバインドには grt（型定義へジャンプ）と grx（コードレンズ実行）が新たに加わった。 Lua APIの拡充とHTTP対応 Lua APIにも注目すべき追加がある。vim.net.request() の追加により、外部ライブラリを使わずにNeovim内から直接HTTPリクエストを発行できるようになった。そのほか vim.list.unique()・vim.list.bisect() などのリスト操作関数、vim.text.diff()（旧 vim.diff）、フローティングウィンドウへのステータスライン表示・タブページ間移動のサポートなども追加された。新オプションとして 'autocomplete'・'pummaxwidth'・'pumborder'・'busy' などが導入されている。 パフォーマンス改善と実験的Zigビルド パフォーマンス面では、i_CTRL-R によるレジスタ挿入が従来のユーザー入力シミュレーション方式から貼り付け方式に変わり約10倍高速化。LPeg実装によりglobパターンマッチングが約50%高速化された。LSPはトークンリクエストを表示中のビューポートに限定するよう最適化され、帯域幅の節約にも貢献している。また実験的機能としてZigベースのビルドシステムが導入された。 破壊的変更と注意点 既存の設定に影響する破壊的変更もいくつか含まれる。vim.diagnostic.disable() などの旧来のDiagnostics APIが削除され、JSONのnull値が nil から vim.NIL に変更された。セマンティックトークン関数が start()/stop() から enable() にリネームされるなど、プラグイン開発者は対応が必要になる場合がある。Windowsでは外部コマンド実行時にカレントディレクトリを検索しなくなるセキュリティ強化も施された。アップグレード前に公式チェンジログでの確認が推奨される。

概要 Rustは全WebAssemblyターゲットにおいて、リンカオプション --allow-undefined フラグを廃止すると発表した。Rust 1.96（2026年5月28日リリース予定）から、未定義シンボルはデフォルトでエラーとして報告されるようになる。この変更はネイティブプラットフォームとの動作の一貫性を高め、WebAssemblyモジュールのビルド時における誤設定やミスの早期発見を可能にするものだ。 変更の背景と理由 従来、WebAssemblyバイナリの生成には wasm-ld リンカが使われており、--allow-undefined フラグによって未解決シンボルをエラーとせず、WebAssemblyモジュールのインポートとして変換する動作が許容されていた。たとえば、Rustコード中で外部C関数 mylibrary_init を宣言した場合、リンク時にエラーを出さず (import "env" "mylibrary_init" ...) としてWasmモジュールへ埋め込まれる仕組みだった。 この動作にはいくつかの問題点があった。関数名のタイポがあってもコンパイルエラーにならず、実行時に壊れたシンボルがインポートされるリスクがあった。また、必要なライブラリが欠落していても警告が出ずに動作しないモジュールが生成される可能性があった。Rustの公式ブログでは「misconfiguration or mistakes in building can result in broken WebAssembly modules being produced（ビルドの誤設定やミスが壊れたWebAssemblyモジュールの生成につながる）」と指摘している。ネイティブプラットフォームでは未定義シンボルはデフォルトでエラーとなるため、WebAssemblyだけが異なる挙動を取っていた点も問題視されていた。 移行方法と影響範囲 Rust公式は、大多数のユーザーはこの変更による影響を受けないとしている。ただし、--allow-undefined の動作に明示的に依存していた場合は対応が必要だ。対処法として2つの方法が案内されている。 1つ目は #[link] 属性を使った明示的なモジュール指定で、インポートするシンボルが属するWasmモジュール名を wasm_import_module で明記する方法だ。2つ目は -Clink-arg=--allow-undefined をコンパイラフラグとして渡すことで、旧来の動作を維持する方法だ。問題が生じた場合は rust-lang/rust リポジトリへのissue報告が推奨されている。変更はすでにPR #149868としてまとめられており、ナイトリービルドへの統合を経てRust 1.96での正式リリースが計画されている。