月刊Linux Foundationウォッチ 70

LFがOSSの脆弱性協調対応イニシアティブ「Akrites」を発足、CRA準備状況レポートは改善どころか悪化、ほか

吉田 行男

6:20

目次

  1. AI時代のOSS脆弱性防衛線「Akrites」始動、
    金融セクターは「OSERA」で下流対応を共同化 Linux Foundation(以下、LF)は2026年6月25日、重要なオープンソースソフトウェア(OSS)の脆弱性をAI支援型のサイバー脅威から守るための業界横断的な協調イニシアティブ「Akrites(アクリテス)」の発足を発表しました。Akritesは、OSSプロジェクトに対する共有型セキュリティインシデントレスポンスチーム(SIRT)と、機密性を最優先とした統一的な脆弱性協調開示(CVD)プロセスを確立するものです。【参照】Linux Foundation and Industry Leaders Launch Akrites to Defend Critical Open Source Software Against AI-Enabled Cyber Threats
    https://www.linuxfoundation.org/press/linux-foundation-and-industry-leaders-launch-akrites-to-defend-critical-open-source-software-against-ai-enabled-cyber-threats創設メンバーとして、Amazon Web Services、Anthropic、Chainguard、Cisco、Citi、Endor Labs、Ericsson、Google、IBM、JPMorganChase、Microsoft/GitHub、NVIDIA、OpenAI、RapidFort、Red Hat、Rust Foundation、Sonatype、Vodafone、Zscalerが参画しており、ハイパースケーラー、AIラボ、金融機関、通信事業者、セキュリティベンダーという異例の幅広い連合体が形成されています。創設メンバーは共同公開書簡「We All Depend on Open Source. We Will Defend It Together.」を公開しました。 なぜ今「Akrites」が必要なのか ーAIが変えた脆弱性発見の時間軸 Akrites設立の背景にあるのは、フロンティアAIモデルによって脆弱性発見の速度と規模が根本的に変化したという現実です。従来、大規模なOSSプロジェクトの脆弱性を見つけるには専門家が数週間を要していましたが、現在のAIモデルは数分でスキャンし脆弱性を検出できます。さらに深刻なのは、パッチが公開された後、攻撃者がAIを活用して脆弱性をリバースエンジニアリングし、エクスプロイトを開発し、攻撃を開始するまでの時間が劇的に短縮されている点です。 LFのCEOであるJim Zemlin氏は「かつて深刻なオープンソースの脆弱性を見つけるには専門家が数週間を必要としました。今はマシンが数分でそれを行います。メンテナーがその競争に負ければ、他の全員も負けます。単一の企業、単一のメンテナー、単一の政府だけではそのギャップを埋めることはできません」と述べています。 Akritesの仕組み:機密性ファーストの協調対応 従来のOSSセキュリティ対応では、複数の組織が同じ問題に独立して取り組み、競合するパッチを出したり、メンテナーに重複する報告が殺到したりする「パッチワーク」状態が常態化していました。Akritesはこのモデルを根本的に変革します。 具体的なプロセスは次の通りです。まず、脆弱性レポートがAkrites SIRTに機密として提出されます。次にSIRTが検証と重複排除を行います。その後、メンテナーと業界のエンジニアがセキュアな環境で修正パッチを共同開発し、修正がアップストリームプロジェクトにマージされます。最後に、同期された協調開示(CVE公開)がエコシステム全体に対して行われます。 このプロセス全体を通じて、CVE、TLP、CWE、CVSS、EPSS、SSVC、VEXといった業界標準のツーリングが使用されます。Akritesの成功は「パッチの公開」ではなく「パッチの展開」で測定されるという点が、従来のCVDプロセスとの大きな違いです。 また、Akritesはメンテナーが不在または放棄されたパッケージに対する「最後の砦のメンテナー(maintainer of last resort)」としての役割も担います。広く展開されているが、もはや積極的にメンテナンスされていないOSSパッケージの修正を確実に提供するための仕組みです。初期資金はLFの既存プログラムAlpha-Omegaから提供されます。 Anthropicの副CISOであるJason Clinton氏は「オープンソースプロジェクトはインターネットの多くを支えています。そして、既存の協調開示モデルはAIが今や脆弱性を見つける速度に追い越されています。これに先手を打つには、業界が発見内容を協調し、開示・悪用される前にアップストリームで修正を行う必要があります」とコメントしています。 OSERA:金融セクターによるAkritesの下流補完 Akrites発表の翌日の6月26日、LFの金融サービス部門であるFINOSは、ロンドンで開催された「Open Source in Finance Forum」において「Open Source Enterprise Resiliency Alliance(OSERA)」の設立意向を発表しました。OSERAは、Akritesの「金融サービスにおけるダウンストリーム補完」と明確に位置づけられています。【参照】FINOS Announces Intent to Form OSERA, a Global Financial Services-Led Alliance for Open Source Supply-Chain Resiliency in the Era of AI
    https://www.linuxfoundation.org/press/finos-announces-intent-to-form-osera-a-global-financial-services-led-alliance-for-open-source-supply-chain-resiliency-in-the-era-of-aiAkritesがアップストリームの脆弱性修正の協調を担うのに対し、OSERAは規制産業が実際に使用しているOSSコンポーネントの「バックパッチング」を共同化します。金融機関は驚くほど共通のOSS依存関係とバージョンを使用しており、ある脆弱性が1社にとってのリスクであれば全社にとってのリスクです。各社が同じ脆弱性を同じパッケージに対して個別に対処するのではなく、その作業をベンダーニュートラルな場で共同化するのがOSERAの基本思想です。 Deutsche Bank、Goldman Sachs、Morgan Stanley、Royal Bank of Canada(RBC)、TD Bank Groupがすでにエンドツーエンドのパイロットを完了しており、日本の金融機関からの参画も検討に値するでしょう。OSERAは、DORA(デジタルオペレーショナルレジリエンス法)、NIS2、CRAなど欧州の規制フレームワークへの準拠を共有可能な監査証跡で支援することも大きな特徴です。 Morgan StanleyのディスティングイッシュドエンジニアであるDov Katz氏は「大規模な金融機関が運用する規模では、修正パッチの作成は課題の半分に過ぎず、複雑で規制された環境全体にわたってそれを確実に適用することが同等に重要です」と述べています。 CRA準備は改善どころか悪化
    ー「2026 CRA認知度・準備状況レポート」が警鐘 LF Research、OpenSSF、Balena、Ericsson、Revaniteの共同により「2026 CRA Awareness and Readiness Report(2026年 CRA認知度・準備状況レポート)」が2026年6月初旬に公開されました。EU Cyber Resilience Act(CRA)への準備状況を追跡する2回目のレポートですが、その結果は「改善どころか悪化」という衝撃的なものでした。【参照】2026 CRA Awareness and Readiness
    https://openssf.org/wp-content/uploads/2026/06/2026_CRA_Awareness_Readiness_Report.pdf認知度66%が「未認知」ー2025年の62%からさらに後退 レポートの最も深刻な発見は、CRAに「馴染みがない」と回答した割合が2025年の62%から2026年の66%に上昇したことです(レポートp.7)。特に北米(米国・カナダ)では72%が未認知であり、自社製品がEU市場に投入される場合に適用される規制を知らないまま操業している状態です(レポートp.8)。CRAを認知している回答者の中でも、知識ギャップは2025年とほぼ同じです。約4割はCRAが自組織に適用されるかどうかすら判断できておらず、製造者(manufacturer)とスチュワード(steward)の区別が54%の回答者にとって不明確なままです(レポートp.9)。完全準拠期限を2027年12月と正しく回答できたのはわずか34%でした。2026年9月の最初の義務期限が迫る 特に緊急性が高いのは、2026年9月に発効する最初のハードデッドラインです。これ以降、製造者は積極的に悪用されている脆弱性と深刻なセキュリティインシデントを24時間以内に報告する義務を負います。しかし、全製品についてSBOM(ソフトウェア部品表)を生成している製造者はわずか32%に留まっています。 さらに、2026年第1四半期のOSSプロジェクト全体の公開脆弱性は前年同期比394%増加し、高重要度の脅威は811%増という爆発的な増加を見せています。これは先述のAkritesおよびOSERAが設立された背景とも直結しており、AI支援による脆弱性発見の加速がCRA準拠の難しさをさらに増幅しています。 製造者の41%が2027年12月の期限までに完全準拠を達成できると見込んでいる一方、39%は準拠能力について完全に不確実な状態です(レポートp.15)。また、56%の組織が不準拠の場合の罰則を認識しておらず、リスクが適切に評価されていません。レポートは認知向上キャンペーンだけではギャップを埋められず、次のフェーズの取り組みはカンファレンス、OSSツーリングのドキュメント、コミュニティチャネルなど、開発者が実際に活動する場所で行う必要があると提言しています。CRAを認知している回答者の48%がそうしたコミュニティチャネルで学んでおり、公式EUチャネルが到達したのはわずか25%です(レポートp.8)。LFは無料コース「Understanding the EU Cyber Resilience Act(LFEL1001)」やCRA Stewards Playbook等のリソースを提供しています。Google/WHOからLFへ
    ー「Open Health Stack Software Foundation」の設立を発表 LFは2026年7月9日、AI対応のデジタルヘルスソリューションを構築するためのオープンソースツールの、ベンダーニュートラルでコミュニティ主導の拠点となる「Open Health Stack Software Foundation(OHS-SF)」の設立意向を発表しました。【参照】Linux Foundation Announces Intent to Launch Open Health Stack Software Foundation to Advance Open Source Digital Health Innovation
    https://www.linuxfoundation.org/press/linux-foundation-announces-intent-to-launch-open-health-stack-software-foundation-to-advance-open-source-digital-health-innovationOHS-SFは、2023年にGoogleとWHO(世界保健機関)が共同で立ち上げた「Open Health Stack」プロジェクトを母体としています。Googleがコードと関連資産をLFに移管するとともに、Google.orgから300万ドルの助成金が提供されます。WHO、Anthropic、Microsoft、Clinton Health Access Initiative、Johns Hopkins Bloomberg School of Public Healthなど20以上の組織が初期支持を表明しています。 3つの技術的柱:FHIR基盤、OHSプレイヤー、AI Commons OHS-SFは、グローバルなオープン標準に基づく3つの技術的柱を中心に構成されます。第1に、HL7 FHIR(Fast Healthcare Interoperability Resources)に基づくコア基盤です。FHIRは医療データの相互運用性のための国際標準で、免疫、HIV、母子保健など個別に構築されてきたサイロ化した医療情報システムを統合するための共通基盤を提供します。 第2に「OHSプレイヤー」と呼ばれるマルチプラットフォーム参照ツールキットです。これにより、各国・各地域の開発者がローカル環境に適応したデジタルヘルスアプリケーションを構築できます。 第3に、WHOと共同開発する「AI Commons」です。これはモデルに依存しない中立的な空間で、グローバルヘルスにおけるAIの安全性、有効性、検証可能性を担保するための取り組みです。 低・中所得国の開発者がガバナンスに参加できる仕組み OHS-SFの特徴的な設計として、低・中所得国(LMIC)の開発者がガバナンスに直接参加できる「Implementer Program」が導入されます。小規模事業者、地域のコンサルティング企業、プレレベニュースタートアップが財政的障壁なしにプロジェクトの方向性を決定する場に参加できます。非営利、学術、政府機関のメンバーシップはLF Associate Membershipティアに準じて無料です。 LFのCEOであるJim Zemlin氏は「オープンソースはすでにエンタープライズソフトウェア、クラウドコンピューティング、AIを変革しました。世界がケアを提供する方法についても同様のことが起きるでしょう」と述べています。 まとめ 今回は、OSSセキュリティ、EU規制対応、デジタルヘルスという3つの異なる領域における重要な動きを取り上げました。 AkritesとOSERAは、OSSセキュリティにおける「上流と下流の連携」という新たなモデルを提示しています。Akritesがアップストリームで脆弱性の協調修正を行い、OSERAが金融セクターという規制産業での下流適用を共同化する。この二層構造は、前回で取り上げた欧州版Tech Talentレポートが示したセキュリティ懸念の深刻さ(51%が最大障壁と回答)と、今回のCRA準備状況レポートが示す準備の遅れを具体的なアクションで解決しようとする試みです。日本のPSIRTやセキュリティチームにとっても、AkritesやOSERAとの連携や情報共有の仕組みを検討する価値があるでしょう。 CRA認知度・準備状況レポートは、2026年9月の最初の義務化と2027年12月の完全準拠期限に向けて、エコシステム全体の準備が十分に進んでいないことを明確に示しています。OSS脆弱性の公開件数が前年比394%増という爆発的増加の中、SBOMの生成体制が32%に留まる現状は、EU市場に製品を投入する日本企業にとって喫緊の課題です。 OHS-SFの設立は、OSSの適用範囲がITインフラストラクチャからグローバルヘルスへと拡大していることを示す象徴的な出来事です。WHOとの連携、LMICの開発者のガバナンス参加という設計は、オープンソースがデジタルデバイドの解消に貢献しうることを示しています。 なお、7月16日にはx402 Foundationの運用開始も発表されています。Coinbaseが開発した「x402プロトコル」をLFに移管し、40メンバーが参画するこの取り組みは、AIエージェントやAPIがHTTP上でシームレスに決済を行うためのオープン標準を目指しています。前回で紹介したOpenSharing(AIアセット共有)と合わせ、エージェンティックAI時代の「データ共有」と「決済」の両面でオープン標準が整備されつつある点は注目に値します。【参照】Linux Foundation Announces Operational Launch of x402 Foundation to Standardize Internet-Native Payments for AI Agents and Applications
    https://www.linuxfoundation.org/press/linux-foundation-announces-operational-launch-of-x402-foundation-to-standardize-internet-native-payments-for-ai-agents-and-applicationsまた、7月28〜30日には横浜で「KubeCon+CloudNativeCon Japan 2026」が開催されます。クラウドネイティブコミュニティの日本における最大イベントとして、AI時代のKubernetes活用に関する最新動向が共有される予定です。
    1. なぜ今「Akrites」が必要なのか ーAIが変えた脆弱性発見の時間軸
    2. Akritesの仕組み:機密性ファーストの協調対応
    3. OSERA:金融セクターによるAkritesの下流補完
  2. CRA準備は改善どころか悪化
    ー「2026 CRA認知度・準備状況レポート」が警鐘
    1. 認知度66%が「未認知」ー2025年の62%からさらに後退
    2. 2026年9月の最初の義務期限が迫る
  3. Google/WHOからLFへ
    ー「Open Health Stack Software Foundation」の設立を発表
    1. 3つの技術的柱:FHIR基盤、OHSプレイヤー、AI Commons
    2. 低・中所得国の開発者がガバナンスに参加できる仕組み
  4. まとめ

