seoTitle: Docker Scout廃止機能を個人開発者向けに整理
metaDescription: Docker Scoutの通知・ECR連携・ポリシーページ廃止を、実務目線でやさしく解説。CLIとCIでの代替手順をまとめました。Dockerの公式ドキュメントが更新され、2026年9月1日付でDocker Scoutの複数機能が順次廃止されることが案内されました。廃止の対象となっているのはCVE通知、Amazon ECR・Azure Container Registryのネイティブ連携、ダッシュボードのPoliciesページ、そしてSonarQube連携です。普段からDocker Hubのイメージ管理にScoutを使っている個人開発者の方も少なくないはずなので、「自分に影響があるかないか」をこのタイミングで一度整理しておきたいところですね。今回は、何が廃止されるのか、そしてどんな代替手段が用意されているのかを、順番に確認していきましょう。
今回の廃止対象を整理してみましょう
まず押さえておきたいのは、Docker Scoutそのものがなくなるわけではなく、「機能の一部が役割を終える」という点です。ドキュメントによると、廃止が決まっているのは大きく分けて4つの機能です。ひとつめはCVE通知で、新たな脆弱性が見つかったときにダッシュボードやメールへ届いていた仕組みが対象になっています。ふたつめは、Amazon ECRとAzure Container Registry向けのネイティブ連携で、クラウド側のレジストリをScoutに直接つないでいた経路が閉じられます。みっつめは、ダッシュボード上のPoliciesページ、そしてSonarQube連携も同時に廃止予定です。
「通知がこなくなる」というと少し心もとない印象を受けるかもしれませんが、これは「見ないまま放置できる仕組み」を手放す、というよりも、評価の主体をCLIやCIパイプライン側に寄せる方針への切り替え、と捉えると捉えやすいでしょう。公式ドキュメントでも、今後は docker scout cves や docker scout policy といったCLIコマンド、そしてCI上での評価が推奨されています。
個人開発者が確認したい実務ポイント
ここからは、LaravelやWordPressのプロジェクトをDockerで運用している読者のみなさんに立ち止まってほしいポイントです。ひとつめは、Scoutからの通知を「脆弱性を知る唯一の入口」にしていないか、という点です。もしメールで届くCVE通知だけが頼りだったとしたら、9月1日以降はその経路が塞がれてしまうため、GitHub DependabotやCIでの定期スキャンなど、別の検知ルートを一本用意しておく必要があります。
ふたつめは、ECRやACRにpushしたコンテナイメージをScout経由で可視化していたケースです。Docker Hub以外のレジストリを使っている場合、ネイティブ連携の終了後はCLIベースの評価や、レジストリ側の脆弱性スキャンへ切り替えるという選択肢になります。普段使いのdocker-composeや、本番環境のリポジトリ構成を見直す良い機会と捉えてみてください。
みっつめは、SonarQube連携を使ってコード品質と脆弱性チェックを一元管理していた構成です。Scout側の連携は廃止になりますが、SonarQube自体は引き続き利用可能なので、CIパイプラインの中で別工程として明示的に走らせる形へリファクタリングする、という方向性が現実的でしょう。
CLIとCIでの代替、評価を回す手順
では、実際にどうやって評価を回すのか、という点を簡単におさえておきましょう。まずローカル環境では、Docker Desktopに同梱されている docker scout コマンドが使えます。イメージに含まれる脆弱性を確認したいときは docker scout cves を、ポリシーに照らして評価したい場合は docker scout policy を、それぞれ実行してみてください。どちらもdockerコマンドと同じ感覚で動かせるので、最初のハードルはそこまで高くないはずです。
次に、CIパイプライン側での評価です。GitHub Actionsを使っているなら、docker/scout-action のようなアクションを .github/workflows 配下に組み込んでおくと、pushやプルリクエストのタイミングで自動的に評価が走ります。「ローカルでは忘れていた」というケースを仕組みで防げるので、通知の廃止よりもむしろこちらの方が再現性は高くなります。
もしあなたがLaravelのアプリケーションをDockerでデプロイしていて、これまでScoutダッシュボードのPoliciesページで「問題ないか」を確認していたとしたら、今夜のうちに対応のひとつとして、評価フローをローカルCLIとCIの両方で一度走らせてみてください。コマンドが実際に動くか、そして出力の差分をどこで受け取るかを、今のうちにチームや自分の「いつもの手順」として決めておくと、9月以降も慌てずに済みますよ。次は、この評価結果をPRのチェックとして自動組み込みする手順を、具体例つきで紹介していきたいと思います。
関連記事: Docker管理ツールDockhand 1.0.47登場：デプロイ履歴と検証機能で運用を自動化 、 Docker Composeのprofiles機能：開発環境とテスト環境でコンテナを起動し分ける設計.