AIシステムの受入テストと納品時の確認項目

AIシステムの受入テストは、入力ごとに期待結果を先に決め、実際の出力と証拠と未検証の範囲を同じ票へ分けて残す確認です。たとえば正常な依頼はready、目的や視聴者が欠けた依頼と尺が矛盾する依頼はholdと期待し、返ってきた判定と理由コードを照合します。

AIシステムの受入テストで確かめること

AIシステムの受入テストとは、発注時に合意した成果物、確認方法、対象外の範囲を、納品物と実際の出力に照らして受け取れる状態か確かめる作業です。文章の自然さや画面の見た目だけでなく、入力した資料、返ってきた結果、残った不足、次に確認する担当を同じ票に置きます。受入票とは、その照合を一枚で残す記録です。

合格探しではなく照合から入る

納品時の確認は、最初から合格か不合格かを急ぐより、発注時の約束を受入票へ移すところから始めます。IPAの情報システム・モデル取引・契約書は、ユーザ企業とITベンダの取引構造を透明化するため、各開発段階で担う責務の解説と契約書のひな型を提供しています。（IPA 情報システム・モデル取引・契約書）AIシステムの受入でも、責務や成果物を抽象的な合意のまま残さず、納品時に試す入力と期待結果へ置き換える方が確認しやすくなります。

モデル品質そのものの評価では、入力条件、期待行動、停止条件を分ける考え方が役立ちます。（業務で使うAIエージェントの評価方法）一方で納品時の受入では、モデルの優劣や本番移行の判断まで広げず、発注した範囲の納品物を受け取れるかに絞ります。確認する対象は、約束した出力が出るか、資料不足や権限不足で止まれるか、未解決の項目が次の担当へ渡るかです。

受入票の記入例

次の受入票は、商品資料から台本下書きを作るAIシステムを想定した編集部の設計例です。顧客の納品結果や実測ではないため、実際の結果欄には未実施と入れます。期待結果と合格を混同せず、試験入力ごとに何が返れば受け取れるかだけを先にそろえます。

受入票に合格の印だけを入れると、何を根拠に受け取ったかが後から追いにくくなります。実際の結果欄には、出力の本文、表示された不足、止まった条件、担当者が見た記録を入れる余地を残します。未実施の段階で合格を入れず、発注者と開発者が同じ入力を見てから判定します。

数値基準は合意して決める

AIシステムの受入テストでは、合格条件の数値を一般標準として作らない方が安全です。出典表示の一致率、許容する表現ゆれ、確認にかけられる時間、停止すべき条件は、対象業務と納品範囲によって変わります。発注者と開発者が、試験入力ごとに何を数値で見るか、何を人の判断で見るかを分けて決めます。

NISTのAIリスク管理の資料は、AIシステムが意図した目的や目標を達成するか、開発や展開を進めるべきかを判断する観点を示しています。（NIST AI RMF Playbook）受入時には、この考え方を継続評価の大きな話に広げるより、納品物を受け取る瞬間の証跡へ寄せると扱いやすくなります。どの入力で何を期待し、実際に何が返り、未解決のリスクを誰へ渡すかを受入票に残します。

数値を置く場合も、数字だけで合格を決める必要はありません。たとえば出典表示の有無は記録で見られますが、台本下書きとして採用できる表現かどうかは担当者が判断します。数字で見た項目と人が見た項目を分けると、受け取れる範囲と直す範囲を同じ会議で切り分けやすくなります。

約束をAIシステム受入テストへ変える流れ

発注時の約束は、そのまま読むだけでは受入テストに使いにくくなります。納品物ごとに、何を入れて、どの状態なら受け取れて、実際には何が返り、次に誰が見るのかへ分けると、AIシステムの受入テストは会議の感想ではなく記録になります。

約束を試験入力へ写す

試験入力とは、受入テストでAIシステムに渡す資料、条件、権限状態のことです。期待結果とは、その入力に対して事前に合意しておく受け取りたい動作や返答の状態です。商品資料から台本下書きを作る納品物なら、現行の商品資料を渡す入力だけでなく、資料がない入力、権限がない入力も試験入力に入れます。

不足と失敗を同じ票に置く