AI時代のOSS脆弱性防衛線「Akrites」始動、
金融セクターは「OSERA」で下流対応を共同化

Linux Foundation(以下、LF)は2026年6月25日、重要なオープンソースソフトウェア(OSS)の脆弱性をAI支援型のサイバー脅威から守るための業界横断的な協調イニシアティブ「Akrites(アクリテス)」の発足を発表しました。Akritesは、OSSプロジェクトに対する共有型セキュリティインシデントレスポンスチーム(SIRT)と、機密性を最優先とした統一的な脆弱性協調開示(CVD)プロセスを確立するものです。

【参照】Linux Foundation and Industry Leaders Launch Akrites to Defend Critical Open Source Software Against AI-Enabled Cyber Threats
https://www.linuxfoundation.org/press/linux-foundation-and-industry-leaders-launch-akrites-to-defend-critical-open-source-software-against-ai-enabled-cyber-threats

創設メンバーとして、Amazon Web Services、Anthropic、Chainguard、Cisco、Citi、Endor Labs、Ericsson、Google、IBM、JPMorganChase、Microsoft/GitHub、NVIDIA、OpenAI、RapidFort、Red Hat、Rust Foundation、Sonatype、Vodafone、Zscalerが参画しており、ハイパースケーラー、AIラボ、金融機関、通信事業者、セキュリティベンダーという異例の幅広い連合体が形成されています。創設メンバーは共同公開書簡「We All Depend on Open Source. We Will Defend It Together.」を公開しました。

