SKILL ARTICLE / dockerfile-check-triage
Dockerfileの警告を、修正判断まで整理する
警告を数えるだけでなく、根拠と修正要否をそろえる。
Docker公式のBuild checksを先に実行し、警告ID、対象行、公式説明、変更差分を結びつけて、修正・確認・意図的な例外に整理するSkill案です。
この記事で紹介するSkill案は、参考資料を読んだうえで私が考えたものです。参照先が提供・評価・推奨しているものではありません。
OVERVIEW → CAN DO → BUILD
知ったことをSkillづくりに活かす
Build checksは警告ID、説明、対象行を返すが、対象リポジトリで今直すか、確認を挟むか、例外とするかの判断は利用者側に残る。
警告ごとに根拠、対象行、判断、確認方法を残し、見落としと根拠のない自動修正を減らす。
AIの一般知識でDockerfileを採点する前に、対応環境を確認してBuild checksを実行します。出力された警告IDと行番号を一次情報として保持し、検出されていない問題を同じ確度で並べません。
01 / OVERVIEW
資料の概要
Dockerの公式ドキュメント「Checking your build configuration」は、Dockerfileとビルドオプションを実際のビルド前に検査するBuild checksを説明しています。Build checksはDockerfile 1.8で導入され、Buildx 0.15.0以降、docker/build-push-action 6.6.0以降、docker/bake-action 5.6.0以降が対応環境として示されています。2026年7月31日時点で、公式公開ページ上の提供状態はBetaです。
公式資料では、通常のビルド時は違反が警告として表示され、`docker build --check .` ではビルド手順を実行せずに検査だけを行い、違反があると終了コードが非0になることが説明されています。警告にはルール名、説明、Dockerfileの行が含まれ、詳細表示ではルールの公式ページも確認できます。Betaであるため、対象環境で挙動とルールを確認してから運用へ組み込みます。
この記事では、2026年7月31日にDocker公式リポジトリのcommit `17b8430ccd2f4c4cf2aa67f6c9fa91445e76841a` で本文を照合しました。対象ページの内容に関する直近の変更は2026年3月16日です。
02 / CAN DO
できるようになること
Dockerが提供しているのはBuild checksであり、ここで考えるSkillをDockerが提供、評価、推奨しているわけではありません。このSkill案では、公式チェックの結果を出発点にし、対象リポジトリのDockerfile、構文バージョン、変更差分を読み合わせます。
各警告を「今回直す」「実行環境や意図を確認する」「理由を記録して例外にする」に分け、警告ID、対象行、公式ルール、判断理由、確認方法を一つの表にします。AIが独自のベストプラクティスを足すのではなく、公式の検出結果から人が修正要否を決められる状態まで整理します。
活かしやすい場面
- 複数のDockerfileを継続的に更新するリポジトリ
- Build checksの警告をPRレビューで扱いたいチーム
- 例外の理由を次回のレビューにも残したい場面
使う前に確認したい場面
- コンテナの実行時動作や性能を検証する作業
- 脆弱性スキャンや組織固有のセキュリティ基準の代替
- Dockerfile 1.8または対応するBuildxより前の環境
03 / BUILD
自分たちのSkill作成に活かせること
文章やコードをそのまままねるのではなく、自分たちのSkillに取り入れたい判断基準や工程の分け方を整理しました。
公式チェックを先に実行する
AIの一般知識でDockerfileを採点する前に、対応環境を確認してBuild checksを実行します。出力された警告IDと行番号を一次情報として保持し、検出されていない問題を同じ確度で並べません。
構文とツールのversionを残す
利用できるチェックや挙動は環境に依存します。Dockerfileのsyntax指定、Buildx、CI Actionのversionを出力に含め、別環境で同じ結果になると無条件に断定しない設計にします。
警告と修正判断を分ける
警告が出た事実と、今回の変更で直すべきかは別の判断です。公式説明、差分、既存の例外理由を並べ、修正、要確認、例外の三つに分けます。
04 / WORKFLOW
Skillにするときの流れ
- 01
対象環境を固定
Dockerfileのsyntax指定、Buildx、CI Actionのversionと対象Dockerfileを確認する。
- 02
公式チェックを実行
安全な対象範囲でBuild checksを実行し、警告ID、説明、対象行、公式リンクを集める。
- 03
修正要否を整理
変更差分と既存の例外理由を照合し、修正、要確認、例外に分けて確認方法を添える。
05 / TRY
試すときに使える依頼文
これは完成したSkillではありません。先に依頼文として試し、期待する結果が返ってくるかを確かめるための試作プロンプトです。
対象Dockerfileとsyntax指定、Docker Buildxのversionを確認してください。対応環境なら安全な対象範囲でBuild checksを実行し、各警告を警告ID・対象行・公式ルール・変更差分・修正案・確認方法で整理してください。修正、要確認、理由を記録する例外に分類し、コードは変更しないでください。Dockerを実行できない場合は推測で警告を作らず、未実行として止めてください。06 / BUILD BRIEF
試作するときの設計メモ
これは配布済みのSkillではありません。対象を小さく絞り、停止条件と評価ケースを足しながら確かめるための出発点です。
Docker公式Build checksの結果を、リポジトリ固有の修正判断へ整理するSkillを作る。
1. 対象Dockerfile、syntax指定、BuildxとCI Actionのversionを確認する。
2. 外部接続、認証情報、build contextを確認してから、対応環境でBuild checksを実行する。
3. 警告ID、説明、対象行、公式ルールURLを構造化する。
4. 変更差分と既存の例外理由を照合し、修正、要確認、例外に分類する。
5. 出力に根拠、判断理由、確認方法、未検証範囲を含め、自動変更は行わない。07 / WATCHOUTS
人が確認するところ
- `--check` はビルド手順を実行しませんが、例示の出力ではベースイメージのメタデータ取得や認証処理が発生しています。外部接続、認証情報、対象コンテキストを実行前に確認します。
- 警告を一括で自動修正せず、Dockerfileの意図と実行時の影響を人が確認できる形で提案までに留めます。
- Build checksを、動作確認、性能測定、脆弱性検査の代わりとして扱いません。