概要 SAPは2026年4月のパッチデーにおいて、CVSS スコア9.9の重大な脆弱性CVE-2026-27681を含む計19件のセキュリティノートを公開した。CVE-2026-27681はSAP Business Planning and Consolidation（BPC）およびSAP Business Warehouse（BW）に存在するSQLインジェクションの欠陥で、認証済みの低権限ユーザーが細工したSQL文を実行することで、データベース上のデータを読み取り・変更・削除できる可能性がある。財務データの窃取やシステム全体の侵害につながる深刻なリスクがあり、ITマネージャーには直ちにパッチを適用するよう呼びかけられている。 主要脆弱性の詳細 最も深刻なCVE-2026-27681は、「不十分な認可チェック」に起因するSQLインジェクション脆弱性だ。CVSS 9.9という最高水準に近いスコアが示す通り、悪用されれば業務中核の財務・計画データが攻撃者の手に渡りかねない。対象製品であるSAP BPCとSAP BWは多くの大企業で予算管理や経営分析に利用されており、侵害の影響範囲は広い。 2番目に深刻な脆弱性CVE-2026-34256（CVSS 7.1）は、SAP ERPおよびSAP S/4HANA（プライベートクラウド・オンプレミス）に影響する認可チェック不備の問題だ。認証済み攻撃者が特定のABAPレポートを実行し、既存の8桁実行可能ABAPレポートを不正に上書きできるため、業務アプリケーションの意図した機能が失われるリスクがある。 その他の修正と推奨対応 今回のパッチデーでは上記2件のほかに、SAP BusinessObjects、Human Capital Management、S/4HANAの各バリアント、NetWeaver Application Server、HANA Cockpitに影響する中程度のリスクを持つ15件の脆弱性と、NetWeaver Application Server ABAPおよびLandscape Transformationに関する低リスク2件も合わせて修正されている。SAPは脆弱なソフトウェアを使用しているかどうかを確認し、特にCVSS 9.9の重大SQLインジェクション脆弱性については最優先でパッチを適用するよう強く推奨している。

概要 クラウド開発プラットフォームのVercelは2026年4月、サードパーティAIツール「Context.ai」の侵害を経由した内部システムへの不正アクセスを確認したと発表した。Vercel CEO の Guillermo Rauch 氏によると、攻撃者はまずContext.aiの従業員を侵害し、そこから取得したGoogle Workspaceの認証情報を使ってVercel環境へのアクセスを拡大したという。影響を受けたのは「顧客の限定的なサブセット」にとどまるとされているが、APIキーや環境変数の漏洩が確認されており、影響を受けた顧客には直接通知と認証情報のローテーションが要請されている。 攻撃の経路：サプライチェーン経由の侵害 セキュリティ企業Hudson Rockの調査によると、攻撃の起点は2026年2月に遡る。Context.aiの従業員がRobloxのゲームチートツール（「自動農業」スクリプトやエクスプロイト）をダウンロードしたことで、それらに組み込まれていた「Lumma Stealer」と呼ばれる情報窃取型マルウェアに感染した。このマルウェアを通じて攻撃者はGoogle Workspaceの認証情報や、Supabase・Datadog・Authkitなどのサービスキーを入手した。さらに「support@context.ai」アカウントを奪取することでVercelのシステムへの権限昇格を実現した。調査チームは、攻撃者がVercelのシステム構造を深く理解していた点から、高度に洗練された脅威グループと評価している。 漏洩データの範囲とVercelの対応 脅威行為者が主張する漏洩データには、従業員情報580件（名前・メールアドレス・アカウントステータス・アクティビティタイムスタンプ）、NPMトークンおよびGitHubトークンを含むAPIキー、ソースコード、内部デプロイメントへのアクセス権が含まれるとされる。ただし「Sensitive（機密）」としてマーク済みの環境変数は暗号化されており、現時点でアクセスされた証拠はないとVercelは説明している。「ShinyHunters」と名乗る脅威行為者がBreachForumsでデータを約200万ドルで売り出していると報告されているが、BleepingComputerはデータの真正性を独自に確認できていない。 Vercelは対応策として、Mandiant（Google傘下）をはじめとする複数のサイバーセキュリティ企業と連携し、法執行機関への通知も完了させている。また、全ユーザーに対して環境変数の監査と「Sensitive（機密）」設定の活用、シークレットのローテーションを推奨している。なお、Next.js・Turbopackなどのオープンソースプロジェクトは本インシデントの影響を受けていないことが確認されている。 サードパーティツール利用リスクへの教訓 今回のインシデントは、従業員が利用するサードパーティSaaSやAIツールが企業全体のセキュリティチェーンにおける脆弱点になり得ることを改めて示した。攻撃者は直接Vercelを攻撃するのではなく、権限を持つ従業員が利用するツールのベンダーを狙うことで、多要素認証などの直接的な防御策を迂回した。企業はサードパーティツールへのアクセス権限の最小化、OAuthアプリケーションIDの定期的な監視、シークレット情報の暗号化管理の徹底など、サプライチェーンリスクへの対策を強化する必要がある。