なぜ今「Akrites」が必要なのか ーAIが変えた脆弱性発見の時間軸

Akrites設立の背景にあるのは、フロンティアAIモデルによって脆弱性発見の速度と規模が根本的に変化したという現実です。従来、大規模なOSSプロジェクトの脆弱性を見つけるには専門家が数週間を要していましたが、現在のAIモデルは数分でスキャンし脆弱性を検出できます。さらに深刻なのは、パッチが公開された後、攻撃者がAIを活用して脆弱性をリバースエンジニアリングし、エクスプロイトを開発し、攻撃を開始するまでの時間が劇的に短縮されている点です。

LFのCEOであるJim Zemlin氏は「かつて深刻なオープンソースの脆弱性を見つけるには専門家が数週間を必要としました。今はマシンが数分でそれを行います。メンテナーがその競争に負ければ、他の全員も負けます。単一の企業、単一のメンテナー、単一の政府だけではそのギャップを埋めることはできません」と述べています。

Akritesの仕組み:機密性ファーストの協調対応

従来のOSSセキュリティ対応では、複数の組織が同じ問題に独立して取り組み、競合するパッチを出したり、メンテナーに重複する報告が殺到したりする「パッチワーク」状態が常態化していました。Akritesはこのモデルを根本的に変革します。

