AI が作った納品物の「完成しました」は、事実ではなく主張です。
正式受領・社内引き渡し・公開を判断する前に、その主張をファイルと実際の動作に突き合わせて、合否を証跡付きで出します。
購入前に「見積り・カスタマイズの相談」から受入前提チェック1〜5(購入にあたってのお願い欄に記載)を送ってください。適合確認後に提案します。
■こんな方へ
・AI(または AI を使う外注先)から納品物を受け取る立場だが、社内にそれを独立して検証できる目がいない
・「動きます」と言われたが、自分では合否を確かめる手段がない
・受入・支払い・公開の判断が近く(期日がある)、その前に第三者の証跡が欲しい
逆に、ご自身で検証できる方・要件がまだ固まっていない方には向きません。後者は要件定義の段階で、これは検収の商品です。
■やること
・合意した受入基準に沿って動作を確認
・合否 / 不可 / ブロックを時刻付き証跡で記録
・同じ確認を再現できる手順を残す
・優先度付きで例外(引っかかった点)を列挙
■やらないこと
・実装の修正・バグ潰し
・品質 / セキュリティ / 法令の保証
・「成功する」という保証・成果 claim
・要件定義・仕様づくりの代行
■納品物 (1 システムあたり)
1. 合意した受入基準マトリクス(どの動作を、何をもって合格とするか)
2. 時刻付きの合否 / 不可 / ブロック証跡
3. 再現可能なチェック手順
4. 優先度付きの例外一覧
・対象: 1 システム、事前合意した重要フロー 2 本
・期間: 実施可否を確認できてから 7 営業日
・含まないもの(明記): 本番の認証情報・MFA・決済データ・顧客個人データの取り扱い、品質/セキュリティ/法令の保証、成功の claim
■認証情報の取り扱い(明記)
認証情報・MFA・本番データは受領しません。認証が必要な確認は、発注者側で手順を再実行し、サニタイズ済みの画面・ログ・出力を共有できる場合だけ対象にします。
■AI利用について(明記)
本サービスはAIを補助に使い、最終判断は人が行います。
この商品は「動くかどうか」を確かめるものなので、確かめる基準(何をもって合格か)が最初に要ります。
下記 1〜5 が揃わない場合は、受注をお断りします。黙って要件定義に化けさせたり、支払い後に全フローを「ブロック」で返したりはしません。
1. 現物(動くもの/ファイル/URL)がすでに手元にある
2. 「何を・いつ決めるか」= 受入判断とその期日が存在する
3. 発注者が、観察可能な合格動作を専門用語なしで 2 つ言える
4. サニタイズ済みデータを使い、発注者側で再実行して画面・ログ・出力を共有できる
5. 各フローについて、期待結果と証跡の取り出し元を事前に合意できる
独立検証は作り手のバイアスを減らせますが、「何が合格か」を発注者が言えないと、正しい対象を検証したことになりません(=間違った要件に対して忠実に合否を出す罠)。だから 1〜5 を受注ゲートにしています。