メジャーアップグレードなしで、使用中のバージョンにCVE修正だけをバックポートするAikido Librariesを解説。仕組みと料金、通常のAutoFixとの違い、そして「テスト不要にはならない」という日本の現場で一番大事な論点まで。
依存ライブラリに CVE の通知が来た。修正は済んでいる。ただし、修正が入っているのは 2 つ先のメジャーバージョンだけ。
アップグレードすれば、API の非互換が出る。呼び出し箇所を全部直す。回帰テストを回す。リリース計画を組み直す。関係部署の承認を取る。——脆弱性そのものの修正は、元のライブラリではおそらく数行のパッチです。しかし、その数行を自分のシステムに運び込む手段が「メジャーアップグレード」しかない。
こうして「直せるのに塞げない脆弱性」が積み上がっていきます。スキャナーの検出一覧に何ヶ月も居座り続けるあの項目たちの多くは、怠慢の産物ではありません。修正の適用と、アップグレードの計画という別の仕事が、束になって売られているだけです。
Aikido が 2026 年に出した「Aikido Libraries」は、この束を解く機能です。
Aikido Libraries がやることは一つです。ロックファイルに固定されている、まさにそのバージョンに対して、セキュリティ修正部分だけをバックポートした派生パッケージを提供する。
例えば starlette 0.27.0 は starlette 0.27.0+aikido.1 になります(npm はプラス記号が使えないためハイフンで 2.5.0-aikido.1)。サフィックスの +aikido.N が「Aikido のパッチ第 N 版」の印です。
適用は 3 ステップです。AutoFix > Aikido Libraries の画面で対象リポジトリを選んで保護を有効化する(この時点で必要なクレジットコストが提示されます)。Aikido がロックファイル内のパッケージに影響する CVE を調べ、パッチ済み派生版を用意する。そして、マニフェストとロックファイルを派生版に向ける PR が届くので、レビューしてマージする。
一度保護を有効化すれば継続的に動きます。公式の説明では、新しく発見された CVE も含めて、パッチ版へのピン留めが毎日の PR として届くとされています。
対応エコシステムは npm、PyPI、Maven、Go、NuGet、Composer。カバレッジはエコシステムごとに異なり、どのパッケージ・バージョンに派生版があるかはカタログで確認できます。
Aikido には以前から AutoFix(修正 PR の自動作成)があります。違いは「運搬手段」です。
| 通常の AutoFix | Aikido Libraries | |
|---|---|---|
| 提案する修正 | CVE を直す最小のバージョンアップ | バージョンアップなし。今のバージョンへの修正バックポート |
| アップグレード | 発生する(小さくても) | 発生しない |
| 向くケース | 活発に開発中で、上げるコストが低いリポジトリ | レガシー、メンテ終了した依存、自分で制御できない推移的依存 |
公式 FAQ の言い方を借りれば「アップグレードが速い選択肢ならそれでいい。アップグレード自体が問題のときに Libraries を使う」。両方の併用も可能で、保護済みリポジトリでも、固定対象外の問題には通常の AutoFix が動きます。
料金は、保護するリポジトリ単位の 1 年間サブスクリプションで、支払いは Aikido クレジット。有効化の確定前にコストが表示され、解約するまで毎年更新される方式です。
ここが、この機能を日本で使ううえで一番大事な話です。
「同じバージョン・同じ API なら、テストせずにマージしていいのか」——答えは、いいえです。公式ページ自身も「挙動は変わらないはず(Behavior should stay the same)」という表現に留めています。バックポートパッチ自体が不具合を含む可能性はゼロではなく、修正が触れた実行パスに依存する挙動差もあり得ます。テストせずに本番へ、という運用は信用に値しません。
正確に言えるのは、こうです。テストが不要になるのではなく、テスト範囲を設計できるようになる。
フルアップグレードでは、API 変更・依存関係の連鎖・非互換の可能性が全体に及ぶため、回帰テストの範囲を「全部」から狭められません。一方バックポートでは、変更されるのはセキュリティ修正の差分だけで、その差分は PR で確認できます。だから「差分が触れた機能の周辺+主要経路のスモークテスト」という絞り込みに、根拠を持たせられる。テスト工数がゼロになるのではなく、桁が変わる——これがこの機能の正しい効能です。
もう一つ、導入判断の場で必ず出る問いがあります。+aikido.N は、元のメンテナーではなく Aikido がビルドした派生物です。つまり、依存関係の供給元が一つ増える。サプライチェーンの観点では、この事実から目をそらすべきではありません。
判断材料は用意されています。修正はレビュー可能な PR として届くので、差分は自分の目で確認できます。ベースバージョンが固定なので、比較対象も明確です。バージョン文字列にサフィックスが残るため、SBOM 上でも「どれが Aikido のパッチ版か」は識別できます。
そのうえで、組織としてやるべきことは変わりません。派生版の出所を依存管理の台帳に載せ、SBOM や第三者ライセンス一覧にも派生パッケージを含めて記載し、監査で「このサフィックスは何か」と問われたときに答えられる状態にしておく。供給元が増えることを受け入れる判断は、ツールではなく組織がするものです。
未対応の CVE 一覧を眺めると、残っている理由の多くは技術的な難しさではありません。リリース計画、テスト工数、責任分界——段取りのコストです。Aikido Libraries は、そのコストを脆弱性修正から切り離す道具です。修正の適用と、アップグレードの計画を、別々の仕事に戻す。
実は、この「パッチ適用」と「機能アップグレード」の分離は、新しい発想ではありません。Red Hat や Ubuntu などの Linux ディストリビューションが LTS で長年続けてきたバックポートと同じ考え方です。OS の世界では当たり前だったこの運用を、アプリケーションの依存ライブラリの層に持ち込んだ——そう位置づけると、この機能の座りの良さが分かります。
ただし、切り離せないものが 2 つ残ります。差分に応じたテストの設計と、供給元を管理する規律です。「テストしなくて良い」ではなく「テストを設計できるようになる」。この一線を守って使う限り、放置された CVE の山を崩す道具としては、かなり実用的な選択肢だと思います。
参考:
関連記事: DSPM が「どこで機微データを扱っているか」を追跡するのに対し、Libraries は「依存ライブラリの脆弱性」をアップグレードなしで修正します。役割は違いますが、レポートで終わらせず PR まで届けるという思想は共通です。同時期に公開された「Aikido DSPM」については、別記事で解説しています。
Aikido Community Japan
公開日: 2026/7/22
最終更新: 2026/7/22
セキュリティの最新情報をお届けします。