具体的なプロセスは次の通りです。まず、脆弱性レポートがAkrites SIRTに機密として提出されます。次にSIRTが検証と重複排除を行います。その後、メンテナーと業界のエンジニアがセキュアな環境で修正パッチを共同開発し、修正がアップストリームプロジェクトにマージされます。最後に、同期された協調開示(CVE公開)がエコシステム全体に対して行われます。

このプロセス全体を通じて、CVE、TLP、CWE、CVSS、EPSS、SSVC、VEXといった業界標準のツーリングが使用されます。Akritesの成功は「パッチの公開」ではなく「パッチの展開」で測定されるという点が、従来のCVDプロセスとの大きな違いです。

また、Akritesはメンテナーが不在または放棄されたパッケージに対する「最後の砦のメンテナー(maintainer of last resort)」としての役割も担います。広く展開されているが、もはや積極的にメンテナンスされていないOSSパッケージの修正を確実に提供するための仕組みです。初期資金はLFの既存プログラムAlpha-Omegaから提供されます。

Anthropicの副CISOであるJason Clinton氏は「オープンソースプロジェクトはインターネットの多くを支えています。そして、既存の協調開示モデルはAIが今や脆弱性を見つける速度に追い越されています。これに先手を打つには、業界が発見内容を協調し、開示・悪用される前にアップストリームで修正を行う必要があります」とコメントしています。

