AI開発でテストした版と配布する版を一致させる

AIが実装や修正を進める開発では、レビューを通ったソースから何が作られ、どの成果物をテストし、その後どれを配布しようとしているかを連続して追います。同じリリース名やタグ名は内容の同一性を保証しません。配布直前に、承認済み成果物のdigestと、実際に配布場所へ渡す成果物のdigestを比較するところから判定を始めます。

SLSAのBuild Provenanceは、成果物がどこで、いつ、どのように作られたかを説明する検証可能な情報です。特定のビルド基盤がbuildDefinitionを実行し、成果物群を生成したことを示すattestationとしてモデル化されています。2026年9月21日確認時点のSLSA v1.2では、出力成果物をstatementのsubjectで表せます。digestの照合は、検証対象の成果物を来歴のsubjectへ結び付ける入口になります。

それでも、digestの一致だけで配布可にはできません。誤ったソースや想定外の条件から作られた成果物を、そのままテストした可能性が残るためです。来歴の署名、subject、builder、ソースとビルド条件も自社の期待値に照らし、「承認した生成経路の成果物を配る」と確認できた時点で判定がそろいます。

確認記録は、一つの配布判断を一行として扱います。列は「承認対象のソースcommit」「依存固定ファイルのdigestまたは解決済み依存の識別子」「builder.idとinvocationId」「テスト対象成果物のdigest」「配布対象成果物のdigest」「期待値との照合結果」です。これは出典の一般原則を実務へ移すための提案で、SLSAやNISTが定める分類・義務ではありません。

たとえば、ソース欄には承認レビューの対象になったcommitを置きます。依存欄には、そのcommitで使う依存固定ファイルのdigest、または来歴に含まれる解決済み依存の識別子を置きます。ビルド欄には許可したbuilder.idと、その回の実行を区別するinvocationIdを置きます。成果物欄はテスト対象と配布対象を分け、双方のdigestを省略しません。照合結果には、両digestの一致と来歴検証の合格を配布条件として明記します。

この対応はSLSA v1.2の表現と接続できます。2026年9月21日確認時点で、外部入力はexternalParameters、解決済み依存はresolvedDependencies、出力はsubject、ビルド基盤はbuilder.id、個別実行はinvocationIdで表現できます。resolvedDependenciesには、リポジトリURIが解決された特定のGit commitを記録する例もあります。社内の列名を変える必要はありません。各列が来歴のどの値を受けるかを固定すれば、担当者が変わっても同じ関係をたどれます。

記録の単位は一回の配布判断です。再ビルドしたら、今回のinvocationIdと成果物digestをあらためて確認し、以前の行を上書きせず、新しい行を作ります。テスト済み成果物を配布対象として取り出す場合も、二つのdigestが一致することを照合結果へ残します。名前の一致を、成果物の一致へ読み替えてはいけません。

SLSAが示す成果物検証は、台帳へ値を転記する作業より広いものです。2026年9月21日確認時点の手順では、来歴の署名を確認し、statementのsubjectと対象成果物のdigestが一致するかを調べ、predicateTypeを確認します。そのうえで、認識した公開鍵とbuilder.idから信頼レベルを確認し、builder identity、正規のソースリポジトリ、buildType、externalParametersを期待値と比較します。

期待値はビルド前に決めておきます。配布を許すbuilder、対象リポジトリ、受け入れるbuildType、外部パラメータの範囲を、自社の配布条件として定めます。確認記録には実測した値と合否を結び、空欄は未確認として扱います。この運用条件は出典の一般原則を基にした提案で、原典所定の分類や義務ではありません。SLSAが、対象成果物と来歴の結合、署名確認、期待値との比較を別々の確認として示している点が根拠です。

判定の順番も固定します。まず配布対象のdigestと来歴のsubjectを対応させ、次に署名とpredicateTypeを確認し、それからbuilderやソース、ビルド条件を期待値へ照らします。最後にテスト対象digestと配布対象digestを比較します。途中のどれかを確認できなければ、記録上の結果は未確認または不合格のままにし、配布可へ読み替えません。これにより、途中の確認結果と配布の承認を混同せずに済みます。

最も迷いやすいのは、来歴は検証できるのにresolvedDependenciesが足りない場合です。SLSA v1.2では、resolvedDependenciesの完全性は少なくともBuild L3までbest effortとされ、依存の再帰検証は任意です。2026年9月21日確認時点の仕様は、記録が不完全な場合にbest-effortで確認できるとも説明しています。つまり、来歴が付いていることだけを根拠に、全依存が漏れなく固定され、検証済みだとは判断できません。

実務上は、resolvedDependenciesが不完全な行を未確認のまま止める条件を置きます。確認記録には、今回調べる依存の対象範囲、欠けている情報、別途照合したlockfileなどの対象、承認者の判断を残します。「lockfileあり」という記載では追跡できないため、どのソースcommitに対応する何のdigestを照合したかまで同じ配布判断へ結び付けます。これは出典の一般原則を基にした提案で、原典所定の分類・義務ではありません。

欠落があれば常に配布禁止とするか、別の確認と承認で進められるかは、組織の要件で変わります。NIST SSDF Version 1.1は、ソフトウェアリリースの全コンポーネントについてprovenance dataを収集・共有するタスクPS.3.2を加えています。SSDF自体は、事業要件、リスク許容度、資源、実現可能性、適用可能性などに応じて調整する出発点と位置付けられています。2026年9月21日確認時点で、この二つを併せて読むと、自社の停止条件と例外承認を明文化する必要性が見えてきます。

確認記録は工程の進行に合わせて埋めます。ビルド完了時にソースcommit、依存情報、builder.id、invocationId、subjectのdigestを取得し、テスト開始時に対象digestを記録します。配布準備では、実際の配布対象を取り出してdigestと来歴を検証し、同じ行へ結果を入れます。識別子は機械的に取得し、期待値との不一致や情報欠落を受け入れられるかは人が判断します。

レビュー、テスト、CI、人の公開判断までの入口を整理するなら、AI駆動開発の開発フロー｜レビュー・テスト・CIで人の判断を残すも併せて確認できます。この記事の確認記録は、そのフローのうちビルド後から配布直前までを細かくしたものです。AIエージェントへビルドや配布操作を許す範囲を検討するときは、Claude Codeのセキュリティ設計で権限境界も切り分けてください。成果物の追跡可能性と、エージェントが操作できる範囲は、別の判定として管理します。

導入時には、配布可に必要な情報を先に定義します。承認済みソースcommitと依存情報が来歴へ結び付き、許可したbuilderと実行を識別でき、来歴のsubjectが配布対象digestと一致し、テスト対象digestと配布対象digestも一致する。さらに署名やビルド条件の期待値照合が合格している。この連鎖を一行で読める状態にします。依存情報に欠落があれば、その範囲と補完確認と承認判断がそろうまで行を閉じません。

AI開発で差分を作る速度が変わっても、配布判断の対象は具体的な成果物です。テストした版と配る版を一致させるには、両者のdigestを照合し、そのdigestを署名付きの来歴へ結び、builder、ソース、ビルド条件を事前の期待値へ照らします。ソースの版、依存固定、ビルド実行、二つの成果物digestを同じ確認記録へ置けば、承認者は途中のつながりを追えます。

最後に決めるのが、依存情報の不完全さを扱う条件です。resolvedDependenciesが完全でない可能性を前提に、対象範囲、欠落、lockfileなどによる別照合、承認者の判断を記録し、未確認の行は止めます。配布ゲートには「テストした成果物と同じdigestで、認めた生成経路を確認できた」という根拠が残り、タグ名に頼らず配布可否を決められます。