資料が足りない時の不足と、出力が合意と違う時の失敗は、別のメモへ逃がさず同じ受入票に置きます。実際の結果欄に、返ってきた文章、止まった理由、表示されなかった情報を残し、次の担当欄に資料担当、開発担当、確認担当のどこへ戻すかを書きます。こうすると、合格か不合格かの二択ではなく、受け取れる部分と未解決の部分を分けられます。

AIシステムの出力は、同じ目的に見えても入力条件や資料の版で揺れます。NISTのAI RMF Coreは、AIリスク管理でテストセット、指標、測定に使う詳細を文書化し、展開に近い条件で評価結果を残す観点を示しています。（NIST AI RMF Core）受入時も、一回の印象で文章がよいかを決めるより、どの入力条件でどの期待結果を置いたかを残す方が、あとから差し戻しや再確認をしやすくなります。

商品資料から台本下書きを作る例では、資料なしで止まった結果は失敗ではなく、期待した停止に近い可能性があります。一方で、依頼時に合意した出典表示が出ない場合は、不具合候補として次の確認へ回す対象になります。どちらも同じ票に置くと、資料を足せば進む問題なのか、納品物の動作を直す問題なのかを混ぜずに扱えます。

空欄版で再利用する

受入票は、自社の納品物に合わせて短く書ける空欄版にしておくと再利用しやすくなります。欄は、試験入力、事前に合意する期待結果、実際の結果、次の担当の四つに絞ります。複雑な条件を票の中で長く説明するより、次の担当欄へ送り、誰が何を確認するかを残します。

入力条件と試験結果を残せる受入テスト記入票をダウンロード（XLSX）できます。記事の空欄版に証拠の保存先と判定欄を加えています。記入例も未実施から始め、試験後に実際の結果を記録します。

架空依頼8件で照合した実測例

上の受入票は設計例のため、未実施のまま残します。これとは別に、編集部は2026年10月14日に、架空の動画制作依頼8件を受付判定する小さな検査を1回だけ実行しました。Claude Code 2.1.285を読み取り専用の新規セッションで動かし、各依頼のid、decision、issue_codesを事前に決めた期待結果と照合しています。8件のidは重複なくそろい、照合した3項目は8件とも期待と一致しました。

この一致は、判定と理由コードの照合が通ったことを示す記録です。confirmation欄の文面が適切か、認証や権限の扱い、実案件で受け入れてよいかは検査していないため、合格とは扱いません。実行は1回だけなので、同じ入力で結果が揺れるかもまだ分かりません。

観測と未検証を分けて記録する

受入テスト記入票（XLSX）に写す時は、「事前に合意する期待結果」に期待を書き、「実際の結果」には観測した内容だけを書きます。「証拠の保存先」には実行記録と入力ファイルのハッシュの置き場所を書きます。「判定」には「id decision issue_codesは一致 confirmationは未検証」のように、照合した範囲を書きます。未検証の項目は「次の担当」へ渡し、R06なら尺を決める制作確認担当を記入します。修正後は同じ入力で再実行し、前回の記録と並べて差分を確かめます。この再確認は設計例で、まだ実施していません。

XLSXは、自社の受入票を未実施の状態から書き始めるための本体です。今回の実測例を期待、観測、証拠、未検証へ書き分ける手順と空欄は、別の記入ガイドにまとめました。この記事の記入例と空欄版を使う

試験の前提になる要件の決め方 関連記事を読む

AIシステム受入テストで残す3つの結果

正常資料で見ること

正常資料とは、発注時に使うと合意した商品資料や承認済みの説明がそろっている入力です。商品資料から台本下書きを作る想定では、期待結果を「出典をたどれる下書きが返る」に置き、文章の好みだけで受け入れないようにします。

確認の順番は、下書きの読みやすさより先に、合意した出典表示と本文中の主張が対応しているかを見ることです。SynClipの要件定義の設計例でも、台本初稿に採用資料IDと要確認点を添える形にすると、商品事実の抽出と文章としての採否を分けやすくなります。（AI開発の要件定義）

出典表示があるだけでは、受入の判断としては足りません。資料のどの内容を根拠にしたか、人が確認すべき表現が残っているか、資料更新後に同じ観点で見直せるかを実際の結果欄へ残します。

資料なしで見ること