OSERA:金融セクターによるAkritesの下流補完

Akrites発表の翌日の6月26日、LFの金融サービス部門であるFINOSは、ロンドンで開催された「Open Source in Finance Forum」において「Open Source Enterprise Resiliency Alliance(OSERA)」の設立意向を発表しました。OSERAは、Akritesの「金融サービスにおけるダウンストリーム補完」と明確に位置づけられています。

【参照】FINOS Announces Intent to Form OSERA, a Global Financial Services-Led Alliance for Open Source Supply-Chain Resiliency in the Era of AI
https://www.linuxfoundation.org/press/finos-announces-intent-to-form-osera-a-global-financial-services-led-alliance-for-open-source-supply-chain-resiliency-in-the-era-of-ai

Akritesがアップストリームの脆弱性修正の協調を担うのに対し、OSERAは規制産業が実際に使用しているOSSコンポーネントの「バックパッチング」を共同化します。金融機関は驚くほど共通のOSS依存関係とバージョンを使用しており、ある脆弱性が1社にとってのリスクであれば全社にとってのリスクです。各社が同じ脆弱性を同じパッケージに対して個別に対処するのではなく、その作業をベンダーニュートラルな場で共同化するのがOSERAの基本思想です。

Deutsche Bank、Goldman Sachs、Morgan Stanley、Royal Bank of Canada(RBC)、TD Bank Groupがすでにエンドツーエンドのパイロットを完了しており、日本の金融機関からの参画も検討に値するでしょう。OSERAは、DORA(デジタルオペレーショナルレジリエンス法)、NIS2、CRAなど欧州の規制フレームワークへの準拠を共有可能な監査証跡で支援することも大きな特徴です。

