AI駆動開発の納品前チェックリスト、品質を「確かめた記録」で渡すキット──レビュー・テスト・セキュリティ・ライセンス・ドキュメントの確認項目50、判定の記録表、例外の記録、顧客向け納品報告書、チェック工数の計算例

この記事は、AI駆動開発で作ったWebサイトやシステムを、納品の前に何で確かめ、どう記録して渡すかという、納品前チェックリストを扱います。

誰が何を見るかというレビューの体制は、無料の記事で扱っています。

▶ AIコードレビューの体制、制作会社は「誰が何を見るか」を先に決める──書いた人・確かめる人・承認する人の役割分担と、レビュー工数を月の予定に確保する計算例

メンバーシップ「黒字化オペ室」では、これまでの有料記事を全て読めます。価格、外注、採用、給与を、一本の流れとして。

月額1,980円、単品記事2本分の金額です。合わなければ、いつでも退会できます。詳しくはプロフィールから。

「AIで作ったところは、ちゃんと確認してありますか」

検収の打ち合わせで、お客様の情報システムの担当者から、こう聞かれました。
担当のエンジニアは「はい、確認しています」と答えましたが、何を確認したかを示す紙は、どこにもありませんでした。

お客様が知りたいのは、AIを使ったかどうかではありません。
何を、誰が、どこまで確かめたのか。その記録がないことが、不安の正体です。

記録がなければ、検収の打ち合わせは「信じてください」の一言で終わります。
そして、納品後に不具合が一つ出れば、AIで作った部分すべてが疑われます。

納品前の品質チェックとは、案件の範囲で「確かめると決めた項目」を、書いた人以外が確かめ、その結果と例外を記録に残して、お客様に渡せる形にする工程である

黒字化の外科医です。AI駆動開発の納品を、記録で説明できる形にするチェックリストを解剖します。

なお私は弁護士ではありません。実務の指針として読み、個別の判断は専門家や公的な窓口に確認してください。

チェックリストが必要な理由は、三つあります。

第一に、AIで速くなるほど、確かめる項目の抜けが起きやすいから。
実装が数時間で終わると、「いつもの確認」を飛ばしても気づきません。項目が紙にあれば、飛ばしたことが見えます。

第二に、確かめたことは、記録がなければ説明できないから。
検収で揉めたとき、口頭の「確認しました」は根拠になりません。項目、結果、確認した人、日付が残っていれば、話は事実の確認になります。

第三に、AIの出力には、人が書くときには起きにくい種類の抜けがあるから。
実在しない部品の名前、出どころの分からないコード、使われていない処理の残り。レビューとテストに加えて、ライセンスとドキュメントの確認を項目に入れる必要があります。

今すぐ試せる：案件に合わせて確認項目を絞り込むプロンプト

私はWeb制作会社の技術責任者です。納品前の確認項目を、この案件に合わせて絞り込んでください。
（顧客名、ID、パスワード、APIキーなどの秘密情報は入力しません）

【前提】
・案件の種類（コーポレートサイト、LP、会員機能、EC、業務ツールなど）：〔　〕
・契約で約束した範囲と、検収の基準：〔　〕
・AIに書かせた範囲：〔　〕
・対応すると約束したブラウザと端末：〔　〕
・確認にかけられる時間：〔　〕

1. 下の6分類（レビュー、テスト、セキュリティ、ライセンス、ドキュメント、引き渡し）ごとに、この案件で必須の項目と、省いてよい項目を分ける。
2. 省く項目には、省く理由を1行で書く。
3. 必須の項目の「確かめ方」と「合格の目安」を書く。
最終の判断は人が行う前提で、案の形で出すこと。

AIが出した案は、次の工場の50項目と照らし合わせて、抜けを人が確かめます。

ここから先に、6分類50項目の確認表、判定の記録表、例外の記録の型、顧客向けの納品報告書、チェック工数の計算例と見積もりへの載せ方を置きます。