要約
Aikidoは、依存関係のアップデートに破壊的変更が含まれているかを確認し、何が変更されたかを表示します。その後、コードベースを分析し、それらの変更が実際にコードベースに影響を与えるかどうかを判断します。チームはセキュリティ修正をマージする前に明確な回答を得られます。
ドキュメントはこちらでご確認ください。
破壊的変更が重要である理由
開発者はフロー状態を維持したいと願っていますが、セキュリティ問題によってその状態が妨げられることがよくあります。これは集中を中断させるだけでなく、次に何をすべきかという不確実性をもたらすためです。開発者はアラートに圧倒されていますが、コードのマージやライブラリのアップグレードが安全であるかどうかが分からない場合、行動を全く起こさないことがよくあります。
その傾向は明らかです。2026年 Aikidoの「セキュリティと開発におけるAIの現状」によると、開発者、セキュリティエンジニア、リーダーの65%が、疲労と検出結果への信頼の欠如のため、セキュリティチェックを回避したり、検出結果を無視したり、修正を遅らせたりしたと述べています。
Aikidoは、開発者にこの自信を取り戻してもらうことを目指しています。その方法の一つとして、オープンソースの依存関係に対する2つの補完的な機能、Breaking ChangesとUpgrade Impact Analysisを提供しています。
開発者は、理由を理解せずに修正を行うべきだと指示されることを望んでいません。また、そのような行動による副作用が何であるか、例えばアプリケーションが破損する可能性があるかなども知りたいと考えています。
これこそが、開発者を不安にさせる不確実性です。
破壊的変更の可視化
開発者の認知負荷を増やすのではなく、事前にコンテキストを提供することこそが、Breaking Changes機能のすべてです。
アップグレードがマージされる前に、Aikidoはチェンジログを分析し、破壊的変更が導入されるかどうかを判断します。すべてのアップグレードは、「問題なし」、「破壊的変更あり」、「手動検証が必要」の3つのカテゴリのいずれかに分類されます。
1. 問題なし
破壊的変更がない場合、アップグレードは安全であると明確にマークされます。
開発者は自信を持って修正を進めることができます。
依存関係の問題は、それを修正するために必要な最小バージョンを示します。下記のSpring Securityの例では、CVEがバージョン6.1.2へのアップグレードによって修正されることが明らかです。
アップグレードは安全であると明確にマークされ、検証のために関連するチェンジログがリンクされているため、開発者はアップグレード適用時に何も破損しないことを確信できます。
2. 破壊的変更あり
アプリケーションに影響を与える破壊的変更がある場合、Aikidoがこれをフラグ付けします。
破壊的変更は、アップグレードと並行して直接要約されます。
In this example, Tomcat may have previously allowed requests with slightly malformed headers, or those that had a missing <host> header, or even conflicting host information. The new version rejects those requests with a 400 Bad Request by default.
アップグレードはアプリケーションコードを変更しませんが、レガシーなクライアントや、そのようなタイプのリクエストを送信する内部ツールとのインタラクション、およびその他のエッジケースを破壊する可能性があります。
代わりに、レガシーなクライアントが存在せず、すべてのトラフィックが適切に設定されたプロキシを介していることを知っていれば、すぐにアップグレードできます。あるいは、マージ前にテストしたり、インフラ作業がより理にかなっているスプリントにアップグレードをスケジュールしたり、CVE修正のためにアップグレードしつつ一時的に厳格な設定を緩和したりすることも可能です。
3. 手動検証が必要
チェンジログが存在しない場合、その不確実性が明示されます。
これにより、開発者は破壊的変更に関する証拠がどちらの方向にもないという透明性を得られます。これは、メンテナーが破壊的変更を文書化していないか、プロジェクトのメンテナンスが不十分であることに起因する可能性があります。チェンジログが利用できない場合、アップグレードはよりリスクが高くなり、開発者はアップグレードを手動で検証する必要があることを示唆します。
Upgrade Impact Analysisの導入
破壊的変更を特定することは、全体の半分に過ぎません。
Upgrade Impact Analysisは、コードベースを分析してそれらの変更が実際に実行されるかどうかを判断することで、さらに踏み込みます。この分析はプルリクエストの一部として自動的に実行されます。
以下の例では、Mongooseのアップグレードにより2つの破壊的変更が発生します。プルリクエストは、非推奨の動作に依存する正確なファイルと行を特定し、変更内容を説明し、更新が必要な箇所を概説します。
Aikidoは、通常リリースノートを読み、使用箇所を追跡する必要がある情報をプルリクエスト内で直接表示します。
依存関係のアップグレードに推測は不要です。変更の影響が明確であれば、チームはためらうことなく作業を進めることができ（そしてセキュリティ修正がマージされる可能性が高まります）。
破壊的変更とアップグレード影響分析は、JavaScript、Python、Java（KotlinおよびScalaを含む）、Go、.NET、PHP、Clojureの各プロジェクトで利用可能です。