Morgan StanleyのディスティングイッシュドエンジニアであるDov Katz氏は「大規模な金融機関が運用する規模では、修正パッチの作成は課題の半分に過ぎず、複雑で規制された環境全体にわたってそれを確実に適用することが同等に重要です」と述べています。

CRA準備は改善どころか悪化
ー「2026 CRA認知度・準備状況レポート」が警鐘

LF Research、OpenSSF、Balena、Ericsson、Revaniteの共同により「2026 CRA Awareness and Readiness Report(2026年 CRA認知度・準備状況レポート)」が2026年6月初旬に公開されました。EU Cyber Resilience Act(CRA)への準備状況を追跡する2回目のレポートですが、その結果は「改善どころか悪化」という衝撃的なものでした。

【参照】2026 CRA Awareness and Readiness
https://openssf.org/wp-content/uploads/2026/06/2026_CRA_Awareness_Readiness_Report.pdf

認知度66%が「未認知」ー2025年の62%からさらに後退

レポートの最も深刻な発見は、CRAに「馴染みがない」と回答した割合が2025年の62%から2026年の66%に上昇したことです(レポートp.7)。特に北米(米国・カナダ)では72%が未認知であり、自社製品がEU市場に投入される場合に適用される規制を知らないまま操業している状態です(レポートp.8)。

CRAを認知している回答者の中でも、知識ギャップは2025年とほぼ同じです。約4割はCRAが自組織に適用されるかどうかすら判断できておらず、製造者(manufacturer)とスチュワード(steward)の区別が54%の回答者にとって不明確なままです(レポートp.9)。完全準拠期限を2027年12月と正しく回答できたのはわずか34%でした。

2026年9月の最初の義務期限が迫る

特に緊急性が高いのは、2026年9月に発効する最初のハードデッドラインです。これ以降、製造者は積極的に悪用されている脆弱性と深刻なセキュリティインシデントを24時間以内に報告する義務を負います。しかし、全製品についてSBOM(ソフトウェア部品表)を生成している製造者はわずか32%に留まっています。

さらに、2026年第1四半期のOSSプロジェクト全体の公開脆弱性は前年同期比394%増加し、高重要度の脅威は811%増という爆発的な増加を見せています。これは先述のAkritesおよびOSERAが設立された背景とも直結しており、AI支援による脆弱性発見の加速がCRA準拠の難しさをさらに増幅しています。

製造者の41%が2027年12月の期限までに完全準拠を達成できると見込んでいる一方、39%は準拠能力について完全に不確実な状態です(レポートp.15)。また、56%の組織が不準拠の場合の罰則を認識しておらず、リスクが適切に評価されていません。

レポートは認知向上キャンペーンだけではギャップを埋められず、次のフェーズの取り組みはカンファレンス、OSSツーリングのドキュメント、コミュニティチャネルなど、開発者が実際に活動する場所で行う必要があると提言しています。CRAを認知している回答者の48%がそうしたコミュニティチャネルで学んでおり、公式EUチャネルが到達したのはわずか25%です(レポートp.8)。LFは無料コース「Understanding the EU Cyber Resilience Act(LFEL1001)」やCRA Stewards Playbook等のリソースを提供しています。

Google/WHOからLFへ
ー「Open Health Stack Software Foundation」の設立を発表

LFは2026年7月9日、AI対応のデジタルヘルスソリューションを構築するためのオープンソースツールの、ベンダーニュートラルでコミュニティ主導の拠点となる「Open Health Stack Software Foundation(OHS-SF)」の設立意向を発表しました。

【参照】Linux Foundation Announces Intent to Launch Open Health Stack Software Foundation to Advance Open Source Digital Health Innovation
https://www.linuxfoundation.org/press/linux-foundation-announces-intent-to-launch-open-health-stack-software-foundation-to-advance-open-source-digital-health-innovation

OHS-SFは、2023年にGoogleとWHO(世界保健機関)が共同で立ち上げた「Open Health Stack」プロジェクトを母体としています。Googleがコードと関連資産をLFに移管するとともに、Google.orgから300万ドルの助成金が提供されます。WHO、Anthropic、Microsoft、Clinton Health Access Initiative、Johns Hopkins Bloomberg School of Public Healthなど20以上の組織が初期支持を表明しています。