概要 Zigプログラミング言語は2026年4月14日、バージョン0.16.0を正式リリースした。244名の貢献者による1183件のコミットが8ヶ月かけて統合された大型リリースで、言語設計・コンパイラ・標準ライブラリ・ビルドシステムにわたる広範な改善が含まれる。最も大きな変化はI/O処理の全面的な再設計と、main()関数への依存性注入パターンの導入だ。 std.Io：I/Oのインターフェース化 0.16.0最大の変更点は、入出力機能をすべて新しいstd.Ioインターフェース経由で扱う設計への移行だ。ブロッキング操作やランダム性を伴うあらゆるI/O処理がIoインスタンスを必要とするようになり、実行モデルを柔軟に切り替えられるようになった。 提供される実装は用途別に用意されている。Io.Threadedはスレッドベースの完全実装、Io.Eventedはグリーンスレッドを使った実験的な実装、さらにIo.Uring（Linux）、Io.Kqueue（macOS/BSD）、Io.Dispatch（Apple）がプルーフオブコンセプトとして含まれる。これにより、同じコードをブロッキング・非同期・OSのI/O多重化機構のいずれでも動作させる基盤が整えられた。 「Juicy Main」：依存性注入によるプロセス初期化 main()関数のシグネチャがpub fn main(init: std.process.Init) !voidという形に変わり、アロケータとI/Oインスタンスが実行時に注入されるようになった。開発チームがこれを「Juicy Main」と呼ぶこの機能は、従来グローバルな状態として暗黙に扱われていた環境変数・コマンドライン引数・メモリアロケータを、initパラメータを通じて明示的に受け取るパターンに切り替える。依存関係が明確になりテストや移植性が向上する一方、既存コードのマイグレーションが必要となる破壊的変更でもある。 インクリメンタルコンパイルとビルドシステムの強化 コンパイラには「Reworked Type Resolution」として型チェック戦略の簡素化が加えられた。struct・union・enum・opaqueがそのサイズやフィールド型が実際に必要になるまで解決されない「Lazy Field Analysis」により、不要なコード生成が削減され、インクリメンタルコンパイルの効率が向上する。 ビルドシステムにはパッケージのローカル管理機能が追加された。プロジェクト内のzig-pkgディレクトリにパッケージをフェッチして管理したり、上流パッケージをローカルでオーバーライドしたりできるようになり、依存関係管理の柔軟性が高まった。 言語・標準ライブラリの変更とLLVM独立への進捗 言語レベルでは、@Typeビルトインが@Int・@Structなど8つの個別ビルトインに分割された。packed unionでの明示的な型指定サポートや、スイッチ式でのpacked struct比較なども追加されている。標準ライブラリにはdeflate圧縮の新規実装、ロックフリー化されたheap.ArenaAllocator、非同期プリミティブstd.Io.Groupとstd.Io.Futureが加わった。 LLVMへの依存削減でも前進があり、Tier 1ターゲットであるx86_64-linux向けに新しいELFリンカが実装され、-fno-llvmフラグでのコンパイルが強化された。開発チームは最終的にコンパイラバイナリを約150MiBから5MiB程度まで削減する計画を進めており、今リリースはその道筋を着実に歩んでいる。

