アプリケーションからImageSharpへの依存を取り除く手順を紹介します。
ImageSharp は純粋なマネージドコードで動く高品質な画像処理ライブラリです。
しかし近年のライセンス方針の変更で、使い続けるうえでの負担やリスクが大きくなっています。
ImageSharp は v3.0.0(2023年)から「Six Labors Split License」というライセンスに変わっています。
オープンソースやソース公開のソフトウェアで使う場合は Apache License 2.0 が適用されます。
一方、年間総収入が100万USDを超える組織が商用アプリケーションで使う場合は、有償の商用ライセンスが必要です。
このライセンスは利用者や用途によって条件が変わるため、OSI が定めるオープンソースの定義を満たしません。
Six Labors 自身もOSI非承認であることを認めています。ソースコードは GitHub で公開されていますが、「誰でも無条件に自由に使えるライブラリ」では
ないことに注意が必要です。この変更に伴い、ImageSharp は .NET Foundation からも離脱しています。
2026年5月にリリースされた ImageSharp 4.0.0 から、パッケージを直接参照するプロジェクトのビルド時にライセンスキーが必須になりました。
キーが無いか無効な場合はビルドが失敗します。
さらに2026年10月には、v3系の最新版である 3.2.0 にも同じ強制が導入されました。
これまではv3系に留まればキー無しで使えましたが、今後のセキュリティ修正を受け取るにはキーの設定が必要です。
キー強制を避けて 3.1.x 以前に留まることは可能です。ただし 3.2.0 にはセキュリティ修正がバックポートされているため、
3.1.x には修正済みの既知の脆弱性が残った状態になります。NuGet のパッケージ監査で脆弱性の警告が出てビルドが止まる、というケースもすでに報告されています。
条件を満たす個人・小規模事業者・OSSプロジェクトは、無料のコミュニティキーを申請できます。ただしキーには有効期限があり、期限前の更新手続きが必要です。
更新を忘れてキーが切れると、ビルドが通らなくなります。急ぎのセキュリティ修正を適用したいときに CI が失敗する、といった事態も起こり得ます。
キーの管理、CI へのシークレット設定、期限の把握といった、従来のライブラリには無かった運用作業が継続的に発生します。
Six Labors はこの1年で、ライセンスキーの強制範囲を2度広げています。v4以降の新バージョンから始まり、次にv3系の新リリースにも拡大しました。
ライセンス条件そのものは「変更していない」と説明されています。しかし実際の運用ルールは段階的に厳しくなっています。
コミュニティからの批判に対しても、Six Labors はライセンスと商用モデルを見直すつもりはないと明言しています。
依存し続ける限り、将来の方針変更の影響を受け続けることになります。
このような状況から、ImageSharpを利用したくないという状況が出てきています。
今回はClaude Codeで処理します。初めに実行計画を策定します。次のプロンプトをClaude Codeで実行します。
処理が始まり、手順書が作成されます。
プログラムの内容によって、結果は変わりますが、以下のような移行案が作成されます。
メリット、デメリットが提示されるので確認して方針を決めます。
以下のプロンプトを実行します。
Claude Codeの場合、ビルドまで実行して動作確認までして完成となりますが、最終確認をして問題なく動作するかを確認します。
以上でImageSharpの依存除去は完了です。
PNGファイルのテキストチャンクを取得するのにImageSharpを利用していました。この処理だけで利用していたので、このアプリは「独自の実装にする」を選択しました。
画像のリサイズと回転、回転フラグの確認にImageSharpを利用していました。画像処理があるため、このアプリは「SkiaSharp に移行する」方針としました。
PNGファイルのテキストチャンク取得、JpegファイルのEXIF 取得、画像フォーマットの判定、画像サイズ(縦横)の取得、にImageSharpを利用していました。複数の機能を利用しているため、このアプリは「SkiaSharp に移行する」方針としました。
画像の縮小と画像サイズ(縦横)の取得、にImageSharpを利用していました。こちらも「SkiaSharp に移行する」方針としました。縮小アルゴリズムですが、Lanczos3はSkiaSharpには無いため、アルゴリズムをLanczos3から、Mitchell へ変更することになりました。