公開パッケージレジストリの資金モデル ― OpenSSF 12 社の声明と、企業が先にやる依存の棚卸し

結論: この声明で請求は始まりません。先に、何をどこから取っているかを棚卸しします

OpenSSF は 2026 年 9 月 16 日、Google・Microsoft・GitHub など 12 組織が署名した声明を公表しました。npm、PyPI、Maven Central、crates.io といった公開パッケージレジストリに、企業が利用量と価値に応じて資金を出す仕組みを支持する、という内容です。

ただし声明は、価格・条件・階層を定めていません。料金をどうするかは各レジストリに委ねられていて、この声明を根拠に請求が始まるわけではありません。いま準備できるのは、どのレジストリから、何を、どこ経由で取っているかの一覧です。この一覧は、費用の話が出る前でも作れます。

声明の中身: 4 つのコミットメント

声明の主体は OpenSSF の Governing Board で、Linux Foundation の Sustaining Package Registries Working Group を通じて出されました。署名したのは Arm、Datadog、Dell Technologies、Ericsson、GitHub、Google、IBM、Kusari、Microsoft、Red Hat、Rust Foundation、Sonatype の 12 組織です。対象として PyPI、Maven Central、crates.io、RubyGems、npm、NuGet、OpenVSX、Packagist などが挙げられています。

声明のコミットメントは、要旨として次の 4 つにまとめられます。

• 無料は続ける: 個人開発者と小規模組織が無料で使い続けられることを支持する
• 企業は利用量と価値で: 企業の利用量と価値に基づく資金モデルを支持する
• 費用は事業費: レジストリの利用料を事業費用として扱い、セキュリティ・レジリエンス・コンプライアンスへの投資と捉える。通常のソフトウェアサービスの購入とは異なる位置づけで、各レジストリの既存の利用規約を尊重する
• 決めるのは各レジストリ: 各レジストリの実験的なモデルを支持し、その自律性を尊重する

無料の維持については、声明に次の一文があります。"We do not want paid models to create barriers to individual developers' everyday publishing, discovery, and installation workflows. Open source stays open."(有償のモデルが、個人開発者の日常の公開・発見・インストールの流れを妨げることは望まない。オープンソースはオープンのまま、という趣旨)。

背景: 利用は年 30〜50% 増え、資金は横ばい

声明が背景として挙げる数字は、利用と資金の差です。ダウンロード量は年 30〜50% 増えている一方、資金は横ばいと書かれています。私たちはこの差を「開いていく差」と呼びます。

声明は背景として、ほかに 3 つの数字を挙げています。2026 年に悪意あるパッケージとしてフラグされたものが 180 万件であること。AI が見つける脆弱性が増えることで、パッケージの公開(publish)イベントが 3〜5 倍になると見込んでいること。多くのレジストリが 2〜3 人のチームで運営されていることです。取りに行く先が少人数で回っている、というのが声明の描く姿です。

これらの数字は署名した組織が声明に書いたもので、私たちは第三者による検証を確認していません。傾向を示す材料として読み、個別の数値を他の資料に転記するときは声明の原文に当たる必要があります。

声明が決めていないこと

• 価格・条件・階層: 声明に規定はありません。いくらか、どの規模から対象か、どんな階層があるかは、現時点では言えません
• どのレジストリが、いつ導入するか: 声明は各レジストリの実験的なモデルを支持するとしているだけです。同じ内容を報じた IT Pro(2026 年 9 月 17 日)にも、個別のレジストリの計画への言及は見当たりませんでした
• 利用量の測り方: 「利用量に基づく」とあっても、価格や条件が決まっていない以上、何をどう数えるかも決まっていないと読めます

したがって、有償化が決まったと読むのは誤りです。読めるのは、署名した 12 組織が、企業が資金を出す方向を支持すると表明したところまでです。

依存管理への効き方: 4 つの論点

1. 依存管理 — 取得先の一覧が入口になる。 声明の軸は企業の利用量と価値です。利用量を何で測るにせよ、自社が何をどのレジストリから取っているかを把握していることが前提になります。「何を」の源は lockfile(依存の版を固定するファイル)で、「どこから」は設定ファイルで補います。

私たちは 2026 年 7 月に、各プロダクトの lockfile を osv-scanner(脆弱性情報を照合する走査ツール)で毎日走査する仕組みを入れました。対象は npm・PyPI・Packagist・Pub の 4 つのエコシステムで、目的は脆弱性と EOL(サポート終了)の検知でした。費用の把握のために作ったものではありません。ただ、依存の一覧を機械で読める状態は、この論点で最初に必要になるものです。

2. ミラー・キャッシュ — 取得の経路を数えられる形にする。 利用量の測り方は決まっていません。そのため、社内のプロキシやキャッシュを挟む構成が有利になるか不利になるかは、現時点で言えません。言えるのは、公開レジストリへ直接取りに行く経路と、社内キャッシュ経由の経路が混在している場合、公開側にどれだけ届いているかが分からないということです。数えられる状態にしておけば、測り方が示されたときに自社の位置を確認できます。

3. SBOM — 依存の中身の台帳。 SBOM(ソフトウェア部品表。ソフトウェアが何の部品で構成されるかの一覧)は、声明のコミットメントには挙がっていません。ただ、声明は料金を「セキュリティ・レジリエンス・コンプライアンスへの投資」と位置づけています。社内でこの費用を説明するとき、何に依存しているかを示す台帳が説明の材料になる、というのが私たちの見方です。

4. 費用の置き場 — 事業費として扱う前提。 声明はレジストリの利用料を事業費用として扱うと書いています。実務では、案内が届いたときに誰が受け、どの予算と稟議で処理するかを先に決めておくと、対応の入口がはっきりします。勘定科目や会計上の扱いは、経理担当と確認する必要があります。

今日から: 取得先の棚卸し 3 ステップ

対象は 1 リポジトリからで始められます。全社の棚卸しを一度に終える必要はありません。

1. lockfile を集めます。npm なら package-lock.json、Python なら poetry.lock や固定した requirements.txt、PHP なら composer.lock が対象です。リポジトリごとに、どのエコシステムの何個の依存があるかを 1 行にします
2. 取得先を 1 行ずつ記録します。公開レジストリを直接見ているのか、社内のプロキシやキャッシュを経由しているのかは、.npmrc、pip.conf、Maven の settings.xml などの設定と、CI の設定で分かります
3. 費用の窓口を決めます。レジストリ側の案内を誰が受け取るか、その記録をどこに置くか、声明の原文と各レジストリの公式告知を誰が確認するかを、担当者の名前で書いておきます

まとめ

案内が出たときに読むのは、声明ではなく、各レジストリの利用規約と案内です。「開いていく差」を誰がどう埋めるかは、声明の段階では決まっていません。

決まるまでの間に企業側でできるのは、自社の取得先を把握しておくことです。案内が出たときに、自社の取得先と担当者がその一覧に載っていれば、判断を先送りせずに済みます。載っていなければ、判断の前に調査から始めることになります。

関連

AI エージェントを業務で回すときの設計と運用については、CTO の note に書いています。

• Leadeas CTO｜note

出典

• OpenSSF ブログ(2026-09-16): 持続可能なパッケージレジストリへの企業コミットメント(一次情報)
• IT Pro(2026-09-17): 同声明の報道

※ この記事は AI を使用しています。Leadeas が自社開発した AI エージェント基盤で下書きを作成し、人間のレビューを経て公開しています。AI ネイティブ開発会社として自社の技術をそのまま実演する目的で、この手法を用いています。(詳しくは AI 利用ポリシー)