概要 2026年版「CISO AIリスクレポート」は、235名のエンタープライズセキュリティリーダーへの調査をもとに、AIアイデンティティとアクセス管理のガバナンスにおける深刻な課題を明らかにした。71%のCISOがAIはコアビジネスシステムへのアクセス権を持っていると回答したにもかかわらず、そのアクセスを適切にガバナンスできていると答えたのはわずか16%にとどまる。Salesforce、SAPといった基幹系プラットフォームに対して、AIエージェントが実質的な権限を持ちながら監視体制が整っていない状況が浮き彫りになった。 47%のセキュリティリーダーがAIエージェントによる意図しない・未認可の動作をすでに確認しており、過去1年以内に実際のセキュリティインシデントまたはニアミスを経験したとする割合は3分の1に上る。AIエージェントがAPIを呼び出し、設定を変更し、エンタープライズシステムへの書き込みを行っている現状において、ガバナンス不在のリスクは急速に顕在化しつつある。 深刻な可視性とガバナンスの欠如 調査では、組織内のAIアイデンティティへの完全な可視性を確保できていないと答えた割合が92%に達した。さらに、侵害されたAIエージェントの検知・対応に自信があると答えたのはわずか5%であり、封じ込め態勢の脆弱さが際立つ。86%のセキュリティリーダーはAIアイデンティティに対するアクセスポリシーを持たないか、持っていても適用していない。人間ユーザーと同等のガバナンス基準をAIアカウントに適用している組織は19%に過ぎず、AIエージェントの管理が人間のワークフローを前提とした既存ツールの寄せ集めで行われている実態が示された。 「シャドーAI」の問題も深刻化しており、4分の3のCISOが組織内で無認可のAIツールが稼働していることを発見している。これらのツールは多くの場合、資格情報を埋め込み、標準的なプロビジョニングのワークフローの外で高度なシステムアクセスを持って動作しているという。AIエージェント専用のアイデンティティ管理やモニタリング制御を導入している組織は全体の25%にとどまる。 推奨される対策と今後の展望 レポートは、プロビジョニング・権限管理・アクセス分析を統合した統一アイデンティティプラットフォームの導入を推奨している。ポイントソリューションを分散して運用するのではなく、AIエージェントの自律的な動作パターンに対応したディスカバリー、分類、継続的なモニタリング、リアルタイムのポリシー適用が必要だと指摘する。AIシステムが企業インフラへの組み込みを加速させる中、アイデンティティ管理とアクセスコントロールをAI時代に合わせて再設計することが、CISOにとって喫緊の課題となっている。

概要 スウェーデンのソフトウェアサプライチェーン企業FossID ABは、AIツールによるコード生成・変更が急増する現状に対応した新技術「Agentic SCA（Software Composition Analysis）」を発表した。従来のSCAツールが開発後の下流フェーズで静的にスキャンするのに対し、Agentic SCAはAIエージェントが生成するコードをリアルタイムかつ継続的に監査する仕組みを提供する。自動車・半導体・通信・ソフトウェアなどの業界で選定されたエンタープライズ顧客によるパイロット段階にあり、2026年後半に正式リリースが予定されている。 技術的なアーキテクチャ Agentic SCAの核心はFossIDが独自に提供する「FossID MCPサーバー」だ。MCP（Model Context Protocol）を介してFossIDのナレッジベースと分析ツールをAIシステムから直接呼び出せるようにする。これによりCopilotなどのAIコーディングアシスタントや自律的なエージェントが、コードを生成・編集する瞬間にリアルタイムでオープンソースライセンス・脆弱性・著作権の問題を検出できる。 主な機能は以下の通りだ。 完全なファイルから断片的なコードスニペットまで、オープンソース・サードパーティ・プロプライエタリコードの検出 ライセンス義務の即時特定（複雑な混合ライセンスシナリオにも対応） 脆弱性の即時フラグ立てと修正ガイダンスの提供 シグネチャスキャン・スニペット検出・依存関係分析を含む多層ソースコード解析 コードの変化に応じた継続的な自動レポート生成 背景と課題 FossIDは、依存関係ベースのマネージドコードを前提として設計された従来型SCAツールが、AIによる高速なコード生成に追いつけなくなっているという問題意識をもとにAgentic SCAを開発した。AIが生成するコードはサードパーティライブラリの断片やスニペットを多数含むことがあり、既存のSCAツールではこれらを適切に検出できないケースがある。コンプライアンス違反や未検知の脆弱性が開発パイプラインに紛れ込む新たなリスクとなっており、Agentic SCAはこのギャップを埋めることを目的としている。 展望 AIコーディングツールの普及に伴い、生成されるコードに対するセキュリティ・ライセンスコンプライアンスの確保はますます重要な課題となっている。FossIDのアプローチは、コンプライアンスチェックを「後工程」から「生成時点」へと前倒しするという業界トレンドに沿ったもので、開発ライフサイクル全体での自動ガバナンスの実現に向けた動きが加速しつつある。