3つの技術的柱:FHIR基盤、OHSプレイヤー、AI Commons

OHS-SFは、グローバルなオープン標準に基づく3つの技術的柱を中心に構成されます。第1に、HL7 FHIR(Fast Healthcare Interoperability Resources)に基づくコア基盤です。FHIRは医療データの相互運用性のための国際標準で、免疫、HIV、母子保健など個別に構築されてきたサイロ化した医療情報システムを統合するための共通基盤を提供します。

第2に「OHSプレイヤー」と呼ばれるマルチプラットフォーム参照ツールキットです。これにより、各国・各地域の開発者がローカル環境に適応したデジタルヘルスアプリケーションを構築できます。

第3に、WHOと共同開発する「AI Commons」です。これはモデルに依存しない中立的な空間で、グローバルヘルスにおけるAIの安全性、有効性、検証可能性を担保するための取り組みです。

低・中所得国の開発者がガバナンスに参加できる仕組み

OHS-SFの特徴的な設計として、低・中所得国(LMIC)の開発者がガバナンスに直接参加できる「Implementer Program」が導入されます。小規模事業者、地域のコンサルティング企業、プレレベニュースタートアップが財政的障壁なしにプロジェクトの方向性を決定する場に参加できます。非営利、学術、政府機関のメンバーシップはLF Associate Membershipティアに準じて無料です。

LFのCEOであるJim Zemlin氏は「オープンソースはすでにエンタープライズソフトウェア、クラウドコンピューティング、AIを変革しました。世界がケアを提供する方法についても同様のことが起きるでしょう」と述べています。

まとめ

今回は、OSSセキュリティ、EU規制対応、デジタルヘルスという3つの異なる領域における重要な動きを取り上げました。

AkritesとOSERAは、OSSセキュリティにおける「上流と下流の連携」という新たなモデルを提示しています。Akritesがアップストリームで脆弱性の協調修正を行い、OSERAが金融セクターという規制産業での下流適用を共同化する。この二層構造は、前回で取り上げた欧州版Tech Talentレポートが示したセキュリティ懸念の深刻さ(51%が最大障壁と回答)と、今回のCRA準備状況レポートが示す準備の遅れを具体的なアクションで解決しようとする試みです。日本のPSIRTやセキュリティチームにとっても、AkritesやOSERAとの連携や情報共有の仕組みを検討する価値があるでしょう。

CRA認知度・準備状況レポートは、2026年9月の最初の義務化と2027年12月の完全準拠期限に向けて、エコシステム全体の準備が十分に進んでいないことを明確に示しています。OSS脆弱性の公開件数が前年比394%増という爆発的増加の中、SBOMの生成体制が32%に留まる現状は、EU市場に製品を投入する日本企業にとって喫緊の課題です。

OHS-SFの設立は、OSSの適用範囲がITインフラストラクチャからグローバルヘルスへと拡大していることを示す象徴的な出来事です。WHOとの連携、LMICの開発者のガバナンス参加という設計は、オープンソースがデジタルデバイドの解消に貢献しうることを示しています。

なお、7月16日にはx402 Foundationの運用開始も発表されています。Coinbaseが開発した「x402プロトコル」をLFに移管し、40メンバーが参画するこの取り組みは、AIエージェントやAPIがHTTP上でシームレスに決済を行うためのオープン標準を目指しています。前回で紹介したOpenSharing(AIアセット共有)と合わせ、エージェンティックAI時代の「データ共有」と「決済」の両面でオープン標準が整備されつつある点は注目に値します。

【参照】Linux Foundation Announces Operational Launch of x402 Foundation to Standardize Internet-Native Payments for AI Agents and Applications
https://www.linuxfoundation.org/press/linux-foundation-announces-operational-launch-of-x402-foundation-to-standardize-internet-native-payments-for-ai-agents-and-applications

また、7月28〜30日には横浜で「KubeCon+CloudNativeCon Japan 2026」が開催されます。クラウドネイティブコミュニティの日本における最大イベントとして、AI時代のKubernetes活用に関する最新動向が共有される予定です。

人気記事トップ10

人気記事ランキングをもっと見る

企画広告も役立つ情報バッチリ! Sponsored