不足連絡とは、必要な資料や条件がない時に、足りないものを伝えて処理を止める応答です。資料がない入力では、期待結果を「不足を伝え根拠のない訴求を断定しない」に置くと、止まれること自体を成功の一部として扱えます。

AIシステムは自然な文章を返せるため、資料なしでもそれらしい台本を作ってしまうと、受入時には危険な見落としになります。NISTのAIリスク管理フレームワークは、AIシステムの知識の限界や、人が出力をどのように利用し監督するかを文書化する観点を示しています。（NIST AI RMF Core）

資料なしの試験入力では、出力文の完成度ではなく、資料不足を理由に確認待ちへ戻せるかを見ます。実際の結果欄には、どの資料が不足していたか、根拠のない効果や訴求を断定しなかったか、次に誰が資料を補うかを残します。

権限なしで見ること

権限外とは、利用者が読んだり使ったりしてよい範囲の外にある資料や操作です。権限なしの入力では、対象外資料を使わず担当へ連絡できることを期待結果に置き、単なる失敗ではなく引継ぎ先を特定する確認として扱います。

商品資料の台本下書きであれば、利用者が読めない対象外資料を使って下書きを進めるのではなく、アクセス確認や資料管理の担当へ戻す状態を残します。実際の結果欄には、使わなかった資料の種類、連絡すべき担当、利用者側で続けられる確認だけを書き、管理者だけが持つ権限を日常利用者へ渡した前提にしません。

納品後に分ける依頼

納品後の依頼は、同じ「直してほしい」という言葉でも扱いを分ける必要があります。不具合候補とは、依頼時に合意した動作や成果物と実際の結果がずれている可能性を残すものです。変更依頼とは、合意していない機能や運用を後から増やしたいものです。

不具合候補として扱うもの

商品資料から台本下書きを作る受入で、依頼時に合意した出典表示が出ない場合は、不具合候補として残します。責任の所在を本文だけで決めず、合意内容、再現入力、実際の結果、確認担当を同じ記録に置くと、次の確認が感情論になりにくくなります。

変更依頼として扱うもの

合意していない媒体への自動投稿を追加したい場合は、変更依頼として扱います。自動投稿は台本下書きの出力確認とは別の責任を伴うため、追加開発の可否、費用、日程を本文上で断定せず、範囲を確かめる論点として残します。

AI開発の要件定義では、自動公開、入稿、資料にない効果の追加を対象外に置くことで、台本初稿の生成と広告運用の実行を混同しない形にできます。（AI開発の要件定義）受入後に新しい媒体投稿を増やしたくなった時は、既存の不具合として押し込まず、対象外だった作業を追加する相談として分けます。

引継ぎ一覧で残すもの

引継ぎ一覧とは、納品物を使い続けるために、手順、担当、連絡先、未解決項目を受け取る記録です。利用手順、資料更新担当、接続アカウント管理、障害連絡先、保守範囲、未解決項目を分けておくと、受入後の問い合わせが「誰に聞くか」から止まりにくくなります。

• 利用手順は日常の利用者が同じ操作を再現できる形で残す
• 資料更新担当はどの版を正として扱うかを決められる人にする
• 接続アカウント管理は日常利用者と管理者権限を分ける
• 障害連絡先は問い合わせ先と復旧判断の担当を分ける
• 保守範囲は合意範囲の資料として受け取る
• 未解決項目は次に確認する担当と一緒に残す

NISTのAI RMF Playbookは、AIの維持、再検証、監視、更新を誰が担うかを文書化する問いを示しています。（NIST AI RMF Playbook）納品時の引継ぎでも、すべての資料や権利が当然に渡るとみなさず、合意範囲の資料、連絡先、再確認の担当を受け取る形にします。

保守範囲と未解決項目を分けると、追加要望を無料対応とみなす誤解も避けやすくなります。未解決項目は失敗の一覧ではなく、資料更新、権限確認、出力の差し戻し、障害連絡など、次に誰が判断するかを決める欄として扱います。

検証から本番運用へ移す確認項目 関連記事を読む

受入時のよくある疑問

自社の業務で試す

広告制作や運用のAI化はインパクトトライアル（最短1ヶ月のスピード検証）で相談できます。自社の商品資料や台本を使った試作を毎週更新し、工数や差し戻しや本数の変化を数字で確かめます。

インパクトトライアルを見る