概要 GitHub Copilot CLIが自動モデル選択（autoモデル選択）機能を正式に一般提供（GA）開始した。この機能はすべてのCopilotプランのユーザーが利用可能で、ユーザーが手動でモデルを選択する手間なく、最も効率的なモデルが自動的に選ばれる。自動選択の対象となるモデルにはGPT-5.4、GPT-5.3-Codex、Sonnet 4.6、Haiku 4.5などが含まれており、ユーザーのプランおよび管理者が設定したポリシーに基づいて動的にルーティングが行われる。 技術的な詳細 autoモデル選択では、レート制限の軽減と最適なモデルの自動割り当てが実現される。実際にどのモデルが使用されたかはCLI上に透明な形で表示されるため、ユーザーは選択結果を確認できる。また、いつでも特定モデルへ手動で切り替えることも可能であり、柔軟な利用が担保されている。管理者によるポリシー設定も尊重されるため、企業環境でも安心して利用できる。 価格・割引 有料購読者がautoモデルを使用する場合、モデル乗数が通常より10%割引される。たとえば乗数1xのモデルを利用した際、通常1プレミアムリクエストが消費されるところ、autoモデル経由では0.9プレミアムリクエストの消費にとどまる。この割引はレート制限の緩和と合わせ、日常的にCopilot CLIを活用する開発者にとってコスト面でのメリットとなる。

概要 Microsoftは、Windows 11のタスクバーにAIエージェント機能を統合する計画を正式に確認した。同社が一部のアプリからCopilotを削除したことで「AI縮小路線」への転換と受け取られる向きもあったが、今回の発表はそうした憶測を否定するものだ。スニッピングツールや写真アプリなど実用性が低い文脈からCopilotを取り除いている一方で、タスクバーへのエージェント統合は引き続き推進しており、「AIをより意図的に、価値を発揮できる場所に絞り込んでいる」というのがMicrosoftの立場だ。パブリックロールアウトに向けた準備が進められており、段階的なオプトイン方式での提供が予定されている。 技術的な詳細 AIエージェントは「計画し、調査し、推論し、ユーザーの介入なしに実行する」自律型システムとして設計されている。ユーザーはタスクバー上のMicrosoft 365 Copilotアイコンにホバーすることで、エージェントの動作をモニタリングしたり制御したりすることができる。 現時点で最初にサポートされるエージェントはMicrosoft 365 Researcherだ。OneDriveやMicrosoft 365のファイルにアクセスしながら複数ステップにわたる調査タスクを実行し、詳細なレポートをタスクバーから直接生成する機能を持つ。開発者向けにはModel Context Protocol（MCP）を採用しており、サードパーティ開発者が互換性のあるエージェントを構築してタスクバーに接続できる仕組みが整備されている。さらに深いOSレベルの統合が必要な場合はWindows.UI.Shell.Tasks APIも利用可能だ。 利用条件と今後の展望 この機能の利用にはMicrosoft 365サブスクリプションが必要であり、自動的に有効化されるものではなく完全なオプトイン方式となっている。現状のサポートはMicrosoft 365アプリに限定されているが、MCPを通じたサードパーティ製エージェントの参入により、将来的には対応するエージェントの幅が大きく広がると見られる。Windowsのタスクバーという常時アクセス可能な場所にAIエージェントが常駐することで、デスクトップ上でのAI活用がより日常的になる可能性がある。

概要 Linux Foundation主催の「OpenSearchCon Europe 2026」が、チェコの首都プラハで2026年4月16〜17日の2日間にわたって開催された。同カンファレンスはOpenSearchプロジェクトのユーザー・管理者・開発者が一堂に会し、実世界の課題解決事例の共有やコミュニティネットワークの構築を行う年次イベントで、今回はオープンソースの検索・分析・オブザーバビリティとエージェントAIの融合が主要テーマに据えられた。50以上のセッションが用意され、AWS、IBM、Oracle、SAP、ノルウェー政府などから多様なスピーカーが登壇した。 主要テーマと参加組織 今回のカンファレンスでは、エージェントAIと検索技術の融合が中心的なテーマとして掲げられた。大規模言語モデル（LLM）を活用したエージェントシステムが普及する中、検索・オブザーバビリティ基盤としてのOpenSearchの役割が改めて注目されている。企業・組織側からはAWSやIBM、Oracle、SAPといった大手テクノロジー企業に加え、ノルウェー政府も参加しており、OpenSearchが民間と公共セクターの双方で広く採用されていることが示された。スポンサーにはAdeptic Reply、AWS（以上ゴールド）、Instaclustr（シルバー）、Aiven、BigData Boutique、Eliatra、Hyland（以上ブロンズ）が名を連ねた。 セッション形式とコミュニティの取り組み プログラムは通常のセッション発表に加え、参加者主導で議題を決めるアンカンファレンス形式のセッションも設けられ、コミュニティの自発的な議論を促す場が用意された。セッションのスライドや動画は後日公開される予定で、参加できなかった開発者や利用者にも成果を広く共有する方針だ。OpenSearchConは欧州と北米で定期開催されており、グローバルなオープンソース検索コミュニティの中核的な情報交換の場として機能している。 今後の展望 OpenSearchはElasticsearchのフォークとして2021年に誕生して以来、急速にエコシステムを拡大してきた。今回のカンファレンスで示されたエージェントAIとの統合方向性は、RAG（Retrieval-Augmented Generation）パイプラインにおける検索エンジンとしての活用や、AIエージェントによるリアルタイムのオブザーバビリティ分析など、今後の主要ユースケースを示唆している。次回以降のOpenSearchConでも、AIとオープンソース検索の融合がさらに深化していくことが期待される。

概要 Perplexityは2026年4月16日、Mac向け常時稼働型AIエージェント「Personal Computer」を正式に展開した。同年3月11日に発表されていたこの機能は、ローカルファイル・ネイティブアプリ・Webを横断してタスクを自律実行する「オールインワンのデジタルワーカー」として設計されており、Perplexity Maxプラン（月額200ドル）の加入者と事前ウェイトリスト登録者から順次利用可能になっている。従来の「Perplexity Computer」はクラウドベースのWeb版であったのに対し、今回のPersonal ComputerはMacのローカルハードウェア上で動作するハイブリッド型として位置付けられる。 機能と技術的な詳細 Personal ComputerはmacOS 14 Sonoma以降に対応し、両Commandキーの同時押しで起動する。テキスト・音声でのコマンド入力を受け付け、iMessage・Apple Mail・カレンダーなどネイティブMacアプリと連携しながら多段階ワークフローを実行できる。20以上のフロンティアモデルを「エージェントチーム」として協調させるアーキテクチャを採用しており、具体的なユースケースとして以下が挙げられる。 ToDoリストの内容を自動処理してiMessageやメールへ反映 散在するファイルフォルダを自動で整理 ローカル文書をWebの最新情報と照合して比較分析 Perplexityが「常時稼働」の推奨デバイスとして挙げるのがMac miniで、24時間365日バックグラウンドで稼働させることを想定している。iPhoneからタスクを指示してデスクトップのPersonal Computerに実行させる二要素認証付きのクロスデバイス連携にも対応する。 セキュリティと制御 自動化の範囲が広い一方で、セキュリティへの配慮も強調されている。ファイルのやり取りはセキュアなサンドボックス環境内で行われ、AIが実行した操作はすべて監査・巻き戻しが可能だ。センシティブなアクションには人間の確認を挟む設計となっており、強制停止のキルスイッチも用意されている。Perplexityはこれを「AIの意思決定ステップへの完全な可視性」と表現し、ユーザーが常に制御を維持できる点を訴求している。 提供条件と今後の展望 Personal Computerは月額200ドルのMaxプラン専用で、月額20ドルのProプランではクラウドベースの旧Perplexity Computerのみ利用できる。Perplexityは今回の機能を「指示に応答するだけの受動的なコンピューティングから、目標指向の能動的なAI支援への進化」と位置付けており、デスクトップAIエージェント市場の開拓を進めている。

概要 Spring Frameworkは2026年4月17日、6.2.18と7.0.7の2バージョンを同時リリースした。どちらもバグ修正とドキュメント改善を主体とするメンテナンスリリースで、6.2.18では27件、7.0.7では52件の修正が含まれる。6.2.18は近日リリース予定のSpring Boot 3.5.14にも同梱される予定となっており、既存の本番環境での安定稼働を重視するプロジェクトにとって重要なアップデートだ。 Spring Framework 6.2.18の主な変更点 6.2.18では、SpringValidatorAdapterとMethodValidationAdapterのパフォーマンス向上が図られた。また、将来のバージョン7.0で削除予定の機能に@Deprecated(forRemoval = true)アノテーションが追加され、移行準備を進める開発者への明示的なシグナルが強化されている。 バグ修正面では、ServerSentEventのidやeventプロパティ設定時に発生していたNullPointerExceptionの解消、@SqlアノテーションとTransactionAwareDataSourceProxyを組み合わせた際の不具合修正、WebDataBinderが不要なコレクションを生成する問題の解決などが行われた。また、MySQLのGalera/WSREPコンフリクト（エラーコード149）への対応やKotlinのnullableな値クラスパラメータの処理改善も含まれている。依存ライブラリはMicrometer 1.15.11とReactor 2024.0.17にアップグレードされた。 Spring Framework 7.0.7の主な変更点 7.0.7はより多くの修正を含む。6.2.18と共通するSpringValidatorAdapterやMethodValidationAdapterのパフォーマンス改善に加え、KotlinSerializationJsonDecoderでのJSON配列からFluxへのデコーディング対応、RestClient向けのMockRestServiceServer#createServerバリアント追加、RestTemplateXhrTransportを置き換えるRestClientXhrTransportの新設など、新機能も盛り込まれている。 バグ修正では、WebDataBinderが「!」や「_」プレフィックス使用時に不要なコレクションを生成する問題、MessageSourceSupportにおける高カーディナリティのキャッシュ汚染問題、Java 24以降でのAnnotatedTypeMetadataのソース宣言順序保持に関する問題、MergedAnnotation.asMap()が存在しないクラスを参照した際の失敗など、より高度な環境での動作安定性が強化された。依存ライブラリはMicrometer 1.16.5とReactor 2025.0.5にアップグレードされている。 ドキュメント改善と今後の展望 両バージョンともSpEL式のホワイトスペース仕様の明確化、@ActiveProfilesの動作解説、Bean OverridesのKotlinサンプルコード追加など、ドキュメントの充実が図られた。6.2.x系は引き続きメンテナンスブランチとして維持され、7.0.x系は最新安定版として機能追加も継続して行われる。Spring Boot利用者は、近日公開予定の3.5.14を通じて6.2.18の修正を自動的に受け取ることができる。